| Author |
Message
|
| santhana lakshmi |
 Posted: Thu Jun 16, 2005 9:41 pm Post subject: Channel starting problem |
 |
|
Newbie
Joined: 02 Feb 2005
Posts: 6
Location: Mumbai
|
Hi,
I have automated the starting of sender channels by putting the MQ commands in the command queue(OS 390). I faced problems when the channel was in retry start.Hence i have changed the automation to include
STOP FORCE
RESOLVE BACKOUT
RESET
START CHANNEL
This was working fine.but for past one week for few members the channel is not getting started. we even checked for the receiver channel status,it is in INACTIVE only.
we use IBM WebsphereMQ for both ends.
can anyone tell me what are the other scenerios in which starting the channel will fail ?
_________________
With Regards,
Santhana Lakshmi Rajagopal,
Tata Consultancy services Limited,
Mumbai,India |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Jun 17, 2005 1:30 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
you should check the chin log on both ends go get the reason why the channel is not running. maybe the receiver is inactive because nobody started the sender 
There could be lots of reasons why a channel is not running, from my experience its the network in most cases.
i would never include backout or reset commands in the automation. if a channel is indoubt or if the sequence number does not match there is the need for manual investigation (to find out why). if you just backout or commit without checking you may doublicate or delete messages.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 17, 2005 2:23 pm Post subject: Re: Channel starting problem |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| santhana lakshmi wrote: |
| I have automated the starting of sender channels by putting the MQ commands in the command queue(OS 390). |
You should not do this. The right way is to enable triggering for the channels.
| santhana lakshmi wrote: |
I faced problems when the channel was in retry start.Hence i have changed the automation to include
STOP FORCE
RESOLVE BACKOUT
RESET
START CHANNEL
|
To expand on Mr.Butcher's answer, if it was such a good idea to automate the RESETs and RESOLVEs, IBM would have done it for you in the base product, right? Don't do that.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| vinodsasidharan |
| Posted: Mon Jun 27, 2005 6:48 am Post subject: Resolve only in case of Indoubt state |
|
|
Apprentice
Joined: 25 Apr 2003
Posts: 47
Location: Norwich
|
Resolve a channel cannot be done blindly .
It is done only when a channel is in Indoubt state .
And further resolve channel commit or backout cannot be done blindly.
If the two LUWIDs ( server / receiver) are the same
then COMMIT
else backout .
_________________
Vinod sasidharan
Ibm Certfied MQ Admin 5.3
Ibm Certfied MQ Admin 6.0
Ibm Certfied WAS Admin 6.0
Ibm Certfied WMB Admin 5.0
Ibm Certfied Db2 Specialist.
Sun certified Java Programmer.
"Ai carte, ai parte ....................." |
|
| Back to top |
|
|
| kingsley |
| Posted: Mon Jun 27, 2005 7:01 am Post subject: |
|
|
Disciple
Joined: 30 Sep 2001
Posts: 175
Location: Hursley
|
Peter,
When the channels are out of sequence, resulting in Retrying State, there is a specific CSQxxxxx line that comes in chintask.
The Chintask is monitored and automation can read that message and a job can be scheduled to reset the channel.
IBM would'nt do that in their base product. But we have implemented it and its there in our infrastructure on MQ on Z/OS for sometime i know.
thanks
kingsley. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Jun 27, 2005 8:32 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
But we have implemented it and its there in our infrastructure on MQ on Z/OS for sometime i know.
|
That isn't a valid arguement for keeping doing it in my opinion. You may get away with it in this case but, as others have explained, it is bad practice.
The message from the CHIN isn't necessarily there for automation, it is there for notification. That is a big difference. Yes, it can be monitored and an automated process could be fired off when it is issued but that doesn't mean it should be blindly reset/resolved. A page or an email...great, blindly doing a reset/resolve, not in our shop.  |
|
| Back to top |
|
|
| santhana lakshmi |
| Posted: Thu Jun 30, 2005 10:24 pm Post subject: Channel Starting problem |
|
|
Newbie
Joined: 02 Feb 2005
Posts: 6
Location: Mumbai
|
Hi All,
I am really sorry for implementing such a bad practice. Thanks for all your responses. As you adviced i checked the CHIN messages. For my surprise for almost all the channels the error was "remote listener unavailable" .
but the listener at the users end is running.can anyone tell me is there any chances of network related issues? we are using TCP/IP protocol.
I would like to ask one more doubt. Is there any process to be followed when the users start the queuemanagers? I hope that nothing as such is required,still kindly clear my doubt.
This issue is raising slowly and now-a-days we are receving complaints from around 30 users during production hours. Kindly advice me on this.
_________________
With Regards,
Santhana Lakshmi Rajagopal,
Tata Consultancy services Limited,
Mumbai,India |
|
| Back to top |
|
|
| santhana lakshmi |
| Posted: Thu Jun 30, 2005 11:51 pm Post subject: channel starting problem - TCP/IP Errors |
|
|
Newbie
Joined: 02 Feb 2005
Posts: 6
Location: Mumbai
|
Dear All,
From the CHIN trace i have collected the error codes and the messages also.but i am unable to make to out where exactly is the problem.can anyone help me on this?
The most common CSQX.. messages.
CSQX202E
CSQX208E
TCP/IP return code
467 - Connection timed out.
461 - Connection reset by peer.
468 - An attemp tp TCP/IP connect was rejected.
46A - No route to Host.
480 - Asynchronous I/O request as been canceled
8C - Pipe is broken.
while browsing in the net i came across the KeepAlive option in TCP/IP. Does it have any connection with our problem.
_________________
With Regards,
Santhana Lakshmi Rajagopal,
Tata Consultancy services Limited,
Mumbai,India |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 01, 2005 11:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
From what you are saying it looks like you already have trouble with the network connection. Using keep alive to avoid the channel going to idle or retry in such an environment is just going against the current.
MQ is per essence an asynchronous mechanism and you just have to let the mechanism take care of these problems.
Have your channels triggered. Let MQ resolve the rest. Have alerts on your channels and network and let the network folks deal with any communications problems.
Enjoy  |
|
| Back to top |
|
|
|
|
