IBM Mainframe Forum

Hi,

My head is spinning , need your help )))

1. Why do we create DSCB (Model dataset) while creating GDG?

2. Is that DSCB name should be same as GDG name?

3. If DSCB serving DCB parameter to particular version then why do we mention DCB=(DSCB dataset name, LRECL=nn,BLKSIZE=nn,RECFM=cc) ? Confused?

4. What is exactly SMS? how its different with DSCB?

5. How can we say SMS-dataset and Non-SMS dataset? How do i find my Mainframe supports SMS or not?

Awaiting for your replied.

Lots of issues here.

SMS (System Managed Storage) is just some new capabilities to assist an installation in managing storage.

Model DSCBs are just datasets that exist to provide DCB attributes when allocating other datasets. These datasets are usually allocated with SPACE=(TRK,0). Prior to SMS, generation data groups had an associated model DSCB with the same name as the generation data group that was used to provide DCB attributes for new generations. Many installations had a system change that removed the requirement for these model DSCBs.

DCB=(model-DSN,other DCB parameters) was often used when allocating GDGs that did not have a model DSCB.

Most IBM mainframe systems support SMS now; there are two other proper questions, "Can I specify STORGRP=xxx?" and "What xxx can I specify for STORGRP?" Actually, when going into a new shop, just specify UNIT=SYSDA when allocating a dataset. If SMS is running it will usually pick up a UNIT=SYSDA allocation and assign an appropriate STORGRP.

You can say SMS and non-SMS dataset, though the proper terminology is SMS managed.

1. Why do we create DSCB (Model dataset) while creating GDG?

2. Is that DSCB name should be same as GDG name?

3. If DSCB serving DCB parameter to particular version then why do we mention DCB=(DSCB dataset name, LRECL=nn,BLKSIZE=nn,RECFM=cc) ? Confused?

4. What is exactly SMS? how its different with DSCB?

5. How can we say SMS-dataset and Non-SMS dataset? How do i find my Mainframe supports SMS or not?

1. You don't -- depending upon the site, you may need to use a model DSCB when creating a GDG, but you don't create one when you create the GDG.

2. The model DSCB cannot be the same as the GDG name -- the model DSCB name references an existing cataloged data set so the GDG name would not be cataloged if the same name is used.

3. The model DSCB supplies default values should you not specify them -- you can still override them by including them in the DCB.

4. SMS is a storage management subsystem; DSCB is a way of determining data set attributes. You are comparing grapes and elephants -- they are not even close to being related.

5. Contact your site storage management group or site support group -- they can tell you if your site is using SMS managed storage. If you do not have to specify volume serials when allocating VSAM files -- using VOLUME(*) instead -- then your site is using SMS.

1. You don't -- depending upon the site, you may need to use a model DSCB when creating a GDG, but you don't create one when you create the GDG.

This issue is sort of iffy. If a model DSCB is required it should be created when the GDG index is created.

2. Is that DSCB name should be same as GDG name?

Yes, but ...

There were always problems with model DSCBs for GDGs.

They were not cataloged, but they had to be allocated on the same volume as the catalog where the GDG was defined. Now why should a programmer creating a GDG have to know the volume where the catalog the GDG is being defined?

In the SMS world this is a no no; all datasets must be cataloged.

The other problem is if the catalog got moved a lot of times the model DSCBs did not get moved.

2. The model DSCB cannot be the same as the GDG name -- the model DSCB name references an existing cataloged data set so the GDG name would not be cataloged if the same name is used.

This is not really correct. The model must be the name of the GDG, but it is not cataloged, so the issue of a duplicte name does not come up.

DSCB is DataSet Control Block, the record in a VTOC that defines a dataset, or more precisely, just a record in a VTOC.

1. In earlier times cant we create GDG generation without creating the model datasets?

2. if "DSCB is a way of determining data set attributes" as mentioned by robert, why are we creating the 0 tracks datasets and while creating generation why we are giving DCB parameters... instead we can created DSCB datasets with necessary tracks and while creating generation we can directly give

DCB =(ModelDSCB dataset) instead "DCB=(DSCB dataset name, LRECL=nn,BLKSIZE=nn,RECFM=cc)"

1. In earlier times cant we create GDG generation without creating the model datasets?

Of course you could create a GDG index and not create a corresponding model DSCB, but you could not create a GDG dataset unless you also specified DCB=(model-DSN,...)

2. if "DSCB is a way of determining data set attributes" as mentioned by robert, why are we creating the 0 tracks datasets and while creating generation why we are giving DCB parameters... instead we can created DSCB datasets with necessary tracks and while creating generation we can directly give

DCB =(ModelDSCB dataset) instead "DCB=(DSCB dataset name, LRECL=nn,BLKSIZE=nn,RECFM=cc)"

I don't think you could do something like DCB=GDG(0). If the DCB parameters in the model DSCB were entirely correct for your application, of course DCB=model-DSN would work. Many shops had selected pre-built model DSCBs around just for that purpose. For example, FB80800 might be built with RECFM=FB,LRECL=80,BLKSIZE=800. In those pre-TSO days it was not always easy to get the DCB attributes of a specific dataset.

BEFORE SMS days, before you can create the files that attach to a GDG base, you need to create a model dataset 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 dataset 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 dataset, 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.

As has been said multiple times - for an SMS site Model DSCB is not needed.

Anuj Dhawan wrote:...

Select all

//STEP2  EXEC PGM=IEFBR14
//MODEL1 DD   DSN=I.AM.GDG.MODEL,
//            DISP=(NEW,KEEP,DELETE),
//            UNIT=SYSDA,
//            SPACE(TRK,0),
//            DCB=(LRECL=80,RECFM=FB)

There is one major problem and three minor problems with this DD statement.

• The dataset name is probably invalid.
  • The HLQ probably is not defined in RACF.
  • The HLQ is probably not defined as an alias in the master catalog if you want to catalog the dataset.
• You probably want to catalog the dataset unless the model is being created as a GDG model. If that's the case you want to specify the volume serial of the volume containing the catalog where the GDG is cataloged.
• The SPACE parameter is invalid as coded. You probably want SPACE=(TRK,0).
• There is a problem with the DCB, and, quite honestly I'm not sure what the net effect will be. Since the BLKSIZE and DSORG parameters are omitted I think, but I'm not certain, that BLKSIZE=0 wil stored in the model DSCB, so that System Determined Blksize will be determined at OPEN. This is OK, especially if the model will be used for both disk and tape.

If thats the case,

What is the use of SMS.. What it will do exactly..

fornanthakumar wrote:If thats the case,

What is the use of SMS.. What it will do exactly..

For a programmer? As far as I'm concerned, absolutely nothing, though linking a data set to a data class can set possibly useful defaults to reduce JCL failures.

Well, OK, getting out from under GDG model DSCB's might be considered useful to a programmer.

For storage management types, it can make their life easier, especially if they can link data sets to management classes and data classes. Remember that storage management is overwhelmed by data; SMS might simplify this