Discussion :

[sam01]

Bonjour,

j'aimerais faire de très nombreuses allocations de tout petit fichiers.

Mon but est de perdre le moins d'espace possible.

Mon cas concret est le suivant :

500000 fichiers en VB de 20 lignes avec un LRECL de 7800.

Si je fais un calcul simple :

7804 * 20 = 15680 soient 15 Kb.

Quelle serait l'allocation optimale pour ces fichiers ?

SPACE=(TRK,(1,0)) ?

Un piste fait 56kb il me semble... Cela signifie que je suis déjà surdimensioné...

ou bien dois-je allouer en BLK ?

Merci d'avance pour votre aide ?

[bernard59139]

Une allocation ne fera jamais moins d'une piste, quelque soit la méthode l'allocation.

Et avec du VB, il faut se méfier. il faut prendre le lrecl_moyen+4 (le +4 c'est pour tenir compte du RDW qui informe le système de la longueur du record ).

[Metalman]

Je ne suis pas expert du tout, mais, ne serait-ce pas dans ces cas-là que des VSAM/IDCAMS seraient utiles ?
Un seul gros VSAM est enregistré sur le disque, et de multiples entrées sont effectuées dedans ?

EDIT : Ou un gros PDS ! Mais ils auront tous le même RECFM et LRECL il me semble...

[bernard59139]

2 remarques

Une allocation ne fera jamais moins d'une piste, quelque soit la méthode l'allocation.

sauf allocation de type SPACE=(TRK,(0,..))

Un seul gros VSAM ... ou PDS

ou une table db2....

++

[sam01]

Bonjour bernard59139 et merci pour tes réponses.

En fait je compte passer par une ACS routine DATACLASS pour que les fichiers aient une taille minimum.

Dans la dataclass, on met l'espace primaire et secondaire en Kb

Je pourrais mettre par exemple :

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
CDS Name  . . . : ACTIVE                                                   
Data Class Name : DATAF                                                    
                                                                           
Description : PETITS FICHIERS               
                                                                           
Recfm  . . . . . . . . . :                                               
Lrecl  . . . . . . . . . :                                               
Override Space . . . . . : YES                                              
Space Avgrec . . . . . . : K                                               
      Avg Value  . . . . :                                            
      Primary  . . . . . : 56000                                            
      Secondary  . . . . :                                      
      Directory  . . . . :                                                 
Retpd Or Expdt . . . . . :                                                 
Volume Count . . . . . . : 1                                               
Add'l Volume Amount  . . :

[bernard59139]

avec 56k, tu alloueras 2 pistes.

En primary qte, met une valeur <= 55k.

[sam01]

j'avoue que j'ai un peu de mal à faire la différence entre les allocations en piste et celles en blocks....

Voici mon cas concret, j'ai un fichier de VB LRECL=6400 et BLKSIZE=27998 qui contient 36 enregs. Ce qui fait 6404*36 = 230544 bytes. Soient : 230 Kb
Sachant qu'une piste fait 56kb, il me faut donc 230/56 = 4,1 TRACKS

(corrigez-moi si mon calcul est faux...)

Quand on regarde le fichier, il est définit comme tel :

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

General Data                           Current Allocation                   
  Management class . . : **None**        Allocated blocks  . : 2             
  Storage class  . . . : HRFCDE          Allocated extents . : 1             
  Volume serial . . . : PGFRPC                                             
  Device type . . . . : 3390                                                
 Data class . . . . . : **None**                                            
  Organization  . . . : PS             Current Utilization                  
  Record format . . . : VB              Used blocks . . . . : 1             
  Record length . . . : 6400            Used extents  . . . : 1             
  Block size  . . . . : 27998                                              
  1st extent blocks . : 2                                                  
  Secondary blocks  . : 998            Dates                                
  Data set name type  :                 Creation date . . . : 2011/11/24    
  SMS Compressible. . : NO              Referenced date . . : 2011/11/24    
                                        Expiration date . . : ***None***

On voit que ce fichier est alloué en block...

Mais quant je regarde au catalogue, je vois :

Code :

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

1
2
3
4
5
6

Command - Enter "/" to select action                        Tracks %Used   XT 
------------------------------------------------------------------------------
         VBGCFR.FGDSTR.FRGRSE.CFD                             1  100     1 
***************************** End of Data Set list ***************************

Ici on voit que seule une piste est utilisée...

Ma question est quelle est l'allocation optimale pour une tel fichier ?

[bernard59139]

Il faut calculer la longueur moyenne des records...

Et vérifier s'il'y a (ou pas) de compress.

bon week-end

[sam01]

pas de compress...

Longueur moyenne : 6404

[M.Dlb]

Si longueur moyenne = longueur maximale, il n'y a pas d'intérêt à utiliser du VB, un FB ferait très bien l'affaire, surtout si tous les records sont "pleins".

De cette façon, ton calcul plus haut semble être juste, il faudrait bien plus de 4 tracks pour ce fichier, mais 1 seul est alloué par z/OS. Si il n'y a pas de compression, la seule explication que je verrais est que les records ne font pas tous 6400 octets.