Migration von RPG im Festformat und die Free-Format-Grenze

RPG im Festformat und RPG im Free-Format können auf derselben IBM i-Partition kompiliert werden, dieselben physischen Dateien verwenden und dieselben Fachbegriffe enthalten. Trotzdem sind es unterschiedliche Migrationsaufgaben. Wer den Unterschied als reine Formatfrage behandelt, erhält eine ordentlich wirkende Schätzung, die zusammenbricht, sobald das Team auf Indikatoren, Eingabespezifikationen oder ein Programm trifft, dessen Kontrollfluss teilweise im vom Compiler erzeugten Zyklus steckt.

Eine belastbare Schätzung beginnt mit der Frage, wo das Verhalten codiert ist. In einem prozeduralen Free-Format-Programm steht ein großer Teil davon in Anweisungen, denen ein moderner Entwickler folgen kann. In altem Festformat-Code können Spalten, die Reihenfolge der Spezifikationen, satzidentifizierende Indikatoren, Gruppenwechsel und Ausgabebedingungen Bedeutung tragen. Die Migration muss diese Bedeutung zurückgewinnen, bevor jemand den Umbau sinnvoll bepreisen kann.

Spalten sind Teil des Programms

Bei RPG im Festformat ist die horizontale Position Syntax. Ein Migrationstool darf Leerraum daher erst normalisieren, wenn es den Quelltext verstanden hat. Laut IBM ILE RPG Reference steht der Spezifikationstyp bei spaltenbegrenztem Quelltext an Position 6: H für Steuerung, F für Dateien, D für Definitionen, I für Eingabe, C für Berechnungen, O für Ausgabe und P für Prozeduren. Auch andere Felder belegen vorgeschriebene Positionen. Ein Zeichen in der falschen Spalte kann eine Operation, eine Indikatorbedingung oder sogar die Frage verändern, ob der Compiler die Zeile überhaupt liest.

Das verändert die Aufnahme der Quellen. Ein Parser muss ursprüngliche Satzbreite, Sequenzfelder, Tabulatoren, CCSID des Quellmembers und Grenzen von Copy-Membern erhalten. Wird ein Quellmember über einen Weg exportiert, der Tabulatoren auflöst oder nachgestellte Leerzeichen abschneidet, können Belege schon vor der Analyse verloren gehen. Der rohe Quellsatz ist das Artefakt; eine Anzeigeversion wird daraus abgeleitet, niemals umgekehrt.

Eine brauchbare Eingangsprüfung protokolliert sowohl die Rohzeile als auch ein Spaltenlineal. Die folgende Ausgabe sollte ein Inventarbericht zum Beispiel sichtbar machen, selbst wenn die eigentliche Extraktion auf IBM i läuft:

member=ORDRPT line=184 bytes=80 spec=C cond_1=03 cond_2=N04 opcode=EXCPT
000001  C   03N04             EXCPT    ORDTOTAL
         1         2         3         4         5         6         7         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890

Es geht nicht um das Format des Berichts. Entscheidend ist, dass 03, N04, EXCPT und ORDTOTAL als getrennte Felder mit ihren ursprünglichen Positionen erfasst werden. Ein allgemeiner Textparser sieht Tokens. Ein RPG-spezifischer Parser erkennt eine Berechnung, die ausgeführt wird, wenn ein Indikator ein- und ein anderer ausgeschaltet ist, gefolgt von einer Ausnahmeausgabe, deren Definition viel weiter unten im Member stehen kann.

RPG im Free-Format entfernt den größten Teil dieser Positionsabhängigkeit. Bei vollständig freiem Quelltext steht **FREE in Spalte 1 der ersten Zeile, und die übrigen Anweisungen können über den alten spaltenbegrenzten Bereich hinausgehen. Anweisungen wie ctl-opt, dcl-f, dcl-s und dcl-proc benennen ihre Rolle durch Schlüsselwörter und enden mit Semikolon. Das lässt sich leichter parsen, beweist aber weder einen prozeduralen Aufbau noch die Abwesenheit alter Konstrukte. Die Syntax ist die erste Klassifikation, nicht die letzte.

Indikatoren bilden ein verborgenes Kontrollflussnetz

Nummerierte Indikatoren verdichten Zustand, Bedingungen und Nebenwirkungen auf zwei Zeichen. Eine feste Berechnung kann Indikatoren in ihren Bedingungsspalten prüfen und in anderen Spalten Ergebnisindikatoren für größer, kleiner oder gleich setzen. Eingabespezifikationen können Indikatoren für Satzidentifikation, Steuerungsebenen und Felder setzen. Dateioperationen können Fehler- oder Dateiendeindikatoren setzen. Ausgabespezifikationen können anhand dieser Zustände entscheiden, ob ein Satz oder eine Druckzeile ausgegeben wird.

Darum ist das Ersetzen von *IN03 durch ein Boolean namens indicator03 eine Transliteration und keine Modernisierung. Der Name erhält den Speicherplatz und verliert den Zweck. Die Migration muss einen Use-Def-Graphen aufbauen: jede Stelle, die den Indikator setzen kann, jede von ihm abhängige Operation, jedes Zurücksetzen und jede Grenze, über die er aktiv bleibt. Erst dann kann das Team entscheiden, ob er customerChanged, writeTotals, recordFound, validationFailed oder mehrere zeitlich getrennte Dinge bedeutet.

Die Wiederverwendung von Indikatoren ist der unangenehme Fall, den Zeilenzahlen verbergen. Ein Indikator kann in Detailberechnungen eine Bedeutung haben, gelöscht werden und später in einer Unterroutine etwas völlig anderes bedeuten. Eine globale Suche findet zwei Gruppen, kann ihre Unabhängigkeit aber nicht beweisen. Die Analyse muss Aufrufreihenfolge, Zyklusphase und Auswirkungen von Dateioperationen einbeziehen. Überschreitet ein Wert eine EXSR-Grenze oder bleibt bis zu Summenberechnungen erhalten, kann eine beiläufige Umbenennung Zustände verschmelzen, die das Original zeitlich getrennt hielt.

IBM dokumentiert *IN als Array der nummerierten Indikatoren und warnt, dass andere Werte als null, eins, *OFF oder *ON spätere Prüfungen unvorhersehbar machen. Das ist bei der Konvertierung relevant, weil einige Programme Abschnitte des Indikatorarrays als Daten bearbeiten. Ein modernes Ziel sollte kein magisches Boolean-Array mit 99 Elementen nachbauen, außer Kompatibilität verlangt dies an einer Grenze. Es sollte Array-Schreibvorgänge entschlüsseln, beabsichtigte Zustände benennen und mehrdeutiges Verhalten mit Tests festhalten, bevor die alte Darstellung verschwindet.

Das praktische Artefakt ist ein Indikatorverzeichnis und keine bloße Zahl:

| Indikator | Gesetzt durch | Gelesen durch | Zyklusphase | Mögliche Bedeutung | Sicherheit | | | | | | | | | 03 | Satztyp in I-Spec | bedingte C-Spec | Detail | Auftragssatz gewählt | hoch | | 04 | CHAIN-Ergebnis | EXCPT-Bedingung | Detail | Kunde fehlt | mittel | | L1 | Wechsel im Steuerfeld | Summenberechnungen | Summe | Kontenwechsel | hoch | | LR | Dateiende der Primärdatei | Summen und Abschluss | letzter Zyklus | Finalisierung | hoch |

Dieses Verzeichnis gibt Prüfern etwas Widerlegbares. Es zeigt auch, wo die Schätzung noch Untersuchung braucht. Zehn sauber benannte Indikatoren mit je einem Zweck können günstiger sein als drei, deren Bedeutung sich mit der Zyklusphase ändert.

Der RPG-Zyklus steuert unsichtbaren Kontrollfluss

Ein zyklusgesteuertes Programm überlässt die Reihenfolge einer vom Compiler erzeugten Logik. Deshalb zeigt das Lesen der Berechnungsspezifikationen von oben nach unten nicht die tatsächliche Laufzeitreihenfolge. Die IBM-Dokumentation zur Zyklusprogrammierung beschreibt eine wiederholte Folge: Satz lesen, Satz- und Steuerungsebenenindikatoren setzen, Summenarbeit für eine Grenze ausführen, Summenausgabe erstellen, die Letztsatzbedingung prüfen, Eingabefelder übertragen und dann Detailberechnungen ausführen. Der erste und der letzte Durchlauf verhalten sich jeweils besonders.

Diese Reihenfolge überrascht Entwickler, die eine explizite Schleife erwarten. Summen für die gerade abgeschlossene Gruppe können laufen, nachdem der nächste Satz weit genug gelesen wurde, um einen Gruppenwechsel festzustellen, aber bevor seine Eingabefelder zu den aktuellen Detaildaten werden. Kopf- oder Detailausgaben können ebenfalls zu zyklusdefinierten Zeitpunkten erfolgen. Ein Umbau, der read() an den Anfang einer üblichen Schleife und Summen an ihr Ende setzt, kann vernünftig, lesbar und falsch sein.

Primär- und Sekundärdateien bringen weiteres implizites Verhalten mit. Das Programm führt möglicherweise nie den Lesevorgang aus, der eine Primärdatei weiterschaltet, weil der Zyklus dies übernimmt. Logik für übereinstimmende Sätze, Steuerfelder, Eingabesätze und Ausgabespezifikationen wirken über Compilerregeln zusammen. Der Indikator LR kann nach dem letzten Primär- oder Sekundärsatz implizit eintreten. IBM weist darauf hin, dass das Setzen von LR auch die Steuerungsebenenindikatoren für die abschließende Summenverarbeitung einschaltet. Das ist Ausführungssemantik und kein altertümliches Ende-Flag.

Eine sichere Konvertierung macht die verborgene Zustandsmaschine explizit, bevor sie deren Architektur ändert. Sie stellt Phasen wie Initialisierung, Eingabeauswahl, Erkennung von Gruppenwechseln, Summen der vorherigen Gruppe, Detailverarbeitung und Abschlusssummen dar. Für jede Phase wird festgehalten, welche Felder den vorherigen Satz, den neu gewählten Satz und die aktuellen Verarbeitungsdaten enthalten. Danach wird das prozedurale Ziel gegen dieses Modell geschrieben.

Eine minimale Verhaltensspur kann so aussehen:

seq=411 phase=read       account=170 record=invoice
seq=412 phase=break      level=L1 old_account=160 new_account=170
seq=413 phase=total      account=160 amount=9284.15 output=ACCT_TOTAL
seq=414 phase=detail     account=170 invoice=88412 amount=73.20
seq=415 phase=final      lr=on output=REPORT_TOTAL

Kann das Altsystem eine solche Spur nicht sicher ausgeben, werden die erwarteten Ereignisse aus aufgezeichneten Eingaben und beobachtbaren Ausgaben abgeleitet. Entscheidend ist die Reihenfolge. Übereinstimmende Endsummen reichen nicht, wenn das Ziel einen Folgesatz schreibt, einen Saldo aktualisiert oder ein anderes Programm in der falschen Phase aufruft.

Free-Format bedeutet nicht immer dasselbe

RPG im Free-Format umfasst mehrere Stile, und nur einige verhalten sich wie gewöhnlicher prozeduraler Code. Ein Member kann freie Berechnungen zwischen /FREE und /END-FREE enthalten, aber feste F-, I- oder O-Spezifikationen behalten. Ein neuerer Member kann freie Deklarationen verwenden und trotzdem auf eine Cycle-Main-Prozedur bauen. Ein vollständig freies Modul kann ctl-opt nomain, Prozeduren, explizite Lesevorgänge, qualifizierte Datenstrukturen und Prototypen nutzen. Alle drei pauschal „Free-Format“ zu nennen, zerstört das nützlichste Signal für die Schätzung.

Die IBM-Dokumentation zieht klare technische Grenzen. Vollständig freier Quelltext verwendet **FREE in der ersten Zeile. Feste Anweisungen, die dieser Quelltext noch benötigt, etwa alte Ein- oder Ausgabespezifikationen, müssen in einem Copy-File liegen. Die RPG-IV-Spezifikationsregeln sagen außerdem, dass MAIN oder NOMAIN eine Cycle-Main-Prozedur verhindert, während ein Modul ohne diese Schlüsselwörter weiterhin eine enthalten kann. **FREE allein beantwortet daher nicht, ob der Zyklus existiert.

Ich klassifiziere Member nach unabhängigen Achsen:

• Quellmodus: fest, spaltenbegrenzt gemischt oder vollständig frei
• Ausführungsmodell: Cycle-Main, lineares Hauptprogramm oder Prozeduren mit MAIN/NOMAIN
• Datenzugriff: zyklusgesteuerte Dateien, explizite native E/A, eingebettetes SQL oder eine Mischung
• Zustandsmodell: nummerierte Indikatoren, benannte Indikatoren, explizite Variablen oder gemischt
• externe Form: Programmaufrufe und Datenbereiche, Serviceprozeduren, Queues, Dateien oder Jobbefehle

Diese Klassifikation verhindert einen typischen Schätzfehler. Zwei vollständig freie Member können grundverschieden sein, wenn einer eine schlanke Prozedur mit explizitem SQL ist und der andere alte O-Specs über /COPY einbindet, nummerierte Indikatoren schaltet und über *INLR endet. Umgekehrt kann ein Festformat-Member mechanisch regelmäßig und mit wiederholbaren Regeln gut abgedeckt sein. Das Format beeinflusst die Schwierigkeit, aber das Verhalten entscheidet sie.

Auch die Compilerstufe zählt. Die Syntax eines Quellmembers zeigt seine Nutzung, aber nicht alle Compiler- oder Laufzeitbedingungen in Produktion. Erfasst werden müssen Zielreleases, Aktivierungsgruppen, Binding Directories, extern beschriebene Dateien, Copybooks, Serviceprogramme und Compile-Befehle. Ein Umbauplan ohne Build-Graph entdeckt später „fehlenden Code“, der beim Kompilieren tatsächlich eingefügt oder aufgelöst wurde.

Modernisierung beginnt mit einem Verhaltensmodell

Das Ziel sollte die fachliche Absicht ausdrücken und Kompatibilität an benannten Grenzen halten. Bei einem Zyklusbericht bedeutet das oft einen Reader für typisierte Sätze, eine Komponente zur Erkennung von Gruppenwechseln, eine Berechnung für Details und Summen sowie einen Ausgabeadapter, der die erforderlichen externen Sätze reproduziert. Bei einem interaktiven Programm kann es heißen, Anzeigezustand, Validierung, Dateizugriff und Befehlsaufrufe zu trennen. Die Form folgt dem Verhalten, nicht den Spezifikationsbuchstaben.

Jede C-Spec in eine Anweisung und jeden Indikator in ein Boolean umzuwandeln und das Ergebnis dann Go oder TypeScript zu nennen, reicht nicht. Der Ansatz ist beliebt, weil er messbar ist: Jede Quellzeile erhält eine Zielzeile, automatisierte Diff-Berichte wirken geschäftig und Prüfer finden vertraute Bezeichnungen. Er ist falsch, weil er zufällige Struktur erhält und implizite Laufzeitregeln schwerer erkennbar macht. Das Ziel wird zu alter RPG-Semantik in einer Sprache, deren Betreuer RPG nicht kennen.

Eine gute Zwischendarstellung bewahrt Fakten, die der endgültige Entwurf bewusst verwirft. Sie hält Quellposition, Spezifikationstyp, Operation, Faktoren, Ergebnis, Bedingungs- und Ergebnisindikatoren, Datei- und Satzformatreferenzen, Unterroutinenkanten, Prozeduraufrufe, Herkunft aus Copy-Membern und Zyklusphase fest. Außerdem unterscheidet sie eine vom Compiler abgeleitete Kante von einer im Quelltext geschriebenen. Ohne diese Trennung kann die Migration nicht erklären, warum ein Zielzweig existiert.

Die Architekturentscheidung hängt auch von der Systemgrenze ab. Wenn Aufrufer von Parameterliste, Data-Queue-Nachrichten, extern beschriebenen Satzformaten, Commitment Control oder Zustand auf Jobebene eines RPG-Programms abhängen, bleibt dieser Vertrag zunächst erhalten. Die Interna ändern sich hinter einem Adapter. Wer gleichzeitig jeden benachbarten Vertrag neu entwirft, macht aus einer Sprachmigration ein unbegrenztes Betriebsmodellprojekt.

Manches Verhalten sollte nicht bleiben. Indikator-Aliasing, globale veränderliche Felder, implizites Öffnen und Zykluszeitpunkte brauchen keinen dauerhaften Platz im Ziel. Zuerst werden ihre beobachtbaren Folgen erhalten und per Parität bewiesen, dann verschwindet das Gerüst. Diese Reihenfolge trennt „gleiches Verhalten“ von „gleicher Implementierung“, zwei Dinge, die Modernisierungsprogramme oft vermischen.

Discovery muss das gesamte ausführbare System prüfen

Eine Schätzung anhand der Zeilenzahl von RPG-Membern lässt einen großen Teil des Programms aus. Zum ausführbaren System gehören Copy-Member, Anzeige- und Druckerdateien, Datenbankdefinitionen, CL-Wrapper, Befehle, Jobbeschreibungen, Binding Directories, Serviceprogramme, Datenbereiche, Data Queues, Nachrichtendateien, SQL-Objekte und das Compile-Verfahren. Ein Member mit 300 Zeilen kann im Zentrum einer viel größeren Verhaltensfläche stehen.

Am Anfang steht ein reproduzierbares Inventar, dessen Zeilen auf Belege zurückgeführt werden können. Mindestens erfasst es Identität von Objekt oder Member, Quelltyp, verfügbare Metadaten der letzten Kompilierung, direkte Referenzen, eingehende Aufrufer, Copy-Abhängigkeiten, Dateizugriffsmodus, Indikatorzahl nach Rolle, Zyklusnutzung, Unterroutinen und Prozeduren, eingebettetes SQL, externe Programmaufrufe und nicht verfügbare Quellen. Generierte Quellen und doppelte Varianten werden markiert statt stillschweigend zusammengeführt.

Die unbequeme Frage lautet, ob der gesamte Produktionsquelltext vorhanden ist. Auf IBM i garantiert ein lauffähiges Objekt nicht, dass der exakte Quelltext oder die Compile-Optionen noch verfügbar sind. Teams finden oft einen neuer wirkenden Member in einer Library, während Produktion ein Objekt aus einer anderen Revision ausführt. Objektmetadaten, Library Lists, Binding-Informationen und das bereitgestellte Verhalten müssen verglichen werden. Ist die Herkunft unsicher, gehört diese Unsicherheit ausdrücklich in den Preis, statt das Repository einfach zur Wahrheit zu erklären.

Stichproben müssen dem Risiko folgen, nicht der Bequemlichkeit. Das sauberste Free-Format-Serviceprogramm zu lesen, sagt wenig über einen zyklusgesteuerten Abrechnungsbericht. Die Auswahl muss jeden Quellmodus, jedes Ausführungsmodell, jede E/A-Form, jedes Indikatormuster, jeden Objekttyp und jeden Geschäftsweg abdecken. Dazu gehören der Member, den alle meiden, der mit kopierten O-Specs und das Programm, das nur zum Abschluss läuft. Dort muss die Schätzung belastbar sein.

Ein Discovery-Ergebnis trennt bekannte, abgeleitete und ungeprüfte Fakten. „Programm A ruft Programm B“ kann aus einem aufgelösten Aufrufgraphen bekannt sein. „Indikator 42 bedeutet Wiederholung“ kann aus Operationen und Nachrichten abgeleitet sein. „Dieser Zweig ist tot“ bleibt ungeprüft, bis Produktionsbelege oder ein kontrollierter Test dies stützen. Unterschiedliche Sicherheitsgrade brauchen unterschiedliche Reserven; ein einziger Komplexitätswert verbirgt die Arbeit.

Parität braucht produktionsnahe Belege

Eine erfolgreiche Kompilierung beweist Syntax, Unit-Tests beweisen ausgewählte Funktionen. Keines von beidem belegt, dass sich ein umgeschriebenes RPG-System wie die Produktion verhält. Paritätstests müssen Alt und Neu mit Eingaben vergleichen, die echte Arbeit abbilden, einschließlich Satzreihenfolge, Leer- und Nullwerten, Grenzfällen gepackter Dezimalzahlen, Statuscodes, Gruppenwechseln, fehlenden Sätzen, doppelten Schlüsseln, Dateiende und Jobkontext.

Die Vergleichseinheit muss zum Vertrag passen. Bei einem Bericht werden normalisierter Spool-Inhalt, Seiten- und Summengrenzen sowie Nebenwirkungssätze verglichen. Bei einer Batch-Aktualisierung zählen Datenbankänderungen, Nachrichten, Aufrufe, Commit-Grenzen und Neustartzustand. Bei einem interaktiven Ablauf werden Bildschirmwechsel, Validierungsmeldungen, Funktionstasten und daraus folgende Schreibvorgänge verglichen. Zeitstempel, erzeugte Kennungen und nicht deterministische Reihenfolgen brauchen festgelegte Normalisierungsregeln, keine spontanen Ausnahmen nach einer Abweichung.

Jede Wiederholung braucht ein Manifest:

{"case":"account-break-final-record","input_set":"sha256:...","old_build":"LIBA/ORDRPT:...","new_build":"git:...","normalizers":["run_timestamp"],"expected_events":417}

Der Harness hält Eingabeidentität, beide Build-Identitäten, normalisierte Ausgaben, Rohdaten soweit die Richtlinie dies erlaubt, und das erste abweichende Ereignis fest. „Dateien unterscheiden sich“ erzeugt eine Untersuchung. „Bei Ereignis 413 gab der alte Code ACCT_TOTAL vor der Verarbeitung von Konto 170 aus, der neue danach“ benennt das fehlerhafte Gruppenwechselmodell.

Aufgezeichneter Produktionsverkehr ist besonders nützlich, weil er Kombinationen enthält, die Testautoren vergessen. Er braucht trotzdem Regeln: sensible Felder einheitlich maskieren oder tokenisieren, relationale Gleichheit bewahren, nötige Jobattribute erfassen und verhindern, dass Wiederholungen echte externe Systeme aufrufen. Wenn Verkehr die Kundengrenze nicht verlassen darf, läuft der Vergleich dort. CodeHero nutzt dieses Modell: Die Plattform liest den ganzen Baum, schreibt die Architektur neu und prüft das Verhalten mit einem Parity Harness gegen aufgezeichneten Produktionsverkehr.

Parität verlangt nicht, jeden alten Unfall für immer zu bewahren. Zuerst wird jede Abweichung als erforderliches Verhalten, geduldeter Fehler, Umgebungsrauschen oder genehmigte Änderung eingestuft. Danach bleibt die Entscheidung nachvollziehbar. Eine Berechnung während der Migration still zu „reparieren“ kann gefährlicher sein, als sie vorübergehend mitzunehmen, weil nachgelagerte Dateien oder Abstimmungen vom alten Ergebnis abhängen können.

Fest und frei brauchen unterschiedliche Schätzeinheiten

Eine prozedurale Free-Format-Migration lässt sich oft anhand expliziter Einheiten schätzen: Prozeduren, SQL-Anweisungen, Dateiverträge, externe Aufrufe, Bildschirme und Tests. Festformatiger Zykluscode braucht zusätzliche Einheiten für zurückgewonnene Semantik: Indikatorgruppen, Netze aus Ein- und Ausgabespezifikationen, Steuerungsebenen, zyklusgesteuerte Dateien, Pfade der Ausnahmeausgabe, Zustand von Unterroutinen und Quellenrekonstruktion. Diese Einheiten stehen für Analyse und Prüfung, nicht für Tipparbeit.

Die Schätzung wird in vier Töpfe getrennt: Inventar und Herkunft, semantische Rekonstruktion, Zielimplementierung und Paritätsbelege. Prozeduraler Free-Format-Code kann mehr Budget in der Implementierung verbrauchen. Fester Zykluscode verschiebt Aufwand meist zur semantischen Rekonstruktion und zum Entwurf der Wiederholungen. Ein Zeilenpreis für beides macht die schwere Arbeit unsichtbar und belohnt die am wenigsten aussagekräftige Kennzahl.

Komplexität steigt, wenn Wechselwirkungen zunehmen. Ein Gruppenwechselindikator mit einer Summenzeile ist begrenzt. Mehrere Steuerungsebenen in Verbindung mit übereinstimmenden Sätzen, gemeinsam genutzten Indikatoren, Ausnahmeausgabe und kopierten Spezifikationen erzeugen Zustandskombinationen. Ein pauschaler Aufschlag je Funktion behandelt ihre Wirkungen fälschlich als unabhängig. Bepreist werden die kombinierten Verhaltenspfade, die verstanden und getestet werden müssen.

Bis Discovery bestimmte Unbekannte schließt, gehören Spannen in die Schätzung. Neben jeder Spanne stehen Grundlage und Ausstiegsbedingung: „Zyklussemantik, mittlere Sicherheit, wird nach zwei repräsentativen Spuren enger“ ist vertretbar. „RPG-Konvertierung, 500 Zeilen pro Tag“ ist es nicht. Die Spanne schrumpft, wenn das Team Quellherkunft klärt, das Indikatorverzeichnis erstellt, den Aufrufgraphen validiert und repräsentative Fälle wiederholt.

Die Schätzung muss auch Ausschlüsse nennen. Datenbereinigung, neue Geschäftsregeln, Ersatz der vorgelagerten Jobsteuerung, Neuentwurf von Bildschirmen oder Zusammenlegung doppelter Anwendungen können sinnvoll sein, gehören aber nicht automatisch zu einer Sprachmigration. Wenn Stakeholder sie wollen, bekommen sie eigene Entscheidungen, Belege und Preise. Sonst wird jede wünschenswerte Änderung der „RPG-Schwierigkeit“ zugerechnet, und niemand erfährt, was die Migration tatsächlich kostet.

Legt man beide Stile auf dasselbe Schätzblatt, wird der Unterschied konkret. Bei einem prozeduralen Free-Format-Service kann der Analyst meist eine Einstiegsprozedur erkennen, expliziten Lesevorgängen oder SQL folgen, Aufrufe auflisten, Rückgabewerte zuordnen und Verträge für Adapter zählen. Unbekannte bleiben, besonders bei Jobzustand und externen Objekten, doch jede hängt an einer sichtbaren Operation oder Grenze. Die Schätzung kann rasch vom Inventar zum Zielentwurf wechseln, weil das Programm selbst sagt, wann Arbeit geschieht.

Bei einem festen Zyklusbericht beginnt das erste Arbeitsblatt früher. Der Analyst muss bestimmen, welche Datei der Zyklus steuert, welche Eingabespezifikationen Sätze identifizieren, welche Felder Gruppenwechsel auslösen, wann Summen laufen, welche O-Spec-Zeilen sie bedingen und was LR anstößt. Danach folgt das Indikatorverzeichnis einschließlich implizit durch Dateioperationen gesetzter Werte. Erst dann kann das Ziel dieselbe Folge durch Reader, Gruppierungslogik, Berechnungen und Ausgabeadapter sichtbar machen. Beide Programme als je einen „RPG-Member“ zu zählen, löscht eine ganze Schicht von Ergebnissen.

Auch die Abnahmekriterien unterscheiden sich. Für den prozeduralen Service reichen möglicherweise Anfrage- und Antwortfälle, Datenbankwirkungen und explizite Fehlerpfade. Der Zyklusbericht braucht geordnete Fälle für den ersten Satz, jede Steuerungsebene, Sätze mit gleichzeitigem Wechsel mehrerer Ebenen, gegebenenfalls leere oder fehlende Eingabe und den letzten Satz. Bei Matching-Record-Logik oder Ausnahmeausgabe wächst die Matrix um diese Wechselwirkungen. Die Zusatztests gleichen keine schlechte Konvertierung aus. Sie belegen, dass der neue explizite Kontrollfluss dem alten impliziten entspricht.

Prüferkenntnisse gehören ebenfalls in die Schätzung. Ein Go-Entwickler kann die Zielstruktur beurteilen, erkennt aber vielleicht nicht, dass eine Summenberechnung Felder aus einer anderen Zyklusphase liest. Ein RPG-Praktiker kann dieses Verhalten rekonstruieren, akzeptiert aber möglicherweise eine wörtliche Architektur, weil sie vertraut wirkt. Beide prüfen gemeinsam, bis Paritätsspuren und Zwischendarstellung die Begründung sichtbar machen. Der Übergabepunkt braucht Belege: Ein Prüfer muss jeden Zielzweig auf eine RPG-Regel, Quellbedingung oder genehmigte Neugestaltung zurückführen können.

Schätzen Sie Nacharbeit getrennt von erwarteter Implementierung. Eine bekannte Konvertierungsregel für Hunderte regelmäßige Berechnungen ist Implementierungsarbeit. Ein ungeklärter Indikator, der fünf Ausgabeformate steuert, ist ein Discovery-Risiko; ihn zu erraten erzeugt Nacharbeit statt Fortschritt. Für jedes solche Risiko werden Verantwortlicher, benötigter Beleg und Entscheidungsfrist festgehalten. So bleibt die Reserve erklärbar, und Unsicherheit in wenigen Festformat-Membern verteuert nicht den sauberen prozeduralen Code.

Die Zahlen können weiterhin in ein kommerzielles Angebot einfließen, doch das Angebot sollte die internen Klassen bewahren. Die Lieferung kann dann prozedurale Komponenten mit geringer Unsicherheit vorziehen, während die semantische Arbeit riskante Zykluspfade klärt, ohne gleichmäßigen Durchsatz vorzutäuschen. Blockiert eine gemeinsame Abhängigkeit beide Klassen, steht sie einmal auf Portfolioebene. Braucht nur die Zyklusrekonstruktion sie, bleibt der Aufwand in dieser Klasse. So kann ein Projektpreis ehrlich bleiben, ohne zwei Arbeitsarten in dieselbe Migrationsschätzung zu zwingen.

Diese Trennung klärt auch die Änderungssteuerung: Verschiebt eine neu entdeckte Zyklusregel die Schätzung, sehen Stakeholder, welche Klasse sich geändert hat und warum die prozedurale Prognose gleich blieb.

Eine Mischzahl erzeugt den falschen Plan

Dieselbe Schätzung kann festformatigen Zykluscode und prozedurales Free-Format-RPG nicht abdecken, weil die Arbeit mit unterschiedlicher Gewissheit beginnt. Im prozeduralen Fall kann das Team den Kontrollfluss oft sehen und seine Zeit in den sauberen Neuaufbau der Verträge stecken. Beim festen Zyklus muss es den Kontrollfluss zuerst aus Spalten, Spezifikationen, Indikatoren, Compilerregeln und Laufzeitbelegen rekonstruieren. Beides ist migrierbar, aber nicht über denselben Eingang.

Das rechtfertigt kein unbegrenztes Archäologieprojekt. Discovery wird anhand repräsentativer Risikoklassen zeitlich begrenzt und muss konkrete Ergebnisse liefern: Zählung der Quellmodi, Klassifikation der Ausführungsmodelle, aufgelöster Build-Graph, Indikatorverzeichnisse für riskante Member, Zyklusspuren, Vertragsinventar und Paritätsfälle. Kann eine Discovery-Aufgabe nicht benennen, welche Schätzunsicherheit sie reduziert, entfällt sie.

Für ein Portfolio werden mindestens getrennte Spannen für zyklusgesteuerten festen oder gemischten Code, prozeduralen festen oder gemischten Code und vollständig freien prozeduralen Code angeboten. Anschließend werden fehlende Quellen, Anzahl externer Objekte, Empfindlichkeit von Datenverträgen und vorhandene Testbelege eingerechnet. Die Klassifikation bleibt in der Lieferplanung sichtbar, weil sie auch Prüferkenntnisse und Reihenfolge der Komponenten bestimmt.

CodeHero verpflichtet sich, jeden Umbau in weniger als 30 Tagen abzuschließen, auch bei Systemen mit mehr als einer Million Zeilen. Deshalb muss unsere Aufnahme diese Unterschiede sofort erkennen, statt sie in einem Mischsatz zu verstecken. Unabhängig davon, ob Sie uns einsetzen, sollte jeder Migrationsanbieter erklären, wie seine Schätzung Zyklusphasen, Wiederverwendung von Indikatoren, kopierte Spezifikationen, Produktionsherkunft und Parität bei Gruppenwechseln berücksichtigt. Kehrt die Antwort zu Zeilenzahlen zurück, beschreibt die Schätzung nicht die Aufgabe.