Cluster naming conventions

Consider naming queue managers in the same cluster using a naming convention that identifies the cluster to which the queue manager belongs. Use a similar naming convention for channel names and extend it to describe the channel characteristics.

Best practices when naming MQ Clusters

Although cluster names can be up to 48 characters, relatively short cluster names are helpful when applying naming conventions to other objects. See Best practices when choosing cluster channel names.

When choosing a cluster name, it is usually helpful to represent the 'purpose' of the cluster (which is likely to be long-lived) rather than the 'content'. For example 'B2BPROD' or 'ACTTEST' rather than 'QM1_QM2_QM3_CLUS'.

Best practices when choosing cluster Queue Manager names

If you are creating a new cluster and its members from scratch, consider a naming convention for the queue managers that reflects their cluster usage. Every queue manager must have a different name. However, you can give queue managers in a cluster a set of similar names, to help in identifying and remembering logical groupings (for example 'ACTTQM1, ACTTQM2).

Relatively short queue manager names (for example less than 8 characters) help if you choose to use the convention described in the next section, or something similar, for channel names.

Best practices when choosing cluster channel names

Because queue managers and clusters can have names of up to 48 characters, and a channel name is limited to 20 characters, take care when first naming objects to avoid having to change the naming convention midway through a project (see previous section).

When defining channels, remember that automatically-created cluster-sender channels on any queue manager in the cluster take their name from the corresponding cluster-receiver channel configured on the receiving queue manager in the cluster, and these must therefore be unique and make sense on remote queue managers in the cluster.

One common approach is to use the queue manager name preceded by the cluster name. For example, if the cluster name is CLUSTER1 and the queue managers are QM1, QM2, then cluster-receiver channels are CLUSTER1.QM1, CLUSTER1.QM2.

You might extend this convention if channels have different priorities or use different protocols. For example:

CLUSTER1.QM1.S1
CLUSTER1.QM1.N3
CLUSTER1.QM1.T4

In this example, S1 might be the first SNA channel, N3 might be the NetBIOS channel with a network priority of three, and T4 might be TCP IP using an IPV4 network.

Naming shared channel definitions: A single channel definition can be shared across multiple clusters, in which case the naming conventions suggested here would need modification. However, as described in Managing channel definitions it is usually preferable to define discrete channels for each cluster in any case.
Older channel naming conventions: Outside of cluster environments it has historically been common to use a 'FROMQM.TO.TARGETQM' naming convention, so you might find existing clusters have used something similar (such as CLUSTER.TO.TARGET). This is not recommended as part of a new cluster naming scheme because it further reduces the available characters to convey 'useful' information within your channel name.
Channel names on IBM® MQ for z/OS®: You can define VTAM generic resources or Dynamic Domain Name Server (DDNS) generic names. You can define connection names using generic names. However, when you create a cluster-receiver definition, do not use a generic connection name.; The problem with using generic connection names for cluster-receiver definitions is as follows: If you define a CLUSRCVR with a generic CONNAME there is no guarantee that your CLUSSDR channels point to the queue managers you intend. Your initial CLUSSDR might end up pointing to any queue manager in the queue sharing group, not necessarily one that hosts a full repository. If a channel starts trying a connection again, it might reconnect to a different queue manager with the same generic name, disrupting the flow of messages.