PH44379: TCPIP LOCK NOT RELEASED AFTER AN ABEND

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• A lock in TCPIP is held by a unit of work that abends and the
  lock is not released.  The lock remaining held causes all other
  units of work to suspend waiting on the lock.
  The type of lock held will determine the impact.  In most cases
  it will eventually lead to the TCPIP stack becoming unresponsive
  and require a restart of TCPIP to recover.
  Depending on the code path executing at the time of the abend it
  may also produce message EZZ9670E.
  If TCPIP sysplex monitoring is active it may produce message
  EZZ9674E.
  
  
  
  ANALYSIS:
  Most locks are obtained by TCPIP units of work and application
  units of work running in TCPIP code.  To access the lock
  strucutures involved a dump of the TCPIP address space is
  required.
  
  IP TCPIPCS LOCKS may show other lock contention.  The lock of
  concern will not show up in the report.  If lock contention is
  in the report then examine the lock holder DUCBs to see if they
  are waiting on locks.
  IP TCPIPCS DUAF (* IN SU will generate a report of DUCBs that
  are in use and suspended.  Examine the DUCBs call stacks to
  ensure the current entry is EZBITDSS and it has returned from
  EZBITKSS.  This is the signature for a DUCB that is suspended on
  a lock.
  IP TCPIPCS DUCB (ducb_address) will format the DUCB structure
  and the DUCB_LOCKS_SUSPENDED_NEXT value that is non x'00's or
  x'7FFAFAF1' indicates the DUCB is waiting on a lock.  The
  DUCB_LOCKS_SUSPENDED_NEXT value points to the lock entry that
  identifies the lock class, lock level, and specific lock.
  The DUCB_SUSPEND_TIME indicates when the DUCB suspended.
  Examining the suspended DUCBs and focusing on those that
  suspended first will help identify the problem lock.
  
  When the problem lock is identified, go to the lock and see if
  it is held exclusive by a specific DUCB.  If so the exclusive
  holder is the DUCB that abended and failed to release the lock.
  Examine that DUCB using IP TCPIPCS DUCB (ducb_address) to get
  the abend information.  When the lock is held shared there is
  simply a lock holder count so each DUCB in the IP TCPIPCS DUAF
  (*
  IN SU that is suspended on a lock will need to be examined to
  see if it is holding the lock.
  
  The problem DUCB will have the DUCB_DUAE_SUSPENDED and/or the
  DUCB_DUAE_RESUMED bit on.   Examining the DUCB lock table
  entry for the problem lock class and lock level will show the
  lock is held by this DUCB.
  
  Examine the abending DUCBs call path to validate there is an
  ITTRR recovery point that issues a ?ITLOCK RELEASE ALL or
  releases specific locks but not the lock that is held.
  
  KNOWN IMPACT:
  The impact is dependent on the lock that is held.  The TCPIP
  stack may become unresponsive or leave the sysplex.
  The reporting customer performed an IPL to recover.
  
  VERIFICATION STEPS:
  DUCB holding the lock has the DUCB_DUAE_SUSPENDED and/or
  DUCB_DUAE_RESUMED bit on.  The DUCB is no longer in use.  The
  DUCB_DRC_FOOTPRINT will be on.  If the call originated from the
  PFS the DUCB_VNR_INPROG and DUCB_VNR_FOOTPRINT will be off.
  
  ADDITIONAL SYMPTOMS:
  EZZ9670E TCPIP SYSPLEX PROCESSING HAS ENCOUNTERED A
  NONRECOVERABLE ERROR 0015F000 - 00000000
  
  EZZ9674E TCPIP SYSPLEX PROCESSING WAS NOT RESPONSIVE FOR AT
  LEAST 60 SECONDS
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of IBM Communications Server for z/OS Version 2    *
  * Release 4 and 5 IP                                           *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Under certain abend timing conditions, a process would not   *
  * properly track its ownership of a lock and thereby prevent   *
  * the lock from being freed during recovery.                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply PTF.                                                   *
  ****************************************************************
  

Problem conclusion

• Code has been updated to ensure lock ownership is tracked before
  opening a window for called functions to abend.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  UI79740 UI79741

Modules/Macros

• EZBXFUTL EZBITKOB
  

Fix information

• Fixed component name

  TCP/IP MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R250 PSY UI79741

     UP22/04/29 P F204 ¢

• R240 PSY UI79740

     UP22/04/29 P F204 ¢

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.