|
|
 |
OpenVMS ALPRMS04_071 Alpha V7.1 RMS ECO Summary
|
TITLE: OpenVMS ALPRMS04_071 Alpha V7.1 RMS ECO Summary
Modification Date: 18-OCT-1999
Modification Type: Updated Kit: Supersedes ALPRMS03_071
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 1997, 1999. All rights reserved.
PRODUCT: OpenVMS Alpha
COMPONENT: RMS.EXE - Record Management Services
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPRMS04_071
ECO Kits Superseded by This ECO Kit: ALPRMS03_071
ALPRMS02_071
ALPRMS01_071
ECO Kit Approximate Size: 3456 Blocks
Kit Applies To: OpenVMS Alpha V7.1, 7.1-1H1, 7.1-1H2
System/Cluster Reboot Necessary: 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:
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 Alpha V7.1 through V7.1-1H2.
Problems addressed in ALPRMS04_071:
o RMS directory cache limits have been removed. Prior to this
enhancement, the maximum size of a directory file that RMS
would cache was 127 blocks; wildcard lookups to larger
directories would go directly to the file system.
With this enhancement, RMS attempts to cache directories of
any size. If memory or other resources are not available to
cache the directory file, wildcard lookups are then directed
to the file system.
This RMS enhancement improves the performance of wildcard
searches. It does not improve the performance of directory
inserts or deletes; management of the latter is done directly
by the file system.
This enhancement is included in OpenVMS Alpha V7.2.
o The directory overhead associated with journal file creation
and deletion has been reduced.
Prior to Version 7.2, recovery unit (RU) journals were created
temporarily in the [SYSJNL] directory on the same volume as
the file that was being journaled. The file name for the
recovery unit journal had the form RMS$process_id (where
process_id is the hexadecimal representation of the process
ID) and a file type of RMS$JOURNAL.
The following changes are being introduced to RU journal file
creation in this remedial release of OpenVMS Version 7.1:
+ The files are created in node-specific sub-directories
of the [SYSJNL] directory.
+ The file name for the recovery unit journal has been
shortened to the form: YYYYYYYY, where YYYYYYYY is the
hexadecimal representation of the process ID in reverse
order.
The following example shows both the previous and current
versions of journal file creation:
Previous versions: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
Current version: [SYSJNL.NODE1]CB300412.;1
If RMS does not find either the [SYSJNL] directory or the
node-specific directory, RMS creates them automatically.
This enhancement is included in OpenVMS Alpha V7.2.
o A SYS$FILESCAN fatal (SYSTEM-F-ACCVIO) error is possible.
For this problem to occur the mandatory first argument in the
call to SYS$FILESCAN must contain a descriptor with both a
zero length and a zero pointer to the string to be searched
for the file specification. In other words, no file
specification is being passed. The caller is doing a no-op
call to $FILESCAN without allocating a valid buffer for its
null request. RMS returns a fatal (SYSTEM-F-ACCVIO) error to
the caller as a result of a probe, but the process is not
terminated.
The fix will result in a success status being returned for a
zero length (null) request.
This problem is fixed in OpenVMS Alpha V7.2.
o An ANALYZE/RMS_FILE of the 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 record 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. This conversion is totally transparent to applications.
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, with
RU journaling enabled, inappropriate data buckets may be
erroneously reclaimed.
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.
Problems addressed in ALPRMS03_071:
o Performance enhancements to Global Buffer processing.
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).
Note that increasing the number of global buffers on specific
files may require some system resources to be increased in
size. In particular, the SYSGEN parameters GBLPAGES,
GBLPAGFIL or GBLSECTIONS may need to be increased. In
addition, process working set size and page file quota may
need to be increased.
This enhancement is included in the next release after OpenVMS
Alpha V7.1.
o Enhancement to add 128-bit UTC support for FAL/RMS time
transfers.
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.
This enhancement is included in the next release after OpenVMS
Alpha V7.1.
o Fix to $READ for invalid transfer size and status returned for
last transfer preceding end-of-file
This problem is restricted to an application using the user
RAB64 structure for a $READ (block I/O) with a buffer size
greater than 65535 bytes. If the last transfer just preceding
the end-of-file exceeds 65535 bytes, then the transfer size
returned in the RAB64 (RAB64$L_RSZ) is invalid and an
RMS-E-EOF status is returned. The correct transfer size will
now be returned with the appropriate status of RMS-S-NORMAL.
This problem was introduced in Alpha V7.0 when the maximum
transfer size was increased from 65535 bytes to 2**31 - 1
bytes.
Alternative workarounds:
+ Apply this remedial kit.
+ Temporarily modify application to restrict block I/O
($READ) transfer size to 127 blocks.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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.
Alternative workarounds:
+ Apply this remedial kit.
+ Following the change in the protection information,
perform an INSTALL/REPLACE on all other nodes in the
cluster.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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.
Alternative workarounds:
+ Apply this remedial kit.
+ Disable KEY compression for the key.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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.
Alternative workarounds:
+ Apply this remedial kit.
+ Disable KEY compression.
This problem was introduced in OpenVMS V6.0. The problem is
fixed in the next release after OpenVMS Alpha V7.1.
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.
+ Use STOP/ID to terminate the process.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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 - 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.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to prevent record locking on the Null device when
encountered in a searchlist.
If the null device is included in a searchlist for a shared
file open, it may inappropriately be accessed with record
locking enabled. Since the null device does not support the
record locking option, the inconsistency may cause an RMS
bugcheck to be reported.
Alternative workarounds:
+ Apply this remedial kit.
+ Place the null device as the first element of the
searchlist, or omit it.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to properly handle buffered block-mode file transfers from
a foreign host that uses a non-standard block size.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to prevent NETBTS (network buffer too small) errors when
reading a remote file with Undefined (UDF) record format.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to correctly fill in XAB$_NET items when executing a
$DISPLAY operation that doesn't require accessing the remote
node.
A $DISPLAY operation failed to fill in the XAB$_NET XABITMs if
a network access wasn't 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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to handle Stream file carriage control for network access
to non-OpenVMS systems.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
Problems addressed in ALPRMS02_071:
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 exec-mode access violation (accvio) that results from
issuing an RFA access using a VBN that exceeds the highest
block (out-of-range) currently allocated to a file.
The accvio will only occur if the out-of-range RFA access is
done to a file that is both an indexed file and has global
buffers enabled. 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.
Note: RFA access is a rare access mode for an application to
use with an indexed file; an out-of-range RFA access to an
indexed file should be even rarer.
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 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.
Problems Addressed in ALPRMS01_071:
o Fix for NULL KEY option for PACKED DECIMAL key type.
This problem is restricted to an indexed file that has a secondary
key type of PACKED DECIMAL and the NULL KEY option set. In
performing adds or updates to the indexed file, the application may
ACCVIO. The process may either:
- Terminate (SYSGEN parameter BUGCHECKFATAL not enabled) with an
access violation (ACCVIO); or
- Crash the system (BUGCHECKFATAL enabled) with a SSRVEXCEPT
(unexpected system service exception) ACCVIO error.
NOTE: Until this remedial kit can be installed, this problem can be
prevented from reoccurring by converting the file with a
revised FDL in which the null key option for the packed
decimal secondary key has been changed to "no."
The problem is fixed in the next release after OpenVMS Alpha V7.1.
Workaround:
- Convert the file temporarily (until the remedial kit is
applied) with a revised FDL in which the null key option for
the packed decimal secondary key has been changed to "no."
o Solution for COB-F-BUG_CHECK error when rereading a sequential file.
This problem is restricted to DEC COBOL on OpenVMS Alpha V7.1.
While a DEC COBOL application may fail with a COBOL internal
consistency error (COB-F-BUG_CHECK) for other reasons, a DEC COBOL
application that worked on an earlier OpenVMS version and is failing
on Alpha V7.1 with a COB-F-BUG_CHECK is likely to be remedied by
this remedial kit if ALL of the following conditions are met:
- The DEC COBOL application fails with the COB-F-BUG_CHECK error
when it is reading data records in a sequential file.
- The sequential file is opened allowing no write sharing.
- The sequential file has a maximum record size greater than
zero. A fixed-length record format always has a maximum record
size greater than zero. A zero maximum record size is
typically associated with a variable or stream record format.
- All the data records in the sequential file are read up to the
end-of-file by the DEC COBOL application.
- And the DEC COBOL application reads all the data records in the
same sequential file more than once.
The DEC COBOL application is either run multiple times within a
short time period on the same system or within the application
itself, all the data records in the same sequential file are
read up to the end-of-file more than once.
If the data records are only read once, then even if all the
other conditions are met, the problem will not occur.
- Presumption: The OpenVMS virtual I/O cache (VIOC) is enabled
(and since it is enabled by default, it will be unless someone
has explicitly disabled it).
A change in behavior between RMS and the VIOC cache was added as a
performance enhancement for RMS in Alpha V7.1 (see Section 5.18 of
the OpenVMS V7.1 Release Notes). VIOC now lets RMS know if it is
able to satisfy one of RMS's read requests from blocks already in
its cache. This allows RMS to avoid stalling, which reduces
overhead and improves performance. Some RMS operations that always
stalled previously may now never stall.
In the case of an unshared sequential file (with maximum record
size > 0), DEC COBOL does not use RMS record I/O ($GETs) to read the
records in the file. DEC COBOL uses asynchronous block I/O ($READs)
and intermediate buffers of its own to do its own record processing.
After reading all the data records in an unshared file, a number of
the blocks may be cached by VIOC, including data blocks beyond the
logical end-of-file. In coding the error checking for the
asynchronous block I/Os, DEC COBOL presumed that an end-of-file
(EOF) status would always be returned as a completion status after a
wait and never as an immediate status for the asynchronous block I/O
read.
With the V7.1 RMS/VIOC enhancement, if the file is reread while the
blocks are still cached, it is possible for an EOF status to be
appropriately returned by RMS as an immediate status. In the case
of an unexpected immediate error status, DEC COBOL returns the
COB-F-BUG_CHECK. In other words, DEC COBOL is returning the
COB-F-BUG_CHECK for an EOF status -- when in fact the read is beyond
the logical end-of-file.
The RMS/VIOC enhancement is a compatible extension of the definition
of the RMS services; a block I/O read ($READ) may (as has always
been true) complete with a status of RMS$_EOF. However, to expedite
delivery of a solution for any DEC COBOL users who may be impacted,
RMS has restored the old status behavior that DEC COBOL presumed.
Namely, in the case of an asynchronous block I/O read that completes
synchronously and the transfer is beyond the logical end-of-file,
RMS$_PENDING will be returned as the immediate status and RMS$_EOF
as the completion status.
Workaround:
Alternative workaround when a nonshared sequential file has to be
read multiple times within a DEC COBOL application:
- Until the kit is installed, DEC COBOL Engineering recommends
modifying the application's source code to temporarily remove
any APPLY PREALLOCATION and APPLY EXTENSION statements. There
is no guarantee that this will provide a workaround in all
cases. Underallocating the file simply decreases the
probability of this problem occurring in some cases. Since not
preallocating a file (or using a reasonable extension size) can
degrade performance, this should be viewed only as a possible
temporary workaround to this specific problem.
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.
Copyright (c) Compaq Computer Corporation 1997, 1998. All rights reserved.
Modification Date: 18-OCT-1999
Modification Type: ARCHIVED
PRODUCT: DIGITAL OpenVMS Alpha
COMPONENT: RMS.EXE - Record Management Services
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPRMS03_071
ECO Kits Superseded by This ECO Kit: ALPRMS02_071
ALPRMS01_071
ECO Kit Approximate Size: 2286 Blocks
Kit Applies To: OpenVMS Alpha V7.1, 7.1-1H1, 7.1-1H2
System/Cluster Reboot Necessary: 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:
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 Alpha V7.1 through V7.1-1H2.
Problems addressed in ALPRMS03_071:
o Performance enhancements to Global Buffer processing.
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).
Note that increasing the number of global buffers on specific
files may require some system resources to be increased in
size. In particular, the SYSGEN parameters GBLPAGES,
GBLPAGFIL or GBLSECTIONS may need to be increased. In
addition, process working set size and page file quota may
need to be increased.
This enhancement is included in the next release after OpenVMS
Alpha V7.1.
o Enhancement to add 128-bit UTC support for FAL/RMS time
transfers.
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.
This enhancement is included in the next release after OpenVMS
Alpha V7.1.
o Fix to $READ for invalid transfer size and status returned for
last transfer preceding end-of-file
This problem is restricted to an application using the user
RAB64 structure for a $READ (block I/O) with a buffer size
greater than 65535 bytes. If the last transfer just preceding
the end-of-file exceeds 65535 bytes, then the transfer size
returned in the RAB64 (RAB64$L_RSZ) is invalid and an
RMS-E-EOF status is returned. The correct transfer size will
now be returned with the appropriate status of RMS-S-NORMAL.
This problem was introduced in Alpha V7.0 when the maximum
transfer size was increased from 65535 bytes to 2**31 - 1
bytes.
Alternative workarounds:
+ Apply this remedial kit.
+ Temporarily modify application to restrict block I/O
($READ) transfer size to 127 blocks.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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.
Alternative workarounds:
+ Apply this remedial kit.
+ Following the change in the protection information,
perform an INSTALL/REPLACE on all other nodes in the
cluster.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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.
Alternative workarounds:
+ Apply this remedial kit.
+ Disable KEY compression for the key.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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.
Alternative workarounds:
+ Apply this remedial kit.
+ Disable KEY compression.
This problem was introduced in OpenVMS V6.0. The problem is
fixed in the next release after OpenVMS Alpha V7.1.
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.
+ Use STOP/ID to terminate the process.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
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 - 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.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to prevent record locking on the Null device when
encountered in a searchlist.
If the null device is included in a searchlist for a shared
file open, it may inappropriately be accessed with record
locking enabled. Since the null device does not support the
record locking option, the inconsistency may cause an RMS
bugcheck to be reported.
Alternative workarounds:
+ Apply this remedial kit.
+ Place the null device as the first element of the
searchlist, or omit it.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to properly handle buffered block-mode file transfers from
a foreign host that uses a non-standard block size.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to prevent NETBTS (network buffer too small) errors when
reading a remote file with Undefined (UDF) record format.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to correctly fill in XAB$_NET items when executing a
$DISPLAY operation that doesn't require accessing the remote
node.
A $DISPLAY operation failed to fill in the XAB$_NET XABITMs if
a network access wasn't 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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
o Fix to handle Stream file carriage control for network access
to non-OpenVMS systems.
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.
The problem is fixed in the next release after OpenVMS Alpha
V7.1.
Problems addressed in ALPRMS02_071:
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 exec-mode access violation (accvio) that results from
issuing an RFA access using a VBN that exceeds the highest
block (out-of-range) currently allocated to a file.
The accvio will only occur if the out-of-range RFA access is
done to a file that is both an indexed file and has global
buffers enabled. 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.
Note: RFA access is a rare access mode for an application to
use with an indexed file; an out-of-range RFA access to an
indexed file should be even rarer.
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 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.
Problems Addressed in ALPRMS01_071:
o Fix for NULL KEY option for PACKED DECIMAL key type.
This problem is restricted to an indexed file that has a secondary
key type of PACKED DECIMAL and the NULL KEY option set. In
performing adds or updates to the indexed file, the application may
ACCVIO. The process may either:
- Terminate (SYSGEN parameter BUGCHECKFATAL not enabled) with an
access violation (ACCVIO); or
- Crash the system (BUGCHECKFATAL enabled) with a SSRVEXCEPT
(unexpected system service exception) ACCVIO error.
NOTE: Until this remedial kit can be installed, this problem can be
prevented from reoccurring by converting the file with a
revised FDL in which the null key option for the packed
decimal secondary key has been changed to "no."
The problem is fixed in the next release after OpenVMS Alpha V7.1.
Workaround:
- Convert the file temporarily (until the remedial kit is
applied) with a revised FDL in which the null key option for
the packed decimal secondary key has been changed to "no."
o Solution for COB-F-BUG_CHECK error when rereading a sequential file.
This problem is restricted to DEC COBOL on OpenVMS Alpha V7.1.
While a DEC COBOL application may fail with a COBOL internal
consistency error (COB-F-BUG_CHECK) for other reasons, a DEC COBOL
application that worked on an earlier OpenVMS version and is failing
on Alpha V7.1 with a COB-F-BUG_CHECK is likely to be remedied by
this remedial kit if ALL of the following conditions are met:
- The DEC COBOL application fails with the COB-F-BUG_CHECK error
when it is reading data records in a sequential file.
- The sequential file is opened allowing no write sharing.
- The sequential file has a maximum record size greater than
zero. A fixed-length record format always has a maximum record
size greater than zero. A zero maximum record size is
typically associated with a variable or stream record format.
- All the data records in the sequential file are read up to the
end-of-file by the DEC COBOL application.
- And the DEC COBOL application reads all the data records in the
same sequential file more than once.
The DEC COBOL application is either run multiple times within a
short time period on the same system or within the application
itself, all the data records in the same sequential file are
read up to the end-of-file more than once.
If the data records are only read once, then even if all the
other conditions are met, the problem will not occur.
- Presumption: The OpenVMS virtual I/O cache (VIOC) is enabled
(and since it is enabled by default, it will be unless someone
has explicitly disabled it).
A change in behavior between RMS and the VIOC cache was added as a
performance enhancement for RMS in Alpha V7.1 (see Section 5.18 of
the OpenVMS V7.1 Release Notes). VIOC now lets RMS know if it is
able to satisfy one of RMS's read requests from blocks already in
its cache. This allows RMS to avoid stalling, which reduces
overhead and improves performance. Some RMS operations that always
stalled previously may now never stall.
In the case of an unshared sequential file (with maximum record
size > 0), DEC COBOL does not use RMS record I/O ($GETs) to read the
records in the file. DEC COBOL uses asynchronous block I/O ($READs)
and intermediate buffers of its own to do its own record processing.
After reading all the data records in an unshared file, a number of
the blocks may be cached by VIOC, including data blocks beyond the
logical end-of-file. In coding the error checking for the
asynchronous block I/Os, DEC COBOL presumed that an end-of-file
(EOF) status would always be returned as a completion status after a
wait and never as an immediate status for the asynchronous block I/O
read.
With the V7.1 RMS/VIOC enhancement, if the file is reread while the
blocks are still cached, it is possible for an EOF status to be
appropriately returned by RMS as an immediate status. In the case
of an unexpected immediate error status, DEC COBOL returns the
COB-F-BUG_CHECK. In other words, DEC COBOL is returning the
COB-F-BUG_CHECK for an EOF status -- when in fact the read is beyond
the logical end-of-file.
The RMS/VIOC enhancement is a compatible extension of the definition
of the RMS services; a block I/O read ($READ) may (as has always
been true) complete with a status of RMS$_EOF. However, to expedite
delivery of a solution for any DEC COBOL users who may be impacted,
RMS has restored the old status behavior that DEC COBOL presumed.
Namely, in the case of an asynchronous block I/O read that completes
synchronously and the transfer is beyond the logical end-of-file,
RMS$_PENDING will be returned as the immediate status and RMS$_EOF
as the completion status.
Workaround:
Alternative workaround when a nonshared sequential file has to be
read multiple times within a DEC COBOL application:
- Until the kit is installed, DEC COBOL Engineering recommends
modifying the application's source code to temporarily remove
any APPLY PREALLOCATION and APPLY EXTENSION statements. There
is no guarantee that this will provide a workaround in all
cases. Underallocating the file simply decreases the
probability of this problem occurring in some cases. Since not
preallocating a file (or using a reasonable extension size) can
degrade performance, this should be viewed only as a possible
temporary workaround to this specific problem.
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.
|
Files on this server are as follows:
|
»alprms04_071.README
»alprms04_071.CHKSUM
»alprms04_071.CVRLET_TXT
»alprms04_071.a-dcx_axpexe
»alprms04_071.CVRLET_TXT
|
