Les sous-systèmes IBM i, QINTER, QBATCH et les autres

À quoi sert un sous-système ?

Un IBM i fait tourner en même temps des sessions d'utilisateurs, des traitements de nuit, des serveurs et des impressions. Les sous-systèmes séparent ces familles de travail, pour que chacune ait ses propres règles :

• sa mémoire : les sessions interactives ne se battent pas pour la même mémoire que les gros traitements ;
• sa priorité : une saisie reste rapide pendant qu'un batch tourne ;
• son débit : on limite le nombre de travaux qui tournent à la fois ;
• son interrupteur : on arrête les sessions des utilisateurs (ENDSBS QINTER) sans arrêter les traitements, par exemple pour un week-end de batch sans connexion.

Chaque sous-système actif est piloté par un travail du même nom, son moniteur (type SBS dans WRKACTJOB), qui démarre les travaux, les contrôle et les arrête. Seuls les travaux système (type SYS) vivent hors de tout sous-système.

Les sous-systèmes livrés par IBM

IBM livre deux configurations prêtes à l'emploi. La valeur système QCTLSBSD choisit celle qui démarre : QBASE, qui réunit dans un même sous-système l'interactif, le batch et les communications, ou QCTL, qui répartit le travail en plusieurs sous-systèmes. Sur notre IBM i 7.5, QCTLSBSD vaut QCTL QSYS. Voici les sous-systèmes de cette configuration, avec le nombre de travaux que nous y avons comptés sans aucune session ouverte :

Le compte inclut le moniteur du sous-système : un QINTER sans session compte 1 travail, son moniteur. Les logiciels ajoutent leurs propres sous-systèmes. Sur notre système, on trouve aussi QHTTPSVR (serveur HTTP) et Q1ABRMNET (BRMS), et DEMOSBS, celui que nous avons créé pour cette rubrique. WRKSBS les liste :

Qui démarre les sous-systèmes ?

Au démarrage d'IBM i (l'IPL), le système démarre le sous-système de contrôle désigné par QCTLSBSD. Celui-ci a un travail autostart qui appelle le programme de démarrage, désigné par la valeur système QSTRUPPGM (par défaut QSTRUP de QSYS). C'est ce programme qui démarre les autres sous-systèmes et les imprimantes. Nous l'avons vérifié dans le source d'origine de QSTRUP : il démarre QSERVER, QUSRWRK, QINTER, QBATCH, QCMN et QSPL, mais pas QSYSWRK, qui est actif dès la fin du démarrage du système.

Le programme de démarrage se remplace : on en écrit une copie qui démarre aussi ses propres sous-systèmes ou serveurs, puis on change QSTRUPPGM, une valeur système que seul un responsable sécurité peut modifier et qui ne compte qu'au démarrage suivant. Sur notre système, c'est une copie rangée dans QGPL.

La description de sous-système (*SBSD)

Un sous-système est entièrement décrit par un objet *SBSD : d'où vient son travail, combien de travaux il accepte, quelle mémoire il utilise, et comment chaque travail est aiguillé. DSPSBSD en montre toutes les parties :

Un sous-système sans poste pour un type de travail ne peut pas l'exécuter : un sous-système sans poste écran n'accepte aucune session, un sous-système sans poste file d'attente n'exécute aucun batch. QINTER, par exemple, accepte les écrans de tout type grâce à son poste *ALL :

Le routage : comment un travail reçoit sa priorité

Quand un travail entre dans un sous-système, celui-ci compare ses données de routage, une courte chaîne de caractères, aux valeurs de comparaison de ses postes de routage, dans l'ordre des numéros de séquence. Le premier poste qui correspond donne au travail son programme, sa classe et son pool de mémoire. Si aucun ne correspond, le travail s'arrête.

Nous avons suivi les deux chemins sur notre IBM i 7.5 :

La session : QCMDI, poste 10 de QINTER

Le profil qui ouvre la session utilise la description de travail QGPL/QDFTJOBD, dont les données de routage valent QCMDI. Le premier poste de routage de QINTER attend justement 'QCMDI' :

Le pool 2 de QINTER est *INTERACT, la mémoire réservée à l'interactif, et la classe QINTER donne une priorité d'exécution de 20 avec une tranche de temps de 2 secondes :

Le batch : QCMDB, et le poste *ANY de QBATCH

Un travail soumis par SBMJOB reçoit par défaut les données de routage QCMDB (paramètre RTGDTA). Or QBATCH n'a aucun poste dont la valeur soit 'QCMDB' : c'est son dernier poste, 9999 *ANY, qui accepte tout, qui prend le travail.

La mémoire : les pools

La mémoire centrale est découpée en pools. Deux sont spéciaux : *MACHINE, réservé au système (aucun travail utilisateur n'y tourne), et *BASE, qui reçoit toute la mémoire non attribuée et sert au batch. Les pools partagés *INTERACT (l'interactif), *SPOOL (les éditeurs) et *SHRPOOL1 à *SHRPOOL60 sont à la disposition des sous-systèmes.

Attention aux deux numérotations. Dans un sous-système, les pools sont numérotés de 1 à 10 : pour QINTER, 1 = *BASE et 2 = *INTERACT. Le système, lui, numérote tous les pools en service : *MACHINE est le 1, *BASE le 2, les autres suivent dans l'ordre où ils sont alloués. C'est pourquoi WRKSBS affiche « 2 3 » pour QINTER : le pool 3 du système est son *INTERACT.

Ne confondez pas non plus le nombre maximal de travaux d'un sous-système et le niveau d'activité d'un pool, le nombre d'unités d'exécution qui peuvent y tourner en même temps. Un travail peut être actif dans le sous-système et attendre son tour dans le pool.

Créer son propre sous-système

Pour notre démonstration, nous avons créé le sous-système DEMOSBS dans la bibliothèque JOBITRV. Il faut trois choses : la description, une source de travail (ici une file d'attente, qui n'exécute qu'un travail à la fois) et un poste de routage :

CRTSBSD    SBSD(JOBITRV/DEMOSBS) POOLS((1 *BASE)) +
             TEXT('Sous-système de démonstration')
ADDJOBQE   SBSD(JOBITRV/DEMOSBS) JOBQ(JOBITRV/DEMOJOBQ) MAXACT(1) +
             SEQNBR(10)
ADDRTGE    SBSD(JOBITRV/DEMOSBS) SEQNBR(9999) CMPVAL(*ANY) +
             PGM(QSYS/QCMD) CLS(QGPL/QBATCH)
STRSBS     SBSD(JOBITRV/DEMOSBS)

La classe QGPL/QBATCH est nommée explicitement : par défaut, ADDRTGE cherche une classe du même nom que le sous-système (CLS(*SBSD)), qui n'existe pas ici. Une fois démarré, DEMOSBS apparaît dans WRKSBS et WRKACTJOB, et sa file d'attente est bien rattachée :

Pour l'arrêter : ENDSBS SBS(DEMOSBS) OPTION(*CNTRLD) DELAY(60) laisse une minute aux travaux pour finir, OPTION(*IMMED) les arrête tout de suite. La suite, avec la file d'attente et la description de travail, est sur la page JOBQ et JOBD.

/* La bibliothèque de démonstration                                  */
CRTLIB     LIB(JOBITRV) TEXT('Démonstration gestion des travaux')

/* Une file d'attente de travaux et une file d'attente de sortie     */
CRTJOBQ    JOBQ(JOBITRV/DEMOJOBQ) +
             TEXT('File d''attente des travaux de démonstration')
CRTOUTQ    OUTQ(JOBITRV/DEMOOUTQ) +
             TEXT('File d''attente de sortie de démonstration')

/* La description de travail qui relie les deux                      */
CRTJOBD    JOBD(JOBITRV/DEMOJOBD) JOBQ(JOBITRV/DEMOJOBQ) JOBPTY(5) +
             OUTPTY(5) OUTQ(JOBITRV/DEMOOUTQ) +
             INLLIBL(JOBITRV QGPL QTEMP) LOG(4 00 *SECLVL) +
             TEXT('Description de travail de démonstration')

/* Le sous-système : un pool, une file, un poste de routage          */
CRTSBSD    SBSD(JOBITRV/DEMOSBS) POOLS((1 *BASE)) +
             TEXT('Sous-système de démonstration')
ADDJOBQE   SBSD(JOBITRV/DEMOSBS) JOBQ(JOBITRV/DEMOJOBQ) MAXACT(1) +
             SEQNBR(10)
ADDRTGE    SBSD(JOBITRV/DEMOSBS) SEQNBR(9999) CMPVAL(*ANY) +
             PGM(QSYS/QCMD) CLS(QGPL/QBATCH)
STRSBS     SBSD(JOBITRV/DEMOSBS)

/* Cinq travaux soumis depuis une session 5250                       */
SBMJOB     CMD(DSPLIB LIB(JOBITRV) OUTPUT(*PRINT)) JOB(EDITION) +
             JOBD(JOBITRV/DEMOJOBD) OUTQ(*JOBD)
SBMJOB     CMD(DLYJOB DLY(3600)) JOB(CALCUL1) JOBD(JOBITRV/DEMOJOBD)
SBMJOB     CMD(DLYJOB DLY(3600)) JOB(CALCUL2) JOBD(JOBITRV/DEMOJOBD)
SBMJOB     CMD(DLYJOB DLY(3600)) JOB(CALCUL3) JOBD(JOBITRV/DEMOJOBD)
SBMJOB     CMD(DLYJOB DLY(3600)) JOB(CALCUL4) JOBD(JOBITRV/DEMOJOBD) +
             HOLD(*YES)

Les commandes des sous-systèmes

Et en SQL :

Questions fréquentes