Suite à un échange que j’ai eu avec le support d’un éditeur, il m’a semblé opportun de faire une piqûre de rappel sur la dette technique.
J’interviens un jour par semaine pour ce client, pour faire essentiellement de la bobologie. Pas de sachant sur IBMi en interne.
Autant dire que nous sommes sur un dispositif très léger, reposant sur les bons réflexes des utilisateurs, qui pour un utilisateur, sont de pouvoir continuer à travailler lors de problèmes et non d’attendre de la disponibilité d’un intervenant externe… pas toujours disponible ! Ils apprennent à se débrouiller seuls, avec par moment de choix qui ne sont pas les meilleurs, d’un point vue informatique, mais ça ce n’est pas leur métier.
Mais place à l’histoire du client, de l’éditeur et de l’informaticien, que je vous conte…
En l’an 2025, par un joli mois d’août, le client profite d’un repos amplement mérité.
L’informaticien, malicieux, profite de ce temps pour mettre à jour l’OS, et installer une nouvelle version d’un logiciel corrigeant quelques petits problèmes. L’éditeur fort content de son logiciel mis à l’honneur, prépara un package aux petits oignons, et une procédure irrépprochable.
L’informaticien, plein d’entrain, et galvanisé par une mise à jour d’OS optimum, monte la nouvelle version du logiciel, en suivant scrupuleusement la procédure, redémarre le logiciel fait un test unitaire… Et badaboum ! Ca ne marche pas. Fort chafouin, il contacte l’éditeur qui espiègle, lui explique qu’en effet cette version est identifiée comme non fonctionnelle, mais qu’il a dans sa besace, une nouvelle merveille, qu’il se fait fort de packager et de mettre à disposition, avec diligence.
Rassuré par autant de dévouement, l’informaticien récupère la nouvelle nouvelle version, suit la procédure et à la fin de l’installation, lance son test unitaire… Et Oh ! Miracle de l’octet ! Tout fonctionne.
Les nuits de la fin du repos estival du client s’enchaînent, et plan de prod après plan de prod, tout va pour le mieux dans le meilleur de monde.
Le client rentre, frais et dispo, prêt à recommencer son activité, et se pâmer devant son SI actualisé !
Le client, l’éditeur et l’informaticien vécurent heureux pendant une belle et longue année, jusqu’à la prochaine montée de version…
FIN.
Sauf que mi-septembre…
Apparition de verrouillages sur un fichier du logiciel qui disparaissent avant de pouvoir analyser.
Le problème dure plusieurs jours, de manière assez fugace, j’ouvre un incident au support du logiciel. Support qui est, d’expérience, aux affaires, réactifs, et qui connait bien son logiciel.
Le lendemain, le logiciel est « bloqué », par le verrouillage. Après recherche, je trouve une session utilisateur en message wait pour un débordement de fichier, le fichier du verrouillage.
Je réponds au message, par incrémentation, le job se termine, les verrouillages disparaissent.
Je regarde l’objet de plus prêt :
- fichier dds
- nombre d’enregistrements :
- nb initial : 10 000
- incrément : 1 000
- nb incréments : 3
- CCSID : 65535 au niveau fichier et sur tous les champs Alpha, rien à voir avec le problème, mais on en reparle avant la fin !
Sur le support de l’éditeur, je demande par courtoisie, si je peux passer la taille du fichier en *NOMAX.
Voici la réponse :
Je regarde dans le fichier concerné, son contenu et je me rends compte qu’il contient :
- 1 an d’historique
- 1 300 enregistrements sur 11 mois
- 12 700 enregistrements en 1 mois
- Fichier contenant des mails, avec par conséquent des champs adresse mail –> CCSID, on en reparle !
Suite à mise en place de la nouvelle version, j’ai un facteur 110 sur le nombre de création d’enregistrements dans la table. Grosse maille !
Je m’enquiers auprès du support s’il y a eu un changement de la gestion de cette table avec la nouvelle version.
Le support me confirme que le fichier est devenu un historique.
On est sur un logiciel d’éditique, on peut considérer que le nombre de mails envoyé sera conséquent.
Nous avons donc un fichier à taille fixe, qui passe d’un usage faible à un usage d’historique avec fort volume, mais sans modification de la taille du fichier.
Je pensais en avoir fini, il y a longtemps, avec ce type de bug !
Ce qui me gêne :
- Modification de l’usage d’une table sans modification de sa taille
- Le support qui donne une réponse avec les préconisations d’IBM… datant des années 90 en 2025 !
- Un bug qui n’aurait jamais eu lieu si les préconisations IBM avait été prises en compte : table SQL, taille en *nomax par défaut en SQL et reusedlt(*yes), par défaut en SQL.
Plus généralement dans notre écosystème, hormis les éditeurs de devops, pour qui l’évolution technique est le fond de commerce, nous rencontrons encore beaucoup d’éditeurs qui rechignent à faire évoluer techniquement leur logiciel.
Je trouve ça dommage, et contre productif. Surtout que dans ce cas, on ne parle pas d’un changement de préconisation récent, mais d’un changement qui date d’une vingtaine d’année. Ca laisse un peu de marge pour s’adapter, voir évoluer de manière opportuniste, version après version.
C’est le même problème pour le CCSID, quand je vois un fichier d’un logiciel d’éditique contenant forcément des caractères à transcoder, à minima le @ des adresses mails, en 65535, je suis dépité. Quand on fait un audit sur le CCSID chez un client et que ce genre de résultat sort, c’est compliqué… Pour rappel, le CCSID est apparu et avec lui le 65535, en V2R11. Le 65535 devant être transitoire.
Nous sommes dans un métier technologique, le matériel, le système d’exploitation, les technologies évoluent. Il est normal que les préconisations IBM prennent compte de ces évolutions et s’ajustent dans le temps.
Nous (sociétés de conseil, éditeurs), les spécialistes, avons obligation de prendre en compte ces évolutions dans nos discours, nos développements, nos livrables.
Pour rappel les préconisations principales sur la base de données d’IBM :
- Passer en SQL – pour la création de la base de données comme pour son utilisation. Très impactant à reprendre. Par contre, à rendre obligatoire sur toutes nouvelles tables et/ou programmes.
- Taille des fichiers *nomax – on peut le faire même avec des fichiers DDS, il faut juste ajouter une alerte sur le remplissage disque, s’il n’y en a pas déjà !
- En SQL, valeur par défaut
- En DDS, CRTPF ou CHGPF mot clé SIZE, par défaut 10 000 / 1 000 / 3
- Réutilisation de l’espace des enregistrements supprimés – Reusedlt – à *YES. C’est modifiable là aussi par un CHGPF – Ca évite de devoir faire des réorganisations de fichiers.
- En SQL, valeur par défaut
- En DDS, CRTPF ou CHGPF mot clé REUSEDLT, par défaut *NO
- Passer la taille page logique des chemins d’accès à 64
- En SQL, valeur par défaut
- En DDS, CRTLF mot clé PAGESIZE, par défaut *KEYLEN soit, généralement, 8 KiB au lieu des 64. Sur la V7R6, les valeurs 8 et 16 sont gardées pour la compatibilité, mais réinterprétées en 32 par l’OS.
- Ajout des index conseillés par l’index advisor, même si vous êtes encore sur des fichiers DDS.
- Ajouter les contraintes sur la base de données. Très impactant et à commencer sous forme d’audit. Comme pour le premier point, à rendre obligatoire sur toutes nouvelles tables.
Dans ces préconisations, il y a des actions qui nécessites de la prudence et du temps, transformation DDS en SQL, ajout de contraintes sur la base de données. Mais d’autres sont faciles, peu gourmandes en temps et sans risque, il n’y aucune raison de ne pas le faire !
