Job Entry Subsystem

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Das Job Entry Subsystem (JES) ist ein Subsystem unter z/OS auf IBM-Großrechnern.

In den Anfängen der IBM-Großrechner war die sogenannte Stapel- bzw. Batchverarbeitung die einzig mögliche Form der Datenverarbeitung. Sogenannte Jobs wurden damals auf Lochkarten codiert, über Lochkartenleser in das System eingelesen und sequentiell abgearbeitet. Auch wenn heute keine Lochkarten mehr verarbeitet werden, spielt die Stapelverarbeitung weiterhin eine wichtige Rolle. Sie wird heute vornehmlich für die automatisierte Verarbeitung, oft für die sogenannte Massenverarbeitung, genutzt. Die Steueranweisungen für die Stapelverarbeitung wurden damals wie heute in der Job Control Language (JCL) codiert.

Das Job Entry Subsystem steuert als Subsystem des Betriebssystems z/OS die auszuführenden Jobs. Es wird vom Betriebssystem benötigt, um Jobs entgegenzunehmen, aufzuarbeiten, zu disponieren, an das Betriebssystem zur Ausführung weiterzuleiten und die Ausgaben des Jobs entgegenzunehmen. Kurz gesagt, bringt das JES die Jobs ins Betriebssystem und nimmt die Ausgaben der Jobs entgegen.

Für z/OS existieren zwei Job Entry Subsystems: JES2 und JES3, wobei JES2 am weitesten verbreitet ist.

Die Verarbeitung eines Jobs durch das JES untergliedert sich in drei Teile:

  1. Preprocessing:
    In diesem Teil wird die eigentliche Datei gelesen und interpretiert. Tritt hier ein Syntaxfehler auf, bricht die Bearbeitung bereits hier ab. Des Weiteren werden Dateien alloziert; dazu kann Unterstützung vom Operator oder vom Hierarchischen Speichermanagement (HSM) erforderlich sein.
  2. Processing:
    Hier werden die eigentlichen Steps ausgeführt und die Programme gestartet.
  3. Postprocessing:
    Das ist die "Aufräumphase" des Job-Laufs: Nicht mehr benötigte Dateien werden gelöscht, Dateien, die zur exklusiven Verarbeitung blockiert waren, werden wieder freigegeben, und die Ausgabe wird gedruckt.

JES gibt es in zwei Varianten: JES2 und JES3.

Beide tun prinzipiell das Gleiche, die Unterschiede für den Benutzer sind gering:

  • JES3 bietet die Möglichkeit, Jobs auf verschiedenen Rechnern (Nodes) zu verteilen oder Job-Netze zu bilden.
  • JES2 ist vom Konfigurationsaufwand her einfacher zu handhaben, weshalb Operatoren bei einzelnen Rechnern in der Regel zu JES2 greifen.

JES2 ist das Job Entry Subsystem in der Version 2.

JES2 entstand aus HASP (Houston Automatic Spool Program), das von IBM in den 1960er Jahren für die NASA entwickelt wurde. Noch heute schreibt JES2 seine Meldungen als $HASP-Meldungen ins Systemlog.

JES2 ist einfacher einzurichten als JES3, kann dafür die Vorteile von Clustern nicht nutzen.

Es besteht allerdings die Möglichkeit, JES2 anzuweisen, einen Job auf einem bestimmten System laufen zu lassen. Das geschieht mit folgendem Record:

/*JOBPARM SYSAFF=system

JES3 ist das Job Entry Subsystem in der Version 3.

JES3 bietet mehr Möglichkeiten zur Kontrolle von Jobs, ist dafür vom Konfigurationsaufwand erheblich höher als JES2. Das Feature schlechthin sind wohl Job-Netze.

Ein Record, unabhängig von //*NET, der näher bei den Job-Netzen beschrieben wird, sei hier erwähnt:

//*MAIN ORG=dst,CLASS=class,SYSTEM=system

Die einzelnen Parameter hierbei sind:

  • ORG=dst: Die Destination, was der Ausgabeadresse entspricht. Hier kann man bestimmte, vom Rechenzentrum vordefinierte Werte eintragen, auf der die Ausgabe erfolgen soll. ORG=LOCAL etwa könnte der Drucker im Rechenzentrum sein.
  • CLASS=class: Hier ist die Angabe einer Job-Klasse möglich, die den Operatoren hilft, Jobs einzuordnen. Diese Klasse unterscheidet sich kaum vom JCL-Parameter CLASS; allerdings besteht die Möglichkeit, mehrere Zeichen statt nur einem anzugeben.
  • SYSTEM=system: Hiermit kann das System ausgewählt werden, auf dem der Job laufen soll. Von der Benutzung dieses Parameters ist (außer in wirklich begründeten Ausnahmefällen) abzuraten, da man die Fähigkeiten von JES3, Jobs auf verschiedene Systeme zu verteilen, damit umgeht.