Interview mit meiner Mutter, einer Mainframe-COBOL-Programmiererin (2016)
(ezali.substack.com)Interview mit meiner Mutter, einer Mainframe-COBOL-Programmiererin
- Meine Mutter arbeitet seit vor meiner Geburt bei einer der größten Banken der EU.
- Die Welt der Bankprogrammierung ist eine völlig andere Welt als die, mit der die meisten Menschen vertraut sind.
- Wenn meine Mutter und ihr Team aufhören würden zu arbeiten, wäre die Bank innerhalb weniger Wochen ruiniert.
1991
- Meine Mutter begann ihre interne Ausbildung bei Nordbanken (heute Nordea).
- Sie legte verschiedene Tests ab und bestand einen IQ-Test, psychologische Tests und einen Multitasking-Test.
- Sie begann als IBM-Mainframe-COBOL-Programmiererin und übt 25 Jahre später bei derselben Bank noch immer dieselbe Tätigkeit aus.
COBOL
- COBOL ist keine coole Programmiersprache wie das funktionale Haskell oder das nebenläufige Golang.
- COBOL ist eine imperative, prozedurale Sprache und seit 2002 auch objektorientiert.
- Im Kontext der Mainframe-Programmierung gibt es kaum Menschen, die COBOL beherrschen.
Datenbank
- Die Hauptdatenbank heißt IMS, eine hierarchische Datenbank, die IBM für das Apollo-Programm entwickelt hat.
- Es gibt Versuche, auf DB2 zu migrieren, aber das ist eine Aufgabe, die Jahre dauern wird.
- Die DB2-Datenbank enthält derzeit etwa 10 TB an Daten.
Batch
- Etwa 80 % des Systems bestehen aus Batch-Jobs.
- Batch-Jobs werden zu bestimmten Zeiten oder Intervallen ausgeführt und verarbeiten Daten oder übertragen Daten an andere Banken/Institutionen.
Probleme, mit denen die Bank konfrontiert ist
- Banken, die Mainframes verwenden, haben viele Probleme zu bewältigen.
- Die Programmierer werden älter, und neue Mitarbeiter brauchen 2–3 Jahre, bis sie selbstständig arbeiten können.
- Es gibt Programme, die mehrere Jahrzehnte alt sind, und niemand weiß, was sie tun.
Schlusswort
- Es ist sehr interessant, welche neuen Technologien Nordea und andere Banken in den kommenden Jahren einführen werden.
Q & A
- Warum haben Sie sich für IBM-Mainframe-COBOL-Programmierung entschieden? Weil ich mit Computern arbeiten wollte.
- Was war das Schlimmste, das an einem Arbeitstag passiert ist? Ein Kollege vergaß einen Punkt in einem wichtigen Systemmodul, wodurch die Bank 16 Stunden lang ausfiel.
- Wie sieht die Zukunft der Bank aus? Man erkennt, dass der Mainframe durch etwas Moderneres ersetzt werden muss.
- Mit welchen Herausforderungen waren Sie als Programmiererin in den 90ern konfrontiert? Mit keinen.
- Wird es langweilig, mehr als 20 Jahre mit derselben Codebasis zu arbeiten? Es hat immer Spaß gemacht, neue Systeme zu bauen.
- Ist es beängstigend, Code für eine Bank zu schreiben? Sehr beängstigend, aber die Testumgebung ist robust, sodass meistens alles reibungslos läuft.
- Haben Sie je einen großen Fehler für die Bank gemacht? 1997 machte ich einen Fehler, durch den man unrechtmäßig Geld von Altersvorsorgekonten abheben konnte.
- Wie ist die Arbeitsumgebung? Wir sind vom eigenen Schreibtisch in ein Großraumbüro umgezogen, und ich hasse das sehr.
Meinung von GN⁺
- Mainframes und die Sprache COBOL spielen in der Finanzindustrie noch immer eine wichtige Rolle, und Fachwissen zu dieser Technologie ist sehr wertvoll.
- Die Komplexität von Bankensystemen und die Abhängigkeit von alten Technologien erschweren den Übergang zu neuen Systemen, was eine große Herausforderung darstellt.
- Dieses Interview zeigt im Kontrast zur schnellen technologischen Entwicklung, dass in manchen Branchen noch immer alte Technologien verwendet werden, was einen interessanten Gegensatz bildet.
1 Kommentare
Hacker-News-Kommentare
Der ursprüngliche HN-Post von 2016 war https://news.ycombinator.com/item?id=12096250
Wer zum Thema „Die Welt der Bankprogrammierung ist eine völlig andere Welt als die, mit der die meisten von uns vertraut sind“ mehr lesen möchte, dem sei auch An oral history of Bank Python empfohlen: https://calpaterson.com/bank-python.html
War damals auch auf HN: https://news.ycombinator.com/item?id=29104047
https://news.ycombinator.com/item?id=12097032
Oft wird angenommen, dass man als 20-jähriger Mainframe-Programmierer wegen des Alters einen enormen Wert habe und entsprechend sehr gut bezahlt werde, aber in der Realität ist das Gehalt meist durchschnittlich oder sogar unterdurchschnittlich, wodurch ein Pipeline-Problem beim Nachwuchs entsteht
Der eigentliche Wert liegt nicht in einer Fähigkeit wie „COBOL kennen“, sondern im Organisationswissen über die gewaltige Geschäftslogik, die sich in COBOL angesammelt hat. Ein durchschnittlicher Entwickler kann COBOL lernen, aber wenn ein pensionierter COBOL-Programmierer mit einem Vertrag über 500.000 Dollar pro Jahr zurückkommt, dann nicht wegen COBOL, sondern wegen des angesammelten institutionellen Wissens
Wenn Banken und Institutionen jungen Mainframe-Programmierern tatsächlich sehr hohe Gehälter gezahlt hätten, wäre das heutige demografische Problem wohl weniger gravierend
Das Projekt galt als fast abgeschlossen, und das Rewrite-Team meinte, inzwischen genug mit COBOL vertraut zu sein, um den Rest ohne ihn zu schaffen. Tatsächlich verstanden sie COBOL zwar, brauchten aber sein institutionelles Wissen dringend. Am Ende kehrte er bis zum Abschluss der Umstellung in Teilzeit zu einem absurd hohen Beratungsstundensatz zurück und baute parallel im Graduiertenstudium seine Fähigkeiten aus
Ein ordentlicher Programmierer kann ein COBOL-Programm lesen und nachvollziehen. Aber er weiß nicht, warum ein zentraler Export beim Datenabzug für das 10-K-Filing abstürzt. Der Grund ist, dass irgendwann jemand annahm, eine bestimmte Anzahl von Datensätzen werde nie über 3000 steigen, und deshalb hart kodiert hat, dass darüber einfach ein Fehler ausgelöst wird
Tatsächlich habe ich deutlich weniger verdient als in meinem vorherigen Job als Installateur für physische Kabelinfrastruktur, also Glasfaser- und Kupfer-Ethernet-Verkabelung, und der Hauptgrund, warum ich den Job annahm, war im Wesentlichen, dass es im Büro eine Klimaanlage gab. Es war nichts, worauf ich meine Karriere aufbauen wollte
Als ich später als Mid-Level-Windows-Systemadministrator im telefonischen Kundensupport bei einem Cloud-Anbieter arbeitete, verdiente ich fast 30 % mehr als damals als Junior im Mainframe-Bereich bei Banken/Versicherungen. Obwohl es eine seltene Fähigkeit in einer wertvollen Branche ist, wurde Mainframe-Arbeit viel schlechter vergütet, und in diesem Unternehmen bekamen Mainframe-Entwickler auf allen Erfahrungsstufen die niedrigste Bezahlung unter den Entwicklern. Ordentlich bezahlt wurden nur die unabhängigen Auftragnehmer, die vor dem Ruhestand 30 Jahre dort gearbeitet hatten
Aber die Bezahlung in solchen Rollen ist im Vergleich zu dem, was ich mit anderen Technologien bekommen könnte, erbärmlich, und das moderne Leben setzt einen stark unter Druck, dem höheren Gehalt hinterherzulaufen
Das Programm bot den „fairen“ Marktpreis für Einstiegsstellen in der Branche und ließ die Teilnehmer im ersten Jahr 2 bis 3 Teams oder Abteilungen durchlaufen. Am Ende konnten die Kandidaten, wenn ihnen das Unternehmen immer noch gefiel, auswählen, in welches Team sie fest wechseln wollten, aber es gab keine Gehaltserhöhung, und bis dahin waren die Leute, die nicht schnell genug Leistung brachten, bereits ausgesiebt worden
Für das Unternehmen war das Ergebnis hervorragend. Es konnte junge Programmierer, die in COBOL kompetenter waren als neue Kollegen, für 60.000 bis 70.000 Dollar pro Jahr beschäftigen, während Senior-Kollegen oder langjährige Mitarbeiter je nach Fall 200.000 bis 400.000 Dollar verdienten
Meine Großmutter hat mit Lochkarten programmiert, aber ich weiß nicht, auf welcher Hardware, und jetzt ist es zu spät, sie noch zu fragen. Mein Vater hat auf sowjetischen Mainframes viel Fortran und COBOL gemacht und später in den USA auch viel an Y2K gearbeitet
Eines der coolsten Dinge darunter ist ein Ausdruck eines Fortran-Programms, den mein Vater früher in drei Streifen gerissen und verwendet hat, um 64-mm-Großformatfilm mit Bergfotos von ihm zu umwickeln. Wahrscheinlich stammt er von einem Minsk-32-Mainframe, der Programmname ist MATR1, es geht um Matrixmanipulation, und in den Kommentaren wird Gelände erwähnt. Heute habe ich ihn gerahmt an der Wand nahe meiner Werkbank hängen
Ich selbst habe mein ganzes Leben in verschiedenen Sprachen programmiert, und jetzt zeigt mein Teenagerkind in der Highschool Interesse am Programmieren und macht dort Java und Python. Auf dem Weg zur vierten Generation von Programmierern
Wenn es stimmt, dass dies aus technischer Sicht die wichtigste Position in einer Bank ist, dann könnte angesichts des Marktanteils von Nordea in Schweden und Nordeuropa das Verschwinden dieses Teams Schweden, vielleicht sogar die nordische Wirtschaft, ins Wanken bringen. Das dürfte dann auch die EU ziemlich stark betreffen.
Seit ich das gelesen habe, frage ich mich immer wieder, ob die COBOL-Programmierer, die solche Banken am Laufen halten, nicht in vielen Volkswirtschaften der Welt ein massiv unterschätzter Bus-Faktor sind. Ich frage mich auch, was der Notfallplan für so eine Situation wäre.
[0] https://en.wikipedia.org/wiki/Nordea
Ich vermute, dass der Verlust institutionellen Wissens ein großer Faktor bei diesem Desaster war.
Wenn man noch den zunehmenden Verkauf von SUVs dazunimmt, die für Fußgänger und Radfahrer gefährlicher sind, ist es fast erstaunlich, dass Banken nicht wegen toter Programmierer zusammenbrechen, sondern wegen schlechter Buchhaltung und Betrug.
Die Stelle mit „Ich hatte einen eigenen Schreibtisch, jetzt bin ich in einen offenen Bereich umgezogen, in dem man sich einfach irgendwo hinsetzt, und ich hasse es wirklich“ trifft mich seltsam stark, obwohl ich nie mit Mainframes gearbeitet habe.
Stuhl, Monitorposition und -helligkeit, Schreibtischhöhe usw. sind dann auf die eigene Person eingestellt, wodurch das ganze Konzept des Hot-Desking lächerlich wird. Ich wünschte, man würde es einfach offiziell aufgeben.
Als Systemintegrationsberater im Finanzdienstleistungsbereich musste ich sehr oft mit solchen Core-Banking-Systemen integrieren.
Wenn man eine komplett neue Schnittstelle aushandeln musste, gab es meist so viel Reibung auf technischer, geschäftlicher und regulatorischer Compliance-Ebene, dass sich das Projekt leicht um 1 bis 2 Jahre oder mehr verzögern konnte; deshalb haben wir versucht, bestehende Integrationspunkte aus früheren Projekten wiederzuverwenden.
Die Integration bestand meist darin, strukturierte Dokumente bis zu einer bestimmten Uhrzeit am Abend für die nächtliche Stapelverarbeitung zu liefern. In offsetbasierten Datendokumenten sind absichtlich noch nicht zugewiesene Bereiche für künftige Updates und Nutzung vorgesehen, und wenn neue Informationen nötig waren, wurde ausgehandelt, welche Bytes davon verwendet werden konnten.
Auf der Seite der Datenextraktion suchte man manchmal nach etwas „moderneren“ APIs, aber allzu feingranulares REST sollte man nicht erwarten. Häufig saß ich mit Regulierungs- und Compliance-Verantwortlichen in Meetings, um Wege zu finden, kostspielige Neuentwicklungen zu vermeiden.
Nebenbei bemerkt waren die Compliance-Leute oft viel pragmatischer und lösungsorientierter als die IT. Unser Team davon zu überzeugen, dass der Wortlaut einer Vorschrift nicht zwingend in der engstmöglichen wörtlichen Auslegung verstanden werden muss, war oft schwieriger, als sich mit den Compliance-Leuten zu einigen.
Wenn man sich vorstellt, dass sich eine solche Integrationsschicht über Jahrzehnte in Hunderten von Projekten aufgebaut hat, bekommt man zum ersten Mal ein Gefühl dafür, warum ein Austausch des Kernsystems so schwierig ist.
Meine Schwiegermutter hat ihr ganzes Berufsleben in der IT-Abteilung einer Versicherung gearbeitet. Sie hat nicht viel programmiert, wurde aber mit der Zeit zu einer Quelle von Domänenwissen.
Es gibt viele alte Geschichten. Vor richtigen Computersystemen wurde natürlich alles in physischen Dokumenten abgelegt, und ihr erstes Projekt nach dem Studienabschluss bestand darin, Außenstellen abzufahren, um deren Ablagesystem nach der neuen Strategie der Zentrale neu zu organisieren.
Während das Team buchstäblich jedes Dokument herausnahm, neu beschriftete und wieder einordnete, stand die Arbeit in der jeweiligen Filiale still, und das gesamte Projekt dauerte über ein Jahr. Das hat meine Sicht auf meine eigene Arbeit etwas verändert.
Ich wünschte, ich hätte mehr mit meiner Großmutter gesprochen, bevor sie dement wurde. Ich wusste, dass sie Mathematikerin und Programmiererin war, aber als wir vor ein paar Jahren kurz darüber sprachen, erzählte sie, sie habe in der Sowjetunion Satellitenbahnen berechnet.
Hoffentlich waren es zumindest Satelliten.
Mit 20 hatte sie in nur 3 Jahren einen Mathematikabschluss gemacht, und in den 1970ern programmierte sie Computer mit Lochkarten.
Heute kann sie nicht einmal mehr zuverlässig ihre Schnürsenkel binden. Ich hoffe, ihr haltet die Leistungen und Lebensgeschichten der Menschen fest, die ihr liebt, bevor es zu spät ist.
Sie ist einfach zu benutzen, hat viele vorbereitete Fragen, und man kann auch eigene erstellen. Man nimmt direkt auf dem Handy auf, und wenn man möchte, kann man das Interview an die Library of Congress der USA hochladen.
https://storycorps.org/participate/storycorps-app/
Meine Großmutter ist dieses Jahr 95 geworden. Sie geht immer noch jeden Tag in ein Forschungsinstitut im postsowjetischen Raum und schreibt numerische Simulationen mit Fortran und Maple.
Ihre Kollegen wollen sie offenbar noch immer nicht in Rente gehen lassen, und sie selbst verschiebt den Ruhestand jedes Jahr weiter. Ich bin wirklich stolz auf ihr herausragendes Wissen in numerischer Analysis und Mathematik.
Ihre erste Stelle als Programmiererin war bei einem Transportunternehmen, und dort arbeiteten viele Programmierer, die seit 15 bis 20 Jahren oder länger im Beruf waren; viele von ihnen warteten vor allem das COBOL, auf dem das Geschäft lief.
Unter diesen Senior-Programmierern waren viele Frauen, und in der Senior-Gruppe fühlte es sich nach mehr als 50 % an. Traurig war, dass es unter den jüngeren Programmierern zwar immer noch etliche Frauen gab, die Mehrheit aber meist männlich war.
Das Unternehmen rekrutierte hauptsächlich an regionalen technischen Hochschulen, daher wirkte es wie ein interessantes Beispiel dafür, wie die Zahl der Frauen, die ein Softwaretechnik-Studium aufnahmen, im Lauf der Zeit zurückging.