Hi Peter,

On the issue of confusion in respect of model DSCBs and SMS, my question would 
be "Why bother to set up a model DSCB."

Over three decades ago it was realised that a generic model data set could be 
used instead of a model DSCB, so many installations defined such a generic data 
set, i.e. SYS1.MODSCB, with zero track allocation.

The advantage of this method at the time was that it avoided VTOC pollution, as 
volumes where much smaller and hence so were VTOC sizes. Model DSCB creation 
could generate VTOC full conditions even when there were large amounts of free 
space on the volume. The disadvantage is that whilst the catalogue data set 
name had to be coded on the DD statement, so did the other DCB parameters to 
override those of the model data set. This lead to coding like:

//  DCB=(SYS1.MODSCB,LRECL=80,RECFM=FB,BLKSIZE=3600)

With modern disks and larger VTOCs the VTOC pollution is less likely to occur 
unless people are creating large numbers of small data sets, so I guess actual 
model DSCBs are more viable, and could theoretically reduce the number of 
parameters on the DD statement if there were a model or pattern explicitly 
created for each GDG with the appropriate DCB attributes. If this is a valid 
reason then it mitigates the use of SMS DATACLAS In preference I believe.

The discussion on how to create a model or patter DSCB is on Page 499 of the 
z/OS SMS Using Data Sets manual.

Kind regards - Terry

Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK

Tel: +44 (0)114 262 0933
WEB:
www.legac-e.co.uk


Reg: England & Wales 3767263 at the above address

All outgoing E-mails are scanned but it remains the recipients responsibility 
to ensure that their system is protected from viruses, trojans, worms, and 
spy-ware.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to