HP Services Software Patches - vaxlavc04_u2055

Copyright (c) Digital Equipment Corporation 1994, 1995.  All rights reserved.

PRODUCT:     OpenVMS VAX

COMPONENTS:  PEDRIVER.EXE
             SDA.EXE
             XQDRIVER.EXE

SOURCE:      Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  VAXLAVC04_U2055
     ECO Kits Superseded by This ECO Kit:  VAXLAVC03_U2055 (CSCPAT_1081)
                                           VAXLAVC02_U2055
     ECO Kit Approximate Size:  1550 Blocks
     Kit Applies To:  OpenVMS VAX V5.5-2 Only
     System Reboot Necessary:  Yes


ECO KIT SUMMARY:

An ECO (patch) kit exists for PEDRIVER on OpenVMS VAX V5.5-2.  This
kit addresses the following problems: 

Problems Addressed in the VAXLAVC04_U2055 Kit:

  o  The sequence message timeout value used to initiate retransmission
     is based on the computed round trip time instead of a fixed value 
     as in previous version of PEDRIVER.  This significantly reduces the
     timeout delay when retransmission is necessary.

     This fix also sends one message a time and waits for the ACK during
     the retransmission. 

     This change also fixes the problem where retransmission from a
     global page results in an ACCVIO. 

     These problems are fixed in OpenVMS VAX V6.0

  o  Nodes in a LAVc (Local Area VAXcluster) may CLUEXIT in mixed
     ENET/FDDI environments where duplicate hello messages are being
     produced (i.e. out-of-rev bridge firmware). 

  o  The default HELLO message interval was changed from 3 seconds +/- .7
     seconds to 3 seconds +0 seconds/-1.4 seconds.  Earlier baselevels of
     V6.0 could break the Virtual Circuit (VC) after loosing a single
     HELLO message if the network delays were long and two HELLO messages
     were sent with an interval of 3.7 seconds.  This change restores the
     behavior seen with V5.5-2 of providing for a long (up to 2 seconds)
     network delay (PEDRIVER to PEDRIVER). 
 

Problems Addressed in the VAXLAVC03_U2055 Kit:

  o  Network congestion problems may exist on an LAVc and will
     manifest as anything from slow performance to broken Virtual 
     Circuits and CLUEXIT crashes.  On a VAXstation 4000 Model 90,
     this may cause an INVEXCEPTN bugcheck at PEDRIVER+060EC.

     This problem is fixed in OpenVMS VAX V6.0.

  o  If PEDRIVER receives a command while it is in a DISABLED state,
     it returns the command with an ABORT status.  No other ports
     generate this status, so it is treated as a malfunction and
     System Communications Services (SCS) crashes the port when it is
     received. 

     This problem is only likely to occur in a heavily loaded system.
     It (combined with the next two problems) can cause a system to
     get into a port-crash-and-reinit loop, which leads to a system
     crash if there is no other path to the system disk. 

     This problem is fixed in OpenVMS VAX V6.0.

  o  Datagram responses with a "Virtual Circuit Closed" status crash
     the port.  It is possible for datagrams to be passed to SCS with
     VC Closed status.  This only happens when there is insufficient
     non-paged pool to process the datagram command.  Since this is an
     illegal status for datagrams, SCS crashes the port. 

     This problem is fixed in OpenVMS VAX V6.0.

  o  When a port crash occurs, PEDRIVER does not purge entries on the
     response queue.  It is possible for these responses to be delivered
     to the port after it reinitializes, which can cause it to crash
     again.  The system is allowed 50 Virtual Circuit loss/reconnects. 
     If the port continues to crash and reinitialize, the system could
     potentially use its allotment of Virtual Circuit loss/reconnects and
     crash with a VAXport bugcheck. 

     This problem is fixed in OpenVMS VAX V6.0.

  o  The system may crash with a VAXport bugcheck if a Virtual Circuit
     is opened with no open channels.  Normally, after a port's
     Virtual Circuit closes, SCS submits a cache clear SNDMSG to the
     port.  SCS expects the message to fail with a "VC Closed" status.
     However, in certain cases, the Virtual Circuit may be open when
     SCS issues the cache clear, so the SNDMSG succeeds and the MSGSNT
     comes back with success status.  Since this possibility is not
     explicitly accounted for, a VAXport bugcheck may occur when a
     check of the opcode fails.

     This problem is fixed in OpenVMS VAX V6.0.

  o  When transmit chaining is in use, it is possible for the datalink
     to read the named buffer after the Virtual Circuit is closed
     potentially causing data corruption or a system crash.  This
     problem occurs when the Virtual Circuit shutdown routine does not
     wait for outstanding VCRPs to be returned before it reports that
     the Virtual Circuit is closed.

     This problem is fixed in OpenVMS VAX V6.0.

  o  XQDRIVER (for both the DELQA and the DEQTA) is not reporting the
     correct number of receive buffers to PEDRIVER.

     This problem is fixed in OpenVMS VAX V6.0.

NOTES:  All Q-bus systems in a LAVc running the repaired PEDRIVER
        must have version X-4 (or higher) of the XQDRIVER
        installed.  

        Various internal structures changed as a result of the
        fixes to PEDRIVER.  System Dump Analyzer (SDA), and the
        SCS and PEDRIVER symbol tables are included in  this  kit
        to allow proper SDA operation.  This also necessitated a
        change in [SYSLIB]LIB.MLB. 
 
        User applications only need to be relinked if they require
        assembly with the $PEMCOMPDEF and $PEMCLSTDEF macros.


INSTALLATION NOTES:

In order for the corrections in this kit to take effect, the system
must be rebooted.  If the system is a member of a VAXcluster, the entire
cluster should be rebooted.

Files on this server are as follows:

»vaxlavc04_u2055.README
»vaxlavc04_u2055.CHKSUM
»vaxlavc04_u2055.CVRLET_TXT
»vaxlavc04_u2055.a-dcx_vaxexe