OSMS OSMSAE02034 Optical Storage Management V3.4 Alpha ECO Summary

 
NOTE:  An OpenVMS saveset or PCSI installation file is stored
       on the Internet in a self-expanding compressed file.
       The name of the compressed file will be kit_name-dcx_vaxexe
       for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
 
       Once the file is copied to your system, it can be expanded
       by typing RUN compressed_file.  The resultant file will
       be the OpenVMS saveset or PCSI installation file which
       can be used to install the ECO.
 
Title:

*OSMS] OSMSAE02034 Optical Storage Management V3.4 (Alpha) ECO Summary
 
********************************************************************************

Copyright (c) Digital Equipment Corporation 1997.  All rights reserved.

PRODUCT:    DIGITAL Optical Storage Management Software for OpenVMS Alpha
            (DEC OSMS)

OP/SYS:     OpenVMS Alpha

SOURCE:     Digital Equipment Corporation

ECO INFORMATION:

     ECO Kit Name:  OSMSAE02034
     ECO Kits Superseded by This ECO Kit:  OSMSAE1034
     ECO Kit Approximate Size: 819 Blocks
     Kit Applies To:   DIGITAL Optical Storage Management Software V3.4
                       OpenVMS Alpha V6.2, 6.2-1H1, V6.2-1H2, V6.2-1H3
     System Reboot Necessary:  Yes


ECO KIT SUMMARY:

An ECO kit exists for DIGITAL Optical Storage Management Software on
OpenVMS Alpha V6.2 through V6.2-1H3.  This kit addresses the following
problems: 

Problems addressed in the OSMSAE02034 Kit:

  o  System failure due to INVEXCEPTN bugcheck at SMP$ACQUIRE_C+00024.

     The environment in which this problem can occur is:

     +  OSMS/Alpha version prior to V3.4-2 and
     +  an Alpha system attached to a RW5xx Series jukebox via a host
        based SCSI adapter, not via an HSC, HSD, or HSJ controller.

     Multiple jukebox configuration may see this problem more frequently.
  
     The problem can cause system operation to fail requiring reboot of
     operating system and restart of all applications.

     The problem was caused by a coding error in an error path of the
     OSMS components WDDRIVER.EXE or RZDRIVER.EXE.  The code path is
     invoked when a SCSI command fails due to device busy status. The
     specific cause of the error was due to the passing of an empty fork
     block to KP_STALL_FORK_WAIT macro.

     The OSMS components WDDRIVER and RZDRIVER have been modified to
     pass the  address of a valid fork block.  This correction is in
     WDDRIVER with the image file identification of "4.6-2" or higher
     and in the RZDRIVER with the image file identification of "1.1-1"
     or higher. 

Problems addressed in the OSMSAE1034 Kit:

  o  Each locally mounted jukebox volume would be placed in a jukebox
     drive when any node in the cluster was (re)booted.

     The environment in which this problem can occur is:

     +  OSMS V3.4 and
     +  an Alpha system attached to a RW5xx Series jukebox that is part
        of a VMScluster and
     +  the SYSGEN parameter MSCP_LOAD is zero and
     +  the system has any locally mounted jukebox volumes

     The processing of new I/O requests would be delayed until all of the 
     mounted jukebox volumes had been placed into a jukebox drive.

     This problem was caused due to the OSMS component, JKDRIVER,
     incorrectly setting the DEV$V_CLU bit in UCB$L_DEVCHAR2.  The setting
     of this bit told the MSCP server that it needed to ensure the unit
     characteristics are up to date in the server's UCB.  The MSCP server
     issues I/O to each mounted jukebox volume causing each volume to be
     placed in a jukebox drive. 

     The setting of the DEV$V_CLU bit in UCB$L_DEVCHAR2 is no longer done
     by the JKDRIVER.  This correction is in JKDRIVER with the image file
     identification of "4.5-0" or higher.

  o  Each clusterwide mounted jukebox volume would be placed in a
     jukebox drive when any node in the cluster was (re)booted.

     The environment in which this problem can occur is:

     +  OSMS V3.4 and
     +  an Alpha system attached to a RW5xx Series jukebox that is part
        of a VMScluster and
     +  the SYSGEN parameter MSCP_LOAD is one and
     +  the system has any jukebox volumes mounted clusterwide

     The processing of new I/O requests would be delayed until all of the
     mounted jukebox volumes had been placed into a jukebox drive when any 
     node in the cluster was (re)booted.

     The problem was caused by the actions of the MSCP server attempting to
     ensure the unit characteristics are up to date in the server's UCB.
     Part of the MSCP servers action in performing this task is an issuing
     of an IO$_NOP request to each cluster-wide mounted volume.  This was
     causing each clusterwide mounted jukebox volume to be placed in a
     jukebox drive so the I/O could be serviced.

     The OSMS component JKDRIVER has been modified to detect these IO$_NOP 
     I/O requests and treat these requests as special I/O. This special
     processing allows the IO$_NOP requests to be serviced  without placing
     each jukebox volume in a jukebox drive.  This correction is in
     JKDRIVER with the image file identification of "4.5-0" or higher.


INSTALLATION NOTES:

The ECO kit checks to ensure that a valid license is installed before 
proceeding.  If one is not found, the installation aborts.

The ECO kit checks to ensure that OSMS V3.4 is installed before 
proceeding.  If OSMS V3.4 is not found, the installation aborts.

The ECO kit will allow installation if V3.4 ECO 1 is installed or if
individually supplied IPMT solutions for these problems are installed.
The installation aborts if the images being modified do not meet these
requirements.

In order for the corrections in this kit to take effect, the system
must be rebooted.

Once the system has been rebooted, you can restart the software as
described in your existing documentation.

Colorado Site
Georgia Site

osmsae02034.README
osmsae02034.CHKSUM
osmsae02034.CVRLET_TXT
osmsae02034.a-dcx_axpexe