Accessing GDGs

[leo6]

Hi ,

I have a GDG having the current version as
NS10.RAD.CFILE.G0070V00 .
Can I access the 25th version of this GDG by writing
as
NS10.RAD.CFILE(25) ? Or
NS10.RAD.CFILE(-45) ..(70-45 = 25)
Because for current version, hope we can write something like
NS10.RAD.CFILE(0) .Also NS10.RAD.CFILE(+1) creates the next version of the GDG..

Thank you.

 

[Glenn9999]

First question: are all the versions of the GDG present?

(+1) is the next version if you want to write a new copy.
(0) is the current version if you want to read it.
(-1) is the last version before that.
(-2) is the version before that, and so on.

So the 25th one back would be (-24)

 

[stevexff]

Comon GDG gotcha: if you read GDG(0) and create the (+1) in a job, it remains (+1) for all subsequent steps of the job. If one of the subsequent steps fails and you have to restart it, the catalog has been updated, and version that was (+1) is now (0).

 

[jrohrbach]

Along with the aforementioned "gotcha," the problem with a relative GDG reference such as (0) or (-24) is that the file being referenced will change if anyone creates a new version of the file. If it is critical that you get the 25th version, then the best way is as "NS10.RAD.CFILE.G0025V00" (assuming, as has also already been noted, that it is still in the catalog).

A quick way to find out whether the generation you want is still available is

tso listc ent('NS10.RAD.CFILE') all

In addition to showing you all of the generations still cataloged for that GDG index, you will be able to see how many generations are being kept:

ATTRIBUTES                                             
  LIMIT------------------6     SCRATCH          NOEMPTY

Hope that helps!

Ever onward,
jar

 

[winzip]

with reference to 'gotcha' about a jobstep that fails where a (+1) generation is referenced, it is not always true that when you restart, the (+1) has already turned into a (0) generation... note that certain catalog maintenance services such as CA11 can 'roll back' GDGs so that you don't have to worry about what generation you are pulling in whenever you restart a failed step...

just my two cents' worth...