OA07428: EXCESSIVE RTP PATH SWITCH WHEN USING ENTERPRISE EXTENDER INTERMITTENT PERFORMANCE DEGRADATION

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• HPR delays due to storage allocation for EE test frames.  Thus
  VTAM initiates Path Switch due to short request retry limit
  exhausted. This Path Switch reason is initiated each time VTAM
  attempts to allocate storage for a Test Frame request.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All using large numbers of Enterprise        *
  *                 Extender connections.                        *
  ****************************************************************
  * PROBLEM DESCRIPTION: Intermittent performance problems due   *
  *                      to large numbers of Enterprise          *
  *                      Extender connections timing out.        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is summarized as follows:
  
  1) In this case, an Enterprise Extender (EE) configuration
     was comprised of thousands of PCOMM EE endpoints.
  2) Intermittently, performance problems are noticed on the
     zOS endpoint.  Generally, one external symptom noticed
     during the performance degradation is unexpected
     path switches for CPSVCMG RTP pipes.
  
     IST1494I  PATH SWITCH STARTED FOR RTP CNRxxxxx
     IST1818I  PATH SWITCH REASON: SHORT REQUEST RETRY LIMIT
               EXHAUSTED
     IST314I   END
  
     The path switches were occurring up to seven times in a
     thirty minute period.
  
  3) Diagnostic traces (VIT) and dumps were provided during times
     of performance degradation.  Analysis of the traces revealed
     that the RTP path switches were occurring because internal
     processes (PABs) were not being dispatched in a timely
     manner.  During this time, the trace showed hundreds of
     EE connections timing out.  This involved the AUNCB PU PABs
     allocating a TIPAC for an LDLC TEST request.  The TIPAC
     buffer was acquired from the TIPACX GETBLK storage pool.
     When large numbers of processes (AUNCB PU PABs) require
     storage from the TIPACX GETBLK pool, the requests
     result in VTALLOC requests.  Each VTALLOC request is
     a branch enter GETMAIN request which requires synchonization
     on a local memory lock.  Each of the AUNCB PU PAB SRBs
     is suspended by MVS while waiting for the local lock.
     When VTAM reaches a limit of 64 SRBs (per PST), no more
     processes can be dispatched.  VTAM is basically not running
     at this point.  This results in performance degradation
     for all other processes waiting to run in VTAM.  This
     results in slow logons, or slow response time.
  
  NOTE: This problem is more likely to occur in networks
     involving large numbers of Enterprise Extender connections.
     This problem was reported in a network involving EE
     connections to each workstation (PCOMM).
  

Problem conclusion

• The problem is resolved as follows:
  
  1) All AUDP modules which previously allocated GETBLK
     TIPACs for XID, DISC and TEST requests, are updated
     to REQSTORE a TIPAC instead.  The following modules
     have been changed to set a STORTYPE of REQSTORE on
     each GETTIPAC invocation:
  
     ISTAUCCL
     ISTAUCCR
     ISTAUCIL
     ISTAUCIR
     ISTAUCOL
     ISTAUCOR
     ISTAUCUL
  
     The GETTIPAC macro has been modified to allow for
     "available" XBUFLENTs to be used for data payload for
     EE connections.  For most LDLC signals, except large
     XIDs, the basic TIPAC REQSTORE buffer will be adequate.
     When the XID length exceeds the available space in
     the TIPAC, an IO buffer (REQSTORE) is acquired
     to hold the XID data.
  
  2) During problem diagnosis, it was noticed that many LDLC
     signals resulted in DSCD (DISCARD) VIT entries being traced
     for normal flow cases.  DSCD trace entries are meant to
     represent exception cases, not normal events.
     Modules ISTALCSF and ISTALCSX have been changed to
     pass a unique DISCARD reason code for each utility module
     (ISTAUCUL) invocation.  Module ISTAUCUL will then issue DSCD
     records for only exception cases.  Normal cases
     will be passed a zero DISCARD reason code which does
     not result in a DSCD entry.  Previously, all DSCD entries
     had a DISCARD reason of 1 from ISTAUCUL.  Now, DISCARD
     reasons 1-99 will be from ISTALCSF, and 100 - 199 from
     ISTALCSX.
  
     The ISTALCPL and ISTAUCPL control blocks have been
     changed to define the
     ALCPL_DISCARD_ROUTINE and AUCPL_DISCARD_ROUTINE
     parameter lists.
     These parameter lists are used by ISTALCSF and ISTALCSX
     to pass the discard code to the utility routine.
  
     Module ISTAUCUL has also been changed to issue the
     ?TSALERT with the passed reason code.
  
  3) Module ISTALCSF has been changed to trace the LDLC command
     for inbound LDLC flows.  Previously, the LDLC command
     was not available in the LDLC trace record.
  
  4) Module ISTAUCLA has been included for maintenance purposes.
  

Temporary fix

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

Comments

APAR Information

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

  OA07160

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

  UA10780

Modules/Macros

• GETTIPAC ISTALCPL ISTALCSF ISTALCSX ISTAUCCL
  ISTAUCCR ISTAUCIL ISTAUCIR ISTAUCLA ISTAUCOL ISTAUCOR ISTAUCPL
  ISTAUCUL ISTAUCXF
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R160 PSY UA10780

     UP04/05/28 P F405 Ž

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.