strategie modules pgm srvpgm

[hermellin]

Bonjour,

Je souhaiterais votre opinion sur la stratégie à suivre en matière de création de *mod *pgm *srvpgm concernant un projet bien précis détaillé ci-dessous.

C'est une question récurrente, il est regrettable que ces potentialités n'aient pas été appliquées autant que c'était souhaitable dans les différents environnements de developpement. Pour ma part j'ai été formé à RPGLE (Ibm center à Lagny (?)) en 2000 mais ai quitté le monde as400/Ibm i pendant 10 ans, d'ou mes lacunes

Mon projet :
Dans le cadre du développement d'une CDU (classif. decimale universelle) , je vais écrire des dizaines de PROCs effectuant chacune une opération simple sur cette CDU (une CDU est comme un arbre : tronc, branches, fruits) :
- création d'une branche
- création d'un fruit
- comptage de fruits sur une branche
- comptage de sous-branches
- deplacement de branche
- recherche de branche
../..

j'ai bien lu le sujet : http://www.developpez.net/forums/d94...el-module-rpg/

Très instructif et me conduit a penser que je dois créer un un *SRVPGM contenant toutes les PROCs qui seront utilisées indifféremment par quelques interactifs et de nombreux Batch.

Ma question est : confirmez vous ce diagnostic ? et qu'en est il réellement de la gestion plus pointue des fichiers au sein d'un *SRVPGM ; sachant que certaines de mes PROC utiliseront la CDU en lecture seule mais plusieurs autres en MaJ et Creation ?

Hermelin

[Mercure]

Envoyé par hermellin

Ma question est : confirmez vous ce diagnostic ? et qu'en est il réellement de la gestion plus pointue des fichiers au sein d'un *SRVPGM ; sachant que certaines de mes PROC utiliseront la CDU en lecture seule mais plusieurs autres en MaJ et Creation ?

OK pour le programme de service et ses procédures à condition qu'il n'y ait qu'une seule fonction par procédure. Quant aux fichiers ou tables, cela ne pose pas de problème particulier quand bien même leurs gestions d'E/S seraient développées en RPG natif. Toutefois, j'opterais probablement pour SQL car plus souple pour manipuler les tables dans le cas présent.

[hermellin]

ok merci Mercure. Je n'ai pas SQL sur ma V5R2 donc ce sera natif

Si je fais X modules (1 proc par module) liés dans un Prog de service. et que plusieurs modules utilisent le meme fichier (disons en Entrée) ; le fichier est-il ouvert une seule fois par le 1er module appelé qui l'utilise, puis le fichier reste ouvert. Ou bien ouvert/fermé a chaque appel d'un module ?

Ou alors peut-etre est-ce mieux d'ouvrir les fichiers dans le *PGM appelant et de faire des Modules (mono procedure avec cartes H NOMAIN) liés dans le *SRVPGM ?

Hermelin

[K2R400]

Envoyé par Mercure

OK pour le programme de service et ses procédures à condition qu'il n'y ait qu'une seule fonction par procédure.

Philippe,

Pourquoi ce conseil ? (je présume que tu veux dire un source par fonction)
Peux-tu être plus explicite ....

[Mercure]

Envoyé par hermellin

Si je fais X modules (1 proc par module) liés dans un Prog de service. et que plusieurs modules utilisent le meme fichier (disons en Entrée) ; le fichier est-il ouvert une seule fois par le 1er module appelé qui l'utilise, puis le fichier reste ouvert. Ou bien ouvert/fermé a chaque appel d'un module ? Ou alors peut-etre est-ce mieux d'ouvrir les fichiers dans le *PGM appelant et de faire des Modules (mono procedure avec cartes H NOMAIN) liés dans le *SRVPGM ?

Tu es en train de confondre module et procédure.

Un programme ILE se compose d'un ou de plusieurs modules. Un module est constitué de une ou plusieurs procédures. Une procédure est constituée de lignes de code qu'on appele par un CALL lié (bound CALL). Il y a deux sortes de procédures : procédure principale et sous-procédure. On appelle la sous-procédure par un CALL prototypé.

Dans les applications courantes où les programmes sont écrits en un seul langage, il n'est pas utile de décomposer les programmes en plusieurs modules, à part peut-être pour des raisons

• de taille de source où gestion et maintenance risquent d'être un peu difficile,
• d'organisation particulière.

En fait, la modularité montre vraiment toute son utilité lorsqu'on est appelé à utiliser différents langages ILE dans le même programme, par exemple un programme constitué d'un mixage de RPG et de CL ou de tout autre langage ILE tel que COBOL, C ou C++.

Envoyé par K2R400

Pourquoi ce conseil ? (je présume que tu veux dire un source par fonction)
Peux-tu être plus explicite ....

Je dis de créer un programme de service constitué de plusieurs PROCEDURES et chaque procédure ne doit remplir qu'une seule fonction. Par exemple, dans la procédure TarifHT(), on ne doit coder que le code pour récupérer le tarif HT de l'article dans le fichier des tarifs et rien d'autre.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
H NoMain

FTarifs    IF   E           K DISK    USROPN

D TarifHT         PR             9p 2       
D   CodArt                       7p 0 const 

P TarifHT         B                   EXPORT
D TarifHT         PI             9p 2       
D   CodArt                       7p 0 const 
 /free                                      
    if not %open(Tarifs);                   
       open Tarifs;                         
    endif;                                  
    chain CodArt Tarifs;                    
    if %found;                              
       return MntTarifHT;                   
    else;                                   
       return -1;                           
    endif;                                  
 /end-free                                  
P TarifHT         E

Dans cet exemple, je montre également comment gérer l'ouverture d'un fichier dans une procédure. Le close du fichier pourra se faire par l'appel à une procédure particulière lorsque le programme ou le groupe d'activation se termine.

[K2R400]

Envoyé par Mercure

...et chaque procédure ne doit remplir qu'une seule fonction

C'est un choix. Personnellement je ne fais pas comme ça.
J'ai une procédure (un source donc) dans lequel je mets plusieurs fonctions.

La fonction Majuscule() est dans le même source que la fonction Minuscule() etc...

Je voulais savoir pourquoi ce choix de ton côté ?
Donc si je comprends bien si tu as une fonction LireTarifs(), une autre EcrireTarifs() une autre ModifieTarifs() tu as 3 sources, 3 cartes F avec le même fichier ?

[Mercure]

Qu'appelles-tu "source" ? Les fonctions "Majuscule()" et "Minuscule()" se trouvent-elles dans la même procédure (ou sous-procédure) ?

Envoyé par K2R400

Donc si je comprends bien si tu as une fonction LireTarifs(), une autre EcrireTarifs() une autre ModifieTarifs() tu as 3 sources, 3 cartes F avec le même fichier ?

Dans le prog de service, j'écris 3 procédures distinctes et une seule spécif F en début de programme.

[K2R400]

Je parlais de fonctions.
1 source en nomain, n fonctions à l'intérieur

[Mercure]

Alors, parle-t-on de la même chose mais dans un verbiage différent ?

[hermellin]

Envoyé par Mercure

Code :

Dans cet exemple, je montre également comment gérer l'ouverture d'un fichier dans une procédure. Le close du fichier pourra se faire par l'appel à une procédure particulière lorsque le programme ou le groupe d'activation se termine.

En tout cas j'ai ma réponse, merci.
hermelin,

[hermellin]

bonjour,

J'ai choisi de creer un membre Source par fichier logique utilisé, mbr src contenant x sous procédures et pas de procédure principale (Nomain).

Ca marche bien mais lors de la compil des modules (option 15), j'ai une erreur :

Code :

1
2
3
 ID msg  Gr Numéro Texte message
*RNF7534 10      1 Les fichiers doivent être fermés explicitement lorsque 
                          NOMAIN est indiqué dans la spécification de contrôle.

Et je ferme effectivement aucun fichier, esperant gagner du temps lors des appels successifs... C'est génant ?

Exemple de début de Source :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
H Nomain
H datfmt(*eur) timfmt(*hms) option(*nodebugio)
 *
 ******************************************************
FCLASSL4   UF   E           K DISK    USROPN
 *
D gestcla5        pr            22S 2
D  pà_pps                       22S 2
D  pà_pky                       22S 2
 *
D gestcla6        pr
D  pà_old                       22S 2
D  pà_new                       22S 2

Hermelin,

[Mercure]

Fais tourner toute ton appli dans un groupe d'activation nommé et fais donc une procédure d'initialisation qui enregistre le nom de ta procédure d'exit [du programme] en faisant appel à l'API CEE4RAGE(). Ensuite crée cette procédure d'exit dans laquelle tu fermes les fichiers lorsque le groupe d'activation se termine.

Je te montre ci-dessous un exemple.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
     H NOMAIN

     FMyFile    UF   E           K DISK    USROPN


     D InzSrvPgm       PR

     D EndSrvPgm       PR
     D   AgMark                      10u 0 options(*nopass)
     D   Reason                      10u 0 options(*nopass)
     D   Result                      10u 0 options(*nopass)
     D   UserRC                      10u 0 options(*nopass)


     D ChoiceArtMonth  PR            10i 0
     D  cdart                        15a   const
     D  p_DArticl                      *
     D  p_DArticld                     *
     D  p_TArticle                     *

     D Initialized     s              1n   inz(*Off)


      *+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      * Routine d'initialization
      *+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     P InzSrvPgm       B
     D InzSrvPgm       PI

     D CEE4RAGE        PR
     D   procedure                     *   procptr const
     D   feedback                    12A   options(*omit)

      /free
         if (Initialized);
             return;
         endif;

         // .. ouvre ici le ou les fichiers ...
         If Not %Open(MyFile);
            Open MyFile;
         Endif;
  
         // .. fais ensuite ici aussi les autres initialisations si besoin ...

         CEE4RAGE(%paddr(EndSrvPgm): *OMIT);

         Initialized = *On;
         return;
      /end-free
     P InzSrvPgm       E

      *+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      * EndSrvPgm():  Cette procédure est appelée quand le groupe 
      *               d'activation se termine, c'est à dire lorsque le 
      *               programme de service sort de la mémoire.
      *+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     P EndSrvPgm       B                   export
     D EndSrvPgm       PI
     D   AgMark                      10u 0 options(*nopass)
     D   Reason                      10u 0 options(*nopass)
     D   Result                      10u 0 options(*nopass)
     D   UserRC                      10u 0 options(*nopass)
      /free

           // ... fais ici les traitements de fin de programme :
           // ... ferme les fichiers
           // ... désalloue la mémoire s'il y a lieu
           // ... etc.

           If %Open(MyFile);
              Close MyFile;
           EndIf;

           InitializeD = *Off;
           return;

      /end-free
     P EndSrvPgm       E

     P ChoiceArtMonth  B                   Export
      *+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      * Selection des Articles  Mensuels
      *+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     D ChoiceArtMonth  PI            10i 0
     D  cdart                        15a   const
     D  p_DArticl                      *
     D  p_DArticlD                     *
     D  p_TArticle                     *

     D ... Autres définitions

      /free

       // **Chaque** procédure exportée, outre EndSrvPgm, doit  
	  obligatoirement commencer par appeler le procédure InzSrvPgm()

       InzSrvPgm();

         ... mettre ici le traitement de la procédure

       return;

      /end-free

     P ChoiceArtMonth  E

[hermellin]

Merci Mercure.

C'est très pointu. Je le mettrai en oeuvre d'ici quelques jours afin de ne pas cumuler trop de nouveautés, ce qui rend plus complexe mes debugs.

hermelin

[jump400]

Envoyé par Mercure

Fais tourner toute ton appli dans un groupe d'activation nommé et fais donc une procédure d'initialisation qui enregistre le nom de ta procédure d'exit [du programme] en faisant appel à l'API CEE4RAGE(). Ensuite crée cette procédure d'exit dans laquelle tu fermes les fichiers lorsque le groupe d'activation se termine.
...//...

Bjr,

Je ne vois pas très bien l'intérêt de cette technique pour les fichiers utilisés en spécifs F et la mémoire allouée
Que je sache, à la fin du groupe d'activation les fichiers sont fermés et le default heap est supprimé, non ?
Mais ce ne sont peut-être que des idées reçus... je suis preneur d'éclaircissements !
Par contre cela peut-être interessant pour les objets temporairement créés (mais Qtemp est trés bien aussi), les ouvertures de fichiers stream ("IFS"), etc

[Mercure]

Envoyé par jump400

Je ne vois pas très bien l'intérêt de cette technique pour les fichiers utilisés en spécifs F et la mémoire allouée
Que je sache, à la fin du groupe d'activation les fichiers sont fermés et le default heap est supprimé, non ?
Mais ce ne sont peut-être que des idées reçus... je suis preneur d'éclaircissements !
Par contre cela peut-être interessant pour les objets temporairement créés (mais Qtemp est trés bien aussi), les ouvertures de fichiers stream ("IFS"), etc

Cette technique est celle que j'utilise et qui provient de mes lectures de la doc de Scott Klement que tu connais de nom certainement, pour traiter les cas de fin de programme. Dans le cas ici présent, l'OP veut laisser les fichiers ouverts pour raisons de performance (et il a raison) et, lorsque son appli se termine, demande s'il doit les fermer ou les laisser ouverts et Vaya con Dios ! En utilisant la méthode que je préconise ici, notre OP n'a pas besoin de faire appel à une procédure pour fermer les fichiers et, le cas échéant, faire du nettoyage parmi les divers objets (user spaces) et mémoires (%ALLOC) utilisés au cours du traitement puisque l'API CEE4RAGE routera son application sur la procédure enregistrée lors de la désactivation du groupe d'activation. Je trouve que c'est également plus propre que de laisser faire le système.

Bien entendu, il n'est pas indispensable de développer cette technique pour fermer les fichiers puisque ceux-ci sont effectivement automatiquement fermés et les heaps de mémoire libérés lorsque le groupe d'activation se termine, l'OP peut laisser les fichiers ouverts après tout, mais je trouve que

• c'est une bonne pratique ILE de faire tourner ses appli dans un groupe d'activation nommé (je pense ici en particulier aux commit/rollback)
• c'est une bonne habitude de gérer soi-même la fermeture de fichiers et le nettoyage d'objets ou de mémoires plutôt que de laisser le système le faire (je n'aime pas beaucoup les options par défaut).