IBM Support

PI31452: CWXN TASKS STUCK IN SOCKET RECIEVE FOR 30 SECONDS UNTIL TIMEOUT FOLLOWING A PERIOD WHERE ALL TASKS WERE SUSPENDED FOR SOMETHING.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • There was a period where transactions, including CWXN
    transactions, were all backed up for a few minutes
    forcing the CICS region to go to maxtask.  Lots of CWXN
    transactions are queued for maxtask.  The socket clients that
    initiated the queued CWXN transaction time out such that they
    will not participate in any SSL flows when the CWXN transactions
    finally get going.  But the sock clients do not close the
    socket.  When the cause of the back up clears and the queued
    CWXN transactions finally run, they allocate an S8 TCB and
    send an SSL flow to the client and wait for the response in
    a SOCKET RECEIVE wait.  Since the client is no longer talking,
    but has not closed the socket, this SOCKET RECEIVE does not
    complete until it times out after 30 seconds.  Because CWXNs
    own an S8 TCB while hung in the SOCKET RECEIVE for 30 seconds,
    other CWXN transactions wait in DISPATCH SSL_POOL to get an
    S8.  The result is that each CWXN task waits for minutes to
    get an S8, and then holds that S8 for 30 seconds waiting for
    the client which is not sending anything.  This makes it
    impossible to recover from a transaction backup.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS users.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: CWXN tasks stuck in socket receive for  *
    *                      30 seconds until timeout.               *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    During a busy period many CWXN transactions are queued for
    MAXTASK, along with other backed up tasks.
    The socket clients that initiated the queued CWXN transactions
    time out and become inactive, however they do not close the
    sockets so CICS is not informed they have gone. When MAXTASK
    clears and the CWXN transactions finally run, they allocate an
    S8 TCB and send an SSL flow to the client and wait for the
    response in a SOCKET RECEIVE wait. Since the client is no longer
    talking, but has not closed the socket, this SOCKET RECEIVE does
    not complete until it times out after 30 seconds.
    Because CWXNs own an S8 TCB while hung in the SOCKET RECEIVE for
    30 seconds, other CWXN transactions wait in DISPATCH SSL_POOL to
    get an S8 TCB. The result is that each CWXN task waits for
    minutes to get an S8, and then holds that S8 for 30 seconds
    waiting for the client which is not sending anything.
    This makes it impossible to recover from a transaction backup,
    each time a CWXN task times out and frees an S8 TCB it is taken
    by another delayed CWXN task which also times out after waiting
    30 seconds for the SOCKET RECEIVE to complete.
    

Problem conclusion

  • The timeout value for the first SOCKET RECEIVE (for the HTTP
    protocol) has been changed from a fixed 30 seconds to be the
    DTIMOUT value of the transaction specified on the TCPIPSERVICE
    definition, normally CWXN. If this DTIMOUT value is zero 30
    seconds is still used.
    
    The CICS Transaction Server for z/OS Version 5 Release 1
    Resource Definition Guide (SC34-2868-00) has been updated in
    Chapter 28, 'TCPIPSERVICE resources', section 'TCPIPSERVICE
    attributes'. The first paragraph of the description for the
    attribute SOCKETCLOSE has been changed to read as follows:
    
    'Specifies whether, and for how long, CICS waits before it
    closes the socket. The SOCKETCLOSE attribute does not apply to
    the first receive request that is issued after a connection is
    made. On the first receive request for the ECI and USER
    protocols CICS waits for data for 30 seconds before it closes
    the socket. On the first receive request for the HTTP protocol,
    CICS waits for the DTIMEOUT value associated with the
    transaction specified on the TCPIPSERVICE. If this DTIMEOUT
    value is zero CICS waits for 30 seconds.'
    
    An equivalent change has been made to the CICS Transaction
    Server for z/OS Version 5 Release 2 Resource Definition Guide
    (SC34-7290-00) and IBM Knowledge Center.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PI31452

  • Reported component name

    CICS TS Z/OS V5

  • Reported component ID

    5655Y0400

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-12-12

  • Closed date

    2015-02-11

  • Last modified date

    2015-09-07

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

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

    UI25074 UI25075 UI25076 UI25077 PI39026

Modules/Macros

  • DFJ@H360
    

Publications Referenced
SC34286800SC34729000   

Fix information

  • Fixed component name

    CICS TS Z/OS V5

  • Fixed component ID

    5655Y0400

Applicable component levels

  • R80D PSY UI25075

       UP15/02/19 P F502

  • R800 PSY UI25074

       UP15/02/19 P F502

  • R90D PSY UI25077

       UP15/02/19 P F502

  • R900 PSY UI25076

       UP15/02/19 P F502

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":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
22 July 2020