Fin

Comment debuger des applications Iseries avec WDS client ou RDI

Pour commencer , ouvrez la perspective debogage

puis choisissez

ce qui vous affiche tous les types de debug possibles depuis cet outil

Dans l'ordre, pour iseries, nous avons : Lancement d'un thread dans le job serveur de RSE Lancement du pgm dans la session ayant passé STRRSESVR Soumission d'un job qui appel le pgm à deboger Debogage d'un travail existant (on passe implicitement la commande STRSRVJOB)

• Pour les trois premiers cas
  
  Indiquez le programme à déboger
  
  
  Et la commande de lancement
  
  
• Pour déboger un travail Iseries existant
  
  Indiquez en plus les coordonnées du job
  
  Mais, vous pouvez lancer tout cela plus simplement, à partir de RSE, en cliquant sur un programme ou un programme de service

Résulat :

1. le programme est lancé
2. WDSc a mis un point d'arrêt sur la première instruction exécutable

Pour une exécution Batch, nous voyons bien les coordonnées du JOB soumis


Ainsi que pour une exécution interactive ou vous avez passé la commande STRRSESVR


D'ailleur, dans la session 5250, nous verrons des messages d'information

Pour un job existant, le plus simple est d'afficher la liste des job depuis RSE

ce qui lance la perspective Debug, qui vous affiche :

Attention, par défaut vous lancerez le même programme que lors de votre dernier DEBUG

pour éviter cela, il faut reprendre cette option

renseigner le programme

et cliquer sur Appliquer (le bouton Déboguer relance la commande STRSRVJOB)

ensuite, lancez le programme depuis le travail en question, ce qui vous affiche :

Si le source n'est pas sur la machine ou a été renommé, vous verrez

• Editer le chemin de recherche permet d'indiquer les coordonnées du source (éventuellement sur un autre machine)
• Changer le fichier texte, permet d'indfiquer comme source un fichier texte local
• Afficher *STATEMENT permet de basculer vers la vue *statement (si celle ci a été demandée à la compil), plutôt que *SOURCE : c'est bien moins pratique !

regardons l'édition du chemin de recherche...

il faut ajouter un chemin (le chemin par défaut correspond à la compilation)

puis choisir Fichier Sources I5/OS (répertoire du système de fichier si vos sources sont dans l'IFS, suivant le langage)

et indiquer

1. le système
2. La bibliothèque (prenez Gérer des bibliothèques pour travailler hors *LIBL)
3. le fichier source (pas le nom du membre)

et c'est parti.

L'utilisation du produit, ensuite, est assez simple :

un clic sur la marge grise permet de gérer les points d'arrêt (je mets / j'enlève)

ou bien un clic droit directement sur la ligne source

A noter l'option Editer, permettant de lancer LPEX et ainsi d'obtenir la vue structure (liste des déclarations)

Un point d'arrêt de contrôle, est une alerte liée au changement de contenu d'une variable.(un watch)

Une fois vos points d'arrêt posés, vous pourrez les voir dans la fenêtre en haut à droite, vue Points d'arrêt.

Vous pourrez aussi les gérer par :

Editer le point d'arrêt, permet de modifier le numéro d'instruction

et les conditions d'arrêt

Surveiller l'expression
  affiche le contenu de certaines variables

toujours dans la fenêtre du haut (vue Moniteurs)

ces variables peuvent être

• modifiées
• affichées partiellement ou en Héxa.
• 

le programme est toujours arrêté sur la première instruction exécutable. Pour avancer ,
utilisez la barre d'outils :

• reprend l'exécution du programme jusqu'au prochain point d'arrêt
• fait une pause
• stop le programme
• déconnecte et supprime de l'affichage tous les debug terminés.
• faits du pas à pas
  • le premier en s'arrêtant sur les "points d'entrée de service"
  • le deuxième, ne s'arrêtant pas sur les appels (sauf point d'arrêt).
• ici, on avance jusqu'à la prochaine instruction "débugable"
• et ici, jusqu'à l'instruction de retour de la fonction

Vous pouvez aussi, cliquez sur une ligne source et demander

Vous pouvez aussi demander un point d'arrêt à la ligne ou quand une variable change de contenu

Enfin, si votre programme fait un appel (CALL ou fonction ILE), demandez la liste des modules

Vous pourrez ainsi faire apparaître les sources qui vous intéressent afin de gérer les points d'arrêt.

Enfin, la version 6 vous propose une option très,très pratique : Entrée de service, uniquement sur les programmes ILE

pensez au préalable à indiquer vos préférences de debug, particulièrement la mise à jour des fichiers de production

Il s'agit ensuite, de définir un nom de programme et un nom d'utilisateur. La prochaine fois que cet utilisateur lance ce programme, le debug aura lieu :

1. Choisissez un programme (ILE uniquement) dans une liste d'objets et indiquez Déboguer (entrée de service)
   
   
   
2. La vue des Entrées de service s'affiche, vous pouvez modifier les paramètres (dont l'utilisateur)
   
   
   
   
3. Au lancement du programme par l'utilisateur indiqué, quelque soit le contexte (Interactif, JAVA/PHP, etc ...), vous êtes en debug
   
   ici CLI sous Zend Core(PHP) a lancé le programme.

Enfin, en Version 7, le Debug est possible sur un travail en attente de message (MSGW)

• localisez le travail en question avec l'option Travaux iSeries
  
• lancez déboguer (avec invite), sans invite le debug est lancé sur le même programme que la dernière fois (??)
  
  Ajoutez le programme que vous voulez déboguer (celui qui est actif)
  
  Il faut que ce dernier soit un ILE, compilé avec dbgview(*source)
  
  
• le debug est lancé
  
  
  vous avez accès à :
  • la liste d'invocation, en haut à gauche
  • la liste des variables avec le contenu, en haut à droite (ici un CLLE)
    

Début

©AF400