OpenVMS VAXF11X01_072 VAX V7.2 F11BXQP ECO Summary
TITLE: OpenVMS VAXF11X01_072 VAX V7.2 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) Compaq Computer Corporation 1998, 2000. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENTS: F11BXQP
F11AACCP
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXF11X01_072
ECO Kits Superseded by This ECO Kit: None
ECO Kit Approximate Size: 414 Blocks
Kit Applies To: OpenVMS VAX 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:
VAXUPDATE01_072
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 F11AACP and F11BXQP on OpenVMS VAX V7.2. This kit
addresses the following problems:
o A READATTR/FID_TO_SPEC mechanism, such as a data collector
process running on the same volume as a defragger competing
for the same data, both processes try to delete the
'primary_fcb' used to get the information in question. In
both of these circumstances, the reference count on the FCB
has not been bumped up so both accesses appear to allow the
deletion. This results in a NOTFCBFCB Bugcheck.
Images Affected: [SYS$LDR]F11BXQP.EXE
o If a process attempts to mount a bound volume set (BVS)
and all the members of the BVS are not present, an attempt
to lock the volume for REBUILDing the meta-data on the volume
will fail. However, the blocking lock (F11B$b) is left
with the process.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o An XQPERR bugcheck in LOCKERS can occur when the retry
limit on the F11B$x lock is reached. This happens when
the owner of the $x lock is running at a high process priority
and there are a number of processes in a clustered system that
are also trying to validate this lock but at a lower process
priority. The high priority process never really gives up the
locks long enough to let the low process priority processes
to continue and either validate or release the $v lock.
To avoid this situation, after (every) 256 attempts, the
process with the most retry iterations is stalled for a short
period to allow other processes to complete their accesses to
the lock.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o After releasing the current process' IPL/Fork lock, a system
can crash with a SPLACQERR bugcheck
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o When writing a large number of log files in rapid succession
to a very large directory, the 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)
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o Exhaustion of non-paged pool with FCBs and CFCBs as the
primary data structures. The output from a SHOW
MEMORY/CACHE/FULL command may put odd values in the files
retained field:
$ SHOW MEMORY /CACHE/FULL
System Memory Resources on 18-NOV-1999 14:13:52.13
Virtual I/O Cache
Total Size (pages) 2098 Read IO Count 13359
Free Pages 0 Read Hit Count 6130
Pages in Use 2098 Read Hit Rate 45%
Maximum Size (SPTEs) 3140177 Write IO Count 16874
Files Retained ****** IO Bypassing the Cache 536
Non-paged pool exhaustion starts when a file create or access
causes the file to become part of the VCC cache and be held on
the XQP limbo queue. A short time later, if this file is
renamed and as part of that rename operation the file is
removed from the limbo queue, the accounting for that file
is not correct. If the file is later deleted, the count
of the limbo items goes down incorrectly and eventually goes
negative. This then allows the limbo list to grow very large.
This can be seen using SDA where the value of EXE$GL_LIMBOLEN
does not match the number of queue elements in EXE$GQ_LIMBOQ.
For example:
SDA> EX EXE$GL_LIMBOLEN
EXE$GL_LIMBOLEN: 00000061 "a..."
SDA> VALIDATE QUEUE EXE$GQ_LIMBOQ
Queue is complete, total of 195 elements in the queue
SDA> EVAL 61
Hex = 00000061 Decimal = 97
SDA>
Images Affected: [SYS$LDR]F11BXQP.EXE
o Under the following circumstances:
1. A directory with multiple headers (from a large ACL for
example) 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
o Fix the internal GETTIM function so that it properly formats
the 64 bit internal time to an RSX-11 compatible ASCII string.
RSX date string contain only a 2 character year field (ASCII).
In order to accommodate the year 2000, this ASCII encoding
will now include the value of decades (since 1900) into the
string. This means that for the years 1900 through 1999, the
date string will appear as 00 to 99. For the years 2000 into
the years 39xx, the string will show as ':0', ';0' etc.
For years prior to the year 1900, dates are encoded as binary
zeros, which is interpreted as 'no date'
Image(s) Affected:
- [SYS$LDR]F11BXQP.EXE
- [SYSEXE]F11AACP.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:
Colorado Site
Georgia Site
European Site
Files on this server are as follows:
vaxf11x01_072.README
vaxf11x01_072.CHKSUM
vaxf11x01_072.CVRLET_TXT
vaxf11x01_072.a-dcx_vaxexe
vaxf11x01_072.CVRLET_TXT
