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)

When working on short-timed queue managers in proof-of-concept or demo environments there is sometimes much easier to just turn of default security behaviour to get the job done then to start configuring a safe and secure queue manager. Here is how to disable the default rule to not allow any privilege users access objects from remote connections.
This example will allow a privileged user to connect to a SVRCONN channel, for example with MQExplorer

The following command is run using the runmqsc command

SET CHLAUTH(MY.MQEXPLORER.CHANNEL) TYPE(BLOCKUSER) USERLIST('nouser') DESCR('Rule to allow privileged user to connect to channel')

Tested on IBM MQ 9.0.5.0 and Red Hat 7

I like passwords, I really do, but on a queue manager that only is used in a proof-of-concept or a demo, I feel that password checking is unnecessary. So because of this and that I can not make myself remember how to do it I put the solution here

The solution is to alter the SYSTEM.DEFAULT.AUTHINFO.IDPWOS CHCKCLNT parameter to NONE or OPTIONAL. This can be done using runmqsc, or MQExplorer if you like a GUI instead

 
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)  AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)

and after that we need to make sure the new setting is in affect

REFRESH SECURITY

Tested on IBM MQ 9.0.4.0 and RHEL 7