| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Purge all knowlege of a cluster from a queue manager |
« View previous topic :: View next topic » |
| Author |
Message
|
| shash |
 Posted: Sat Mar 12, 2005 4:02 pm Post subject: Purge all knowlege of a cluster from a queue manager |
 |
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
I have a cluster of 3 queue managers. QM1 (FR), QM2 (FR) and QM3 (PR). Let's call the cluster CLUSX.
I now go and delete QM2 and QM3 using endmqm+dltmqm commands (its the worst thing anyone can ever do in a cluster but please humor me for a while; this is a test environment.)
Now I end up with a confused cluster where the only existing queue manager, QM1, is unaware that QM2 and QM3 have been deleted. QM1 still contains definitions for QM2 and QM3 along with all channel and other MQ object definitions.
What I now want to do is reintroduce QM2 and QM3 into the cluster (CLUSX), but if I just define QM2 and QM3 and add it to the cluster, QM1 will have duplicate definitions of QM2 and QM3, since each of these new queue managers will have a different QMID. So I want to purge all knowlege of the cluster (CLUSX) from QM1 and reassemble everything.
I believe there are two ways to approach this problem -
1) I remove QM1 from the cluster CLUSX and then blow away the repository information
| Code: |
ALTER QMGR REPOS(' ') REPOSNL(' ')
SUSPEND QMGR CLUSTER(CLUSX)
STOP CHANNEL(TO.QM1)
ALTER CHANNEL(TO.QM1) CHLTYPE(CLUSRCVR) CLUSTER(' ')
DELETE CHANNEL(TO.QM1)
STOP CHANNEL(TO.QM2)
DELETE CHANNEL(TO.QM2)
ALTER QLOCAL(SYSTEM.CLUSTER.COMMAND.QUEUE) GET(DISABLED) PUT(DISABLED)
CLEAR QLOCAL(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
ALTER QLOCAL(SYSTEM.CLUSTER.COMMAND.QUEUE) GET(ENABLED) PUT(ENABLED)
Restart QM1
|
The questions I have about this approach are:
a) The SYSTEM.CLUSTER.TRANSMIT.QUEUE contains messages which has to be taken care of seperately (in winnt probably using clusxq utility in ms0g). How do I flush out messages in SYSTEM.CLUSTER.TRANSMIT.QUEUE if QM1 is hosted on z/OS?
b) even though QM1 is purged of all info about the cluster CLUSX, will reintroducing QM1 back into CLUSX create any problem. Is CLUSX purged of info about all the queue managers?
c) Is a REFRESH CLUSTER('CLUSX') command needed at any step in this approach?
d) If I go by this approach am I missing something? Any extra command I need to execute?
2) Use the "clean QueueManagerName ClusterName" utility from the ms0g support pack, which essentially does the following:
- remove the queue manager QM1 from the cluster
| Code: |
ALTER QMGR REPOS(' ') REPOSNL(' ')
ALTER CHANNEL('TO.QM1') CHLTYPE(CLUSRCVR) CLUSTER(' ')
ALTER CHANNEL('TO.QM2') CHLTYPE(CLUSSDR) CLUSTER(' ')
REFRESH CLUSTER('CLUSX')
|
- remove residual memory of cluster from QM
| Code: |
DEFINE NAMELIST('SYSTEM.CLEAN.NAMELIST') NAMES('CLUSX') REPLACE
ALTER QMGR REPOS(' ') REPOSNL('SYSTEM.CLEAN.NAMELIST')
RESET CLUSTER('CLUSX') QMNAME('QM2') ACTION(FORCEREMOVE)
RESET CLUSTER('CLUSX') QMNAME('QM3') ACTION(FORCEREMOVE)
ALTER QMGR REPOS(' ') REPOSNL(' ')
DELETE NAMELIST('SYSTEM.CLEAN.NAMELIST')
REFRESH CLUSTER('CLUSX')
|
The questions I have about this approach are:
a) Would you prefer this approach over approach 1#
b) Will the SYSTEM.CLUSTER.TRANSMIT.QUEUE get cleaned up if I use this approach?
c) How is
| Quote: |
ALTER QLOCAL(SYSTEM.CLUSTER.COMMAND.QUEUE) GET(DISABLED) PUT(DISABLED)
CLEAR QLOCAL(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
ALTER QLOCAL(SYSTEM.CLUSTER.COMMAND.QUEUE) GET(ENABLED) PUT(ENABLED)
Restart QM1
different from
RESET CLUSTER('CLUSX') QMNAME('QM2') ACTION(FORCEREMOVE)
RESET CLUSTER('CLUSX') QMNAME('QM3') ACTION(FORCEREMOVE)
REFRESH CLUSTER('CLUSX')
|
I would really appreciate of someone can help me with answers to these questions and thanks for your patience 
shash |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sun Mar 13, 2005 6:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
a) The SYSTEM.CLUSTER.TRANSMIT.QUEUE contains messages which has to be taken care of seperately (in winnt probably using clusxq utility in ms0g). How do I flush out messages in SYSTEM.CLUSTER.TRANSMIT.QUEUE if QM1 is hosted on z/OS?
|
Use a program that can destructivly get the messages for you. Support pack MO71 or MS0H I would use, or use your own. z/OS also has a clear q command.
| Quote: |
b) even though QM1 is purged of all info about the cluster CLUSX, will reintroducing QM1 back into CLUSX create any problem. Is CLUSX purged of info about all the queue managers?
|
If QM1 was the only QM in CLUSX, and you blow away all info in the repository queue (after declustering any of its objects), then there is no CLUSX. Anywhere. So you are free to recreate it.
| Quote: |
c) Is a REFRESH CLUSTER('CLUSX') command needed at any step in this approach?
|
Not if you do it this way.
| Quote: |
d) If I go by this approach am I missing something? Any extra command I need to execute?
|
I would do this:
| Code: |
ALTER QMGR REPOS(' ') REPOSNL(' ')
STOP CHANNEL(TO.QM1)
DELETE CHANNEL(TO.QM1)
STOP CHANNEL(TO.QM2)
DELETE CHANNEL(TO.QM2)
ALTER QLOCAL(SYSTEM.CLUSTER.COMMAND.QUEUE) GET(DISABLED) PUT(DISABLED)
CLEAR QLOCAL(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
CLEAR QLOCAL(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
CLEAR QLOCAL(SYSTEM.CLUSTER.COMMAND.QUEUE)
ALTER QLOCAL(SYSTEM.CLUSTER.COMMAND.QUEUE) GET(ENABLED) PUT(ENABLED)
Restart QM1
|
We have done this a few times when we were at 5.2. Back then clustering had some issues, and sometimes the cluster was FUBARed, so this was the easiest and quickest way to be 100% all was well. We had small clusters.
THIS IS NOT A RECOMMENDED OR SUPPORTED WAY OF DOING THIS! But it does work.
I have not used MSOG much.
| Quote: |
a) Would you prefer this approach over approach 1#
|
If it works, yes. I would rather do it by commands instead of causing the Repository Manager to crash and restarting a QM. But I would have to test it first. It seems it would work.
| Quote: |
b) Will the SYSTEM.CLUSTER.TRANSMIT.QUEUE get cleaned up if I use this approach?
|
Not if there is already stuff sitting there.
The very last question.
The RESET commands purge info about QM2 and QM3 from QM1. And then when you issue REFRESH on QM1 (after declustering all its objects including QM1 itself), it will tag all its objects as not in CLUSX, so CLUSX is gone. But all those messages are still sitting in the Repository queue, tagged. If you trust IBM that this works (and you should), then this is fine.
However, if you screwed up the cluster by deleting QMs without declustering them, personally, I would do the method of clearing the repository queue on the last remaing QM and then bouncing the QM. This way, you are 100% sure there is no info anywhere about CLUSX, tagged as obsolete or not. It is not recomended or supported if you do this. But it works.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| shash |
| Posted: Mon Mar 14, 2005 10:43 am Post subject: |
|
|
Novice
Joined: 08 Dec 2004
Posts: 20
|
Thanks Peter for sharing your insight and having the patience to go through, probably, the longest issue in the history of message boards.
In the scenario that I mentioned, I had deleted QM2 and QM3 directly without actually declustering them first. In other words, I had not suspended the QMs and deleted the CLUSRCVR and CLUSSDR channels before deleting them, as recommended by IBM.
Since this is a test environment, I will blow up the repository using approach 1#.
However, I guess if it were a production environment, I would rather prefer approach 2#.
shash |
|
| 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
|
|
|
|
