On peut coder un gestionnaire de conditions de deux manières

une procédure dans un programme de service. Les programmes de
service sont plus faciles à  maintenir que les modules liés parce qu’on peut mettre
à  jour un programme de service sans être obligé de recréer tous les programmes
qui l’utilisent.
La figure 1 présente le code du programme de service de notre gestionnaire de
conditions simple, CndHdl. Les cartes D de CndHdl commencent par une directive
de copie d’un membre source appelé StdTypH, qui définit les types de données standard.
On peut transférer la source pour StdTypH depuis l’adresse http://www.mysystemsjournal.com.
Les cartes D définissent ensuite le prototype pour la procédure de gestion de
conditions CndHdl (en A, figure 1). La procédure CndHdl utilise une liste de paramètres
prédéfinis, obligatoire pour tous les gestionnaires de conditions :

· CndTok définit le jeton de condition transmis à  la procédure.
· CndPtr définit un pointeur vers une adresse mémoire transmis à  la procédure.
Le gestionnaire de conditions peut mettre à  jour les données à  cette adresse pour
communiquer avec le programme défaillant (nous y reviendrons plus loin).
· CndAct définit l’action renvoyée par le gestionnaire de conditions au système
d’exploitation. Dans cet article, je m’en tiens aux actions de reprise et de transmission
décrites précédemment.

La structure de données CndTokDs (en B) définit un jeton de condition. Rappelons
qu’un jeton de condition est la représentation, indépendante de la machine, d’un
message :

· CndTokSvr est la gravité du message.
· CndTokId est la représentation hexadécimale de l’identificateur du message.
CndTokId, par exemple, contiendrait X’0102′ (en hexadécimal) pour le message division
par zéro (divide-by-zero) du RPG IV (RNX0102).
· CndTokPfx est le préfixe du message, incluant ‘RNX’ pour une erreur d’exécution
du RPG IV.

La structure de données CndDs (en C) contient une représentation AS/400 standard
d’un identificateur de message et de sa gravité. CndDs sert à  renvoyer les détails
d’une erreur au programme défaillant.
La procédure CndHdl (en D) traite une condition. Elle commence par déplacer le
jeton de condition dans la structure de données CndTokDs, puis elle remplace le
contenu de la zone mémoire par la structure de données CndDs dans le programme
défaillant, défini par le pointeur CndPtr. La procédure reformate ensuite le jeton
de condition de CndTokDs dans CndDs, mettant ainsi l’information à  la disposition
du programme défaillant. Enfin, la procédure choisit la marche à  suivre en réponse
à  la condition. Si la condition s’accompagne de messages du type « target too small »
(cible trop petite) ou « divide by zero » (division par zéro), le programme défaillant
reprendra l’exécution. Toutes les autres conditions sont transmises au programme
défaillant par le biais d’un message d’exception. Notons que le groupe Select
vérifie les deux versions « MCH » et « RNX » de chaque message (une condition pourrait
signifier l’un ou l’autre des préfixes de message, selon les options utilisées
pour créer le programme défaillant).

Utilisation du gestionnaire de conditions
Voyons le gestionnaire de conditions à  l’oeuvre. Le membre d’en-tête de CndHdlH
(figure 2) inclut toutes les définitions nécessaires pour utiliser le gestionnaire
de conditions dans un programme :

· CndHdlPtr (en A) est un pointeur de procédure pour la procédure CndHdl.
· CndPtr et CndDs (en B) accèdent aux détails d’une sortie de condition par le
gestionnaire de conditions.
· CndTokDs (en C) définit la structure d’un jeton de condition.
· Le prototype de procédure SetCndHdl (en D) définit le gestionnaire de conditions
pour un programme utilisant l’API CEEHDLR (Enregistrer un gestionnaire de conditions
écrit par l’utilisateur).
· Le prototype de procédure ClearCndHdl (en E) efface le gestionnaire de conditions
pour un programme utilisant l’API CEEHDLU (Désenregistrer un gestionnaire de conditions
écrit par l’utilisateur).
· Le prototype de procédure ClearCnd (en F) efface le contenu de la structure
de données CndDs.

Après la complexité de toute la théorie précédente, sachez que l’utilisation du
gestionnaire de conditions est simple et directe.

On se souviendra que, dans un article précédent, nous avons utilisé le programme
de service SlsAnlPrc (figure 3). Voyons les conditions à  remplir pour utiliser
le gestionnaire de conditions dans ce programme :

· Ajouter des directives de copie des membres StdTypH et CndHdlH aux cartes D
(en A).
· Définir le gestionnaire de conditions au début de la procédure (en B).
· Effacer la dernière condition avant chaque bloc de code (en C). Quand un programme
reprend après une condition, il continue de s’exécuter comme si de rien n’était.
Le seul moyen d’intercepter une condition consiste donc à  tester le contenu de
CndDs à  des points stratégiques.
· Extraire l’identificateur de messages de toute condition survenue pendant l’exécution
du bloc de code (en D). Si le système d’exploitation a appelé le gestionnaire
de conditions pour répondre à  une condition, CndDs (effacé à  l’étape précédente)
contiendra les détails de la condition.
· Effacer le gestionnaire de conditions à  la fin de la procédure (en E).