Bob trifft den Mainframe

Als wir Bob gestartet haben, sagten wir, das interessante Problem sei nicht das Schreiben von neuem Code, sondern das Arbeiten in einem System, das bereits existiert — die richtige Stelle für eine Änderung zu finden, Konventionen zu respektieren, auf die sich ein Team vor Jahren geeinigt hat, und das Verhalten über Dateien hinweg konsistent zu halten, die seit langer Zeit wachsen.

Die am längsten laufende Version eines „Systems, das bereits existiert", läuft auf einem Mainframe. Jahrzehnte von COBOL und PL/I, Millionen von Zeilen, Zehntausende von Programmen, die über Db2, CICS, IMS und Batch-Scheduler miteinander verbunden sind — Code, der das Geschäft ohne Unterbrechungen weiterführt, die man sich nicht leisten kann.

Heute machen wir IBM Bob Premium Package for Z (Bob PP4Z) allgemein verfügbar. Es löst IBM watsonx Code Assistant for Z ab und bringt IBM Z-Expertise — Plattformsprachen, Middleware-Bewusstsein und deterministische unternehmensweite Analyse — direkt in die Bob-Erfahrung.

Dies ist die Engineering-Geschichte, keine Feature-Tour. Statt alles aufzulisten, was PP4Z tut, wollen wir drei Dinge tun:

Erklären, warum ein Universalmodell deine Mainframe-Anwendungen häufiger falsch versteht, als es zugibt.
Zeigen, wie wir Bob in deterministischen Fakten über dein System statt in Wahrscheinlichkeiten verankern.
Die Z-spezifischen Modi, Skills und Workflows durchgehen — und was du damit aufbauen kannst.

1. Warum der Mainframe der schwierige Fall ist

Ein Universalmodell, das auf einen Mainframe-Bestand gerichtet wird, stößt auf drei Probleme, die kein noch so cleveres Prompting wirklich löst. Das Design von PP4Z bietet Lösungen für jedes dieser Probleme.

1.1. Skalierung und was sie mit einem Kontextfenster macht

Eine einzelne Geschäftsanwendung kann Millionen von COBOL-Zeilen umfassen, Zehntausende miteinander verbundene Module über COBOL, PL/I und Assembler, und Tausende von Batch-Jobs, die durch einen Enterprise-Scheduler verkettet sind. Selbst ein „kleiner" Ausschnitt von 200 Programmen umfasst komfortabel Hunderttausende von Codezeilen.

Das passt nicht in ein Kontextfenster, und das Problem ist nicht nur das Fenster. Mit wachsendem Kontext verschlechtert sich die Modellleistung (Chroma Research Context Rot Study, 2025) — Antworten werden unvollständig, inkonsistent oder selbstsicher falsch, genauso wie ein Mensch in Informationsüberlastung ertrinkt. Das Einbeziehen „der relevanten Dateien" setzt voraus, dass du bereits weißt, welche Dateien relevant sind — genau das, was du herauszufinden versuchst.

1.2. Bedeutung, die nicht im Code steckt

Mainframe-Code ist semantisch dicht. Die Geschäftsbedeutung lebt in Feldnamen und jahrzehntelangen Konventionen, nicht in etwas, das ein Parser lesen kann. Einiges lässt sich erraten — SERIALN ist wahrscheinlich eine Seriennummer, TOT-STTM wahrscheinlich eine Gesamtabrechnung. Das meiste nicht: Was ist C-M? M-CAP? Warum das CCZD-Präfix? Was unterscheidet NO-SIN, NO-EVN und NO-CNT?

Die Bedeutung ist real und tragend, aber sie ist nicht aus dem Code allein zu erschließen. Die traditionelle Antwort ist ein Datenwörterbuch — aber der Umfang (Millionen, wenn nicht Milliarden von Variablen) macht es schwierig, eines von Hand oder mit roher KI-Kraft aufzubauen.

1.3. Die wahrscheinlichste Antwort ist nicht die richtige Antwort

Ein Sprachmodell gibt zurück, was statistisch wahrscheinlich ist. Modelle sind nicht-deterministisch; dieselbe Frage kann an verschiedenen Tagen unterschiedliche Antworten liefern. In einem System, in dem eine falsche Antwort über Kontrollfluss die Geschäftslogik falsch darstellen kann, ist das ein erhebliches Risiko.

Dies ist ein Szenario, dem du wahrscheinlich selbst begegnet bist, vorausgesetzt, du hast es erkannt. Nimm eine echte COBOL-Batch-Anwendung: 233 Programme, 742 Copybooks, mehr als 20 MB Code, mit einem häufig aufgerufenen Datums-Utility, N991DATE. Aus den Metadaten ergibt sich, dass 30 Programme es aufrufen. Nun frag ein Frontier-Modell direkt:

Tag 1. Es kann nicht alles laden, also grepped es nach statischen CALL-Anweisungen und meldet 13. Bei dynamischen Aufrufen erweitert es den Regex und meldet 29. Das fehlende, CHKOUTB, liegt in einer Datei namens ROCHKOUT.cbl — weil ein Dateiname per Konvention zwar meist zur PROGRAM-ID passt, aber nie muss.
Tag 2. Gleiche Frage, andere Heuristiken, und jetzt meldet es 31 — Überzählung. Ein falsch positives Ergebnis, N285RODR, deklariert lediglich das Literal 'N991DATE' im Working Storage und verwendet es nie. Das Modell schlussfolgert das erst nach mehreren Nachfragen.

Keine dieser Heuristiken ist unvernünftig. Sie sind einfach nicht gut genug, und „wer ruft X auf" ist eine der zentralen Fragen bei der Impact-Analyse und dem Programmverständnis. Komplexere Fragen — welche Tabellen werden in mehr als einem Programm aktualisiert, welche Dateien werden gelesen, aber nie geschrieben, welche Variablen fließen in die Berechnung von WS-UIT02 in PREMPZ72 ein — benötigen vollständige, präzise Analyse, die Pattern-Matching nicht liefern kann.

Die Schlussfolgerung ist nicht „Modelle sind für das Mainframe-Programmverständnis nicht nützlich." Es ist, dass die Qualität der Modellantworten erheblich verbessert wird, wenn es etwas Wahres gibt, über das es nachdenken kann. Sprachmodelle sind hervorragend darin, Daten zu verarbeiten.

2. Bob in Fakten statt Wahrscheinlichkeiten verankern

PP4Z's Antwort ist, das Modell nicht mehr zu bitten, das System aus dem Quellcode zu rekonstruieren, sondern ihm stattdessen eine deterministische, abfragbare Darstellung des Bestands zum Nachdenken zu geben. Drei Mechanismen verankern es: Das Modell wird aufgefordert, mehrdeutige z/OS-Konstrukte in der Anfrage selbst zu kennzeichnen; Prompts werden mit autoritativen IBM Z-Einblicken, IBM-Dokumentation, Referenzmaterial, verifizierten Beispielen und mehr angereichert, wobei allgemeine Programmiervorurteile aktiv unterdrückt werden; und das Modell wird angewiesen, Antworten zuerst aus Analysemetadaten zu geben. Das Ziel ist, Antworten zum IBM Z-System, nicht zu einer Trainingsverteilung, rückverfolgbar zu machen.

2.1. Z Understand: ein abfragbares Modell deines Bestands

Z Understand ist die statische Analyseplattform unter PP4Z. Es läuft auf einem Server mit Zugriff auf deinen vollständigen Quellcode, liefert Scanner für COBOL, PL/I und Assembler sowie JCL und Scheduler wie Control-M und TWS, und verarbeitet Tausende von Programmen parallel in ein abfragbares Repository. Es hält deterministische, konsistente Struktur über Bestände von 10.000+ Programmen.

Es hilft, es als eine Compiler-Pipeline mit einem anderen Output zu betrachten: kein ausführbares Programm, sondern strukturiertes, abfragbares Wissen — Datendefinitionen, Kontrollfluss über Programme und Jobs hinweg, präziser Datenfluss (einschließlich REDEFINES und Speicher-Offsets) und Subsystem-Interaktionen.

2.2. Das Modell seine eigenen Abfragen schreiben lassen

Wie die Metadaten bereitgestellt werden, ist genauso wichtig wie die Metadaten selbst. Feste APIs und vordefinierte MCP-Abfragemuster sind für bekannte und erwartete Fragen sehr effizient, versagen aber bei offener Analyse. Bei offener Analyse verzweigt sich eine reale Frage in viele Unterabfragen, die sich mit dem Fortschritt des Denkens ändern.

Wir haben Bob daher beigebracht, über die bereitgestellten vorgefertigten Abfragen hinaus zu gehen und eigene Abfragen gegen die Metadaten zu generieren und auszuführen. Das nutzt, was Modelle wirklich gut können — Reasoning und Abfragegenerierung — und skaliert so, wie strukturierte Daten skalieren: ob du 10 oder 10.000 Programme hast, die Abfrage ist dieselbe; nur das Ergebnisset wächst. In der Praxis bedeutet das höhere Genauigkeit, mehr Konsistenz über Läufe hinweg und niedrigeren Token-Verbrauch.

2.3. Erweiterbarkeit, benutzerdefinierte Scanner und Laufzeitdaten

Rein syntaktische Analyse verpasst die Beziehungen, die wichtig sind, wenn dynamische Aufrufe, API-Abstraktionen und Präprozessoren den echten Fluss verbergen. Das Z Understand Extensibility-Framework schließt diese Lücke:

API-Aufruf-/Makro-Auflösung bildet indirekte und parametergesteuerte Aufrufe auf ihre echten Ziele ab und ersetzt generische Aufrufkanten durch konkrete Aufrufer-Aufgerufener-Beziehungen, über JSON-Konfiguration oder User-Exits.
Präprozessor-Erweiterbarkeit interpretiert nicht-standardmäßige Anweisungen unter Beibehaltung der ursprünglichen Quellansicht und bildet sauber zwischen vor- und nachverarbeitetem Code ab.
Benutzerdefinierte Scanner bringen proprietäre Sprachen, 4GLs und sogar Nicht-Code-Quellen über eine schemagesteuertes JSON-Interface in ein Modell — du übernimmst Parsing und Extraktion, Z Understand übernimmt Speicherung, Beziehungen und Analyse.

Statische Analyse sagt dir, was passieren kann; Laufzeitdaten sagen dir, was passiert ist. PP4Z verwandelt den Debugger in ein Datenerhebungsinstrument — Ausführungspfade verfolgen, Variablenwerte erfassen, Branch-Entscheidungen und Subsystem-Aufrufe beobachten — und übergibt diese präzisen Traces an Bob.

2.4. Das Datenwörterbuch: Relevanz vor Vollständigkeit

Milliarden von Variablen zu dokumentieren ist weder machbar noch wartbar, also versucht PP4Z das nicht. Die deterministische Analyse bewertet Variablen danach, wie sehr sie das Verhalten tatsächlich steuern — Nutzungshäufigkeit, Verteilung über Codebereiche, Beteiligung am Kontrollfluss, Interaktion mit Datenbanken und I/O — und wählt die kleine Menge aus, die den Zweck eines Programms offenbart. Für jede davon werden Metadaten, echte Verwendungsausschnitte und Interaktionsmuster zusammengestellt und dann eine geschäftliche Beschreibung generiert.

Der nützliche Befund hier: Begrenzter Abdeckung reicht aus. Die Definition von ungefähr den Top 10-20 Variablen pro Programm verbessert das Verständnis wesentlich ohne erschöpfende Dokumentation. Z Understand Services automatisiert dies über ganze Portfolios hinweg, ein Konfidenz-Score behält nur Definitionen über einem Schwellenwert, und ein Human-in-the-Loop-Schritt in der IDE lässt Entwickler die Ausgabe überprüfen, korrigieren und mit bestehenden Glossaren abgleichen.

3. Bob für Z spezialisieren

Verankerung gibt Bob gute Fakten. Spezialisierung macht es vorhersehbar in einer Umgebung, in der Outputs erklärbar sein müssen und Prozesse Governance erfüllen müssen. PP4Z basiert auf vier Teilen: Modi, Tools, Skills und Workflows.

Modi legen die Rolle und die Grenzen für einen Interaktionsfluss fest. Ein Architekt-Modus priorisiert Analyse, Dokumentation und Abhängigkeitserkennung, wobei Code-Modifikation explizit verboten ist. Ein Entwickler-Modus ist für Generierung und Refactoring mit eingebauter Coding-Standard-Durchsetzung abgestimmt. Governance lebt im Interaktionsmodell selbst.
Tools geben dem Modell direkten Zugriff auf strukturiertes Systemwissen — Programm-Scanning, Metadaten-Abfrage, Datenwörterbuch-Lookup, unternehmensweite Analysedienste.
Skills kodifizieren wiederkehrendes Fachwissen in wiederholbaren, prüfbaren Schritten. Der Implementierungsplanungs-Skill erzwingt zum Beispiel eine feste Sequenz: Kontext erwerben und validieren, Anforderungen formulieren, Impact aus Metadaten abbilden, dann einen persistenten, überprüfbaren Plan erstellen.
Workflows fügen zustandsbehaftete Orchestrierung hinzu — Reihenfolge erzwingen, Zwischenergebnisse validieren, bei fehlerhafter Eingabe anhalten. Der Datenwörterbuch-Workflow stoppt, wenn er keine Variablen findet, statt welche zu erfinden.

Standards und Governance werden standardmäßig durch agents.md-Regeln auf Repository-Ebene durchgesetzt. Da IBM diese Skills und Workflows mitliefert, startest du nicht bei null: Sie kodieren IBMs eigenen Ansatz für COBOL, PL/I, z/OS-Middleware und Modernisierung. Du kannst auch eigene Skills erstellen, ohne Code zu schreiben.

Wenn diese zusammenwirken, kann ein einzelner Prompt eine End-to-End-Aufgabe steuern:

„Füge der Motor Policy Table eine Spalte hinzu, die erfasst, ob das Fahrzeug elektrisch ist. Wende meine Coding-Standards an und aktualisiere alle betroffenen Programme."

Bob liest die Absicht, erstellt einen Plan, wählt die richtigen Modi, Skills und Repository-Regeln, und führt sicher die Tools aus — Governance, Ausführung und Reasoning in einem Durchgang, mit deiner Genehmigung der Änderungen.

4. Was du heute aufbauen kannst

Dokumentation, die nicht veraltet. Behandle Docs als generierbares Artefakt, verankert in deterministischen Metadaten plus Quell- und Laufzeitkontext — bei Bedarf neu generierbar, auf das aktuelle System ausgerichtet.
Deterministischer COBOL-zu-Java-Übergang auf z/OS. PP4Z nutzt Metadaten als Rückgrat der Transformation, baut parallele Modelle von Quelle und Ziel, damit Architektur reproduzierbar ist und Geschäftslogik präzise abgebildet wird.
Gezieltes Refactoring und Funktionsextraktion. Bob erstellt eine priorisierte Liste von Refactoring-Kandidaten, annotiert mit Geschäftsfunktion, und extrahiert dann eigenständige Module mit klaren Inputs und Outputs.
Natives z/OS-Tooling. Z Open Editor-Fähigkeiten plus neue MCP-Tools: Dependency Based Build (DBB), Z Code Scan und IBM Debug for z/OS, um Live-Debug-Sessions in KI-gestützte Root-Cause-Analysen zu verwandeln.

Ein Hinweis zur Ehrlichkeit, da dies ein Engineering-Beitrag ist: Nichts davon entfernt den Entwickler aus dem Loop, und das ist auch nicht beabsichtigt. Die Modi, die Genehmigungsgates und das Human-in-the-Loop-Datenwörterbuch existieren alle, weil auf diesen Systemen „meistens richtig" der Fehlermodus ist, nicht das Ziel.

5. Wie du Zugang erhältst

Bob Premium Package for Z (PP4Z) ist ein Add-on zu IBM Bob, kein separates Produkt. PP4Z läuft gegen einen aktiven Mainframe-Bestand in einer Unternehmensumgebung — die Berechtigung ist vertriebsgesteuert.

Beginne mit deinem IBM-Ansprechpartner, oder nutze „Vertrieb kontaktieren" auf bob.ibm.com. Sie richten den IBM Bob-Basisplan und das Z-Add-on für deine Organisation ein.
Sobald dein Bob-Administrator dir einen Seat mit dem Z-Add-on zuweist, wird die Berechtigung erkannt, wenn du IBM Bob verwendest. Installiere die Bob IDE, melde dich an, und die Z-spezifischen Modi, Skills und Tools erscheinen.

6. Loslegen

Wenn du Bob bereits nutzt, fügt PP4Z die Z-spezifischen Modi, Skills und Tools zu dem hinzu, was du hast.
Nutze die eingebettete Understand-Funktion, um tiefere Einblicke in den Code in deinem Workspace zu erhalten.
Richte Z Understand auf eine echte Anwendung, bei der du die richtigen Antworten bereits kennst — und überprüfe Bobs Analyse mit deiner Ground Truth.
Beginne mit einer Frage, auf die du noch nie eine klare Antwort erhalten hast: Wer ruft dieses Utility wirklich auf? Welche Tabellen berührt dieser Job? Was bedeutet diese Variable?
Stelle herausforderndere Fragen, die Daten und Reasoning kombinieren: „Gib mir einen Call-Graph mit Diagrammen, geordnet nach Themen"

Links