IBM Support

PH07185: MQ FOR Z/OS: THE CHIN JOB LOOPS READING SYSTEM.CHANNEL.SYNCQ RECORDS FOR A CHANNEL WITH MULTIPLE CLUSTER TRANSMIT QUEUES

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • High CPU in the CHIN job is observed.  It started after a
    RESOLVE CHANNEL command was done for an indoubt cluster channel
    that had been receiving CSQX507E channel is in-doubt.
    
    A CHIN trace has repetitive entries:
    Entry   15:28:53.371106  rrxReadSync
    Entry   15:28:53.371107  CSQXSEM Semaphore Processing
    Exit    15:28:53.371107  CSQXSEM Semaphore Processing
    Entry   15:28:53.371108  CSQXSEM Semaphore Processing
    Exit    15:28:53.371109  CSQXSEM Semaphore Processing
    Entry   15:28:53.371109  MQGET   Get Message
    Entry   15:28:53.371110  CSQXSRVR Service Requester
    Exit    15:28:53.371119  CSQXSRVR Service Requester
    Exit    15:28:53.371120  MQGET   Get Message
    Entry   15:28:53.371121  MQGET   Get Message
    Entry   15:28:53.371122  CSQXSRVR Service Requester
    Exit    15:28:53.371205  CSQXSRVR Service Requester
    Exit    15:28:53.371206  MQGET   Get Message
    Exit    15:28:53.371207  rrxReadSync
    
    The MQGET is for SYSTEM.CHANNEL.SYNCQ.  The records being
    returned alternate between two messages with the same cluster
    channel name but different transmission queue names.
    
    There is an issue with channel sync records and multiple
    cluster transmit queues if a REFRESH CLUSTER command is issued
    while the cluster sender channel is indoubt. This can result in
    multiple indoubt sync records on the SYSTEM.CHANNEL.SYNCQ with
    different transmit queues in the records. In this case, during
    the RESOLVE CHANNEL command, if the cluster channel definition
    has a different transmit queue than an indoubt sync record, a
    loop condition may occur when the SYNCQ is being read.
    
    Note that a REFRESH CLUSTER should be used in rare
    circumstances.
    
    Additional Symptom(s) Search Keyword(s):
    Performance
    CSQXRSYN
    

Local fix

  • If the loop occurs, a CSQ4SUTL utility may be provided that
    will help clear bad records from SYSTEM.CHANNEL.SYNCQ.
    

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: Errors occur when using CSQUTIL to      *
    *                      switch the transmit queue used by a     *
    *                      CLUSSDR channel. These can include:     *
    *                       - duplicate syncq records              *
    *                       - loops when resolving indoubt clussdr *
    *                         channels                             *
    *                       - incorrect indoubt resolution for     *
    *                         clussdr channels                     *
    ****************************************************************
    When CSQUTIL is used to issue the SWITCH CHANNEL command in
    order to make a pending xmitq switch for a cluster sender
    channel active, it causes the transmit queue name to be
    updated in sync records on SYSTEM.CHANNEL.SYNCQ, and in the
    channel initiators live copies of these records.
    However, when the channel is indoubt, the indoubt record on the
    sync queue is not updated, leading to a loop if RESOLVE CHANNEL
    is used to resolve the indoubt state.
    In addition, a chaining error when updating the live sync record
    can cause the live sync record to be lost in some circumstances,
    leading to duplicate records being created for the channel, and
    in the case of indoubt channels, the resolution of the indoubt
    state being performed incorrectly.
    

Problem conclusion

  • When switching cluster transmit queue using CSQUTIL, any indoubt
    records for the channel are now updated, and the chaining error
    when processing the live record is corrected.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PH07185

  • Reported component name

    IBM MQ Z/OS V9

  • Reported component ID

    5655MQ900

  • Reported release

    000

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2019-01-11

  • Closed date

    2019-02-07

  • Last modified date

    2019-03-01

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

    PI89568

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

    UI61201 UI61202

Modules/Macros

  • CSQMCTQS CSQXRSYN
    

Fix information

  • Fixed component name

    IBM MQ Z/OS V9

  • Fixed component ID

    5655MQ900

Applicable component levels

  • R000 PSY UI61201

       UP19/02/28 P F902 ¢

  • R100 PSY UI61202

       UP19/02/28 P F902 ¢

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":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
01 March 2019