Re: Storage exception

[CRPence <CRPbottle@xxxxxxxxx>]

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