Facilitez-vous la vie avec ces conseils utiles de lecteurs, IBMeurs et nos rédacteurs Techniques.
Du nouveau du côté des trucs et astuces en environnement i : nos experts se sont penchés sur la question pour allier performance et efficacité !
API : Extraire un nom de procédure
Avez-vous besoin d’extraire le nom d’une procédure courante ? Cette information est souvent nécessaire à l’occasion d’un audit ou d’un traitement d’erreurs. Elle peut être obtenue de deux manières.
Méthode classique. Envoyer un message à l’appelant en utilisant l’API Send Program Message (QMHSNDPM), extraire le message en utilisant l’API Retrieve Program Message (QMHRCVPM), et extraire le nom de la procédure envoyeuse. Cette méthode donne de bons résultats mais n’est pas très performante. En outre, une partie de l’information n’est pas toujours immédiatement disponible.
Meilleure méthode. Appeler l’API Retrieve Call Stack (QWVRCSTK). Cette méthode donne aussi de bons résultats mais les utilisateurs ont tendance à imbriquer l’appel vers QWVRCSTK directement dans la procédure (ou dans un copybook), avec pour résultat du code en double.
La solution consiste à avoir une procédure unique appelée GetProcName() dans un module appelé PROCNAME dans un programme de service (aussi appelé PROCNAME). Le PROCNAME *SRVPGM se trouve dans un répertoire de liage d’utilitaires appelé UTILITY, auquel toutes les applications font référence pendant la compilation avec le paramètre BNDDIR pour des commandes, telles que Create Bound RPG Program (CRTBNDRPG) et Create Cobol Module (CRTCBLMOD).
En incluant le copybook PROCNAME_P dans vos programmes, vous accédez à la procédure GetProcName(). Pour connaître le nom de la procédure courante, appelez simplement GetProcName, qui passe qproc (une structure de données aussi définie dans le copybook PROCNAME_P).
Après l’appel adressé à GetProcName, la structure de données qproc contient les noms de la bibliothèque, du programme (ou programme de service), du module, et de la procédure qui a appelé GetProcName(). J’aime utiliser cette approche conjointement à l’opcode DUMP pour identifier le fichier spoolé program dump QPPGMDMP. /free D string S 132A ... ... procedure code here ... begsr *pssr; GetProcName( qproc ); string = %trim( qproc.library ) + '/' + %trim( qproc.program ) + '/' + %trim( qproc.module ) + '/' + %trim( qproc.proc ); dump(a) string; endsr; /end-free
Comme résultat, la ligne supérieure du fichier spoolé QPPGMDMP contient quelque chose du genre MYLIB/ MYSRVPGM/MYMOD1/GetSystemValue – où GetSystem Value() est la procédure qui a appelé GetProcName(). Grâce à cette information, il est beaucoup plus facile de trouver le bon fichier spoolé s’il y en a beaucoup. Faute de spécifier un paramètre pour l’opcode DUMP, la ligne supérieure du fichier spoolé QPPGMDMP contient simplement ILE RPG/400 FORMATTED DUMP.
Pour télécharger le code, aller sur iTPro. Le code de la procédure PROCNAME et du copybook PROCNAME_P est inclus, ainsi que le code d’un programme appelé TESTPROCR qui montre comment appeler PROCNAME. Pour plus d’informations sur le préprocesseur compile, lire l’article « Using a Compile Preprocessor » - Club abonnés.
- Rory Hewitt Software developer
La plus grande partie de mon développement Web s’est faite du côté .NET de la barrière. Généralement les développeurs .NET utilisent les méthodes trace.warn() ou trace.write() pour fournir l’information de débogage.
Cependant, en essayant de suivre à la trace les programmes CGI, je n’ai pas trouvé de méthode nette et légère pour accomplir cela. Jusqu’au jour où Bob Cozzi m’a présenté une API : Qp0zLprintf, qu’il utilise pour envoyer l’information au journal des travaux (job log). Le prototype RPG IV Qp0zLprintf (figure 1) peut sembler un peu curieux parce que c’est réellement une fonction C, mais il est simple d’emploi.
L’API attend au moins un paramètre sous forme de chaîne avec un caractère nouvelle ligne (x'25') et une terminaison nulle (x'00'). La valeur options(*string) ajoute le terminateur null ; mais vous devez supporter le nouveau caractère. Si de multiples paramètres sont passés à l’API, le premier sert de chaîne de formatage.
En effet, cette API convient bien dans des jobs batch SQL à longue exécution, pour lesquels de multiples instructions doivent s’exécuter, quand l’API est incorporée dans des programmes interactifs complexes utilisés pour déterminer des règles de gestion, ou encore quand l’API est imbriquée dans un job serveur sans fin.
Dossiers
System i 
