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-V0300 Alpha V7.3-1 RMS ECO Summary
TITLE: OpenVMS VMS731_RMS-V0300 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:       05-MAY-2003
Modification Date:  26-MAY-2003

*									       *
* After installation of the DEC-AXPMS-VMS731_RMS-V0300--4.PCSI patch kit,      *
* systems may experience a crash due to an INVEXCEPTN bugcheck: 	       *
* Crashdump Summary Information:	                                       *
* ------------------------------		                               *
* Bugcheck Type: INVEXCEPTN, Exception while above ASTDEL		       *
* Current Image: $1$DGA1:[SYS0.SYSCOMMON.][SYSEXE]AMQZLAA0.EXE 		       *
* Failing PC: FFFFFFFF.800C4F08 __RELEASE_KERNEL_ACCVIO+004E4   	       *
* Failing PS: 00000000.00000801						       *
* Module: EXCEPTION (Link Date/Time: 19-FEB-2003 11:27:02.61)		       *
* Offset: 0000AF08							       *
* Stack Pointers:							       *
* KSP = 00000000.4001FD68 ESP = 00000000.7AFCFAA0			       *
* SSP = 00000000.40028000 USP = 00000000.00951B00 			       *
* SCOPE									       *
* This problem only affects environments that meet the following criteria:     *
* Systems where the SYSGEN parameter MULTITHREAD is greater than 1. 	       *
* Process applications which are threaded (linked with MULTIPLE_KERNEL_THREADS *
* and UPCALLS enabled). 						       *
* Customers can use the following methods to determine if their systems and    *
* applications are subject to the problem:				       *
* To tell if MULTITHREAD is greater than 1 issue the following commands:       *
* $ MCR SYSGEN								       *
* For example:								       *
* $ MCR SYSGEN								       *
* Parameter Name Current Default Min. Max Unit 				       *
* MULTITHREAD 4 1 0 256 KThreads					       *
* Dynamic								       *
* SYSGEN> EXIT								       *
* $									       *
* You can determine if images are threaded with the following commands:        *
* 1. $ THREADCP/SHOW {application_image.exe} 				       *
* If this command displays the following message then the application is       *
* threaded:		                                                       *
* $ THREADCP/SHOW {application_image.exe}				       *
* ...									       *
* %THREADCP-I-MKT, multiple kernel threads are enabled			       *
* %THREADCP-I-UPC, upcalls are enabled					       *
* 2. $ ANALYZE/IMAGE/HEADER/INTERACTIVE {application_image.exe)		       *
* In the resulting "Fixed Header Information" there will be two flags,         *
* EIHD$V_MKTHREADS and EIHD$V_UPCALLS. If both of these values are set to 1,   *
* and the SYSGEN parameter MULTITHREAD is greater than 1, then the application *
* is subject to this problem. For example:			               *
* This is an OpenVMS Alpha image file					       *
* IMAGE HEADER								       *
* Fixed Header Information						       *
* image format major id: 3, minor id: 0					       *
* header block count: 2							       *
* image type: executable (EIHD$K_EXE)				               *
* I/O channel count: default						       *
* I/O pagelet count: default						       *
* Symbol Vector Virtual Address: %X'00000000'				       *
* Symbol Vector Size: 0 bytes						       *
* Virtual Memory Block Size: 65536 (BPAGE = 16)				       *
* Fixup Section Virtual Address: %X'00050000'				       *
* linker flags:								       *
* (0) EIHD$V_LNKDEBUG 0							       *
* (1) EIHD$V_LNKNOTFR 0							       *
* (2) EIHD$V_NOP0BUFS 0							       *
* (3) EIHD$V_PICIMG 1							       *
* (4) EIHD$V_P0IMAGE 0							       *
* (5) EIHD$V_DBGDMT 1							       *
* (6) EIHD$V_INISHR 0							       *
* (7) EIHD$V_XLATED 0							       *
* (8) EIHD$V_BIND_CODE_SEC 0						       *
* (9) EIHD$V_BIND_DATA_SEC 0						       *
* (10) EIHD$V_MKTHREADS 1 						       *
* (11) EIHD$V_UPCALLS 1							       *
* (12) EIHD$V_OMV_READY 0						       *
* (13) EIHD$V_EXT_BIND_SECT 0						       *
* HP recommends that customers with environments that match this criteria      *
* do not install the DEC-AXPMS-VMS731_RMS-V0300--4.PCSI patch kit. 	       *
* RESOLUTION								       *
* Customers that have already installed the DEC-AXPMS-VMS731_RMS-V0300--4.PCSI *
* patch kit and who find that they are susceptible to the problem described    *
* can take either ofthe following action to prevent the problem from occurring:*
* Use the following commands to reset the SYSGEN parameter MULTITHREAD to 1    *
* SYSGEN> WRITE CURRENT							       *
* SYSGEN> EXIT								       *
* $									       *
* Make this change permanent by adding it to the MODPARAMS.DAT file.           *
* Note that if this is not done, the next time AUTOGEN is run and the system   *
* rebooted, the parameter setting will be lost and MULTITHREAD will be reset   *
* to the previous value.In order to make this change permanent 	  	       *
* perform the following steps:						       *
* 1. Edit [SYSEXE]MODPARAMS.DAT, adding the line:			       *
* MULTITHREAD = 1 !Disable Multithreading			               *
* 2. Exit MODPARAMS.DAT							       *
* Note that the above change may cause a performance degradation. 	       *
* Remove the DEC-AXPMS-VMS731_RMS-V0300--4.PCSI patch kit by renaming the      *
* images replaced by the RMS kit to be the latest system images:	       *
* Rename SYS$COMMON:[SYSEXE]RMSREC$SERVER.EXE_OLD to                           *
* SYS$COMMON:[SYSEXE]RMSREC$SERVER.EXE	                                       *
* Rename SYS$COMMON:[SYSLIB]SDARMS$SHARE.EXE_OLD to                            *
* SYS$COMMON[SYSLIB]SDARMS$SHARE.EXE		                               *
* After making these changes the system must be rebooted.		       *
*									       *
Copyright (c) Hewlett-Packard Company 2001,2002,2003.  All rights reserved.

OP/SYS:     OpenVMS Alpha


SOURCE:     Hewlett-Packard Company


     ECO Kit Name:  VMS731_RMS-V0300
     ECO Kits Superseded by This ECO Kit:  VMS731_RMS-V0200
     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 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


     o  RMS fix for a user buffer size exceeding the  terminal  driver
        limit (in particular if the SYSGEN parameter MAXBUF is greater
        than 32K and the session is a Telnet session).

        The specific error returned by a terminal  driver  to  RMS  is
        SS$_IVBUFLEN;  RMS  returns  to  the  caller  RMS-F-QIO in the
        RAB$L_STS  and  the  system  error  (SYS-F-IVBUFLEN)  in   the
        RAB$L_STV.   However, if this error is returned to a C runtime
        library call for a read I/O to a terminal, it is  more  likely
        the  symptom visible to users will be a C program failing with
        a a generic C IO error.

        An RMS change was implemented in Alpha V7.3-1 that may  result
        in a larger I/O transfer size being used for "reads" from unit
        record devices (mainly terminals) than  the  previous  smaller
        default  RMS  intermediate  buffer  size.   The larger size is
        based on the size of the user's record buffer specified in the
        RAB (RAB$W_USZ or RAB64$Q_USZ) for the read.

        Under certain conditions, the larger  size  can  result  in  a
        limit   imposed  by  at  least  one  driver  (TTDRIVER)  being
        exceeded.  Drivers are free to set  a  limit  arbitrarily;  in
        this  case  the  limit  imposed  is  32767.  When the limit is
        exceeded, an SS$_IVBUFLEN  fatal  error  is  returned  by  the

        One example of the combination of conditions that can  trigger
        this problem is as follows:

        -  System is accessed via Telnet (TNDRIVER) or SET  HOST/LAT.
           This  results  in the particular TT driver with this limit
           being used for the terminal I/O.  A regular SET HOST  uses
           another  terminal  driver and does not encounter the limit

        -  The read request to this  particular  TT  driver  is  made
           through RMS with the user buffer size specified in the RAB
           (RAB$W_USZ  or  RAB64$Q_USZ)  being  greater  than  32767.
           While  this  could  be  done  from any application issuing
           calls to RMS,  there  is  a  high  probability  that  a  C
           application  with  a  C  runtime library call to read data
           from a terminal (e.g.  getc, gets) may be involved if  the
           SYSGEN  parameter  MAXBUF on the impacted system is set to
           greater than 32K.

           The C runtime  library  uses  a  heuristic  involving  the
           SYSGEN  parameter  MAXBUF value (MAXBUF less 512 bytes) to
           set the buffer size  in  the  RAB  passed  to  RMS.   This
           parameter  ships with a default of 8192 (with a maximum of
           64000).  However, some systems increase this parameter  to
           the  maximum  for  tuning purposes.  This results in the C
           runtime library  heuristic  setting  a  user  buffer  size
           greater  than  32K.   There is nothing substantively wrong
           with the C runtime library or any application specifying a
           user buffer size greater than 32K.

          For  this  particular  example,  a  proactive  measure  or  an
          immediate  workaround  to  the  problem  is  to set the MAXBUF
          SYSGEN parameter down to 32K.  This is a dynamic parameter  so
          no  reboot  is required.  We are not aware of any applications
          that would break by setting MAXBUF down  to  32K.   Once  this
          remedial  kit  is  applied, the SYSGEN parameter MAXBUF can be
          reset above 32K.

            Images Affected:[SYS$LDR]RMS.EXE

     o  RMS fix for an incorrect record returned  for  a  reverse  key
        search  on  a  secondary  key  using  a partial key (just some
        leading characters).

        As a side-effect of calling a sequence of  common  lower-level
        routines  to unpack a compressed key or segmented primary key,
        the potential exists that an RMS internal scratch  key  buffer
        may  be overwritten.  This results in the target secondary key
        value being replaced with the primary key associated with  the
        primary  record  being  unpacked.   The full set of conditions
        necessary for this to occur are rare.

        While no user data is compromised by the overwriting,  if  the
        copy  of  the  target  secondary  key value gets replaced, the
        search from thereon uses this  particular  primary  key  value
        rather  than  the  target secondary key value as its criterion
        for the secondary key search.  In such a case if  the  forward
        search  for a match reaches the end-of-the-key without finding
        either an exact match or a "mismatch" (a record with a  higher
        key  value), it will return the last record at the end of that
        secondary key as the match.

          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

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