OS390-Jobs
OS390-JobsDieser Subtyp des JOBS-Objektes definiert die z/OS390-spezifischen Verarbeitungsschritte, die auf einem Zielsystem ausgeführt werden sollen. Wie alle Jobobjekte (JOBS), können z/OS390-Jobs eigenständig laufen oder zu einer GruppeFasst Aufgaben zusammen, um diese gemeinsam durchzuführen. Auch ein eigener Objekttyp in der Automation Engine. (JOBG) oder einem Workflow"Ermöglicht das Hinzufügen, Anordnen, Verknüpfen, Definition von Eigenschaften und Entfernen von Aufgaben eines Workflows. Ein eigener Objekttyp in der Automation Engine. [Früher ""AblaufPlan"" und ""JobPlan"" gennant.]" hinzugefügt werden.
Die 
Seite enthält plattformspezifische Ausführungsparameter:
Validierungsprüfungen
Der zOS/390-Agent"Programm, das die Ausführung von Verarbeitungen auf Zielsystemen wie z.B. Rechner oder Geschäftslösungen ermöglicht. Auch ein eigener Objekttyp in der Automation Engine. [Früher ""Executor"" genannt.] Siehe auch ""Host""." verfügt über verschiedene integrierte Prüfungen, die ausgeführt werden, bevor Jobs an das JES übergeben werden, falls sie nicht unbedingt laufen sollen. Falls ein JobVerarbeitung auf einem Zielsystem. Auch ein eigener Objekttyp in der Automation Engine. aufgrund einer dieser Prüfungen blockiert ist, wird der StatusZustand einer Aufgabe (z.B. aktiv, blockiert, in Generierung, usw.). 1683 angenommen: Wartet auf Remote-Ressource. In der Spalte Remote-Status im Fenster Aufgaben erscheint eine Mitteilung mit Erklärungen. Zusätzlich wird der Blockiergrund im Jobreport (LOG) protokolliert.
Ob ein Agent die Prüfungen ausführen soll oder nicht, wird in der INI-Datei des Agenten festgelegt.
Prüfung auf Job-Duplikate
Vor dem Absenden eines Jobs an den JES prüft der Agent, ob bereits ein Job mit gleichem Namen ausgeführt wird. Ist dies der Fall, wird der Job nicht abgesendet.
Dies ist zum Beispiel nützlich, wenn Sie mehrere z/OS-Jobs starten möchten, die den gleichen z/OS-Namen haben, jedoch in der Automic Web Interface unterschiedlich benannt sind. Diese Jobs können in der Automic Web Interface gestartet werden, würden jedoch in z/OS eine QueueObjekttyp in der Automation Engine. Legt die maximale Anzahl parallel laufender Aufgaben, deren Prioritäten und somit die Reihenfolge von auszuführenden Objekten fest. verursachen. Mit dieser Prüfung wird solche Situationen vermieden.
Diese Prüfung berücksichtigt alle Jobs im gleichen Agenten. Es werden keine Jobs berücksichtigt, die von anderen Agenten übergeben werden.
Scheduling Environment-Prüfung
Nehmen wir an, Sie möchten verhindern, dass ein Job an den JES übergeben wird, wenn das im Job definierte Scheduling Environment in keinem der Systeme verfügbar ist, an die er übergeben werden kann.
Initiator-Prüfung
Nehmen wir an, Sie möchten verhindern, dass der z/OS-Agent weitere Agenten startet, wenn alle z/OS-Initiatoren ausgelastet sind. Da der WLM in z/OS die Anzahl der verfügbaren Initiatoren anpassen kann, muss der Agent deren Anzahl prüfen, um die maximale Anzahl an Jobs zu ermitteln, die zu einem bestimmten Zeitpunkt gestartet werden können.
Diese Prüfungen bieten mehrere Vorteile:
Diese Prüfungen garantieren nicht, dass der Job, der an JES übergeben und somit Aktiv ist, sofort ausgeführt wird. Dies hat folgende Gründe:
Es kann vorkommen, dass eine Ressourcen innerhalb der kurzen ZeitspanneEine Zeitspanne ist im Service Orchestrator ein Zeitraum, der verwendet wird, um SLA-Leistungsergebnisse in Berichtsdiagrammen aufzuschlüsseln und zu gruppieren. Wenn Sie zum Beispiel die SLA-Ergebnisse des letzten Jahres durchsehen, können Sie die Ergebnisse nach der Zeitspanne „Quartal“ aufschlüsseln, so dass jeder Balken die Ergebnisse pro Quartal darstellt. Dies ist nicht das Gleiche wie eine Zeitperiode, welche den gesamten Zeitraum umfasst, der den Berichten zugrunde liegt. zwischen der Ressourcen-Prüfung und der Übergabe des Jobs nicht mehr verfügbar ist.
Die Ressourcen-Prüfungen berücksichtigen nicht, ob Jobs nach deren Übermittlung zu bestimmten Systemen umgeleitet werden (aufgrund von SYSTEM-/SYSAFF-Parametern). So kann der Agent beispielsweise ermitteln, dass das benötigte Scheduling Environment auf System A verfügbar ist, und den Job übergeben. Aufgrund der SYSAFF-Parameter wird der Job jedoch an System B umgeleitet, in dem das Scheduling Environment nicht verfügbar ist.
Andererseits wird die Standard-Jobklasse nur einmal vom Agenten beim Startup abgefragt; entweder vom JES oder vom „defaultJobclass“-Parameter in der INI-Datei. Das bedeutet: Wird die Standard-Jobklasse geändert, während der Agent läuft, werden das Scheduling Environment 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.
Abschnitt „Parameter“
| Feld | Beschreibung |
|---|---|
| Typ |
|
| Jobname |
Das Datenset, das hier die JCL enthält. Die Jobkarte wird aus den hier definierten HostRechner, Zielsystem.-Attributen generiert. Die JCL aus dem Pre-Script 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. |
|
Programmname
|
Programmer's name - Identifiziert den Eigentümer oder die Gruppe des Jobs (optional). Der Name wird in der Jobkarte des Jobs eingetragen. Er kann bis zu 20 Zeichen lang sein. |
| Jobklasse | Angabe der Jobklasse, in der dieser Job laufen soll (optional). |
| Kostenstelle | Accounting-Information des Jobs. Er kann bis zu 40 Zeichen lang sein. |
| Priorität |
Angabe der Priorität, mit der dieser Job ausgeführt werden soll. Der Wert kann zwischen 1 und 15 liegen, wobei 1 die höchste und 15 die niedrigste Priorität ist. Die Priorität bestimmt lediglich die Startreihenfolge und hat keinen Einfluss auf die Verarbeitung von Aufgaben. Die AufgabeEin gestartetes Objekt, welches gerade durchgeführt wird. Aufgaben werden auch als Aktivitäten bzw. Tasks bezeichnet. mit der höchsten Priorität wird zuerst gestartet. Bei Aufgaben mit gleicher Priorität kommt das Prinizip „first in/first out“ (FIFO) zur Anwendung. |
| MSGCLASS | Zuordnung des Joblogs zu einer Ausgabeklasse (optional). |
| MSGLEVEL |
Ausgabeoption (Traceoption) für den ReportBericht, der nähere Informationen über die Durchführung einer Aufgabe oder einer Komponente enthält. (optional). Möglich ist ein numerischer Wert für Anweisung und Meldung durch Komma getrennt. Erlaubte Formate: „Anweisung,Meldung“, „Meldung“ oder „Anweisung“ Erlaubte Werte für Ausgabe von Anweisungen:
Erlaubte Werte für Ausgabe von Meldungen:
|
| Benachrichtigen | Angabe einer BenachrichtigungSendet Mitteilungen an einzelne Benutzer und BenutzerGruppen des Automation Engine-Systems. Auch ein eigener Objekttyp in der Automation Engine. [Früher "CallOperator" genannt.] auf z/OS. Kann bis zu 17 Zeichen lang sein. |
| Scheduling Environment | Der Name des Workload Manager (WLM)-Scheduling Environment, der diesem Job zugeordnet werden soll. Ein Scheduling Environment ist eine Liste mit Ressourcen und deren benötigten Einstellungen. Wenn Sie einem Job einen Scheduling Environment-Namen zuordnen, stellen Sie sicher, dass die Ausführung eines Jobs nur auf einem System geplant wird, das dessen Anforderungen an den Ressourcenstatus erfülltErfüllt bezeichnet den Status eines SLA, den dieser einnimmt, wenn die im SLA definierten Zeitbedingungen erfüllt wurden. Dies bedeutet, dass der Prozess oder die Ereignisse bis zu dem im SLA angegeben Zeitpunkt oder innerhalb des im SLA angegebenen Zeitraums ausgeführt wurden. Das Gegenteil von erfüllt ist verletzt.. |
| Job-Parameter | |
| OS/390-Dateiname |
Name des Datasets bzw. des Members, das/der entweder
Beispiel: SYSS.AWA.JCL.JOB1 oder SYSS.AWA.JCLLIB(UC4JOB1) Die Jobs können auch aus dem Source-Verwaltungssystem Librarian stammen. Verwenden Sie dabei folgende Syntax:*LIBRARIAN(Dataset, Member). Es sind maximal 255 Zeichen zugelassen. Dataset-Name und Membername müssen in einfache Anführungszeichen gesetzt werden, da der Agent andernfalls den Benutzernamen, unter dem er ausgeführt, voranstellt. Im folgenden Beispiel IBMUSER.SYSS.AWA.JCL.JOB1 ignoriert der Agent die erste Zeile in der Datei, wenn Sie beim Typ „JCL aus z/OS“ auswählen, da er annimmt, dass sie die Jobkarte enthält. |
| RückgabewertWert, der das Ergebnis von Aufgaben und Script-Funktionen repräsentiert. |
Diese Einstellung ist relevant, wenn das Jobende über SMF-Records überwacht wird. In diesem Fall werden die Rückgabewerte der Job-STEPS gesammelt. Wählen Sie
Der Administrator entscheidet, ob SMF-Records für die ÜberwachungÜberwachung ist der Funktionsbereich des Service Orchestrator, in dem der Echtzeitstatus der SLAs des aktuellen Tages angezeigt wird. Ein SLA kann in Überwachung einen von drei Status einnehmen: erfüllt, verletzt und Verletzung vorhergesagt. Anhand des Status und weiterer Informationen im Bereich Überwachung können Sie erkennen, wann Wiederherstellungsmaßnahmen und Vorsorgemaßnahmen erforderlich sind, um verzögerte SLAs aufzulösen oder abzufangen. des Jobendes verwendet wird. Der relevante Parameter ist SMFJob= in der INI-Datei des EreignisAktion, die ausgelöst wird, wenn bestimmte Bedingungen zutreffen. Auch ein eigener Objekttyp in der Automation Engine.-Monitors und die VariableSpeichert oder ermittelt Werte dynamisch zur Laufzeit. Auch ein eigener Objekttyp in der Automation Engine. UC_EX_JOB_MD=UC4START in der INI-Datei des Agenten. |
Abschnitt „Job-Report“
Die nachfolgende Tabelle beschreibt die verfügbaren Optionen:
| Feld | Beschreibung |
|---|---|
| Speichere in |
Sie können eine der Optionen oder beide auswählen. |
| Generiere |
Definieren Sie, wann das Prozessprotokoll des Betriebssystems geschrieben wird.
|
|
Job Log Umfang |
Erlaubte Werte:
|
| Job Log löschen |
|
| Druckfreigabe |
|
| Nachrichtenklassen lesen |
Nachrichtenklassen, die eingelesen und in weiterer Folge umgeleitet werden sollen. Geben Sie eine oder mehrere Nachrichtenklassen an. Beispiele: „A“, „ABC“, „X1“. Die Reihenfolge spielt hierbei keine Rolle. Außerdem sind noch folgende Werte erlaubt: *DEFAULT und *ALL.
|
| Zu Nachrichtenklassen umleiten |
Nachrichtenklassen, in die umgeleitet werden soll. Nach der Übertragung in der Automation Engine kann das Jobprotokoll zusätzlich in die angegebenen Nachrichtenklassen (beispielsweise für ein Output ManagementManagement ist der Funktionsbereich des Service Orchestrator, in dem die Verwaltung von Service Level Agreements (SLAs) durchgeführt wird. In diesem Bereich werden SLA-Definitionen erstellt, bearbeitet und gelöscht. Außerdem dient dieser Bereich auch der Verwaltung Ihrer Geschäftseinheiten. System) umgeleitet werden. Geben Sie entweder eine oder so viele Nachrichtenklassen an, wie Sie im Feld Nachrichtenklassen lesen angegeben haben. Die Reihenfolge spielt dabei eine wichtige Rolle! Beispiel: Folgende Nachrichtenklassen werden „ABC“ eingelesen und nach „DEF“ umgeleitet Die Klasse „A“ wird zur Klasse „D“ umgeleitet, „B“ zu „E“ und „C“ zu „F“. Ein weiteres Beispiel: Folgende Nachrichtenklassen werden eingelesen: „ABC“ und wie folgt umgeleitet: „D“. Die Klassen „A“, „B“ und „C“ werden zu „D“ umgeleitet. Anstelle von konkreten Nachrichtenklassen sind auch folgende Werte erlaubt:
|
Sobald Sie die notwendigen Parameter definiert haben, können Sie mit Ihren Jobs zu arbeiten beginnen. Die nachstehende Liste versucht, eine mögliche Roadmap darzustellen. Sie bietet eine kurze Beschreibung aller realisierbaren Maßnahmen und zusätzliche Informationen zum besseren Verständnis sowie Links zu Themen, in denen diese Maßnahmen genauer beschrieben werden:
Führen Sie den Job aus.
Dafür gibt es mehrere Möglichkeiten, die wie folgt gruppiert werden können:
Das ist der Fall bei Jobs, die in einem Parent-Objekt enthalten sind (zum Beispiel ein Workflow oder eine Gruppe). Beachten Sie bei der Definition, dass ihre Aktivierungszeit von der Startzeit abweichen kann. Diese hängt gewöhnlich vom Parent-Objekt ab.
Stand alone
Das ist der Fall, wenn der Job nicht Teil eines Parent-Objekts ist oder Sie ihn unabhängig von seinem Parent ausführen. Es gibt drei Möglichkeiten:
Wenn ausführbare Objekte verarbeitet werden, durchlaufen sie die folgenden vier Phasen: 1. Aktivierung, 2. Generierung, 3. Prozessierung und 4. Abschluss. Werfen Sie einen Blick auf diese Themen, um zu verstehen, was in den einzelnen Verarbeitungsphasen passiert.
Bei der Verarbeitung von Jobs generiert die Automation Engine Ausgabedateien und Reports, die die Rückverfolgbarkeit und Prüfbarkeit gewährleisten. Schauen Sie sich die folgenden Themen an, um mehr darüber zu erfahren:
Überwachen Sie das generierte Objekt.
Sobald der Job aktiviert ist, steht er als Aufgabe in der PerspektiveEigener Funktionsbereich der Automic Web Interface (AWI) - Weboberfläche.Process Monitoring zur Verfügung. In der Liste Aufgabe sehen Sie seinen Status.
Klicken Sie mit der rechten Maustaste darauf, um den Monitor zu öffnen (siehe Jobs überwachen). Er enthält drei Seiten, die die wichtigsten Informationen zu den Jobparametern liefern.