MSCF-Schnittstelle bei /ENTER-JOB und /ENTER-PROCEDURE

Der Operand HOST der Kommandos /ENTER-JOB und /ENTER-PROCEDURE enthält den Wert HOST=*ANY. Seine Bedeutung ist nachfolgend beschrieben. Eine Beschreibung der vollständigen Kommandos befindet sich im Handbuch „Kommandos“ [10].

Operandenbeschreibung

HOST = *ANY

Legt fest, dass der Auftrag auf einem beliebigen Rechner des XCS-Verbunds ablaufen darf. Der Auftrag wird durch die Verteilkomponente des JMS an den Rechner zur Bearbeitung übergeben, der die geringste Batch-Auslastung aufweist.

Hinweise

Der Operand HOST=*ANY veranlasst das JMS, selbst einen Zielrechner im XCS-Verbund des Auftraggebers zu bestimmen. Als Auswahlkriterium, welcher Rechner zur Bearbeitung des Auftrags herangezogen wird, dient die Batch-Auslastung der dem XCS-Verbund angehörenden Rechner, d.h., die Bearbeitung des Auftrags wird demjenigen Rechner übertragen, der die geringste Batch-Auslastung aufweist. Dabei ist Folgendes zu beachten:

• Die Auslastung der Rechner wird anhand der Jobklassenbelegungen jeweils in der Annahmephase der Aufträge ermittelt, d.h., das JMS ermittelt den Zielrechner eines Auftrags durch Vergleich der Belastung zum Zeitpunkt der Auftragseinleitung. Über die Jobklassen des JMS werden die Aufträge nach ihrer Inanspruchnahme von Systemressourcen (CPU-Verbrauch, Ablaufpriorität etc.) eingeteilt (vgl. Handbuch „Einführung in die Systembetreuung“ [5]). Die Anzahl aktiver, also gleichzeitig laufender Aufträge einer Jobklasse ist durch deren Attribut CLASS-LIMIT begrenzt. Werden dem System mehr Aufträge einer Jobklasse zur Abarbeitung übergeben, als durch CLASS-LIMIT zugelassen, so werden die überzähligen Aufträge vom JMS zwar übernommen, sie sind aber nicht aktiv und belegen keine Betriebsmittel. Auch Termin-, Repeat- und Kalender-Aufträge sind in der Regel zunächst nicht aktiv, da ihr Startzeitpunkt noch nicht erreicht ist.

  Zur Ermittlung des Zielrechners werden vom Auftragsrechner (das ist der Rechner des MSCF-Verbunds, dem der Auftrag zur Annahme zunächst übergeben wird, z.B. über das Kommando ENTER-JOB) Anfragen an alle Rechner des XCS-Verbunds mit Informationen über den zu übernehmenden Batch-Auftrag gesandt. Auf allen erreichbaren XCS-Teilnehmern (hierzu gehört auch der Auftragsrechner) wird eine „Prävalidierung“ durchgeführt. Diese besteht aus der Ermittlung der prinzipiellen Akzeptierbarkeit des Auftrags auf dem jeweiligen Rechner (der Auftrag würde z.B. nicht akzeptiert, wenn seine Jobklasse auf dem potenziellen Zielrechner nicht definiert ist).
  Als Ergebnis der Prävalidierung erhält der Auftragsrechner Antworten mit folgender Information:

  • akzeptierbar / nicht akzeptierbar

  • Indikatoren Systemüberlast, Kategorienüberlast
    (bei Eintritt dieser Überlastsituation werden von JMS keine Aufträge mehr gestartet, auch wenn Jobklassenbelegungen dies erlauben würden)

  • Jobklassenzähler und Status der Jobklasse

  • Anzahl der nicht aktiven Aufträge der Jobklasse

  Aus diesen rückgemeldeten Informationen ermittelt der Auftragsrechner aus der Menge der möglichen Zielrechner, für die die Prävalidierung die prinzipielle Akzeptierbarkeit bestätigt hat, den Rechner mit der größten noch verbliebenen Aufnahmekapazität. Das JMS wählt den Zielrechner nach folgender Rangfolge aus:

  1. Stream-/Jobklassenstatus (ist z.B. der betroffene Stream auf einem Rechner nicht aktiv oder wurde die betroffene Jobklasse auf einem Zielrechner mittels Kommando HOLD-JOB-CLASS angehalten oder deren CLASS-LIMIT ist temporär 0, so kann der Auftrag auf diesem Rechner nicht unmittelbar nach der Akzeptierung gestartet werden)

  2. Rechnerauslastung (System-/Kategorienüberlast)

  3. Jobklassenbelegung (Differenz CLASS-LIMIT abzüglich der aktuell in Jobklasse aktiven Aufträge)

  4. Jobklassen-Optimum (Differenz CLASS-OPTIMUM abzüglich der aktuell in Jobklasse aktiven Aufträge

  Zunächst werden also die Belastungen mit aktiven (sich in Bearbeitung befindlichen) Aufträgen verglichen, wie sie zum Zeitpunkt der Auftragsakzeptierung auf den einzelnen Rechnern des Verbunds bestehen. Im Normalbetrieb (keine Überlast, Streams und Jobklassen auf allen Rechnern aktiv, CLASS-OPTIMUM=0) hat der Rechner die größte Aufnahmekapazität, auf dem die Differenz CLASS-LIMIT minus der aktuell in der Jobklasse befindlichen Aufträge den größten Wert hat. Sind die Jobklassen auf allen verfügbaren Rechnern des Verbunds belegt, so werden die Differenzen CLASS-LIMIT minus Gesamtzahl der akzeptierten Aufträge der betroffenen Jobklasse auf den Rechnern negativ, der Vergleich ergibt aber auch in diesem Fall den potenziell am geringsten ausgelasteten Rechner des Verbunds. Signalisiert ein Rechner, dass auf Grund der

  aktuellen Einstellung (Stream nicht aktiv, Jobklasse im HOLD-Zustand) oder wegen System-/Kategorienüberlast der Auftrag nicht gestartet werden kann, so scheidet er als Zielrechner aus, auch wenn er auf Grund der Jobklassenzähler eine geringere Batch-Auslastung aufweist. Falls alle der genannten Kriterien keine Entscheidung über einen Zielrechner zulassen, verbleibt der Auftrag auf dem Auftragsrechner.

  Das Jobklassen-Optimum ist ein weiterer Parameter, mit dem im XCS-Verbund in Einzelfällen die Batch-Auftragsverteilung gesteuert/verbessert werden kann. Dabei handelt es sich um eine Zahl (siehe Operand CLASS-OPTIMUM des Kommandos MODIFY-JOB-CLASS), die kleiner als die Maximalzahl möglicher aktiver Aufträge einer Jobklasse ist. Mit ihr wird die optimale Belegung einer Jobklasse durch den Systembetreuer festgelegt. In der Regel ist dies ein Erfahrungswert, der nur im konkreten Anwendungsfall bestimmbar ist (z.B. wegen des beobachteten besten Durchsatzes an Batch-Aufträgen einer Anwendung). Ist CLASS-OPTIMUM ungleich 0, so berücksichtigt die Verteilkomponente des JMS zunächst alle Rechner, auf denen in der betroffenen Jobklasse der Wert CLASS-OPTIMUM noch nicht erreicht ist. Stehen mehr als ein Rechner zur Verfügung, so wird derjenige bevorzugt, bei dem die Differenz CLASS-OPTIMUM minus aktuell in Jobklasse befindlicher Aufträge am höchsten ist.

• Ist über den Zielrechner entschieden, so wird der Auftrag an diesen Rechner verschickt (analog zu der schon bestehenden Funktion, über die ein Zielrechner explizit mit dem Operanden HOST des Kommandos ENTER-JOB vom Benutzer bestimmt wird). Der Auftrag durchläuft dort die Akzeptierungsphase, das Ergebnis wird dem Auftraggeber mitgeteilt (Meldung JPM0500 und weitere Meldungen, in der Regel JMS0066). Der auf dem Zielrechner akzeptierte Auftrag wird dem dortigen Jobscheduler übergeben und von diesem zum Start freigegeben. Ein einmal auf einem Rechner akzeptierter Auftrag verbleibt dort.
  Das Ergebnis der Prävalidierung muss nicht in jedem Fall mit dem der endgültigen Akzeptierung übereinstimmen. Dies ist dann der Fall, wenn zwischen Prävalidierung und Akzeptierung auf dem Zielrechner JMS-Einstellungen auf dem Zielrechner durch die Systembetreuung geändert werden. Z.B. kann zwischenzeitlich das CLASS-LIMIT auf 0 gesetzt worden sein. Solche Eingriffe der Systembetreuung werden durch das JMS nicht verhindert (kein globales Sperren von JMS-Daten im XCS-Verbund). Das JMS versucht in solchen Fällen (nachdem ihm vom Zielrechner entgegen dem Ergebnis der Prävalidierung gemeldet wurde, dass der Auftrag nicht akzeptiert wird) einen anderen Rechner des Verbunds zu finden.

• Kann der Auftrag im gesamten Verbund nicht akzeptiert werden, werden die Gründe pro erreichtem Rechner auf dem Auftragsrechner gemeldet (vgl. Meldung JDS0322).

• Standard-Verhalten: Sind bei folgenden Job-Attributen im Kommando ENTER-JOB keine Angaben gemacht, so ist das Standard-Verhalten wie folgt:

  • PROCESSING-ADMISSION (Standardwert = *SAME):
    Benutzerkennung des zu erzeugenden Batch-Auftrags ist die Benutzerkennung der Auftraggeber-Task auf dem Auftragsrechner. Für die Rechte-Überprüfungen sind die Attribute der gleichnamigen Benutzerkennung des Zielrechners ausschlaggebend.

  • JOB-CLASS (Standardwert = *STD):
    Jobklasse des zu erzeugenden Batch-Auftrags ist die Default-Batch-Jobklasse der Benutzerkennung auf dem Zielrechner.

  • Job-Attribute, deren Standardwert der Jobklasse entnommen werden; es gilt der Standardwert der Jobklassendefinition des Zielrechners.

• Für Termin-, Kalender- und Repeat-Aufträge ist die Angabe des Operanden HOST mit dem Wert *ANY nicht sinnvoll, wird aber vom JMS nicht verhindert. Für Termin-Aufträge kann das JMS zum Akzeptierungszeitpunkt, zu dem die Verteilung erfolgt, keine Prognose für die Belastung zurzeit der Auftragseinleitung abgeben. Repeat-Aufträge werden zwar für jede Ausprägung mit neuer TSN generiert, sie verbleiben jedoch auf dem einmal ausgewählten Rechner. Kalender-Aufträge haben nur eine TSN und müssen daher auf dem einmal ausgewählten Rechner bleiben. Werden diese Aufträge dem System unter Angabe des Operanden HOST=*ANY übergeben, so werden sie so wie oben beschrieben verteilt. Das JMS macht keine Planung über zu erwartende Lasten; es ermittelt die Aufnahmekapazität eines Rechners auch hier anhand der oben beschriebenen Differenzen von Aufträgen.

  Analoges gilt auch für alle anderen Aufträge, die nicht unmittelbar nach der Annahme starten können (z.B. CLASS-LIMIT=0, Jobklasse oder Jobstream im HOLD-Status oder Jobstream nicht gestartet). Werden z.B. Aufträge tagsüber für einen Stream übergeben, der nachts aktiv sein soll, so wird vom JMS über die Verteilung anhand der zum Akzeptierungszeitpunkt verfügbaren Auftragszahlen entschieden. Es ist Sache des Benutzers, zu entscheiden, ob sich das von ihm gewünschte Verhalten erreichen lässt.

• Einschränkung:
  Hat die Auftraggeber-Task eines Batch-Auftrags das Privileg OPERATOR, so wird bei Angabe von HOST=*ANY das Kommando SET-LOGON-PARAMETERS in der Enter-Kommandodatei nicht ausgewertet.

• Empfehlungen für Systemeinstellungen (JMS-Parameter, Benutzerattribute):Es wird empfohlen, die JMS-Parameter (Jobklassendefinition, Standard-Jobklassen) bzw. Benutzerattribute und Kontingente auf allen Teilnehmern des XCS-Verbunds gleich zu vergeben. Das JMS führt die oben beschriebenen Überprüfungen durch (Prävalidierung), sodass die Ablauffähigkeit des Batch-Auftrags auf dem ausgewählten Rechner soweit garantiert ist, erzwingt die einheitliche Vergabe aber nicht. Inkonsistenzen, die erst zur Ablaufzeit der Batch-Aufträge wirksam werden, können damit nicht aufgedeckt werden (z.B. unterschiedliche Syntax-Dateien, unterschiedliche Privilegienvergabe etc.). Wird von der Vergabe einheitlicher Systemeinstellungen abgewichen, so soll dies im Bewusstsein des erzielten Effektes geschehen. Werden z.B. CLASS-LIMITs für die gleiche Jobklasse auf den Rechnern unterschiedlich vergeben, so hat dies den Effekt, dass Rechner mit dem größeren Wert bevorzugt werden, auch wenn die Anzahl der Aufträge, die ein solcher Rechner in der entsprechenden Jobklasse bereits aufgenommen hat, größer ist als auf anderen Rechnern.