OpenVMS ALPY2K02_062 OpenVMS Alpha V6.2 Year 2000 ECO Summary
TITLE: OpenVMS ALPY2K02_062 OpenVMS Alpha V6.2 Year 2000 ECO Summary
Modification Date: 29-JUN-98
Modification Type: Updated Kit: Supersedes ALPY2K01_062
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, 1998. All rights reserved.
OP/SYS: DIGITAL OpenVMS Alpha and OpenVMS/Japanese Alpha
COMPONENTS: CLUE$SDA
DUMP
EXCHANGE
F11BXQP
LBRSHR
LIBRTL
MESSAGE_ROUTINES
MTAAACP
TECOSHR_TV
VERIFY
VMS$REMEDIAL_ID
STARLET.OLB
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: ALPY2K02_062
ECO Kits Superseded by This ECO Kit: ALPY2K01_062
ALPVERI02_062
ALPF11X02_062
ALPLIBR06_062
ALPMTAA01_070 (V6.2 fixes *ONLY*)
ECO Kit Approximate Size: 5850 Blocks
Kit Applies To: OpenVMS Alpha and OpenVMS/Japanese Alpha V6.2,
V6.2-1H1, V6.2-1H2, V6.2-1H3
System/Cluster Reboot Necessary: Yes
Installation Rating: 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:
ALPCLUSIO01_062
In order to receive all the corrections listed in this
kit, the following remedial kits should also be installed:
None
ECO KIT SUMMARY:
This kit provides Year 2000 enhancements for OpenVMS Alpha and OpenVMS
Japanese/Alpha V6.2 through 6.2-1H3.
This document contains information regarding both the VAX and Alpha
Year 2000 enhancements that ship in kits VAXY2K02_062 and ALPY2K02_062,
respectively.
NOTE
Kits VAXY2K02_062 and ALPY2K02_062 supersede kits VAXY2K01_062 and
ALPY2K01_062. The new kits are identical to the superseded kits except
that kits VAXY2K02_062 and ALPY2K02_062 also correctly replace image
LBRSHR.EXE in SYS$COMMON:[SYSLIB]IMAGELIB.OLB. Kit VAXY2K02_062 also
contains a fix that correctly installs F11BXQP.EXE in [SYSEXE].
Even though DIGITAL believes that few customer sites will need these
enhancements, which affect only a few areas of the operating system,
all customer sites running OpenVMS V6.2x should install the Year 2000 kit.
The few Year 2000 enhancements in this kit result from a rigorous and
comprehensive analysis of the entire OpenVMS operating system, including
extensive OpenVMS testing.
For more information on the OpenVMS Year 2000 Initiative, please visit
the OpenVMS Year 2000 web page:
http://www.openvms.digital.com/openvms/products/year-2000
NOTE
DIGITAL expects that most year 2000-related problems will occur
primarily in locally developed layered product applications.
Therefore, it is important to start evaluating your applications
and environments as soon as possible. Even if DIGITAL's products
are ready for the year 2000, you must ensure that the environments
in which these products operate are also ready. The OpenVMS Year
2000 web page includes a link to testing instructions, including
how to set the system clock ahead to simulate the transition to
the year 2000 or other future dates.
If you need additional help, contact your DIGITAL support representative
to learn what information and tools are available to get you started.
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, but need no
changes.
o Crash Log Utility Extractor (CLUE)
The CLUE history listing file contains a 2-digit year format in
its file name, which has this format:
CLUE$node_ddmmyy_hhmm.LIS
This file format poses no year 2000 problem in itself, but
the code that generates this date has been changed from using
a subtract operation to using a modulo function so that the
correct date will still be calculated in the year 2000. This
change has no visible effect on the file name format.
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 following sections describe conditions you should be aware
of if you interoperate with RSX-11 or if you use RSX-11 software
on your OpenVMS system.
- 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 the code
will not be changed.
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
Problems Addressed in the ALPVERI02_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 the ALPVERI01_071 Kit:
o ANALYZE/DISK goes into an infinite loop.
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 the ALPVERI01_062 Kit:
o Errors similar to these may occur during execution of the
'ANALYZE/DISK' DCL command:
%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
This problem has been corrected in OpenVMS Alpha V7.0.
Problems Addressed in the ALPF11X02_062 Kit:
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 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 the ALPF11X01_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.
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 the ALPF11X03_070 Kit:
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 the ALPF11X02_070 Kit:
o The ALPF11X01_070 remedial kit did not install on systems
running OpenVMS Alpha V6.2-1H1, as it should have.
Problems Addressed in the ALPF11X01_070 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
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 the ALPLIBR06_062 kit:
o DEBUG links LIBRTL.OLB into its DEBUG.EXE image. The
LIB$CALLING_STANDARD routines included can ACCVIO when
trying to walk the call chain or write to a call's
invocation context block on a corrupt stack. These ACCVIOs
have now been observed from DEBUG CALL commands from certain
register frames.
In order to receive this full fix the ALPDEBU01_062 or
its supersedant remedial kit must also be installed.
Problems addressed in the ALPLIBR05_062 kit:
o Because multi-version kits are no longer being issued, the
ALPLIBR05_070 kit, which was for OpenVMS Alpha V6.1 through
V7.0, has been broken down so that there is a kit for each
version. This kit, ALPLIBR05_062, is the V6.2 portion of
ALPLIBR05_070.
Problems addressed in the ALPLIBR05_070 kit:
o The OpenVMS operating system has a documented delta-time
restriction that may cause an error in some applications and
OpenVMS components beginning on or around 19-MAY-1997. This ECO
corrects this potential problem by removing 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.
This problem is fixed in OpenVMS Alpha V7.1.
Problems addressed in the ALPLIBR04_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 the ALPLIBR03_070 kit:
o LIBRTL.EXE was not replaced in IMAGELIB.OLB.
Problems addressed in the ALPLIBR02_070 kit:
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.
o LIB$STAT_TIMER produces incorrect results. Elapsed time jumps
significantly from the initial value to the next returned value.
o Problem noticed using OTS$DIV_PK_LONG or OTS$DIV_PK_SHORT LIBRTL
routine. Packed value 11259 divided by 1, yielded 1125.90083841.
Only a handful of numbers cause bad results.
Problems addressed in the ALPLIBR01_070 kit:
o The multiplication algorithm for delta time was faulty. This
is a regression in V7.0.
Problems addressed in the ALPLIBR03_062 kit:
o When setting host into a DECnet PhaseV system, the logical name
SYS$REM_NODE is incorrectly set. When the code was originally
written, there was no support for node synonyms. The code
does not get the right values from the system call.
Problems addressed in the ALPMTAA01_070 kit for OpenVMS Alpha V6.2,
V6.2-1H1, V6.2-1H2, and V6.2-1H3:
o MTAACP can hang during multivolume copy operations.
NOTE: According to OpenVMS Engineering, the fixes discussed
below have been included in OpenVMS Alpha V7.0. There
are some fixes that have been included in previous
versions of OpenVMS and those versions are specified in
text following the problem descriptions.
Problems addressed in the ALPMTAA01_062 kit:
o The system crashes with NOBVPVCB bugcheck when performing a test
for an empty queue with a DO_CANCEL function in ACPCTR.B32.
o The system crashes with an XQPERR bugcheck while dismounting a MAD
drive.
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, 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:
alpy2k02_062.README
alpy2k02_062.CHKSUM
alpy2k02_062.CVRLET_TXT
alpy2k02_062.a-dcx_axpexe
|
