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

Obtain the fix for this APAR.

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 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.