Mainframe, MVS and zOS Discussion

Over the years I've seen these two terms misused quite badly though I'm not sure if Generation and Version in GDG is winner by a good difference... .  Well, said that...

DCB is 'Data Control Block' specifies attributes of the records in the data-set. DCB parameters will be present only when creating a data set. There may be a few exceptions, but these will be determined by operating system requirements. You may use the DCB refer back when creating more than one data set with the same DCB characteristics.

A DSCB is a Data Set Control Block which represents an entry in the VTOC. There are several different types and generally what people see when they list a VTOC is the Format 1 DSCB. There are now 9 formats used, which include the supported Extended Addressability Volume [EAV] attributes.

The role of a model DSCB was specific only to generation data sets and represented a VTOC entry [which was allocated no space] to represent the basic attributes of the generation data set being created. This could be represented by any VTOC entry and often employed the use of the data set name in the DCB parameter [DCB=(HLQ.MDSCB)]

Model DSCB's do NOT exist as data sets. Catalog entries are simply an entry where a name is associated with a device type and volume serial number. If that name is not on the stated volume, then a S213 abend will occur, so catalogs are not any indication of existence.

Similarly a Format 1 DSCB that describes no space is simply a VTOC record entry. It also is inaccessible and only provides data set attribute information. As a result, the data set name being referenced, describing a model DSCB, does NOT exist.

To know more on DSCB read here: Data Set Control Block (DSCB) Types.


Long ago, before you can create the files that attach to a GDG base, you need to create a model data-set that contains the DCB information for the files. This model data just needs to be a VTOC entry, it does not need to actually use up disk space. It is possible to create a different model data-set for every possible DCB combination, and some sites actually do that, but this needs a lot of effort to maintain. Many sites use a single model data-set, and then override the DCB information to build the correct type of file. To create a model DCB, use a dummy IEFBR14 job like this:
The SPACE=(TRK,0) parameter means that this file will just be created as a VTOC entry, it will not use up disk space.

Said that, these DSCBs are no longer required if DFsms is installed and tailored correctly and most of the shops are "tailored correctly these days"!

The SPACE=(TRK,0) parameter means that this file will just be created as a VTOC entry, it will not use up disk space.

When it does not use up any space, does it really exist?

When it does not use up any space, does it really exist?

That depends upon how you define the term "really exist". If you dump the catalog, the data set will be there. If you dump the VTOC for the volume, the data set will be there. If you look for the data set on the volume, it will NOT be there. So maybe we should say the data set has 2/3 existence?

If you attempt to allocate and catalog another data set with the same name, the catalog entry will prevent you from doing so. If you attempt to allocate another data set with the same name on the same volume without using the catalog, the VTOC entry will indicate duplicate data set. But if you allocate another data set with the same name on a different volume without using the catalog, that data set will be allocated. This is all standard z/OS behavior, so I would say that the data set exists.

Robert Sample wrote:So maybe we should say the data set has 2/3 existence?

That's a classic statement!

DCB parameters will be present only when creating a data set.

DCB parameters are ALWAYS present and they are required to be coded within the program. These define the files that the program will use. The DCB parameter in the JCL is only used to override any values that have not been specified within the program. The general standard is that minimal information will be coded within the program to allow for more flexible specifications via JCL.

DSCB, on the other hand, also known as MLDSCB - "Model DCB".

Sorry, but that is completely wrong. A DSCB is a Data Set Control Block which represents an entry in the VTOC. There are several different types and generally what people see when they list a VTOC is the Format 1 DSCB. There are now 9 formats used, which include the supported Extended Addressability Volume [EAV] attributes.

The role of a model DSCB was specific only to generation data sets and represented a VTOC entry [which was allocated no space] to represent the basic attributes of the generation data set being created. This could be represented by any VTOC entry and often employed the use of the data set name in the DCB parameter [DCB=(HLQ.MDSCB)]

Model DSCB's do NOT exist as data sets. Catalog entries are simply an entry where a name is associated with a device type and volume serial number. If that name is not on the stated volume, then a S213 abend will occur, so catalogs are not any indication of existence.

Similarly a Format 1 DSCB that describes no space is simply a VTOC record entry. It also is inaccessible and only provides data set attribute information. As a result, the data set name being referenced, describing a model DSCB, does NOT exist.

Gerhard_Adam wrote:

DCB parameters will be present only when creating a data set.

DCB parameters are ALWAYS present and they are required to be coded within the program.  These define the files that the program will use.  The DCB parameter in the JCL is only used to override any values that have not been specified within the program.  The general standard is that minimal information will be coded within the program to allow for more flexible specifications via JCL.

The use of only is questionable in my statement. I'm not sure now why did I use it. Thank for correcting me. I have removed "only" in the first post. 

You're essentially correct about DSCB and MLDSCB.

I'll have to modify the original post to make it coherent including your remarks.

I have not seen DSCB being used. So is that like some people just decide about using it and some do not? Is there no rule?

I have not seen DSCB being used. So is that like some people just decide about using it and some do not? Is there no rule?

The requirement used to be that a model DSCB was required to create a new generation of a GDG. With the advent of system-managed storage (SMS), the necessity of using a model DSCB was eliminated since SMS does not support model DSCB. If you are creating generation data sets that are non-SMS, you may still need a model DSCB.

Robert Sample wrote: ↑Thu Apr 26, 2018 8:58 pmThe requirement used to be that a model DSCB was required to create a new generation of a GDG. With the advent of system-managed storage (SMS), the necessity of using a model DSCB was eliminated since SMS does not support model DSCB. If you are creating generation data sets that are non-SMS, you may still need a model DSCB.

What is SMS?

SMS = System Managed Storage as you would have found out if you did some research instead of jist asking people to do your research for you.

I got a link describing about SMS. Was not able to get it before. One more question though, If SMS does not support DSCB then if there is a system which make use of DSCB then how will it keep on working when SMS is active?

nicc wrote: ↑Mon Apr 30, 2018 3:31 pmSMS = System Managed Storage as you would have found out if you did some research instead of jist asking people to do your research for you.

Sorry nicc. I was searching for it but could not get it. Got it later. I understand it now that it is storage management subsystem.

What is SMS?

In my answer, I said

With the advent of system-managed storage (SMS),

So if you had actually read AND UNDERSTOOD my answer, you would not have had to ask that question.