My cluster channel definition worked – why?

This question came up during some education on clustering.

The problem arose because she had typed in the wrong name for the channel, yet clustering worked – she could send a message to a remote clustered queue. Most people who have created sender/receiver channel pairs have experienced the frustration of the channel not starting because the name was not quite the same – Ohs and zeros, different punctuation marks etc. So it was a surprise that when she made a mistake it worked!

Let me take a simple example. We have three queue managers in a cluster:

• QM_REPOS is the full repository. It has a CLUSRCVR Channel called TO_REPOS, and a conname of REPOS(1414).
• A queue manager called QMA. This has
  • a cluster sender channel called TO_REPOS, and a conname of REPOS(1414) which matches QM_REPOS
  • a cluster receiver channel called TO_QMA, conname(SYSA(1414))
• A queue manager QMB. This has
  • a cluster queue called TEST
  • a cluster sender channel called TO_REPOS, and a conname of REPOS(1414) which matches QM_REPOS
  • a cluster receiver channel called BAD_SPELLING conname(SYSB(1414))

When QMB joined the cluster it sent information about the queue manager to the cluster repository. The repository then stores the data in the form of a logical table

QNAME=TEST, use_channel_name = BAD_SPELLING conname(SYSB(1414))

When QMA wants to use the TEST queue, it finds it does not have the information, and so asks the repository, which sends down all the data for QNAME=TEST. QMA then caches this data locally. QMA then picks an entry (from the list of one entry), and dynamically creates a cluster sender channel called BAD_SPELLING with conname(SYSB(1414)). Because BAD_SPELLING is the same as what QMB sent to the repository it matches – and so works! Pretty amazing eh!

How can I tell what Ive got?

In this excellent article by David Ware of IBM, it talks about cluster channel. Ive copied some of it below.

Using the DISPLAY CLUSQMGR command. Each CLUSQMGR entry represents how the local queue manager sees the other queue managers in each of the clusters it is a member of. You get a separate entry per cluster irrespective of whether namelists have been used on the cluster channels or not. The entry contains two particularly useful attributes for this discussion, QMTYPE and DEFTYPE.

QMTYPE simply shows if the other queue manager is a full repository (‘REPOS’) for the cluster or a partial repository (‘NORMAL’).

DEFTYPE shows you how the relationship between the queue managers has been established, based on what cluster channels have been defined. DEFTYPE has a number of rather cryptic values, CLUSSDR, CLUSSDRA, CLUSSDRB and CLUSRCVR. I’ll summarize them here:

DEFTYPE values

CLUSRCVR: This is the entry for the local queue manager in each cluster it has a cluster receiver channel defined.

Any CLUSSDR* value means this entry represents a remote queue manager in a cluster. The different values however help you understand how the local queue manager came to know about it:

CLUSSDRA: This is a remote cluster queue manager that the local queue manager has no manually defined cluster sender channel for it, but has been told about it by someone else, either by the remote queue manager itself (typically because this queue manager is a full repository) or because a full repository has told this queue manager about it as it needs to communicate with it for some reason.

CLUSSDRB: This means the local queue manager has a manually defined cluster sender channel which has been used to establish contact with the target queue manager and that queue manager has accepted it from the point of view of the cluster. The target could be a full or a partial repository, although as I’ve already said you really only want it to be a full repository at the other end.

CLUSSDR: This means the local queue manager has manually defined a cluster sender channel to the remote queue manager but the initial cluster handshake between them has not yet completed. This may be because the channel has never started, perhaps because the target is not running or the configuration is incorrect. It could also mean the channel has successfully started but the target queue manager did not like the cluster information provided, for example a cluster name was set in the cluster sender channel definition that does not match the target’s cluster membership. Once the handshake has been performed, the DEFTYPE should change to CLUSSDRB, so in a healthy system CLUSSDR should only be a transitory state.