Current MQ clustering behaviour (and why it can be risky)
In IBM MQ clustering today, any queue manager can join a cluster provided it knows a small set of connection details—typically:
- the Full Repository (FR) queue manager name
- the DNS name or IP address
- the listener port
This model differs fundamentally from point-to-point (non-cluster) connectivity. With point-to-point channels, both ends must be explicitly configured (for example, defining the appropriate SVRCONN/RCVR/SDR channel objects on each side) before any communication can occur. That bilateral configuration requirement creates a natural control point: connectivity cannot be established unless both parties have been deliberately set up.
With clustering, the barrier to entry is lower. A prospective partial repository queue manager only needs to define the cluster sender and receiver channels (for example, CLUSSDR and CLUSRCVR) to one or more full repositories. Once those channels are established, the queue manager can effectively participate in the cluster without the cluster owner necessarily performing any explicit “admission” step.
Operational challenges in large organisations
In a large enterprise, it’s common for multiple Business Units to manage their own queue managers independently. In that environment, it is entirely possible for:
- several queue managers (owned by different teams) to attempt to join the same cluster, and
- the cluster-owning team to be unaware this is happening until after the fact.
Additionally, modern DevOps/Agile delivery models can increase the likelihood of configuration drift and human error. For instance, a less experienced engineer provisioning MQ might inadvertently:
- connect a non-production queue manager to a production cluster, or
- join an incorrectly named queue manager to the wrong environment due to reused scripts, templated configuration, or copied channel definitions.
The impact of an unintended join can be severe—ranging from routing and workload disruption to governance breaches—particularly in tightly controlled production estates.
Proposed enhancement: explicit cluster admission control
To reduce this risk, there should be an enhancement to MQ clustering that introduces explicit admission control—effectively allowing a cluster to operate in one of two modes:
Open membership (current behaviour)
- “Any queue manager can join at any time, provided it can connect to the full repository.”
Restricted membership (proposed behaviour)
- “Only queue managers on an approved list are permitted to join this cluster.”
From an implementation perspective, the configuration could be provided via:
- a parameter in the distributed platform.iniconfiguration, and/or
- a parameter in the PARM configuration on IBM z/OS, with
- the approved queue manager names maintained in a centrally managed list (for example, a dataset referenced by the started task).
This would keep the control point within the MQ administrative domain, rather than relying primarily on external controls.
Relationship to existing controls (and why this still matters)
It’s acknowledged that there are other ways to restrict cluster access, such as:
- firewall rules and network segmentation,
- platform and network security policies,
- IP allowlists, routing constraints, and other infrastructure controls.
However, those controls often sit outside MQ administration and may require:
- coordination across multiple teams,
- lengthy change processes,
- and indirect enforcement that is not always aligned with MQ object-level governance.
A built-in MQ clustering control would provide a first-class, MQ-native safeguard that is easier to operationalise and audit.
Desired outcome (production example)
In a production cluster, the full repository could maintain an explicit allowlist such as:
…and only those queue managers would be permitted to join.
If someone attempted to connect PROD4 (not yet approved) or NONPROD1 (clearly outside the production estate), the join attempt would be rejected, preventing accidental cross-environment contamination and reducing operational and security risk.
