PK10028: DFHSOS23 CALLS DFHSOS14 FOR FUNCTION RELINQUISH AGAINST FREED SOCKET. S0C4 IN DFHLMLM BECAUSE LOCK TOKEN STORAGE IS RE-USED.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An IIOP request receiver task hasissued a sockets ASYNC receive
  with a timeout time of SOCKETCLOSE (which is 2 minutes).
   When this times out, timer domain executes code in DFHSOTI to
  timeout the receive. This cancels the active receive whichcause
  s the sockets listener task to wake up and process the abnormall
  y completed receive.  This invokes DFHSOS23 for NOTIFY. As the
  socket is for IIOP, the NOTIFY GATE for the socket is called
  (DFHIIRR function SO_NOTIFY).  The call passes an action of
  timeout which causes routine iirr_so_notify_gate to close the
  socket. This frees the socket and STE and deletesthe lock token
  owned by the socket.  DFHIIRR then returns to DFHSOS23. The code
  in DFHSOS23 assumes that the socket which is the subject of the
  timeout still exists and attempts to call DFHSO14 for function
  relinquish against the freemained socket.(which has been
  deleted). the lock token (which was in the freemained socket)
  has been re-used by tempstorage. hence DFHLMLM program checks.
  Additional symptoms: Listener CSOL hang hung Web processing
  stops due to the CSOL transaction being in an LMQUEUE wait.
  In this case the Resource type was BLANK. Looking at LM=3, I
  there were no waiters shown. In this case DFHSOS23 is issuing
  a reqlinquish against a socket that is freed. The LOCK token
  passed to lock manager was x'40404040' and was addressable
  storage- so there was no program check. when going to this
  address x'40404040' we found offset x'1C' or 4040405C pointed
  back to the lock element address found in lock manager.
  WEB tcpip tcpipservice hang hung
  Additional symptoms: The CSOL task is stuck in an LMQUEUE wait
  yet LM=3 does not show any waiters.  This is our main socket
  listener task running on the SL tcb. The lock token appears
  to be 40404040.  Backing up looking at DU=3 in the  dump, we
  found they previously experienced errors- DFHLM0001 abend0C4
  0C4 at offset 106E in DFHLMLM, followed by DFHSO0001.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: MSGDFHLM0001 An abend (code 0C4/AKEA)   *
  *                      has occurred in module DFHLMLM when an  *
  *                      IIOP socket receive times out.          *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  An IIOP request is received on a TCPIP socket and processed
  successfully. The IIOP client doesn't close the socket and the
  SOCKETCLOSE value on the IIOP TCPIPSERVICE is set to 2 minutes.
  This causes a CICS socket NOTIFY to be scheduled in 2 minutes
  time to timeout and close the socket. When this timeout occurs,
  the sockets listener task calls DFHIIRR to notify it of the
  timeout. DFHIIRR calls sockets domain to close the socket as
  part of cleanup. This deletes the socket and the locks owned by
  the socket. When DFHIIRR finishes NOTIFY processing, it returns
  to its caller ( DFHSOS23 ) which decrements a count in the now
  freemained socket and issues a socket relinquish call to remove
  any reserve which the listener task may have on the socket.
  The relinquish call attempts to use a lock which has been
  deleted. The lock token is taken from the freemained socket
  block but the socket storage has been re-used and overwritten.
  DFHLMLM program checks when it tries to use the garbage lock
  token and a DFHLM0001 message and LM0001 dump result.
  This leads to an ASOB transaction abend which causes a
  DFHSO0001 message and SO0001 dump.
  
  ADDITIONAL KEYWORDS :- MSGDFHSO0001 S0C4 ABENDS0C4 0C4 ABEND0C4
  

Problem conclusion

• DFHSOS23 has been changed so that on completion of a socket
  notify to a callback routine, it confirms that the socket
  token is still valid before attempting to decrement the
  notify_count and relinquish the socket.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PK06301

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

  UK06394

Modules/Macros

•    DESSOSO  DFHSOSOC DFHSOS00 DFHSOS01 DFHSOS02
  DFHSOS03 DFHSOS04 DFHSOS05 DFHSOS06 DFHSOS07 DFHSOS08 DFHSOS09
  DFHSOS10 DFHSOS11 DFHSOS12 DFHSOS13 DFHSOS14 DFHSOS15 DFHSOS16
  DFHSOS17 DFHSOS18 DFHSOS19 DFHSOS20 DFHSOS21 DFHSOS22 DFHSOS23
  

Fix information

• Fixed component name

  CICSTS 3.1 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK06394

     UP05/08/24 P F508

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.