OK, here is where I am at now. Below is the set up once more: ************************************************************** QM1 and QM2 are in ClusterA. QM3 is not in any cluster, and has a local queue called FinalQ.
QM1 is the gateway to QM3. QM1 has an XMIT queue called QM3.XMIT. It has a QM Alias called QM3, which maps to QM3.XMIT. I did the following on QM1: DEFINE QREMOTE('QM3') RNAME(' ') RQMNAME(QM3) XMITQ(QM3.XMITQ) CLUSTER(ClusterA) DEFINE QLOCAL(QM3.XMIT) USAGE(XMITQ) An app connected to QM2 needs to get messages to FinalQ / QM3. In its open of FinalQ, it cannot specify the QM name, so I want to create a remote queue definition on QM2 that points to FinalQ / QM3. So I did the following on QM2: DEFINE QREMOTE(FinalQ) RNAME('FinalQ') RQMNAME(QM3) XMITQ(' ') CLUSTER(ClusterA) But any messages I put to FinalQ on QM2 just sit in the SYSTEM.CLUSTER.TRANSMIT.QUEUE. ******************************************************************* If the remote queue def FinalQ on QM2 is part of cluster ClusterA, the messages get stuck in the SYSTEM.CLUSTER.TRANSMIT.QUEUE. If I remove the cluster attribute from the remote def FinalQ on QM2, it works fine! Actually they end up on the DLQ on the gateway, but that's related to a problem with CSD04 (see below). If I delete the remote queue def completely from QM2, and instead make it on the gateway (QM1), then it always works, whether it is clustered or not. If I use the above setup on my local pc and make all the QMs local, it works any which way no problem. Other people use the above setup with no problem. The common thing - no CSD04. In the setup where I have the problem the version is 5.2 CSD04. The release notes for CSD05 include the following: IY30457 - With CSD04 installed, if you put to a local queue manager alias which resolved to a queue manager in a cluster then the queue name was reset to blank. As a result messages started going to the dead letter queue instead of the destination queue on the final queue manager. The reason code in the DLH when this happens could have been either 2184 (MQRC_REMOTE_Q_NAME_ERROR) or 2085 (MQRC_UNKNOWN_OBJECT_NAME). Now this explains why my messages ended up on the DLQ when I tweaked the remote queue def to not be clustered -OR- to be on the Gateway. It does not explain why the messages get stuck in the cluster XMITQ if the remote queue def is clustered and not on the gateway. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Friday, September 27, 2002 10:21 AM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in System.Cluster.Transmit.Queue Any idea why the stuck messages in the cluster xmit queue would not have an xmit header? That explains why they aren't going anywhere, but how/why did they get on the XMIT queue with no header??? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 9:05 AM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in System.Cluster.Transmit.Queue One more clue. If I use the MQExplorer to look at the QM Alias in my original setup, (before I moved the remote queue def to the gateway) to click on the Cluster Tab, I see that the queue is part of my Cluster. When I click on say the general tab, as I am leaving the cluster tab, I get the following error: The queue manager is not member of the cluster 'Cluster1'. The object which you have shared is in the cluster will no be made available to other members of the cluster until you make this queue manager a member of the cluster (AMQ4514). I get this on the gateway QM. In fact I get it for any clustered queue if I do a properties check on it on QM1. But it IS part of the cluster, since messages are using QM1 to get into the cluster and messages that don't use remote queue defs are leaving the cluster via this single gateway. Its like QM2 doesn't know about the QM Aliases on QM1, so the messages stack up??? Also this error doesn't show up on my teammates MQExplorer, which is newer than mine. Is the error even valid? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 10:42 PM To: [EMAIL PROTECTED] Subject: Re: Messages stuck in System.Cluster.Transmit.Queue 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 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