This, IMHO, is a design area of z/OS which could stand some improvement. The RSM and ASM areas of z/OS have been extremely busy with the addition of 64-bit storage support, 1Mb pages, much larger real memories, larger page data sets, etc. One item that has been pushed to the back burner has been the management of aux storage, which really hasn't changed for decades...it's been in the province of the SYSPROG staff to allocate aux storage data sets and attempt to manage its use.
However, since the consequences of running out of aux are so severe and frequently lead to system outages, something really needs to be done rather than caste blame. I have to admit that this is one area in which Windows actually does better...if there's a shortage of aux, it issues a message and allocates additional aux page space with no outage (perhaps a momentary slowdown). Currently, page data sets must be preformatted because the tracks are staggered due to SLED DASD concerns. Since SLED DASD is not used anywhere anymore, a new design of aux page data sets could be done without having to preformat the page data sets. Aux could be managed according to a policy similar to that used for dump data sets today. If there is a shortage of aux storage, another page data set could be allocated and the system could go on. This doesn't mean that large virtual storage users don't need to be managed; this would just be another way of avoiding an unscheduled IPL. Tom Harper IMS Utilities Development Team Neon Enterprise Software, LLC Sugar Land, TX -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Hal Merritt Sent: Thursday, January 29, 2009 9:45 AM To: [email protected] Subject: Re: IPL after 4Gbyte alloc NOMEMLIMIT I would respectfully submit that the application did not bring down the system. It was a system configuration issue. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Miklos Szigetvari Sent: Thursday, January 29, 2009 9:19 AM To: [email protected] Subject: Re: IPL after 4Gbyte alloc NOMEMLIMIT Hi I see , my point here, how a normal, nonauthorised application can brings down the system. Mark Zelden wrote: >On Thu, 29 Jan 2009 15:52:35 +0100, Miklos Szigetvari ><[email protected]> wrote: > > > >>In our systems (till now) we set the MEMLIMIT to NOLIMIT, we have 6G >>real , and a small 6 G page >>A test 64 bit unautorised application tried to alloc and set a 4Gbyte >>storage, it led to an IPL wit critical aux storage shortage. >>I was unable to kill the process. >>Now we set the MEMLIMIT to 2G. >>Any way to prevent his ? >> >> >> > >The same way you would have limited 24-bit or 31-bit allocations. >The IEFUSI SMF exit. Search the archives for more information. > >I forgot to mention: You should also beef up your aux storage. If you >have 6G real, you should have enough aux storage to support >*much* more virtual storage usage. See the INIT and tuning guide and >reference for details on how to estimate the size. > > >Mark >-- >Mark Zelden >Sr. Software and Systems Architect - z/OS Team Lead >Zurich North America / Farmers Insurance Group - ZFUS G-ITO >mailto:[email protected] >z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ >Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 > > > > -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: [email protected] Info: [email protected] Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --------------------------------------------------------------- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --------------------------------------------------------------- ---------------------------------------------------------------------- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- 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
