PI16269: ABENDS0878 ECSA SP241 STORAGE GROWTH WITH XFVRT LOCK HELD

Obtain the fix for this APAR.

APAR status

• Closed as unreproducible.

Error description

• .
  This APAR is a FIN REVERSAL of APAR PM73523.
  .
  Storage growth in ECSA, eventually leading to multiple
  S878 ABENDs in various address spaces.  Examination of storage
  usage will show numerous SP241K6 areas x174000 bytes long that
  start with a DUCB eye-catcher at offset +18.
  
  To confirm the growth is associated with this problem:
  
   - TCPIP must have VIPAROUTE configured.
  
   - A TCPIPCS LOCK(DETAIL) report will show many DUCBs waiting on
     the IPMAIN and (likely) XCF locks.  The holder of the IPMAIN
     lock will show a pattern similar the following:
  
     asid ducbaddr      ...      Iu Su
       Lock Class 03:   ...
         Lock Level 01: ...  Held Shr  EnqH  IPMAIN
     asid ducbaddr      ...      Iu Su
       Lock Class 09:   ...
         Lock Level 07: ...  Wait Excl       XFVRT
  
     And the holder of the XFVRT lock will show:
  
     asid ducbaddr      ...      Iu Su
       Lock Class 03:   ...
         Lock Level 01: ...  Wait Shr        IPMAIN
     asid ducbaddr      ...      Iu Su
       Lock Class 09:   ...
         Lock Level 01: ...  Held Excl EnqH  XCF
         Lock Level 07: ...  Held Shr  EnqH  XFVRT
  

Local fix

• .
  Requires recycling TCPIP.  May need to do a FORCE ARM.
  .
  This APAR is a FIN REVERSAL of APAR PM73523.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS Version 1 Release 13 IP: Sysplex    *
  *                 distributor with VIPAROUTE                   *
  *                                                              *
  *                                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: A deadlock occurs when locks are        *
  *                      obtained out of order.                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A deadlock occurs when two separate threads try to
  obtain the same two locks, but one thread obtains
  the locks in the wrong order. The first thread
  initially obtains the locks in the correct order. It
  releases the first lock without releasing the second
  lock. It tries to obtain the first lock again, but a
  second thread is holding the first lock so the first
  thread goes into a wait. The second thread is waiting
  for the second lock which is held by the first thread.
  Both threads will now wait indefinitely while holding
  their respective locks.
  +-------------------------------------------------------------+
  + Please check our Communications Server for OS/390 homepages +
  + for common networking tips and fixes.  The URL for these    +
  + homepages can be found in Informational APAR II11334.       +
  +-------------------------------------------------------------+
  

Problem conclusion

Temporary fix

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

Comments

• The code will be changed to always release both
  locks when the first lock must be released. Then
  both locks will obtained in the correct order.
  

APAR Information

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

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

  UI17738

Modules/Macros

• EZBIERTE EZBIFIUM EZBIPPBR EZBIPRHD EZBIPRTE
  EZBIPRT2 EZBXFDYN EZBXFGP2 EZBXFHSH EZBXFMS2 EZBXFMS4 EZBXFPTB
  EZBXFTMR EZBXFUTL EZBX6HSH EZBX6MS2 EZBZIPBR ITTIMER
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R1D0 PSY UI17738

     UP14/06/21 P F406

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.