Re: Disappearing cluster queues

[Wyatt, T Rob]

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]On 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
well. Information about changes to a queue manager is sent directly to two
repositories.
================================================================================
When a queue manager sends out information about itself or requests information
about another queue manager, the information or request is sent to two full
repositories.
================================================================================
Having selected the queue managers to hold full repositories, you need to decide
which queue managers should link to which full repository. The CLUSSDR channel
definition links a queue manager to a full repository from which it finds out about
the other full repositories in the cluster. From then on, the queue manager sends
messages to any two full repositories, but it always tries to use the one to which it
has a CLUSSDR channel definition first.

I hope this helps.

Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]

"David C. Partridge" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/22/2004 10:50 AM Please respond to MQSeries List

To:        [EMAIL PROTECTED]         cc:                 Subject:        Re: Disappearing cluster queues

Mike,

You said:

>out of the box MQ will only publish and subscribe cluster object
information to 2 Full Repositories

can you point to where this is documented please.

Thanks
Dave

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

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.