IBM Support

PK55520: OSPF ROUTES NOT LEARNED WHEN TCPIP IS STARTED BEFORE VTAM

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • OMPROUTE OSPF routes are not being learned if TCPIP is started
    before VTAM is initialized.  The device is active, however, no
    OSPF traffic is received over the interface.  This can occur
    as result of a timing problem where the multicast capable flag
    is not set on the device when Omproute is informed that the
    device is active.
    
    
    Keywords: ping timeout ospf routes multicast
    
    
    Verification steps:
    SYSTCPIP Ctrace with options LCS,VTAM,IOCTL
    will show that the response to the SendQIPAsst command is being
    received AFTER the response from the SendStartLAN and
    SendLANSTATS commands.
    

Local fix

  • Start VTAM before TCPIP.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the IBM Communications Server   *
    *                 for z/OS Version 1 Release 6, 7, 8 & 9 IP:   *
    *                 OSA devices in LCS mode                      *
    ****************************************************************
    * PROBLEM DESCRIPTION: A timing condition exists where an LCS  *
    *                      mode OSA may be activated before the    *
    *                      multicast capability has been           *
    *                      determined. As a result, the device     *
    *                      may start without multicast capability. *
    *                      Any application depending on multicast  *
    *                      capability may fail to function.        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    An OSA device in LCS mode is currently activated once the
    StartLAN and LANStats commands have completed. However,
    multicast capability is determined only after a separate
    command, QIPAsst, has completed. Normally QIPAsst completes
    before the other commands that activate the OSA. However,
    there is currently no guarantee of the order in which the
    commands complete.
    
    As a result, a timing window exists where an OSA device in LCS
    mode may be activated before the device's multicast capability
    has been determined. The timing window is more likely to occur
    when VTAM is started after TCPIP. A device activated before
    multicast capability has been determined is assumed to be
    multicast incapable. Any application depending on multicasting
    will fail to work on the multicast incapable devices. If the
    application involved is a routing daemon such as omproute, then
    no dynamic routes will be learned.
    +-------------------------------------------------------------+
    + Please check our Communications Server for OS/390 homepages +
    + for common networking tips and fixes.  The URL for these    +
    + homepages can be found in Informational APAR II11334.       +
    +-------------------------------------------------------------+
    

Problem conclusion

  • Module EZBIFIND has been amended to to change the order of the
    LANStats, QIPAsst, and StartLAN commands. QIPAsst is now issued
    first and is immediately followed by LANStats. The StartLAN
    command is only issued once a response for LANStats has been
    received. The QIPAsst command should complete by the time the
    StartLAN command is sent and a response to it is received.
    
    * Cross Reference between External and Internal Names
    

Temporary fix

Comments

APAR Information

  • APAR number

    PK55520

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    160

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2007-10-26

  • Closed date

    2007-12-06

  • Last modified date

    2008-02-02

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

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

    UK31973 UK31974 UK31975 UK31976

Modules/Macros

  • EZBIFIND
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R160 PSY UK31973

       UP08/01/23 P F801

  • R170 PSY UK31974

       UP08/01/23 P F801

  • R180 PSY UK31975

       UP08/01/23 P F801

  • R190 PSY UK31976

       UP08/01/23 P F801

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":"160","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":"160","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 February 2008