OpenVMS VAXRMS01_071 VAX V7.1 RMS ECO Summary
TITLE: OpenVMS VAXRMS01_071 VAX V7.1 RMS ECO Summary
Modification Date: 28-OCT-98
Modification Type: New Kit
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.
Copyright (c) Compaq Computer Corporation 1998. All rights reserved.
OP/SYS: DIGITAL OpenVMS VAX
COMPONENT: RMS
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXRMS01_071
ECO Kits Superseded by This ECO Kit: None.
ECO Kit Approximate Size: 648 Blocks
Kit Applies To: OpenVMS VAX V7.1
System/Cluster Reboot Necessary: Yes/No
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 and global buffer processing on OpenVMS
VAX V7.1. This kit addresses the following problems:
o RMS has implemented a new algorithm for global buffer management
that dramatically improves scalability. The performance associated
with the previous algorithm effectively limited the maximum number
of global buffers on large, shared files. With this change,
customers may increase the number of global buffers on these files
to the full limit of 32,767 to fully exploit large memory systems.
Access to the global section used for RMS global buffers is
now mainly synchronized using inline atomic instruction sequences
rather than distributive locking. This change allows more concurrent
access to the section (particularly on SMP machines).
As has always been true, increasing the number of global buffers
on specific files may require some system resources to be increased
in size.
Note that these enhancements required changes to the internal
structures representing RMS global buffers. This will lead to
some erroneous values being displayed by the System Dump
Analyzer (SDA) in two RMS structures (global buffer descriptors
and global buffer headers). This is a display anomaly only.
o RMS and FAL have been enhanced to support time transfers using
128-bit UTC format. Currently, RMS and FAL exchange date-time
file attributes using an 18-byte ASCII string which includes a
2-digit year. Since the date is pivoted at 1970 (YY's from 70
to 99 map to 1970 through 1999 and YY's from 00 to 69 map to
2000 through 2069), OpenVMS RMS is Year 2000 compliant in
regards to file access using DECNET FAL.
The DAP specification provides for using a 128-bit UTC binary
date as an alternative to the ASCII format. This enhancement
allows non-VMS operating systems to access file dates on
OpenVMS in a completely Year 2000 compliant manner.
Alternative workarounds:
+ Apply this remedial kit.
+ There is no temporary workaround for avoiding the
secondary key inconsistency. However, a convert of the
file after the problem has occurred will rebuild the
secondary indexes and leave the file in a consistent
state.
o The last data record(s) added at the end of a relative file
may be lost (overwritten) after an "explicit" call to the RMS
$EXTEND service for a relative file that is being shared by
two or more concurrent writers. This problem is restricted to
an explicit $EXTEND; autoextends done transparently by RMS for
a relative file work correctly.
NOTE: Until this remedial kit can be installed, this problem
can be prevented by not doing any explicit $EXTEND for a
shared write relative file. Let the autoextend feature
of RMS take care of any extends needed. See "Relative
File Extend Size" section in Chapter 3 (Performance
Considerations) of the Guide to OpenVMS File Applications
for a description of how RMS derives the value it uses
for its autoextend feature.
Alternative Workarounds:
+ Apply this remedial kit.
+ Do not do an explicit $EXTEND for a relative file.
Let the autoextend feature of RMS take care of any
extends needed. Autoextends work correctly. See
"Relative File Extend Size" section in Chapter 3
(Performance Considerations) of the Guide to OpenVMS
File Applications for a description of how RMS derives
the value it uses for its autoextend feature.
o Stored semantics is a file attribute used to indicate that a
file contains compound documents (i.e., contains a number of
integrated components including text, graphics, and scanned
images). Support for setting this file attribute is provided
through RMS using an item list XAB (XABITM) user interface.
In specifying the item list for setting this attribute
(XAB$_STORED_SEMANTICS), a user may request a return length
(the length of the stored semantics ACE added by the file
system to the file). RMS without the fix returns a length of
zero if the file is on a SMFS device despite the fact that the
stored semantics attribute was successfully added to the file.
Alternative workarounds:
+ Apply this remedial kit.
+ In actuality, the XABITM XAB$_STORED_SEMANTICS request
succeeds. There is just no temporary workaround for the
correct length of the ACE being returned to the return
length address provided in the XABITM item list.
o Fix for appender lock timing window hang for shared write, RU
journaled sequential file.
This hang requires all of the following conditions: a shared
write sequential file, multi-record streaming enabled, RU
journaling enabled on the file, and heavy write contention
among sharers at the end-of-file. It has only been reported
by one site, and even then there was a lapse of over one year
between two occurrences.
Alternative workarounds:
+ Apply this remedial kit.
+ There is no temporary workaround. Changing the
application to use only a single record stream on
the journaled file would theoretically work, but
this would most likely involve too much of a
design change to the application to be a viable
workaround. Disabling RU journaling would also
not be a viable workaround.
o Changes to the security profile of a file that was installed
with the /OPEN qualifier were not reflected cluster wide until
an INSTALL/REPLACE was performed on each node. With this
correction, the protection information is dynamically
propagated.
Alternative workarounds:
+ Apply this remedial kit.
+ Following the change in the protection information,
perform an INSTALL/REPLACE on all other nodes in the
cluster.
o Fix to properly handle a special bucket split case to prevent
an exec-mode ACCVIO occurring during a bucket split.
This problem is restricted to a file with KEY compression
enabled containing a secondary key allowing duplicates with a
nearly full SIDR data bucket. An ACCVIO (access violation)
may occur during a bucket split operation if both the last
valid record in the bucket contains a long list of duplicates
and starts before the calculated split point and the memory
page adjacent to the page mapping the current buffer is not
valid.
If the SYSGEN parameter BUGCHECKFATAL is not enabled, then the
process will be terminated; if it is enabled, then the system
will crash with a SSRVEXCEPT ACCVIO. The file will not be
left corrupted. A temporary workaround if the problem ever
occurs on a file would be to convert the file using a revised
FDL in which key compression is disabled until the remedial
kit is applied.
Alternative workarounds:
+ Apply this remedial kit.
+ Convert the file using a revised FDL in which key
compression is disabled until the remedial kit is applied.
o Fix to correct a unique situation where the delete of a record
in a file with key compression enabled could possibly cause
the resulting key expansion to overflow the current bucket.
This problem is restricted to a file with key compression
enabled. A nonfatal RMS bugcheck (R2 value FFFFFFD4 (Internal
ISAM Error)) could occur during a record delete operation on a
prologue 3 file. The ISAM error would be returned when the
deletion of a record caused the expansion of the compressed
key value of the next record in the bucket to exceed the
available space in the data bucket.
This would occur if the primary data bucket containing the key
was nearly full and the record that followed the record being
deleted was compressed to the extent that only one physical
byte of the key was stored in the data record.
The file will not be left corrupted. A temporary workaround
if the problem ever occurs on a file would be to convert the
file using a revised FDL in which key compression is disabled
until the remedial kit is applied.
This problem was introduced in OpenVMS V6.0.
Alternative workarounds:
+ Apply this remedial kit.
+ Convert the file using a revised FDL in which key
compression is disabled until the remedial kit is applied.
o Fix to prevent process hangs when RMS rundown is invoked from
within an EXEC-mode AST.
If RMS rundown is invoked from within an EXEC-mode AST, the
process will hang indefinitely waiting on the delivery of
pending ASTs. As documented in Section 2.5 of the RMS
Reference Manual, RMS services should not be called from
within an EXEC-mode AST. If however, an EXEC-mode AST routine
fails due to an unhandled condition, RMS rundown will be
indirectly invoked by the image exit (resulting in a process
hang).
The rundown routine has been modified to abort RMS rundown
with an RMS$_BUSY return status if it has been invoked from
within an EXEC-mode AST.
Alternative workarounds:
+ Apply this remedial kit.
+ While the use of STOP/ID is typically strongly
discouraged, due to the nature of this loop,
STOP/ID must be used to terminate the process.
o Fix to prevent a nonfatal RMS bugcheck (ENQDEQFAIL) when a
timeout on a lock request coincides with a system detected
SS$_DEADLOCK condition for the same resource.
If an RMS $GET is performed with the WAT and TMO options
specified (wait for lock and timeout request after specified
number of seconds) in the RAB$L_ROP (record options) field,
it is possible for a nonfatal RMS bugcheck (ENQDEQFAIL;
R2=FFFFFFF4) to be signaled when the timeout occurs. This can
happen if an SS$_DEADLOCK condition is detected by the system
(which cancels the lock request) but the timeout AST routine
is triggered before RMS receives the AST notification that the
request has been cancelled.
Alternative workarounds:
+ Apply this remedial kit.
+ Ensure that the DEADLOCK_WAIT SYSGEN parameter and the
time out value specified in the RAB are different values.
o If a foreign host initiates a buffered block-mode file transfer
with a block size that is not a multiple of the OpenVMS standard
512 byte block, the output file may contain extraneous null bytes.
FAL was padding its internal buffer with nulls to position the
transfer on a 512-byte boundary. The nulls would appear at or
around the 64th block of the file (the size of FAL's internal
buffer). With this modification, FAL no longer pads the buffer
to be on a 512-byte boundary.
Alternative workarounds:
+ Apply this remedial kit.
+ Use a buffer size that is a multiple of 512 bytes.
o When reading a file with undefined record format from a remote
node, FAL fills in the DAP buffer completely and returns it to
the requesting application. This can cause the application to
receive more data than it was expecting, resulting in a NETBTS
error. With this change, the USZ (user size) field is used in
the DAP packet to specify how much data the user application
is requesting.
o A $DISPLAY operation failed to fill in the XAB$_NET XABITMs if
a network access was not necessary. This would occur even if
the information was available locally in the Network Work Area.
Alternative workarounds:
+ Apply this remedial kit.
+ Attach a NAM block or some other structure that requires
access to the remote node for information.
o OpenVMS FAL misrepresents the carriage control attributes of
stream format files (STM) to non-OpenVMS systems. With this
correction, the carriage control is no longer unconditionally
changed to EMBEDDED in the DAP ATTRIBUTES message. This
problem was specific to stream (STM) format files.
o This problem only occurs when the convert transfer_mode
(/TRANSFER_MODE=CONVERT) option is used with a file that
exceeds 255 blocks in size.
Alternative workarounds:
+ Apply this remedial kit.
+ There is no temporary workaround. If possible, use the
convert utility to do the transfer.
INSTALLATION NOTES:
The images in this kit will not take effect until the system is
rebooted. If there are other nodes in the VMScluster, 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.
All trademarks are the property of their respective owners.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
European Site
Files on this server are as follows:
vaxrms01_071.README
vaxrms01_071.CHKSUM
vaxrms01_071.CVRLET_TXT
vaxrms01_071.a-dcx_vaxexe
