Hi

Thank you.
We got to this as test some C 64 bit applications.
Seems to me if you set some MEMLIMIT for 64 bit storage, you could run into this situation relative easaly
or you should setup a very large aux storage.

Tom Harper wrote:

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

Reply via email to