GDG_Details

GDG

Confidential of 34

GENERATION DATA GROUPS (GDG)

GDG

Confidential of 34

Table of Contents

Section Title Sub Heading

1.0 Assumptions about the reader -

2.0 Overview -

3.0 What exactly is a GDG? -

3.1 - What happened before GDGs?

3.2 - Why would I want to use a GDG?

3.3 - What does a GDG look like?

3.3.1 - Absolute Generations

3.3.2 - Relative Generations

3.3.3 - Creating a new GDS

3.3.4 - Model/Pattern DSCBs

4.0 How to Create a GDG Structure? -

5.0 GDGs and System Managed Storage (SMS) -

5.1 - The SMS affect on GDGs

5.2 - A 'ROLLED IN' GDS

5.3 - A 'DEFERRED' GDS

5.4 - Using a Catalog Listing to understand GDGs

5.4.1 - LISTCAT Output for Non-SMS Managed GDGs

5.4.2 - LISTCAT Output for SMS Managed GDGs

5.5 - An 'ACTIVE' GDS

5.6 - Putting a 'DEFERRED' GDS into 'ACTIVE' status

5.7 - A 'ROLLED OFF' GDS

5.8 - LISTCAT and the display order of GDSs

5.9 - Clearing up 'ROLLED OFF' GDSs

6.0 How to change GDG attributes? -

7.0 How to delete a GDG? -

7.1 - Deleting a GDG by individual GDS deletions

7.2 - Deleting a GDG by Generic GDS deletion

8.0 What tools are available to help with GDGs? -

9.0 How to access GDGs -

10.0 Are GDGs worth it? -

11.0 Bibliography -

12.0 Glossary -

GDG

Confidential of 34

1.0 Assumptions about the Reader:

The Following assumptions have been made about the reader:

1) Is familiar with Job Control Language (JCL)

2) Knows what a Data Set or File is.

3) Knows what a Catalog is or at least how data sets can be referred to by the Catalog

4) Knows about IBM Utility programs even if they are not conversant with them

5) Has heard of System Managed Storage (SMS) and how it affects the way data sets are

allocated and referred to.

6) Knows what a DASD (Direct Access Storage Device) or Disk is

7) Knows where Allocation messages can be found in Job output

8) Is familiar with TSO ISPF and how to use it

2.0 Overview:

Generation Data Groups or GDGs have been a part of IBM's MVS data set naming

convention for three decades.

What exactly is a GDG?

What happened before GDGs?

Why would I want to use a GDG?

How to create a GDG Structure?

What about GDGs and System Managed Storage (SMS) ?

How to change GDG attributes?

How to delete a GDG when I'm finished with it?

What Tools are available to help with GDGs?

This document tries to answer the following questions and some more.

GDG

Confidential of 34

3.0 What is a GDG?:

A GDG or Generation Data Group is a name given to a collection of related data sets

(sometimes called Generation Data Sets or GDSs). These related Data Sets share a

unique Data Set Name. This Data Set Name is the same for each related Data Set within

the collection except for the 'Low Level Qualifier' (LLQ). Details of this Data Set

Naming convention will follow.

A GDS has a Generation number and Version number automatically assigned to each

data set.

This unique data set name qualifier is appended to the end of the Data Set Name as the

LLQ. The generation number assigned increases by one for each new data set created.

This increase is in chronological order (i.e. the higher the number the more recent and

vice versa).

3.1 What happened before GDGs?:

The term 'Generation' was often used to refer to older data sets. The terms 'Grandfather',

'Father', and 'Son' were used to refer to similar data sets that were related in time. An

example of this may help explain this generation idea.

Let's suppose that in January you produce a data set that contains all the employee

information for your company. For example, let's call this Data Set Name or Master File

'COMPANY.EMPLOYEE.MASTER' (Data Set Name and File are used interchangeably

in most cases). Now, if after each month you take this file and update it by adding new

employees, deleting retired employees, and changing salaries of other employees, you

may create an updated master file that you call 'COMPANY.EMPLOYEE.NEW' (for

February).

You may still wish to keep the old 'MASTER' data set around for reporting purposes or

disaster recovery. In some installations this was done by the following:

Rename 'COMPANY.EMPLOYEE.MASTER' to 'COMPANY.EMPLOYEE.OLD'

Rename 'COMPANY.EMPLOYEE.NEW' to 'COMPANY.EMPLOYEE.MASTER'

Of course if this procedure is run again for a third month (March), the results would be :

GDG

Confidential of 34

'COMPANY.EMPLOYEE.OLD' data for January

(Grandfather)

'COMPANY.EMPLOYEE.MASTER' data for February (Father)

'COMPANY.EMPLOYEE.NEW' data for March (Son)

If the data sets are to be renamed as in the previous procedure, then problems arise

because there already is an existing 'COMPANY.EMPLOYEE.OLD' data set. This means

there must be procedures in place to delete the oldest data set (Grandfather in this case).

3.2 Why Should we use a GDG?:

Wouldn't it be great if these Data Set Names could be handled automatically?

Wouldn't it be great if the oldest generation (Grandfather or older generation) were

automatically deleted when a new generation (Son) was produced?

Wouldn't it be great if you could refer to any of these Data Sets by a number, say maybe

a relative number? This relative number could be with respect to the newest Data Set, or

chronological order?

Wouldn't it be great if you could easily keep many more than three generations of this

Data Set?

Along come Generation Data Groups or GDGs.

GDGs will do all of the above - and more.

3.3 What does a GDG look like?

The generation LLQ produced for our sample data sets (COMPANY.EMPLOYEE) is of

the form:

'GnnnnVnn'

This results in the full GDS name of 'COMPANY.EMPLOYEE.GnnnnVnn'.

Where: 'COMPANY.EMPLOYEE' - is the fixed High and Second Level qualifier for the

GDS

'G' - is a constant character referring to the word Generation

GDG

Confidential of 34

'nnnn' - is a Generation number consisting of four digits. This number starts at 0001 and

goes to 9999 before repeating (the only time a lower number means a newer data set

chronologically)

'V' - is a constant character referring to the word Version

'nn' - is a Version number consisting of two digits. at 00 This number starts at 00 and

goes to 99.

NOTE: the Version number default is '00'. It is extremely rare for a Version greater than

'00'. Version numbers are used when you wish to keep the same generation number but

also want to have different versions. An example of this situation might be when

'G0006V00' contains data for your personnel file that has old department numbers,

however 'G0006V01' contains the same data with new department numbers.

The actual GDS name would resemble 'COMPANY.EMPLOYEE.G0001V00'.

With GDGs you do not have to rename Data Sets to keep track of their relative position

to each other or their chronology. In fact a GDG produces a Data Set Name 'Low Level

Qualifier' that is added to the Data Set Name and determines its relative position (the

appended generation and version number referred to earlier). This LLQ gives each GDS a

unique name. Data (Remember a Generation Group data set is referred to as a Generation

Data Set or GDS.)

3.3.1 Absolute Generations

Referring the previous example with the three 'COMPANY.EMPLOYEE' Data Sets

created in January, February, and March. In this case the following names are produced

by a GDG :

'COMPANY.EMPLOYEE.OLD' (Grandfather in January)

becomes

'COMPANY.EMPLOYEE.G0001V00'

'COMPANY.EMPLOYEE.MASTER' (Father in February) becomes


'COMPANY.EMPLOYEE.NEW' (Son in March) becomes


This all looks fine but how do you remember the LLQ value? Well, the data sets can be

referred to by their 'Absolute' (or fully qualified) Data Set Name such as:


GDG

Confidential of 34

However, this appears the only advantage to a GDG is not having to rename the data sets

every month as we did before.

How a GDG Structure keeps the ABSOLUTE GDS names.

This is where GDGs have a tremendous advantage over the manual method of

'Generation' management and remembering Absolute generations. But can you remember

all those'GnnnnV00' values?

3.3.2 Relative Generations:

This means the latest generation (Son) is always generation '(0)' (zero). The generation

just before it (Father) is referred to by generation '(-1)' (minus one). The generation

immediately before that (Grandfather) is referred to by generation '(-2)' (minus two).

How a GDG Structure keeps RELATIVE GDS names.

Referencing the GDS is done with the suffix of the 'Relative' generation number. We do

this by using brackets to enclose the 'Relative' generation (as shown in the Figure above).

CATALOG

GDG Structure for COMPANY.EMPLOYEE

G0001V00 G0002V00 G0003V00

CATALOG


(-2) (-1) (-0)

GDG

Confidential of 34

For Example :

Absolute Generation. Relative Generation.

'COMPANY.EMPLOYEE.G0003V00' is referred to by 'COMPANY.EMPLOYEE(0)'

'COMPANY.EMPLOYEE.G0002V00' is referred to by 'COMPANY.EMPLOYEE(-1)'

'COMPANY.EMPLOYEE.G0001V00' is referred to by 'COMPANY.EMPLOYEE(-2)'

GDGs also have other advantages.

We have mentioned the 'Grandfather', 'Father' and 'Son' generations, but what if you

wanted to keep track of monthly data sets for a whole year? We can consider Great,

great,..... Grandfather type of logic, or merely let the GDG handle it by referring to the

oldest (11 months previous) as '-11' (remember '0' is the newest or current generation).

Another advantage to GDGs is the elimination of the manual task of deleting generations

or data sets that are old and have become obsolete. If we wish to keep only three months

of data in our Grandfather, Father, Son example, we would have to delete the fourth

oldest month of data manually. A GDG that has been created properly will do this for

you automatically.

If we use the example where we wish to keep the most recent three months of the data

set, here is what happens.

Remember with the old manual method, 'COMPANY.EMPLOYEE.OLD' must be

manually or procedurally deleted before the data set called

'COMPANY.EMPLOYEE.MASTER' can be renamed.

However, with a GDG, 'COMPANY.EMPLOYEE.G0001V00' is automatically deleted

when the fourth generation, 'G0004V00' is created. (We'll soon see how you control this

function and how many generations you can actually keep active.)

3.3.3 Creating a new GDS:

How do you create a new generation (a new GDS)?

A good question with a simple answer.

Just as you can refer to old generations by a 'Relative' number, you also refer to a new

generation by a 'Relative' number. This 'Relative' number is '(+1)'. It follows the same

format as mentioned earlier, for example :

'COMPANY.EMPLOYEE(+1)' would produce 'COMPANY.EMPLOYEE.G0004V00'

The actual JCL (Job Control Language) might resemble :

GDG

Confidential of 34

//GENJOB JOB (acct'ng information....

//STEP1 EXEC PGM=MYPGM

//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR

//NEWGEN DD DSN=COMPANY.EMPLOYEE(+1),

// DISP=(NEW,CATLG),

//

SPACE=(TRK,(5,5)),DCB=(SYS1.DUMMY,RECFM=FB,LRECL=80)

// other DD and EXEC cards may follow

The key statement in this JCL is the 'DISP' (Disposition) parameter. It states the data set

to be created is 'NEW' and it is to be 'CATLG'd (Cataloged).

If this JOB had another step, we would still refer to the GDS just created by its

RELATIVE generation number '(+1)'. An example of such JCL might be as follows:






//

SPACE=(TRK,(5,5)),DCB=(SYS1.DUMMY,RECFM=FB,LRECL=80)

//STEP2 EXEC PGM=MYPGM2


//OLDGEN DD DSN=COMPANY.EMPLOYEE(+1),

// DISP=(OLD,KEEP)

// other DD and EXEC cards may follow

Notice the 'DISP' (Disposition) is now '(OLD,KEEP)'. The system keeps track of what

the actual or Absolute name of the GDS data set is.

3.3.4 Model/Pattern DSCBs

If you have sharp eyes you will have noticed something strange within the DCB

parameter of the DD statement. The words 'SYS1.DUMMY' appear. What does that

mean? What does it do? And do I need it?

When GDGs were first introduced it was felt that JCL coding could be reduced as well.

This reduction was based on simple logic. The logic was that if you are creating a new

GDS then it probably had the same DCB characteristics as the previous generations. In

order to help reduce coding it is possible to place a valid Data Set Name as the first sub

parameter of the DCB parameter. This Data Set's DCB would be used for the new data

set and you would not have to code the remaining DCB parameters.

This was a good idea and it had some advantages.

GDG

Confidential of 34

If this data set had the same name as the GDG (minus the generation LLQ), it could be

found and used to get DCB information.

But here is the catch. Using our example, this data set would have to be called

'COMPANY.EMPLOYEE'. This was not valid before modern ICF Catalogs came along.

In older style Catalogs (called VSAM Catalogs), you could not have a catalog entry like

'COMPANY.EMPLOYEE' and one called 'COMPANY.EMPLOYEE.G0001V00' and

have them both cataloged. This was a restriction for this type of Catalog Structure.

So how did the system find the data set 'COMPANY.EMPLOYEE' in order to use its

DCB information?

At that time it was valid to have uncataloged data sets all over the place. This data set

was uncataloged. The system found it by looking on the DASD volume where the actual

System Catalog Data Set resided (the System Catalog, not the user's data set).

Because the Data Set Names were identical up to the last qualifier (the LLQ), this

uncataloged data set was called a 'PATTERN DSCB' (Data Set Control Block).

We Can put any valid Data Set in the DCB parameter even if it was not a PATTERN. In

this case it was called a 'MODEL DSCB' because the DCB parameters were Modeled

after this data set.

If you do not have a PATTERN DSCB data set then you can use the data set we have

indicated that is called 'SYS1.DUMMY'. It fits the requirements for a MODEL DSCB.

Note :

1.) 'SYS1.DUMMY' has no useful DCB characteristics and you must supply them within

the JCL or the program ('SYS1.DUMMY' and its use is unique to our system).

2.) You DO NOT REQUIRE a MODEL or PATTERN DSCB with SMS managed GDGs.

4.0 How to Create a GDG Structure?

The IBM Utility program IDCAMS (the 'AMS' stands for Access Method Services), is

used to produce a Generation Data Group Structure.

The term 'Structure' is used here to refer to the pre-defined group of related generation

data sets. This Structure actually consists of catalog entries that are entered in the order of

creation. Sometimes you will read the GDG Structure referred to as a GDG Base. There

is basically no difference. I just happen to like the term Structure.

Here's an example of a GDG Structure we would create for our fictitious company files.

Suppose we wish to keep three months (or versions) of data sets at one time. The Job

GDG

Confidential of 34

Control Language and IDCAMS control information would be :


//STEP1 EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=X

//SYSIN DD *

DEFINE GDG NAME(COMPANY.EMPLOYEE) ENTRIES(3) SCRATCH

NOEMPTY

/*

Here are what the parameters means:

DEFINE - This tells IDCAMS that you are going to create something new .

GDG - This tells IDCAMS that you are creating a new GDG Structure.

NAME - This is the parameter that contains the actual Data Set Name (the Structure

name) for definition (minus the generation and version numbers) .

COMPANY.EMPLOYEE - This is the Data Set Name minus the 'Low Level Qualifier'

(the GnnnV00 part of the Data Set Name) upon that the GDG Structure will be built

(User controlled).

ENTRIES - This indicates how many generations (Relative or Absolute) you wish to

maintain (User controlled).

SCRATCH - This is the default and means that when a fourth generation (in this

example we are saying we only wish to keep three) is created, the oldest is deleted and

uncataloged (NOSCRATCH is the other option and is not available on our system).

NOEMPTY - This is the default and means that when a fourth generation (in this

example) is created, the oldest generation only is to be deleted (EMPTY is the other

option and means that when a fourth generation (in this example) is created, all previous

generations (the last three), are to be deleted).

We can also Define a GDG Structure by using the TSO ISPF GDG command.

5.0 GDGs and System Managed Storage (SMS):

The management of GDGs changed when System Managed Storage (SMS) was

introduced.

The GDG concept remained intact with System Managed Storage, however the major

change was with respect to how the generations (the GDSs themselves), were Cataloged.

All the other information, such as generation numbers, and IDCAMS control parameters

GDG

Confidential of 34

to create a GDG, remained the same.

In order to understand how SMS and GDGs interact, it helps to explain a rule of SMS.

The most important rule of SMS is that all Data Sets MUST be Cataloged. That is, they

must have a Catalog entry and can be referred to by the catalog. This generally means

you can not refer to data sets by indicating the DASD Volume Serial they reside on.

In the non-SMS world it is possible to create many identically named data sets on

different DASD volumes and have only one or possibly none of them Cataloged. This

cannot be done in the SMS world. One and only one cataloged Data Set Name can exist

at a given time in the SMS environment.

5.1 The SMS affect on GDGs:

How does SMS affect GDGs?

In a non-SMS environment it is possible to create a GDS and not catalog it. This can be

because the user forgot to catalog the GDS, or the step which did the actual cataloging

did not execute. In a SMS environment the GDS is always cataloged at creation time and

the possibility of not cataloging it does not take place.

However, and this is the key point, when you create a SMS managed GDS and do not

catalog it, SMS does catalog it. This may cause a problem because of the SMS logic at

this point.

* Critical Point Here * SMS catalogs your GDS even if you don't, but it will NOT place

the GDS within the GDG Structure.

5.2 A 'ROLLED IN' GDS:

Your CATALOG action is like a moving action. This moving action moves the GDS

from outside the GDG Structure and places it in the GDG Structure. This 'move' action

of a cataloged GDS from outside the GDG Structure to within the GDG Structure is

called 'ROLLED IN'. It means the GDS has been 'moved' or 'ROLLED IN' to the

Structure.

At this point we must take a moment to examine where this 'ROLLED IN' term comes

from.

When you look at your job listing, you will find the message output. In this area the

allocation messages are shown. When you examine a non-SMS managed GDS data set

line, you will get a message that says 'KEPT' or 'CATALOGED'. 'KEPT' means the data

GDG

Confidential of 34

set was not cataloged, while the 'CATALOGED' message means it was.

Because of the rule for SMS that says all data sets must be cataloged, the allocation

system messages are a little different. In place of the 'KEPT' message you will see a

'RETAINED' message.

'RETAINED' means that SMS has kept and cataloged your data set. (Note: This

'RETAINED' message occurs when 'DISP=(NEW,KEEP)' is used and not when

'DISP=(NEW,CATLG)' is used.)

Further down in the system messages you will see a second line of messages referring to

the same GDS again. This message will hopefully say 'ROLLED IN'. (Note: This second

line occurs only if 'DISP=(NEW,KEEP)' was used in a previous step, otherwise the

'ROLLED IN' message is the only one that appears.) As was said before, this means the

GDS is now part of the GDG Structure.

If you do not see this 'ROLLED IN' message, then the GDS has not been 'ROLLED IN'

and even though it is cataloged, it is not part of the GDG Structure.

Some examples may help explain this apparent cataloging confusion.

Let's suppose we give an example of a SMS managed GDS being created where

everything is perfectly clear. (Users should note there is no Data Set Name reference

within the DCB parameter. Remember this Pattern or Model DSCB is no longer required

for SMS managed GDGs.)

Example where everything is normal:




//NEWGENDD DSN=COMPANY.EMPLOYEE(+1),


// SPACE=(TRK,(5,5)),DCB=(RECFM=FB,LRECL=80)

Suppose this example creates a new GDS called 'COMPANY.EMPLOYEE.G0004V00'.

It can be referred to in later jobs by the ABSOLUTE generation data set name of :

'COMPANY.EMPLOYEE.G0004V00' - or -

by the RELATIVE generation data set name of :

'COMPANY.EMPLOYEE(0)'

This GDS in fact has been 'ROLLED IN'. It belongs to the GDG Structure.

GDG

Confidential of 34

The following example shows where everything is not normal.





// DISP=(NEW,KEEP),





// DISP=(OLD,CATLG)

This example creates a new GDS called 'COMPANY.EMPLOYEE.G0004V00' (for

example). In this example let's suppose the second step (STEP2) does not execute for any

one of many reasons.

You will notice the DISP on STEP1 says '(NEW,KEEP)' and not '(NEW,CATLG)'. This

is a very important difference. If we know that a SMS managed data set is automatically

cataloged at creation, the 'KEEP' portion of the DISP parameter is ignored and a DISP of

'CATLG' actually occurs, with one exception. The exception is that the GDS created is

not 'ROLLED IN' to the GDG Structure at this point.

It is a cataloged data set but exists outside the GDG Structure. The STEP1 message for

this data set will indicate 'RETAINED'.

The DISP on STEP2 is very important and we will see why in a moment.

In our example we have a DISP of '(OLD,CATLG)'. This makes the system assume the

data set already exists. It first searches the Job Control Blocks to see if it has a Volume

Serial reference for this data set. Because we said '(NEW,KEEP)', it will not have an

entry for this specific Data Set Name. It will then search the catalog for the '(+1)'

generation within the GDG Structure. However, it will not find it and a JCL error

indicating a DISP conflict with the Data Set Name, will occur.

The message for this data set will be 'DISP FIELD INCOMPATIBLE WITH DSNAME'.

What would happen if I used the following JCL for STEP1 above:





// DISP=(NEW,PASS), <- CHANGED



GDG

Confidential of 34



// DISP=(OLD,CATLG)

Notice the DISP is now '(NEW,PASS)'. This difference is critical to what happens in

STEP2.

The STEP1 message for this data set will indicate 'PASSED'

When the DISP in STEP1 says '(NEW,PASS)' the system is smart enough to figure that

you will be using this data set in a further step and it keeps track of it in its Job Control

Blocks. When the System searches for this specific Data Set Name in STEP2, it can find

it and no JCL error will occur. However, if as we suggested, STEP2 does not get

executed, the GDS is never 'ROLLED IN' to the GDG Structure.

NOTE: If the second step (STEP2) was executed, the message for this data set will be

'ROLLED IN'.

When the second step (STEP2) is not executed and the GDS has not been 'ROLLED IN',

it is in what is called a 'DEFERRED' status. DEFERRED is explained in the next section.

5.3 A 'DEFERRED' GDS:

This data set's inclusion in the GDG Structure is DEFERRED. We will see where this

term 'DEFERRED' appears in other areas regarding GDGs.

DEFERRED

How a Catalog keeps track of DEFERRED GDSs. Note it is not part of the

GDG Structure yet.

The second step (STEP2) in our previous example, does specify 'CATALOG' in its DISP

parameter. This 'CATALOG' action will put the GDS (just created and referred to by its

CATALOG


G0001V00 G0002V00 G0003V00 G0004V00

GDG

Confidential of 34

RELATIVE generation number '(+1)'), into the GDG Structure (via a 'ROLLED IN'

action).

Remember a 'DEFERRED' GDS is a data set that has not been 'ROLLED IN'.

'DEFERRED' does not appear as a keyword in any Job messages but is the status of a

GDS where 'RETAINED' appears and is not followed by a 'ROLLED IN' message.

This GDS STATUS appears in a Catalog Listing as we will see in the next section.

5.4 Using a Catalog Listing to understand GDGs:

It may assist in understanding GDGs and GDSs if we use a Catalog listing of the GDG

structure to show how the system looks at the data sets involved.

5.4.1 LISTCAT Output for Non-SMS Managed GDGs

Suppose we look at a non-SMS GDG. In this case we will assume that the GDG

'COMPANY.EMPLOYEE' is not a SMS managed GDG. The standard JCL for IDCAMS

is again used:

//LISTCJOB JOB (acct'ng information....



//SYSIN DD *

LISTCAT LVL(COMPANY.EMPLOYEE)

Here are what the parameters means:

LISTCAT - This tells IDCAMS to get details from the actual System Catalog

LVL - This is short for LEVEL (use the long form if you wish). It means you are giving

only some of the Data Set Name indices (one or more)

This will result in output to the SYSPRINT file that shows the following.

NONVSAM ------- COMPANY.EMPLOYEE.G0001V00

IN-CAT --- CATALOG.NV.CAT01





GDG

Confidential of 34

The output is simple and there are no surprises.

NOTE: There are similar On-Line commands available through the GDG TSO ISPF

Option screen. For further details on this facility refer to the section titled 'What Tools are

available to help with GDGs?', or Section 8 of this document. (Note: The 'GDG'

command is unique to our installation.)

5.4.2 LISTCAT Output for SMS Managed GDGs:

The LISTCAT output for a SMS managed data set will be the same. However, if a fourth

generation (G0004V00) were produced that did not get included in the GDG Structure

but was in fact cataloged, (remember the DEFERRED status mentioned earlier), then the

output would resemble:









Suddenly there are some surprises! The order of GDSs listed is one surprise. This seems

to confuse the issue.

However, if we consider that the fourth generation (G0004V00) really is treated like a

separate data set by the Catalog. IDCAMS is listing all the data sets with the same data

set name pattern first and then listing the entries it finds within the GDG Structure.

It is very important to remember this, as we get into more complex SMS and GDG

relationships.

The catalog listing we just displayed is the simplest one we can get. If more details are

required from a 'LISTCAT', we can specify other parameters. The most common is the

'ALL' sub parameter. The 'ALL' sub parameter will list many more details about the data

sets.

The listing information we wish to see is the 'STATUS' parameter that appears on a

LISTCAT output. This 'STATUS' line will appear only for SMS managed GDGs. It also

will disclose more information about the status of each individual data set as it relates to

GDG

Confidential of 34

the GDG Structure.

If we take the above LISTCAT example but add the 'ALL' sub parameter, we will get a

different output. For brevity sake we will show only the IDCAMS Control card input and

not the Job card and associated JCL.

NOTE: There are similar On-line commands available through the 'GDG' TSO ISPF

Option screen.

The IDCAMS Control card would be:

LISTCAT LVL(COMPANY.EMPLOYEE) ALL

The 'ALL' parameter means you want all the details about these Data Set Names you

have in the System Catalog.

This will result in output to the SYSPRINT file that shows the following : * Note * The

output shown below was compressed to squeeze it into 80 bytes.



HISTORY

DATASET-OWNER----(NULL) CREATION--------1997.100

RELEASE-----------------------2 EXPIRATION-----0000.000

ACCOUNT-INFO-------------------------------------------(NULL)

STATUS--------------DEFERRED

SMSDATA

STORAGECLASS--STANDARD MANAGEMENTCLASS-STANDARD

DATACLASS-----FB80 LBACKUP --XXXX.XXX.XXXX

VOLUMES

VOLSER--------------US1900 DEVTYPE------X'3010200F' FSEQN---

-----0

ASSOCIATIONS------------(NULL)

ATTRIBUTES



HISTORY




STATUS--------------ACTIVE

SMSDATA



VOLUMES


-----0


ATTRIBUTES



GDG

Confidential of 34

HISTORY





SMSDATA



VOLUMES


-----0


ATTRIBUTES



HISTORY





SMSDATA



VOLUMES


-----0


ATTRIBUTES

Notice the extra detail lines we see as well as the order of GDSs listed. A 'STATUS' line

and three lines called 'SMSDATA' are now shown. They appear only for SMS managed

GDGs. Note where the 'G0004V00' generation appears. The 'STATUS' line and the three

'SMSDATA' lines will not appear if the GDG is not SMS managed.

5.5 An 'ACTIVE' GDS:

As you can see from the previous SYSPRINT output we suddenly have two new terms

we hadn't seen before in a 'LISTCAT' output. They are 'DEFERRED' and 'ACTIVE'.

Let's examine them as they occurred.

'DEFERRED' appeared for a GDS that we said did not belong to the GDG Structure. It

had not been 'ROLLED IN' yet. DEFERRED means the system will move this entry into

the GDG Structure as soon as you tell it to (assuming you want to). In effect it is just

waiting for the command to move it or 'ROLL' it 'IN'.

'ACTIVE' seems straight forward. It means the GDS is part of the GDG Structure and

available for processing. When the 'STATUS' line of a LISTCAT output says 'ACTIVE'

all normal rules of GDG processing apply.

GDG

Confidential of 34

5.6 Putting a 'DEFERRED' GDS into 'ACTIVE' status:

If a GDS doesn't belong to a GDG Structure you may want to move it into the Structure

or have it 'ROLLED IN'. The term 'ROLLED IN' in fact comes from the Allocation

messages you see in the message log of a batch job.

Briefly, the line in the Message log of your Job output would resemble the following if

your GDS was added or 'ROLLED IN' to the GDG:

IGD107I COMPANY.EMPLOYEE.G0004V00. ROLLED IN,

DDNAME=XXX

Other Message lines were not shown for clarity sake.

Now there are two ways to have a 'DEFERRED' GDS 'ROLLED IN'.

The first method is to force it to be 'ROLLED IN'. For this you must use the IDCAMS

utility again. To force a GDS to be added to the GDG Structure, the following JCL and

control card may be used:

//ALTER JOB (acct'ng information....



//SYSIN DD * ALTER COMPANY.EMPLOYEE.G0004V00 ROLLIN

Here are what the parameters mean:

ALTER - Means you will be changing the status of something

COMPANY.EMPLOYEE.G0004V00 - is the Data Set Name to be ALTERed. Note it

must be the ABSOLUTE GDS name.

ROLLIN - The IDCAMS keyword that will add the GDS to the GDG Structure and in

fact give it an 'ACTIVE' status and make it 'ROLLED IN'.

The second method to 'ROLLIN' a 'DEFERRED' GDS is to reuse it. This seems simple

and basically it is.

Consider that the GDS already exists and all we need to do is reuse the existing data set

in a new JOB. The JCL for this action is (Note the DD card only is shown here):

//NEWGDS DD DSN=COMPANY.EMPLOYEE(+1),


// DCB=(RECFM=FB,LRECL=80),SPACE=(TRK,(5,5))

GDG

Confidential of 34

Although the above 'DD' shows a DISP of '(NEW,CATLG)', the existing GDS that is in

'DEFERRED' status, will be reused. (The actual Data Set is reused and not just the Data

Set Name.)

Note: Once a 'DEFERRED' GDS is 'ROLLED IN' and becomes part of the GDG

Structure (no matter which method you use), the oldest generation will be deleted

(assuming we specified NOEMPTY as our IDCAMS parameter option when we created

the GDG Structure in the beginning).

If you have the above JCL with 'DISP=(NEW,KEEP)', and the GDS happens to be

'DEFERRED', it will also be reused and remain 'DEFERRED'.

If you had JCL that specified GDSs '(+1)' and '(+2)' with 'DISP=(NEW,KEEP)' for both,

a fascinating thing occurs.

The first '(+1)' GDS will reuse the first 'DEFERRED' GDS. The second GDS '(+2)' will

be added but in a 'DEFERRED' status

5.7 A 'ROLLED OFF' GDS:

Sometimes the oldest generation cannot be deleted.This can occur if one or more of the

following events take place:

a) User does not have the RACF authority to delete the data set

b) An EXPDT (Expiry Date) was used (Note that no SMS managed data sets may contain

EXPDT (Expiry Dates) or RETPD (Retention Periods) at our installation)

c) Some system error occurs that keeps the deletion process from completing (such as the

DASD volume being unavailable - please note this is very rare)

d) The generation to be deleted was allocated at the time (The most common reason)

This makes things very interesting. Because the data set is no longer part of the GDG

Structure and yet it is not in 'DEFERRED' status. What is its status?

We must introduce another new term for GDGs. This data set is not 'ACTIVE' and is in

effect in the opposite condition of being 'ROLLED IN'. What better term to describe it

than to have a status of 'ROLLED OFF'. In fact that is the term you will see in a

LISTCAT.

GDG

Confidential of 34

ROLLED OFF

How a Catalog keeps track of ROLLED OFF GDSs. It has been removed from the

GDG Structure.

Suppose the example we have been using has a situation where the fourth generation

(G0004V00) was successfully 'ROLLED IN'. Now if the first generation (G0001V00)

could not be deleted for one of the reasons mentioned above, it would still exist as a

cataloged data set but would have a status of 'ROLLED OFF'. The LISTCAT output

would look like (detail lines are not included):

NONVSAM ---- COMPANY.EMPLOYEE.G0001V00

STATUS ---- ROLLED OFF


STATUS ---- ACTIVE


STATUS ---- ACTIVE


STATUS ---- ACTIVE

5.8 LISTCAT and the display order of GDSs

What happens if we create a fifth generation (G0005V00) and it is not 'ROLLED IN' for

whatever reason. We now have a mixture of GDSs where one is in 'ROLLED OFF'

status, some are in 'ACTIVE' status, and one is in 'DEFERRED' status. The LISTCAT

output from this situation would be (detail lines are not included):

CATALOG


G0002V00 G0003V00 G0004V00 G0001V00

GDG

Confidential of 34




STATUS ---- DEFERRED


STATUS ---- ACTIVE


STATUS ---- ACTIVE


STATUS ---- ACTIVE

The order of the generations is 1, 5, 2, 3, and 4!

Remember what was said earlier about order.

The LISTCAT takes the data sets as it finds them in the Catalog. It first checks for all

data sets that meet the criteria for data set name, then lists all of the data sets that match

the pattern. The last thing it does is list the entries within the GDG Structure. It seems

confusing, but it follows the rules.

In all my LISTCAT examples I have used the Level (LVL) as

'COMPANY.EMPLOYEE'.

What if I use just 'COMPANY' as the Level (LVL)? (Let's assume for simplicity sake

that 'COMPANY' is unique and only has GDSs under it.)

Surprise!

Our LISTCAT output would now look like (detail lines are not included): NONVSAM ---- COMPANY.EMPLOYEE.G0001V00



STATUS ---- ACTIVE


STATUS ---- ACTIVE


STATUS ---- ACTIVE



They are back in order again!

Don't worry why this happens; it just does!

GDG

Confidential of 34

5.9 Cleaning up 'ROLLED OFF' GDSs

If you get a LISTCAT output like this you may wish to 'clean up' your GDG Structure.

You can 'ROLLIN' the DEFERRED GDG in one of the two methods we discussed

earlier. This will eliminate the 'DEFERRED' status of the GDS 'G0005V00'.

But what about the 'ROLLED OFF' status of generation 'G0001V00'?

In this case we must manually delete this 'ROLLED OFF' generation. We can do this

with our IDCAMS utility.

The control card would be (Note we are only showing the control card and not the rest of

the JCL required): DELETE COMPANY.EMPLOYEE.G0001V00 PURGE


DELETE - This Command tells the system to delete the data set you are about to

identify. This deletes and uncatalogs the data set and even issues a DFHSM deletion if

the data set is under DFHSM control (Migrated).

COMPANY.EMPLOYEE.G0001V00 - The data set you wish to delete. It must be the

Absolute GDS name and not the Relative name.

PURGE - This command is optional. It is used when the data set that is to be deleted was

Expiry Date protected. This command can be used at all times if so desired and does not

cause any adverse effects if the data set is not Expiry Date protected.

It is important to realize that many combinations of 'ACTIVE', 'ROLLED OFF' and

'DEFERRED' status GDSs may exist. Without going into any details, a LISTCAT output

could result in a report such as this (again no detail lines are shown):










STATUS ---- ACTIVE

GDG

Confidential of 34


STATUS ---- ACTIVE


STATUS ---- ACTIVE

Just when you thought it seemed easy!

Don't worry. The previous example is very rare and most often you will deal with the

occasional GDS that is 'ROLLED OFF' (very seldom), or 'DEFERRED' (more likely, but

still rare).

6.0 How to I change GDG attributes?

Once you have created a GDG Structure it will operate just as described. However,

sometimes we find we require more generations to be kept than was originally thought.

We also may want to change the NOEMPTY attribute to EMPTY.

These tasks can be performed by ALTERING the Structure of GDG. We use the

IDCAMS utility again to perform this task.

The following control card can be used to change the number of entries from three (3) to

four (4) in our sample GDG (Note JCL not shown).

The IDCAMS Control card would be: ALTER GDG COMPANY.EMPLOYEE ENTRIES (4)


ALTER - This Command will change the status or attributes of the described entry

GDG - This command means the Data Set is a GDG Structure

COMPANY.EMPLOYEE - Is the GDG to be Altered

ENTRIES(4) - This the specific Attribute to be Altered. In this case the value is to be

changed and increased (or decreased) to 4 (*Note* If you reduce the number of entries

then the oldest GDSs by Relative number will be deleted up to this new ENTRIES limit.)

The following control card can be used to change the NOEMPTY attribute to EMPTY

(Note JCL not shown).

The IDCAMS Control card would be: ALTER GDG COMPANY.EMPLOYEE EMPTY


GDG

Confidential of 34

ALTER - This Command will change the status or attributes of the described entry

GDG - This command means the Data Set is a GDG Structure

COMPANY.EMPLOYEE - Is the GDG to be Altered

EMPTY - This is the specific Attribute to be Altered. It could be changed from EMPTY

to NOEMPTY as well


Option screen. For further details on this facility refer to the section titled 'What Tools are

available to help with GDGs?', or Section 8.0 of this document.

7.0 How to delete a GDG?

Eventually a GDG Structure must be deleted. This can happen for many reasons such as:

1. GDG name is no longer valid or meaningful (Note that the GDGname is not an

ALTERable attribute via the IDCAMS ALTER command)

2. The GDG is no longer useful (system now in production from test etc.)

3. Application has terminated

There are two methods you can follow when deleting a complete GDG Structure and

ALL of its related Data Sets.

The methods regard the various techniques used to remove 'ACTIVE', 'ROLLED OFF',

and 'DEFERRED' GDSs.

These methods are :

1) All GDSs within the GDG Structure must be deleted individually before you can

delete the GDG Structure itself. Deleting the GDS data sets individually is one way of

guaranteeing you are removing all of the data sets within the GDG Structure.

2) All GDSs can be deleted in a group. This generic deletion is quicker and does not

require knowledge of all the individual (Absolute) generations involved. However, in an

example below, we see that when we delete all of the GDSs related to a GDG Structure

by using a group or generic deletion, we must be careful or problems will arise.

There are two methods as mentioned, to delete all the data sets within a GDG Structure.

GDG

Confidential of 34


Option screen.

7.1 Deleting a GDG by individual GDS deletions

The first method is individual GDS deletions as shown in this example. We again use the

IDCAMS utility (Note we have used our fictitious GDG again): //DELGDS JOB (acct'ng information....

//STEP1 EXEC PGM=IDCAM


//SYSIN DD *

DELETE COMPANY.EMPLOYEE.G0004V00 PURGE




DELETE - This Command will delete and uncatalog the Data Set Name that follows

COMPANY.EMPLOYEE.G0004V00 - This is the specific GDS that must be deleted.

(Generation G0004V00 is shown in this line.)

PURGE - This command is optional. It is used when the data set that is to be Deleted

was EXPIRY DATE protected. This command can be used at all times if so desired and

does not cause any adverse effects if the data set is not EXPIRY DATE protected.

7.2 Deleting a GDG by Generic GDS deletion

The second method is the easiest but also may cause the greatest problems. In this

method you can delete all of the GDSs involved by referring to their index levels and not

the full or Absolute GDS name.

This method again uses the IDCAMS utility as above: //DELGDS JOB (acct'ng information....



//SYSIN DD *

DELETE COMPANY.EMPLOYEE.* PURGE


DELETE - This Command will delete and uncatalog the data set name that follows

GDG

Confidential of 34

COMPANY.EMPLOYEE.* - This is the data set name pattern that will be followed for

data set deletion. Notice the '*' (asterisk) is used to represent the LLQ. But Beware!

Because the system doesn't know you want to delete GDSs and only GDSs, it will delete

ALL data set names that match this pattern. For example, if you had a data set called

'COMPANY.EMPLOYEE.JCLLIB', this data set would also be deleted by the above

command. Beware! Use at your own risk! It sometimes helps if the GDG and related

GDSs have data set names that are very unique. Usually unique means long.

PURGE - This command is optional. It is used when the data set that is to be deleted was

EXPIRY DATE protected. This command can be used at all times if so desired and does

not cause any adverse effects if the data set is not EXPIRY DATE protected.

FORCE - This command option has not even been shown in the example above for a few

reasons. This command will delete the GDG Structure and uncatalog all the GDSs, but it

will not delete them. This may be useful if Tape GDSs are involved. In fact it will NOT

function if you attempt to use this command on SMS Managed GDGs (you get a RACF

error about your authourity). Don't use this command unless you know what you are

doing.

Not everything is doom and gloom with the second method of deleting GDS data sets.

Remember it will also delete the 'ROLLED OFF' and 'DEFERRED' GDSs as well. That

way, you won't have to try and remember the status of all the GDSs involved.

8.0 What Tools are available to help with GDGs?

Until now we have only seen JCL that must be run in Batch. But there are On-line or

TSO facilities available at ITSD to help you with GDG maintenance.

The TSO ISPF screen that will perform many GDG functions, is invoked via the 'GDG'

command from the main option menu or other command line. Remember the 'GDG'

command is unique to our installation.

It is very important to recognize that this Utility function performs most basic GDG

Structure functions but does have limitations as mentioned in the specific text where it

may apply.

This 'GDG' command will produce the following screen :

GDG

Confidential of 34

Image of a TSO ISPF Screen showing the GDG option panel


Generation Dataset Group (GDG) Utility - is the title of the panel being displayed.

OPTION - is the Option line of this ISPF screen and allows you to enter any valid option

from the list of options shown below.

GDG Index Name - is the actual Data Set Name of the GDG Structure.

userid - is the TSO users Userid that will be appended to Data Set Names that are not

enclosed in quotes (the actual Userid appears and not just the word 'userid').

L - List a Generation Dataset Group, will produce a display almost the equivalent to a

LISTCAT output shown earlier. (*Note* actual command is 'LISTCAT

LVL(HLI.LLQ) ALL GDG'. This results in ONLY the Active GDSs appearing. This is

very important researching for DEFERRED or ROLLED OFF GDSs, because they will

NOT be shown.)

A - Add a Generation Dataset Group, will produce another screen that will allow you to

------------GENERATION DATASET GROUP(GDG) UTILITY----------

OPTION �

GDG INDEX NAME �

(userid will be added to names not in quotes)

Enter one of the following Options above:

L. List a Generation Dataset Group.

A. Add a Generation Dataset Group.

D. Delete a Generation Dataset Group.

E. Change number of Entries in a Generation Dataset Group.

F Change EMPTY mode for Generation Dataset Group.

GDG

Confidential of 34

create a new GDG Structure by building IDCAMS commands for you.

D - Delete a Generation Dataset Group, will produce another screen that allows you to

delete all Active GDSs within a GDG Structure and also delete the GDG structure.

*Note* Caution should be used when using this command as is indicated. The reasons are

as follows:

a) The first problem occurs if there are any DEFERRED or ROLLED OFF GDSs. These

will not be deleted by this function even though the GDG Structure itself is deleted.

These remaining 'orphaned' DEFERRED and ROLLED OFF GDSs must be individually

deleted by reference to their Absolute GDS name. You can discover what these are, if

there are any at all, by doing an IDCAMS LISTCAT of the GDG Index and also

specifying the ALL parameter. (*Note* Remember the 'L' List option of this panel does

NOT show Deferred or Rolled Off GDSs.)

b) The next problem is mentioned on the actual delete screen that is produced when you

run this command. This warning tells you that you could accidentally delete all data sets

with the same Index level as the GDG if any exist. If we use our

'COMPANY.EMPLOYEE' index as an example, we can see what happens. (*Note* The

FORCE command is used by this delete panel. See Section 7.2 for a Warning about using

FORCE.)

Suppose the delete you use will delete the following:

'COMPANY.EMPLOYEE.G0022V00' and 'COMPANY.EMPLOYEE.G0023V00' and

'COMPANY.EMPLOYEE.G0024V00' and 'COMPANY.EMPLOYEE' the GDG

Structure itself. It will also delete a data set like 'COMPANY.EMPLOYEE.JCLLIB' if it

existed. So you can see how important it is to do a LISTCAT first.

E - Change number of Entries in a Generation Dataset Group, will produce another

screen that will allow you to Alter the number of entries within your GDG Structure.

M - Change EMPTY Mode for a Generation Dataset Group, will produce another screen

that will allow you to ALTER the GDG Structure from NOEMPTY (Default).

NOTE: Generally only the 'L' (List) and 'D' (Delete) options should be used with care. As

each specific section mentions, you may get different results than what you had expected

or your results may not indicate all the actual GDSs you may wish to examine.

9.0 How to access GDSs:

Most of the JCL examples shown indicate how you create a new GDS. But what if you

want to read a GDS?

GDG

Confidential of 34

Not a great deal of problems here. Remember you can refer to a GDS by its ABSOLUTE

or RELATIVE Data Set Name. The example below will show how easy this is.

//READGDG JOB (acct'ng information....




//GDGIN DD DSN=COMPANY.EMPLOYEE(0),DISP=SHR

In the above example the GDS is referred to by its RELATIVE generation.





//GDGIN DD DSN=COMPANY.EMPLOYEE.G0005V00,DISP=SHR

In this example the GDS is referred to by its ABSOLUTE generation.

But what about the example below ?





//GDGIN DD DSN=COMPANY.EMPLOYEE,DISP=SHR

In this example there is no RELATIVE or ABSOLUTE generation number. What will

happen?

In this case when the GDG base or structure is given as the Data Set Name the system

will concatenate ALL existing ACTIVE generations. The concatenation is done from the

highest to the lowest generation number (or most recent to oldest if you wish). Therefore,

the above example is the same as:





//GDGIN DD DSN=COMPANY.EMPLOYEE(0),DISP=SHR

// DD DSN=COMPANY.EMPLOYEE(-1),DISP=SHR

// DD DSN=COMPANY.EMPLOYEE(-2),DISP=SHR

GDG

Confidential of 34

10.0 Are GDGs worth it?

Generation Data Groups can be very useful. We must remember the tricks and pitfalls

that may occur if the GDS is a SMS Managed Data Set.

In general we must always be aware of the 'STATUS' of a When SMS Managed GDS.

the STATUS has been considered then everything else falls into place. The rules for

creating a GDG Structure have been discussed. The methods of fixing ' 'ROLLED OFF'

or 'DEFERRED' GDSs have been examined. We mentioned the way GDGs can be

ALTERed and even how to delete a GDG Structure and all its related data sets.

If you still have questions I suggest you peruse the following IBM Manuals indicated in

the Bibliography

11.0 Bibliography

o MVS/ESA Integrated Catalog Administration: Access Method Services Reference

(SC26-4500)

o MVS/ESA JCL User's Guide (C28-1653)

o MVS/ESA JCL Reference (C28-1654)

o ITSD MVS User's Guide

12.0 Glossary

ABSOLUTE - This term refers to a GDS where the full data set name is used to

reference the GDS. (Example : COMPANY.EMPLOYEE.G0005V00)

ACTIVE - The Status of a GDS and how it relates to the GDG Structure when it is part

of the Structure.

CATALOG - A Special System Data Set that contains information about the data set or

about a GDG Structure. The data set's location with respect to the DASD or TAPE

Volume Serial, its location within the VTOC (Volume Table of Contents on a DASD),

SMS attributes, and more, are stored within a Catalog.

DCB - Short for Data Control Block. Generally the information regarding data set

attributes like Blocksize, record length, or record format.

GDG

Confidential of 34

DEFERRED - The Status of a GDS and how it relates to the GDG Structure when it is

not yet part of the Structure but exists as a separate cataloged data set.

DSCB - Short for Data Set Control Block. Similar to DCB but sometimes refers to the

attribute information about a data set contained within the Volume Table of Contents on a

Disk storage device.

FORCE - This is a Sub-command of the IDCAMS DELETE command. It will uncatlog

all ACTIVE GDSs as well as the GDG Structure itself. However, it will not delete them

or delete DEFERRED or ROLLED OFF GDSs. Use Caution when coding this command.

GDS - Short form of Generation Data Set. The individual entries within a GDG

Structure

GDG - Short form of Generation Data Group. A set of related data sets. The Data Set

Names are all the same except for the Low Level Qualifier (LLQ) that is the Generation

and Version number.

GENERATION - A term used to describe a unique data set. Usually this is a

chronological relationship where some method is used to distinguish its relative position

in time from another similar data set.

LLQ - Short form of Low Level Qualifier. The last or right most index level within a

Data Set Name.

PATTERN - A Pattern DSCB refers to the DCB characteristics of a Data Set which has

the same name as the Data Set being created (a GDS) except for the LLQ.

PURGE - This is a Sub-command of the IDCAMS DELETE command. It will bypass

the EXPIRY Date (EXPDT) or RETENTION Period (RETPD) protection by deleting

GDSs that have not reached those dates.

RELATIVE - This term refers to a GDS where the data set is referenced by its position

within a GDG Structure. These references are by number and can be negative, positive,

or zero. The relative number is always contained within brackets. (Example:

COMPANY.EMPLOYEE(-3), COMPANY.EMPLOYEE(0), or

COMPANY.EMPLOYEE(+1))

RETAINED - Appears in the Message log from a Batch Job. This means the data set has

been kept by the system. This can refer to an existing data set or a new one. When a GDS

is involved , it should be followed by a message indicating that the data set has been

'ROLLED IN'.

ROLLED IN - Appears in the Message log from a Batch Job. This means the data set is

a valid GDS and has been included in the GDG Structure. This is the equivalent of the

GDG

Confidential of 34

IDCAMS 'ROLLIN' command that forces a GDS into the GDG Structure after the fact.

ROLLED OFF - The Status of a GDS and how it relates to the GDG Structure when it

is not part of the Structure but exists as a separate cataloged data set. This also means the

GDS would have been deleted under normal circumstances due to the addition of a new

GDS.

ROLLIN - An IDCAMS Command parameter that will take a DEFERRED GDS and

make it part of a GDG Structure.

MODEL - A Model DSCB is a Data Set that is used as a pattern for DCB information for

a new Data Set.

GDG_Details

Documents

Transcript of GDG_Details