In einem MSCF-Verbund hat der Benutzer die Möglichkeit, seine Stapelaufträge auf beliebige Rechner des Verbunds zu verteilen, vorausgesetzt, es gibt eine MSCF-Verbindung zwischen den beiden Rechnern. Der Benutzer kann somit die Betriebsmittel von jedem Rechner des Verbundnetzes nutzen, insbesondere solche Betriebsmittel, die nur an bestimmten Rechnern verfügbar sind. Durch Auftragsverteilung lässt sich auch eine Überbelastung einzelner Rechner ausgleichen.
Auf jedem am MSCF-Verbund teilnehmenden Rechner kann die Auftragsverteilung über die Kommandos ENTER-JOB und ENTER-PROCEDURE bzw. den ENTER-Makro eingeleitet werden. Die Adressierung des Zielrechners erfolgt jeweils über den Operanden HOST. Bei fehlender HOST-Angabe wird der Auftrag lokal ausgeführt. Betriebsmittel-Anforderungen des auszuführenden Auftrags (Geräte, Dateien, Kataloge) können nicht mit diesen Kommandos gesteuert werden.
Zielrechner-Adressierung
Im Kommando ENTER-JOB kann der Zielrechner über den Operanden HOST wie folgt angegeben werden:
HOST='<hostname>'
HOST=<jvname>
HOST='<&jvname>'
HOST=*CATALOG(IDENTIFICATION='<catid>'/<jvname>)
HOST=*ANY
Wird der Zielrechner direkt über HOST='<hostname>' adressiert, so wird der Auftrag unmittelbar an den Zielrechner übergeben und dort in die Auftrags-Warteschlange eingereiht. Der Zielrechner kann aber auch indirekt durch Hinterlegen des Host-Namens in einer JV adressiert werden. Der Host-Name wird in diesem Fall der JV entnommen, entweder durch den Kommando-Server (d.h. durch die Routinen, die das Kommando ENTER-JOB ausführen (HOST=<jvname>)) oder durch Ausdrucksersetzung (HOST='<&jvname>'), eine SDF-Funktion, die allgemein zur Verfügung steht. Eine weitere indirekte Adressierungsmöglichkeit besteht in der Angabe der Katalogkennung eines Pubsets, der am Zielrechner importiert ist (HOST=*CATALOG(IDENTIFICATION='<catid>')).
Grundsätzlich bietet die indirekte Adressierung eine größere Flexibilität in der Formulierung von Prozeduren. Das folgende Beispiel soll dies erläutern:
In Absprache mit den Benutzern legen die einem MSCF-Verbundnetz angehörenden Rechenzentren Namen und Bedeutung bestimmter JVs fest. Jede dieser JVs repräsentiert dabei eine Gruppe von Betriebsmitteln (z.B. Geräte, Dateien, Aufträge), die einem oder mehreren Rechnern des MSCF-Verbunds zugeordnet werden. Wird nun eine Gruppe von Betriebsmitteln einem bestimmten Rechner zugeordnet, so wird der Wert der JV auf den zugeordneten Rechner-/Katalognamen gesetzt. In der Folge werden Aufträge, die den Namen dieser JV im HOST-Operanden enthalten, an den entsprechenden Rechner übergeben.
Während die direkte Adressierung einen Auftrag statisch an einen Rechner oder Katalog bindet, ist über die indirekte Adressierung eine dynamische Auftragsbindung an eine Vielzahl von Rechner/Kataloge ohne Änderung der ursprünglichen Auftragssteuerungsanweisungen möglich. Bei der indirekten Adressierung mittels einer Katalogkennung können lokale und nichtlokale importierte Kataloge angegeben werden. Der Auftrag wird auf dem Rechner ausgeführt, auf dem der angegebene Katalog zum Zeitpunkt der ENTER-JOB Kommandoeingabe importiert ist. Liegt der Katalog auf einem Shared-Pubset (siehe "Shared-Pubset-Verbund"), der sowohl vom lokalen als auch von einem Remote-Rechner aus zugreifbar ist, so wird der Auftrag auf dem lokalen Rechner bearbeitet.
Für den Benutzer ist diese Art der Rechner-Adressierung sehr komfortabel, da er nicht zu wissen braucht, auf welchem Rechner im MSCF-Verbund sich der angegebene Katalog befindet und welchen Host-Namen dieser Rechner führt. Darüber hinaus spricht für diese Art der Zielrechner-Adressierung, dass in einem MSCF-Verbund Kataloge zwischen den einzelnen Systemen exportiert und importiert werden können.
Diese Variante der Zielrechner-Adressierung ist auch unabhängig vom Bestehen eines MSCF-Verbunds verwendbar (die Pubsets sind lokal importiert). Der Umstieg auf den MSCF-Verbund ist möglich, ohne dass Kommandos geändert werden müssen.
Hinweise
Der Zielrechner wird zum Akzeptierungszeitpunkt festgelegt. Zwischen dem Akzeptieren eines Stapelauftrags und seiner Ausführung kann jedoch ein größerer Zeitraum liegen (z.B. wegen Termin-Job, Überlastsituation etc.). Zu beachten ist, dass ein einmal akzeptierter Stapelauftrag zwangsläufig auf dem ausgewählten Zielrechner abläuft, ein Umstand, der auch nicht mittels der indirekten Zielrechneradressierung anhand einer Katalogkennung beeinflusst werden kann. Das Umkonfigurieren eines Kataloges (Export am ausgewählten Zielrechner, Import an einem anderen Rechner des Verbunds) zwischen Akzeptierung und Ablauf bewirkt nicht automatisch, dass der Stapelauftrag auf dem neuen Zielrechner abläuft.
Eine Ausnahme hiervon stellt lediglich der Fall dar, dass mit der Katalogkennung der Home-Pubset des ursprünglichen Zielrechners bezeichnet wurde und mit diesem Home-Pubset ein Startup für den neuen Zielrechner durchgeführt wird.Das Kommando ENTER-PROCEDURE bietet nicht alle Optionen für den Operanden HOST an, die das Kommando ENTER-JOB für diesen Operanden gestattet. Dies bedeutet jedoch keine Einschränkung in der Funktionalität, da durch das Mittel der Ausdrucksersetzung (<&jvname>) generell Indirektionen möglich sind.
Beispiel einer indirekten Adressierung per Katalogkennung
Die Systeme RECHNER1, RECHNER2 und RECHNER3 bilden einen MSCF-Verbund, in dem jeder Rechner mit jedem anderen verbunden ist:
|
|
|
Auf RECHNER1 werden nun folgende Kommandos zur Auftrags-Verteilung eingegeben:
/ENTER-JOB FROM-FILE=job1,HOST=C'RECHNER2' ———————————————————————————— (1) /ENTER-JOB FROM-FILE=job2,HOST=*CATALOG(IDENTIFICATION=C'D') —————————— (2) /ENTER-JOB FROM-FILE=job3,HOST=*CATALOG(IDENTIFICATION=C'A') —————————— (3)
(1) | Der Auftrag 'job1' wird auf RECHNER2 ausgeführt. |
(2) | Der Auftrag 'job2' wird auf RECHNER3 ausgeführt, da dieser Katalog D verwaltet. Im MRSCAT von RECHNER1 muss ein Eintrag für 'D' mit Verweis auf RECHNER3 enthalten sein. |
(3) | Der Auftrag 'job3' wird auf dem lokalen Rechner (RECHNER1) ausgeführt. |
Katalog D wird anschließend von RECHNER3 nach RECHNER2 transportiert (die Systembetreuung von RECHNER3 gibt das Kommando EXPORT-PUBSET PUBSET=D, die Systembetreuung von RECHNER2 das Kommando IMPORT-PUBSET PUBSET=D).
Bei bestehender MSCF-Verbindung wird durch EXPORT-/IMPORT-PUBSET auf RECHNER1 der zugehörige Zustandswechsel (ACC, RECHNER3 nach INACC, RECHNER3 und ACC, RECHNER2) durchgeführt.
Gibt nun der Benutzer auf RECHNER1 das Kommando (2) ein, wird der Auftrag 'job2' auf RECHNER2 ausgeführt. Obwohl sich der Katalog jetzt auf einem anderen Rechner als vorher befindet (siehe Bild unten), muss der Benutzer seine Auftragssteuerungs-Anweisungen nicht ändern.
|
|
|
Beispiel einer indirekten Adressierung per Katalogkennung und JV
Die Aufträge JOB-A, JOB-B, JOB-C und JOB-D sollen auf bestimmte Rechner eines MSCF-Verbunds verteilt werden:
JOB-A soll auf RECHNER1 ablaufen.
JOB-B soll auf dem Rechner ablaufen, der den Katalog B verwaltet.
JOB-C soll auf dem Rechner ablaufen, an dem der Laserdrucker über einen Kanalumschalter angeschlossen ist. Der entsprechende Rechner wird in unserem Beispiel über die Jobvariable 'LASERDRUCKER' identifiziert (es ist Aufgabe der Systembetreuung, dafür zu sorgen, dass diese Jobvariable den Namen des Rechners enthält, an dem der Laserdrucker momentan angeschlossen ist).
JOB-D soll auf dem Rechner ablaufen, der den Katalog mit der Datei 'UDS.DATEN' verwaltet. Der entsprechende Katalog wird in unserem Beispiel über die Jobvariable 'UDSDTA' identifiziert (die Systembetreuung muss dafür Sorge tragen, dass diese Jobvariable die Kennung des Katalogs enthält, der die Datei 'UDS.DATEN' beinhaltet).
Bild 9: Auftragsverwaltung
Die Aufträge werden mit folgenden Kommandos gestartet:
/ENTER-JOB FROM-FILE=JOB-A,HOST=C'RECHNER1' /ENTER-JOB FROM-FILE=JOB-B,HOST=*CATALOG(IDENTIFICATION=C'B') /ENTER-JOB FROM-FILE=JOB-C,HOST=:C:LASERDRUCKER /ENTER-JOB FROM-FILE=JOB-D,HOST=*CATALOG(IDENTIFICATION=:C:UDSDTA)
Der Auftrag JOB-A wird an RECHNER1, der Auftrag JOB-B an RECHNER2 übergeben (RECHNER2 verwaltet den Katalog B). Die Angabe der Zielsysteme für die Aufträge JOB-A und JOB-B ist statisch.
Die Verteilung der Aufträge JOB-C und JOB-D ist abhängig von den Werten der Jobvariablen LASERDRUCKER und UDSDTA. JOB-C wird an RECHNER2, JOB-D an RECHNER1 übergeben. Durch eine einfache Wertänderung der Jobvariablen lässt sich eine flexible Verteilung der Aufträge im MSCF-Verbund entsprechend der jeweiligen Auslastung und Lage der Betriebsmittel erzielen. Die Angabe der Zielsysteme für die Aufträge JOB-C und JOB-D ist dynamisch.