Das Kefk Network Wiki befindet sich im Testbetrieb.

Job Control Language

Aus Kefk.

Wechseln zu: Navigation, Suche

JCL (Job Control Language) ist die Steuersprache für Stapelverarbeitungen in einem Großrechnerumfeld. Die heute noch auf Systemen unter z/OS eingesetzte JCL wurde 1964 für OS/360 entwickelt. Während der Großrechner (wie die übrige EDV) in den letzten Jahrzehnten eine enorme Entwicklung durchgemacht hat, sind an der JCL nur wenige Verbesserungen vorgenommen worden.

Die JCL hat zwei Eigenschaften, die im Verlauf der Modernisierung interaktiver Systeme zunehmend aus den Augen verloren werden: Einerseits lassen sich Ausführungen von Software zur Gänze im Voraus planen und ohne jegliche Interaktion im Hintergrund ablaufen. Andererseits ist die vollständige Entkoppelung jeglicher physikalischer Gegebenheiten (wie Dateinamen, Druckergeräte etc) aus der ablaufenden Software isoliert und in die JCL verlagert. Dadurch lassen sich Abläufe gut und flexibel planen, die viele Stunden oder Tage Rechnerleistung erfordern. Diese hohe Funktionalität lässt sich durch die nicht eben moderne aber einfache Syntax nicht unbedingt leicht erschließen. Außerdem musste bei Erweiterungen der JCL volle Abwärtskompatibilität gewährleistet sein.

Ursprünglich wurde JCL auf Lochkarten gespeichert, heute sind JCL-Bibliotheken Partitioned Datasets mit Recordformat FB (Fixed Blocked) und Recordlänge 80.

JCL wird von JES2 oder JES3 eingelesen und interpretiert. Alle Anweisungen beginnen mit '//'. Kommentare werden mit '//*' gekennzeichnet und nach '// ' findet keine Verarbeitung mehr statt. Es ist möglich, 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 zum definieren lokaler oder globaler Prozeduren

Diese wenigen Statements reichen in der Praxis für schätzungsweise 95% der Jobs aus. Die umfangreiche JCL-Reference (etwa 700 Seiten) geht auf alle spezielleren Anforderungen ein.

Eine Programmausführung, die mit EXEC gestartet wird, nennt man Step. 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. Direkter Rückbezug auf Ausgabedaten eines vorhergenden Steps sind möglich, um diese als Eingebabedaten folgender Steps zu verwenden. Schleifen sind bei der Jobabarbeitung nicht möglich, die Steps werden immer sequentiell ausgeführt. D.h. die „Intelligenz“ eines Jobs steckt zum Großteil in den aufgerufenen Programmen. Die Aufgabe der JCL besteht ja im Grunde darin, den Programmen eine Laufzeitumgebung vorzugeben (Verbindung zu physischer Hardware, E/A und Dateien)

Die Verwendung von Variablen (Symbols) in der JCL ist möglich. Dies ist allerdings vielen Einschränkungen unterworfen. Diese können nur dazu verwendet werden, um Teile der JCL (z.B. Dataset-Namen) VOR Ausführung des Jobs zu ändern, d.h. dadurch wird nur die Jobgenerierung vereinfacht. Zur Laufzeit beeinflussen nur die Return-Codes der einzelnen Steps die bedingte Ausführung anderer Steps.

Ein Job wird entweder automatisiert zeitgesteuert über einen Scheduler gestartet oder kann auch von einem Operator direkt angestoßen werden (meist über ISPF)

Ein neuer Job wird in der Praxis meist dadurch erstellt, dass bestehende Jobs kopiert und entsprechend adaptiert werden.

Im Grunde werden alle Subsysteme eines Großrechners über die Steuersprache JCL gestartet. Auch die Anmeldung eines Benutzers, der danach interaktiv am System arbeitet (im TSO und / oder ISPF), arbeitet mit diesem Formalismus.

Beispiele für JCL: 

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

Dieser Job löscht den katalogisierten Dataset AB.CD.EFGH . Das ausgeführte Programm IEFBR14 ist ein Dummyprogramm. 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) bzw „JCL ERROR“, falls der Job fehlerhaft kodiert wäre oder wenn die entsprechende Datei nicht existiert.

Die Zuordnung des Datasets AB.CD.EFGH zum DD-Namen DD1 ist in diesem Fall beliebig, weil das Dataset vom aufgerufenen Programm nicht verwendet wird.

Ablauf (vereinfacht):

  • Das Dataset wird allokiert (1. DISP-Parameter OLD => exklusiver Zugriff) und den DD-Namen DD1 zugeordnet. (Step-Preallocation)
  • Das Dummy-Programm wird aufgerufen.
  • Das Dataset wird gelöscht (2. DISP-Parameter DELETE, Step-Nachverarbeitung)
Tip für Fortgeschrittene
Wird das Dataset mit den Dispositionsparametern DISP=(MOD,DELETE) angesprochen, ist der Return-Code in jedem Fall 0, auch wenn das Dataset zuvor noch nicht existiert hat. Allerdings muss in dem Fall zwingend eine Space-Angabe kodiert werden: SPACE=(TRK,1), da das Dataset durch MOD kurzfristig angelegt wird, wenn es nicht existiert! 


//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 ausführbare Lademodul befindet sich in der Bibliothek BH.PROD.LOAD oder LOAD2. Beim lesenden Zugriff auf Dateien können Datasets unter einem DD-Namen verkettet werden. Die Suche nach dem Programm erfolgt sequentiell, bis es gefunden wird. Würde sich in BH.PROD.LOAD und in LOAD2 ein Programm „SALDO“ befinden, so würde immer das erste genommen. Der Programminput im Dataset BH.DETAIL.BESTAND und die Ergebnisliste sollen in ein Spoolfile geschrieben werden (DD-Name LISTE). Die Zuordnung des Input-Datasets zum DD-Namen „INPUT“ bzw. des Outputs zu „LISTE“ ist zwingend, da das Programm unter diesem DD-Namen die Eingabedaten erwartet. 


//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 ein Spoolfile geschrieben, die Steueranweisung für IDCAMS (REPRO-Command) wurde im Standardinput SYSIN kodiert, welcher mit /* abgeschlossen wird.

Siehe auch: Job

Andere Mainframebetriebssysteme wie VSE verwenden ebenfalls JCL genannte Sprachen, die jedoch eine komplett andere Syntax haben.

Weblinks

Wikipedia
 Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Job_Control_Language, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.
Von „http://www.kefk.org/wiki/Job_Control_Language“
Persönliche Werkzeuge