OS/400

OS/400

OS/400-Agent - FileEvent-Unterstützung

---

Agent - Zusammenwirken Automation Engine und OS/400

Der OS/400-Agent arbeitet über eine TCP/IP-Schnittstelle mit dem Automation Engine System zusammen.

Der OS/400-Agent verfügt über folgende Funktionalität:

• Verarbeiten von Jobs
• Erfassen und Nachverfolgen von Remote-Status
• Durchführen von FileTransfers
• Durchführen von FileTransfers
• Ereignis-Behandlung
• CallAPI

Verarbeiten von Jobs 

Jobs werden in der AE als Objekte mit verschiedenen Registerkarten definiert und gepflegt. In der Registerkarte Script ist die JCL (CMD, CL oder REXX) hinterlegt. Sie kann durch Script-Sprachmittel von AE mit einer komplexen Logik versehen werden.
Siehe: Benutzerhandbuch - Job und Job - Ausführen

Ein Job wird in AEdurch Steuerungsmechanismen, wie beispielsweise Workflow oder Schedule, bzw. manuell gestartet. Dabei wird in der Automation Engine ein ablauffähiger Job generiert und per FileTransfer an den OS/400-Agenten gesendet.
Siehe: AE Intern - Durchführung von Objekten

Im OS/400 wird der Job über das Kommando SBMJOB gestartet, in welchem die „AE Job-Shell" (Programm „IRSTRJOB" in ausgelieferter Bibliothek) aufgerufen wird. Die Job-Shell bekommt unter anderem den von der Automation Engine generierten Jobnamen bzw. den Namen des Filemembers, unter welchem der Job gespeichert ist, als Parameter mit. Sie führt je nach Typ des Jobs Folgendes durch:

• CMD
  Die Job-Shell führt jede Zeile aus dem Filemember durch. Tritt bei einer Zeile ein Fehler auf, wird der Severitycode als Rückgabewert des Jobs gesetzt und nur noch der Jobmelder am Ende des Jobs aufgerufen.
• ILE CL
  Die Job-Shell wandelt das Filemember um und erzeugt damit ein temporäres CL-Programm. Bei erfolgreicher Umwandlung wird das CL-Programm von der Job-Shell durchgeführt.
• REXX
  Die Job-Shell ruft den REXX-Interpreter auf und übergibt den Namen des Filemembers, welches das REXX-Script beinhaltet.

Jeder Job meldet Beginn und Ende der Durchführung dem Agenten (Jobmelder), der seinerseits diese Informationen an die Automation Engine weiterschickt. Der Rückgabewert des Jobs ist in der AE verfügbar.

Der Agent überwacht in regelmäßigen Intervallen den Status des Jobs. Geht ein Job verloren (durch ABEND oder CANCEL), wird durch diesen Mechanismus das abnormale Ende festgestellt. Der Job gilt dann im Automation Engine System als verschwunden.

Es wird auch der Status der Jobs ermittelt, die durchgeführt wurden, während der Agent inaktiv ist. Dies ist durch die Ausgabe von Start- und Endmelder im Job-Report möglich, die vom Agenten analysiert wird.

Beachten Sie, dass die JCL auf OS/400 zu einem Programm kompiliert und danach ausgeführt wird. Dabei kann es zu einem unkontrollierten Abbruch kommen, wodurch der Jobstatus nicht korrekt angezeigt werden kann. Mit dem Kommando MONMSG ist es möglich, Programmabbrüche zu erkennen und darauf zu reagieren. Für die Verwendung dieses Kommandos ist die Jobeinstellung "Typ" - "ILE CL" erforderlich.

In folgendem Beispiel die Durchführung der JCL mit dem Kommando MONMSG überwacht und der Jobstatus entsprechend gesetzt:

Registerkarte Pre-Script:

! Activates the start and end messenger output for the status recovery.
:SET&UC_QPRINT = 10
! The OS/400 CL command monitors all exceptions and skips to the ERROR label.
MONMSG CPF0000 (GOTO ERROR)

Registerkarte Script:

! Command to be executed by the job. All active processes are shown in this case.
wrkactjob *print
! Sets the job's return code to the value 0.
CHGVAR &RETCODE '0'
! Calls the end messenger.
GOTO END
! The adequate return code is set if an error occurs.
ERROR:
CHGVAR &RETCODE '99'

Der Job-Report (Spool), bestehend aus dem Spoolinhalt (je nach Definition des Jobs nur QPJOBLOG oder der gesamte Inhalt), wird in die von der Automation Engine benannte Datei geschrieben. Wenn im Job so festgelegt, überträgt der Agent den Report an die Automation Engine, welche diesen in die AE Datenbank speichert.

Erfassen und Nachverfolgen von Remote-Status

Wenn sie mit OS/400 Version IBM i 6.1 oder neuer arbeiten, können Sie mit den folgenden Beispielen für SQL Anweisung überprüfen, ob OS/400-Jobs mit Status MSGW (= auf Meldungen wartend) vorliegen:

Alle Jobs mit MSWG-Status auflisten:

select count(*) from EH where EH_RemoteStatus = 2006018 AND EH_Client = &$CLIENT#

Rückgabe aller notwendigen Informationen, für Aktionen bezüglich Jobs im MSGW-Status:

select EH_AH_Idnr, EH_RemoteStatus, EH_RemoteStatusIns, EH_Alias from EH where EH_RemoteStatus = 2006018 AND EH_Client = &$CLIENT#

Sie können das Intervall für die Überprüfung des Job-Status verkürzen, indem Sie den Wert für JOB_CHECKINTERVAL in der Systemvariable UC_HOSTCHAR_DEFAULT ändern. Bitte beachten Sie, dass sich eine Senkung dieses Wertes auf die Serverleistung auswirkt.

Durchführen von FileTransfers

FileTransfers werden in der AE als Objekte mit verschiedenen Registerkarten definiert und gepflegt. Sie werden mit der dort festgelegten Zeichenumsetzung durchgeführt, zum Beispiel „EBCDIC_00273".

Mehr Informationen dazu siehe: OS/400-Agent - FileTransfer-Unterstützung

Ereignis-Behandlung

Ereignisse werden in der AE als Objekte mit verschiedenen Registerkarten definiert und gepflegt. Es können Dateisystem-Ereignisse definiert werden, welche sich auf das Library File System (QSYS.LIB) beziehen. Der OS/400-Agent unterstützt auch Ereignisse vom Typ "Konsole".
Siehe: Benutzerhandbuch - Ereignis

Ausführen von Dateisystem-Ereignisobjekten

Bei der Verwendung von Dateisystem-Ereignissen mit einem OS/400 Agenten sind einige Besonderheiten zu berücksichtigen.

Mehr Informationen dazu siehe: OS/400 Agent - Unterstützung für Dateisystem-Ereignisse

CallAPI

Das CallAPI kann mit einem Dienstprogramm genutzt werden, welches beispielsweise aus einem CL-Script heraus aufgerufen werden kann.
Siehe: Benutzerhandbuch - CallAPI

Siehe auch:

Job

Ausführung von Objekten

OS/400-Agent - FileTransfer-Unterstützung

OS/400 Agent - Unterstützung für Dateisystem-Ereignisse