Kit Name: ALPRMS03_071 Kits superseded by this kit: ALPRMS02_071 Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this, or any required kit: None In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None Kit Description: Version(s) of OpenVMS to which this kit may be applied: OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2 Files patched or replaced: o [SYS$LDR]RMS.EXE (new image) o [SYSEXE]FAL.EXE (new image) o [SYSLIB]SDARMS$SHARE.EXE (new image) o [SYSEXE]EXCHANGE$NETWORK.EXE (new image) Problems addressed in ALPRMS03_071 kit 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. Page 2 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, GBLPAGFILE or GBLSECTIONS may need to be increased. In addition, process working set size and page file quota may need to be increased. 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. 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. >>the problem description goes to customers. The last sentence is the type of info (that we introduced a problem) that we put in the problem analysis which is for internal use only. Do you want to move it? 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. Page 3 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. 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. 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. 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 Page 4 triggered before RMS receives the AST notification that the request has been canceled. 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. 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. 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. 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. 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. Page 5 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. 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. Page 6 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 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. Page 7 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. 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 Page 8 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. 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: 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 ALPRMS03_071 [location of the saveset] The saveset location may be a tape drive, or a disk directory that contains the kit saveset. The images in this kit will not take effect until the system is rebooted. If you have other nodes in your VMS 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. Page 9 Copyright (c) Compaq Computer Corporation, 1998 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.