MQRC 2042: Object in use

What it means

A queue can be opened for input in shared mode or exclusive mode. Shared input lets many readers take messages at once. Exclusive input gives one handle sole access. MQOPEN fails with 2042 in two cases. It asks for shared input while another handle has exclusive input, or it asks for exclusive input while any other handle has the queue open for input.

Whether an open is shared or exclusive depends on three things. The application can ask for MQOO_INPUT_SHARED or MQOO_INPUT_EXCLUSIVE directly. If it uses MQOO_INPUT_AS_Q_DEF, the queue's DEFSOPT attribute decides. And if the queue is defined with NOSHARE, every input open is exclusive whatever the program asked for. IBM notes that NOSHARE is the default on z/OS.

The other handle may belong to the same program, another copy of it, or an MQ process. Receiver channel agents and the z/OS intra-group queuing agent can hold queues open even when no messages are flowing. On z/OS, 2042 can also come back from MQOPEN or MQPUT1 when the object is being deleted.

Common causes

• A second copy of an application starts while the first is still running, and the application opens the queue for exclusive input to keep message order.
• A program crashed or was killed, but its connection hasn't been cleaned up yet, so its exclusive handle still exists. Client connections can linger until heartbeat or TCP keepalive notices the dead client.
• The queue is defined with NOSHARE, or DEFSOPT(EXCL) with an application that uses MQOO_INPUT_AS_Q_DEF, so a second reader is refused.
• The same program opens the queue twice, the second time for input, and the first open was exclusive.
• On z/OS, the queue, namelist or process is being deleted while the open runs.

How to find the problem

1. Find who has the queue open with DISPLAY QSTATUS(ORDERS.IN) TYPE(HANDLE) ALL. The output shows each handle's application tag, process or job, channel, connection name and whether input is SHARED or EXCL.
2. Check the input count and sharing settings with DISPLAY QLOCAL(ORDERS.IN) IPPROCS SHARE DEFSOPT.
3. Check the open options in the application code or its configuration. Look for MQOO_INPUT_EXCLUSIVE or MQOO_INPUT_AS_Q_DEF.
4. If the holder is a client connection from a host where the program is no longer running, the connection is orphaned. DISPLAY CONN(*) WHERE(APPLTAG EQ ...) shows its details on distributed MQ.
5. On z/OS, issue the same DISPLAY QSTATUS command with the command prefix. It shows the job name or CICS transaction holding the handle.

How to fix it

• Stop the extra copy of the application, or let the first one finish. If only one reader is wanted, this is the protection working as designed.
• End an orphaned connection. On distributed MQ use STOP CONN(...). On z/OS, end the owning job or task. Then make heartbeats and keepalive shorter so dead clients are noticed sooner.
• If several readers are wanted, set the queue to SHARE and DEFSOPT(SHARED), or have the application open with MQOO_INPUT_SHARED.
• Decide in the design whether the program should wait and retry on 2042 or end with an alert. IBM leaves this to 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.