Kit Name: ALPRMS02_071 Kits superseded by this kit: ALPRMS01_071 Kit Description: Version(s) of OpenVMS to which this kit may be applied: OpenVMS Alpha V7.1 In order to receive the full fixes listed in this kit the following remedial kits also need to be installed: None Files patched or replaced: o [SYS$LDR]RMS.EXE (new image) o [SYSEXE]EXCHANGE$NETWORK.EXE (new image) Problems addressed in ALPRMS02_071 kit 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. Page 2 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. Page 3 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 kit 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: o Terminate (SYSGEN parameter BUGCHECKFATAL not enabled) with an access violation (ACCVIO); or o 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." 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: o The DEC COBOL application fails with the COB-F-BUG_CHECK error when it is reading data records in a sequential file. o The sequential file is opened allowing no write sharing. o 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. o All the data records in the sequential file are read up to the end-of-file by the DEC COBOL application. Page 4 o 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. o 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 Page 5 completion status. Kit Installation Rating: The following kit installation rating, based upon current CLD information, is provided to serve as a guide as to which customers should apply this remedial kit. (Reference attached Disclaimer of Warranty and Limitation of Liability Statement) INSTALLATION RATING: 1 : To be installed by all customers. Installation Instructions: Install this kit with the VMSINSTAL utility by logging into the SYSTEM account, and typing the following at the DCL prompt: @SYS$UPDATE:VMSINSTAL ALPRMS02_071 [location of the saveset] The saveset location may be a tape drive, or a disk directory that contains the kit saveset. System should be rebooted after successful installation of the kit. If you have other nodes in your VMScluster, they should also be rebooted in order to make use of the new image(s). Copyright (c) Digital Equipment Corporation, 1997 All Rights Reserved. Unpublished rights reserved under the copyright laws of the United States. The software contained on this media is proprietary to and embodies the confidential technology of Digital Equipment Corporation. Possession, use, or dissemination of the software and media is authorized only pursuant to a valid written license from Digital Equipment Corporation. DISCLAIMER OF WARRANTY AND LIMITATION OF LIABILITY THIS PATCH IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE EXTENT PERMITTED BY APPLICABLE LAW. IN NO EVENT WILL DIGITAL BE LIABLE FOR ANY LOST REVENUE OR PROFIT, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, WITH RESPECT TO ANY PATCH MADE AVAILABLE HERE OR TO THE USE OF SUCH PATCH.