|
|
 |
OpenVMS VAXODS1_01_U2055 VAX V5.5-2__V5.5-2H4 ODS-1 ECO Summary
|
TITLE: OpenVMS VAXODS1_01_U2055 VAX V5.5-2__V5.5-2H4 ODS-1 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.
Copyright (c) Compaq Computer Corporation 1999. All rights reserved.
Modification Date: 15-DEC-1999
Modification Type: Corrected Kit Name
OP/SYS: OpenVMS VAX
COMPONENT: ODS1
BACKUP
DUMP
F11AACP
F11BXQP
INIT$SHR
MTAAACP
STABACKUP
VERIFY
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXODS1_01_U2055
ECO Kits Superseded by This ECO Kit: None
VAXODS1_01_U2055 does not supersede any other kits.
However, it does include problem corrections shipped
in the VAXF11X06_U2055, VAXINIT03_061 and VAXBACK05_U2055
remedial kits. If you install the VAXODS1_01_U2055 kit,
you do not need to install any of these other remedial kits.
ECO Kit Approximate Size: 1584 Blocks
Kit Applies To: OpenVMS VAX V5.5-2, V5.5-2H4
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:
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:
An ECO kit exists for Y2K and other issues on ODS-1 on OpenVMS VAX
V5.5-2 and V5.5-2H4. 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
- [SYSEXE]BACKUP.EXE
- [SYSLIB]BACKUPSHE.EXE
- [SYSEXE]STABACKUP.EXE
Problems addressed in the VAXINIT03_061 Kit:
o When initializing a tape without MME running, if the
expiration date of the first file on the tape has not been
reached, and no user over-ride flag is set, INIT will ignore
this and initialize the tape anyway.
o The item_list parameter to the $init_vol system service is
documented as being optional, and if not specified a zero must
be passed. If a zero is passed, $init_vol returns with an
ACCVIO status.
Problems addressed in the VAXINIT01_U2055 Kit:
o The command "INITIALIZE/OVERRIDE=ACCESSIBILITY tape: label"
fails with the error :
%INIT-F-NORMAL, normal successful completion
if the user has the VOLPRO privilege enabled.
New Features included in VAXBACK05_U2055:
o The following items are new features by the BACKUP utility:
+ 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
+ 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:
+ 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.
+ Incremental Backups Using PATHWORKS for OpenVMS 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.
+ 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 the 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 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.
This problem is corrected in OpenVMS VAX V6.2
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 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
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.
Copyright (c) Compaq Computer Corporation 1999. All rights reserved.
Modification Date: 14-DEC-1999
Modification Type: New Kit
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_071
ECO Kits Superseded by This ECO Kit: None
The VAXODS1_01_071 does not supersede any other kits.
However, it does include problem corrections shipped
in the VAXF11X05_071, VAXVER01_071 and VAXMTAA01_071
remedial kits. If you install the VAXODS1_01_071 kit,
you do not need to install the VAXF11X05_071, VAXVER01_071
and VAXMTAA01_071 remedial kits.
ECO Kit Approximate Size: 1908 Blocks
Kit Applies To: OpenVMS VAX V7.1
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:
VAXY2K01_071
In order to receive all the corrections listed in this
kit, the following remedial kits should also be installed:
VAXSYSA02_071
VAXBACK04_071
VAXMOUN05_071
VAXDISM01_071
VAXMTAA01_071
ECO KIT SUMMARY:
An ECO kit exists for Y2K issues on ODS-1 on OpenVMS VAX V7.1. 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
- [SYSEXE]BACKUP.EXE
- [SYSLIB]BACKUPSHE.EXE
- [SYSEXE]STABACKUP.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
o Verify does not flag files which are directly back linked to
themselves as having invalid backlinks.
Images Affected: [SYSEXE]VERIFY.EXE
o VERIFY hangs in an infinite loop during its scan of the
directory structure.
Images Affected: [SYSEXE]VERIFY.EXE
Problems Addressed in the VAXF11X05_071 Kit:
o When two processes are accessing a file via the MOVEFILE and
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.
Image(s) 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.
Image(s) 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.
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
o When a directory with multiple headers, e.g., a large ACL, is
deleted on one mode in a cluster (Node A), if that directory
had previously been accessed on another node in the cluster
(Node B), the files created with the previously deleted
headers would show up on Node B with a NOSUCHFILE error."
Image(s) Affected: [SYS$LDR]F11BXQP.EXE
Problems Addressed in the VAXF11X04_071 Kit:
o During the mounting of the system disk, the error message that
the disk is mounted with a reduced cache is suppressed. Thus,
the System Manager may be unaware that the performance of the
system disk and all others attached to the same cache block is
questionable.
Image Affected: [SYSEXE]FILESERV.EXE
Note: [SYS$STARTUP]VMS$CONFIG-050_CACHE_SERVER.COM also is
needed to run the FILESERV.EXE image.
o When deleting a large file (such as a system dump file), a
UNXSIGNAL Bugcheck may occur. This particular bugcheck occurs
because a variable in the code causes a reference to memory
data that the file system does not own and an internal access
violation occurs (ACCVIO).
Image Affected: [SYS$LDR]F11BXQP.EXE
o On some systems with higher rates of system paging or with
WSDEC set to a non-standard value, a system can crash with a
PGFLIPLHI (Page Fault IPL too High) bugcheck. This problem
happened when the system returns from a SMP$ACQUIRE call.
Image Affected: [SYS$LDR]F11BXQP.EXE
o An XQPERR can occur in the RDBLOK module during disk cleanup
using DCL.
Image Affected: [SYS$LDR]F11BXQP.EXE
o When storing the value of a directory index buffer, the system
may crash with a PGFLIPLHI, SSRVEXCPTN error.
Image Affected: [SYS$LDR]F11BXQP.EXE
o A dismount on a shadowed device results in an unnecessary
copy.
Image Affected: [SYS$LDR]F11BXQP.EXE
o If a process is created with a termination mailbox unit
assigned, the files are not properly audited.
Image Affected: [SYS$LDR]F11BXQP.EXE
o An XQPERR bugcheck (crash) in the RETURN_CREDITS module can
occur during DISMOUNT.
Image Affected: [SYS$LDR]F11BXQP.EXE
o A XQPERR Bugcheck (crash) in XQP can occur during an SET ACL
(SET FILE/ACL) operation.
Image Affected: [SYS$LDR]F11BXQP.EXE
o When two processes are competing to dismount a volume, one
process may be just a bit faster than the other. This process
can delete the VCB and other structures before the second
process has time to finish up its processing. The result is
in an UNXSIGNAL/ACCVIO crash.
Image Affected: [SYS$LDR]F11BXQP.EXE
o A device reporting a read error (SS$_PARITY) during read/write
processing in the XQP will attempt to record the bad blocks
and FID in the BADLOG.SYS file. When the internal close
operation occurs (on BADLOG), the system XQPERR bugchecks
when it finds the process's dirty buffers have not been written
out.
Image Affected: [SYS$LDR]F11BXQP.EXE
o An UNXSIGNAL/ACCVIO error can occur at module F11BXQP. This
problem can occur during mount, when the primary volume is not
yet mounted.
Image Affected: [SYS$LDR]F11BXQP.EXE
o Processes can hang (deadlock) when dismounting a device.
Image Affected: [SYS$LDR]F11BXQP.EXE
o Alternate file access checking does not provide the correct
information for files on ODS-1 disks. That is, an ODS-1 disk
access does not process the alternate file access checking
parameters FIB$L_ALT_ACCESS and FIB$L_STATUS.
Image Affected: [SYSEXE]F11AACP.EXE
o The F11A routine ACPCONTROL only understands the control
function REMAP_FILE. Hence, for illegal function codes, all
other control functions return NORMAL, when ILLIOFUNC should
be returned instead.
Image Affected: [SYSEXE]F11AACP.EXE
o Occasional false end-of-file (EOF) errors can occur on a read
operation.
Image Affected: [SYS$LDR]F11BXQP.EXE
o The XQP fails after an IO$_DEACCESS call with an SS$_BADPARAM
error. One cannot determine whether a file is still open or
not due to the failed IO$_DEACCESS call.
Image Affected: [SYS$LDR]F11BXQP.EXE
o Non-privileged users can change the revision date (and count)
of a file for which they should have only READ access. For
example, if a non-privileged user with READ-only file access
tries to set the file protection, a failure occurs with an
SS$_NOPRIV error as expected. However, the revision date (and
count) are modified.
Image Affected: [SYS$LDR]F11BXQP.EXE
Problems Addressed in the VAXF11X03_071 Kit:
o A XQPERR bugcheck error "all the index buffers are active"
occurs typically when running with a reduced cache or during a
BACKUP.
o An XQPERR bugcheck error, 'wrong lock basis with FCB present',
occurred when creating files with ACLs on a full volume.
o One can serialize on the wrong volume in a volume set.
o If more than one process queues for a volume's activity
blocking lock, the XQP can deadlock.
o The user-mode crasher in VALIDATE_FILE needed to be fixed.
Specifically, the FIB$C_VALIDATE_FILE ACP control function
caused a bugcheck if called on a channel which was not
accessed.
o Various XQPERR bugchecks occur in directory scanning/shuffling.
o When a file with a version limit of 1 is created and SYSTEM_CHECK
is on or bit 5 or 6 of ACP_DATACHECK is 1, an XQPERR bugcheck
occurs due to a corrupted directory.
o The NOTIFY_USER for final status of an XQP request occurs too
early in XQP request completion to report any errors produced
in cleanup or auditing. This problem is normally all right,
since USER_STATUS is not expected to change during cleanup.
However, if it does change, then the output of SET WATCH FILE
is misleading.
o XQP requests to create a new file with version limits set can
fail with an SS$_NOSUCHFILE error.
o Deleting a stale alias on a directory with extension headers
can bugcheck with XQPERR "Lock index has shifted". This
problem occurs when:
1. an alias to an existing file is created,
2. the original file is deleted, and
3. the original file's file header is reused as an extension
header of the alias's parent directory (when ACEs are
added to the directory).
o Prevent access to file headers beyond index file
highwater-marking (HWM).
One can possibly ACCESS by FID a file header beyond the
current end of the index file on a freshly-initialized volume.
Creating a new file accessed in this way can bugcheck the
system with the XQPERR error.
o Fix a reserved operand fault bugcheck on $QIO exit. The $QIO
failed on return because the IPL was set to zero but was
entered at IPL 2.
o The code was in a pageable psect and managed to get paged out.
o $GET_SECURITY was reading the ORB on a file without any
synchronization with the filesystem. In the best case, this
problem can lead to bad information being returned. In the
worst case, if the filesystem was rebuilding the ORB's ACL
chain at the time, a kernel mode ACCVIO can occur.
*** Note: In order to get this fix, you must install the
VAXSYSA02_071 kit.
Problems Addressed in the VAXINIT01_071 Kit:
o A possible system crash occurs during Host Based RAID Unbinds
with MME code enabled. A mailbox read synchronization problem
causes the crash.
This problem only occurs when a host-based RAID UNBIND command
is done while an MME-based application is running.
This problem can occur in several different code areas of the
operating system. In order to eliminate all known instances
of this problem, the following remedial kits (or their
supersedants) will also need to be installed:
VAXSYSA02_071
VAXBACK03_071
VAXMOUN04_071
VAXDISM01_071
VAXMTAA01_071
Images Affected: [SYSEXE]INIT$SHR.EXE
o A process using MME could potentially "miss" the VOL1 label on
a tape. Also, a process could "hang" trying to send a message
to the MME process.
Problems Addressed in the VAXVERI01_071 Kit for OpenVMS VAX V6.1, V6.2,
V6.2-0HF, V7.0, V7.1:
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.
Images Affected: [SYSEXE]VERIFY.EXE
Problems Addressed in the VAXMTAA01_071 Kit:
o A possible system crash occurs during Host Based RAID Unbinds
with MME code enabled. A mailbox read synchronization problem
causes the crash.
This problem only occurs when a host-based RAID UNBIND command
is done while an MME-based application is running.
This problem may occur in several different code areas of the
operating system. In order to get eliminate all known
instances of this problem, the following remedial kits (or
their supersedants) will also need to be installed:
VAXSYSA02_071
VAXBACK03_071
VAXDISM01_071
VAXINIT01_071
VAXMOUN04_071
o A process using MME could potentially "miss" the VOL1 label on
a tape. Also, a process could "hang" trying to send a message
to the MME process.
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.
|
Files on this server are as follows:
|
»vaxods1_01_u2055.README
»vaxods1_01_u2055.CHKSUM
»vaxods1_01_u2055.CVRLET_TXT
»vaxods1_01_u2055.a-dcx_vaxexe
»vaxods1_01_u2055.CVRLET_TXT
|
