Re: ASP threshold

On 11-Aug-2015 06:47 -0600, Henrik Rützou wrote:

many years ago on an early release I head about a machine they
could't even start in restricted mode - just the size of QSYSOPR that
expanded under IPL killed the machine

If a phase of the IPL has insufficient storage to effect what is necessary to continue, the system will crash. Thus the system will not be able to restart in such a scenario, irrespective of restricted vs non-restricted. However after analyzing the crash, there are likely steps to bypass that problem so as to allow getting to a later IPL-step; the resolution might require an iterative approach, but would likely be able to be bypassed. The problem is knowing how many iterations and how much time [and special, likely paid, support to review each crash and possible ameliorative (re)actions], or even if a bypass is truly possible, for which the option to scratch-install to recover the system [should already have been made or] hence is deemed the more appropriate resolution.

There is no magic to avoid such a scenario. The likely situation is however, that there will have been enough temporary storage [not to be confused with storage in QTEMP] that gets recovered, such that the OS will be able to get most work done to complete the IPL. There are some likely big-storage tickets that are problematic, irrespective of starting into restricted-state, such as journal/commit/database-related recovery work; some of those pending operation(s) could require more storage than even the reclaimed temporary storage made available. I used to have a patch to no-op the call to the database-IPL code [for a specific PTF level; probably I made that patch available with an /eye-catcher/ so as to avoid having to know the PTF level] specifically to allow bypassing such problems during the database-recovery phases; and for problems after the first reference to the *DBXREF dataspaces [and queues], damaging those would effect their deletion and thus a potentially large recovery of permanent storage.

In the described scenario, hard-damaging the QSYSOPR message queue would surely see the implicit re-create of the object during the next IPL rather than an extent to the existing object, and the new\empty size might [though improbable] allow achieving transition to the next IPL phase\subfunction.