Considérations sur la récursion

profils et tables utilisateur à vérifier sont codés en dur dans le programme. Ce qui entraîne quelques questions. Et si ces données doivent être plus dynamiques ? Et si le programme de sortie lui-même avait besoin de lire dans une table ou d’insérer des lignes dans une table (par exemple, lors de l’écriture dans une table d’audit) ?

Pour changer le programme à cet effet, il faudrait ouvrir une table de base de données elle-même. Par conséquent, le point de sortie émettrait une nouvelle invocation du programme de sortie. Comme une telle invocation existait déjà sur la pile de programmes, un appel de programmes récursifs s’est produit. Et alors ? Et bien cela pose un problème parce que RPG ne prend pas en compte les appels de programmes récursifs.

Vous pensez peut-être pouvoir régler ce problème en compilant le programme de sortie RPG avec ACTGRP (*NEW), en ordonnant au système d’activer le programme dans un nouveau groupe d’activation chaque fois qu’il est appelé. Même si cela marchait dans certain cas, ce n’est pas recommandé pour des raisons de performances. (En effet, la création d’un nouveau groupe d’activation est une activité système lourde et qui interviendrait pour chaque ouverture de base de données.) En outre, si vous spécifiez ACTGRP(* NEW), le point de sortie échouera s’il a été appelé comme résultat d’une opération open table à partir d’une UDF (user-defined function) SQL externe.

Pour éviter les problèmes de récursion RPG, plusieurs possibilités s’offrent à vous :

Coder en dur les valeurs. Comme le démontre l’exemple précédent, on peut coder en dur les valeurs si les données changent peu ou jamais et si l’on n’a besoin d’aucune journalisation d’audit. Autrement dit, le programme de sortie éviterait complètement d’accéder à une quelconque table de base de données. Toute modification éventuelle demanderait de mettre à jour le code source, de recompiler, et de promouvoir les objets par l’intermédiaire du système de gestion du changement.

Utiliser des objets non-base de données. Plutôt que d’utiliser des tables de base de données pour stocker des données dynamiques (profils utilisateur à bloquer, noms de tables à sécuriser), utilisez un objet système alternatif pour stocker les données. Vous pouvez utiliser des objets tels que des zones de données et des espaces utilisateur à cet effet. Vous pouvez accomplir la journalisation d’audit par quelque autre mécanisme : envoi de messages à une file d’attente de messages ou d’entrées dans une file d’attente de données.

Utiliser un autre langage de programmation. Si votre programme point de sortie a besoin d’un I/O base de données, utilisez un langage tel que C ou CL qui permet la récursion. Vous pouvez écrire tout le programme en C, ou bien écrire un programme CL qui émet un appel de procédure liée (CALL PRC) vers une procédure RPG pour accomplir le plus gros du travail. Bien que vous ne puissiez pas appeler récursivement un programme RPG, vous pouvez appeler récursivement une procédure RPG. (Pour voir des exemples d’un programme C et d’un programme CL qui traite la récursion, voir l’encadré « C and CL Program Recursion Examples » sur www.itpro.fr Club abonnés)