Job Control Language

Job Control Language (JCL) ist die Steuersprache für Stapelverarbeitungen in einem Großrechnerumfeld und gehört zu den Skriptsprachen. Aufgabe der JCL ist es, die auszuführenden Programme, deren Reihenfolge sowie eine Laufzeitumgebung (Verbindung zu physischer Hardware, also den Ein- und Ausgabegeräten und Dateien) vorzugeben. Die zu einer konkreten Aufgabe gehörenden Programme oder Programmfolgen und die erforderliche Umgebung werden mithilfe der JCL in sogenannten Jobs gebündelt, die so als lauffähige Einheiten im Rahmen des Multitasking definiert werden. Die Jobs stellen eine den eigentlichen Anwendungsprogrammen übergeordnete Stufe auf Systemebene dar und sind insofern mit den Shell-Skripten bei Unix oder den Batch-Dateien bei MS-DOS oder Windows vergleichbar.

Dieser Artikel beschreibt die JCL unter IBM-z/OS. Andere Großrechner-Betriebssysteme wie VSE verwenden ebenfalls JCL genannte Sprachen, die jedoch eine ganz andere Syntax haben.

Entwicklung

Die heute auf Systemen unter z/OS eingesetzte JCL wurde 1964 für OS/360 IBM entwickelt. Bei der Weiterentwicklung wurde Abwärtskompatibilität gewährleistet.

Ursprünglich wurde JCL auf Lochkarten gespeichert. Die Jobs wurden dann per Kartenleser ins System eingespielt. Heute sind JCL-Bibliotheken Partitioned Datasets mit Datensatz-Format FB (Fixed Blocked) und Datensatz-Länge 80 üblich. Die Bezeichnung Karte für eine JCL-Anweisung ist aber immer noch gebräuchlich.

Verarbeitung

JCL wird vom Job Entry Subsystem (JES2 oder JES3) eingelesen und interpretiert.

Auch die Subsysteme, Systemfunktionen (Started Tasks) und die Anmeldungen eines Benutzers am TSO verwenden JCL-Prozeduren zur Initialisierung.

Anweisungen

Alle Anweisungen beginnen mit //. Kommentare werden mit //* gekennzeichnet. Es ist möglich, Daten für die Standardeingabe direkt in der JCL mitzugeben.

Die wichtigsten Anweisungen sind:

• JOB (Informationen über auszuführende Batchverarbeitung)
• EXEC (führe ein Programm oder eine Prozedur aus)
• DD (Data Definition, Zuordnung „file“ im Programm zu physischer Datei)
• PROC und PEND zum Definieren lokaler oder globaler Prozeduren

Eine Programmausführung, die mit einer EXEC-Anweisung gestartet wird, wird Step (Verarbeitungsschritt) genannt. Es ist möglich, die Durchführung von Steps von den Rückgabewerten früherer Steps (Condition Code) abhängig zu machen. Dafür gibt es eine einfache IF-THEN-ELSE Logik, mithilfe derer man Blöcke von Anweisungen (Steps) bedingt ausführen kann. Schleifen sind bei der Job-Abarbeitung nicht möglich, die Steps werden immer sequentiell ausgeführt.

Ein direkter Rückbezug auf Ein- und Ausgabedaten eines vorhergehenden Steps ist möglich, um diese in folgenden Steps weiterzuverwenden.

Die Verwendung von Variablen (Symbols) in der JCL ist möglich, unterliegt allerdings einigen Einschränkungen. Variablen können nur dazu verwendet werden, um Teile der JCL vor der Ausführung des Jobs zu ändern. Zur Laufzeit können lediglich die Rückgabewerte („return codes“) der einzelnen Steps den Job-Ablauf beeinflussen.

Ein Job wird entweder automatisiert zeitgesteuert über ein Scheduling System gestartet oder kann auch direkt angestoßen werden (meist über ISPF).

Beispiele

Beispiel 1:

//JOB1   JOB (12345),MSGCLASS=X,NOTIFY=SYSPROG1
//STEP1 EXEC PGM=IEFBR14
//DD1     DD DSN=AB.CD.EFGH,DISP=(OLD,DELETE)

Dieser Job löscht die katalogisierte Datei AB.CD.EFGH. Das ausgeführte Programm IEFBR14 ist ein Dummy-Programm. Dieses ist nur notwendig, weil der JCL-Interpreter bei jedem Step einen Programm- oder Prozeduraufruf erwartet. Der Benutzer SYSPROG1 wird nach Ende des Jobs über den Ausführungsstatus informiert. In diesem Fall Return-Code 0 (=OK) oder „JCL ERROR“, falls der Job fehlerhaft kodiert wurde oder wenn die entsprechende Datei nicht existiert.

Die Zuordnung der Datei AB.CD.EFGH zum DD-Namen DD1 ist in diesem Fall beliebig, weil sie vom aufgerufenen Programm nicht verwendet wird.

Ablauf (vereinfacht):

• Die Datei wird alloziert (1. DISP-Parameter OLD → exklusiver Zugriff) und dem DD-Namen DD1 zugeordnet. (Step-Preallocation)
• Das Dummy-Programm wird aufgerufen.
• Die Datei wird gelöscht (2. DISP-Parameter DELETE, Step-Nachverarbeitung)

Beispiel 2:

//JOB2     JOB (123456),MSGCLASS=X
//STEP1   EXEC PGM=SALDO
//STEPLIB   DD DISP=SHR,DSN=BH.PROD.LOAD
//          DD DISP=SHR,DSN=BH.PROD.LOAD2
//INPUT     DD DISP=SHR,DSN=BH.DETAIL.BESTAND
//LISTE     DD SYSOUT=*

Hier wird das Anwendungsprogramm SALDO ausgeführt, das Lademodul wird zunächst in den Bibliotheken BH.PROD.LOAD und BH.PROD.LOAD2 gesucht, danach in Systembibliotheken. Beim lesenden Zugriff auf Dateien können mehrere Datensätze unter einem DD-Namen verkettet werden.

Das Programm SALDO soll seine Eingabedaten aus der Datei BH.DETAIL.BESTAND lesen und die Ergebnisse in eine Spool-Datei schreiben (DD-Name LISTE). Die Zuordnung des Eingabe-Datensatzes zum DD-Namen „INPUT“ bzw. der Ausgabe zu „LISTE“ ist vom Programm vorgegeben (logischer Dateiname).

Beispiel 3:

//JOB3    JOB (123456),MSGCLASS=X
//STEP1  EXEC PGM=IDCAMS
//DDIN     DD DISP=SHR,DSN=SYSPROG.SMF.AUSWERT
//DDOUT    DD DISP=(NEW,CATLG),DSN=SYSPROG.SMF.HISTORY(+1),
//            UNIT=SYSDA,SPACE=(CYL,(15,15),RLSE),DCB=*.DDIN
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  REPRO INFILE(DDIN) OUTFILE(DDOUT)
/*

Hier wird mit dem System-Utility IDCAMS die Datei SYSPROG.SMF.AUSWERT in eine neue Generation der „Generation Data Group“ (GDG) SYSPROG.SMF.HISTORY kopiert. Das Protokoll dieser Aktion (SYSPRINT) wird in eine Spool-Datei geschrieben, die Steueranweisung für IDCAMS (REPRO-Command) wurde in der Standard-Eingabe SYSIN kodiert, welche mit /* abgeschlossen wird.

Beispiel 4

//JOB4    JOB (123456),MSGCLASS=X
//STEP1   EXEC PGM=P1
...
//STEP2   EXEC PGM=P2,COND=(4,GT,STEP1)
...
//STEP3   EXEC PGM=P3,COND=(8,LE)
...

Programme unter zOS geben in der Regel einen Condition code zurück, der mit dem COND-Parameter getestet werden kann, vergleichbar mit dem Return Code unter Unix.

In diesem Beispiel wird STEP1 ausgeführt und anschließend STEP2 nicht ausgeführt, wenn der 4 größer ist als der Condition Code aus STEP1. Mit anderen Worten, STEP2 wird nur ausgeführt, wenn der Condition Code aus STEP1 größer oder gleich 4 ist.

STEP3 mit dem COND-Parameter ohne Jobstep spezifiziert, dass dieser Step dann nicht ausgeführt wird, wenn 8 kleiner oder gleich irgendeinem condition code eines vorhergehenden job steps ist – mit anderen Worten, wenn irgenein vorheriger Job Step einen Condition code von kleiner als 8 hatte.

Trivia

Fred Brooks, bis 1964 Projektleiter des OS/360-Projekts bei IBM, scherzte 2004 bei einem Vortrag anlässlich „40 Jahre System/360“, JCL sei „die schlechteste Programmiersprache, die jemals irgendwann von irgendjemandem zu irgendeinem Zweck entwickelt wurde, und das unter meiner Leitung. […] Es ist eine Jobsteuersprache für alle sechs echten Programmiersprachen“. IBM selbst benutzt dieses Zitat von Brooks in den eigenen Schulungsunterlagen, um zu verdeutlichen, was JCL ist und welchem Zweck es dient.

Literatur

• Michael Winter: MVS/ESA JCL: Einführung in die Praxis. Oldenbourg Wissenschaftsverlag, 1999, ISBN 978-3-486-25058-9
• Gary DeWard Brown, Michael Teuffel: zOS/JCL: Job Control Language im Betriebssystem z/OS MVS. Oldenbourg Wissenschaftsverlag, 2004, ISBN 978-3-486-27397-7

Weblinks

• Originalhandbuch MVS JCL User’s Guide
• Originalhandbuch MVS JCL Reference
• Interaktive Kurzeinführungen in JCL und ISPF