Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
ALPRMS04_062 Alpha V6.2 RMS/CONVERT ECO Summary
Copyright (c) Compaq Computer Corporation 1998, 2000. All rights reserved.
Modification Date: 08-SEP-2000
Modification Type: Updated Kit: Supersedes ALPRMS04_062
OP/SYS: OpenVMS Alpha
COMPONENT: RMS.EXE - Record Management Services
CONVERT.EXE
CONVSHR.EXE
RECLAIM.EXE
RECOVER.EXE
RMSREC$SERVER.EXE
EXCHANGE$NETWORK.EXE
RMSDEF.STB (new file)
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPRMS04_062
ECO Kits Superseded by This ECO Kit: ALPRMS03_062
ALPRMS02_062
ECO Kit Approximate Size: 3132 Blocks
Kit Applies To: OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3
System/Cluster Reboot Necessary: Yes
Rolling Reboot Supported: Yes
Installation Rating: 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:
ALPCLUSIO01_062
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 Alpha V6.2 through V6.2-1H3.
This kit addresses the following problems:
Problems addressed in ALPRMS04_062:
o An ANALYZE/RMS_FILE of an indexed file reports the following
error:
"Index bucket references missing data bucket with VBN nnn"
The problem is that the primary index structure has duplicate
index value entries and there should never be duplicates in
the index structure. Any application 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 Alpha V7.2.
o In the case of a Prolog 1 or 2 indexed file with fixed length
records, it is possible that an update may result in a
duplicate record being added to a noduplicate primary key.
This problem will never occur with a Prolog 3 indexed file.
Prolog 3 has been the recommended indexed file format since
VAX/VMS V4.0. The possibility of this problem occurring can
be avoided by converting any remaining Prolog 1 or 2 indexed
files. No changes are necessary to the application to convert
the files to Prolog 3.
This problem is fixed in OpenVMS Alpha V7.2.
o Under rare conditions, if a CONVERT/RECLAIM is performed on a
file with a non-compressed, fixed length record format, and
with RU journaling enabled, inappropriate data buckets may be
erroneously reclaimed.
This problem is fixed in OpenVMS Alpha V7.2.
o 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.
This problem is fixed in the release to follow OpenVMS Alpha
V7.2.
o A small timing window in the RMS last chance handler could
allow a lock deadlock hang to occur during an abnormal
termination of a process with RMS global buffers mapped. This
window presented itself in situations where a STOP/ID
($DELPRC) was executed before properly running down an
application.
This problem is fixed in OpenVMS Alpha V7.1.
o 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.
This problem is fixed in the release of OpenVMS Alpha to
follow V7.2.
o Processes may disappear with an RMS IORNDN non-fatal bugcheck
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 open increases the probability of
the problem occurring.
If the SYSGEN parameter BUGCHECKFATAL is set to one, the
system will crash.
This problem is fixed in the release to follow OpenVMS Alpha
V7.2.
Problems addressed in ALPRMS03_062:
o Fix 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 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.
o Fix for inconsistent secondary key in RU-journaled indexed
file.
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 XABITM stored semantics attribute fix for 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 Fix 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 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 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 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
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 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.
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 canceled.
o Fix 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 Alpha V7.0 release.
o Fix for 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 %CONV-F-READERR converting undefined file format to fixed.
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 ALPRMS02_062 kit:
o Fix to exclude block I/O access from XAB area maximum check on
the open of an indexed file.
This problem is fixed in OpenVMS Alpha V7.1.
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 get 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 Alpha V7.1.
o Fix for RMS bugcheck NOTLOCKED (R2=FFFFFFEF) on shared
sequential file.
Process is delivered blocking AST to release file lock. Before
releasing file lock, it has to release lock it holds on EOF
buffer. NOTLOCKED bugcheck is returned if process is holding
PW (protected write) rather than EX (exclusive) lock on EOF
buffer. The check should be for either EX or PW lock.
This problem is fixed in OpenVMS Alpha V7.1.
o A loop may occur at the EXEC-MODE AST level suring the deletion of
network logical links. The processthat 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 Alpha 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 RMS bugcheck FTL$_BADEBKHBK
(R2=FFFFFFDC).
This problem is fixed in OpenVMS Alpha V7.1.
o Improved error reporting on ASB allocation failure. If there
is a user context to return the error to, RMS$_DME will now be
returned instead of RMS$_BUSY.
When RMS allocates an Asynchronous Status Block (ASB) for an
RMS thread from process-permanent pages (PIOPAGES), and the
allocation attempt fails due to lack of memory. The error is
not properly handled: in some cases the error is ignored,
leading to subsequent hangs and inconsistencies, or else the
true cause of the error is obscured by overlapping bugchecks.
These allocation failures are most likely to be encountered
with RMS journaling applications, and can be avoided by
increasing the PIOPAGES SYSGEN parameter.
This problem is fixed in OpenVMS Alpha V7.1.
o Non-indexed file opened with an indexed file XAB may ACCVIO.
If a non-indexed file (sequential or relative) is opened with
one or more XABs specific to indexed files (XABKEY, XABSUM, or
XABALL) chained to the FAB, the process may either:
o Terminate (SYSGEN parameter BUGCHECKFATAL not enabled) with
an access violation (ACCVIO); or
o Crash the system (BUGCHECKFATAL enabled) with a SSRVEXCEPT
ACCVIO.
A necessary condition for this to occur is that the virtual
address space used for the program region (P0) must be more
than half a gigabyte. In other words, it requires both a very
large application and one that has indexed XABs chained to the
FAB for a non-indexed file. We are aware of only one
application that this problem has occurred with to date:
ALL-IN-1.
This problem is fixed in OpenVMS Alpha V7.1.
NOTE: Until the system can be upgraded to OpenVMS Alpha V7.1
or this remedial kit can be installed, these symptoms may be
avoided by modifying the application's source code. Remove any
of the indexed XABs (XABSUM, XABKEY, or XABALL) from the chain
off the FAB for any file that is not an indexed file.
o Fix for SDA-W-FAOERR when displaying RMS FWA (File Work Area).
The contents of a buffer (LOGNAM) are being displayed after the
space have been returned and reallocated for some other use.
This problem is fixed in OpenVMS Alpha V7.1.
Problems addressed in ALPRMS01_062:
o Make last chance handler more robust when a process that has a
file opened with global buffers enabled is terminated with
STOP/ID. STOP/ID invokes the RMS abort last chance handler
(RM$LAST_CHANCE). Problems addressed include:
o 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.
o 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.
These problems are fixed in OpenVMS Alpha V7.1.
o Fix for a bugcheck on a compressed secondary key. 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) would overflow
a 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 indexes and leave the file
in a consistent state.
This problem is corrected in OpenVMS Alpha V7.0.
o Fix for a SIDR (secondary index data record) compressed key
expansion problem that could result in a corrupted SIDR bucket.
The conditions that are required make the probability of its
occurrence are rare.
For this problem to occur requires both (1) the presence of
many duplicate records for a secondary key, (2) a secondary key
of string type that is 9 bytes or more in length, and (3) 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 Alpha V7.0.
o Audit check fix for installed /OPEN images. Incomplete
security success audit information is generated upon image
activation of installed /OPEN images in some cases.
This problem is fixed in OpenVMS Alpha V7.1.
o Fix for Known File Entry (KFE) file open SSRVEXCEPT (Unexpected
system service exception) due to 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 Alpha V7.0.
o Fix for crash with kernel-mode caller.
A kernel-mode caller may crash with KRNLSTAKNV (kernel stack
not valid). A page in the kernel stack has the 'fault on
write' bit set.
This problem is fixed in OpenVMS Alpha V7.1.
o Statistics setting on a file is 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.
This problem is fixed in OpenVMS Alpha V7.1.
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 is fixed in OpenVMS V7.0.
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OpenVMS database(s). To view these articles, open the appropriate
product database and perform a query using either of the following
search strings: 'ALPRMS04_062' or 'ALPRMS'.
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:
The images in this kit will not take effect until the system is
rebooted.
If there are other nodes in the VMS 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 | 1434EE8D | X-3 | 29-AUG-1999 |
| | | 19:26:44.02 |
+----------------------------+----------+-----------------+--------------+
| CONVSHR.EXE | B259E6DD | X1-007 | 29-AUG-1999 |
| | | 19:25:20.44 |
+----------------------------+----------+-----------------+--------------+
| EXCHANGE$NETWORK.EXE | 14FA493C | X-5B1 | 13-OCT-1998 |
| | | 22:33:00.94 |
+----------------------------+----------+-----------------+--------------+
| RECLAIM.EXE | D96E6478 | X-3 | 29-AUG-1999 |
| | | 19:27:12.93 |
+----------------------------+----------+-----------------+--------------+
| RECOVER.EXE | 82B8418B | X-16 | 25-NOV-1996 |
| | | 11:48:59.99 |
+----------------------------+----------+-----------------+--------------+
| RMS.EXE | A47E72AD | X-3 | 23-FEB-2000 |
| | | 11:49:06.65 |
+----------------------------+----------+-----------------+--------------+
| RMSREC$SERVER.EXE | ACDAED12 | X-8 | 25-NOV-1996 |
| | | 11:49:07.89 |
+----------------------------+----------+-----------------+--------------+
|
