PM77014: ROUTING TREE UPDATES SUSPENDED AFTER APPLICATION ABEND

APAR status

• Closed as fixed if next.

Error description

• If an application has an unrecoverable ABEND (such as a CANCEL
  command) while in a socket call that requires a route lookup
  (such as a CONNECT or SENDTO call), the potential exists for the
  count of active searches in that table to remain set after that
  address space is removed.  After that point, later attempts to
  update that table will be suspended waiting for that search to
  complete (which it never will).  Affected processes can be:
  
   - An OBEYFILE that specifies a replacement for the GATEWAY or
     BEGINROUTES statement block.
  
   - OMPROUTE updates.  If SYSPLEXMONITOR is enabled, an EZZ9672E
     and (eventually) an EZZ9678E message will be issued with an
     accompanying S4C5/77610404 ABEND.
  
   - Stopping or starting one of the TCPIP devices.  This can
     include XCF interfaces when one of the other members of the
     sysplex goes up or down.
  
   - On systems with PATHMTUDISCOVERY enabled, traffic over an
     affected connection could stop.
  
  
  Verification:
  
    In a dump of TCPIP, the affected DUCB will be holding the
    IELOCK/IEREQLK and PTREE locks exclusive and the IPMAIN lock
    shared.  The call sequence in the DUCB will be similar to the
    following:
  
       10000048 19591270 194F5000 194F51A0 00F89D00 0057 OMPROUTE
                                                    00000000 Iu Su
       RSA  194F56E8  Prev 1F4F45F0  Next 194F5EC8  Mod EZBPFIOC
       RSA  194F5ED0  Prev 194F56E8  Next 194F71A8  Mod EZBUDWR1
       RSA  194F71B0  Prev 194F5ED0  Next 194F7470  Mod EZBIECTL
       RSA  194F7478  Prev 194F71B0  Next 194F7710  Mod EZBIEACC
       RSA  194F7718  Prev 194F7478  Next 16700038  Mod EZBIERTE
       RSA at 16700040 is outside address range of DUSA
       RSA  16700040  Prev 194F7718  Next 16700E30  Mod EZBIPRTE
       RSA  16700E38  Prev 16700040  Next 00000000  Mod EZBITDSS
  
    On the affected routing table, the current Search tree will
    have the pr_ptreeUpdateWait and pr_ptreeTreeInd flags set and
    a non-zero pr_ptreeNumReaders and pr_PtreeWaitDUCB value.  For
    a typical configuration (single stack, no Policy Based
    Routing), these can be examined by doing a
    L 10?+8C?+B0?+5C?+40?+F0?+78?+50?+1C?+18 command while
    browsing the TCPIP address space, the first byte will be
    x'C0', the next three the number of searchers and the next
    word the pointer to the updater's DUCB.
  

Local fix

• TCPIP will need to be recycled to clear this.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS Version 1 Release(s) 13 IP          *
  ****************************************************************
  * PROBLEM DESCRIPTION: Routing tree updates become suspended   *
  *                      when a non-retryable abend occurs on    *
  *                      a unit of work searching for a route.   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Routing tree updates become suspended when a non-retryable abend
  occurs on a unit of work searching for a route.
  
  The request for a route increments the number of readers that
  are accessing the routing table.  If the request is running
  under an application unit of work that terminates with a non-
  retryable abend (cancel, force) the reader count will not be
  decremented.
  Route updates may occur due to dynamic route changes (OMPROUTE)
  or configuration changes such as an interface state change.
  The route update is not committed until the count of readers
  accessing the routing table is zero.
  In this non-retryable abend condition updates to the routing
  table stall and lock contention is likely to occur, causing
  other units of work not performing route processing to also
  stall.
  +-------------------------------------------------------------+
  + 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

Comments

• The solution for this APAR is included in CS for zOS Version 2
  Release 2.
  
  
  This problem will be tracked as Feature F156158
  by Communications Server for z/OS Development.
  
  This APAR is fixed in HIP61D0 by APAR PM96049.
  This APAR is fixed in HIP6210 by APAR PI04881.
  

APAR Information

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

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

Fix information

Applicable component levels

• R1D0 PSN

     UP