COBOL-Modernisierung mit KI: Code erklären, dokumentieren, On-Premise nach Java übersetzen

COBOL mit lokalem LLM erklären, dokumentieren und übersetzen

Ein lokales LLM, also ein KI-Sprachmodell auf einer GPU-Workstation oder einem Server im eigenen Rechenzentrum, kann COBOL-Programme erklären, ihre Dokumentation und Geschäftsregeln entwerfen und COBOL nach Java übersetzen, ohne dass der Quellcode Ihr Netz verlässt. Veröffentlichte Forschung zeigt, wo das zuverlässig ist: In der COBOL-Coder-Studie übersetzte das offene Modell gpt-oss-120b COBOL-Aufgaben in Java, das in 98,6 Prozent der Fälle kompilierte, schrieb aber in weniger als einem von fünf Fällen kompilierbares COBOL. Eine NVIDIA RTX PRO 6000 Blackwell Workstation Edition oder Max-Q mit 96 GB betreibt dieses Modell in einer Workstation für ein kleines Modernisierungsteam. Server mit vier oder acht RTX PRO 6000 Server Edition kommen für den Team-Chat und für nächtliche Dokumentationsläufe über den gesamten Mainframe-Code hinzu.

Dieser Leitfaden richtet sich an Mainframe- und Kernsystem-Teams in Banken, Versicherungen, Behörden und im Handel. Ihr Quellcode und die Geschäftsregeln darin sind Daten, die sie oft nicht an eine Cloud-API schicken wollen. Der Leitfaden behandelt die Aufgaben nach Risiko, die veröffentlichten COBOL-Benchmarks, IBMs On-Premise-Weg, den Weg mit offenen Modellen und die Hardware für jede Phase. Unser Leitfaden zu GPU-Servern für Banken und Versicherungen behandelt die gesamte Plattform und DORA; unser Leitfaden zu lokaler KI für die SPS-Programmierung zeigt dasselbe Muster für eine andere Legacy-Sprache. Für SAP-Custom-Code auf dem Weg zu S/4HANA folgt unser Leitfaden zu ABAP mit lokalem LLM derselben Schleife aus Compiler- und Unit-Test-Rückmeldung.

Vier Aufgaben, nach Risiko geordnet

1. Ein Programm erklären. Das Modell liest die PROCEDURE DIVISION mit den Datendefinitionen und Copybooks, die sie nutzt, und beschreibt, was das Programm tut, welche Dateien und Tabellen es liest und schreibt und welche Programme es aufruft. Eine falsche Erklärung kann Leser in die Irre führen, ändert aber keinen Code; deshalb kommt diese Aufgabe zuerst.
2. Den Bestand dokumentieren. Derselbe Durchlauf über alle Programme liefert Beschreibungen, ein Datenverzeichnis aus den Copybooks und Zusammen­fassungen der Geschäftsregeln: der Bedingungen in EVALUATE- und IF-Blöcken, die über Zinsen, Gebühren oder Berechtigungen entscheiden. Eine COBOL-Fachkraft prüft jede Zusammenfassung, bevor sie in die Dokumentation eingeht.
3. Charakterisierungstests schreiben. Das Modell entwirft Testfälle und Eingabedaten, die festhalten, was ein Programm heute tut. Gegen das bestehende Programm ausgeführt, werden sie zur Referenz für jede spätere Änderung oder Übersetzung.
4. Nach Java übersetzen. Das Modell entwirft Java-Klassen aus einem Programm und seinen Datenstrukturen. Der Entwurf muss kompilieren, die Charakterisierungstests bestehen und durch Ihr normales Code-Review gehen, genau wie Code eines Entwicklers.

COBOL selbst zu schreiben oder zu ändern liegt am oberen Ende der Risikoskala, und die Forschung unten zeigt, warum.

COBOL-Benchmarks für LLMs in der Forschung

Der ausführlichste öffentliche Vergleich ist das COBOL-Coder-Paper der Concordia University und des FPT Software AI Center, eingereicht bei arXiv am 5. April 2026. Die Autoren trainierten Qwen2.5-Coder mit 7B und 14B auf COBOL-Daten nach, die mit dem Compiler GnuCOBOL geprüft wurden, und testeten die Code-Erzeugung auf COBOLEval, 146 aus dem HumanEval-Benchmark übertragenen Aufgaben, sowie die Übersetzung auf COBOL-JavaTrans, 143 eigenen Paaren aus COBOL und Java.

COBOL-Coder-Paper, arXiv 2604.03986v1, Tabellen 3 und 4, gelesen am 30. Oktober 2026. COBOL-Spalten: COBOL schreiben auf COBOLEval (146 Aufgaben); Java-Spalten: COBOL nach Java übersetzen auf COBOL-JavaTrans (143 Aufgaben). Pass@1 ist der Anteil der Aufgaben, deren erste Antwort die Tests besteht. Die Werte sind eigene Messungen der Autoren.

Für die Projektplanung lässt sich die Tabelle so lesen. COBOL lesen und Java schreiben gelingt dem stärksten offenen Modell der Studie mindestens so gut wie GPT-4o. COBOL schreiben fällt allgemeinen Modellen schwer: Sechs der offenen Vergleichsmodelle, darunter CodeLlama 7B und StarCoder2 15B, erzeugten auf COBOLEval kein einziges kompilierbares COBOL-Programm, Mainframer 7B kompilierte zu 69,17 Prozent, bestand die Tests aber nur zu 6,16, und das auf COBOL trainierte Modell kam auf etwa drei kompilierende Programme von vier. Die Größe allein entscheidet wenig. Das 14B-Modell Qwen2.5-Coder scheiterte an der Übersetzung, das 16B-Modell DeepSeekCoder-V2 schnitt gut ab. Die Aufgaben haben die Größe einzelner Funktionen und sind weit kleiner als ein Unternehmensprogramm mit Dutzenden Copybooks. Als Einschränkung nennen die Autoren selbst, dass jede Datei für sich bewertet wird; gemeinsame Copybooks und Aufrufe zwischen Programmen bildet der Test nicht ab. Die Gewichte von COBOL-Coder sind noch nicht veröffentlicht; das Repository unter Apache 2.0 führt die Modelle mit 7B und 14B als „Coming soon“ und enthält die Benchmarks und den Auswertungscode.

Forschende von IBM und dem IIIT Hyderabad stellten auf der ICSE 2026 einen zweiten Ansatz vor: Statische Programmanalyse leitet aus den COBOL-Datendefinitionen und Kontrollflussgraphen Java-Klassen, Hierarchien und Methodensignaturen ab, und das LLM übersetzt die prozedurale Logik innerhalb dieses Entwurfs. Auf 20 GenAPP-Programmen und 10 Kundenanwendungen erreichte die Pipeline einen Median über 80 Prozent bei der strukturellen und über 75 Prozent bei der funktionalen Bewertung, beide von einem LLM-as-Judge-Verfahren vergeben; Kompilier- oder Testquoten nennt die Zusammenfassung nicht. Sie beschreibt die Pipeline als „a core component of IBM's watsonx Code Assistant for Z (WCA for Z) product“.

Der Weg mit offenen Modellen auf eigener Hardware

Der offene Weg verbindet einen Modellserver mit Werkzeugen, die die deterministische Arbeit erledigen. Das Modell ist der kleinere Teil der Pipeline.

• Kontext zusammenstellen. Die Bedeutung eines Programms hängt von seinen Copybooks ab, von der JCL, die es startet, und von den Programmen, die es aufruft. COPY-Anweisungen und Aufrufketten aufzulösen ist reines Parsen; ein Skript stellt deshalb den Kontext für jede Anfrage zusammen, und ein Suchindex über Copybooks und JCL beantwortet Fragen über Programmgrenzen hinweg. Unser Leitfaden zu GPUs für Embedding und Reranker bei RAG behandelt diesen Teil.
• Modell bereitstellen. gpt-oss-120b (117B Parameter, 5,1B aktiv, Apache 2.0) hat 65,3 GB Gewichte und einen Kontext von 131.072 Token. vLLM stellt es mit einer OpenAI-kompatiblen API auf einer Workstation oder einem Server bereit; für ein streng getrenntes Netz beschreibt unser Leitfaden zum Air-Gapped-LLM-Server die Offline-Installation.
• Prüfungen. Jeder Java-Entwurf wird kompiliert und gegen die Charakterisierungstests ausgeführt; jeder COBOL-Entwurf läuft durch Ihren Compiler. GnuCOBOL, der offene Compiler, den die COBOL-Coder-Autoren nutzten, findet Syntaxfehler früh, Ihr Mainframe-Compiler bleibt die Referenz.
• Eine Verbesserungsschleife. OpenHands beschrieb am 18. Dezember 2025 eine Schleife, in der ein Agent COBOL-Dateien nach Java umwandelt und ein zweiter jede Umwandlung bewertet, bis die Bewertung eine Schwelle erreicht. Compilerfehler und fehlgeschlagene Tests sind für eine solche Schleife die nützlichste Rückmeldung.

Sie können die Workstation allein bestellen, die Einrichtung von vLLM und gpt-oss-120b allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

IBM watsonx Code Assistant for Z On-Premise

IBMs eigenes Produkt geht einen anderen Weg. IBMs Dokumentation zu den Transform-Funktionen von watsonx Code Assistant for Z, die COBOL nach Java umwandeln, sagt, dass Sie die Software in IBM Software Hub installieren können, „if you want the entire solution to run on prem“. IBMs Installationsleitfaden für Software Hub 5.2.x nennt GPU-Operatoren für die watsonx-Code-Assistant-Produkte als immer erforderlich: für watsonx Code Assistant for Z und seine Variante Code Explanation sowie ab Version 5.2.1 für die Varianten Code Generation und Agentic. Installiert werden sie über den Node Feature Discovery Operator und den NVIDIA GPU Operator unter Red Hat OpenShift. Diese Seite nennt keine GPU-Modelle; klären Sie deshalb mit IBM, welche Karte unterstützt wird, bevor die Hardware bestellt wird.

Beide Wege lassen sich parallel betreiben. Ein Team, das IBMs Produkt für die Übersetzung lizenziert, kann für Erklärung und Dokumentation aller Programme trotzdem ein offenes Modell auf eigener GPU betreiben.

Hardware für jede Projektphase

Die Dimensionierung folgt unserer Regel für Nutzer je Karte wie in unserem Leitfaden wie viele Nutzer eine RTX PRO 6000 bedient: 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB je Karte und abzüglich der Gewichte. gpt-oss-120b lässt auf einer Karte mit 96 GB 22,2 GiB frei, genug für 9 Sitzungen zu 64K Token mit 16-Bit-Cache oder 4 zu 128K. Die kleinste RTX-PRO-Karte, die das Modell mit brauchbarem Kontext hält, ist deshalb die RTX PRO 6000: Auf einer RTX PRO 5000 mit 72 GB blieben etwa 0,7 GiB. Kleinere Modelle passen auf kleinere Karten, lagen in der Studie bei der Übersetzung aber hinter gpt-oss-120b, das beste davon, DeepSeekCoder-V2 16B, um 14 Punkte, und scheiterten meist am Schreiben von COBOL. Prüfen Sie ein solches Modell an Ihren eigenen Programmen, bevor Sie mit einer kleineren Karte planen. Wir zählen eine arbeitende Sitzung je Person in der Spitzenstunde und begrenzen jede Sitzung zusätzlich auf geplante 50 Token pro Sekunde, nach unserer Schätzung eine Obergrenze.

Sitzungen mit gpt-oss-120b (65,3 GB, 60,8 GiB), 16-Bit-Cache von 2,25 GiB je 64K nach unserer Rechnung aus der config.json, nach unserer Regel für Nutzer je Karte; geplant ist der kleinere Wert aus Speicher und unserer Grenze von 50 Token pro Sekunde, mit etwa 5 GB aktiven Gewichten je Token, 1.792 GB/s je Workstation Edition oder Max-Q und 1.597 GB/s je Server Edition (NVIDIA). Schätzungen, keine Messungen.

Einstieg: eine Workstation. Eine RTX PRO 6000 Workstation Edition (600 W) oder Max-Q (300 W) passt zu einem Team von drei bis neun Personen, die Programme erklären und dokumentieren und Übersetzungen entwerfen. Programme, die mit ihren Copybooks mehr als 64K Token Kontext brauchen, laufen in 128K-Sitzungen, was die Zahl halbiert.

Zwei Karten. Ein Paar teilt das Modell auf zwei Karten auf und lässt mehr als viermal so viel Platz für den Cache wie eine Karte, passend für ein größeres Team oder längere Kontexte. Zwei Workstation-Edition-Karten sind für diese Edition das praktische Maximum; drei oder vier Max-Q gehören nur in ein Gehäuse, das dafür mit starkem, gerichtetem Luftstrom gebaut ist.

Server. Der Inferenzknoten auf unserer Seite zu KI-Servern trägt vier RTX PRO 6000 Server Edition mit 768 GB DDR5-ECC-Speicher und nimmt nach unserer Schätzung etwa 3,4 kW auf. Er bedient das Team tagsüber und erledigt nachts die Dokumentations-Batches. Acht Karten nehmen nach unserer Schätzung etwa 6,3 kW auf, und Dells Datenblatt nennt etwa 8 kW je Knoten mit acht Karten als Richtwert; den Anschluss plant man deshalb nach der Angabe des Serverherstellers. Ein Server mit acht Karten hält auch Qwen3-Coder-480B-A35B in FP8 (482 GB) mit 13 Sitzungen zu 64K, 27 mit FP8-Cache, für ein Team, das ein größeres Coding-Modell auf eigenem Code mit gpt-oss-120b vergleichen will; acht H200 NVL halten es mit 34. Ein COBOL-Ergebnis für dieses Modell ist nicht veröffentlicht; unser Leitfaden zum Server für Coding-Agenten enthält seine Dimensionierung.

Wir bauen diese Workstations und KI-Server auf Bestellung; senden Sie uns die Zahl der Programme, der Beteiligten und die geplanten Aufgaben, und unser Team antwortet mit einer Konfiguration.

Ein Dokumentationslauf über den ganzen Codebestand

Alle Programme zu dokumentieren ist ein Batch-Job: Niemand wartet auf eine einzelne Antwort, entscheidend ist, ob der Lauf in einer Nacht fertig wird. Unser Leitfaden zur Batch-LLM-Inferenz On-Premise beschreibt die Methode: Programme zählen, die Ausgabelänge je Programm festlegen, einen veröffentlichten Durchsatz nehmen oder eine Stichprobe messen, und teilen.

Für gpt-oss-120b auf diesen Karten gibt es einen veröffentlichten Wert. In MLPerf® Inference v6.1 erzeugte ein HPE ProLiant Compute DL380a Gen12 mit acht RTX PRO 6000 Blackwell Server Edition im Offline-Szenario 15.256 Token pro Sekunde auf gpt-oss-120b. Als Beispiel ergeben 10.000 Programme mit je 1.000 Token Dokumentation 10 Millionen Ausgabetoken; bei dieser Rate dauern sie nach unserer Rechnung etwa 11 Minuten, mit der Halbierung, die unser Batch-Leitfaden ansetzt, bis eine Stichprobe gemessen ist, etwa 22 Minuten. Der Benchmark nutzt eigene Eingaben. Ein COBOL-Programm mit seinen Copybooks ist ein deutlich längerer Prompt, das Einlesen der Prompts nimmt also einen größeren Teil der Zeit ein, und die Rate auf Ihrem Code liefert ein Testlauf. Die Tokenzahl Ihrer Programme liefert der Tokenizer des Modells über den Endpunkt /tokenize, den vLLM in seiner Dokumentation führt. Selbst mit großem Aufschlag ist der GPU-Lauf kurz neben der Prüfung von 10.000 Entwürfen durch Ihre COBOL-Fachleute.

Planen Sie einen solchen Dokumentationslauf, fragen Sie uns, welche Konfiguration zur Größe Ihres Codebestands und zu Ihrem Budget passt.

MLPerf® Inference v6.1, Rechenzentrum, Closed Division, gpt-oss-120b, Offline-Szenario, Eintrag 6.1-0050, abgerufen von mlcommons.org am 24. Oktober 2026, Ergebnis verifiziert von der MLCommons Association. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Governance in Banken, Versicherungen und Behörden

Das Modell auf eigener Hardware zu betreiben beantwortet die erste Frage einer Sicherheitsprüfung: Quellcode und Geschäftsregeln bleiben in Ihrem Netz, und kein Dritter verarbeitet sie. Die übrigen Fragen betreffen die Pipeline. Erzeugtes Java durchläuft dasselbe Review, dieselbe statische Analyse und dieselbe Freigabe wie jeder andere Code, und die Charakterisierungstests werden als Nachweis der Gleichwertigkeit mit ihm abgelegt. Prompts und Antworten enthalten Quellcode; legen Sie deshalb vor dem ersten Lauf fest, ob das Gateway sie speichert und wie lange. Unser Leitfaden zum LLM-Gateway mit Schlüsseln und Abfrageprotokoll beschreibt die Möglichkeiten. Für Banken und Versicherungen setzen die Regeln der DORA, Verordnung (EU) 2022/2554, zu IKT-Risiken und IKT-Drittdienstleistern den Rahmen der Plattform, wie unser Leitfaden für diese Branche darlegt; Ihre Rechtsberatung und Ihr Datenschutz­beauftragter bestätigen, wie sie für das Projekt gelten.

FAQ