Von IBM i zu IBM z/OS in 3.. 2..
Mittlerweile ist es über einen Monat her, dass ich den Arbeitgeber gewechselt habe um mit Native COBOL unter z/OS entwickeln zu dürfen. Hier mal meine Erkenntnisse mit Blick auf den Umstieg:
Ein paar Konzepte werden grundsätzlich anders gedacht unter z/OS, das stimmt. Aber das ist alles kein Hexenwerk und lässt sich gut herleiten. Ich bin aber auch in einem Umfeld gelandet, dass hervorragend dokumentiert (weil reglementiert) ist. Das macht es einfach auch in die Sourcen von 1978 einzusteigen. Und die hatte ich wirklich vor mir :-) Aber sowas mag ich ja. Und dank der Rückwärtsgewandheit der IBM wird der Code ja nicht schlecht. Heute würde man es sich hier und da zwar einfacher machen, aber auch das hast du ja immer und in jedem Umfeld. Vor allem nach dem Zeitraum.
Die Art zu entwickeln ist stark standardisiert. In der Theorie gibt es hier keinen Spielraum für wilde Ausreißer. Natürlich gibt es trotzdem "Alt"bestand, für den seinerzeit andere Regeln galten. Das ist aber handlebar. Weil dokumentiert.
z/OS macht großen Spaß und man kommt super schnell rein und sucht sich seine Abkürzungen. Das ist cool. Aber meine Hauptumgebung ist der IDz (Eclipse). Zum Glück habe ich schon jahrelange Erfahrungen mit dem "Rational Developer for i" gesammelt. Das ist auch eine Eclipse-Variante, aber eben für die iSeries / AS400 / IBM i gedacht. Micht stört das Gleiche, das mich immer stört bei Eclipse: Die Schriftart in verschiedenen Panelen ist viel zu klein. VS Code könnte ich benutzen - allerdings müsste ich die Compiles für die Testumgebungen (Plural!) und den Produktivcompile unter IDz machen. Entsprechend behalte ich das derzeit nur im Blick. In der Anlernphase halte ich mich aber sowieso an meinen Paten. Und der arbeitet seit fast einem halben Jahrhundert in dem Unternehmen. IDz schon Teufelszeug ;-) Man kann mit dem IDz aber wirklich alles steuern und machen, das man auch im z/OS machen muss um ein Programm zum laufen zu bringen. Oder um es zu debuggen.
Fluch und Segen ist besagte Doku. Es gibt die Programmdoku und die technische Beschreibung für die externen Prüfer:innen. Beides will und muss aktuell sein und ständig gepflegt werden. Aber das gehört nunmal zum Handwerk dazu.
Die Büros sind total modern, die Leute sind mehrheitlich offen und intelligent, die Arbeit ist qualitativ hochwertig und es fließen oft mehrere Perspektiven ein. Die Arbeitsweise selbst ist stark agil geprägt. Für mich neu in der Praxis, aber machbar.
Nach Anpassungen oder der Erstellung neuer Programme teste ich aus technischer Perspektive. Hinzu kommt immer ein fachlicher Test. Für Commits gilt das Vier-Augen-Prinzip.
Die Kantine bietet jeden Tag ein veganes Gericht an. Ein eigenes Fitnessstudio, moderne Büroräume, Freizeitbetreuung für Kinder und ein Eltern-Kind-Büro für die Tage, an denen nichts zusammen läuft mit der KiTa, runden die komplette Arbeitnehmer:innen-Experience ab.
Ich mache es kurz: Der Wechsel war eine meiner besseren Entscheidungen, die ich je getroffen habe. Und man darf auch mal Glück haben.
💬 Keine Kommentare
Fertig
Dieser Blog ist einmal mit allem durch. Kein Story-Telling, kein Schisslaweng. Ich komme langsam in meinem neuen beruflichen Umfeld an und plane für Systemkritisch.org eine eigene Journal-Lösung auf der Basis einer Postgres-Datenbank.
Alles Gute für 2026!
💬 2 Kommentare
Vierhundert
Der Abschied von der AS/400 (IBM i) rückt immer näher. In 5,5 Arbeitstagen ist mein Ausflug als Systementwickler bzw. Systemberater vorbei. Zwar freue ich mich auf alles, was kommt, und das sogar sehr. Jedoch blicke ich auch mit einem weinenden Auge auf meine Anfänge zurück. Ich habe so viel gelernt. Über die Software Entwicklung, über Software Entwickler, über IBM, über das Gewinnen und Scheitern. Vieles musste ich mir erkämpfen - oft über die volle Distanz und mehr. Zum Schluß habe ich eigenständig komplexe Projekte mit und für Kunden umgesetzt. Mit und ohne interne Hilfe. Vieles haben wir und habe ich erreicht. Vieles lag leider außerhalb unserer und meiner Möglichkeiten. Ich behalte meinen aktuellen Arbeitgeber im Blick und hoffe, von ganzem Herzen, dass er die Kurve kriegt und zeitnah die richtigen und notwendigen Schritte unternimmt. Sonst sehe ich schwarz. Die hohe Mitarbeiterfluktuation in Relation zur Anzahl der Systementwickler:innen ist jetzt schon herausfordernd und wird noch problematischer durch anstehende Fluktuationen in naher Zukunft. Trotzdem: Ich bin Fan von der Art der Entwicklung.
Nach meinem Abschied habe ich 2,5 Wochen um abzuschalten und die Weihnachtsfeiertage mit der Familie zu genießen. Danach geht es für mich auf IBM Z Mainframes weiter. Hierfür will ich unbedingt noch ein bisschen in Spur kommen. Der Open Mainframe Kurs hilft mir dabei - am Ende ist es nur fürs Gewissen, irgendwas getan zu haben. Aber je sicherer ich mich bewegen kann im z/OS, desto wohler fühle ich mich gerade.
Frohe Feiertage allerseits!
💬 Keine Kommentare
z/OS für Anfänger
Während ich innerlich Abschied von IBM i nehme, nimmt mein Onboarding auf Z Mainframes richtig Fahrt auf. z/OS it is, so oder so. Aber bevor ich mich jetzt in Absurde Udemy-Kurse stürze oder Tage damit verbringe irgendwem auf YouTube zuzusehen, wie er das achte "Hallo Welt"-Programm in COBOL schreibt samt zugehörigem JCL, wollte ich mich nach etwas nachhaltigerem umsehen. Etwas, mit mehr Tiefgang.
Open Mainframe Project
Hier findet man einen richtig guten (Enterprise) COBOL Kurs. Der Anbieter für die technische Seite ist IBM selbst über die Plattform IBM Z Xplore. Das Titelbild ist das, was ich auf der Plattform sehe. Und es ist genau das, was ich jetzt brauche. Üblicherweise ist IBM dafür bekannt richtig teuer zu sein. Aber mir geht es dieses Mal auch nicht um Badges, sondern um echtes Wissen. Wissen, das mir dabei hilft, in ein neues, berufliches, Leben zu starten.
IBM Mainframe Developer
Auf Coursera habe ich ja schon vor einer ganzen Weile den IBM Mainframe Developer abgeschlossen. Leider ist davon nicht so viel hängen geblieben, da mein beruflicher Alltag auf dem Midrangeprodukt von IBM stattfand. Noch dazu mit COBOL-Frameworks, deren Skriptsprache entfernt an ABAP erinnert. Aber an ein paar Mechanismen erinnere ich mich noch. Die Mitschrift war eher daran orientiert das nächste Quiz zu bestehen, denn nachhaltig Wissen aufzubauen. Schade :-)
Man findet mich dann im z/OS Grind.
Nachtrag zum Open Mainframe Projet
Jeder, der Lust hat und sich 3270 annäheren will ist dort wirklich gut aufgehoben. Mittlerweile habe ich meinen ersten Job via VS Code (Zowe) submitted und habe eine Terminalverbindung zum Mainframe aufbauen können. Man wird wirklich Schritt für Schritt durch den Prozess geführt. Hinzu kommt ein bisschen Gamification um auch jüngere Generationen am Ball zu halten. Ich mags. Alles daran. Freue mich auf den nächsten Lernslot.
💬 Keine Kommentare
Berufliche Perspektiven nach zwei Jahren als Junior Entwickler
Im September 2023 bin ich in die IT-Branche eingestiegen. Ohne großes Vorwissen, aber mit einer klaren Vorstellung: Ich wollte programmieren. Richtig programmieren, nicht nur Frameworks zusammenstecken. Dass ich dann ausgerechnet in einer Welt gelandet bin, in der COBOL, RPG, CL und IBM i den Ton angeben, hätte ich vorher nicht gedacht. Heute bin ich froh darüber.
Mein aktueller Arbeitgeber entwickelt ein Warenwirtschaftssystem und ein Lagerverwaltungssystem auf IBM i – mit einem hauseigenen COBOL-Framework, das in vielen Bereichen fast schon an ABAP erinnert. Dazu Java, ein bisschen RPG, viel SQL (Db2 for i) und eine Architektur, die in Teilen älter ist als ich. Mich reizt genau das: Systeme, die seit Jahrzehnten laufen und jeden Tag produktiv sind.
Gestartet bin ich damals mit 48.000 € Jahresgehalt. Nach der Probezeit konnte ich auf 54.000 € nachverhandeln. Vor einigen Monaten kam dann ein Angebot, das die Situation komplett verändert hat.
Der deutsche KfZ-Premiumhersteller – technisch spannend, organisatorisch ein Abturner
Über einen Recruiter auf Xing bin ich auf eine Stelle in der Automobilindustrie gestoßen. Dort läuft alles auf einem IBM Mainframe unter z/VSE, mit COBOL und CICS. Technisch wäre das ein Traum gewesen: echte Transaktionssysteme, alte Schultern, moderne Herausforderungen.
Gehalt: 65.000 € wären drin gewesen.
Der Teamleiter: Voller Energie, absolut mit Feuer dabei – ähnlich wie bei meinem aktuellen Arbeitgeber.
Und trotzdem ein Nein. Fünf Tage Präsenzpflicht, keine Flexibilität, mehrere Red Flags im Gespräch. 2025 noch so zu arbeiten, muss man wollen. Ich will es nicht.
Die Versicherung – schwerer Tanker, aber überraschend modern
Kurz darauf kam über LinkedIn der Kontakt zu einer großen Versicherung. Ein echter Konzern, der gerade Schritt für Schritt von IMS auf Db2 und von COBOL auf Java migriert. Nicht kopflos, sondern mit Augenmaß – alte Themen werden modernisiert, wenn es Sinn ergibt. Als Entwickler wäre man dort im aufrgenden Spannungsfeld zwischen Legacy (bzw. Legendary) und Zukunft unterwegs.
Gehaltlich reden wir, für mich, über eine Range von 75.000 bis 80.000 € im Jahr.
Zwei von drei Tagen im Büro wären gewünscht.
Die Standorte liegen in Städten, in denen man wirklich leben kann.
Ein Umzug wäre mittelfristig gewollt. Das wäre für mich (und uns) irgendwas zwischen herausfordernd und aufregend. Eine echte Chance und ein Neuanfang.
Der IT-Dienstleister in der Finanzindustrie – familienfreundlich, modern und technisch stabil
Über Xing kam dann noch ein dritter Recruiter. Diesmal ging es um ein Unternehmen, das Dienstleistungen für Banken anbietet, ebenfalls auf IBM Mainframe, ebenfalls COBOL.
Dieses Unternehmen setzt stark auf Familienfreundlichkeit und Flexibilität.
Die Konditionen liegen grob in der gleichen Liga wie bei der Versicherung.
Zwei Tage Büro, der Rest frei einteilbar.
Arbeitszeit innerhalb eines großzügigen Rahmens frei gestaltbar.
Selbst ein Eltern-Kind-Büro gibt es – für die Tage, an denen nichts so läuft wie geplant.
Technisch wäre das klassische Mainframe-Entwicklung. Stabil, wichtig, tief. Und die Kultur klingt (für einen Konzern) ungewohnt menschlich.
Was die letzten zwei Jahre mit mir gemacht haben
Was mich überrascht: Ich bekomme von all den Horrornachrichten über Massenentlassungen, Outsourcing nach Polen und Indien und dem „Ende von echten Juniorstellen“ rein gar nichts ab.
Im Gegenteil: Große Konzerne und bekannte Unternehmen wollen jemanden wie mich – jemanden, der COBOL liest und schreibt, IBM-Systeme fühlt und Java nicht verlernt.
Das war am Anfang nicht absehbar. Der Einstieg in COBOL war.. ungeplant. Aber er hat sich ausgezahlt. Ohne IBM i, ohne Legacy, ohne Datenbanknähe wäre ich heute vermutlich einer von vielen Java- oder JavaScript-Entwicklern, die um die gleichen Stellen konkurrieren. Stattdessen habe ich die Wahl.
Der aktuelle Arbeitgeber – und das Problem
So sehr ich meinen Einstieg dort schätze: Mein Job verändert sich. Aus Entwicklung wird mehr und mehr Support. Statt Produktlogik zu entwickeln, lande ich in Tickets, Beratung, Analyse, Projektbegleitung.
Ich wurde nicht vollständig ins Produkt onboarded, soll aber gleichzeitig Kunden beraten, komplexe Fälle einschätzen und täglich Kundenanfragen aus dem Echtbetrieb lösen, die ich fachlich erst noch verstehen muss. Das erzeugt Druck – an guten Tagen spürbar, an schlechten Tagen erdrückend.
Ich will entwickeln. Nicht Prozesse flicken. Ich will in COBOL besser werden, Java vertiefen, SQL weiter nutzen. Kein reiner Supporter werden, der "Altbestände" elendsverwaltet.
Und deshalb wird sich etwas ändern müssen.
Wie es weitergeht
Stand heute läuft es auf zwei Optionen hinaus: die Versicherung oder der Bank-Dienstleister. Beide bieten Entwicklung. Beide bieten Perspektiven. Beide bieten ein Umfeld, in dem man langfristig wachsen kann.
Welche Entscheidung die richtige ist, wird sich nicht an der Technik festmachen, sondern daran, was zu meinem Leben passt.
Eines weiß ich aber sicher: Der Schritt in die IBM-Welt war die richtige Entscheidung. COBOL zu lernen, Java nicht zu verlieren, SQL zu schätzen – das hat mir Möglichkeiten eröffnet, die ich vor zwei Jahren nicht einmal erahnt hätte.
Und egal, wie es ausgeht: Der Weg fühlt sich richtig an.
💬 Keine Kommentare