PM70709: SYSTEM.CLUSTER.TRANSMIT.QUEUE CURDEPTH BECOMES NON-ZERO AND CLUSTER CHANNELS START AT ONCE WHEN WEBSPHERE MQ CHIN STARTS

APAR status

• Closed as duplicate of another APAR.

Error description

• 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).
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• 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.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  PM78265

Fix information

Applicable component levels