Author |
Message
|
KeeferG |
Posted: Tue Sep 18, 2007 8:56 am Post subject: Best way to alter CLUSRCVR channels |
|
|
 Master
Joined: 15 Oct 2004 Posts: 215 Location: Basingstoke, UK
|
Hi,
I am looking for the best way to manually alter the SHORTRTY and SHORTTMR parameters for a cluster of 32 queue managers.
My plan is to fix 1 CLUSRCVR at a time by doing the following.
Stopping all CLUSSDR channels until the CLUSRCVR shows inactive.
ALTER CLUSRCVR to remove from cluster. Not sure if needed.
ALTER CLUSRCVR to take new parameters and rejoin cluster.
Start all CLUSSDR channels and check status.
I am wondering if instead of stopping the CLUSSDR channels I can alter my CLUSRCVR channel then issue a refresh as the above process is long and painful for all 32 queue managers.
Any thoughts.
[/list] _________________ Keith Guttridge
-----------------
Using MQ since 1995 |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Sep 18, 2007 10:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I'd think you could stop the clusrcvr instead of all the clussdrs.
Then alter the parameters.
Then start the clusrcvr. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Sep 18, 2007 2:54 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Step 1 Suspend the qmgr cluster(mycluster)
Step 2 stop clusrcvr chl
Step 3 chge clusrcvr chl
Step 4 start clusrcvr chl
Step 5 resume qmgr cluster(mycluster) _________________ MQ & Broker admin |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Sep 18, 2007 4:44 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
How fast do you need this to happen? You could just go to all your CLUSRCVRs and alter them on the fly and then just wait for the running channel(s) to reach DISCINT. The next time the channel starts up it will start with the new parms. That will handle running channels. For new incoming channels your change will be picked up immediatly when they start up for the first time after your change. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
KeeferG |
Posted: Wed Sep 19, 2007 12:19 am Post subject: |
|
|
 Master
Joined: 15 Oct 2004 Posts: 215 Location: Basingstoke, UK
|
We have tried issuing a stop from the CLUSRCVR before and this caused problems but we can try it again and if it fails again then issue a stop from all sending ends
We only ever have a single instance of a cluster queue so the suspend step is not required.
I think we shall try the following
FOR each QMGR
1) STOP CLUSRCVR
2) ALTER CLUSRCVR
3) START CLUSRCVR
Channels will then autmatically pick up the new settings once they are stopped or go inactive.
Fingers crossed the stop on the CLUSRCVR works this time. _________________ Keith Guttridge
-----------------
Using MQ since 1995 |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Sep 19, 2007 9:40 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
I stop CLUSRCVRs all the time Keith. Should work fine as long as your MQ version is relatively current. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
KeeferG |
Posted: Thu Sep 20, 2007 8:31 am Post subject: |
|
|
 Master
Joined: 15 Oct 2004 Posts: 215 Location: Basingstoke, UK
|
When I last did it on our production 5.3.12 system they stopped fine. We made our changes and then started them up. And then the vfun began with DLQs filling up with messages that were to big for destination queues. A quick look at the messages showed that they were being concatonated. Whether this was by the channels or a rogue app was never determined. A panic stop of the CLUSRCVR and all correponding CLUSSDR's stopped the issue. No problems occured after the restart.
Lots of fun.
This time I have decided not to stop the channels at all and let the config update by themselves once they have naturally timed out. _________________ Keith Guttridge
-----------------
Using MQ since 1995 |
|
Back to top |
|
 |
|