Konzept der Job-Klassen

Die Verwendung von Job-Klassen ermöglicht der Systembetreuung eine Klassifizierung von Benutzer-Jobs.

Das Konzept der Job-Klassen trägt verschiedenen Anforderungen Rechnung.

1. Über die Job-Klassen und deren Zuordnung zu den Job-Schedulern kann ein optimaler Auftragsmix erzeugt werden (z.B. viele kurzlaufende Jobs, wenige langlaufende Jobs).Letztendlich trägt dies zu einer ausgewogenen Systemauslastung bei. Außerdem besteht die Möglichkeit, mit Hilfe der Zugriffsrechte zu den Job-Klassen, Privilegien der Job-Steuerung unter den Benutzern zu verteilen.

2. Eine zusätzliche Zugangskontrolle zum System kann erreicht werden, indem die Systembetreuung den Benutzern Nutzungsrechte für bestimmte Job-Klassen gibt. Gibt der Benutzer in den Kommandos SET-LOGON-PARAMETERS bzw. ENTER-JOB keine Job-Klasse an, so wird sein Job in einer Standard-Job-Klasse geführt. Die Systembetreuung hat die Möglichkeit, Job-Klassen zu definieren, zu modifizieren oder zu löschen. Dazu steht das Dienstprogramm JMU zur Verfügung, das im Handbuch „Dienstprogramme“ [15] beschrieben ist.

3. Da sich Jobs durch die Benutzeranforderungen unterscheiden, müssen sie auch von den Job-Schedulern unterschiedlich behandelt werden.

Die Beschreibung einer Job-Klasse basiert auf einer Vielzahl von Angaben. Auf Grund vielschichtiger Möglichkeiten, Job-Eigenschaften zu kombinieren, ist es theoretisch denkbar, für jede Job-Merkmal-Kombination eine eigene Job-Klasse zu definieren.
Eine solche Vorgehensweise geht allerdings stark zu Lasten der Transparenz.

Die Systembetreuung sollte demnach die Job-Klassen nach den Kriterien definieren, die für den täglichen Produktionsbetrieb wichtig sind.

Mit dem Dienstprogramm JMU (Anweisung DEFINE-JOB-CLASS) legt die Systembetreuung u.a. folgende Eigenschaften und Vereinbarungen für eine Job-Klasse fest:

• Job-Klassenname

• Zuständiger Stream oder Default-Stream

• Dringlichkeit (Gewichtung) der Job-Klasse

• maximale Anzahl von Jobs, die in der Job-Klasse gleichzeitig ablaufen können

• Anzahl der Jobs, die idealerweise in der Job-Klasse laufen sollen

• Auftragstyp

• Job- und Task-Scheduling-Priorität

• Erlaubnis für das Starten von Repeat-Jobs

• Wiederholungsrhythmus für Repeat-Jobs

• maximal zu verbrauchende CPU-Zeit

• Start-Attribute

Während die Job-Scheduling-Priorität das Starten des Jobs beeinflusst, bezieht sich die Task-Scheduling-Priorität auf den Ablauf des gestarteten Jobs (= Ausführungspriorität).

Als mögliche Werte gelten für die Job-Steuerung die Prioritäten 1 bis 9 und für die Task-Steuerung die Prioritäten 30 bis 255.

Je niedriger der angegebene Wert ist, desto höher ist die Priorität.

Der Begriff Auftragstyp trifft eine Unterscheidung zwischen Batch- und Dialog-Jobs. Für beide Auftragstypen lassen sich Job-Klassen definieren, wobei allerdings zu beachten ist, dass die Dialog-Job-Klassen keinem Job-Scheduling unterliegen.
Hier wird lediglich auf die Einhaltung der Klassen-Grenzen geachtet, d.h. auf die Zahl der in der Job-Klasse geführten Dialog-Jobs und die Zugangsberechtigung zu dieser Job-Klasse.

Beispiel 1

Einteilung der Job-Klassen nach der zu verbrauchenden CPU-Zeit:

• Job-Klasse JCSHORT
  für Jobs, die nicht mehr als 5 CPU-Sekunden verbrauchen werden

• Job-Klasse JCNORMAL
  für Jobs, die nicht mehr als 500 CPU-Sekunden verbrauchen werden

• Job-Klasse JCLONG
  für Jobs, die mehr als 500 CPU-Sekunden verbrauchen werden

Beispiel 2

Einteilung der Job-Klassen nach dem Start-Zeitpunkt:

• Job-Klasse JCEXPRES
  für Jobs, die mit dem Start-Attribut IMMEDIATE ausgerüstet sind

• Job-Klasse JCNORMAL
  für Jobs, die keinen besonderen Zeitpunkt zum Start aufweisen

• Job-Klasse JCTERMIN
  für Jobs, die zu einem bestimmten Zeitpunkt (Datum/Uhrzeit) gestartet werden sollen (Termin-Jobs)

Neben den Job-Klassen für Benutzer-Jobs existiert die vordefinierte System-Job-Klasse mit Namen $SYSJC für System-Jobs. Diese System-Job-Klasse sollte den Benutzern nicht zur Verfügung stehen, da $SYSJC alle Auftragstypen zulässt und keinerlei Begrenzung hinsichtlich der Klassenattribute enthält.

Es bestehen grundsätzlich zwei Möglichkeiten, Job-Klassen zu definieren, zu modifizieren oder zu löschen:

1. Die statische Definition ist in der Datei $TSOS.SJMSFILE hinterlegt. Diese Datei ist die Basis für jeden Systemlauf. Sie wird mit dem Dienstprogramm JMU erzeugt und verwaltet.

   Folgende JMU-Anweisungen stehen zur Verfügung:

   DEFINE-JOB-CLASS
   MODIFY-JOB-CLASS
   DELETE-JOB-CLASS
   GRANT-JOB-CLASS-ACCESS
   SET-JOB-CLASS-DEFAULT
   SET-POSIX-JOB-CLASS-DEFAULT 
   

   Will die Systembetreuung die Attribute einer Job-Klasse modifizieren oder die Zuordnung einer Benutzerkennung zu einer Job-Klasse in der Datei $TSOS.SJMSFILE ändern, so wirken sich diese Änderungen erst im nächsten Systemlauf aus.

2. Die dynamische Definition bezieht sich nur auf den aktuellen Systemlauf. Sie wird ebenfalls mit dem Dienstprogramm JMU verwaltet, wobei der Bearbeitungsmodus SET-MODIFICATION-MODE=*SYSTEM eingestellt sein muss. Es stehen die selben JMU-Anweisungen wie oben zur Verfügung. Bei SET-MODIFICATION-MODE=*ALL werden die Änderungen auch in die Datei $TSOS.SJMSFILE übernommen.

   Darüber hinaus gibt es Eingriffsmöglichkeiten über die Kommandoschnittstelle.
   Mit folgenden Kommandos reagiert die Systembetreuung kurzfristig und schnell auf Überlastsituationen, ohne die Systemdatei $TSOS.SJMSFILE ändern zu müssen:

   HOLD-JOB-CLASS
   MODIFY-JOB-CLASS
   RESUME-JOB-CLASS