A fix is available
APAR status
Closed as program error.
Error description
When a WebSphere MQ Version 7.1.0 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
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Cluster sender channels start when * * the queue manager and channel initiator * * are started. * **************************************************************** * RECOMMENDATION: * **************************************************************** During startup, the channel initiator loads the channel definitions from the SYSTEM.CLUSTER.REPOSITORY.QUEUE and compares them to the objects that are in the cache. When there is a mismatch, the object in the cache is updated, and in the case of cluster queue manager objects, the object is published to the full repository, causing the cluster sender channel to be started. In this case, new attributes where added to the cluster queue manager object in MQ V710, RemoteVersion and RemoteProduct, which are set for objects loaded from the cache, but not for objects loaded from the SYSTEM.CLUSTER.REPOSITORY.QUEUE. Thus a mismatch is detected, and the object in the cache updated.
Problem conclusion
The code is changed to correctly initialise the new attributes in the case of loading objects from the SYSTEM.CLUSTER.REPOSITORY.QUEUE, avoiding the update in the cache and the starting of the cluster sender channel. 100Y CSQXRFIC CSQXRFXR CSQXRRMF
Temporary fix
Comments
APAR Information
APAR number
PM78265
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2012-12-03
Closed date
2013-05-13
Last modified date
2013-07-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK94223
Modules/Macros
CSQXRFIC CSQXRFXR CSQXRRMF
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UK94223
UP13/06/14 P F306
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 July 2013