Thank you for that proposal.
We are familiar with CSQ1LOGP so this will surely be an option.
I will post any news if this "incident" will occur again.
Original Message:
Sent: Wed November 26, 2025 10:50 AM
From: Tim Zielke
Subject: Uncommitted message in XMITQ
Assuming this message is under a unit of work and is a persistent message, another option is to do a DIS CONN(*) ALL to find the URID (e.g. QMURID) for the connection that has a long running unit of work (e.g. running for several days), and then display the message with the CSQ1LOGP utility.
------------------------------
Tim Zielke
Original Message:
Sent: Wed November 26, 2025 02:14 AM
From: Norbert Pfister
Subject: Uncommitted message in XMITQ
Hi @Tim Zielke ,
thank you for your nice suggestion, i didn't have that on the radar because the last time i did an GTF trace was more than 10 years ago.
Unfortunately the uncommitted message "vanished" this morning around 2:30 a.m , the qmgr logs show no suspicious entries.
But we will not know if that happens again eventually.
------------------------------
Norbert Pfister
system engineer
Nuremberg
Germany
Original Message:
Sent: Tue November 25, 2025 09:33 AM
From: Tim Zielke
Subject: Uncommitted message in XMITQ
If you turn on the User (API) trace and stop/start the channel, I would think you would get the first 256 bytes of the message when it is PUT back on the XMITQ. Just an educated guess, though.
https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=trace-interpreting-information-zos
------------------------------
Tim Zielke
Original Message:
Sent: Tue November 25, 2025 08:14 AM
From: Norbert Pfister
Subject: Uncommitted message in XMITQ
We have a weird situation in one of our z/OS (all V9.4 LTSR) queuemanagers.
It has a traditional sender channel to another z/OS qmgr and inside its XMITQ a message got stuck.
The Queue:
DEFINE QLOCAL('QMG2') +
QSGDISP(QMGR) +
DESCR(' ') +
CLUSTER(' ') +
CLUSNL(' ') +
CLWLRANK(0) +
CLWLPRTY(0) +
CLWLUSEQ(QMGR) +
USAGE(XMITQ) +
CLCHNAME(' ') +
STREAMQ(' ') +
STRMQOS(BESTEF) +
INDXTYPE(NONE) +
STGCLASS('XMIT') +
MAXDEPTH(999999999) +
MAXMSGL(4194304) +
DEFPRTY(0) +
DEFPSIST(NO) +
DEFPRESP(SYNC) +
DEFREADA(NO) +
DEFBIND(OPEN) +
MSGDLVSQ(PRIORITY) +
PUT(ENABLED) +
GET(ENABLED) +
NOHARDENBO +
BOTHRESH(0) +
BOQNAME(' ') +
NOSHARE +
DEFSOPT(EXCL) +
RETINTVL(999999999) +
PROPCTL(COMPAT) +
CAPEXPRY(NOLIMIT) +
CUSTOM(' ') +
TRIGGER +
INITQ('SYSTEM.CHANNEL.INITQ') +
PROCESS(' ') +
TRIGTYPE(FIRST) +
TRIGMPRI(0) +
TRIGDPTH(1) +
TRIGDATA('QMG1.QMG2') +
QDEPTHHI(80) +
QDEPTHLO(40) +
QDPMAXEV(ENABLED) +
QDPHIEV(DISABLED) +
QDPLOEV(DISABLED) +
QSVCINT(999999999) +
QSVCIEV(NONE) +
STATQ(QMGR) +
ACCTQ(QMGR) +
MONQ(QMGR) +
REPLACE
The situation:
dis chstatus(QMG1.QMG2) all
CSQN205I COUNT= 3, RETURN=00000000, REASON=00000000
CSQM420I QMG1 CHSTATUS(QMG1.QMG2) CHLDISP(PRIVATE) XMITQ(QMG2)
CONNAME(1.2.3.4) CURRENT CHLTYPE(SDR) STATUS(RUNNING)
SUBSTATE(MQGET) INDOUBT(NO) LSTSEQNO(40244757)
LSTLUWID(E1CA8D0F11AC6C09) CURMSGS(0) CURSEQNO(40284249)
CURLUWID(E1D774F9BC1CDD8C) LSTMSGTI(14.05.49) LSTMSGDA(2025-11-25)
MSGS(39492) BYTSSENT(83457794) BYTSRCVD(1385580) BATCHES(39469)
CHSTATI(09.25.47) CHSTADA(2025-11-25) BUFSSENT(78963) BUFSRCVD(39471)
LONGRTS(999999999) SHORTRTS(10) MONCHL(LOW) XQTIME(607, 409)
NETTIME(520, 373) EXITTIME(0, 0) XBATCHSZ(1, 1)
COMPTIME(0, 0) COMPRATE(0, 0) STOPREQ(NO) KAINT(360)
QMNAME(QMG1) RQMNAME(QMG2) SECPROT(NONE) SSLCERTI( ) SSLCERTU(STCMQS)
SSLCIPH( ) SSLRKEYS(0) SSLKEYTI( ) SSLKEYDA( ) SSLPEER( )
RPRODUCT(MQMV) RVERSION(09040000) STATCHL(HIGH)
LOCLADDR(1.2.3.5(25265)) BATCHSZ(50) MAXMSGL(4194304)
COMPHDR(NONE ,NONE) COMPMSG(NONE ,NONE) HBINT(300)
NPMSPEED(FAST)
CSQ9022I QMG1 CSQMDRTS ' DIS CHSTATUS' NORMAL COMPLETION
dis qstatus(QMG2) all
CSQN205I COUNT= 3, RETURN=00000000, REASON=00000000
CSQM441I QMG1 QSTATUS(QMG2) TYPE(QUEUE) OPPROCS(1) IPPROCS(1)
CURDEPTH(1) UNCOM(YES) MONQ(MEDIUM) QTIME(685, 653)
MSGAGE(497001) LPUTDATE(2025-11-25) LPUTTIME(13.50.50)
LGETDATE(2025-11-25) LGETTIME(13.50.50) QSGDISP(QMGR)
CSQ9022I QMG1 CSQMDRTS ' DIS QSTATUS' NORMAL COMPLETION
dis qstatus(QMG2) type(handle) all
CSQN205I COUNT= 3, RETURN=00000000, REASON=00000000
CSQM441I QMG1 QSTATUS(QMG2) TYPE(HANDLE) INPUT(EXCL) OUTPUT(YES)
BROWSE(NO) INQUIRE(YES) SET(YES) URID(D4D7F5D7C3C8C9D5) QMURID( )
URTYPE(QMGR) QSGDISP(QMGR) HSTATE(ACTIVE) ASTATE(NONE) USERID(STCMQS)
APPLTAG(QMG1CHIN) ASID(0289) APPLTYPE(CHINIT)
APPLDESC(IBM MQ Channel Initiator) CHANNEL(QMG1.QMG2)
CONNAME(10.222.6.1)
CSQ9022I QMG1 CSQMDRTS ' DIS QSTATUS' NORMAL COMPLETION
Message Age shows nearly 6 days - we didn't notice it because the channel is up and running.
It still transports other messages ...
Until now we didn't find any method to have a look at the message - it doesn't show up.
Of course we tried stopping the sender channel and switch the XMITQ to GET(ENABLED) to browse for it.
Any hints ?
It is a production environment so qmgr restart is no valid option.
Channel Initiator restart is possible.
------------------------------
Norbert Pfister
system engineer
Nuremberg
Germany
------------------------------