What would be the alternative? If GRS has a memory leak you might want
some kind of alert but would you want to fail a request by having
imposed a limit? If GRS has a memory leak but it's still working I want
it to keep working till I IPL. If I start failing requests for GRS to
obtain storage then I lose the choice of when to IPL it will most likely
be NOW.
Just a consideration that some tasks that make up the z/OS core services
really probably should be exempt from exits intended to impose limits on
user programs. I agree it probably should be submitted as an RCF
against both GRS Planning and MVS Exits publications.
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
"Think big, act bold, start simple, grow fast..."
-----Original Message-----
I guess GRS should be documented as bypassing IEFUSI too. Its MEMLIMIT
is 64PB. Hope there are no future bugs with GRS 64-bit storage usage
either.
If IBM was worried about customers not changing the MEMLIMIT=0 default,
why didn't they just code REGION=0M.
I'm not really paranoid like Barbara is, I guess I just don't like the
fact that IBM isn't "playing by the rules" as Wayne said. If limiting
storage for OS system address spaces and subsystems via IEFUSI for
24-bit and 31-bit was allowed before, why the need to ignore it now for
some address spaces / subsystems? Were so many installations shooting
themselves in the feet that IBM decided this was for our own good?
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead Zurich North America
and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/ Mark's
MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
<>
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
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
