Yeah that was a typo in the email (QM3.XMIT vs. QM3.XMITQ). I don't understand why yours works and mine don't. ?????
I deleted the remote queue def from QM2. I then added the remote queue def to QM1, but this time also specified the XMIT queue in the remote queue def, and it works. Before I saw your email, I concluded that if you are going to create a remote queue def in a cluster, it needs to be on the gateway queue manager, since that is where the XMIT queue lives. Since I can't cluster the XMIT queue, I can't refer to it in a remote queue def on a clustered QM that doesn't house that XMIT queue. I didn't feel to confident though, since I don't see any docs that say you can or can't define a remote queue def anywhere in a cluster. I did find an example of exactly what I am trying to achieve in this years Cluster Handout from the Tech Conference in Dallas. In this example, they define the remote queue def on the gateway QM, and the putting app is connected to another clustered QM. It doesn't say you HAVE to do it this way, but since it was the only example I found, I assume this was the case, until you came along and debunked that theory! Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Tony Devitt [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 7:41 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in System.Cluster.Transmit.Queue ************************************************************************** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ************************************************************************** : Peter, I assume(?) that 'QM3.XMIT' is a typo, or is there a reason to have it as well as 'QM3.XMITQ'. Anyway I set up the definitions as you have on three test queue managers, and see on: 1. QM1: FINALQ ( a cluster queue owned by QM2) QM3 (a remote def with no RNAME pointing to RQMNAME(QM3) using XMITQ(QM3.XMITQ) belonging to cluster (CLUS1)) QM3.XMITQ ( a local XMITQ, which I have associated with a sdr/rcvr channel 'QM1.QM3') 2. QM2: FINALQ (a remote def with RNAME(FINALQ) at RQMNAME(QM3) using XMITQ (' ') belonging to cluster (CLUS1)) QM3 (a cluster queue owned by QM1) 3. QM3: FINALQ (a local queue) With this set of definitions, messages that I place in FINALQ at QM2 travel from QM2 to QM1 on the cluster channel and then via the channel QM1.QM3 to the final destination FINALQ on QM3. This seems to be what you are trying to achieve. Did your remote QDef for cluster queue QM3 get propagated from QM1 to QM2? : **************************************************************************** **** The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of CGU Insurance. This message has been scanned for viruses and cleared by MailMarshal. ******************************************************************** : 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