Re: Disappearing cluster queues
Morag, I have a cluster of 5 QMs. 4 are FRs (FR1, FR2, FR3, FR4), each with
manually CLUSSNDRs to the other 3 FRs. QM #5 (PR1) is a partial. The cluster
is functioning normally and as expected. I wait long enough so that channel
status (*) on PR1 shows nothing; all the channels have gone past their
DISCINT.
I define (using MO71) a queue on PR1, and cluster it. Instantly, dis channel
status(*) on PR1 shows TO.FR1, TO.FR2, TO.FR3 and TO.FR4 starting up. If I
add another queue to PR1, the sequence numbers of all 4 Auto CLUSSNDRs go
up. If I REFRESH CLUSTER(CLUSTER1), all 4 channels' sequence numbers go up.
If I issue REFRESH CLUSTER(CLUSTER1) REPOS(YES), and keep refreshing the
channel status(*) on PR1, I see that TO.FR1 comes up first, and then the
other three.
I see what you are referring to in the docs. I just don't see the cluster
behaving that way. It seems that a PR always tells ALL the FRs that it knows
about any updates it needs.
5.3 CSD07 on Windows XP.
-Original Message-
From: Morag Hughson [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 23, 2004 5:38 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues
Each subscription made will only be made to two full repositories. That
doesn't mean every publication/subscription is made to only the same two
full repositories.
The choice of full repositories is made using the usual workload balancing
algorithm with a preference for manual defined cluster-senders. If a number
are equal choices, then the subscriptions will be round robin-ed.
A partial repository is told when it first connects to the cluster, what
the route to all full repositories are so that it can use it for the above
choice of subscriptions.
I attach a small pdf of the relevant pages from the Administering Clusters
presentation that gets given at the various conferences which is a very
good source of information about this.
(See attached file: S1133_Part.pdf)
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
23/09/2004 16:36
Please respond to
MQSeries List
Morag, the below testing contradicts your post that says a PR only talks to
2 FR directly. ???
I just issued a REFRESH CLUSTER(CLUSTER1) command from PR1, and the
channels to FR1, FR2 and FR3 all started up.
5.3 CSD04
Windows XP SP1
All testing done via MO71.
When I added FR4 to the FR ring after PR1 was introduced, PR1 did made an
Auto CLUSSNDR channels to FR4 immediately.
When I added PR2 to the cluster, it made Auto CLUSSNDR channels to all 4
FRs immediatly.
-Original Message-
From: Potkay, Peter M (ISD, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 22, 2004 11:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues
I did the following in the order listed:
Create queue manager FR1, FR2 and FR3
Define CLUSRCVRs on FR1 called TO.FR1, on FR2 called TO.FR2 and on
FR3 called TO.FR3, all with the CLUSTER attribute set to CLUSTER1
Alter each QM to be a Full Repository for CLUSTER1
Manually define CLUSSNDRs on each FR to both other FRs (on FR1 create
CLUSSNDRs TO.FR2 and TO.FR3, on FR2 create CLUSSNDRs TO.FR1 and
TO.FR3, on FR3 create CLUSSNDRs TO.FR1 and TO.FR1)
I have a ring of three FRs.
Now I create queue manager PR1, define a CLUSRCVR called TO.PR1
clustered to CLUSTER1, and then define one and only one CLUSSNDR to
FR1. Without doing anything else, PR1 immediately had Automatic
CLUSSNDRs to all 3 FRs.
Looks like a PR defines Auto CLUSSNDRs to every FR in the cluster.
I check the Sequence Numbers of the channels leaving PR1
TO.FR1=6
TO.FR2=5
TO.FR3=2
Now I create 1 local queue called PR1.LOCAL.QUEUE on PR1, and cluster
it to CLUSTER1. All 3 Auto CLUSSNDRs start running. Looking at the
sequence numbers again, I see:
TO.FR1=8
TO.FR2=6
TO.FR3=3
To me, this indicates that a partial repository QM in a cluster sends
its info directly to ALL full repositories in a cluster, regardless
of how many there are.
As for the question about overlapping clusters, I have 1 Gateway QM
that is a partial repository for four overlapping clusters. Each of
the clusters has only 2 other QMs, and those are the Full
Repositories for their respective clusters. If a create a queue on
Re: Disappearing cluster queues
Each subscription made will only be made to two full repositories. That
doesn't mean every publication/subscription is made to only the same two
full repositories.
The choice of full repositories is made using the usual workload balancing
algorithm with a preference for manual defined cluster-senders. If a number
are equal choices, then the subscriptions will be round robin-ed.
A partial repository is told when it first connects to the cluster, what
the route to all full repositories are so that it can use it for the above
choice of subscriptions.
I attach a small pdf of the relevant pages from the Administering Clusters
presentation that gets given at the various conferences which is a very
good source of information about this.
(See attached file: S1133_Part.pdf)
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
23/09/2004 16:36
Please respond to
MQSeries List
Morag, the below testing contradicts your post that says a PR only talks to
2 FR directly. ???
I just issued a REFRESH CLUSTER(CLUSTER1) command from PR1, and the
channels to FR1, FR2 and FR3 all started up.
5.3 CSD04
Windows XP SP1
All testing done via MO71.
When I added FR4 to the FR ring after PR1 was introduced, PR1 did made an
Auto CLUSSNDR channels to FR4 immediately.
When I added PR2 to the cluster, it made Auto CLUSSNDR channels to all 4
FRs immediatly.
-Original Message-
From: Potkay, Peter M (ISD, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 22, 2004 11:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues
I did the following in the order listed:
Create queue manager FR1, FR2 and FR3
Define CLUSRCVRs on FR1 called TO.FR1, on FR2 called TO.FR2 and on
FR3 called TO.FR3, all with the CLUSTER attribute set to CLUSTER1
Alter each QM to be a Full Repository for CLUSTER1
Manually define CLUSSNDRs on each FR to both other FRs (on FR1 create
CLUSSNDRs TO.FR2 and TO.FR3, on FR2 create CLUSSNDRs TO.FR1 and
TO.FR3, on FR3 create CLUSSNDRs TO.FR1 and TO.FR1)
I have a ring of three FRs.
Now I create queue manager PR1, define a CLUSRCVR called TO.PR1
clustered to CLUSTER1, and then define one and only one CLUSSNDR to
FR1. Without doing anything else, PR1 immediately had Automatic
CLUSSNDRs to all 3 FRs.
Looks like a PR defines Auto CLUSSNDRs to every FR in the cluster.
I check the Sequence Numbers of the channels leaving PR1
TO.FR1=6
TO.FR2=5
TO.FR3=2
Now I create 1 local queue called PR1.LOCAL.QUEUE on PR1, and cluster
it to CLUSTER1. All 3 Auto CLUSSNDRs start running. Looking at the
sequence numbers again, I see:
TO.FR1=8
TO.FR2=6
TO.FR3=3
To me, this indicates that a partial repository QM in a cluster sends
its info directly to ALL full repositories in a cluster, regardless
of how many there are.
As for the question about overlapping clusters, I have 1 Gateway QM
that is a partial repository for four overlapping clusters. Each of
the clusters has only 2 other QMs, and those are the Full
Repositories for their respective clusters. If a create a queue on
the Gateway QM, and cluster it to the Cluster Namelist, all 8 FRs
know about the new queue right away, and they get that info directly
from the Gateway QM.
-Original Message-
From: Wyatt, T Rob [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 22, 2004 4:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues
Peter,
FR#1 gets an update (or at least an attempt) every time. If I
remember correctly, the secondary FR is chosen using cluster
workload balancing - PUT-enabled cluster command queue, FR#_ is
not suspended, NETPRTY on the channels, etc. I know Jill
covered this in class but I can't remember for sure. If you
were to define two explicit CLUSSDRs to two FRs however, then
those two are always used.
What is not clear to me is what happens if you advertise a
queue in two different overlapping clusters with two distinct
full repositories each (4 FRs in 2 clusters). Does the partial
repository publish to two
Re: Disappearing cluster queues
Morag, the below testing contradicts your post that says a PR only talks to 2 FR directly. ??? I just issued a REFRESH CLUSTER(CLUSTER1) command from PR1, and the channels to FR1, FR2 and FR3 all started up. 5.3 CSD04 Windows XP SP1 All testing done via MO71. When I added FR4 to the FR ring after PR1 was introduced, PR1 did made an Auto CLUSSNDR channels to FR4 immediately. When I added PR2 to the cluster, it made Auto CLUSSNDR channels to all 4 FRs immediatly. -Original Message-From: Potkay, Peter M (ISD, IT) [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 22, 2004 11:57 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queues I did the following in the order listed: Create queue manager FR1, FR2 and FR3 Define CLUSRCVRs on FR1 called TO.FR1, on FR2 called TO.FR2 and on FR3 called TO.FR3, all with the CLUSTER attribute set to CLUSTER1 Alter each QM to be a Full Repository for CLUSTER1 Manually define CLUSSNDRs on each FR to both other FRs (on FR1 create CLUSSNDRs TO.FR2 and TO.FR3, on FR2 create CLUSSNDRs TO.FR1 and TO.FR3, on FR3 create CLUSSNDRs TO.FR1 and TO.FR1) I have a ring of three FRs. Now I create queue manager PR1, define a CLUSRCVR called TO.PR1 clustered to CLUSTER1, and then define one and only one CLUSSNDR to FR1. Without doing anything else, PR1 immediately had Automatic CLUSSNDRs to all 3 FRs. Looks like a PR defines Auto CLUSSNDRs to every FR in the cluster. I check the Sequence Numbers of the channels leaving PR1 TO.FR1=6 TO.FR2=5 TO.FR3=2 Now I create 1 local queue called PR1.LOCAL.QUEUE on PR1, and cluster it to CLUSTER1. All 3 Auto CLUSSNDRs start running. Looking at the sequence numbers again, I see: TO.FR1=8 TO.FR2=6 TO.FR3=3 To me, this indicates that a partial repository QM in a cluster sends its info directly to ALL full repositories in a cluster, regardless of how many there are. As for the question about overlapping clusters, I have 1 Gateway QM that is a partial repository for four overlapping clusters. Each of the clusters has only 2 other QMs, and those are the Full Repositories for their respective clusters. If a create a queue on the Gateway QM, and cluster it to the Cluster Namelist, all 8 FRs know about the new queue right away, and they get that info directly from the Gateway QM. -Original Message-From: Wyatt, T Rob [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 22, 2004 4:14 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queues Peter, FR#1 gets an update (or at least an attempt) every time. If I remember correctly, the secondary FR is chosen using cluster workload balancing - PUT-enabled cluster command queue, FR#_ is not suspended, NETPRTY on the channels, etc. I know Jill covered this in class but I can't remember for sure. If you were to define two explicit CLUSSDRs to two FRs however, then those two are always used. What is not clear to me is what happens if you advertise a queue in two different overlapping clusters with two distinct full repositories each (4 FRs in 2 clusters). Does the partial repository publish to two fulls *per cluster* or two fulls total? How would this be affected if the CLUSSDR CLUSNL attribute specified two clusters and the target QMgr was a repository for only one of them? I haven't found reference to this in any manual and it did not occur to me to ask while in cluster class. I would have to assume it is per cluster and MQ is smart enough to know which clusters the target QMgr is a full repository for. But I've been surprised before on stuff that seemed more obvious than this (AdoptNewMCA not supported on RQSTR channels comes to mind). Paul? Justin? Any help here? -- T.Rob -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Potkay, Peter M (ISD, IT)Sent: Wednesday, September 22, 2004 3:44 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queues 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 PMTo: [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 repo
Re: Disappearing cluster queues
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
Re: Disappearing cluster queues
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 qu
Re: Disappearing cluster queues
I did the following in the order listed: Create queue manager FR1, FR2 and FR3 Define CLUSRCVRs on FR1 called TO.FR1, on FR2 called TO.FR2 and on FR3 called TO.FR3, all with the CLUSTER attribute set to CLUSTER1 Alter each QM to be a Full Repository for CLUSTER1 Manually define CLUSSNDRs on each FR to both other FRs (on FR1 create CLUSSNDRs TO.FR2 and TO.FR3, on FR2 create CLUSSNDRs TO.FR1 and TO.FR3, on FR3 create CLUSSNDRs TO.FR1 and TO.FR1) I have a ring of three FRs. Now I create queue manager PR1, define a CLUSRCVR called TO.PR1 clustered to CLUSTER1, and then define one and only one CLUSSNDR to FR1. Without doing anything else, PR1 immediately had Automatic CLUSSNDRs to all 3 FRs. Looks like a PR defines Auto CLUSSNDRs to every FR in the cluster. I check the Sequence Numbers of the channels leaving PR1 TO.FR1=6 TO.FR2=5 TO.FR3=2 Now I create 1 local queue called PR1.LOCAL.QUEUE on PR1, and cluster it to CLUSTER1. All 3 Auto CLUSSNDRs start running. Looking at the sequence numbers again, I see: TO.FR1=8 TO.FR2=6 TO.FR3=3 To me, this indicates that a partial repository QM in a cluster sends its info directly to ALL full repositories in a cluster, regardless of how many there are. As for the question about overlapping clusters, I have 1 Gateway QM that is a partial repository for four overlapping clusters. Each of the clusters has only 2 other QMs, and those are the Full Repositories for their respective clusters. If a create a queue on the Gateway QM, and cluster it to the Cluster Namelist, all 8 FRs know about the new queue right away, and they get that info directly from the Gateway QM. -Original Message-From: Wyatt, T Rob [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 22, 2004 4:14 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queues Peter, FR#1 gets an update (or at least an attempt) every time. If I remember correctly, the secondary FR is chosen using cluster workload balancing - PUT-enabled cluster command queue, FR#_ is not suspended, NETPRTY on the channels, etc. I know Jill covered this in class but I can't remember for sure. If you were to define two explicit CLUSSDRs to two FRs however, then those two are always used. What is not clear to me is what happens if you advertise a queue in two different overlapping clusters with two distinct full repositories each (4 FRs in 2 clusters). Does the partial repository publish to two fulls *per cluster* or two fulls total? How would this be affected if the CLUSSDR CLUSNL attribute specified two clusters and the target QMgr was a repository for only one of them? I haven't found reference to this in any manual and it did not occur to me to ask while in cluster class. I would have to assume it is per cluster and MQ is smart enough to know which clusters the target QMgr is a full repository for. But I've been surprised before on stuff that seemed more obvious than this (AdoptNewMCA not supported on RQSTR channels comes to mind). Paul? Justin? Any help here? -- T.Rob -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Potkay, Peter M (ISD, IT)Sent: Wednesday, September 22, 2004 3:44 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queues 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 PMTo: [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 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.
Re: Disappearing cluster queues
Peter, FR#1 gets an update (or at least an attempt) every time. If I remember correctly, the secondary FR is chosen using cluster workload balancing - PUT-enabled cluster command queue, FR#_ is not suspended, NETPRTY on the channels, etc. I know Jill covered this in class but I can't remember for sure. If you were to define two explicit CLUSSDRs to two FRs however, then those two are always used. What is not clear to me is what happens if you advertise a queue in two different overlapping clusters with two distinct full repositories each (4 FRs in 2 clusters). Does the partial repository publish to two fulls *per cluster* or two fulls total? How would this be affected if the CLUSSDR CLUSNL attribute specified two clusters and the target QMgr was a repository for only one of them? I haven't found reference to this in any manual and it did not occur to me to ask while in cluster class. I would have to assume it is per cluster and MQ is smart enough to know which clusters the target QMgr is a full repository for. But I've been surprised before on stuff that seemed more obvious than this (AdoptNewMCA not supported on RQSTR channels comes to mind). Paul? Justin? Any help here? -- T.Rob -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Potkay, Peter M (ISD, IT)Sent: Wednesday, September 22, 2004 3:44 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queues 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 PMTo: [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
Re: Disappearing cluster queues
T. Rob, I failed to mention that important point. The Cluster manual addresses that issue, as well: Because all cluster information is sent to two full repositories, there might be situations in which you want to make a second CLUSSDR channel definition. You might do this in a cluster that has a large number of full repositories, spread over a wide area, to control which full repositories your information is sent to. Thanks for the clarification. :-) Mike Davidson TSYS MQ Tech Support IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 [EMAIL PROTECTED] "Wyatt, T Rob" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/22/2004 03:20 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: 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]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
Re: Disappearing cluster queues
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 PMTo: [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]On Behalf Of Potkay, Peter M (ISD, IT)Sent: Wednesday, September 22, 2004 2:27 PMTo: [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 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queuesI 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 DavidsonTSYS MQ Tech SupportIBM Certified System Administrator - WebSphere MQ V5.3IBM 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 queuesMike,You said:>out of the box MQ will only publish and subscribe cluster objectinformation to 2 Full
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]On Behalf Of Potkay, Peter M (ISD, IT)Sent: Wednesday, September 22, 2004 2:27 PMTo: [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 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queuesI 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 DavidsonTSYS MQ Tech SupportIBM Certified System Administrator - WebSphere MQ V5.3IBM 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 queuesMike,You said:>out of the box MQ will only publish and subscribe cluster objectinformation to 2 Full Repositoriescan you point to where this is documented please.ThanksDaveInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: 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
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 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queuesI 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 DavidsonTSYS MQ Tech SupportIBM Certified System Administrator - WebSphere MQ V5.3IBM 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 queuesMike,You said:>out of the box MQ will only publish and subscribe cluster objectinformation to 2 Full Repositoriescan you point to where this is documented please.ThanksDaveInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: 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.
Re: Disappearing cluster queues
Mike, It is the *Partial* repositories that publish to only two other nodes. The Full repositories will publish to all repositories they know about and that have explicit CLUSSDR channels defined. This is the basis for IBM's recommendation to explicitly define CLUSSDRs between ALL full repositories in the cluster. From the manual at: http://publibfp.boulder.ibm.com/epubs/html/csqzah06/csqzah0617.htm#HDRCSQ6849 "The full repositories republish the publications they receive through the manually-defined CLUSSDR channels, which must point to other full repositories in the cluster. You must make sure that a publication received by any full repository ultimately reaches all the other full repositories. You do this by manually defining CLUSSDR channels between the full repositories. The more interconnection of full repositories you have, the more robust the cluster." -- T.Rob -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Mike DavidsonSent: Wednesday, September 22, 2004 9:27 AMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queuesOne important point that should be made concerning the decision to go with more than 2 Full Repositories is that - out of the box MQ will only publish and subscribe cluster object information to 2 Full Repositories. Any more than 2 will require manual intervention to update the extras of any changes/additions/deletions that are taking place within the cluster.Mike DavidsonTSYS MQ Tech SupportIBM Certified System Administrator - WebSphere MQ V5.3IBM Certified Solution Designer - WebSphere MQ V5.3[EMAIL PROTECTED] "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/21/2004 04:12 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Disappearing cluster queuesIf all these QMs are in 1 cluster, then all you need is 2 Full Repositories,with manual CLUSSNDRS defined between them. Those extra Full Repositoriesare just that, extra. No need for them, unless you put FR #1 and FR #2 onservers 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 PMTo: [EMAIL PROTECTED]Subject: Re: Disappearing cluster queuesSo in my cluster, I have 2 groups (each group is in a separate datacenter) of 12 queue managers. Each group has 2 full repos's defined,with channels defined across groups to ensure that the cluster works asa whole.If I understand correctly, does this mean that on Repos-A, I have todefine a CLUSSDR to Repos-B,C & D? Similarly on Repos-B, do I have todefine 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 definedchannels. Do all four of your repositories have explicitly defined CLUSSDRSto each other? When your queues go missing, do they go missing on thepartial 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, therepositories get out of synch. The partials will reflect whichever of thefull repositories they are talking to at the moment. So if the repositoriesget out of synch, the partials may change from time to time as they talk todifferent fulls.>> From the manual:>http://publibfp.boulder.ibm.com/epubs/html/csqzah06/csqzah060u.htm#HDRCSQ6841> "The CLUSSDR definitions made on the full repository queue managers arespecial. All the updates exchanged by the full repositories flow exclusivelyon these channels. The administrator controls the network of fullrepositories explicitly. The administrator must make the CLUSSDR definitionson full repository queue managers manually and not leave them to beauto-defined.">> So you should have explicitly defined CLUSSDR channels from each repos toeach other repos. You should not need to create explicit defs to the leafnodes 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
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
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
Re: Disappearing cluster queues
One important point that should be made concerning the decision to go with more than 2 Full Repositories is that - out of the box MQ will only publish and subscribe cluster object information to 2 Full Repositories. Any more than 2 will require manual intervention to update the extras of any changes/additions/deletions that are taking place within the cluster. Mike Davidson TSYS MQ Tech Support IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 [EMAIL PROTECTED] "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/21/2004 04:12 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Disappearing cluster queues 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
Re: Disappearing cluster queues
The manuals only say to create the channels manually FROM the partial TO only ONE of the fulls. No other channels need to be manually defined in a properly working cluster. -Original Message- From: Scott Gray [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Refer to T Robs note that quotes the manuals as saying this is a requirement. I wouldn't think it would have to work this way, but that is what the manual says and is backed up by our experience. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Tuesday, September 21, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. > Original Message ---- > Subject: Re: Disappearing cluster queues > From: "Scott Gray" <[EMAIL PROTECTED]> > Date: Mon, September 20, 2004 6:28 pm > To: [EMAIL PROTECTED] > > We had that problem between sun/hp and z/os...we were told to have at > least one static cluster sender between full repository and leaf node. > We were relying on dynamic clussdrs from full repos to leaf node. Once > we did this, that problem has not reoccured. No explanation for the > behavior was provided by IBM. > > Good luck. > > Scott > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On 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 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 Ins
Re: Disappearing cluster queues
Tony, In a word - yes. As Peter points out, it is unusual to have more than 2 full repositories but if you are going to do that, they ALL need to talk to one another. The best way to do that is by defining any-to-any connections between them. You get some redundant traffic but if one repos is down, the others stay up to date. You can also make it work with a ring or bridge topology but then some repositories act as gateways to the others and you have a greater chance of getting out of synch. The important thing is that you can get from any repository to any other repository along explicitly defined CLUSSDR channels. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tony Boggis 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#HDRCSQ6841 > "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 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
Re: Disappearing cluster queues
I agree that in one sense having 4 full repos's is unecesary, the reason for the redundancy is that each group needs to be able to operate in the event of the loss of the other group (loss of a data center for instance). This way each group always has two full repos's available. tonyB. > Original Message > Subject: Re: Disappearing cluster queues > From: "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> > Date: Tue, September 21, 2004 1:12 pm > To: [EMAIL PROTECTED] > > 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 &
Re: Disappearing cluster queues
Yes, and in fact looking back at my notes the QMs in question were in fact all full repositories rather than partials. Sorry for the confusion. This is what I get for drinking all that cough medicine on my way to work. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T Rob Sent: Tuesday, September 21, 2004 1:15 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Scott, The quote and link I provided apply specifically to *full* repositories. The idea behind that was for Tony to make absolutely sure the full repositories were in synch before trying to diagnose the partials. If the full repositories are not synchronized, there is no basis to think the partials will be. Assuming Tony gets past that part and still has a problem, then he can try the explicit channels or issue refreshes. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Scott Gray Sent: Tuesday, September 21, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Refer to T Robs note that quotes the manuals as saying this is a requirement. I wouldn't think it would have to work this way, but that is what the manual says and is backed up by our experience. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Tuesday, September 21, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott 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
Re: Disappearing cluster queues
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
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#HDRCSQ6841 > "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
Re: Disappearing cluster queues
Scott, The quote and link I provided apply specifically to *full* repositories. The idea behind that was for Tony to make absolutely sure the full repositories were in synch before trying to diagnose the partials. If the full repositories are not synchronized, there is no basis to think the partials will be. Assuming Tony gets past that part and still has a problem, then he can try the explicit channels or issue refreshes. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Scott Gray Sent: Tuesday, September 21, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Refer to T Robs note that quotes the manuals as saying this is a requirement. I wouldn't think it would have to work this way, but that is what the manual says and is backed up by our experience. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Tuesday, September 21, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott 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
Re: Disappearing cluster queues
My experience is that you *need* to have explicitly defined cluster sender and receiver channels between all the FULL repositories, and that if you don't you will run into this sort of problem. You shouldn't need to explicitly define clussdr channels from the full repositories to the other cluster members. 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
Re: Disappearing cluster queues
The interpretation of that one paragraph is disputed by the QUEUE MANAGER CLUSTERS manual in chapter 3 where the setup of a cluster is explained in detail. After defining a Receiver channel you define the Sender channel to one of the full repository queue managers. The idea of defining sender channels for all repositories full and partial is never discussed as you would no longer have a cluster but a distributed system. Also in that manual in the troubleshooting section the solution given for the several cluster problems is the Refresh Cluster command. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Tuesday, September 21, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Refer to T Robs note that quotes the manuals as saying this is a requirement. I wouldn't think it would have to work this way, but that is what the manual says and is backed up by our experience. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Tuesday, September 21, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. > Original Message ---- > Subject: Re: Disappearing cluster queues > From: "Scott Gray" <[EMAIL PROTECTED]> > Date: Mon, September 20, 2004 6:28 pm > To: [EMAIL PROTECTED] > > We had that problem between sun/hp and z/os...we were told to have at > least one static cluster sender between full repository and leaf node. > We were relying on dynamic clussdrs from full repos to leaf node. Once > we did this, that problem has not reoccured. No explanation for the > behavior was provided by IBM. > > Good luck. > > Scott > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On 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:/
Re: Disappearing cluster queues
Refer to T Robs note that quotes the manuals as saying this is a requirement. I wouldn't think it would have to work this way, but that is what the manual says and is backed up by our experience. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Tuesday, September 21, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. > Original Message ---- > Subject: Re: Disappearing cluster queues > From: "Scott Gray" <[EMAIL PROTECTED]> > Date: Mon, September 20, 2004 6:28 pm > To: [EMAIL PROTECTED] > > We had that problem between sun/hp and z/os...we were told to have at > least one static cluster sender between full repository and leaf node. > We were relying on dynamic clussdrs from full repos to leaf node. Once > we did this, that problem has not reoccured. No explanation for the > behavior was provided by IBM. > > Good luck. > > Scott > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On 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 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
Re: Disappearing cluster queues
Alan, having to issue a REFRESH command at every QM startup is a bit hokey as well. ;-) Seems like you have an unresolved problem too that you are getting around with a band-aid solution. -Original Message- From: Bender, Alan [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 9:09 AM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. > Original Message > Subject: Re: Disappearing cluster queues > From: "Scott Gray" <[EMAIL PROTECTED]> > Date: Mon, September 20, 2004 6:28 pm > To: [EMAIL PROTECTED] > > We had that problem between sun/hp and z/os...we were told to have at > least one static cluster sender between full repository and leaf node. > We were relying on dynamic clussdrs from full repos to leaf node. > Once we did this, that problem has not reoccured. No explanation for > the behavior was provided by IBM. > > Good luck. > > Scott > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On 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 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, disclos
Re: Disappearing cluster queues
Excuse me but if you are defining sender channels for each QM then you no longer have a true cluster but rather a distributed system and you are back to all of the admin headaches of a distributed system. I have no solution to offer but I'm sure someone at IBM has seen this and does either have a fix or a work around that doesn't include going back to a distributed system. We have had this problem with our iSeries / Windows cluster. Every time the iSeries is IPL'd we have to issue the refresh command or we begin to get the dreaded 2085 return code. Maybe it is as simple as including the refresh in a command string at startup. I don't know, just a thought. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Gray Sent: Monday, September 20, 2004 8:53 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. > Original Message > Subject: Re: Disappearing cluster queues > From: "Scott Gray" <[EMAIL PROTECTED]> > Date: Mon, September 20, 2004 6:28 pm > To: [EMAIL PROTECTED] > > We had that problem between sun/hp and z/os...we were told to have at > least one static cluster sender between full repository and leaf node. > We were relying on dynamic clussdrs from full repos to leaf node. > Once we did this, that problem has not reoccured. No explanation for > the behavior was provided by IBM. > > Good luck. > > Scott > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On 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 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
Re: Disappearing cluster queues
We were losing the defs on the partial repository qms. The solution for us was to define a static clussdr from a full repos to each partial repos. We had defined the cluster relying on dynamic clussdr channels from the full repos qms to the partial repos qms. That is, we had defined static clussdrs from partial to full, but allowed MQ to auto define the clussdr from full to partial based. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tony Boggis Sent: Monday, September 20, 2004 9:40 PM To: [EMAIL PROTECTED] Subject: Re: Disappearing cluster queues I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. > Original Message > Subject: Re: Disappearing cluster queues > From: "Scott Gray" <[EMAIL PROTECTED]> > Date: Mon, September 20, 2004 6:28 pm > To: [EMAIL PROTECTED] > > We had that problem between sun/hp and z/os...we were told to have at > least one static cluster sender between full repository and leaf node. > We were relying on dynamic clussdrs from full repos to leaf node. > Once we did this, that problem has not reoccured. No explanation for > the behavior was provided by IBM. > > Good luck. > > Scott > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On 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 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
Re: Disappearing cluster queues
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#HDRCSQ6841 "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
Re: Disappearing cluster queues
I'm not sure I follow... Are you saying that on each FULL-REPOS, have an additional CLUSSDR channel? So that would mean that each full repository holder having one CLUSSDR channel to another full repos and a second CLUSSDR to a partial repos (cluster member) queue manager? tonyB. > Original Message > Subject: Re: Disappearing cluster queues > From: "Scott Gray" <[EMAIL PROTECTED]> > Date: Mon, September 20, 2004 6:28 pm > To: [EMAIL PROTECTED] > > We had that problem between sun/hp and z/os...we were told to have at > least one static cluster sender between full repository and leaf node. > We were relying on dynamic clussdrs from full repos to leaf node. Once > we did this, that problem has not reoccured. No explanation for the > behavior was provided by IBM. > > Good luck. > > Scott > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On 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
Re: Disappearing cluster queues
We had that problem between sun/hp and z/os...we were told to have at least one static cluster sender between full repository and leaf node. We were relying on dynamic clussdrs from full repos to leaf node. Once we did this, that problem has not reoccured. No explanation for the behavior was provided by IBM. Good luck. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On 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
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
