Discussion :

[m4k-Hurrican]

Bonjour, il m'arrive un truc qui commence à ressembler pour moi à un bug IBM, mais avant de les appeler pour signaler un souci grave, je préfèrerais vous demander votre avis. Pas envie de passer pour un clown si c'est moi le responsable.
Voilà, j'ai un module chargé de récupérer des valeurs dans un enregistrement, et de les retourner à des programmes chargés d'imprimer, afficher, etc... Bref un simple petit Select Into que voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
D get_Ent_Rcd     PI            10i 0                                      Code retour       
D   P_CodSoc                     1    Const                                Code société      
D   P_CodEnt                     2    Const                                Code Entrepôt     
D   P_NOM                       30    Options(*varsize)                    Retour: Nom       
D   P_RU1                       30    Options(*varsize)                    Retour: Rue 1     
D   P_RU2                       30    Options(*varsize)                    Retour: Rue 2     
D   P_CPO                        5    Options(*varsize)                    Retour: C.Post    
D   P_VIL                       25    Options(*varsize)                    Retour: Ville     
D   P_MAI                       50    Options(*varsize)                    Retour: EMail     
D   P_TEL                       20    Options(*varsize)                    Retour: Tél.      
D   P_FAX                       20    Options(*varsize)                    Retour: Fax       
D                                                                                            
D retcod          s             10i 0 Inz(0)                               Code retour       
D                                                                                            
C* ========================================================================                  
 /Free                                                                                       
                                                                                             
  // Lit l'enregistrement correspondant                                                      
  Exec SQL                                                                                   
    Select ENTNOM, ENTRUE1, ENTRUE2, ENTCPOS, ENTVILLE, ENTTELGEN,                           
           ENTFAXGEN, ENTEMAIL                                                               
      into :P_NOM, :P_RU1, :P_RU2, :P_CPO, :P_VIL, :P_TEL, :P_FAX, :P_MAI                    
    From   ELSOCODB/ENTREPOT                                                                 
    Where  ENTCODSOC = :P_CodSoc and ENTCODE = :P_CodEnt;

Le hic, c'est que lors de la lecture, j'ai 2 zones, en l'occurence P_NOM et P_TEL, dont le début est écrasé par des blancs. Les 2 premiers caractères pour P_NOM, les 4 premiers pour P_TEL. Exemple :
Si la valeur réelle de P_NOM est 'ABCDEF' je trouve dans cette variable ' CDEF' juste après la lecture.

Voici le fichier utilisé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE TABLE ELSOCODB.ENTREPOT ( 
	ID FOR COLUMN ENTID      SMALLINT GENERATED ALWAYS AS IDENTITY ( 
	START WITH 1 INCREMENT BY 1 
	NO MINVALUE NO MAXVALUE 
	NO CYCLE NO ORDER 
	CACHE 20 ) 
	, 
	CODE_SOCIETE FOR COLUMN ENTCODSOC  CHAR(1) CCSID 1147 NOT NULL DEFAULT '' , 
	CODE FOR COLUMN ENTCODE    CHAR(2) CCSID 1147 NOT NULL DEFAULT '' , 
	NOM FOR COLUMN ENTNOM     CHAR(30) CCSID 1147 NOT NULL DEFAULT '' , 
	RUE1 FOR COLUMN ENTRUE1    CHAR(30) CCSID 1147 NOT NULL DEFAULT '' , 
	RUE2 FOR COLUMN ENTRUE2    CHAR(30) CCSID 1147 NOT NULL DEFAULT '' , 
	CODE_POSTAL FOR COLUMN ENTCPOS    CHAR(5) CCSID 1147 NOT NULL DEFAULT '' , 
	VILLE FOR COLUMN ENTVILLE   CHAR(24) CCSID 1147 NOT NULL DEFAULT '' , 
	TELEPHONE FOR COLUMN ENTTELGEN  CHAR(20) CCSID 1147 NOT NULL DEFAULT ' ' , 
	TELECOPIE FOR COLUMN ENTFAXGEN  CHAR(20) CCSID 1147 NOT NULL DEFAULT ' ' , 
	EMAIL FOR COLUMN ENTEMAIL   CHAR(50) CCSID 1147 NOT NULL DEFAULT '' , 
	CREATED_AT FOR COLUMN ENTCRTAT   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP , 
	UPDATED_AT FOR COLUMN ENTUPDAT   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP , 
	UPDATED_BY FOR COLUMN ENTUPDBY   CHAR(10) CCSID 1147 NOT NULL DEFAULT '' , 
	CONSTRAINT ELSOCODB.Q_ELSOCODB__ENTR0001__ENTID_00001 PRIMARY KEY( ID ) )   
	  
	RCDFMT "Entr0001" ;

Merci d'avance à ceux qui vont se prendre la tête.

[Hédhili Jaïdane]

Bonjour,...
Le hic, c'est que lors de la lecture, j'ai 2 zones, en l'occurence P_NOM et P_TEL, dont le début est écrasé par des blancs. Les 2 premiers caractères pour P_NOM, les 4 premiers pour P_TEL. Exemple :
Si la valeur réelle de P_NOM est 'ABCDEF' je trouve dans cette variable ' CDEF' juste après la lecture....

Bonjour.

Donc si je comprends bien, il y a un décalage à gauche des valeurs de certaines zones de 2 ou 4 octets.

Sans trop m'avancer, et comme je ne suis pas gapiste, je soupçonnerais une mauvaise utilisation des zones à longueur variable.

[m4k-Hurrican]

Non les valeurs ne sont pas décalées, elles sont remplies de blancs. Et ce dès la lecture par l'instruction SQL.
2 blancs pour la variable P_NOM, 4 pour la variable P_TEL.

[Hédhili Jaïdane]

ok.

Est ce que tu as un moyen d'afficher ces deux caractères en hexa, c'est peut être pas des espaces, mais la longueur effective de la zone NOM ?

[m4k-Hurrican]

Non ce sont bien des blancs. :/
J'affiche l'enreg par SQL, il est correct, je le récupère dans un SQLRPGLE il est bancal.
Et ce qui est dingue, c'est que ce sont les zones P_NOM et P_TEL exclusivement, alors qu'elles ont la même définition que les autres zones. P_NOM est strictement identique à P_RU1, ou P_RU2, et ¨P_TEL strictement identique à P_FAX. Pourtant ces zones sont récupérées intactes elles, pas de remplissage par des blancs en début de zone.

[FORMULARY]

Essaie de faire ton select ENTNOM into F_NOM définie de longueur fixe puis de faire un eval P_NOM = F_NOM
Juste pour voir

[m4k-Hurrican]

J'avais déjà eu cette idée et j'ai fais les tests.
La variable est alors correcte. Enfin, jusqu'au retour dans la procédure appelante. Là, les premiers caractères sont à nouveau écrasés.
J'ai un Options(*varsize) parce que les procédures appelantes ont parfois des tailles (fixe) de zone légèrement différentes, bridées par une taille d'affichage ou d'impression limitée.
J'y perd mon latin, je fais ce genre de choses tout le temps, çà marche ailleurs, et avec cette procédure (ou plutôt ce fichier) non.

[Hédhili Jaïdane]

Il n'y a pas une option de compilation VARCHAR qu'il faut mettre ?

[m4k-Hurrican]

Non il n'y a pas ce genre d'option de compilation.
Je n'ai pas envie de passer par des zones de taille fixe, qui vont m'obliger à gérer des variables intermédiaires dans les procédures appelantes.

De toute manière, il y a un souci. Pourquoi est-ce que la valeur récupérée dans la procédure appelante est différente de celle retournée par la procédure appelée ?
En l'occurence si je lit l'enreg dans des zones de taille fixe, pour ensuite remplir à l'aide d'un Eval la variable retournée (qui elle est donc définie avec options(*varsize), un debug me montre que la valeur est OK. Lors du passage sur le code Return, la valeur dans la variable P_NOM est correcte ('ABCDEF'). Si je passe à l'instruction suivante, et donc que je reviens dans la procédure appelante, la variable retournée est incorrecte (' CDEF').

[Hédhili Jaïdane]

Non il n'y a pas ce genre d'option de compilation....

Si, cette option existe bien. C'est l'un des paramètres de l'option CVTOPT des commandes CRTRPGMOD et CRTBNDRPG.

Les zones à longueur variable contiennent 2 octets en leur début qui contiennent la longueur effective de la zone. Si j'insiste dessus c'est que ça m'a joué des tours quand j'ai eu à gérer des zones VARLEN dans les DDS en provenance des tables.

[m4k-Hurrican]

Mes zones ne sont pas des zones à longueur variable.
Il n'y a pas de mot clé VARYING, et mes zones de fichier sont bien de type CHAR (taille fixe). Cette option de compilation ne concerne que ce type de données.
A ne pas confondre avec options(*varsize) ! Comme Scott Klement l'a dit un jour, VARYING aurait du être défini comme un type de donnée, pas comme un mot clé.

Bref, j'ai solutionné mon problème de manière bizarre. Mais çà fonctionne...
Je me suis aperçu que dans toutes les autres procédures appelantes les données échangées n'étaient jamais définies en dur dans les cartes D, mais provenaient de descriptions externes. Alors j'ai simplement déclaré le fichier en DS qualified, défini les zones avec Like(NomDeLaDS.NomDeLaZone), et là çà fonctionne.
Précision, j'ai revérifier dans les listings de compilation, les tailles et types de zones sont strictement identiques dans l'ancienne version qui ne fonctionnait pas et dans la nouvelle (Alpha 30 caractères pour P_NOM par exemple). Donc çà marche mais je sais pas pourquoi.

[Hédhili Jaïdane]

ok.

Le *varsize, dont je n'ai pas parlé, c'est pour les params et n'a rien à voir avec le varying et le varlen.

Sur ce, et bonne continuation.

[vincent.ng]

Bonjour,

ça fait un an que je ne fais plus de rpgle mais il me semble que quand on déclare *varsize il faut gérer la longueur réelle de variable passée par le programme appelant, me trompe je ? Tu dis n'avoir jamais eu de pb ailleurs et pourtant je suis persuadé d'avoir eu des problèmes similaires dans le passé.

[m4k-Hurrican]

Ah déterrage de post.
Tu as raison sur le fait qu'il faille gérer la longueur de la zone avec l'option *varsize, mais le problème n'est pas là.
C'est le début de la zone qui foirait, et pas la fin (symptomatique d'une longueur mal gérée). Et la manière dont j'ai résolu le souci, en définissant les zones dans des DS au lieu de variables isolées, semble bien pousser vers un bug. Étant toujours en V5R4, je n'ai pas contacté le support logiciel.