Oddly, perhaps, member generations was one topic in my last SHARE pitch
as well.
Interactively, you can use the M line command in ISPF OPT3.4 to get a
member list. Selecting a member from the member list with the E line
command *and* using a slash (/) in the prompt column for the member will
let you select a different generation. OPT 3.2 tells you how many
genrations there are.
In addition to the ISPF services you've found, there is more information
here for...
Enablement: z/OS Initialization and Tuning, in the documentation about
member IGDSMSxx
Allocating a data set in JCL: See the MAXGENS and REFDD parameters of
the DD statement in z/OS MVS JCL Reference
Programming services: See z/OS DFSMS Macro Instructions for Data Sets
Preserving member generations on unload and copy operations: See z/OS
DFSMSdss Storage Administration
Recovering a prior member using ISPF: See z/OS ISPF User's Guide Vol I
...it looks as though DESERV comes closest to what you want with GET_G
(retrieves all the generation information for a single member of a PDSE)
and GET__ALL_G (retrieves all the generation information for all the
members of a PDSE). I don't know if they return what you're after, but
the area returned is mapped by DESB DSECT in the IGWDES macro according
to z/OS DFSMS Macro Instructions for Data Sets.
HTH.
Dyck, Lionel B. , TRA wrote:
Working with PDSE V2 generations can be a challenge since IBM does not fully
support them. True they have made them available for us to use but they have
not made it easy. ISPF supports them in a very minimal way and not intuitively.
An excellent presentation was given at SHARE in Seattle in 2015 by Thomas Reed
which provided an example of how to list generations. The approach is
basically to:
1. Use dsinfo to get the number of generations allowed (zdsngen)
2. Lminit and then lmopen the pdse
3. In a loop using the zdsngen as the limit
a. Edit the dataid - member - gen# using a macro
i. The
macro just does a cancel to end
b. Test the return code for < 5 and if so then you've found a generation
The challenge that I've discovered is that zdsngen limit is like a gdg limit -
that is the number of generations allowed but the gen number, like a gdg
number, can grow beyond the limit as it does not wrap.
Has anyone stumbled across a better way to find the member generations?
Using the loop process I've found you have to do an almost infinite limit, or
set it fairly high or you risk missing a generation or 100. And the overhead of
the edit isn't trivial.
<snip>
--
John Eells
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
