OpenVMS VAXY2K02_062 OpenVMS VAX V6.2 Year 2000 ECO Summary
TITLE: OpenVMS VAXY2K02_062 OpenVMS VAX V6.2 Year 2000 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.
*OpenVMS] VAXY2K02_062 OpenVMS VAX V6.2 Year 2000 ECO Summary
Copyright (c) Digital Equipment Corporation 1997, 1998. All rights reserved.
WORKAROUND FOR COSMETIC ERROR INTRODUCED BY THIS KIT:
PROBLEM STATEMENT:
This kit fails to replace image LBRSHR.EXE in
SYS$COMMON:[SYSLIB]IMAGELIB.OLB.
PROBLEM SYMPTOM:
If you try to link against a routine in the LBRSHR image, the
following informational message can occur:
%LINK-I-DATMISMCH, creation date of d2-mmm-yyyy hh:mm in
shareable image
SYS$COMMON:[SYSLIB]LBRSHR.EXE;2 differs from date of
d1-mmm-yyyy hh:mm in Shareable image library
SYS$COMMON:[SYSLIB]IMAGELIB.OLB;2
The date d2-mmm-yyyy reflects the LBRSHR image left by the Y2K
ECO kit, while the d1-mmm-yyyy date reflects the date when
LBRSHR was last replaced in the library.
SOLUTION:
Execute the following DCL command to avoid getting the informational
message:
$ LIBRARY/REPLACE SYS$COMMON:[SYSLIB]IMAGELIB.OLB -
_$ SYS$COMMON:[SYSLIB]LBRSHR.EXE
OP/SYS: DIGITAL OpenVMS VAX
COMPONENTS: BACKUP
DUMP
EXCHANGE
F11AACP
F11BXQP
LBRSHR
LIBRTL
LIBRTL2
LIBRTL_INSTRUMENTED
MESSAGE_ROUTINES
MTAAACP
STABACKUP
TECOSHR
VERIFY
VMS$REMEDIAL_ID
STARLET.OLB
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXY2K01_062
ECO Kits Superseded by This ECO Kit: VAXY2K01_062 (Identical Images)
VAXVERI02_062
VAXF11X03_062
VAXLIBR06_070 (V6.2 fixes *ONLY*)
ECO Kit Approximate Size: 3432 Blocks
Kit Applies To: OpenVMS VAX V6.2
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 kit must be installed BEFORE
this kit:
VAXCLUSIO01_062
NOTE TO USERS WHO INSTALLED VAXY2K01_062:
Kit VAXY2K02_062 supersedes kit VAXY2K01_062. The image files
contained in the two kits are identical, but VAXY2K02_062 correctly
installs image F11BXQP.EXE into SYS$COMMON:[SYSEXE]. If you have
already installed the VAXY2K01_062 kit, you can either install the
VAXY2K02_062 kit, or you can perform the following workaround:
1. Execute the following DCL command to relocate image F11BXQP.EXE:
$ COPY SYS$LOADABLE_IMAGES:F11BXQP.EXE SYS$COMMON:[SYSEXE]
2. Reboot the local node and all OpenVMS Cluster nodes that are
currently bootstrapped off the same local system disk.
3. Once all nodes have completed the reboot, issue the following
DCL commands:
$ DELETE SYS$SYSROOT:[SYS$LDR]F11BXQP.EXE;*
$ PURGE SYS$COMMON:[SYSEXE]F11BXQP.EXE
YEAR 2000 KIT INSTALLATION ISSUES:
SUMMARY:
There is a problem with the installation of some TIMA kits (the
kit list is detailed below) after the Year 2000 V6.2 TIMA kit
VAXY2K02_062 is applied.
If the Y2K is installed, and you plan to install any of the kits
listed below, please follow the workaround until OpenVMS Engineering
provides further information.
BACKGROUND:
The interdependencies among various remedial kits led to the
implementation of the VMS$REMEDIAL_ID.EXE image. This image
has been shipped with various baseline TIMA kits, such as
SHAD09_061, CLUSIO01_062, Y2K01_062 and Y2K01_071. For each
kit, running VMS$REMEDIAL_ID.EXE provides a unique id to confirm
that a baseline kit has been installed. Subsequent TIMA kits
check this id to insure that these dependency requirements have
been met.
PROBLEM:
The KITINSTAL check that is in the various kits checks for an
exact id and does not allow an id that is greater. For example,
the VMS$REMEDIAL_ID.EXE supplied in the CLUSIO kit returns a unique
id of 5. The newer VMS$REMEDIAL_ID.EXE supplied in the Y2K kits
returns an id greater than 5. This causes the KITINSTALs for those
kits that require CLUSIO to falsely believe that the CLUSIO kit has
not been installed and the installation fails.
The following error will be displayed:
"In order for the images in this remedial kit to execute
properly, the VAXCLUS01_062 remedial kit for OpenVMS VAX
6.2 must be installed first. For assistance in obtaining
the VAXCLUS01_062 remedial kit, please contact your normal
Digital support channel."
SOLUTION:
OpenVMS Engineering is presently investigating options to
permanently solve this installation problem. Further
information will be provided as soon as possible.
WORKAROUND:
To workaround this problem, you will have to regress the version
of the VMS$REMEDIAL_ID.EXE image to that of the CLUSIO kit, install
the needed TIMA kits, then re-apply the correct VMS$REMEDIAL_ID.EXE.
For example:
$ SET DEFAULT SYS$COMMON:[SYSUPD]
$ RENAME VMS$REMEDIAL_ID.EXE VMS$REMEDIAL_ID.EXE_Y2K
$ RUN VMS$REMEDIAL_ID.EXE
$ SHOW SYMBOL $STATUS
$!
$! $STATUS should be %X00000005, if not, rename the next version
$! of VMS$REMEDIAL_ID.EXE until you get a value of 5.
$!
$! Install other TIMA kits now
$!
$ RENAME VMS$REMEDIAL_ID.EXE_Y2K VMS$REMEDIAL_ID.EXE;
Alternatively, you can restore the VMS$REMEDIAL_ID.EXE that is in the
CLUSIO kit, perform the TIMA installations, and then delete it.
AFFECTED KIT LIST:
VAXF11X03_062 (this kit presently does not check for CLUSIO)
VAXDRIV05_062
VAXMSCP02_062
VAXCLIU06_062
ECO KIT SUMMARY:
This kit provides Year 2000 enhancements for OpenVMS VAX Version 6.2.
The following release notes identify certain conditions you
should be aware of when preparing your OpenVMS environment for
the year 2000. This kit contains minor modifications to several
older components of the operating system; other conditions are
simply noted here, but need no changes.
o EXCHANGE Utility
When the EXCHANGE utility is used to transfer files between
OpenVMS and RT-11 or DOS-11 systems, date problems could occur
starting in the year 2004 for RT-11 and in the year 2036 for DOS-11.
NOTE
RT-11 volumes are also used as console storage media
on certain older VAX systems.
This kit contains an enhancement to EXCHANGE that makes the RT-11
date format continue to function correctly until the year 2099.
NOTE
DIGITAL transferred the RT-11 operating system, along
with other PDP-11 software, to Mentec in 1994.
o File System $QIO Interface
The file system $QIO interface supports several attributes for
RSX-11 compatibility. Of these, ATR$C_EXPDAT and ATR$C_ASCDATES
return the file creation date, revision date, and expiration
date using 2-digit years.
These attributes are not normally used by native code and can be
replaced with the following documented, compliant interfaces:
ATR$C_CREDATE
ATR$C_EXPDATE
ATR$C_REVDATE
The file system $QIO interface is provided by the following file
systems:
DIGITAL TCP/IP Network File System (NFS) client
Distributed File System (DECdfs)
Magnetic tape ACP
OpenVMS ODS-1 file system
OpenVMS ODS-2 file system
o ODS-1 File Header Format and Utility Support
For RSX-11 compatibility, OpenVMS VAX supports ODS-1 file format
disk volumes. The ODS-1 file system uses a 2-digit year format
internally, and current implementations have limitations for the
year 2000.
The magnetic tape ACP also returns an ODS-1 format file header
in response to an application request for the ATR$C_HEADER
attribute. This feature is supported on both VAX and Alpha.
ODS-1 data structures use a 2-digit year (ddmmmyy) in the following
items:
- ODS-1 file header:
FI1$T_CREDATE
FI1$T_CRETIME
FI1$T_EXPDATE
FI1$T_REVDATE
FI1$T_REVTIME
- ODS-1 home block: HM1$T_CREDATE
The OpenVMS VAX file system and the following OpenVMS utilities
that support the ODS-1 file system format have been modified to
correctly interpret these 2-digit years until the year 2057:
Analyze/Disk_Structure Utility
Backup Utility
Dump Utility
Librarian (LBR) routines
NOTE
Even though we are updating the ODS-1 code for the year
2000, DIGITAL strongly recommends that users of ODS-1
formatted media move to a newer file format by the year 2000.
o LIB$ Run-Time Library
In the run-time library, the LIB$CONVERT_DATE_STRING routine
allows the user to select a 2-digit year format (as well as
many others). This routine interprets 2-digit years as belonging
to the century in which the system is currently running
(according to the system clock). For example, in the 1900s, 61
is interpreted as 1961, and starting January 1, 2000, 61 will be
interpreted as 2061. If this behavior could produce unexpected
results on your system, select one of the alternatives to the
2-digit year format.
NOTE
This behavior has been documented in the OpenVMS RTL
Library (LIB$) Manual since Version 6.0, so we will not
change the code.
o TECO Editor
This kit includes two minor changes to the TECO editor.
- The date value in the TECO editor has been extended to a
longword so that the year value returned by the Ctrl/B
function will not overflow on 01-JAN-2028.
- This kit also fixes a TECO problem that is unrelated to
dates. The UIC value returned by the 2EJ function was
incorrect if the process UIC had a group or member number
greater than 377.
For compatibility reasons, the 2EJ value cannot be changed.
However, the problem has been fixed by the following changes:
o All group and member numbers that exceed a byte are now
mapped to 377 (octal).
o A 3EJ function has been implemented to return the longword
UIC.
The following TECO example demonstrates the change.
NOTE: The ESCAPE () sequence can be entered on
most keyboards by typing Ctrl/[.
$ SET UIC [1234,567]
$ TECO
*3EJ/65536==
1234
*3EJ&65535==
567
RELEASE NOTES FROM SUPERSEDED KITS:
PROBLEMS ADDRESSED IN VAXVERI02_062 KIT:
o VERIFY does not flag files, which are directly back linked to
themselves, as having invalid backlinks.
o VERIFY hangs in an infinite loop during its scan of the
directory structure.
PROBLEMS ADDRESSED IN VAXVERI01_071 KIT:
o Verify has incorrectly 'fixed' the backlink of a lost directory
to point to itself. The next time verify is run, it encounters
the lost directory and goes into a tight loop following the
directory's backlink.
PROBLEMS ADDRESSED IN VAXVERI01_062 KIT:
o Analyze/disk gives multiple errors of the form, or similar to:
%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 3, RVN 1
%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 4, RVN 1
%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 5, RVN 1
NOTE: In order to receive this full fix, in addition to this kit,
the VAXCLIU04_062 kit or any kits that supersede it, must
also be installed.
PROBLEMS ADDRESSED IN VAXF11X03_062 KIT:
o An XQPERR bugcheck occurs when trying to create a file.
o A bad FID 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 an 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 the following bugcheck:
FILCNTNONZ, Open file count nonzero after process rundown
PROBLEMS ADDRESSED IN VAXF11X01_071 KIT:
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.
o System Hang. Processes are stalled waiting to perform I/O
operations, despite buffer credits being available for use.
PROBLEMS ADDRESSED IN VAXF11X03_070 KIT:
o A system could crash with a SECAUD bugcheck whenever
ANALYZE/DISK 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.
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.
PROBLEMS ADDRESSED IN VAXF11X02_062 KIT:
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
has been run.
o UNXSIGNAL crash due to a corrupt Window Control Block.
o File Access Control Lists are corrupted after a failure to
allocate an extension File Control Block due to disk quota
being exceeded.
PROBLEMS ADDRESSED IN VAXF11X01_062 KIT:
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.
o Lock Ranking Violation (with EDIT/EDT usage). 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, or
- having the necessary entry in an ACL.
+ User A edits one of user B's files using EDIT/EDT.
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.
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).
o When issuing a set security/volume command from the command
line, it is possible to make the XQP crash.
o Due to INDEXF.SYS resizing the system may cash with the
following errors:
o BADFID, ACP file number out of range for this volume
o Failed to allocate FID when expected
PROBLEMS ADDRESSED IN VAXLIBR06_070:
Kit VAXY2K01_062 supersedes kit VAXLIBR06_070. However,
VAXLIBR06_070 includes fixes for OpenVMS Version 5.5-2*
only, so OpenVMS users did not need to apply VAXLIBR06_070 to
Version 6.2 operating systems. See the following sections for
information about OpenVMS Version 6.2 problems that were
addressed in kits that were superseded by VAXLIBR06_070.
PROBLEMS ADDRESSED IN VAXLIBR05_070 KIT:
o The OpenVMS operating system has a documented delta-time
restriction that may cause a serious error in some applications
and OpenVMS components beginning on or around 19-MAY-1997.
DIGITAL has corrected this potential problem and has provided
ECOs (Engineering Change Orders) that remove the delta-time
limit.
Applications and OpenVMS components most likely to experience
errors are those that pass delta-time arguments with values
exceeding 9999 days on system-supplied date routines. The most
likely date that these errors will occur is 19-MAY-1997:00:00,
which is 10,000 days after the common UNIX time origin of
1-JAN-1970.
Fixed in: V7.1
PROBLEMS ADDRESSED IN VAXLIBR02_070 KIT:
o Heaps that are removed from the heap pending list are only
merged with the most recently returned heap. This can lead to
heap fragmentation.
PROBLEMS ADDRESSED IN VAXLIBR01_070 KIT:
o LIB$FID_TO_NAME has been modified to ensure that the use of
very deep directory trees do not result in the call stack being
corrupted.
o The 10,000 day limit in LIB$CVT_TO_INTERNAL_TIME causes
problems for DECthreads since it is using this routine to
convert UNIX times to VAX time. It will fail to work on
19-May-1997.
PROBLEMS ADDRESSED IN VAXLIBR02_062 KIT:
o When the code was originally written there was no support for
node synonyms. Now that the support is there, people are using
it. The code does not get the right value from the network call.
PROBLEMS ADDRESSED IN VAXLIBR01_062 KIT:
o LIB$CVT_DX_DX returns a status of 00158334 (LIB$_INTOVF) when
converting '-2147483648' to quadword.
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 an OpenVMS Cluster system,
the entire cluster should be rebooted.
During the kit installation you will be prompted with options to print
and/or display the release notes.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxy2k02_062.README
vaxy2k02_062.CHKSUM
vaxy2k02_062.CVRLET_TXT
vaxy2k02_062.a-dcx_vaxexe
|
