Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXODS1_01_072 VAX V7.2 ODS1 ECO Summary
Copyright (c) Compaq Computer Corporation 2000. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENT: ODS1
BACKUP
F11BXQP
F11CACP
F11AACP
DUMP
INIT
MTAAACP
VERIFY
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXODS1_01_072
ECO Kits Superseded by This ECO Kit: None
The VAXODS1_01_072 does not supersede any other kits.
However, it does include the problem corrections shipped
in the VAXF11X01_072 and VAXBACK01_072 remedial kits.
If you install the VAXODS1_01_072 kit, you do not need to
install the VAXF11X01_072 or VAXBACK01_072 remedial kits.
ECO Kit Approximate Size: 2034 Blocks
Kit Applies To: OpenVMS VAX V7.2
System/Cluster Reboot Necessary: Yes
Rolling Re-boot Supported: Yes
Installation Rating: INSTALL_2
2 - To be installed on all systems running
the listed version(s) of OpenVMS and
using the following feature(s):
Users of ODS-1 Format Files
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 Y2K issues on ODS-1 on OpenVMS VAX V7.2. This kit
addresses the following problems:
Problems Addressed in this kit:
o The 64 bit internal time is not formatted to an RSX-11 compatible
ASCII string. An RSX date string contains 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) in the
string. This means that for the years 1900 through 1999, the date
string will appear as 00 to 99. For the years 2000 through the
years 39xx, the string will show as ':0', ';0' and so forth.
Images Affected:
- [SYSEXE]F11AACP.EXE
- [SYSLIB]INIT$SHR.EXE
- [SYSEXE]VERIFY.EXE
- [SYS$LDR]F11BXQP.EXE
- [SYSEXE]MTAAACP.EXE
- [SYSEXE]F11CACP.EXE
- [SYSEXE]F11DACP.EXE
- [SYSEXE]DUMP.EXE
o An INIT/STRUCTURE=1 command returns the following error:
%INIT-F-ILLBLKNUM, illegal logical block number
Images Affected: [SYSLIB]INIT$SHR.EXE
o Attempting to mount the second volume of a two-volume RMU
backup results in %MOUNT-F-MEDOFL and %MOUNT-F-FILACCERR
errors.
Images Affected: [SYSEXE]MTAAACP.EXE
Problems Addressed in the VAXF11X01_072 Kit:
o 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, but the blocking lock (F11B$b) is left with the process.
Images Affected: [SYS$LDR]F11BXQP.EXE
o An XQPERR Bugcheck occurs in LOCKERS when the retry limit on
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.
Images Affected: [SYS$LDR]F11BXQP.EXE
o A system would crash with an SPLACQERR bugcheck after releasing
the IPL/Fork lock.
Images 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 corrupted.
A 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)
Images 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 latter 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
Problems Addressed in VAXBACK01_072:
o An %BACKUP-F-BADOPTVAL error can occur when using an
Identifier String for a BACKUP/BY_OWNER qualifier value.
For example:
$ BACKUP SOURCE:*.*/BY_OWNER=USER TAPE:A.BCK/SAV
%BACKUP-F-BADOPTVAL, invalid callable interface option value,
argument position 7, option type = 59, option value = 2147549409
Image(s) Affected:
- [SYSEXE]BACKUP.EXE
- [SYSLIB]BACKUPSHR.EXE
o Attempting to use BACKUP/ENCRYPT in BATCH results in the error
%BACKUP-F-ENCNOTSUP.
Images(s) Affected:
- [SYSEXE]BACKUP.EXE
- [SYSLIB]BACKUPSHR.EXE
o The BACKUP/DRIVE_CLASS qualifier was not processed properly.
Images(s) Affected:
- [SYSEXE]BACKUP.EXE
- [SYSLIB]BACKUPSHR.EXE
o BACKUP/JOURNAL fails with an ACCVIO under the following two
conditions:
- backing up a moderate number of files to tape
- backing up a file, where the combined length of the
directory specification and filename exceed 512 characters
Image(s) Affected:
- [SYSEXE]BACKUP.EXE
- [SYSLIB]BACKUPSHR.EXE
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS database. To view these articles, open the appropriate
product database and perform a query using either of the following
search strings: 'VAXODS1_01_072' or 'VAXODS1_01'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
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.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| BACKUP.EXE |%XE762540F| VAX72R005 | 18-NOV-1999 |
| | | 08:06:18.92 |
+----------------------------+----------+-----------------+--------------+
| BACKUPSHR.EXE |%X203199FF| VAX72R005 | 18-NOV-1999 |
| | | 08:06:18.92 |
+----------------------------+----------+-----------------+--------------+
| DUMP.EXE |%XBBB7B041| X-22 | 13-OCT-1999 |
| | | 10:22:31.79 |
+----------------------------+----------+-----------------+--------------+
| F11AACP.EXE |%X5266A53E| X-2 | 13-OCT-1999 |
| | | 10:22:31.39 |
+----------------------------+----------+-----------------+--------------+
| F11BXQP.EXE |%X3695482D| XQP V7.2R-0002 | 13-OCT-1999 |
| | | 10:24:28.20 |
+----------------------------+----------+-----------------+--------------+
| F11CACP.EXE |%X312EFE6B| X-8 | 2-NOV-1999 |
| | | 22:39:03.50 |
+----------------------------+----------+-----------------+--------------+
| F11DACP.EXE |%X903EEB66| X-8 | 2-NOV-1999 |
| | | 22:39:29.17 |
+----------------------------+----------+-----------------+--------------+
| INIT$SHR.EXE |%X4807EBC4| X-2 | 23-NOV-1999 |
| | | 08:33:32.47 |
+----------------------------+----------+-----------------+--------------+
| MTAAACP.EXE |%XFD3745E5| X-7 | 18-NOV-1999 |
| | | 08:06:18.73 |
+----------------------------+----------+-----------------+--------------+
| STABACKUP.EXE |%XAD1DD243| VAX V7.2R001 | 18-NOV-1999 |
| | | 08:06:23.86 |
+----------------------------+----------+-----------------+--------------+
| VERIFY.EXE |%X1160CD57| X-16 | 23-NOV-1999 |
| | | 08:37:33.44 |
+----------------------------+----------+-----------------+--------------+
All trademarks are the property of their respective owners.
|
