| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CLUSNL Question |
« View previous topic :: View next topic » |
| Author |
Message
|
| TonyD |
 Posted: Wed Dec 17, 2008 4:21 pm Post subject: CLUSNL Question |
 |
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
I have a queue manager QM01 that is a PR in three different clusters, say CL01, CL02, CL03. I therefore defined a namelist CLNL with entries CL01, CL02, CL03 and defined the cluster receiver channel TO.QM01 with 'clusnl(CLNL)'.
This appeared to be OK. I then defined a cluster queue CQ01 on the two FR queue managers for CL01. In the MQExplorer I can see these two queues as cluster queues under QM01 and I can successfully 'put a test message' to both queues.
However when I 'runmqsc QM01' for the FR queue manager, followed by 'dis qcluster(*)', the two cluster queue instances are still not shown.
Similarly an amqrfdm 'q' display does not show these queues even though there has been successful access to them.
This is not the behaviur that I expect and I wonder if it is associated with my use of the namelist on the cluster receiver channel, particularly since in other cases where I use the 'cluster' property rather than 'clusnl' on the cluster receiver channel definition I do see the remote cluster queues at the FR queue manager, both under runmqsc and also in amqrfdm.
I hope this explanation is not too involved and would be interested in any comments. |
|
| Back to top |
|
 |
| zhanghz |
| Posted: Wed Dec 17, 2008 10:18 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| how about doing all from command line ("amqsput CQ01 QM01", then "runmqsc QM01", then "DIS QC(*)") and check? |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Dec 17, 2008 11:35 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| when I 'runmqsc QM01' for the FR queue manager |
you mix up things. QM01 is PR as you wrote. to me it looks like you did the put to the cluster queue not from QM01, otherwise it would know the queues. in addition, you wrote you saw the queues before purring to them, for a PR this is not true.
instead of getting confused by the mq explorer, i suggest you follow what zhanghz recommended, this should work fine.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| TonyD |
| Posted: Thu Dec 18, 2008 11:36 am Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
| zhanghz wrote: |
| how about doing all from command line ("amqsput CQ01 QM01", then "runmqsc QM01", then "DIS QC(*)") and check? |
Did that ... the Put was fine but as I indicated the cluster queues were not shown under runmqsc on the PR
Yes, Mr Butcher, '...when I 'runmqsc QM01' for the FR queue manager' is a typo; it is of course the PR and is the queue manager from which I put the message to the cluster queue on the FR QM.
My question addressed the anomaly that, after doing the first access from the PR to the FR cluster queue, I saw the cluster queues in MQExplorer under QM01, but not when using 'runmqsc'.
I can assure you that I am not confused by MQExplorer or runmqsc  |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Dec 19, 2008 1:46 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| TonyD wrote: |
| ...My question addressed the anomaly that, after doing the first access from the PR to the FR cluster queue, I saw the cluster queues in MQExplorer under QM01, but not when using 'runmqsc'... |
Working as advertised in the case of 'runmqsc'. The following might help:
"Partial Repository queue managers only know what they need to know about a cluster, when they need to know it, but then remember what they've learned. Full Repository queue managers know all about the cluster all of the time"
A bit simplistic in description, but basically correct. Your PR would not have known about the queue until it first needed to put to an instance of it, hence zhanghz's suggestion.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 19, 2008 4:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
For what it's worth, the only place I use CLUSNL is at the QM level when a FR needs to be a FR in 2 or more clusters. Otherwise for overlapping PRs, its typical to define multiple cluster receiver.
TO.PR1.CLUSTER1
TO.PR1.CLUSTER2
TO.PR1.CLUSTER3
This way you can tune the individual channels to the individual clusters (i.e. SSL or exits or MCAUSER values). And its a little simpler and more explicit in my opinion. (Big deal, you have to define a couple of extra channels, one time)
Now if we could only get dedicated cluster transmit queues per cluster.....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Dec 19, 2008 5:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| ...Now if we could only get dedicated cluster transmit queues per cluster..... |
I've asked (twice) in the appropriate forum, but the more votes the better 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Dec 19, 2008 8:39 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| PeterPotkay wrote: |
For what it's worth, the only place I use CLUSNL is at the QM level when a FR needs to be a FR in 2 or more clusters. Otherwise for overlapping PRs, its typical to define multiple cluster receiver.
TO.PR1.CLUSTER1
TO.PR1.CLUSTER2
TO.PR1.CLUSTER3
This way you can tune the individual channels to the individual clusters (i.e. SSL or exits or MCAUSER values). And its a little simpler and more explicit in my opinion. (Big deal, you have to define a couple of extra channels, one time)
|
I have created a case of cluster overlapping, and don't know if it's acceptable or recommendable or none of it, where a qmgr is a FR in one and PR in the second cluster. I have used CLUSNL in that case only to define a single cluster receiver for both clusters on that qmgr. For both cluster senders and qmgr I have used CLUSTER and REPOS respectively, hence not a NL parameter. I don't know if that can produce some problems arround the corner, I think I didn't find in the info center any pro's and contra's for that case. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Dec 23, 2008 12:16 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| jcv wrote: |
| PeterPotkay wrote: |
For what it's worth, the only place I use CLUSNL is at the QM level when a FR needs to be a FR in 2 or more clusters. Otherwise for overlapping PRs, its typical to define multiple cluster receiver.
TO.PR1.CLUSTER1
TO.PR1.CLUSTER2
TO.PR1.CLUSTER3
This way you can tune the individual channels to the individual clusters (i.e. SSL or exits or MCAUSER values). And its a little simpler and more explicit in my opinion. (Big deal, you have to define a couple of extra channels, one time)
|
I have created a case of cluster overlapping, and don't know if it's acceptable or recommendable or none of it, where a qmgr is a FR in one and PR in the second cluster. I have used CLUSNL in that case only to define a single cluster receiver for both clusters on that qmgr. For both cluster senders and qmgr I have used CLUSTER and REPOS respectively, hence not a NL parameter. I don't know if that can produce some problems arround the corner, I think I didn't find in the info center any pro's and contra's for that case. |
There are a lot of possibilities. Take the excellent advice of keeping things simple and never use namelists with cluster channels. The PR(s) will need two cluster senders (one for each cluster) and two cluster receivers (one for each cluster). This makes it very clear to the observer what your intent is. You might even incorporate the cluster name and QMGR name as part of the channel name (remember, you only have 20 characters).
A PR that is in more then one cluster could be called a Gatway QMGR.
One last point, every FR in a cluster must have an explicit cluster sender to every other FR in a cluster to ensure that the repositories do not get out of sync. This is one of the reasons why at least two and no more then two FRs for a cluster is a best practice. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Jan 02, 2009 12:48 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
