Model 204 USE OF AND ACCESS TO PRODUCTS AND FEATURES ARE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE USER’S SOFTWARE LICENSE. THE PRESENTATION OF MATERIAL HEREIN DOES NOT, IN ANY MANNER, MODIFY SUCH TERMS AND CONDITIONS.
Using GDGs for CCAJRNL, CCAJLOG, and CHKPOINT By James Damon
As the requirement for true 24x7 operations increases, so too does the need to have facilities, such as dataset management, to support that requirement. In V6R1.0 CCA introduced support for Generation Data Groups (GDGs) to help you -- both in your implementation of 24x7 operations and to significantly reduce the risk of filling CCAJRNL, CCAJLOG, and CHKPOINT in z/OS environments. GDGs are not supported by the z/VM and VSE operating systems.
What is a GDG?
IBM defines a GDG as:
“A collection of historically related non-VSAM data sets that are arranged in chronological order; each data set is called a generation data set.”
Suppose your CCAJRNL dataset is named V6R1.CCAJRNL.M204. When defined as a GDG to the operating system and to Model 204 as a GDG stream, this dataset name, called the GDG Base Entry, is used to automatically allocate at least one, and potentially multiple datasets in a single Model 204 job step. Those datasets are named:
V6R1.CCAJRNL.M204.G0001V00 V6R1.CCAJRNL.M204.G0002V00 V6R1.CCAJRNL.M204.G0003V00 And so on…
V6R1.CCAJRNL.M204.G0001V00 V6R1.CCAJRNL.M204.G0002V00 V6R1.CCAJRNL.M204.G0003V00
And so on…
The first dataset is allocated during Model 204 initialization. If that dataset fills at any time during the run, the second dataset is allocated and the run continues without interruption. If the second dataset fills, the third is allocated and so on. The number of datasets that can be allocated in this manner is very large, but only LIM number of datasets (as described further on) are cataloged.
Defining a GDG to z/OS
The IDCAMS job step, shown in Figure 1, defines this GDG Base Entry to the operating system.
Figure 1. Defining a GDG Base Entry to the operating system
//LISTC EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE GENERATIONDATAGROUP - (NAME(V610.CCAJRNL.M204) - NOEMPTY NOSCRATCH - LIM(25)
Note the important keywords in this definition: NOEMPTY, NOSCRATCH and LIM. Although NOEMPTY and NOSCRATCH are the default parameters when creating a GDG, you should set them explicitly as part of good programming practices. They tell the operating system not to delete generation datasets even when the limit (LIM) of generation datasets for the group is exceeded.
The LIM parameter specifies the maximum number of generation datasets, from 1 to 255, that can be associated with the GDG being defined. You can determine a value for LIM based on your experience with size requirements for each of the datasets you define as a GDG. The number should provide a healthy overrun capacity to cover unpredictable situations.
When LIM is exceeded, the oldest generation dataset is uncataloged, but it is not scratched (NOSCRATCH) from the volume where it was allocated, unless datasets are managed by SMS. Note well: In this case, uncataloged datasets are always deleted, regardless of the NOSCRATCH NOEMPTY. If any recovery datasets are scratched, recovery processing, should it be required, is impossible.
Defining a GDG to Model 204
In Figure 2 the DEFINE command establishes CCAJRNL as a GDG to Model 204.
Figure 2. Defining CCAJRNL as a GDG
DEFINE STREAM CCAJRNL WITH SCOPE=SYSTEM GDG=GDGJRNL CONTROL=CTLJRNL DEFINE DATASET GDGJRNL WITH SCOPE=SYSTEM CATALOG GEN=+1 CYL PRI 100 - DSN=V6R1.CCAJRNL.M204 UNIT=DISKGROUP DEFINE DATASET CTLJRNL WITH SCOPE=SYSTEM OLD - DSN=V6R1.CCAJRNL.CTL.M204
The first DEFINE command merely defines CCAJRNL as a GDG stream. GDG=GDGJRNL identifies the ddname that points to the GDG Base Entry, DSN=V6R1.CCAJRNL.M204. A control dataset is also required for GDG streams and it is identified by CONTROL=CTLJRNL. The control dataset is a small sequential dataset; a space allocation of TRK,(1,1) is sufficient. The control dataset keeps track of all generation datasets associated with the GDG Base Entry that have been allocated in one Model 204 run. While some of the data in the control dataset is in hexadecimal, each entry also contains the printable name of the generation dataset allocated and can be viewed under TSO. Figure 3 shows a typical collection of entries in the control dataset.
Figure 3. A GDG stream for CCAJRNL
BROWSE V6R1.CCAJRNL.CTL.M204 Line 00000000 Col 001 076 Command ===> Scroll ===> CSR ****************************** Top of Data ******************************** .........................+1 .V6R1.CCAJRNL.M204.G0001V00 . .......... á............+2 .V6R1.CCAJRNL.M204.G0002V00 . ...........&.........í..+3 .V6R1.CCAJRNL.M204.G0003V00 . ...........Ã........=..+4 .V6R1.CCAJRNL.M204.G0004V00 . ...........n.........x..+5 .V6R1.CCAJRNL.M204.G0005V00 . ...........î..........J..+6 .V6R1.CCAJRNL.M204.G0006V00 . ***************************** Bottom of Data ******************************
Based on the GDG definition from Figure 2, each of these datasets is allocated with a primary allocation of 100 cylinders. As no secondary allocation is specified, each dataset is closed after consuming 100 cylinders, the next generation dataset is allocated and the run continues. This is indicated in CCAAUDIT with the messages shown in Figure 4:
Figure 4. Part of CCAAUDIT tracking GDG expansion
M204.0055: I/O ERROR - NO MORE SPACE IN THIS DATASET - CCAJRNL M204.1846: MEMBER +2 OF GDG STREAM CCAJRNL NOW ACTIVE V6R1.CCAJRNL.M204.G0002V00 M204.0055: I/O ERROR - NO MORE SPACE IN THIS DATASET - CCAJRNL M204.1846: MEMBER +3 OF GDG STREAM CCAJRNL NOW ACTIVE V6R1.CCAJRNL.M204.G0003V00 M204.0055: I/O ERROR - NO MORE SPACE IN THIS DATASET - CCAJRNL M204.1846: MEMBER +4 OF GDG STREAM CCAJRNL NOW ACTIVE V6R1.CCAJRNL.M204.G0004V00 M204.0055: I/O ERROR - NO MORE SPACE IN THIS DATASET - CCAJRNL M204.1846: MEMBER +5 OF GDG STREAM CCAJRNL NOW ACTIVE V6R1.CCAJRNL.M204.G0005V00 M204.0055: I/O ERROR - NO MORE SPACE IN THIS DATASET - CCAJRNL M204.1846: MEMBER +6 OF GDG STREAM CCAJRNL NOW ACTIVE V6R1.CCAJRNL.M204.G0006V0
Since LIM(25) is specified for this GDG, 19 more generation datasets could be allocated before the oldest dataset is uncataloged. However, since the GDG definition specifies NOSCRATCH, the dataset is not deleted. Although virtually an unlimited number of datasets can be allocated and used in one run, only the most recent 25 are cataloged. This has the potential to cause a failure in recovery, since all datasets must be available. If LIM is exceeded, many datasets may be uncataloged.
If you can find those uncataloged datasets, you can rename them and catalog them under the new name. Recovery could then run, if those datasets are all concatenated under the ddname=CCARF. However, this would be a manual and time consuming process. Carefully monitoring M204.0055 and M204.1846 messages is a much easier way to determine the proper value of the LIM parameter and prevent this from happening.
Using a GDG in recovery
A recovery step, using the previous CCAJRNL datasets, would define CCARF as follows:
DEFINE STREAM CCARF WITH SCOPE=SYSTEM GDG=GDGJRNL CONTROL=CTLJRNL DEFINE DATASET GDGJRNL WITH SCOPE=SYSTEM OLD - DSN=V6R1.CCAJRNL.M204 DEFINE DATASET CTLJRNL WITH SCOPE=SYSTEM OLD - DSN=V6R1.CCAJRNL.CTL.M204
The control dataset determines the correct generation datatsets, and in what order they are input to roll forward recovery. The example is the same if you define CHKPOINT as a GDG in the Online run and RESTART as a GDG in the recovery step.
Summary
If you are looking for a way to virtually eliminate the possibility of filling the CCAJRNL, CHKPOINT, or CCAJLOG datasets, consider using the new GDG feature in V6R1.0. The GDG feature provides a flexible, easy-to-use interface between Model 204 and the operating system component that allocates and manages generation datasets and should greatly assist in making Model 204 a 24x7 application in a z/OS environment.
