Signatures des programmes de service

liés au programme correspondent bien aux signatures auxquelles le programme s’attend.

Le test ci-après permet de voir tout cela en action. Modifiez le source binder MATHUTIL, dans la commande STRPGMEXP changez la signature en ‘MATHUTIL1’ et recréez le programme de service.

Quittez le système revenez-y (sign off/on) (ou utilisez RCLACTGRP QILE) puis appelez votre programme. Il échouera avec MCH4 431 (Violation de signature du programme). A présent, corrigez le source binder et recréez le programme de service. Votre programme devrait fonctionner correctement à nouveau.

Il y a deux manières courantes de traiter la signature pour un programme de service. Pour illustrer les deux manières, supposons que notre programme de service MATHUTIL ait reçu deux modifications importantes : premièrement, les procédures MULT_10 et MULT_20 ont été ajoutées et, ultérieurement, ADD_2, ADD_3 et ADD_4 ont été ajoutées.

La première méthode consiste à utiliser la même signature pour toute la durée de vie du programme de service. La commande STRPGMEXP dans le source binder ne change jamais. (C’est ainsi qu’IBM gère ses programmes de service.) La figure 10 montre la version monosignature du source binder pour le programme de service MATHUTIL après les deux modifications visant à ajouter les nouvelles procédures.

La seconde méthode consiste à changer la signature chaque fois que l’on change le programme de service. Elle demande un peu plus de travail, mais elle permet de voir exactement quelle version d’un programme de service a été utilisée pour créer n’importe quel programme. La figure 11 montre la version multisignature du source binder pour le programme de service MATHUTIL après les deux modifications destinées à ajouter les nouvelles procédures. On voit que cette version a trois blocs export, chacun commençant et finissant par les commandes STRPGMEXP et ENDPGMEXP, et que toutes les commandes STRPGMEXP à l’exception de la première, ont PGMLVL(*PRV). Chaque fois que l’on crée une nouvelle version, on copie l’ancien bloc PGMLVL(*CURRENT), on change l’ancien *CURRENT en *PRV, et on ajoute les nouveaux exports au bloc *CURRENT.

A première vue, il semble bien compliqué de maintenir la version multi signatures de votre source binder. En réalité, c’est très simple parce que les anciens blocs export ne changent jamais : ils ne sont là que pour les programmes créés avec les versions antérieures du programme de service. Mais, si vous ajoutez fréquemment des procédures aux programmes de service, vous jugerez probablement beaucoup plus facile de maintenir simplement un bloc export unique. De multiples blocs export augmentent le risque d’apporter une modification incorrecte au source binder, c’est pourquoi je recommande d’utiliser un bloc export unique sauf s’il y a une raison impérieuse d’utiliser des blocs multiples.

Voici une règle importante pour changer le source binder : l’ordre des exports ne doit jamais changer. Cette règle s’applique aux deux méthodes de manipulation des signatures.

Chaque fois que l’on ajoute un nouvel export au programme de service, il faut le placer à la fin de la liste et il ne faut jamais rien ôter à cette dernière. Dès lors qu’un programme a été lié à un programme de service, le système trouve les procédures dans le programme de service d’après la position dans la liste export. Une fois le programme créé, le nom de la procédure n’a aucune importance pour le système.

Nous avons dit que l’ordre ne doit jamais changer. Pour voir pourquoi, livrons-nous à l’expérience suivante :

• Ajoutez à votre module une nouvelle procédure appelée add_10 qui ajoute 10 au paramètre d’entrée.
• Modifiez le source binder comme dans la figure 12, en ajoutant la nouvelle procédure incorrectement au milieu de la liste.
• Recréez le module et le programme de service.
• Récupérez le groupe d’activation et appelez le programme (ne recréez pas le programme). Au lieu d’afficher 7 et 11 comme prévu, le programme affichera 7 et 16. Quand ADD_1 est appelé, le système appelle en réalité une quelconque procédure qui a été spécifiée dans le premier EXPORT quand le programme de service a été créé. Quand ADD_5 est appelé, le système appelle une quelconque procédure qui a été spécifiée dans le second EXPORT. Comme le programme de service a été créé avec ADD_10 dans le second EXPORT, le système appelle ADD_10 au lieu de ADD_5. Pour démontrer spectaculairement ce problème, il suffit d’exécuter votre programme dans le débogueur et d’entrer dans l’appel de ADD_5.
• Corrigez le source binder comme dans la figure 13, puis recréez le programme de service.
• Récupérez le groupe d’activation et appelez à nouveau votre programme : il affichera bien 7 et 11.

Pour plus de pratique en la matière, répétez l’expérience en utilisant des blocs export multiples comme dans les figures 14A et 14B. Même avec des blocs export multiples, le système s’attend à ce que les exports restent à la même position dans chaque liste d’export.