Peter - Correct, I issued the RESET command on the qmgr's that were being removed from the cluster. I've never had a scenario where the qmgr's (in this case QM1 and QM2) were already deleted from the box altogether.
Ruzi - As strange as it sounds, try recreating QM1 and QM2 and just run the ALTER QMGR REPOS(****) command. Then run the RESET CLUSTER(****) QMNAME(QM1/QM2) ACTION(FORCEREMOVE) QUEUES(YES/NO) command. Then run ALTER QMGR REPOS(' '). Then see what DIS CLUSQMGR on the mainframe returns. And, finally, delete QM1 and QM2 if no longer needed.
(Essentially, you'd be introducing QM1 and QM2 back into the cluster as full repositories, running the RESET command to try and rid yourself of the auto-defined chl's, and backing the qmgr's out of the cluster.)
Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]
706.644.9501
| "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]> 08/25/2003 10:05 AM Please respond to MQSeries List
|
To: [EMAIL PROTECTED] cc: Subject: Re: Urgent help: Unexpected behavior in the Cluster!!! |
So you would issue this command from the QM where other QMS are still trying to send stuff to. In Ruzi's case, the old QM1 and QM2 queue managers, right? This would tell all other QMs in the cluster to delete any automatic CLUSSNDRs to QM1 or QM2?
What do you do in the case where perhaps QM1 and QM2 were already deleted? Is there any official way in this case? Perhaps issuing "REFRESH CLUSTER REPOS(YES)" on the QM that had the bad automatic CLUSSNDRs would flush them out? In Ruzi's case, the mainframe QM? (Sorry Ruzi, from your original post it was not clear if you issued this command on the mainframe or not).
-----Original Message-----
From: Mike Davidson [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 9:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Urgent help: Unexpected behavior in the Cluster!!!
I found in my testing that using the RESET command got rid of the automatically-defined channels from the DIS CLUSCHL(*) command. I tried it after reading the "Queue Manager Clusters" manual and, believe it or not, it worked. Here's an excerpt (p. 68):
"You might use the RESET CLUSTER command if, for example, a queue manager has been deleted but still has cluster-receiver channels defined to the cluster. Instead of waiting for WebSphere MQ to remove these definitions (which it does automatically) you can issue the RESET CLUSTER command to tidy up sooner. All other queue managers in the cluster are then informed that the queue manager is no longer available."
I hope this helps.
Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]
| "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 08/25/2003 08:55 AM Please respond to MQSeries List | To: [EMAIL PROTECTED] cc: Subject: Re: Urgent help: Unexpected behavior in the Cluster!!! |
I would bet that the mainframe queue manager still has some automatic
CLUSSNDRs leftover from when they were pointing to QM1 and QM2. just
stopping / deleting / or modifying the manually defined ones does not do
anything to the automatic ones.
They will even continue to retry even now, hoping that the listener on QM!/@
comes back.
I know of no graceful way of eliminating Automatic CLUSSNDRs. :-( My
biggest pet peeve with clustering. The only way I know how to do it is to
completely blow away the repositories in the cluster (partial and full).
Maybe someone knows a better way???
The one thing I have learned in the past couple of weeks with clustering is
never ever just delete something. You always have to un cluster it first
(queues, channels), and then delete.
-----Original Message-----
From: Ruzi R [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 8:39 AM
To: [EMAIL PROTECTED]
Subject: Urgent help: Unexpected behavior in the Cluster!!!
Hi all,
The QM1 and QM2 (on W2K, MQ 5.3) were full
repositories for our cluster. I have just replaced
them (full repositories) with QMA and QMB-- removing
QM1 and QM2 from the cluster. I have done this
following the instructions given in the MQ Cluster
manual. I have done the clean-up of the obsolete
channels etc. (e.g. TO.QM1 and TO.QM2). In other
words, no cluster member has any CLUSSDR channel
pointing to the old repositiories. The old
repositories have their cluster channels deleted.
Have done REFRESH CLUSTER REPOS(YES/NO) as per the
instructions in the manual.
As we don t need QM1 and MQ2 any longer, I did endmqm
on QM1 and QM2. Stopped the listener on both. Did some
testing; everything seemd OK in the cluster.
Then I had to move on to something else
MQ2T (on OS/390 MQ 5.3) is a member in the cluster. I
had modified the procs for MQ2T to pick up the new
connames (for QMA and QMB). As part of testing, my
colleague stopped MQ2T and re-started. Apparently, on
the re-start, the event logs on the old full
repositories got flooded with messages indicating MQ2T
was trying to connect to them (at least that is what
he says.. I haven t seen the errors myself. He cleaned
up the log and saved the data somewhere but I don t
know where yet). Why would this happen as there is
nothing in the start-up procc pointing to QM1 or MQ2?
I have to find an answer to this as we have another
cluster whose full repsoitories will have to be
replaced today. He said that, as soon as he stopped
the listener on these qmgrs the errors stopped. It
just so happens that we don t need QM1 and QM2 any
longer, so I will delete them. My question is,
suppose that QM1 and QM2 were to stay as independent
queue managers (not as a cluster member) with their
listeners running obviously, how would I prevent their
logs from getting filled with messages from cluster
queue managers trying to connect?
My thinking is, because the new full repositories
will keep the info related to the old repositories for
90 days during which time, any member qmgr
re-starting will cause this kind of error???
I would very much appreciate your input on the above
unexpected behavior the cluster.
Thanks,
Ruzi
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
