DCB and DSCB.

Previous topicNext topic
User avatar

Topic Author
Anuj Dhawan
Founder
Posts: 2497
Joined: Sun Apr 21, 2013 7:40 pm
Location: Mumbai, India
Zodiac: Sagittarius

DCB and DSCB.

Post by Anuj Dhawan » Sun Oct 13, 2013 10:34 pm

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:

Code: Select all

//STEP2  EXEC PGM=IEFBR14 
//MODEL1 DD   DSN=THIS.IS.A.GDG.MODEL, 
//            DISP=(NEW,KEEP,DELETE), 
//            UNIT=SYSDA, 
//            SPACE(TRK,0), 
//            DCB=(LRECL=80,RECFM=FB)
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"! :)

old post
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 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.

[s]DSCB, on the other hand, also known as MLDSCB - "Model DCB"[/s]: See the explanation below by [s]  [/s][font=Tahoma, Arial, Helvetica, sans-serif]Gerhard_Adam[/font]


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:

Code: Select all

//STEP2  EXEC PGM=IEFBR14 
//MODEL1 DD   DSN=THIS.IS.A.GDG.MODEL, 
//            DISP=(NEW,KEEP,DELETE), 
//            UNIT=SYSDA, 
//            SPACE(TRK,0), 
//            DCB=(LRECL=80,RECFM=FB)
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.
Last edited by Anuj Dhawan on Thu Jun 30, 2016 2:06 pm, edited 1 time in total.


Thanks,
Anuj

Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.


Ajit Shah
Registered Member
Posts: 13
Joined: Mon Oct 14, 2013 5:17 pm

Re: DCB and DSCB.

Post by Ajit Shah » Wed Oct 16, 2013 11:45 am

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?



User avatar

Robert Sample
Global Moderator
Global Moderator
Posts: 1331
Joined: Fri Jun 28, 2013 1:22 am
Location: Dubuque Iowa
Zodiac: Virgo

Re: DCB and DSCB.

Post by Robert Sample » Wed Oct 16, 2013 4:27 pm

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? :D

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.



User avatar

Topic Author
Anuj Dhawan
Founder
Posts: 2497
Joined: Sun Apr 21, 2013 7:40 pm
Location: Mumbai, India
Zodiac: Sagittarius

Re: DCB and DSCB.

Post by Anuj Dhawan » Sat Oct 19, 2013 8:17 pm

Robert Sample wrote:So maybe we should say the data set has 2/3 existence? :D
That's a classic statement! :)


Thanks,
Anuj

Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.


Gerhard_Adam
Registered Member
Posts: 14
Joined: Thu Nov 26, 2015 10:51 am

Re: DCB and DSCB.

Post by Gerhard_Adam » Sat Jun 25, 2016 6:19 pm

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.



User avatar

Topic Author
Anuj Dhawan
Founder
Posts: 2497
Joined: Sun Apr 21, 2013 7:40 pm
Location: Mumbai, India
Zodiac: Sagittarius

Re: DCB and DSCB.

Post by Anuj Dhawan » Thu Jun 30, 2016 1:56 pm

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.


Thanks,
Anuj

Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.

Previous topicNext topic

Return to “Terminology is Important.”