IBM Support

PI07181: SHARED SDR RECEIVED CSQX202E RC=00000467 (ETIMEDOUT), THE CHANNEL IS WAITING FOR THE TCP/IP SOCKET TO RESPOND.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Shared SDR (Sender channel) received CSQX202E RC=00000467
    (ETIMEDOUT).
    The channel is waiting for the TCP/IP socket to respond.
    .
    The issue occurs when the following occurs:
    
    - A shared sender channel is starting on one qmgr in
      the QSG (QM1), but the connection is not able to be
      established immediately. The channel is waiting for
      the TCP/IP socket to respond.
    .
    +CSQX202E WMQ1 CSQXRCTL Connection or remote listener
          unavailable, channel SOME.CHANNEL.
          connection SOME.REMOTE.QMGR (xxx.xxx.xxx.xxx).
          TRPTYPE=TCP RC=00000467 (ETIMEDOUT) reason=00000000.
    .
    - STOP CHINIT is issued for QM1.
    
    - START QMGR and START CHINIT are issued for another
      member of the QSG (QM2).
    
    - QM2 detects that QM1's chinit is stopping and
      attempts to recover any active shared channels that
      are owned by QM1. This updates the state for the
      problem channel to show QM2 as the owner.
    
    - On QM1, the socket for the channel detects that
      there is a problem and provides a return code which
      causes the channel to end.
    - As part of the channel termination processing,
      QM1 temporarily changes the XMIT queue to
      GET(DISABLED).
    - After completing the channel processing, QM1 should
      re-enable the XMIT queue, but it notices that it is
      not the channel owner and incorrectly determines
      that the queue does not need re-enabling.
    .
    This leaves the XMIT queue GET(DISABLED), and the channel
    is stuck with a status of starting. No further retry
    of the channel connection occurs without manual
    intervention.
    
    
    
    
    Additional Symptom(s) Search Keyword(s):
    

Local fix

  • The issue could be avoided by changing the automated processing
    for this QSG so that you are not doing the stop and restart of
    all queue managers at the same time.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
    *                 Release 1 Modification 0.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Shared channel may fail to enter        *
    *                      retry after being peer-recovered        *
    *                      to another channel initiator            *
    *                      in the QSG and failing to start.        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    If a shared channel fails at the same time as its channel
    initiator is being shut down and another channel initiator
    is starting peer channel recovery, the recovered channel
    instance on the new channel initiator may fail to open
    the XMITQ.
    
    The following error messages may appear on the channel initiator
    joblog:
    
    +CSQX477E +CSQ1 CSQXSUPR Channel CHANNEL.NAME is active,
    transmission queue XMIT.QUEUE
    in use on ????
    
    Following the above error, instead of the channel entering retry
    the channel remains inactive requiring manual intervention to
    start.
    

Problem conclusion

  • Shared channel restart processing has been amended to ensure
    that the channel correctly enters the retry state.
    100Y
    CSQXRCSI
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI07181

  • 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

    2013-12-02

  • Closed date

    2014-02-25

  • Last modified date

    2014-05-02

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

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

    UI15442

Modules/Macros

  • CSQXRCSI
    

Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID

    5655R3600

Applicable component levels

  • R100 PSY UI15442

       UP14/04/08 P F404

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:
02 May 2014