How to connect queue managers for WebSphere MQ 7.0 distributed publish/subscribe

Question

As always, IBM documenation is great for what it tells you but leaves important details out. Apologies if this is already answered here - the search terms are unfortunately mostly generic or at least ambiguous and I have looked through a few hundred questions with no luck.

I have two (IBM i) servers, each with a single WMQ 7.0 queue manager. I have two channels running between them - one each direction.

I have a topic defined on "server A" with Publication and Subscription Scopes of "All" and Proxy Subscription Behaviour of "Force".

I have a subscription defined on "server B" with Scope "All".

Everything is up and running but when I drop a message into the topic on server A (using MQ Explorer), nothing appears on server B.

I have read about the "proxy subscriptions" required to make this work but I cannot for the life of me figure out how these get created.

Any assistance appreciated. I've got this far (never used pub/sub before) in a few hours only to trip at this hurdle.

You have to setup a hierarchy between these two queue managers for publications to flow to queue manager on B.

You have to setup a hierarchy between these two queue managers for publications to flow to queue manager on B.

Assuming queue manager on A as parent and queue manager on B as child, you have to issue "ALTER QMGR PARENT ()" in a RUNMQSC prompt of queue manager on B. This will create the hierarchy between two queue managers. Once a subscription is created on queue manager on B, a proxy subscription will automatically flow to queue manager on A. Assuming queue manager on A as parent and queue manager on B as child, you have to issue "ALTER QMGR PARENT ()" in a RUNMQSC prompt of queue manager on B. This will create the hierarchy between two queue managers. Once a subscription is created on queue manager on B, a proxy subscription will automatically flow to queue manager on A.

EDIT: More detail on my configuration (with slightly more meaningful - to me - server names)

On server A7:

Queue manager A7.QUEUE.MANAGER 
Sender channel A7.TO.A2 with transmission queue A7.TO.A2 
Alias queue A2.QUEUE.MANAGER pointing to A7.TO.A2 
Receiver channel A2.TO.A7 

In server A2:

Queue manager A2.QUEUE.MANAGER 
Sender channel A2.TO.A7 with transmission queue A2.TO.A7 
Alias queue A7.QUEUE.MANAGER pointing to A2.TO.A7 
Receiver channel A7.TO.A2 
I then issued ALTER QMGR PARENT('A7.QUEUE.MANAGER') 

I have the topic on A7 and after issuing the ALTER (above) I added a subscription on A2 to the topic.

display pubsub type(ALL)                               
3 : display pubsub type(ALL)                      
AMQ8723: Display pub/sub status details.               
QMNAME(A2.QUEUE.MANAGER) TYPE(LOCAL) 

display pubsub type(ALL)                               
1 : display pubsub type(ALL)                      
AMQ8723: Display pub/sub status details.               
QMNAME(A7.QUEUE.MANAGER) TYPE(LOCAL) 

Answer 1

You have to setup a hierarchy between these two queue managers for publications to flow to queue manager on B.

Assuming queue manager on A as parent and queue manager on B as child, you have to issue "ALTER QMGR PARENT ()" in a RUNMQSC prompt of queue manager on B. This will create the hierarchy between two queue managers. Once a subscription is created on queue manager on B, a proxy subscription will automatically flow to queue manager on A.

Answer 2

Cluster the two QMgrs and advertise the topic to the cluster. WMQ will then make publications available across the cluster.

On QMGR01

# Make the QMgr a cluster repository
ALTER QMGR REPOS('CLUSTERNAME')

# Create CLUSRCVR and advertise to cluster
# Substitute your CONNAME parms, QMgr name, channel names, etc.
DEF CHL(CLUSTERNAME.QMGR01) CHLTYPE(CLUSRCVR) +
    TRPTYPE(TCP) +
    CONNAME('127.0.0.1(1414)') +
    CLUSTER('CLUSTERNAME') +
    REPLACE

# Create topic object and advertise to cluster
DEF TOPIC('ROOT') TOPICSTR('ROOT') CLUSTER('CLUSTERNAME') REPLACE

On QMGR02

# Always create CLUSRCVR first and advertise to cluster
# Substitute your CONNAME parms, QMgr name, channel names, etc.
DEF CHL(CLUSTERNAME.QMGR02) CHLTYPE(CLUSRCVR) +
    TRPTYPE(TCP) +
    CONNAME('127.0.0.1(1415)') +
    CLUSTER('CLUSTERNAME') +
    REPLACE

# Then conecct to the repos and advertise the CLUSSDR to the cluster too
# Substitute your CONNAME parms, QMgr name, channel names, etc.
DEF CHL(CLUSTERNAME.QMGR01) CHLTYPE(CLUSSDR) +
    TRPTYPE(TCP) +
    CONNAME('127.0.0.1(1414)') +
    CLUSTER('CLUSTERNAME') +
    REPLACE

Now you can publish to the topic that was advertised to the cluster:

On QMgr01

amqspub ROOT/Whatever QMGR01

On QMgr02

amqssub ROOT/Whatever QMGR02

You don't have to name your object ROOT or use that as the top of the topic namespace. This was an arbitrary example and you can use anything you want. In Production you would probably have some topic objects at the 2nd or 3rd level in the topic hierarchy to hang access control lists from. Generally it is these objects that are used to advertise the topics to the cluster.

Some additional notes:

• You cannot advertise SYSTEM.BASE.TOPIC or SYSTEM.DEFAULT.TOPIC to the cluster.
• A clustered topic need be defined on only one node in the cluster. It can be any node but it's a good practice to advertise it on the primary full repository. That way you know where all your clustered topic objects are defined in one place and the repository is (or should be) highly available.
• If there are local and clustered topic objects that overlap, the local one takes precedence.

Please see Creating a new cluster topic for more info. Also, Creating and configuring a queue manager cluster has tasks to create the cluster and add QMgrs to it. However, I tested with the above on my Windows host and in this minimal cluster, the pub/sub worked great.