Les travaux IBM i, ce qu'est un job

C'est quoi, un travail ?

Sur IBM i, aucun programme ne tourne « tout seul ». Quand vous ouvrez une session, quand un traitement de nuit démarre, quand un PC lit une table par ODBC, c'est un travail qui s'en charge. Le travail exécute les programmes les uns après les autres et leur fournit un environnement : un utilisateur, une liste de bibliothèques, une file de sortie pour les impressions, un historique des messages.

Un travail actif contient au moins une unité d'exécution (thread). Un travail Java ou un serveur en a souvent plusieurs, qui travaillent en parallèle ; un programme RPG ou CL classique se contente d'une seule.

IBM compare le système à un centre commercial. Les sous-systèmes sont les boutiques, chacune avec sa surface (sa mémoire) et ses portes d'entrée. Les travaux sont les commandes que chaque boutique traite. Ses règles de fonctionnement sont la description de sous-système. Les clients arrivent par la porte (un écran) ou font la queue (une file d'attente de travaux).

Ce qui se passe sans personne connecté est tout aussi instructif. Nous avons compté les travaux actifs de notre IBM i 7.5 le 14 octobre 2026, sans aucune session 5250 ouverte : 174 travaux, dont 43 travaux système et 45 travaux prédémarrés pour les serveurs. Un IBM i « au repos » travaille en permanence.

Le nom d'un travail : numéro, utilisateur, nom

Chaque travail a un nom qualifié en trois parties, qui l'identifie de façon unique :

On l'écrit dans l'ordre numéro/utilisateur/nom : 011954/SAKADM/EDITION. C'est ce que le système affiche quand on soumet un travail :

Travail 011954/SAKADM/EDITION soumis à la file d'attente DEMOJOBQ de JOBITRV.

Pour agir sur un travail, on peut donner le nom complet ou seulement une partie : WRKJOB JOB(011954/SAKADM/EDITION), WRKJOB JOB(SAKADM/EDITION) ou WRKJOB JOB(EDITION). Si plusieurs travaux correspondent, le système propose de choisir dans une liste. WRKJOB ouvre alors le menu du travail :

Interactif ou batch

Les deux grandes familles de travaux n'ont ni la même entrée ni le même rythme :

L'interactif : un travail par session

Un travail interactif naît quand un utilisateur ouvre une session sur un écran 5250 (un émulateur comme IBM i Access Client Solutions) et meurt quand il la ferme. Entre les deux, le système attend l'utilisateur, traite sa demande, affiche la réponse, et recommence. L'écran d'ouverture de session le dit d'ailleurs : il appartient déjà au sous-système QINTER.

Une fois connecté, la première page de WRKJOB (option 1) confirme le type INTER, le sous-système QINTER et le pool 2 de ce sous-système, celui de la mémoire interactive :

Le batch : soumettre, attendre, exécuter

Un travail batch est un traitement qui n'a pas besoin de dialoguer : une édition, une mise à jour de fichiers, une sauvegarde. On le soumet avec SBMJOB, et l'utilisateur récupère tout de suite la main. Le travail attend dans une file d'attente de travaux, puis un sous-système l'exécute en arrière-plan. Plusieurs travaux batch peuvent tourner en même temps. S'il rencontre une erreur, personne n'est là pour répondre : avec la réponse aux messages par défaut (INQMSGRPY(*RQD)), le travail s'arrête en état MSGW et attend qu'un opérateur réponde au message.

Le système donne aussi la priorité aux humains. La classe de QINTER donne une priorité d'exécution de 20 aux sessions, celle de QBATCH 50 aux traitements : plus le nombre est petit, plus le travail passe en premier sur le processeur. Une saisie reste fluide même pendant un gros traitement.

Le chemin d'un travail batch

IBM décrit la vie d'un travail batch en cinq étapes, des étapes que l'on retrouve dans toutes les pages de cette rubrique. Cliquez sur une étape pour l'ouvrir.

1. On soumet le travail. SBMJOB crée le travail et lui donne ses attributs, pris dans la commande, dans la description de travail (JOBD), dans le profil utilisateur et dans le travail qui soumet.
2. Il attend dans une file d'attente de travaux (JOBQ), la salle d'attente d'un sous-système, rangé par priorité puis par heure d'arrivée.
3. Le sous-système le prend quand il a de la place. Ses données de routage désignent un poste de routage, qui donne le programme à lancer, la classe (priorité, tranche de temps) et le pool de mémoire.
4. Il s'exécute dans la mémoire du pool, et ses impressions deviennent des spools.
5. Les spools attendent dans une file d'attente de sortie (OUTQ), qu'un éditeur les envoie à l'imprimante.

Nous avons suivi ce chemin sur un IBM i 7.5, avec une bibliothèque de démonstration, JOBITRV, qui contient son propre sous-système, sa file d'attente, sa description de travail et sa file de sortie. Le travail EDITION y a été soumis par SBMJOB CMD(DSPLIB LIB(JOBITRV) OUTPUT(*PRINT)) JOB(EDITION) JOBD(JOBITRV/DEMOJOBD) OUTQ(*JOBD). Son historique raconte tout le voyage, de la file d'attente au code de fin :

CPF1124  Travail 011954/SAKADM/EDITION démarré le 14/10/26 à
         15:53:59 dans le sous-système DEMOSBS de JOBITRV ; soumis le 14/10/26 à
         15:53:59.
CPI1125  Travail 011954/SAKADM/EDITION soumis.
         Le travail 011954/SAKADM/EDITION a été soumis en file
         d'attente de travaux DEMOJOBQ de JOBITRV à partir du travail
         011953/SAKADM/QPADEV0001. Le travail 011954/SAKADM/EDITION a été démarré par
         la commande SBMJOB (Soumettre un travail) avec les attributs : JOBPTY(5)
         OUTPTY(5) PRTTXT() RTGDTA(QCMDB) SYSLIBL(QSYS       QSYS2      QHLPSYS
         QUSRSYS) CURLIB(*CRTDFT) INLLIBL(QGPL       QTEMP) INLASPGRP(*NONE) LOG(4 00
         *SECLVL) LOGCLPGM(*NO) LOGOUTPUT(*JOBEND) OUTQ(JOBITRV/DEMOOUTQ)
         PRTDEV(PRT01) INQMSGRPY(*RQD) HOLD(*NO) DATE(*SYSVAL) […]
*NONE    -DSPLIB LIB(JOBITRV) OUTPUT(*PRINT)
CPF1164  Travail 011954/SAKADM/EDITION arrêté le 14/10/26 à
         15:53:59; temps UC 0,007; code fin 0 .

On y lit la file d'attente (DEMOJOBQ), le sous-système (DEMOSBS), les attributs reçus (dont la file de sortie JOBITRV/DEMOOUTQ), la commande exécutée, puis CPF1164 et le code de fin 0 : le travail s'est terminé normalement. Ses deux spools, la liste de la bibliothèque et l'historique lui-même, attendent maintenant dans la file de sortie.

Les types de travaux

Interactif et batch ne sont pas les seuls. WRKACTJOB et le service SQL QSYS2.ACTIVE_JOB_INFO affichent le type de chaque travail sous forme d'un code. Voici les principaux, avec le nombre relevé sur notre IBM i 7.5 au repos :

Aucun travail interactif ni éditeur sur notre relevé : personne n'était connecté, et la partition n'a pas d'imprimante. Les travaux batch ne sont pas des traitements soumis par des utilisateurs : presque tous tournent dans QSYSWRK, le sous-système des fonctions système démarrées automatiquement avec IBM i.

Voir les travaux : WRKACTJOB et WRKSBMJOB

WRKACTJOB liste les travaux actifs, rangés sous leur sous-système. Ici, nous l'avons limitée à cinq sous-systèmes pendant la démonstration :

La colonne Etat dit ce que fait le travail à cet instant. Les plus courants :

WRKSBMJOB montre les travaux que vous avez soumis, y compris ceux qui ne sont pas encore actifs ou déjà terminés. On y voit les trois moments de la vie d'un travail batch :

L'historique du travail

Chaque travail tient un historique (job log) : les commandes exécutées et les messages reçus, informations comme erreurs. C'est le premier endroit où chercher quand un traitement a échoué. Pendant que le travail est actif, on le lit par DSPJOBLOG ou par l'option 10 de WRKJOB. À la fin du travail, il peut devenir un spool, QPJOBLOG.

Le paramètre LOG du travail en décide, en trois éléments : le niveau de détail (0 à 4), la gravité minimale des messages consignés, et le texte. Le troisième est le plus important : avec *NOLIST, aucun historique n'est imprimé si le travail se termine normalement, seulement en cas de fin anormale (code de fin de 20 ou plus). C'est la valeur des descriptions de travail QDFTJOBD et QBATCH sur notre IBM i 7.5 : un travail qui réussit n'y laisse aucune trace imprimée. Notre description de travail de démonstration demande LOG(4 00 *SECLVL) : tout est consigné, avec le texte d'aide des messages, et l'historique est imprimé même quand tout se passe bien.

Les commandes pour gérer les travaux

Et en SQL, avec les services IBM i :

Questions fréquentes