Apprendre un nouveau binder language

lie un programme, celuici
garde une copie des signatures
concernant les programmes de service
associés. Quand ce programme se
charge par la suite, il charge aussi tous
les programmes de service qui lui ont
été liés. A ce moment-là , les signatures
de chaque programme de service doivent
correspondre, faute de quoi le
programme de service ne se chargera pas.
Le composant le plus courant de la signature est une liste
des procédures présentes dans le programme de service. Si
la signature qui se trouve dans un programme de service correspond
à  celle qu’il avait quand il a été lié dans un programme
appelable, le programme a la certitude que toutes
les procédures dont il a besoin sont encore dans le programme
de service.
On peut contrôler explicitement la liste des procédures
dans un programme de service en stockant la liste dans un
membre source. Le binder language dans le membre source
pourrait se présenter ainsi :

STRPGMEXP PGMLVL(*CURRENT)
EXPORT SYMBOL(« DAYNAME »)
EXPORT SYMBOL(« DAYNBR »)
ENDPGMEXP


Le langage de liaison ne comporte que trois « commandes
». STRPGMEXP (Start Program Export) commence
une définition de signature, et ENDPGMEXP (End Program
Export) termine une signature. Entre ces deux lignes, on listera
chaque procédure en utilisant EXPORT. Dans cet
exemple, je définis une signature constituée de deux procédures,
DAYNAME et DAYNBR. J’aurais tout aussi bien pu
nommer la signature dans la ligne STRPGMEXP, mais j’ai préféré
confier au système le soin de la nommer.
On ne compile jamais ce binder language. On se
contente de s’y référer lorsqu’on crée un programme de service
:

CRTSRVPGM SRVPGM(srvpgm-name) +
EXPORT(*SRCFILE) +
SRCFILE(file-name) +
SRCMBR(member-name)

Le paramètre EXPORT, conjointement aux paramètres
SRCFILE et SRCMBR, indique au binder où trouver l’information
de signature pour le programme de service.
L’utilisation du binder language pour contrôler la signature
du programme de service présente un avantage important
: on peut maintenir de multiples signatures simultanées
pour un programme de service. Autrement dit, on peut
maintenir une signature courante et un nombre quelconque
de signatures précédentes. On peut ainsi ajouter des procédures
à  un programme de service ou apporter d’autres
modifications à  son interface, sans être obligé de relier un
programme qui pourrait connaître le programme de service
par une ancienne signature.
Examinons ce binder language, qui modifie et élargit
l’exemple précédent :

STRPGMEXP PGMLVL(*CURRENT)
EXPORT SYMBOL(« BEGOFMONTH »)
EXPORT SYMBOL(« ENDOFMONTH »)
EXPORT SYMBOL(« ENDOFWEEK »)
EXPORT SYMBOL(« DAYNAME »)
EXPORT SYMBOL(« DAYNBR »)
ENDPGMEXP
STRPGMEXP PGMLVL(*PRV)
EXPORT SYMBOL(« DAYNAME »)
EXPORT SYMBOL(« DAYNBR »)
ENDPGMEXP

Ici, je définis une signature courante constituée de cinq
procédures: BEGOFMONTH, ENDOFMONTH, ENDOFWEEK,
DAYNAME et DAYNBR. Mais j’ai aussi maintenu la signature
originale, en la changeant en une signature *PRV
(previous, précédente). L’ordre des exportations n’affecte en
rien la signature générée, donc il faut veiller à  ne pas changer
l’ordre des lignes EXPORT dans les signatures précédentes.
Quand je relierai ce programme de service, il aura deux
signatures. Si je le lie à  d’autres programmes, ceux-ci le
connaîtront par sa signature courante et pourront accéder
aux cinq procédures. Si certains programmes actuels
connaissent ce programme de service par son ancienne signature,
avec seulement les deux procédures originales, ces
programmes fonctionneront sans aucun problème. Mais ils
ne pourront utiliser que les deux procédures originales :
pour qu’ils puissent accéder aux nouvelles, il faudrait relier
les programmes.