IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Info on GDG


IBM Mainframe Forums -> Mainframe Interview Questions
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
gsnvsr

New User


Joined: 06 Jul 2005
Posts: 40

PostPosted: Wed Jul 13, 2005 5:31 pm
Reply with quote

Can someone help me understand these GDG's? Though a search in google can give some info, I thought this is the best place to find answers.
There was a reply posted on the documentation abt GDG a while back, but that link doesn't seem to work any longer. If someone can post a link or doc, that will be helpful.

Thanks in adavance!

Prasad
Back to top
View user's profile Send private message
therasith

New User


Joined: 02 Jan 2004
Posts: 52
Location: chennai

PostPosted: Wed Jul 13, 2005 7:00 pm
Reply with quote

GENERATION DATA GROUPS
__________ ____ ______
APPLICATION OF GENERATION DATA GROUPS

___________ __ __________ ____ ______

A Generation Data Group, often abbreviated GDG, is a facility of the oper- ating system that keeps track of periodic or cyclical data sets. As the name suggests, each new data set that is created forms a new "generation" in a series. Generation data groups typically follow this pattern:

1. A new generation of the data set is added.

2. Some number of the previous generations of the data set are
retained.

3. The oldest generation of the data set is deleted.

Of course, you don't have to delete the oldest generation of the data set, but there are few data sets for which you need to keep all generations forever.

Typical nomenclature for the generations of data sets is:

Current version Current generation
Previous version Parent or minus 1 version
Next previous version Grandparent or minus 2 version

The data set naming convention uses a number to indicate the generation.

DSN=data-set-name(0) Current generation
DSN=data-set-name(-1) Previous generation or parent
DSN=data-set-name(-2) Next previous generation or grandparent

The biggest advantage of using generation data groups is that the system keeps track of the generations for you so you don't have to change your JCL each time you run.

Generation data groups consist of data sets that are normal except for their names. The data sets can be sequential, partitioned, or direct. The benefit of using generation data groups is that the system keeps track of the generations for you. You don't have to keep track of many individual data set names.

For example:

With normal data set names: With generation data group names:

ACCT.DEC.DATA ACCT.DATA(0)
ACCT.NOV.DATA ACCT.DATA(-1)
ACCT.OCT.DATA ACCT.DATA(-2)

To add a new generation to a generation data group, you just create a data set with the same name as before and +1 for the generation:

DSN=data-set-name(+1)

The system then changes all the previous generation names so that the old (0) becomes (-1), the old (-1) becomes (-2), etc. Here's an example:

Before job completes: After job completes:

ACCT.DATA(+1) ACCT.DATA(0)
ACCT.DATA(0) ACCT.DATA(-1)
ACCT.DATA(-1) ACCT.DATA(-2)
ACCT.DATA(-2) Deleted--if only 3 generations were to be kept

With a generation data group named ACCT.DATA, you could add a new generation by creating a data set named ACCT.DATA(+1):

//ddname DD DSN=ACCT.DATA(+1),DISP=(NEW,CATLG),...

If you used individual data set names instead, you would need to do the following:

1. Change the JCL to create the new data set name, such as
ACCT.DEC.DATA.

2. Delete the previous third generation, such as ACCT.SEPT.DATA (if
you wanted to keep only three generations).

With generation data groups, there is no need to change the JCL. You just run it each time you want to create a new generation. The system keeps track of generation data groups in the catalog. Of course, this means that when you specify the disposition for a new generation data set, you must specify CATLG.

To make things consistent within a given job, generation data group numbers are not updated at the end of the job step in which a new generation is created. Instead, they are updated at the end of the job. This is important to as (+1) throughout the job.

+---------------------------------------------------------------------------+
//UPDATE01 JOB ...
//STEP1 EXEC PGM=CREATE
//OUT DD DSN=ACCT.DATA(+1),DISP=(NEW,CATLG),...
...
//STEP2 EXEC PGM=REPORT
//IN DD DSN=ACCT.DATA(+1),DISP=OLD
+---------------------------------------------------------------------------+

You refer to generation data group generations as:

name(+n) or name(0) or name(-n)

The system actually names the data sets as follows:

name.GnnnnVvv

nnnn is the absolute generation number, 0000-9999.
vv is the version number. Usually this is 00. (You can create
different versions of the same generation, but not with JCL, and
we get into that here.)

For example:

Name you use Name you use Actual name (used during
during the job: after the job: and after the job):

ACCT.DATA(+1) ACCT.DATA(0) ACCT.DATA.G0008V00
ACCT.DATA(0) ACCT.DATA(-1) ACCT.DATA.G0007V00
ACCT.DATA(-1) ACCT.DATA(-2) ACCT.DATA.G0006V00
ACCT.DATA(-2) Deleted ACCT.DATA.G0005V00

Since you refer to a generation data group as:

name(+n) or name(0) or name(-n)

you don't need to keep track of the real data set name:

name.GnnnnV00

The system does that for you. But if you're looking at your data sets with a tool such as ISPF, it's nice to know how your data sets are actually named, because the actual name is what you'll see with ISPF.

If the generation data group contains partitioned data sets, you must use the real data set name to refer to a member:

name.GnnnnV00(member)

Generation data groups are rarely used for partitioned data sets, however. When you create the first generation of a generation data group:

name(+1)

it is actually named name.G0000V00. The next generation of the data set is named name.G0001V00, the next name.G0002V00, and so on. You must not exceed 10,000 (0000-9999) total generations. Furthermore, you can keep only 256 ((0) to (-255)) generations active at any one time. That is, generation data groups are numbered from 0 to 9999. Only 256 of these can be active at any one time. So generations 6000 to 6255 could be active, and generations 0 to 5999 would all be inactive.

The individual generations in a generation data group don't all have to have the same DCB attributes. The RECFM, LRECL, BLKSIZE, and even DSORG can all be different. However, the DCB attributes are usually the same. If they are the same, you can refer to the generation data group without a generation number.

DSN=data-set-name

The system then concatenates all the generations (current to oldest generation) for the processing. This might be used to produce such things as year-to-date reports.

Generation data groups can reside on disk or tape.


TOPIC 11.2: CREATING AND USING GENERATION DATA GROUPS
_____ _____ ________ ___ _____ __________ ____ ______

To create a generation data group, you must first do these two things:

1. Create a generation data group base entry in a VSAM catalog. This
entry names the generation data group and specifies how many
generations to keep.

2. Create a data set label on the same volume as that used for the
VSAM catalog entry. The data set label is used as a model for the
generation data group. The DCB sub-parameters on the label may or
may not be used for the data sets for the generation data group.


CREATING A GENERATION DATA GROUP BASE ENTRY

o Sets up the catalog entry used to keep track of the generation data
group generations.

o Names the generation data group.

o Specifies how many generations are to be kept.

o Tells what to do with old generations (those that get bumped).

o As an option, tells how long to keep the entire generation data
group.

You create a generation data group base entry by executing a VSAM utility
program called IDCAMS. Here is an example:

+---------------------------------------------------------------------------+
//jobname JOB ...
/ EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE GDG ( -
NAME (X2222.ANNUAL.DATA) -
LIMIT(12) -
NOEMPTY -
SCRATCH )
/*
+---------------------------------------------------------------------------+

The NAME parameter names this generation data group as X2222.ANNUAL.DATA.

The VSAM utility programs have a different syntax from the regular utility programs, which in turn are different from JCL. The dash at the end of a line continues a statement only for the VSAM utilities.

Here's an explanation for the DEFINE statement used to create a generation data group base entry:

DEFINE GDG ( -
(The items following GDG are enclosed in parentheses. The - indi-
cates that the statement is continued.)

NAME (generation-data-group-name) -

LIMIT(generations) -
(The number of generations to be kept. The value can be 1 through
255.)

NOEMPTY -
(This tells what to do with the old generations. Coding NOEMPTY
requests that the LIMIT number of newest generations be kept and
the remainder be deleted. If you code EMPTY instead, all the old
generations are deleted, and only the (+1) generation is kept when
the LIMIT is reached.)

Here's the DEFINE statement with EMPTY coded rather than NOEMPTY:

+---------------------------------------------------------------------------+
DEFINE GDG ( -
NAME (X2222.ANNUAL.DATA) -
LIMIT(12) -
EMPTY SCRATCH )
+---------------------------------------------------------------------------+

NOEMPTY - When the LIMIT number is exceeded, NOEMPTY keeps the LIMIT
number of newest generations.

EMPTY - When the LIMIT number is exceeded, EMPTY keeps only the most
recent generation.

EMPTY is mainly used to wipe out all the old data sets for the beginning of a new time period.

Here's some more of the DEFINE statement:

DEFINE GDG ( -
NAME (generation-data-group-name) -
LIMIT(generations) -
NOEMPTY -
(EMPTY or NOEMPTY)
SCRATCH -
(SCRATCH tells the system to uncatalog and delete the old gener-
ations--those not kept. You could code NOSCRATCH instead, and the
system would uncatalog the data sets and keep them. Generally you
would back up the data set to tape and then just code SCRATCH to
keep things simple.)
FOR(days) )
(FOR is optional. It specifies the number of days to keep a
generation data group. As an alternative, you can specify the
retention period as TO(yymmdd).)


CREATING A MODEL DATA SET LABEL

The second step in creating a generation data group, after the IDCAMS program is used to create a base entry, is to create a data set to be used as a model for the generation data group. Actually, the system doesn't need an entire data set. It just requires the DCB information contained in the data set label. The following JCL can be used to create a data set label. The IEFBR14 program doesn't do anything--it just allows a step to be executed so that the DD statement is processed.


+---------------------------------------------------------------------------+
//jobname JOB ...
// EXEC PGM=IEFBR14
//DD1 DD DSN=data-set-name,DISP=(NEW,KEEP),
// SPACE=(TRK,0),
// UNIT=unit,VOL=SER=volume,
// DCB=(whatever sub-parameters you want)
+---------------------------------------------------------------------------+

data-set-name This is usually the generation data group name, but

volume This must be the number of the volume containing the
VSAM catalog base entry for the generation data group.
The system will only look in this volume for the model
data set label.

SPACE=(TRK,0) is coded because creating a data set on disk without allo-cating space to the data set results in just the data set label being created, which is all that is required.


CREATING A DATA SET FOR A GENERATION DATA GROUP

To create a new data set for a generation data group, you provide the generation number for the new generation.

+---------------------------------------------------------------------------+
//jobname JOB ...
//STEP1 EXEC PGM=CREATE
//IN DD ...
//OUT DD DSN=X2222.ANNUAL.DATA(+1),
// UNIT=SYSDA,VOL=SER=PACK12,
// DISP=(NEW,CATLG),SPACE=(6160,(20,10))
+---------------------------------------------------------------------------+

If the model data set being used for the generation data group does not have the same name as the generation data group, you must name this model data set with the DCB parameter:

+---------------------------------------------------------------------------+
//jobname JOB ...
//STEP1 EXEC PGM=CREATE
//IN DD ...
//OUT DD DSN=X2222.ANNUAL.DATA(+1),
// UNIT=SYSDA,VOL=SER=PACK12,
// DISP=(NEW,CATLG),SPACE=(6160,(20,10)),
// DCB=Y3333.MODEL.DATA
+---------------------------------------------------------------------------+

The requirements for creating a new data set for a generation data group are:

o The DISP parameter must be CATLG. All the generation data group
information is kept in the catalog.

? The DCB sub-parameters are copied from the model. The DCB
Parameter must refer to a data set name being used as the model.

o You must name the new generation as follows:

generation-data-group-name(+n)

Although there must always be a model data set label when you create a new generation, you don't have to actually use any of its DCB sub-parameters. You

+---------------------------------------------------------------------------+
//jobname JOB ...
//STEP1 EXEC PGM=CREATE
//IN DD *
//OUT DD DSN=X2222.ANNUAL.DATA(+1),DISP=(NEW,CATLG),
// SPACE=(6200,(120,10)),
// UNIT=SYSDA,VOL=SER=PACK12,
// DCB=(Y3333.MODEL.DATA,BLKSIZE=6120)
+---------------------------------------------------------------------------+

The model data set label doesn't have to have the same name as the gener-ation data group. If it has a different name, you can catalog it, too. Here's an example:

+---------------------------------------------------------------------------+
//jobname JOB ...
// EXEC PGM=IEFBR14
//DD1 DD DSN=Y3333.MODEL,DISP=(NEW,CATLG),
// SPACE=(TRK,0),UNIT=SYSDA,VOL=SER=PACK12,
// DCB=(RECFM=VB,LRECL=255,BLKSIZE=6250)
...
//jobname JOB ...
// EXEC PGM=CREATE
//IN DD ...
//OUT DD DSN=X2222.ANNUAL.DATA(+1),DISP=(NEW,CATLG),
// SPACE=(6160,(30,2),RLSE),
// UNIT=SYSDA,VOL=SER=PACK12,
// DCB=(Y3333.MODEL,RECFM=FB,LRECL=80,BLKSIZE=6160)
+---------------------------------------------------------------------------+

Y3333.MODEL is the model data set for the X2222.ANNUAL.DATA generation data group. None of Y3333.MODEL's DCB sub-parameters is used in this example.

You can copy the following DCB sub-parameters from the model data set:

DSORG OPTCD
RECFM KEYLEN
LRECL RKP
BLKSIZE

Of course, you don't need to use any of them, if you don't want to.



Therasith
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> Mainframe Interview Questions

 


Similar Topics
Topic Forum Replies
No new posts in REXX,how to get sysprt info CLIST & REXX 9
No new posts Copy a PDS to a new PDS - why do I ne... TSO/ISPF 8
No new posts Tivoli INFO/MANAGEMENT IBM Tools 1
No new posts Recreating VSAM cluster catalog info ... All Other Mainframe Topics 6
No new posts Need an info to store Hexadecimal val... DB2 5
Search our Forums:

Back to Top