Discussion :

[sam01]

Bonjour,

lorsque l'on doit remplacer un nom de ficher par un DUMMY,

je ne sais pas jamais s'il faut mettre le DCB du fichier derrière le DUMMY,
ou s'il ne faut rien mettre du tout.

Cela dépend-t'il du programme utilisé ?

[Homer-ac]

Cela dépend effectivement du programme utilisé.
Le DCB est le bloc de contrôle représentatif de la méthode d'accès qui à l'OPEN va vérifier que le DCB du programme correspond au DCB donné dans le JCL.
Si c'est un programme non assembleur, disons un COBOL c'est normalement inutile. Ler runtime du langage alloueront dynamiquement le DCB qui va bien. Si c'est un Assembleur 'maison', il faudra souvent mettre de DCB dans le JCL correspondant au DCB programme, même pour un fichier Dummy sauf si c'est un assembleur très bien écrit (s'est généralement le cas des utilitaires standards MVS) qui crée correctement le DCB en s'appuyant sur le descriptif VTOC du fichier (DSCB).

[sam01]

OK,

le mieux serait de le mettre tout le temps alors ?

[Homer-ac]

Oui et non,
Il y a de moins en moins de 'vieux' ASM sur les sites. Donc pour des fichiers en entrée procéder par exception me semble aller bien. Pour des fichiers en écriture et c'est le plus souvent le cas des fichiers mis en Dummy, tu as sans doute raison.

[sam01]

Merci.

[Homer-ac]

s'agissant d'un aspect très théorique liée à la typologie des programmes pouvant être utilisés sur un site, il serait intéressant d'avoir d'autres avis personnels. Je pense en particulier à notre ami Bernard59139 qui a une bonne expérience et donc expertise, entre autres, sur la gestion des fichiers.

nb. Bernard à raison, les fichiers sont de plus en plus SMS, et il faut donc tenir compte de la dataclass pour les attributs lrecl ou autre.
D'autre part et pour être puriste, j'ai cité DSCB plus haut. C'est JFCB que j'aurai du écrire, même s'il en est une émanation. Un programme ne va en principe pas s'amuser à lire la VTOC et ses DSCB 1, il va plus simplement accéder au JFCB du fichier qui est le bloc en mémoire qui contient tout ce qu'il faut pour vérifier les caractéristiques d'un fichier alloué par TSO ou JES2 et en déduire au besoin le DCB à décrire. Il peut même par ce biais savoir si un fichier est Dummy, cela étant les ASM 'maison' ne s'embarassent le plus souvent pas de ça et on retombe sur le pb évoqué.

[bernard59139]

Bonjour

CA dépend, comme dit plus haut.

En général; il y a 3 cas:

1. le programme n'oblige pas de coder le dcb, et le système alloue le fichier avec un DCB optimum. cas le plus courant
2. le programme impose un dcb plus ou moins précis, recfm+lrecl; et parfois un blksize précis
3. le programme fait ce qu'il veut , quelque soit le dcb codé

Et ce, que le fichier soit en DUMMY ou pas.

Si tes modules sont des programmes COBOL==> l'option 1 quasi certain

Dans tous les autres cas, il faut trouver la documentation liée aux modules , ou se l'écrire.
Ne pas oublier qu'avec SMS il peut y avoir des dcb par défaut (la DataClass).

tout ça pour dire "ça dépend".