Can a REMOTE QUEUE definition unexpectadly utilize the CLUSTER transmit queue

3
votes

I've got a clustered partner in WMQ on distributed platforms (HP-UX). They and the qmgr they are putting messages to are both members of "my" cluster, but have never utilized the cluster relationship to communicate amonst themselves. They have a remote queue def, transmit queue (named as the queue manager), unique point to point sender/receiver channel pair, etc., but he claims that a TRACE ROUTE from one to the other is magically utilizing the SYSTEM.CLUSTER.TRANSMIT.QUEUE and the cluster channel (presumably), even though the remote queue, of course, has configured no such thing.

Is there any strange anomalie of MQ that would cause a standard REMOTE queue to choose to use the cluster path without expecting it to?

The queues on either side are NOT shared in the cluster of course.

1
ibm-mq

1 Answers

2
votes

I think we've answered our own question. Can't imagine how I managed to follow the rules all along, and never elicit this behavior. If the supposed transmit queue specified in the remote queue definition does not have USAGE(XMITQ) specified, but rather, (NORMAL), and the transmit queue specified in the RQ is indeed the name of the known queue manager in the cluster, then voila, we have the cluster being used regardless of the definition explicitly configured in the remote queue definition itself. What a handy way to migrate from remote queue / unclustered definitions, to clustered ones.