PI05583: GROWTH OF SP231K6 ECSA STORAGE WITH STRANDED SKMB/SKDB ZBLOCKS

APAR status

• Closed as program error.

Error description

• ECSA storage in use is growing on a system with a fairly steady
  rate of new x'3000' byte areas.  These areas will start with an
  ITSH eye-catcher at +18, then repeated 128 byte areas with SKMB
  and SKDB eye-catchers.
  
  The configuration that can lead to this growth is having
  Enterprise Extender (EE) enabled, outbound routes defined
  (static or dynamic) to partner systems that use non-QDIO devices
  (CLAW, CTC, LCS, XCF), and those partner systems regularly
  sending null XID (liveness test) or EEDIAG messages.
  
  
  Additional confirmation:
  
  Half of the stranded SKMBs will have:
     -0C  Pointer to EZBUDBYP +2CC2
     +0C  Non-zero pointer to another SKMB
     +20  Starting pointer somewhere in ECSA
     +24  Ending pointer that will be +15C from the previous value
     +4C  Same value as +20
  
  The SKMB referenced from +0C above will have:
  
     -0C  Pointer to EZBUDBYP +EFxx (will vary by PTF level)
     +0C  00000000
     +20  Starting pointer, probably to somewhere in ECSA
     +24  Ending pointer that will be either +3 (null XID) or +30
          (EEDIAG) from the starting pointer
     +48  Either 00000000 (meaning ECSA) or non-zero (meaning the
          ALET for a CSM data spece)
     +4C  Same value as +20
     +50  The length implied by +24 above.
  
  The areas referenced from these SKMBs will not have any
  meaningful data, except possibly a few very recently used
  entries.  For those that still show valid data, the first
  starting pointer will have an IUDR eye-catcher and the IP and
  UDP headers for the outbound packet will be at +140.
  

Local fix

• - If partner system is sending a large number of EEDIAG
     requests, see if these can be disabled (or at least reduced).
  
   - Consider increasing the LIVTIME specification on the partner
     system.
  
   - Ensure that routing tables favor routes using QDIO devices.
     if possible.  For dynamic routes, this is accomplished by
     configuring an appropriate cost on the interface.
  

Problem summary

• ***************************************************************
  * USERS AFFECTED:  All users of the IBM Communications Server *
  *                  for z/OS Version 2 Release(s) 1 IP:        *
  *                  Enterprise Extender (EE)                   *
  ***************************************************************
  * PROBLEM DESCRIPTION:  ECSA storage growth with Enterprise   *
  *                       Extender (EE) enabled using routes to *
  *                       partner systems over non-QDIO devices *
  *                       (such as CLAW or MPCPTP) when sending *
  *                       null XID (liveness test) or EEDIAG    *
  *                       messages                              *
  ***************************************************************
  * RECOMMENDATION:  apply PTF                                  *
  ***************************************************************
  When the stack sends an EE test probe
  or null XID reply over an interface
  other than OSA-Express QDIO, HiperSockets,
  or IUTSAMEH, it is not freeing the
  message triple associated with the send.
  

Problem conclusion

• Ensure message triple is freed when sending
  EE test probe or null XID reply
  

Temporary fix

Comments

APAR Information

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

  PI05014

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

  UI12361

Modules/Macros

• EZBIFOUT EZBUDBYP EZBIFIUT
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels