If all these QMs are in 1 cluster, then all you need is 2 Full Repositories,
with manual CLUSSNDRS defined between them. Those extra Full Repositories
are just that, extra. No need for them, unless you put FR #1 and FR #2 on
servers that are both down frequently, but why would you do that?



-----Original Message-----
From: Tony Boggis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 21, 2004 3:15 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues


So in my cluster, I have 2 groups (each group is in a separate data
center) of 12 queue managers. Each group has 2 full repos's defined,
with channels defined across groups to ensure that the cluster works as
a whole.

If I understand correctly, does this mean that on Repos-A, I have to
define a CLUSSDR to Repos-B,C & D? Similarly on Repos-B, do I have to
define a CLUSSDR to Repos-A,C & D... and so on?

tonyB.

> -------- Original Message --------
> Subject: Re: Disappearing cluster queues
> From: "Wyatt, T Rob" <[EMAIL PROTECTED]>
> Date: Mon, September 20, 2004 6:49 pm
> To: [EMAIL PROTECTED]
>
> Tony,
>
> Information flows between repositories only on explicitly defined
channels.  Do all four of your repositories have explicitly defined CLUSSDRS
to each other?  When your queues go missing, do they go missing on the
partial repository only?  If they are in the full repositories, are they in
*ALL* of them?
>
> If there is a problem in the distribution of repository information, the
repositories get out of synch.  The partials will reflect whichever of the
full repositories they are talking to at the moment.  So if the repositories
get out of synch, the partials may change from time to time as they talk to
different fulls.
>
> From the manual:
>
http://publibfp.boulder.ibm.com/epubs/html/csqzah06/csqzah060u.htm#HDRCSQ684
1
> "The CLUSSDR definitions made on the full repository queue managers are
special. All the updates exchanged by the full repositories flow exclusively
on these channels. The administrator controls the network of full
repositories explicitly. The administrator must make the CLUSSDR definitions
on full repository queue managers manually and not leave them to be
auto-defined."
>
> So you should have explicitly defined CLUSSDR channels from each repos to
each other repos.  You should not need to create explicit defs to the leaf
nodes if the repositories are fully in synch.
>
> Hope that helps,
> -- T.Rob
>
>
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tony
> Boggis
> Sent: Monday, September 20, 2004 9:18 PM
> To: [EMAIL PROTECTED]
> Subject: Disappearing cluster queues
>
>
> Puzzling situation...
>
> Environment: Solaris, WMQ 5.3 CSD05.
>
> I have a cluster with about 24 queue managers each on it's own host. All
> are "sharing" one or more queues in the cluster, eaching being unique,
> giving 200+ queues.
>
> Periodically cluster queues "disappear" on some hosts, leaving me
> getting 2085 errors, even from amqsput. Manually refreshing the cluster
> (REFRESH CLUSTER) usually does the trick. Usually.
>
> All my CLUSSDR/CLUSRCVR channels are configured and none are
> Binding/Retrying, etc. I have 4 full-respository managers defined, all
> are up and running.
>
> This is not 60+ days or anything that would obviously point to cluster
> expiration.
>
> tonyB.
>
> 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

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

Reply via email to