ECO NUMBER: VAXRMS04_062 PRODUCT: OpenVMS VAX OPERATING SYSTEM V6.2 UPDATE PRODUCT: OpenVMS VAX OPERATING SYSTEM V6.2 COVER LETTER 1 KIT NAME: VAXRMS04_062 2 KITS SUPERSEDED BY THIS KIT: VAXRMS03_062 3 KIT DEPENDENCIES: 3.1 The following remedial kit(s) must be installed BEFORE installation of this, or any required kit: None. 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 VAX V6.2. 4.2 Files patched or replaced: o [SYS$LDR]RMS.EXE (new image) o [SYSEXE]CONVERT.EXE (new image) o [SYSLIB]CONVSHR.EXE (new image) o [SYSEXE]EXCHANGE$NETWORK.EXE (new image) o [SYSEXE]RECLAIM.EXE (new image) o [SYSEXE]RECOVER.EXE (new image) o [SYSEXE]RMSREC$SERVER.EXE (new image) -- COVER LETTER -- Page 2 25 January 2001 5 PROBLEMS ADDRESSED IN VAXRMS04_062 KIT 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. o Fix to prevent an inconsistent primary index structure. This problem is characterized by an ANALYZE/RMS_FILE of an indexed file reporting the following error: "Index bucket references missing data bucket with VBN nnn" When the index bucket is examined, the problem is determined to be that the primary index structure has duplicate index entries. There should never be duplicate entries in the index structure. Any file 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 VAX V7.2. o Fix to prevent the creation of a corrupt file structure with repeated calls to the CONVERT callable interface. 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. o Fix convert/reclaim of RU_DELETED records. A CONVERT/RECLAIM of a fixed record length file with no compression enabled that has been used with RU journaling may inappropriately reclaim buckets containing valid user records. This results in data loss. This problem is fixed in OpenVMS VAX V7.2. -- COVER LETTER -- Page 3 25 January 2001 o Prevent RMS pool corruption when accessing bad .DIR file Access to a corrupted directory could result in the user's process being deleted from the system through an EXEC mode exception (a system bugcheck would occur if the SYSGEN parameter BUGCHECKFATAL were set). o Fix IORNDN non-fatal bugchecks caused by busy RMS stream. Processes may disappear with RMS IORNDN non-fatal bugchecks 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 increases the probability of the problem occurring. 6 PROBLEMS ADDRESSED IN VAXRMS03_062 KIT o A fix was done 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 A fix was done 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 A fix was done 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 -- COVER LETTER -- Page 4 25 January 2001 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 A XABITM stored semantics attribute fix was done for the 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 A fix was done to dynamically reflect file protection changes cluster wide for files that are INSTALLED with the /OPEN qualifier. Changes to the security profile of a file that was installed with the /OPEN qualifier were not reflected cluster wide until an INSTALL/REPLACE was performed on each node. With this correction, the protection information is dynamically propagated. o A fix was done 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 -- COVER LETTER -- Page 5 25 January 2001 applied. o A fix was done 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 A fix was done to prevent process hangs when RMS rundown is invoked from within an EXEC-mode AST. If RMS rundown is invoked from within an EXEC-mode AST, the process will hang indefinitely waiting on the delivery of pending ASTs. As documented in Section 2.5 of the RMS Reference Manual, RMS services should not be called from within an EXEC-mode AST. If however, an EXEC-mode AST routine fails due to an unhandled condition, RMS rundown will be indirectly invoked by the image exit (resulting in a process hang). The rundown routine has been modified to abort RMS rundown with an RMS$_BUSY return status if it has been invoked from within an EXEC-mode AST. o A fix was done 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. -- COVER LETTER -- Page 6 25 January 2001 o A fix was done 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 VAX V7.1 release. o A fix was done for an 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 A %CONV-F-READERR converting undefined file format to fixed occurred. 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 VAXRMS02_062 KIT o Fix for compressed primary key problem that occurs in the context of record deletes being done using sequential access rather than keyed access. 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 VAX 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 -- COVER LETTER -- Page 7 25 January 2001 buffer. The check should have been for either EX or PW lock (oversight in new routine added in OpenVMS VAX V6.1). This problem is fixed in OpenVMS VAX 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 VAX 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 VAX V7.1. o Fix for possible client/server hang in detached RU recovery server. Given the right series of coincidences, both a client RMS process and the detached RU recovery server process can hang when the client accesses a file on which there is an open RU transaction. This problem is fixed in OpenVMS VAX V7.1. 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 VAX V7.1. o Fix to detect outlier area on indexed file open. RMS-F-AID error (invalid area ID) was not reported on the open of an indexed file with an XABALL declaration that has an area ID that is exactly one greater than the maximum number of areas in that indexed file. A check has been added for record I/O access. Block I/O access is excluded from this check. This problem is fixed in OpenVMS VAX V7.1. -- COVER LETTER -- Page 8 25 January 2001 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. 8 PROBLEMS ADDRESSED IN VAXRMS01_062 KIT o Make last chance handler more robust when process that has file opened with global buffers enabled is terminated with STOP/ID. STOP/ID invokes the RMS abort last chance handler (RM$LAST_CHANCE). Problems addressed include: o A potential deadlock in the RMS last-chance handler if the same file is open more than once within a process or subprocess and it has global buffers set on it. o A potential fatal KRNLSTAKNV system crash due to nonfatal RMS bugchecks from failing $GETLKI calls which cause error rundown recursion until the stack fills up. The first problem is fixed in OpenVMS VAX V7.0; the second in OpenVMS VAX 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 -- COVER LETTER -- Page 9 25 January 2001 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 fixed in OpenVMS VAX 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 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 VAX V7.0. o Audit check fix for installed /OPEN images. Incomplete security success audit information is generated upon image activation of installed /OPEN images in some cases. This problem is fixed in OpenVMS VAX 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 VAX V7.0. 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 VAX V7.1. -- COVER LETTER -- Page 10 25 January 2001 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. 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 VAXRMS04_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, 2001 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. -- COVER LETTER -- Page 11 25 January 2001 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.