DSNTYPE=LARGE et utilisation

Bonjour à tous,

les fichiers devenant de plus en plus en gros ainsi que la capacité des disque (Model 9, 27 etc..), j'aimerais savoir si vous utilisez ce paramètre de JCL : DSNTYPE=LARGE.
Si j'ai bien compris, il permet de dépasser la limite des 65535 tracks.

Mais j'aimerais savoir s'il y a des contre indication à utiliser ce genre de paramètre ? Sinon, pourquoi ne pas l'utiliser systématiquement pour tous les fichiers ?

Et quand vous utiliser ce paramètres, quelle est l'allocation que vous donnez ?

Pour vous donner un exemple, j'ai un fichier :

XW.YYY.BIG qui fait : 584130 tracks

Code:

---

1 2 3 4 5 6

Command - Enter "/" to select action Tracks %Used XT ------------------------------------------------------------------------------- XW.YYY.BIG 584130 99 83 ***************************** End of Data Set list ****************************

---

Voici ces caractéristques :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Data Set Name . . . . : XW.YYY.BIG General Data Current Allocation Management class . . : XDDBDUP Allocated cylinders : 38,942 Storage class . . . : XDDBDUP Allocated extents . : 83 Volume serial . . . : XDU012 + Device type . . . . : 3390 Data class . . . . . : XDSEQ Organization . . . : PSU Current Utilization Record format . . . : VB Used cylinders . . : 38,942 Record length . . . : 27994 Used extents . . . : 83 Block size . . . . : 27998 1st extent cylinders: 1000 Secondary cylinders : 1000 Dates Data set name type : Creation date . . . : 2014/08/30 Referenced date . . : 2014/09/02 Expiration date . . : ***None*** To display multiple volumes press Enter or enter Cancel to Exit.

---

L'allocation dans le JCL de ce fichier est la suivante :

Code:

---

1 2 3

//XGEP DD DSN=XW.YYY.BIG,DISP=(,CATLG,DELETE), // SPACE=(CYL,(1000,1000),RLSE),VOL=(,,,17),

---

vous pouvez voir qu'il n'y a pas de DSNTYPE=LARGE (ni dans la dataclass qui lui est affectée)

et voici comment le fichier est alloué sur les différents disque :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

XW.YYY.BIG 60030 100 12 XW.YYY.BIG 28335 100 7 XW.YYY.BIG 27225 99 5 XW.YYY.BIG 64800 100 10 XW.YYY.BIG 60000 100 5 XW.YYY.BIG 64800 100 10 XW.YYY.BIG 38820 100 9 XW.YYY.BIG 60000 100 4 XW.YYY.BIG 60120 100 13 XW.YYY.BIG 60000 100 4 XW.YYY.BIG 60000 100 4

---

Le fichier s'est planté à plusieurs reprise en E37...

J'aimerais savoir s'il existe une allocation optimale pour ces gros fichiers afin d'éviter ces plantages.

Dans ma shop on alloue parfois des fichiers dépassants les 65535 tracks sur un seul volume(M9,27 ou 54).
biensur on utilise le paramètre DSNTYPE=LARGE.

sur un des livre IBM on peut lire :


//SYSUT2 DD UNIT=SYSDA,DSNAME=BIGPROJ.BIGDATA,DSNTYPE=LARGE,
// SPACE=(TRK,(80000,40000))
The SYSUT2 DD statement creates a single-volume data set that contains more than 65535 tracks. Space units such as cylinders, megabytes, or average record size can be used instead of counting tracks. A data class (DATACLAS) with a DSNTYPE value of LARGE can be coded instead of DSNTYPE=LARGE. While SMS is running, you can use a data class for a new data set that will not be SMS-managed.

À part l'ajout du paramètre DSNTYPE=LARGE et la grosseur du volume, je ne pense pas qu'il y a une considération particulière à tenir en compte.

Bonjour

avec les fichiers "LARGE", faire (un peu) attention:

1. au support par les programmes. Certains programmes ne supportent pas (par ex, si tu es encore en db2 9). Vu que ton fichier est en DSORG=PSU, assez rare comme dsorg, je suspecte un programme particulier.
2. aux temps de réponses, normalement c'est assez transparent mais on ne sait jamais.

Mais surtout, il faut d'avoir assez de place disponible pour allouer tous tes fichiers, celui en cause et les autres.

Sans dsntype=large, l'allocation opti est CYL,(273,273)). Si ca plante, c'est qu'il y a un problème d'espace disque à gérer par les admin.
en primaire, tu peux mettre un multiple de 273.
Avec LARGE, à voir selon ton espace disque. Mais sans dépasser 65535 tracks en primaire ou en secondaire.

Citation:

---

Envoyé par bernard59139

Sans dsntype=large, l'allocation opti est CYL,(273,273)). Si ca plante, c'est qu'il y a un problème d'espace disque à gérer par les admin.

---

Avec DSNTYPE=LARGE quelle est alors l'allocation optimale ?

Citation:

---

Envoyé par bernard59139

Avec LARGE, à voir selon ton espace disque. Mais sans dépasser 65535 tracks en primaire ou en secondaire.

---

Pourquoi ne pas dépasser 65535 tracks, puisque DSNTYPE=LARGE permet justement cela ?


Autre chose, suite à la remarque de Trexx,

Citation:

---

The SYSUT2 DD statement creates a single-volume data set that contains more than 65535 tracks.

---

Ca signifie que lorsque l'on met DSNTYPE=LARGE, le fichier ne peut pas devenir un multivolume ? Il ne va que sur un volume ?

Si c'est ça, ça change tout...

Citation:

---

Avec DSNTYPE=LARGE quelle est alors l'allocation optimale ?

---

C'est à toi de choisir...

Citation:

---

Pourquoi ne pas dépasser 65535 tracks, puisque DSNTYPE=LARGE permet justement cela ?

---

je me suis trompé, désolé..

Code:

---

The SYSUT2 DD statement creates a single-volume data set that contains more than 65535 tracks.

---

C'est l'exemple de la doc. très simple.
Dans l'exemple, il y a

Code:

---

UNIT=SYSDA

---

, donc, c'est un seul VOLSER.
Très souvent, les ajouts de volume se font par des processus automatiques gérés par des logiciels (x37) ou certaines facilités sms, proccessus qu'ibm ignore souvent dans les exemples.
consulte la doc , DFSMS Using Data Sets le paragraphe Processing Large Format Data Sets

Parmi les 18 volume disponible,

j'ai deux volume model 27 et 16 model 9.
J'aimerais, lors de l'allocation, que le fichier aille d'abord remplir les disques model 27, ensuite quand ceux ci seront remplis, utiliser les disques model 9.

Existe-t-il un moyen cela ?

je pense que l'allocation théorique optimale pour les disque model 27 serait de space=(cyl(2047,2047))

Par contre, il me semble qu'il y a une histoire d'espace contigu disponible...

S'il sagit d'un pool SMS (c'est le cas je pense), il faut mettre les models 9 à l'état QUINEW.

QUINEW : Si, dans le pool, les autres volumes ont atteints leurs seuils de remplissage, on peut alors allouer sur ce volume.

on peut faire ça de 2 façons, via ISMF ou bien dynamiquement via SDSF :

la commande à passer, pour chacun de tes volumes M9, sous sdsf est la suivante :

/V SMS,VOL(volser),Q,N

cette commande change le status du volume 'volser' pour 'QUIESCE NEW', c à d que les fichiers déjà alloués peuvent avoir d'autres extents, mais z/OS n'allouera aucun nouveau fichier sur ce volume tant qu'il y a de l'espace sur les autres volumes du pool.

à la fin il faut remettre les volumes à leur status 'Enable', voici la commande :

/V SMS,VOL(volser),E

mettre des disques en QUINEW ne doit pas être fait sans une analyse préalable, et doit être fait avec l'accord des admin.
Il faut surtout tenir compte des autres fichiers, et là ca dépend de l'environnement.

Ton idée est pas mal Trexx, mais je suis un peu d'accord avec bernard59139.
Faut faire attention aux éventuels dommages collatéraux avec une commande comme celle-ci.
C'est un peu prendre un bazouka pour tuer une mouche.
C'est étonnant qu'il n'y ait pas d'autres solution plus simple..
J'avais pensé à utiliser dans le JCL : vol=ser=(vol1,vol2,vol3,vol4,vol5...)

Reste à savoir s'il choisit bien les volumes de façon séquentielle les uns après les autres..

Normalement, avec sms, ca sert à rien de coder les volser .

Exact. SMS a le plein control sur ses pool et il ignorera toujours ton énoncé vol=ser=(vol1,vol2,...) sauf si tu utlilse une Storage class avec l'attribut 'Guaranteed space' à YES.

Bonjour à tous

Comme le fait remarquer bernard59139, le fichier donné en exemple est PSU. Ce type de fichier ne peut être SMS.

Page 329 de la doc IBM "DFSMS Using Data Set" il est spécifié :

"Unmovable data sets cannot be system managed."

Il me semble que les fichiers déclarés UNMOVABLE contiennent des données physiques (TTR) qui pointent sur une autre partie de ce fichier.

Avant de répondre plus complètement à la question DSNTYPE=LARGE, je souhaite connaître quel est le logiciel qui crée ce fichier.

Cordialement

Bonjour egshuml,

c'est un programme maison qui créé ces fichiers.
Mais il me semble qu'il est SMS puisque qu'il a une dataclass.

Autre chose bizarre, ce programme qui créé ces fichier génère des fichier en PSU dans certains environnements tandis que dans les autres, ils sont en PS. Et pourtant c'est le même programme.

J'ai juste remarqué une chose, c'est que les fichier en PSU sont beaucoup plus volumineux que les fichier en PS. Mais je ne sais pas s'il y a un lien.

Citation:

---

il me semble qu'il est SMS puisque qu'il a une dataclass

---

presque normal.
Quand le fichier est alloué dans le jcl, il est trappé par sms vu qu'il n'y a pas de dsorg=psu. SMS alloue le fichier sans problème.
ensuite, le programme travaille, et c'est lui qui doit forcé le dsorg=PSU.

Citation:

---

Et pourtant c'est le même programme.

---

là, ca demande une vérification.
Est-ce la même version de programme? et de sous-programme.
Faut ensuite vérifier certains processus d'allocation de fichiers (exit, stopx37 qui permet certains trucs).

Citation:

---

les fichier en PSU sont beaucoup plus volumineux que les fichier en PS

---

pour le même nombre de records?
et en copiant le fichier en PSU dans un fichier en PS, ca donne quoi?

Bonjour Bernard59139,

les fichiers sont énormes, je ne peux en copier un pour le test, il n'y a pas la place nécessaire.

A moins de faire un skip count...

j'ai vérifié rapidement, je ne pense pas que PSU soit plus consommateur que PS.

A part cela, les LRECL et RECFM sont-ils identiques dans chacun des environnements?

Les LRECL et BLKSIZE sont rigoureusement identiques.

J'ai fait une copie avec skip just de 4 lignes sur un fichier PS, et la copie se passe bien et le fichier en sortir reste en PS.