MQRC 2071: Storage unavailable

What it means

MQ calls need working storage in the application's process or address space, and sometimes in the queue manager. When that storage can't be obtained, the call fails with MQCC_FAILED and reason 2071. Nothing about the queue or the message is wrong. The process ran out of room.

IBM's advice starts with the application. A program that loops, opens handles without closing them, or keeps allocating large message buffers uses up storage until an MQ call is the one that fails. Only when the applications look healthy should you add storage. On z/OS, IBM's advice at that point is to have the system programmer enlarge the region the queue manager runs in. IBM also notes that on z/OS the code can mean the application's own address space ran out of storage, and then the job's REGION is the place to look.

The call that fails is often not the cause. A leak elsewhere in the same process can leave MQ with too little memory for a routine MQGET or MQOPEN. That is why the useful evidence is the storage use of the whole process over time, not the single failing call.

Common causes

• The application loops and keeps allocating storage, for example by opening queues or connecting repeatedly without closing or disconnecting.
• The program allocates very large buffers for MQGET, such as a 100 MB buffer for every get, and several threads do it at once.
• On z/OS, the batch job or region has a REGION size too small for its MQ work, or an installation exit limits it below what was requested.
• On distributed MQ, the process hits an operating system limit, such as a ulimit on memory, or a 32-bit process runs out of address space.
• The system as a whole is short of memory, so every process is affected, not only MQ applications.

How to find the problem

1. Check whether the failing program loops or leaks. Watch its memory use over time with the operating system's tools, and count its open handles with DISPLAY CONN(*) TYPE(HANDLE) filtered on its application tag.
2. On z/OS, check the REGION on the JOB or EXEC statement and the storage usage reported in the job log at step end. Compare with what the step needed.
3. On distributed MQ, check the user's resource limits (for example ulimit -a on Linux and UNIX) and whether the program is 32-bit.
4. Look at the queue manager error log and any FDC files at the time of the failure. They show whether the queue manager itself was short of storage.

How to fix it

• Fix loops and leaks first. Close object handles and disconnect connections that are no longer needed, and reuse buffers instead of allocating new ones on every call.
• Size MQGET buffers to the messages you expect, and handle 2080 to grow the buffer only when a larger message arrives.
• On z/OS, raise the REGION of the job if its own address space ran out of storage. If the applications are healthy, IBM's advice is for the system programmer to raise the region size of the queue manager.
• On distributed MQ, raise the process limits or move to a 64-bit build of the application.

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.