So ordnen Sie JCL COBOL zu und warum das wichtig ist

Jeder Großrechner in Unternehmen verwendet zwei eng miteinander verknüpfte Sprachen, die die meisten modernen Entwickler nie selbst geschrieben haben. COBOL implementiert Geschäftslogik, Berechnungen, Dateiverarbeitung, Datensatztransformationen und die Erstellung von Berichten für regulatorische Zwecke. JCL (Job Control Language) steuert die Ausführung dieser Logik und definiert, welche Programme in welcher Reihenfolge, mit welchen Dateien und unter welchen Bedingungen ausgeführt werden und was im Erfolgs- oder Fehlerfall geschieht. Keine der beiden Sprachen ist ohne die andere vollständig. Ein COBOL-Programm weiß nicht, woher seine Eingabedateien stammen oder wohin seine Ausgabedateien gehen; JCL beantwortet beide Fragen, bevor der erste Datensatz gelesen wird.

Für Organisationen, die Mainframe-Systeme warten, prüfen oder modernisieren, ist das Verständnis der Beziehung zwischen JCL und COBOL keine optionale Hintergrundinformation. Es ist die Grundvoraussetzung für alles: Folgenabschätzung vor jeder Änderung, Dokumentation vor jeder Migration, Wissenstransfer vor dem Ausscheiden eines Experten. Der Job, der die nächtliche Abrechnung verarbeitet, der Batchlauf, der vierteljährliche Berichte für die Aufsichtsbehörden erstellt, die Prozedur, die Daten von einem System in ein anderes überträgt – all dies wird durch JCL definiert, durch COBOL ausgeführt und nur von der immer kleiner werdenden Gruppe von Ingenieuren verstanden, die mit beiden Sprachen gearbeitet haben.

Was ist JCL?

JCL steht für Job Control Language. Es handelt sich um die Skriptsprache, die auf IBM-Großrechnersystemen verwendet wird, um Batch-Jobs zur Ausführung einzureichen. JCL verarbeitet selbst keine Daten. Sie gibt dem Betriebssystem Anweisungen zur Programmausführung: welches Programm ausgeführt werden soll, welche Dateien bereitgestellt werden sollen, welche Speicher- und CPU-Ressourcen zugewiesen werden sollen, was bei einem Fehler zu tun ist und in welcher Reihenfolge mehrere Schritte innerhalb eines einzelnen Jobs ausgeführt werden sollen.

Jeder JCL-Job besteht aus drei grundlegenden Anweisungstypen:

Die JOB-Anweisung identifiziert den Job im System und definiert Abrechnungs-, Prioritäts- und Planungsparameter.

Die EXEC-Anweisung gibt das Programm oder die Prozedur an, die in einem Schritt ausgeführt werden soll.

Die DD-Anweisung (Data Definition) definiert die Datensätze, die das Programm lesen oder schreiben wird, einschließlich ihres Speicherorts, Formats und ihrer Disposition.

JCL

//PAYBATCH JOB (ACCT#7), 'PAYROLL RUN',
//          CLASS=A, MSGCLASS=X, NOTIFY=&SYSUID
//*
//STEP010  EXEC PGM=PAYROLL1
//STEPLIB  DD   DSN=PROD.PAYROLL.LOADLIB,DISP=SHR
//EMPFILE  DD   DSN=PROD.PAYROLL.EMPLOYEE,DISP=SHR
//TRANSACT DD   DSN=PROD.PAYROLL.TRANS.D&&DATE,DISP=SHR
//PAYRPT   DD   SYSOUT=A
//SYSOUT   DD   SYSOUT=*
//SYSIN    DD   DUMMY

In diesem Beispiel: PAYBATCH ist die Stellenbezeichnung STEP010 ist ein Schritt der Aufgabe. PGM=PAYROLL1 Der Befehl benennt das auszuführende COBOL-Programm, und die DD-Anweisungen definieren jede Datei, auf die das Programm zugreifen kann. Das COBOL-Programm PAYROLL1 weiß nicht und es kümmert ihn nicht, wo EMPFILE or TRANSACT Die Daten stammen nicht von einem physischen Speicherort, sondern werden einfach anhand ihres DD-Namens gelesen. JCL ermittelt den physischen Speicherort, das Datensatzformat und den Zugriffsmodus, bevor die Ausführung beginnt.

JCL-katalogisierte Prozeduren (PROCs)

Anstatt für jeden Job dasselbe JCL-Muster zu schreiben, definieren Mainframe-Teams katalogisierte Prozeduren (PROCs), die wiederverwendbare Ausführungsmuster kapseln. Eine PROC ist eine Vorlage, die in einer Prozedurbibliothek gespeichert ist; einzelne Jobs referenzieren sie und überschreiben bei Bedarf bestimmte Parameter.

JCL

//PAYPROC  PROC RUNDATE=TODAY
//COMPILE  EXEC PGM=IGYCRCTL,PARM='OBJECT,NODUMP'
//SYSIN    DD   DSN=PROD.COBOL.SRC(&MEMBER),DISP=SHR
//SYSOBJ   DD   DSN=&&OBJSET,DISP=(NEW,PASS),
//              UNIT=SYSDA,SPACE=(TRK,(10,5))
//LKED     EXEC PGM=IEWL,PARM='LIST,LET,XREF'
//SYSLIN   DD   DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSLMOD  DD   DSN=PROD.PAYROLL.LOADLIB(&MEMBER),
//              DISP=SHR
//         PEND

Anruf bei der PROC von einem Arbeitsplatz aus:

JCL

//COMPILE  EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205

Diese einzelne EXEC-Anweisung wird zur Ausführungszeit in die vollständige PROC-Anweisung erweitert, MEMBER und RUNDATE ersetzt, wo immer &MEMBER und &RUNDATE PROCs sind einer der Hauptgründe, warum die JCL-zu-COBOL-Zuordnung komplex ist: Ein Job kann Dutzende von COBOL-Programmen über eine einzige PROC-Referenz aufrufen, und die tatsächlich aufgerufenen Programme hängen von symbolischen Parametern ab, die sich bei jedem Lauf ändern.

Worin besteht der Unterschied zwischen JCL und COBOL?

JCL und COBOL werden oft gemeinsam erwähnt, erfüllen aber völlig unterschiedliche Funktionen. Keines der beiden ersetzt das andere, und beide sind für die Stapelverarbeitung auf Mainframes unerlässlich.

Abmessungen	JCL	COBOL
Zweck	Orchestriert die Ausführung	Implementiert Geschäftslogik
Was es definiert	Jobs, Schritte, Dateien, Bedingungen	Programme, Datenstrukturen, Berechnungen
Wenn es läuft	Vor der Programmausführung (Setup) und nach der Programmausführung (Cleanup)	Während der Programmausführung
Liest/schreibt Daten	Über Datensatzzuordnung (DD-Anweisungen)	Über DATEI-ABSCHNITT und LESE-/SCHREIB-Anweisungen
Fehlerbehandlung	Rückgabecodes, bedingte Schrittausführung	Ausnahmebehandlungsroutinen, PERFORM-Fehlerroutinen
Tragbarkeit	IBM z/OS-spezifisch	Plattformübergreifend mit Compilern portierbar
Wer schreibt es	Systemprogrammierer, Batch-Ingenieure	Anwendungsentwickler
Modernes Äquivalent	CI/CD-Pipeline + Container-Orchestrierung	Anwendungscode (Java, Python, C++)

Die einfachste Art, sich die Beziehung vorzustellen: JCL ist die Bereitstellungs- und Orchestrierungsschicht; COBOL ist die Anwendungsschicht. In einem modernen Cloud-nativen System würden die Aufgaben von JCL durch Kubernetes-Jobmanifeste, Shell-Skripte und CI/CD-Pipeline-Phasen übernommen. Die Aufgaben von COBOL würden durch in Java, Python oder Go geschriebene Anwendungsdienste übernommen.

Wie JCL COBOL aufruft: Die Ausführungskette

Der Weg von einem JCL-Job zur COBOL-Ausführung folgt einer festgelegten Kette. Das Verständnis jedes einzelnen Schrittes ist die Grundlage dafür, zu verstehen, was eine JCL-zu-COBOL-Zuordnung erfassen muss.

Schritt 1: Jobübermittlung. Der JCL-Job wird an das Job-Eingabe-Subsystem (JES) übermittelt. JES reiht den Job in die Warteschlange ein und beginnt mit dem Lesen seiner Anweisungen.

Schritt 2: Schritteinrichtung. Für jeden EXEC-Schritt sucht das System das benannte Programm in der durch die STEPLIB DD-Anweisung angegebenen Ladebibliothek. Wenn keine STEPLIB angegeben ist, durchsucht das System die Systemlinkbibliothek.

Schritt 3: Datensatzzuweisung. Bevor das Programm ausgeführt wird, weist das System alle in diesem Schritt durch DD-Anweisungen definierten Datensätze zu. Dies umfasst das Öffnen von Dateien, die Überprüfung der Existenz von Eingabedatensätzen und das Erstellen von Ausgabedatensätzen.

Schritt 4: Programmausführung. Das COBOL-Programm wird ausgeführt. Es greift über die in der JCL definierten DD-Namen auf Dateien zu. OPEN INPUT EMPFILE in COBOL direkt auf die DD-Anweisung abgebildet EMPFILE in JCL.

Schritt 5: Auswertung des Rückgabecodes. Wenn das COBOL-Programm beendet wird, setzt es einen Rückgabewert (typischerweise 0 für Erfolg, 4 für Warnung, 8 für Fehler, 12 oder 16 für schwerwiegenden Fehler). JCL verwendet COND Parameter oder IF/THEN/ELSE Konstrukte, um anhand dieses Codes zu bestimmen, ob nachfolgende Schritte ausgeführt werden sollen.

Schritt 6: Datensatzdisposition. Nach diesem Schritt verarbeitet das System die in den einzelnen DD-Anweisungen definierten Datensatzdispositionen: behalten, löschen, katalogisieren, aus dem Katalog entfernen oder zum nächsten Schritt übergehen.

Das folgende Beispiel zeigt, wie diese Kette in der Praxis aussieht: JCL links, die entsprechenden COBOL-Elemente rechts:

JCL

//STEP020  EXEC PGM=ACCTREC
//STEPLIB  DD   DSN=PROD.ACCOUNT.LOADLIB,DISP=SHR
//INFILE   DD   DSN=PROD.ACCT.DAILY.INPUT,DISP=SHR     ← maps to COBOL SELECT/ASSIGN
//OUTFILE  DD   DSN=PROD.ACCT.PROCESSED,               ← maps to COBOL SELECT/ASSIGN
//              DISP=(NEW,CATLG,DELETE),
//              UNIT=SYSDA,SPACE=(CYL,(5,2),RLSE)
//RPTFILE  DD   SYSOUT=A                                ← maps to COBOL WRITE report
//SYSOUT   DD   SYSOUT=*

Das COBOL-Programm ACCTREC enthält:

Cobol

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT INFILE    ASSIGN TO INFILE.         *> maps to DD INFILE
           SELECT OUTFILE   ASSIGN TO OUTFILE.        *> maps to DD OUTFILE
           SELECT RPTFILE   ASSIGN TO RPTFILE.        *> maps to DD RPTFILE

       DATA DIVISION.
       FILE SECTION.
       FD  INFILE
           RECORDING MODE IS F
           BLOCK CONTAINS 0 RECORDS
           RECORD CONTAINS 200 CHARACTERS.
       01  ACCOUNT-RECORD.
           05  ACCT-NUMBER    PIC X(10).
           05  ACCT-BALANCE   PIC S9(13)V99 COMP-3.
           05  ACCT-STATUS    PIC X(2).

Das SELECT INFILE ASSIGN TO INFILE im FILE-CONTROL-Abschnitt von COBOL wird eine Verbindung zur DD-Anweisung mit dem Namen hergestellt. INFILE in JCL. Dies ist die grundlegende Zuordnungsbeziehung: COBOL verwendet logische Dateinamen; JCL löst sie in physische Datensätze auf.

JCL-Abendcodes: Was sie bedeuten

JCL-Abbruchcodes (Abbruchcodes) geben an, warum ein Jobschritt unerwartet beendet wurde. Sie erscheinen in der Jobausgabe als S000 (Systemabbruch) oder U0000 (Benutzerabbruch-)Codes. Das Verständnis dieser Codes ist für die Diagnose von Fehlern bei Batch-Jobs unerlässlich.

Abendcode	Typ	Gemeinsame Ursache
S001	System	E/A-Fehler beim Lesen oder Schreiben eines Datensatzes
S013	System	DCB-Attributkonflikt, Datensatzlängen- oder Formatkonflikt zwischen JCL DD und COBOL FD
S0C4	System	Speicherschutzfehler: Das Programm versuchte, auf Speicher außerhalb seines zugewiesenen Bereichs zuzugreifen.
S0C7	System	Datenfehler, Versuch einer arithmetischen Operation mit nicht-numerischen Daten (sehr häufiger COBOL-Abbruch)
S322	System	Zeitlimit überschritten, Auftrag lief länger als im TIME-Parameter zulässig.
S806	System	Das Lademodul wurde nicht gefunden. Das in EXEC PGM= angegebene Programm ist in keiner der durchsuchten Ladebibliotheken vorhanden.
S913	System	Verstoß gegen die Zugriffssicherheit des Datensatzes, Zugriff verweigert durch RACF oder gleichwertige Zugriffsmethode
U0000	Mitglied	Anwendungsdefinierter Programmabbruch, COBOL-Programm aufgerufen STOP RUN mit Benutzercode
U4076	Mitglied	IMS-spezifischer Abbruch, Datenbankzugriffsfehler

Der häufigste Produktionsabbruch, S0C7Dieser Fehler tritt auf, wenn ein COBOL-Programm arithmetische Operationen auf einem Feld durchführt, das Leerzeichen oder nicht-numerische Zeichen enthält. Die typische Ursache ist eine Diskrepanz zwischen dem erwarteten Datenformat im COBOL-Programm und den von JCL gelieferten Daten. Genau diese Art von Diskrepanz deckt die JCL-zu-COBOL-Zuordnung auf, bevor sie zu einem Produktionsausfall mitten in der Nacht führt.

Der COND-Parameter und die bedingte Ausführung

JCL steuert, welche Schritte basierend auf den Rückgabewerten vorheriger Schritte ausgeführt werden. COND Parameter:

JCL

//STEP010  EXEC PGM=VALIDATE,COND=(4,LT)
//STEP020  EXEC PGM=PROCESS, COND=(4,LT,STEP010)
//STEP030  EXEC PGM=CLEANUP, COND=(0,NE,STEP010)

COND=(4,LT) bedeutet: Überspringe diesen Schritt, wenn der Rückgabewert eines vorherigen Schritts kleiner als 4 ist. COND=(4,LT,STEP010) bedeutet: Überspringen Sie diesen Schritt, wenn der Rückgabewert von STEP010 kleiner als 4 ist. COND=(0,NE,STEP010) bedeutet: Schritt 030 wird übersprungen, wenn der Rückgabewert von Schritt 010 nicht gleich 0 ist, d. h. die Bereinigung wird nur ausgeführt, wenn Schritt 010 erfolgreich war.

Modernes JCL verwendet die IF/THEN/ELSE/ENDIF Stattdessen sollte man etwas konstruieren, was besser lesbar ist:

JCL

//IF010    IF (STEP010.RC = 0) THEN
//STEP020  EXEC PGM=PROCESS
//         ENDIF
//IF020    IF (STEP010.RC > 4) THEN
//STEP030  EXEC PGM=ERRORHANDLER
//         ENDIF

Die Zuordnung bedingter Ausführungspfade ist einer der wichtigsten und am häufigsten übersehenen Aspekte der JCL-zu-COBOL-Analyse. Ein COBOL-Programm, das nur ausgeführt wird, wenn ein vorheriger Schritt fehlschlägt, kann Fehlerbehandlungen, Rollback-Logik oder Wiederherstellungsprozeduren enthalten – Funktionalitäten, die völlig unsichtbar bleiben, wenn man nur den COBOL-Quellcode ohne die zugehörige JCL betrachtet.

JCL, COBOL und DB2: Der Drei-Schichten-Stack

Die meisten Mainframe-Transaktionssysteme verwenden neben JCL und COBOL eine dritte Komponente: DB2, die relationale Datenbank von IBM. COBOL-Programme greifen über eingebettete SQL-Anweisungen (EXEC SQL-Blöcke) auf DB2 zu. JCL verwaltet die Verbindung zum DB2-Subsystem und das DBRM (Database Request Module) mithilfe spezifischer DD-Anweisungen.

JCL

//DBRM     DD   DSN=PROD.DBRMLIB.DATA(ACCTREC),DISP=SHR
//SYSPRINT DD   SYSOUT=*

Cobol

       WORKING-STORAGE SECTION.
       EXEC SQL
           INCLUDE SQLCA
       END-EXEC.

       PROCEDURE DIVISION.
       MAIN-LOGIC.
           EXEC SQL
               SELECT ACCT_BALANCE, ACCT_STATUS
               INTO   :WS-BALANCE, :WS-STATUS
               FROM   ACCOUNT_MASTER
               WHERE  ACCT_NUMBER = :WS-ACCT-NUM
           END-EXEC.

           IF SQLCODE NOT = 0
               PERFORM DB2-ERROR-ROUTINE
           END-IF.

Im JCL-COBOL-DB2-Stack stellt JCL die Laufzeitumgebung und den Datenzugriff bereit; COBOL implementiert die Geschäftslogik und greift auf die Datenbank zu; DB2 speichert und ruft Daten gemäß dem im COBOL-Programm eingebetteten SQL ab. Eine vollständige Abhängigkeitsübersicht eines jeden COBOL-Programms, das DB2 verwendet, muss nicht nur die aufrufenden JCL-Jobs enthalten, sondern auch die gelesenen und geschriebenen DB2-Tabellen, die verwendeten Spalten und die anderen Programme, die auf dieselben Tabellen zugreifen. Denn eine Schemaänderung an einer Tabelle wirkt sich auf jedes COBOL-Programm aus, das diese Tabelle referenziert.

Warum die JCL-zu-COBOL-Abbildung für die Modernisierung wichtig ist

Die Zuordnung von JCL zu COBOL ist nicht primär eine technische Aufgabe, sondern vielmehr ein Risikomanagement-Prozess. Jede Änderung an einem Mainframe-System – sei es die Modifizierung eines JCL-Parameters, das Hinzufügen eines Schritts, die Änderung eines Dataset-Namens oder die Modifizierung des von einem Job aufgerufenen COBOL-Programms – hat Auswirkungen, die über die geänderte Komponente hinausgehen. Nur mit einer vollständigen Übersicht über alle vorhandenen Komponenten und deren Verbindungen lassen sich diese Auswirkungen vor einer Änderung präzise abschätzen.

Vor der Migration : Die Migration von Batch-Workloads vom Mainframe in die Cloud erfordert Kenntnisse über die vorhandenen JCL-Jobs, die von ihnen aufgerufenen COBOL-Programme, die zwischen den Schritten fließenden Datensätze, die Ausführungsreihenfolge und das Verhalten bei Fehlern. Ohne diese Übersicht arbeitet das Migrationsteam mit unvollständiger oder gar keiner Dokumentation. Schritte werden übersehen, Abhängigkeiten werden erst im Produktivbetrieb entdeckt und die Umstellungstermine verschieben sich.

Vor jeder Codeänderung : Ein COBOL-Programm, das geändert wird, ohne zu prüfen, welche JCL-Jobs es aufrufen, kann Jobs beeinträchtigen, die unter anderen Bedingungen oder mit anderen Dataset-Konfigurationen laufen. Eine scheinbar lokale JCL-Parameteränderung kann das Verhalten eines COBOL-Programms beeinflussen, das auf bestimmte Dataset-Attribute angewiesen ist. Für eine Auswirkungsanalyse muss die gesamte JCL-COBOL-Dataset-Kette vor jeder Änderung bekannt sein.

Zum Wissenstransfer : Wenn ein COBOL-Entwickler, der zwanzig Jahre lang ein Batch-System betreut hat, in den Ruhestand geht, nimmt er sein Verständnis der Zusammenhänge zwischen JCL-Jobs und COBOL-Programmen mit. Eine dokumentierte Übersicht ist der einzige Mechanismus, um dieses Wissen an das nächste Team weiterzugeben. Ohne sie übernehmen neue Entwickler ein System, das sie nicht sicher modifizieren können.

Für Compliance-Audits : Regulatorische Audits erfordern häufig den Nachweis, dass Finanzberechnungen, Datentransformationen oder Zugriffskontrollen wie dokumentiert funktionieren. Ist die Beziehung zwischen JCL und COBOL nicht dokumentiert, lässt sich dies ohne Reverse Engineering des Systems unter Auditdruck nicht nachweisen.

JCL-Management-Tools und Analyseplattformen

Die Mehrsprachigkeit der Search Console-Daten für diesen Artikel, mit Anfragen in Italienisch, Französisch, Spanisch, Japanisch und Deutsch zu JCL-Management-Tools, spiegelt die globale Verteilung der Mainframe-IT-Community wider und zeigt, wie einheitlich Teams in allen Regionen mit demselben Problem konfrontiert sind: Ihre JCL- und COBOL-Dokumentation ist unvollständig, veraltet oder gar nicht vorhanden.

Die für die JCL-Analyse und -Verwaltung verfügbaren Werkzeuge lassen sich in drei Kategorien einteilen:

IBM-eigene Tools : IBM bietet das Job Entry Subsystem (JES), die JES-Spool-Verwaltung und die IBM z/OS Batch Runtime. Diese übernehmen die Ausführung und Überwachung, bieten jedoch keine programmübergreifende Abhängigkeitsanalyse oder Visualisierung.

Drittanbieter-Jobplaner wie CA7, TWS (Tivoli Workload Scheduler) und Broadcoms ESP Workload Automation verwalten die Stapelverarbeitung von Tausenden von Jobs, bieten abhängigkeitsbasierte Planung und warnen bei Fehlern. Sie verstehen Abhängigkeiten auf Jobebene, analysieren aber in der Regel nicht die in den einzelnen Schritten aufgerufenen COBOL-Programme.

Plattformen für statische Codeanalyse und Abhängigkeitsabbildung : Tools, die JCL- und COBOL-Quellcode analysieren, um ein Strukturmodell zu erstellen, das aufzeigt, welche Jobs welche Programme aufrufen, welche Programme auf welche Datensätze zugreifen und wie Daten im System fließen. Sie bieten die schichtübergreifende Transparenz, die Job-Scheduler und IBM-eigene Tools nicht bieten können: die Beziehung zwischen einer bestimmten JCL-DD-Anweisung und dem zugehörigen COBOL-FILE-CONTROL-Eintrag oder zwischen einem COBOL-Programm, das in einen Datensatz schreibt, und dem nächsten Job, der diesen Datensatz als Eingabe liest.

SMART TS XL gehört zu dieser dritten Kategorie und erweitert sie auf alle Sprachen in der Unternehmensumgebung, COBOL, JCL, PL/I, Assembler, SQL, Java und andere, und bietet so die sprachübergreifende Strukturanalyse, die kein Einzelsprachen-Tool liefern kann.

Wie SMART TS XL Bildet JCL auf COBOL im Unternehmensmaßstab ab

Die manuelle JCL-zu-COBOL-Zuordnung ist für einen einzelnen Job mit drei Schritten machbar. Für eine Organisation mit 50,000 JCL-Jobs, 200,000 COBOL-Programmen und Millionen von Datensatzreferenzen, die sich über vier Jahrzehnte angesammelt haben, ist sie jedoch nicht praktikabel. Die Beziehungen zwischen einer bestimmten Prozedur, den zu ihrem Aufruf verwendeten symbolischen Parametern, den COBOL-Programmen, auf die diese Parameter verweisen, und den von diesen Programmen verwendeten Datensätzen lassen sich in diesem Umfang nicht manuell nachverfolgen.

SMART TS XL Das Programm analysiert JCL- und COBOL-Quellcode, einschließlich Prozeduren mit symbolischer Parameterersetzung, In-Stream-Prozeduren, INCLUDE-Elementen, Überschreibungen und bedingter Ausführungslogik, und erstellt ein einheitliches Querverweismodell, das alle strukturellen Beziehungen im System abbildet. Dieses Modell ist abfragefähig, navigierbar und stets aktuell, da es aus dem Quellcode neu generiert und nicht als manuell aktualisiertes Dokument gepflegt wird.

Das JCL-Erweiterung Die Funktion löst die symbolische Parameterersetzung auf, um die tatsächlich von einer beliebigen Prozedur aufgerufenen Programme und Datensätze anzuzeigen und dabei die von jedem aufrufenden Job vorgenommenen Überschreibungen zu berücksichtigen. Eine Prozedur, die verwendet &PGMNAME Als symbolischer Parameter erscheint er im Modell als alle konkreten Programme, zu denen er bei allen Aufrufern aufgelöst wird, und nicht als unaufgelöste Referenz.

Die Funktion zur Abbildung von Anwendungsabhängigkeiten erstellt den vollständigen Abhängigkeitsgraphen vom JCL-Job über das COBOL-Programm und die DB2-Tabelle bis hin zum nachgelagerten Programm. Dabei werden alle Systemkomponenten und deren Verbindungen dargestellt. Vor jeder Modernisierung kann das Team folgende Fragen beantworten: Welche Jobs rufen dieses Programm auf? Welche Datensätze liest dieses Programm? Welche anderen Programme schreiben in diese Datensätze? Welche Jobs werden als Nächstes ausgeführt?

Die Auswirkungsanalysefunktion generiert eine detaillierte Liste der Konsequenzen für jede vorgeschlagene Änderung: Ändern Sie dieses Copybook und sehen Sie jedes Programm, das es enthält; ändern Sie dieses Dataset-Layout und sehen Sie jede JCL-DD-Anweisung, die darauf verweist; entfernen Sie diesen Schritt aus einem Job und sehen Sie jeden nachfolgenden Schritt, der von seiner Ausgabe abhängig war.

Für Teams, die im Rahmen eines Projekts mit der JCL-zu-COBOL-Zuordnung konfrontiert sind Modernisierung des Altbestands Programms, SMART TS XL bietet die Grundlage, die Modernisierungsanbieter wie Astadia, TSRI, Advanced und andere benötigen, bevor mit den Umstellungsarbeiten begonnen wird: eine vollständige und genaue Bestandsaufnahme der vorhandenen Strukturen, sodass der Umfang der Umstellung durch Analyse und nicht durch Annahmen definiert wird.

Die Karte ist nicht das Gebiet, aber sie ist der Ausgangspunkt.

JCL und COBOL werden auch weiterhin bestehen. Die Batch-Systeme für die Lohn- und Gehaltsabrechnung, die Bearbeitung von Versicherungsfällen, die Erstellung von Berichten für Aufsichtsbehörden und die Abwicklung von Finanztransaktionen werden auch künftig auf Mainframes laufen, während Cloud-Migrationen geplant, genehmigt, finanziert und durchgeführt werden – ein Prozess, der in der Regel Jahre statt Monate dauert. In dieser Zeit müssen die Systeme gewartet, angepasst und verstanden werden.

Die JCL-zu-COBOL-Zuordnung ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess: Das Strukturmodell muss stets aktuell gehalten werden, wenn Programme geändert, Jobs hinzugefügt und Datensätze reorganisiert werden. Teams, die in diese Vorgehensweise investieren, können souverän Änderungen an Systemen vornehmen, die in der Branche größtenteils als Blackboxes betrachtet werden. Teams, die dies nicht tun, nehmen Änderungen an Systemen vor, die sie nicht vollständig überblicken können – in Umgebungen, in denen eine fehlende Abhängigkeit zwar keinen Compilerfehler verursacht, aber mitten in der Nacht während des Batch-Laufs zu einem Produktionsausfall führt.