OpenVMS VAXY2K01_U2055 VAX V5.5-2 Year 2000 ECO Summary
TITLE: OpenVMS VAXY2K01_U2055 VAX V5.5-2 Year 2000 ECO Summary
Modification Date: 12-JUL-1999
Modification Type: DOCUMENTATION: Technical Modification
This kit cannot be installed on OpenVMS
VAX V5.5-2HW. Please see note below.
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, 1999. All rights reserved.
NOTES: VAXF11X06_U2055 should be installed after installing this
ECO. If the F11X kit is not installed, the system may
experience random crashes or hangs during backups.
This ECO *CANNOT* be installed on OpenVMS VAX V5.5-2HW.
Please upgrade your system to OpenVMS VAX V5.5-2 before
attempting to install this kit.
OP/SYS: OpenVMS VAX
COMPONENTS: BACKUP
DCLTABLES
DUMP
EXCHANGE
F11AACP
F11BXQP
FILMNTMSG
LBRSHR
LIBRTL
LIBRTL2
LIBRTL_INSTRUMENTED
MESSAGE_ROUTINES
MTAAACP
STABACKUP
TECOSHR
VERIFY
VMS$REMEDIAL_ID
STARLET.OLB
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXY2K01_U2055
ECO Kits Superseded by This ECO Kit: VAXBACK05_U2055
VAXF11X05_U2055
VAXVERI01_U2055
VAXLIBR06_070 (V5.5-2 fixes only)
ECO Kit Approximate Size: 2698 Blocks
Kit Applies To: OpenVMS VAX V5.5-2, V5.5-2H4, V5.5-2HF
System/Cluster Reboot Necessary: Yes
Rolling Reboot Supported: Yes
Installation Rating: 1 - To be installed on all systems running
the listed version(s) of OpenVMS.
Kit Dependencies:
NOTE: To prevent XQPERR bugchecks, VAXF11X06_U2055 must be installed
after VAXY2K01_U2055.
The following remedial kit must be installed BEFORE
installation of this kit:
VAXSHAD09_U2055
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 VAX Version
5.5-2. All Year 2000 enhancements shipped in this kit will be
included in the operating system starting with the release that
follows OpenVMS VAX Version 7.1 and OpenVMS Alpha Version
7.1-1H1.
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 typically 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.
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 before 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.
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:
ADDED FEATURES IN VAXBACK05_U2055 KIT:
o The following items are new features in the BACKUP utility:
o The /(NO)ALIAS qualifier has been added to allow users more
control over how alias (synonym) file entries are processed
by the OpenVMS Backup utility (BACKUP). The default is
/ALIAS.
The /ALIAS qualifier maintains the previous BACKUP behavior
of treating alias file entries the same as primary file
entries. Therefore, a primary file may be processed
multiple times by BACKUP if one or more alias file entries
reference the same primary file entry.
If you specify /NOALIAS, alias directory and file entries
are ignored. Therefore, multiple processing of primary
files may be avoided, which saves time and saveset file
space. If a restore operation is performed using the
/ALIAS qualifier but the saveset was created by using the
/NOALIAS qualifier, a message is displayed that the /ALIAS
qualifier will be ignored
o New messages associated with this fix are:
AECREATED: created alias file entry
'dev:[directory]entry.ALIAS'
Indicates that the specified alias file entry was created
during a backup restore operation. Requires no user
action.
ALIASQUAL: SAVESET WAS CREATED /NOALIAS, RESTORE /ALIAS
qualifier will be ignored.
Indicates that the backup restore operation could not be
performed as specified because the saveset was created
ignoring alias entries. Therefore, there are no separate
files in the saveset to restore in place of the alias
directory entries. The restore operation was performed by
processing the alias file entries as directory entries
instead of as separate file entries.
The user should examine the saveset used in the backup
restore operation to determine if it is the correct save
set. If not, restore the correct image and incremental
save sets in the recommended order. If the save set is the
correct one, no additional action is required.
ARESTERR: error restoring alias file entry
'dev:[directory]entry.alias', the primary file
entry was 'dev:[prim_dir]primary.file'
Indicates that an error occurred when the Backup utility
tried to restore an alias file entry. The alias file entry
was not restored. Note that in most cases the alias file
is eliminated from the directory.
User should examine the primary file, the directory, and
the alias entry directory to determine the cause of the
error. Then, based on the data in this error message and
any secondary error status, correct the problem and create
the alias file entry using the DCL command SET FILE/ENTER.
As a general practice, Digital recommends that you execute
the DCL command ANALYZE/DISK after Backup restore
operations of all save sets have been completed and any
subsequent error corrections have been made, for example,
using SET FILE/ENTER commands.
o The following are known problems and restrictions with the
Backup utility:
o Image and Incremental Backups
The first time you back up a disk, you must perform an
image backup using the BACKUP/IMAGE/RECORD command before
you perform regular incremental backups. The image backup
saves a copy of the entire disk and marks each file as
being saved. Subsequent incremental backups assume an
image backup has been performed and therefore save only new
or modified files.
If an image backup was not performed first, the incremental
backups save more files than might be necessary to ensure
that an incremental restore will be successful.
o Incremental Backups Using PATHWORKS for OpenVMS Macintosh
Servers
An incompatibility between the operating procedures of the
PATHWORKS for OpenVMS Macintosh server and OpenVMS
incremental backup operations can cause BACKUP to save
entire disks or directory structures, including
subdirectories and files.
A recent change to fix other problems now causes Backup to
detect whether a directory file has been modified since the
date indicated by the Backup date field in the file header.
If a directory file has been modified, all subdirectories
and files of that directory are saved for possible later
restore operations. Updating the modification date of
directory files is unusual for OpenVMS systems, but it can
happen, for example, if you rename a directory file from
one version to another.
By contrast, the PATHWORKS Macintosh server maintains the
modification date of directory files for Macintosh users;
that is, it updates the modification data for each
directory change, file creation and file deletion.
Thus, an incremental backup of a disk where PATHWORKS is
used to serve files to Macintosh users may result in saving
the entire disk or entire directories (including their
subdirectories and files) instead of just the user files
that were created or modified since the last incremental
backup operation.
This incompatibility will be addressed in a future version
of OpenVMS.
For now, you can avoid the needless saving of files by
performing a dummy BACKUP/RECORD operation on all directory
files immediately before performing the incremental backup.
The following example illustrates this workaround:
$BACKUP/RECORD/IGNORE= (INTERLOCK) -
_$ disk:[000000...]*.DIR;* -
_$ NLA0:DUMMY.BCK/SAVE/NOCRC/GROUP_SIZE=0
$
$ BACKUP/VERIFY/FAST/RECORD/IGNORE= (INTERLOCK) -
_$ /NOASSIST/COMMENT="Incremental backup of DISK:" -
_$ disk:[000000...]*.*;*/SINCE=BACKUP -
_$ tape:incr.bck/LABEL=incr/SAVE
In this example , the first BACKUP command performs the
dummy backup operation and the second performs the actual
incremental backup. The first command updates the Backup
Date field for all the directory files. Specifying the
null output device [000000...] causes no saveset file to
actually be written. Since no file information need be
retained from this operation, the /NOCRC and /GROUP_SIZE=0
qualifiers are specified to avoid CRC and XOR block
calculation.
o Warning Issued on ANALYZE/DISK Operation
An ANALYZE/DISK operation performed immediately after a
BACKUP/IMAGE restore of a disk might result in a warning
message similar to the following:
%ANALDISK-W-ALLOCLR, blocks incorrectly marked allocated
LBN 97 to 105, RVN 1
This can be caused by attempting to perform a BACKUP/IMAGE
restore operation where alias file entries are restored as
separate (primary) file entries. (The primary file which
uses the same file header but allocates different data
storage blocks, is also restored.)
Note that there is no BACKUP error or loss of data.
This problem will be addressed in a future version of
OpenVMS.
PROBLEMS ADDRESSED IN VAXBACK05_U2055 KIT:
o BACKUP may not incrementally restore a disk to the same
directory and file structure as existed at the time of the last
(most recent) incremental save operation. (Some directories
and their files may not be deleted properly, resulting in
additional [unwanted] files.) This may cause restore errors due
to insufficient space on the output disk device because the
additional/unwanted files are not deleted.
This problem is corrected in OpenVMS VAX V6.2
o When performing a BACKUP/LIST ddcu:*.*/SAVE_SET operation on a
tape that contains many save sets, the BACKUP utility may
eventually abort with the errors:
%BACKUP-F-ALLOCMEM, error allocating virtual memory
SYSTEM-F-EXQUOTA, exceeded quota
or
%BACKUP-F-INSBUFSPACE, Insufficient virtual memory to
accommodate minimum buffer count
or
%BACKUP-F-BUFFERSLOST, all buffers are lost
This problem is corrected in OpenVMS VAX V6.2
o If a customer produces a listing file while doing an image
backup and then compares this to a listing file created from
the saveset, these listings may not be the same. One listing
may show several files to be at the end of a tape, while the
other listing may show those same files to be at the beginning
of the next tape. In reality, the files exist only at the
beginning of the tape.
This problem is corrected in OpenVMS VAX V6.2
o If a user enters a version for a disk saveset and the file
already exists (i.e. FOOBAR.BCK;1), BACKUP will overwrite the
file, thus destroying the information in the file and possibly
causing loss of data.
This problem is corrected in OpenVMS VAX V6.2
o If a user specifies /record on a RESTORE and an error occurs at
a certain point in the code, an ACCVIO may result.
This problem is corrected in OpenVMS VAX V6.2
o On a BACKUP file restore operation a file gets an ACL with
default ACE created when there was none before. (The
[DIRECTORY] had a default ACE though.) An ACE with the DEFAULT
option on a directory file causes this ACE to be added to the
restored file's ACL.
Note: This problem does not occur on BACKUP/image save/restore
operations.
This problem is corrected in OpenVMS VAX V6.2
o A fix to the following problem was backported to V5.5-2.
Behavior of OpenVMS V6.1 and OpenVMS V6.0 is different with an
input saveset that has errors. Essentially V6.1 prompts the
user for action where V6.0 did not. A problem introduced by
the change in behavior is that besides prompting for (QUIT OR
CONTINUE) on every count of 100, it would also prompt on the
first error detected before any XOR recovery could be attempted
on the failing block. This fix corrects that.
Example follows:
OpenVMS V6.0 behavior:
V6.0> backup/li/noass tape11:bell.sav
{/list output removed for readability}
[TDMS.RTOKIT.SAVEB]THDLIB.OLB;1 44 3-MAY-1990 18:36
[TDMS.RTOKIT.SAVEB]TSSLIB.OLB;1 621 3-MAY-1990 18:36
[TDMS.RTOKIT.SAVEB]TSSLINK.COM;1 2 1-FEB-1986 21:48
[TDMS.RTOKIT.SAVEB]TSSLNK.COM;1 1 3-MAY-1990 18:40
[TDMS.RTOKIT.SAVEB]TSSSHROPT.OPT;1 4 30-JUL-1986 13:17
%BACKUP-I-XORERRS, 1 error recovered by redundancy group in
$4$MUA11:[000000]BELL.SAV;
OpenVMS V6.1 behavior:
V6.1> backup/li/noass tape11:bell.sav
{/list output removed for readability}
[TDMS.RTOKIT.SAVEB]TSSLIB.OLB;1 621 3-MAY-1990 18:36
%BACKUP-E-READERRS, excessive error rate reading
$4$MUA11:[000000]BELL.SAV;
-BACKUP-E-BLOCKCRC, software block CRC error
%BACKUP-I-SPECIFY, specify option (QUIT or CONTINUE)
BACKUP> cont
[TDMS.RTOKIT.SAVEB]TSSLINK.COM;1 2 1-FEB-1986 21:48
[TDMS.RTOKIT.SAVEB]TSSLNK.COM;1 1 3-MAY-1990 18:40
[TDMS.RTOKIT.SAVEB]TSSSHROPT.OPT;1 4 30-JUL-1986 13:17
%BACKUP-I-XORERRS, 1 error recovered by redundancy group in
$4$MUA11:[000000]BELL.SAV;
Total of 22 files, 1907 blocks
End of save set
This problem is corrected in OpenVMS VAX V6.2
o BACKUP will erroneously abort with a GENMINUS1 error on a
non-shadowed disk.
o In some cases, a user may erroneously specify the /INCREMENTAL
and/or the /SINCE qualifier on the same BACKUP command line
which will result in unpredictable results.
This problem is corrected in OpenVMS VAX V6.2
o A power fail test on two tape storage devices, TA90E and TA78,
ended up with two different results. The TA78 recovered the
power fail test but the TA90E failed with:
%BACKUP-E-FATALERR, fatal error on $88$MUA3:[]TEST.BCK;
BACKUP/IMAGE/REW/VER/IGN=INTER SYS$SYSDEVICE:
$88$MUA3:TEST.BCK/SAVE
Power fail the tape storage unit during I/O.
This problem is corrected in OpenVMS VAX V6.2
o BACKUP does not continue on the tape that is mounted while
using the /exact_order qualifier. For example, with the
following command file:
$ write sys$output " backup av ingtab1 "
$ backup/journal/fast -
/exclude=(pppp*.t*,*.m*,*.d*,*.sm*) -
ingtab1:[ingres.data.tds01]*.* -
tape:ingtab1.bck -
/norew -
/block=65024 -
/label=(N0,V0,W0,N1,V1,W1) -
/exact_order
$!
$ write sys$output " backup av ingtab2 "
$ backup/journal/fast -
/exclude=(pppp*.t*,*.m*,*.d*,*.sm*) -
ingtab2:[ingres.data.tds01]*.* -
tape:ingtab2.bck -
/norew -
/block=65024 -
/label=(W0,N1,V1,W1) -
/exact_order
$!
$ exit
when the first BACKUP command completes on tape_volume label
'w0' and that volume is only about half full, the second
command requests a tape with label 'w0'. BACKUP complains and
will not allow that label 'w0' to be used. However, if the
tape is dismounted and BACKUP remounts the same tape_volume to
do the append operation or the /EXACT_ORDER qualifier is
removed from the command line, the tape_volume is mounted
correctly.
This problem is corrected in OpenVMS V6.2
o RESTORE operation completes successfully, but with INVRECTYP
message that may cause user to doubt data integrity.
This problem is corrected in OpenVMS VAX V6.2
o If a tape volume switch is required during a BACKUP operation,
and the Media Manager (MME) is running, and a volume switch is
required, then the BACKUP operation will fail with
"BACKUP-F-NOTANSI - tape is not valid ANSI format".
This problem is corrected in OpenVMS VAX V6.2
o Layered products or users may create disk directory structures
that are not supported by OpenVMS utilities due to the depth of
the directory structures exceeding 8 levels. These files could
not be processed by OpenVMS BACKUP selectively. (Only
BACKUP/IMAGE save and restore operations would work.)
This problem is corrected in OpenVMS VAX V6.2
o Descriptions for problems that were corrected in kits
prior to VAXBACK05_U2055 are included in the file
VAXBACKUP_U2055.PROBLEM_HISTORY. This file is located in the
saveset VAXBACK05_U2055.A. To access this file, restore it
from the saveset by issuing a command with the following format:
$ BACKUP/SEL=VAXBACKUP_U2055.PROBLEM_HISTORY DEVICE:[DIR]VAXBACK-
_$ 05_U2055.A/SAVE DEVICE:[DIR]VAXBACKUP_U2055.PROBLEM_HISTORY
PROBLEMS ADDRESSED IN VAXF11X05_U2055 KIT:
o This kit is being re-issued as a maintenance release only for
OpenVMS V5.5-2. This kit does not contain any new fixes or
images.
PROBLEMS ADDRESSED IN VAXF11X03_070 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
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 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
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 When disk quota is exceeded, an extension File Control Block is
not allocated, causing corruption of File Access Control Lists.
PROBLEMS ADDRESSED IN VAXF11X01_062 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
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:
o User B does not have an entry in the quota file.
o 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.
o 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 The system crashes with 'BADFID, ACP file number out of
range for this volume"
o The system crashes with 'Failed to allocate FID when
expected'
PROBLEMS ADDRESSED IN VAXF11X01_U2055 KIT FOR OPENVMS VAX V5.5-2:
o Previously, reading beyond the high water mark of a file
produced inconsistent results. The user's buffer was not
actually modified yet the I/O status returned indicated
success. This problem manifested itself principally when doing
BACKUP/VERIFY of files whose high water mark was less than the
physical file size. The result was BACKUP issuing error
alarming error messages.
o This problem sometimes causes systems to crash in the file
system at offset REMOVE+4F. It also might cause us to delete
the wrong directory entry and it is also suspected of possibly
causing other types of directory corruption.
Prior to this fix, when the file system received a hardware
write error trying to write a directory data block to disk, the
system sometimes crashed.
o In order to prevent deadlocks, the file system has assigned
certain ranking rules to the various locks that it deals with.
In particular, it is incorrect for the file system to attempt
to acquire the SERIAL lock of a particular file while the file
system holds the ALLOCATION lock for the volume on which the
particular file exists.
o A previous attempt to solve the problem of extending the
INDEXF.SYS file has introduced new problems which resulted in
sometimes leaving the INDEXF.SYS file very fragmented.
Therefore a new simplified algorithm for INDEXF.SYS extending
has been introduced.
o During a cluster transition, lock value blocks may normally
become invalid. It is responsibility of lock manager users,
such as the file system to take appropriate action in the face
of invalid value blocks.
o This problem leads to a loss of synchronization that leads to a
system crash which occurs when one processes accesses what
turns out to be an extension header, by FID, at the same time
that that header is being deleted. In the past this same
problem caused a system deadlock resulting in a hung system.
The fix that resolved the deadlock now sometimes results in a
crash.
The file system synchronizes access to files and FCBs by taking
out the serial lock on the primary header of a file. The
problem is that we support access by File ID in some cases, and
if a file ID happens to be an extension file ID, then
determination of the proper lock to use is an interactive
process.
o A problem was reported when performing a certain set of steps
for two different processes running two different images
simultaneously (Image A & Image B):
- Image A creates FILE.DAT
- Image A writes 100 blocks to FILE.DAT
- Image B opens FILE.DAT
- Image B calls $CRMPSC and maps FILE.DAT
- Image A extends FILE.DAT to 200 blocks (FILE.DAT now has
multiple fileheaders)
- Image B calls $CRMPSC and remaps FILE.DAT
- Image B tries to reference address returned from $CRMPSC
will result in Image B terminating with a SS$_PAGRDERR.
o On a very fragmented disk, creation of a file on a volume could
cause the INDEXF.SYS to become corrupt. The last map pointer
count (from a DUMP/HEADER INDEXF.SYS) in the INDEXF.SYS header
would contain a value of 256. ANALYZE/DISK would report this
as an "invalid map area" error.
o If a nonprivileged user performed a $ SET FILE/NODIRECTORY on a
directory file the user owns, no error was returned, but the
file retained the directory attribute.
o Note that in an allocation failure on a single volume no
corruption is possible from this bug.
Previously, if we tried to extend a file on a bound volume set
and we failed to find enough space to satisfy the request we
would leave a corrupt WCB in memory that could lead to possible
data corruption.
o Previously it was possible to attempt to perform a directory
operation on an already corrupt directory without noticing it.
Then when we went to write the directory and found corruption
we would crash the system.
o In the past it was legal to issue a QIO request to extend a
directory and make it non-contiguous. This had negative
side-effects because the file system assumes that directories
are contiguous.
o In the past it was legal to issue a QIO request to lookup a
file in a directory, specified by DID = 1, which would result
in a crash. The problem is that file ID 1 is that of
INDEXF.SYS, which is not a directory, and that due to an error
we did not properly cleanup after discovering the discrepancy.
o There is a problem that can occur on:
- Bound volume sets in non-clustered configurations.
- Bound volume sets on devices that are not available
cluster-wide.
A synchronization error in the XQP may lead to open files
caching stale mapping information for bound volume sets.
If the file is open for write, you may lose file updates or
corrupt disk file contents. Any resulting corruption affects
complete disk blocks.
PROBLEMS ADDRESSED IN VAXF11X01_070 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
o This fix merges the PWXQP+ threaded OpenVMS VAX V5.5-2 XQP with
the OpenVMS VAX remedial V5.5-2 code. From this point on, all
V5.5-2 XQP kits will provide the threaded version of the XQP.
This XQP has exactly the same functionality as the current
V5.5-2 XQP except when multi-threading is explicitly enabled.
PROBLEMS ADDRESSED IN VAXF11X03_061 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
o An ACCVIO in routine EXE$SEARCH_RIGHT results in an UNXSIGNAL
crash.
o After deletion of a large file, the free disk space value
reported by SHOW DEVICE can indicate that disks have more or
less free space than they actually have.
PROBLEMS ADDRESSED IN VAXF11X04_U2055 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
o There are several places in the XQP where the code will $ENQ
for a lock on a resource, specifying LCK$M_NOQUEUE, since it
does not expect to have to queue for the lock. On very odd
occasions, it will receive back a status of SS$_NOTQUEUED,
indicating that it did not get the lock since it would have had
to have queued for the lock. This causes a fatal bugcheck and
the system crashes.
PROBLEMS ADDRESSED IN VAXF11X03_U2055 KIT FOR OPENVMS VAX V5.5-2:
o An application tries to access (IO$_ACCESS | IO$M_ACCESS) an
extension header directly when the file (primary header/FCB) is
not open. The call should fail with SS$_NOSUCHFILE, and does
most of the time. However, if the header is the first
extension header in a chain and contains just mapping pointers,
we return a bogus SS$_ACCONFLICT. If the header contains an
ACL we take a crash in [F11X]INIFC2.B32/FILL_FCB (offset
varies).
Inspection of the code while attempting to locate the cause of
this problem exposed another problem. We can pick up cached
FCBs from VIOC as the primary FCB when accessing extension
headers directly - thus getting a bogus "access" on the
primary, allowing unsynchronized access to extension headers.
PROBLEMS ADDRESSED IN VAXF11X02_U2055 KIT FOR OPENVMS VAX V5.5-2:
o This problem is due to a basic inadequacy in the lock manager
design that manifests itself in two different file system
visible problems. The first is that, from time to time, access
to a cluster shared file is incorrectly denied to an accessor.
That is, an application running on a node of a cluster will
attempt to open (access) a given shared file in what looks to
be a compatible way and will receive an SS$_ACCONFLICT status.
Secondly, again sporadically, an application will create a new
file and the system will crash in CREATE with and XQP bugcheck
whose text reads, 'how can we fail to access a new file'.
o When a file is open with an NL mode access lock, then an attempt
to access an extension header may fail because the FCB chain is
being rebuilt.
This fix allows an extension file header to be accessed even if
the initial search for the FCB failed.
o During backups BACKUP accesses file extension headers directly
instead of going in under the synchronization of the primary
header. This can lead to the FCBs for the headers which backup
is looking at being deallocated under its feet by other
processes.
The net result is any number of different XQP bugchecks, most
notably UNXSIGNAL (ACCVIO), NOTFCBFCB, and XQPERRs.
This seems to be relatively easy to provoke if you back up the
same disk in two different processes at the same time.
A modification was made earlier to the XQP to fix this lack of
synchronization; however, this fix had a timing window in it.
PROBLEMS ADDRESSED IN VAXVERI01_062 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
o Anal/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 VAXCLIU02_070 kit or any kits that supersede it, must
also be installed.
o After the installation of VAXVERI02_061, doing an ANAL/RMS will
cause an ACCVIO.
This problem is fixed in OpenVMS VAX V6.2
PROBLEMS ADDRESSED IN VAXVERI02_061 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
o When running ANAL/DISK/REPAIR, a directory that is reported as
having bad backlinks may be completely erased if it contains an
alias pointing to itself.
o When running ANAL/DISK, an error may be returned from LIB (for
example, "-LIB-F-BADBLOSIZ, bad block size") and a user-mode
crash may occur.
o ANAL/DISK does not notice out of order file names or versions
within a directory block.
PROBLEMS ADDRESSED IN VAXVERI01_061 FOR V5.5-2, V5.5-2H4, V5.5-2HF:
o When ANAL/DISK/REPAIR is run on a volume containing corrupt
directory files the system crashes with an UNXSIGNAL bugcheck.
Verify has been changed so all errors detected by the XQP are
also detected by anal/disk and fixed if anal/disk/repair is
used. Bad RVNs (relative volume numbers) in directory files
are now removed properly and anal/disk/repair will not bugcheck
when fixing a broken directory.
PROBLEMS ADDRESSED IN VAXLIBR06_070 KIT FOR OPENVMS V5.5-2*
o The VAXLIBR05_070 remedial kit contained a fix that caused a
Kernel Stack Not Valid Bugcheck which resulted in a system
reboot. This appears to happen under two circumstances:
o The system has at least one secondary pagefile installed
and Autogen is run with preserve feedback i.e.
AGEN$FEEDBACK.EXE is run.
o The Polycenter DECps product is installed and run on the
system, specifically the Data Collection portion DECps-DC.
If either of the above are run after the VAXLIBR05_070 kit has
been installed on V5.5-2*, the system may crash.
This is only a problem for customers running V5.5-2*. If you
are running a version other than V5.5-2* and have installed the
VAXLIBR05_070 remedial kit you do not need to install the
VAXLIBR06_070 kit.
o Possible memory leak when calling lib$get_vm.
o The message length field in the message sent to the queue
manager can get corrupted when the buffer size exceeds 64K and
the user process can obtain 64K of P1 space.
o Sometimes, during a heavy system load, a process may lose the
response to a queuing request and the command will hang
indefinitely.
o In order to correct a problem where the batch/print queue
manager can lose a connection to one of its client nodes (after
a failover), the $SNDJBC system service has added the new
status return code QMAN$_RETRYLINK. This informs the queue
manager to attempt to re-establish its link to this client
node.
The new status is returned when the client node detects that
the queue manager is attempting to link, but context for a
previous link still exists.
However, in order to correct the lost connection problem, you
must be running a version of the queue manager which recognizes
the new QMAN$_RETYRLINK status code.
Queue manager versions beginning with OpenVMS VAX V6.0 contain
the update which recognizes the new status code. The update is
also available in the remedial kit VAXQMAN03_070. If you are
experiencing the lost connection problem (a very low
probability event), and have installed the VAXLIBR06_070 kit,
you may see OPCOM messages similar to the following (on the
operator console or in the operator log file):
%%%%%%%%%%% OPCOM 6-AUG-1992 15:06:00.26 %%%%%%%%%%%
Message from user QUEUE_MANAGE on SUMNODE
%QMAN-E-COMMERROR, unexpected error #5 in communicating
with node CSID 0008000B
%%%%%%%%%%% OPCOM 6-AUG-1992 15:06:00.28 %%%%%%%%%%%
Message from user QUEUE_MANAGE on SUMNODE
-QMAN-W-NOMSG, Message number 04FE8678
o Allow lowercase months to be entered to the $BINTIM system
service.
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.
These problems are fixed in OpenVMS Version 7.1.
Y2K
Year 2000
INSTALLATION NOTES:
The images in this kit will not take effect until the system is
rebooted.
If you have other nodes in your VMS cluster, they must also be
rebooted in order to make use of the new images. If it is not
possible or convenient to reboot the entire cluster at this time, a
rolling re-boot may be performed.
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:
vaxy2k01_u2055.README
vaxy2k01_u2055.CHKSUM
vaxy2k01_u2055.CVRLET_TXT
vaxy2k01_u2055.a-dcx_vaxexe
vaxy2k01_u2055.CVRLET_TXT
|
