Jede Mainframe-Migration beginnt damit, dass jemand nach Mainframe-Migrationstools sucht, und jede Herstellerdemo, die darauf folgt, wirkt bemerkenswert überzeugend. Ein paar tausend Zeilen COBOL gehen hinein, lesbares Java kommt heraus, die Testsuite läuft durch, und die Präsentation verspricht siebzig oder achtzig Prozent Automatisierung. Die Demo ist meist ehrlich. Sie läuft nur ebenso meist gegen Code, der sich völlig anders verhält als Ihrer.

Dieser Leitfaden beschreibt die Werkzeugkategorien, die tatsächlich existieren, was jede davon wirklich gut kann und an welchen konkreten Stellen sie bei echten Arbeitslasten scheitert. Er ist für die Menschen geschrieben, die den Business Case unterschreiben müssen, nicht für den internen Fürsprecher des Herstellers.

Die ehrliche Position: Mainframe-Migrationstools leisten sehr viel nützliche Arbeit, besonders bei Analyse, Datenbewegung und mechanischer Übersetzung. Was sie nicht können, ist Ihre Geschäftsregeln verstehen. Automatisierte Konvertierung erzeugt zuverlässig Code, der läuft; sie erzeugt keinen Code, den Ihr Team pflegen möchte, und das Schließen dieser Lücke ist der Punkt, an dem der Großteil des Budgets tatsächlich landet.

Die vier Kategorien von Mainframe-Migrationstools

Der Markt wirkt überfüllt, bis man ihn danach sortiert, was die Produkte tatsächlich tun. Fast alles fällt in eine von vier Gruppen, und ein reales Programm nutzt Werkzeuge aus mindestens dreien davon.

Discovery- und Analysewerkzeuge lesen Ihren Quellcodebestand und sagen Ihnen, was Sie haben. Sie parsen COBOL, JCL, Copybooks und Datenbankdefinitionen und bauen daraus Aufrufgraphen, Data-Lineage-Karten und Abhängigkeitsbäume. Diese Kategorie ist die unglamouröseste und die beständigste, weil niemand in Ihrer Organisation ein vollständiges Bild eines Systems hat, das seit vierzig Jahren wächst.

Rehosting- und Emulationsplattformen lassen kompilierte Mainframe-Workloads auf Standardhardware oder Cloud-Instanzen laufen. Ihr COBOL bleibt COBOL, Ihr JCL bleibt JCL, und eine Kompatibilitätsschicht liefert die Laufzeitdienste, die früher der Mainframe bereitgestellt hat.

Automatisierte Übersetzungswerkzeuge konvertieren Quellcode von COBOL nach Java, C# oder in eine andere moderne Zielsprache. Diese Kategorie begeistert Käufer am meisten und enttäuscht am häufigsten, aus Gründen, die weiter unten stehen.

Datenmigrationswerkzeuge bewegen die Daten selbst: VSAM-Dateien, sequenzielle Datasets und DB2-Tabellen in relationale oder cloud-native Speicher. Sie beherrschen die Zeichensatzkonvertierung, die gepackten Dezimalfelder und die Satzlayouts, die allgemeine ETL-Produkte schlicht nicht parsen können.

Die großen Cloud-Anbieter bündeln jeweils mehrere davon, und die Spezialanbieter haben sich in den letzten Jahren stark durch Übernahmen konsolidiert. Bevor Sie einen mehrjährigen Supportvertrag unterschreiben, prüfen Sie, wem das Produkt derzeit gehört und wie verbindlich die Roadmap ist, denn Eigentumsverhältnisse ändern sich in diesem Markt häufiger als die Technologie.

Was Analysewerkzeuge wirklich richtig machen

Wenn Sie nur eine Kategorie kaufen, kaufen Sie diese. Discovery-Werkzeuge beantworten Fragen, für die ein Team externer Kräfte sonst mehrere Monate Handarbeit bräuchte.

Gute Analyseprodukte sagen Ihnen, welche Programme in der Produktion tatsächlich aufgerufen werden und welche seit einem Jahrzehnt tot sind, wie Daten von einem Bildschirmfeld über ein halbes Dutzend Programme in eine DB2-Tabelle fließen, welche Copybooks über Subsysteme hinweg geteilt werden und wo der wirklich gefährliche Code liegt. Dieses letzte Ergebnis ist es, das Pläne ändert. Jeder Mainframe-Bestand enthält eine Handvoll Programme, von denen alles abhängt, und es sind selten die, die das Unternehmen vermutet.

Die Grenze ist die Interpretation. Ein Abhängigkeitsgraph mit vierzigtausend Knoten ist eine Datenmenge, keine Erkenntnis. Jemand muss die Ausgabe trotzdem ansehen, sie zu fachlichen Fähigkeiten gruppieren und entscheiden, was zuerst umzieht. Werkzeuge, die versprechen, Geschäftsregeln automatisch abzuleiten, erzeugen eher eine Paraphrase des Codes als eine Beschreibung der Absicht, und beide unterscheiden sich genau dort, wo der Code einen Fehler enthält, an den sich das Unternehmen stillschweigend angepasst hat.

Führen Sie die Analyse durch, bevor Sie sich auf einen Ansatz festlegen. Unser Leitfaden zur Mainframe-Modernisierungsstrategie arbeitet heraus, wie diese Erkenntnisse die Entscheidung zwischen Rewrite, Refactor und Replatform prägen sollten.

Rehosting-Plattformen: schnell, echt und keine Modernisierung

Rehosting ist die vorhersehbarste verfügbare Option und wird gerade deshalb chronisch unter Wert verkauft.

Der Vorschlag ist einfach. Ihr COBOL wird auf einer Plattform neu kompiliert oder interpretiert, die die Laufzeitdienste des Mainframes emuliert, sodass Transaktionsverarbeitung, Batch-Steuerung, Dateiverwaltung und Job Control sich weiter verhalten wie zuvor. Weil sich der Quellcode kaum ändert, ist die Testlast weit geringer als auf jedem anderen Weg, und Projekte enden in Monaten statt in Jahren.

Die Ersparnis ist real, und sie kommt aus dem Hardware- und Lizenzmodell, nicht aus der Software. Organisationen berichten häufig von deutlichen Senkungen der jährlichen Betriebskosten nach dem Abschied vom physischen Mainframe, was oft ausreicht, um die nächste Arbeitsphase zu finanzieren.

Was Rehosting nicht leistet, ist genau das, weswegen die meisten Vorstände diese Programme genehmigen. Nach einem erfolgreichen Rehost haben Sie immer noch eine COBOL-Codebasis, brauchen immer noch COBOL-Entwickler, und Ihre Chancen, sie einzustellen, haben sich nicht verbessert. An der Anwendung ist nichts leichter änderbar geworden. Rehosting kauft Ihnen Zeit und Geld, was einen echten Wert hat, sollte aber ehrlich als Plattformwechsel und nicht als Modernisierung bezeichnet werden.

Es führt außerdem eine neue Abhängigkeit ein. Sie haben IBMs Laufzeitumgebung gegen die Kompatibilitätsschicht eines Anbieters getauscht, und Ihr Produktivbestand hängt nun davon ab, dass dieser Anbieter sie weiter unterstützt. Angesichts der Konsolidierung in diesem Markt ist das ein Risiko, das in den Business Case gehört.

Automatisierte Übersetzung: hier wohnt der eigentliche Ärger

Automatisierte COBOL-Konvertierung funktioniert. Das ist nicht das Problem. Das Problem ist, wie die Ausgabe aussieht und was es kostet, mit ihr zu leben.

Übersetzungsengines sind in der Regel treu. Sie erhalten das Verhalten, auch das von niemandem beabsichtigte, weil Treue das einzige verteidigbare Designziel ist. Ein Werkzeug kann nicht wissen, dass eine bestimmte Rundungseigenart in einer Prämienberechnung ein Fehler ist, den die Aktuare seit 1997 ausgleichen, also reproduziert es ihn exakt. Das ist die richtige Entscheidung, und sie bedeutet, dass Ihr neues Java-System jede angesammelte Merkwürdigkeit des alten erbt.

Die Ausgabe wird außerdem von der Eingabe geformt. COBOL mit GOTO-Ketten, durchlaufenden PERFORM THRU-Konstruktionen, ALTER-Anweisungen und Paragraphen, die aus mehreren Richtungen betreten werden, zerfällt nicht in saubere Methoden, weil es keine saubere Zerlegung zu finden gibt. Heraus kommt Java oder C#, das COBOLs Kontrollfluss folgt, COBOLs Variablennamen benutzt und häufig schwerer zu lesen ist als das Original. Praktiker nennen das JOBOL, und es ist durchaus möglich, eine Migration erfolgreich abzuschließen und mit einer Codebasis dazustehen, die niemand in einer der beiden Sprachen pflegen kann.

Mehrere konkrete Konstrukte verursachen unverhältnismäßig viel Mühe, und es lohnt sich, früh nach ihnen zu suchen, weil sie die Schätzung des manuellen Aufwands treiben.

Die fünf Konstrukte, die den manuellen Aufwand treiben

Gepackte Dezimalarithmetik ist das erste. COBOLs COMP-3-Felder und die Festkomma-Dezimalsemantik bilden sich nicht auf Gleitkomma ab, und jedes Werkzeug, das es doch zulässt, erzeugt Finanzergebnisse, die an der vierten Nachkommastelle vom Mainframe abweichen. Korrekte Konvertierungen verwenden Dezimaltypen mit beliebiger Genauigkeit, die langsamer sind und über jeden Rechenpfad hinweg konsistent angewendet werden müssen.

Die Zeichenkodierung ist das zweite. Die Umsetzung von EBCDIC nach ASCII ist mechanisch, aber die Sortierreihenfolge ist nicht dieselbe, also kann sich alles ändern, was von der Sortierung abhängt. Berichte erscheinen in anderer Reihenfolge, Bereichsprüfungen verhalten sich anders, und Schlüsselvergleiche liefern Ergebnisse, die im neuen System richtig und gegen das alte falsch sind.

REDEFINES und Variantensätze sind das dritte. Ein einzelner Speicherbereich, der auf mehrere Arten interpretiert wird, hat in einer streng typisierten Sprache kein natürliches Äquivalent. Generierter Code produziert dafür meist Byte-Array-Manipulation, verpackt in Zugriffsmethoden, was funktioniert und in der Pflege zutiefst unangenehm ist.

Die Transaktionssemantik ist das vierte. Pseudo-konversationelle CICS-Programmierung, bei der der Zustand zwischen Bildschirminteraktionen in einem Kommunikationsbereich getragen wird, entspricht keinem modernen Web- oder Servicemuster. Sie zu emulieren erzeugt etwas Seltsames; sie sauber neu zu entwerfen ist eine Neuentwicklung der Präsentationsschicht.

Assembler-Routinen sind das fünfte und das zuverlässigst unterschätzte. Fast jeder langlebige Bestand enthält eine Handvoll Assembler-Module, meist von jemandem geschrieben, der vor Jahren in Rente gegangen ist, und sie tun etwas Performancekritisches oder Plattformspezifisches. Kein Werkzeug konvertiert sie. Sie werden von Hand nachgebaut, aus dem beobachteten Verhalten heraus, unter Test.

Wenn Sie Zielsprachen abwägen, zeigen unsere ausführlichen Leitfäden zur COBOL-zu-Java-Migration und zur COBOL-zu-C#-Migration , wie diese Konstrukte im jeweiligen Ökosystem landen.

Datenmigrationswerkzeuge und die Details, die zubeißen

Datenbewegung bekommt weniger Aufmerksamkeit als Codekonvertierung und verursacht mindestens ebenso viele Verzögerungen.

Spezialwerkzeuge verdienen sich hier ihren Platz, weil Mainframe-Datenformate wirklich sperrig sind. Sie verstehen Copybook-Layouts, gepackte und gezonte Dezimalfelder, Vorzeichen-Overpunches, OCCURS DEPENDING ON-Klauseln und die Tatsache, dass eine einzelne VSAM-Datei mehrere Satzarten enthalten kann, unterschieden durch ein Byte an Position zwölf. Allgemeine ETL-Produkte verstehen das nicht, und Teams, die sie dazu zwingen wollen, bauen meist eine schlechtere Version derselben Fähigkeit nach.

Das schwierigere Problem ist semantisch, nicht technisch. Mainframe-Dateien kodieren Bedeutung häufig so, dass ein relationales Schema sie nicht direkt ausdrücken kann: Füllfelder, die zweckentfremdet wurden, Datumsangaben als sechsstellige Ganzzahlen mit einer Fensterregel, Statuskennzeichen, deren gültige Werte in einem Programm statt in einer Nachschlagetabelle stehen, und doppelte Schlüssel, die die Anwendung toleriert. Zu entscheiden, was daraus im Zielschema werden soll, ist Analysearbeit, und sie lässt sich nicht automatisieren, weil die Antworten nur in den Köpfen von Menschen existieren.

Planen Sie die Abstimmung von Anfang an ein. Jeder migrierte Datenbestand braucht Satzzahlen, Kontrollsummen und einen feldweisen Vergleich gegen die Quelle, wiederholt statt einmalig ausgeführt. Die meisten Programme brauchen außerdem eine Phase des Parallelbetriebs, in der beide Systeme dieselben Eingaben verarbeiten und die Ausgaben Byte für Byte verglichen werden, bis die Unterschiede entweder beseitigt oder erklärt sind. Dieses Vergleichswerkzeug ist echte Software mit eigenen Entwicklungskosten, und es gehört in den Plan statt in die Reserve.

Mainframe-Migrationstools ohne Reue auswählen

Ein paar Grundsätze halten diese Entscheidungen bodenständig.

Bestehen Sie auf einem Proof of Concept mit Ihrem eigenen schlimmsten Code, nicht mit dem Muster des Anbieters. Wählen Sie das Modul, um das alle einen Bogen machen, das mit dem Assembler-Aufruf und dem siebenstufigen REDEFINES, und bitten Sie um dessen Konvertierung. Das Ergebnis sagt Ihnen mehr als jede Referenzkundenliste.

Fragen Sie ausdrücklich, wie das Werkzeug Dezimalarithmetik und Sortierreihenfolge behandelt, und lassen Sie sich den erzeugten Code zeigen statt einer Zusammenfassung. Wenn der Anbieter aus hässlicher Eingabe keinen lesbaren Code vorführen kann, gehen Sie davon aus, dass die Schätzung für die manuelle Nacharbeit größer ist als angegeben.

Behandeln Sie Automatisierungsprozente als Maß für Zeilen, nicht für Aufwand. Ein Werkzeug, das neunzig Prozent der Anweisungen konvertiert, kann Ihnen trotzdem die zehn Prozent überlassen, die das gesamte Risiko enthalten, und diese zehn Prozent verschlingen regelmäßig mehr als die Hälfte des Zeitplans.

Budgetieren Sie schließlich die Teile, die kein Werkzeug berührt: das Testgerüst, die Abstimmung, den Parallelbetrieb, die Betriebshandbücher und die Umschulung. Unser Leitfaden zu Kosten und Zeitplan der COBOL-Migration zeigt, wie sich diese Posten typischerweise über ein Programm verteilen.

Holen Sie sich eine unabhängige Einschätzung, bevor Sie unterschreiben

Mecanik arbeitet an Programmen zur Migration von Legacy-Mainframes und zur COBOL-Migration als Ingenieure und nicht als Werkzeughändler, was bedeutet, dass an keiner Plattformentscheidung eine Provision für uns hängt. Wir führen die Discovery durch, konvertieren ein wirklich schwieriges Modul von Hand und per Werkzeug und zeigen Ihnen den Unterschied, bevor irgendjemand etwas unterschreibt.

Wenn Ihr Bestand kleiner ist oder Ihre Frage eher der Zielsprache als dem Werkzeug gilt, beschreiben unsere Seiten zum COBOL-Modernisierungsservice , wie wir diese Arbeit zuschneiden. So oder so ist der nützliche erste Schritt ein kurzes Gespräch darüber, was tatsächlich in Ihrer Codebasis steckt, denn davon hängt die Antwort auf die Werkzeugfrage vollständig ab.

Siehe auch: COBOL-zu-Python-Migration , COBOL-zu-Go-Migration: Leitfaden für UK-Unternehmen und COBOL-zu-Rust-Migration - Leitfaden für UK-Unternehmen ., COBOL-Modernisierung: den Anbieter richtig wählen

Häufig gestellte Fragen

Können Mainframe-Migrationstools das gesamte Projekt automatisieren? Nein. Automatisierte Übersetzung konvertiert typischerweise die große Mehrheit der Anweisungen, doch der Rest enthält Assembler-Module, Transaktionszustände, Variantensatzstrukturen und undokumentierte Geschäftsregeln, die Handarbeit verlangen. Tests, Abstimmung und Parallelbetrieb bleiben vom erreichten Automatisierungsgrad ohnehin unberührt.

Was ist besser, Rehosting oder automatisierte Codekonvertierung? Sie lösen unterschiedliche Probleme. Rehosting holt die Last schnell von der Mainframe-Hardware und senkt die Betriebskosten, lässt Sie aber mit COBOL zurück. Codekonvertierung ändert Sprache und Bewerberpool, zu deutlich höheren Kosten und Risiken. Viele Organisationen rehosten zuerst, um damit eine gestaffelte Konvertierung zu finanzieren.

Warum sieht konvertierter COBOL-Code so unleserlich aus? Übersetzungsengines erhalten das Verhalten getreu, einschließlich COBOLs Kontrollfluss, Benennung und Datenstrukturen. Code rund um GOTO-Ketten und geteilte Speicherbereiche hat in Java oder C# kein sauberes Äquivalent, also spiegelt die Ausgabe die ursprüngliche Struktur wider. Wartbarer Code entsteht erst durch menschliches Refactoring nach der Konvertierung.

Welche Datenprobleme übersehen Mainframe-Migrationstools? Formatkonvertierung beherrschen sie gut, Bedeutung können sie nicht auflösen. Zweckentfremdete Füllfelder, sechsstellige Datumsangaben mit Fensterregeln, nur im Programm definierte Statuscodes und tolerierte doppelte Schlüssel verlangen alle menschliche Entscheidungen, bevor ein Zielschema korrekt entworfen werden kann.

Wie weise ich nach, dass sich ein migriertes System identisch verhält? Lassen Sie beide Systeme über einen festgelegten Zeitraum dieselben Produktionseingaben verarbeiten und vergleichen Sie die Ausgaben Feld für Feld, gestützt auf Satzzahlen und Kontrollsummen für jeden migrierten Datenbestand. Bauen Sie dieses Vergleichswerkzeug als eigenständiges Ergebnis, denn Unterschiede tauchen fortlaufend auf statt auf einmal.