Discussion :

[*_Cub_*]

Bonjour,

Je sollicite votre aide car je sèche sur un plantage cics assez étrange :
Voici le compte rendu d'un outil d'aide au débuggage au moment de l'erreur :

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
TRANID: E004      CICS ABEND: AEIV              
  001686        *EXEC CICS RECEIVE INTO (ZORECEP)                              
  001687        *                  LENGTH (LONGMAP)                            
  001688        *END-EXEC.                                                     
  001689             Call 'DFHEI1' using by content x'0402c0000700000014000040 
  001690        -    '00f0f1f4f4f2404040' by reference ZORECEP by reference    
  001691             LONGMAP end-call.                                         
The COBOL source code for data fields involved in the failure:                 
  Source                                                                       
  Line £                                                                       
  000081         77  LONGMAP             PIC S9(4)   COMP SYNC   VALUE +1000.  
  000083         77  ZORECEP             PIC X(1000).                          
Data field values at time of abend:                                            
  LONGMAP = 302                                                                
  ZORECEP = . AE003. N  SAISIE . ^SORTIE PREPARATION     .AH11/06/13.B/TOURNEE 
            NOTE: Above value truncated after 118 bytes.

Je plante sur un receive en AIEV, donc sur un problème de longueur. C'est logique car LONGMAP vaut 302 (!!). Pourtant cette variable n'est jamais modifiée dans le programme (!). Elle est initialisée à 1000. Ce plantage est assez rare (2 fois dans une journée sur des centaines d'utilisations du programme). Est-ce que ce problème vous évoque quelque chose ? Je vois que la variable de longueur (LONGMAP) est passée "by reference", est-ce que CICS modifie la valeur de la variable (si je passe plusieurs fois sur le receive) ?

(Quelques heures plus tard re-plantage... cette fois LONGMAP valait 266...)

Je vous remercie à l'avance.

[bernard59139]

Dans le programme, vérifie si il n'y a pas plusieurs RECEIVE avec LENGTH (LONGMAP).

Ca fait très longtemps que je n'ai pas fait du cobol cics...

[*_Cub_*]

Bonjour Bernard,

Merci de ta réponse.
J'ai effectivement plusieurs receive qui utilisent la variable LONGMAP dans le programme. Tu penses qu'un ordre receive est susceptible de modifier la valeur de la variable LONGMAP ? (je le soupsonne comme la variable est passée "by reference")

Je vais simplement tenter un move 1000 to longmap juste avant le receive qui plante.

[bernard59139]

la piste de plusieurs receive est à creuser.
Extrait de la doc:

LENGTH(data-area)
specifies the length, as a halfword binary value, of the data transmitted.
If you specify the INTO option, but omit the MAXLENGTH option, the argument must be a data area
that specifies the maximum length that the program accepts. If the value specified is less than zero, zero is assumed.
If the length of the data exceeds the value specified, but the NOTRUNCATE option is not specified, the data is truncated to that value and the LENGERR condition occurs. When the data has been received, the data area is set to the original length of the data.
If you specify the SET option, the argument must be a data area. When the data has been received, the data area is set to the length of the data.

Un simple suivi avec CEDF devrait confirmer cette piste.

[*_Cub_*]

C'est bien ça.
Quand je reviens d'un

Code :

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

1
2
3
MOVE 1000 TO LONGMAP
EXEC CICS RECEIVE INTO (ZORECEP)      
                  LENGTH (LONGMAP)

LONGMAP est bien modifié avec la taille réelle de ce qui a été reçu. (J'ai fait un petit test et LONGMAP vaut 249 après le receive.)
Et on plante dans le receive suivant car le developpeur pense que longmap vaut toujours 1000.

Encore merci pour le coups de main.