IMS OSAM HIDAM DB exceeds 8GB before abending with U0844

Technical condition:
During OSAM space search during update activity (ISRT or REPL), occasionally an invalid input will cause the request to exceed the blocksize.
The source of the invalid input might be an overlaid block, an incorrect calculation by application code, or a variety of other errors.
When this happens, the OSAM space create process will cause allocation, preformatting, and search of new blocks, as it would normally.
However, the invalid size of the request, will fail to find adequate space, and the process will continue.
This occurs despite the fact that the next allocated space has no better chance of success.
Requirement:
A change to OSAM space mgmt code that will recognize the fact that new allocations of blocks will not resolve the invalid space request.
It should recognize this early in the process, and abend. This will provide documentation that will aid in diagnosing the original cause,
which is often lost due to the long repetitive allocation process that occurs currently.





This continues until all DEB storage is exhausted for that dataset (limit is about 60), and an AbendU0844 is produced.
In addition, the allocation continues beyond the 8G limit for OSAM, because SMS does not recognize this IMS limitation.

No space is used or useable for the current request, so no IMS records are stored in this space, and thus no data integrity issues occur.
However, customer based space mgmt and monitoring efforts will be confused by this unexpected condition.
In addition, the U0844 is too late to capture what the root cause might have been, and this frequently goes unresolved.