> Tech > Rechercher un programme dans une pile d’appels

Rechercher un programme dans une pile d’appels

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

par Gary Guthrie - Mis en ligne le 26/08/02
Certaines circonstances dictent des techniques de programmation 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 ...

Pour accomplir certaines tâches, les programmeurs aiment parfois utiliser des techniques de programmation astucieuses. C'est ainsi que les programmeurs RPG chevronnés reconnaissent du premier coup d'oeil les nombres 10000.01 et 10.00001 comme des membres de formules malines destinées à  convertir des dates entre le format MMJJAA et AAMMJJ. Convertir des formats de date en multipliant les dates numériques par l'un de ces nombres est l'un des plus vieux trucs RPG en circulation.

Cette ingéniosité n'est pourtant pas toujours intuitive, fiable ou performante.

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.

Téléchargez cette ressource

Sécuriser votre système d’impression

Sécuriser votre système d’impression

Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.

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