| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Channel INBOUBT problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| rajesh00001 |
 Posted: Thu Jul 08, 2010 10:52 am Post subject: Channel INBOUBT problem |
 |
|
Apprentice
Joined: 08 Sep 2009
Posts: 34
|
Hi Friends,
Recently I am facing problem with channel.
Sender channel status is showing running, but messages are transferring very slowly.
At the same time I have identified channel in-doubt property got changed to YES( INDOUBT(YES)).
I have stopped inbound flow then after some time xmit queue got empty and again channel
in-doubt property got changed to NO automatically INDOUBT(NO)).
I have verified CURLUWID value of sender channel and LSTLUWID value of receiver channel and found both values are different.
So I have executed below command as I read some where.
RESOLVE CHANNEL(CHANNEL NAME) ACTION(BACKOUT)
After that again I have started channel and inbound flow of messages, but again I am facing same problem.
Please help me to resolve the issue.
Source system is UNIX and target system is Z/os |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jul 08, 2010 12:03 pm Post subject: Re: Channel INBOUBT problem |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rajesh00001 wrote: |
So I have executed below command as I read some where.
RESOLVE CHANNEL(CHANNEL NAME) ACTION(BACKOUT)
|
What led you to select this command, given that you can't remember where you read it? Specifically what investigation of the problem resulted in your selection of the BACKOUT option?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Jul 08, 2010 9:26 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
My guess is that there is a problem on the z/OS receiving end, and that maybe the channel retry parameters are used on this receiving end. This could explain that the channel is still runing, but indoubt because the receiving end is busy with retries and did not confirm the receive of the messages to the sender.
check the receiving end for problems (queue full, no or full dlq, security issues, .....) and check the receiving channel for the retry parameters.
if a channel is indoubt there is a problem. solve the problem first. then start the channel. Most indoubt situations are resolved by MQ itself after the problem has been fixed and the channel has been started again. Do nor resolve the channel without fixing the problem. you may lose or doublicate messages if you chose the wrong action.......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| rajesh00001 |
| Posted: Fri Jul 09, 2010 1:53 am Post subject: |
|
|
Apprentice
Joined: 08 Sep 2009
Posts: 34
|
Hi,
http://www.mqseries.net/manuals/intercommunication/csqzae061d.htm
In-doubt channels
An in-doubt channel is a channel that is in doubt with a remote channel about which messages have been sent and received. Note the distinction between this and a queue manager being in doubt about which messages should be committed to a queue.
You can reduce the opportunity for a channel to be placed in doubt by using the Batch Heartbeat channel parameter (BATCHHB). When a value for this parameter is specified, a sender channel checks that the remote channel is still active before taking any further action. If no response is received the receiver channel is considered to be no longer active. The messages can be rolled-back, and re-routed, and the sender-channel is not put in doubt. This reduces the time when the channel could be placed in doubt to the period between the sender channel verifying that the receiver channel is still active, and verifying that the receiver channel has received the sent messages. See Chapter 6, Channel attributes for more information on the batch heartbeat parameter.
In-doubt channel problems are usually resolved automatically. Even when communication is lost, and a channel is placed in doubt with a message batch at the sender whose receipt status is unknown, the situation is resolved when communication is re-established. Sequence number and LUWID records are kept for this purpose. The channel is in doubt until LUWID information has been exchanged, and only one batch of messages can be in doubt for the channel.
You can, when necessary, resynchronize the channel manually. The term manual includes use of operators or programs that contain WebSphere MQ system management commands. The manual resynchronization process works as follows. This description uses MQSC commands, but you can also use the PCF equivalents.
1. Use the DISPLAY CHSTATUS command to find the last-committed logical unit of work ID (LUWID) for each side of the channel. Do this using the following commands:
* For the in-doubt side of the channel:
DISPLAY CHSTATUS(name) SAVED CURLUWID
You can use the CONNAME and XMITQ parameters to further identify the channel.
* For the receiving side of the channel:
DISPLAY CHSTATUS(name) SAVED LSTLUWID
You can use the CONNAME parameter to further identify the channel.
The commands are different because only the sending side of the channel can be in doubt. The receiving side is never in doubt.
On WebSphere MQ for iSeries, the DISPLAY CHSTATUS command can be executed from a file using the STRMQMMQSC command or the Work with MQM Channel Status CL command, WRKMQMCHST
2. 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. This is done with the following channel RESOLVE command:
RESOLVE CHANNEL(name) ACTION(COMMIT)
3. 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. This is done with the following channel RESOLVE command:
RESOLVE CHANNEL(name) ACTION(BACKOUT)
On WebSphere MQ for iSeries, you can use the Resolve MQM Channel command, RSVMQMCHL.
Once this process is complete the channel is no longer in doubt. The transmission queue can now be used by another channel, if required |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jul 09, 2010 2:48 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
And what is your question? or why did you post that part of the documentation? i'd rather suggest to find out why the channel is indoubt and running. again... check the receiving end.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| SAFraser |
| Posted: Fri Jul 09, 2010 9:39 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
A running channel INDOUBT is not, by definition, broken.
We have an application that puts messages very quickly, and we batch them on the channel. While the sender waits for the receiver channel to acknowledge the batch (and by the way, the sender is a big bad mainframe and the receiver is a twinkie box), the running channel is properly indoubt.
That's my understanding, anyway. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 09, 2010 9:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| SAFraser wrote: |
| That's my understanding, anyway. |
IMHO that's not an indoubt channel, as the 2 MCAs are very clear on what's happening - there's a batch of messages in flight which may or may not be acknowledged. So the channel status will show as running. An indoubt channel is where the MCAs can't agree on what the message transmission status is.
I could be wrong, and await correction from the better informed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Fri Jul 09, 2010 10:34 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
The sender sends a big batch of messages very quickly.
A batch of messages are in-flight.
The channels are both happily running.
But until the receiver acknowledges the batch, doesn't the sender consider the status of the messages as indoubt?
I think of "indoubt" the same way I think of "uncommitted" -- as informational rather than inherently evil. But that's probably just uninformed optimism.
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 09, 2010 10:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| But until the receiver acknowledges the batch, doesn't the sender consider the status of the messages as indoubt? |
Until all the end-of-batch hand-shaking is done, both sender and receiver ends of the channel consider the batch indoubt.
_________________
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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
