Parametrisierung von Testjobs im z/OS-Umfeld

Für den Aufbau und die Wartung von produktiven Jobs ist im Mainframe-Umfeld in der Regel die Arbeitsvorbereitung zuständig, der für die Verwaltung der Jobs ein Scheduler-Tool zur Verfügung steht.

Testjobs werden im Regelfall von den Entwicklern selbst verwaltet und gestartet. Dies führt in komplexeren Systemen regelmäßig dazu, dass Jobs mit geringen Anpassungen kopiert werden und dadurch in vielfacher Ausführung vorliegen und gepflegt werden müssen.

In der aktuellen Version von IBMs JCL-Interpreter JES2 gibt es die Möglichkeit, mit geringem Aufwand Jobs zu parametrisieren und damit manuelle Änderungen, die oft mit dem ISPF Line Command CHANGE ALL direkt im Job durchgeführt wurden, auszulagern und zu zentralisieren. Des Weiteren gibt es im JES2 die Möglichkeit, Jobs mit geringem Aufwand automatisiert nacheinander auszuführen.

Job-Ablauf/-Verarbeitung anhand eines Beispiels
Folgende Jobs sollen ein minimales Beispiel darstellen. Die Methoden, die in diesem Beispiel gezeigt werden, sind jedoch genauso auf wesentlich größere und komplexere Systeme anwendbar. Für alle in diesem Artikel aufgeführten JCLs und per Include einzubindende Member wird in diesem Beispiel davon ausgegangen, dass diese in einem Verzeichnis, und zwar im TSO.CNTL des aktiven Benutzers, abgelegt sind.

Die folgenden Beispiel-Jobs verarbeiten Posten pro Tag, pro Liegenschaft, pro Kunde. Dazu werden im ersten Job (JOB1) die für diesen Lauf relevanten Posten aus einer Datei gelesen und per SORT-Programm für den folgenden Job zur Verfügung gestellt. Die Verarbeitung kann pro Umgebung (z. B. Entwicklung, Test, etc.) stattfinden. Dazu sind klassischerweise pro Umgebung dieselben Jobs mit lediglich angepassten Dateinamen und Parametern vorbereitet und als Member gespeichert.

In diesem Job zeigt sich auch gleich eine Schwäche des Vorgehens mit CHANGE ALL. Das Kundenkürzel CON als Kurzform für Consist ist ebenfalls in anderem Zusammenhang in der letzten Zeile enthalten (COND). Beim Wechsel vom Kunden CON wären also jedes Mal eine manuelle Korrektur des Jobs an dieser Stelle notwendig.

Der zweite Job (JOB2) verarbeitet die im ersten Job (JOB1) selektierten Sätze und schreibt dazu Datenbank-Einträge. Dabei ist die Angabe des DB-Plans und die STEPLIB pro Umgebung spezifisch.

Die übliche Herangehensweise zur Durchführung dieser Jobs wäre, die in den Kommentaren angegebenen Change-Befehle manuell durchzuführen, um die für den Testlauf benötigten Werte zu setzen. Dazu müssten die meisten Change-Befehle für jeden Job wiederholt werden. Mit steigender Anzahl an Jobs erhöht sich bei diesem Verfahren auch die Wahrscheinlichkeit für Tippfehler, die zu Fehlern in der Testverarbeitung führen.

Es können in diesem Beispiel zwei Arten von Parametern ausgelagert werden:

• Es gibt einmal die umgebungsspezifischen Daten, also Dateipräfix, DB-Plan und STEPLIB.
• Andererseits gibt es die laufspezifischen Parameter, die bisher per CHANGE ALL gesetzt wurden (Kunde, Liegenschaft und Verarbeitungsdatum).

Durch das Auslagern können diese in jeden Job eingebunden, müssen aber nur einmal zentral gesetzt werden.

Für die umgebungsspezifischen Daten können folgende Member angelegt werden:

Die laufspezifischen Parameter könnten wie folgt in einem Member definiert werden:

Die benötigten Werte für den Durchlauf werden in diesem Member vor dem Start des ersten Jobs mit Gültigkeit für alle Jobs eingetragen. Dadurch müssen diese pro Testlauf nur einmal gesetzt werden.
Der Wechsel zwischen Entwicklungs- und Testumgebung findet dadurch statt, dass die Zeile mit dem entsprechenden INCLUDE ein- bzw. auskommentiert wird.
Die Variable DDAT wird automatisch aus anderen Variablen zusammengesetzt.

Der erste Job kann folgendermaßen umgeschrieben werden:

Im EXPORT Statement in Zeile 2 müssen alle Variablen aufgelistet werden, die in Inline-Vorlaufkarten verwendet werden sollen. Mit dem INCLUDE in Zeile 3 wird das Member BUCHEN mit den für diesen Lauf gesetzten Variablen eingebunden. Damit stehen die Variablen im Job zur Verfügung.
Die Variable ISODAT wird nur in diesem Job benötigt, daher wird sie hier gesetzt. Wenn die Variable für mehrere Jobs relevant wäre, sollte diese auch in das Member BUCHEN ausgegliedert werden.

Die Namen der verwendeten Datasets werden alle über Variablen definiert.

Durch die Angabe ",SYMBOLS=EXECSYS" am SYSIN können in dieser Vorlaufkarte Variablen genutzt werden.

Um uns das manuelle Starten des Folgejobs (JOB2) zu sparen, wurde ein weiterer Step an den Job angehängt. Hier wird über das Programm IKJEFT01 der ebenfalls angepasste Folgejob gestartet.

Den zweiten Job muss man dann wie folgt anpassen:

Hier wird im EXEC-Statement auch der PARM-Parameter über eine Variable gesetzt.
In der darauffolgenden Zeile wird auch der Member Name des INCLUDES parametrisiert. Darüber ist es möglich, über Variablen gesteuert, verschiedene Member einzubinden. In den zugehörigen Member STEPEN und STEPTS müssen die STEPLIBS der jeweiligen Umgebung definiert worden sein.

Vereinfachter Jobstart
Das Vorgehen zum Starten der angepassten Jobs hat sich insoweit verändert, dass die benötigten Werte nun alle zentral in einem Member vorgegeben werden. Es sind keine Anpassungen mehr an den Job direkt notwendig. Nach der Anpassung des zentralen Members muss nur der erste Job gestartet werden. Alle weiteren Jobs werden dann automatisch gestartet.

Potenzial für weitere Verbesserungen
Um die Jobläufe weiter zu automatisieren, wären Verarbeitungen umsetzbar, die Ketten von Jobs aus einer sequenziellen Datei einlesen und entsprechend der Vorgabe in der sequenziellen Datei starten. Die Steuerung dieses Verfahrens ist per SORT-Programm umsetzbar. Es werden also nur die unter z/OS zur Verfügung stehenden Standardprogramme benötigt.