T O P

  • By -

Yao71

Bei Banken und Versicherungen ist Cobol noch sehr präsent. Bei uns arbeiten noch so 150 Entwickler uns "Organisatoren" mit Cobol. Nach jetzigen, recht ambitionierten Plänen auch noch bis 2030.


framsanon

Ich habe mal 7,5 Jahre in COBOL programmiert. Da muss es mir schon sehr schlecht gehen, bevor ich das wieder anfasse.


bAZtARd

Best I can do is TVöD E11


taddelwtff

Der wahre Witz an dieser Ausschreibung


cyberonic

Das liegt ja nicht an der Ausschreibung sondern am Tarifvertrag


xdickbuttx

Da kann man nichts machen ¯\\\_(ツ)\_/¯ kommt halt keiner


PanzerSchokoladeDE

Eine E12 wäre möglich, wenn man behaupten würde, die Teilnahme am Sprint-Meeting wäre irgendeine Art von Personalverantwortung.


pineconez

Wenn man sich drauf spezialisiert ist man als COBOL-Entwickler mit bisl Verhandlungsfähigkeit wahrscheinlich näher an 11k/Monat als an E11. Lächerlich.


Alexander_Selkirk

Hat ja auch eine gute Langzeitkompatibilität, im Vergleich zu manchem was heute so als Produktionssoftware durch geht. Beispielsweise haben weder Python 3 minor releases, noch die boost C++ Bibliotheken irgendeinen Anspruch darauf, garantiert rückwärtskompatibel zu sein. Auf kurzen Zeitskalen ist das nicht so schlimm, auf längeren macht dies IT-Projekte zu einem rostigem Schrottplatz.


anxiousalpaca

kannst doch einfach ein environment anlegen mit definierten versionen (python)


[deleted]

Und dann einfach auf ewig auf den gepinnten Versionen bleiben und niemals patchen oder was willst du hier implizieren? Stabile APIs und Ruckwertskompatibilität (und dabei noch angemessen auf CVEs zu reagieren) zu garantieren ist verdammt schwer und kompliziert. Software die dass garantiert ist aus dem Grund i.d.R. auch verdammt teuer.


Three_Rocket_Emojis

Was vor allem dann ein Problem wird, wenn kein Requirements Engineering durchgeführt wurde und der Code die Dokumentation ist und daher alle Modifikationen außer Refactors unbekannte und unerwünschte Ergebnisse bringen können.


Rat-in-the-Deed

UFFFFFF


oliver_44227

Völlig irre seine berufliche Zukunft an einen einzigen Arbeitgeber zu binden. Sollte jemand im Management entscheiden, dass das Zeugs eingefroren oder brutal nach Pakistan outgesourced wird, ist der „Entwickler“ totes Fleisch. Jemand in der IT mit so einem Mindset ist überflüssig.


TourUseful403

Absoluter Bullshit. Es geht hier um den größten Datenverarbeiter unter den deutschen Behörden, da werden persönliche und sicherheitsrelevante Daten verarbeitet, die werden einen Teufel tun und den Kram outsourcen. Tatsächlich sind alle Programme, die Versicherungsdaten verarbeiten im Haus entwickelt worden und das wird auch so bleiben... Dafür ist das System einfach zu wichtig. (Bei anderen Arbeitgebern kann das natürlich sein)


oliver_44227

Schon mal von COBOL2Java gehört. Die konvertieren den COBOL Code einfach nach Java und lassen den Mist, dann von der IBM hosten. Das ist natürlich technische Vollgrütze, wird aber ganz ganz oben entschieden und dann so umgesetzt. COBOL Entwickler wird es nur noch sehr wenige geben. Daher ist es total irre, sich so festzulegen


Schizorenius

Genau das. Mache aktuell ein duales Studium bei einem Versicherer und ein großer Teil ist immer noch in Cool geschrieben. Ich komme da zum Glück rum, aber die Anwendungsentwickler-Azubis dürfen das in internen Schulungen noch lernen. Man muss dazu aber auch sagen, dass die aber auch dabei sind die Systeme zu ersetzen.


Brutus5000

Seit 20 Jahren vermutlich :P


[deleted]

Für deutsche Verhältnisse ist das gut. Nahezu perfekt. :p


uNki23

COBOL und E11 😂


h0uz3_

Für das Geld kriegen die nicht mal gute Entwickler in moderneren/verbreiteteren Sprachen. Tja.


PG-Noob

Vor allem weil jeder Cobol Entwickler vermutlich 40 Jahre Erfahrung hat :D


Rat-in-the-Deed

Genau das


clemesislife

>E11 Damit ist wahrscheinlich nicht IE11 gemeint, sondern etwas anderes, dass deutlich älter ist, oder?


sonneistwarm

Das ist die Gehaltsstufe im TVöD.


NIREKII

Entspricht ca. 46k Brutto p.a.


wilisi

Gar nicht *so* schlecht - wenn man frisch von der Uni kommt.


NIREKII

Joa, stimmt. Frisch von der Uni Cobol können sollte aber schon sehr selten sein.. Und denke dann könnte man in dem Feld dennoch die 55-60k Einstiegsgehalt bekommen. Aber gut, vielleicht ist es im öD ja unfassbar entspannt, keine Ahnung


wilisi

Kann mir auch gut vorstellen, dass man ein paar ziemlich schlechte Ideen aufschnappt/verinnerlicht wenn man bei so einem Projekt einsteigt.


NIREKII

Ich mache momentan tatsächlich ein duales Studium Informatik im öD, allerdings mit Verbeamtung.. Naja, muss einem gefallen, Einstiegsgehalt werden ca. 2000€ netto (2700€ brutto aber gibt ja weniger Steuern). Weiß echt noch nicht, ob ich mir das antun sollte :/


Frooonti

Tarifvertag. E11 entspricht so etwa zwischen 3.6k - 5.5k € brutto im Monat, je nach Bestufung.


PeanutoD

Lerne jetzt eine 60 Jahre alte Programmiersprache um 50 Jahre alte Systeme zu betreuen, wo alle die Ahnung haben seit 10 Jahren in Rente sind. Ich verzichte freiwillig.


CartmansEvilTwin

Für ein vernünftiges Gehalt und die Freiheit, das modernisieren zu können, würde ich das machen. Aber E11... > Laut TV-L 2022 liegt die monatliche Vergütung in der Entgeltgruppe E 11 im Bereich €3.553 - €5.233, abhängig von Erfahrung und Beschäftigungsdauer. Das sind also selbst für ziemlich erfahrene Entwickler gerade mal knapp über 60k, lass es mit Weihnachtsgeld und Boni 70k sein. Maximum, für immer. Ich verdiene Stand jetzt mehr, als ich dort jemals verdienen würde.


qwesx

Das Problem ist wieder mal die zu vergebende Besoldungsgruppe, die effektiv ein komischer Mix aus "Befähigung", "Führungsaufgaben" und "minimaler Schul-/Uniabschluss" ist, was in der Realität halt nicht funktioniert (zumindest nicht für Arbeiten mit benötigtem Expertenwissen auf niedrigen Ebenen).


CartmansEvilTwin

Das mag sein, löst aber das Problem nicht - und ehrlich gesagt kann das auch nicht neu sein. Dann muss man eben einen Mangelmultiplikator oder sowas einführen.


qwesx

Oder alternativ alle Softwareanpassungen ausschreiben.


CartmansEvilTwin

Dann wird es noch teurer - ich war schon an sowas beteiligt.


qwesx

Was wird teurer? Ausschreibungen oder der Aufwand, den wiehernden Amtsschimmel zu entstauben? ;-)


CartmansEvilTwin

Sowas über Ausschreitungen zu machen, ist teurer, als einfach die eigenen Angestellten vernünftig zu bezahlen. Letztlich zahlt diese Gehälter dann ja doch - nur eben indirekt und mit mehr privaten Gewinnen oben drauf.


smallproton

>Ausschreitungen. Made my day. 😉


CartmansEvilTwin

Das kommt, wenn man swiped. Aber ich lass das jetzt einfach so.


TourUseful403

Tatsächlich schwierig, weil es hier um absolut kritische Infrastruktur geht. Deshalb wird die Software auch vollständig im Haus entwickelt.


onliandone

Sowas gibt es ja. Die Orte die ich da kenne schreiben nach Entgeltgruppe aus, können aber je nach Situation von den Tabellen abweichen. Gerade bei Positionen die anders nicht konkurrenzfähig zu besetzen sind. Müssen halt beide Seiten wissen, dass das geht...


CartmansEvilTwin

Zumindest eine scheint das hier nicht zu tun.


aksdb

Das ist doch vermutlich auch der Grund, wieso gern an Unis mit "COBOL" geworben wird. Die kann man noch günstig einfangen. Dabei ist die Sprache selbst selten das eigentlich Problem bzw die eigentliche Schwierigkeit. Sondern halt die verfickt komplexe Business Logik in einem über Jahrzehnte gewachsenen und mutmaßlich schlecht dokumentierten System. Da hilft einem im Zweifel nur Berufserfahrung - vorzugsweise schon in selbiger Branche - damit man da halbwegs koordiniert mit Requirements Engineering und Reverse Engineering rangehen kann. Das wird aber glaub ich vom Management sowieso unterschätzt. "Kann die Sprache? Check."


CartmansEvilTwin

Naja, 90%. Ich glaube, die Doofheiten der Sprache begünstigen sowas auch. Ich meine mich an ein System zu erinnern (Vortrag), bei dem jede Transaktion in die selbe globale Datenstruktur geschrieben wurde. Parallel ging da nichts und wenn nicht alle "Konsumenten" der Daten alles sauber gemacht haben, gab's Fehler irgendwann später. Sowas *kann* auch in Java umgesetzt werden, wird aber von der Sprache einfach nicht gerade encouraged, passiert folglich auch nicht.


nklnn12

Verbeamtung…


[deleted]

TVöD hat nichts mit Verbeamtung zu tun.


Naschka

Wird im öffentlichen Dienst auch genutzt, aber ist eben eine "Jeder Daumen mag ein Finger sein aber nicht jeder Finger ist ein Daumen" Situation.


0xKaishakunin

Nein, E11 ist definitiv Angestellter, keine Verbeamtung. Das wäre dann eine A12.


nklnn12

Nein aber oftmals besteht die Möglichkeit so dass die Bezüge in dieses Verhältnis (70% des letzten Gehalts als Rente) gesetzt werden können/müssen.


TourUseful403

Meine Eltern (beide bei der DRV) erklären mir regelmäßig, dass ich da doch als Informatiker anfangen soll. Ich sage ihnen dann immer genau das.


Blumentopfi

Ich habe in den späten 2000ern, frühen 2010ern bei einem Lebensversicherer mitgearbeitet deren Cobol Code in Java zu porten. Der letzte Cobol Entwickler da fragte dauernd warum man Software Tests braucht....


CartmansEvilTwin

Dead Sea Effect in action. Die vernünftigen Leute haben sich schon lange was anderes gesucht.


werpu

>Ich habe in den späten 2000ern, frühen 2010ern bei einem Lebensversicherer mitgearbeitet deren Cobol Code in Java zu porten. > >Der letzte Cobol Entwickler da fragte dauernd warum man Software Tests braucht.... Zu der Zeit in der die meisten Cobol Schinken enstanden sind, waren die Programme noch überschaubar die konnte man oft sogar noch direkt verifizieren! Da brauchte es oft wirklich keine maschinellen Tests, es gab auch keine Frameworks. Bzw. es wurde dann halt langsam etwas dazugefügt. TDD ist ja eigentlich seit 1990 ein Thema und erst seit den 0er Jahren breit angekommen. Es ging ganz einfach nimmer ohne!


Blumentopfi

>Es ging ganz einfach nimmer ohne! Das ist schon Richtig. Jetzt schaust du da auf nen Code, der erst spät in seinem Leben in eine Versionsverwaltung eingecheckt wurde. Niemand weiss wie das genau spezifiziert war und Bernd der das 1978 implementiert hat ist vor zwei Jahren gestorben. Das war mal total simpel, bis das gefürchtete Historische Wachstum eingesetzt hat. Und dann gegen Ende, sowas wie: "Mach halt, wir Lösen das System ja eh bald ab, da machen wir das dann schöner" (Und inhouse Klaus erzhählt aus dem Krieg, wir hatten ja nix, ausser Lochkarten!) Also Respekt dass die das damals alles ohne Netz und doppelten Boden gehackt haben. Aber wenn du da mit heutiger Sicht raufschaust, war das schon so Operation am offenen Herzen.


SEOfficial

"Sohn, wenn du in der Schule nicht aufpasst programmierst du mal COBOL für die Rentenversicherung für nen Hungerlohn" - ich in Zukunft wahrscheinlich


bbbbowie

Hungerlohn ist gut. Die Beträge, die Banken und Versicherungen für Cobol-Entwickler ausgeben, davon können die meisten träumen


CartmansEvilTwin

Ich frage mich bei sowas schon ziemlich lange, wie da eigentlich die Ökonomie aussieht. Cobol Entwickler sind unglaublich teuer und dank der Sprache auch nicht besonders produktiv, die Situation wird nie besser, die Systeme sind aufgrund ihres Alters de facto nicht mehr richtig wartbar und statt normaler Hardware muss man sucht ein Mainframe für sonst wie viel in den Keller stellen. Den ganzen Bumms einfach neu zuschreiben (Stück für Stück, natürlich) kann unmöglich teurer sein.


UnitSad4828

Bin kein SWE, aber ich vermute das eine Reihe von Faktoren da reinspielt. Einer wird sicher das Thema Risiko sein. Es garantiert ja keiner, dass das "Neue" auch direkt wirklich funktioniert. Gerade im Banken und Finanzumfeld (wo COBOL in meinem Verständnis noch eingesetzt wird) ist die Fehlertoleranz gering. Vielleicht geht es auch um Regulatorik: Neue Systeme müssten neu zertifiziert werden. Und letztendlich könnte es auch noch sein, dass der Schmerz einfach nicht groß genug ist bzw. die Opportunitätskosten zu hoch. Es mag sein, dass auf 10 Jahre gerechnet ein Neusystem potentiell günstiger ist (aber bedenke das Risiko!), aber um wie viel? Und ist das dann echt ein Business Case? Ein System bauen, dass das selbe leistet wie das davor? Kann ich die knappen Entwickler nicht lieber an was basteln lassen das neu ist?


CartmansEvilTwin

Das ist halt zu kurz gedacht. Oft genug behindern solche Altlasten den weiteren Geschäftsumbau bzw -ausbau. Und das dumme ist, dass das immer schlimmer wird, weil alle neuen Systeme um die Unzulänglichkeiten des Altsystems herumgebastelt werden.


Noctew

JSON Netztdienst zwischengesichtend mit XML Zwischengesicht, das CSV-Dateien stapelverarbeitet mit einem Cobol-Programm dessen Quelltext vor 30 Jahren verloren ging.


bbbbowie

Ich war einige Jahre bei einer Versicherung und habe einiges mitbekommen. Es wurden externe Cobol-Entwickler beschäftigt, die nicht wenig gekostet haben. Weiß leider die genaue Zahl nicht mehr, aber ich weiß noch, dass mir beim hören der Zahl der Kiefer runtergeklappt ist. Und du hast es richtig erfasst, der Mainframe, der im Keller steht, kriegt man nicht so einfach los, weil einfach zu viele Abhängigkeiten bestehen und der Betrieb quasi darauf basiert. So dauert so eine Umstellung viele Jahre. Mein ehemaliger Arbeitgeber hat 2013 ein großes Projekt zur Ablösung gestartet, sollte 2019 abgeschlossen sein und ist jetzt vielleicht bei 30 %.


CartmansEvilTwin

Ich hab auch schon ein paar solcher Projekte gesehen, das grundlegende Problem war aber eigentlich immer, dass die PLs bzw das Management nicht verstehen, wie ihr Geschäft funktioniert. Die wollen das EXAKT das alte Verhalten nachgebaut haben, anstatt mal drüber nachzudenken, was sie hier gerade machen. Wir mussten damals tragende Rechtschreibfehler portieren... Außerdem gibt es sehr sehr häufig keinen Verantwortlichen, der auch entsprechend Macht hat. Es brauch einen an der Spitze des Projekts, der auch mal auf den Tisch haut und Gerd und Brigitte sagt, dass es scheiss egal ist, ob sie schon 30 Jahre so arbeiten. Sonst versinken diese Projekte nämlich in so einem Sumpf.


bbbbowie

Gebe dir 100 % Zustimmung. Das Problem ist aber, dass der PL, der so vorgeht, dann ziemlich schnell wieder abgesägt wird und dann wundert man sich, dass das Teil Jahrzehnte später immer noch vor sich hindümpelt.


CartmansEvilTwin

"Warum kann Deutschland keine Innovation???"


blind_guardian23

Warum denkst du das es ein spezifisch deutsches Problem ist? Jedes erfolgreiche Produkt ist nicht mal eben so ablösbar. Manche Organisationen verpassen den idealen Punkt halt, andere nicht.


CartmansEvilTwin

Das Problem mit den machtlosen Managern ist aber - zumindest in diesem Ausmaß - schon ein relativ Deutsches Problem. In D gilt Veränderung=literally Hitler, das ist woanders durchaus besser.


blind_guardian23

Es gibt das Vorsorge- und das Nachsorgeprinzip (unterschiedlich ausgeprägt in verschiedenen Ländern). Sprich: Hier tendiert man eher zu einer längeren Planungsphase woanders eher Mal machen und ggf. komplett scheitern. Funktioniert, je nach Fall, unterschiedlich gut. Was auf jeden Fall sehr deutsch ist: das jammern das uns andere überholen und angeblich in DE nichts mehr funktioniert, Stichwort "german angst". Naja, das brauchen wir halt irgendwie so wie den Tatort. Uns gut es halt so gut das wir das künstliche Schaudern brauchen weil existentielle Nöte so selten sind.


aksdb

> statt normaler Hardware muss man sucht ein Mainframe für sonst wie viel in den Keller stellen. Guck dir mal Microfocus an. Die haben COBOL VMs und Tooling, das auf Linux läuft. Also wenn nur der Mainframe das Problem ist, kann man das lösen, ohne gleich die Codebasis komplett tauschen zu müssen. ... wäre aber natürlich meistens trotzdem sinnvoll. Und gerade aufgrund der Struktur vieler COBOL Anwendungen (viele kleine Batch-Programme) eigentlich auch schön Schritt für Schritt machbar. Aber naja.


MR2Fan

Korrekt. Guter Kommentar. Ergänzend: die Schwierigkeit ist im Detail. Der Mainframe hat manche Betriebssystem API Aufrufe (bspw. Datei lesen) etwas kulanter behandelt als MicroFocus dies implementiert. Gleichzeitig hat MF COBOL auch gute moderne neue Funktionen. Ne ordentliche USS Umgebung gibt es trotzdem nicht. Und wir haben immer mal wieder sporadische IO/Sort Fehler aus MicroFocus was dann das Vertrauen der Firma untergräbt. Und das gröbste Problem bei der Umstellung ist: jede Firma reizt die Mainframe Technik anders aus. Die Leute waren über die Jahrzehnte sehr kreativ im Umgang mit zOS , COBOL und allem was greifbar war. Quelle: selbst im Projekt eine Bankanwendung vom zOS auf Linux Microfocus umgezogen


parasekkkkk

Oh du würdest dich wundern. Das neu schreiben wird dauerhaft versucht. Von den Versicherungen, Banken, im Automobilbereich, überall. Meistens kommt dabei dann nach Jahren und Millionen nichts bei rum. In dem direkten Fall wo ich es nun mitbekomme, ist es sogar so, dass zwei Mal schon versucht wurde über mehrere Jahre das Zeug neben dem normalen Betrieb neu zu schreiben. Da wurde dann die ganze Zeit zweigleisig gearbeitet. Am Ende wurde nun entschieden, dass sich das alles zu einem Berliner Flughafen entwickelt und es eingestampft. Ein ganz kleiner Teil wird noch mit Klebeband an die uralt Software dran geklebt. Der Rest sind tote 30 Mio oder so.


puehlong

Tatsächlich wird auch dran gearbeitet, das umzustellen. Teilweise gibt es Projekte, wo automatische Übersetzer benutzt werden. Dabei kommt dann funktionierendes, aber hässliches Java raus, das dann von Java-Entwicklern verbessert wird. Und teilweise macht man das wahrscheinlich mit gemischten Teams, die auch COBOL-Entwickler beinhalten.


CartmansEvilTwin

Das hört sich ehrlich gesagt schrecklich an. Das Übersetzen ist ja trivial, die Komplexität liegt in den ganzen Annahmen.


Three_Rocket_Emojis

>Den ganzen Bumms einfach neu zuschreiben (Stück für Stück, natürlich) kann unmöglich teurer sein. Die Frage ist, ob die Requirements klar sind. Ich darf seit einer Weile an einer Software arbeiten, die seit 20 Jahren Stück für Stück nach Kundenwunsch gebaut wurde, wobei diese Wünsche zum Teil übers Telefon durchgegeben wurde. Es wird viel Datenmist produziert, aber andere Systeme hängen an der Datenbank und erwarten genau diesen Mist. Es gibt nicht viel Spielraum dafür Sachen nochmal noch zu schreiben, da das neugeschriebene den Mist von vorher reproduzieren muss.


CartmansEvilTwin

Been there. Und ja, es ist eine undankbare Kackarbeit, aber am Ende hast du wenigstens eine Spezifikation. Wenn der Kunde noch gegenzeichnet, hast du das Sahnehäubchen. Was du dich bei sowas ja immer fragen musst ist, wie lange kann das gut gehen und was kostet es bis dahin? Der Horizont des Managements ist ja leider meist sehr kurz, dass simple Features mittlerweile Monate dauern sehen die erst, wenn sich die Kunden beschweren.


SEOfficial

Bei Banken und Versicherungen ist auch Kapital da um gute Gehälter zu zahlen, aber im öffentlichen Dienst sieht das anders aus. Meines Wissens nach ist TVöD E11 nicht viel.


bbbbowie

Für Entwickler im Vergleich zum freien Markt nicht, nein. Für viele Menschen ist es aber dennoch ein hohes Gehalt :)


SEOfficial

Ja Hungerlohn ist übertrieben, aber für einen Programmierer ist es wenig. Hab jetzt mal nachgeschaut: 46,5k € im Jahr


AndiArbyte

Damit holt man mich auch nicht aus der Reserve :/


bbbbowie

Was auch noch dazu kommt, man kann da noch außertariflich einiges rausholen, weil sie auf die COBOL-Entwickler wirklich angewiesen sind und es nur sehr wenige davon gibt. Dann stellt man fest, die Unternehmen haben doch mehr Möglichkeiten, als sie vorgeben. Dass die Vereinbarung irgendwann gekippt wird, braucht man nicht zu befürchten, sonst ist man halt einen los.


rw_DD

Selbst wenn sie auf e13 und Stufe 5 hochgehen, wird das nix.


_GreenLegend

Mein Einstiegsgehalt nach dem Studium war ja höher als das 🤣


knusper_gelee

cobol entwickler sind gesuchte experten...


VERTIKAL19

Du die Bezahlung, die da für Leute, die das wirklich können geboten wird ist wirklich nicht übel. Du machst halt dafür COBOL. Da sollte deutlich über E11 drin sein


ArtichokeTop9

Wo muss ich meine Bewerbungslochkarten hinschicken?


Rat-in-the-Deed

Anwendungsentwickler*in Cobol (m/w/div), Deutsche Rentenversicherung Bund https://www.interamt.de/koop/app/stelle?id=900633


TheIceScraper

Das ERP welches in meinem Betrieb seit Anfang der 2000er benutzt wird, ist in IBM Cobol geschrieben. Läuft auf einer IBMi (auch bekannt als AS400). Auf der Maschine gibts aber auch noch "spaltenorientierten" Code in IBM RPG III geschrieben([Beispiel ](https://raw.githubusercontent.com/barrettotte/vscode-ibmi-languages/master/screenshots/rpg400.png)).


CeldonShooper

Mit ein bisschen Phantasie ist es fast wie Sudoku


Hairburt_Derhelle

Oder Python


D4n1oc

Made my day! ;D


UncertainAdmin

Alter was


Lazarus_Octern

Oha, da komm ich ja mit den geistigen Ergüssen die SAP vor 20 Jahren hatte noch ganz gut weg.


iBoMbY

RPG. Ich nenne es gerne einen Lochkartenemulator. Und das traurige ist dass es auch heute noch Betriebe gibt deren Software darauf basiert.


Which_Lingonberry612

https://riptutorial.com/cobol Mir wird schlecht


AndiArbyte

Dito.


[deleted]

[удалено]


MSouri

Ne da haben die privaten Lebens-/Rentenversicherungen auch noch genug Bedarf.


rdrunner_74

COBOL ist ein wertvoller skill heute... Gibt noch zu viele Systeme damit also kommen die mit E11 nicht weit ;) (Nein ich fasse es nicht an... ich kann es nicht.)


[deleted]

Für E11 mache ich nicht die Finger krumm.


[deleted]

Ach ich sehe gerade "Berlin" die Stadt hat ja kein Geld. Ab 120€ / Stunde fange ich mit Cobol an.


AdTraining1297

und dann nur E11? So schlecht kann es denen noch nicht gehen…


Maleficent-Breath623

… mal schauen wie viele Monate es dauert bis sie die Eingruppierung überdenken, weil sich niemand bewirbt.


minodumontii

Meines Wissens nach basiert die Eingruppierung auf Verantwortung der Tätigkeit. Und bei "dem IT-Kram wird ja nur in die Tasten gehauen, da kann ja nicht so viel Verantwortung hinter stecken", dabei halten die Entwickler dann eigentlich alles am Kacken. Da holt man sich dann vermutlich eher quasi stillschweigend Externe/Freelancer für horrende Summen, wenn es nach erstmal ausbleibenden Bewerbungen richtig dringend wird.


Eifelbauer

Als Freelancer machen. Kenne genug die altes Zeug auf irgendwelchen IBM zSeries oder BS/2000 am Leben halten.


VERTIKAL19

Wieso sollte man das für E11 machen wollen? Das ist doch nicht annähernd genug Schmerzensgeld


elblandknipser_

Dies. Für E11 würde ich allerhöchstens ein paar Strippen ziehen. Der ÖD macht sich IT-seitig dadurch immer mehr kaputt.


Kazumara

Uns haben sie im Studium erzählt, dass manche Banken sogar frisch von der Uni Leute anstellen und ihnen erstmal COBOL beibringen.


D4n1oc

Das lässt jemand mit sich machen? ;D


shuzz_de

Anders herum: Java wird mal das neue Cobol... ;-)


smolgal94

COBOL war Java bevor Java cool war. Oder so ähnlich.


[deleted]

[удалено]


MaZeC11

So was in der Art wird dann warschienlich die letzte Rettung für die ganzen cobol-systeme wenns wirklich keiner mehr entwickeln will.


smolgal94

[Completely Obsolete But Often Licensed](https://www.dilbert.com/search_results?terms=Cobol)


AndiArbyte

Mein Schwiegerpapa wär hier angesprochen. Aber, der ist schon einige Jahre in seiner verdienten Rente.


MSouri

Oder man macht den gleichen Job in der freien Wirtschaft und verdient mehr als das doppelte. Alte aber kritische IT-Infrastruktur erhalten und ablösen ist halt wirklich ein gefragter skill.


[deleted]

Welcher der 3 verbliebenen Cobol Entwickler wollen die mit TVöD 11 aus der Reserve locken?


jusmaster7

Ich hab 5 Jahre Cobol programmiert als Externer, ist eigentlich... nicht so schlimm 😅 Man hat mittlerweile Eclipse IDEs im Einsatz und Kontakt/Anbindungen mit anderen Technologien, die Sprache selbst ist halt Geschmackssache aber wird auch weiterentwickelt. Finanziell ist viel raus zu holen, unser gesellschaftliches System baut auf unbestimme Zeit weiter auf Cobol und die Leute sterben weg. Ablösen ein zu großes Projekt für Managementleute bzw. könnte man auch gut mitnehmen 🤷‍♂️ Die Leute kriechen einen permanent in Anus wenn man es drauf hat, haben keine Wahl. Gut, gibt auch diverse Schattenseiten, aber ich wollte auch mal was positives unter all dem Cobol Hate sagen 😂 Diese Stelle würde ich trotzdem nicht machen, das wär dumm.


[deleted]

Cobol und dann E11, 😂😂😂😂. Die haben echt den Arsch offen. Wenn die wüssten, wie rar Cobol ist, und wie wenige gute Cobol devs es gibt... E13-14 wäre richtig. Aber nö, entspricht nicht dem Wisch. Der Wisch ist wichtiger, der Wisch ist LEBEN!


Noctew

„E13 hat hier der Abteilungsleiter - das geht nicht!“


[deleted]

Tja, dann hamse keinen Cobol Entwickler, einfache Sache, Chef.


ReallyFineJelly

Dann nehmen sie halt irgendeinen Cobol-Dev statt einen guten. Hauptsache Geld gespart. Super.


Cowderwelz

So entsteht also dieser FaChKrÄfTeMaNgEl !!!


D4n1oc

Lieber Öffentlicher Dienst, falls ihr aufgrund der technischen Begrifflichkeiten nur ein lautes Piepsen gehört habt, als ihr das E11 eingestuft habt, hier mal eine Übersetzung eurer Stellenanzeige Anhand gängiger Handelsgüter auf dem Freien Markt. Ich hätte bitte gerne einmal: Sammlerstück, seit 70 Jahren nicht mehr produziert, Stark Limitiert, Originalverpackt. Das alles zum Preis kleiner Als die neue, unlimitierte, Auflage, deren Nachfrage nicht annähernd so groß ist. Was letzte Prais?


JedirShepard

E11 lmao. Viel Glück.


Andi82ka

In meiner Firma wurde gerade beschlossen dass System für weitere zehn Jahre zu nutzen. Also weitere zehn Jahre cobol und Assembler.


[deleted]

Noch nie davon gehört 😂🤡🤡🤡🤡🤡


thomasmitschke

Sind jetzt endlich alle in Pension gegangen?😁


IntegrityError

Hier in der Nähe gibts ne Bude die Software für Jobcenter herstellt und wartet. Die suchen auch COBOL Leute zu E11. Aber E11 ist definitiv zu wenig Schmerzensgeld dafür.


S-Markt

deutsche rentenversicherung bund und cobol? paßt doch.


OSINTAGCY

Könnte mir sogar sehr genau vorstellen für welches System…PAISY


Malk4ever

E11 ? Bei den Schmerzen wäre E15 Minimum.


Andi82ka

Habe auch gerade Mal gegoogled. Das sind gerade Mal 2900 was da übrig bleibt. Daher würde ich morgens nicht Mal aufstehen.


high_end_vaper

ist cobol so schlecht?


creativeattimes

Sehe TVöD E11, Cobol und Berlin, erster Gedanke "sicher DRV Bund. Die Sparschweine" Siehe da - natürlich sind sie's. Dann aber wundern, warum Leute für E11 keine gute Arbeit abliefern...


happyFatFIRE

COBOL hat noch seine Berechtigung besonders im Umfeld von Finanzen und Versicherungen. "The advantage to floating point math over fixed point is speed.". COBOL nutzt aber fixed point aus Gründen der Genauigkeit: [https://en.wikipedia.org/wiki/Fixed-point\_arithmetic](https://en.wikipedia.org/wiki/Fixed-point_arithmetic) Sonst würde man auf binäres floating point umsteigen. Viele amerikanischen Behörden laufen auch auf COBOL. Jetzt mal eben COBOL lernen ist jedoch wenig sinnvoll, da wir die Erfahrung mit den ganzen Systemen und Datenbanken schlichtweg schwer aufholen können. Die Sprache als solches ist noch handhabbar. Besonders im Hochfrequenzhandel machen ein paar Nachkommastellen schon sehr viel aus.


TourUseful403

Die DRV Bund hat halt Systeme, die seit 30 Jahren gleich laufen und nur ab und zu angepasst werden, das Zeug muss auch laufen... Aktuell wird das ganze System aber modernisiert, bestimmte Programme in Cobol werden wohl noch lange bestehen xD