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.