Mixed version cluster coexistence
A cluster can contain queue managers running at IBM MQ Version 9.0, and any currently supported earlier level of the product. However new features cannot be exploited from queue managers at an earlier level.
Cluster workload balancing in a mixed version cluster
IBM MQ Version 7.1 added a new DEFBIND value called GROUP to queues. Applications on queue managers earlier than Version 7.1 must not open or put messages to queues specifying the new value. When an application ignores this limitation, the workload balancing behavior (for example: BIND_ON_OPEN or BIND_NOT_FIXED) is undefined.
Routing behavior in a mixed version publish/subscribe cluster
From IBM MQ Version 8.0, topic host routing is available for publish/subscribe clusters. The queue manager where the object is defined, and the full repository queue managers, must be at a level that supports the topic route hosting feature, that is Version 8.0 or later. Any queue manager in the cluster that is at an earlier level does not adhere to the topic route hosting behavior.
When a clustered topic is defined for topic host routing (by setting the topic CLROUTE parameter to TOPICHOST ), only queue managers at the new level are aware of the clustered topic. Older queue managers do not receive the clustered topic definition and therefore behave as if the topic is not clustered. This means that all queue managers that need to work in a routed publish/subscribe manner must be at a version that supports this feature, not just the queue managers that host the routed topics.
Important notes:
- All full repositories must be at Version 8.0 or later to use this feature. If a full repository queue manager is at an earlier version, the CLROUTE of TOPICHOST is not recognized by the full repository, and the full repository propagates the topic definition to all queue managers in the cluster. Any pre-Version 8.0 queue managers then use the topic as if it is defined for DIRECT routing. This behavior is unsupported.
- If an older queue manager defines a direct routed clustered topic with the same name as an existing topic host routed clustered topic, the full repositories notice the conflicting definition and do not propagate the definition.
To find out the version of each queue manager in the cluster, specify the VERSION parameter with the DISPLAY CLUSQMGR command. If you issue this command from a queue manager with a full repository, the information returned applies to every queue manager in the cluster. Otherwise the information returned applies only to the queue managers in which it has an interest. That is, every queue manager to which it has tried to send a message and every queue manager that holds a full repository.