Attention! Méthode de Bugbuster

Un des premiers endroits où fouiller lorsqu’on recherche des bogues, c’est les
fondations, c’est-à -dire, les fichiers base de données de l’AS/400. Une base de
données se doit d’être bien organisée. De plus, elle doit respecter des standards
clairement définis et le suivi de son intégrité doit être assuré par un responsable
clairement identifié. Un analyste-programmeur ne devrait avoir aucun problème
pour apprendre à  définir de nouveaux fichiers et à  intégrer ces derniers à  l’ensemble
du système.

Quatre types de fichiers associés aux bases de données fournissent des mécanismes
permettant d’identifier et d’exterminer les bogues sans jamais avoir à  analyser
le code du programme source à  proprement parler :

Les journaux. Les journaux constituent la première
ressource à  exploiter pour traquer les problèmes rapidement et avec précision.
Souvent, les utilisateurs et les éditeurs sont incapables de fournir avec précision
des informations vitales, telles que les données qu’ils viennent juste de taper,
ou l’écran qui était affiché juste avant que ne survienne un problème. Mais en
ce qui concerne les journaux, ils ne mentent jamais.

En utilisant un journal, on peut identifier avec précision le programme qui a
provoqué le dysfonctionnement d’une requête en la plaçant dans un état invalide.
Par exemple, un programme qui supprime un enregistrement client important, peut
déclencher son identificateur de cycle de validation qui, à  son tour,peut mener
au programme original sur la pile d’appel ayant déclenché l’ensemble du processus.
(Un cycle de validation est le laps de temps qui s’écoule entre le moment où un
ensemble de mises à  jour d’une base de données est effectué et le moment où ces
modifications sont soit confirmées de façon définitive par une instruction commit,
soit annulées). En outre, si un utilisateur modifie incorrectement ou détruit
des données précieuses, on peut facilement les restaurer à  l’aide de commandes
associées au fichier journal.

S’attaquer à  un problème relatif à  la production sans disposer d’un fichier journal
équivaut à  essayer d’anéantir une invasion de termites en piquant chaque termite
avec une épingle. Et pourtant, de nombreuses entreprises n’utilisent pas les journaux
de peur de dégrader les performances de leurs systèmes ou du coût supplémentaire
que cela induirait pour les unités de stockage. Je me demande combien de ces entreprises
ont effectivement mené des tests pour évaluer les effets qu’auraient réellement
l’activation des fichiers journaux sur les performances du système et sur les
besoins de mémoire de masse nécessaires.

Les fichiers en entrée. Certaines données sont
saisies par les utilisateurs, et sont de ce fait difficiles à  tracer. En revanche,
la plupart des applications dialoguent avec un fichier ou un autre. Pour visualiser
la liste des fichiers en entrée requis ou utilisés par un programme donné, vérifiez
le code source ou utilisez la commande DSPPGMREF (Display Program References).
Ensuite, validez les informations contenues dans ces fichiers. Remontez les opérations
à  la trace pour identifier les données affichées avant que le problème ne se produise.

Les fichiers en sortie. Comme des sillons dans la neige
(ou les empreintes laissées par les cafards), un fichier en sortie peut aider
à  identifier des données défectueuses. Comparez les données contenues dans votre
fichier en sortie aux données contenues dans les fichiers en entrée. Y a-t-il
des champs qui manquent ? Y aurait-il des calculs qui seraient inexacts ? Un enregistrement
particulier n’aurait-il jamais été écrit ? Remontez tout problème que vous aurez
identifié au programme ayant généré le fichier de sortie et vous isolerez le problème.
Accessoirement, les rapports imprimés et les fichiers générés en sortie peuvent
également identifier la section d’un programme qui pose problème.

Les mises à  jour. Il arrive quelques fois que les utilisateurs
génèrent des bogues en manipulant par erreur un champ clé ou en mettant à  jour
un enregistrement qu’ils n’auraient pas dû modifier. Pour vérifier les mises à 
jour des données effectuées, utilisez la commande DSPJRN (Display Journal) sur
la base de données afin de vérifier quand et comment les enregistrements ont été
altérés.