|
|
|
You can refer collectively to all of the data sets in a GDG as a single data set for input by omitting the generation number when you define the transmission definition. This causes all data sets in the GDG to be treated as one sequential data set, beginning with the current relative generation 0 and ending with the oldest data set (-n) in the GDG.
Use of collective concatenation makes it possible to cater to accumulate data before transmission and eliminates the need to know the exact number of generations that need to be transmitted. In our example, entry of GDG.IN would imply all data sets that currently exist within the GDG.
Restart of transmissions that refer collectively to all data sets in a GDG is not supported and a cold start is performed. The data sets that exist in the GDG at the time of the cold start are used. In such cases there is no resolution or checkpointing of the individual data set names in the GDG when the transmission request is scheduled.
Attempts to collectively reference (for instance, no generation number is specified) a GDG as an output data set are rejected. For new data sets, this results in dynamic allocation errors because the catalog index structure is incorrect. For existing data sets (OLD or SHR), the transmission fails with an appropriate completion code, because allowing it to proceed would result in the entire transmission being written to the current relative generation 0 data set. Thus, for output to a GDG, the TO data set name must always specify either a relative or absolute generation number.
An alternative to collective concatenation of GDGs is using a system utility to copy the entire GDG to a sequential data set before transmission and performing the transmission from that data set.
Note: While Generation Data Groups offer great potential for improving operational efficiency, you must consider the procedures established for their use, keeping the above points in mind.
| Copyright © 2010 CA. All rights reserved. |
|