OA07440: REPETITIVE IST1488I ACTIVATION AS PASSIVE PARTNER MESSAGES ENTERPRISE EXTENDER SNASW CPSVCMG RTP PIPE SENSE 08050000

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Multiple occurrences of message IST1488I ACTIVATION OF CNRxxxxx
  AS PASSIVE PARTNER are issued.  The CNR PU is different, but it
  is always as PASSIVE partner.  The CP-CP session fails and this
  message is issued:  IST663I BFTERM RECEIVED, SENSE 08050000.
  The resource in IST891I indicates the SNASW router generated
  the failure notification.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All using RTP connections.                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: CP-CP session with Network Node         *
  *                      server fails with sense 08050000.       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Sample Configuration:
  
                  CISCO
                  SNASw
         NNS1 ==== EN1 ==== NNS2
               EE       EE
  
  
  The problem is summarized as follows:
  
  1) End Node 1 (EN1) has EE connections to both NNS1 and NNS2.
     EN1 has CP-CP session (CPSVCMG RTP pipe) to its primary
     network node server (NNS1).  In this configuration, EN1 is
     a CISCO SNASw.
  
  2) At some point in time, the CISCO SNASw believes there are
     connectivity problems to NNS1 and terminates its end of
     the CPSVCMG RTP pipe.  No RTP termination flows are sent to
     NNS1.
  
  3) The SNASw tries to reestablish the CP-CP RTP pipe to
     the primary NNS (NNS1).  A connection setup request is
     sent to NNS1 for the CPSVCMG COS.  The connection setup
     contains a BIND RU to reestablish the CP-CP sessions.
  
  4) The new RTP pipe is created on NNS1, and the BIND RU
     forwarded to VTAM half session processing.
  
  5) VTAM APPC half session rejects the BIND with sense 08050000
     since CP-CP sessions still exist to this partner.  The
     original CPSVCMG pipe and its sessions still exists to this
     EN partner.
  
    Console log shows the following error:
  
    IST1488I ACTIVATION OF RTP CNRxxxxxx AS PASSIVE TO netid.snasw
    IST663I  BFTERM REQUEST FROM xxxxxxxx RECEIVED, SENSE=08050000
    IST664I  REAL  OLU=xxxxxxxx  REAL  DLU=xxxxxxxx
    IST891I  xxxxxxxx.xxxxxxxx   GENERATED FAILURE NOTIFICATION
  
  6) The CISCO SNASw retries this sequence (roughly 6 times). Each
     time a new CPSVCMG RTP pipe is created, the BIND fails, and
     the latest CPSVCMG RTP pipe is terminated.
  
  7) The CISCO SNASw then sends a connection_setup request (with
     SNASVCMG BIND) to its backup network node server (NNS2).
  
  8) The CPSVCMG RTP pipe and CP-CP sessions from the SNASw are
     successfully established to the NNS2.
  
  9) At this point in time, both network node servers display RTP
     pipes (and sessions) to this end node.
  

Problem conclusion

• To resolve the CPSVCMG RTP pipe problem, the basic idea is to
  use the inbound connection setup request (CPSVCMG COS) as
  a signal that the partner has reset its end of the CPSVCMG
  RTP pipe.  Receipt of the connection setup will cause VTAM
  to verify existing RTP connections to the partner.
  
  The following modules have been modified to implement this
  function:
  
  ISTRCCSP -  When processing a connection setup for the CPSVCMG
  COS, code has been added to find any existing CPSVCMG RTP pipes
  to the originating RTP endpoint.  If a CPSVCMG RTP
  pipe exists already, and the RTP pipe is connected via a one
  hop Enterprise Extender connection, each RTP pipe associated
  with this Enterprise Extender connection is processed as
  follows:
    a) RPN_SIM_LIVTIME_EXP bit is turned on
    b) RPNCB PC PAB (ISTRPCRT) is scheduled to process the
       simulated liveness timer expiration
  
  ISTRPCCS - Has been changed to unconditionally reset the
             RPN_SIM_LIVTIME_IN_PROGRESS bit.
  
  ISTRPCRS - If the RPN_SIM_LIVTIME_IN_PROGRESS bit is on, code
             has been changed to force a maximum value on the
             short request timer to 500 milliseconds.  This code
             only runs for CP-CP pipes.
  
  ISTRPCRT - Code has been added to allow module ISTRPCTL to be
             called for all RTP pipes when the RPN_SIM_LIVTIME_EXP
             bit is on.  For CP-CP pipes, the
             RPN_SIM_LIVTIME_IN_PROGRESS bit is turned on prior to
             calling ISTRPCTL.
  
  ISTRPCTR - Code has been added to force CP-CP RTP termination
             if the RPN_SIM_LIVTIME_IN_PROGRESS bit is on
             when processing the final short request
             timer expiration.
  
  ISTRPNCB - Has been modified to define two new bits:
             RPN_SIM_LIVTIME_IN_PROGRESS -  simulated LIVENESS
             timer in progress for OneHop EE CP-CP pipe.
  
             RPN_SIM_LIVTIME_EXP  - Simulated liveness timer
                                    expiration.
  
  This APAR also addresses a second issue dealing with RTP
  pipe termination.  During RTP path switch processing, when
  VTAM fails to path switch an RTP pipe, or terminates a
  path switching pipe due to retry exhaustion, VTAM currently
  does not notify the partner that the RTP pipe is terminating.
  VTAM will now send a connection fault segment to the RTP
  partner with a SENSE A00200001.  This connection fault is
  simply a last ditch effort to inform the RTP partner to
  terminate its end of the RTP pipe.  This flow is being sent
  to save the partner time in discovering the RTP pipe is no
  longer valid.  At times it has been observed that RSETUP
  pipes can get out of synchronization.  One side of the
  RTP pipe may exist, but the partner node has no knowledge
  of the RSETUP pipe.  Liveness timer processing does not
  exist for RSETUP pipes.  The code being enhanced here is
  to try to notify the partner of RTP pipe termination
  in hopes to keep each synchronized.
  
  The following changes have been made to implement this
  new function:
  
  ISTSNS -  Has been modified to define a new architected
  sense code for HPR connection fault segments.  New sense code,
  SNSRPCFN, has been defined as x'A00200001'.  This sense code is
  sent in a connection fault segment to inform the RTP partner
  this end of the pipe is terminating.  The RTP partner should not
  treat this as an error case, but rather terminate their
  endpoint without alerts.
  
  ISTRPCRC - Has been changed to avoid issuing SALERT
             CPHP005 when a connection fault is received from the
             partner RTP with either SENSE 80200007 or A0020001.
  
  ISTRPCSW - Segment INACTREQ has been changed to unconditionally
             send a connection fault with sense A0020001 when an
             RTP pipe is being terminated.  This allows
             the partner to be notified that this end of the RTP
             pipe is terminating.
  
  ISTRPCTR - Segment INACTREQ has been
             changed to unconditionally send a
             connection fault with sense A0020001 when an
             RTP pipe is being terminated.
  
  The following documentation changes have been made:
  
  z/OS Communications Server : IP and SNA Codes
  Chapter 1 : SNA sense codes
  
  1) Modify the description of the A0XX (RTP sense data) category
     as follows:
  
  A0XX (RTP sense data)
  
  This category generally indicates when an RTP machine detects a
  protocol violation and terminates the RTP connection.  The
  A002 category of sense codes does not indicate a protocol
  violation has been detected.
  
  2) Add the following description of the A002 category of
     RTP sense data (after A001 and before A018):
  
  Sense code A002
  
  The RTP connection is terminating.
  
  Bytes 2 and 3 following the sense code contain
  sense-code-specific information.
  
  0001
      Sense code sent in a connection fault to inform the RTP
      partner this end of the pipe is terminating.  The RTP
      partner should not treat this as an error case, but rather
      terminate its endpoint without issuing an alert.  This flow
      may occur as a last ditch effort, after a failure to path
      switch, to notify the RTP partner that the pipe is being
      terminated.  The partner RTP should clean up its end of
      the connection upon receipt of the connection fault.
  

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:

  UA11025 UA11026 UA11027

Modules/Macros

• ISTRCCSP ISTRPCCS ISTRPCRC ISTRPCRS ISTRPCRT
  ISTRPCSW ISTRPCTR ISTRPNCB ISTSNS
  

Fix information

• Fixed component name

  VTAM V4 MVS/ESA

• Fixed component ID

  569511701

Applicable component levels

• R140 PSY UA11025

     UP04/06/21 P F406 Ž

• R150 PSY UA11026

     UP04/06/21 P F406 Ž

• R160 PSY UA11027

     UP04/06/21 P F406 Ž

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.