| Author |
Message
|
| stupidmqguy |
 Posted: Thu Dec 30, 2010 2:51 am Post subject: How to get the connection Handle for a channel in BINDING? |
 |
|
Newbie
Joined: 30 Dec 2010
Posts: 5
|
Hi all,
I am using MQV6 on AIX 5.3. I have few cluster sender channels that are in BINDING state. When I try to stop the channle i get the below error :
AMQ8101: WebSphere MQ error (7F9) has occurred.
7F9 --> 2041(MQRC_OBJECT_CHANGED)
I am getting this issue very often. Everytime I have to restart my qmgr to resolve the issue.
Can anyone provide any solution other than restarting the qmgr?
I am thinking, If I can get the conn handle for the channel in binding and stop the connection will solve the problem. Then, how to get the conn handle for the channels in Binding??
-Thanks in advance. |
|
| Back to top |
|
 |
| suneel |
| Posted: Thu Dec 30, 2010 5:09 am Post subject: |
|
|
Voyager
Joined: 06 Nov 2009
Posts: 89
|
Please check whether any queues are full and mqpartition is full
Don |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Dec 30, 2010 5:14 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
Check what you have mentioned in the CONNAME in cluster sender and receiver ends.
Also check there is no network/DNS issue in your system..in order to resolve the connection across.
Try to 'PING' the channel, after stopping in Force mode. If Ping is happening correctly then try to 'Resolve' the channel in 'commit Action'. Then 'Start' the Channel.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Dec 30, 2010 5:24 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...try to 'Resolve' the channel in 'commit Action'... |
Really? And you would do this without determining the LUWID at each end? 
Do any of your customers complain about lost messages?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Dec 30, 2010 5:42 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
| ...try to 'Resolve' the channel in 'commit Action'... |
Really? And you would do this without determining the LUWID at each end? |
Ya we can also check LUWID.
Use the DISPLAY CHSTATUS command to find the last-committed logical unit of work ID (LUWID) for each side of the channel.
The Seq.No. & LUWID are there if the channel is in doubt and his channel is still in BINDING state. (http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzae.doc/ic11350_.htm)
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Dec 30, 2010 5:47 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Code: |
The last logical unit-of-work identifier for a message on the channel.
To determine the last-committed logical unit of work ID (LUWID) for the channel, compare this value to the last-committed LUWID for the receiving side of the channel.
* If the two LUWIDs are the same, the receiving side has committed the unit of work that the sender considers to be in doubt. The sending side can now remove the in-doubt messages from the transmission queue and re-enable it.
* If the two LUWIDs are different, the receiving side has not committed the unit of work that the sender considers to be in doubt. The sending side needs to retain the in-doubt messages on the transmission queue and re-send them.
|
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Dec 30, 2010 5:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...Ya we can also check LUWID... |
My point being that the OP was stupidmqguy's first post on the site, and while I make no assumptions as to his depth of knowledge, it may be that your (initially dangerous) advice may be taken at face value and acted upon - with little consequence to you, but potentially job-fatal consequences for someone else...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Dec 30, 2010 6:21 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
| ...Ya we can also check LUWID... |
My point being that the OP was stupidmqguy's first post on the site, and while I make no assumptions as to his depth of knowledge.. |
What the SUBSTATE of the channel as his channel is in BINDING state ?
Give command, DISPLAY CHS(CHANNELNAME) ALL , on both the ends.
Note:
1. In some cases there might be a substate at one end of the channel only. 2. Many substates are transitory, so issue that command a few times to detect/know whether a channel is stuck somewhere in a particular substate.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| stupidmqguy |
| Posted: Thu Dec 30, 2010 10:25 pm Post subject: |
|
|
Newbie
Joined: 30 Dec 2010
Posts: 5
|
| exerk wrote: |
| shashivarungupta wrote: |
| ...Ya we can also check LUWID... |
My point being that the OP was stupidmqguy's first post on the site, and while I make no assumptions as to his depth of knowledge, it may be that your (initially dangerous) advice may be taken at face value and acted upon - with little consequence to you, but potentially job-fatal consequences for someone else... |
@exerk,
Yes, This is my first post. But i have been a silent follower of the site for a long time. I am really sorry if you think my ideas are dangerous or something. I just thought of sharing my idea in the forum and correct my self if i am not following the right path.
Last edited by stupidmqguy on Thu Dec 30, 2010 10:41 pm; edited 1 time in total |
|
| Back to top |
|
|
| stupidmqguy |
| Posted: Thu Dec 30, 2010 10:40 pm Post subject: |
|
|
Newbie
Joined: 30 Dec 2010
Posts: 5
|
| shashivarungupta wrote: |
| exerk wrote: |
| shashivarungupta wrote: |
| ...Ya we can also check LUWID... |
My point being that the OP was stupidmqguy's first post on the site, and while I make no assumptions as to his depth of knowledge.. |
What the SUBSTATE of the channel as his channel is in BINDING state ?
Give command, DISPLAY CHS(CHANNELNAME) ALL , on both the ends.
Note:
1. In some cases there might be a substate at one end of the channel only. 2. Many substates are transitory, so issue that command a few times to detect/know whether a channel is stuck somewhere in a particular substate. |
The substate of the channel is null. Below is the o/p of dis chs.
AMQ8417: Display Channel Status details.
CHANNEL(XYZ.ABC) CHLTYPE(CLUSSDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(0) BUFSSENT(0)
BYTSRCVD(0) BYTSSENT(0)
CHSTADA(2010-12-27) CHSTATI(23.33.06)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(abc.labs.com(10001))
CURLUWID(0000000000000000) CURMSGS(0)
CURRENT CURSEQNO(0)
EXITTIME(0,0) HBINT(60)
INDOUBT(NO) JOBNAME(00068986000028A9)
LOCLADDR( ) LONGRTS(999999999)
LSTLUWID(0000000000000000) LSTMSGDA( )
LSTMSGTI( ) LSTSEQNO(0)
MCASTAT(RUNNING) MCAUSER( )
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RAPPLTAG( ) RQMNAME( )
SHORTRTS(10) SSLCERTI( )
SSLKEYDA( ) SSLKEYTI( )
SSLPEER( ) SSLRKEYS(0)
STATUS(BINDING) STOPREQ(NO)
SUBSTATE( ) XBATCHSZ(0,0)
XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE) XQMSGSA(39)
XQTIME(0,0)
The corresponding receiver channel is in inactive state.
dis chs(XYZ.ABC) all
9 : dis chs(XYZ.ABC) all
AMQ8420: Channel Status not found.
Here is the output of display channel.
dis chl(XYZ.ABC)
10 : dis chl(XYZ.ABC)
AMQ8414: Display Channel details.
CHANNEL(XYZ.ABC) CHLTYPE(CLUSRCVR)
ALTDATE(2010-07-29) ALTTIME(03.02.20)
BATCHHB(0) BATCHINT(0)
BATCHSZ(50) CLUSNL( )
CLUSTER(XYZ) CLWLPRTY(0)
CLWLRANK(0) CLWLWGHT(50)
COMPHDR(NONE) COMPMSG(NONE)
CONNAME(abc.labs.com(10001))
CONVERT(NO) DESCR( )
DISCINT(120) HBINT(60)
KAINT(AUTO) LOCLADDR( )
LONGRTY(999999999) LONGTMR(1200)
MAXMSGL(4194304) MCANAME( )
MCATYPE(THREAD) MCAUSER( )
MODENAME( ) MONCHL(OFF)
MRDATA( ) MREXIT( )
MRRTY(10) MRTMR(1000)
MSGDATA( ) MSGEXIT( )
NETPRTY(7) NPMSPEED(FAST)
PUTAUT(DEF) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SEQWRAP(999999999)
SHORTRTY(10) SHORTTMR(60)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) STATCHL(OFF)
TPNAME( ) TRPTYPE(TCP)
One more point here, the same cluster channel is running from a third qmgr in the same cluster. |
|
| Back to top |
|
|
| stupidmqguy |
| Posted: Thu Dec 30, 2010 10:47 pm Post subject: |
|
|
Newbie
Joined: 30 Dec 2010
Posts: 5
|
| shashivarungupta wrote: |
Check what you have mentioned in the CONNAME in cluster sender and receiver ends.
Also check there is no network/DNS issue in your system..in order to resolve the connection across.
Try to 'PING' the channel, after stopping in Force mode. If Ping is happening correctly then try to 'Resolve' the channel in 'commit Action'. Then 'Start' the Channel. |
I have tried all these option without any success. Tried stopping in force mode. But the same error is comming.(AMQ8101: WebSphere MQ error (7F9) has occurred. ) and the channel status remains in STOPPING state for ever. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Dec 31, 2010 1:00 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| stupidmqguy wrote: |
@exerk,
Yes, This is my first post. But i have been a silent follower of the site for a long time. I am really sorry if you think my ideas are dangerous or something. I just thought of sharing my idea in the forum and correct my self if i am not following the right path. |
My humble apologies to you stupidmqguy if you thought that the 'dangerous' remark was in reference to you; I can assure you it was not.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Dec 31, 2010 1:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
1. What maintenance level of WMQ are you at?
2. Have you switched on/off trace (briefly) to capture any information while you try to stop the channel?
3. Is this the only queue manager in the cluster that exhibits this behaviour?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| stupidmqguy |
| Posted: Fri Dec 31, 2010 1:51 am Post subject: |
|
|
Newbie
Joined: 30 Dec 2010
Posts: 5
|
| exerk wrote: |
1. What maintenance level of WMQ are you at?
2. Have you switched on/off trace (briefly) to capture any information while you try to stop the channel?
3. Is this the only queue manager in the cluster that exhibits this behaviour? |
1.
Name: WebSphere MQ
Version: 6.0.2.8
CMVC level: p600-208-090930
BuildType: IKAP - (Production)
2. No I didnt switched on/off the trace.
3. Yes, channels from other cluster qmgrs don't have any issues. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Dec 31, 2010 2:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Have a good look at THIS, and consider applying the latest maintenance (6.0.2.10). Go forward from there.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
