Discussion:
Why do Full Repositories accept a second QM by the same name
Potkay, Peter M (CTO Architecture + Engineering)
2014-10-19 15:28:34 UTC
Permalink
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.
************************************************************

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
Coombs, Lawrence
2014-10-20 13:14:29 UTC
Permalink
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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.

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
Tim Zielke
2014-10-20 13:32:40 UTC
Permalink
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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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
Potkay, Peter M (CTO Architecture + Engineering)
2014-10-20 14:07:44 UTC
Permalink
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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
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.
************************************************************

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
Tim Zielke
2014-10-20 14:18:59 UTC
Permalink
By PR duplication, I just meant having two PRs with the same name, like you are trying to prevent with this RFE. I am not saying this would be a good idea to have a duplicate PR in your cluster. But if clustering is currently allowing it and some customers have intentionally or unwittingly allowed it, it is sometimes hard then to add an enhancement to prevent it, as it could break existing configurations.

Kind of like when you find a bug in a function that is currently being used, and you can not guarantee that the other callers are now relying on this "bug" for their functionality to work. Usually, the better approach is to leave the "buggy" function in place, and write a new one that corrects it.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Monday, October 20, 2014 9:08 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Why do Full Repositories accept a second QM by the same name

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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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
David Ware
2014-10-20 16:02:06 UTC
Permalink
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

Barton, Linda
2014-10-20 13:46:12 UTC
Permalink
I have not had issues deleting qmgrs and recreating them as long as I first remove the original qmgr queues from the cluster, then the qmgr from the cluster (with REPOS(NO)).
The once I recreate the qmgr, I add it to the cluster and add the queues back to the cluster.
We have had to do that when we changed the LogFilePages.


Linda Barton



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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
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<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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
Loading...