IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

z/OS Discussion :

DSNTYPE=LARGE et utilisation


Sujet :

z/OS

  1. #1
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    1 907
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 1 907
    Points : 411
    Points
    411
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : 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
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  2. #2
    Membre à l'essai
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    Janvier 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Janvier 2012
    Messages : 8
    Points : 19
    Points
    19
    Par défaut
    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.

  3. #3
    Membre chevronné Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2006
    Messages
    950
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Octobre 2006
    Messages : 950
    Points : 2 064
    Points
    2 064
    Par défaut
    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.

  4. #4
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    1 907
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 1 907
    Points : 411
    Points
    411
    Par défaut
    Citation Envoyé par bernard59139 Voir le message
    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 Voir le message
    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,
    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...

  5. #5
    Membre chevronné Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2006
    Messages
    950
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Octobre 2006
    Messages : 950
    Points : 2 064
    Points
    2 064
    Par défaut
    Avec DSNTYPE=LARGE quelle est alors l'allocation optimale ?
    C'est à toi de choisir...
    Pourquoi ne pas dépasser 65535 tracks, puisque DSNTYPE=LARGE permet justement cela ?
    je me suis trompé, désolé..
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 , 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

  6. #6
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    1 907
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 1 907
    Points : 411
    Points
    411
    Par défaut
    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...

  7. #7
    Membre à l'essai
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    Janvier 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Janvier 2012
    Messages : 8
    Points : 19
    Points
    19
    Par défaut
    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

  8. #8
    Membre chevronné Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2006
    Messages
    950
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Octobre 2006
    Messages : 950
    Points : 2 064
    Points
    2 064
    Par défaut
    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.

  9. #9
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    1 907
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 1 907
    Points : 411
    Points
    411
    Par défaut
    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..

  10. #10
    Membre chevronné Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2006
    Messages
    950
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Octobre 2006
    Messages : 950
    Points : 2 064
    Points
    2 064
    Par défaut
    Normalement, avec sms, ca sert à rien de coder les volser .

  11. #11
    Membre à l'essai
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    Janvier 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : Janvier 2012
    Messages : 8
    Points : 19
    Points
    19
    Par défaut
    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.

  12. #12
    Membre averti

    Homme Profil pro
    Consultant Informatique à la retraite
    Inscrit en
    Mars 2014
    Messages
    38
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 81
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Informatique à la retraite
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2014
    Messages : 38
    Points : 405
    Points
    405
    Par défaut
    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

  13. #13
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    1 907
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 1 907
    Points : 411
    Points
    411
    Par défaut
    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.

  14. #14
    Membre chevronné Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2006
    Messages
    950
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Octobre 2006
    Messages : 950
    Points : 2 064
    Points
    2 064
    Par défaut
    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.

    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).

    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?

  15. #15
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    1 907
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 1 907
    Points : 411
    Points
    411
    Par défaut
    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...

  16. #16
    Membre chevronné Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    Octobre 2006
    Messages
    950
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Octobre 2006
    Messages : 950
    Points : 2 064
    Points
    2 064
    Par défaut
    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?

  17. #17
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    1 907
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 1 907
    Points : 411
    Points
    411
    Par défaut
    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.

Discussions similaires

  1. [pdist] Utilisation avec une large matrice
    Par syki.mail dans le forum MATLAB
    Réponses: 1
    Dernier message: 27/02/2014, 15h33
  2. utiliser les tag [MFC] [Win32] [.NET] [C++/CLI]
    Par hiko-seijuro dans le forum Visual C++
    Réponses: 8
    Dernier message: 08/06/2005, 16h57
  3. utilisation du meta type ANY
    Par Anonymous dans le forum CORBA
    Réponses: 1
    Dernier message: 15/04/2002, 13h36
  4. [BCB5] Utilisation des Ressources (.res)
    Par Vince78 dans le forum C++Builder
    Réponses: 2
    Dernier message: 04/04/2002, 17h01
  5. Réponses: 2
    Dernier message: 21/03/2002, 00h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo