ECO NUMBER: VAXRMS01_073 PRODUCT: OpenVMS VAX OPERATING SYSTEM V7.3 UPDATE PRODUCT: OpenVMS VAX OPERATING SYSTEM V7.3 COVER LETTER 1 KIT NAME: VAXRMS01_073 2 KITS SUPERSEDED BY THIS KIT: None. 3 KIT DEPENDENCIES: 3.1 The following remedial kit(s), or later, 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, or later, should also be installed: None. 4 KIT DESCRIPTION: 4.1 Version(s) of OpenVMS to which this kit may be applied: OpenVMS VAX V7.3 4.2 Files patched or replaced: o [SYSEXE]CONVERT.EXE (new image) o [SYSLIB]CONVSHR.EXE (new image) o [SYSEXE]RECLAIM.EXE (new image) o [SYS$LDR]RMS.EXE (new image) o [SYS$LDR]RMSDEF.STB (new file) -- COVER LETTER -- Page 2 23 September 2002 5 PROBLEMS ADDRESSED IN VAXRMS01_073 KIT o RMS: Fix for potential RMS lock hang when global buffers are enabled. This problem involves a rare condition if the last accessor of the global section is interrupted by an abort rundown, which may lead to the need for the cleanup of the global section not being properly detected. This could result in the survival of the global section and a global bucket system lock after the last accessor is deleted. Since this problem requires the accessor that is aborted to also be the last accessor, it is more apt to occur with a file that accessors come and go -- with a file that is opened and closed frequently and may have only one accessor at a particular time (e.g. RIGHTSLIST.DAT) -- versus a file with global buffers enabled that typically has several concurrent accessors at all times until there is an application (or system) shutdown. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Fix to prevent possible process hangs and system crashes when files with global buffers are accessed. An application accessing a file with global buffers enabled might experience any one of several symptoms ranging from an IVLOCKID being returned to RMS through a possible SSRVEXCEPTN due to corruption of an RMS internal control structure. Prior to this change, it is possible for an internal table maintained by RMS (the Global Buffer Interlock Table) within its global buffer sections to overflow. This can potentially result in corruption to adjoining control structures. No user data are compromised; however, the process may hang or the system crash depending on what is overwritten. This problem is most prevalent on systems where there is a high turnover of processes. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Fix for inconsistent secondary key index structure. Any application that does a lot of deleting or does updates that change a no duplicate secondary key value to another value in an indexed file is a potential candidate for this problem. -- COVER LETTER -- Page 3 23 September 2002 An ANALYZE/RMS_FILE of the indexed file reports the following error for a secondary key: "Index bucket references missing data bucket with VBN nnn" The problem may be that the secondary index structure has duplicate index value entries and there should never be duplicates in the index structure. If the secondary index allows a binary search (is uncompressed), records could be hidden using an exact secondary key lookup. This problem results from the entire space being inappropriately reclaimed for the physically last SIDR record in some secondary data bucket which contains only deleted entries. This problem is restricted to an indexed file with a secondary key that allows no duplicates. The primary key contents will be intact and correct, and a convert of the file will rebuild the secondary indexes and leave the file in a consistent state. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Fix for some records being potentially skipped over in a reverse key search. If the very last bucket in the data bucket chain for a particular key-of-reference is empty (no valid records), the potential exists for any valid records in the next-to-the-last bucket (and only this bucket) being skipped over in the backwards scan done by a reverse key search. This problem is restricted to a reverse key search. Images Affected: - [SYS$LDR]RMS.EXE o RMS RU journaling fix for an update window when a SIDR (secondary index data record) marked as RU-DELETE may be inappropriately re-marked as deleted while the SIDR is still part of an active recovery unit. If this transaction were aborted, this could result in the new secondary key value being retained in the primary data record. Images Affected: - [SYS$LDR]RMS.EXE -- COVER LETTER -- Page 4 23 September 2002 o RMS: Avoid an exec-mode infinite loop if RMS ever attempts to add a duplicate key value to a compressed index bucket. An index bucket should never have a duplicate key value. There is the potential, however, some inconsistency (corruption) in a lower level could result in such an attempt in the case of a compressed key. A correction has been added to issue a nonfatal RMS bugcheck (ISAM) and avoid the loop. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Fix to prevent a non-fatal SSRVEXCEPT bugcheck when a wildcard network copy completes. Attempts to perform wild card file copy operations across the network may fail with a non-fatal SSRVEXCEPT bugcheck upon completion when a third party event notification software package is installed. Stale information contained within a recycled DAP message buffer could cause an invalid path to be executed during the implicit $DISPLAY of a file during RMS rundown. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Correction for processes exiting with RMS IORNDN non-fatal bugcheck. Processes may disappear with RMS IORNDN non-fatal bugchecks when an EXIT is requested by an Executive-mode application (such as ACMS). This is a very small timing window, so processes with a large number of files increases the probability of the problem occurring. If the SYSGEN parameter BUGCHECKFATAL is not enabled, then the process will be terminated; if it is enabled, then the system will crash with a RMSBUG (R2=FFFFFFF0, IORNDN) bugcheck. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Warning added that the limit of 16383 for the number of either file opens or stream connects by one process has been exceeded. The Internal File (IFI) and Stream Identifier (ISI) values for file opens or stream connects are limited to 14 bits (or a maximum value of 16383). Exceeding the limit can result in unpredictable error conditions depending on what operations are -- COVER LETTER -- Page 5 23 September 2002 attempted after the open or connect. Prior to this change, RMS failed to issue a warning when this limit was exceeded. RMS has been modified to return a RMS$_DME error status so an application won't continue when this limit is exceeded for an $OPEN or $CONNECT. This serves as a warning to an application that it must be redesigned to limit either the number of files opened or streams connected to less than 16383. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Set the return length of the auxiliary buffer for calls to SYS$FILESCAN. The return length of the auxiliary buffer ("retlen" optional parameter) that was passed to SYS$FILESCAN was not being set when the Field Flags argument ("fldflags" parameter) was absent. This change sets the return length value unconditionally when one has been requested. Images Affected: - [SYS$LDR]RMS.EXE o RMS: Rollback of a remote file transfer change made in OpenVMS VAX V7.2R and V7.3 to its day 1 behavior in order to restore prior performance metrics for remote file transfers that request file transfer mode by setting the SQO (FAB$L_FOP) option. The change was made to ignore the file transfer mode (FTM) request if the remote file was write shared. This has led to a number of reports of applications that previously had SQO specified for remote files that are experiencing significant performance degradations in their remote applications with VAX V7.2R and V7.3. We have reviewed the previous behavior for file transfer mode and found that while there is the appearance of locking inconsistencies for readers when FTM is used, there is no potential for data corruption. We have concluded that when users set the FTM (SQO) option, they are in effect giving permission for the same kind of inconsistencies that a user allows when the read-regardless (RRL) option is set. This change restores the VAX pre-V7.2 behavior for the file transfer mode for remote files. If SQO is set, file transfer mode will be used regardless of the sharing specified for the remote file. Users should expect to see the same kind of inconsistencies in reading data as they see when the read-regardless (RRL) option is set. The SQO option should be disabled if this is not acceptable for some application. In addition, to avoid the possibility of a hang that may be induced by retrying remote accesses after a record lock error, -- COVER LETTER -- Page 6 23 September 2002 users should consider setting both the no-lock (NLK) and read-regardless (RRL) options in the RAB$L_ROP in applications that use the file transfer mode (SQO) option for remote file accesses. An application should continue to work with the restored behavior without a new change even if a change has been made to an existing application to restore the file transfer mode behavior since the SQO fix was made in VAX V7.2R (e.g., adding the UPI sharing option). There is just one potential problem that we need to point out. For new applications designed and implemented in VAX V7.2R or V7.3 that may allow remote accesses to write shared files, they should check whether SQO (FAB$L_FOP) is enabled. Currently the SQO option is being ignored (unless the UPI sharing option is specified), and the file transfer mode is not being used for any remote accesses. With the restore of the VAX pre-V7.2 SQO behavior, it will start being used and so the behavior of the application could change. Anyone with a new application that has SQO set and the possibility of write shared files being remotely accessed by the application should consider whether the SQO option needs to be disabled. Images Affected: - [SYS$LDR]RMS.EXE o CONVERT/RECLAIM: Fix to prevent the CONVERT/RECLAIM utility from producing an inconsistent index structure in an indexed file during a reclamation. An ANALYZE/RMS_FILE reports the following error: "Index bucket references missing data bucket with VBN nnn" A level 1 index record associated with a data (level 0) bucket that was reclaimed was not removed from the index bucket, as it should have been. It is extremely difficult to detect in advance of doing a convert/reclaim whether an indexed file is vulnerable if a reclaim were applied to it. For example, one condition is that one of the initial level 1 index buckets associated with data buckets eligible for reclamation has some condition (for example, only one index record) that will cause a rollback of a removed index record during a reclamation. Without the fix, doing a full convert (without the /RECLAIM qualifier) ensures avoiding this problem. Images Affected: -- COVER LETTER -- Page 7 23 September 2002 - [SYSEXE]RECLAIM.EXE - [SYSEXE]CONVERT.EXE - [SYSLIB]CONVSHR.EXE o CONVERT: Fix to prevent accvio when repeated calls are made to CONVERT utility callable interface. When making repeated calls to the CONVERT utility callable interface from within a user application, an access violation or various sort errors may be returned. The following conditions must exist for this error to occur: - An application must be making repeated calls to the callable CONVERT interface. - The current file being converted must have more than 3 keys. - At least one of the previously converted files must have had all compressions disabled. - The current file being converted must have some compression enabled. Images Affected: - [SYSEXE]CONVERT.EXE - [SYSLIB]CONVSHR.EXE o CONVERT: Fix for remote file DAP protocol regression. The convert utility fails with the following error when the input file is a sequential file on a remote foreign (non-VMS) system and the output file is a sequential file on a VMS system if and only if /SORT is explicitly specified or implied by /FDL: %CONV-F-READERR, Error reading (IBM_filename) -RMS-F-BUG_DAP, Data Access Protocol error detected; DAP code = 0001A008 The problem is not reproducible using a remote VMS system. Images Affected: - [SYSEXE]CONVERT.EXE - [SYSLIB]CONVSHR.EXE -- COVER LETTER -- Page 8 23 September 2002 o CONVERT: Fix for a user-mode accvio when converting a sequential file when the maximum record size (MRS) in its file header is inappropriately set to zero. Images Affected: - [SYSLIB]CONVSHR.EXE - [SYSEXE]CONVERT.EXE 6 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. 7 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 VAXRMS01_073 [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. 7.1 Special Installation Instructions: There are no special installation instructions for the VAXRMS01_073 ECO kit. Copyright (c) Compaq Computer Company, 2002 All Rights Reserved. Unpublished rights reserved under the copyright laws of the United States. COMPAQ, the COMPAQ logo, VAX, Alpha, VMS, and OpenVMS are -- COVER LETTER -- Page 9 23 September 2002 registered in the U.S. Patent and Trademark Office. All other product names mentioned herein may be trademarks of their respective companies. Confidential computer software. Valid license from COMPAQ are required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. COMPAQ shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided as is without warranty of any kind and is subject to change without notice. The warranties for COMPAQ products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty. 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.