> Tech > Le débogueur graphique rend le débogage de SQL Procédural encore plus facile

Le débogueur graphique rend le débogage de SQL Procédural encore plus facile

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

par Kent Milligan - Mis en ligne le 31/03/2004

La fonction V5R2 permet d'exterminer ces maudits bogues plus rapidement que jamais

DB2 UDB a simplifié le débogage des procédures de fonctions et triggers SQL en V5R2, avec la vue de débogage SQL *SOURCE...Mais vous pouvez simplifier encore davantage le débogage des procédures et triggers SQL à  l'aide d'une autre fonction V5R2, le Toolbox for Java iSeries System Debugger. Voyons ces deux nouvelles améliorations V5R2 (et le support équivalent en V5R1) et comment les utiliser ensemble.

Le débogueur graphique rend le débogage de SQL Procédural encore plus facile

Les procédures SQL ont utilisé le code
C en coulisse, depuis leur première introduction
en V5R2. Le code C ne pose
pas de problèmes aux programmeurs RPG et Cobol tant qu’ils n’ont pas besoin
de déboguer une procédure,
fonction ou trigger SQL. Au lieu de
montrer les instructions procédurales
SQL d’origine, le débogueur iSeries (la
commande STRDBG, ou Start Debug
montre le code C généré qui est utilisé
pour mettre en oeuvre les instructions
procédurales SQL d’origine.
La figure 1 montre la source d’une
instruction de procédure SQL dans le
nouveau débogueur, et la figure 2
montre la vue de débogage de type C
que les programmeurs étaient obligés
d’utiliser avant la V5R2.
Avec l’arrivée de la vue de débogage
*SOURCE en V5R2, les programmeurs
ont le moyen de travailler avec
du code source SQL original en mode
débogage au lieu du code C complexe
généré par DB2. On peut créer la vue de débogage SQL *SOURCE de deux
manières. L’une consiste à  spécifier l’option
debug dans la source de la procédure,
fonction ou trigger SQL. Comme
le montre la figure 3, on fait cela en indiquant
DBGVIEW= *SOURCE sur la
clause SET OPTION. Une autre méthode
consiste à  spécifier une valeur
*SOURCE pour le paramètre DBGVIEW
sur la commande CL RUNSQLSTM (Run
SQL Statements).

Avec la vue de débogage *SOURCE
spécifiée, DB2 UDB crée une vue de débogage
au niveau source SQL supplémentaire
au moment où elle génère le
programme C. (Ce changement est très
récent. Avec le support V5R2 original, la
vue de débogage au niveau source SQL
était toujours stockée dans QTEMP.)
Seul le job qui a créé la procédure, fonction
ou trigger SQL pourra utiliser la vue
de débogage *SOURCE. Une fois ce job
terminé, la prochaine session de débogage
de l’objet SQL utilisera la vue de
débogage du listing C normale, et pas la
vue de débogage au niveau source SQL.
Bien que cette restriction semble sévère,
elle est adoucie par le fait que
iSeries Navigator permet très facilement
de recréer une procédure, fonction ou
trigger SQL existant avec la vue de débogage
*SOURCE. Par un simple clic
droit sur l’un de ces objets SQL dans
iSeries Navigator, on peut choisir la
tâche Generate SQL pour extraire le
code source SQL et le déposer dans un
membre de fichier source OS/400. La
commande RUN SQLSTM peut ensuite
utiliser ce membre de fichier source
pour créer la procédure SQL et rendre
la vue de débogage *SOURCE disponible
pour votre job.
Depuis peu, il est possible via les
PTF V5R1 et V5R2 de stocker la vue de
débogage *SOURCE dans une bibliothèque
permanente. Avec ces PTF, si le
nom de la procédure, du trigger ou de
la fonction est qualifié avec un nom de
bibliothèque, la vue de débogage
*SOURCE est stockée dans la bibliothèque
spécifiée. Si le nom de la bibliothèque
n’est pas spécifié, la vue de
débogage *SOURCE sera créée dans
QTEMP.
Le débogage au niveau source SQL
présente plusieurs autres nuances que
vous devez connaître. L’une est que les
commentaires ne sont pas sauvegardés
dans la vue de débogage *SOURCE.
Une autre est que quand vous défilez
dans la vue de débogage *SOURCE en
mode debug, le débogueur peut rester
sur la même instruction SQL pendant
plusieurs pas si l’implémentation de
cette instruction SQL nécessitait plusieurs
lignes de code C généré.
La dernière nuance concerne l’accès
à  la valeur des variables et paramètres
SQL pendant la session de débogage.
Vous utilisez encore la
commande EVAL, mais vous devez préfixer
le nom de la variable et du paramètre
avec un label et les entrer en
lettres capitales. Pour les paramètres,
le nom du label est le nom de la procédure.
EVAL SHIP_IT.ORDNUM affichera
la valeur du premier paramètre
d’entrée de la procédure illustrée figure
3. Les variables utilisent le label
spécifié sur l’instruction BEGIN, donc
EVAL SP.RATECALC devrait être la commande
à  exécuter dans la session de
débogage pour afficher la valeur variable
de la figure 3. Si le variable
contient une chaîne caractère, le nom
de la variable doit être préfixé par un
astérique (*) – du genre EVAL
*PROC.CHARVAR.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

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