OpenVMS VAXF11X02_072 VAX V7.2 F11AACP/F11BXQP ECO Summary
TITLE: OpenVMS VAXF11X02_072 VAX V7.2 F11AACP/F11BXQP ECO Summary
Modification Date: 16-APR-2001
Modification Type: Documentation:Update the kit Dependencies
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
For OpenVMS savesets, the name of the compressed saveset
file will be kit_name.a-dcx_vaxexe for OpenVMS VAX or
kit_name.a-dcx_axpexe for OpenVMS Alpha. Once the OpenVMS
saveset is copied to your system, expand the compressed
saveset by typing RUN kitname.dcx_vaxexe or kitname.dcx_alpexe.
For PCSI files, once the PCSI file is copied to your system,
rename the PCSI file to kitname-dcx_axpexe.pcsi, then it can
be expanded by typing RUN kitname-dcx_axpexe.pcsi. The resultant
file will be the 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: VAXF11X02_072
ECO Kits Superseded by This ECO Kit: VAXF11X01_072
ECO Kit Approximate Size: 432 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
VAXODS1_01_072
NOTE: The VAXODS1_01_072 kit dependency applies only
if the user has OPS-1 drives.
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:
Problems Addressed in VAXF11X21_072:
o A BADATTRIB error can occur from BACKUP and other applications
that use ATR$C_ASCNAME.
Images Affected:
- [SYSEXE]F11AACP.EXE
- [SYSEXE]F11AACP.STB
o An XQPERR bugcheck can occur when the volume allocation lock
becomes invalid and the process is extending/re-validating the
INDEXF.SYS file.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o An exception, which leads to an INVEXCEPTN bugcheck, can occur
in XQP routine INS_LIMBO or TRIM_LIMBO.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o The XQP bugchecks in routine MARK_INCOMPLETE with NOTWCBWCB, a
corrupted WCB list. Other bugchecks could occur, depending
upon when the WCB queue corruption is detected.
Images Affected: [SYSEXE]F11BXQP.EXE
o MOUNT routine START_ACP bugchecks with NOTUCBRVT.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o If a directory command is executed for a directory file that
is greater than 127 blocks, the UCB$x_QLEN counter gets
incremented, but may not get decremented.
If an I/O past the highwater mark is started exactly at
%x7FFFFF blocks from the file size, a false SS$_ENDOFFILE
would be reported.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o A process hangs and may not be deleteable when writing to a
sequential file. The process may have a "lost" I/O
outstanding. In such cases, the I/O may be on the FCB (file
control block) HWM (high water mark) wait queue waiting for
other I/Os.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o Separator pages for print jobs, which are created via COPY to
a spooled device, do not include the complete file specification.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o The XQP bugchecks with an XQPERR in routine RES_SEQ_MISMATCH,
'Found a stale referenced or non directory FCB (file control
block) in FCB queue'.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o The XQP bugchecks with an XQPERR in routine MAKE_DEACCESS,
'deaccess conversion failed'.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
o An XQPERR bugcheck occurs in UPDATE_INDX of multi-header
directories.
Images Affected:
- [SYS$LDR]F11BXQP.EXE
- [SYS$LDR]F11BXQP.STB
o A paged pool may become overused or exhausted when many
shuffles occur on a directory with multiple headers. This is
due to an occurrence of a large ACL (access control list)
chain.
Images Affected:
- [SYSEXE]F11BXQP.EXE
- [SYSEXE]F11BXQP.STB
Problems Addressed in VAXF11X01_072:
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
Files on this server are as follows:
vaxf11x02_072.README
vaxf11x02_072.CHKSUM
vaxf11x02_072.CVRLET_TXT
vaxf11x02_072.a-dcx_vaxexe
vaxf11x02_072.CVRLET_TXT
|
