TITLE: OpenVMS VAXRMS03_062 VAX 6.2 RMS/CONVERT 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.
Copyright (c) Compaq Computer Corporation 1996, 1998. All rights reserved.
Modification Date: 31-DEC-98
Modification Type: Updated Kit Supersedes VAXRMS02_062
OP/SYS: DIGITAL OpenVMS VAX
COMPONENT: RMS - RMS.EXE
CONVERT CONVSHR.EXE
CONVERT.EXE
RECLAIM.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXRMS03_062
ECO Kits Superseded by This ECO Kit: VAXRMS02_062
VAXRMS01_062
ECO Kit Approximate Size: 792 Blocks
Kit Applies To: OpenVMS VAX V6.2
System/Cluster Reboot Necessary: Yes
Rolling Reboot 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/CONVERT on OpenVMS VAX V6.2. This kit
addresses the following problems:
Problems addressed in the VAXRMS03_062 ECO kit:
o A fix was done for explicit $extend to a relative file.
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.
o A fix was done 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.
o It is possible for an indexed file with more than one
secondary key allowing no duplicates to show an inconsistent
total number of data records as being accessible via two or
more of the secondary keys. In order for this problem to
occur, the file must have RU journaling enabled. As part of
an RU transaction, a secondary data record must be deleted in
one of the nonduplicate secondary keys (will be marked
RU-DELETED) and then an attempt must be made to add a
duplicate key value to another nonduplicate secondary key as
part of a $PUT operation, which results in a duplicate (DUP)
error.
As part of the recovery triggered by the DUP error, the
secondary key value marked as RU-DELETED will not be
recovered. This will leave the file with an inconsistent
secondary key. However, the primary key contents will be
intact and correct, and a convert of the file will rebuild the
secondary indexes and leave the file in a consistent state.
o A XABITM stored semantics attribute fix was done for the SMFS
(Sequential Media File System) device.
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.
o A fix was done to dynamically reflect file protection changes
cluster wide for files that are INSTALLED with the /OPEN
qualifier.
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.
o A fix was done 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 this 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.
o A fix was done 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 this 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.
o A fix was done 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.
o A fix was done 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 canceled.
o A fix was done so that a RMS-F-FTM (network DAP file transfer
mode does not permit operation) error is not returned
inappropriately for a remote $FIND operation when the
sequential-only (SQO) option is set in the FAB$L_FOP (file
options) field and the access method used is sequential.
When the SQO option is set, this error is only appropriate if
either the keyed or record-file-address (RFA) access method is
specified. The sequential access method should be allowed.
This problem is fixed in the OpenVMS VAX V7.1 release.
o A fix was done for an EXCHANGE/NETWORK user-mode access
violation (accvio).
This problem only occurs when the convert transfer_mode
(/TRANSFER_MODE=CONVERT) option is used with a file that
exceeds 255 blocks in size.
o A %CONV-F-READERR converting undefined file format to fixed
occurred.
Converting a sequential file with an UNDEFINED record format
to a FIXED record format aborts with following errors:
%CONV-F-READERR, error reading
-RMS-F-UBF, invalid user buffer
Problems addressed in the VAXRMS02_062 ECO kit:
NOTE: According to OpenVMS Engineering, the following fixes are
included in the official OpenVMS VAX V7.1 software release.
o This kit contains a fix for the compressed primary key problem
that occurs in the context of record deletes being done using
sequential access rather than keyed access.
While sequentially walking through (accessing) the primary data
records in an indexed file (a primary key is a string key with
key compression enabled), a delete is done of one of the
records. The following error may be returned when an attempt
is made to sequentially access the next record:
RMS-F-BUG, fatal RMS condition, process deleted.
The file is not left corrupted. A convert of the file will
leave the file in a consistent state.
This problem is fixed in OpenVMS VAX V7.1.
o For a file lock to be released, a process is delivered a blocking
AST. Before the file lock is released, it has to release the
lock it holds on the EOF buffer. A NOTLOCKED bugcheck is
returned if the process is holding a PW (protected write) rather
than an EX (exclusive) lock on the EOF buffer. A new routine
in OpenVMS VAX V6.1 did not check for either EX or PW as it
should have.
This problem is fixed in OpenVMS VAX V7.1.
o A loop may occur at the EXEC-MODE AST level during the deletion
of network logical links. The process that loops cannot be
deleted and will be an application that does network operations.
RMS maintains a process cache of recent logical links for a
period of time in an attempt to reuse them and save on image
and process activations. When a link becomes inactive and is
added to the cache, RMS deletes any links in surplus of three.
In walking the link cache queue to delete these links, there
is a potential race condition that could result in a stale
pointer being used after a stall, which leads to the loop.
This problem is fixed in OpenVMS VAX V7.1.
o This kit contains an autoextend fix for a shared block I/O
write which requires the use of the UPI option which disables
any locking (file or EOF bucket).
For this particular case with no locking synchronization,
it is possible if two or more processes or two or more
asynchronous streams are writing to a file, that two or more
autoextends may occur concurrently. Though the file system
will do the extends synchronously, the processing of the
extend result may complete out of sequence and result in the
FTL$_BADEBKHBK (R2=FFFFFFDC) RMS bugcheck.
This problem is fixed in OpenVMS VAX V7.1.
o The client/server may hang in detached RU recovery server.
Given the right series of coincidences, both a client RMS
process and the detached RU recovery server process can
hang when the client accesses a file on which there is an open
RU transaction. This is a VAX-specific problem.
This problem is fixed in OpenVMS VAX V7.1.
o An SDA-W-FAOERR error may occur when RMS FWA (File Work Area)
is displayed. The contents of a buffer (LOGNAM) are being
displayed after the space has been returned and reallocated
for some other use.
This problem is fixed in OpenVMS VAX V7.1.
o The outlier area is not detected on an indexed file open. The
RMS-F-AID error (invalid area ID) is not reported on the open
of an indexed file with an XABALL declaration that has an area
ID that is exactly one greater than the maximum number of areas
in that indexed file. A check has been added for record I/O
access. Block I/O access is excluded from this check.
This problem is fixed in OpenVMS VAX V7.1.
Problems addressed in the VAXRMS01_062 ECO kit:
o The last chance handler needs to be more robust when a process
that has a file opened with global buffers enabled is terminated
with a STOP/ID. STOP/ID invokes the RMS abort last chance handler
(RM$LAST_CHANCE). Problems addressed include:
+ A potential deadlock in the RMS last-chance handler if the
same file is open more than once within a process or
subprocess and it has global buffers set on it.
+ A potential fatal KRNLSTAKNV system crash due to nonfatal
RMS bugchecks from failing $GETLKI calls which cause error
rundown recursion until the stack fills up.
o An ISAM RMS nonfatal bugcheck is returned by RM$EXPAND_KEY
(module RM3PCKUNP). This bugcheck is forced if key expansion
for the deletion of a secondary index data record (SIDR)
overflows an SIDR data bucket.
The current problem occurs in the context of an $UPDATE that
changes a secondary key value (with key compression enabled)
if both the SIDR data bucket freespace is exactly equal to the
bucket size minus one and the key expansion of the next SIDR
record (if any) results in a gain in bytes exactly equal to the
number of bytes to be deleted. For both conditions to be
satisfied makes the probability of this problem's occurrence
rare.
The update to the primary record will have been completed. The
problem occurs during the delete operation to remove the old
secondary key value after the new updated secondary key value
has been added. The file is not left corrupted. A convert of
the file will rebuild the secondary indices and leave the file
in a consistent state.
This problem is fixed in OpenVMS VAX V7.0.
o An SIDR (secondary index data record) compressed key
expansion problem could result in a corrupted SIDR bucket.
The conditions that are required make the probability of its
occurrence rare.
For this problem to occur requires
+ The presence of many duplicate records for a secondary key;
+ A secondary key of a string type that is 9 bytes or more in
length; and
+ A very particular key pattern which results in a number of
bytes at the front of the key being compressed.
The problem occurs in the context of a bucket split when the
current design moves an entire SIDR array into a new bucket.
It is possible that when the compressed secondary key for that
SIDR array is expanded in its position as the first record in the
new bucket, it may grow larger than the bucket.
Since the problem is with a secondary key bucket, a convert
will recover all the data records in the corrupted file.
This problem is fixed in OpenVMS VAX V7.0.
o In some cases, incomplete security success audit information
is generated upon image activation of installed /OPEN images.
o A Known File Entry (KFE) file open SSRVEXCEPT (Unexpected
system service exception) may occur due to an ACCVIO in
RM$KNOWNFILE (RMS0OPEN).
Heavy concurrent INSTALL and F$FILE_ATTRIBUTE usage may cause
locking conflicts accessing the KFE list, which can result in a
bad KFE pointer being handed to RMS leading to ACCVIO.
This problem is fixed in OpenVMS VAX V7.0.
o The Statistics setting on a file may be lost from the FDL
produced by ANALYZE/RMS/FDL. File monitoring is always set
to 'no' whether it is enabled or not. The problem is not
with ANALYZE[/RMS], but with RMS's processing of an XABITM list.
o The following error will be reported in converting a VFC-format
file to a fixed-format file using the /PAD qualifier:
%LIB-F-BADBLOADR, bad block address
The problem is restricted to a convert job that involves an
input file with a VFC record format that is being converted to
an output file with a fixed record format using the /PAD
qualifier.
This problem was introduced in OpenVMS V6.1 and is fixed in
OpenVMS V7.0.
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.
