OpenVMS VMS72_F11X-V0200 Alpha V7.2 F11BXQP ECO Summary

TITLE: OpenVMS VMS72_F11X-V0200 Alpha V7.2 F11BXQP ECO Summary Modification Date: 07-OCT-1999 Modification Type: Updated Kit: Supersedes VMS72_F11X-V0100 NOTE: An OpenVMS saveset or PCSI installation file is stored on the Internet in a self-expanding compressed file. The name of the compressed file will be kit_name-dcx_vaxexe for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha. Once the file is copied to your system, it can be expanded by typing RUN compressed_file. The resultant file will be the OpenVMS saveset or PCSI installation file which can be used to install the ECO. Copyright (c) Compaq Computer Corporation 1999. All rights reserved. OP/SYS: OpenVMS Alpha COMPONENT: F11BXQP SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: VMS72_F11X-V0200 DEC-AXPVMS-VMS72_F11X-V0200--4.PCSI ECO Kits Superseded by This ECO Kit: VMS72_F11X-V0100 DEC-AXPVMS-VMS72_F11X-V0100--4.PCSI ECO Kit Approximate Size: 896 Blocks Kit Applies To: OpenVMS Alpha V7.2 System/Cluster Reboot Necessary: Yes Rolling Re-boot Supported: Yes Installation Rating: INSTALL_1 1 - To be installed on all systems running the listed version(s) of OpenVMS. Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this kit: VMS72_HARDWARE-V0100 Or VMS72_UPDATE-V0100 In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None ECO KIT SUMMARY: An ECO kit exists for the F11BXQP on OpenVMS Alpha V7.2. This kit addresses the following problems: Problems Addressed in VMS72_F11X-V0200: o Since the VMS72_F11X-V0100 kit only checks to see if the VMS72_UPDATE-V0100 kit has been installed, the installation fails if only the VMS72_HARDWARE-V0100 kit is installed. Since the VMS72_HARDWARE-V0100 kit includes the VMS72_UPDATE-V0100 kit, the installation should also check to see if the VMS72_HARDWARE-V0100 kit is installed and continue the installation if it has been. This kit corrects this problem by checking for both the VMS72_UPDATE-V0100 and VMS72_HARDWARE-V0100 kits. There are no functional changes in this kit. If you have installed the VMS72_F11X-V0100 kit, you do not need to install this kit. Problems Addressed in VMS72_F11X-V0100: o An XQPERR bugcheck in LOCKERS can occur when the retry limit on the F11B$x lock is reached. This problem can occur when the owner of the $x lock is running at a high process process priority and a number of processes that are in a clustered system are also trying to validate this lock, but at a lower process priority. Image(s) Affected - [SYS$LDR]F11BXQP.EXE o After releasing the current process's IPL/Fork lock, a system can crash with an SPLACQERR bugcheck Image(s) Affected - [SYS$LDR]F11BXQP.EXE o A directory file becomes "corrupt" and DUMP/DIRECTORY displays a block similar to the following: Virtual block number 3574 (00000DF6), 512 (0200) bytes 0000 Directory Entry: 0000 Size: 508 0002 Version limit: 32767 0004 Type: 0 (FID) 0005 Name count: 24 0006 Name: COSLR1201_01_JUPICC2.LIS 001E Version: 7859 FID: (40993,5,0) 0026 Version: 7858 FID: (40990,1,0) 002E Version: 7857 FID: (40988,3,0) ... 01E6 Version: 7802 FID: (40455,1,0) 01EE Version: 7801 FID: (40454,1,0) 01F6 Version: 32767 FID: (16744447,65535,0) 01FE End of records (-1) The directory shuffle code creates the above erroneous directory entry for the following reasons: 1. So that a new directory buffer will have a valid structure (this allows VALIDATE_DIRBLK to write the block to disk); and 2. The entry will be spotted as incorrect (via VERIFY) if the system crashes in the middle of this shuffle. After the directory block (with the erroneous directory entry) is written to disk, the bad entry is removed. A subsequent call to READ_BLOCK assumes that the block comes from the buffer cache and not from disk. Under heavy load, this assumption may not be true as the directory block may have been kicked out of the cache. Image(s) Affected - [SYS$LDR]F11BXQP.EXE o XQP DELETE code accepts an FCB (File Control Block) off the limbo queue if not IO$V_DELETE. This prevents the invalidation of VIOC cache blocks as the result of a RENAME operation. This causes a large amount of XQP (FCB) and VIOC (CFCB) non-paged pool usage as well as XQPERR bugchecks. Image(s) Affected - [SYS$LDR]F11BXQP.EXE o Under the following circumstances, 1. A directory with multiple headers (e.g., from a large ACL) is deleted on one node (A) in a cluster; and 2. the directory had been previously accessed on another node (B) in the cluster, The files created with the previously deleted headers in step 1 would show up on node B with the error: %SYSTEM-F-NOSUCHFILE, no such file. Image(s) Affected - [SYS$LDR]F11BXQP.EXE INSTALLATION NOTES: The images in this kit will not take effect until the system is rebooted. If there are other nodes in the VMScluster, 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. All trademarks are the property of their respective owners.

This patch can be found at any of these sites:

Files on this server are as follows:

dec-axpvms-vms72_f11x-v0200--4.README
dec-axpvms-vms72_f11x-v0200--4.CHKSUM
dec-axpvms-vms72_f11x-v0200--4.pcsi-dcx_axpexe
vms72_f11x-v0200.CVRLET_TXT