SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
.
} what's new
.
} contract access
.
} browse patch tree
.
} search patches
.
} join mailing list
.
} feedback
.
patches by topic
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
OpenVMS ALPF11X04_070 for OpenVMS Alpha V7.0 F11BXQP ECO Summary

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) Digital Equipment Corporation 1997. All rights reserved. OP/SYS: OpenVMS Alpha COMPONENT: File System - F11BXQP.EXE (XQP) SOURCE: Digital Equipment Corporation ECO INFORMATION: ECO Kit Name: ALPF11X04_070 ECO Kits Superseded by This ECO Kit: ALPF11X01_071 (for V7.0 only) ALPF11X03_070 ALPF11X01_070 ECO Kit Approximate Size: 881 Blocks Saveset A - 864 Blocks Kit Applies To: OpenVMS Alpha V7.0 System/Cluster Reboot Necessary: Yes Installation Rating: 1 - To be installed on all systems running the listed version(s) of OpenVMS.} NOTE: In order to receive the full fixes listed in this kit, the following remedial kits also need to be installed: None ECO KIT SUMMARY: An ECO kit exists for F11BXQP on OpenVMS Alpha V7.0. This kit addresses the following problems: PROBLEMS ADDRESSED IN ALPF11X04_070 for OpenVMS Alpha V7.0: o An XQPERR bugcheck occurs when trying to create a file. o Bad FID bugcheck when trying to mark a file header free in the index file bitmap. o There are multiply allocated blocks and file headers on the disk. o The contents of a header or bitmap block could be corrupted within the block buffer cache. o Failure to take an allocation lock could be ignored. o If a DEACCESS request failed with a SS$_DEADLOCK error, a process could be left in RWAST state indefinitely. o If a large file is created on a fragmented disk that has quotas enabled and the user needs to use EXQUOTA privilege to allocate the necessary disk space, an internal XQP table can become corrupted. This leads to the following bugcheck: SECAUDERR, Fatal error attempting to perform a security audit o Superseding a file with a version limit set can remove the oldest version of a file, even if that version is undeletable by the user according to its protection mask or ACL. The file is removed but not deleted, and can be recovered by ANALYZE/DISK/REPAIR. o Attempting to queue a maximal length (39.39;5) filename to the XQP for spooling to a symbiont would cause either an infinite CPU loop or a FILCNTNONZ, Open file count nonzero after process rundown bugcheck. PROBLEMS ADDRESSED IN ALPF11X01_071 KIT FOR OpenVMS Alpha V7.0: o The problem occurs when a file is deleted while still being accessed by someone. This produces an XQPERR bugcheck when an attempt is made to access the deleted file. o The problem may result in an XQPERR bugcheck which claims that: "all the index buffers are active" during the processing of a directory file. The problem occurs when no free directory index BFRD's are found on the first pass through MAKE_DIRINDX. The thread then stalls to allow some of the BFRD's to be freed, but doesn't release the cache lock which would allow others to do this. This means that if no free BFRD was found on the first try then none will be found on subsequent tries either, and the bugcheck will occur. o The fault occurs as a UNXSIGNAL Bugcheck after running AUTOGEN, and rebooting with very large SYSGEN ACP cache parameters. The problem occurs when the calculation of DIRINDX in RELEASE_LOCKBASIS overflows. This is due to a multiplication taking place before a division, which overflows when more than 87381 blocks have been allocated between the ACP_MAPCACHE, ACP_DIRCACHE and ACP_HDRCACHE caches. PROBLEMS ADDRESSED IN ALPF11X03_070 KIT for OpenVMS Alpha V7.0: o BACKUP and SLS can cause WCBFCBMNG bugchecks when operating on some files. These files are legal, uncorrupted files so they should not repeatedly cause a crash whenever BACKUP or SLS tries to back them up. o A system could crash with a SECAUD bugcheck whenever ANAL/DISK/etc is run on a corrupted disk with auditing turned on. o The XQP bugchecks when a file is accessed for the first time, with cathedral windows, and the accessing process runs out of BYTLM quota. o Window mapping code could incorrectly concatenate extents which ran from one volume to another in a volume set. o XQPERR bugcheck in [F11X]DIRSCNuPDATE_INDEX() when trying to insert index entry into directory index block with DIR$W_TOTALCELLS equal to zero. o Directory FCBs can become stale but invisible to the XQP. The File IDs can then be reused, and if the FCB in question was an extension FCB, the next time the new file is accessed on that node, the XQP bugchecks with the fatal XQPERR 'wrong lockbasis with FCB present'. o If a file is opened for exclusive access on one node in a cluster and a BACKUP/IGNORE=INTERLOCK command is issued to backup the file on that node, after the BACKUP completes the file can be successfully accessed from the other node(s) of the cluster. The BACKUP destroys the exclusive access. PROBLEMS ADDRESSED IN ALPF11X01_070 KIT for OpenVMS Alpha V7.0: o When enabling quotas on the system disk, the system occasionally crashes with an ACCVIO. o File name appears twice in a directory block. o System crashes with a BADDALRQSZ bugcheck o Multiple allocated blocks being reported after the defragger has been run. o UNXSIGNAL crash due to a corrupt Window Control Block o File Access Control Lists are corrupted after a failure to allocated an extension File Control Block due to disk quota being exceeded. INSTALLATION NOTES: In order for the corrections in this kit to take effect, the system must be rebooted. If the system is a member of a VMScluster, the entire cluster should be rebooted.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

alpf11x04_070.README
alpf11x04_070.CHKSUM
alpf11x04_070.CVRLET_TXT
alpf11x04_070.a-dcx_axpexe

privacy and legal statement