GDGCOPY is a handy little utility that will copy all the generations in a Generation Data Group into their ascending order by creation (generation) number, rather than in descending order, which is what you will get if you allow MVS to do the concatenation for you.
GDGCOPY is located in File #482 of the CBT tape and was written by Eric Bielefeld at P&H Mining Equipment in Milwaukee, WI. He posted information about his utility on bit.listserv.ibm-main back in 2001 and I have kept a hardcopy of the message on the wall by my desk since then, thinking someday I would get around to installing this under Hercules/MVS. Finally! I'm not sure there will be a great deal of use for this utility in the Hercules/MVS community, but it is great to know that it exists and how to use it.
There were no changes required to assemble and link-edit Eric's program under MVS 3.8j. He supplies the assembler source for GDGCOPY, plus three macros - $REGS, $PROLOG, and $EPILOG - in the CBT file. Since the F assembler doesn't accept inline macros, I built a jobstream that creates a temporary macro library containing the three macros and then assembles and link-edits the utility to SYS2.LINKLIB. The installation jobstream and the jobstream to execute the utility are included in gdgcopy.tgz [MD5: 2F40387A6C2684C1A05031C26A4B62D9].
Download the archive and extract the jobstream (WinZip on Windows/?? or tar on Linux). Submit the jobstream to assemble and link the single load module for GDGCOPY into SYS2.LINKLIB. If you don't have SYS2.LINKLIB defined, you will need to modify the jobstream to specify a different target load library.
The input dataset name is passed to the program via PARM='???' and consists of the name of the Generation Data Group (the high level of the GDG). It is used to dynamically allocate each generation dataset in the group, oldest first, followed by the second oldest, through to the latest generation.
If the output dataset is specified as a new (+1) generation of the same GDG, once the job completes, you can uncatalog and scratch all but the last (newly created) generation. The program does not uncatalog or scratch any dataset.
DCB information must be given for the input datasets, if they are unlabled (NL) or have non-standard labels, and must always be provided for the output dataset. To include DCB information for unlabeled input, include a //SYSUT DD DCB=??? card with the proper DCB parameters. For VS/VBS datasets, BFTEK=A will be added to the SYSUT1 DCB via open exit. This is to ensure that a logical record is passed by QSAM and allows the output to be reblocked (if specified).
I created a small test GDG - five generations of twenty records each - each record has a record number and visible indication of which generation it belongs to. Then I ran a couple of jobs against the GDG for comparison - SYSREPRO, specifying the GDG name and allowing MVS data management to concatenate the generation datasets, and GDGCOPY. The output may be viewed at GDGCOPYP.
I hope that you have found my instructions useful. If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:
This page was last updated on January 17, 2015 .