MQ

 View Only

 MQXF_CMIT against a thread or hobj??

Jump to  Best Answer
John Hawkins's profile image
John Hawkins IBM Champion posted Tue July 15, 2025 11:01 AM

Hi Folks,

I'm looking deeply into activity trace at the moment. 

I see my applications make connections (CONNX) on a thread. They then OPEN an object - for which they get a HOBJ back on that thread. They can inq,get,put, close and I see both the thread and hobj in the activity trace for all those activities. But, when it comes to the CMIT I don't have a hobj - I just see the threadID.

I'm writing an application to track activity - so, should I assume that all hobj activity that are using that thread are being committed or is the CMIT trace activity hiding something from me? 

I'm essentially asking what the relationship is between a thread and a hobj ? chatgpt tells me that a hobj is owned by a thread so therefore a commit should commit everything for the thread?

Can anyone confirm/clarify for me pls ?

many thanks !

John.

thanks !

MARK PHILLIPS's profile image
MARK PHILLIPS posted Tue July 15, 2025 01:37 PM  Best Answer

Hi John 

The MQCMIT is scoped to the connection not an Hobj or the thread.  The ConnectionId is reported in the MQMD.CorrelId field of the activity trace message.

Connections that are created using MQCONNX - like yours - can use MQCNO_HANDLE_SHARE_* options to specify that the connection can be used across threads.  See: https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=call-shared-thread-independent-connections-mqconnx .  If your application did that then you could see activity linked to the connection across different threads.  

Similarly, object handles and units of work are scoped to their connection not the thread (see note 1 in the link above), so that sounds like a dodgy answer from chatgpt. 

The MQCMIT will try to commit all the uncommitted changes that were made under the connection’s current unit of work – so it will affect any Hobj on that connection that has uncommitted changes (see notes 5 & 6 here: https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=calls-mqcmit-commit-changes )

Cheers

Mark

Morag Hughson's profile image
Morag Hughson IBM Champion posted Tue July 15, 2025 10:51 PM

Hi John,

Mark's already answered - but I am replying in case it is useful to you to have a read of Using Application Activity Trace (from an earlier MQTC conference). Page 19 covers the connection ID that Mark has described. Since an hConn is not tied to a thread, the thread ID isn't that useful. An hObj is tied to an hConn - ChatGPT is wrong.

Re: MQBACK call you mentioned - can't see that here, but I'm sure I saw you say it somewhere, if this is a SVRCONN connection application, I think it is standard practice for channels (and best practice for all applications) to issue an MQBACK just before an MQDISC, to ensure no implicit commit/rollback behaviour is needed in the MQDISC. It's essentially a no-op if there is nothing to do, and a good clean up if there was something to do. So seeing an MQCMIT followed by an MQBACK is not a concern.

Cheers,
Morag

John Hawkins's profile image
John Hawkins IBM Champion posted Wed July 16, 2025 05:35 AM

Mark - good to  hear from you after all these years !! And an excellent answer - thanks. That was the missing link. I'm using the MQ kafka connector so I wasn't really looking at the underlying MQ messages - just the data section.

Thanks Mark !

Related Content