×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.