MQRC 2038: Handle not open for inquiry

What it means

MQINQ reads object attributes through an existing handle. That handle must have been opened with MQOO_INQUIRE. An application can successfully put or get messages and still receive 2038 when it later asks for attributes.

IBM additionally documents MQINQ restrictions for Multicast topic handles. Avoid assuming that all handles expose the same administrative information.

A troubleshooting example

A sender puts an invoice successfully, then queries queue depth for a status display. The inquiry returns 2038 and the wrapper reports the whole send as failed. A caller retries and can duplicate the invoice. Correct both problems: provide the required inquiry capability where appropriate, and report the put outcome independently from a diagnostic attribute read. A test should deliberately fail the inquiry after a successful put and verify that the sender does not resubmit the business message.

Common causes

• A producer queries queue attributes using its output-only handle.
• A generic library adds an attribute check without updating object-open requirements.
• The application attempts MQINQ through an unsupported Multicast topic handle.

How to find the problem

1. Record the attribute query, object type and Hobj from the failing MQINQ. Then locate the corresponding open.
2. Compare actual open options with the library's documented prerequisites. Check whether one caller configures inquiry and another does not.
3. Determine why the application needs the attribute. Some diagnostic paths can be separated from the critical message flow.
4. For topic or Multicast use, confirm support in the installed release before adding an open option that cannot make the call valid.

How to fix it

• Include MQOO_INQUIRE when opening an object that supports the required inquiry. Reopen safely if the existing handle must change.
• Document inquiry capability in the wrapper's contract. Avoid hidden attribute reads that unexpectedly change the permissions or modes required by a producer.
• Test startup and steady-state behavior with inquiry enabled. Confirm an inquiry failure does not trigger an unsafe retry of a message operation that already succeeded.

What it looks like

Illustrative diagnostic notes; not an IBM message template.
MQPUT: succeeds
MQINQ through output-only handle: Reason=2038
Do not report the successful put as a failed send.

Technical reviewer: Albert Joseph, WND Software.

Updated 2026-10-23. IBM documentation checked for this article. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.