ECO NUMBER: ALPRMS04_062 PRODUCT: OpenVMS Alpha OPERATING SYSTEM 6.2 UPDATE PRODUCT: OpenVMS Alpha OPERATING SYSTEM 6.2 COVER LETTER 1 KIT NAME: ALPRMS04_062 2 KITS SUPERSEDED BY THIS KIT: ALPRMS03_062. 3 KIT DEPENDENCIES: 3.1 The following remedial kit(s) must be installed BEFORE installation of this, or any required kit: ALPCLUSIO01_062 3.2 In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None. 4 KIT DESCRIPTION: 4.1 Version(s) of OpenVMS to which this kit may be applied: OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3 4.2 Files patched or replaced: o [SYS$LDR]RMS.EXE (new image) o [SYSLIB]CONVSHR.EXE (new image) o [SYSEXE]RECLAIM.EXE (new image) o [SYSEXE]CONVERT.EXE (new image) o [SYSEXE]EXCHANGE$NETWORK.EXE (new image) o [SYSEXE]RECOVER.EXE (new image) o [SYSEXE]RMSREC$SERVER.EXE (new image) o [SYS$LDR]RMSDEF.STB (new file) -- COVER LETTER -- Page 2 31 August 2000 5 PROBLEMS ADDRESSED IN ALPRMS04_062 KIT 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. -- COVER LETTER -- Page 3 31 August 2000 o Prevent deadlock hang in RMS last chance handler. 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 Mark the Buffer Descriptor as busy for asynch multistreamed block IO autoextends. Performing multistreamed asynchronous Block IO to a sequential file could result in random data corruption and/or sporadic SS$_BADPARAM errors if an autoextend occurs. This problem is fixed in the release of OpenVMS Alpha to follow V7.2. o Prevent RMS IORNDN non-fatal bugchecks when an Executive-mode subsystem Exits. 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. 6 PROBLEMS ADDRESSED IN ALPRMS03_062 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. -- COVER LETTER -- Page 4 31 August 2000 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. -- COVER LETTER -- Page 5 31 August 2000 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. -- COVER LETTER -- Page 6 31 August 2000 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 -RMS-F-UBF, invalid user buffer 7 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 Fix for compressed primary key problem that occurs in the context of record deletes being done using sequential access rather than keyed access. -- COVER LETTER -- Page 7 31 August 2000 Sequentially walking through (getting) the primary data records in an indexed file (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 Fix for loop when deleting network logical links. Loop occurs at exec-mode AST level and process cannot be deleted. Process in loop 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 Autoextend fix for shared block I/O write which requires use of 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 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. -- COVER LETTER -- Page 8 31 August 2000 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. 8 PROBLEMS ADDRESSED IN ALPRMS01_062 KIT 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: -- COVER LETTER -- Page 9 31 August 2000 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. -- COVER LETTER -- Page 10 31 August 2000 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. 9 KIT INSTALLATION RATING: The following kit installation rating, based upon current CLD information, is provided to serve as a guide to which customers should apply this remedial kit. (Reference attached Disclaimer of Warranty and Limitation of Liability Statement) INSTALLATION RATING: INSTALL_1 : To be installed by all customers. -- COVER LETTER -- Page 11 31 August 2000 10 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 ALPRMS04_062 [location of the saveset] The saveset location may be a tape drive, CD, or a disk directory that contains the kit saveset. 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. Copyright (c) Compaq Computer Corporation, 1999 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 Compaq Computer Corporation. Possession, use, or dissemination of the software and media is authorized only pursuant to a valid written license from Compaq Computer 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 COMPAQ 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.