Discussion :

[midonet7]

Utilité des Blocs dans les programmes et JCL

Bonjour,
Je voudrai savoir l’utilité des blocs dans les JCLs et programmes en Cobol :
Par exemple

Code :

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

1
2
3
JCL : DCB=(RECFM=FB,LRECL=200,BLKSIZE=32600)
Et au niveau de FILE SECTION du programme BLOCK CONTAINS  163 RECORDS

Est-ce qu’il permet de simplifier la lecture d’un fichier ?

Merci d’avance !

[Darkzinus]

Bonjour,

Je les fixe toujours à Blocksize = 0. C'est le JCL qui alloue dynamiquement les blocs (optimise l'écriture dans les fichiers). C'est a priori plus performant.

En FD : BLOCK CONTAINS 0 CHARACTERS

et dans le JCL BLKSIZE=0

[midonet7]

Bonjour,

Je les fixe toujours à Blocksize = 0. C'est le JCL qui alloue dynamiquement les blocs (optimise l'écriture dans les fichiers). C'est a priori plus performant.

En FD : BLOCK CONTAINS 0 CHARACTERS

et dans le JCL BLKSIZE=0

Merci Darkzinus pour la réponse,

Sinon par rapport "l'optimisation de l'écriture dans les fichiers" cela veut dire ==> Ecriture de plusieurs enregistrements (lignes) en même temps ?

[Darkzinus]

IBM l'explique mieux que moi

http://www-01.ibm.com/support/knowle...lo.htm?lang=fr

Mais le plus simple c'est de prendre pour acquis le 0 pour le BLKSIZE (rajouter cette clause dans le programmes sur consignes de l'exploitation a fait gagner en performances) qui évite de calculer soi-même un optimum incertain.

[midonet7]

THANK YOU !

[Pico-----]

Bonjour,

Pour beaucoup simplifier : le bloc correspond au buffer de lecture/ecriture sur le disque.
Le BLKSIZE fait donc référence à la taille du buffer que l'on veut utiliser.

En JCL, cette taille doit être exprimée en octets. En COBOL, on peut mettre soit la taille en octet soit en nombre d'enregistrements qui sont décrits en FILEquelquechose (j'avoue, je le fais de tête, mais je n'ai plus fait de COBOL depuis 5-6 ans).
Depuis quelques temps déjà c'est une valeur pris en charge par défaut par le système quand elle n'est pas renseignée ou mis à 0 (voire quand elle est mal renseignée) donc souvent on ne la renseigne plus.

Pour aller un peu plus loin : c'est le buffer qu'on veut utiliser mais il y a quelque contraintes.
Déjà il doit être inférieur ou égale à la plus petite unité physique utilisable (même si c'est de l'émulation de nos jour), exemple : sur un volume 3390-1, il y a 1113 cylindres avec 15 pistes (tracks) de 2 demi pistes de 27 920 octets utilisables.
Ensuite dans le cas d'enregistrements fixe (RECFM=FB ou FBA), le bloc doit être un multiple de la taille de l'enregistrement (pour pas écrire du blanc ou des moitiés d'enregistrement).

Donc pour être propre, sur un 3390-1, il faut mettre en blocksize le plus grand multiple de la taille de l'enregistrement en dessous de 27920. EASY !

Clairement, même si c'est géré en automatique la plupart du temps, j'ai déjà vu des sites où la valeur par défaut hors prod était "foireuse" : le blksize induit le nombre d'accès "physique" qui sont très gourmand en elapsed, si c'est mal taillé, sur de la haute volumétrie cela peut considérablement pourrir les temps de traitements...

[bernard59139]

Bonjour

En laissant le système gérer les blksize, par rapport à des blksize exotiques, les gains peuvent être assez énormes en:

• taille en pistes. quand on a mis en place cette fonctionnalité, les gains ont atteints parfois 30% en tracks
• elaps-time (temps de traitement)
• cpu-time

Sauf si vous avez des besoins "exotiques", et comme le disent les collègues du forum, le mieux est de laisser le système gérer.

B59

ps: si ca interesse qqun, j'ai une page html(avec javascript) qui donne une idée des gains/pertes selon le LRECL et le BLKSIZE.

[bernard59139]

si les info données au départ reflètent ce qui existe sur disque (Lrecl=200, blksize =32600)

le système écrira 1 block de 32600 écrit par piste, et donc 163 records par block ou par piste.

Avec le blksize optimisé de 27800, le système écrira 2 block par piste, et donc, 278 records par piste.

Donc, par rapport à l'optimal, le fichier occupe près de 70% d'espace disque en plus.

a+

[Pico-----]

si les info données au départ reflètent ce qui existe sur disque (Lrecl=200, blksize =32600)

le système écrira 1 block de 32600 écrit par piste, et donc 163 records par block ou par piste.

Avec le blksize optimisé de 27800, le système écrira 2 block par piste, et donc, 278 records par piste.

Donc, par rapport à l'optimal, le fichier occupe près de 70% d'espace disque en plus.

a+

J'avoue : j'ai pas compris...
Peux tu expliquer plus, stp ?

[bernard59139]

Bonjour

je vais essayer de faire simple.

Avec des disques modèle 3390, une piste peut contenir 56Ko max.
Avec des blocks de 32Ko , il n'y aura qu'un seul bloc par piste, soit un espace inutilisé 24 Ko ( 56Ko - 32Ko= 24Ko). Cet espace inutilisé n'apparait pas en 3.4 dans la colonne %use.

A chaque bloc écrit, le système y ajoute des octets de contrôle (le GAP, 232 octets si j'ai bien relu mes notes).

Toute l'astuce est de remplir au maximum une piste avec des données utiles, donc:

• blksize maxi
• pour un espace inoccupé réduit au minimum

En simplifiant au maximum, et comme dit par les collègues ci dessus, il faut avoir des blksize qui se rapprochent de 1/2 piste, soit 27998 octets, mais sans dépasser (27999 et tu as un espace inutilisé de 27997 octets par piste).

j'ai écrit les 2 petits trucs il y a plus de 10 ans.
Pour comprendre les calculs, plongeon obligatoire dans la doc système.

Tout cela n'est valable que pour des séquentiels simples (pas compressés, recfm=FB).

a+

[midonet7]

Bonjour

je vais essayer de faire simple.

Avec des disques modèle 3390, une piste peut contenir 56Ko max.
Avec des blocks de 32Ko , il n'y aura qu'un seul bloc par piste, soit un espace inutilisé 24 Ko ( 56Ko - 32Ko= 24Ko). Cet espace inutilisé n'apparait pas en 3.4 dans la colonne %use.

A chaque bloc écrit, le système y ajoute des octets de contrôle (le GAP, 232 octets si j'ai bien relu mes notes).

Toute l'astuce est de remplir au maximum une piste avec des données utiles, donc:

• blksize maxi
• pour un espace inoccupé réduit au minimum

En simplifiant au maximum, et comme dit par les collègues ci dessus, il faut avoir des blksize qui se rapprochent de 1/2 piste, soit 27998 octets, mais sans dépasser (27999 et tu as un espace inutilisé de 27997 octets par piste).

j'ai écrit les 2 petits trucs il y a plus de 10 ans.
Pour comprendre les calculs, plongeon obligatoire dans la doc système.

Tout cela n'est valable que pour des séquentiels simples (pas compressés, recfm=FB).

a+

Je vous remercie Bernard et Pico pour les informations et les documents très intéressants !!