*******************************************************************************
* *
* This is a newly released patch... *
* *
* Online links can be found at *
* http://ftp.support.compaq.com/patches/public/vms/axp/v7.2-2/dec-axpvms-vms722_rms-v0100--4.README
*******************************************************************************

TITLE: OpenVMS VMS722_RMS-V0100 Alpha V7.2-2 RMS ECO Summary

New Kit Date : 17-OCT-2001
Modification Date: Not Applicable
Modification Type: New Kit
 
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-dcx_axpexe.pcsi, then it can
       be expanded by typing RUN kitname-dcx_axpexe.pcsi. The resultant
       file will be the PCSI installation file which can be used to install
       the ECO.
 

 
Copyright (c) Compaq Computer Corporation 2001. All rights reserved.

OP/SYS: OpenVMS Alpha

COMPONENT: RMS

SOURCE: Compaq Computer Corporation

ECO INFORMATION:

     ECO Kit Name: VMS722_RMS-V0100
                    DEC-AXPVMS-VMS722_RMS-V0100--4.PCSI
     ECO Kits Superseded by This ECO Kit: None
     ECO Kit Approximate Size: 2832 Blocks
     Kit Applies To: OpenVMS Alpha V7.2-2
     System/Cluster Reboot Necessary: Yes
     Rolling Re-boot Supported: Yes
     Installation Rating: INSTALL_1
                            1 - To be installed on all systems running
                                the listed version(s) of OpenVMS.
     
     Kit Dependencies:

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

         None

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

         None

ECO KIT SUMMARY:

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

PROBLEMS ADDRESSED IN VMS722_RMS-V0100 KIT:

  o Fix to increase the directory path cache size to accommodate
     larger directories.

     A threaded process may deplete the RMS directory path cache
     when multiple process threads are performing simultaneous
     directory lookups. This can result in a race condition in
     which the threads end up in an infinite loop attempting to
     traverse their respective paths while the cache is being
     frequently flushed. This problem is aggravated when the
     directory paths contain long names and/or deep structures.
     The directory path cache size has been increased to prevent
     this behavior.

          Images Affected: [SYS$LDR]RMS.EXE

  o Fix to increase the size of RMS's internal ASB stack.

     RMS's internal ASB stack boundaries may be exceeded due to
     unanticipated third party EXEC mode activity such as an AST
     delivery while RMS is operating on its internal stack.
     Because the stack was initially sized for exclusive RMS use,
     the stack limits can overflow causing adjacent RMS data
     structures to become corrupted. This can result in various
     aberrant RMS conditions including non-fatal EXEC mode System
     Service Exceptions.

          Images Affected: [SYS$LDR]RMS.EXE

  o Fix to prevent EXEC mode hangs with EXEC ASTs disabled.

     Under rare circumstances, non-atomic access to an RMS process
     global data cell could result in status bits being lost during
     concurrent cell access. A status bit to indicate whether RMS
     currently has ASTs disabled could inadvertently be cleared
     through this access resulting in an infinite hang within RMS
     waiting for an AST delivery, but with EXEC mode ASTs disabled.
     Atomic access to this cell prevents this from occurring.

          Images Affected: [SYS$LDR]RMS.EXE

  o RMS RU journaling fix for an update window when a SIDR
     (secondary index data record) marked as RU-DELETE may be
     inappropriately re-marked as deleted while the SIDR is still
     part of an active recovery unit. If this transaction were
     aborted, this could result in the new secondary key value
     being retained in the primary data record.

          Images Affected: [SYS$LDR]RMS.EXE

  o Fixes for problems associated with deleting an accessor of a
     file with global buffers enabled.

     The probability of these problems occurring increases not only
     with processes deleted with a $delprc or stop/id but also if
     they are also accessing a file that is opened and closed
     constantly for only one operation, with brief windows when the

     file has only one accessor (for example, SYSUAF.DAT).

       - Process hang waiting for exclusive global section process
          lock if same file is opened more than once and process is
          deleted during a $connect to the same file before the
          section is completely initialized. This could leave one
          stream still holding the exclusive lock when the process
          is terminated.

       - Fatal accvio. The last accessor of the file is deleted,
          and during the abort rundown a new process is waiting to
          connect to the global section when the global section lock
          is released by the last accessor. Because the global
          section is a temporary section and doesn't get marked for
          delete, there is the possibility of a lag before the
          section is deleted by the system. There was a potential
          race condition when the new connect might map to the old
          global section before it was deleted. This could result
          in the new mapper using some stale (no longer valid)
          pointers in the old section.

          Images Affected: [SYS$LDR]RMS.EXE
                            [SYS$LDR]DDIF$RMS_EXTENSION.EXE
                            [SYSLIB]SDARMS$SHARE.EXE
                            [SYS$LDR]RMSDEF.STB

  o Enhance minimum process quotas that the RMSREC_SERVER detached
     process is created with. This server is dedicated to RMS RU
     journaling detached recovery.

     ENQLM and PGFLQUOTA are the process quotas that some
     applications have found it necessary to override the minimum
     on their system or cluster by increasing the associated
     PQL_Mxxxx sysgen parameter (e.g. PQL_MENQLM). The defaults
     for these quotas are now 1 million for ENQLM and 100 thousand
     for PGFLQUOTA. The enhancement also sets WSEXTENT at runtime
     to the WSMAX sysgen parameter.

          Images Affected: [SYS$LDR]RMS.EXE

  o Rollback of a remote file transfer change made in V7.2 to its
     day 1 behavior in order to restore prior performance metrics
     for remote file transfers that request file transfer mode by
     setting the SQO (FAB$L_FOP) option. The change was made to
     ignore the file transfer mode (FTM) request if the remote file
     was write shared.

     This has led to a number of reports of applications that
     previously had SQO specified for remote files that are
     experiencing significant performance degradations in their
     remote applications with the V7.2 family and V7.3. We have
     reviewed the previous behavior for file transfer mode and
     found that while there is the appearance of locking
     inconsistencies for readers when FTM is used, there is no
     potential for data corruption. We have concluded that when
     users set the FTM (SQO) option, they are in effect giving
     permission for the same kind of inconsistencies that a user
     allows when the read-regardless (RRL) option is set.

     This change restores the pre-V7.2 behavior for the file
     transfer mode for remote files. If SQO is set, file transfer
     mode will be used regardless of the sharing specified for the
     remote file. Users should expect to see the same kind of
     inconsistencies in reading data as they see when the
     read-regardless (RRL) option is set. The SQO option should be
     disabled if this is not acceptable for some application. In

     addition, to avoid the possibility of a hang that may be
     induced by retrying remote accesses after a record lock error,
     users should consider setting both the no-lock (NLK) and
     read-regardless (RRL) options in the RAB$L_ROP in applications
     that use the file transfer mode (SQO) option for remote file
     accesses. (Note: The new NQL (no query locking) option
     introduced in V7.2-1H1 is not supported by the DAP protocol
     for remote files.)

     An application should continue to work with the restored
     behavior without a new change even if a change has been made
     to an existing application to restore the file transfer mode
     behavior since the SQO fix was made in V7.2 (e.g., adding the
     UPI sharing option).

     There is just one potential problem that we need to point out.
     For new applications designed and implemented in V7.2 or later
     that may allow remote accesses to write shared files, they
     should check whether SQO (FAB$L_FOP) is enabled. Currently
     the SQO option is being ignored (unless the UPI sharing option
     is specified), and the file transfer mode is not being used
     for any remote accesses. With the restore of pre-V7.2 SQO
     behavior, it will start being used and so the behavior of the
     application could change. Anyone with a new application that
     has SQO set and the possibility of write shared files being
     remotely accessed by the application should consider whether
     the SQO option needs to be disabled.

          Images Affected: [SYS$LDR]RMS.EXE

  o Fix to prevent an infinite loop in SDA's SHOW PROCESS/RMS.

     Under rare circumstances, a high priority process utilizing
     the online System Dump Analyzer (ANALYZE/SYSTEM) to examine a
     low priority process's RMS attributes (SHOW PROCESS/RMS) may
     enter an infinite loop. Since the process is at high
     priority, it may have an adverse impact on other processes on
     the system.

          Images Affected: [SYSLIB]SDARMS$SHARE.EXE

  o Fix for a user-mode accvio when converting a sequential file
     when the maximum record size (MRS) in its file header is
     inappropriately set to zero.

          Images Affected: [SYSLIB]CONVSHR.EXE
                            [SYSEXE]CONVERT.EXE

INSTALLATION NOTES:

This kit requires a system reboot. Compaq 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.

INSTALLATION INSTRUCTIONS:

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

PRODUCT INSTALL VMS722_RMS /SOURCE=[location of Kit]

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:

As part of the post installation processing of this kit, two
SYSGEN parameters (PIOPAGES and IMGIOCNT) will be modified in
order to accommodate changes being made within the RMS image.

The post installation process will make an effort to add
appropriate lines to the MODPARAMS.DAT files for all system
roots found on the installation disk and will perform a SYSGEN
write current with the modifications on the system from which
this kit is being installed. The installation process will
provide the status of these changes and any further
instructions as necessary.

     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:

       1. Define logical NO_ASK$BACKUP as TRUE

       2. Define logical NO_ASK$REBOOT as TRUE

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

           /PROD=DEC/BASE=AXPVMS/VER=V1.0

       4. De-assign the logicals assigned

     For example, a sample command file to install the VMS722_RMS

     kit would be:

          $ DEFINE/SYS NO_ASK$BACKUP TRUE
          $ DEFINE/SYS NO_ASK$REBOOT TRUE
          $!
          $ PROD INSTALL VMS722_RMS/PROD=DEC/BASE=AXPVMS/VER=V1.0
          $!
          $ DEASSIGN/SYS NO_ASK$BACKUP
          $ DEASSIGN/SYS NO_ASK$REBOOT
          $ exit

All trademarks are the property of their respective owners.

---

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]