Trucs, astuces et anecdotes

Les outils IBM

Un AS/400, comme un PC ou autres ordinateurs, comporte un minimum de SOFTWARE indispensable au fonctionnement général de la machine. Sur une machine de production, ce minimum s’accompagnera d’un logiciel de gestion qui, en théorie du moins, se suffit à lui même. Sur une telle machine on ne trouvera donc pas SEU, ni aucun compilateur d’aucune sorte, dans certains cas il n’y aura même pas de SQL.

La raison tient au fait que tous ces modules ne sont pas gratuits et qu’il serait inutile d’acheter des outils dont personne ne se sert.

Et pourtant, il est bien rare que l’on ne se retrouve pas obligé d’en avoir certains.

Lors du chargement des sous-fichiers, nous avons évoqué la possibilité de chargement par SQL. Sur la machine de développement SQL est bien là et tout se passe bien, mais lorsque vous passez le programme en production, s’il n’y a pas de SQL le programme ne fonctionnera pas.

Sans compter qu’il y a, même sur les produits les plus aboutis, toujours un risque d’erreur dans un fichier qu’il est absolument nécessaire de corriger au plus vite.

Plus compliqué aussi, j’ai rencontré dans un logiciel un outil intégré qui créait des tables de paramétrage de la manière suivante. On faisait une description des zones paramètres, type, longueur...

Le fichier plein qui est vide

Personnellement, j’évite d’utiliser les fichiers de travail pour un oui ou pour un non et ceci à cause de certaines mésaventures pouvant survenir.

Dans la plupart des cas l’opération se déroule de la façon suivante dans un CL :

0044.01              CRTDUPOBJ  OBJ(FIC00P) FROMLIB(*LIBL) OBJTYPE(*FILE) +
0044.02                           TOLIB(QTEMP)
0044.04              OVRDBF     FILE(FIC00O) TOFILE(QTEMP/FIC00P)
0044.05              CALL       PGM(PGXX01) PARM(&PARM)
0044.06              CALL       PGM(PGXX02) PARM(&PARM) 

Premièrement, on crée une copie du fichier dans QTEMP, puis OVRDBF afin que les programmes qui suivent voient le fichier de QTEMP qui est vide, du moins au début.

Le programme PGXX01 écrit dans le fichier de travail FIC00P et le programme qui suit lit ce fichier de travail et dans ce cas tout se passe bien. Quelques mois plus tard, il s’avère qu’il est nécessaire de rajouter un petit module, utilisant lui aussi FIC00P et qu’on ne peut le mettre qu’à la fin du programme PGXX01 pour cause de paramètres nécessaires.

Et c’est là que les ennuis commencent. En effet, alors que tout allait pour le mieux jusque-là, il semble que le module intercalaire ne voie jamais qu’un fichier vide dans QTEMP et donc, ne fasse rien de ce qu’on attend de lui. Perplexe, notre développeur se lance dans une multitude de débogages en se demandant...

Un exemple à ne pas suivre

J’ai personnellement vu trop souvent des programmes mal conçus avoir des temps de réponse rédhibitoires. Un des cas le plus symptomatique était un programme qui tournait toutes les nuits pour sortir des états comptables tous les matins. Le jour où l’ingénieur d’exploitation m’a expliqué que le programme était lancé vers 7 heures du matin et que, depuis quelques jours, les états comptables ne sortaient que vers 10 heures, je me suis dit que je risquais d’en avoir pour un bon moment à résoudre le problème. En fait, il s’agissait d’un bon logique, mais mal utilisé. Le fichier augmentait d’environ 1 000 enregistrements par jour. Le programme d’extraction utilisait environ une centaine d’enregistrements pour les données comptables et renseignait une date de traitement de façon à ne pas réutiliser le lendemain les enregistrements extraits le jour même. Pour réaliser ce projet, le programmeur avait utilisé un logique d’exclusion, c’est-à-dire qui ne voit que certains enregistrements. Dans ce cas c’était la date et le logique ne voyait que les enregistrements dont la date était à zéro. Si la date était à zéro (enregistrement non traité), le programme testait...

Supprimer des fichiers inutiles

Il devait être environ 15 heures lorsque l’ingénieur système m’annonce froidement : "Il y a un problème grave, il y a une bibliothèque qui est pleine à ras bord". C’était du temps où les bibliothèques ne pouvaient contenir que 32 766 objets, sur un PC on peut mettre 2 gigas d’objets, que ce soit fichier, répertoire, programme ou autre. Bref, pour cause d’un programme facétieux qui créait un physique et deux logiques toutes les cinq minutes, la bibliothèque avait atteint le seuil critique. Après quelques recherches j’ai tapé la commande DLTF BIBDTA/FICX*. Tous les fichiers en question et eux seuls commençaient par FICX, j’ai donc fait [F4] pour voir, et là j’ai vu que je pouvais soumettre la suppression. La machine étant sur le point de rendre l’âme et pour éviter d’envenimer la situation, j’ai fait [F19] comme suggéré et ce fut l’effet papillon. Je pensais, à tort, que la machine allait soumettre globalement un seul JOB de suppression. En fait, il y a eu quelque chose comme 20000 JOB soumis qui se sont mis en file d’attente dans QBATCH bloquant par là-même la plupart des impressions et autres intégrations pour une durée estimée d’environ 5 heures. Il a fallu...

Le JOB qui ne s’arrête jamais

Il y avait un bug bien sûr. Un peu subtil et qui ne se produisait que dans des circonstances particulières. C’était dans un dépôt, un préparateur devait flasher un code-barre pour valider une opération. Malheureusement, si un autre utilisateur voulait visualiser l’opération en question, le programme verrouillait l’enregistrement et le malheureux préparateur recevait un message "Tentative de suppression ou mise à jour sans lecture préalable". C’était d’autant plus stressant que le message en question n’apparaissait pas vraiment (un écran de pistolet-badgeur est minuscule). Donc il s’est dit, il doit y avoir un problème de réseau (les pistolets-badgeurs sont sans fil et il y a parfois des coupures), je vais éteindre et me reconnecter. L’ennui, et donc le bug, c’est que le programme, non seulement continuait de tourner, sans pilote, mais finissait par verrouiller à son tour l’enregistrement en question. Quand l’ingénieur système s’est demandé pourquoi cet utilisateur avait 15 sessions ouvertes qui se bloquaient toutes mutuellement, il s’est douté que quelque chose n’allait pas. Le problème a été résolu assez rapidement en "tuant" (KILL) toutes les sessions inutiles....

La boucle infinie

Par distraction, le programmeur a écrit la "boucle infinie" et, malheureusement, au milieu de cette boucle il y a l’écriture d’un enregistrement qui, bien sûr, ne crée jamais de clé en double. Si on a pris la précaution de laisser le fichier avec la limite des 10 000 enregistrements, au bout d’une seconde environ le programme passera à l’état *MSGW (ou *MSGATT), ce qui signifie attente d’une réponse dans la file d’attente.

Le message sera : La taille maximale du fichier FIC00P a été atteinte.

On peut choisir soit d’annuler (CANCEL) soit d’augmenter la taille d’un certain nombre d’incréments de 1000 (9999 au maximum).

Lors des tests, il est fortement recommandé de choisir l’annulation. En production, il est assez prudent de réfléchir avant d’augmenter la taille du fichier. S’il y a une anomalie dans le programme, le résultat peut être catastrophique dans les secondes qui suivent. L’AS/400 commence par ne plus effectuer les tâches jugées secondaires, envoi de mail, Internet, impressions, réseau local, afin de préserver le plus longtemps possible l’intégrité des données, une sorte de mise en hibernation progressive.

Garder en mémoire qu’un AS/400 actuel est capable de créer...

Le SQL à risques

Je tape la commande STRSQL… puis UPDATE et [F4] et je choisis le fichier à mettre à jour sans remarquer que j’avais choisi non pas le fichier de la base de test, mais celui de la production. Je lance la mise à jour en me demandant pourquoi c’est un peu long. Lorsque l’opération est terminée, je constate que je n’ai pas mis à jour la centaine d’enregistrements que comporte mon fichier de test, mais 6 000 enregistrements, c’est-à-dire tout le fichier du personnel.

Dernier cas de figure, il s’est passé quelque chose d’anormal dans la base, et du coup plus rien ne fonctionne. Par exemple, le fichier du personnel a été modifié par erreur. Avant de rechercher le coupable, il s’agit de restaurer les données. La modification était mineure. Un programme tout neuf faisait la lecture de la base pour mettre à jour le fichier des adresses, malheureusement il y avait un bogue dans le programme. Ce bogue n’avait pas été remarqué lors des tests. Dans un cas particulier il faisait l’inverse de ce qui était prévu, il remplaçait le matricule par le code mail (dans l’environnement de test ces deux codes étaient identiques et donc personne n’avait remarqué le problème).

Il y avait bien sûr la possibilité de récupérer...

La haute disponibilité

Dans les cas précédents, on utilisait la journalisation afin de récupérer des données corrompues, mais il y a une autre utilisation qui détourne la journalisation pour faire ce qui se nomme pompeusement, la Haute Disponibilité.

J’ai donc un AS/400 dans un local assez sécurisé, avec des sauvegardes quotidiennes. J’ai même prévu de mettre mes sauvegardes ailleurs que dans le local AS/400. Hélas, et bien que la machine soit assez robuste, elle n’est pas à l’abri de tout. Et vers 15 h ce jour-là, une vanne rend l’âme et répand des dizaines de litres d’eau juste à l’aplomb de la machine. Bien sûr, j’ai un contrat d’assistance qui prévoit le remplacement de la machine dans les 3 heures. Il faudra aussi compter 2 heures pour l’IPL et pour restaurer les données. En clair, j’ai une journée de production de perdue. Sur un AS/400, il n’est pas rare que le travail de 1 000 personnes dépende entièrement du bon fonctionnement de la machine. Je laisse le soin aux experts d’évaluer le coût d’un pareil incident, mais à coup sûr les conséquences financières seront assez élevées.

Pour pallier ce genre de mésaventure, il y a une méthode basée...

La clé en double (bis)

Un mail arrive m’expliquant qu’il y a encore une clé en double, cauchemar récurrent du programmeur sur AS/400. J’examine le travail, je cherche la cause de l’erreur en relisant les sources des programmes, et rien. Le programme en cause faisait une lecture honnête et si l’enregistrement n’était pas trouvé, le créait dans la foulée. Pas de bug apparent, d’autant plus incompréhensible que ce programme fonctionne depuis plus de 4 ans sans aucune anicroche. Et pourtant, il y avait eu clé en double. C’est là qu’il faut aller fouiller au plus profond des JOBLOG. L’investigation a pris une dizaine de minutes avant de trouver une explication. En fait, il y avait deux JOB qui écrivaient le même enregistrement, un en interactif, l’autre soumis. Celui qui s’était planté était le JOB soumis. Bien que ce ne soit que pure hypothèse, la déduction a été la suivante. L’interactif soumet le job, ensuite il écrit l’enregistrement incriminé, pendant ce temps le job soumis cherche si l’enregistrement en question existe, et à ce moment-là l’interactif n’a pas encore écrit dans le fichier, le BATCH prépare donc la création de l’enregistrement. Entre-temps, l’interactif a écrit...