IMS and PDSE

Willem Vermeer · Posted: Mon Mar 14, 2011 6:39 pm

Greetings.

It's documented that IMS does not accept PDSE for any library except PGMLIB.

One of the reasons mentioned is:

"The main reason is that IMS branch enters FETCH for loading its code and control blocks. IMS "GETMAINs" storage from specific subpools, and loads these control blocks into that storage."

Why should a Branch-entry into FETCH + a Getmain in specific subpools prevent the use of PDSE?

Another reason seems to be:

"The second reason is that IMS maintains BLDL information in storage for a period of time and cannot tolerate reorganization of the partitioned dataset(s) while holding this information internally. Both of these techniques enhance the performance of IMS. "

I realise that PDSE does not provide you with BLDL-info (TTR) similar to that in a PDSE and that IMS maintains this info for performance reasons. However, if [1] the PDSE is NOT reorganized and [2] IMS would maintain an active connection to every module in such a PDSE, would that really hurt performance that much? And, after all, you could still reach that module, even if somebody else would delete it.

Willem Vermeer
ING, Amsterdam

dbzTHEdinosauer · Posted: Mon Mar 14, 2011 7:04 pm

1. neither pdse or pds undergo 'reorginization'.

2. pds undergoes compression, upon demand.

3. pdse automatically performs 'internal' compression.

here is a list of manuals you can read IBM Redbooks about PDSE

Willem Vermeer · Posted: Mon Mar 14, 2011 7:53 pm

Dick,

1. What I mean with "reorganization" is: "compression".
2. True.
3. I'm not sure that's quite true. PDSE does not - to my knowledge - move data around to get rid of any "gas"/"dead space" (whatever). It does, however, reuse space that's become available when one deletes a member.

Anyway, I still don't understand IBM's reasons for not having IMS fully support PDSE. I'm not aware of any such restriction for DB2 and, surely, a good performance is important for any DB2-system also? These IMS performance-techniques sound a lot like something from the olden days.

Willem Vermeer.

Peter Nancollis · New User Joined: 15 Mar 2011 Posts: 47 Location: UK

Willem
A lot is "from the olden days"
Times are changing :
DFSESL datasets can be PDSE (eg SDSNLOAD )
z/OS now supports direct fetch (which was waht IMS exploited)
- so maybe more PDSE supprt in IMS will emerge for things like MODBLKs
MATRIXn are or (should be) a thing of the past

ACBLIBx and the various flavours of the FORMAT libs dont play by the usual rules so are more problematic

But one has to ask the question with the possible exceptions of PROCLIB (and JCLPDS in DBRC task) what do you get by having libs as PDSE ?

From my experience they offer alot more pain, than gain (yuk!)

dick scherrer · Posted: Tue Mar 15, 2011 2:44 am

Hello and welcome to the forum,

Willem Vermeer · Posted: Tue Mar 15, 2011 12:55 pm

Dick,

you're right! A much better handling of space was/is our main reason to convert many of our (production)libraries to PDSE. We also have some libraries that are positively HUGE and offer a much better performance (as PDSE).

Peter,

You're not the only one I've heard complaining about PDSE and, frankly, I still don't quite understand why. I'm sure you must have very good reasons to be sceptical about PDSE, but we've never had any major problems with it. True, there were some issues during the conversion from PDS to PDSE, but we've been using them for some time now, and on a fairly large scale too, without any problems.

Willem Vermeer

Peter Nancollis · New User Joined: 15 Mar 2011 Posts: 47 Location: UK

Hello there
I dont disagree (double negative??) that PSDEs offer potential benefits [space management, though I did read of tales of excessive allocations for dsets with small members - control decks , some JCL etc. ], or that they are becoming a more viable option with the removal of some of the early restrictions [SMS required!] and are now being retrofitted to be more seamless ...shame the effort wasnt expended at their conception

Anyway I was responding to their use in an IMS environment - and even there support if creeping in. With my caveats [or as Willem said for PGM libs ] they either cant be used [ACB FMT MOD] or if they could provide little benefit - not having to compress isnt an issue

My view is if you need them use them, but [for me] they do have a bad reputation to overcome. Such as shared library updates providing IPL opportunities

Performance - we currently have issues with a product - that looks like it may be PDSE related ...[PDS - OK ... PDSE - Slooooooww ] but the jury is still out and it all may just be a spooky coincidence