-
Notifications
You must be signed in to change notification settings - Fork 2
GDG
A generation data group (GDG) is a collection of historically related sequential data sets that are arranged in chronological order. That is, each data set is historically related to the others in the group. They have sequentially ordered absolute and relative names that represent their age. Older data sets have smaller absolute numbers.
The relative name is a signed integer used to refer to the latest (0), the next to the latest (-1), and so forth, generation.
The group of datasets (usually called root) is a properties file that contains the list of generations and files related to it. To guarantee the consistency of file, JEM asks to GRS to lock both the root file and the necessary generation with the same disposition defined in the data description.
[gdgPath]/nnnn
is format of file name for all generations. A sample is following:
Directory gdg/jemtest
Date Time Size Filename
14/06/2012 16:14 1.726 root.properties
11/06/2012 18:11 1.768 00012
11/06/2012 18:11 1.872 00013
11/06/2012 18:27 1.826 00014
11/06/2012 18:28 1.826 00015
13/06/2012 11:37 1.826 00016
13/06/2012 14:58 1.826 00017
13/06/2012 14:59 1.976 00018
13/06/2012 15:16 2.080 00019
14/06/2012 16:13 2.184 00020
14/06/2012 16:13 2.288 00021
gdg/jemtest
is the directory which represents the GDG path and the root.properties is the root of GDG while all others are the files, created, read and written by programs.
Here is the content of root:
#new GDG version
jem.last.generation=21
00012=00012
00013=00013
00014=00014
00015=00015
00016=00016
00017=00017
00018=00018
00019=00019
00020=00020
00021=00021
There is a specific property key, called jem.last.generation
, used to save the last generation of GDG, addressable by index 0 (for this reason is also called generation zero). All the generation are stored inside the properties file, using as key the generation in format nnnnn and as value the complete file name.
In this way, the generation is completely decoupled by the filename which could be changed.
Let's see now a JCL sample to understand how to address the generations:
<taskdef name="step-exec" classname="org.pepstock.jem.ant.tasks.StepExec"></taskdef>
<step-exec executable="cmd" dir="CobolDirectory">
<arg value="/c"></arg>
<arg value="myCobol.exe"></arg>
<dataDescription name="FILEOUT" disposition="NEW">
<dataSet name="gdg/jemtest(1)"></dataSet>
</dataDescription>
<dataDescription name="FILEIN" disposition="SHR">
<dataSet name="gdg/jemtest(0)"></dataSet>
<dataSet name="gdg/jemtest(-1)"></dataSet>
</dataDescription>
</step-exec>
In above sample, in FILEIN data description, JEM will pass generation 0 of GDG, so gdg/jemtest/00021
, and the generation -1, so gdg.jemtest.00020
.
In FILEOUT data description, JEM will pass generation +1 of GDG, so gdg/jemtest/00022
which doesn't exist and it's a new file (see disposition set to NEW). When the step will end, the root will be changed, adding the new generation (22) and changing the property jem.last.generation
set to 22.
Here is the root content after step execution:
#new GDG version
jem.last.generation=22
00012=00012
00013=00013
00014=00014
00015=00015
00016=00016
00017=00017
00018=00018
00019=00019
00020=00020
00021=00021
00022=00022
Using same example to show a table with explanation about relative position to address the GDG:
Physical file name | Relative index | Relative file name | Possible disposition | ANT sample |
---|---|---|---|---|
gdd/jemtest/00020 | (-2) | gdd/jemtest(-2) | OLD, MOD, SHR | <dataDescription name="gdg" disposition="SHR"><dataSet name="gdd/jemtest(-2)"/></dataDescription> |
gdd/jemtest/00021 | (-1) | gdd/jemtest(-1) | OLD, MOD, SHR | <dataDescription name="gdg" disposition="SHR"><dataSet name="gdd/jemtest(-1)"/></dataDescription> |
gdd/jemtest/00022 | (0) | gdd/jemtest(0) | OLD, MOD, SHR | <dataDescription name="gdg" disposition="SHR"><dataSet name="gdd/jemtest(-0)"/></dataDescription> |
gdd/jemtest/00023 | (+1) | gdd/jemtest(+1) | NEW | <dataDescription name="gdg" disposition="NEW"><dataSet name="gdd/jemtest(1)"/></dataDescription> |
- Introduction
- Installation
- Configuration
- Job Execution
- JCL
- User Interfaces
- Security
- REST api
- Features
- Log Messages
- Sandbox
- Software Quality
- Some performance data