AXMER0001 80A-00 or DFHXQ0501 when max AXMPGANY storage too low to allocate buffer in TS queue server

Abend 80A-00 is the server's way of simulating a real abend 80A (for which reason code 00 is not valid). It is issued when code running in the server tries to allocate one or more pages of storage from the main storage area (acquired at AXM start-up) but there is insufficient storage available for the request and the caller has not specified an UNAVAIL= exit on the AXMPAGE macro.

When queue pool data buffers are being allocated (in DFHXQBF), an UNAVAIL= exit is used, so if storage runs out during that process it will not abend at the time but will issue DFHXQ0501 and stop allocating buffers at that point (and there is then a risk of getting abend 80A later when there is insufficient storage for new request stacks).

So in general, if you run out of storage while allocating data buffers, you will get message DFHXQ0501, but if you run out either before or after that point you will get abend 80A-00.

In this case, the problem looks likely to be down to the huge number of buffers being specified for the server. In our experience this is much more than would normally be specified. For buffer numbers for the server, the minimum number required to avoid buffer waits is 10 per CICS region which can connect. Additional buffers avoid the need to reread recently accessed queues if the data has not been changed on another system. From the shared data server developer's perspective, they had not expected to see much benefit from allocating more than 1000 buffers even in a very busy system, and certainly not more than 10000.

Certainly, the numbers being specified here (30000+) seem excessive. Reducing this should improve storage usage for the server address space.