Dieses Kapitel gibt eine einführende Beschreibung der Komponenten und Einrichtungen, die Sie zur Steuerung und Überwachung des Entire Operations-Systems benutzen können.
Grundsätzlich stehen diese Komponenten und Einrichtungen für alle von Entire Operations unterstützten Betriebssysteme zur Verfügung. Auf eventuelle Ausnahmen und plattformspezifische Unterschiede wird an relevanten Stellen eingegangen.
Bestimmte Objekte müssen im System definiert werden, bevor die Kontrolle über die Batch-Verarbeitung an Entire Operations übergeben werden kann. Dieses Kapitel enthält eine kurze Beschreibung dieser Objekte und erläutert die Art und Weise, wie Entire Operations sie benutzt.
Siehe auch:
Performance-Überlegungen in der Installation und Inbetriebnahme-Dokumentation
Konzept und Leistungsumfang-Dokumentation
Innerhalb von Entire Operations bedeutet der Begriff "Betriebssystemklasse" ein oder mehrere Betriebssysteme, die für gewöhnlich auf die gleiche Art und Weise behandelt werden.
| Betriebssystemklasse | Betriebssystem |
|---|---|
| B | BS2000 |
| M | z/OS |
| V | z/VSE |
| X | Alle unterstützten UNIX-Betriebssysteme, einschließlich AIX, HP-UX, Linux, Sun Solaris |
| W | Alle unterstützten Windows-Betriebssysteme |
Die Betriebssystemklasse wird an diversen Stellen innerhalb von Entire Operations benutzt.
Um Zugang zum System zu erhalten, kann in Entire Operations eine Benutzerkennung ("User-ID, Benutzer-ID") verwendet werden. Entire Operations-Benutzerkennungen sollten, aber müssen nicht im TP-Monitor des Rechnersystems definiert sein.
Mehrere Benutzer können sich bei Entire Operations mit derselben Benutzerkennung und demselben Passwort gleichzeitig anmelden. Aus Gründen der Datensicherheit und um Änderungen an Daten nachzuvollziehen, hat allerdings jeder einzelne Benutzer gewöhnlich eine eigene persönliche Benutzerkennung und ein eigenes Passwort.
Entire Operations-Benutzerkennungen sind relevant für:
Entire Operations-Benutzerprofile
Jede Entire Operations-Benutzerkennung kann individuelle
Zugriffsberechtigungen für Entire Operations-Funktionen und Entire
Operations-Objekte haben. Siehe
Profil-Einstellungen
in der Systemverwaltung-Dokumentation.
Mailboxen
Einer Benutzerkennung können bis zu 10 elektronische Briefkästen
("Mailboxen") zugeordnet werden, über die der Benutzer über alle
noch nicht erledigten logischen Bedingungen benachrichtigt wird, die mit diesen
Mailboxen verknüpft sind. Siehe Kapitel Mailboxen.
Protokollierung
Entire Operations führt Protokoll über alle Aktivitäten
(einschließlich der Benutzeraktivitäten) und Ereignisse, die innerhalb des
Systems auftreten.
Eine Benutzerkennung ist grundsätzlich mit mindestens einem Eigentümer verknüpft. Siehe Abschnitt Eigentümer.
Dieser Abschnitt behandelt die folgenden Themen:
Wenn Sie mit Betriebssystem-Objekten arbeiten möchten (z.B. um JCL zu editieren), müssen Sie sich auf dem Entire System Server bei den Knoten anmelden (Logon), mit denen Sie arbeiten möchten. Nach einer solchen Anmeldung haben Sie alle Zugangsberechtigungen der von Ihnen angegebenen Betriebssystem-Benutzerkennung. Siehe Logon bei einem Betriebssystem-Server (Knoten) im Abschnitt Entire Operations benutzen.
Für Entire Operations-Netzwerke und -Jobs müssen Sie Betriebssystem-Benutzerkennungen spezifisch als JCL-Benutzerkennungen und als Start-(Ausführungs-)Benutzerkennungen festlegen. Siehe auch spezielle Angaben bei z/OS zur Job-Start-Benutzerkennung im Abschnitt Spezielle Angaben für z/OS im Kapitel Job-Verwaltung.
Wenn Sie mit einem Betriebssystem-Objekt arbeiten möchten und nicht bei dem definierten Entire System Server-Knoten angemeldet sind, erscheint in vielen Fällen automatisch der Anmelde-Bildschirm für den Knoten.
Sie können auch eine explizite Anmeldung (Logon) bei dem Knoten
ausführen, indem Sie das Direktkommando
LOGON
SERVER benutzen.
Um Ihren aktuellen Logon-Status anzuzeigen, können Sie das
Direktkommando STATUS
NODES benutzen.
In Netzwerk- und Job-Definitionen ist es möglich, Folgendes anzugeben:
eine JCL-Benutzerkennung für den JCL-Knoten;
eine Job-Start-(Ausführungs-)Benutzerkennung für den Ausführungsknoten.
Darüber hinaus ist es möglich, eine Gruppe (UNIX) bzw. eine Domäne (Windows) anzugeben.
Wenn für einen UNIX-Knoten keine Gruppe definiert ist, dann gilt die Standard-Gruppe der Benutzerkennung.
Wird für einen Windows-Knoten keine Domäne angegeben, dann wird die Benutzerkennung als lokaler Benutzer behandelt. Wenn Sie im Feld Domäne (Gruppe) den Namen des Knoten-Host eingeben, wird die Benutzerkennung ebenfalls als lokaler Benutzer behandelt.
Wenn lokal keine Definition der Betriebssystem-Benutzerkennung für den JCL-Knoten oder den Ausführungsknoten erfolgt ist, setzt Entire Operations eine Betriebssystem-Benutzerkennung fest, und zwar in Abhängigkeit von Folgendem:
Wenn eine nicht mit der Benutzerkennung des Entire Operations-Monitors
(Job-Start-Sicherheit-Benutzertyp = M) identische,
Betriebssystem-Benutzerkennung benutzt werden soll, gilt eine Suchhierarchie
für die Betriebssystem-Benutzerkennung. Siehe Felder
Monitor-UserId und Jobstart-Benutzertyp im
Zugriffskontrollsystem im Abschnitt
Felder:
Monitor-Standardwerte in der
Systemverwaltung-Dokumentation.
Die Suchreihenfolge ist:
Die Benutzerkennung (JCL oder Job-Start) des Jobs.
Die Benutzerkennung (JCL oder Job-Start) des Netzwerks.
Die Standard-Benutzerkennung des Knotens (Großrechner, UNIX und Windows).
Der Benutzer mit der letzten Änderung ("last modification user") des Jobs.
Dies gilt für die Master-Definition des Netzwerks, die Master-Definition des Jobs und die aktive Job-Definition:
Eine Symbolersetzung ist möglich in den folgenden Feldern:
JCL-Benutzerkennung
JCL-Gruppe
Job-Start-Benutzerkennung
Job-Start-Gruppe
Wenn das Aktivierungsfluchtzeichen benutzt wird, wird die Ersetzung zum Aktivierungszeitpunkt durchgeführt. Dies ist für JCL-Benutzerkennung und -Gruppe erforderlich. Wenn das Job-Startfluchtzeichen benutzt wird, wird die Ersetzung vor dem Job-Start durchgeführt. Symbolersetzungsfehler in einem dieser Felder werden als permanente Fehler behandelt.
Entire Operations bietet mit dem Konzept des Eigentümers erhöhte Benutzerfreundlichkeit und Zugriffskontrolle. Durch Zuordnung von Eigentümern ermöglicht dieses Konzept die Aufteilung der Job-Netzwerke in Gruppen. In der Benutzerverwaltung ordnet der Systemadministrator einer Benutzerkennung einen Eigentümernamen zu. Dieser Eigentümername wird an jedes Netzwerk automatisch übergeben, das von diesem Benutzer definiert wird. Siehe Zuordnung Benutzer/Eigentümer in der Systemverwaltung-Dokumentation.
Ein Eigentümer kann dadurch eine Abteilung, ein Projekt oder eine Gruppe zusammengehöriger Job-Netzwerke darstellen. Benutzer, die zu einem bestimmten Eigentümer gehören, können Funktionen nur an Job-Netzwerken ausführen, die mit diesem Eigentümer verknüpft sind.
Anmerkung:
In besonderen Fällen kann ein Eigentümer berechtigt sein, auf
Netzwerke zuzugreifen, die anderen Eigentümern gehören. Der Eigentümer SYSDBA
ist berechtigt, auf die Netzwerke aller Eigentümer zuzugreifen.
Mit jedem Eigentümer können beliebig viele Job-Netzwerke verknüpft werden. Der Name eines Job-Netzwerkes ist nur in Verbindung mit dem Eigentümernamen innerhalb des Systems eindeutig.
Auch der Zugriff auf die meisten anderen Entire Operations-Objekte ist eigentümerabhängig. Der Eigentümername erscheint in der obersten Zeile der meisten Masken und Fenster.
Das folgende Beispiel veranschaulicht die Verbindungen zwischen Benutzern, Eigentümern und Job-Netzwerken:
In Entire Operations hat der Begriff "Job" eine weiter gefaßte Bedeutung als im Betriebssystem. Siehe Abschnitt Jobs in Konzept und Leistungsumfang.
In der Job-Verwaltung von Entire Operations können verschiedene Jobtypen definiert werden.
Auf die verschiedenen Jobtypen wird in den Abschnitten Entire Operations Jobtypen und Kommandozeilen-Parameterübergabe im Kapitel Job-Verwaltung eingegangen.
Ein Job kann auch aus einer manuellen Aktion bestehen, die vom Benutzer ausgeführt wird. Eine manuelle Aktion kann in das Job-Netzwerk integriert werden, indem Bedingungen dafür definiert werden, die nicht-automatisch gesetzt werden.
Alle Jobs sind Bestandteile von Job-Netzwerken und können durch
logische Bedingungen miteinander
verknüpft werden. Bei der Job-Ende-Prüfung gibt es, je nach Jobtyp und
Betriebssystem, Unterschiede (siehe Job-Ende-Prüfung und
-Aktionen). Sie können aber Job OK oder
Job nicht OK immer als Bedingung für eine spätere Systemaktion
definieren.
Nur die Jobtypen JOB, MAC (Speicherart), SRV und STC werden zu Jobs des Betriebssystems, wenn sie gestartet werden.
Für z/OS und z/VSE gilt: Ein Job des Betriebssystems kann sich aus mehreren Steps zusammensetzen, wobei Entire Operations die Ergebnisse jedes Jobsteps im Rahmen der Job-Ende-Analyse überprüfen kann und eine entsprechende Systemaktion anstößt.
Ein Job wird innerhalb eines Job-Netzwerkes durch seinen Job-Namen eindeutig identifiziert. Der Job-Name kann derselbe sein wie der Name der JOB- oder LOGON-Anweisung (d.h. Job-Name, mit dem das Betriebssystem den Job identifiziert), aber dies ist nicht zwingend vorgeschrieben. Vor dem Job-Start können Jobs deswegen nur mittels des Namens identifiziert werden, der in Entire Operations definiert ist. Auf einen Job kann von Entire Operations nur mit seinem Entire Operations-Namen zugegriffen werden.
Bei der Definition eines Jobs müssen Sie außerdem Folgendes angeben:
Speicherart der JCL (je nach Jobtyp);
JCL und Ausführungsknoten (wenn nicht mit denen für das Job-Netzwerk angegebenen identisch);
Zeitplan-Parameter (optional, sonst wird der definierte Standardwert des Netzwerkes benutzt);
Aktionen und Prüfungen am Job-Ende (siehe Job-Ende-Prüfung und -Aktionen).
Weitere Informationen siehe Abschnitte Job-Verwaltung.
Anmerkung:
(Nur bei z/OS) Es wird empfohlen, dass die JCL eines Entire
Operations Jobs jeweils nur eine JOB-Anweisung enthält. Entire Operations
behandelt nur die zuerst vergebene Jobnummer eines gestarteten Jobs.
Ein Job-Netzwerk (kurz: "Netzwerk") ist eine Gruppe von Jobs, die in einer definierten Beziehung zueinander stehen. Diese Beziehung besteht aus Abhängigkeiten, die als logische Bedingungen ausgedrückt werden. Im einfachsten Fall können zwei Jobs in einem Job-Netzwerk durch eine Bedingung miteinander verknüpft werden: Wenn Job 1 erfolgreich beendet wurde, dann Job 2 starten (siehe Logische Bedingungen).
Ein Job-Netzwerk wird durch seinen Eigentümernamen und seinen Netzwerknamen eindeutig definiert. Jedes Netzwerk erhält eine Start- und eine Endezeit, die bestimmen, wann das Netzwerk zu aktivieren ist. Wenn Ihre Entire Operations-Installation mehrere CPUs unterstützt, können Sie auch eine Standardknotennummer für die Jobs im Netzwerk angeben. Diese Knotennummer kann auf der Job-Ebene modifiziert werden (siehe Betriebssystem-Server-Knoten).
Ein Benutzer kann nur dann auf ein definiertes Job-Netzwerk zugreifen, wenn seine Benutzerkennung mit demselben Eigentümer wie das Netzwerk verknüpft ist, es sei denn, er besitzt eine besondere Zugriffsberechtigung für andere Netzwerke.
Ein Job-Netzwerk oder ein einzelner Job sind die Arbeitseinheiten, die Entire Operations aktivieren kann. Wird ein Job-Netzwerk aktiviert, so wird ihm automatisch eine Laufnummer zugeordnet, die diese Netzwerkaktivierung eindeutig identifiziert. Deshalb können mehrere Kopien desselben Job-Netzwerkes gleichzeitig laufen.
Ein Job-Netzwerk kann ein Unternetzwerk eines anderen Job-Netzwerkes sein.
Mit dem Jobtyp NET
können Sie ein Unternetzwerk innerhalb eines Hauptnetzwerks definieren und
somit verschachtelte Netzwerke konstruieren. Das Unternetzwerk muss zum
Zeitpunkt der Definition bereits existieren. Das gleiche Unternetzwerk darf in
verschiedenen Jobs des Hauptnetzwerks definiert werden. Bei der Aktivierung
bekommt jedes aktive Unternetzwerk eine eindeutige
Laufnummer. Innerhalb von
Unternetzwerken können wiederum Unternetzwerke aufgerufen werden.
Unternetzwerke dürfen jedoch nicht in sich selbst aufgerufen werden, da sonst
eine unendliche Rekursion entstehen kann.
Weitere Informationen siehe Unternetzwerk definieren im Kapitel Job-Verwaltung.
Logische Bedingungen sind Variablen innerhalb von Entire Operations, die Job-Abhängigkeiten beschreiben. Die Namen von Bedingungen müssen innerhalb eines Netzwerkes eindeutig sein.
Eine aktive Bedingung stellt den aktuellen Wert der Bedingung
für die Aktivierung eines gegebenen Job-Netzwerkes dar. Sie kann entweder den
Wert WAHR (= Bedingung existiert) oder FALSCH (=
Bedingung existiert nicht) haben. Die Laufnummer, die dem Job-Netzwerk bei
Aktivierung zugewiesen wird, wird den Bedingungen automatisch übergeben, die
für die Jobs im Netzwerk definiert sind. Eine aktive Bedingung wird eindeutig
identifiziert durch Eigentümer, Netzwerk, Laufnummer und den
Bedingungsnamen.
Logische Bedingungen werden in der Entire Operations-Umgebung benutzt als:
Diese werden in den folgenden Abschnitten ausführlicher beschrieben.
Logische Bedingungen können global sein. Globale Bedingungen existieren pro Name maximal einmal im System.
Eingabebedingungen sind Voraussetzungen für das Starten eines Jobs. Entire Operations startet einen Job erst dann, wenn alle Eingabebedingungen und andere Voraussetzungen gesetzt (erfüllt) sind. Eine Eingabebedingung kann durch das Auftreten eines Ereignisses gesetzt werden, das von Entire Operations erkannt oder vom Benutzer bei der Verwaltung der aktiven Bedingungen gesetzt wird. Sie kann außerdem durch Antwort auf eine Mailbox-Abfrage gesetzt werden.
Wird keine Eingabebedingung für einen Job definiert, geht Entire
Operations davon aus, dass eine virtuelle WAHR-Eingabebedingung
vorliegt. Dies bedeutet, dass dieser Job zu der (frühesten) Startzeit, die für
ihn definiert wurde, sofort gestartet werden kann, es sei denn, der Job hat
andere Voraussetzungen, wie z.B. Ressourcen.
Jobs werden verknüpft, indem die Ausgabebedingungen eines Jobs als die Eingabebedingungen des folgenden Jobs definiert werden (siehe Job-Verwaltung).
Mit der Connect-Funktion können Sie zwei Jobs auf sehr schnelle Weise verknüpfen. Entire Operations stellt hierbei eine Standardbedingung zur Verfügung, die dem einen Job als Ausgabebedingung und dem anderen als Eingabebedingung zugeordnet wird.
Eingabebedingungen können sich nicht nur auf den aktuellen Lauf eines Job-Netzwerkes, sondern auch auf vorgegebene Zeitrahmen in der Vergangenheit oder auf vorangegangene Läufe beziehen.
Sie können eine Eingabebedingung auch dazu verwenden, einen Job bei ihrem Auftreten in einen temporären Dummy-Job zu verwandeln. Weitere Informationen siehe Job-Ausführung als Dummy-Job.
Ausgabebedingungen können während der Entire Operations Job-Ende-Prüfungen und -Aktionen gesetzt oder zurückgesetzt werden. Bei jedem Job oder Jobstep (Job eines Betriebssystems) können Sie eine beliebige Anzahl von möglichen Ereignissen angeben. Jedem Ereignis können bis zu 20 Ausgabebedingungen zugeordnet werden. Wenn eines dieser Ereignisse auftritt, setzt Entire Operations automatisch die diesem zugeordneten Ausgabebedingungen und startet die Jobs, für die diese Bedingungen Eingabebedingungen sind (siehe Job-Ende-Prüfung und -Aktionen).
Die folgende Abbildung veranschaulicht ein einfaches Beispiel zweier Jobs, die durch logische Bedingungen verknüpft sind:
Durch logische Bedingungen verknüpfte Jobs
Zur Verknüpfung der beiden Jobs wird eine Ausgabebedingung von Job 1 als eine Eingabebedingung für Job 2 definiert.
Jeder aktive Job wird auf seine Bedingungen hin überprüft, bevor er gestartet werden kann. Nur wenn alle definierten Bedingungen gleichzeitig zur Verfügung stehen, kann der Job gestartet werden. Die Prüfung von Bedingungen für einen aktiven Job wird solange wiederholt, bis alle definierten Bedingungen zur Verfügung stehen, aber nur bevor die späteste Startzeit erreicht ist.
Die für einen Job oder ein Netzwerk definierten Start- und Endezeiten müssen erreicht worden sein.
Die für den Job definierten Eingabebedingungen müssen erfüllt sein.
Die für die Verwendung durch den Job definierten Resourcen müssen zur Verfügung stehen.
Für den Job oder das Netzwerk definierte, betriebssystem-spezifische Objekte (z.B. ein BS2000-Benutzerschalter) müssen zur Verfügung stehen.
Der für den Job oder das Netzwerk definierte Ausführungsknoten muss zur Verfügung stehen.
Entire Operations verwendet mehrere Verfahren, um den Aufwand bei der Prüfung von Bedingungen zu verringern. Diese Verfahren sind für den Anwender transparent. Sie sollen hier aber dennoch aufgezeigt werden.
Die Sortierreihenfolge bei der Prüfung von Bedingungen ist wie folgt:
Früheste Startzeit;
Superdeskriptor Eigentümer, Netzwerk, Lauf, Job.
Der Sortiervorgang wird nur bei Jobs durchgeführt, die zur selben Zeit sich in der Eingabe-Warteschlange für die Prüfung von Bedingungen befinden.
Aktive Jobs, die auf eine oder mehrere Eingabebedingungen, Ressourcen, oder auf die Verfügbarkeit eines Betriebssystem-Servers (Knotens) warten, werden in eine gesonderte Warteschlange gestellt, die sie temporär aus der aktiven Prüfung durch den Monitor herausnimmt.
Aktive Jobs werden aus dem passiven Wartezustand "aufgeweckt":
beim Setzen oder Löschen aktiver Bedingungen, die sie betreffen könnten, an beliebiger Stelle,
beim Setzen oder Löschen von Ressourcen, die im Job verwendet werden, an beliebiger Stelle,
nach der Veränderung oder Löschung von Definitionen für Eingabebedingungen und Ressourcen in aktiven Jobs,
beim Start des Monitors,
bei Tageswechsel,
durch explizite Anforderung, siehe Spezielle Funktionen in der Systemverwaltung-Dokumentation.
Nach einem Aufwecken wird erneut eine aktive Prüfung der Vorbedingungen, Ressourcen und Betriebssystem-Server ausgeführt. Wenn die zum Job-Start notwendigen Bedingungen nicht erfüllt sind, kann ein erneutes passives Warten die Folge sein.
Anmerkung:
Die Hauptroutine für passives Warten reaktiviert die wartenden Jobs
nicht zur selben Zeit. Stattdessen gibt sie sie in 300er Portionen frei.
Zwischen der Freigabe dieser Bündel liegt ein Zeitraum von 30 Sekunden. Dies
optimiert die Verteilung der Monitor- und der Datenbank-Aktivitäten bei der
Prüfung von Bedingungen für eine große Anzahl an Jobs über einen längeren
Zeitraum.
Das folgende Diagramm zeigt den Ablauf beim passiven Warten auf Bedingungen und Ressourcen.
|
|
Es wurde ein Netzwerk aktiviert. Die Job-Verarbeitung wird durch den Monitor gesteuert. |
|
|
Die Vorbedingungen für einen Job werden nach der
Job-Aktivierung geprüft.
Falls eine Vorbedingung nicht erfüllt wird (z.B. wenn der für den Job definierte Ausführungsknoten nicht zur Verfügung steht), wird die Vorbedingungsprüfung an der Stelle angehalten, an der sie nicht erfolgreich war. |
|
|
Der Job wird in einen aktiven Wartezustand
versetzt und wartet darauf, dass die erforderliche Vorbedingung bis zur
nächsten Prüfung erfüllt wird.
Die Vorbedingsprüfung wird der Stelle fortgesetzt, an der die vorangegegangene Prüfung nicht erfolgreich war. |
|
|
Der Monitor bestimmt, wie lange auf die fehlende Vorbedingung gewartet werden soll, bevor den Job in einen passiven Wartezustand versetzt. |
|
|
Eine Trigger-Routine reaktiviert den Job, wenn
die für die Reaktivierung des Jobs definierten Kriterien erfüllt sind (z.B. der
nicht verfügbare Ausführungsknoten steht jetzt zur Verfügung), und erzwingt die
erneute aktive Prüfung des Jobs.
Der Prüfvorgang (von aktivem zu passivem Warten und umgekehrt) kann sich mehrere Male wiederholen. The check procedure (from active to passive wait and vice versa) can repeat several times. |
|
|
Wenn alle Vorbedingungen erfüllt sind, wird der Job zur Ausführung gestartet. |
Anmerkung:
Bei jedem Monitorstart werden alle Jobs, die sich in der passiven
Warteschlange befinden, für eine weitere Vorbedingungsprüfung
reaktiviert.
In den folgenden Fällen kann kein passives Warten ausgeführt werden:
Warten auf eine Eingabebedingung, die von der Existenz einer Datei abhängt,
Warten auf eine Eingabebedingung, die von dem Ergebnis eines User Exit abhängt.
In diesen Fällen kann Entire Operations nicht selbst feststellen, wann ein solcher Job wieder in den aktiven Wartezustand zurückgestellt werden soll. Deshalb wird ein aktiver Job in einem solchen Fall nicht in den passiven Wartezustand versetzt.
Ein passives Warten kann aber auch für diese Jobs zumindest für einen Teil der Wartezeit ausgeführt werden, wenn sie parallel zu den oben genannten Fällen auf eine "normale" Bedingung warten, die möglichst kurz vor dem Job-Start gesetzt wird.
Mit anderen Worten: Es empfiehlt sich, ein Warten auf Bedingungen mit speziellen Abhängigkeiten durch ein Warten auf "normale" Bedingungen zu flankieren.
Wenn Vorbedingungen und Ressourcen eines aktiven Jobs aktiv geprüft werden, wird die Reihenfolge der Prüfungen eines Jobs dynamisch optimiert.
Bei einer Folgeprüfung wird wieder bei der letzten nicht erfolgreichen Prüfung aufgesetzt. Damit wird vermieden, dass erfolgreiche Prüfungen redundant mehrfach durchlaufen werden. Es ist jedoch sichergestellt, dass direkt vor der Freigabe zum Job-Start alle Eingabebedingungen und Ressourcen zusammen zu einem Zeitpunkt überprüft worden sind.
Das folgende Diagramm zeigt den Ablauf des Round-Robin-Verfahrens bei der Prüfung von Vorbedingungen und Ressourcen:
Nach der Terminologie von Entire Operations ist ein Ereignis das Auftreten einer definierten Situation, die in der Job-Ende-Analyse erkannt wird. Entire Operations stößt automatisch eine Systemaktion an - je nach dem Auftreten von Ereignissen während der Job-Verarbeitung. Siehe Job-Ende-Prüfung und Aktionen.
Eine beliebige Anzahl von Ereignissen kann für einen Job definiert werden.
Einige Beispiele für mögliche definierte Ereignisse sind:
Exit-Code eines UNIX-Jobs ist gleich 2;
STEP2 von JOB1 wird mit einem Bedingungscode beendet, der größer als 8 ist;
kein Job-Step wird mit einem Bedingungscode beendet, der größer als 0 ist;
eine definierte Meldung erscheint im Job-SYSOUT;
eine Datenbank oder Datei enthält bestimmte erwartete Daten - oder enthält sie nicht;
das Ergebnis eines User Exit (ausgedrückt durch ihren Rückgabe-Code);
eine Job-Variable enthält bestimmte erwartete Daten (BS2000).
Der Ausdruck "Job-Ende-Aktionen" bezieht sich auf alle Aktionen, die nach Beendigung eines Jobs erfolgen. Diese Aktionen können automatisch von Entire Operations oder manuell vom Benutzer ausgeführt werden.
Job-Ende-Prüfung und -Aktionen erfolgen in zwei Schritten:
Job-Ergebnisse analysieren (Job-Ende-Status feststellen).
Entsprechende Systemaktionen anstoßen.
Entire Operations erkennt den Job-Ende-Status am Auftreten benutzerdefinierter Ereignisse. Ein solches Ereignis kann z.B. eines der im Abschnitt Ereignisse beschriebenen Ereignisse sein.
Wenn Sie kein Ereignis definieren, verwendet Entire Operations ein Standard-Ereignis, das als "Job OK" oder "Job nicht OK" bezeichnet wird - je nachdem, ob ein erhaltener Bedingungscode größer oder kleiner als ein Standardwert-Bedingungscode ist oder (im Falle von BS2000) bestimmte Systemmeldungen aufgetreten sind.
Sie können definieren, wie sich Entire Operations bei jedem der benutzerdefinierten Ereignisse oder bei Standard-Ereignissen verhalten soll. Eine solche Job-Ende-Aktion kann aus einer der folgenden Aktivitäten bestehen:
Ausgabebedingungen setzen, um den Job-Fluss fortzusetzen.
Eine Meldung an bestimmte Benutzer oder die Konsole verschicken, die Informationen über ein eventuell abnormales Ereignis oder eine aktuelle Bedingung enthält.
SYSOUT-Daten eines Jobs ausdrucken oder löschen.
Ausgabedateien oder SYSOUT an Entire Output Management übergeben.
Einen User Exit ausführen.
Andere Job-Netzwerke aktivieren.
Eine Fehlerbehandlung durchführen.
Eine Jobvariable setzen (nur BS2000).
Weitere Informationen siehe Job-Ende-Prüfung und -Aktionen.
In z/OS-Systemumgebungen
Die Überprüfung des Job-Ergebnisses wird vom Entire Operations-Monitor
bis zu zehn Mal versucht, wenn die Meldung erscheint, dass der Job aus der
Spool-Warteschlange verschwunden ist.
Das Warte-Intervall zwischen den Versuchen, SYSOUT zu lesen, beträgt konstant 30 Sekunden (nicht zu verwechseln mit der Monitor-Wartezeit, die sehr kurz sein kann).
In BS2000-Systemumgebungen
Entire Operations kann den Job-SYSOUT nur dann prüfen, wenn dieser
einer Datei zugeordnet ist. Die JCL von Jobs, die unter der Kontrolle von
Entire Operations laufen sollen, dürfen deswegen keine SYSOUT-Zuweisung an
"*dummy", "primary" oder eine temporäre Datei
enthalten, andernfalls ist die Job-Ende-Prüfung nicht möglich.
Siehe auch SYSOUT-Aktionen definieren.
Dieser Abschnitt behandelt folgende Themen:
Siehe auch:
Ressourcen im Abschnitt Entire Operations-Objekte in Konzept- und Leistungsumfang
Ressourcen in der Systemverwaltung-Dokumentation
Ressourcen können Voraussetzungen für einen Job sein. Entire Operations startet den Job erst dann, wenn die Ressourcen in der definierten Menge verfügbar sind. Sie können folglich Ressourcen verwenden, um den Job-Fluss mit zu steuern, wenn alle Eingabebedingungen für Jobs, die parallel laufen können, erfüllt sind. Dazu definieren Sie die Priorität der Ressourcenvergabe an einen Job.
Bei Ressourcen unterscheidet man die Merkmale:
quantitativ oder absolut
wiederverwendbar oder nicht wiederverwendbar.
Beispiele:
| Ressourcen | Merkmal |
|---|---|
| Druckformulare | quantitativ, nicht wiederverwendbar |
| Hauptspeicher | quantitativ, wiederverwendbar |
| Leitung zu dezentralem Rechner | absolut |
| Verfügbarkeit eines Gerätes | absolut |
Jede Ressource muss in der Systemverwaltung als Master-Ressource definiert sein, bevor sie als Voraussetzung für einen beliebigen Job definiert werden kann.
Die aktuelle Menge einer Master-Ressource kann durch einen Exit bestimmt werden, der in regelmäßigen Abständen vom Entire Operations-Monitor aufgerufen wird.
Ressourcen können entweder reale Systemressourcen darstellen oder virtuell sein. Entire Operations überwacht Ressourcen, soweit sie in der Verwaltungsfunktion für Netzwerke und Jobs definiert sind (siehe Vorausgesetzte Ressourcen für einen Job verwalten im Abschnitt Job-Verwaltung.
Die folgenden Regeln gelten für die Anordnung von Ressourcen-Zuweisungen:
Wenn eine Ressource von dem gleichen Eigentümer, Netzwerk, oder Job aber unterschiedlichen Läufen zur gleichen Zeit angefragt wird, erhält der aktive Job mit der niedrigsten Laufnummer oder der frühesten Aktivierungs-Zeit die Ressource zuerst.
Wenn verschiedene Jobs eines aktiven Netzwerkes oder verschiedener aktiver Netzwerke auf die gleiche Ressource warten: Die verfügbare Menge der Ressource wird auf so viele Jobs wie möglich parallel verteilt unter Beachtung von Punkt 1.
Wenn ein Ressourcen-Wartezyklus mit einer höheren Priorität während
einer Ressourcen-Bedingungsprüfung gefunden wird, wird die Meldung
Ressource <Ressource-Name> verfügbar, andere Jobs haben
Priorität in das Protokoll geschrieben. Anschließend kommt die Meldung
Ressource <Ressource-Name> - im Wartestatus mit höherer
Priorität und eine oder mehrere Zeilen mit kontextspezifischen
Informationen.
Gewöhnlich wird eine Ressource für die Dauer der Ausführung eines Jobs zugewiesen. Vor Entire Operations 4.1.1 konnten Ressourcen nur auf diese Art belegt werden.
Ab Entire Operations Version 4.1.1 ist es möglich, Ressourcen für einen längeren Zeitraum zu belegen. Diese Funktion steht im Fenster Definition einer vorausgesetzten Ressource für einen Job (Freigabe-Modus) zur Verfügung.
Es gibt folgende Freigabe-Modi für Ressourcen:
| Code | Ressourcen-Freigabe | Bedeutung |
|---|---|---|
J
|
Freigabe bei Beenden des Jobs (Standard) | Die Ressource wird freigegeben, wenn der zuweisende Job beendet ist. |
N |
Freigabe bei Beenden des Netzwerks. |
Die Ressource wird freigegeben, wenn der Entire Operations-Monitor feststellt, dass alle Jobs eines Job-Netzwerks beendet sind. Anmerkung: |
E |
Freigabe bei Beenden des Netzwerks, jedoch frühere Freigabe nach einem fehlerhaften Job. | Die Ressource wird bis zum Beenden des Netzwerks
belegt gehalten. Falls ein Job mit nicht ok endet, wird sie
unmittelbar nach dem Beenden dieses Jobs freigegeben.
|
K |
Belegt halten bis zur manuellen Freigabe. | Die Ressource wird nicht automatisch bei Beendigung des Jobs oder Netzwerks freigegeben. |
Es gelten immer die folgenden zusätzlichen Regeln:
Ist ein aktives Netzwerk oder ein aktiver Job deaktiviert,
werden auch alle damit belegten Ressourcen freigegeben. Dies wird ungeachtet
des definierten Freigabemodus durchgeführt, d.h., auch Ressourcen mit
Freigabe-Modus K (Keep = belegt halten) werden in diesem Falle
freigegeben.
Mengen einer Master-Ressource können durch Aufrufen von API-Routinen geändert werden. Beachten Sie, dass dies nur möglich ist, wenn die Menge nicht durch einen User Exit zur Bestimmung der Menge einer Ressource festgelegt ist.
Ressourcen können durch den Aufruf einer API-Routine für einen Job belegt werden. Diese zusätzlich belegten Ressourcen werden genauso behandelt wie definierte vorausgesetzte Ressourcen.
Ressourcen können durch Aufrufen von API-Routinen freigegeben werden. Vorläufige Freigaben von Ressourcen sind für Freigabe-Modi zulässig.
Alle Ressourcen-Belegungen und -Freigaben werden protokolliert.
Weitere Informationen zu diesem Thema finden Sie unter Bearbeiten von Ressourcen-Belegungen im Abschnitt API-Routinen.
Ressourcen werden zwangsweise freigegeben, falls der Zeitraum für die Ressource-Belegung größer ist als der Aufbewahrungszeitraum für aktive Bedingungen ist.
Der Ort und der Grund von Ressourcen-Freigaben werden aufgezeichnet:
während einer Netzwerk-Deaktivierung,
während einer Job-Deaktivierung,
während einer erzwungenen Freigabe einer Ressourcen-Zuweisung,
während einer Bereinigung ("Cleanup").
Es ist möglich, eine Ressourcen-Freigabe zu unterbinden, wenn ein Job
mit nicht ok beendet wurde. Dies ist z. B. der Fall, wenn eine
Ressource bei einer Wiederherstellung für einen nicht erfolgreichen Lauf belegt
gehalten werden soll. Hier gelten auch die zusätzlichen Regeln. Dies bedeutet,
dass eine solche Ressource auch automatisch freigegeben wird, wenn der
zuweisende Job deaktiviert wird.
Siehe Feld Freigabe, wenn nicht ok in Feldbeschreibung: Definition einer vorausgesetzten Ressource (Master).
Alle aktuellen Ressourcen-Belegungen können in Benutzungslisten abgefragt werden. Von diesen Benutzungslisten aktiver Ressourcen aus ist es möglich, die Freigabe einer gegebenen Ressourcen-Belegung zu erzwingen.
Weitere Informationen siehe Ressourcen-Verwendung zeigen im Abschnitt Ressourcen in der Systemverwaltung-Dokumentation.
Bitte benutzen Sie diese Funktion mit Bedacht. Seien Sie sich dessen bewusst, dass einer oder mehrere aktive Jobs, die auf diese Ressource gewartet haben, sofort gestartet werden können.
Die verfügbare Menge einer Ressource kann mittels eines Exits bestimmt werden. Ein User Exit zur Bestimmung der Menge einer Ressource wird vom Entire Operations-Monitor vor Prüfungen vorausgesetzter Ressourcen aufgerufen.
Weitere Informationen siehe Ressource-Bestimmungs-Exit im Abschnitt Ressourcen in der Systemverwaltung-Dokumentation.
Mailboxen werden zum Nachrichtenaustausch mit Entire Operations-Benutzern verwendet. Wenn eine Nachricht eine Reaktion erfordert, kann dies im Mailbox-Fenster dargestellt werden.
Jede Eingabebedingung kann einer Benutzerinteraktion zugeordnet werden.Der Benutzer kann nach Erhalt einer Nachricht entsprechende Maßnahmen ergreifen und die Bedingungen manuell setzen, die für das Fortsetzen des Jobs nötig sind.
Das Konzept der Mailboxen ermöglicht es Ihnen, manuelle Aktionen in das Job-Netzwerk zu integrieren.
Die nachstehende Abbildung zeigt als Beispiel die Mailbox "Papiermenge":
Job 1 "Bericht erstellen" erstellt einen Bericht. Die Bedingung "Papier OK" wird als die Eingabebedingung für Job 2 "Bericht drucken" definiert.
Wenn Sie die Nachricht "Bedingung Papier OK anstehend" empfangen, können Sie die erforderliche Menge Papier zur Verfügung stellen und die Bedingung direkt im Mailbox-Fenster an Ihrem Bildschirm manuell setzen. Entire Operations kann dann mit dem nächsten Job ("Bericht drucken") fortfahren.
Die Mailbox SYSDBA, auf die der Eigentümer SYSDBA Zugriff hat, enthält alle Nachrichten, für die keine Empfänger definiert wurden.
Eine ausführliche Beschreibung aller Mailbox-Funktionen finden Sie im Abschnitt Mailboxen.
Knoten sind Entire System Server und beziehen sich auf Maschinen, auf denen die Betriebssystem-Anforderungen ausgeführt werden. Knoten unterscheiden sich durch numerische Kennungen, genauso wie Datenbankkennungen zwischen Adabas-Datenbanken unterscheiden. Innerhalb Entire Operations wird jeder Maschine eine Knotennummer zugewiesen. In einer physischen Maschine kann sich mehr als ein Betriebssystem-Server-Knoten befinden.
Auf den Maschinen, die durch Knotenkennungen bezeichnet werden, können verschiedene Ziel-Betriebssysteme laufen. Entire Operations erkennt das Betriebssystem.
Kommunikationswege zwischen ansonsten isolierten Knoten werden von Entire Net-work und EntireX Broker bereitgestellt. Diese Software-AG-Produkte ermöglichen eine transparente Verbindung von Knoten ungeachtet der Art ihrer physischen Verknüpfung.
Bei der Definition eines Job-Netzwerks in Entire Operations können Standard-Knoten für die JCL und für die Ausführung der Jobs angegeben werden. Diese Standard-Knoten können bei jedem Job geändert werden mit der Folge, dass verschiedene Jobs innerhalb desselben Netzwerks auf verschiedenen Maschinen laufen können.
Das folgende Abbildung zeigt ein Beispiel dafür, wie Entire Operations Server und Knoten auf verschiedenen Maschinen und unter verschiedenen Betriebssystemen unterstützen kann:
Weitere Informationen siehe Definition der Knoten in der Systemverwaltung-Dokumentation.
Dieser Abschnitt behandelt folgende Themen:
Die Master-Datenbank speichert alle Benutzer-, Job-Netzwerk-, Job- und Zeitplanungsdefinitionen. Sie enthält außerdem alle Informationen über definierte logische Bedingungen, Ressourcen, Kalender und Symboltabellen. Alle in der Master-Datenbank gespeicherten Informationen können online verwaltet werden.
Weitere Informationen siehe Master-Datenbank in Konzept und Leistungsumfang.
Wenn ein Job-Netzwerk aktiviert wird, wird es in die aktive Datenbank kopiert. Die aktive Datenbank kann mehrere Kopien desselben Job-Netzwerkes enthalten, von denen jede durch eine eindeutige Laufnummer unterschieden wird. Alle aktuellen Informationen über Bedingungsstatus und Job-Status, aktive JCL und Symbole sind in der aktiven Datenbank enthalten und können geändert werden.
Die Master-Datenbank und die aktive Datenbank befinden sich normalerweise in derselben physischen Datenbankdatei.
Weitere Informationen siehe:
Aktive Datenbank im Abschnitt Entire Operations Komponenten in Konzept- und Leistungsumfang
Direktkommando SET
ACTIVE (setzt die Auswahlkriterien für die aktive
Datenbank)
Bereinigung der aktiven Datenbank in der Systemverwaltung-Dokumentation
Bereinigung der aktiven Datenbank im Batch-Betrieb im Abschnitt Spezielle Monitor-Funktionen und Batch-Jobs
Dieser Abschnitt behandelt folgende Themen:
Der Entire Operations-Monitor aktiviert und verarbeitet Job-Netzwerke entsprechend der für deren Ausführung vorausgeplanten Tage und Uhrzeiten. Mögliche Funktionen sind:
Aktivierung geplanter Job-Netzwerke
Prüfung der Vorbedingungen (Eingabebedingungen und Ressourcen)
Job-Start
Job-Ende-Prüfung und -Aktionen
Protokollierung aller Ereignisse
In technischer Hinsicht können Sie den Monitor auf zwei Arten betreiben, und zwar als eine oder mehrere Subtasks oder als Batch-Task.
Sie können den Entire Operations-Monitor als eine oder mehrere Subtasks einer Entire System Server Task in z/OS- oder z/VSE-Betriebssystemen betreiben.
Die JCL der Entire System Server-Task (XCOM-Knoten) muss für die Anforderungen des Monitors erweitert werden. Außerdem müssen die XCOM-Parameter ergänzt werden. Die REGION-Zuweisung für die Entire System Server-Task muss groß genug sein, um den Monitor aufzunehmen. Weitere Informationen siehe Entire Operations auf Großrechner installieren in Installation und Inbetriebnahme von Entire Operations in der Installation und Operations-Dokumentation.
Die Vorteile dieser Methode sind:
Alle Entire System Server-Aufrufe des Monitors an den eigenen Knoten werden lokal bearbeitet, ohne dass eine Inter-PROCESS-Kommunikation stattfindet;
Der Entire System Server und der Entire Operations-Monitor teilen denselben Adressraum.
Unter z/OS oder BS2000 können Sie den Entire Operations-Monitor als eine eigene Batch-Task betreiben.
Der Monitor kann wie ein beliebiger Batch-Job laufen. Die Funktionen, die er in diesem Modus zur Verfügung stellt, sind dieselben wie unter einer Subtask. Als Batch-Task erfordert der Monitor jedoch, dass der Betriebssystem-Server-Knoten aktiv bleibt, solange er selbst aktiv ist.
Von der Implementierung her ist der Entire Operations-Monitor ein Sonderbenutzer innerhalb Entire Operations. Der Monitor wird nicht von einer Terminaleingabe gesteuert, sondern von den eigenen Verarbeitungsregeln.
Der Systemadministrator kann einen Zeitabstand zwischen Monitorzyklen definieren. Zu Anfang eines Zyklus wird der Monitor aktiviert und prüft dann die Entire Operations-Arbeitswarteschlangen. Hier führt der Monitor alle erforderlichen Aktionen (z.B Job-Start und Job-Ende-Prüfung und -Aktionen) durch. Die zu definierende Wartezeit zwischen zwei Monitorzyklen hängt von der Anzahl der Jobs ab, die für das System definiert sind, und von ihrer durchschnittlichen Laufzeit. Je kürzer die Wartezeit, desto kürzer der Zeitabstand zwischen der Beendigung des Jobs und seiner Job-Ende-Analyse. Diese verkürzte Wartezeit hat allerdings eine zusätzliche Belastung des Systems wegen der häufigen Reaktivierung des Monitors zur Folge.
Die einzelnen Funktionen, die der Entire Operations-Monitor auszuführen hat, können auf mehrere Subtasks verteilt werden. Durch dieses "Subtasking" können Verarbeitungsprozesse parallelisiert und Performance-Verbesserungen erzielt werden. Die Verteilung der Monitor-Funktionen auf Subtasks ist möglich unter z/OS, z/VSE, BS2000 und UNIX. Unter BS2000 und UNIX sind Monitor-Subtasks separate Prozesse im Betriebssystem.
Einzelheiten dazu, wie die typischen Monitor-Funktionen verteilt werden, entnehmen Sie dem Abschnitt Profil der Monitor-Tasks in der Systemverwaltung-Dokumentation.
Wenn ein Job-Netzwerk mit dem Namen MON-START unter dem Eigentümer SYSDBA definiert ist, wird dieses Netzwerk exklusiv bei jedem Entire Operations-Monitor-Start ausgeführt. Dieses Netzwerk wird als Monitor-Start-Netzwerk bezeichnet.
Bevor das Start-Netzwerk ordnungsgemäß beendet ist, wird kein anderes Job-Netzwerk gestartet.
Der letzte Job des Start-Netzwerkes darf keine Bedingung setzen (aber der Job darf Bedingungen zurücksetzen). Während der Ausführung des Start-Netzwerkes ist die absolute Bedingung SYSDBA/MON-START-RUNNING gesetzt.
Falls irgendein Job des Start-Netzwerkes nicht ok endet,
bleibt diese Bedingung wahr und blockiert jede weitere Monitor-Aktion. Die
Bedingung kann manuell zurückgesetzt werden, um die Abarbeitung weiterer
Verarbeitungsaufträge freizugeben. Während der Zeit, in der die absolute
Bedingung aktiv ist, erscheint bei jedem Monitor-Zyklus die Meldung
Start-Netzwerk läuft noch im Protokoll und auf der
System-Konsole.
Siehe auch Monitor-Start-Netzwerk in Spezielle Monitor-Funktionen und Batch-Jobs im Abschnitt Spezielle Monitor-Funktionen und Batch-Jobs.
Dieser Abschnitt behandelt folgende Themen:
Das Aktivieren eines Job-Netzwerkes oder Jobs bedeutet, dass das Netzwerk oder der Job zur Ausführung vorbereitet wird. Bei der Aktivierung wird folgendes durchgeführt:
Die Definitionen von Jobs, Netzwerken, logischen Bedingungen, Symboltabellen usw. werden in die aktive Datenbank von Entire Operations kopiert, in der ihnen eine eindeutige Laufnummer zugewiesen wird.
Falls nötig, wird die Eingabe von Symbolen angefordert. Die Symboleingabe wird allerdings nicht bei eventuell definiertem Unternetzwerk durchgeführt.
Der globale Aktivierungs-Exit für User Exits wird aufgerufen, sofern er in den Entire Operations-Standardwerten definiert ist.
Die JCL, die für Jobs innerhalb des Netzwerkes definiert ist, wird in den aktiven JCL-Speicher in der aktiven Datenbank kopiert.
Variablen (Symbole), die in einer dynamisch generierten JCL benutzt werden, werden durch ihre aktuellen Werte ersetzt. Dies gilt nicht für Variable, die gemäß Definition zum Zeitpunkt des Job-Starts ersetzt werden sollen.
Die Karten-Definitionen aktiver Job-Netzwerke bzw. aktiver Jobs können von denen der Master-Definition abweichen. Dazu müssen zum Aktivierungszeitpunkt in den zugehörigen Symboltabellen bestimmte vordefinierte Symbole vorhanden sein. Siehe auch Vordefinierte Symbole im Kapitel Symboltabellen und Symbole.
Falls vorgenerierte JCL verwendet wird, ist die Symbolersetzung bereits zum Zeitpunkt der JCL-Generierung durchgeführt worden.
Der Entire Operations-Monitor erkennt das Job-Netzwerk als aktiv und prüft die Zeitrahmen, Eingabebedingungen und Ressourcen, die für die Jobs definiert sind. Sind alle Voraussetzungen für einen Job erfüllt, so wird er gestartet.
Bei der Aktivierung eines Job-Netzwerks oder eines einzelnen Jobs bestimmt Entire Operations die Liste der erforderlichen (aktiven) Symboltabellen. Das Ergebnis dieser Bestimmung wird in das Entire Operations-Protokoll ("Log") geschrieben. Dies kann zum Beispiel folgendermaßen aussehen:
List of active Symbol Tables created Determined Symbol Table Versions for 17.01.14 ... Ob Job St SymTab defined determined ... NV 00 N1649T00 (current) -> v002 ... JM J001 00 N1649T00 (unnamed) -> (unnamed) ... JM J003 ED N1649T00 (current) -> v002 ... JM J004 ED N1649T00 (nv) -> (unnamed) ... JM J005 ED N1649T00 (svn) -> v002
Die Spalte St enthält den Status der zu aktivierenden Symboltabelle.
ED bedeutet "Auswertungsduplikat" (Evaluation
Duplicate). Dieser Status wird gesetzt, wenn eine frühere Bestimmung
(Auswertung) dieselbe Symboltabelle mit derselben Version ergeben hat. In
diesem Fall wird die Symboltabelle (Version) nur einmal aktiviert.
Die so bestimmten Symboltabellen-Versionen werden für die anschließende Symboltabellenaktivierung verwendet.
Im Falle eines Bestimmungsfehlers wird die Aktivierung des Job-Netzwerkes bzw. des Jobs abgebrochen.
In diesem Dokument und auf der Benutzeroberfläche werden die Begriffe Aktivierung und Netzwerk-Start bzw. Job-Start in der folgenden Bedeutung verwendet:
Aktivierung
Bezeichnet den Vorgang der Erstellung einer aktiven Kopie einer
Netzwerk- oder Job-Definition.
Netzwerk-Start bzw. Job-Start
Bezeichnet den tatsächlichen Beginn der Ausführung dieses aktivierten
(aktiven) Job-Netzwerkes oder Jobs.
Job-Netzwerke werden in zwei Schritten automatisch aktiviert:
Zu Anfang eines Tages oder während eines Monitor-Starts werden alle Zeitpläne für Job-Netzwerke geprüft, die im Laufe desselben Tages auszuführen sind. Dieser Prozess heißt Zeitplanauszug , und die extrahierten Daten heißen Aktivierungs-Aufträge.
Die Aktivierungs-Aufträge bewirken die Aktivierung eines Job-Netzwerks kurz vor dem frühesten Start des Netzwerks. Diese Zeitspanne kann in den Entire Operations-Standardwerten definiert werden. Siehe Feld Zeitplan-Auszüge im Abschnitt Standardeinstellungen (2) in der Systemverwaltung-Dokumentation.
Anmerkungen:
Nach der Erstellung der Aktivierungsaufträge werden die aktiven Symboltabellen für den entsprechenden Lauf des Netzwerks abgeleitet. Sofern es wenigstens ein Symbol mit dem Hinweis "muss eingegeben werden innerhalb dieser aktiven Symboltabellen" gibt, wird eine Eingabeaufforderung für dieses Symbol an die Mailboxen all derjenigen Benutzer geschickt, die als Meldungsempfänger für dieses Netzwerk definiert sind.
Die Netzwerkaktivierung wird solange ausgesetzt, bis ein Benutzer diese Eingabeaufforderung bemerkt und eine Eingabe oder Bestätigung für die angezeigten Symbole durchführt. Deshalb ist ein Zeitplanauszug auch für einige Tage im Voraus möglich; siehe Allgemeine Zeitplanauswertung in der Systemverwaltung-Dokumentation.
Ein Job-Netzwerk kann, unabhängig von jedem definierten Zeitplan, manuell aktiviert werden. Dies kann z. B. in folgenden Fällen notwendig sein:
Es wurde kein Zeitplan für das Job-Netzwerk definiert.
Ein definiertes Aktivierungsdatum und eine definierte Aktivierungszeit sollen übergangen werden.
Das Job-Netzwerk ist für das entsprechende Datum nicht eingeplant.
Eine Aktivierung eines Job-Netzwerks oder eines Jobs kann außerdem durch ein beliebiges Ereignis angestoßen werden, z.B. durch die Beendigung eines anderen Job-Netzwerkes innerhalb von Entire Operations oder durch die Anwendungsprogrammierschnittstelle ("API/Application Programming Interface") von Entire Operations (siehe Zugriff auf Entire Operations aus Anwendungen über API). Diese Aktivierung kann - ebenso wie die manuelle - jederzeit durchgeführt werden.
Auch bei der manuellen Aktivierung wird die Symboleingabe für aktive Symbole durchgeführt, wenn mindestens ein Symbol einer verwendeten Symboltabelle entsprechend markiert ist.
Wenn die errechnete späteste Startzeit nach der errechneten Ende-Zeit liegt, wird der letzte Start auf eine Minute vor der Ende-Zeit gelegt.
Wenn die (neue) späteste Startzeit vor der frühesten Startzeit liegt, wird die Job-Aktivierung abgebrochen und eine Fehlermeldung ausgegeben.
Entire Operations weist jeder aktiven Kopie eines Job-Netzwerkes in der aktiven Datenbank automatisch eine Laufnummer zu. Diese Laufnummer identifiziert eindeutig die aktive Kopie eines Job-Netzwerkes und wird automatisch seinen Jobs, Eingabe-Bedingungen usw. zugeordnet.
Die Zuweisung der Laufnummer erfolgt:
während der Erstellung der Aktivierungsaufträge,
bei manueller Aktivierung,
wenn ein Netzwerk durch eine API-Routine aktiviert wird.
Laufnummern liegen standardmäßig im Wertebereich 1 bis 99999. Sie sind auf Netzwerkebene eindeutig. Nach Erreichen der höchsten Laufnummer wird wieder bei 1 begonnen.
Die Obergrenze für Laufnummern kann in den Entire Operations-Standardwerten geändert werden. Weitere Information siehe Feld Limit für Laufnummern im Abschnitt Standardeinstellungen (2) in der Systemverwaltung-Dokumentation.
Durch die Zuweisung einer Laufnummer für jede Aktivierung eines Job-Netzwerkes können Sie ein Job-Netzwerk am selben Tag mehrfach aktivieren lassen und zwischen mehreren aktiven Kopien desselben Job-Netzwerkes unterscheiden.
Anmerkung:
Es wird nicht garantiert, dass aufeinander folgende
Netzwerk-Aktivierungen aufsteigende Laufnummern haben. Sie sind ebenso wenig
vorhersagbar wie Jobnummern des Betriebssystems. Auch bei gelöschten
Job-Netzwerken merkt sich Entire Operations die letzte Laufnummer. Bei erneuter
Definition eines Job-Netzwerkes gleichen Namens wird mit dieser (um 1 erhöhten)
Laufnummer fortgefahren.
Ein Zeitplan ist eine vordefinierte Zeittabelle, nach der ein Job-Netzwerk aktiviert wird. Entire Operations überwacht Zeitpläne, um festzustellen, welche Job-Netzwerke zu aktivieren sind.
Sie können Aktivierungsdaten in einem Zeitplan als explizite und/oder wiederkehrende Daten definieren (Wochentage, Monatstage oder eine Kombination von Tagen und Monaten).
Entire Operations kann in einem Zeitplan Feiertage wahlweise berücksichtigen. Beispiel: Wenn Sie ein Job-Netzwerk planen, das am ersten Tag eines Monats anlaufen soll, und die Zeitplantabelle sich auf einen Kalender bezieht, der Samstag und Sonntag als Nicht-Arbeitstage definiert, startet Entire Operations das Job-Netzwerk nicht, falls der erste Monatstag ein Samstag oder Sonntag ist. Die Aktivierung kann auf den nächsten Arbeitstag (in unserem Fall: Montag) verschoben werden. Mit anderen Worten: Entire Operations ist in der Lage, automatisch den ersten Monatstag als den ersten Arbeitstag eines Monats zu interpretieren.
Ein Zeitplan kann auf einem vordefinierten Kalender basieren, der zwischen Arbeitstagen und Nicht-Arbeitstagen unterscheidet.
Sie können den definierten Zeitplan im Kalenderformat überprüfen - unabhängig davon, ob Aktivierungsdaten als explizite oder relative Daten definiert sind. Dies ist möglich, weil Entire Operations relative Daten automatisch in explizite übersetzt.
Es ist möglich, die Ausführung einzelner Jobs eines Netzwerks von der Position im Zeitplan (z.B. erster Zeitplan-Tag der Woche) oder im Kalender (z. B. letzter Werktag des Jahres) abhängig zu machen.
Weitere Informationen siehe:
Kalender können die Grundlage der Zeitplantabellen bilden , die für Jobs und Job-Netzwerke definiert sind. Ein Entire Operations-Kalender unterscheidet zwischen Arbeitstagen und benutzerdefinierten Nicht-Arbeitstagen (d. h. Wochenenden, landesüblichen Feiertagen und Betriebsferien).
Kalender können geändert werden, um Arbeits- und Nicht-Arbeitstage aufzunehmen oder zu modifizieren. Änderungen von Kalendern können sich auf die Zeitpläne der damit verknüpften Job-Netzwerke auswirken.
Kalender werden durch Eigentümer, Namen und Jahr identifiziert und können einem Eigentümer gehören oder auch systemweit benutzt werden. Sie können einen Systemkalender oder einen eigentümerspezifischen Kalender für eine Zeitplantabelle angeben. Sie können jedoch nur Kalender ändern, die Ihrem Eigentümer gehören. Systemkalender können nur von dafür autorisierten Benutzern geändert werden.
Die Anzahl von Kalendern, die in Entire Operations definiert werden, kann beliebig groß sein.
Weitere Informationen siehe Kalender.
Eine Symboltabelle enthält eine Liste mit Symbolen (Variablen), die zum Ersetzen von Zeichenketten während der JCL-Generierung benutzt werden können.
Symbole werden normalerweise während der Aktivierung eines Job-Netzwerks oder Jobs ersetzt, d.h. während die aktive JCL in die aktive Datenbank geladen wird. Symbole können auch bei einem Job-Start ersetzt werden.
Weitere Informationen siehe Symboltabellen und Symbole.
Dieser Abschnitt behandelt folgende Themen:
Jobkontrolle wird in Entire Operations in folgender Weise verwendet:
Master-JCL
Das ist die JCL in ihrem ursprünglichen Format auf dem
Original-Datenträger. Die gängigen JCL-Speicherarten der Betriebssysteme werden
unterstützt. Auch die Quelltexte für die dynamische JCL-Generierung zählen zur
Master-JCL.
Aktive JCL
Das ist die tatsächlich an das Betriebssystem zur Ausführung
übergebene JCL. Sie wird zur Aktivierungszeit des Jobs oder Netzwerks aus der
Master-JCL erzeugt. Dabei werden die Symbole durch Werte aus der aktiven
Symboltabelle ersetzt. Falls es sich um dynamische JCL handelt, wird die
Generierung zu diesem Zeitpunkt ausgeführt. Die aktive JCL wird in der aktiven
Datenbank von Entire Operations gespeichert.
Vorgenerierte aktive JCL
Aus
Performance-Gründen kann es notwendig werden, aktive JCL im voraus zu
generieren. Die Vorgenerierung aktiver JCL wird mit einem Zeilenkommando im Bildschirm
Job-Verwaltung aufgerufen. Siehe
Aktive JCL
vorgenerieren.
Die Vorgenerierung muss jedes Mal neu ausgeführt werden, wenn
die Definition der Master-JCL-Speicherung geändert wurde,
die Master-JCL editiert wurde,
die zugehörige Symboltabelle geändert wurde.
Das Editieren von JCL ist mit dem Software AG Editor möglich. Siehe Editor.
Bei allen Speicherarten von Master-JCL können Symbole zur Ersetzung definiert werden.
Fluchtzeichen für Symbole können systemweit vorgegeben werden, sie können aber auch für jeden Job individuell definiert werden. Standardwerte für Fluchtzeichen können für jedes Betriebssystem definiert werden.
Fluchtzeichen zur Symbolersetzung dürfen nicht in Konflikt mit anderweitig in der JCL verwendeten Zeichen kommen.
Weitere Informationen siehe Symboltabellen und Symbole.
Entire Operations ermöglicht das Einfügen von Textobjekten in die JCL. Die Textobjekte können ihre eigenen lokalen Parameter haben. Textobjekte können andere Textobjekte aufrufen, d. h. eine Verschachtelung ist möglich.
Das Einfügen von Textobjekten kann nicht nur aus Macro-Jobs
(JCL-Speicherart MAC) verwendet werden, sonderen auch bei
verschiedenen anderen JCL-Speicherarten.
Weitere Informationen siehe Textobjekte in die JCL einfügen.
Die Namensgenerierung für Arbeitsdateien unter BS2000 ist beschrieben unter BS2000 im Abschnitt Namenskonventionen bei Arbeitsdateien in der von Entire Operations Installation und Inbetriebnahme-Dokumentation.
Namen von BS2000-Arbeitsdateien können auch durch einen User Exit erzeugt werden; siehe Generieren von SYSOUT-Dateinamen für BS2000 im Abschnitt API-Routinen.
Die Environment-Variable $EOR_WORK von
Entire System Server (NPR) unter UNIX enthält den Namen des
Entire
Operations-Arbeitsverzeichnisses. Innerhalb dieses Verzeichnisses
werden die Arbeitsdateien hierarchisch gespeichert.
Dieser Abschnitt behandelt folgende Themen:
Das Jobkontrollsystem von Entire Operations läuft auch in einer Windows-Umgebung, mit folgenden Charakteristika:
betriebssystemneutrale Modellierung von Job-Netzwerken,
transparente Bereitstellung der bisherigen Funktionalität und Flexibilität von Entire Operations auch für Windows,
Unterstützung von DOS-Batch-Dateien und ausführbaren Programmen (EXE),
Vermeidung der direkten Eingabe von Windows-DOS-Kommandos,
Ablauffähigkeit in gemischten Großrechner-/Windows-/UNIX-Umgebungen,
Jobkontrolle auf mehreren Windows-Maschinen gleichzeitig.
Entire Operations-Monitor
Der Monitor kann unter dem Betriebssystemen BS2000, z/OS, z/VSE und
UNIX laufen und dabei gleichzeitig Jobs steuern, die auf den Plattformen
BS2000, z/OS, z/VSE und UNIX zur Ausführung kommen.
Entire System Server (NPR) für Großrechner, UNIX und
Windows
Erforderlich für den Zugriff auf Großrechner-, UNIX- oder
Windows-Betriebssysteme.
Auf jeder zu steuernden Maschine muss ein Entire System Server/Windows-Server installiert sein. Dieser wird als Windows-Service installiert und kann mit der Windows-Dienste-Verwaltung administriert werden.
Entire Net-work/EntireX Broker
Dient als Transportschicht.
Zur Ausführung von Betriebssystem-Funktionen gibt es auf jedem Windows-Knoten einen Server vom Typ Entire System Server/Windows. Dieser Server läuft als Windows-Prozess im Hintergrund.
Zur Kommunikation mit den Servern verwenden der Entire Operations-Monitor und die Entire Operations-Online-Anwendung folgende Komponenten:
die Kommunikationsschicht der System Automation Tools (SAT),
den Entire Broker zur Übermittlung von Client/Server-Anforderungen,
Entire Net-work als Transportschicht.
Es können maximal 740 Windows-Knoten gleichzeitig bedient werden.
Da auf Großrechnern kein umgekehrter Schrägstrich, engl.: Backslash, (
\ ) zur Verfügung steht, können Windows-Dateinamen alternativ auch mit einem
normalen Schrägstrich ( / ) geschrieben werden, wenn dem Dateinamen unmittelbar
die Zeichenfolge +F+ vorausgeht. Dies gilt auch für Dateinamen
innerhalb von JCL.
| Original Windows: |
c:\jcl\script1.bat |
| Alternative Darstellung: |
+F+c:/jcl/script1.bat |
Vom Entire Operations-Monitor werden alle Jobs mit Umlenkung der Job-Ausgabe in eine Datei gestartet. Die SYSOUT-Dateien werden im Entire Operations-Arbeitsverzeichnis abgelegt. Im Falle einer Job-Wiederholung wird die alte SYSOUT-Datei umbenannt.
Die Umgebungsvariable %EOR_WORK% von
Entire System Server unter Windows enthält den Namen des Entire
Operations-Arbeitsverzeichnisses. Innerhalb dieses Verzeichnisses werden die
Arbeitsdateien hierarchisch abgelegt.
Die Namensgenerierung für Arbeitsdateien unter BS2000 ist beschrieben unter Namenskonventionen bei Arbeitsdateien, Abschnitt Windows in der Installation und Inbetriebnahme von Entire Operations-Dokumentation.
Der Name des Arbeitsverzeichnisses für ein aktives Netzwerk ist in dem
vordefinierten Symbol P-NADIR verfügbar. Anwendungsspezifische
Arbeitsdateien dürfen dort abgelegt werden, soweit es keine Namenskonflikte mit
von Entire Operations erzeugten Dateien gibt.
Von Entire Operations und von der Anwendung erzeugte Arbeitsdateien werden bei der Netzwerk- oder Job-Deaktivierung vom Entire Operations-Monitor gelöscht.
Umgebungsvariablen ("Environment Variables") von Windows können innerhalb von Dateinamen beliebig verwendet werden. Dies entspricht dem aus BAT-Dateien gewohnten Verhalten. Die Kombination von Umgebungsvariablen und Variablen aus Symboltabellen ist möglich.
Die Jobkontrolle für Windows kann an beliebiger Stelle abgelegt sein. Sie kann unter anderem in Natural-Textobjekten oder in Großrechner-Dateien abgelegt sein. Symbolersetzung und JCL-Generierung (Speicherart MAC) stehen zur Verfügung.
Jobs werden wie auf dem Großrechner vom Entire Operations-Monitor bedingungs- und zeitabhängig gestartet. Accounting-Daten werden gewonnen und gespeichert. Der manuelle Job-Abbruch ("Cancel") aus der Online-Umgebung ist möglich.
Entire Operations fügt der Windows-Jobkontrolle einige
echo-Anweisungen hinzu, um bestimmte Meldungen im
SYSOUT steuern zu können:
Start- und Ende-Meldung mit Zeitangabe
Job-Laufzeit
Anhand dieser Meldungen wird die Vollständigkeit des Job-Laufs überprüft, und außerdem werden Accounting-Informationen gewonnen. Zur Prüfung des Jobs kann man die Suche nach Zeichenketten im SYSOUT und Job-Ende-Prüfungsroutinen verwenden.
Das Versenden von Nachrichten (z.B. mittels E-Mail) an Benutzer kann
von Windows-Knoten aus erfolgen. In der Knoten-Definition von Windows-Knoten
kann man ein Programm zum Senden von Nachrichten definieren. Dieses Programm
muss von der DOS-Eingabeaufforderung ("Command Prompt") aus
aufgerufen werden können. Ein Beispiel dafür ist das Shareware-Programm
wsendmail. Alle anderen Formen der Nachrichtenübermittlung, wie
die Entire Operations-Mailbox, können weiterhin verwendet werden.
Das Drucken von Dateien und SYSOUT-Listen kann als Job-Ende-Aktion definiert werden. Für jeden Windows-Knoten kann ein Windows-Druckbefehl mit Platzhalter für den Dateinamen definiert werden. Über User Exits können weitere Aktionen ausgeführt werden.
Dieser Abschnitt behandelt folgende Themen:
Sobald Entire Operations ein Job-Netzwerk aktiviert, wird die JCL der Jobs im Netzwerk in die aktive Datenbank kopiert. Entire Operations stellt eine Funktion zur Verfügung, mit der Sie Variablen in der ursprünglichen JCL benutzten können, und die Teile der JCL je nach Programmlogik erzeugen kann. Variablen werden durch ihre aktuellen Werte entweder bei Aktivierung oder beim Job-Start ersetzt. Dieser Vorgang wird als "Dynamische JCL-Generierung" bezeichnet. Er betrifft nur Jobs mit Speicherart MAC in Entire Operations.
Die dynamisch generierte JCL ist z.B. dann sinnvoll, wenn die JCL nur
unter bestimmten Umständen einen Verarbeitungsschritt enthalten soll. Beispiel:
Ist das aktuelle Datum YYYYMMDD, dann soll der Jobstep
X aufgenommen werden.
Die dynamische JCL kann für Jobs mittels der Editierfunktion in der
Job-Verwaltung von Entire Operations definiert werden. Zur Konvertierung der
bestehenden JCL in das Entire Operations MAC-Format ist die JCL-IMPORT-Funktion
in der Job-Definition zu benutzen, wobei NAT als JCL-Speicherart anzugeben ist.
In jedem Falle muss das Editor-Kommando MACRO zur
Generierung der endgültigen JCL benutzt werden; zum Testen der Generierung
steht das Editor-Kommando TEST zur Verfügung.
Anmerkung:
Das Macro TEST aktiviert nur Job- und
Netzwerk-Symboltabellen, d.h., die Funktion des Macros TEST kann
mit der Meldung Symbol nicht gefunden einen Fehlschlag
anzeigen, aber dennoch erfolgreich durchlaufen, wenn das Macro beim Laden
aktiver JCL ausgeführt wird und dabei mehrere Symboltabellen (zum Beispiel
Aufrufer-Symboltabellen) zur Verfügung stehen.
Zum Editieren und Generieren von MAC-Jobs müssen Sie den Software AG Editor verwenden.
Weitere Informationen siehe:
Die Entire Operations-Bibliothek enthält einige Routinen, die aus einer
beliebigen Natural-Anwendung heraus aufgerufen werden können, um Zugriff auf
interne Entire Operations-Daten zu ermöglichen. Diese Routinen definieren
jeweils eine Anwendungsprogrammierschnittstelle, die als API
("Application Programming Interface") bezeichnet wird. Ein solches
API kann einfach mit einem Natural-CALLNAT-Statement aufgerufen
werden.
Das API stellt die folgenden Funktionen zur Verfügung:
Dynamische Verbindung zur Entire Operations-Datei
Zugriff auf Bedingungen
Zugriff auf Symbole
Informationen in das Entire Operations Protokoll schreiben
Ein API kann innerhalb und außerhalb von Entire Operations für verschiedene Aufgaben benutzt werden.
Beispiele:
Symboltabellen während der Ausführung eines Job-Netzwerkes dynamisch ändern.
Bedingungen aus Natural-Programmen heraus ändern.
Informationen zwischen Entire Operations und einer beliebigen Online- oder Batch-Anwendung austauschen.
Eingabebedingungen für Job-Netzwerke von Online-Anwendungen setzen.
Von Anwendungen den Status von Job-Netzwerken abfragen.
Entire Operations-Symbole aus externen Tabellen setzen.
Entire Operations-Symbole zur Benutzung in externen Anwendungen abfragen.
Ausführliche Informationen siehe Kapitel API-Routinen.
Dieser Abschnitt behandelt folgende Themen:
Jobs, die in Entire Operations definiert und geplant werden, werden automatisch unter der Kontrolle des Entire Operations-Monitor gestartet. Während des Startvorgangs kann die JCL auf folgende Arten behandelt werden:
Vervollständigung oder Veränderung der Job-Karte(n) gemäß den Entire Operations-Standardeinstellungen.
Überprüfen aller gestarteten JCL von einem globalen Benutzer-Exit (muss in den Entire Operations-Standardeinstellungen definiert werden).
Einfügen von Header-Informationen als Kommentare in die gestartete JCL. Diese Möglichkeit wird immer durchgeführt. Die Header-Informationen können in der Job-SYSOUT angesehen werden.
Beispiel:
JobId JOB01 (45856) Typ SM Datei 2--------------------------- Columns 001 072
====> BLAETTERN===> CSR
***** ****************************** top of data *****************************
00001 1 //JOB01 JOB ,EXAMPLE,CLASS=G,
00002 // MSGCLASS=X,MSGLEVEL=(1,1)
00003 //* =====================================================
00004 //* S O F T W A R E A G
00005 //* Entire Operations Version 5.3.1
00006 //*
00007 //* Eigent: EXAMPLE Lauf: 3002
00008 //* Netzwerk: E60-FLOW Symboltabelle: EXAM-ST1
00009 //* Job: JOB-01 Escape Akt: § Start: $
00010 //* Start Ben.-Id: SN
00011 //* JCL-Knoten: 146 Ausf.Knoten: 146
00012 //*
00013 //* 07.01.10 13:33 erzeugt/geaendert . XSETAA1
00014 //* 14.04.10 21:00 aktiviert ......... SN
00015 //* 15.04.10 13:14 gestartet
00016 //* =====================================================
00017 //* Beim JCL-Laden ersetzte Symbole:
00018 //*
Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
Help End Quit Rfind Up Down Left Right Curso
|
Anmerkung:
Bei BS2000 wird die LOGON-Karte überprüft. Falls nicht anders bei
der Job-Definition spezifiziert, werden LOGON-Parameter, Account-Nummer,
Job-Klasse, überwachende Job-Variable (evtl. mit Passwort) von hier gezogen.
Job-Priorität, Laufnummer und
CPU-Zeit können ebenso mittels der LOGON-Card mitgegeben werden.
Einfügen von Informationen über alle ersetzten Symbole und ihre aktuellen Werte, falls Symbole ersetzt wurden.
Beispiel:
JobId JOB01 (45856) Typ JL Datei 1---------------------------- Columns 001 072
====> BLAETTERN===> CSR
00015 //* 15.04.10 13:14 gestartet
00016 //* =====================================================
00017 //* Beim JCL-Laden ersetzte Symbole:
00018 //*
00019 //* Symbol : CLASS
00020 //* Eigent. : EXAMPLE Symboltabelle: EXAM-ST1
00021 //* Geaend. : SN am 2009-04-14 um 15:21
00022 //* Wert : G
00023 //* Symbol : MSGCLASS
00024 //* Eigent. : EXAMPLE Symboltabelle: EXAM-ST1
00025 //* Geaend. : SN am 2009-11-21 um 13:48
00026 //* Wert : X
00027 //* Symbol : JOBLIB
00028 //* Eigent. : EXAMPLE Symboltabelle: EXAM-ST1
00029 //* Geaend. : SN am 2009-03-11 um 08:41
00030 //* Wert : NOP.EXAMPLE.LOAD
00031 //* =====================================================
00032 //*
00033 //* ENTIRE OPERATIONS EXAMPLE JOB ON 20100414
Enter-PF1---PF2---PF3---PF4---PF5---PF6---PF7---PF8---PF9---PF10--PF11--PF12---
Help End Quit Rfind Up Down Left Right Curso
|
Das Ersetzen von Symbolen in der JCL durch ihre aktuellen Werte zur Startzeit.
Nur bei z/OS:
Wenn ein Symbolersetzungsfehler zur Übertragungszeit auftritt, wird
ein JCL-Fehler erzwungen, um zu verhindern, dass der Job ausgeführt
wird.
Zeilen wie z.B. die folgende können einen JCL-Fehler hervorrufen:
// ###### Entire Operations Symbol Replacement Error
######
Der Job wird in einem Fehlerstatus wie dem folgenden bleiben:
JobId 51058 - Symbol Replacement Error
Der Job wird nicht fertig bearbeitet, weil dies wie ein Startfehler gehandhabt wird.
Siehe auch Arbeiten mit Entire System Server-Knoten im Abschnitt Betriebssystem-Benutzerkennungen.
Die Start-Benutzerkennung wird immer angezeigt.
Die Benutzerkennung für erstellt/geändert wird nur
geändert, wenn die Job-Definition oder die JCL geändert wurde. Eine Aktivierung
oder Reaktivierung gilt nicht als Änderung.
Die Trigraphen-Kodierung wird verwendet, um Fehler bei der ASCII/EBCDIC-Textkonvertierung zu vermeiden. Ein ASCII-Zeichen, für das es kein gleichbedeutendes EBCDIC-Zeichen gibt, wird dann durch eine Drei-Zeichen-Sequenz (Trigraph) ersetzt, und der Text kann dann erfolgreich kodiert werden.
Entire Operations verwendet Trigraphen bei der Generierung von JCL für UNIX und Windows. Standardmäßig wird die Trigraphen-Kodierung mit einem Fragezeichen (?) als Fluchtzeichen bei UNIX- und Windows-Entire System Server-Ausführungsknoten eingeschaltet
Für einige Zeichen des ASCI-Zeichensatzes (UNIX und Windows) gibt es keine oder aber mehrdeutige Entsprechungen im EBCDIC-Zeichensatz (Großrechner). Solche Zeichen können deshalb als Trigraphen dargestellt werden. Trigraphen beginnen stets mit zwei Trigraphen-Steuerzeichen (Escape-Sequenz).
Standardmäßig wird mit dem Fragezeichen (?) als Fluchtzeichen bei UNIX- und Windows-Entire System Server-Ausführungsknoten die Trigraphen-Kodierung eingeschaltet. Durch diese Korrektur ist es möglich, die Trigraph-Kodierung innerhalb der JCL ein- und auszuschalten.
Sie können mit dem folgenden Kommando die Trigraphen-Kodierung innerhalb der JCL ein- und ausschalten:
#EOR-TRIG=YES |
Schaltet die Trigraphen-Kodierung ein. |
#EOR-TRIG=NO |
Schaltet die Trigraphen-Kodierung aus. |
Das Kommando darf am Anfang einer Zeile oder in einer Kommentarzeile stehen.
... # #EOR-TRIG=NO ls example.??? # #EOR-TRIG=YES if ??( a == b ??) then ...
Entire System Server-Ausführungsknoten unter UNIX und Windows unterstützen die in der folgenden Tabelle aufgeführten Trigraphen. Ein Triagraph beginnt immer mit zwei Fluchtzeichen. In der folgenden Tabelle gilt für das Fragezeichen (?) als Trigraph-Standard-Fluchtzeichen.
| ASCII | Trigraph | Bemerkungen |
|---|---|---|
| [ | ??( | |
| \ | ??/ | |
| ] | ??) | |
| ^ | ?? ' | |
| { | ??< | |
| | | ??_ | |
| } | ??> | |
| ~ | ??- | |
| @ | ??% | |
| ` | ??; | |
| ! | ??: | |
| \f | ??+ | Druckvorschubsteuerzeichen (Form Feed) |
| \t | ??& | Tabulator (Tab) |
Die Ausführung als Dummy-Job bedeutet, dass der Job ohne Job Control und ohne eigene Aktion innerhalb Entire Operations abläuft. Dummy-Jobs können eine erwartete Laufzeit haben, die sie dann im System warten. Dummy-Jobs enden immer mit dem Zustand o.k.
Ausführliche Informationen siehe Dummy-Job benutzen.
Die Entire Operations-Protokoll-Funktion zeichnet jedes Ereignis und jede Benutzeraktion bei der Ausführung eines Job-Netzwerkes auf. Diese protokollierten Informationen ("Log") sind online verfügbar. Aus dem System-Log können Sie detailliertere Protokolle für einzelne Jobs auswählen, wenn eine Protokollierung auf der Job-Ebene zum Zeitpunkt der Job-Definition angegeben wurde.
Das Standard-System-Log zeigt Informationen über systemweite Aktivitäten wie z.B. Benutzeraktionen, Kalenderdatum und Uhrzeit von Ereignissen sowie Meldungen über Ereignisse. Sind mehr Informationen über ein Objekt im Systemlog verfügbar, dann wird dies mit einem vorangestellten Stern (*) gekennzeichnet.
Mögliche Protokoll-Informationen auf der Job-Ebene sind:
JCL-Protokoll
Zeigt die JCL eines bestimmten Job-Laufes an.
SYSOUT-Protokoll
Zeigt die SYSOUT-Datei eines bestimmten Job-Laufes an.
Systemmeldungsprotokoll
Zeigt alle Meldungen des Betriebssystems über Jobs an.
Das Systemmeldungsprotokoll zeigt die erste dieser Meldungen an. Sie können einen Job aus dem Systemprotokoll auswählen, um alle Systemmeldungen über ihn anzuzeigen.
Ein Auswahlfenster in der Protokoll-Funktion fordert Sie auf, das Standard-Protokoll nach Eigentümer, Netzwerk, Job und Laufnummer auszuwählen.
Weitere Informationen siehe Protokollierte Informationen.
Entire Operations kann Nachrichten an verschiedene Stellen schicken. Solche Benachrichtigungen werden durch systeminterne und benutzerdefinierte Ereignisse angestoßen.
Es können verschiedene Zielarten für Nachrichten definiert werden. Daneben gibt es das Senden von E-Mail auf Großrechnern und E-Mail auf UNIX- und Windows-Systemen.
Sie können die globalen Ereignisse auswählen, die das Versenden von Nachrichten bei Entire Operations anstoßen.
Wahlweise können Sie einen globalen Exit für Nachrichtenübermittlung benutzen. Dieser Exit kann alle Nachrichten "sehen", die aus verschiedenen Gründen vom Entire Operations-Monitor versendet werden. Der Exit kann den Nachrichten-Inhalt in Dateien speichern und zu anderen Anwendungen weiterleiten.
Entire Operations zeigt Status- und Fehlermeldungen an folgenden Stellen an:
| Ausgabestelle | Bedeutung |
|---|---|
| Auf dem aktuellen Bildschirm | Wenn mit Entire Operations online gearbeitet wird.
In vielen Fällen werden zusätzliche Informationen in das Entire Operations-Protokoll geschrieben. Nach komplexeren Fehlern empfiehlt es sich, dort nachzuschauen. Weitere Informationen zum Entire Operations-Protokoll siehe Protokollierte Informationen ("Log"). |
| Liste der aktiven Jobs | Die Spalte Nachricht enthält die letzte
Status- oder Fehlermeldung für den aktiven Job.
Weitere Informationen siehe Alle aktiven Jobs auflisten |
| Entire Operations-Protokoll | Diese protokollierten Informationen ("Log") enthalten alle
Status- und Fehlermeldungen.
Wenn wegen Datenbank-Problemen nicht mehr in die Protokoll-Datei geschrieben werden kann, dann werden die Meldungen in das SYSOUT der Monitor-Tasks geschrieben. Weitere Informationen siehe Protokollierte Informationen ("Log"). |
| SYSOUT der Monitor-Tasks | Enthält vorwiegend Start- und Ende-Meldungen der Monitor-Tasks.
In diesem Fall werden auch sonstige, wichtige Ereignisse hier zusätzlich protokolliert. |
| Konsole | Auf Großrechnern werden gravierende Meldungen der Monitor-Tasks
auf die System-Konsole geschrieben.
In den meisten Fällen sind diese vom Operator zu beantworten. Ein Beispiel ist die Nichtverfügbarkeit der Datenbank, während der Entire Operations-Monitor läuft. |
In Entire Operations stehen Systemmeldungen in den Sprachen Englisch und Deutsch an folgenden Stellen zur Verfügung:
| Ausgabestelle | Bedeutung |
|---|---|
| Auf dem aktuellen Bildschirm | Standardmäßig die Sprache, die im Benutzer-Profil definiert ist; siehe Entire Operations-Standardwerte in der Systemverwaltung-Dokumentation. |
| Liste der aktiven Jobs | Die Spalte Nachricht enthält die Sprache, die im Benutzer-Profil definiert ist; siehe Entire Operations-Standardwerte in der Systemverwaltung-Dokumentation. |
| Entire Operations-Protokoll ("Log") | Die Sprache, die im Benutzer-Profil definiert ist; siehe
Entire
Operations-Standardwerte in der
Systemverwaltung-Dokumentation.
Protokoll-Meldungen werden sprachneutral gespeichert. Jeder Benutzer kann sie sich in seiner eigenen Sprache anzeigen lassen. Siehe Protokollierte Informationen ("Log"). |
| SYSOUT der Monitor-Task(s) | Abhängig von der Sprache der Natural-Umgebung des Entire
Operations-Monitors.
Diese kann z. B. mit dem Natural-Profilparameter
|
| Konsole | Abhängig von der Sprache der Natural-Umgebung des Entire
Operations-Monitors.
Diese kann z. B. mit dem Natural-Profilparameter
|
Anmerkung:
Der Benutzer kann die aktuelle Sprache der Benutzungsoberfläche in
seiner Sitzung jederzeit mit dem Direktkommando
SET
LANGUAGE ändern.
Eine Liste der Systemmeldungen, die in Entire Operations ausgegeben werden können, ist im Dokument Meldungen enthalten.
Außerdem können Sie sich den Langtext einer Meldung online anzeigen
lassen, indem Sie das Direktkommando HELP
MSG msg-id benutzen. Siehe
Direktkommando HELP.
In Entire Operations stehen die Sprachen Deutsch und Englisch an folgenden Stellen der Benutzungsoberfläche zur Verfügung:
Alle Anwendungsbildschirme und -fenster, einschließlich der Status- und Fehlertext-Meldungen.
Alle Online-Hilfe-Texte, einschließlich der feldspezifischen Informationen.
In der Entire Operations-Protokolldatei.
Anmerkung:
Die Speicherung der Entire Operations-Protokoll-Meldungen erfolgt
sprachunabhängig. Der Benutzer kann sie sich in Deutsch oder Englisch anzeigen
lassen.
Dieser Abschnitt beschreibt die Stellen, an denen Sie abhängig von Ihren Berechtigungen die Benutzer-Sprache ändern können:
Geben Sie eines der folgenden Entire Operations-Direktkommandos ein, und drücken Sie Enter:
SET LANGUAGE 2
(für Deutsch)
SET LANGUAGE 1
(für Englisch)
Siehe auch Direktkommando
SET.
Die Spracheinstellung wird für die Dauer der Entire Operations-Sitzung beibehalten.
Als Administrator können Sie die Sprache an folgenden Stellen angegeben:
Im Bildschirm Standardeinstellungen (1) der Entire Operations Standardwerte.
Im Benutzerprofil auf dem Bildschirm Benutzer-Definition und Profil.
Siehe entsprechende Abschnitte in der Systemverwaltung-Dokumentation.
Der Natural-Profilparameter ULANG steuert die
Sprache, die vom Entire Operations-Monitor benutzt wird, z.B. bei den Monitor
Tasks und der Ausgabe auf der Konsole.
Sie können den Natural-Profilparameter ULANG
dynamisch beim Start der Natural-Session angeben oder, wenn Sie dazu berechtigt
sind, statisch im
Natural-Parameter-Modul/Datei.
Weitere Informationen zu ULANG siehe
Parameter-Referenz in der Natural-Dokumentation.
Die Entire Operations-Berichtsfunktionen ermöglichen Ihnen einen Überblick über Ihre Job-Netzwerkumgebung und helfen Ihnen bei der Definition von Objekten, der Überwachung des Systems und der Planung der Arbeitsbelastung.
Eine Beschreibung der Bericht-Typen finden Sie im Abschnitt Berichte.
Die Cross-Referenzen-Funktion dient zum Generieren von Reports, die Cross-Referenzen zu einzelnen Objekten in Entire Operations liefern.
Informationen zu den Cross-Referenzen-Typen finden Sie im Abschnitt Cross-Referenzen.
Entire Operations stellt eine Variante des Software AG Editor zur Verfügung, die an die Entire Operations-Umgebung speziell angepasst ist.
Bevor der Editor eine bearbeitete Datei zurückschreibt, legt er eine Sicherheitskopie dieser Datei an.
Sie können mit dem Editor folgende Funktionen ausführen:
JCL für Jobs erzeugen oder bearbeiten. Existierende JCL kann auch dann editiert werden, wenn sie außerhalb von Entire Operations mit anderen Editoren geschrieben wurde. Siehe JCL oder Natural-Programme editieren im Abschnitt Job-Verwaltung.
JCL für Jobs des Typs MAC (Macro) erstellen oder
editieren.
Natural-Programme schreiben, die als Jobs in Job-Netzwerken laufen oder als User Exits ausgeführt werden sollen.
Beschreibungen auf der Netzwerk-, Job- und Ereignisebene (Online-Dokumentation) schreiben und ansehen.
JCL, Job-SYSOUT und Listen ansehen (editieren nicht möglich).
Das Entire Operations-Protokoll ("System-Log") ansehen.
Der Software AG Editor und die Editor-Kommandos sind in der Editoren-Dokumentation von Natural für Großrechner ausführlich beschrieben.
Dieser Abschnitt behandelt folgende Themen:
Die operativen Daten von Entire Operations müssen nach gewissen Zeiten wieder aus der aktiven Datenbank entfernt werden. Dazu gehört auch die Entfernung von Arbeitsdateien, die Entire Operations für JCL-Zwecke im Dateisystem angelegt hat.
Die Aufbewahrungszeiträume für aktive Objekte können definiert werden; siehe Entire Operations-Standardwerte in der Systemverwaltung-Dokumentation.
Es kann definiert werden, dass die Bereinigung automatisch täglich durchgeführt wird. Falls keine Zeit für die Bereinigung definiert wird, so wird sie um 00:00 gestartet. Man kann eine Zeit für den täglichen Start der Bereinigung definieren. Eine genauere Beschreibung finden Sie in der Systemverwaltung-Dokumentation.
Die Bereinigung der aktiven Datenbank kann auch jederzeit manuell gestartet werden; siehe Bereinigung der aktiven Datenbank in der Systemverwaltung-Dokumentation.
Es besteht zudem die Möglichkeit, die Bereinigung der aktiven Datenbank in einem Natural-Batch-Job außerhalb des Entire Operations-Monitors auszuführen. Siehe Bereinigung der aktiven Datenbank im Batch-Betrieb. Die Bereinigung im Batch-Betrieb kann bei laufendem Monitor oder bei heruntergefahrenem Monitor erfolgen.
Bitte beachten Sie, dass die Bereinigung der aktiven Datenbank abhängig von der zu behandelnden Datenmenge das System belastet. Es empfiehlt sich, die Bereinigung in "ruhige" Zeiten zu legen.
Bereinigungsläufe können auch mehrmals täglich stattfinden. Dadurch kann man das pro Lauf zu behandelnde Volumen reduzieren.
Unter BS2000, UNIX und Windows legt Entire Operations Dateien im Betriebssystem an. Sie enthalten u.a. den Job-SYSOUT oder die auszuführende JCL.
Bei der Deaktivierung aktiver Jobs, die in einem dieser Betriebssysteme gelaufen sind, werden auch die zugewiesenen Arbeitsdateien gelöscht.
Für BS2000 können die Namen dieser Arbeitsdateien auch mit einem Namens-Exit generiert worden sein. Dieser wird auch für das Löschen der Arbeitsdateien verwendet.
Alle Definitionen werden in den Entire Operations-Standardeinstellungen vorgenommen. Siehe umgebungsspezifische Unterabschnitte im Abschnitt Entire Operations-Standardwerte in der Systemverwaltung-Dokumentation.
