> Tech > Attention! Méthode de Bugbuster

Attention! Méthode de Bugbuster

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Jeremy Likness
Les vrais professionnels analysent les problèmes de manière exhaustive avant de recourir au débogueur ILE. Les informaticiens professionnels chargés de repérer et d'éradiquer les bogues ont une priorité : éliminer les problèmes techniques aussi rapidement que possible. Par conséquent, ils ont tendance à  s'en remettre énormément au débogueur ILE RPG. Mais, éradiquer des bogues sur un AS/400 représente bien plus qu'une simple question de commodité. Une bonne stratégie de déboguage implique au moins une part d'analyse manuelle des données et/ou du code source afin de déterminer exactement comment un bogue a pu se glisser entre les mailles du filet. Il est également recommandé de conduire des opérations de suivi afin d'identifier et d'éliminer tout problème potentiel révélé par le processus de déboguage.

En adoptant une stratégie de déboguage exhaustive plutôt qu'une approche de type "le plus rapidement possible", on améliore sa maîtrise de l'AS/400 et de son environnement applicatif. Fort de cette expertise, lorsque vous utiliserez effectivement le débogueur, vous gagnerez énormément de temps. Pour une introduction au "code de conduite de l'exterminateur de bogues averti", consultez l'encadré "Critters 101".

Dans le présent article, je fournis une méthode de base pour le déboguage des systèmes, et présente plusieurs ressources importantes. Pour de plus amples renseignements sur le déboguage sur AS/400, consultez les articles "ILE à  l'oeuvre : le débogueur", NEWSMAGAZINE, octobre 1997 et "Le déboguage des batchs sans peine", NEWSMAGAZINE, mai 1997.

Les informaticiens professionnels ont tendance à  s'en remettre énormément au débogueur ILE RPG

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.

Téléchargez cette ressource

SD-WAN de confiance : guide de mise en œuvre

SD-WAN de confiance : guide de mise en œuvre

Ce livre blanc décrit les différents aspects indispensables pour la mise en place d’une approche SD-WAN sécurisée et de confiance. Ce document s’adresse aux consultants et responsables sécurité des systèmes d’information pour bien comprendre les enjeux du Trusted SD-WAN à l’heure de la transformation numérique des entreprises.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT