OS/390 JOBS

OS/390-Jobs enthalten die erforderlichen Parameter, um Verarbeitungsschritte auf OS/390-Zielsystemen auszuführen, diese Schritte zu überwachen und zu definieren, wie Laufzeitoptionen und Reports verarbeitet werden müssen. Ihr Automation Engine-System ist über den Agenten mit dem Zielsystem verbunden. Der Agent interpretiert die Befehle so, dass das Zielsystem sie versteht.

Voraussetzungen

  • Der Agent ist aktiv
  • Der Agent wird dem Job auf der Seite Attribute zugewiesen.
  • Für den Job ist ein Login-Objekt (LOGIN) zugewiesen, das die Anmeldeinformationen für die Anmeldung beim Zielsystem enthält.

Weitere Informationen zur Integration von Automation Engine und OS/390-Systemen finden Sie unter AE und z/OS.

Diese Seite beinhaltet Folgendes:

OS/390-Jobs definieren

Eine OS/390-Auftragsdefinition besteht aus den folgenden Seiten:

Einen OS/390-Job definieren

  1. Ein Objekt des Typs Job > OS/390 hinzufügen. Das neue Objekt wird auf der Seite OS/390 geöffnet.

  2. Im Abschnitt Parameter definieren Sie die Konfiguration des Jobs, je nach Typ:

    • Typ: Automation Engine (AE)

      Dieser Typ bedeutet, dass die Job-Logik vollständig in Automic Automation definiert ist, d. h. Sie schreiben die Job-JCL direkt auf der Seite Prozess des Jobs.

      • Jobname

        Datensatz, der die JCL enthält. Die Jobkarte wird aus den hier definierten Host-Attributen generiert. Die Pre-Prozess-JCL wird vor dem ersten Schritt hinzugefügt. Das Script muss leer sein.

        Die Jobkarte, die in diesem Jobobjekt definiert ist, wird eingefügt, unabhängig davon, ob JCL eine Jobkarte enthält, oder nicht.

      • Programmierer-Name

        Name des Programmierers. Er identifiziert den Job-Verantwortlichen oder seine Job-Gruppe (optional). Der Name wird in der Jobkarte eingetragen.

        Maximale Länge: 20 Zeichen

      • Job-Klasse

        Queue, in der der Job laufen soll

      • Kostenstelle

        Kontonummer oder Buchhaltungsinformationen, die vom OS390-System benötigt werden

        Maximale Länge: 40 Zeichen

      • Priorität

        Priorität, mit der dieser Job ausgeführt werden soll

        Zulässige Werte: 1 bis 15, wobei 1 die höchste und 15 die niedrigste Priorität ist.

      • MSGCLASS

        Dem Job zugewiesene Meldungsklasse.

      • MSGLEVEL

        Trace-Option für das Job-Log. Numerischer Wert für Anweisung und Meldung, durch ein Komma getrennt.

        Zulässige Formate: "Befehl, Meldung", ", Meldung" oder "Befehl"

        Erlaubte Werte für Ausgabe von Anweisungen:

        • "0" - Nur Ausgabe der Anweisungen
        • "1" - Alle Anweisungen des Jobs, der JES2- oder JES3-Kontrollanweisungen, der Prozeduranweisungen und alle IEF653I-Meldungen
        • "2" - Nur alle Job-Anweisungen (JCL) und die JES2- oder JES3-Kontrollanweisungen

        Erlaubte Werte für Ausgabe von Meldungen:

        • "0" - Nur Meldungen der JCL. Bei Abbrüchen auch die JES-Kontrollanweisungen und Operator-Meldungen. Bei Fehlern durch SMS auch die entsprechenden Meldungen.
        • "1" - Alle JCL-, JES-, Operator- und SMS-Meldungen.

      • Benachrichtigen

        Benachrichtigung, die vom OS/390-System gesendet werden soll, wenn die Job-Verarbeitung abgeschlossen ist

        Maximale Länge: 17 Zeichen.

      • Scheduling-Umgebung

        Name der Workload Manager (WLM)-Scheduling-Umgebung, die diesem Job zugeordnet werden soll. Eine Scheduling-Umgebung ist eine Liste mit Ressourcen und deren benötigten Einstellungen. Wenn Sie einem Job einen Scheduling-Umgebungsnamen zuordnen, stellen Sie sicher, dass die Ausführung eines Jobs nur auf einem System geplant wird, das dessen Anforderungen an den Ressourcenstatus erfüllt.

      • Job-Parameter

        Platzhalter für alle unterstützten zusätzlichen Job-Karten-Parameter

      • Rückgabewert

        Diese Einstellung ist relevant, wenn das Jobende über SMF-Records überwacht wird. In diesem Fall werden die Rückgabewerte der Job-STEPS gesammelt.

        • Höchster

          Der höchste Rückgabewert wird verwendet, wenn der Job endet

        • Letzter

          Es wird nur der zuletzt eingetretene Rückgabewert berücksichtigt

        Der Administrator kann angeben, ob SMF-Datensätze für die Überwachung verwendet werden sollen, wann Jobs enden. Dazu werden SMFJob= in der INI-Datei des Ereignis-Monitors und die Variable UC_EX_JOB_MD=UC4START in der INI-Datei des Agenten verwendet.

    • Typ: OS/390 JCL

      Wählen Sie diese Option aus, wenn die Job-JCL vom OS/390-System übernommen wird und nicht in der Automation Engine definiert ist. Bei diesem Typ wird jedoch die Job-Karte von der Automation Engine generiert.

      Wenn Sie diese Option auswählen, wird ein zusätzliches Eingabefeld für den OS/390-Dateinamen angezeigt. Hier geben Sie den Namen des Datensatzes oder Members ein, der die Job-JCL enthält.

      Beispiel: SYSS.AWA.JCL.JOB1 oder SYSS.AWA.JCLLIB(UC4JOB1)

      Jobs können auch aus dem Source-Verwaltungssystem Librarian stammen.

      Syntax: *LIBRARIAN(Dataset, Member).

      Maximale Länge: 225 Zeichen

      Zulässiges Format: Dataset-Name und Membername müssen in einfachen Anführungszeichen stehen Andernfalls stellt der Agent den Namen des Benutzers, unter dem er läuft, in den Vordergrund.

      Beispiel:

      In IBMUSER.SYSS.AWA.JCL.JOB1 ignoriert der Agent die erste Zeile in der Datei, wenn der Typ "z/OS JCL" ausgewählt ist, da er annimmt, dass sie die Jobkarte enthält.

    • Typ: JCL inkl. OS/390-Jobkarte

      Wählen Sie diese Option aus, wenn sowohl die Job-JCL als auch die Jobkarte auf dem OS/390-System definiert sind und nicht in der Automation Engine. Die Laufzeit-Optionen sind nicht verfügbar, da die Definitionen der Jobkarte gelten.

      Sie können ein Script zur Vorverarbeitung auf der Pre-ProzessSeite des Jobs schreiben. Beim Erstellen eines Jobs wird die JCL von der Seite Pre-Prozess vor dem ersten Schritt des Jobs hinzugefügt.

      Wenn Sie diese Option auswählen, werden die Felder OS/390-Dateiname und Rückgabewert angezeigt.

      Geben Sie unter OS/390-Dateiname den Namen des Datensatzes ein, der die Job-JCL und die Job-Karte enthält.

  3. Konfigurieren Sie im Bereich Job-Report Folgendes:

    Speicherort des Reports

    Sie haben dafür zwei Möglichkeiten. Sie können eine Option oder beide gleichzeitig auswählen:

    • Speichere in: Datenbank bedeutet, dass nach der Ausführung des Jobs das auf dem Zielsystem (auf dem Agenten) verfügbare Prozesslog in der Datenbank gespeichert wird.

      Wenn ein Auftrag auf einem Agenten ausgeführt wurde, wird der entsprechende Report auf dem Agentencomputer gespeichert. Nachdem diese Daten durch die Automation Engine in die Datenbank geschrieben wurden, wird der Report automatisch vom Agentencomputer gelöscht. Wenn dieser Job-Report aufgrund eines Fehlers nicht gelöscht werden kann, wird der Löschvorgang nicht wiederholt und eine Fehlermeldung ausgegeben.

    • Speichere in: Datei bedeutet, dass das Prozesslog als Datei in einem Zielsystem (Agent) gespeichert wird.

    Wann soll der Report erstellt werden?

    Sie haben dafür zwei Möglichkeiten:

    • Generiere: Immer bedeutet, dass das Prozesslog des Betriebssystems immer geschrieben wird.

    • Generieren: Nur im Fehlerfall bedeutet, dass das Prozesslog nur dann geschrieben wird, wenn ein Fehler auftritt. Zum Beispiel, wenn der Job abgebrochen wird.

    OS/390-spezifische Optionen

    • Job-Log-Umfang

      Hier geben Sie den Inhalt des Logs an:

      • Agent-Voreinstellung

        Die Komplexität des Job-Logs ist abhängig von der Konfiguration in der INI-Datei des Agenten (Parameter completeJobout=)

      • JES-Statistik und Jobausgabe speichern

        Die JES-Statistik und die Jobausgabe werden im Job-Log gespeichert

      • Nur JES-Statistik speichern

        JESMSGLG, JESJCL und JESYSMSG werden aufgenommen

    • Job-Log löschen

      • Agent-Voreinstellung

        Ob das Job-Log gelöscht wird, ist abhängig von der Konfiguration in der INI-Datei des Agenten (Parameter im (jobPurge=)

      • Nach Lesen löschen

        Das Job-Log wird gelöscht, nachdem es vom Agenten gelesen wurde.

      • Nicht löschen

        Das Job-Log bleibt im JES-Spool

    • Druckfreigabe

      • Agent-Voreinstellung

        Ob das Job-Log gelöscht wird, hängt von der Konfiguration in der INI-Datei des Agenten ab (Parameter relMsgClass=).

      • Nach Lesen freigeben

        Das Job-Log wird, nachdem es vom Agenten gelesen worden ist, gelöscht

      • Nicht freigeben

        Das Job-Log bleibt im JES-Spool

    • Meldungsklassen lesen

      Meldungsklassen, die eingelesen und dann umgeleitet werden sollen. Geben Sie eine oder mehrere Meldungsklassen an. Beispiele: "A", "ABC", "X1".

      Die Reihenfolge spielt hierbei keine Rolle. Außerdem sind noch folgende Werte erlaubt: *DEFAULT und *ALL.

      • DEFAULT

        Die Meldungsklassen, die eingelesen werden sollen, hängen von der Konfiguration in der INI-Datei des Agenten ab (Parameter getMsgClass=).

        Wenn Sie diese Einstellung verwenden, muss auch *DEFAULT im Feld Zu Meldungsklassen umleiten spezifiziert werden.

      • ALL

        Alle Klassen werden eingelesen.

    • Zu Meldungsklassen umleiten

      Meldungsklassen, in die umgeleitet werden soll.

      Nach der Übertragung in der Automation Engine kann das Job-Log zusätzlich in die angegebenen Meldungsklassen (beispielsweise für ein Output Management System) umgeleitet werden.

      Geben Sie entweder eine Meldungsklasse an, oder so viele Meldungsklassen, wie Sie im Feld Meldungsklassen lesen angegeben haben. Die Reihenfolge ist dabei relevant.

      Beispiele:

      • Die Meldungsklassen "ABC" werden eingelesen und nach "DEF" umgeleitet. Die Klasse "A" wird zur Klasse "D" umgeleitet, "B" zu "E" und "C" zu "F".

      • Die Meldungsklassen "ABC" werden gelesen: und umgeleitet nach "D". Die Klassen "A", "B" und "C" werden nach "D" umgeleitet.

        Anstelle von konkreten Meldungsklassen sind auch folgende Werte erlaubt:

        • DEFAULT

          Die Meldungsklassen, die eingelesen werden sollen, hängen von der Konfiguration in der INI-Datei des Agenten ab (Parameter routeMsgClass=).

          Diese Einstellung muss eingetragen sein, wenn *DEFAULT ebenfalls im Feld Meldungsklassen lesen eingetragen wurde

        • NO

          Es erfolgt keine Umleitung

  4. Wechseln Sie auf die Seite Attribute, und konfigurieren Sie Folgendes:

    • Wählen Sie den OS/390-Agenten aus.
    • Wählen Sie das Login-Objekt aus, das die Anmeldeinformationen enthält, die der Agent für den Zugriff auf das z/OS-System benötigt.

  5. Wechseln Sie auf die Seite Allgemein > Laufzeit.

    Wählen Sie im Bereich Rückgabewert-Verarbeitung die Option Abschlusscode aus, um OS/390-spezifische Optionen anzuzeigen. Hier können Sie jedem Schritt im Job einen Rückgabewert und einen Status zuweisen.

    1. Geben Sie den Stepnamen und den Rückgabewert ein und wählen Sie den Status.
    2. Klicken Sie auf Hinzufügen, um den Fertigstellungscode hinzuzufügen, und wiederholen Sie dies für alle Schritte im Job.

  6. Speichern Sie das Objekt.

Ausführen, auf den Report zugreifen und überwachen

Nachdem Sie den Job konfiguriert haben, können Sie ihn ausführen, um zu überprüfen, ob er sich wie erwartet verhält. Klicken Sie auf die Schaltfläche Ausführen in der Symbolleiste. Sobald der Job ausgeführt wurde, finden Sie Informationen zu seiner Ausführung in den folgenden Bereichen der Benutzeroberfläche:

Job-Report

Automic Automation bietet verschiedene Reporttypen mit umfassenden Informationen zur Ausführung von Objekten. Bei OS/390-Jobs ist der wichtigste Report SREP. Dieser Report zeichnet jeden Schritt auf, den der Job durchlaufen hat.

Gehen Sie wie folgt vor, um den SREP-Report zu öffnen:

  1. Klicken Sie auf Report öffnen, um die Report-Ansicht zu öffnen.
  2. Wählen Sie in der Dropdown-Liste in der oberen linken Ecke des Reportfensters die Option SREP.

Weitere Informationen finden Sie unter Mit der Reports-Ansicht arbeiten.

Aufgabenliste

Jede Zeile in der Aufgabenliste in der Process Monitoring-Perspektive entspricht der Ausführung eines Objekts. Normalerweise werden nur aktive Aufgaben in dieser Liste angezeigt, es sei denn, Sie haben sie anders konfiguriert.

Weitere Informationen finden Sie unter Die Aufgabenliste.

Ausführungsliste

Jede Ausführung des Jobs wird aufgezeichnet und gespeichert. Sie können auf die Jobausführungsliste zugreifen, um zu überprüfen, was bei jeder einzelnen Ausführung passiert ist.

Weitere Informationen finden Sie unter Ausführungsdaten.

Job-Monitor

Sobald der Job gestartet wurde, wird sein Monitor in der Process Monitoring-Perspektive angezeigt. Er enthält die Konfigurationsdetails, mit denen der Job ausgeführt wurde. Außerdem wird die JCL angezeigt.

Weitere Informationen finden Sie unter Jobs überwachen.

Job- und Aufgabendetails

Über die Schaltfläche Details können Sie auch auf die Konfigurationsdetails zum Job-Objekt und dessen Ausführungen (Aufgaben) zugreifen.

Weitere Informationen finden Sie unter Objekt- und Aufgabendetails anzeigen.

Integration von WLM (Workload Management)

Der OS/390-Agent kann integrierte Prüfungen durchführen, bevor er Jobs an das JES weitersendet. Falls definiert, werden diese Prüfungen immer durchgeführt, auch dann, wenn der Job nicht auf OS/390 ausgeführt würde. Wenn ein Job aufgrund einer dieser Prüfungen blockiert wird, lautet der Status 1683, Wartet auf Remote-Ressource. In der Spalte Remote-Status in der Aufgabenliste (Process Monitoring-Perspektive) wird eine Meldung angezeigt, die die Ursache erklärt. Zusätzlich wird der Blockiergrund im Job-Report (SREP) protokolliert.

Die folgenden Prüfungen sind verfügbar; Ihr Systemadministrator kann sie in der INI-Datei des Agenten aktivieren:

  • Prüfung auf Job-Duplikate

    Vor dem Absenden eines Jobs an das JES prüft der Agent, ob bereits ein Job mit gleichem Namen ausgeführt wird. Ist dies der Fall, wird der Job nicht abgesendet.

    Dieses Duplikat ist zum Beispiel nützlich, wenn Sie mehrere OS/390-Jobs starten möchten, die den gleichen OS/390-Namen haben, jedoch im Automation Engine unterschiedlich benannt sind. Diese Jobs können in der Automation Engine gestartet werden, würden jedoch eine Queue in OS/390 verursachen. Mit dieser Prüfung wird solche Situationen vermieden.

    Diese Prüfung berücksichtigt alle Jobs in einem Agenten.

  • Scheduling Environment-Prüfung

    Dese Überprüfung verhindert, dass ein Job an das JES übergeben wird, wenn die Scheduling-Umgebung in keinem der Systeme verfügbar ist, an die er möglicherweise übergeben wird.

  • Initiator-Prüfung

    Diese Überprüfung verhindert, dass der OS/390-Agent zusätzliche Jobs startet, wenn alle OS/390-Initiatoren ausgelastet sind. Das WLM in OS/390 kann die Anzahl der verfügbaren Initiatoren anpassen. Der Agent muss ihre Anzahl überprüfen, um die maximale Anzahl der Jobs zu bestimmen, die zu einem bestimmten Zeitpunkt gestartet werden können.

Vorteile dieser Prüfungen:

  • Jobs, die nicht ausgeführt werden können, blockieren die Kapazität der JES-Queue nicht
  • Blockierte Aufträge werden als solche in der Aufgabenliste markiert, die auch Informationen über den Grund für die Blockierung enthält.
  • Jobs mit dem Status 1683: Wartet auf eine Remote-Ressource beanspruchen keine abstrakten Ressourcen (WORKLOAD_MAX_JOB) innerhalb der Automation Engine
  • Die Laufzeitberechnung für vorübergehend blockierte Jobs ist präziser, da Wartezeit nicht als Laufzeit berücksichtigt wird

Wichtig! Diese Überprüfungen stellen nicht sicher, dass jeder Job, der an das JES übergeben wird, sofort ausgeführt wird. Dies sind die Gründe dafür:

  • Die Art der Prüfungen

    • Wenn die Initiator-Prüfung nur auf SYSPLEX-Ebene ausgeführt wird, können Jobs auch dann übergeben werden, wenn kein System freie Ressourcen hat
    • Die Prüfung auf Job-Duplikate berücksichtigt keine Jobs, die von anderen Agenten, Prozessen oder Benutzern übergeben wurden

  • Timerprobleme

    Eine Ressource kann nach der kurzen Zeitspanne zwischen der Ressourcenprüfung und der Übergabe des Jobs nicht mehr verfügbar sein.

  • Job-Routing

    Die Ressourcen-Prüfungen berücksichtigen nicht, ob Jobs nach deren Übermittlung zu bestimmten Systemen umgeleitet werden (aufgrund von SYSTEM-/SYSAFF-Parametern).

    Beispiel: Der Agent stellt fest, dass die erforderliche Scheduling-Umgebung auf System A verfügbar ist. Der Agent übergibt den Job. Aufgrund des SYSAFF-Parameters wird der Job jedoch an System B weitergeleitet, wo die Scheduling-Umgebung nicht verfügbar ist.

Die Standard-Job-Klasse wird vom Agenten nur einmal beim Start abgefragt, entweder vom JES oder vom Parameter "defaultJobclass" in der INI-Datei. Wird die Standard-Job-Klasse geändert, während der Agent läuft, werden die Scheduling-Umgebung und die Initiator-Prüfungen für Jobs ohne spezifizierte Job-Klasse nicht ordnungsgemäß funktionieren. In einem solchen Fall muss der Agent neu gestartet werden, damit die Prüfungen erneut korrekt ausgeführt werden.

Siehe auch: