Blocksize pour allocation de fichiers

**sam01** · 02/09/2008, 14h34

Pouvez-vous m'expliquer en détail la notion de bloksize lors de l'allocation d'un fichier.
De quelle façon peut-on optimiser un bloksize afin que le fichier prenne un minimum de place sur le disque ?
Quel est le lien entre le bloksize est la piste ?

Si le lrecl est à 27994 ( en FB) quel doit être son bloksize ?

Même question pour un VB .

Merci d'avance pour vos réponses.

**Homer-ac** · 02/09/2008, 19h25

Vaste débat, la réponse n'est pas si simple sans évoquer les évolutions matérielles.
Le Blocksize est pour faire court l'unité d'entrée/sortie. Plus le blocksize est grand, moins il y aurra d'interruption du programme pour appel programme canal.
On peut avoir intérêt à augmenter le buffer d'entrée sortie pour transférer plusieurs blocs et donc diminuer les appels canal (cf. JCL : BUFNO pour du QSAM, BUFND, BUFNI pour du VSAM).
Il faut être plus dubidatif pour les économies de place disque. Il faut comprendre que les unités disques 3380 / 3390 en architecture CKD (Count Key Data) ont pratiquement disparues. Elles sont simplement émulées via le controleur disques en z/OS. Derrière ce sont des disques FBA en RAID 5 ou 10 par exemple pour de l'Enterprise Storage Serveur IBM ou autres formes de RAID pour d'autres matériels.
Ces disques sont comparables avec les disques PC, sinon qu'ils sont plus rapides (10 à 15.000 rpm).
De plus les UC de contrôle disques ont évoluées et sont capables d'anticiper largement les entrés sorties en utilisant de la mémoire cache.
Vu du z/0S on voit des 3390 traditionnels (le plus souvent) mais ce n'est qu'une image virtuelle.
Avec SMS on peut allouer en kilo ou méga octets et avec une allocation traditionnelle en TRK ou CYL, il faut simplement retenir les contraintes d'émulation historiques. Donc que le blocksize doit être idéalement proche de limitation imposée par le demi octet contenu dans le DCB, soit X'7FFF' = 32767
en composant avec la taille d'une demi piste, pour rappel 47476 octets/piste pour un volume 3380 et 56664 octets/piste pour un volume 3390. Mais encore une fois il s'agit d'émulation matérielle.
Historiquement un REXX sur les sites permettaient de calculer un BLKSIZE optimum. A présent z/OS avec SMS fait ça très bien en spécifiant un BLKSIZE 0, C'est donc à mon avis toujours la meilleure solution.
Bref tout ça pour dire que BLKSIZE=0 est certainement le mieux et encore en essayant de faire simple !

**sam01** · 04/09/2008, 17h31

merci.

mais je dois avouer que je n'ai pas tout compris...

**Homer-ac** · 04/09/2008, 21h35

mais je dois avouer que je n'ai pas tout compris...

A présent SMS permet de gérer au mieux les fichiers sur disques, pardon, sur mémoire externe. La gestion SMS est devenue un métier à part entière. Mais pour l'utilisateur usuel, SMS a apporté pas mal de simplifications, BLKSIZE= 0 (c'est quand mème plus facile non ?) ou LIKE=un autre fichier.
Un produit de ce niveau ne se résume pas en quelques lignes. Si on est curieux et qu'on se balade dans l'interface SMS : ISMF on remarquera deux choses :
1) Le Help est assez bien fichu et donne une idée de l'impact de la quantité de paramètres possibles
2) Les ACS routines : 'les procédures des gestion internes', assez proches du REXX, permettent de corriger au mieux les 'écarts' de code JCL en fonction des critères et contraintes site.
Inutile de dire que je n'ai pas la prétention, d'expliquer en qques lignes tout ce qu'il peut y avoir dans ce produit ou les évolutions matérielles. Juste qu'il faut faire confiance aux 'métiers' et 'matériels'. Je m'avance un peu et je risque de me faire allumer, mais les volumétries sont devenues telles que l'on ne peut plus raisonner au niveau fichier mais au niveau typologie de fichier, les classes SMS et au final le 'Storage Group'. Donc Si tout le monde fait simple (BLKSIZE=0 pour la question), la majorité y gagnera. C'est le but recherché et la bonne cible.
Ceci dit je veux bien essayer de répondre à toute questrion précise sur ce sujet, mais on aborde des concepts plus vastes qu'un simples problème de taille de bloc. Les 'métiers' sont confrontés à d'autres priorités, disons multiplication volumétrie mémoire externes par 4 sur 3 ans. Si bien que pour aller pus loin, il faudrait adjoindre des rubriques explications produits dans ce forum.