# MQRC 2019: Object handle error Source: https://wndsoftware.com/mainframe-errors/mqrc-2019 ### MQRC 2019: Object handle error MQRC 2019 (MQRC_HOBJ_ERROR, hex 07E3) means the object handle (Hobj) passed to an MQI call such as MQGET, MQPUT or MQCLOSE isn't valid. It was never returned by MQOPEN, it was already closed, or it is being used on a thread or in a way it doesn't allow. #### Other names for this code Also written as `RC2019`, `reason code 2019`, `MQ 2019`, `MQ error 2019`, `MQRC_HOBJ_ERROR`, `07E3`, `0x07E3`, `Hobj error`, `invalid object handle MQ`, `MQJE001 Reason 2019`. ### What it means MQOPEN returns an object handle for the queue, topic or other object it opened. Later calls such as MQGET, MQPUT, MQINQ, MQSET and MQCLOSE pass that handle back. If the queue manager doesn't recognise the handle, the call fails with MQCC_FAILED and reason 2019. Like 2018, this is a program error. The handle may never have been set because MQOPEN failed, it may have been closed already, or it may belong to a thread that doesn't own it. Another thread may also have closed a shared handle. The same code comes back when MQGET or MQPUT is given the handle of an object that isn't a queue, for example a handle opened on the queue manager object only to inquire on its attributes. In Java and .NET the MQ classes manage handles for you, so 2019 there usually means the program used a queue object after closing it or after its connection ended. ### Common causes - MQOPEN failed and the program didn't check the reason code, then used the empty handle on MQGET or MQPUT. - The program closed the queue and later used the same handle, for example a close in an error path followed by a retry that skips the reopen. - A multithreaded program uses a handle on a thread other than the one that opened it, and the connection isn't shared. - Another thread closed a shared handle while this thread still used it. - The program passes the handle of a non-queue object, such as the queue manager or a namelist, to MQGET or MQPUT. - The handle variable was overwritten by a buffer overrun or a parameter list that doesn't match the call. ### How to find the problem - Find which call returned 2019 and trace the handle back to its MQOPEN. Check that MQOPEN returned MQCC_OK and that nothing changed the variable since. - Search the code for MQCLOSE calls on that handle, including in error handlers and cleanup routines that may run earlier than you expect. - On distributed MQ, an MQ trace (`strmqtrc`) or application activity trace records each call with its Hobj and shows where the handle was closed. - In a threaded program, log the thread ID with each open, use and close of the handle. - If the program reconnects after a broken connection (2009), check that it also reopens every queue. Handles from the old connection are no longer valid. ### How to fix it - Always check the result of MQOPEN before using the handle, and set the handle back to MQHO_UNUSABLE_HOBJ after MQCLOSE so a later use fails clearly. - Reopen every object after a reconnect. Old handles don't carry over to a new connection. - Keep handles on the thread that owns the connection, or use a shareable connection and coordinate closes. - Open the queue itself for MQGET and MQPUT. Use the queue manager object handle only for MQINQ. - Retrying with the same handle won't help. Fix the code path that loses or reuses it. ### IBM documentation [IBM documentation: MQRC 2019](https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=codes-2019-07e3-rc2019-mqrc-hobj-error). Use the documentation for your installed release. [Report a correction to WND Software](https://wndsoftware.com/contact#message). Technical reviewer: [Albert Joseph](https://wndsoftware.com/authors/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. ### Related codes [MQRC 2018 MQRC_HCONN_ERROR Read →](https://wndsoftware.com/mainframe-errors/mqrc-2018) [MQRC 2009 MQRC_CONNECTION_BROKEN Read →](https://wndsoftware.com/mainframe-errors/mqrc-2009) [MQRC 2085 MQRC_UNKNOWN_OBJECT_NAME Read →](https://wndsoftware.com/mainframe-errors/mqrc-2085) [MQRC 2042 MQRC_OBJECT_IN_USE Read →](https://wndsoftware.com/mainframe-errors/mqrc-2042) [MQRC 2195 MQRC_UNEXPECTED_ERROR Read →](https://wndsoftware.com/mainframe-errors/mqrc-2195) ### Questions #### What is the difference between MQRC 2018 and 2019? 2018 means the connection handle from MQCONN is bad. 2019 means the object handle from MQOPEN is bad. Both point to the program, not the queue manager. #### Can a queue being deleted cause 2019? Not usually. MQ won't delete a queue that a program has open, so 2019 nearly always comes from the program's own handle use. If the definition of an open object changes in a way that affects the handle, later calls can get 2041 (MQRC_OBJECT_CHANGED) instead. #### Why do I get 2019 after a reconnect? Object handles belong to a connection. When the connection broke and the program made a new one, every handle it held before became invalid, so it must open its queues again. [IBM MQ reason codes](https://wndsoftware.com/mainframe-errors/mq-reason-codes) · [MQRC 2018](https://wndsoftware.com/mainframe-errors/mqrc-2018) · [MQRC 2024](https://wndsoftware.com/mainframe-errors/mqrc-2024) [← All error codes](https://wndsoftware.com/mainframe-errors/)