Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp

more options
hp.com home
End of Jump to page title
HP Services software patches
Jump to content

» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

patches by topic
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

connection tools
» nameserver lookup
» traceroute
» ping

Find Support Information and Customer Communities for Presario.
Content starts here
OpenVMS VMS731_RMS-V0400 Alpha V7.3-1 RMS ECO Summary
TITLE: OpenVMS VMS731_RMS-V0400 Alpha V7.3-1 RMS ECO Summary
NOTE:  An OpenVMS saveset or PCSI installation file is stored
       on the Internet in a self-expanding compressed file.
       For OpenVMS savesets, the name of the compressed saveset
       file will be kit_name.a-dcx_vaxexe for OpenVMS VAX or
       kit_name.a-dcx_axpexe for OpenVMS Alpha. Once the OpenVMS
       saveset is copied to your system, expand the compressed
       saveset by typing RUN kitname.dcx_vaxexe or kitname.dcx_alpexe.
       For PCSI files, once the PCSI file is copied to your system,
       rename the PCSI file to kitname.pcsi-dcx_axpexe or
       kitname.pcsi-dcx_vaxexe, then it can be expanded by typing
       RUN kitname.pcsi-dcx_axpexe or kitname.pcsi-dcx_vaxexe.  The
       resultant file will be the PCSI installation file which can be
       used to install the ECO.
New Kit Date:       18-JUN-2003
Modification Date:  NONE
Modification Type:  NEW KIT

Copyright (c) Hewlett-Packard Company 2001,2002,2003.  All rights reserved.

OP/SYS:     OpenVMS Alpha


SOURCE:     Hewlett-Packard Company


     ECO Kit Name:  VMS731_RMS-V0400
     ECO Kits Superseded by This ECO Kit:  VMS731_RMS-V0300
     ECO Kit Approximate Size:  2816 Blocks
     Kit Applies To:  OpenVMS Alpha V7.3-1
     System/Cluster Reboot Necessary:  Yes
     Rolling Re-boot Supported:  Yes
     Installation Rating:  INSTALL_1
                            1 - To be installed by all customers.
     Kit Dependencies:

       The following remedial kit(s) must be installed BEFORE
       installation of this kit:


       In order to receive all the corrections listed in this
       kit, the following remedial kits should also be installed:



An ECO kit exists for RMS on OpenVMS Alpha V7.3-1.  This kit addresses the 
following problems: 


     o  Fix to prevent an INVEXCEPTN  system  bugcheck  with  Multiple
        Kernel Threaded applications.

        This fix prevents  an  INVEXCEPTN  system  bugcheck  that  was
        introduced by the VMS731_RMS-V0300 kit when executing an image
        that  uses  Multiple  Kernel  Threads.   To  determine  if  an
        application  is  at  risk, the following command can be issued
        against the application image from the OpenVMS command prompt:

            $ THREADCP/SHOW {application_image.exe}

            If the following two lines are observed in the resulting
            display, then  the application is using  Multiple Kernel
            Threads and is at risk: 

            %THREADCP-I-MKT, multiple kernel threads are enabled
            %THREADCP-I-UPC, upcalls are enabled

        Images Affected:[SYS$LDR]RMS.EXE

     o  Fix to prevent an erroneous RMS-F-DIR error if attempt to set
        a default directory exceeding 255 bytes.
        This fix prevents an RMS-F-DIR error status being returned
        when an attempt is made to execute a set default (either from
        DCL or from program control) to a directory string that
        exceeds 255 bytes in length.  Prior to this fix, the command
        fails with an RMS-F-DIR status regardless of whether the path
        exists or not.
          Images Affected:[SYS$LDR]RMS.EXE
     o  RMS Journaling's detached recovery of an exclusively accessed
        file was performing recovery in asynchronous mode, allowing
        concurrent access to the file between the initiator of the
        recovery operation and detached recovery.  This correction
        forces the recovery to be in synchronous mode, blocking access
        to the file until recovery is complete.
          Images Affected:[SYS$LDR]RMS.EXE
     o  This fix addresses a potential race condition in the RMS last
        chance handler (ABORT rundown) if the creator of a global
        section is terminated before the new section is completely
        initialized.  If another process is waiting to connect to the
        file, it might successfully map to the partially initialized
        section before it is deleted by the creator.  The mapping
        precludes the section from being deleted, since the creator is
        no longer the last (single) accessor.  Accessing the partially
        initialized section eventually results in a fatal accvio.
        This problem requires the creator process to be deleted
        ($delprc or stop/id), and is more likely to be triggered for a
        file that has frequent opens and closes with only one accessor
        from time to time (for example, SYSUAF.DAT).
          Images Affected:[SYS$LDR]RMS.EXE
     o  The RMS Journaling Detached Recovery Server process can
        potentially be a large consumer of resources during a detached
        recovery operation.  This change enforces an intended cap to
        the number of files that an individual recovery server will
        accept work for, reducing the amount of resources required by
        sharing the work between multiple recovery servers.
          Images Affected:[SYSEXE]RMSREC$SERVER.EXE
     o  A nonfatal RMS bugcheck with an R2 value of FFFFFFDF (BADBLB)
        could be signaled for a process if a blocking lock AST was
        delivered to the process while RMS was busy closing the same
        file.  This fix prevents the nonfatal bugcheck by properly
        handling the arrival of the untimely AST.
          Images Affected:[SYS$LDR]RMS.EXE


     o  RMS fix for directory not found errors when copying to a
        spooled device.

        Copying a file to a spooled device will result in the
        following errors under OpenVMS Alpha V7.3-1:

           %COPY-E-OPENOUT, error opening TTA0:[DIR]FILE.EXT;1 as output
           -RMS-E-DNF, directory not found
           -SYSTEM-W-NOSUCHFILE, no such file

        These errors are the result of a change to the RMS directory
        path cache code in support of merging Posix support into RMS.
        For spooled devices, RMS was applying defaults to missing
        portions of the file specification, including a defaulted
        directory.  Prior to the V7.3-1 change, this was a harmless
        operation since the directory portion was ignored for a
        spooled device.  With the added Posix support, the defaulted
        directory specification is now validated resulting in the
        directory not found error.  Since spooled files are not
        entered into a directory, a change has been implemented to
        bypass the validation of the directory for a spooled device.


        While the following is not directly related to this fix, from
        the reports that we received from the field of this problem,
        it appears that some users may need a reminder of the proper
        procedures they should use when setting a device /SPOOLED.
        The user setup error that can occur if proper procedures are
        not followed is not new to OpenVMS V7.3-1.  We are simply
        taking this opportunity to share the proper procedures so this
        user setup problem can be avoided.

        The target queue of the spooling operation must either be
        explicitly specified on the SET command line, or a queue with
        the same name as the spooled device must exist.
        When issuing a $SET DEVICE/SPOOLED command, failure to
        explicitly specify a target queue name will default the queue
        name to that of the spooled device.  Failure to specify a
        valid existing queue name will result in subsequent attempts
        to copy to the device to fail with a file deaccess failure
        (RMS-E-DAC) during the close operation.

        The following is an example of implicitly specifying the queue
        name as "LTA69":

           $ SET DEVICE/SPOOLED LTA69:

        In this example, the queue name has been derived from the
        device name since it was not explicitly specified.  Failure to
        ensure that the implicit queue name (LTA69) exists will cause
        all subsequent use of the spooled device to fail with a
        deaccess failure.

        This is the same as issuing the following command:


        The following is an example of explicitly specifying the queue


        An example of an explicit specification where the queue name
        is "LATQUE" might be:


        Failure to ensure that the specified queue exists (either
        implicit or explicit), will result in the errors seen below.
        This example presumes that the LTA69 queue does not exist:

             $ SET DEVICE/SPOOLED LTA69:
             $ COPY LOGIN.COM LTA69:
             %COPY-E-CLOSEOUT, error closing LTA69: as output
             -RMS-E-DAC, ACP file deaccess failed during $CLOSE
             -SYSTEM-F-NOTPRINTED, failed to queue spool file for print

          Images Affected:[SYS$LDR]RMS.EXE

     o  RMS fix to prevent a SSRVEXCEPT bugcheck when RU journaling is
        enabled for a file.

        A System Service Exception may occur under rare circumstance
        when RU journaling is enabled on a file.  The failure is due
        to the access of an invalid page (access violation).

          Images Affected:[SYS$LDR]RMS.EXE


This kit requires a system reboot.  HP strongly recommends that
a  reboot  is performed immediately after kit installation to avoid
system instability

If you have other nodes in your OpenVMS cluster, they must also  be
rebooted  in  order  to make use of the new image(s).  If it is not
possible or convenient to reboot the entire cluster at this time, a
rolling re-boot may be performed.


Install this kit with the POLYCENTER Software installation utility
by logging into the SYSTEM account, and typing the following at the
DCL prompt:


The kit location may be a tape drive, CD, or a disk directory that
contains the kit.

Additional help on installing PCSI kits can be found by typing
HELP PRODUCT INSTALL at the system prompt

Special Installation Instructions:

     o  Scripting of Answers to Installation Questions

        During installation, this kit will ask and require user
        response to several questions.  If you wish to automate the
        installation of this kit and avoid having to provide responses
        to these questions, you must create a DCL command procedure
        that includes the following definitions and commands:



           -  Add the following qualifiers to the PRODUCT INSTALL
              command and add that command to the DCL procedure.


           -  De-assign the logicals assigned

        For example, a sample command file to install the
        VMS731_RMS-V0400 kit would be:

          $ exit

All trademarks are the property of their respective owners.

Files on this server are as follows:
privacy statement using this site means you accept its terms