Morag, Owing the following reason that cluster exit can choose repository it like, when we define cluster queue (from a member QM in the cluster), we may not see the cluster queue defined immediately. Is it true? Can REFRESH CLUSTER or other means help to make the cluster queue effective immediately. In some case, we found that we may need to put some test message into the new cluster queue to make it effective. However, this approach is not feasible in a production environment.
K K --- Morag Hughson <[EMAIL PROTECTED]> $:.e!G > A partial repository will publish information (about > it's queues and > channels) to two full repositories. > A partial repository will subscribe for information > (e.g. "who hosts the > queue called FRED") from two full repositories. > > The two full repositories used for each subscription > will not necessarily > be the same two if you have more than two full > repositories available. > > The choice of which full repository used will be, by > preference, any that > have a manual cluster-sender definition to them and > then the standard > workload balancing applies to choose between equal > choices. So you can > control which two full repositories any particular > partial uses by defining > two manual cluster-sender channels. > > If you have more than two full repositories, you > still should not take more > than one off-line at a time, since you could take > the only two full > repositories that one particular partial is using > off-line and therefore > that particular partial repository would not receive > any updates. If you > have a need to take more than one full repository > off-line at the same time > and your have numerous full repositories, you are > advised to alter them to > be partial repositories first, which forces the > partial repositories using > them to remake subscriptions with another full > repository, thus ensuring > the continued receipt of updates to the resources > they are interested in. > > Cheers > Morag > > Morag Hughson > WebSphere MQ for z/OS Development > Telephone: +44 (0) 1962 816900 > Internet: [EMAIL PROTECTED] > > > > > "Potkay, Peter M > (ISD, IT)" > <[EMAIL PROTECTED] > To > HARTFORD.COM> > [EMAIL PROTECTED] > Sent by: MQSeries > cc > List > <[EMAIL PROTECTED] > Subject > N.AC.AT> Re: > Disappearing cluster queues > > > 22/09/2004 20:44 > > > Please respond to > MQSeries List > > > > > > > So given FR#1 and FR#2 and FR#3 and FR#4, which FRs > get the updates > (directly) from PR#1 if PR#1 has a manually defined > CLUSSNDR to FR#1, which > is all PR#1 needs? > > Is it random? How does PR#1 decide what other FR it > should send its info > to? > > > > -----Original Message----- > From: Wyatt, T Rob > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 22, 2004 3:21 PM > To: [EMAIL PROTECTED] > Subject: Re: Disappearing cluster queues > > Peter, > > The full repositories publish to as many other > full repositories as > they have explicit CLUSSDR definitions for but > a partial publishes to > only two full repositories no matter how many > you have. Once the > full repository receives information from a > partial, it then > republishes to all the other full > repositories. > > So the assertion that the partials only > publish to two fulls is > correct. So is the notion that you can have > more than two full > repositories and they are all in synch - > assuming you have properly > defined CLUSSDR channels between all the > repositories. > > -- T.Rob > -----Original Message----- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf > Of Potkay, Peter M (ISD, IT) > Sent: Wednesday, September 22, 2004 2:27 > PM > To: [EMAIL PROTECTED] > Subject: Re: Disappearing cluster queues > > Hmmm, I think all these statements were > written with the > assumption that you followed IBM's > recommendation that you use > only 2 FRs. But I can certainly see why > someone would think the > info only goes to 2 FRs. > > I think it would go to all FRs if you > had more than 2 because > IBM's manuals also state you can have > more than 2 FRs, and so > do the Conference sessions, and nowhere > in them does it say if > you have 3 or more FRs, that only 2 > would have the info. If FR > #3 didn't have all the info, then it > wouldn't be a FR. > > I think you when you define the manual > CLUSSNDR to one of your > FRs, that FR sends back info to the new > QM telling it how to > make Automatic CLUSSNDRs to itself, as > well as info on how to > make Automatic CLUSSNDRs to every other > FR it know about, > whether it is just FR #2, or FR #2, #3 > and #4. But the > assumption is that all the FR know about > each other, and the > only way that can happen is if there is > some route between all > of them via manual CLUSSNDRs, be it > AnyToAny or a Ring > connection. > > > Not 100% sure though.... > > -----Original Message----- > From: Mike Davidson > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 22, > 2004 12:58 PM > To: [EMAIL PROTECTED] > Subject: Re: Disappearing cluster > queues > > > I pulled it straight from the MQ > conference this year. > Ian Vanstone (from IBM Hursley) > mentioned this in one of > his session on "Administering WMQ > Qmgr Clusters". > > I also found these 3 statements in > the Cluster manual: > > Every queue manager in a cluster > must refer to one or > other of the full repositories > in order to gather information > about the cluster and so > build up its own partial > repository. Choose either of the > repositories, because as > soon as a new queue > manager is added to the cluster it > immediately learns > about the other repository as > === message truncated === _________________________________________________________ %21~'^!B6<:q!B$p,P,P... v:)9aAn 1!$_3sC4 http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/ 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
