JCL lesen beginnt mit der Ausführungsreihenfolge

JCL wird verständlich, sobald Sie es nicht mehr als Programm, sondern als serialisierten Kontrollgraphen betrachten. Der Quelltext nennt Programme, stellt Ressourcen bereit und deklariert Schranken, doch mehrere Systeme entscheiden gemeinsam, was tatsächlich läuft: Der Konverter erweitert Prozeduren, der Katalog löst Datensätze auf, JES und der Initiator legen den Jobkontext fest, der Scheduler kann Symbole einsetzen, und ein Operator kann den Job in der Mitte neu starten. Wer nur die sichtbaren Karten liest, zeichnet leicht ein überzeugendes, aber falsches Ablaufdiagramm.

Der erste Durchgang hat ein einziges Ziel: Ermitteln Sie die geordneten Schritte, die von jedem Schritt gelesenen und geschriebenen Daten sowie die Bedingungen, die einen Schritt unterdrücken können. Syntaxdetails kommen danach. Ich habe Teams einen Vormittag lang Spalten und Kommata entschlüsseln sehen, während ihnen entging, dass eine katalogisierte Prozedur sechs Schritte beisteuerte und der Scheduler die Generation vom Vortag auswählte. Beginnen Sie mit dem Verhalten und belegen Sie es anschließend mit der Syntax.

Ein JCL-Member ist ein Kontrollgraph, kein Skript

Ein Job enthält normalerweise eine JOB-Anweisung, gefolgt von EXEC-Anweisungen, denen jeweils DD-Anweisungen zugeordnet sind. Das wirkt sequenziell und ist es auf oberster Ebene auch: Wenn kein Überspringen, Fehler, Neustart oder abnormaler Abbruch eingreift, übergibt JES die Schritte der Reihe nach an einen Initiator. Das vorliegende Member kann dennoch nur einen Teil des Graphen enthalten. Ein EXEC kann eine katalogisierte oder eingebettete Prozedur aufrufen, eine JCLLIB-Anweisung kann die Suchorte für Prozeduren ändern, und INCLUDE-Anweisungen können vor der Ausführung weitere Anweisungen einfügen.

Trennen Sie vier Phasen. Bei der Eingabe liest JES den Job und wendet Eingaberegeln an. Bei der Konvertierung prüft das System die JCL, erweitert Prozeduren und löst Symbole auf. Bei der Allokation sucht oder erstellt z/OS die für einen Schritt benötigten Datensätze und Geräte. Bei der Ausführung läuft das gewählte Programm und liefert einen Code zurück oder bricht ab. Ausgabeaufbereitung und Bereinigung umgeben diesen Ablauf, machen aus der JCL aber keine Anwendungslogik.

Diese Trennung erklärt ein häufiges Rätsel: Ein Job kann fehlschlagen, bevor sein erstes Programm läuft. Eine fehlende Prozedur, ein unaufgelöstes symbolisches Argument, ein doppelter Schrittname, eine ungültige DD-Anweisung oder ein nicht verfügbarer Datensatz kann bei Konvertierung oder Allokation einen JCL-Fehler auslösen. Bezeichnen Sie nicht jeden roten Job als Anwendungsfehler. Prüfen Sie zuerst, ob überhaupt ein Programm die Kontrolle erhielt. JES-Meldungen und Jobprotokoll beantworten das.

Skizzieren Sie einen groben Graphen, bevor Sie Operanden lesen. Zeichnen Sie einen Knoten pro erweitertem EXEC-Schritt, einen durchgehenden Pfeil für die normale Folge, einen gestrichelten Pfeil für jede Bedingung und Datenkanten für benannte Datensätze zwischen Erzeugern und Verbrauchern. Vermerken Sie drei Zustandsarten, die keine normalen Dateien sind: bei der Konvertierung aufgelöste Symbole, bei der Allokation abgefragter Katalogzustand und bei der Ausführung erzeugte Rückgabecodes. Dieses Bild deckt fehlende Belege schnell auf.

Die Quellreihenfolge ist weiterhin wichtig, beantwortet aber nur eine Frage: In welcher Reihenfolge würden ausführbare Schritte laufen? Sie sagt nicht, ob die Schritte ausführbar sind, was eine Prozedur enthält, welche physische Generation ein relativer GDG-Name auswählt oder wo ein Neustart beginnt. Behandeln Sie das Member als Eingabe eines Laufs, nicht als dessen Protokoll.

EXEC-Anweisungen definieren die Arbeitseinheiten

Jede EXEC-Anweisung erzeugt einen Schritt, und der Operand bestimmt, ob der Schritt direkt ein Programm startet oder eine Prozedur aufruft. EXEC PGM=IEFBR14 nennt ein Programm. EXEC PROC=DAILY oder die kürzere Form EXEC DAILY ruft eine Prozedur auf. Der Schrittname links von EXEC ist der stabile Bezugspunkt für Bedingungen, Überschreibungen, Neustarts und Meldungen. Notieren Sie ihn exakt.

Beginnen Sie mit einem kleinen Beispiel:

//BILLING  JOB (ACCT),'DAILY BILL',CLASS=A,MSGCLASS=X
//EXTRACT  EXEC PGM=EXTBILL,PARM='DAILY'
//INPUT    DD DSN=APP.CUST.MASTER,DISP=SHR
//OUT      DD DSN=APP.BILL.WORK(+1),DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,10)),UNIT=SYSDA
//SORT     EXEC PROC=SORTBILL,INDSN=APP.BILL.WORK(+1)
//LOAD     EXEC PGM=LOADBILL,COND=(0,NE,SORT)
//IN       DD DSN=APP.BILL.SORTED(+1),DISP=SHR

Die sichtbare Gliederung lautet EXTRACT, SORT, LOAD. Sie ist noch kein Ausführungsplan. SORTBILL kann mehrere Prozedurschritte enthalten. Der Name SORT bezeichnet den aufrufenden Schritt, während Meldungen und Bedingungsreferenzen innerhalb der Prozedur qualifizierte Namen wie SORT.COPY verwenden. LOAD besitzt eine Bedingung, die es unterdrücken kann. Beide relativen Generationsnamen benötigen Katalogkontext.

Lesen Sie ein EXEC in dieser Reihenfolge: Schrittname, PGM oder Prozedur, Bedingungssteuerung, gegebenenfalls Region- oder Zeitgrenzen und an das Programm übergebener Parametertext. Interpretieren Sie PARM nicht als JCL-Logik. JCL übergibt den Text an das Programm; nur der Vertrag dieses Programms erklärt, was PARM='DAILY' bedeutet. Das gilt auch für Werte in SYSIN. Sie sehen oft wie eine andere Sprache aus, weil sie tatsächlich eine andere Sprache sind, die ein Dienstprogramm, Datenbankwerkzeug, Compiler oder internes Programm verarbeitet.

Eine Prozedur erzeugt zwei Namensräume. Der aufrufende Job hat einen äußeren Schrittnamen, die Prozedur innere Schrittnamen. In Meldungen, Überschreibungen und Neustartsyntax erscheinen qualifizierte Formen. Geben Sie jedem erweiterten Schritt in Ihrer Tabelle einen Namen wie SORT.COPY und bewahren Sie den ursprünglichen Prozedurtext daneben auf. Sonst erscheinen zwei Prozeduren mit einem internen STEP1 als derselbe Schritt.

Programme können Daten auch dynamisch über SVC 99 oder eine Bibliotheksroutine allokieren. Diese Allokationen erscheinen nicht als DD-Anweisungen im eingereichten JCL. Wenn ein Programm einen nicht erklärbaren Datensatz öffnet, prüfen Sie Meldungen, Allokationsspuren, Quelltext oder Laufzeitkonfiguration, bevor Sie eine fehlende DD-Anweisung vermuten. JCL deklariert einen großen Teil der Umgebung, aber nicht zwingend alles.

DD-Anweisungen binden Programmnamen an Ressourcen

Eine DD-Anweisung gehört bis zum nächsten EXEC zum vorangehenden EXEC-Schritt. Der Name links ist normalerweise der Name, den das Programm öffnet; die Operanden beschreiben die hinterlegte Ressource und ihren Lebenszyklus. Lesen Sie //INPUT DD DSN=APP.CUST.MASTER,DISP=SHR so: Binde für diesen Schritt den Programmnamen INPUT an den katalogisierten Datensatz und erwarte gemeinsamen Zugriff. INPUT ist keine Variable, die über Schritte hinweg bestehen bleibt. Ein anderer Schritt kann ein eigenes INPUT DD mit anderer Bedeutung definieren.

Ordnen Sie jede DD-Anweisung einer von fünf praktischen Gruppen zu: katalogisierter Datensatz, neuer Datensatz, temporärer Datensatz, eingebettete Daten oder Systemausgabe. DSN= bezeichnet einen Datensatz. DD * und DD DATA leiten im Job eingebettete Datensätze ein. SYSOUT=* sendet Ausgabe in die Ausgabeklasse des Jobs. DUMMY lässt viele Zugriffsmethoden so arbeiten, als sei Eingabe leer oder Ausgabe verworfen. Eine fehlende DD kann beabsichtigt sein, wenn das Programm dynamisch allokiert oder sie optional behandelt. Prüfen Sie den Programmvertrag.

DISP hat bis zu drei Teile: Status zu Schrittbeginn, Aktion nach normalem Abschluss und Aktion nach abnormalem Abschluss. Bei DISP=(NEW,CATLG,DELETE) fordert der Schritt einen neuen Datensatz an, katalogisiert ihn nach normalem Abschluss und löscht ihn nach abnormalem Abbruch. DISP=SHR fordert einen vorhandenen Datensatz mit gemeinsamem Zugriff an. OLD verlangt im Allgemeinen exklusive Kontrolle, während MOD für Erweiterung positioniert und ein Erstellungsverhalten besitzt, das Sie im IBM-Handbuch prüfen sollten. DISP beschreibt Allokation und Verbleib, nicht fachlichen Erfolg. Ein Programm kann normal mit 8 enden, und die normale DISP-Aktion gilt trotzdem, weil kein Abend vorlag.

Temporäre Namen beginnen mit && und bestehen normalerweise für die Dauer des Jobs. Wird ein solcher Name vom erzeugenden an den verbrauchenden Schritt weitergegeben, entsteht eine klare Datenkante, obwohl der Katalog ihn nie sieht. Umgekehrt beweisen zwei ähnlich benannte permanente DSNs keine Erzeuger-Verbraucher-Beziehung. Ein Scheduler kann beide liefern, oder ein früherer Job erzeugte die Eingabe.

Verkettungen sind ein weiterer Fall, in dem visuelles Überfliegen scheitert. Aufeinanderfolgende DD-Anweisungen können einen logischen Eingabestrom bilden, wenn spätere Anweisungen den ddname auslassen. Bibliotheken in einer STEPLIB- oder JOBLIB-Verkettung werden der Reihe nach durchsucht, sodass das erste passende Lademodul gewinnt. Eingabeverkettungen werden nacheinander präsentiert, doch Kompatibilitätsregeln hängen von Zugriffsmethode und Datensatzattributen ab. Erfassen Sie die Verkettung als eine geordnete Bindung.

Überschreibungen können DD-Anweisungen innerhalb einer Prozedur ersetzen oder ergänzen. //SORT.COPYIN DD DSN=APP.SPECIAL.INPUT,DISP=SHR kann COPYIN im Prozedurschritt COPY unter dem aufrufenden Schritt SORT ansprechen. Der Prozedurtext allein beschreibt den Lauf dann falsch, während die aufrufende Quelle wie eine verwaiste DD wirkt. Nur die Erweiterung zeigt die Wahrheit.

Die IBM z/OS JCL Reference definiert Operanden, sagt aber nicht, ob Ihr Programm einen ddname benötigt oder welche Sätze in SYSIN gehören. Dafür brauchen Sie die Schnittstellendokumentation des Programms oder dessen OPEN- und dynamisches Allokationsverhalten. JCL erklärt die Bindung, das Programm den Vertrag. Wer beides vermischt, migriert Dateinamen und bricht Verhalten.

Erst die Prozedurerweiterung zeigt den fehlenden Quelltext

Sie können die Ausführungsreihenfolge erst bestimmen, wenn Sie alle Prozeduren und INCLUDE-Gruppen mit denselben Bibliotheken und Symbolen wie beim Lauf erweitern. Eine katalogisierte Prozedur ist wiederverwendbares JCL in einer Prozedurbibliothek. Eine eingebettete Prozedur steht zwischen PROC und PEND im eingereichten Job. Beide können EXEC- und DD-Anweisungen, symbolische Parameter und innerhalb der Systemgrenzen verschachtelte Aufrufe enthalten.

Die erweiterte Auflistung in der JES-Ausgabe ist meist ein besserer Beleg als eine Repository-Suche, weil sie das Konvertierungsergebnis dieser Einreichung festhält. Suchen Sie die JES-JCL-Auflistung, häufig JESJCL, und Meldungen in JESYSMSG und JESMSGLG. Standortanpassungen ändern Aufbewahrung und Anzeige, deshalb müssen Sie die lokalen Spool-Konventionen kennen. Wenn Auflistung und Git widersprechen, prüfen Sie zuerst, ob der Scheduler ein generiertes Member oder eine andere PROCLIB einreichte.

Symbolische Parameter sehen etwa wie &INDSN. aus. Der Punkt kann den Symbolnamen beenden und bei der Ersetzung verschwinden. Standardwerte stehen auf PROC-Anweisungen, Aufrufer überschreiben sie bei EXEC, SET weist Werte zu, und Scheduler-Werkzeuge können Variablen ersetzen, bevor JES die Eingabe liest. Erfassen Sie Ausdruck und aufgelösten Wert. Nur die Auflösung macht den nächsten Lauf schwer vorhersagbar, nur die Quelle macht den beobachteten Lauf unerklärlich.

JCLLIB und standortspezifische Prozedurverkettungen steuern die Suche. Zwei Bibliotheken können ein Member gleichen Namens enthalten; die Reihenfolge entscheidet über die Erweiterung. Das entspricht der Suche nach der richtigen Abhängigkeitsversion, nur dass die Version in der Bibliotheksreihenfolge statt in einem Manifest stecken kann. Erfassen Sie Membername, Bibliothek, verfügbaren Änderungsstand und erweiterte Anweisungen.

Überschreibungen greifen nach Definition der wiederverwendbaren Prozedur. Sie können EXEC-Parameter ändern, DD-Definitionen ersetzen, DDs aufheben oder Bindungen ergänzen. Die knappe Syntax kann wesentliches Verhalten in wenigen Zeilen verbergen. Markieren Sie in Ihrem flachen Graphen jedes überschriebene Feld und nennen Sie beide Fundstellen.

Kopieren Sie Prozedurtext nicht manuell in den Job und erklären die Analyse für beendet. Dabei gehen leicht verschachtelte Aufrufe, Symbolgrenzen, Bibliotheksvorrang und Überschreibungen verloren. Nutzen Sie die Konvertierungsausgabe eines aufgezeichneten Laufs als Basis und rekonstruieren Sie dann ihren Ursprung. Für eine Syntaxprüfung verwenden viele Installationen TYPRUN=SCAN, dessen genaue Wirkung jedoch von lokaler JES-Politik abhängt. Ein Scan prüft eingereichtes JCL, nicht Anwendungsdaten oder späteres Laufzeitverhalten.

GDG-Namen hängen vom veränderlichen Katalogzustand ab

Eine Generation Data Group ist ein Katalogeintrag, der eine Folge von Generationsdatensätzen verwaltet. Eine Basis wie APP.BILL.WORK kann über einen absoluten Generationsnamen oder relativ angesprochen werden: (0) für die aktuelle Generation, (-1) für die vorherige und üblicherweise (+1) für eine neue. Die relative Schreibweise ist betrieblich praktisch, analytisch aber unvollständig, weil der physische Name vom Katalogzustand abhängt.

Wenn ein Schritt APP.BILL.WORK(+1) mit NEW erzeugt und spätere Schritte dieselbe relative Generation lesen, kann der Job eine neu erzeugte Generation weitergeben, ohne den absoluten GxxxxVyy-Namen fest einzutragen. Ihr Graph sollte relative Referenz und den im Lauf beobachteten absoluten Namen zeigen. Ersetzen Sie relative Referenzen nie durch das, was (0) heute bedeutet. Der Katalog kann seitdem weitergelaufen sein.

Der unangenehme Fehler entsteht, wenn ein Erzeuger übersprungen wird oder scheitert und ein Verbraucher folgt. Angenommen, EXTRACT allokiert WORK(+1), endet abnormal und DELETE greift. SORT erhält keine gültige neue Generation. Je nach Bedingungen und Allokationszeitpunkt wird SORT übersprungen, scheitert bei der Allokation oder sieht einen anderen Katalogzustand. Startet jemand später nur SORT erneut, kann (+1) eine neue Allokation statt der beabsichtigten Ausgabe bedeuten. Relative Syntax trägt keine Herkunftsinformation.

Eine weitere Falle liegt zwischen Jobs. Ein Scheduler kann JOB A zur Erzeugung und JOB B zum Lesen von (0) ausführen. Die Abhängigkeit steht in keinem der JCL-Member. Beginnt JOB B zu früh oder startet ein Operator JOB A erneut, kann (0) eine andere Generation wählen. Scheduler-Plan, Kataloghistorie und Zeitstempel gehören zum Programm. Das Repository allein beweist nicht, welche Sätze JOB B las.

Erstellen Sie für den Lauf ein GDG-Ledger mit Schritt, DD-Name, relativer Referenz, Disposition, aufgelöstem absolutem DSN, Katalogaktion und beobachtetem Ergebnis. Füllen Sie es aus Allokationsmeldungen und Katalogbelegen, nicht aus Vermutungen. Bei einem Fehllauf halten Sie fest, ob die Allokation abgeschlossen wurde und welche Disposition griff. So lässt sich meist klären, ob ein Neustart Daten wiederverwendet oder eine Generation erzeugt.

Die IBM-Dokumentation trennt GDG-Basis, Modell und Grenzverhalten von einzelnen Generationsdatensätzen. Bewahren Sie diese Trennung. Das Löschen oder Entkatalogisieren einer Generation ändert nicht die Basis, und das Herausfallen unter Grenzregeln bedeutet keine sofortige Löschung vom Datenträger. Für das Verständnis gilt: Relative GDG-Notation ist eine Katalogabfrage im Laufkontext, kein fester Dateiname.

Bedingungscodes unterdrücken Schritte anhand früherer Ergebnisse

Ein normal endendes Programm liefert einen Rückgabecode, in Jobausgaben oft RC oder CC. JCL kann damit entscheiden, ob ein späterer Schritt läuft. Ein Abend-Code unterscheidet sich von einem normalen Rückgabecode; bei Allokations- oder Konvertierungsfehler existiert vielleicht gar kein Programmcode. Führen Sie RC, System-Abend, User-Abend und JCL-Fehler in getrennten Spalten. Die Reduktion auf Erfolg oder Fehler zerstört die zur Rekonstruktion benötigten Daten.

Der ältere COND-Parameter beschreibt einen Überspringtest. Bei COND=(0,NE,SORT) vergleicht das System den Literalwert 0 über NE mit dem Rückgabecode von SORT. Ist 0 ungleich SORTs RC, ist der Test wahr und der aktuelle Schritt wird übersprungen. LOAD läuft also nur bei SORT RC 0. Viele lesen COND fälschlich als Ausführungsbedingung. Ergänzen Sie gedanklich immer überspringen wenn und übersetzen Sie dann den Vergleich.

Einige Beispiele zeigen die Umkehrung:

• COND=(4,LT,COMPILE) bedeutet: überspringen, wenn 4 kleiner als COMPILEs RC ist; Werte über 4 unterdrücken den Schritt.
• COND=(0,EQ,CHECK) bedeutet: überspringen, wenn CHECK 0 zurückgab.
• COND=EVEN lässt eine Prüfung auch nach einem früheren Abend zu, unter Berücksichtigung weiterer Regeln.
• COND=ONLY führt den Schritt nur nach einem früheren Abend aus, ebenfalls im vollständigen Jobkontext.

Modernes JCL kann IF, THEN, ELSE und ENDIF verwenden, was näher an Anwendungslogik liest. Ausdrücke können qualifizierte Rückgabecodes und Abend-Status nennen. Es bleibt Steuerlogik um Schritte, nicht innerhalb der Programme. Verschachtelung und Prozedurqualifikation können einen IF-Block über mehr Quelltext spannen als sichtbar. Markieren Sie Blockgrenzen im erweiterten Ablauf.

Job- und schrittweises COND wirken mit Fehlern zusammen, und eine Prozedur kann Bedingungen definieren, die der Aufrufer überschreibt. Reduzieren Sie sie nicht auf einen grünen Pfeil. Schreiben Sie für jeden Schritt einen Berechtigungs-Ausdruck anhand früherer Ergebnisse und werten Sie ihn für den tatsächlichen Lauf aus. So trennen Sie mögliche von tatsächlich genommenen Pfaden.

Die Bedeutung eines Rückgabecodes definiert das Programm. RC 4 bedeutet bei IBM-Dienstprogrammen häufig Warnung, ein internes Programm kann ihn anders verwenden. Manche Scheduler akzeptieren einen Bereich als erfolgreich, obwohl spätere JCL zwischen 0 und 4 unterscheidet. Erfassen Sie drei Regeln getrennt: Programmmeldung, JCL-Sprunglogik und Scheduler-Klassifikation. Ein Statussymbol bildet nicht alle drei ab.

Ein Neustart ändert den Anfang, nicht das Member

Ein neu gestarteter Job beginnt nicht zwingend beim ersten EXEC. Der Neustart kann einen Jobschritt oder einen Schritt in einer Prozedur nennen; Installationswerkzeuge oder Scheduler können die wirksame Anforderung erzeugen. Das Member bleibt unverändert, obwohl der Lauf in der Mitte anfängt. Jedes Ablaufdiagramm ohne Laufidentität und Neustartmetadaten bleibt deshalb vorläufig.

Neustartsicherheit hängt vom Datenzustand ab, nicht nur von der Reihenfolge. Frühere Schritte können Ausgaben katalogisiert, Datenbanken geändert, Sätze gedruckt, Nachrichten gesendet oder Prüfpunkte bestätigt haben. Ein Beginn bei STEP5 rollt diese Effekte nicht zurück. Abnormale DISP-Aktionen können andererseits einen von STEP5 erwarteten Datensatz gelöscht haben. Listen Sie vor einer Freigabe alle früheren Nebenwirkungen und Eingaben des Zielschritts auf.

Ein Checkpoint-Neustart innerhalb eines Programms unterscheidet sich vom JCL-Schrittneustart. Ein Dienstprogramm kann innerhalb eines Schritts fortsetzen, während JES an einer EXEC-Grenze wieder einsteigt. Belege und Wiederherstellungsregeln sind verschieden. Wenn jemand sagt, der Job sei neu gestartet worden, fragen Sie nach Mechanismus, Ziel und Jobkennungen.

Scheduler bilden eine weitere unsichtbare Ebene. Sie können Datumswerte berechnen, Member wählen, SET-Werte einsetzen, Abhängigkeiten hinzufügen, Jobs auf Ressourcen warten lassen und Rückgabecodes klassifizieren. Nichts davon muss im gespeicherten JCL stehen. Ein vorgeschalteter Job kann die DSN für den ersten sichtbaren Schritt erzeugen. Eine Kalenderregel kann zum Monatsabschluss eine andere Prozedur wählen. Beschaffen Sie Scheduler-Definition und Einreichungsprotokoll zusammen mit der Spool-Ausgabe.

Externer Zustand verändert selbst einen sauberen Wiederholungslauf. Die aktuelle GDG-Generation kann fortschreiten, Eingabedateien können ersetzt, Datenbanktabellen geändert und über Bibliothekssuche neue Programmversionen gewählt werden. Ein Wiederholungslauf beweist heutiges Verhalten im heutigen Zustand. Er reproduziert den ursprünglichen Lauf nur mit dessen Eingaben, Katalogzuordnungen, Binärdateien, Symbolen und Kontrollen.

Operatoren geben außerdem Befehle ein und beantworten Allokations- oder Geräteanfragen. Diese Aktionen stehen selten im Repository. Jobprotokoll, Automationsprotokolle und Betriebsticket können die fehlende Kante enthalten. Wartete ein Schritt auf ein Band oder wurde nach einem Timeout abgebrochen, erklärt Quelltext weder Laufzeit noch Endstatus.

Der Spool ist ein Beleg, kein Rauschen

Am schnellsten verstehen Sie einen geerbten Batch, wenn Sie den Quelltext mit einem erfolgreichen Spool-Satz und einem typischen Fehler kombinieren. Der Quelltext zeigt beabsichtigte Möglichkeiten. Der Spool zeigt Konvertierung, Allokation, Programmmeldungen, Rückgabecodes und den Pfad einer Einreichung. Beides ist nötig.

Beginnen Sie mit Jobname, Job-ID, System, Einreichungszeit, Scheduler-Auftrag oder Lauf-ID und Neustartstatus. Sammeln Sie dann konvertierte JCL-Auflistung, JES- und Systemmeldungen sowie Anwendungs-SYSOUT. JESJCL, JESMSGLG und JESYSMSG sind häufige Namen, die lokale Politik variiert jedoch. Sichern Sie das Rohmaterial, bevor die Spool-Aufbewahrung es entfernt.

Lesen Sie chronologisch und kennzeichnen Sie Phasen. Konvertermeldungen erklären Symbol- und Syntaxprobleme. Allokationsmeldungen ordnen DD-Namen Datensätzen und Volumes zu. Abschlussmeldungen nennen Programm, Rückgabecode und Abend. Anwendungsmeldungen erklären fachliche Zähler und Dienstprogrammentscheidungen. Zeitstempel können durch Pufferung täuschen; verwenden Sie zusätzlich Schritt- und Meldungsidentität.

Erfassen Sie für jeden erweiterten Schritt eine beobachtete Zeile:

SORT.COPY | PGM=SORT | ran=yes | RC=0004 | abend=none
  COPYIN  -> APP.BILL.WORK.G0123V00      DISP=SHR
  COPYOUT -> APP.BILL.SORTED.G0098V00   DISP=(NEW,CATLG,DELETE)
  gate    -> eligible after EXTRACT RC=0000

Dieses bewusst schlichte Format ist diffbar und macht Unbekanntes sichtbar. Fehlt der absolute DSN, schreiben Sie unbekannt und benennen den nötigen Beleg. Setzen Sie nicht still den aktuellen Katalogwert ein.

Vergleichen Sie Erfolg und Fehler nach erweitertem Schrittnamen, Programm, DSNs, Symbolwerten, Schranken und Ergebnissen. Die erste Abweichung ist oft wichtiger als der letzte Abend. Eine andere Eingabegeneration kann später eine Prüfung auslösen, eine geänderte STEPLIB denselben Schritt mit anderem Code laden, und eine Warnung kann Bereinigung überspringen und den nächsten Lauf vergiften.

Entfernen Sie Zugangsdaten und regulierte Daten, bevor Spool in allgemeine Entwicklungssysteme gelangt. JCL und SYSOUT können Kontofelder, Tokens in PARM, Datenbankbefehle oder vollständige Geschäftssätze enthalten. Behandeln Sie Spool als Produktionsbeleg. Bei einer Air-Gap-Prüfung bleiben Belege und Werkzeuge innerhalb der Kundengrenze.

Eine Trace-Tabelle macht die Archäologie prüfbar

Eine Trace-Tabelle soll einem anderen Engineer erlauben, Ihr Ablaufmodell zu prüfen, ohne den ganzen Spool zu lesen. Verwenden Sie eine Zeile pro erweitertem EXEC in wirksamer Reihenfolge. Nötig sind qualifizierter Schrittname, Programm, Prozedurursprung, Symbole, Ein- und Ausgabe-DDs, Berechtigungsregel, RC oder Abend und Neustartfolgen. Ergänzen Sie dynamische Allokationen.

Gehen Sie bei einem echten Job so vor:

1. Sichern Sie Quelle, Scheduler-Datensatz, erweiterte JCL, Spool und Katalogzuordnungen eines Laufs unter einer gemeinsamen Lauf-ID.
2. Erweitern Sie Prozeduren und INCLUDE-Gruppen, lösen Sie Symbole auf und geben Sie jedem EXEC einen qualifizierten Namen.
3. Ordnen Sie DD-Bindungen und Verkettungen zu und lösen Sie GDGs auf die im Lauf beobachteten absoluten Namen auf.
4. Übersetzen Sie COND oder IF in Berechtigungsregeln und werten Sie sie gegen aufgezeichnete Ergebnisse aus.
5. Markieren Sie Startpunkt, übersprungene Schritte, dynamische Allokationen, Operatoraktionen und neustartrelevante Nebenwirkungen.

Prüfen Sie die Tabelle in zwei Richtungen. Von oben nach unten kontrollieren Sie den Ablauf, vom Erzeuger zu Verbrauchern die Datenherkunft. Eine Datei ohne Erzeuger kann externer Feed, Scheduler-Abhängigkeit oder alter Zustand sein. Eine Ausgabe ohne Verbraucher kann Bericht, Austauschobjekt oder tote Arbeit sein. Löschen Sie sie erst nach Klärung von Betrieb und Aufbewahrung.

Trennen Sie Fakten von Hypothesen. SORT.COPY returned 4 ist eine Tatsache aus dem Spool. RC 4 means duplicate records bleibt eine Hypothese, bis Steueranweisungen und Meldungen sie beweisen. Die Auflösung von APP.BILL.WORK(+1) auf G0123V00 ist historischer Beleg. Dass ein Neustart denselben Namen wählt, ist eine Vorhersage, die Katalog- und Neustartanalyse braucht.

Die Tabelle zeigt auch eine Migrationsgrenze. Programme, JCL-Schranken, Scheduler-Abhängigkeiten, Katalogverhalten und Operatoraktionen bilden gemeinsam das Batchsystem. Eine COBOL-Übersetzung ohne JCL erhält nur die sichtbarste Komponente. Ein moderner Dienst braucht explizite Orchestrierung, dauerhafte Datenidentität, Wiederholungsregeln und beobachtbare Ergebnisse, die das alte Verhalten dort treffen, wo es zählt.

CodeHero liest den gesamten COBOL- und JCL-Baum gemeinsam und prüft das neue System mit einem Parity-Harness gegen aufgezeichneten Produktionsverkehr. Das zählt, weil eine zeilenweise Portierung kein Verhalten wiederfindet, das in Prozedurwahl, DD-Bindungen, GDG-Zustand oder Neustartpraxis lebte.

Modernisierung muss versteckte Reihenfolge sichtbar machen

Die sicherste Modernisierung bildet nicht jede JCL-Anweisung in neuer Syntax nach. Sie bewahrt beobachtbares Verhalten und macht implizite Abhängigkeiten zu benannten, testbaren Verträgen. Ein temporärer Datensatz kann zum Objekt oder zur Staging-Tabelle werden, eine GDG-Übergabe zu einem unveränderlichen Laufartefakt, eine COND-Schranke zu einem expliziten Zustandswechsel. Das Zieldesign darf sich ändern, doch Paritätstests müssen abhängiges Verhalten abdecken.

Beginnen Sie die Spezifikation mit aufgezeichneten Läufen, nicht mit Erinnerung. Wählen Sie Normalläufe, Warnpfade, Erzeuger- und Allokationsfehler sowie Neustarts. Erfassen Sie Eingabeidentitäten, erweiterte Schritte, Ausgaben, Rückgabeklassen und externe Effekte. Produktionsverkehr kann Verhalten belegen, muss aber unter den Sicherheitsvorgaben des Kunden bleiben.

Übernehmen Sie zufällige Eigenheiten nicht blind. Manche Verhaltensweisen sind Vertrag, andere Betriebshilfe oder unentdeckter Defekt. Fragen Sie Besitzer, welche Verbraucher ein Detail benötigen, und schreiben Sie einen Test, der die Entscheidung benennt. Ändert das neue System die Regel bewusst, dokumentieren Sie die genehmigte Abweichung, statt den Paritätsvergleich weichzustellen.

Air-Gap-Ausführung kann nötig sein, wenn Quelle, Spool oder Produktionssätze die Kundengrenze nicht verlassen dürfen. Das betrifft Bereitstellung und Datenverarbeitung und ist keine Compliance-Zertifizierung. Trennen Sie beide Aussagen in Architekturprüfung und Beschaffung.

Ein glaubwürdiger Umstellungsplan beantwortet: Welcher alte Schritt entspricht welcher neuen Operation, wie wird Eingabeidentität fixiert, wie vermeiden Wiederholungen doppelte Effekte, wie werden Warnungen abgebildet, wie setzt ein Teillauf fort, und welcher Beleg beweist Parität? Kann das Team diese Fragen nicht beantworten, hat es die JCL nicht fertig gelesen. Mehr Syntaxstudium schließt die Lücke nicht. Rekonstruieren Sie einen Lauf vollständig, einschließlich allem, was das Member ausließ, dann verliert der Batch sein Geheimnis.