ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportUnable to browse message on the queue with UCom:null

Post new topicReply to topic Goto page 1, 2  Next
Unable to browse message on the queue with UCom:null View previous topic :: View next topic
Author Message
harimhkr
PostPosted: Thu Feb 15, 2018 4:52 am Post subject: Unable to browse message on the queue with UCom:null Reply with quote

Novice

Joined: 08 Jan 2013
Posts: 19

on the system cluster transmit queue there are few messages with UCom:null but when i try to browse those message i am unable to do so and message age keeps on increasing.

i tried using amqsbrc and q tool to view those messages but it says no messages.

can you please advice on how we can browse or remove those message from the queue.

Below are the snippets for reference

dis q(SYSTEM.CLUSTER.TRANSMIT.QUEUE)

QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) TYPE(QLOCAL)
CRTIME(13.23.39) CURDEPTH(2)
CUSTOM( ) DEFBIND(OPEN)
DISTL(YES) GET(ENABLED)


q -ISYSTEM.CLUSTER.TRANSMIT.QUEUE -m<QMNAME> -dd3
MQSeries Q Program by Paul Clarke [ V4.5 Build:Sep 15 2006 ]
Connecting ...connected to 'VS1CN4033'.
No more messages
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Feb 15, 2018 5:33 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19744
Location: LI,NY

You need to look at queue status and the UNCOMM attribute.
Then you may look at dspmqtrn -a to see if there are any unresolved transactions / long running transactions.
Worst case scenario, they'll go away when you bounce the qmgr.

Those messages are either due to a long running transaction or may be poison messages on the SCTQ. If you can stop all your cluster sender channels still using the SCTQ and then look at the message on there. If they are not uncommitted you should be able to browse them and determine whether they are destined to a channel that no longer exists or that is in constant retrying or if they are SCTQ messages at all.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
harimhkr
PostPosted: Thu Feb 15, 2018 5:47 am Post subject: Reply with quote

Novice

Joined: 08 Jan 2013
Posts: 19

We tried restarting the QM but the messages are still present.

stop all your cluster sender channels still using the SCTQ ???
what does SCTO stand for, sorry i have not heard that before can you please let me know how it can be done? i can try


And here is the output for the dspmqtrn -a

TranNum(0,369775)
TRANSTATE(ACTIVE)
UOWLOGDA( ) UOWLOGTI( )
UOWSTDA(2018-02-15) UOWSTTI(08.06.25)
UOWLOG( )
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
CONN(5A59CC0720000501)
PID(18707) TID(1)
APPLTAG(amqrrmfa)
APPLDESC(WebSphere MQ Cluster Repository)
CHANNEL()
CONNAME()
QMURID(0.369775)
USERID(mqm)

TranNum(0,10)
TRANSTATE(ACTIVE)
UOWLOGDA( ) UOWLOGTI( )
UOWSTDA(2018-01-13) UOWSTTI(04.06.17)
UOWLOG( )
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
CONN(5A59CC0720000F01)
PID(18680) TID(10)
APPLTAG(amqzmuf0)
APPLDESC(WebSphere MQ Distributed Pub/Sub Command Task)
CHANNEL()
CONNAME()
QMURID(0.10)
USERID(mqm)

TranNum(0,369936)
TRANSTATE(ACTIVE)
UOWLOGDA( ) UOWLOGTI( )
UOWSTDA(2018-02-15) UOWSTTI(08.43.35)
UOWLOG( )
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
CONN(5A59CC0720000D01)
PID(18680) TID(9)
APPLTAG(amqzmuf0)
APPLDESC(WebSphere MQ Distributed Pub/Sub Fan Out Task)
CHANNEL()
CONNAME()
QMURID(0.369936)
USERID(mqm)

TranNum(0,1)
TRANSTATE(PREPARED)
UOWLOGDA( ) UOWLOGTI( )
UOWSTDA(2018-01-13) UOWSTTI(04.06.14)
UOWLOG( )
EXTURID(XA_FORMATID[WASD] XA_GTRID[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474] XA_BQUAL[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474000000010000000000000000000000000001])

TranNum(0,2)
TRANSTATE(PREPARED)
UOWLOGDA( ) UOWLOGTI( )
UOWSTDA(2018-01-13) UOWSTTI(04.06.14)
UOWLOG( )
EXTURID(XA_FORMATID[WASD] XA_GTRID[00000155FF5DAB94000000017C2544C8A5233F1354C6B5CDD56E1E68EE047CA889F00724] XA_BQUAL[00000155FF5DAB94000000017C2544C8A5233F1354C6B5CDD56E1E68EE047CA889F00724000000010000000000000000000000000003])

TranNum(0,3)
TRANSTATE(PREPARED)
UOWLOGDA( ) UOWLOGTI( )
UOWSTDA(2018-01-13) UOWSTTI(04.06.14)
UOWLOG( )
EXTURID(XA_FORMATID[WASD] XA_GTRID[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474] XA_BQUAL[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474000000010000000000000000000000000003])

TranNum(0,369937)
TRANSTATE(ACTIVE)
UOWLOGDA( ) UOWLOGTI( )
UOWSTDA(2018-02-15) UOWSTTI(08.43.35)
UOWLOG( )
EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
CONN(5A59CC0720000E01)
PID(18680) TID(11)
APPLTAG(amqzmuf0)
APPLDESC(WebSphere MQ Distributed Pub/Sub Publish Task)
CHANNEL()
CONNAME()
QMURID(0.369937)
USERID(mqm)
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 15, 2018 5:53 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25168
Location: Ohio, USA

harimhkr wrote:
stop all your cluster sender channels still using the SCTQ ???
what does SCTO stand for, sorry i have not heard that before can you


System Cluster Transmit Queue.

Given what the cluster sender channels would be using, and what you're posting about, it's not that much of a leap......

It's also a commonly used abbreviation in the MQ world, so you might want to make a note.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
harimhkr
PostPosted: Thu Feb 15, 2018 6:07 am Post subject: Reply with quote

Novice

Joined: 08 Jan 2013
Posts: 19

Not much of a user in forum its good to know, thanks for clarifying the SCTQ --- i will make a note.
Back to top
View user's profile Send private message
harimhkr
PostPosted: Thu Feb 15, 2018 6:10 am Post subject: Reply with quote

Novice

Joined: 08 Jan 2013
Posts: 19

fjb_saper wrote:
You need to look at queue status and the UNCOMM attribute.
Then you may look at dspmqtrn -a to see if there are any unresolved transactions / long running transactions.
Worst case scenario, they'll go away when you bounce the qmgr.

Those messages are either due to a long running transaction or may be poison messages on the SCTQ. If you can stop all your cluster sender channels still using the SCTQ and then look at the message on there. If they are not uncommitted you should be able to browse them and determine whether they are destined to a channel that no longer exists or that is in constant retrying or if they are SCTQ messages at all.

Have fun



i tried the option of stopping the channels that are connected to the SCTQ and still unable to view the content of the messages
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 15, 2018 7:22 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

harimhkr wrote:
Not much of a user in forum its good to know, thanks for clarifying the SCTQ --- i will make a note.

When faced with a new mq acronym, like SCTQ, go first to google, search for 'mq+sctq'. Google is your friend.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 15, 2018 7:29 am Post subject: Re: Unable to browse message on the queue with UCom:null Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

harimhkr wrote:
...
i tried using amqsbrc and q tool to view those messages but it says no messages.

It would help if you posted complete errors. I suspect that the entire error was along the lines of ReasonCode 2033 MQRC_NO_MESSAGES_AVAILABLE. Did you go to google and search for 'mq+2033'?

2033 does not mean that the queue is empty; rather, that there was no consumable message available for delivery. Messages in active Units of Work are not available for consumption.

What else took place around this time? For example, did you make any changes to another down-network cluster qmgr, a queue or a channel definition?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Feb 15, 2018 8:15 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19744
Location: LI,NY

harimhkr wrote:
We tried restarting the QM but the messages are still present.

stop all your cluster sender channels still using the SCTQ ???
what does SCTO stand for, sorry i have not heard that before can you please let me know how it can be done? i can try


And here is the output for the dspmqtrn -a

Code:
 TranNum(0,369775)
   TRANSTATE(ACTIVE)
   UOWLOGDA( )   UOWLOGTI( )
   UOWSTDA(2018-02-15)   UOWSTTI(08.06.25)
   UOWLOG( )
   EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
   CONN(5A59CC0720000501)
   PID(18707)            TID(1)
   APPLTAG(amqrrmfa)
   APPLDESC(WebSphere MQ Cluster Repository)
   CHANNEL()
   CONNAME()
   QMURID(0.369775)
   USERID(mqm)

 TranNum(0,10)
   TRANSTATE(ACTIVE)
   UOWLOGDA( )   UOWLOGTI( )
   UOWSTDA(2018-01-13)   UOWSTTI(04.06.17)
   UOWLOG( )
   EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
   CONN(5A59CC0720000F01)
   PID(18680)            TID(10)
   APPLTAG(amqzmuf0)
   APPLDESC(WebSphere MQ Distributed Pub/Sub Command Task)
   CHANNEL()
   CONNAME()
   QMURID(0.10)
   USERID(mqm)

 TranNum(0,369936)
   TRANSTATE(ACTIVE)
   UOWLOGDA( )   UOWLOGTI( )
   UOWSTDA(2018-02-15)   UOWSTTI(08.43.35)
   UOWLOG( )
   EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
   CONN(5A59CC0720000D01)
   PID(18680)            TID(9)
   APPLTAG(amqzmuf0)
   APPLDESC(WebSphere MQ Distributed Pub/Sub Fan Out Task)
   CHANNEL()
   CONNAME()
   QMURID(0.369936)
   USERID(mqm)

 TranNum(0,1)
   TRANSTATE(PREPARED)
   UOWLOGDA( )   UOWLOGTI( )
   UOWSTDA(2018-01-13)   UOWSTTI(04.06.14)
   UOWLOG( )
   EXTURID(XA_FORMATID[WASD] XA_GTRID[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474] XA_BQUAL[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474000000010000000000000000000000000001])

 TranNum(0,2)
   TRANSTATE(PREPARED)
   UOWLOGDA( )   UOWLOGTI( )
   UOWSTDA(2018-01-13)   UOWSTTI(04.06.14)
   UOWLOG( )
   EXTURID(XA_FORMATID[WASD] XA_GTRID[00000155FF5DAB94000000017C2544C8A5233F1354C6B5CDD56E1E68EE047CA889F00724] XA_BQUAL[00000155FF5DAB94000000017C2544C8A5233F1354C6B5CDD56E1E68EE047CA889F00724000000010000000000000000000000000003])

 TranNum(0,3)
   TRANSTATE(PREPARED)
   UOWLOGDA( )   UOWLOGTI( )
   UOWSTDA(2018-01-13)   UOWSTTI(04.06.14)
   UOWLOG( )
   EXTURID(XA_FORMATID[WASD] XA_GTRID[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474] XA_BQUAL[00000155FF5DAB94000000017C1154A809E9A516D8BFDF87B32A4CCA09F394EFA8957474000000010000000000000000000000000003])

 TranNum(0,369937)
   TRANSTATE(ACTIVE)
   UOWLOGDA( )   UOWLOGTI( )
   UOWSTDA(2018-02-15)   UOWSTTI(08.43.35)
   UOWLOG( )
   EXTURID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
   CONN(5A59CC0720000E01)
   PID(18680)            TID(11)
   APPLTAG(amqzmuf0)
   APPLDESC(WebSphere MQ Distributed Pub/Sub Publish Task)
   CHANNEL()
   CONNAME()
   QMURID(0.369937)
   USERID(mqm)


Looking at your output here and more specifically at UnitOfWork Start date and time a few things stand out:
You have UOWs that were started on 2018-01-13 that are defined as external (MQ is not the transaction manager) and have an external URID and XA_BQUAL. They are in the prepared state.
Apparently the Transaction Coordinator never commited or rolled back those messages (see tran 0,1; 0,2; 0,3). Is this expected? Do you really have transactions that last that long? This would account for the unreachable messages you're seeing on the SCTQ.

The question here is:
If the Transaction Coordinator (TC) was a J2EE server did you configure it so that on Restart it could commit / rollback any transaction that was suspended on shutdown?

In any case you will need to investigate what happened to those transactions from Jan 13th and what you'd want to do about them: commit or rollback...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
harimhkr
PostPosted: Thu Feb 15, 2018 8:40 am Post subject: Reply with quote

Novice

Joined: 08 Jan 2013
Posts: 19

fjb_saper wrote:


Looking at your output here and more specifically at UnitOfWork Start date and time a few things stand out:
You have UOWs that were started on 2018-01-13 that are defined as external (MQ is not the transaction manager) and have an external URID and XA_BQUAL. They are in the prepared state.
Apparently the Transaction Coordinator never commited or rolled back those messages (see tran 0,1; 0,2; 0,3). Is this expected? Do you really have transactions that last that long? This would account for the unreachable messages you're seeing on the SCTQ.

The question here is:
If the Transaction Coordinator (TC) was a J2EE server did you configure it so that on Restart it could commit / rollback any transaction that was suspended on shutdown?

In any case you will need to investigate what happened to those transactions from Jan 13th and what you'd want to do about them: commit or rollback...

Have fun


Yes the application using these is a Java based application and we don't administer it and doesn't have insight in to it.
And application team says everything from their end looks fine.
Is there anything we can do from the MQ side to remove these messages from the SCTQ so that we don't see these messages.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 15, 2018 9:05 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

harimhkr wrote:
Yes the application using these is a Java based application and we don't administer it and doesn't have insight in to it.

Work with those that do administer the app. Work with the MQ admins to make sure that the appropriate XA settings are in place.
harimhkr wrote:
And application team says everything from their end looks fine.

Apparently, there is/are transactions that did not complete (backout or commit) successfully, so all is not 'fine.' But, it's not an mq issue, rather it's an application issue.
harimhkr wrote:
Is there anything we can do from the MQ side to remove these messages from the SCTQ so that we don't see these messages.

No, not really. These so-called 'orphaned' messages should not have any impact on your qmgrs, so feel free to ignore them.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
harimhkr
PostPosted: Thu Feb 15, 2018 10:44 am Post subject: Reply with quote

Novice

Joined: 08 Jan 2013
Posts: 19

Quote:
Work with those that do administer the app. Work with the MQ admins to make sure that the appropriate XA settings are in place.
.


I am from MQ team what are the XA setting that is being refereed here. the Request comes from the JAVA based application and consumed by another java based application. i am not sure of any XA settings from the QM level. please advice

thankyou very much for all the assist
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 15, 2018 11:19 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

harimhkr wrote:
Quote:
Work with those that do administer the app. Work with the MQ admins to make sure that the appropriate XA settings are in place.
.


I am from MQ team what are the XA setting that is being refereed here. the Request comes from the JAVA based application and consumed by another java based application. i am not sure of any XA settings from the QM level. please advice

thankyou very much for all the assist


What transaction coordinator software are you using? What does their documentation specify for appropriate settings for resource managers participating in extended Units of Work?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
harimhkr
PostPosted: Thu Feb 15, 2018 11:21 am Post subject: Reply with quote

Novice

Joined: 08 Jan 2013
Posts: 19

bruce2359 wrote:

No, not really. These so-called 'orphaned' messages should not have any impact on your qmgrs, so feel free to ignore them.


Removed the messages from the queue as below will it have any negative implication that i should check for. Please advice.

To display the transaction numbers
dspmqtrn -m <QMNAME>
AMQ7056: Transaction number 0,1 is in-doubt.

to remove(backout) the uncommitted ones below is the syntax

rsvmqtrn -m <QMNAME> -b 0,1
rsvmqtrn -m <QMNAME> -b 0,2


thank again for all the help provided
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 15, 2018 11:53 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

Is the transaction worth one cent? One million dollars? While you may have technical skills to do either, what business rules apply? Should the transaction be committed? Or backed out?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexGeneral IBM MQ SupportUnable to browse message on the queue with UCom:null
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.