> Tech > Analyse, sécurité et débogage en ILE

Analyse, sécurité et débogage en ILE

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

Retour sur les solutions en mode LAN, RPG, sous forme de Questions/Réponses posées aux experts de la rédaction.

Bases de données et commandes, au menu de ce trucs et astuces spécial System i. Des solutions pour l'administration et l'optimisation des infrastructures.

Analyse, sécurité et débogage en ILE

Q : Je suis programmeur RPG/400, un produit que j’ai connu à l’ère du débogage interactif. Je n’ai jamais été très à l’aise avec les anciens programmes de débogage et comme nous passons à ILE RPG, je constate que c’est mon seul choix. Est-ce vrai ?

R : Vous faites allusion à l’ancien débogueur qui fonctionnait ainsi : on le démarrait, on définissait un point de rupture avec la commande ADDBKP, et il fallait avoir un listing de compilation sous la main pour voir quelle ligne de code le programme était en train d’exécuter. Dans l’une des releases V2 (j’ai oublié laquelle), IBM a inclus le débogueur source interactif (ISDB, Interactive Source Debugger) que l’on pouvait utiliser sur les anciens programmes RPG pour visualiser la source directement sur l’écran. ISDB est certes utile, mais il n’accepte pas tous les langages du System i.

En particulier, il n’accepte aucun des langages ILE ou Java : seulement OPM CL, RPG et Cobol. A partir de l’OS/400 V3, IBM a élevé la commande STRDBG pour qu’elle soit un débogueur interactif également. Contrairement à ISDB, elle fonctionne avec tous les langages qui tournent sur le System i, y compris tous les langages ILE, les langages OPM (le Original Program Model qui précédait ILE), et même Java. Pour couronner le tout, on peut les traiter tous en même temps. Par exemple, supposons un programme CL OPM qui appelle un programme ILE. La procédure principale du programme ILE est écrite en RPG IV mais elle appelle des modules supplémentaires écrits en C et Cobol. A l’aide de la touche D22, vous pouvez entrer dans chacun des programmes et modules au moment où ils sont appelés, en passant d’un langage à un autre au fur et à mesure que le code s’exécute.

C’est une fonction très utile ! Pour valider le débogage interactif de vos programmes, vous devez spécifier une vue de débogage quand vous la compilez. Vous spécifiez la vue de débogage à l’aide du paramètre DBGVIEW sur n’importe quel compilateur ILE. La liste suivante explique les valeurs disponibles : DBGVIEW(*STMT) – C’est le paramètre par défaut. Il n’inclut que les numéros d’instructions dans la vue. Avec cette option, vous ne pourrez pas déboguer vos programmes interactivement. DBGVIEW(*SOURCE) – Ce paramètre permet au débogueur de visualiser le membre source de votre programme quand vous le déboguez. Le résultat ainsi obtenu ressemble beaucoup à celui de ISDB.

L’inconvénient est que si le code source est modifié, on risque des résultats incorrects. De plus, quand votre objet programme est déplacé dans le système de production, vous ne disposerez peut-être pas du membre source, ce qui peut être ennuyeux. DBGVIEW(*LIST) – Une copie du listing de compilation est imbriquée dans votre objet programme. Quand le débogueur visualise votre programme, il utilise cette liste de compilation au lieu de visualiser le membre source.

Ainsi, si la source est modifiée ou indisponible, vous pouvez quand même déboguer le programme. C’est l’option que j’utilise et que je préconise. DBGVIEW(*ALL) – Accomplit tout ce qui précède. Bien sûr, le point faible de DBGVIEW(*LIST) est qu’il occupe davantage d’espace disque parce que le listing de compilation doit être inclus dans l’objet programme lui-même. D’après mon expérience, c’est sans importance.

Sur chaque System i que j’ai vu, les fichiers base de données constituent la plus grande partie du disque utilisée. Le code programme occupe très peu d’espace, et le fait d’augmenter la taille des objets programmes ne fait pas une grosse différence. Si la quantité d’espace disque représente une grande différence dans votre cas, n’oubliez pas que les lecteurs de disque dur sont plutôt bon marché. Un programmeur gaspillant 15 heures par an parce que son source est désynchronisé coûtera plus cher que l’extension disque. Si je ne vous ai pas convaincus d’utiliser DBGVIEW(*LIST), vous pouvez continuer à employer DBGVIEW(* OURCE) pour utiliser la commande STRDBG interactivement sans souci de gaspiller de l’espace disque supplémentaire. Vous pouvez déboguer des programmes OPM interactivement avec STRDBG.

Vous devez compiler ces programmes avec OPTION(*SRCD BG) ou OPTION(*LST DBG) pour valider cette fonctionnalité. Ces options sont analogues à DBGVIEW (*SOURCE) et DBGVIEW(*LIST), respectivement. Après avoir compilé votre programme avec la vue de débogage appropriée, vous pouvez lancer le débogueur en tapant la commande suivante : STRDBG PGM(myProgram) Ou, pour un programme OPM, tapez : STRDBG PGM(myProgram) OPMSRC(*YES)

Après quoi, le débogueur instaure l’environnement de débogage et montre le code source de votre programme sur l’écran. La figure 1 montre l’écran que j’obtiens en procédant ainsi. Vous pouvez feuilleter le source et insérer des points de rupture là où vous voulez que le programme s’arrête. Appuyez sur les touches F10=Step ou F22=Step Into pour lui ordonner de s’arrêter sur la prochaine instruction exécutée. La différence entre ces touches (Step et Step Into) se manifeste quand un programme ou une sous-procédure est exécuté(e).

La fonction Step ne montrera pas le code de la sous-procédure ou du programme au moment de son exécution, mais continuera la progression avec la ligne suivante de la routine dans laquelle vous vous trouvez. En revanche, Step Into progressera ligne par ligne dans la routine appelée également. Appuyez sur la touche F14 pour passer d’un module à un autre dans le programme ou pour ajouter d’autres modules ou programmes au débogueur, afin de pouvoir y glisser aussi des points de rupture. Une fois les points de rupture établis, appuyez sur F12 pour continuer. Cette man?uvre vous fera sortir de l’affichage source interactif et vous ramènera à la ligne de commande.

Contrairement à ISDB, votre programme ne s’exécutera pas automatiquement. Il faudra l’exécuter à partir de la ligne de commande, par la commande CALL. Au terme du débogage, utilisez la commande ENDDBG pour sortir du mode de débogage. Par ailleurs, s’il faut recompiler le programme, mettez fin au débogueur avec ENDDBG et redémarrez-le avec STRDBG. Vous aurez ainsi la certitude que la nouvelle copie du programme sera chargée dans le débogueur.
Scott Klement 

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

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