Re: Storage exception

On 1/27/11 9:16 AM, Åke Olsson wrote:

We had a problem with one server where the used storage went through
the roof (> 99%).

The strange thing is that even after we reduced utilization down to
a high, but workable level of 87% new jobs that started could not
perform any action requiring space allocation, such as opening a
printer file.

The job log has messages:

"Machine storage limit overflow. Cannot allocate auxiliary storage
that is larger than the storage capacity of the machine."

The only resolution was apparently an IPL.

Is this common? I.e. have others experienced this? And is there any
other way than an IPL in the middle of the work day?

In my experience, for all tests and actual incidents in the lab [again, me, not what others may have experienced] for which that error occurred, if the system did not crash due to a critical-system-task having encountered the problem versus the error only being encountered by applications, test-cases, and non-critical code paths, the system recovered normally, simply by returning the required storage; i.e. either temporary or permanent. I recall at least once however, that many thousands of interrupted database operations prevented the IPL because the database recovery phase in the IPL encountered MCH2804 for the list of objects being too large; exacerbated by many testcases failing while the system was previously active, all failing with the system-full condition and thus each having left a pending database request.

IIRC the system Storage Management issues the MCH2803 when either all addresses or all storage [necessary to perform the operation] is unavailable; although the message only alludes to the latter. The noted condition could occur for either permanent or temporary storage. Opening a[ny type of] *FILE via common data management requires creating a temporary object [and associated space] and the addresses for each. Possibly the system had permanent storage and addresses available, but was lacking in either temporary storage or addresses.? If temporary storage or address utilization were very high, there is a specific symptom keyword string for searching APARs and associated PTFs; something like TMPSTGLK or TMPSTG, and msgMCH2803 is the specific symptom keyword for the described error although that is unlikely to be recorded in all temporary storage leak APARs.

Regards, Chuck