I am not an expert with MQ and have a situation I wanted to see if anyone could help with. I have a system that messages via MQ across IBM mainframes (LPARs) in a request/response mode. In some cases an issue one the receiveing side may cause a response to not be sent to the other. The side waiting on the response gets a 2033 error code (no message) and exits the program. When we start to get other response messages on that same side, we see 2019 messages start to appear. My question is this, when we get the 2033 in the first instance, should we make a call to close the queue? Currently the program just exits when the 2033 is hit. I was wondering if issusing the close would clear up the 2019's.
This topic has been locked.
4 replies Latest Post - 2013-03-04T02:55:16Z by SystemAdmin
Pinned topic MQ Question
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-03-04T02:55:16Z at 2013-03-04T02:55:16Z by SystemAdmin
Re: MQ Question2013-02-21T17:49:34Z in response to SystemAdminI'm guessing from what you've said, that the response queue is a dynamic queue, in fact a temporary dynamic queue, and so when the program gives up waiting for the response, and exits, that temporary queue is cleaned up and so is no longer there? Then when the responses later arrive, the handle that the other application had on the queue is now not valid because the queue is not there and so it reports MQRC_HOBJ_ERROR (2019). I am just guessing here a little bit though.
To answer you specific question, "Would issuing MQCLOSE before exiting help?". I think in this case no, because the application is exiting, and so an implicit MQDISC is being issued on your behalf. As part of an MQDISC (implicit or explicit) MQCLOSEs are issued for all your open handles. So I would say it would have the same effect.
Would it be possible for you to provide a little more detail, for example about the reply queue, and also about the application that is seeing the 2019? That way we can provide an answer that has less guess-work in it.
Re: MQ Question2013-02-21T22:15:44Z in response to SystemAdminIn general, don't rely on any MQ clean up at program termination, its not a recommened programming practice.
Regardless of any reason code returned by MQI calls like MQGET, MQPUT, always issue a MQCLOSE for every MQOPEN when access to the queue is no longer needed. The MQCLOSE will set the object handle to an unusable value.
This ensures that any subsequent MQGET, MQPUT etc. using the handle variable will fail with 2019 and it indicates a programming error or design error.
The same applies for MQCONN. Always issue an MQDISC when the connection is no longer needed.
Re: MQ Question2013-02-22T10:53:39Z in response to SystemAdmin> GBaddeley wrote:
> The MQCLOSE will set the object handle to an unusable value.
Actually, on this specific point, don't rely on this and always set your hObj to MQHO_UNUSABLE_HOBJ after you have done an MQCLOSE. Not every platform does this.
I agree it is nice to issue an MQDISC before ending, as you then don't have to rely on the implicit one. I'd add, always issue an MQCMIT or MQBACK prior to the MQDISC, so you have no reliance on the implicit UoW processing in MQDISC. Even if you think you don't have any outstanding work, an MQBACK will ensure this is the case before you end. The MQCLOSE is less important though as there is less implicit decision making going on on your behalf. Unless you wanted to remove durable subs, or purge delete dynamic queues perhaps, then there is less of an argument for this one. Personally, I always do the MQCLOSE, as I like symmetry!
Re: MQ Question2013-03-04T02:55:16Z in response to SystemAdmin>always set your hObj to MQHO_UNUSABLE_HOBJ after you have done an MQCLOSE.
I do this in my programs after calling MQCLOSE, just to make sure :-)
>...so you have no reliance on the implicit UoW processing in MQDISC
Yes, such as on z/OS where SYNCPOINT is enabled on MQI calls by default.
For portable code, all relevant MQI calls should be explicitly coded with SYNCPOINT or NO_SYNCPOINT.