PH52185: ABEND CODE DS0002 OPEN_DSTCB_FREE_CHAIN_ERROR

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An abend occurred with CODE=DS0002 and message:
  DFHDS0002 xxxxxxxx A severe error (code X'0217') has occurred in
  module DFHDSAT.
                                                                 .
  The CICS internal trace showed an entry like:
  29093 L800T DS 0217 DSAT  *EXC* OPEN_DSTCB_FREE_CHAIN_ERROR
                                                                 .
  Shortly prior to the abend with DS0002 there was a system ssl
  error.
  The CICS internal trace showed:
  29094 S800C SO 080C SOSE  *EXC* SYSTEM_SSL_ERROR
     GSK_RESPONSE(GSK_API_NOT_AVAILABLE) FUNCTION(SECURE_SOC_INIT)
     RESPONSE(DISASTER) REASON(GSK_ERROR)
     GSK_RETURN_CODE(2) CERTIFICATE_USERID() CIPHER_SELECTED()
     HANDSHAKE_TYPE() PROTOCOL_USED()
                                                                 .
  Both entries (both taskids) involved the same S8 TCB.
                                                                 .
    The problem is caused by the changes at CICS TS 6.1 to add
  additional diagnostics when there is a handshake failure.
  The additional diagnostic code disassociates the S8 TCB from the
  task, but that task retains the S8 TCB token and changes back to
  it directly even though it no longer owns that TCB.
                                                                 .
    Due to this situation it is possible for 2 tasks to use the
  same TCB at the same time.
                                                                 .
    The use of an S8 TCB for 2 concurrent System SSL calls results
  in the GSK_API_NOT_AVAILABLE response.
                                                                 .
    Then when the second task releases the S8 TCB, the CICS
  dispatcher finds that the TCB is already on the free chain which
  trips the OPEN_DSTCB_FREE_CHAIN_ERROR and causes the DS0002
  dump.
                                                                 .
  A secondary problem may occur after a TLS handshake failure.
  It is possible for outbound HTTP requests to acquire an S8TLSHS
  resource slot and fail to release it.  The number of S8TLSHS
  slots is set at CICS initialisation time to 90% of MAXSSLTCBS.
  If there are enough handshake failures for outbound requests
  then all the S8TLSHS slots can be invalidly allocated.  That
  prevents any further TLS handshakes from taking place.
  
  Keywords: Upgrade2CICS61
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: DFHDS0002 and DFHSO0002 messages and    *
  *                      dumps as well as possible hung region   *
  *                      following TLS handshake failures for    *
  *                      outbound HTTP requests.                 *
  ****************************************************************
  CICS is processing a large amount of outbound HTTP requests.
  The requests all use TLS connections.  Some of the TLS
  handshakes fail.
  
  The reporting of the failure issues message DFHSO0123 and
  DFHSO0399.  During the processing of the DFHSO0399 message it is
  possible for the current task to lose ownership of its S8 TCB.
  When that happens it is possible for another task to be given
  the S8 TCB while it is still in use by the original task.
  
  If both tasks make a System SSL call at the same time then one
  will fail with a DFHSO0002 message and dump with reason
  GSK_API_NOT_AVAILABLE.
  
  When both tasks finally free the S8 TCB the CICS dispatcher will
  detect that the TCB is already freed.  This is reported by a
  DFHDS0002 message and dump with code x'0217'.
  
  It is also possible for a tasks owned S8 chain to become
  corrupted.  In this case the tasks S8 TCB points to itself.
  This causes the task to still own the S8 TCB at task
  termination.  DFHDSKE tries to free all open TCBs still
  allocated to the task.  The S8 TCB pointing to itself causes
  the dispatcher to get into a loop and the region hangs.
  
  Another problem that occurs after the handshake failure happens
  when the task makes a WEB CLOSE call.  This causes the task to
  acquire an S8TLSHS resource slot in the belief that the TLS
  handshake still needs to be done.  This slot is never released.
  Eventually the region can run out of S8TLSHS slots.  When that
  happens no further TLS handshakes can be performed.
  

Problem conclusion

• CICS has been changed to;
   - correctly retain ownership of the S8 TCB during the reporting
      of a TLS handshake failure.
   - Ensure that S8TLSHS slots are correctly released after TLS
     handshake failures.
  

Temporary fix

Comments

• ×**** PE23/08/25 FIX IN ERROR. SEE APAR PH56549  FOR DESCRIPTION
  

APAR Information

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

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

  UI90518

Modules/Macros

• DFHSOAD  DFHSOCK  DFHSODM  DFHSODUF DFHSOIS  DFHSOL   DFHSOLI
  DFHSOLS  DFHSOLX  DFHSOLX6 DFHSOM01 DFHSOM02 DFHSOM03 DFHSOPL
  DFHSORD  DFHSOS00 DFHSOS01 DFHSOS02 DFHSOS03 DFHSOS04 DFHSOS05
  DFHSOS06 DFHSOS07 DFHSOS08 DFHSOS09 DFHSOS10 DFHSOS11 DFHSOS12
  DFHSOS13 DFHSOS14 DFHSOS15 DFHSOS16 DFHSOS17 DFHSOS18 DFHSOS19
  DFHSOS20 DFHSOS21 DFHSOS22 DFHSOS23 DFHSOSE  DFHSOST  DFHSOTB
  DFHSOTI  DFHSOTRI DFHSOUE  DFHSOXM
  

Fix information

• Fixed component name

  CICS TS Z/OS V6

• Fixed component ID

  5655YA100

Applicable component levels

• R400 PSY UI90518

     UP23/03/01 P F302 ¢

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.