IBM Support

PH04894: OUT OF DATE QUEUE AND QMGR OBJECT CLUSTER CACHE RECORDS CAN INCORRECTLY BE USED WITHOUT FIRST UPDATING THEM

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Queue Alias deletions are not being being propagated across
    cluster
    .
    Additional keywords:
    Although the MQOPEN will work, the message may go to the
    Dead Letter Queue (DLQ) on a remote queue manager that once
    hosted a deleted cluster queue or queue manager alias.
    The DLH Reason might be:
      2085  0x00000825  MQRC_UNKNOWN_OBJECT_NAME
      2082  0x00000822  MQRC_UNKNOWN_ALIAS_BASE_Q
      2087  0x00000827  MQRC_UNKNOWN_REMOTE_Q_MGR
    .
    QALIAS
    *
    Additional information to be aware of after applying this APAR:
    .
    This APAR also addresses an clustering issue where QALIAS
    deletions were not correctly propagated around the cluster. This
    led to situations where messages could be put to a clustered
    queue that no longer exists, resulting in the messages being put
    to the DLQ instead.
    .
    Part of the fix for that situation involves MQ temporarily
    creating and then deleting new clustering subscriptions to
    ensure we reach the correct final state. These temporary
    subscriptions cause more messages to be created on
    SYSTEM.CLUSTER.* queues (higher curdepth) and cause more storage
    usage within the cluster cache. When these subscriptions are
    deleted, the storage they use is not immediately released. It is
    released when clustering maintenance processing runs around once
    per hour.
    .
    After this APAR is applied, if there are a large number of
    cluster objects to resolve, and if CLCACHE=STATIC, the following
    message can result:
      CSQX460E :MQP1 CSQXREPO Cluster cache is full
    In that situation use CLCACHE=DYNAMIC if possible.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
    *                 Release 0 Modification 0 and Release 1       *
    *                 Modification 0.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: It is possible when a Queue or QMGR     *
    *                      Cluster Cache record is used and has    *
    *                      not been used for a long period of      *
    *                      time that the process will attempt      *
    *                      to use the object 'as is' without       *
    *                      first updating the object which can     *
    *                      lead to unwanted behaviour.             *
    ****************************************************************
    After the subscriptions for a Cluster Cache Object (either a
    Queue or QMGR object) expire the object itself will remain in
    the cluster cache for a grace period. It is during this time
    that if some change happens to the actual object that the
    cluster cache record relates to then the cluster cache record
    will not be updated to reflect the change. This is because there
    are no subscriptions for that object anymore.
    
    For Queue objects this poses a problem if the Queue has been
    deleted in this time window as any MQPUT's to the queue via the
    cluster member hosting the active Queue Cluster cache record
    will not fail for RC=2085 MQRC_UNKNOWN_OBJECT_NAME as may be
    expected and the message will end up on the Dead Letter Queue.
    Similar behaviour can also be seen for QMGR cluster cache
    objects as well, for example if a QMGR is removed from a cluster
    in the discussed time window.
    

Problem conclusion

  • Additional checks have been introduced so that on an MQOPEN the
    Cluster Cache object that is being used is checked to see if any
    subscriptions exist for the object before using it. If there are
    none then new ones will be created. This will ensure that the
    cluster cache object being used is up to date before it is being
    used.
    
    The following page in the IBM MQ 9.0.x Knowledge Center is
    updated:
    
    Home
    ->IBM MQ 9.0.x
      ->IBM MQ
        ->Reference
          ->Messages
            ->IBM MQ for z/OS messages, completion, and reason codes
              ->Messages for IBM MQ for z/OS
    
    https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.
    ibm.mq.ref.doc/csq_m.htm
    
    The following is added:
    
    CSQM580I
    
        csect-name CLUSTER OBJECT NAME object-name LOCATED AT QMID
        qmid IS RESOLVED USING OLD CACHED INFORMATION.
    Severity
        0
    Explanation
    
        The cluster object referenced has been resolved using old
        cached information.
    System action
    
        Processing continues.
    System programmer response
    
        None.
    
    ================================================================
    
    The following page in the IBM MQ 9.1.x Knowledge Center is
    updated:
    
    Home
    ->IBM MQ 9.0.x
      ->IBM MQ
        ->Reference
          ->Messages
            ->IBM MQ for z/OS messages, completion, and reason codes
              ->Messages for IBM MQ for z/OS
    
    https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.
    ibm.mq.ref.doc/csq_m.htm
    
    The following is added:
    
    CSQM580I
    
        csect-name CLUSTER OBJECT NAME object-name LOCATED AT QMID
        qmid IS RESOLVED USING OLD CACHED INFORMATION.
    Severity
        0
    Explanation
    
        The cluster object referenced has been resolved using old
        cached information.
    System action
    
        Processing continues.
    System programmer response
    
        None.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PH04894

  • Reported component name

    IBM MQ Z/OS V9

  • Reported component ID

    5655MQ900

  • Reported release

    000

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-11-05

  • Closed date

    2019-04-25

  • Last modified date

    2021-05-06

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

    PH00904

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

    UI62677 UI62678 UI62679 UI62680 UI62681 UI62682 UI62683 UI62684
    UI62685 UI62686 UI62687 UI62688

Modules/Macros

  • CSQFMDIC CSQFMDIE CSQFMDIF CSQFMDIK CSQFMDIU CSQFMTXC CSQFMTXE
    CSQFMTXF CSQFMTXK CSQFMTXU CSQMZLOO
    

Fix information

  • Fixed component name

    IBM MQ Z/OS V9

  • Fixed component ID

    5655MQ900

Applicable component levels

  • R000 PSY UI63982

       UP19/07/24 P F907

  • R001 PSY UI63984

       UP19/07/24 P F907

  • R002 PSY UI63983

       UP19/07/24 P F907

  • R003 PSY UI63985

       UP19/07/24 P F907

  • R004 PSY UI63986

       UP19/07/24 P F907

  • R005 PSY UI63987

       UP19/07/24 P F907

  • R100 PSY UI63988

       UP19/07/24 P F907

  • R101 PSY UI63991

       UP19/07/24 P F907

  • R102 PSY UI63993

       UP19/07/24 P F907

  • R103 PSY UI63992

       UP19/07/24 P F907

  • R104 PSY UI63989

       UP19/07/24 P F907

  • R105 PSY UI63990

       UP19/07/24 P F907

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.

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0"}]

Document Information

Modified date:
07 May 2021