Un travail batch bloqué : LCKW, MSGW et RNQ1218

La chaîne de nuit

Un programme pilote, NUITCHAINE, lance sept programmes l'un après l'autre et note chaque lancement et chaque fin d'étape dans un fichier journal :

Les données sont dans quatre fichiers physiques décrits en DDS et deux fichiers logiques :

Le pilote appelle les programmes par un seul prototype dont le nom est une variable (extpgm(nomPgm)). Son fichier journal est déclaré block(*no) : chaque ligne est écrite tout de suite, et reste lisible même si la chaîne ne va pas au bout.

**free
// ---------------------------------------------------------------------
// NUITCHAINE : pilote du traitement de nuit
// Lance les 7 programmes de la chaîne l'un après l'autre et trace
// chaque lancement dans le journal JOURNP et dans l'historique du travail.
// ---------------------------------------------------------------------
ctl-opt dftactgrp(*no) actgrp(*new) option(*srcstmt:*nodebugio);

// block(*no) : chaque ligne est écrite tout de suite, visible même si
// la chaîne reste bloquée
dcl-f JOURNP usage(*output) block(*no);

dcl-s nomPgm char(10);
dcl-pr lancer extpgm(nomPgm) end-pr;

dcl-s programmes char(10) dim(7);
dcl-s etape int(5);

programmes(1) = 'NUIT01INI';    // ouverture de la journée
programmes(2) = 'NUIT02VAL';    // validation des commandes saisies
programmes(3) = 'NUIT03ENC';    // mise à jour de l'encours client
programmes(4) = 'NUIT04FAC';    // facturation des commandes validées
programmes(5) = 'NUIT05STA';    // statistiques clients
programmes(6) = 'NUIT06PUR';    // purge des commandes annulées
programmes(7) = 'NUIT07FIN';    // clôture de la journée

journal(0: 'NUITCHAINE': 'Début de la chaîne de nuit');

for etape = 1 to %elem(programmes);
  nomPgm = programmes(etape);
  journal(etape: nomPgm: 'Lancement');
  snd-msg *info 'Étape ' + %char(etape) + ' : lancement de ' + %trim(nomPgm);
  lancer();
  journal(etape: nomPgm: 'Terminé');
endfor;

journal(0: 'NUITCHAINE': 'Chaîne de nuit terminée normalement');
snd-msg *info 'Chaîne de nuit terminée normalement';
*inlr = *on;

// ---------------------------------------------------------------------
// Écrit une ligne dans le journal de la chaîne
// ---------------------------------------------------------------------
dcl-proc journal;
  dcl-pi *n;
    pEtape int(5) const;
    pPgm char(10) const;
    pMsg varchar(60) const;
  end-pi;

  joheure = %timestamp();
  joetape = pEtape;
  jopgm = pPgm;
  jomsg = pMsg;
  write journr;
end-proc;

L'étape 3 parcourt les commandes validées par client (logique CDEL1) et relit chaque client pour mise à jour : c'est ce CHAIN, ligne 20, qui va attendre.

**free
// ---------------------------------------------------------------------
// NUIT03ENC : étape 3, mise à jour de l'encours client
// Parcourt les commandes validées par client (logique CDEL1) et ajoute
// leur montant à l'encours du client (CLIENTP lu pour mise à jour).
// Si un autre travail tient la fiche d'un client, le CHAIN attend
// (WAITRCD du fichier) puis le programme s'arrête sur RNQ1218.
// ---------------------------------------------------------------------
ctl-opt dftactgrp(*no) actgrp(*caller) option(*srcstmt:*nodebugio);

dcl-f CDEL1 usage(*input) keyed;
dcl-f CLIENTP usage(*update) keyed;
dcl-f JOURNP usage(*output) block(*no);

dcl-s nbMaj int(10);

setll 'V' CDEL1;
reade 'V' CDEL1;
dow not %eof(CDEL1);
  chain cdcli CLIENTP;
  if %found(CLIENTP);
    clencours += cdmont;
    clnbcde += 1;
    update clientr;
    nbMaj += 1;
  endif;
  reade 'V' CDEL1;
enddo;

journal(%char(nbMaj) + ' commandes ajoutées à l''encours client');
*inlr = *on;

dcl-proc journal;
  dcl-pi *n;
    pMsg varchar(60) const;
  end-pi;

  joheure = %timestamp();
  joetape = 3;
  jopgm = 'NUIT03ENC';
  jomsg = pMsg;
  write journr;
end-proc;

Le coupable

Pour provoquer la panne, un autre travail joue l'utilisateur parti déjeuner en laissant la fiche du client 3 ouverte en modification : il la lit pour mise à jour, et ne la relâche jamais.

**free
// ---------------------------------------------------------------------
// SAISIECLI : simule un utilisateur parti déjeuner en laissant la fiche
// du client 3 ouverte en modification. Le CHAIN pour mise à jour pose
// un verrou d'enregistrement qui n'est jamais relâché, puis le travail
// attend 30 minutes.
// ---------------------------------------------------------------------
ctl-opt dftactgrp(*no) actgrp(*new) option(*srcstmt:*nodebugio);

dcl-f CLIENTP usage(*update) keyed;

dcl-pr qcmdexc extpgm('QCMDEXC');
  cmd char(200) const;
  lng packed(15:5) const;
end-pr;

dcl-s numClient zoned(6:0) inz(3);

chain numClient CLIENTP;
qcmdexc('DLYJOB DLY(1800)': 16);
*inlr = *on;

Les deux travaux sont soumis par SBMJOB. Le coupable va dans QSYSNOMAX : la file QBATCH de notre système ne fait tourner qu'un travail à la fois, et la chaîne aurait attendu derrière lui sans même démarrer (voir MAXACT).

/* Le coupable : garde la fiche du client 3 en mise à jour, puis attend 30 minutes */
SBMJOB CMD(CALL PGM(JOBIBLOC/SAISIECLI)) JOB(SAISIECLI) +
       JOBD(JOBIBLOC/SIMJOBD) JOBQ(QSYSNOMAX) INLLIBL(*JOBD)

/* La chaîne de nuit : 7 programmes à la suite */
SBMJOB CMD(CALL PGM(JOBIBLOC/NUITCHAINE)) JOB(CHAINENUIT) +
       JOBD(JOBIBLOC/SIMJOBD) INLLIBL(*JOBD)

Le diagnostic, écran par écran

1. Le travail est en LCKW

Quelques secondes après la soumission, WRKACTJOB montre la chaîne dans QBATCH, en état LCKW : elle attend un verrou.

2. Où est-il arrêté ? La pile d'appels

La colonne Fonction ne nomme que le pilote. Pour savoir quel programme attend, et à quelle instruction : option 5 (gérer le travail), puis 11 (liste d'appel des programmes).

Option 12 (verrouillages du travail), puis F10 : les verrous d'enregistrements.

3. Qui tient l'enregistrement ?

DSPRCDLCK sur le fichier répond directement :

En SQL, la vue QSYS2.RECORD_LOCK_INFO donne la même réponse (relevé lors d'un second passage, après remise à zéro des données) :

SELECT RELATIVE_RECORD_NUMBER AS RRN, LOCK_STATE, LOCK_STATUS, JOB_NAME
  FROM QSYS2.RECORD_LOCK_INFO
 WHERE TABLE_SCHEMA = 'JOBIBLOC' AND TABLE_NAME = 'CLIENTP'

RRN  LOCK_STATE  LOCK_STATUS  JOB_NAME
  9  UPDATE      HELD         014827/SAKADM/SAISIECLI
  9  UPDATE      WAITING      014828/SAKADM/CHAINENUIT

Le journal de la chaîne confirme l'étape : les étapes 1 et 2 sont terminées, la 3 a été lancée et ne s'est jamais terminée.

Deux minutes plus tard : MSGW et RNQ1218

Le délai d'attente d'un enregistrement est celui du fichier : le paramètre WAITRCD de CRTPF ou CHGPF, 60 secondes par défaut, 120 pour notre CLIENTP. Le délai écoulé, la base de données refuse la lecture (CPF5027), le programme RPG n'intercepte pas l'erreur, et le travail passe en MSGW :

L'option 7 (afficher le message) montre la question posée :

Avant de répondre, F10 affiche l'historique du travail. Il nomme le coupable en toutes lettres, sans avoir besoin de DSPRCDLCK :

Débloquer et relancer

L'ordre compte : d'abord libérer l'enregistrement, ensuite répondre. Répondre R tant que le verrou est tenu ne fait que relancer la lecture, qui attend de nouveau.

1. Faire libérer le verrou. Le mieux est de demander à l'utilisateur de quitter son écran. Sinon, arrêter le travail qui le tient, avec ENDJOB : ses modifications non écrites sont perdues, c'est une décision à prendre avec lui.
2. Répondre R au message : le programme refait le CHAIN et continue.

Le travail disparaît de QBATCH : la chaîne est allée au bout. Le journal montre les sept étapes, avec 2 min 32 s entre le lancement et la fin de l'étape 3, le temps du blocage :

Nous avons comparé les encours des clients à ceux d'une exécution sans blocage : identiques. La réponse R n'a rien perdu ni rien compté deux fois, parce qu'elle reprend la même lecture, au même endroit.

Et si l'on avait répondu C ?

Le programme NUIT03ENC aurait été annulé alors qu'il avait déjà ajouté à l'encours les commandes des clients 1 et 2. Relancer la chaîne depuis le début ajouterait ces commandes une seconde fois. Une chaîne bien conçue prévoit donc une reprise par étape (repartir de l'étape 3, et savoir lesquels de ses enregistrements sont déjà traités), ou travaille sous contrôle de validation pour annuler proprement une étape interrompue.

Et si le verrou est libéré pendant l'attente ?

Nous l'avons vérifié : verrou libéré alors que la chaîne était encore en LCKW, elle est repartie seule, sans message et sans intervention, et s'est terminée normalement. Le MSGW n'arrive que si l'attente dépasse le WAITRCD.

Éviter que la chaîne reste en MSGW

• Intercepter l'erreur dans le programme : chain(e) cdcli CLIENTP; puis if %status(CLIENTP) = 1218; pour décider soi-même : réessayer quelques fois, écrire l'incident dans le journal, passer au client suivant ou arrêter la chaîne proprement avec un message clair.
• Régler le délai : CHGPF FILE(BIB/CLIENTP) WAITRCD(…), ou OVRDBF … WAITRCD(…) dans le CL de la chaîne pour ne changer que son attente.
• Choisir le moment : une chaîne qui met à jour les clients ne devrait pas tourner pendant que les utilisateurs les modifient.
• Prévoir la reprise : un journal d'étapes comme JOURNP dit où repartir ; un pilote qui accepte une étape de départ évite de tout relancer.
• Surveiller : en SQL, QSYS2.ACTIVE_JOB_INFO filtré sur JOB_STATUS IN ('MSGW', 'LCKW') repère les travaux arrêtés avant que quelqu'un ne s'en plaigne.

Questions fréquentes