| Author |
Message
|
| bamboozled_by_MQ |
 Posted: Tue Jan 20, 2004 4:29 am Post subject: indoubt channels - Please help |
 |
|
Voyager
Joined: 07 Jan 2004
Posts: 75
|
our setup is windowsXP mq5.3 to AIX mq5.3
we are seeing where some channels seem to go indoubt (X12.to.USERID) BUT instead of RESOLVE CHL(X12.to.USERID) ACTION(BACKOUT) working like most of the time this happens, it says:
error message AMQ9592: Program cannot resolve QMGR object.
I don't understand, we completely stop MQ on the worksation side and both the channels on the aix side but it will not let us resolve the channels but when displaying the channelstatus is it still clearly indoubt. the only way we are currently resolving this is completely moving them to a different aix box!!
x21.to.USERID
someone please help!!
thank you. |
|
| Back to top |
|
 |
| JasonE |
| Posted: Tue Jan 20, 2004 7:53 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
I can find many hits on our problem database for this problem.
If you are hitting that problem, first thing to try is fixpack 5 on both ends, although there may be another fix required on top of that depending on the problem.
You can try to circumvent by put disabling the xmitq and waiting to see
if it clears, then trying the resolve again, or if that does not work,
you might be hitting an apar IY47946 (post-APAR IY45615).
If you cant clear the problem either live with it until fixpack 6 and see if that helps or contact service.
Unless anyone else has a simpler answer! |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Jan 20, 2004 10:36 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well is the channel still sending data?? I have seen runmqsc report the channel status to be indoubt until a batch completes ???
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Jan 20, 2004 12:29 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
OK,
1st. it is not good practice to stop a channel from the receiver side. Normally you should stop the Sender and let the receiver stop on its own.
B. Check your CURSEQNO on the channels on both sides. If the sequence numbers are different and the messages are persistent the channel will go indoubt. Did you try a reset chl to reset the CURSEQNO?
III. is the indoubt channel the sender or the receiver? If it is the sender channel do a stop chl (chl.name) mode(force) and then a start chl.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| pgorak |
| Posted: Wed Jan 21, 2004 4:20 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
| Quote: |
| III. is the indoubt channel the sender or the receiver? If it is the sender channel do a stop chl (chl.name) mode(force) and then a start chl. |
Only the sending side may be in doubt. The receiving side is never in doubt.
The method for manual re-synchronization (action(backout) is not necessarily correct) is explained in the manuals.
Piotr
_________________
***
IBM Certified Solution Developer WebSphere MQ 5.3 |
|
| Back to top |
|
|
| Carla Viragh |
| Posted: Wed Jan 21, 2004 5:13 am Post subject: |
|
|
Voyager
Joined: 31 Oct 2003
Posts: 92
Location: São Paulo - Brasil
|
| csmith28 wrote: |
OK,
Did you try a reset chl to reset the CURSEQNO?
|
It´s dangerous, a message may be lost reseting the sequence of the channels, isn´t it?
_________________
Carla Viragh |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Jan 21, 2004 5:17 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Yep.
first RESOLVE CHANNEL(channel_name) ACTION(BACKOUT ), so the data is 'safe' on the transmissionQ.
if then the sequences still do not match, then you can reset, start channel.
Michael |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Jan 21, 2004 7:48 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
NO. Do not just do a BACKOUT without checking. You might end up sending messages twice.
There is a table in the Intercommunications book that leads you through the sequence of checking if you should do a COMMIT or a BACKOUT. Failure to follow that table will lead to either lost or duplicated messages.
Also, Carla, just resetting the sequence numbers (without a RESOLVE) will not cause messages to be sent twice. There is no correlation between messages and sequence number. The sequence number is just another method the channels use to make sure they are in sync.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Jan 21, 2004 7:59 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Eddie,
thanks for pointing that out! I stand corrected 
Carla asked about losing messages rather then them being sent twice.
Simply resetting the channel when in doubt can cause lost messages, resolving (with backout and no checking) can cause messages to be sent twice.
interesting stuff in Intercommunication Chapter 6 
Michael |
|
| Back to top |
|
|
| Carla Viragh |
| Posted: Wed Jan 21, 2004 9:58 am Post subject: |
|
|
Voyager
Joined: 31 Oct 2003
Posts: 92
Location: São Paulo - Brasil
|
Exactly... I wrote last post to advise that reset channel may lose the message 
But... if there is no correlation between sequence number and messages (as Eddie said), there is no way of losing messages in a reset channel command!
_________________
Carla Viragh |
|
| Back to top |
|
|
| csmith28 |
| Posted: Wed Jan 21, 2004 10:36 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| pgorak wrote: |
| Quote: |
| III. is the indoubt channel the sender or the receiver? If it is the sender channel do a stop chl (chl.name) mode(force) and then a start chl. |
Only the sending side may be in doubt. The receiving side is never in doubt.
The method for manual re-synchronization (action(backout) is not necessarily correct) is explained in the manuals.
Piotr |
right, sorry, not sure what I was thinking
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
|
|
