IBM Support



You can track all active APARs for this component.

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.
      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
         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
    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
    + 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


  • 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 number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention


  • Submitted date


  • Closed date


  • Last modified date


  • 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


Document information

More support for: z/OS family

Software version: 1D0

Operating system(s): z/OS

Reference #: PM77014

Modified date: 25 September 2015