I am attempting to use DSINFO in a REXX exec to get secondary allocation (as coded during the define) for all of our ICF user catalogs. My understanding was variable zds2ex from DSINFO would provide this information. After writing my exec that identified all of our ICF user catalogs and then running DSINFO for each ucat I found that zds2ex returned 0 for some user catalogs while zds2ex returned the expected non-zero value other user catalogs. This is all part of a catalog "health checker" that I am creating which compares available free space on a volume which a catalog, or catalogs, reside versus the defined secondary space that would be needed if one or more catalogs on those volumes required a secondary extent within a brief period of time. IDCAMS LISTCAT appears to be out of the question because some of our user cats are large which means execution times for some LISTCATs would be long.
I opened a Service Request with IBM regarding DSINFO and variable zds2ex and here is their response:
"A LISTCAT shows the allocation parameters used when the data
set is allocated, not the actual space allocated on the volumes.
The actual space used and whether secondary extents are actually
allocated and used is contained in the DSCBs on the volume.
The ISPF DSINFO service uses SVC 27 (OBTAIN) to obtain the
DSCBs and report the actual space allocated on the volumes."
What the IBM response doesn't explain is, why zds2ex for some user catalogs allocated in one extent returns 0 while zds2ex for other user catalogs allocated in one extent returns a valid (and confirmed) non-zero value. When I posed this same follow-up question to IBM, their response was: "DSINFO issues SVC27 to obtain dataset's allocation attributes from DSCBs."
With that being said:
Has anybody attempted to use DSINFO to report in ICF user catalog allocation information and encountered this issue?
Is there any other way to quickly obtain allocation parameters for ICF user catalogs besides using IDCAMS LISTCAT?
Oh, I didn't mention that I get the same "inconsistencies" from ISMF data set listings.
What you are looking at is definitional information. ZDS2EX will tell you how much space the secondary extents will be when they are allocated: '5' in the example. And I think that is the information you want, based on:
Quote:
get secondary allocation (as coded during the define)
However, your reference to 'one extent' implies that you do not want definitional information, but current usage:
Quote:
why zds2ex for some user catalogs allocated in one extent returns 0 while zds2ex for other user catalogs allocated in one extent returns a valid (and confirmed) non-zero value.
The reference to 'one extent' is not relevant if you are looking for how a catalog was defined. And I think it is valid to define a user catalog without secondary extents.
For a health checking function, I suspect you want to know how big the next extent will be (ZDS2EX) and how full the current extents are. I suggest you have a look at ZDSTOTA, ZDSTOTU, ZDSEXTA and ZDSEXTU.
You also will need to know the amount of free space on a volume. Use the LSPACE macro.
This does not make sense to me:
Quote:
IDCAMS LISTCAT appears to be out of the question because some of our user cats are large which means execution times for some LISTCATs would be long.
Please elaborate.
It does not make sense to me because the LISTCAT will get information about the user catalog from the master catalog.
Actually, you probably do not want catalogs to go into secondary extents. Just allocate large enough catalogs to begin with.
You are correct, I want to use ZDS2EX (which we believe to be 'definitional' information) to tell me how much space the secondary extents will be if and when they are allocated.
According to the IBM developer who responded to my IBM Service Request, LISTCAT shows the allocation parameters used when a data set is defined and DSINFO uses SVC 27 to report on the actual space allocated on the volumes. Given this explanation from IBM, it seems that ZDS2EX cannot be relied upon to provide secondary 'definitional' space information. This doesn't make sense to me, especially since it seems the entire REXX community believes that ZDS2EX returns 'definitional' information, so I'm going to continue to hound IBM.
As for my reference to "one extent"..., I was trying to illustrate that I have some user catalogs allocated in one extent and DSINFO returns a value of zero for ZDS2EX and I have other user catalogs allocated in one extent and DSINFO returns ZDS2EX with a value that matches the secondary space that was coded in the DEFINE. It is this situation that caused me to open the Service Request with IBM. Here's an example of two user catalogs that were allocated with the same primary and secondary space values:
Regarding my comment about not wanting to use LISTCAT because it ran to long for my purposes..., I realized this morning that I wasn't using the proper parameters to just get allocation information so this issue of mine has been resolved.
So I am still stuck with the questions, why does ZDS2EX return zero for some ucats and why does ZDS2EX return a non-zero value for other ucats? Also, what is the actual definition of ZDS2EX (you and I believe it is "definitional" but IBM says otherwise) and where does DSINFO obtain that information? Both questions I guess need to be answered definitively by IBM.
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
Quote:
it seems that ZDS2EX cannot be relied upon to provide secondary 'definitional' space information
It is not clear what question you posed... it is hard to determine if the answer was correct or not. I think you are jumping to conclusions in stating that ZDS2EX is not reliable. Nothing in your posts would lead others to believe it is not reliable. I do not believe DSINFO uses output from LISTCAT.
Quote:
since it seems the entire REXX community believes
As far as I can tell, I am the only one that answered! I am flattered that you think I speak on behalf of the entire community. Actually, I do not. You jumped to conclusions.
Quote:
IBM says otherwise
Again, you have not posted your question to IBM here, so it is not clear to me whether their response is incorrect or not.
But I would like to point out that using OBTAIN will return the format 1 DSCB, which contains both the definitional information and actual usage information. I strongly think it is unlikely that it is incorrect.
I do not think you can easily prove that there is a problem with the operating system. All datasets on a volume have entries in the Volume Table of Contents (VTOC), where the format 1 DSCB resides. And VTOCs have been in use since the 1960's. If there were defects in this area, there would be many many user complaints.
A more likely explanation is that on your system, different user catalogs were added over time using different methods. With the result being that some were defined with secondary extents and some were not. What you are seeing after the fact is a mish-mash of various styles, which is typical of systems that have been a long history.
Since catalogs are frequently used, there would be a performance problem if they grow into multiple extents. I recommend allocating the first extent sufficiently large enough.
I received the following response from IBM regarding DSINFO and ZDS2EX:
"IDCAMS LISTC is reading data information from catalog.
Attributes listed in its output are from 'DEFINE' statement when you
create the dataset, not the current usage.
ISPF DSINFO does not read attributes from catalog as IDCAMS LISTC does,
it issues SVC27 to read current DSCB which resides on VTOC. Secondary
allocation information is from VTOC which represents current usage."
What I was trying to get was the primary and secondary space attributes and I was under the assumption that ZDS1EX and ZDS2EX from DSINFO would provide that information. Apparently I assumed wrong so I'll be using
