A fix is available
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
SC34286800 | SC34729000 |
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