The mainframe procs do NO have any reference whatsoever to the old repositories. And I did "un"cluster things first before I removed/deleted them...
Any other ideas, please??? Thanks, Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > 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 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
