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

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• There was a period where transactions, including CWXN
  transactions, where all tasks were backed up for a few minutes
  forcing the CICS region to go to maxtask.  Lot's 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 4 Release 2
  Resource Definition Guide (SC34-7181-01) has been updated in
  Chapter 31, '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 closing
  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 closing 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.'
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PI31452

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

  UI27607

Modules/Macros

• DFHIEIE  DFHIEXM  DFHIIRR  DFHIIXM  DFHRZDM  DFHRZIX  DFHRZLN
  DFHRZNR2 DFHRZRG2 DFHRZRM  DFHRZRS1 DFHRZSO  DFHRZSO1 DFHRZTA
  DFHRZTCX DFHRZTRI DFHRZTR1 DFHRZXM  DFHSOAD  DFHSOCK  DFHSOCKT
  DFHSODM  DFHSODUF DFHSOIS  DFHSOL   DFHSOLI  DFHSOLS  DFHSOLX
  DFHSOM01 DFHSOM02 DFHSOM03 DFHSOPL  DFHSORD  DFHSOSE  DFHSOSES
  DFHSOST  DFHSOS00 DFHSOS01 DFHSOS02 DFHSOS03 DFHSOS04 DFHSOS05
  DFHSOS06 DFHSOS07 DFHSOS08 DFHSOS09 DFHSOS10 DFHSOS11 DFHSOS12
  DFHSOS13 DFHSOS14 DFHSOS15 DFHSOS16 DFHSOS17 DFHSOS18 DFHSOS19
  DFHSOS20 DFHSOS21 DFHSOS22 DFHSOS23 DFHSOTB  DFHSOTI  DFHSOTRI
  DFHSOUE  DFHSOXM  DFHWBA   DFHWBAP  DFHWBAPF DFHWBA1  DFHWBBLI
  DFHWBCL  DFHWBDM  DFHWBDUF DFHWBENV DFHWBPA  DFHWBPW  DFHWBSO
  DFHWBSR  DFHWBSV  DFHWBTTA DFHWBXM  DFHWBXN
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R700 PSY UI27607

     UP15/05/22 P F505

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.