Peter, i get a little bit confused by the mix of your remotequeues and qmgr aliases, and the setup you described in this mail sounds different from the setup you described before, but both setups look like a "works as designed" to me.
see my comments (>>) below. regards stefan -----Ursprüngliche Nachricht----- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 22. November 2002 23:44 An: [EMAIL PROTECTED] Betreff: Re: Cluster Question (remote defs in overlapping clusters) I deleted the QM Alias on QMB. The set up is as follows now: ******************************************************* QMA and QMB are in ClusterAB. QMA has a remote queue def called RequestQueue (RemoteQName=RequestQueue, RemoteQMname=QM1, XMITQ= blank) QM1 and QM2 are in Cluster12. Each has a local queue called RequestQueue, and each one is clustered under Cluster12. ClusterAB and Cluster 12 overlap. QMB is in both. ***************************************************** If I put messages to the remote queue def on QMA, they all go to QM1. Cool. >> why? because there is a REMOTEQ(QM1) RNAME() RQMNAME(QM1) XMITQ(QM1.XMIT) CLUSTER(CLUSTERAB) >> defined on QMB. Thats correct. If I change the properties of the remote queue def to be (RemoteQName=RequestQueue, RemoteQMname=QM2, XMITQ= blank), they all go to QM2. >> no. this cant be true. i get a 2087 because QMA does not know about QM2 >> QMA asks QMB (if this one is repository) "do you know something with the >> name QM2 in cluster CLUSTERAB"? and QMB says "no" (he only knows QM2 as >> a member of CLUSTER12). >> if you created a QMGR Alias named QM2 on QMB like you did for QM1 >> then this will work the same way it worked with QM1. if you did not >> create that alias for QM2 then there is more in CLUSTERAB that you >> think it is. (sounds linke QM2 is member of CLUSTERAB too). If I delete the remote queue def on QMA, and recreate it on QMB, the messages round robin. That I cant figure out. Why doesn't the RemoteQMname parameter in the remote queue def hold it to one QM like it did when the remote def was on QMA? >> how exactly does this remoteq looks like? >> my tests are (all definitions on QMB): >> rq(RequestQueue) rname(RequestQueue) rqmname(QM1) CLUSTER(CLUSTERAB) >> --> will route to QM1 >> rq(RequestQueue) rname(RequestQueue) rqmname(QM2) CLUSTER(CLUSTERAB) >> --> will route to QM2 >> rq(RequestQueue) rname(RequestQueue) rqmname(QMB) CLUSTER(CLUSTERAB) >> --> will route to DLQ on QMB >> rq(RequestQueue) rname(RequestQueue) rqmname() CLUSTER(CLUSTERAB) >> --> will route to DLQ on QMB Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Raabe, Stefan [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 4:41 AM To: [EMAIL PROTECTED] Subject: AW: Cluster Question (remote defs in overlapping clusters) Peter, i rebuilt the situation and it worked fine here. (all queuemanagers on win/nt version 5.2) messages are sent from QMA to QMB using TO.QMB clustersenderchannel, and then from QMB to QM1 using QM1.XMIT and QMB.TO.QM1 senderchannel. I tried to create the error by applying some changes to the QM1 QmgrAlias on QMB but no gain. If doing bad things here, messages are put to QMB dead letter queue. Its hard to guess why. Maybe - you did a definition error somehow (most likely on QMB, because if QMA is not member of CLUSTER12 it is only up to QMB to do the round-robin distribution. if the messages really flow from QMA to QMB first, then QMB msut think that they are destined for QMB and not for QM1). check all definitions if they exaclty match what you described. - does QMA knows about the RequestQueue Cluster entries? does QMA knows about Clusterqueuemanagers QM1 and QM2? - maybe a cluster error (what version are you running?) - verify the channel status after sending messages to check which way the messages took (QMA to QM1/2 directly or via QMB) - maybe the application is running with QMB instead of QMA? - maybe all of the above is nonsense :-) regards stefan -----Ursprüngliche Nachricht----- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 21. November 2002 23:19 An: [EMAIL PROTECTED] Betreff: Cluster Question (remote defs in overlapping clusters) Man, what a mess. Try and draw this one 1st before attempting to solve it! QMA and QMB are in ClusterAB. QMA has a remote queue def called RequestQueue (RemoteQName=RequestQueue, RemoteQMname=QM1, XMITQ= blank) QM1 and QM2 are in Cluster12. Each has a local queue called RequestQueue, and each one is clustered under Cluster12. ClusterAB and Cluster 12 overlap. QMB is in both. There is a QMAlias called QM1 on QMB. QM1 has QM1 as the RemoteQMname, and QM1.XMIT queue as the transmit queue. That transmit queue goes directly to QM1. If an App on QMA puts to RequestQueue, wouldn't it's definition cause all the messages to go to QM1, via the QM1 Alias definition on QMB? Instead I see them round robin between QM1 and QM2. Why? Is there anyway the App on QMA can get all of its messages to QM1 consistently (without disabling the queue on QM2)? I thought the QMAlias along with the remote queue def would force that behavior. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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 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
