I seem to recall that this message was added around MQ 7.1/7.5. The logic
wasn't changed, even prior to that the new queue manager would still push
out the older queue manager. It just did it silently - hence adding the
message! As the message suggests, the scenario where this behaviour is
expected to come into play is when replacing a failed queue manager with a
replacement of the same name/channel name. Whether this is good practice
or not is to be seem.
As Tim has suggested, continuing to maintain the existing behaviour is
probably necessary due to the many varied ways people use MQ and clusters.
For example, simply deleting and recreating a queue manager in a cluster
without first removing the old one from the cluster relies on this
behaviour for the new version to be accepted into the cluster by the FRs.
However, we always have options, so if you and others are keen for the
counter behaviour to be possible, raising an RFE would probably be
worthwhile.
Thanks
David
From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 20/10/2014 15:08
Subject: Re: Why do Full Repositories accept a second QM by the
same name
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
What is ?PR Duplication?? When would it ever be acceptable to have 2 PRs
by the same name in the cluster?
When the second PR by the same name is attempting to join, its either on
purpose (original gone, new rebuilt one coming in) or something you want
to avoid (by mistake or maliciously someone recreated a second copy of the
PR that is now trying to join). In either case, wouldn?t you want the FR
to say ?Whoa, looks what?s going on here?get rid of the old one first and
then we can talk?.
But check out what one of my team mates referred me to in the 7.5
Knowledge Center:
?AMQ9468
Cluster receiver channel <insert_3> has been configured by multiple queue
managers.
Severity
0 : Informational
Explanation
Queue manager <insert_4> has joined a cluster using a cluster receiver
channel with the same name as one that has already been defined by queue
manager <insert_5> . All cluster receiver channels used within a cluster
must be uniquely named. Only the last queue manager to join the cluster
will use the named channel, Queue manager <insert_5> will not successfully
participate in the cluster while the newer queue manager is a member.
Response
The use of a channel name currently associated with a different queue
manager in the cluster may be intentional, for example, the original queue
manager may have been deleted and re-created as a new queue manager.
However, accidental duplication of a channel name across multiple queue
managers will also result in this behaviour. If this was not intended,
further investigation into the configuration of the queue managers should
be performed.
?
Yikes! That?s new I think. So on the one hand that?s good if you are
intentionally adding in a new copy of the old PR. But I think it also
means if a rogue QM can maliciously insert itself into your cluster, it
can take over the workload from the legitimate PR and the FR allows that
to happen by design.
I dunno, I just think the FRs should be less willing to accept a duplicate
PR.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Tim Zielke
Sent: Monday, October 20, 2014 9:33 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Why do Full Repositories accept a second QM by the same name
It might be difficult for IBM to do this cluster enhancement, as it could
break customer?s existing clusters that currently have a PR duplication.
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Coombs, Lawrence
Sent: Monday, October 20, 2014 8:14 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Why do Full Repositories accept a second QM by the same name
I would say no. If the FRs know BOTH the QMID and queue manager name, then
this should be a simple enough enhancement for IBM.
RFE anyone?
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Sunday, October 19, 2014 10:29 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Why do Full Repositories accept a second QM by the same name
So we all know your cluster?s going to be less than perfect if you add a
second QM by the same name into the cluster. Or if you delete and recreate
a Partial Repository and then add the new one into the cluster, again
things are going to be messy.
Clearly the FRs know this is a duplicate because they will show you both
by QMID when you do a display cluster queue manager list. And they let you
selectively eject one of the duplicates.
So if the FRs can identify duplicates, why do they even accept the second
one? I have never seen anything in MQ Clustering where having 2 QMs by the
same name would be anything less than problematic , so why don?t the FRs
just reject the attempt by the second QM automatically, sending back some
sort of message to the new PR attempting to join that would cause the new
PR to log a rather explicit message along the lines of ?Hey, you are about
to make a mess of things here. If you really want to add THIS queue
manager to the cluster, first remove the old one by the same name.?
Is there any legitimate reason for a FR to accept a duplicate PR?
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/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 e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/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 e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html