CPF4019, Cdes srvpgm

[hermellin]

Bonjour,

j'ai 2 questions qui n'ont pas de lien entre elles :
- a l'execution d'un interactif j'ai dans la joblog l'apparition de xxx CPF4019 qui ne gène en rien l'execution du prg, mais je n'en comprends pas le sens ?
(EGESTGENP est un DSPF !)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
                     Complément d'informations sur message
 ID message . . . . . . :   CPF4019
 Date d'envoi . . . . . :   07/01/11      Heure d'envoi  . . . . :   18:22:43
 Message . . . . :   Longueur d'enregistrement indiquée différente de celle du
   fichier.
 Cause . . . : La longueur d'enregistrement indiquée pour un fichier de niveau
   zone est supérieure ou inférieure à celle du fichier. La longueur
   d'enregistrement indiquée est différente de celle du fichier EGESTGENP, de
   la bibliothèque RYAEL. La longueur de l'enregistrement indiquée est 333,
   alors que celle du fichier est 413. Tout fichier est ouvert avec une
   longueur minimale de 100. Cette valeur est attribuée par défaut aux fichiers
   dont la longueur d'enregistrement est inférieure à 100. Le fichier est
   ouvert avec la longueur d'enregistrement indiquée.
 Que faire . . . : Reportez, dans le programme, la longueur maximale
   d'enregistrement du fichier.

- 2eme question concernant les Progs de Service :

. Si je modifie un module pré-existant dans un SRVPGM, je recompile le module (option 15) puis je fais un UPDSRVPGM pour ce module : je n'ai pas a recompiler les progs utilisant le SRVPGM.

. Mais si je créé un nouveau module (option 15) et souhaite le rajouter dans ce meme SRVPGM : la commande UPDSRVPGM ne passe pas (normal) et donc je n'ai que la commande CRTSRVPGM qui nécessite de spécifier TOUS les modules et pas seulement le nouveau. => d'ou nécessité de recompilation de tous les progs utilisant le SRVPGM.

Comment faire ?

merci d'avance et bon weekend,
Hermelin

[Mercure]

Réponse à la question 1
Comme te l'indique le libellé du message, tu as déclaré dans le programme une longueur d'enreg. de 333 et le fichier concerné a une longueur réelle de 413. L'OS ne tiendra compte que des 333 premiers caractères de ton fichier, c'est à dire la longueur déclarée, et les caractères restants seront ignorés.
Comme indiqué, tu devrais déclarer la longueur réelle dans le programme et tu n'auras plus cette erreur "warning".

Réponse à la question 2
Si tu as créé un nouveau module, c'est que tu as créé de nouvelles procédures, n'est-ce pas ? Il est donc normal que tu recompiles le srvpgm via CRTSRVPGM pour qu'il prenne en compte ce nouveau module.

Maintenant, comment veux-tu que les programmes qui sont liés à ce srvpgm trouvent les nouvelles procédures si tu ne recompiles pas ces programmes ?

Comment as-tu organisé le membre BND (QSRVSRC) se rapportant au srvpgm ?

Quelle signature y as-tu indiqué ?

As-tu placé les nouvelles procédures à la fin de celles qui existaient déjà dans le membre ?

Pour y voir + clair, colle ici le membre BND stp.

[hermellin]

merci pour ta réponse mercure.

pb 1 : EGESTGENP etant un DSPF je ne vois pas bien quelle déclaration de longueur 333 j'aurais pu faire. C'est juste un fichier DSPF décrit en carte F sans aucune déclaration de longueur, d'ou mon incomprehension du CPF et de ton explication

pb2 : je n'ai pas de membre BND dans QxxxSRC. Il y a dans une déclaration BNDDIR ('xxxx') dans la carte H des progs concernés et je fais CRT ou UPDSRVPGM avec EXPORT(*all)

Si j'ai 20 modules dans mon SRVPGM et 10 progs RPGLE utilisant ce srvpgm, je rajoute un module X (utilisé par 1 seul des progs RPGLE), c'est qd même dommage d'avoir à recompiler les 10 progs a cause du problème de signature. C'est le sens caché de ma question

Hermelin

[K2R400]

Pour le 1) ca ressemble à un fichier qui a été modifié et qui possède un LVLCHK(*NO) sans recompilation du programme.

Pour le reste, tu n'as pas besoin de recompiler tes programmes qui utilisent le programme de service. Mais pour ce faire il va falloir que tu gères les versions avec ce que l'on appelle un langage de liage.

Tu commences par regénérer le source d'exportation de ton srvpgm existant avec RTVBNDSRC MODULE(*ALL)....

SI tu avais 2 exports X, Y et que tu viens de créer Z, il te faut modifier le source pour obtenir

Code :

1
2
3
4
5
6
7
8
9
10
STRPGMEXP(*PRV)
EXPORT(X)
EXPORT(Y)
ENDPGMEXP

STRPGMEXP(*CURRENT)
EXPORT(X)
EXPORT(Y)
EXPORT(Z)
ENDPGMEXP

puis tu refais un UPDSVRPGM en précisant ce source.

[hermellin]

merci de ta réponse K2r400

Je vérifie le point 1 cet aprem....

Pour le point 2, il est vrai que j'avais souhaité dès le départ éviter la gestion d'un source BND (langage de liage) car je trouvais cela fastidieux ; mais effectivement puisque cela va résoudre mon problème je vais le faire.

Ca veut dire que la cde UPDSRVPGM + langage de liage , est plus puissante que si utilisée en ligne. Je m'attendais a pouvoir faire UPDSRVPGM module('NEWMODULE') *ADD
mais cet *ADD ne semble etre realisable qu'au travers du BND que tu as décrit ci-dessus.
je ne connaissais pas la cde RTVBNDSRC qui va m'être bien utile

Hermelin

[Mercure]

Pour le point 1, OK pour le LVLCHK(*NO). Je n'avais pas vu qu'il s'agissait d'un DSPF. Mea culpa.

En revanche, pour le point 2, je ne suis pas OK.
Vous êtes en train de confondre une fois de plus modules et procédures.
Un module est composé de une ou de plusieurs procédures et le programme de service est composé de un ou de plusieurs modules.
Avoir créé le srvpgm avec EXPORT(*all) est la pire chose à ne jamais faire. Il faut toujours créer dans QSRVSRC un membre de liage (BND). Dans ce membre, il faut indiquer :

• Une fois pour toutes une signature immuable et définitive. En général, on indique le nom de l'application (COMPTA, VENTES, etc) mais ce n'est pas obligatoire, on peut y mettre ce qu'on veut. En tout cas, ne pas utiliser *GEN sinon la signature va changer à chaque évolution du programme de service et çà, on ne le veut pas. Une fois que la signature est validée, ne plus jamais y toucher.
• Le nom de chaque procédure qui composent le programme de service. Le plus simple est de les indiquer dans l'ordre où elles apparaîssent dans le programme de service mais ce n'est pas obligatoire. Le nom des modules n'a rien à faire ici.

Le programme de service va vivre et on va y ajouter des nouvelles procédures. Dans ce cas -- et c'est ton cas ici --, ajoute toujours le nom des nouvelles procédures à la suite des anciennes mais sans jamais altérer l'ordre dèjà établi pour les procédures précédentes.

Si tu suis toutes ces recommandations à la lettre, tu n'auras plus à te soucier des *PRV et *CURRENT. Tu compileras ou recompileras ton programme de service par CRTSRVPGM ou UPDSRVPGM sans avoir à te prendre la tête lorsque tu seras appelé à le modifier et tu ne devras compiler ou recompiler que les programmes qui font appel aux nouvelles procédures.

Exemple

A la première création du programme de service, dans le membre de liage j'indique la signature définitive et le nom des 3 procédures qui le compose :

Code :

1
2
3
4
5
STRPGMEXP  PGMLVL(*CURRENT) LVLCHK(*YES) SIGNATURE('Ma Signature')
EXPORT SYMBOL('Proc1')   
EXPORT SYMBOL('Proc2')
EXPORT SYMBOL('Proc3') 
ENDPGMEXP

Plus tard, j'ai besoin de créer 2 nouvelles procédures. Voici alors comment va se présenter le membre de liage :

Code :

1
2
3
4
5
6
7
STRPGMEXP  PGMLVL(*CURRENT) LVLCHK(*YES) SIGNATURE('Ma Signature')
EXPORT SYMBOL('Proc1')   
EXPORT SYMBOL('Proc2')
EXPORT SYMBOL('Proc3') 
EXPORT SYMBOL('Proc4') 
EXPORT SYMBOL('Proc5') 
ENDPGMEXP

Je n'ai surtout pas touché à l'existant et me suis limité à ajouter le nom de mes 2 nouvelles procédures à la suite des anciennes (en gras ci-dessus).

Et c'est tout ce que j'ai à faire à ce niveau. Il faut ensuite faire la recompilation du programme de service par UPDSRVPGM. Enfin, seuls les programmes utilisant ces nouvelles procédures doivent être compilés et ceux qui ne les utilisent pas n'ont pas besoin de recompilation.

Pour le cas qui te préoccupe, je ferais le RTVBNDSRC, je figerais la signature et ajouterais les nouvelles procédures à la fin dans la membre de liage puis je recopilerais tout le bazar, le programme de service et les 10 programmes utilisateur pour repartir sur une base saine.

Si tu utilises la méthode *CURRENT et *PRV, tu vas à la longue te retrouver avec une multitude de *PRV qui vont compliquer sérieusement la gestion de ton application et, en général, à moins d'être maso, on n'a pas besoin de s'ajouter une couche supplémentaire de complexité dans notre travail quotidien, n'est-ce pas ? Plus c'est simple et mieux je me porte !

[hermellin]

Pour le point 1, c'etait bien un dephasage de niveau de compil rpgle/dspf...

Envoyé par Mercure

Un module est composé de une ou de plusieurs procédures et le programme de service est composé de un ou de plusieurs modules.

Aucun problème, c'est comme ca que je vois le topo. Un SRVPGM est composé de 1 à x MODULES eux mêmes composés de 1 a x procédures

Tu compileras ou recompileras ton programme de service par CRTSRVPGM ou UPDSRVPGM sans avoir à te prendre la tête lorsque tu seras appelé à le modifier et tu ne devras compiler ou recompiler que les programmes qui font appel aux nouvelles procédures.

Ok je vais figer les signatures (je ne savais pas que c'etait possible). et maintenir mon source BND en rajoutant toujours à la fin.

Bien que ma formation ILE date de plusieurs années, j'ai toujours pensé que ces innovations IBM étaient un peu cafouilleuses et pas vraiment claires, sans doute trop paramètrables pour être simple d'utilisation.

Une fois qu'on a trouvé la voie à suivre, ca va tout seul... donc merci de faire profiter de votre expérience

Hermelin

[K2R400]

Philippe,

Si on ajoute de nouvelles procédures à un programme de service il faut changer la signature !!!!! recommandations d'IBM... et même pour t'y retrouver tu fais comment ?????

Exemple :

Code :

1
2
3
4
5
6
7
8
9
STRPGMEXP  PGMLVL(*CURRENT) SIGNATURE('Version 1.2')
EXPORT SYMBOL('Proc1')   
EXPORT SYMBOL('Proc2')
EXPORT SYMBOL('Proc3') 
ENDPGMEXP

STRPGMEXP  PGMLVL(*PRV) SIGNATURE('Version 1.1')
EXPORT SYMBOL('Proc1')   
ENDPGMEXP

[m4k-Hurrican]

Il y a eu de multiples discussions à ce sujet, entre autre sur la liste Easy400 avec S. Klement et Giovanni Perotti et on est tous tombés d'accord avec la méthode présentée par Mercure.
Si dans un monde idéal avoir une signature unique à chaque changement de procédure est une bonne idée théorique de départ, elle rend la vie impossible et ne règle pas tout loin de là.
Il vaut mieux se tenir à la règle qui veut qu'on ne change jamais l'ordre des procédures (et qu'on en retire pas non plus), qu'on ajoute les nouvelles à la fin, et qu'on fige la signature. On ne prend alors pas plus de risques, et on se simplifie réellement la vie.

[K2R400]

Envoyé par m4k-Hurrican

Si dans un monde idéal avoir une signature unique à chaque changement de procédure est une bonne idée théorique de départ, elle rend la vie impossible et ne règle pas tout loin de là.
Il vaut mieux se tenir à la règle qui veut qu'on ne change jamais l'ordre des procédures (et qu'on en retire pas non plus), qu'on ajoute les nouvelles à la fin, et qu'on fige la signature. On ne prend alors pas plus de risques, et on se simplifie réellement la vie.

L'ordre ne doit jamais jamais être effectivement changé.
Avoir un programme de Service version 1.0 contenant 3 procédures et version 2.0 contenant 4 procédures, c'est exactement ce qu'IBM préconise !!!!

[Mercure]

@K2R400,
Faire évoluer la signature avec les versions du logiciel, c'est en effet ce que préconise IBM, mais dans la pratique, on se rend compte au fil du temps que cette méthode est vraiment trop contraignante et complique sérieusement la maintenance.
Je dirais la même chose que m4k-Hurrican. Je suis effectivement la méthode préconisée par Scott Klement, qui nous a maintes fois montré de quoi il était capable et je ne m'en porte que mieux.

[K2R400]

Envoyé par Mercure

Faire évoluer la signature avec les versions du logiciel, c'est en effet ce que préconise IBM, mais dans la pratique, on se rend compte au fil du temps que cette méthode est vraiment trop contraignante et complique sérieusement la maintenance.

Je suis en train de réfléchir à ce problème de maintenance d'un source de liage avec plusieurs versions et un source de liage avec qu'une seule version.
Je n'arrive pas à voir ou est la complexité de l'un par rapport à l'autre...
Si vous faites référence à cet article http://systeminetwork.com/article/bi...gnature-debate de scott inspiré de l'article de Ted Holt http://www.itjungle.com/fhg/fhg101508-story02.html, je reste très sceptique du conseil...
Ted montre qu'il est possible de le faire, Scott, le conseille...
On perd la notion de version pour simplifier le source de liage, je ne vois aucun avantage. Certes, Scott développe (avec brio) dans sa boutique de saucisses mais n'est pas un éditeur de progiciel.
Un éditeur qui livre un programme de service version 1.0 avec 2 procédures, puis un an plus tard le même programme de service version 1.0 avec 10 procédures, celà ne me semble pas vraiment cohérent pour s'y retrouver par la suite, c'est mon point de vue.
En tant que formateur pour big blue, je continuerai donc de conseiller mes élèves sur la base des redbooks sauf si peut-être avez d'autres arguments plus convaincants qu'une simple "réduction" du source de liage au détriment du versioning.

Je prends un autre exemple :

J'ai un programme de service avec deux exports :

Code :

1
2
3
4
STRPGMEXP  PGMLVL(*CURRENT) SIGNATURE('Version 1')
  EXPORT SYMBOL('ProcA')
  EXPORT SYMBOL('ProcB')
ENDPGMEXP

Un mois plus tard j'en ajoute un :

Code :

1
2
3
4
5
6
7
8
9
10
STRPGMEXP  PGMLVL(*CURRENT) SIGNATURE('Version 2')
  EXPORT SYMBOL('ProcA')
  EXPORT SYMBOL('ProcB')
  EXPORT SYMBOL('ProcC')
ENDPGMEXP

STRPGMEXP  PGMLVL(*PRV) SIGNATURE('Version 1')
  EXPORT SYMBOL('ProcA')
  EXPORT SYMBOL('ProcB')
ENDPGMEXP

Puis je décide d'ajouter un paramètre supplémentaire au prototype de ProcB :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
STRPGMEXP  PGMLVL(*CURRENT) SIGNATURE('Version 3')
  EXPORT SYMBOL('ProcA')
  EXPORT SYMBOL('ProcB_OLD')
  EXPORT SYMBOL('ProcC')
  EXPORT SYMBOL('ProcB')
ENDPGMEXP

STRPGMEXP  PGMLVL(*PRV) SIGNATURE('Version 2')
  EXPORT SYMBOL('ProcA')
  EXPORT SYMBOL('ProcB')
  EXPORT SYMBOL('ProcC')
ENDPGMEXP

STRPGMEXP  PGMLVL(*PRV) SIGNATURE('Version 1')
  EXPORT SYMBOL('ProcA')
  EXPORT SYMBOL('ProcB')
ENDPGMEXP

Comment faites-vous avec la technique de Scott versus celle d'IBM ? Le programme de service est continuellement en version 1 ?????

[m4k-Hurrican]

Un exemple ?
J'ai un programme de service dont les procédures sont utilisées par près de 800 programmes.
Si j'ajoute une procédure, qui pour le moment n'est utilisée que dans un seul nouveau programme, et que suivant les guides je change de version, bien que mes 800 programmes n'ont strictement rien à voir avec la nouvelle procédure, je serais obligé de tous les recompiler. C'est un travail monstrueux et inutile !
Si au contraire je garde le n° de version, j'ai juste à modifier le source de liage, recompiler le programme de service, et compiler le nouveau programme.
De toute façon si une procédure n'est pas à niveau on obtiendra un erreur, comme pour le programme de service.

[K2R400]

Envoyé par m4k-Hurrican

Un exemple ?
J'ai un programme de service dont les procédures sont utilisées par près de 800 programmes.
Si j'ajoute une procédure, qui pour le moment n'est utilisée que dans un seul nouveau programme, et que suivant les guides je change de version, bien que mes 800 programmes n'ont strictement rien à voir avec la nouvelle procédure, je serais obligé de tous les recompiler. C'est un travail monstrueux et inutile !
Si au contraire je garde le n° de version, j'ai juste à modifier le source de liage, recompiler le programme de service, et compiler le nouveau programme.
De toute façon si une procédure n'est pas à niveau on obtiendra un erreur, comme pour le programme de service.

Tu parles de l'export *ALL qui oblige effectivement à tout recompiler.
Personne ne préconise ceci et surtout pas moi, ni même les "guides" comme tu dis.

[Mercure]

Patrick,

Tu fais une fixation sur le fait que signature = version. Ce n'est pas indispensable, on peut mettre ce qu'on veut dans la signature, pas que la version, n'est-ce pas ?
Si tu laisses tomber la version du logiciel dans la signature, tu constateras que la méthode que préconise Scott semble alors couler de source. Pourquoi donc se prendre la tête à vouloir

• gérer plusieurs signatures
• risquer une violation de signature à l'exécution
• alourdir la gestion du membre BND

alors qu'on peut s'en passer ? Cela en vaut-il la peine uniquement pous gérer les versions ?

[K2R400]

lol, je ne fais pas de fixation j'essaye de trouver des avantages à ce que propose Scott et je suis du genre à prendre les bonnes techniques et de changer d'avis s'il il le faut.
Pour l'instant vous semblez dire que les redbooks et les supports de cours d'IBM ne sont pas pertinents, j'essaye juste de comprendre votre point de vue.

IBM préconise de gérer les signatures (pas les versions si tu veux) pour premettre justement ce que j'ai expliqué dans mon précédent post.
Avec la technique de Scott, je ne vois pas comment le gérer. Une idée ???

De plus, comme je l'ai dis, le point de vue de développeurs internes à une entreprise n'est pas forcément celui d'un éditeur de progiciels qui pourrait avoir maintes "versions" du même programme de service.

[pwrdwnsys]

Bonjour.

Je suis de l'avis de Patrick sur la gestion des versions de signatures.

Dans notre entreprise, notre cycle de maintenance passe par ces phases :
- Développement de multiples projets distincts (avec donc des multi-maintenances sur des programmes de service )
- Recette globale de plusieurs projets
- Pré-production
- Production

Nous cherchons donc à être sûr que ce que nous livrons en production soit bien ce que nous avons testé et que ça ne va pas planter lors de l'appel de quelque chose d'inexistant. Pour nous l'assurer, la violation de signature est imparable : dès le début des recettes, nous savons que nous exécutons un programme qui utilise un programme de service dont la signature correspond à celle qui a été utilisée lors des développements.
Cela évite principalement de livrer une version 2 d'un programme de service (avec 15 procédures) avant une version 1 (avec 10 procédures), par exemple, ce qui, avec une seule signature, provoquerait immanquablement le plantage de tous les programmes utilisant les 5 nouvelles procédures (pas de violation de signature, mais procédure inconnue).

Je suis preneur de toute simplification de la gestion des historiques de signatures (IBM ne fournit pas grand chose pour nous aider), mais je pense que ne gérer qu'une seule signature, c'est comme faire un *LVLCHK(*NO) sur un fichier : c'est masquer le problème et attendre que ça plante, alors que nous préférons détecter une incohérence avant la livraison.

[m4k-Hurrican]

Je ne suis pas de cet avis. Cà n'évite rien du tout.
En cas de soucis de version tu auras juste un message différent. Le message sera au niveau du programme de service au lieu de la procédure c'est tout.
Rien ne remplacera les tests.

@ K2R400
A moins que je ne me trompe, mais là il y aurait vraiment quelque chose qui m'aurait échappé, le changement de signature implique automatiquement la recompilation des programmes utilisant le programme de service concerné. Rien à voir avec l'EXPORT(*ALL). Si je me plante, je veux bien des explications, parce que pour ma part, c'est l'argument principal.

Parenthèse à ce sujet. Je développe pour d'autres OS et dans d'autres langages. On peut facilement assimiler le programme de service aux bibliothèques de fonction (comme les dll de Windows ou les librairies de la plupart des autres OS). Dans tous ces autres OS, la bibliothèque de fonction a une signature. Mais elle n'est pas bloquante à l'exécution, si la version est supérieure ou égale à la version demandée. Car les développeurs sont sensés garder une compatibilité ascendante. IBM n'a pas permis ce genre de chose, et c'est bien dommage. Moi je suis pour un n° de version, à condition que ce n° soit gérer de manière standardisée (Version Release Modification ?) et que les programmes puissent indiquer un niveau "minimum", ne générant pas d'erreur de signature si le programme de service est plus récent.

[K2R400]

Envoyé par m4k-Hurrican

A moins que je ne me trompe, mais là il y aurait vraiment quelque chose qui m'aurait échappé, le changement de signature implique automatiquement la recompilation des programmes utilisant le programme de service concerné. Rien à voir avec l'EXPORT(*ALL). Si je me plante, je veux bien des explications, parce que pour ma part, c'est l'argument principal.

Un programme de service peut avoir plusieurs signatures comme indiqué plus haut, Signature 1 avec 2 procédures, Signature 2 avec 5 procédures, Signature 3 avec 6 procédures dont l'une a changé d'interface (de paramètre) etc...
Ce n'est pas Signature 1 OU Signature 2 mais bien Signature 1 ET Signature 2.
Pas besoin de recompiler les programmes existants qui utilisent ces procédures. Si un programme a été compilé en faisant référence au programme de service comportant la Signature 1, il fonctionnera toujours sans recompilation si le programme se service possède la Signature 1 et la Signature 2.

Envoyé par m4k-Hurrican

Parenthèse à ce sujet. Je développe pour d'autres OS et dans d'autres langages. On peut facilement assimiler le programme de service aux bibliothèques de fonction (comme les dll de Windows ou les librairies de la plupart des autres OS). Dans tous ces autres OS, la bibliothèque de fonction a une signature. Mais elle n'est pas bloquante à l'exécution, si la version est supérieure ou égale à la version demandée. Car les développeurs sont sensés garder une compatibilité ascendante. IBM n'a pas permis ce genre de chose, et c'est bien dommage. Moi je suis pour un n° de version, à condition que ce n° soit gérer de manière standardisée (Version Release Modification ?) et que les programmes puissent indiquer un niveau "minimum", ne générant pas d'erreur de signature si le programme de service est plus récent.

Exact, celà ressemble de très près aux DLL.
Mais IBM a permis d'avoir plusieurs signatures donc la compabilité est gérée, certes avec complexité, mais elle est gérée. Comme je l'ai déjà dis à plusieurs reprises, une procédure peut avoir 1 paramètre avec la signature 1 et 2 paramètres avec la signature 2 encore faut-il utiliser la technique d'IBM et pas celle de Scott Klement, d'où l'objet de mes réponses.

[hermellin]

bonjour,

Toujours a propos des MODULES et SRVPGM :

y a-t-il des règles générales de regroupement des PROCS au sein des MODULES
et de regroupement des MODULES au sein des SRVPGM ?

On peut imaginer des regroupements de procs de calcul, procs d'accès fichiers, procs sur DtaQueue, procs IFS etc etc...

Mais les regroupements des MOD dans les SRVPGM : quelles contraintes respecter ? Vous qui les créez au quotidien, quelles sont vos critères ?

Merci
Hermelin