Jobs, sous-systèmes et journaux de job IBM i : WRKACTJOB, WRKSBS, DSPJOBLOG et arrêt sûr d'un job

Ce que c'est

Chaque unité de travail sur IBM i (session interactive 5250, job batch, processus PASE lancé via SSH, job de serveur TCP/IP) s'exécute sous la forme d'un job au sein d'un sous-système, un environnement d'exécution doté de ses propres pools de stockage et files de jobs (QINTER pour l'interactif, QBATCH pour le batch, QSYSWRK et QUSRWRK pour de nombreux jobs serveur). WRKACTJOB liste tous les jobs actuellement actifs, tous sous-systèmes confondus, avec leur consommation de CPU et leur état ; WRKSBS liste les sous-systèmes actifs eux-mêmes.

Chaque job accumule un journal de job (job log) : les commandes qu'il a exécutées ainsi que les messages qu'il a reçus ou envoyés. Ce journal sert à comprendre pourquoi une commande CL s'est comportée de façon inattendue. DSPJOBLOG affiche le journal d'un job encore actif ou dont le journal est en attente (pas encore écrit) ; une fois écrit, le journal est le fichier spoule QPJOBLOG de ce job. DSPJOB ou WRKJOB permettent d'afficher un job à l'état actif, en file de jobs ou en file de sortie, et WRKUSRJOB liste tous les jobs soumis sous un profil utilisateur donné, qu'ils soient actifs, en file d'attente ou avec une sortie en attente. Le niveau de journalisation des messages et les attributs de texte définis dans la description de job déterminent la quantité de détails qui se retrouve dans le journal.

Les messages opérateur à l'échelle du système (notifications de démarrage et d'arrêt de serveurs, erreurs de périphériques et de communications, avertissements de sécurité) arrivent dans la file de messages QSYSOPR plutôt que dans le journal d'un job particulier. DSPMSG QSYSOPR l'affiche, et l'utilitaire PASE system (voir l'article sur SSH/PASE) rend cette commande utilisable depuis une session SSH distante.

Terminer un job ne se résume pas à « le tuer » : ENDJOB prend une valeur OPTION. OPTION(*CNTRLD), la valeur par défaut, demande au job de se terminer de manière contrôlée dans le délai DELAY (30 secondes par défaut). Si le job a enregistré un gestionnaire de signaux et s'est déclaré intéressé par les signaux asynchrones, le système d'exploitation génère le signal SIGTERM pour que l'application puisse se nettoyer, et ne force l'arrêt qu'à l'expiration du délai. OPTION(*IMMED) saute cette phase coopérative et termine le job immédiatement, sans garantie de SIGTERM ; cette option ne convient que pour un job déjà bloqué ou qui ne répond plus.

Pourquoi c'est important

Un agent qui automatise le contrôle des jobs doit distinguer « je veux que ce job s'arrête proprement » (*CNTRLD, avec un délai suffisant pour tout nettoyage multithread) de « ce job est bloqué et je dois m'en débarrasser » (*IMMED). Il doit aussi savoir quelle file de messages (le journal propre au job ou QSYSOPR) contiendra réellement les indices de ce qui s'est mal passé.

Comment l'appliquer

• Utiliser WRKACTJOB ou WRKUSRJOB user-id pour localiser un job avant d'agir sur lui, plutôt que de deviner un numéro de job.
• Utiliser le nom qualifié complet, ENDJOB JOB(number/user/name) OPTION(*CNTRLD) DELAY(nnn) ; un nom de job seul peut correspondre à plusieurs jobs. Réserver *IMMED aux jobs qui ne répondent pas à une fin contrôlée. Terminer les jobs d'autres utilisateurs requiert normalement l'autorité spéciale *JOBCTL.
• Consulter DSPMSG QSYSOPR pour les défaillances au niveau système (serveur arrêté, erreur de périphérique), qui n'apparaissent pas dans le journal d'un job applicatif.
• Si le journal d'un job est maigre, vérifier son niveau de journalisation dans la description de job avant de conclure qu'il ne s'est rien passé.

Pièges

• Terminer un job multithread avec un délai trop court pour que ses threads détectent SIGTERM et se nettoient : cela revient simplement à un *IMMED plus lent.
• Chercher dans un journal de job une défaillance de démarrage ou de serveur alors qu'elle a en réalité été publiée dans QSYSOPR.