| Author |
Message
|
| Trainee |
 Posted: Wed Oct 10, 2007 10:01 am Post subject: CLUSTER SENDER CHANNEL |
 |
|
Centurion
Joined: 27 Oct 2006
Posts: 124
|
Hi ,
We have 4 queue managers in FQT environment in cluster 2 are full repository and 2 are partial which are on 2 aix servers.
Sender Channel on full repos queue manager 2 to full repos 1 is retrying status..when i chek the status it is showing different conn name than what we defined when we create.
This happend beacues some one took the saveqmgr dump from FQT and run on different servers(SIT) without changing the channel definations and clusters etc.I guess these got pointed to FQT .
So messages from queue manager2 in FQT are going to qm1 on SIT(We want it in FQT)
When we check the channel status cluster sender channel from QM2 is trying to resolve to QM1 on SIT..
Is there any way that we can solve the issue. Please advice
Channels got removed from SIT which are pointing to FQT got removed and receted with new host name etc on the same day when he created.Right now we stopped all these queue managers in SIT
Thank you
Trainee |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Oct 10, 2007 2:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Had the same problem and solved it in about 2 hours.
- Make sure the clusrcvr on the PR that was pointing falsely to your FR gets deleted and replaced with the correct clusrcvr.
- Restart the clussdr on the faulty PR
- suspend the faulty PR from the cluster
- shut the faulty PR down
- go to the FR and reset the cluster booting the faulty PR out of it.
- check that the faulty PR is no longer in the FR.
- If it still is make the other FR a PR reissue the reset cluster on the full FR and check again... then make the 2nd FR a full repository again...
- check all the PR's for a reference to the faulty PR.
If you find one run refresh cluster repos(yes) on it.
- Restart the previously faulty PR (still in suspended mode)
- check again the PR and make sure the clusrcvr channel is correct. As long as you're at it check as well the clussdr channel.
- repeat previous step with 4 eyes. You could have missed something
- resume the qmgr to the cluster
- start the clussdr channel
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 10, 2007 3:09 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
At least some of those steps should be unnecessary.
Maybe we can tempt ivans into confirming or denying.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 10, 2007 3:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
At least some of those steps should be unnecessary.
Maybe we can tempt ivans into confirming or denying. |
Well to tell you the truth I had a few more steps in it including the deletion of messages to the Cluster command queue that were for the wrong qmgr from the cluster xmitq...
... clearing the cluster repository queue... etc...
But I was hoping this should be enough.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 10, 2007 5:24 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I would hope that one would merely need to correct the channel definitions, and stop any assorted autodef channels to ensure that the correct definitions would be used.
But that's just a hope. I'm quite willing to take your practical experience as a better guide to what's actually necessary... but I'm also hoping that someone more knowledgeable than me on how it really works will weigh in.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 10, 2007 5:42 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzah.doc/qc13100_.htm
Seems to me all you would have to do is correct the CONNAME in the PR's CLUSRCVR channel and then....wait a bit. The change should be propogated out to any QMs that have an interest in this channel. Once the Autodefined channel has the new conname info, the next time it starts it will use the new conname. If the channel is retrying, the next retry will go with the new name (or just manually click START). If you are changing some other parm and the incoming channels are currently haoppily running, then you would have to restart the channels manually or wait for DISCINT to kick in.
Its been a couple of years since I dealt with this scenario, but I don't remember jumping through all those hoops, fjb_saper. I think I got thru it as described in the Cluster Manual.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 10, 2007 7:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The problems I had with it, was that it needed to be fixed real quick.
The qmgr that had been used as a blueprint to load the other qmgr was being used as a gateway to the cluster and the SLA should have been around 1 second.
Of course the fact that the colleague had loaded the new qmgr before editing the script did not help. Instantly the SLA went south... 
Fixing the receiver channel on the offending qmgr and booting the offending qmgr out of the cluster did not help much... We ended having to fix both the cluster, the offending qmgr and the qmgr of origin to reclaim the SLA...
Whenever the cluster got a whiff of confusion (sending responses to the offending qmgr to the origin qmgr) the response times where out there. As well as when sending messages back to the original qmgr....
Guess the cluster got confused that it was using one connection to send messages to 2 different qmgrs....
So you might be able to fix it all by waiting a bit... Just don't be too impatient and don't rely on some SLA...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
