Generation Data Groups (GDGs) on z/OS offer a unique and versatile approach to accessing data. You can use a relative generation number to access the current generation data set in the GDG while maintaining a fixed data set name in the job JCL.
For example, if you use a GDG data set name in a data map, you can write to the generation data set by using the relative generation number. You do not need the data set name in the data map to be dynamically updated for each generation.
By default, the PowerExchange Listener refreshes the generation table for a GDG with the latest information from the z/OS catalog so that you can use a relative generation number, such as AAA.BBB.CCC(0), to access the latest generation. This behavior is appropriate for long running batch jobs and started tasks such as the PowerExchange Listener, which need to access the current generation by using a relative generation number.
If you set the GDGLOCATE=N statement in the DBMOVER configuration member, after the PowerExchange Listener uses a relative generation number to access a generation data set the first time, all future Listener references to that GDG access the same generation. As a result, for the life of the batch job, the Listener accesses the same generation data set regardless of whether more current generations exist.
If you use relative generation references and want the PowerExchange Listener to refresh the generation table, perform one of the following actions:
Use the default setting of GDGLOCATE=Y in the DBMOVER configuration member. This setting ensures that PowerExchange references the z/OS catalog to get the latest generation information when accessing a GDG to read an existing data set or create a new data set. With this setting, you do not need to restart the PowerExchange Listener.
If you set GDGLOCATE=N in the DBMOVER configuration member, set up a netport job that allows the latest generation data set in a GDG to be referenced. This method is similar to how IMS is handled. Each time the file is accessed, the netport job shuts down and then another netport job is invoked. All GDGs are recognized, as intended.
Ensure that the netport job runs on the same z/OS image as the PowerExchange Listener to satisfy socket API call constraints. Otherwise, the job might timeout.