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 IndexClusteringSYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue

Post new topicReply to topic Goto page 1, 2  Next
SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue View previous topic :: View next topic
Author Message
venillav
PostPosted: Tue Apr 03, 2012 1:05 am Post subject: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue Reply with quote

Newbie

Joined: 03 Oct 2009
Posts: 7

Hi,

In one fo the clusteFR qmgr's SCTQ has a msg which is uncomitted and due to which I cnat even browse it but the curdepth shows as 1. The chl to its other Fr is running fine. It was before "SYSTEM.TEMP.." error which I solved by forcemove reset and then refresh cluster which solved the "SYSTEM.TEMP..." issue but still the msg on the SCTQ there...
Back to top
View user's profile Send private message
mvic
PostPosted: Tue Apr 03, 2012 2:54 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

Are any of your cluster channels INDOUBT?

Are any applications currently using the queue (check DIS QSTATUS)?
Back to top
View user's profile Send private message
venillav
PostPosted: Tue Apr 03, 2012 3:52 am Post subject: Reply with quote

Newbie

Joined: 03 Oct 2009
Posts: 7

No chls are INDOUBT, and Application which are handling it are APPLTAG(amqrmppa) , APPLTAG(amqrrmfa), broker flows. Out of which broker flows are inactive as of now, but amqr*** are active ones.

1 : dis qs(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
AMQ8450: Display queue status details.
QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) TYPE(QUEUE)
CURDEPTH(1) IPPROCS(9)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MEDIALOG(S0013622.LOG) MONQ(OFF)
MSGAGE( ) OPPROCS(35)
QTIME( , ) UNCOM(YES)
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 03, 2012 4:20 am Post subject: Reply with quote

Poobah

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

Try DIS CHS(*)
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
venillav
PostPosted: Tue Apr 03, 2012 4:32 am Post subject: Reply with quote

Newbie

Joined: 03 Oct 2009
Posts: 7

All the chls are running and no issues like YSTEM.TEMp as I said earlier

dis chs(*) where (status NE running)
9 : dis chs(*) where (status NE running)
AMQ8420: Channel Status not found.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 03, 2012 5:01 am Post subject: Reply with quote

Poobah

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

Moved to Clustering forum.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 03, 2012 5:14 am Post subject: Reply with quote

Poobah

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

What version/release of WMQ?
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
venillav
PostPosted: Tue Apr 03, 2012 5:20 am Post subject: Reply with quote

Newbie

Joined: 03 Oct 2009
Posts: 7

Name: WebSphere MQ
Version: 6.0.2.9
CMVC level: p600-209-100316
BuildType: IKAP - (Production)
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 03, 2012 5:31 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue Reply with quote

Poobah

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

venillav wrote:
...It was before "SYSTEM.TEMP.." error which I solved by forcemove reset and then refresh cluster which solved the "SYSTEM.TEMP..." issue ...

A common cause of SYSTEM.TEMP... channels is a defective (incorrect) CLUSRCVR channel definitions that prevents the creation of a matching CLUSSDR(A) channel. The simple fix is to take the offending CLUSRCVR definition out of the cluster, correct the definition, then add it back into the cluster.

Use of the FORCEREMOVE and RESET cluster commands is seldom necessary; and should be used at the direction of IBM for serious cluster errors. Your use of FORCEREMOVE and RESET commands was a sledge-hammer approach.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Apr 03, 2012 5:42 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue Reply with quote

Grand High Poobah

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

bruce2359 wrote:
Your use of FORCEREMOVE and RESET commands was a sledge-hammer approach.




It looks a lot like you've broken it. I suspect that uncommitted message is intended for the queue manager you blew out of the cluster. Note that

venilav wrote:
I cnat even browse it but the curdepth shows as 1


is true for all uncommitted messages.

You could try demoteing this queue manager to a PR, promoting another queue manager to FR and seeing if that cleans up. I'm not confident this will achieve anything, but since the next step is to tear down your cluster and rebuild it properly there's nothing left to lose.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mvic
PostPosted: Tue Apr 03, 2012 5:54 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

Vitor wrote:
since the next step is to tear down your cluster and rebuild it properly there's nothing left to lose.

Reserve that for the very last resort.

The OP just has an UNCOM message; no need to tear down your cluster for that.
Back to top
View user's profile Send private message
mvic
PostPosted: Tue Apr 03, 2012 6:00 am Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

venillav wrote:
IPPROCS(9) OPPROCS(35)

So, lots of open handles on your SCTQ.

What's the chance that one of them holds a UOW open?

The only other possibility is a non-connected process holding the open UOW, and since none of your channels are indoubt, this would suggest an XA transaction.

Do you have any XA (eg. WebSphere, Weblogic, CICS etc.) applications?
Back to top
View user's profile Send private message
venillav
PostPosted: Tue Apr 03, 2012 6:15 am Post subject: Reply with quote

Newbie

Joined: 03 Oct 2009
Posts: 7

Yes we use Websphere.

And also I havent broken the cluster, other messages are getting processed as they are intended to.

"What's the chance that one of them holds a UOW open? " I havent checked it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 03, 2012 7:46 am Post subject: Reply with quote

Poobah

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

venillav wrote:

And also I havent broken the cluster, other messages are getting processed as they are intended to.

You are picking nits here. Broken, damaged, scratched, dented, ...

My car has one flat tire, but 3 are still inflated and round, and getting me to and from work just fine.

You started with a very minor problem (SYSTEM.TEMP...) channel, then didn't follow the doc in the WMQ Queue Manager Clusters manual to fix the bad CLUSRCVR definition, the damaged the cluster with cluster commands that are to be used on recommendation by IBM.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
mvic
PostPosted: Tue Apr 03, 2012 7:55 am Post subject: Reply with quote

Padawan

Joined: 09 Mar 2004
Posts: 1981

bruce2359 wrote:
You are picking nits here. Broken, damaged, scratched, dented, ...

Why are you guys saying the OP has broken his/her cluster?

They have an UNCOM message.. this is (very probably) a totally separate issue from their cluster config. And IMHO the UNCOM message is not an issue at all.

venillav: remember, applications manage their own transaction lifetime. The only other things that do transactions on transmission queues are the channels getting from them. And you checked the channels for indoubt status. So the UNCOM message is bound to be owned by an application unit of work somewhere. The application will roll it back or commit it sooner or later, and if it does not, then the queue manager will roll it back automatically to recover log space.
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 IndexClusteringSYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue
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.