IBM Support

OA25881: EE HPR PIPE HANGS DUE TO MAX NLP SIZE ERROR WHEN ANR ROUTING THROUGH V1R9 VTAM.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • EE HPR pipe hangs (hung) when a V1R9 VTAM is used as an ANR
    node on the HPR pipe.  When the HPR pipe sets up, and different
    maximum packet sizes are defined for the links involved in the
    pipe - the resulting maximum NLP (Network Layer Packet) can
    be incorrect (as seen in IST1511I of a display of the pipe).
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All with multi-hop RTP pipes which ANR route *
    *                 through a V1R9 host using EE.                *
    ****************************************************************
    * PROBLEM DESCRIPTION: Multi-hop RTP pipe may transmit more    *
    *                      data than one of the hops supports.     *
    *                      Enterprise Extender must also           *
    *                      be involved in the configuration.       *
    *                      HPR traffic may get fragmented in the   *
    *                      IP network leading to firewalls         *
    *                      discarding the EE packets.              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Sample Configuration:
    
    VTAM A    MTU 1400                MTU 1500      VTAM C
    APPL A =======EE======= VTAM B =======EE======= APPL C
    V1R8                    V1R9                    V1R8
    <--------------------CNR00005--------------------->
    
    1) APPL C initiates a sessions to APPL A.
    2) A multi-hop RTP pipe is setup with 2 APPN hops.  In this
       example, both APPN hops traverse EE connections.
    3) For this problem to occur:
       - An RTP pipee must ANR route through a node (VTAM B)
         that is at V1R9 or higher.  This ANR node (VTAM B)
         must also have at least one of its adjacent hops
         utilizing EE.
       - There must also be a variations in the maximum
         packet sizes which each link supports (which the
         RTP pipe traverses).  For an EE link, this is the MTU size.
         In this case, MTU values of 1400 and 1500 bytes are being
         used.
    4) When the RTP pipe is established from VTAM A to VTAM C,
       the maximum NLP size learned for each end of the pipe
       varies.  In this example, VTAM A displays the NLP size
       as 1469, while VTAM C displays it at 1369.
    5) Since the local link in VTAM A is 1400 bytes, HPR data
       sent to EE must be fragmented before it can be forwarded
       towards VTAM C.  In this case, UDP fragments are not
       permitted and some HPR packets are not delivered.
    6) The packets are reported as missing by VTAM C and
       the packets are retransmitted, fragmented and discarded
       over and over.
    7) All session utilizing this HPR pipe are hung.
    
    Note: If all nodes in this configuration are V1R9 or higher,
          this problem does not occur.
    

Problem conclusion

  • ISTRCCRB - Subroutine NON_VR_CV80_BLD has been corrected to
               correctly set the maximum packet size to be the
               minimum of the received value and the value
               of the EE MTU (for the specific priority of the
               RTP pipe).  This processing takes place during
               RSETUP flows during the creation of an RTP pipe.
    ISTRPCRT,
    ISTAUCLA - Included for maintenance purposes.
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    OA25881

  • Reported component name

    VTAM V4 MVS/ESA

  • Reported component ID

    569511701

  • Reported release

    190

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2008-07-17

  • Closed date

    2008-07-24

  • Last modified date

    2008-10-02

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

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

Modules/Macros

  • ISTAUCLA ISTRCCRB ISTRPCRT
    

Fix information

  • Fixed component name

    VTAM V4 MVS/ESA

  • Fixed component ID

    569511701

Applicable component levels

  • R1A0 PSY UA42540

       UP08/09/04 P F809 Ž

  • R190 PSY UA42541

       UP08/09/04 P F809 Ž

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"190","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"190","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 October 2008