Agenten - Interaktion zwischen AE und OS/400

Das folgende Dokument richtet sich an Administratoren, die wissen möchten, wie der OS/400-Agent über eine TCP/IP-Schnittstelle mit dem AE-System zusammenarbeitet.

Diese Seite beinhaltet Folgendes:

Jobs verarbeiten

Jobs werden in der AE als Objekte mit verschiedenen Seiten definiert und gepflegt. Verwenden Sie Automation Engine scripting language, um komplexe Logik auf die Prozessseite des Jobs aufzunehmen.

Mehr Informationen:

Auf der Seite Prozess des Job-Objekts schreiben Sie Befehle in der Job Control Language (CMD, CL oder REXX). Weitere Informationen finden Sie unter Job Control Language – Script-Referenz.

Mehr Informationen:

Ein Job wird in der AE durch Steuerungsmechanismen, wie beispielsweise Workflow oder Schedule, oder auch manuell gestartet. Dabei wird in der Automation Engine ein ablauffähiger Job generiert und per FileTransfer an den OS/400-Agenten geschickt. Weitere Informationen finden Sie unter Ausführungsphasen.

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

Jeder Job meldet Beginn und Ende der Durchführung dem Agenten (Job Messenger). Dieser reicht diese Informationen seinerseits an die Automation Engine weiter. 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 AE-System als verschwunden.

Es wird auch der Status der Jobs ermittelt, die durchgeführt wurden, während der Agent inaktiv ist. Dies ist anhand der Ausgaben zu Start und Ende durch den Messenger möglich.

Hinweis:

Auf OS/400 wird die JCL zu einem Programm kompiliert und danach ausgeführt. Dabei kann es zu einem unkontrollierten Abbruch kommen, wodurch möglicherweise 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 Befehls ist die Jobeinstellung Typ- ILE CL erforderlich.

In folgendem Beispiel wird die Ausführung der JCL mit dem Befehl MONMSG überwacht und der Jobstatus entsprechend gesetzt:

Seite "Pre-Prozess"

! Aktiviert die Start-und End-Messenger-Ausgabe für die Statuswiederherstellung.
:SET &UC_QPRINT= 10
! Der OS/400 CL-Befehl überwacht alle Ausnahmen und springt zum ERROR-Label.
MONMSG CPF0000 (GOTO ERROR)

Seite "Prozess"

! Befehl, der vom Job ausgeführt werden soll. In diesem Fall werden alle aktiven Prozesse angezeigt.
wrkactjob *print
! Setzt den Rückgabewert des Jobs auf den Wert 0.
CHGVAR &RETCODE '0'
! Ruft den Ende-Messenger auf.
GOTO END
! Der entsprechende Rückgabewert wird festgelegt, wenn ein Fehler auftritt.
ERROR:  
CHGVAR &RETCODE '99'

Der Job-Report (Spool) besteht aus dem Spool-Inhalt (je nach der Job-Definition nur QPJOBLOG oder dem gesamten Inhalt). Er wird in eine Datei geschrieben, die durch die Automation Engine angegeben ist. Wenn im Job so festgelegt, überträgt der Agent den Report an die Automation Engine, welche diesen in der AE Datenbank speichert.

Remote-Status-Erfassung und -verfolgung

OS/400-Jobs haben möglicherweise den Status MSGW (Warten auf Nachrichten), was bedeutet, dass ein Job auf eine Antwort auf eine bestimmte Meldung wartet. Dieser Status ist spezifisch für OS/400-Jobs und sie benötigen zusätzliche Objekte, um sie in die Automation Engine zu integrieren.

Aus Sicht der Automation Engine ist der OS/400-Job wie jeder andere Job (Windows, Unix usw.) aktiv. Wenn Sie OS/400 Version IBM i 6.1 oder höher haben, können Sie mit einem zusätzlichen SQL-Befehl abfragen, ob der Job noch wartet (Status MSGW). Dazu können Sie eine SQLI-Variable (siehe SQLI-VARA-Objekte ) erstellen und den folgenden SQL-Befehl verwenden:

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

Hinweis: Sie können das Intervall, in dem der Status von Jobs überprüft wird, verringern, indem Sie den Wert für JOB_CHECKINTERVAL in den Systemeinstellungen ändern. Weitere Informationen finden Sie unter UC_HOSTCHAR_DEFAULT - Host-Charakteristika. Beachten Sie, dass sich dieser Wert negativ auf die Serverleistung auswirkt.

Wenn es einen Job mit MSGW-Status gibt, liefert die SQLI-Variable, die die Abfrage ausgeführt, das Ergebnis mit den folgenden Informationen:

Sie können die Meldungseinträge der Felder EH_RemoteStatus und EH_RemoteStatusIns mithilfe der Script-Funktion GET_MSG_TXT übersetzen, siehe GET_MSG_TXT. Die Script-Funktion gibt den Meldungstext zurück.

Beispiel

U00020408 U02006018 Job Run-Id: '24212270' Report-Status 'Warten auf Meldung' für Prozess '969637/UCPROD/MSGW'. Prozess wartet auf eine Meldungsantwort auf Meldung 'CPA5305', Schlüssel '0000D220' in Meldungs-Queue: 'QSYS/QSYSOPR'.

Sie können auch die Script-Funktion STR_SPLIT (siehe STR_SPLIT) verwenden, um den Text dieses Felds zu unterteilen, damit der Inhalt im Script verarbeitet werden kann. Der Eintragstext enthält die folgenden Daten:

Diese Informationen ermöglichen es Ihnen, die Daten des Felds EH_RemoteStatusIns zu verwenden, um einen zusätzlichen OS/400-Job zu erstellen, um auf die Anfragemeldung zu beantworten. Dazu können Sie den Befehl OS/400 Send Reply (SNDRPY) verwenden.

Beispiel

OS/400-Job sendet eine Antwort auf die Anfragemeldung, die vom OS/400-Meldungsschlüssel (Registerkarte Pre-Prozess des OS/400-Jobs) gefunden wurde:

! Für MSGW

:SET &MSGW_MSGKEY# = STR_TRIM(&MSGW_MSGKEY#)

DCL VAR(&MSGKEY) TYPE(*CHAR) LEN(4)

! MSGKEY# kommt von außen

CHGVAR VAR(&MSGKEY) VALUE(X'&MSGW_MSGKEY#)

Wenn es einen Job mit MSGW-Status gibt, verwenden Sie SNDRPY, um zu antworten (Registerkarte Prozess des OS/400-Jobs):

! Antwort mit 9999

SNDRPY MSGKEY(&MSGKEY) MSGQ(&MSGW_MSGQ#) RPY(9999) RJTDFTRPY(*ALWRJT)

Weitere Informationen finden Sie unter Prozess-Seiten.

FileTransfers durchführen

FileTransfers werden in der AE als Objekte mit verschiedenen Registerkarten definiert und gepflegt. Sie werden mit der auf diesen Registerkarten festgelegten Zeichenumwandlungen durchgeführt (z. B. EBCDIC_00037).

Weitere Informationen finden Sie unter OS/400-Agent - Unterstützung bei FileTransfers.

Ereignisbehandlung

Ereignisse werden in der AE als Objekte mit verschiedenen Registerkarten definiert und gepflegt. Es können FILE-Ereignisobjekte definiert werden, welche sich auf das Bibliotheksdateisystem (QSYS.LIB) beziehen. Der OS/400-Agent unterstützt auch Ereignisse vom Typ "Konsole".Weitere Informationen finden Sie unter
Ereignisse (EVNT).

FILE-Ereignisobjekte ausführen

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

Weitere Informationen finden Sie unter OS/400 Agent - Dateiereignisunterstützung.

CallAPI

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

Weitere Informationen finden Sie unter CallAPI für OS/400.

Siehe auch: