Anda di halaman 1dari 34

GDG

GENERATION DATA GROUPS (GDG)

Confidential Page 1 of 34
GDG

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 -

Confidential Page 2 of 34
GDG

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.

Confidential Page 3 of 34
GDG

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 :

Confidential Page 4 of 34
GDG

'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

Confidential Page 5 of 34
GDG

'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.G0002V00'

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


'COMPANY.EMPLOYEE.G0003V00'
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:

'COMPANY.EMPLOYEE.G0002V00'

Confidential Page 6 of 34
GDG

However, this appears the only advantage to a GDG is not having to rename the data sets
every month as we did before.

CATALOG

GDG Structure for COMPANY.EMPLOYEE

G0001V00 G0002V00 G0003V00

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).

CATALOG

GDG Structure for COMPANY.EMPLOYEE

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

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).
Confidential Page 7 of 34
GDG

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 :

Confidential Page 8 of 34
GDG

//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:

//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)
//STEP2 EXEC PGM=MYPGM2
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//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.

Confidential Page 9 of 34
GDG

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
Confidential Page 10 of 34
GDG

Control Language and IDCAMS control information would be :

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


//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

Confidential Page 11 of 34
GDG

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
Confidential Page 12 of 34
GDG

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:

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


//STEP1 EXEC PGM=MYPGM
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//NEWGENDD DSN=COMPANY.EMPLOYEE(+1),
// DISP=(NEW,CATLG),
// 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.

Confidential Page 13 of 34
GDG

The following example shows where everything is not normal.

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


//STEP1 EXEC PGM=MYPGM
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//NEWGEN DD DSN=COMPANY.EMPLOYEE(+1),
// DISP=(NEW,KEEP),
// SPACE=(TRK,(5,5)),DCB=(RECFM=FB,LRECL=80)
//STEP2 EXEC PGM=MYPGM2
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//NEWGEN DD DSN=COMPANY.EMPLOYEE(+1),
// 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:

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


//STEP1 EXEC PGM=MYPGM
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//NEWGEN DD DSN=COMPANY.EMPLOYEE(+1),
// DISP=(NEW,PASS), <- CHANGED
// SPACE=(TRK,(5,5)),DCB=(RECFM=FB,LRECL=80)
//STEP2 EXEC PGM=MYPGM2

Confidential Page 14 of 34
GDG

//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//NEWGEN DD DSN=COMPANY.EMPLOYEE(+1),
// 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.

CATALOG

GDG Structure for COMPANY.EMPLOYEE

G0001V00 G0002V00 G0003V00 G0004V00

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

Confidential Page 15 of 34
GDG

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


//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=X
//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

NONVSAM ------- COMPANY.EMPLOYEE.G0002V00


IN-CAT --- CATALOG.NV.CAT01

NONVSAM ------- COMPANY.EMPLOYEE.G0003V00


IN-CAT --- CATALOG.NV.CAT01
Confidential Page 16 of 34
GDG

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:

NONVSAM ------- COMPANY.EMPLOYEE.G0004V00


IN-CAT --- CATALOG.NV.CAT01

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


IN-CAT --- CATALOG.NV.CAT01

NONVSAM ------- COMPANY.EMPLOYEE.G0002V00


IN-CAT --- CATALOG.NV.CAT01

NONVSAM ------- COMPANY.EMPLOYEE.G0003V00


IN-CAT --- CATALOG.NV.CAT01

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
Confidential Page 17 of 34
GDG

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.

NONVSAM ------- COMPANY.EMPLOYEE.G0004V00


IN-CAT --- CATALOG.NV.CAT01
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

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


IN-CAT --- CATALOG.NV.CAT01
HISTORY
DATASET-OWNER----(NULL) CREATION--------1997.100
RELEASE-----------------------2 EXPIRATION-----0000.000
ACCOUNT-INFO-------------------------------------------(NULL)
STATUS--------------ACTIVE
SMSDATA
STORAGECLASS--STANDARD MANAGEMENTCLASS-STANDARD
DATACLASS-----FB80 LBACKUP --XXXX.XXX.XXXX
VOLUMES
VOLSER--------------US1900 DEVTYPE------X'3010200F' FSEQN---
-----0
ASSOCIATIONS------------(NULL)
ATTRIBUTES

NONVSAM ------- COMPANY.EMPLOYEE.G0002V00


IN-CAT --- CATALOG.NV.CAT01

Confidential Page 18 of 34
GDG

HISTORY
DATASET-OWNER----(NULL) CREATION--------1997.100
RELEASE-----------------------2 EXPIRATION-----0000.000
ACCOUNT-INFO-------------------------------------------(NULL)
STATUS--------------ACTIVE
SMSDATA
STORAGECLASS--STANDARD MANAGEMENTCLASS-STANDARD
DATACLASS-----FB80 LBACKUP --XXXX.XXX.XXXX
VOLUMES
VOLSER--------------US1900 DEVTYPE------X'3010200F' FSEQN---
-----0
ASSOCIATIONS------------(NULL)
ATTRIBUTES

NONVSAM ------- COMPANY.EMPLOYEE.G0003V00


IN-CAT --- CATALOG.NV.CAT01
HISTORY
DATASET-OWNER----(NULL) CREATION--------1997.100
RELEASE-----------------------2 EXPIRATION-----0000.000
ACCOUNT-INFO-------------------------------------------(NULL)
STATUS--------------ACTIVE
SMSDATA
STORAGECLASS--STANDARD MANAGEMENTCLASS-STANDARD
DATACLASS-----FB80 LBACKUP --XXXX.XXX.XXXX
VOLUMES
VOLSER--------------US1900 DEVTYPE------X'3010200F' FSEQN---
-----0
ASSOCIATIONS------------(NULL)
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.

Confidential Page 19 of 34
GDG

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....
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=X
//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),
// DISP=(NEW,CATLG),
// DCB=(RECFM=FB,LRECL=80),SPACE=(TRK,(5,5))

Confidential Page 20 of 34
GDG

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.

Confidential Page 21 of 34
GDG

CATALOG

GDG Structure for COMPANY.EMPLOYEE

G0001V00 G0002V00 G0003V00 G0004V00

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
NONVSAM ---- COMPANY.EMPLOYEE.G0002V00
STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0003V00
STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0004V00
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):
Confidential Page 22 of 34
GDG

NONVSAM ---- COMPANY.EMPLOYEE.G0001V00


STATUS ---- ROLLED OFF
NONVSAM ---- COMPANY.EMPLOYEE.G0005V00
STATUS ---- DEFERRED
NONVSAM ---- COMPANY.EMPLOYEE.G0002V00
STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0003V00
STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0004V00
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 ---- ROLLED OFF
NONVSAM ---- COMPANY.EMPLOYEE.G0002V00
STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0003V00
STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0004V00
STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0005V00
STATUS ---- DEFERRED
They are back in order again!

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

Confidential Page 23 of 34
GDG

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

Here are what the parameters mean:

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):

NONVSAM ---- COMPANY.EMPLOYEE.G0001V00


STATUS ---- ROLLED OFF
NONVSAM ---- COMPANY.EMPLOYEE.G0002V00
STATUS ---- ROLLED OFF
NONVSAM ---- COMPANY.EMPLOYEE.G0006V00
STATUS ---- DEFERRED
NONVSAM ---- COMPANY.EMPLOYEE.G0007V00
STATUS ---- DEFERRED
NONVSAM ---- COMPANY.EMPLOYEE.G0003V00
STATUS ---- ACTIVE
Confidential Page 24 of 34
GDG

NONVSAM ---- COMPANY.EMPLOYEE.G0004V00


STATUS ---- ACTIVE
NONVSAM ---- COMPANY.EMPLOYEE.G0005V00
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)
Here are what the parameters mean:

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

Here are what the parameters mean:

Confidential Page 25 of 34
GDG

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

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

Confidential Page 26 of 34
GDG

NOTE: There are similar On-line commands available through the 'GDG' TSO ISPF
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
//SYSPRINT DD SYSOUT=X
//SYSIN DD *
DELETE COMPANY.EMPLOYEE.G0004V00 PURGE
DELETE COMPANY.EMPLOYEE.G0003V00 PURGE
DELETE COMPANY.EMPLOYEE.G0002V00 PURGE

Here are what the parameters mean:

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....
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=X
//SYSIN DD *
DELETE COMPANY.EMPLOYEE.* PURGE

Here are what the parameters mean:

DELETE - This Command will delete and uncatalog the data set name that follows
Confidential Page 27 of 34
GDG

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 :

Confidential Page 28 of 34
GDG

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

Image of a TSO ISPF Screen showing the GDG option panel

Here are what the parameters mean:

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

Confidential Page 29 of 34
GDG

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?

Confidential Page 30 of 34
GDG

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


//STEP1 EXEC PGM=MYPGM
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//SYSPRINT DD SYSOUT=X
//GDGIN DD DSN=COMPANY.EMPLOYEE(0),DISP=SHR

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

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


//STEP1 EXEC PGM=MYPGM
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//SYSPRINT DD SYSOUT=X
//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 ?

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


//STEP1 EXEC PGM=MYPGM
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//SYSPRINT DD SYSOUT=X
//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:

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


//STEP1 EXEC PGM=MYPGM
//STEPLIB DD DSN=MY.PGMLIB,DISP=SHR
//SYSPRINT DD SYSOUT=X
//GDGIN DD DSN=COMPANY.EMPLOYEE(0),DISP=SHR
// DD DSN=COMPANY.EMPLOYEE(-1),DISP=SHR
// DD DSN=COMPANY.EMPLOYEE(-2),DISP=SHR

Confidential Page 31 of 34
GDG

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.

Confidential Page 32 of 34
GDG

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
Confidential Page 33 of 34
GDG

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.

Confidential Page 34 of 34

Anda mungkin juga menyukai