Aufbau von Kommandodateien

Eine Kommandodatei, die vom Operator an der Konsole gestartet wird, ist eine SAM- oder ISAM-Datei bzw. ein Bibliothekselement (Typ J) auf gemeinschaftlichen Datenträgern. Die Datensätze dürfen beliebige Operatorkommandos enthalten, unter bestimmten Voraussetzungen auch privilegierte und Benutzerkommandos. Die RUN-Kommandofolge darf kein SET-LOGON-PARAMETERS- oder EXIT-JOB-Kommando enthalten. Die Datensätze der Kommandodatei haben entweder feste oder variable Satzlänge, wobei die maximale Satzlänge allerdings 201 Byte beträgt. Es werden keine Fortsetzungszeilen unterstützt.
Die Systembetreuung kann die Kommandodatei durch die Vergabe eines Ausführungskennwortes gegen unberechtigte Ausführung durch den Operator schützen. Die Kommandodatei wird vom System nur dann verarbeitet, wenn der Operator im RUN-Kommando das passende Kennwort angibt. Das mögliche Kennwort wird in der CONSLOG-Datei nicht protokolliert.

RUN-Kommandofolgen können beliebig viele Kommandos aufnehmen. Die Systembetreuung sollte beim Aufbau der Kommandofolge nach spätestens 30 Kommandos das Kommando ASTOP einfügen, um einen strukturierten Ablauf der Kommandos zu gewährleisten. Eine Unterbrechung ist auch dann ratsam, wenn die Ausführung eines Kommandos die vollständige Abarbeitung des vorhergehenden bzw. den Aufruf abhängiger Funktionen bedingt.
Stehen beispielsweise 10 Kommandos in der RUN-Kommandodatei, werden diese Kommandos hintereinander eingelesen und bearbeitet. Wird in der Kommandofolge das Kommando SHOW-PENDING-MSG ausgeführt, sollte die Prozedur nach diesem Kommando mit einem ASTOP-Kommando unterbrochen werden. Der Operator kann daraufhin evtl. ausstehende Fragen beantworten. Nach Ablauf der Wartezeit oder einem AGOGO wird die Kommandofolge weiter bearbeitet.

Ein Vorteil einer mit ASTOP-Kommandos gegliederten RUN-Datei ist, dass die Kommandofolge während der Ausführung nicht unnötig Klasse-4-Speicher belegt.
Das System liest eine so aufgebaute und umfangreiche Kommandodatei abschnittsweise in den Klasse-4-Speicher, d.h. von einem ASTOP-Kommando bis zum folgenden, und führt jeweils den eingelesenen Dateiabschnitt aus, bevor es einen neuen einliest.

Sind DSSM-Kommandos Bestandteile der Kommandodatei, sollte die Systembetreuung Folgendes beachten:
Eine eigene Task arbeitet die DSSM-Kommandos ab. Kommandos, die erst eingegeben werden dürfen, wenn das jeweilige Subsystem geladen ist, müssen warten, bis die DSSM-Kommandos abgearbeitet sind. Entsprechend ist auch an dieser Stelle das Kommando ASTOP in die Kommandodatei aufzunehmen.

Die Kommandodatei CMDFILE (Bibliothekselemente sind nicht zulässig) kann eine Folge von Operatorkommandos enthalten, die bei jedem Systemstart unverändert ablaufen. Sie enthält z.B. Aufrufe für die folgende Kommandofolge:

DCSOF

Kommandodatei (Start Option File) zur Inbetriebnahme des Datenkommunikationssystems (DCS)

Beispiel für eine CMDFILE

/MODIFY-JOB-CLASS CLASS-NAME=JCDIALOG,C-L=0                               1.
/MODIFY-JOB-CLASS CLASS-NAME=TSOSDIA,C-L=0                                2.
/MODIFY-JOB-CLASS CLASS-NAME=JCBATCH,C-L=40                               3.
/SET-MSG-SUPPRESSION MSG-ID=(BLS0980,JMS0154),CONSOLE=C0                  4.
/DCSTART DCSOF=SOF.ACT.DCM8                                               5.
/ASTOP                                                                    6.
/MOD-TASK-CAT CATEG-NAME=DIALOG,WEIGHT-CODE=400,MIN-ACT=35,MAX-ACT=50     7.
/MOD-TASK-CAT CATEG-NAME=BATCH,WEIGHT-CODE=10,MIN-ACT=5,MAX-ACT=20        8.
/MOD-TASK-CAT CATEG-NAME=TP,WEIGHT-CODE=500,MIN-ACT=20,MAX-ACT=40         9.
/IMPORT-PUBSET PUBSET=L                                                  10.
/ATTACH-DEVICE (X3,X4,X5,S1,S3,K7,X0,Y3)                                 11.
/SET-DISK-P V=(PRI009,PRI010,PRI037,PRI038,SESAMA),USER=SHARE,ASS=OPER   12.
/SET-DISK-P V=(WORK11,SLED),USER=SHARE,ASS=OPER                          13.
/START-SUBSYS SUBSYS-NAME=MSCF,SUBSYS-PARAM='FILE=$TSOS.RFA.MSCFSTART'   14.
/START-SUBSYS SUBSYS-NAME=SPOOL,SUBSYS-PARAM='RSO=STD'                   15.
/ASTOP                                                                   16.
/MODIFY-JOB-CLASS CLASS-NAME=JCDIALOG,CLASS-LIMIT=20                     17.
/MODIFY-JOB-CLASS CLASS-NAME=TSOSDIA,CLASS-LIMIT=4                       18.

1. Keine Jobs für die Jobklasse JCDIALOG zulassen.

2. Keine Jobs für die Jobklasse TSOSDIA zulassen.

3. Maximal 40 Jobs für die Jobklasse JCBATCH zulassen.

4. Meldungen mit den Meldungsnummern BLS0980 oder JMS0154 werden an der Konsole C0 unterdrückt.

5. Laden des Datenkommunikationssystems.

6. Kommandodatei anhalten, bis das Datenkommunikationssystem geladen ist.

7. Anzahl und Dringlichkeit von Tasks für die Kategorie DIALOG festlegen.

8. Anzahl und Dringlichkeit von Tasks für die Kategorie BATCH festlegen.

9. Anzahl und Dringlichkeit von Tasks für die Kategorie TP festlegen.

10. Pubset L importieren.

11. Geräte dem System zuschalten.

12. Vorgaben setzen für die Überwachung von Platten.

13. Vorgaben setzen für die Überwachung von Platten.

14. MSCF-Kommunikation aktivieren.

15. Laden des Subsystems SPOOL mit automatischem Laden von RSO.

16. Kommandodatei anhalten, bis SPOOL geladen ist.

17. Maximal 20 Jobs für die Jobklasse JCDIALOG zulassen.

18. Maximal 4 Jobs für die Jobklasse TSOSDIA zulassen.

Mit dem Systemparameter NBCONOPI=Y kann ein System beantragt werden, bei dem auch bei physikalischen Konsolen ein Logon nötig ist.
In einem solchen System ist also z.B. die Eingabe eines RUN-Kommandos an einer physikalischen Konsole nur nach einem erfolgreichen SET-LOGON-PARAMETERS und einem entsprechenden REQUEST-OPERATOR-ROLE möglich.

Wird bei Verwendung des Systemparameters NBCONOPI=Y der Dateiname der RUN-Datei ohne Benutzerkennung angegeben, wird die Datei zuerst unter der Kennung des Operators, dann unter der im Systemparameter NBRUNUID angegebenen Kennung und zuletzt unter der Benutzerkennung TSOS gesucht. Da das Privileg OPERATING das Privileg TSOS nicht mehr voraussetzt, muss die RUN-Datei ggf. „shareable“ gemacht werden.

Bei Verwendung des Systemparameters NBCONOPI=Y kann nicht jeder Operator die Kommandos AGOGO oder CANCEL-RUN-PROCESS für jede RUN-Sequenz eingeben, auch wenn er über die notwendigen Berechtigungsschlüssel verfügt.
Die beiden Kommandos sind nur dann zulässig, wenn mindestens eine der folgenden Bedingungen erfüllt ist:

• die Benutzerkennung des Aufrufers stimmt mit der Kennung überein, unter der das RUN-Kommando abgesetzt wurde

• die Benutzerkennung des Aufrufers ist TSOS

• das RUN-Kommando wurde von einem berechtigten Benutzerprogramm mit generiertem Berechtigungsnamen eingegeben

• der Aufrufer des RUN-Kommandos hat sich vom System abgemeldet

Beim Hochfahren des Systems wird die CMDFILE abgearbeitet und dabei so behandelt wie ein abgesetztes RUN-Kommando auf diese Datei von der Hauptkonsole. Hier ist vorher kein SET-LOGON-PARAMETERS- und REQUEST-OPERATOR-ROLE-Kommando nötig, denn für diese CMDFILE und nur bei Startup wird die Berechtigungsprüfung anhand von Berechtigungsschlüsseln so durchgeführt, als wären der Hauptkonsole alle Berechtigungsschlüssel zugewiesen. Alle aus der CMDFILE aufgerufenen RUN-Kommandos genießen ebenfalls dieses Privileg.

Das Kommando RUN und die mit ihm logisch verbundenen Kommandos (z.B. AGOGO und CANCEL-RUN-PROCESS) sind einer Benutzertask auch mit OPERATING-Privileg nicht erlaubt. Hier sind SDF-P-Prozeduren anwendbar, in denen auch Kommandos des Privilegs OPERATING benutzt werden können.