Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXRMS01_073 VAX V7.3 RMS ECO Summary
*OpenVMS] VAXRMS01_073 VAX V7.3 RMS ECO Summary
New Kit Date: 17-OCT-2002
Modification Date: Not Applicable
Modification Type: NEW KIT
Copyright (c) Compaq Computer Corporation 2001,2002. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENT: RMS
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXRMS01_073
ECO Kits Superseded by This ECO Kit: None
ECO Kit Approximate Size: 864 Blocks
Kit Applies To: OpenVMS VAX V7.3
System/Cluster Reboot Necessary: Yes
Rolling Re-boot Supported: Yes
Installation Rating: INSTALL_1
1 - To be installed by all customers.
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 VAX V7.3. This kit addresses the following
problems:
PROBLEMS ADDRESSED IN VAXRMS01_073 KIT
o RMS: Fix for potential RMS lock hang when global buffers are
enabled.
This problem involves a rare condition if the last accessor of
the global section is interrupted by an abort rundown, which
may lead to the need for the cleanup of the global section not
being properly detected. This could result in the survival of
the global section and a global bucket system lock after the
last accessor is deleted.
Since this problem requires the accessor that is aborted to
also be the last accessor, it is more apt to occur with a file
that accessors come and go -- with a file that is opened and
closed frequently and may have only one accessor at a
particular time (e.g. RIGHTSLIST.DAT) -- versus a file with
global buffers enabled that typically has several concurrent
accessors at all times until there is an application (or
system) shutdown.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Fix to prevent possible process hangs and system crashes
when files with global buffers are accessed.
An application accessing a file with global buffers enabled
might experience any one of several symptoms ranging from an
IVLOCKID being returned to RMS through a possible SSRVEXCEPTN
due to corruption of an RMS internal control structure.
Prior to this change, it is possible for an internal table
maintained by RMS (the Global Buffer Interlock Table) within
its global buffer sections to overflow. This can potentially
result in corruption to adjoining control structures. No user
data are compromised; however, the process may hang or the
system crash depending on what is overwritten. This problem
is most prevalent on systems where there is a high turnover of
processes.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Fix for inconsistent secondary key index structure.
Any application that does a lot of deleting or does updates
that change a no duplicate secondary key value to another
value in an indexed file is a potential candidate for this
problem.
An ANALYZE/RMS_FILE of the indexed file reports the following
error for a secondary key:
"Index bucket references missing data bucket with VBN nnn"
The problem may be that the secondary index structure has
duplicate index value entries and there should never be
duplicates in the index structure. If the secondary index
allows a binary search (is uncompressed), records could be
hidden using an exact secondary key lookup.
This problem results from the entire space being
inappropriately reclaimed for the physically last SIDR record
in some secondary data bucket which contains only deleted
entries.
This problem is restricted to an indexed file with a secondary
key that allows no duplicates. 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.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Fix for some records being potentially skipped over in a
reverse key search.
If the very last bucket in the data bucket chain for a
particular key-of-reference is empty (no valid records), the
potential exists for any valid records in the next-to-the-last
bucket (and only this bucket) being skipped over in the
backwards scan done by a reverse key search.
This problem is restricted to a reverse key search.
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 RMS: Avoid an exec-mode infinite loop if RMS ever attempts to
add a duplicate key value to a compressed index bucket.
An index bucket should never have a duplicate key value.
There is the potential, however, some inconsistency
(corruption) in a lower level could result in such an attempt
in the case of a compressed key. A correction has been added
to issue a nonfatal RMS bugcheck (ISAM) and avoid the loop.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Fix to prevent a non-fatal SSRVEXCEPT bugcheck when a
wildcard network copy completes.
Attempts to perform wild card file copy operations across the
network may fail with a non-fatal SSRVEXCEPT bugcheck upon
completion when a third party event notification software
package is installed. Stale information contained within a
recycled DAP message buffer could cause an invalid path to be
executed during the implicit $DISPLAY of a file during RMS
rundown.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Correction for processes exiting with RMS IORNDN
non-fatal bugcheck.
Processes may disappear with RMS IORNDN non-fatal bugchecks
when an EXIT is requested by an Executive-mode application
(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.
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 RMSBUG (R2=FFFFFFF0, IORNDN) bugcheck.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Warning added that the limit of 16383 for the number of
either file opens or stream connects by one process has been
exceeded.
The Internal File (IFI) and Stream Identifier (ISI) values for
file opens or stream connects are limited to 14 bits (or a
maximum value of 16383). Exceeding the limit can result in
unpredictable error conditions depending on what operations
are attempted after the open or connect. Prior to this
change, RMS failed to issue a warning when this limit was
exceeded.
RMS has been modified to return a RMS$_DME error status so an
application won't continue when this limit is exceeded for an
$OPEN or $CONNECT. This serves as a warning to an application
that it must be redesigned to limit either the number of files
opened or streams connected to less than 16383.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Set the return length of the auxiliary buffer for calls
to SYS$FILESCAN.
The return length of the auxiliary buffer ("retlen" optional
parameter) that was passed to SYS$FILESCAN was not being set
when the Field Flags argument ("fldflags" parameter) was
absent. This change sets the return length value
unconditionally when one has been requested.
Images Affected:[SYS$LDR]RMS.EXE
o RMS: Rollback of a remote file transfer change made in
OpenVMS VAX V7.2R and V7.3 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 VAX V7.2R 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 VAX 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.
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 VAX V7.2R (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 VAX V7.2R or
V7.3 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
the VAX 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 CONVERT/RECLAIM: Fix to prevent the CONVERT/RECLAIM utility
from producing an inconsistent index structure in an indexed
file during a reclamation.
An ANALYZE/RMS_FILE reports the following error:
"Index bucket references missing data bucket with VBN nnn"
A level 1 index record associated with a data (level 0) bucket
that was reclaimed was not removed from the index bucket, as
it should have been.
It is extremely difficult to detect in advance of doing a
convert/reclaim whether an indexed file is vulnerable if a
reclaim were applied to it. For example, one condition is
that one of the initial level 1 index buckets associated with
data buckets eligible for reclamation has some condition (for
example, only one index record) that will cause a rollback of
a removed index record during a reclamation.
Without the fix, doing a full convert (without the /RECLAIM
qualifier) ensures avoiding this problem.
Images Affected:[SYSEXE]RECLAIM.EXE
[SYSEXE]CONVERT.EXE
[SYSLIB]CONVSHR.EXE
o CONVERT: Fix to prevent accvio when repeated calls are made
to CONVERT utility callable interface.
When making repeated calls to the CONVERT utility callable
interface from within a user application, an access violation
or various sort errors may be returned. The following
conditions must exist for this error to occur:
- An application must be making repeated calls to the
callable CONVERT interface.
- The current file being converted must have more than 3
keys.
- At least one of the previously converted files must have
had all compressions disabled.
- The current file being converted must have some
compression enabled.
Images Affected:[SYSEXE]CONVERT.EXE
[SYSLIB]CONVSHR.EXE
o CONVERT: Fix for remote file DAP protocol regression.
The convert utility fails with the following error when the
input file is a sequential file on a remote foreign (non-VMS)
system and the output file is a sequential file on a VMS
system if and only if /SORT is explicitly specified or implied
by /FDL:
%CONV-F-READERR, Error reading (IBM_filename)
-RMS-F-BUG_DAP, Data Access Protocol error detected;
DAP code = 0001A008
The problem is not reproducible using a remote VMS system.
Images Affected:[SYSEXE]CONVERT.EXE
[SYSLIB]CONVSHR.EXE
o CONVERT: 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
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: 'VAXRMS01_073' 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.
All trademarks are the property of their respective owners.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| CONVERT.EXE |%X55A60565| X-5 | 26-JUN-2002 |
| | | 14:41:37.64 |
+----------------------------+----------+-----------------+--------------+
| CONVSHR.EXE |%XB4BA15DB| X-1 | 26-JUN-2002 |
| | | 14:37:31.14 |
+----------------------------+----------+-----------------+--------------+
| RECLAIM.EXE |%X314BC452| X-5 | 26-JUN-2002 |
| | | 14:41:39.78 |
+----------------------------+----------+-----------------+--------------+
| RMS.EXE |%XF0B3FA06| RMS | 8-AUG-2002 |
| | | 08:59:26.38 |
+----------------------------+----------+-----------------+--------------+
|
