Has anyone else seen a 200% increase in space utilization of the resultant PDS/e compared to that of the pds that was converted using BSTXCOPY? I noticed it with smaller libraries too, but the 69 extents on this one (28,300 members) made me take notice and copy the new pdse to a single extent.
Enter "/" to select action Tracks %Used XT
GIO.END.GPROD.BCHLOAD 43500 56 1 current PDS Used cylinders : 1,633
GIO.END.GPROD.BCHLOAD.PDSENEW 53700 99 69 PDS>PDSE BSTXCOPY 35 minutes Allocated cylinders : 3,580
GIO.END.GPROD.BCHLOAD.PDSENEW1 54000 49 1 PDSE>PDSE BSTXCOPY 15 minutes ~1800 cylinders
GIO.END.GPROD.BCHLOAD.PDSENEW2 54000 49 1 PDSE>PDSE PDSFAST less than 30 secs ~1800 cyls (all *loadmods intact)
Is the dataset in use and a type 1 PDS/e?
I ask because type 1 PDS/e don't free space if enqueued.
Thanks for pointing this out, Stuart! I just looked up PDSE Version 2 and, imho, this is kind of critical information if you want to use PDSE and Endevor!
IBM Knowledge Center
This raises a clear and obvious related question.... What is the performance impact of PDS/e version 1 versus version 2? Reading the IBM material would lead one to believe yes, the effort is worth it.
Stuart, you seem to have been aware of this and (I'm guessing) have made the effort to convert. Is it worthwhile? Are there performance and utilization benefits to be realized?
There is no conversion path from type 1 to type 2 datasets! IBM see them as different access methods.
BSTXCOPY all the way.
I needed type 2 for DFHRPL allocated datasets as we run an active/active setup, so under type 1 they never released space.
That was enough of a business driver.
Also, Compuware now store the debug listing with the load module, so I am guessing our load datasets are going to get mighty big.
I haven't done any performance analysis.
Now I'm curious.... can you think of any reason not to just allocate type 2 across the board?
None at all John.That is my plan from here on.
That's what I was thinking as well. And fortunately I'm in the "enviable" position of re-engineering a complete installation and don't have a myriad of datasets to worry about (yet)....
Ask the operating systems staff to set the PDSE_VERSION keyword in IGDSMSxx to specify a default version number 2.
I pre-allocate with br14 and dsntype=library. This happened on the initial conversion. I noticed it with smaller libraries too, like I pre-allocated 5 cyls for a 2 cyl pds and ended up 97% full,
Just out of curiosity, what is the space utilization if you copied the library using IEBCOPY?
Yes- we will lose the Footprints but just curious if the IBM utility results in the same tremendous increase in space when going from PDS to PDS/e
Never mind - Craig and the TEC article answered that
The test I ran with PDSFAST 1) took 2 hours, compared to BSTXCOPY’s 35 minutes, but space wise came in at the same 1800 cyls as the PDSE to PDSE copy.
Question for Stuart: How do I tell and/or allocate type 1 vs type 2 ?
In the 3.2 option there is a field called version, put a 2 in there.
The info command will show 1 or 2 when you query the dataset.
In batch you need to code DSNTYPE(LIBRARY,2) along with the other DCB parms.
I hope that helps
Thanks Stuart, they’re 1 ☹. Glad I’ve only done the first 100 so far.
Technical Support Sr. Specialist
Software Code Management Team
860-902-3064 (IP phone)
Upcoming PTO: Week of July 4th;Monday, July 24th
When just copying PDSE to PDSE, you should not see the size increase. That will only happened during conversion from PDS to PDSE. You don't need to use BSTXCOPY going from PDSE to PDSE. IEBCOPY is fine.
Thanks Craig, that part I knew already too. PDSFAST also does in about 1/10 the time.
Thanks for all the good info.
Please see the document TEC1395137. This is a known issue with PDSE loadlibs. The solution is to use IEBCOPY to copy to new PDSE loadlib after conversion, and you will have the space back.
Question: Is TEC1395137 applicable to both Version 1 and Version 2 of PDS/E? I get the impression "yes" for Version 1 but "no" for Version 2. The document just talks about "PDS/E", which is really too generic a term now.....