Stellen Sie sich Folgendes vor: Es ist 2 Uhr morgens, Sie stecken knietief in einem COBOL-Incident. Der Payroll-Batch ist abgestürzt, weil sich ein Copybook geändert hat, und jetzt haben Sie die klassische Kombination: fehlerhafter Lauf, verärgerte Stakeholder und ein Release-Train, der sich plötzlich wie eine Draisine oder ein Bollerwagen anfühlt.
Ich habe diese Nächte mehrfach erlebt. Die gute Nachricht: Die Problemursachen lösen Sie nicht, indem Sie „härter arbeiten“ oder ein paar Skripte an den Mainframe anflanschen. Sie lösen es, indem Änderungen nachvollziehbar werden, Builds reproduzierbar sind, Tests automatisiert ablaufen und Deployments zunehmend langweilig werden.
Diese Thematik kennen alle Mainframer, die gerne DevOps Praktiken einführen möchten – dort, wo COBOL-Systeme, Batch-Verarbeitung und Release-Druck aufeinandertreffen, ohne dass moderne Delivery-Praktiken etabliert sind.
Im Folgenden wird ein Projekttag Schritt für Schritt dargestellt – wie aus diesem Chaos eine stabile Pipeline entsteht, mithilfe einer praxisnahen IBM Z DevOps-Toolchain (IDz + VS Code, Git, DBB, Zowe, Jenkins, CobolCheck und Wazi Deploy).
Spoiler: Hierfür sind keine Heldentaten erforderlich.
Schritt 1: Den Fehler finden – IDz zur Rettung
Der Tag beginnt mit einem fehlgeschlagenen Batch-Lauf und einem Hinweis: „Irgendetwas hat sich geändert“ (ohne DevOps Praktiken normalerweise ein Satz der ausdrückt, dass es gleich teuer/arbeitsintensiv/riskant wird).
Ich öffne IBM Developer for z/OS for Eclipse (IDz) und springe in das betroffene COBOL-Modul. Mit Syntax-Highlighting, Content Assist, Copybook-Erkennung und der Möglichkeit, direkt gegen z/OS zu debuggen – ohne dauerhaft im Terminal leben zu müssen. So kann ich tatsächlich sehen, was das Programm macht, statt raten zu müssen.
Ich finde das Problem: Das Programm ruft nach einer kürzlichen Änderung die falsche CICS-Transaktion auf, und der Kontrollfluss nimmt einen Pfad, der im letzten Release nicht ausreichend getestet wurde.
Ja, Eclipse kann sich zuerst schwergewichtig anfühlen – als würde es die gesamte Historie der Plattform mit sich tragen. Aber genau hier zahlt sich eine leistungsstarke IDE aus: produktionskritische Fehler werden schnell erkannt und im Kontext analysierbar.
Idee für den Fix entworfen; Nächster Schritt: Die kleinstmögliche sichere Änderung umsetzen.
Schritt 2: Patch erstellen mit VS Code und guter Developer Experience
Für viele Änderungstätigkeiten (JCL, PROCs, kleinere COBOL-Anpassungen usw.) gibt es auch eine sehr gute Werkzeugalternative: Wechsel zu VS Code mit Mainframe-Erweiterungen. Hier wird die Developer Experience für das gesamte Team moderner – insbesondere für diejenigen, die eine schlanke IDE bevorzugen.
Mit der Zowe Explorer Extension kann mit z/OS-Artefakten (Datasets, PDS-Membern, USS-Dateien) gearbeitet werden – in einer Weise, die sich wie zeitgemäße Softwareentwicklung anfühlt und nicht wie klassische „Mainframe-Zeremonien“. Man ist schnell, es ist intuitiv und es gibt keinen „3270-Schock“ für neue Engineers im Team.
Ist es eine vollumfängliche Refactoring-Umgebung? Nicht wirklich. Aber für schnelle, robuste Änderungen (insbesondere bei Änderungen in JCL und Konfigurationen) ist es eine super Werkzeug.
Änderung umgesetzt. Jetzt kommen sie in die Versionskontrolle.
Schritt 3: Branch und Build – Git + DBB im Zusammenspiel
Jetzt kommt der entscheidende Punkt: Ab nun wird Arbeit am Mainframe wird nicht mehr länger wie ein manueller Sonderfall behandelt, sondern wir arbeiten wie Software Engineers auf allen anderen üblichen Softwareplattformen.
Ich erstelle einen Git-Branch für den Fix und öffne einen Pull Request. Das bedeutet:
- Die Änderung ist sichtbar.
- Das Review ist explizit.
- „Wer hat was warum geändert?“ ist dokumentiert – ohne auf implizites Teamwissen angewiesen zu sein.
Ab hier tritt der eigentliche Held in diesem Arbeitsschritt auf: IBM Dependency Based Build (DBB).
Wichtig ist: Auf dem Mainframe ist der Wunsch „eine kleine Änderung“ zu machen häufig eine Illusion. Ein angepasstes Copybook kann Dutzende von Compile-Zeilen betreffen. DBB regelt Builds abhängigkeitsbasiert, sodass nur das nur Dinge neu kompiliert werden, die von Änderungen betroffen sind. Ohne jedes Mal die gesamte Anwendung neu bauen zu müssen.
Die erstmalige Baseline-Erstellung kann etwas dauern (der Preis für das Erstellen des Dependency Graphs). Danach zeigen inkrementelle Builds ihren Mehrwert: kürzere Durchlaufzeiten, sauberere Audit-Trails und weniger Überraschungen à la „Warum wurde dieses Modul geändert?“
Branch bereit. PR offen. Zeit für Automatisierung.
Schritt 4: Pipeline-Zeit – Jenkins orchestriert, Zowe verbindet
AfNach dem Merge des Pull Requests wird in Jenkins eine Pipeline ausgelöst.
Ab hier handelt diese Geschichte nicht mehr vom “einzelnen Entwickler, der ein Problem behebt”, sondern dreht sich um Praktiken, die verhindern, dass der gleiche Schmerz im nächsten Monat wieder erlebt werden muss.
Die Pipeline führt wiederholbare Schritte aus:
- Kompilieren / Bauen
- Statische Prüfungen und grundlegende Quality Gates
- Ausführen kontrollierter Testjobs auf dem Zielsystem
- Paketieren der Anwendung
Zowe ist der Klebstoff zwischen Jenkins und dem Mainframe, der das Ganze modern wirken lässt. Statt individueller Einmal-Skripte und fragiler Remote-Command-Ketten können Jobs strukturiert eingereicht, überwacht und ausgewertet werden – genau das, was für CI/CD Abläufe erforderlich ist.
Der entscheidende Punkt: Wir sind nicht mehr auf magische Hände einzelner Teamkollegen angewiesen, sondern setzen auf ein zuverlässiges und reproduzierbares Pipeline System mit rückwirkend nachvollziehbaren Durchläufen.
Anmerkungen am Rande:
Mit anderen Orchestratoren (TeamCity, GitLab CI) wird Zowe für eine moderne CI/CD-Pipeline nicht zwingend benötigt. Jenkins Groovy-Pipelines können u.a. auch schnell unübersichtlich werden, wenn sie als Sammelbecken für zuviele Dinge missbraucht werden. Tip: Pipelines modular halten. Stages lesbar gestalten.
Pipeline läuft. Jetzt wird professionell getestet.
Schritt 5: Testen wie Profis – CobolCheck macht Regression real
In vielen Mainframe-Teams hört man oft: “Unit Testing in COBOL funktioniert nicht so gut wie in modernen Programmiersprachen”.
Doch! Das geht, wenn es pragmatisch angegangen und in die Pipeline integriert wird.
CobolCheck ermöglicht Unit-Tests nativ in COBOL. Das reduziert Reibung, da keine zusätzliche Sprache oder Runtime eingeführt werden muss. Tests validieren Geschäftslogik (Gehaltsberechnungen, Randfälle, Rundungsregeln, Grenzwerte) und laufen automatisch.
Schwer isolierbare Komponenten (z. B. externe Aufrufe) werden mit geeigneten Isolationsmustern testbar gemacht. Ziel ist nicht, das gesamte Universum in Testfällen zu simulieren, sondern denselben Fehler nicht zweimal auszuliefern.
Hier werden Fehler erkannt, die in manuellen Testabläufen leicht übersehen werden: z.B. ein Off-by-One-Fehler, der nur bei einer bestimmten Datensatzanzahl auftritt. Ohne Unit Testing endet das schnell mal in einem Wochenend-Incident. Stattdessen sehen wir jetzt einen fehlgeschlagen Test in der Pipeline und können diesen schnell beheben.
Tests erfolgreich. PR grün. Nächster Schritt: Deployment – ohne Nervenkitzel.
Schritt 6: Entspannte Deployments – Wazi Deploy macht Promotion erfrischend langweilig
DDeployment ist traditionell der Moment, in dem Mainframe-Teams die volle Komplexität zu spüren bekommen: manuelle Schritte, Abweichungen/Drifts zwischen Umgebungen und das berüchtigte „Auf der Testumgebung lief es doch noch?“.
Mit Wazi Deploy wird das Deployment als kontrollierter, von der Pipeline gesteuerter Prozess automatisiert. Kein Spektakulum, kein Nervenkitzel. Fokus auf Zuverlässigkeit und Reproduzierbarkeit. Konkret bedeutet das:
- Die CI Abläufe erzeugen saubere Build-Artefakte.
- Diese Artefakte werden konsistent durch die jeweiligen Umgebungen promotet.
- Konfigurations-Overlays und umgebungsspezifische Regeln werden reproduzierbar angewendet.
- Promotion wird zu einem nachvollziehbaren und einfachen Ablauf
Wichtig ist dabei die Einordnung: Wazi Deploy ist kein „großer roter Button“ in einer Benutzeroberfläche. Es handelt sich um Automatisierung, die in den Delivery-Prozess integriert ist – konsistent, auditierbar und mit vorhersagbaren Ergebnissen.
Dadurch verlieren wöchentliche Releases ihren Schrecken. Hotfixes verlaufen strukturiert statt hektisch und werden weniger “Hot” als in der Vergangenheit. Und die Ausrede „Der Mainframe ist der Blocker im System“ ist Schnee von gestern.
Das Happy End dieser Geschichte: Der Mainframe tanzt im modernen DevOps Takt
So funktioniert DevOps für den Mainframe, wenn es richtig umgesetzt wird: Das Pipelinesystem schultert die Last und reduziert Nervenkitzel. Noch vor dem Mittag ist die Payroll wieder stabil und es braucht keinen Feuerwehreinsatz für den Rollout. Wir sind nun in der Lage jederzeit kritische Änderungen durch das Delivery System zu jagen.
- Entwickler arbeiten mit Werkzeugen, die sie tatsächlich gerne nutzen (IDz, VS Code).
- Git macht Änderungen sichtbar, reviewbar und nachvollziehbar.
- DBB sorgt für intelligente Builds statt brachialer Komplett-Neuübersetzungen.
- Jenkins automatisiert den Prozess durchgängig.
- Zowe macht die Automatisierung gegen z/OS praktikabel.
- CobolCheck schafft Regressionssicherheit.
- Wazi Deploy macht Promotion reproduzierbar und – im besten Sinne – langweilig (das höchste Lob im Betrieb).
So stellt sich heute die DevOps-Welt für den Mainframe dar: mit weniger Nachtschichten – nicht durch zusätzliche Vorsichtsmaßnahmen im Arbeitsprozess, sondern durch automatisierte, reproduzierbare Abläufe sowie den gezielten Einsatz geeigneter Werkzeuge und klarer Standards.
Falls Sie Fragen haben, sind wir nur einen Klick entfernt.
