Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXRMS04_062 VAX 6.2 RMS/CONVERT ECO Summary
Copyright (c) Compaq Computer Corporation 2001. All rights reserved.
New Kit Date : 07-FEB-2001
Modification Date: 13-FEB-2001
Modification Type: DOCUMENTATION: Technical Modification
Added note regarding
superfluous file in saveset.
OP/SYS: OpenVMS VAX
COMPONENT: RMS - RMS.EXE
CONVERT CONVSHR.EXE
CONVERT.EXE
RECLAIM.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXRMS04_062
ECO Kits Superseded by This ECO Kit: VAXRMS03_062
VAXRMS02_062
VAXRMS01_062
ECO Kit Approximate Size: 810 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
NOTE: The saveset for this kit contains the following extra file:
REQUEST.RELEASE_NOTES;1
The file is an engineering work file and is not necessary for
the functionality of this kit. It will not be copied to the
system when the kit is installed.
ECO KIT SUMMARY:
An ECO kit exists for RMS/CONVERT on OpenVMS VAX V6.2. This kit
addresses the following problems:
PROBLEMS ADDRESSED IN VAXRMS04_062 KIT:
o Mark the Buffer Descriptor as busy for asynch multistreamed
block IO autoextends.
Performing multistreamed asynchronous Block IO to a sequential
file could result in random data corruption and/or sporadic
SS$_BADPARAM errors if an autoextend occurs.
o Fix to prevent an inconsistent primary index structure.
This problem is characterized by an ANALYZE/RMS_FILE of an
indexed file reporting the following error: "Index bucket
references missing data bucket with VBN nnn"
When the index bucket is examined, the problem is determined
to be that the primary index structure has duplicate index
entries. There should never be duplicate entries in the index
structure.
Any file that has a prevalence of deleted records as the last
records in a data bucket that is subsequently a candidate for
a bucket split could potentially encounter this problem.
A convert of the file will rebuild the primary index structure
and leave the file in a consistent state.
This problem is fixed in OpenVMS VAX V7.2.
o Fix to prevent the creation of a corrupt file structure with
repeated calls to the CONVERT callable interface.
Under rare circumstances, repeated calls to the CONVERT
callable interface from within an application can produce a
file with a corrupted file structure. The conditions that
must exist for this to occur are as follows:
+ The previous file processed must have allowed duplicates
on the last key
+ The last data bucket of the file must be part of a
duplicate chain.
o Fix convert/reclaim of RU_DELETED records.
A CONVERT/RECLAIM of a fixed record length file with no
compression enabled that has been used with RU journaling may
inappropriately reclaim buckets containing valid user records.
This results in data loss.
This problem is fixed in OpenVMS VAX V7.2.
o Prevent RMS pool corruption when accessing bad .DIR file
Access to a corrupted directory could result in the user's
process being deleted from the system through an EXEC mode
exception (a system bugcheck would occur if the SYSGEN
parameter BUGCHECKFATAL were set).
o Fix IORNDN non-fatal bugchecks caused by busy RMS stream.
Processes may disappear with RMS IORNDN non-fatal bugchecks
when an EXIT is requested by an Executive-mode subsystem (such
as ACMS). This is a very small timing window, so processes
with a large number of files increases the probability of the
problem occurring.
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 <input filespec>
-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.
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS database. To view these articles, open the appropriate
product database and perform a query using either of the following
search strings: 'VAXRMS04_062' or 'VAXRMS'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
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.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| CONVERT.EXE |%XF570BDAA| X-3 | 17-JUL-2000 |
| | | 01:30:09.06 |
+----------------------------+----------+-----------------+--------------+
| CONVSHR.EXE |%X05802920| X-1 | 17-JUL-2000 |
| | | 01:20:48.90 |
+----------------------------+----------+-----------------+--------------+
| EXCHANGE$NETWORK.EXE |%X09D988B8| X-5 | 25-NOV-1998 |
| | | 22:51:38.61 |
+----------------------------+----------+-----------------+--------------+
| RECLAIM.EXE |%XD82CED0E| X-3 | 17-JUL-2000 |
| | | 01:30:14.85 |
+----------------------------+----------+-----------------+--------------+
| RECOVER.EXE |%X955513BA| X-3 | 23-DEC-1996 |
| | | 09:53:01.09 |
+----------------------------+----------+-----------------+--------------+
| RMS.EXE |%X2FC5600C| RMS | 17-JUL-2000 |
| | | 01:37:08.88 |
+----------------------------+----------+-----------------+--------------+
| RMSREC$SERVER.EXE |%XB40D5D72| X-4 | 23-DEC-1996 |
| | | 09:53:05.84 |
+----------------------------+----------+-----------------+--------------+
|
