OA25383: IST1494I PATH SWITCH FAILED IST1495I NO ALTERNATE ROUTE AVAILABLE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An RTP pipe is brought up over an EE GVRN between network nodes
  in 2 different networks.  A MODIFY RTP command is issued to
  force a path switch, or a network outage occurs over the GVRN.
  The first path switch succeeds.  However, subsequent attempts
  to path switch this RTP pipe fail with NO ALTERNATE ROUTE even
  though there is an alternate route available through the EBNs.
  The problem is the RPN_LOCATE_REQ bit is not set for the RTP
  pipe. RTP asks TRS for a route without passing any TGs and the
  route request fails. A locate needs to be sent to learn the
  possible TGs for the new RTP pipe path.
  
  F NET,RTP,ID=CNR00001
  IST097I  MODIFY   ACCEPTED
  IST1494I  PATH SWITCH FAILED    FOR RTP CNR00001 TO
  NETB.SSCPB
  IST1495I  NO ALTERNATE ROUTE AVAILABLE
  IST314I  END
  
  This failure will only occur when the 2 RTP endpoint nodes are
  defined as Network Nodes. If either side is an End Node or an
  Extended Border Node, or the RTP is for MNPS sessions, then
  path switches will always succeed.
  

Local fix

• Make one side of the pipe an End Node or an EBN.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All who configure NNs (which are not EBNs)   *
  *                 with connections to Enterprise Extender      *
  *                 (EE) Global Virtual Routing Nodes (GVRNs).   *
  ****************************************************************
  * PROBLEM DESCRIPTION: RTP pipes established over dynamic      *
  *                      GVRN links between 2 non-EBN NNs in     *
  *                      different APPN networks will path       *
  *                      switch successfully once.  But all      *
  *                      subsequent attempts to path switch      *
  *                      fail with NO ALTERNTATE ROUTE even      *
  *                      though an alternate path exists         *
  *                      through the EBNs.                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem occurred in the following configuration:
  
  A.NN1 ----- A.BN2 ---/--- B.BN3 ----- B.NN4
    |                                     |
    +--------------EE GVRN----------------+
  
  In order to compute an alternate path for an RTP pipe that
  crosses an APPN/EBN network boundary (like an RTP pipe between
  A.NN1 and B.NN4), a new search must be sent to find an
  alternate path, collect the necessary TG vectors and compute
  the route in each APPN subnetwork.  The RPN_LOCATE_REQ flag
  is set in the RPNCB for each RTP pipe that crosses network
  boundaries to indicate that a new search (Locate) is required
  when path switching.
  
  The RPNCB flag is set based on a similar bit in Route_Setup.
  But VTAM generally only sets this flag in Route_Setup when VTAM
  is configured as an end node (EN) or an extended border node
  (EBN), as both types of nodes typically require that a new
  search be sent for every path switch to obtain the necessary TG
  vectors to compute the new path.
  
  In this specific case, the only nodes on the RTP path are the 2
  network nodes (A.NN1 and B.NN4), which are not EBNs.  The RSCV
  that is computed uses an EE global virtual routing node (GVRN)
  to cross the network boundary, which results in a dynamic EE
  link being created directly between A.NN1 and B.NN4.  But
  because neither node is an EN or EBN, the RPN_LOCATE_REQ flag
  is never set.
  
  The reason the first PATH SWITCH succeeds is because VTAM has
  not yet computed the "end-to-end weight" of the path taken by
  the cross-network RTP pipe.  (The "end-to-end weight" of the
  RTP is needed to determine if the new path has a lower weight
  than the existing path, which determines if the RTP should be
  path switched.)  The end-to-end weight is computed during the
  very first path switch for an RTP pipe by forcing a new search
  to be sent.  However, once the end-to-end weight is computed,
  subsequent attempts to path switch this RTP pipe fail because
  a new search is no longer sent.
  

Problem conclusion

• ISTRPCSW is changed to set the RPN_LOCATE_REQ flag in the RPNCB
  when a reply is received for a search that is sent before a
  possbile path switch.  The RPN_LOCATE_REQ flag is set based on
  whether the target of the search (the CP NAME of the node on
  the other end of the RTP) is found to be non-native.
  
  ISTRPCRT is included in this APAR for maintenance purposes.
  

Temporary fix

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

Comments

APAR Information

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

  OA24475

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

  UA41539

Modules/Macros

• ISTRPCRT ISTRPCSW
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R1A0 PSY UA41539

     UP08/06/24 P F806

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.