Rechercher un programme dans une pile d’appels

Examinons par exemple le
code suivant :

Date1 Mult 1à˜à˜à˜à˜.à˜1 Date2

Il est peut-être ingénieux de bénéficier
des règles de troncature du RPG
pour convertir une date du format
MMJJAA en AAMMJJ à  l’aide d’une telle
instruction, mais on ne peut pas dire
que ce soit très intuitif. De plus, la multiplication
est une opération relativement
lourde, comme en témoignent
les benchmarks de performances.
Heureusement, on ne trouve pratiquement
plus dans les applications de
conversion de formats de date par multiplication.
Néanmoins, certaines circonstances
dictent des techniques qui,
malgré leur intérêt, sont critiquables
en matière d’intuition, de fiabilité, et
de performances. C’est souvent le cas quand une application a besoin de renseignements
sur des programmes situés
dans la pile d’appel d’un job. Un
programme applicatif, par exemple,
peut avoir besoin de déterminer le
nom de son appelant, ou un programme
trigger peut avoir besoin de
connaître avec certitude le programme
applicatif ayant provoqué son déclenchement.
D’autres fois, un programme
peut avoir besoin de savoir à  partir de
quelle bibliothèque, lui ou l’un des
autres programmes de la pile d’appel,
s’exécute.

Les fonctions de messagerie
OS/400 sont la technique standard par
laquelle un programme peut déterminer
son appelant ou par laquelle un programme trigger peut confirmer le
programme applicatif déclenchant le
trigger. Le programme envoie un message
à  une file d’attente de messages
de programmes précédente, reçoit le
message envoyé, et extrait le nom du
programme précédent des informations
renvoyées. Soit le code CL suivant
:

SndPgmMsg Msg(‘Any message will do')
          ToPgmQ(*Prv *)
          KeyVar(&MsgKey)
RcvMsg PgmQ(*Prv ( * ))
       MsgKey(&MsgKey)
       Sender(&Sender)
ChgVar &PrvPgm (%Sst(&Sender 56 1à˜)

Bien que ce soit le cas le plus
simple dans lequel un programme applicatif
utilise la messagerie pour déterminer
son appelant, ce code n’indique
pas intuitivement son objectif.

S’il s’agit de déterminer la bibliothèque
depuis laquelle un programme
s’exécute, les fonctions de messagerie
ne constituent pas une solution. Les
programmeurs utilisent plutôt une
technique semblable à  celle du code
CL suivant :

RtvObjD Obj(*LibL/SomePgm)

        RtnLib(&ActualLib)

Cette commande n'a absolument
rien à  voir avec les programmes que
l'application appelle. Elle recherche
simplement dans la liste des bibliothèques
la première occurrence du
programme SomePgm et renvoie dans
le paramètre &ActualLib, la bibliothèque
dans laquelle elle trouve cette
occurrence. Bien que cette technique
soit satisfaisante dans certains cas, ce
n'est pas la panacée car elle présuppose
deux dépendances applicatives
critiques.

Tout d'abord, cette technique présuppose
que l'application adresse un
appel non qualifié au programme
(c'est-à -dire qu'elle spécifie *LibL
comme la bibliothèque du programme
appelé). Si l'application spécifie la
bibliothèque du programme, cette
technique ne donne pas de résultats
fiables. En fait, le programme n'existe
peut-être dans aucune des bibliothèques de la liste ! Ensuite, cette
technique tient pour acquis que la liste
de bibliothèques n'a subi aucune modification
entre le moment où l'application
appelle le programme et celui
où la commande RtnObjD s'exécute.

Même dans les cas où la technique
RdnObjD fonctionne, l'application
s'expose à  des problèmes liés à  la
maintenance. En effet, un programmeur
procédant à  une simple révision
de l'application qui change le programme
pour effectuer un appel qualifié
ou qui modifie la liste de bibliothèques,
risque de ne pas se rendre
compte que la commande RtvObjD,
ainsi que ses présupposés, apparaît
ailleurs dans l'application.

Pour les applications qui doivent
extraire des informations à  propos de
la pile d'appel d'un job, la V5R1 propose
une solution plus solide et plus
intuitive - l'API QWVRCStk (Retrieve Call Stack). Commençons par disséquer
l'API. Puis nous examinerons un
programme de service qui extrait certaines
informations de la pile d'appel.