Base de connaissances > Automation Engine et systèmes cibles > OS/400 > Agent - Combinant AE et OS/400

Agent - Interaction entre Automation Engine et OS/400

L'agent OS/400 interagit avec le système AE via une interface TCP/IP.

L'agent OS/400 dispose des fonctionnalités suivantes :

Traitement de jobs 

Dans AE, les jobs sont définis et gérés comme des objets à l'aide d'onglets. Le JCL (CMD, CL ou REXX) est enregistré dans l'onglet Traitement. Sa logique peut être très complexe si vous utilisez des éléments de scripts d'AE.
Rubriques connexes : Manuel utilisateur – Job et Job – Exécution.

Dans AE, un job est démarré manuellement ou à l'aide de mécanismes de contrôle comme les Workflows ou les Schedules. Automation Engine génère un job activable et l'envoie à l'agent OS/400 par un transfert de fichier.
Rubriques connexes : Manuel de fonctionnement d'Automation Engine - Exécuter des objects

Dans OS/400, vous pouvez démarrer des jobs avec la commande SBMJOB qui appelle le shell du job AE (programme IRSTRJOB dans la bibliothèque fournie). Entre autres informations, le shell du job reçoit les paramètres suivants : le nom du job généré par le Automation Engine et le nom du membre de fichier sous lequel le job est enregistré. Selon le type de job, il exécute les tâches suivantes :

Chaque job notifie à l'agent (messager du job) le début et la fin de l'exécution. L'agent transmet ensuite cette information au Automation Engine. Le code retour du job est disponible dans AE.

L'agent surveille le statut du job à intervalles réguliers. Ce mécanisme permet de déterminer une fin anormale si un job est perdu (ABEND ou CANCEL). Le job est alors considéré comme perdu dans le système AE.

Les statuts des jobs qui ont été exécutés quand l'agent était arrêté sont également récupérés. Cela est possible en raison des messages de sortie de début et de fin.

Notez que sur OS/400, le JCL est compilé en un programme puis est exécuté. Une terminaison incontrôlée peut se produite ce qui aurait comme effet que le statut du job ne pourrait pas être affiché correctement. Utilisez la commande MONMSG ppour identifier les terminaisons de programmes et y réagir. Pour utiliser cette commande, le paramètre du job "Type" - "ILE CL" est nécessaire.

L'exemple suivant suirveille l'exécution du JCL à l'aide de la commande MONMSG et définit en fonction du statut du job :

Onglet Pré-traitement :

! 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)

Onglet Traitement :

! 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'

Le rapport du job (spool) est composé du contenu du spool (selon la définition du job, uniquement QPJOBLOG ou le contenu entier). Il est écrit dans le fichier indiqué par le Automation Engine. Si cela est défini dans le job, l'agent transfère le rapport à Automation Engine qui l'enregistre dans la base de données AE.

Capture et suivi du statut distant

Sous OS/400 version IBM i 6.1 ou précédents, vous devez utiliser les exemples d'instruction SQL suivants pour vérifier si un job OS/400 a un statut MSGW (en attente de message) :

Liste tous les jobs en statut MSGW :

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

Retourne toutes informations nécessaires pour réaliser des actions sur les jobs en statut MSGW :

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

Vous pouvez diminuer l'intervalle pendant lequel le statut du job est vérifié en changeant la valeur par JOB_CHECKINTERVAL, dans la variable système UC_HOSTCHAR_DEFAULT. La diminution de valeur a un impact sur les performances du serveur.

Exécuter des transferts de fichiers

Dans AE, les transferts de fichiers sont définis et gérés comme des objets à l'aide d'onglets. Ils sont exécutés avec la conversion de caractères définie dans ces onglets, par exemple "EBCDIC_00273".

Pour plus d'informations, voir... Agent OS/400 - Support du transfert de fichier

Traitement des événements

Dans AE, les événements sont définis et gérés comme des objets avec différents onglets. Vous pouvez définir des événements de système de fichiers se rapportant au Library File System (QSYS.LIB). L'agent OS/400 prend également en charge les événements de type console.
Rubriques connexes : Manuel utilisateur – Evénement

Exécution d'un objet événement de système de fichiers

Quelques particularités sont à prendre en compte lors de l'utilisation d'un événement fichier avec un agent OS/400.

Pour plus d'informations, voir... Agent OS/400 - Support des événements du système de fichiers

CallAPI

CallAPI peut être utilisé avec un utilitaire pouvant par exemple être exécuté à partir d'un script CL.
Rubriques connexes : Manuel de l'utilisateur - CallAPI

 

Rubriques connexes :

Job

Exécution d'objets

Agent OS/400 - Support du transfert de fichier

Agent OS/400 - Support des événements du système de fichiers