problème d'écriture dans un fichier

**JauB** · 29/02/2012, 12h03

Bonjour,
On rencontre un problème sérieux ce matin.
En effet, on arrive pas à écrire dans un fichier via son logique.
en mode débogage lors de l'écriture on a le statut 24.
Sur Internet on lit que ce 24 signifie :

"Relative and indexed files only. Indicates a boundary violation. Possible causes:
Attempting to write beyond the externally defined boundaries of a file
Attempting a sequential WRITE operation has been tried on a relative file, but the number of significant digits in the relative record number is larger than the size of the relative key data item described for the file."
Mais je ne vois pas trop ce qu'on doit faire !
Si vous avez une piste les amis.
Merci d'avance.

**Hédhili Jaïdane** · 29/02/2012, 14h13

Bonjour.

Il faudrait nous donner un peu plus de détails sur le fichier sur lequel tu as le plantage.

Apparemment, le cas le plus fréquent, tu essaies d'écrire dans un fichier direct avec une valeur de la relative key dépassant le max autorisé (alloué) ou dans un indexé qui a atteint sa taille maximale et qu'il n'y a pas d'incrément possible. Je pense plus à ce deuxième cas puisque tu fais l'ajout à travers un logique. Si c'est le cas, fais un CHGPF du fichier physique en mettant plus d'enregistrements et d'incréments ou en mettant la taille à *NOMAX

Donne nous les messages CPF associés au problème.

**el_slapper** · 29/02/2012, 14h54

Marrant, j'ai eu le même hier sur un VSAM. L'exploit a trouvé(j'étais assez sec, moi aussi) : on allouait un VSAM à une certaine taille(1,2M de lignes), et on écrivait par programme dedans, ligne à ligne. Comme on avait 1,24M lignes, boum. Ils ont agrandi le fichier VSAM alloué, et tout a bien marché.

**JauB** · 29/02/2012, 15h30

Et comment on agrandit sa taille ?

**Hédhili Jaïdane** · 29/02/2012, 15h32

Envoyé par el_slapper

...boum. Ils ont agrandi le fichier VSAM alloué, et tout a bien marché.

Salut el_slapper.

En fait, le DB2 de l'AS/400 (et suivants) fait juste pchiiiiiiiit et demande ce qu'il faut faire pour ne pas perdre l'enregistrement en cours, sauf si on a interdit volontairement l'incrémentation de la taille.

(DB2/400 est en fait basé sur des fichiers SAM, DAM, ISAM et même SRC et les index secondaires)

**JauB** · 29/02/2012, 15h37

Bonjour,
il ne s'agit pas d'un problème de *NOMAX (le physique est déjà compilé avec le *NOMAX).

Si tu peux m'expliquer ceci "tu essaies d'écrire dans un fichier direct avec une valeur de la relative key dépassant le max autorisé (alloué)" ?? Ce max est il paramétrable ? Comment ?

Je n'ai pas de message, lorsque je débeugue le programme qui essaie d'écrire dans le fichier à problème, le statut du fichier est à 24 !

Envoyé par Hédhili Jaïdane

Bonjour.

Il faudrait nous donner un peu plus de détails sur le fichier sur lequel tu as le plantage.

Apparemment, le cas le plus fréquent, tu essaies d'écrire dans un fichier direct avec une valeur de la relative key dépassant le max autorisé (alloué) ou dans un indexé qui a atteint sa taille maximale et qu'il n'y a pas d'incrément possible. Je pense plus à ce deuxième cas puisque tu fais l'ajout à travers un logique. Si c'est le cas, fais un CHGPF du fichier physique en mettant plus d'enregistrements et d'incréments ou en mettant la taille à *NOMAX

Donne nous les messages CPF associés au problème.

**Hédhili Jaïdane** · 29/02/2012, 15h53

Envoyé par JauB

Et comment on agrandit sa taille ?

J'avais dit par la commande CHGPF :

Si c'est le cas, fais un CHGPF du fichier physique en mettant plus d'enregistrements et d'incréments ou en mettant la taille à *NOMAX

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
Physical file  . . . . . . . . . > MONFICHIER    Name                        
  Library  . . . . . . . . . . . >   MABIBLIO    Name, *LIBL, *CURLIB        
System . . . . . . . . . . . . .   *LCL          *LCL, *RMT, *FILETYPE       
Source file  . . . . . . . . . .   *NONE         Name, *NONE                 
  Library  . . . . . . . . . . .                 Name, *LIBL, *CURLIB        
Expiration date for member . . .   *SAME         Date, *SAME, *NONE          
Maximum members  . . . . . . . .   *SAME         Number, *SAME, *NOMAX       
Access path size . . . . . . . .   *SAME         *SAME, *MAX4GB, *MAX1TB     
Access path maintenance  . . . .   *SAME         *SAME, *IMMED, *REBLD, *DLY 
Access path recovery . . . . . .   *SAME         *SAME, *NO, *AFTIPL, *IPL   
Force keyed access path  . . . .   *SAME         *SAME, *NO, *YES            
Member size:                                                                 
  Initial number of records  . .   *SAME         1-2147483646, *NOMAX, *SAME 
  Increment number of records  .   *SAME         0-32767, *SAME              
  Maximum increments . . . . . .   *SAME         0-32767, *SAME              
Allocate storage . . . . . . . .   *SAME         *NO, *YES, *SAME

Soit tu mets "Initial number of records" à *NOMAX,
soit tu modifies le "Maximum increments" et "Increment number of records". A la création du fichier, ces paramètres sont à :

Code :

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

1
2
3
4
5
Member size:                                                           
  Initial number of records  . .   10000         1-2147483646, *NOMAX  
  Increment number of records  .   1000          Number                
  Maximum increments . . . . . .   3             Number

En mettant "Initial number of records" à *NOMAX, tu ne contrôles plus la taille.

A mon avis, le système t'a demandé via le programme ou l'utilitaire utilisé (DFU par exemple) si tu voulais faire une extension automatique pour l'enregistrement en cours ou pour un certain nombre d'enregistrements.

**JauB** · 29/02/2012, 16h06

J'ai demandé "comment augmenter la taille "car j'ai cru qu'il y a autre chose à augmenter autre que le *NOMAX au niveau du Initial number of records !

Donc je confirme qu'il ne s'agit pas du *NOMAX, il faut chercher sur autre chose !
Si vous avez d'autres pistes, je suis testeur

**JauB** · 29/02/2012, 16h21

Re,
on a réorganisé le fichier à problème, lors de la réorganisation on a eu le message suivant :

Limite mémoire atteinte pour membre MYFILE.

**JauB** · 29/02/2012, 16h21

Re,
on a réorganisé le fichier à problème, lors de la réorganisation on a eu le message suivant :

Limite mémoire atteinte pour membre MYFILE01.

N.B: MYFILE01 est un logique sur le physique MYFILE.

**Hédhili Jaïdane** · 29/02/2012, 16h29

- Tu n'as aucun message dans la joblog (DSPJOBLOG) où le programme s'exécute ?
- Ton fichier physique (parent du logique), il a été crée comment ? Il n'a tout de même pas dépassé les 2.147.483.646 enregistrements ?

Pour un fichiers direct, quand il est accédé en tant que tel par un programme cobol, si au moment du write la relative key contient un nombre supérieur à celui de la taille, il y a plantage et il n'y a pas de possibilité de l'agrandir automatiquement.

Mais comme tu as déjà mis *NOMAX et que tu y accède par un logique, je ne vois pas ce cas arriver.

Il reste peut être l'espace alloué aux chemins d'accès, paramètre ACCPTHSIZ dans la création du physique ou du logique, qui peut prendre les valeurs *MAX1TB ou *MAX4GB.

Number of records contained in a file member 4,294,967,294 records
.../...
For files with keyed sequence access paths, the maximum number of records in a member varies and can be estimated using the following formula: 2,867,200,000 / (10 + (.8 x key length))

**Hédhili Jaïdane** · 29/02/2012, 16h34

Tiens jette un coup d'oeil les database file sizes en V5R3 :
http://publib.boulder.ibm.com/infoce...bafoappmax.htm

**JauB** · 29/02/2012, 16h36

Comment je peux avoir cette relative key pour voir s'elle est vraiment supérieure à la taille du fichier ?

**Hédhili Jaïdane** · 29/02/2012, 16h43

Envoyé par JauB

Comment je peux avoir cette relative key pour voir s'elle est vraiment supérieure à la taille du fichier ?

Attends, il faut savoir si tu as un traitement de ce genre. Est ce que ton programme qui plante ou un autre programme concurrent, accède au fichier physique, en même temps, en le déclarant ORGANIZATION RELATIVE... RELATIVE KEY ?

**Hédhili Jaïdane** · 29/02/2012, 16h52

Je suis sur le CHAT DVP si ça t'intéresse, tu peux m'y rejoindre

**JauB** · 29/02/2012, 16h57

Bon, il s'agit d'un progiciel utilisé par plusieurs gestionnaires. Toutes les transactions se passent correctement sur tous les fichiers à part un seul fichier où l'écriture ne se passe pas !!

Le programme qui permet d'écrire dans ce fichier déclare le fichier comme :

ORGANIZATION INDEXED
ACCESS DYNAMIC

!

**JauB** · 29/02/2012, 17h15

J'y suis maintenant sur Développement des applicatifs.

Envoyé par Hédhili Jaïdane

Je suis sur le CHAT DVP si ça t'intéresse, tu peux m'y rejoindre

**Hédhili Jaïdane** · 29/02/2012, 17h22

D'accord.

Donc je pense que le fichier a atteint les limites permises par la version de ton OS.

En attendant, tu peux le vider des enregistrements inutiles en le déplaçant dans un autre fichier ou un autre membre du même fichier, dans ce dernier cas, attention aux logiques ! Ils sont par défaut basés sur tous les membres du physique. Cette possibilité peut s'avérer intéressante : physiquement les données sont dans plusieurs membres, mais les logiques accèdent à toutes.

Le multi-membre pose problème avec SQL (et l'intégrité référentielle). Pour SQL, il faut passer par les alias à chaque fois.

problème d'écriture dans un fichier

Cobol

Discussions similaires

Partager

Partager