Gérer les modules

UPDSRVPGM SRVPGM(srvpgm-name) +
MODULE(module-name)

Ne listez que les modules modifiés, qui doivent exister
quand vous liez à  nouveau l’objet. Les modules non modifiés
dans le programme ou le programme de service ne sont pas
affectés. Généralement, si vous reliez un programme de service,
vous n’avez rien à  faire sur les programmes qui utilisent
le programme de service, pourvu que la signature de ce dernier
(expliquée en deuxième partie) reste intacte.
J’essaie généralement d’éviter le sujet des conventions
de nommage, parce qu’elles dégénèrent généralement en arguments
pseudo-religieux. Pourtant le nommage a une part
importante dans la gestion des modules. Généralement, un
nom de procédure (et par extension, un nom de module)
devrait refléter le nom de la valeur de renvoi de la procédure.
Ainsi, si une procédure renvoie le nom en toutes lettres d’un
jour de la semaine, on pourrait l’appeler NomJour. Quand
une procédure ne renvoie pas de valeur, on peut lui donner
un nom « verbe/objet », semblable à  une commande CL.
MajCrédit, par exemple, pourrait nommer une procédure
qui met à  jour une limite de crédit.
On pourrait aussi envisager une convention de nommage
de modules permettant de lister les noms génériques
sur le paramètre MODULE pour les commandes CRTPGM et
CRTSRVPGM. Par exemple

CRTPGM PGM(MYPGM) +
MODULE(MYLIB/DAY*)

lierait inconditionnellement tous les modules dans MYLIB
qui commencent par les caractères DAY. Mais cette
convention est un peu délicate : il est facile de lier par inadvertance
des modules que l’on ne veut pas forcément dans le
programme.
On peut aussi organiser les modules dans des bibliothèques
communes puis lister *ALL au lieu des modules spécifiques
:

CRTPGM PGM(MYPGM) +
MODULE(MYLIB/*ALL)

Chaque module présent dans MYLIB serait alors lié dans
le programme.