What’s in a name? GDG for mainframes to get the job done

Mainframes are different. They are the largest, fastest, and most capable systems on the planet, and they still run many, if not most, of the most important applications in the commercial world.

One reason mainframes remain dominant? Their long history of efficient handling of business data.

In large business data processing environments, it is a common requirement to work with many different consecutive sets of the same type of data. Daily files lead to weekly files, which are then aggregated into monthly and yearly files, all of which must be easily accessible either individually or as a group, in the desired order.

Since the early days of mainframe computing, the Generation Data Group (GDG) has been a means of managing these successive occurrences (or “generations”) of the same data. By simply using a dataset name, applications can select the current or previous generation, create new generations, or use the entire collection of datasets (“GDG-all” request).

This powerful yet simple method of data management is unique to z/OS.

How to create a GDG mainframe

Before the individual datasets that contain the GDG can be created, a “base” GDG entry is created in the catalog using IDCAMS. Once the GDG base is created, individual Generational Data Sets (GDSs) can be created, which are usually common sequence data sets.

A DEFINE statement like the one below accomplishes several different things:

• Creates a GDG base item
• Sets the number of generations to track
• Specifies what to do when the maximum number of generation datasets is reached

DEFINE GDG(NAME(MY.FIRM.DATA)) LIMIT(255) NON-EMPTY SCRATCH

In the above example, each individual Generation Data Set (GDS) is cataloged as it was created, and a maximum of 255 generations (LIMIT value) are kept in the GDG base catalog entry.

Once 255 datasets have been created, the base GDG entry is “full” and the oldest generation must be “started” from the GDG and is scrapped (SCRATCH). Optionally, if EMPTY is specified instead of NOEMPTY, all generations (not just the latest) will start when GDG is full.

The generation datasets belonging to the GDG above have dataset names of the form MY.BUSINESS.DATA.G0001V00where the last qualifier (referred to as the ‘goovoo’ level) specifies absolute generation number – which can range from 0001 to 9999 how generations are created, rolled away and erased. The version number (‘Vxx’) is rarely used.

While it is possible to refer to a specific generation dataset by its absolute name and version, it is more common to use relative generation numbers in the dataset name.

Relative generation is specified by placing parentheses after the base GDG name.

The most recent or current generation is generation zero – in our example it is MY.COMPANY.DATA(0).

• Old generation numbers are preceded by a minus sign – so the generation preceding the current generation would be BUSINESS.DATA(-1)
• New generation are created by entering a plus sign: BUSINESS.DATA(+1) and MY.FIRM.DATA (+2).

When creating new generations, be sure to enter each new generation number in ascending order as the dataset names appear in the JCL, especially in a multi-step job, so that the generations are cataloged correctly.

Generational datasets are commonly used not only for common business applications, but also for system data – especially SMF data. They are particularly flexible because any single generation data set within a GDG can reside on disk or tape, be managed with or without SMS, and have different block sizes or other characteristics.

Nevertheless, GDSs are easily and automatically managed based on their naming convention. The generations are:

• Kept in chronological order
• Automatically deleted as needed
• It is listed individually or as a group

Processing all generations

While most day-to-day processing will likely deal with generating datasets one at a time, applications that process weekly or monthly may want to deal with all generations belonging to the GDG at once.

This can be achieved by simply specifying the GDG base name in the JCL without any relative or absolute generation number. For example:

//ENTER DD DSN=MY.BUSINESS.DATA,DISP=SHR

This “GDG-all” processing treats the DD command as if it were the combined input of all generations belonging to the GDG.

By default, generations are processed from newest to oldest (LIFO order). However, they can be processed from oldest to newest by specifying FIFO either when defining the GDG base or on GDGORDER parameter in the JCL.

In later versions of z/OS, IBM continued to add features to GDG processing, including LIFO ordering and the use of extended GDGs that can track up to 999 generations instead of the previous limit of 255.

Additional GDG-related parameters have been added to the JCL. Default values ​​for GDG DEFINE can now be set in the IGGCATxx member of SYS1.PARMLIB. In addition, users of Precisely Syncsort The Allocation Control Center (ACC) can take advantage of system allocation standards enforced by the ACC Policy Rules Engine to set policies for the creation and characteristics of not only data set generation, but all types of other SMS or non-SMS data.

GDG: Basic Power of z/OS

GDG processing is a unique strength of z/OS.

With very little effort, multiple iterations of related data can be grouped, tracked, and managed using common batch and catalog processing.

GDGs are easy to understand and useful for a wide range of business and system data. They are often the backbone of some of the most important applications running on today’s z/OS.

To learn more and take the next step beyond GDG, see how Syncsort Storage Management helps you optimize your IBM Z storage and avoid costly space-related failures.

The post What’s in a name? GDG for Mainframes Get the Job Done appeared first on Precisely.