IBM Support

PM84108: WMQ Z/OS 7.1.0: THE CLUSTER NAME FOR Z/OS CLUSTER OBJECTS HAS GARBAGE CHARACTERS WHEN DISPLAYED ON DISTRIBUTED QUEUE MANAGERS

A fix is available

Subscribe

You can track all active APARs for this component.

 

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