OA41280: EZBITDSA(UK68305 11.151)+0005E0 S4C5/74FF2500 EZBUDEET(UK71936 11.258)+004AA8 S0C4/00000010

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• EZBITDSA(UK68305 11.151)+0005E0 S4C5/74FF2500
  EZBUDEET(UK71936 11.258)+004AA8 S0C4/00000010
  ---
  Abends occur as the result of a storage shortage. The dump
  showed many processes were waiting for TCPIP UCB lock.
  Elements being processed were EE TESTs (keepalive)- both
  requests and responses.
  Additional Symptoms:
  ABEND4C5  ABEND0C4
  

Local fix

• Increasing the LIVTIME value on both sides
  of the EE connection may be beneficial to
  reduce the number of keep-alive flows.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All using Enterprise Extender connections.   *
  ****************************************************************
  * PROBLEM DESCRIPTION: Abend ABEND4C5 reason code 74FF2500     *
  *                      when contention exists on the UCB lock  *
  *                      for Enterprise Extender traffic.        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is summarized as follows:
  1) EE configuration consisted of multiple local VIPAs active
     with connections to over 6000 EE partners.
  2) At times of HPR inactivity, EE connections are issuing
     Test frames for "Liveness" processing.  In this case, the
     LIVTIME was set to 10 seconds.
  3) Each of these Test frames must pass through the TCP/IP
     FastUDP layer, which acquires the UCB lock exclusively to
     update route as well as policy information.
  4) In this configuration, a combination of a busy system
     which is receiving large numbers of device interrupts
     along with UCB lock contention seems to be causing TCP/IP
     DUCBs to become suspended.  This leads to a slowdown of
     outbound EE traffic and a growth in ECSA.  In this case,
     ECSA growth expands until it is exhausted leading to the
     reported abends.
  Note: In the dump provided, there were over 2200 DUCBs
     suspended on the UCB lock.  Most of these were for
     EE test request/responses to EE connections.
  

Problem conclusion

• Enterprise Extender processing for outbound port 12000 traffic
  has been optimized to better handle large amounts of outbound
  traffic.  The basic design is for VTAM to pass a new queueing
  structure, IUTIPNEE, along with IUTIL PLISTs to the TCP/IP
  stack when crossing the IUTSAMEH connection.
  
  This new queueing structure is similar to the IUTRPNEE
  structure which VTAM passes for HPR traffic originating from
  this host.  One IUTIPNEE structure exists for each local
  static VIPA active for EE.  This new structure allows
  a serialization point for outbound port 12000 traffic.  If
  FastUDP is busy processing a previous signal for EE, a new
  request will simply queue up on this structure and exit
  processing.  This exit alleviates the need for the
  running DUCB as well as the SRB itself.  When the previous
  process finishes up the current request, it will simply
  continue to process the remaining elements until all
  outbound work is complete.
  

Temporary fix

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

Comments

APAR Information

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

  OA40347

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

  UA67884

Modules/Macros

• INNERMAP ISTACMDT ISTAUCAL ISTAUCCL ISTAUCDL
  ISTAUCIL ISTAUCIR ISTAUCLA ISTAUCOA ISTAUNCB ISTIPNCB ISTTSCRG
  ISTTSCWU ISTTSC89 IUTRPNEE
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R1C0 PSY UA67884

     UP13/03/15 P F303 Ž

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.