Wie eine AS/400-Migration mehr als ein ERP bewegt

Den AS/400 als ERP zu bezeichnen, ist ein Kategorienfehler, der Teams den falschen Projektumfang wählen lässt. Ein ERP ist eine Anwendung. IBM i ist eine Betriebsumgebung, auf der gekaufte Pakete, individuelle RPG-Anwendungen, eine Datenbank, Masken, Warteschlangen, Berichte, Sicherheitsregeln und die Routinen laufen können, die all diese Teile verbinden. Ein Unternehmen kann das bekannte Paket ersetzen und dennoch an die Maschine gebunden bleiben.

Eine AS/400-Migration gelingt nur, wenn der Ersatz die Geschäftsergebnisse der bestehenden Umgebung reproduziert, einschließlich der ungewöhnlichen Abläufe, die niemand dokumentiert hat. Tabellen zu verschieben und sichtbare Programme neu zu schreiben, deckt nur einen Teil dieser Aufgabe ab. Die schwere Arbeit besteht darin, alle Orte mit Verhalten zu finden, zu entscheiden, welches Verhalten erhalten bleiben soll, und vor der Abschaltung nachzuweisen, dass das neue System mit der Produktion übereinstimmt.

Die sinnvolle Untersuchungseinheit ist weder ein Anwendungsname noch ein Quelltextmember. Es ist ein Geschäftsvorgang mit jedem Objekt, das dieser Vorgang berührt. Verfolgen Sie eine Auftragsfreigabe, eine Kreditsperre, eine Lagerkorrektur oder eine Monatsabschlussbuchung durch Masken, Programme, Dateien, Warteschlangen, Druckausgaben und Eingriffe der Operatoren. Dieser Pfad zeigt, was migriert werden muss.

Hinter dem Namen AS/400 steckt eine Betriebsumgebung

Auf der Maschine befindet sich meist ein Netz aus Anwendungen und betrieblichen Konventionen, kein einzelner ERP-förmiger Block. IBM hat die Plattform mehrfach umbenannt, und IBM i läuft heute auf Power-Hardware. Viele Unternehmen verwenden AS/400 trotzdem weiterhin als praktische Bezeichnung für alles hinter einem Green Screen. Diese Kurzform ist harmlos, bis sie zur Migrationsgrenze wird.

Beginnen Sie mit dem Objektmodell. Programme, Datenbankdateien, Bildschirmdateien, Druckerdateien, Befehle, Datenbereiche, Datenwarteschlangen, Jobwarteschlangen, Ausgabewarteschlangen, Benutzerprofile und Berechtigungslisten sind Systemobjekte mit Typen und Berechtigungen. Bibliotheken gruppieren Objekte, während die Bibliotheksliste eines Jobs beeinflusst, welches Objekt ein nicht qualifizierter Name zur Laufzeit auflöst. Zwei Jobs können denselben Programmnamen aufrufen und unterschiedliche Objekte erreichen, weil ihre Bibliothekslisten voneinander abweichen. Eine Suche im Repository zeigt das allein nicht.

Gekaufte Software erschwert das Bild. Ein Anbieterpaket kann den Buchhaltungskern besitzen, während individueller RPG-Code Preisbildung, Zuteilung, regulatorische Prüfungen, Lagerarbeit oder Dateiaustausch übernimmt. CL-Programme können die Umgebung vorbereiten, Dateien überschreiben, Arbeit einreichen und sowohl Anbieterprogramme als auch eigene Programme aufrufen. Operatoren führen Befehle vielleicht in einer genauen Reihenfolge aus Menüs aus, weil ein alter Ausnahmefall nie eine richtige Oberfläche erhalten hat. All das wird nicht Teil des ERP, nur weil Benutzer über dasselbe Menü einsteigen.

Die erste Grenze muss Plattform, Paket, Anpassung und Integration voneinander trennen. Erfassen Sie für jede Komponente, wem sie gehört, wie sie aufgerufen wird und welche Daten oder Nebenwirkungen sie steuert. Diese Unterscheidung verändert die Möglichkeiten. Sie könnten ein Paket ersetzen, eine Datenbank vorübergehend behalten, individuelle Abläufe neu schreiben und ein Übertragungsprotokoll nach jeweils eigenen Zeitplänen stilllegen. Wenn Sie die gesamte Umgebung als ein Produkt behandeln, erzwingen Sie eine riskante Umstellung auf einmal oder entdecken verborgene Abhängigkeiten erst beim Cutover.

Architekturdiagramme lassen betriebliche Objekte oft weg, weil sie nicht wie Quellcode aussehen. Das ist ein Fehler. Eine Jobbeschreibung kann Bibliotheksliste, Ausgabewarteschlange, Protokollierungsstufe und Benutzeridentität für eingereichte Arbeit festlegen. Ein Datenbereich kann ein Verarbeitungsdatum oder einen Sequenzwert enthalten. Eine Nachrichtenwarteschlange kann der einzige Ort sein, an dem ein Operator von einem gestoppten Batch erfährt. Wenn ein Geschäftsprozess ein Objekt braucht, gehört dieses Objekt in die Anwendungskarte.

Db2 for i gehört zum Anwendungsverhalten

Ein Datenbankexport erfasst die Semantik von Db2 for i nicht, weil Programme von mehr als Zeilen und Spalten abhängen. Db2 for i ist in IBM i integriert. Traditionelle Anwendungen verwenden häufig mit DDS erstellte physische und logische Dateien über nativen Datensatzzugriff. Neuerer oder überarbeiteter Code kann dagegen SQL-Tabellen, Sichten, Indizes, Prozeduren und Trigger verwenden. Beide Stile können in derselben Transaktion nebeneinander bestehen.

Die IBM-Dokumentation Database files zieht eine genaue Grenze: Eine physische Datei speichert Anwendungsdaten, während eine logische Datei eine oder mehrere physische Dateien abbildet, ohne eine weitere Kopie der Datensätze zu speichern. Aus SQL-Sicht ähnelt eine physische Datei einer Tabelle. Eine logische Datei kann einer Sicht, einem Index oder beidem ähneln. Der letzte Punkt ist wichtig. Eine logische Datei kann einen schlüsselbasierten Zugriffspfad definieren, Datensätze auswählen oder ausschließen, Felder neu ordnen, physische Dateien verbinden oder ein von einem Programm erwartetes Datensatzformat bereitstellen. Wenn jede logische Datei in eine PostgreSQL-Sicht umgewandelt wird, kann eine Sortier- oder Sucheigenschaft verloren gehen, auf die nativer RPG-Code angewiesen war. Wird jede Datei in einen Index umgewandelt, gehen möglicherweise Auswahl- und Projektionsregeln verloren.

Member verursachen eine weitere Abweichung. Eine physische Datei kann mehrere Member enthalten, also getrennte Datensatzmengen mit demselben Format. Viele Systeme verwenden nur den Standardmember, manche nutzen Member jedoch für Perioden, Niederlassungen, Importe oder Arbeitsmengen. Ein flacher Export, der nur einen Member liest, verliert unbemerkt Daten. Das Zieldesign muss entscheiden, ob aus einem Member eine Partition, eine Mandanten- oder Periodenspalte, eine Staging-Tabelle oder eine überholte Konvention wird. Diese Entscheidung braucht Nutzungsnachweise statt einer pauschalen Zuordnung.

Datensatzformate tragen ebenfalls Datenannahmen. Gepackte Dezimalzahlen, gezonte Dezimalzahlen, Zeichenfelder fester Länge, Leerwerte, Nulldaten, codierte Kennzeichen und extern beschriebene Felder verhalten sich anders als beiläufig gewählte SQL-Typen. Eine zehnstellige Zahl kann eine Kennung sein, mit der nie gerechnet werden darf. Ein Leerwert kann unbekannt bedeuten, während Null ausdrücklich nichts bedeutet. Manche Dateien besitzen keine Datenbankeinschränkung, weil historisch jedes schreibende RPG-Programm die Regel durchgesetzt hat. Die Migration muss diese Regel vor dem Hinzufügen einer Einschränkung im Ziel wiederfinden, sonst scheitern beim Laden zulässige Altdatensätze.

Journaling und Commitment Control müssen getrennt untersucht werden. Die IBM-Dokumentation Commitment control erklärt, dass eine Gruppe von Datenbankänderungen gemeinsam bestätigt oder zurückgenommen werden kann und dass unter Commitment Control verwendete Dateien journalisiert sein müssen. Manche Anwendungspfade verwenden diese Grenzen, andere führen unabhängige native Schreibvorgänge aus und verlassen sich auf Neustartlogik. Eine vollständige Ersatzanfrage in eine Transaktion zu packen, kann Sperrdauer und Fehlerbehebung verändern. Fehlt eine Transaktion, wo der alte Job eine hatte, werden Teiländerungen sichtbar. Reproduzieren Sie zuerst die beobachtete Arbeitseinheit und verbessern Sie sie anschließend bewusst.

Die Datenbankanalyse braucht daher Dateidefinitionen, Member, Zugriffspfade, Einschränkungen, Trigger, Journale, Datensatzmengen, Berechtigungen und echte Zugriffsspuren. Das Schema ist nur der Anfang.

RPG-Quelltext ist nur ein Teil des ausführbaren Graphen

RPG-Programme zeigen Berechnungen, doch zum ausführbaren Graphen gehören auch kompilierte Beschreibungen, Aufrufkonventionen, CL-Vorbereitung, gebundene Prozeduren, Überschreibungen und die Objektauflösung zur Laufzeit. Selbst ein sauberer Quelltextbestand kann den Code verfehlen, der in Produktion tatsächlich läuft.

Die RPG-Dokumentation von IBM unterscheidet programmbeschriebene von extern beschriebenen Dateien. Bei einer extern beschriebenen Datei holt der Compiler Feld- und Datensatzdefinitionen zur Kompilierzeit aus DDS- oder SQL-Definitionen. Dadurch entsteht eine leicht übersehene Abhängigkeit: Eine Änderung am Dateiformat kann die Neukompilierung abhängiger Programme verlangen, obwohl deren Quelltext unverändert blieb. Level Checks können ein inkompatibles Format erkennen. Sie abzuschalten macht die Layouts aber nicht kompatibel, sondern entfernt nur einen Warnmechanismus.

Altes RPG kann den Zyklus, Indikatoren, Datenstrukturen, Unterroutinen, Ausnahmeindikatoren und native Operationen wie CHAIN, SETLL, READE, WRITE, UPDATE und DELETE verwenden. Modernes RPG kann freie Syntax, Prozeduren, Serviceprogramme und eingebettetes SQL nutzen. Keine Syntax verrät die geschäftliche Bedeutung eines Programms. Ein CL-Wrapper mit dreißig Zeilen, der eine Bibliotheksliste setzt und eine Datenbankdatei überschreibt, kann die Bedeutung eines RPG-Programms mit zehntausend Zeilen verändern.

Die Laufzeitbindung verdient eine eigene Karte. Erfassen Sie jede beobachtbare Aufrufkante, darunter dynamische, aus Daten zusammengesetzte Programmnamen, Menübefehle, Exitprogramme, Trigger und entfernte Aufrufe. Halten Sie Parameter nach Position, Typ, Länge und Änderungsverhalten fest. IBM i-Programme übergeben Parameter häufig als Referenz, sodass ein aufgerufenes Programm Statusinformationen durch Änderung eines Eingabefelds zurückgeben kann. Eine Ersatz-API, die nur den sichtbaren Rückgabewert modelliert, kann Fehlerdetails oder Fortsetzungszustand verwerfen.

Dateiüberschreibungen verursachen häufig Migrationsfehler. Ein OVRDBF-Befehl kann den Dateinamen eines Programms auf eine andere Datei oder einen anderen Member umleiten, ohne den RPG-Quelltext zu ändern. Dieser Mechanismus unterstützt Testdaten, alternative Unternehmen, Archivmember und temporäre Arbeit. Wenn die Analyse nur F-Spezifikationen und SQL-Anweisungen liest, erfasst sie das erklärte Ziel statt des zur Laufzeit geöffneten Objekts. Erfassen Sie Überschreibungen aus CL und aktiven Jobs und verknüpfen Sie sie anschließend mit den Transaktionen, die sie verwenden.

Gehen Sie bei Bibliothekslisten und Berechtigungen ebenso vor. Ein Programm kann unter dem Profil des Aufrufers laufen, die Berechtigung seines Eigentümers übernehmen oder von einer Berechtigungsliste abhängen. Der Zieldienst braucht ein ausdrückliches Identitäts- und Berechtigungsmodell. Breite IBM i-Rechte in ein einziges Datenbankkonto zu kopieren kann den ersten Test bestehen lassen, entfernt aber die Trennung, von der die Produktion still abhängig war.

Ein Rewrite ist sicher, wenn jeder Produktionseinstieg einen nachverfolgten Pfad durch diesen Graphen besitzt. Quelltextübersetzung ohne diesen Graphen erzeugt überzeugenden Code, der das falsche Objekt aufruft.

Bildschirmdateien enthalten Geschäftsentscheidungen

Eine Bildschirmdatei beschreibt ausführbares Oberflächenverhalten und nicht nur das Aussehen einer Maske. DDS-Bildschirmdateien definieren Datensatzformate, Felder, Konstanten, Funktionstasten, Subfiles, Attribute, Validierungsschlüsselwörter und Indikatoren, die steuern, was ein Benutzer sehen oder eingeben kann. RPG und Bildschirmdatei teilen sich die Verantwortung für die Interaktion. Wer nur die RPG-Hälfte migriert, verändert den Ablauf.

Betrachten Sie eine Maske zur Auftragsfreigabe. RPG kann den Auftrag laden und Indikator 31 setzen, wenn ein Kunde eine Kreditgrenze überschreitet. Die Bildschirmdatei kann über diesen Indikator eine Warnung anzeigen, ein Betragsfeld schützen, einen Status farblich markieren oder eine Funktionstaste freischalten. Ein anderer Indikator kann eine ungültige Eingabe markieren und den Cursor auf das fehlerhafte Feld setzen. Der RPG-Quelltext zeigt die Änderung des Indikators, DDS erklärt deren Bedeutung für den Operator. Ohne beide Teile kann eine neue Webmaske eine Änderung erlauben, die die alte Maske blockierte.

Subfiles bringen zustandsbehaftetes Verhalten hinzu. Ein Programm kann eine Seite laden, eine relative Datensatznummer halten, geänderte Zeilen markieren und nur Datensätze verarbeiten, deren Auswahlfeld sich geändert hat. Funktionstasten können je nach Datensatzformat verschiedene Bedeutungen besitzen. Fehlermeldungen können aus Nachrichtendateien statt aus Textliteralen stammen. Feldreferenzdateien können Längen und Validierungsregeln für viele Masken liefern. Ein Screenshot hält das Aussehen eines Zustands fest, nicht die Regeln zwischen den Zuständen.

Die DDS-Regeln von IBM sagen, dass Optionsindikatoren oder Bedingungsnamen ein Schlüsselwort, ein Feld oder eine Feldposition bedingen können. Dieser kurze Satz erklärt, warum automatisierte Bildschirmkonvertierung oft enttäuscht. Die Oberflächenlogik liegt verteilt in RPG-Zustand und DDS-Bedingungen. Ein Bildschirmparser muss ein Zustandsmodell erzeugen, kein statisches Formular.

Gehen Sie den Fehlerpfad durch, nicht nur den Erfolgsfall. Geben Sie einen geschlossenen Kunden, ein ungültiges Lager, eine Menge über dem Bestand und eine Funktionstaste während einer teilweise abgeschlossenen Aktualisierung ein. Erfassen Sie angezeigte Nachricht, Cursorposition, geschützte Felder, Datenbanklesevorgänge, Schreibvorgänge, Sperren und die nächste Maske. Wiederholen Sie den Test dann mit zwei Sitzungen, die denselben Datensatz bearbeiten. Operatoren verlassen sich oft auf das genaue Wiederherstellungsverhalten, auch wenn es niemand als Anforderung bezeichnet.

Der Ersatz muss einen Green Screen nicht Pixel für Pixel nachbilden. Er soll Entscheidungen und Kontrollen bewahren und sie anschließend in einem verständlichen Clientdesign ausdrücken. Trennen Sie Feldvalidierung von Domänenregeln. Erhalten Sie Tastaturwege, wenn der Durchsatz davon abhängt. Ersetzen Sie kryptische Indikatoren durch benannte Zustände. Eine hübschere Maske, die die Freigabegrenze schwächt, ist eine Regression.

Batchjobs und Druckausgaben sind Produktionsschnittstellen

Interaktive Masken zeigen bei vielen IBM i-Systemen nur den Rand des Tagesbetriebs. Batchjobs, Warteschlangen, Scheduler, Spooldateien, Übertragungen und Operatormeldungen erledigen oft Abrechnung, Nachschub, Fakturierung, Berichte und Partneraustausch, nachdem die Benutzer gegangen sind. Diese Schnittstellen brauchen dieselbe Migrationsdisziplin wie eine API.

Die IBM-Dokumentation zur Arbeitsverwaltung beschreibt, wie eingereichte Jobs in Jobwarteschlangen warten und in Subsystemen mit zugewiesenen Ressourcen und Verarbeitungsanweisungen laufen. Eine Jobbeschreibung kann Routing und Ausgabe steuern. Deshalb hängt das Verhalten eines Batchprogramms von seinem Startkontext ab. Derselbe interaktive Aufruf kann im Test eine andere Bibliotheksliste, ein anderes Benutzerprofil, eine andere Nachrichtenbehandlung, ein anderes Datum oder eine andere Ausgabewarteschlange verwenden. Der Test besteht, während der geplante Job weiterhin fehlschlägt.

Inventarisieren Sie jeden Scheduler, eingereichten Job, jedes Subsystem, jede Jobwarteschlange, Jobbeschreibung, Routingeintragung, Ausgabewarteschlange und überwachte Nachrichtenwarteschlange im geschäftlichen Umfang. Beziehen Sie externe Scheduler und Skripte ein, die sich über FTP, SFTP, Datenbankprotokolle oder Befehlsschnittstellen verbinden. Erfassen Sie Kalender, Abhängigkeiten, Wiederholungsregeln, Nebenläufigkeitsgrenzen, erwartete Laufzeitbereiche und die Person oder das System, das auf Fehler reagiert. Leiten Sie einen Zeitplan nicht aus Kommentaren im Quelltext ab. Beobachten Sie ihn.

Spoolausgaben verdienen besondere Aufmerksamkeit. Eine Druckerdatei kann Überschriften, Summen, Überlaufverhalten, Seitenumbrüche, Kopien und Routing festlegen. Der physische Drucker kann längst verschwunden sein, während ein anderer Prozess den Spool weiterhin als Dokument- oder Archivquelle nutzt. Fragen Sie, wer jede Ausgabe erhält, was damit geschieht und welcher Nachweis die Zustellung belegt. Einen Bericht durch eine Webseite zu ersetzen ist nicht gleichwertig, wenn ein Lager einen Etikettenstrom oder eine Bank eine Datei mit festem Datensatzformat erwartet.

Auch das Neustartverhalten von Batches ist ein verborgener Vertrag. Ein Job kann eine Arbeitsdatei leeren, Datensätze in Schlüsselreihenfolge verarbeiten, mit einem Datenbereich einen Prüfpunkt setzen und sich nach einer behebbaren Meldung erneut einreichen. Ein anderer Job lässt sich absichtlich sicher wiederholen, weil er ein Verbucht-Kennzeichen prüft. Wenn der Ersatz eine Warteschlange mit mindestens einmaliger Zustellung verwendet, müssen Sie wissen, welche Operationen idempotent sind und welche einen stabilen Geschäftsschlüssel brauchen. Eine doppelte Rechnung ist kein Infrastrukturdetail.

Behandeln Sie Zeit als Eingabe. Verarbeitungsdaten, Geschäftsjahre, Sommerzeitwechsel, Feiertagskalender und Tagesabschlusswechsel können aus Datenbereichen oder Steuerdateien statt von der Systemuhr stammen. Ein Cloud-Scheduler mit der richtigen Uhrzeit kann trotzdem das falsche Geschäftsdatum erzeugen.

Die Analyse muss eine Verhaltenskarte erzeugen

Eine brauchbare Analysephase erzeugt eine abfragbare Verhaltenskarte, die Einstiegspunkte, Objekte, Daten, Nebenwirkungen und Operatoren verbindet. Eine Tabelle mit Programmnamen und Zeilenzahlen kann nicht beantworten, ob eine Kreditfreigabe einen Druck, eine Warteschlangennachricht und eine zweite Aktualisierung durch ein aufgerufenes Programm auslöst.

Beginnen Sie mit Systeminventaren und gleichen Sie diese anschließend mit Quelltext und Laufzeitnachweisen ab. Die folgenden IBM i-Befehle erzeugen Outfile-Daten, die sich abfragen lassen, statt sie aus Terminalmasken abzuschreiben:

DSPOBJD OBJ(APP/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/OBJECTS)
DSPPGMREF PGM(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/PGMREF)
DSPFD FILE(APP/*ALL) TYPE(*ATR) OUTPUT(*OUTFILE) FILEATR(*PF *LF) OUTFILE(AUDIT/FILEATTR)
DSPFFD FILE(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/FIELDS)

Diese Befehle sind ein erstes Artefakt, kein vollständiger Scanner. Führen Sie entsprechende Inventuren über alle relevanten Bibliotheken aus, bewahren Sie qualifizierte Objektnamen und halten Sie fest, wo die Befehle getrennte Auswahlen verlangen. Ergänzen Sie Listen der Quelltextmember, SQL-Katalogdaten, Jobzeitpläne, Warteschlangenkonfiguration, Berechtigungen, Trigger, Einschränkungen, Journale und Pfade im Integrated File System. Ein Outfile mit Programmreferenzen meldet statische Referenzen, die dem Programmobjekt bekannt sind. Dynamische Aufrufe und Laufzeitüberschreibungen brauchen weiterhin Traces und eine CL-Analyse.

Speichern Sie für jeden Geschäftsvorgang mindestens Einstiegspunkt, aufrufende Identität, Bibliotheksliste, erreichte Programme und Serviceprogramme, geöffnete Dateien und Member, verwendete Datensatzformate, gesendete Nachrichten, eingereichte Jobs, erzeugte Spooldateien, aufgerufene externe Endpunkte und das endgültige Geschäftsergebnis. Hängen Sie jeder Kante Vertrauensgrad und Nachweis an. Eine Quelltextreferenz, eine Objektbeschreibung und ein Produktionstrace besitzen nicht dasselbe Gewicht. Widersprüche zwischen ihnen sind Befunde und kein Rauschen.

Die Analyse von ungenutztem Code muss Laufzeitnachweisen folgen. Daten der letzten Änderung sind bei stabilen Systemen schwache Signale, und Daten der letzten Nutzung können fehlen oder zurückgesetzt worden sein. Ein Programm, das seit fünfzehn Jahren unverändert ist, kann jede Nacht laufen. Umgekehrt kann ein kürzlich kompiliertes Objekt nie einen Produktionsaufruf erhalten. Isolieren Sie vermutlich tote Pfade, beobachten Sie einen repräsentativen Geschäftszyklus und lassen Sie einen Verantwortlichen die Stilllegung genehmigen.

Die unbequeme Frage lautet, wie viel Analyse ausreicht. Es reicht, wenn das Team eine Transaktion auswählen und deren Lesevorgänge, Schreibvorgänge, Ausgaben, Fehlersignale, Identität und Wiederherstellungspfad vorhersagen und diese Vorhersage anschließend mit Produktionsnachweisen bestätigen kann. Unbekannte dynamische Kanten müssen ausdrücklich benannt und getestet werden. Ein großes Inventar mit ungeklärten Einstiegspunkten ist nicht vollständig.

Parität vergleicht Ergebnisse und Nebenwirkungen

Paritätstests müssen beobachtbares Geschäftsverhalten vergleichen, nicht nur ähnliche Rückgabewerte übersetzter Funktionen. Zum Vertrag des alten Systems gehören Datenbankänderungen, Reihenfolge, Nachrichten, Dokumente, eingereichte Jobs, externe Aufrufe, Sperren und Fehlerbehebung. Ein Test, der nur die letzte Zeile prüft, kann einen Ersatz freigeben, der zwei Rechnungen verschickt.

Bauen Sie eine Testvorrichtung um aufgezeichnete und bereinigte Produktionstransaktionen. Erfassen Sie den Eingabekontext, der für die Wiederholung jedes Falls nötig ist: Benutzer oder Rolle, Bibliotheks- oder Unternehmenskontext, Geschäftsdatum, relevante Startdatensätze, Masken- oder Anfragefelder und abhängige Antworten. Führen Sie alte und neue Pfade mit isolierten Daten aus, normalisieren Sie unwichtige Unterschiede und vergleichen Sie das gesamte Ergebnis. Halten Sie den ursprünglichen Trace unveränderlich, damit ein verändertes Testobjekt nicht beide Systeme aus dem falschen Grund übereinstimmen lässt.

Ein Vergleichsdatensatz kann einfach bleiben:

{"case_id":"credit-release-017","result":"held","writes":[{"entity":"order","key":"48152","fields":{"status":"H"}}],"messages":["CREDIT LIMIT EXCEEDED"],"jobs_submitted":[],"documents":[]}

Die Kennungen dienen nur als Beispiel, doch die Struktur zwingt das Team, mehr als einen Statuscode zu vergleichen. Ergänzen Sie geordnete Lesevorgänge, wenn die Zugriffsreihenfolge das Ergebnis beeinflusst, Zeitstempel mit erklärten Toleranzen und Hashwerte für große Dokumente. Vergleichen Sie bei erzeugten Berichten zunächst geparste Felder und Summen, bevor Sie Bytegleichheit verlangen. Bei Finanzauszügen oder festen Partnerformaten kann Bytegleichheit der Vertrag sein.

Nehmen Sie Grenz- und Nebenläufigkeitsfälle aus echten Regeln auf: Leerwerte gegenüber Null, höchste gepackte Werte, doppelte Einreichungen, Datensatzsperren, Teilfehler, abgebrochene Masken, Neustart nach einem Jobende und zwei Benutzer, die dasselbe Objekt bearbeiten. Wiederholen Sie Fälle, in denen Operatoren eine ungewöhnliche Funktionstaste wählten oder ein Feld nach einem Fehler korrigierten. Diese Pfade legen Regeln offen, die normale Erfolgsmuster verfehlen.

Lassen Sie die neue Implementierung nicht das Orakel definieren. Produktverantwortliche können beabsichtigte Änderungen genehmigen, aber jede Abweichung braucht eine benannte Entscheidung und ein erwartetes Ergebnis. Andernfalls wird Modernisierung zur Ausrede für unbemerkte semantische Verschiebung. Die Paritätssuite sollte den Cutover überdauern und als Regressionstests für spätere Releases dienen.

Das Ziel soll Regeln sichtbar machen statt die Maschine zu kopieren

Eine gute Zielarchitektur erhält Verhalten und verschiebt Regeln zugleich in Komponenten, die Menschen verstehen und betreiben können. Sie baut Bibliotheken, Indikatoren und Dateiüberschreibungen nicht unter neuen Namen nach. Transliteration bewahrt genau die Abhängigkeiten, die Änderungen am alten System erschwert haben.

Ordnen Sie das Ziel nach Geschäftsfunktionen und den aus Nachweisen ermittelten Transaktionsgrenzen. Go-Dienste können transaktionale Abläufe und externe APIs besitzen. TypeScript-Clients können Maskenzustand ohne numerische Indikatoren ausdrücken. PostgreSQL kann relationale Einschränkungen durchsetzen und ausdrückliche Schemas, Sichten und Indizes bereitstellen. Rust eignet sich für numerische Kerne, wenn Messungen oder fachliche Anforderungen es rechtfertigen, nicht als Standardersatz für jede Berechnung. Das sind Designentscheidungen und keine mechanische Sprachzuordnung.

Ordnen Sie jedes IBM i-Konstrukt nach seiner Bedeutung zu. Eine physische Datei kann zu einer Tabelle werden, doch die Nutzung mehrerer Member braucht ein bewusstes Modell. Eine logische Datei kann zu einem Index plus Sicht oder zu einer Abfrage in einem Dienst werden. Eine Datenwarteschlange kann je nach Zustellvertrag zu einem Broker-Topic, einer Datenbank-Outbox oder einem direkten Aufruf werden. Ein Datenbereich kann Konfiguration, dauerhafter Zustand oder Sequenz werden. Eine Bedingung aus einer Bildschirmdatei kann zu einer Clientregel oder einer serverseitigen Berechtigungsprüfung werden. Legen Sie Sicherheitsentscheidungen auf den Server, auch wenn die alte Maske an ihrer Durchsetzung beteiligt war.

Schneiden Sie entlang von Grenzen, die die Verhaltenskarte prüfen kann. Eine übliche Reihenfolge verschiebt zuerst reine Abfragen, dann begrenzte Aktualisierungen und anschließend Batch- und externe Schnittstellen, während eine Routingschicht entscheidet, welche Implementierung eine Transaktion bearbeitet. Die richtige Reihenfolge hängt von Kopplung und Betriebsrisiko ab. Vermeiden Sie doppeltes Schreiben, wenn Sie Reihenfolge, Deduplizierung und Wiederherstellung nicht nachweisen können. Change Data Capture oder ein einzelner maßgeblicher Schreiber lässt sich meist leichter begründen.

CodeHero liest den gesamten RPG- und CL-Baum gemeinsam, schreibt das System in Go, Rust, TypeScript und PostgreSQL neu und prüft das Verhalten mit einer Paritätsvorrichtung gegen aufgezeichneten Produktionsverkehr. Dieser Ansatz hilft nur, wenn der Eingabeumfang die hier beschriebenen Dateien, Bildschirmdefinitionen und Betriebswege enthält. Ein Agent kann kein Objekt erhalten, das niemand erfasst hat.

Trennen Sie Modernisierungsentscheidungen von Paritätsentscheidungen. Beschreiben Sie zuerst das alte Verhalten mit Nachweisen. Genehmigen Sie dann eine geänderte Regel, ein Datenmodell oder einen Benutzerablauf und codieren Sie die neue Erwartung. Durch diese Trennung kann Engineering bei der Prüfung jede Abweichung erklären und sie zurücknehmen, ohne raten zu müssen, welche Unterschiede versehentlich entstanden.

Der Ausstiegstest gehört dem Betrieb

Die Migration ist abgeschlossen, wenn das Unternehmen den Ersatz betreiben, wiederherstellen, prüfen und ändern kann, ohne von IBM i abzuhängen. Funktionstests sind notwendig, doch Operatoren verantworten den Ausstiegstest, weil sie mit den Zuständen umgehen, die Anwendungsdemos vermeiden.

Bereiten Sie den Cutover als kontrollierten Zustandswechsel vor. Legen Sie den letzten maßgeblichen Schreibvorgang auf IBM i, die letzte Erfassung oder Ladung, Abstimmungsabfragen, Regeln zum Leeren von Warteschlangen, Dokumentbehandlung, Zugangsdatenänderungen, Routingwechsel und einen Entscheidungspunkt für den Rollback fest. Benennen Sie die Person, die den Cutover stoppen kann, und die Nachweise, die sie dafür verwendet. Wenn ein Rollback Schreibvorgänge aus zwei Systemen zusammenführen müsste, lösen Sie dieses Design vor dem Ereignis, statt ein hoffnungsvolles Runbook zu schreiben.

Stimmen Sie Geschäftsregeln ab und nicht nur Tabellenzahlen. Aufträge nach Status, offene Salden, Bestand nach Standort, nicht verbuchte Batches, Sequenzfortführung, wartende Nachrichten und Dokumentsummen decken unterschiedliche Fehler auf. Bewahren Sie Quellkennungen, damit das Team einen Zieldatensatz zu seinem Ursprung zurückverfolgen kann. Archivieren Sie Quelldefinitionen, Objektinventare, verfügbare Compilerlisten, nach Richtlinie erforderliche Journale oder Extrakte und die Paritätsnachweise für die Abnahme.

Üben Sie die Wiederherstellung vor der Abschaltung. Beenden Sie einen Worker während einer Aktualisierung mehrerer Datensätze. Halten Sie eine externe Antwort zurück. Duplizieren Sie eine Nachricht. Füllen Sie eine Warteschlange. Stellen Sie eine Datenbanksicherung wieder her und spielen Sie die fehlende Arbeit nach. Bestätigen Sie, dass Alarme eine Person mit genügend Kontext zum Handeln erreichen. IBM i kann manche Wiederherstellungsabläufe durch Journale, Jobprotokolle und Warteschlangen zur Routine gemacht haben. Der Ersatz muss jede Verantwortung ausdrücklich zuweisen.

Die Sicherheit braucht denselben Nachweis. Vergleichen Sie den effektiven Zugriff nach Geschäftsrolle, einschließlich übernommener Berechtigungen und Identitäten geplanter Jobs. Entfernen Sie vorübergehende Migrationszugänge, breite Datenbankrechte, Übertragungskonten und Firewallausnahmen. Dokumentieren Sie für regulierte Umgebungen, wo Daten und Modelle laufen, wer sie verwalten kann und welche Protokolle vorhanden sind. Die Unterstützung einer kontrollierten Umgebung erzeugt keine Zertifizierung.

Lassen Sie das alte System schließlich nur so lange in einem definierten schreibgeschützten oder wiederherstellbaren Zustand verfügbar, wie ein genehmigter Bedarf besteht. Weisen Sie Eigentümer, Kosten, Zugriffsrichtlinie und eine Bedingung für Löschung oder Archivierung zu. Eine unbefristete Rückfalllösung wird zum zweiten Produktionssystem, das niemand testet. Die ehrliche Ziellinie ist der erste normale Betriebstag, an dem sich ein fehlgeschlagener Job, eine strittige Summe und eine neue Regel bearbeiten lassen, ohne die letzte Person anzurufen, die sich an Indikator 31 erinnert.