| Author |
Message
|
| venillav |
 Posted: Tue Apr 03, 2012 1:05 am Post subject: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue |
 |
|
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 |
|
 |
| mvic |
| Posted: Tue Apr 03, 2012 2:54 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
Are any of your cluster channels INDOUBT?
Are any applications currently using the queue (check DIS QSTATUS)? |
|
| Back to top |
|
|
| venillav |
| Posted: Tue Apr 03, 2012 3:52 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Tue Apr 03, 2012 4:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Try DIS CHS(*)
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| venillav |
| Posted: Tue Apr 03, 2012 4:32 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Tue Apr 03, 2012 5:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Clustering forum.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 03, 2012 5:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What version/release of WMQ?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| venillav |
| Posted: Tue Apr 03, 2012 5:20 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Tue Apr 03, 2012 5:31 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 03, 2012 5:42 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
| mvic |
| Posted: Tue Apr 03, 2012 5:54 am Post subject: Re: SYSTEM.CLUSTER.TRANSMIT.QUEUE UNCOM msg issue |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| 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 |
|
|
| mvic |
| Posted: Tue Apr 03, 2012 6:00 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| 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 |
|
|
| venillav |
| Posted: Tue Apr 03, 2012 6:15 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Tue Apr 03, 2012 7:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Apr 03, 2012 7:55 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| 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 |
|
|
|
|
