> Tech > Gérer les modules

Gérer les modules

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

Dès lors qu'on a packagé un module dans un objet *PGM ou *SRVPGM, l'objet *MODULE a rempli son objectif. On n'a besoin de l'objet *MODULE que pour créer ces objets, pas pour les exécuter. Si l'on travaille dans un environnement de développement/production séparé, il n'est pas nécessaire de maintenir des

Gérer les modules

modules sur la
machine de production. La commande
DLTMOD (Delete Module)
supprimera les objets *MODULE du
système.
Mais vous aurez besoin des modules
s’il faut un jour recréer le
programme ou le programme de
service et si vous ne voulez pas recompiler
le code source. Chaque
module listé par la commande
CRTPGM ou CTRSRVPGM doit exister
au moment du liage : s’il en
manque un, il faudra le recompiler.
S’il est nécessaire de changer un
module dans un programme ou un
programme de service, il faut recompiler
le membre source dans un
module puis lier à  nouveau ce
module dans le programme ou le
programme de service approprié.
La commande UPDPGM (Update Program) ou UPDSRVPGM (Update Service Program) liera à 
nouveau un module dans un programme ou un programme
de service :

UPDPGM PGM(program-name) +
MODULE(module-name)

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.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010