A fix is available
APAR status
Closed as program error.
Error description
On a distributed queue manager, the cluster name for z/OS cluster objects may appear as garbage characters when displayed on distributed queue managers. This includes "at signs", for example: CLUSTER(ÔØ×Ã×âñ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@) The same channel or queue object may also have an object with a valid cluster name, so the one with the garbled name appears as a duplicate entry with a different CLUSDATE. . If amqrfdm output is viewed in binary mode, the first bytes of the CLUSTER name are the hex for EBCDIC characters. The name is not being properly converted. The following error occurs on the distributed queue managers: AMQ9420: No repositories for cluster ÔØ×Ã×âñ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@. . The reported environment includes: - full repositories (FR) for a cluster on both WMQ for z/OS 7.1.0 and WMQ on a distributed platform - an object hosted on a z/OS partial repository (PR) - partial repositories on the distributed platform --------------------------------------------------------------- The problem is due to a conversion error in a cluster admin message. When a cluster object such as a cluster receiver or a cluster queue is changed in any way (e.g. SUSPEND QMGR CLUSTER, ALTER QUEUE or ALTER CHANNEL TYPE(CLUSRCVR)), an INSERT message is sent to both full repositories. The FRs in turn update their cache with the new (updated) object and then update the other FR before informing all interested parties of the change. This is to ensure that FRs are consistent with each other. . The problem occurs when the z/OS FR receives the update via the distributed FR first, before it receives it from the z/OS partial where the change was made. In that case the admin message is being converted incorrectly--the cluster name is being left as EBCDIC characters but they are labelled as being in an ASCII codepage, e.g. 819. Therefore, that part of the admin message is not converted from EBCDIC. The bad admin message is sent to interested parties. When the cluster name is then displayed on a distributed partial repository, it shows as garbage. . Normally, the update would arrive at the z/OS FR from the PR first rather than from the FR, so there is a race condition which is normally won by the 'direct' update. However if the channel from the z/OS PR to the z/OS FR is down, then the problem manifests itself every time. Similarly if the z/OS FR was down then it makes it more likely that the 'indirect' update via the FR will win the race. . The problem can be recreated by: 1. On a z/OS partial repostiory, stop ALL channels to the z/OS full repository. DISPLAY CLUSQMGR will show the CLUSSDRA (auto-defined) and CLUSSDRB (manually defined) channels--look for all the ones to the FR. 2. On the z/OS partial repository, make some kind of update to a cluster queue or the clusrcvr channel, for instance alter the description field or the PUT(ENABLED|DISABLED) status. 3. On a distributed partial repository that has an interest in the changed object, do a DIS QCLUSTER(*) or DIS CLUSQMGR(*). You should find a new object where the cluster name is garbage. . ADDITIONAL KEYWORDS: atsign at_sign ghost corrupt corrupted
Local fix
A ++APAR is available from the support center. This will prevent the problem from occurring in the future. . To clean up the bad entries on distributed partial repositories, issue REFRESH CLUSTER(*) REPOS(YES) The garbage cluster names can not be individually cleared. The queue manager can be suspended from the cluster prior to the refresh to minimize impact to applications.
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Incorrect CodedCharSetId in MQCFSL * * (String List) parameters in PCF * * messages that have been converted by * * the queue manager. * * If the message is converted again, this * * can lead to conversion failures e.g. * * MQRC_NOT_CONVERTED 2119 * * or invalid values in the string list. * * * * In a clustering environment, the * * internal PCF command messages can * * be sent with the incorrect * * CodedCharSetId associated with the * * cluster name, causing an incorrect * * cluster name, containing invalid * * characters to be associated with * * records in the cluster cache. * **************************************************************** * RECOMMENDATION: * **************************************************************** When a PCF message (with Format MQADMIN) is converted by the queue manager, CSQAADM6 is called to convert the PCF fields into the requested CodedCharSetId and Encoding. When converting a MQCFSL (String List) parameter, CSQAADM6 correctly converts the strings contained in the string list, but does not set the CodedCharSetId field. If the message is subsequently converted again, the incorrect CodedCharSetId field can cause an invalid conversion to take place, resulting in conversion failures, or can cause the strings in the string list to remain unconverted. In a clustering environment, this can lead to cluster command messages sent from z/os full repositories to distributed partial repositories with the cluster name in an EBCDIC codepage, but the CodedCharSetId field indicating the value is already in the partial repository's ASCII codepage. This results in incorrect entries being added to the partial repository's cluster cache, with invalid characters in the cluster name.
Problem conclusion
CSQAADM6 is changed to correctly set the CodedCharSetId field in MQCFSL parameters to the codepage requested by the conversion after successfully converting the values in the string list. 100Y CSQAADM6
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PM84108
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-03-05
Closed date
2013-03-12
Last modified date
2015-04-16
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK92431 010PC2 010PC2
Modules/Macros
CSQAADM6
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UK92431
UP13/04/13 P F304
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:
16 April 2015