PM70709: SYSTEM.CLUSTER.TRANSMIT.QUEUE CURDEPTH BECOMES NON-ZERO AND CLUSTER CHANNELS START AT ONCE WHEN WEBSPHERE MQ CHIN STARTS
Closed as duplicate of another APAR.
When a WebSphere MQ Version 7.0.1 QMGR is started the CURDEPTH of the SCTQ remains at zero; however, once the CHINIT starts the CURDEPTH rises as cluster command messages arrive due to changes in a CLUSRCVR channel object. Change Team finds rrmCmpClqMgr detected differences in the objects created. Specifically, when a DEFINE REPLACE is issued for a cluster-receiver channel, rrmChangeClqMgr invokes rrxValidateChannel which causes several fields in the MQCD in the new cluster QMGR object to be set to blanks (such as the xmitqname or qmgrname). This causes a mismatch with the cluster QMGR object already in the cache, and hence a republication of the cluster queue-manager is made to the full repositories, causing channels to be started. This does not occur at Version 6 of the product as rrxValidateChannel was not invoked by rrmChangeClqMgr (so fields such as xmitqname remained as nulls in the new cluster QMGR object, thus matching the contents of the cluster cache).
Closing as a duplicate of PM52894. The V710 backwards migrate APAR PM52894 doesn't change the MQCD_VERSION number from 7 to 9 in rfiRestoreObject and as a result there is no reconciliation at start-up time which causes the clusrcvr to be republished to the full repositories, and therefore for the channels to start.
Reported component name
WMQ Z/OS V7
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Applicable component levels
More support for:
APAR / Maintenance
Software version: 7.0.1
Reference #: PM70709
Modified date: 03 December 2012