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 ALPF11X03_061 for OpenVMS Alpha V6.1 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: ALPF11X03_061 ECO Kits Superseded by This ECO Kit: ALPF11X01_071 (for V6.1 only) ALPF11X03_070 ALPF11X01_070 ALPF11X01_062 AXPF11X02_061 AXPF11X01_061 ECO Kit Approximate Size: 890 Blocks Saveset A - 864 Blocks Kit Applies To: OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2 System/Cluster Reboot Necessary: Yes Installation Rating: 1 - To be installed on all systems running the listed versions of OpenVMS. NOTE: In order to receive the full fixes listed in this kit, the following remedial kits also need to be installed: ALPSYS08_070 ECO KIT SUMMARY: An ECO kit exists for F11BXQP on OpenVMS Alpha V6.1 through V6.1-1H2. This kit addresses the following problems: PROBLEMS ADDRESSED IN ALPF11X03_061 for OpenVMS Alpha V6.1: o An XQPERR bugcheck occurs when trying to create a file. o A bad FID (File ID) bugcheck occurs 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 Processes hang in an RWAST state while trying to deaccess a file during channel deassignment. o The system hangs during cluster wide cache flushes. 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 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 V6.1: 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. PROBLEMS ADDRESSED IN ALPF11X03_070 KIT FOR OpenVMS Alpha V6.1: 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 V6.1: o The OpenVMS Alpha V6.1 images in the ALPF11X01_062 kit did not contain the complete fixes listed. PROBLEMS ADDRESSED IN ALPF11X01_062 KIT FOR OpenVMS Alpha V6.1: o The system crashes with a BADFID bugcheck. 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 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. o The system crashes with 'BADFID, ACP file number out of range for this volume" The system crashes with 'Failed to allocate FID when expected' This problem is fixed in OpenVMS Alpha V7.0 o On a disk with highwater marking enabled, a file is created with several extents, of which any extent, except the last one, exceeds 2 Gb in size. When a write operation is performed on a block in the last extent of the file, the user may see blocks of a different file erased incorrectly. This problem is fixed in OpenVMS Alpha V7.0 o Lock Ranking Violation when using EDIT/EDT. The problem is caused under the following circumstances: - User B does not have an entry in the quota file. - User A has CONTROL access to user B's files. CONTROL access grants the accessor all the privileges of the objects actual owner. User A can have this access by either: - being a member of the SYSTEM group - having the necessary entry in an ACL. - User A edits one of user B's files using edit/EDT. This problem is fixed in OpenVMS Alpha V7.0 o On a large, very fragmented disk with little free space and heavy usage, an XQP lock ranking violation can occur on a regular basis This problem is fixed in OpenVMS Alpha V7.0 PROBLEMS ADDRESSED IN ALPF11X01_062 KIT FOR OpenVMS ALPHA V6.1: o When issuing a set security/volume command from the command line, it is possible to make the XQP crash. This problem is fixed in OpenVMS Alpha V6.2 o The user sees an XQPERR bugcheck, with a message in the code 'FCBs must be in ascending order', although with XQP+ there can be an unexpected lock manager error on a DEQ (where the DIRLCKID and PRIMFCB fields of an FCB overlap and we try to DEQ an FCB address. The broken FCB chain in question is invariably for a multi-header directory (produced by PATHWORKS V5 putting lots of ACLs on the directory). This problem is corrected in OpenVMS Alpha V6.2 PROBLEMS ADDRESSED IN AXPF11X02_061 KIT for OpenVMS Alpha V6.1: o After deletion of a large file, the free disk space value reported by SHOW DEVICE can indicate that disks have more or less free space than they actually have. o Fix an XQPERR bugcheck which can occur during an IO$_CREATE function (usually RENAME). Fix an XQPERR bugcheck which occurs when attempting to create a file on a volume set when a previous version of the file exists. This problem is fixed in OpenVMS Alpha V6.2 o Massive POSIX forking will result in a K-stack invalid crash. This problem is fixed in OpenVMS Alpha V6.2 o Restore ability to use wildcard values for valid UIC owner and group value ranges. This problem is fixed in OpenVMS Alpha V6.2 o Process hangs in LEF or RWAST (if you try to delete it) when the VMS File System (XQP+) has not finished initialization before it is being called to deassign/deaccess a global section file. This problem is fixed in OpenVMS Alpha V6.2 PROBLEMS ADDRESSED IN AXPF11X01_061 KIT for OpenVMS Alpha: o As of VAX V6.0 and Alpha V6.1 the XQP MOVEFILE primitive allows movement of directory files, so long as no node in the cluster has data from these files cached. The cluster-wide check for this condition did not work properly. This results in cache incoherency, and as a result, directory file corruption. Common symptoms are: o out of order directory listings o duplicate directory entries for the same file o "lost" files o inconsistent directory listings on different nodes o files appearing in directory listings which are not"accessible" from the RMS level (e.g. you can't type them) This problem is fixed in OpenVMS Alpha V6.2 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:

alpf11x03_061.README
alpf11x03_061.CHKSUM
alpf11x03_061.CVRLET_TXT
alpf11x03_061.a-dcx_axpexe

privacy and legal statement