Wo COBOL in Produktion noch die eigentliche Arbeit leistet

COBOL bleibt dort in Produktion, wo ein Unternehmen über Jahrzehnte Geld, Ansprüche und die Behandlung von Ausnahmen in einen verlässlichen Betriebsablauf eingebaut hat. Die Sprache ist in der Quellbibliothek sichtbar, doch zum System gehören auch JCL, Scheduler, Dateien, Datenbanken, Transaktionsmonitore, Betriebsanweisungen, Abstimmberichte und Vereinbarungen mit jedem angrenzenden System. Wer nur die Programme ersetzt, ersetzt den einfachsten Teil.

Der vertraute Satz „Banken verwenden noch COBOL“ stimmt und hilft fast gar nicht. Er verschweigt, welche Lasten noch davon abhängen und warum ihre Betreiber weiter dafür zahlen. COBOL konzentriert sich auf die Stapelabrechnung, die Verwaltung von Versicherungspolicen, zentrale Bankhauptbücher und die Berechnung staatlicher Leistungen. Diese Systeme blieben aktiv, weil sie auch unter schlechten Bedingungen korrekte Geschäftsergebnisse lieferten. Sie werden ersetzt, wenn die Änderung weniger kostet als das gemeinsame Risiko aus Wissensverlust, Plattformgrenzen, langsamen Produktänderungen und einer Schnittstelle, die niemand mehr sicher erweitern kann.

Die Produktionslandkarte folgt Geld und Ansprüchen

COBOL wird noch dort eingesetzt, wo ein großer, dauerhafter Datensatz viele Transaktionen überstehen muss und später jemand das Ergebnis erklären soll. Vier Arten von Arbeitslast prägen einen großen Teil der ernst zu nehmenden Produktionsbestände.

Die Stapelabrechnung nimmt die akzeptierten Vorgänge eines Tages, wendet Gebühren und Korrekturen an, gleicht Kontrollsummen ab, bucht Ergebnisse und erzeugt Dateien für nachgelagerte Stellen. Das Online-Frontend kann in einer neueren Sprache geschrieben sein, während der endgültige Finanzstand weiterhin aus COBOL-Jobs nach einem Annahmeschluss stammt.

Die Policenverwaltung hält die vertragliche Geschichte von Versicherungsprodukten. Sie berechnet Prämien, verarbeitet Nachträge, verlängert Policen, erzeugt Rechnungen und Dokumente und hält fest, welcher Schutz an einem bestimmten Datum galt. Ein Webportal kann davorstehen, ohne dieses System zu ersetzen.

Zentrale Bankhauptbücher buchen Soll und Haben, führen Salden, berechnen Zinsen, erzwingen Buchungsregeln und schließen Rechnungsperioden ab. Mobile Apps und Zahlungs-APIs sind Kanäle. Das Hauptbuch entscheidet, was die Bank für geschehen hält.

Die Berechnung staatlicher Leistungen wendet Gesetze und Programmregeln auf Anträge, Erwerbsverläufe, Haushaltsdaten, Wirksamkeitsdaten, Überzahlungen und Widersprüche an. Das Haushaltsmaterial der Social Security Administration beschreibt etwa die Bearbeitung von Anträgen über getrennte alte COBOL-Systeme. Das ist eine konkrete betriebliche Abhängigkeit und keine Nostalgie für eine alte Sprache.

Diese Kategorien überschneiden sich. Eine Leistungsplattform besitzt Hauptbücher. Ein Versicherer führt Abrechnungsläufe aus. Eine Bank verwaltet Produkte mit Wirksamkeitsdaten ähnlich denen einer Police. Entscheidend ist die fachliche Invariante: Die Abrechnung muss aufgehen, eine Police muss den Schutz zu einem Datum reproduzieren, ein Hauptbuch muss die buchhalterische Wahrheit bewahren und ein Leistungssystem muss eine Anspruchsentscheidung erklären.

Stapelabrechnung ist eine kontrollierte Kette, kein einzelnes Programm

Eine Abrechnungslandschaft ist ein zeitgesteuerter Abhängigkeitsgraph mit finanziell wirksamer Ausgabe. Eine typische Nacht beginnt erst, wenn die Kanäle ihre Eingabefenster schließen. Jobs prüfen Dateizahlen, sortieren Datensätze, reichern Transaktionen an, berechnen Entgelte, buchen Summen, vergleichen Gesamtwerte, erstellen Ausgabedateien und leiten Ausnahmen an den Betrieb weiter. Ein Wiederanlauf kann an einem sicheren Kontrollpunkt beginnen statt ganz am Anfang.

Die z/OS-Dokumentation von IBM bezeichnet Stapelverarbeitung als grundlegende Funktion von z/OS und erklärt, wie JES Jobs entgegennimmt, plant und ihre Ausgabe steuert. Diese Beschreibung korrigiert einen häufigen Modernisierungsfehler: Die ausführbare COBOL-Datei besitzt nicht den ganzen Ablauf. JCL benennt Ein- und Ausgaben, katalogisierte Prozeduren liefern gemeinsame Schritte, der Scheduler liefert Kalender und Abhängigkeiten, und der Betrieb deutet Rückgabecodes und Spool-Ausgaben.

Ein kleiner Jobausschnitt zeigt, wie viel Verhalten außerhalb des Anwendungsquelltexts liegt:

//SETTLE   JOB CLASS=A,MSGCLASS=X
//POST     EXEC PGM=POSTDAY,PARM='RESTART=CHK7'
//INTRANS  DD DSN=BANK.CLEARING.ACCEPTED,DISP=SHR
//OUTPOST  DD DSN=BANK.LEDGER.POSTED(+1),
//            DISP=(NEW,CATLG,DELETE)
//EXCEPT   DD DSN=BANK.SETTLE.EXCEPT(+1),
//            DISP=(NEW,CATLG,DELETE)
//SYSOUT   DD SYSOUT=*

Der Ersatz muss die Fragen beantworten, die dieser Ausschnitt offenlegt. Was erzeugt Generation (+1)? Löscht ein fehlgeschlagener Schritt eine teilweise Ausgabe? Bei welchen Rückgabecodes darf der nächste Job laufen? Was bedeutet CHK7 nach einer teilweise erfolgten Buchung? Wer entscheidet, ob eine Ausnahmedatei vollständig ist? Die Übertragung von POSTDAY in eine andere Sprache kann gültigen Code und zugleich einen ungültigen Abrechnungsprozess hervorbringen, wenn diese Kontrollen fehlen.

Abrechnungssysteme bleiben, weil sie auf Annahmeschluss, Wiederanlauf und große Ein- und Ausgabemengen abgestimmt sind. Sie bewegen sich schließlich, wenn neue Kanäle häufigere Buchungen verlangen, Gegenparteien andere Datei- oder API-Grenzen fordern, Stapelfenster mit weltweiten Betriebszeiten kollidieren oder zu wenige Personen eine fehlgeschlagene Kette wiederherstellen können.

Policenverwaltung bewahrt Zeit als Geschäftsdaten

Eine Policenverwaltung muss sowohl „Was galt damals?“ als auch „Was gilt jetzt?“ beantworten. Wirksamkeits- und Transaktionsdaten, rückwirkende Nachträge, Kündigungen, Wiederinkraftsetzungen, Verlängerungen, regionale Regeln und Produktversionen beeinflussen die Antwort. Wegen dieses Zeitmodells ersetzt eine einfache Datenbankmigration das System nur selten.

Nehmen wir einen heute erfassten Nachtrag, der vor der letzten Rechnung wirksam wird. Das System muss vielleicht die Prämie für einen Teil der Laufzeit neu berechnen, bereits ausgegebene Dokumente bewahren, eine neue Forderung erzeugen und einen Prüfpfad hinterlassen, der die Differenz erklärt. Ein naiver Dienst, der nur den neuesten Policenstand speichert, vernichtet Belege. Ein getreuer Ersatz behandelt Ereignisse, Wirksamkeitszeiträume, abgeleitete Werte und ausgegebene Unterlagen als getrennte Anliegen.

COBOL passt zu dieser Arbeit, weil feste Geschäftsdatensätze, Dezimalarithmetik, sequenzielle Verarbeitung und ausdrückliche Verzweigungen zur Domäne passen. Der umgebende Bestand enthält oft Copybooks, die viele Programme teilen, außerhalb des Codes gepflegte Tabellen, Dokumentvorlagen, Tarifierungsmodule und nächtliche Abrechnungsläufe. Manche Regeln kommen doppelt vor, weil Online-Angebot und Verlängerungsabrechnung getrennt gewachsen sind. Die doppelte Logik kann nur bei einer seltenen Produktversion abweichen. Genau dann kann ein sauberer Neubau ein gültiges Kundenergebnis verändern.

Die Betreiber schalteten diese Systeme nicht ab, nur weil sich Browser und Anwendungsserver änderten. Sie setzten Portale, Workflow-Werkzeuge und APIs davor. Das war vernünftig, solange Produkte stabil blieben und der Kern belegbare Ergebnisse erzeugte. Die Entscheidung kippt, wenn ein neues oder geändertes Produkt Eingriffe in viele alte Programme verlangt, jede Veröffentlichung von einer kleiner werdenden Prüfergruppe abhängt oder eine nicht mehr unterstützte Dokument- oder Integrationskomponente den ganzen Weg blockiert.

Ein Ersatz muss zeitliches Verhalten mit datierten Testfällen belegen. Prüfen Sie eine neue Police, einen Nachtrag in der Laufzeit, eine rückdatierte Korrektur, eine Kündigung mit anschließender Wiederinkraftsetzung und eine Verlängerung über die Grenze einer Produktversion. Vergleichen Sie Geldbeträge, Status, Deckungszeiträume, Dokumente, Hauptbucheinträge und Begründungen. Die aktuelle Zeile einer Policentabelle zu treffen reicht nicht.

Zentrale Hauptbücher bleiben, weil Buchungsfehler sich fortpflanzen

Ein zentrales Hauptbuch läuft weiter in COBOL, weil eine Änderung der Buchungsmaschine die Bücher des Instituts verändern kann. Die Arbeit besteht aus weit mehr als dem Addieren und Subtrahieren von Salden. Buchungsreihenfolge, Wertstellung, Sperren, Stornos, Zinsabgrenzung, Gebühren, Währungsgenauigkeit, Zwischenkonten und Periodenabschlusskontrollen wirken zusammen.

Die Branche verwechselt oft ein Hauptbuch mit einem Saldodienst. Ein Saldodienst beantwortet eine Leseanfrage schnell. Ein Hauptbuch zeichnet geordnete, dauerhafte Einträge auf und erlaubt die Rekonstruktion. Kopiert eine Migration nur aktuelle Salden und verliert Buchungshistorie oder Stornobeziehungen, können die Zahlen am Morgen der Umstellung stimmen und nach der ersten Reklamation unerklärbar werden.

Die Online-Transaktionsverarbeitung läuft häufig über CICS. Die Enterprise-COBOL-Dokumentation von IBM erklärt, dass Programme mit CICS-Diensten eingebettete CICS-Anweisungen über die CICS-Befehlsschnittstelle kompilieren. Dieses Detail weist auf eine weitere Grenze hin, die ein Neubau finden muss: Der Transaktionsumfang kann von CICS-Ressourcen, Db2-Arbeit, Dateien, Warteschlangen und Fehlerbehandlung abhängen und nicht allein von COBOL-Anweisungen.

Der Ersatz eines Hauptbuchs scheitert auf wiedererkennbare Weise. Ein Team ordnet Kontozeilen neuen Tabellen zu, baut Buchungen für den Normalfall nach und weist einen Satz Unit-Tests nach. Im Parallellauf trifft ein altes Storno ein, nachdem die zugehörige Transaktion eine Buchungsdatumsgrenze überschritten hat. Das neue System wendet die heutige Regel an, das alte die Regelversion des ursprünglichen Eintrags. Beide Ausführungen wirken plausibel. Nur eine passt zu den anerkannten Büchern des Instituts.

Die Lösung besteht nicht darin, jeden historischen Implementierungsfehler zu behalten. Das Team muss Verhalten einordnen. Buchhalterische Invarianten und vertragliche Ergebnisse verlangen Parität. Zufällige Anzeigeformatierung vielleicht nicht. Eine verdächtige Regel braucht eine ausdrückliche fachliche Entscheidung, bevor jemand sie „repariert“. Sonst treffen Entwickler politische Entscheidungen im Code-Review, wo niemand die finanzielle Folge sieht.

Leistungsberechnung verbindet Recht und Betriebsgeschichte

Staatliche Leistungssysteme behalten COBOL, weil ausführbare Regeln auf langen Fallgeschichten und Verwaltungsverfahren liegen. Eine Berechnung kann von Erwerbszeiträumen, Haushaltszusammensetzung, Behinderungsstatus, früheren Entscheidungen, Wechselwirkungen zwischen Programmen, Wirksamkeitsdaten, Rundungsregeln, Grenzen, Verrechnungen und späteren Korrekturen abhängen. Bei Widersprüchen muss die Behörde eine Entscheidung oft mit den damals geltenden Fakten und Regeln reproduzieren.

Das Gesetz ist nicht die ausführbare Spezifikation. Verordnungen, Fachhandbücher, Tabellenänderungen, Stapelkalender, Regeln zur Datenbereinigung und Ausnahmeverfahren schließen die Lücke zwischen Gesetzestext und Zahlung. Zwei Datensätze, die einem neuen Dienst gleich erscheinen, können verschiedene Wege nehmen, weil ein alter Indikator festhält, wie die Behörde eine frühere Abweichung löste.

Modernisierungsprogramme geraten in Schwierigkeiten, wenn sie seltsame Felder für überholt halten, bevor sie deren Nutzung verfolgen. Ein einstelliger Code kann einen Rechenzweig wählen, eine Mitteilung unterdrücken, einen Fall zur manuellen Prüfung schicken oder eine frühere Entscheidung bewahren. Seine Entfernung kann die Zahlung einer Person ändern, ohne einen Softwarefehler auszulösen. Das Programm läuft, die API meldet Erfolg, und der Fehler fällt erst auf, wenn Anspruchsteller oder Sachbearbeiter das Ergebnis anfechten.

Ein Ersatz für die Leistungsberechnung braucht deshalb Belege auf Entscheidungsebene. Erfassen Sie pro aufgezeichnetem Fall normalisierte Eingaben, Regelversion, Zwischenergebnisse, Endbetrag, Gültigkeitszeitraum, Mitteilungen, Begründungscodes und die Weiterleitung zur manuellen Prüfung. Schwärzen oder tokenisieren Sie personenbezogene Daten, bevor sie ihren zulässigen Bereich verlassen. In regulierten Umgebungen müssen Testinfrastruktur und Modelle womöglich innerhalb derselben Grenze wie die Quelldaten laufen.

Der Ersatzdruck steigt, wenn Gesetzesänderungen zu lange brauchen, alte Schnittstellen das sichere Zusammenführen von Daten verhindern, Beschäftigte bestimmte Pfade nicht mehr erklären können oder die Beschaffung für die Plattform enger wird. Öffentliche Kontrolle macht einen übereilten Neubau besonders gefährlich. Schnellere Änderung zählt, doch reproduzierbare Entscheidungen zählen mehr.

Diese Systeme blieben wegen des ungleichen Ersatzrisikos

Einen funktionierenden COBOL-Bestand weiterzubetreiben war oft finanziell vernünftig. Der Nachteil des Wartens wuchs langsam als Wartungskosten, langsamere Lieferung und Personalrisiko. Der Nachteil eines fehlerhaften Ersatzes trat sofort als falsche Salden, gescheiterte Abrechnungen, falscher Schutz oder falsch berechnete Zahlungen ein.

Mehrere Bedingungen verstärkten dieses Ungleichgewicht. Mainframe-Funktionen für Transaktionen und Stapelverarbeitung übernahmen bereits Planung, Zugriffskontrolle, Wiederherstellung und große I/O-Mengen. Hardware- und Compiler-Upgrades verlängerten das Leben der Plattform ohne erzwungenen Anwendungsneubau. Stabile Dateiformate ließen neue Kanäle am Rand andocken. Vor allem besaß das Geschäft Produktionsbelege dafür, dass der alte Weg funktionierte, einschließlich jahrzehntelang gewachsener Ausnahmen, die kein Anforderungsdokument enthielt.

Die verbreitete Behauptung, COBOL habe nur aus Angst des Managements vor Veränderung überlebt, greift zu kurz. Manager finanzierten viele Änderungen rund um diese Kerne. Sie ersetzten Terminals durch Weboberflächen, führten Nachrichtenvermittler ein, stellten Dienste bereit und verlagerten Berichte. Sie vermieden den Ersatz des zustandsbehafteten Zentrums, weil der Geschäftsnutzen das Risiko nicht ausglich.

Ein weiterer verbreiteter Rat lautet, jeden COBOL-Absatz in gleichwertigen Code einer neueren Sprache zu übertragen. Das wirkt attraktiv, weil es eine messbare Konversionsquote erzeugt und das Verhalten nahe am Ausgang hält. Als Endzustand ist es falsch. Eine Absatz-zu-Funktion-Übertragung bewahrt globalen Zustand, dateiförmige Grenzen, Stapelannahmen und jahrzehntelange strukturelle Kompromisse. Danach besitzt die Organisation einen Mainframe-Entwurf in ungewohnter Syntax, oft mit schlechteren Betriebswerkzeugen.

Eine sachliche Entscheidung trennt drei Fragen. Ist die aktuelle Plattform für den nächsten Planungshorizont zuverlässig genug? Kann die Organisation Geschäftsregeln in der nötigen Geschwindigkeit ändern? Kann sie Fehler weiterhin beheben und erklären, ohne von ein oder zwei Personen abzuhängen? Ein „Ja“ auf die erste Frage hebt ein „Nein“ auf eine der anderen nicht auf.

Lange Laufzeit schafft auch falsches Vertrauen in die Dokumentation. Betriebshandbücher beschreiben oft den Normalplan und das letzte Wiederherstellungsverfahren, das jemand aufgeschrieben hat. Sie halten nicht unbedingt fest, warum eine Kontrollsumme eine Quelle ausschließt, warum eine Datei vor einer anderen eintreffen muss oder warum der Betrieb einen Rückgabecode ungleich null akzeptiert und beim nächsten stoppt. Solche Entscheidungen leben als Gewohnheit weiter. Eine Migration entdeckt sie erst bei einer Abweichung im Parallellauf, also spät und teuer.

Behandeln Sie Betriebswissen wie Produktionslogik. Beobachten Sie einen vollständigen Zyklus mit Annahmeschluss, Wiederanlauf, Abstimmung, verspäteter Eingabe und manueller Reparatur. Lassen Sie den Betrieb die vertrauten Belege erklären und verbinden Sie diese mit den erzeugenden Jobs und Daten. Nutzt jemand privat eine Tabelle oder Befehlsliste für den Tagesabschluss, gehört sie in den Umfang, selbst wenn Architekturdiagramme sie auslassen. Der Ersatz braucht eine unterstützte Kontrolle oder die ausdrückliche Entscheidung, die Praxis aufzugeben.

Verwechseln Sie ein ruhiges System nicht mit einem einfachen. Reife Kerne wirken oft ruhig, weil der Betrieb Unregelmäßigkeiten abfängt, bevor sie im Störungsmanagement erscheinen. Zählen Sie manuelle Eingriffe, Wiederholungen, Übersteuerungen, Abstimmungen und Anrufe bei früheren Teammitgliedern. Diese Signale zeigen, ob die Stabilität aus der Software stammt oder aus Menschen, die sie ausgleichen.

Das erzwingende Ereignis liegt meist außerhalb des COBOL-Compilers

COBOL selbst setzt selten die Frist. Die Entscheidung wird unvermeidbar, wenn eine äußere Bedingung das Warten unmöglich macht. Ein Anbieter beendet den Support für Datenbank, Bildschirmebene, Scheduler oder Integrationsprodukt. Eine Fusion verlangt, zwei unvereinbare Hauptbücher zu vereinen. Ein neues Produkt braucht taggleiche Abläufe von einem nächtlichen Kern. Eine regulatorische Änderung verlangt Nachvollziehbarkeit, die der aktuelle Prozess nicht günstig liefern kann. Eine zentrale Fachkraft geht und nimmt das Wiederherstellungswissen mit.

Plattformkosten können beitragen, aber ein reiner Lizenzvergleich ist ein schwacher Migrationsgrund. Verteilte Ersatzsysteme verursachen eigene Kosten für Rechenleistung, Beobachtbarkeit, Speicher, Netz, Sicherheit und Personal. Braucht der Antrag unrealistisch billige Infrastruktur, scheitert er mit Produktionsvolumen und Aufbewahrung.

Auch Personalrisiko braucht Genauigkeit. „COBOL-Entwickler gehen in Rente“ sagt einem CTO nicht, was er genehmigen soll. Messen Sie Verantwortung auf Ebene der Geschäftsfunktion. Ermitteln Sie, wer den Wiederanlauf zum Monatsende erklären, eine Prämienregel ändern, den Umweg eines Buchungscodes um eine Warteschlange begründen und einen Leistungslauf abstimmen kann. Die Gefahr ist konzentriertes Wissen und nicht das Durchschnittsalter einer Sprachgemeinschaft.

Architekturdruck entscheidet, wenn jede neue Fähigkeit durch wenige starre Datei- oder Transaktionsgrenzen muss. Teams bauen Adapter, duplizieren Referenzdaten und warten auf die Stapelbestätigung. Schließlich zeigt sich der Preis als Produktverzögerung und betriebliche Unklarheit statt auf einer Mainframe-Rechnung. Dann liegt die Verantwortung für den Ersatz außerhalb der Infrastruktur, bei der Führungskraft für Produkteinführungen, Zusammenlegung des Betriebs oder einen gesetzlichen Termin.

Verlangen Sie vor der Freigabe ein Memo zum erzwingenden Ereignis. Benennen Sie Bedingung, bindendes Datum oder Kriterium, betroffene Geschäftsergebnisse, zulässige Parallelphase und nötige Umstellungsbelege. Steht dort nur „technische Schulden“, wandert der Umfang, weil niemand die zu ermöglichende Entscheidung definiert hat.

Das Migrationsrisiko steckt im Verhalten zwischen Komponenten

Ein verlässlicher Neubau beginnt mit der Ermittlung beobachtbaren Verhaltens im gesamten Bestand. Quelltextanalyse zählt, aber Code allein zeigt keine Scheduler-Übersteuerungen, Bedienhandlungen, lebenden Datenformen, undokumentierten Verbraucher oder Tabellenregeln. Das Inventar muss Programme mit Jobs, Datensätzen, Datenbankobjekten, Warteschlangen, Masken, Berichten und Bestätigungen nachgelagerter Systeme verbinden.

Beginnen Sie mit Produktionspfaden statt Repository-Ordnern. Verfolgen Sie für ein Geschäftsergebnis das auslösende Ereignis bis zur letzten Buchung oder Mitteilung. Erfassen Sie Komponente, Eingabe, Ausgabe, Nebenwirkung, Kontrollpunkt und Wiederherstellungsaktion. Wiederholen Sie das für Ausnahmen: doppelte Eingabe, fehlende Referenzdaten, teilweiser Datenbankausfall, verspätetes Eintreffen, Wiederanlauf nach Ausgabeerzeugung und manuelle Korrektur.

Ein Verhaltensdatensatz kann diese schlichte Form verwenden:

{
  "case_id": "settlement-late-file-restart",
  "inputs": ["accepted-transactions", "fee-table-v17"],
  "pre_state": "checkpoint-6-complete",
  "action": "restart-from-checkpoint-7",
  "outputs": ["posted-generation", "exception-generation"],
  "invariants": ["debits-equal-credits", "no-duplicate-posting"],
  "evidence": ["job-log", "control-report", "ledger-query"]
}

Der Datensatz hängt bewusst nicht von einer Implementierung ab. Er sagt, was wahr bleiben muss und woher der Nachweis kommt. Bauen Sie Datensätze aus echten Produktionsvarianten und ergänzen Sie konstruierte Randfälle für Grenzen, die im Beobachtungsfenster nicht vorkommen.

Führen Sie alten und neuen Pfad mit derselben akzeptierten Eingabe aus und vergleichen Sie normalisierte Ergebnisse. Die Normalisierung entfernt Werte, die berechtigt abweichen dürfen, etwa erzeugte Kennungen oder Zeitstempel. Geld, Daten, Status, fachlich relevante Reihenfolge, Begründungscodes und Nebenwirkungen bleiben erhalten. Speichern Sie Abweichungen als prüfbare Artefakte. Eine grüne Zahl ohne konkreten Diff verleitet Teams dazu, unerklärte Unterschiede durchzuwinken.

Aufgezeichneter Verkehr liefert starke Belege, ist aber keine vollständige Spezifikation. Er belegt nur beobachtete Fälle. Ergänzen Sie ihn durch aus Quellen abgeleitete Zweige, Copybook-Werte, Tabellendomänen, Gespräche mit dem Betrieb und Abstimmverfahren. Dieser Unterschied zählt: Replay-Tests messen die Kompatibilität mit beobachteter Nutzung, Regeltests decken gültiges Verhalten ab, das während der Aufzeichnung nicht vorkam.

Sicherheit und Datenschutz prägen die Methode. Produktionsdatensätze können Konto-, Policen-, Gesundheits- oder Identitätsdaten enthalten. Halten Sie Erfassung, Tokenisierung, Modellausführung und Vergleich im zulässigen Bereich, wenn Daten ihn nicht verlassen dürfen. Bewahren Sie referenzielle Beziehungen in tokenisierten Fixtures, sonst lassen sich viele datensatzübergreifende Regeln nicht testen.

Die Datendarstellung braucht eine eigene Testfläche. Copybooks können gepackte Dezimalzahlen, Vorzeichenfelder, Überlagerungen, Wiederholungsgruppen und Werte beschreiben, deren Bedeutung von einem anderen Feld abhängt. Dateien können EBCDIC, feste Satzlängen oder standortspezifische Regeln für fehlende Werte verwenden. Ein Parser, der still Leerzeichen entfernt oder ein ungültiges Datum normalisiert, kann Zustände vereinen, die das alte System trennte. Erzeugen Sie Grenz-Fixtures aus jeder deklarierten Feldform und vergleichen Sie geparste Werte sowie abgewiesene Datensätze, bevor Sie Geschäftsregeln testen.

Gemeinsame Copybooks bedeuten nicht zwangsläufig gleiche Bedeutung. Ein Programm kann einen Code als Kontostatus lesen, ein anderes dieselben Bytes als Routingentscheidung. Verfolgen Sie Lese- und Schreibzugriffe statt nur Namen. Ermitteln Sie bei über die Zeit veränderten Layouts, welche Produzenten jede Version noch senden und wie Verbraucher sie unterscheiden. So löscht ein neues kanonisches Modell keine Information, die eine späte Datei oder historische Wiederholung noch braucht.

Datenkonvertierung und Anwendungsersatz erzeugen verschiedene Risiken. Eine konvertierte Historie beweist, dass Datensätze die Zielform erreichen. Sie beweist nicht, dass die Verarbeitung morgen richtige neue Datensätze erzeugt. Testen Sie Eröffnungssalden und Historienkonvertierung getrennt vom Transaktionsverhalten und verbinden Sie beides in einer Generalprobe über eine echte Buchungs- oder Rechnungsgrenze. Stimmen Sie Satzanzahl, Kontrollsummen, Salden, nicht zugeordnete Verweise und jede Ablehnung ab. Ein passender Gesamtwert kann zwei gleich große gegenläufige Fehler verbergen, deshalb prüfen Sie auch auf Eintrags- und Kundenebene.

Leistungstests müssen die Arbeitsform statt nur das Durchschnittsvolumen abbilden. Ein Abrechnungslauf hat Eingangsspitzen und eine feste Endzeit. Ein Online-Hauptbuch hat Latenzanforderungen und Konkurrenz um stark genutzte Konten. Eine Leistungsneuberechnung kann tiefe Historie lesen und mehrere Nebenwirkungen erzeugen. Bewahren Sie Reihenfolge und Sperrkonflikte in Testdaten, messen Sie die Wiederanlaufzeit nach einem Ausfall und beziehen Sie nachgelagerte Verarbeitung ein. Ein schneller Produzent, der das nächste System überlastet, verbessert den Geschäftsweg nicht.

Behandeln Sie Rückgabecodes und Betriebsmeldungen als Schnittstellen, bis das Gegenteil bewiesen ist. Scheduler verzweigen danach, Supportteams suchen danach und Verfahren nutzen sie zur Entscheidung über die Vollständigkeit einer Ausgabe. Ordnen Sie jede alte Bedingung einem typisierten Fehler, einer Wiederholungsregel, einem Alarm und einer Wiederherstellungsaktion im Ziel zu. Machen Sie Idempotenz ausdrücklich: Eine Wiederholung nach einem Timeout darf Geld, Dokumente oder Ausnahmen nicht doppelt verarbeiten.

In die Prüfergruppe gehören die Personen, die Ergebnisse abstimmen, nicht nur die Quelltextpfleger. Der Finanzbetrieb erklärt, welche Summen eine Abrechnung bestätigen. Policenfachleute kennen die datierten Dokumente, die reproduzierbar bleiben müssen. Sachbearbeiter kennen Begründungscodes für manuelle Prüfung. Ihre Belege machen aus einem technischen Diff eine Umstellungsentscheidung. Ohne sie kann ein Team Tausende Unterschiede schließen und dennoch den einen übersehen, der eine Verpflichtung verändert.

Legen Sie schließlich eine Regel für unbekanntes Verhalten fest. Wenn der alte Pfad ein unerklärtes Ergebnis erzeugt, kopieren Sie es nicht automatisch und korrigieren Sie es nicht still. Isolieren Sie den Fall, bewahren Sie Eingaben und Belege, benennen Sie einen fachlichen Besitzer und protokollieren Sie das gewählte Zielverhalten. Diese Warteschlange enthält Fehler, überholte Regeln und gültige Ausnahmen. Ihre Abarbeitung misst Bereitschaft ehrlicher als der Anteil konvertierter Dateien.

Ersetzen Sie die Grenze und belegen Sie die Umstellung

Das Ziel soll Verantwortung und Schnittstellen modernisieren und erforderliche Ergebnisse bewahren. Definieren Sie begrenzte Dienste um Geschäftsfähigkeiten, wählen Sie ein dauerhaftes Datenmodell und trennen Sie Stapel- und Online-Verantwortung klar. Lassen Sie nicht die alte Programmstruktur jedes Modul bestimmen. Lassen Sie ihr Verhalten jedes außen wirksame Ergebnis begrenzen, bis das Geschäft eine Änderung genehmigt.

Eine praktische Folge hat fünf Teile:

1. Frieren Sie für den gewählten Geschäftsausschnitt ein Inventar der Produktionseinstiege, geplanten Jobs, Speicher und Verbraucher ein.
2. Bauen Sie das Paritätsgerüst vor dem Ersatz, damit jede Implementierungsentscheidung dieselben Belege erhält.
3. Implementieren Sie die neue Architektur hinter stabilen Adaptern einschließlich Wiederanlauf, Abstimmung und Betriebskontrollen.
4. Lassen Sie historische Fixtures und aufgezeichneten Produktionsverkehr durch beide Pfade laufen und ordnen Sie jede Abweichung ein.
5. Stellen Sie mit ausdrücklichen Rückfallkriterien um und halten Sie die Abstimmung aktiv, bis das vereinbarte Risikofenster endet.

Wählen Sie Ausschnitte, die in einem prüfbaren Geschäftsergebnis enden. „200 Programme konvertieren“ ist kein Ausschnitt. „Eine Abrechnungsquelle bis zu Buchung und Abstimmung verarbeiten“ ist einer. Das legt Abhängigkeiten offen und liefert der Führung bewertbare Belege.

CodeHero setzt diesen Ansatz um, indem es COBOL, JCL und den übrigen Baum gemeinsam liest, die Architektur in Go, Rust, TypeScript und Postgres neu baut und das Verhalten mit einem Paritätsgerüst gegen aufgezeichneten Produktionsverkehr prüft. Seine Projekte werden in unter 30 Tagen geliefert, einschließlich isolierter Ausführung innerhalb der Kundengrenze, wenn die Umgebung sie verlangt.

Geschwindigkeit nimmt dem Eigentümer die Verantwortung für die Umstellung nicht ab. Die Organisation entscheidet weiter, welches Verhalten vertraglich ist, welche Auffälligkeiten korrigiert werden sollen, welche Belege Risiko- und Prüfteams brauchen und wer den Rückfall genehmigen darf. Diese Entscheidungen lassen sich nicht sicher aus Quelltext ableiten.

Ein COBOL-System sollte nicht umziehen, weil seine Syntax alt aussieht. Es sollte umziehen, wenn die aktuelle Grenze das Geschäft blockiert und wenn der Ersatz Fall für Fall zeigen kann, dass Geld, Anspruch, Geschichte, Wiederherstellung und Erklärung weiter funktionieren. Geben Sie den Neubau frei, wenn beides stimmt.