I am in this post going to show how I setup a dedicated “clients” queue manager where all queue managers are on the same machine. This can be useful when you want clients to connect to you in a dev or test environment and you do not want them to interfere with your work, and still easily be able to help them with messages.
This example will also show you have to setup any cluster since the tasks are pretty much the same.
We are going to need two queue managers. The one that we are working on (WORK01), and one for the clients to connect to (CLIENTDEV01). To enable sending messages between them we are going to setup a small cluster
We start with making our WORK01 queue manager a full repository and start the cluster there. All commands are for the runmqsc interpreter but can be done via MQExplorer if you like a GUI better
ALTER QMGR REPOS(CLIENTS)
This puts our WORK01 queue manager into a cluster named CLIENTS (which only contains one queue manager at this time)
Now we need a listener for communication…
DEFINE LISTENER(CLUSTER.LISTENER) TRPTYPE(TCP) CONTROL(QMGR) PORT(1420) START LISTENER(CLUSTER.LISTENER)
This creates a listener for port 1420 and it is started/stopped with the queue manager. This way we don’t have to worry about forgetting to start it
…and channels for messages
DEFINE CHANNEL(TO.WORK01) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('127.0.0.1(1420))') CLUSTER(CLIENTS) DESCR('TCP Cluster-receiver channel for queue manager WORK01')
Create a cluster receiver channel pointing to our listener and a part of the CLIENTS cluster
Now we are done with our WORK01 queue manager. Time to move on to our CLIENTDEV01 queue manager. This queue manager is not going to be a full repository so we do not need to put the queue manager into the CLIENTS cluster. We can here instead choose what objects (queues, topics and so on) to be part of the cluster
We create a listener for communication with the cluster
DEFINE LISTENER(CLUSTER.LISTENER) TRPTYPE(TCP) CONTROL(QMGR) PORT(1421) START LISTENER(CLUSTER.LISTENER)
Standard TCP listener on port 1421, just as that one for there WORK01 queue manager
A few channels to send messages over
DEFINE CHANNEL(TO.CLIENTDEV01) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('127.0.0.1(1421))') CLUSTER(CLIENTS) DESCR('TCP Cluster-receiver channel for the CLIENTDEV01 queue manager')
This channel points to the listener and is meant to receive messages from the cluster CLIENTS
DEFINE CHANNEL(TO.WORK01) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('127.0.0.1(1420)') CLUSTER(CLIENTS) DESCR('Cluster-sender channel from CLIENTDEV01 to the repo WORK01')
Now this needs a little more explaining:
* Cluster sender channel to the full repository on WORK01
* Port (1420) needs to be the same as the listener on the WORK01 queue manager
* Channel name (TO.WORK01) has to have the same name as the cluster receiver channel on the WORK01 queue manager
* Cluster sender channels should ONLY point to full repositories, so we are not going to point any cluster sender channel to our CLIENTSDEV1 queue manager which is a partial repository, only containing the object we define in it
* Cluster channels does not need to be started, they are started automatically
Done!
To test you can now define a queue alias on CLIENTDEV01 queue manager that points to a queue in the CLIENTS cluster on WORK01 and see if messages gets through
Troubleshooting tips:
# Ping remote queue manager through it's cluster receiver channel runmqsc: PING CHANNEL(<remote qmanager cluster receiver channel>) # Display channel status on all channels - here you can see the status of the cluster sender/receiver channels runmqsc: DIS CHSTATUS(*) # Displays all cluster qmanagers (full or partial) and their clusters names runmqsc: DIS CLUSQMGR(*)
Tested on MQ7.1.0.1 (RHEL 6.8) and MQ9.0.5.0(RHEL 7.5)
0 Comments.