OA28031: CSA STORAGE GROWTH IN VTAM TIPAC EXTENDED POOL ACCOMPANIES REPEATED ENTERPRISE EXTENDER CONNECTION FAILURES

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When Enterprise Extender connection failures occur due to an
  incorrect local IP address being presented by VTAM to the TCP/IP
  stack, storage growth in the extended TIPAC pool in ECSA may
  result.  When an XCA Major Node with multiple EE lines is
  activated, VTAM attempts a samehost connection to the stack
  using each defined line, until a connection succeeds or all of
  the lines have been tried.  If the local IP address used by
  VTAM is not defined as a static VIPA address in the TCP/IP
  stack, all of these connection attempts will fail.  When the
  attempt to connect using all of the lines is unsuccessful,
  large numbers of TIPACs containing ENABLE indications are
  allocated but are never freed.
  

Local fix

• Ensure that the IP address for Enterprise Extender defined in
  VTAM matches a static VIPA address defined in the TCP/IP
  stack.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All using Enterprise Extender connections.   *
  ****************************************************************
  * PROBLEM DESCRIPTION: ECSA storage growth in TIPACX GETBLK    *
  *                      storage pool after repeated EE          *
  *                      activation failures.                    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is summarized as follows:
  
  1) At VTAM initialization, the EE XCA major node is
     automatically activated in an attempt to establish
     connectivity with the local TCP/IP stack.
  2) VTAM is configured with an invalid IPADDR (VIPA) start
     option.  The VIPA is not defined to the local TCP/IP
     stack.
  3) The EE line activation fails as expected since the local
     TCP/IP stack does not have the VIPA configured.
  
    v net,act,id=lnip1
  
    IST097I VARY ACCEPTED
    EZD0800I TCPIP1 IP ADDRESS xx.xx.xx.xx IS NOT VALID FOR USE IN
             ENTERPRISE EXTENDER
    EZD0802I TCPIP1 ENTERPRISE EXTENDER CONNECTION FAILURE ON
             IP ADDRESS xx.xx.xx.xx REASON 00000008
    IST1685I TCP/IP JOB NAME = TCPIP1
    IST1680I LOCAL IP ADDRESS xx.xx.xx.xx
    IST1683I HPR/IP CALL FAILURE: ID = XCAIP STATUS = 081Axxxx
    IST380I ERROR FOR ID = xxxxxxxx - REQUEST: ACTLINK
            SENSE: 081C0000
    IST105I LNIP1 NODE NOW INACTIVE
  
  4) No traces were available in the original error scenario that
     led to the storage growth.  However, it has been determined
     that the internal control blocks (SAP,FILTER) representing
     the IUTSAMEH connection from VTAM's perspective are not
     cleaned up.  It is believed the an error occurred during the
     processing of the CM_CALL_SETUP_IND signal.  The failure
     may have resulted from a storage shortage or an IUTIL
     failure.
  
  5) In this scenario, an automated CLIST tried to activate the
     EE XCA major node at 10 minute intervals.  There were 30
     lines in the XCA major node that caused many IUTSAMEH
     activation attempts to fail as documented in step 3.
     Many of these attempts suffered the same "unknown" error
     described in step 4.
  
     After many activation failures, there will be multiple
     SAP and FILTER control blocks stranded for the EE
     samehost connection.  In this example, a display of
     the IUTSAMEH connection shows multiple IST1717I messages
     with an ULPID of XCAIP (EE XCAmajor node name).  This
     signifies that old SAP control blocks for the
     EE VIPA are being stranded and this problem may be
     occurring. Generally, the IUTSAMEH connection only shows
     one IST1717I message for each upper layer protocol.
     In this example, there are many IST1717I message for
     XCAIP.
  
     d net,id=iutsameh
  
      IST097I DISPLAY ACCEPTED
      IST075I NAME = IUTSAMEH, TYPE = TRLE
      IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
      IST087I TYPE = LEASED             , CONTROL = MPC ,
              HPDT = YES
      IST1954I TRL MAJOR NODE = ISTTRL
      IST1715I MPCLEVEL = HPDT       MPCUSAGE = SHARE
      IST1717I ULPID = XCAIP
      IST1717I ULPID = XCAIP
      IST1717I ULPID = XCAIP
      IST1717I ULPID = XCAIP
      IST1717I ULPID = TCPIP1
      IST1500I STATE TRACE = OFF
      IST314I END
  
      For this specific problem, the TIPACX storage pool is
      growing after each activation failure.  You may monitor
      this storage over time.  A sample display follows:
  
      d net,storuse,pool=tipacx
  
      IST097I DISPLAY ACCEPTED
      IST350I DISPLAY TYPE = STORAGE USAGE
      IST1242I POOL     CURRENT MAXIMUM
      IST1243I TIPACX        28      32
      IST1454I 1 POOL(S) DISPLAYED
      IST314I END
  
  6) Although, internal control blocks (SAP, FILTERs) are being
     stranded as described by step 4, a more severe storage growth
     occurs.  Because the SAP and FILTER control blocks are
     not cleaned up, IUTSAMEH believes these are available for
     FastUDP connectivity.
  
  7) This causes each subsequent line activation (initiating port
     activation sequence) to strand CM_ENABLE_IND TIPACs.  When
     ISTAUCPF issues the CM_ENABLE_Req to enable the FastUDP
     protocol, CM_ENABLE_Inds are sent to each of the "stranded"
     SAPs that have allocated Filters for FastUDP.  Module
     ISTAUCIS (signal interpreter) is driven to process the
     CM_Enable_Ind, but is rejected as the signal does not
     originate from the TCP/IP stack (RC=6).  Module IUTLLCS4
     sees the error returned from ISTAUCIS, but does not
     discard the CM_Enable_Ind TIPAC.  This causes the TIPACX
     storage subpool to creep over time as the number of
     activation attempts increase over time.
  
     As discussed earlier, there is an unknown timing window
     which has not been diagnosed at this point.  The activation
     should fail, but the "unknown" error in step 4 has not
     been identified at this point.  This APAR does not address
     this issue as the necessary documentation was not available
     to understand this condition.
  
     This APAR does address the CM_ENABLE_IND TIPACs that
     are lost during the EE activation failures.
  

Problem conclusion

• FILTERMF.PLXMAC - Modified procedure Handle_Matching_Rem_Filter
                    to issue a TSALERT to free up the
                    CM_Enable_Ind Tipac should the signal
                    interpreter return an error.
  IUTLLCS4 - Recompile Only.
  
  ISTAUCLA - Included for maintenance purposes.
  

Temporary fix

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

Comments

APAR Information

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

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

  UA46424 UA46425 UA46426 OA28881

Modules/Macros

• FILTERMF ISTAUCLA IUTLLCS4
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R1A0 PSY UA46424

     UP09/05/05 P F905

• R180 PSY UA46425

     UP09/05/05 P F905

• R190 PSY UA46426

     UP09/05/05 P F905

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.