Lizzette, I think what may help you out here a little in terms of seeing what is 'inside' SHRLIBRGN is this nice little REXX:
ftp://public.dhe.ibm.com/s390/zos/tools/wjsigshl/wjsigshl.txt Its accessible via the USS tools & toys site (although wasnt at the time we were given it, a few years back), although it may not be terribly obvious unless you are specifically looking for it. We went through the loop you are going through right now, a few years back, as we didnt fully understand the need nor the ramifications of increasing SHRLIBRGNSIZE. After gaining some better understanding, we decided to leave it at the 64Mb default, as changing it would have had a detrimental impact on the amount of extended private available to OMVS address spaces, such as 31bit webspheres, so that was a complete no-no for us. We decided to just take the hit of the 'overspill' of SHRLIB-eligible objects getting loaded into an address space's private once SHRLIB was full. I setup some housekeeping using the above rexx to monitor the 'residency' of what was in SHRLIBRGN over time, and it is quite interesting to see how things change over an extended period of time. I did have plans to 'manage' the attributes of certain objects such that they would not be eligible for loading into SHRLIBRGN if just one task was using them (for example), as there was clearly better justification for objects that a large number of webspheres or CTGs all sharing the same things, rather than just one outlier address space selfishly taking up valuable SHRLIBRGN slots. But they were only plans, and they didnt actually go anywhere..!! Would be nice if IBM could allow this to be managed a little better than the first-come-first-served principle, although I cant think right now how it could easily be done any different, I must admit! Moving SHRLIBRGN above the bar would make this a non-issue of course.......that would definitely get my vote! And I think someone mentioned that things dont always "tie up", and if I remember correctly, I think this could be because of the "lazy flush" which happens after the last user of an object closes down, such that an object with '0 users' will get purged out of SHRLIBRGN a period of time afterwards (cant remember the precise controls/timings around that though). HTH. Graham On 31 October 2011 23:26, Shane <[email protected]> wrote: > On Mon, 31 Oct 2011 12:23:00 -0500 "Shmuel Metz (Seymour J.)" wrote: > > ... > > BTW, am I the only one to think of Contract Bridge when I see a > > reference to the line? > > Can't say I've ever confused the two in all these years. > Of course, now that you've mentioned it ... > > Shane ... > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
