Qu’est-ce qui va où ?

peuvent être écrits dans des langages différents) dans un programme ou objet programme de service. Cette méthodologie soulève quelques questions intéressantes : Combien de programmes de service faut-il avoir ? Combien de modules dans un programme de service ? Combien de sous-procédures dans un module ?

Les choses sont moins compliquées qu’elles semblent à première vue, mais c’est dans ce domaine que vous pratiquerez le plus la méthode essais/erreurs pour parvenir à la solution idéale. Le bon sens doit l’emporter et votre fil directeur doit être la facilité de maintenance. Groupez les sous-procédures communes (routines de date, routines de messagerie, routines d’évaluation, par exemple) dans un module. Groupez les sous-procédures dans un module quand il est bon qu’elles partagent la mémoire globale (par exemple dans le cas de sous-procédures qui accèdent aux fichiers base de données). Le nombre de sous-procédures dans un module n’est pas important : il faut simplement éviter un membre source tellement gros que son chargement dans WDSc prenne 10 minutes.

Il vaut mieux avoir trop peu de programmes de service que d’en avoir trop, parce que quand un programme est appelé, tous les programmes de service auxquels il est lié sont chargés. De plus, les programmes de service devraient contenir des ensembles de modules semblables. Laissez vous toujours guider par la facilité de maintenance. N’ayez pas d’emblée la performance comme objectif principal : ce point pourra être corrigé ultérieurement si nécessaire.

Ne dépassez pas huit ou neuf caractères pour les noms des programmes et des programmes de service. Les modules doivent avoir le même nom que l’objet programme final, avec un caractère ou un chiffre en suffixe. Dans le cas de programmes lien par copy (bind by copy), le suffixe le plus bas devrait être le module d’entrée du programme. Le principal mérite de cette technique est de pouvoir utiliser un nom générique pour les modules quand on utilise les commandes CRTPGM (Create Program) ou CRTSRVPGM (Create Service Program) :

CRTPGM PGM (MYPGM) MODULE(MYPGM)*

Le déplacement de sous-procédures entre modules (ou la division d’un module en plusieurs) se fait généralement par un simple couper/coller. Il faut simplement s’assurer que les éventuelles définitions globales sont reflétées correctement dans les nouveaux modules. Le programme de service doit être recréé avec les nouveaux modules, mais les exports pour le programme de service restent les mêmes.

La division d’un programme de service en plusieurs, ou la fusion de plusieurs programmes de service, signifie que les objets programmes de service sont créés en utilisant les modules existants – sans changement de programmation. Mais tous les programmes qui sont liés à ces programmes de service doivent être recréés afin d’être liés aux nouveaux programmes de service. Ce lien est très facile à réaliser avec les répertoires de liage, que j’explique ci-après.