OpenVMS VAXBACK4_U2055 VAX V5.5 - V5.5-2 BACKUP ECO Summary
Copyright (c) Digital Equipment Corporation 1994. All rights reserved.
OP/SYS: OpenVMS VAX
COMPONENT: BACKUP Utility
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXBACK4_U2055
ECO Kits Superseded by This ECO Kit: VAXBACK03_U2055
VAXBACK02_U2055 (CSCPAT_1101 V1.7)
VAXBACK01_U2055
ECO Kit Approximate Size: 1100 Blocks
Kit Applies To: OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2H4
System Reboot Necessary: No
ECO KIT SUMMARY:
An ECO kit exists for BACKUP on OpenVMS VAX V5.5 through V5.5-2H4. This
kit addresses the following problems:
NOTE: OVERWRITE is no longer a valid response to the BACKUP utility's
UNEXPIRED message. The only valid response to the message
query is QUIT or NEW.
Problems addressed by the VAXBACK4_U2055 kit:
o BACKUP inadvertently queries the user when the first CRC error
occurs and before XOR recovery takes place. BACKUP should
prompt only on every 100th error logged internally. Responding
to the query with a CONTINUE usually allows the BACKUP operation
to proceed. However, it is possible the process could hang.
This problem will be fixed in a future version of OpenVMS VAX.
o The code to update the RMS journaling date was not terminating
the RMS journaling attribute descriptor correctly.
This problem will be fixed in a future version of OpenVMS VAX.
o BACKUP may terminate during a /VERIFY pass with the error "FATAL
CONTROLLER ERROR" when excessive read errors occur on a marginal
tape media.
This problem will be fixed in a future version of OpenVMS VAX.
Problems addressed in previous kits that have been included in this kit:
o If an attempt is made to append a saveset to a tape after receiving
a fatal PROCINDEX error, the backup will fail with the POSITERR
error because the logical end of tape can not be found. This occurs
due to BACKUP initializing the saveset with the ANSI tape label
prior to the PROCINDEX error.
This problem is fixed in OpenVMS VAX V6.1.
o A lost file with a file name greater than 20 characters can not be
selectively restored from an image backup. The file name as
displayed by BACKUP/LIST is truncated to 20 characters. It is
not possible to restore this file with the /SELECT using either
the original name, the 20 character truncated name, or using
wildcard characters.
This problem is fixed in OpenVMS VAX V6.1.
o A BACKUP/IMAGE operation may save many lost files if the process
directory is a specific value. For example, if the process
default directory is set to [$1$], BACKUP/IMAGE will save all
files as lost files.
This problem is fixed in OpenVMS VAX V6.1.
o A number of changes were previously added to BACKUP to correct
various problems when BACKUP was run from a subprocess. For
example, at a volume_switch when prompting for a continuation
volume. These changes are no longer needed since the appropriate
changes have been made to the MOUNTSHR and IO_ROUTINES images.
The following messages are now obsolete:
SUBALL
SUBNOALL
This change is included in OpenVMS VAX V6.1.
o Input files are incorrectly deleted or updated when /VERIFY is
used with either /DELETE or /RECORD. For example, if
/DELETE is used with the /VERIFY qualifier on the same
command line, the input files will be deleted if the output
files can not be written.
NOTE: While researching this problem, it was discovered that the
/COMPARE qualifier was allowed with the /DELETE or /RECORD
qualifier. This combination is illegal and will now be
detected and no longer allowed on the command line.
This problem is fixed in OpenVMS VAX V6.1.
o When /VOLUME is used in the BACKUP command line and the input
volume is not part of a volume set, a possible ACCVIO may occur.
BACKUP will now test for this situation and issue an informational
message that the /VOLUME qualifier will be ignored.
This problem will be fixed in a future version of OpenVMS VAX.
o After performing a backup of an AXP system disk on a OpenVMS VAX
system, the target disk will not boot. For example,
>>>b dkb100
(boot dkb100.1.0.1.0 -flags 0,0)
block 0 of dkb100.1.0.1.0 is not a valid boot block
bootstrap failure
After using WRITEBOOT on the disk, the system will be bootable.
This problem is fixed in OpenVMS VAX V6.1.
o BACKUP does not allow the /RECORD or /DELETE qualifiers if the
input disk is writelocked. Previously, BACKUP started the save
operation and failed later during the recording or delete pass
because of the writelocked disk.
BACKUP will now check early whether or not a /RECORD or /DELETE can
be performed. If it can not be performed, BACKUP will inform the
user and exit immediately
This problem will be fixed in a future version of OpenVMS VAX.
o BACKUP does not deal with a corrupted directory. For example,
the following BACKUP 'system messages' may occur if a corrupted
directory is backed up and 'namecount' field is at fault:
%BACKUP-F-FREEMEM, error freeing virtual memory
-LIB-F-BADBLOSIZ, bad block size
or
%BACKUP-F-FREEMEM, error freeing virtual memory
-LIB-BADBLOADR , bad block address
After informing the user with the following message,
%BACKUP-E-BADDIR, directory device:[dir_filespec] has invalid
format
BACKUP will now skip the bad directory. BACKUP will then continue
with the next available directory.
This problem will be fixed in a future version of OpenVMS VAX.
o When writing to an output tape, BACKUP incorrectly changes the
default buffer size of the tape device to a 4. After completing,
BACKUP does not dismount the tape drive. This results in possible
subsequent RMS read operations failing with errors such as:
%COPY-E-READERR, error reading disk:[dir]file.ext
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-BADPARAM, bad parameter value
This problem is fixed in OpenVMS VAX V6.1.
o A restriction was implemented to disallow the use of the /REWIND and
/EXACT_ORDER qualifiers concurrently in a BACKUP command. This
prevented the user from specifying the exact label for the first
volume which the user wished to re-use.
This problem is fixed in OpenVMS VAX V6.1.
o The use of /EXACT_ORDER with /PROTECTION and /TAPE_EXPIRATION did
not detect a Volume-out-of-order or a Volume-used condition.
Therefore, the tape_volume label was overwritten. If the
tape_expiration date had not expired the tape may also be
overwritten.
This problem is fixed in OpenVMS VAX V6.1.
o Systems that have the Media Management Extensions [MME] enabled and
active and that specify files successfully saved be post-processed
(either /RECORD or /DELETE) may receive a message indicating that
postprocessing did not occur for any saved files. Those files will
not in fact have been post-processed as requested. For example,
$ BACKUP/RECORD/LOG SYS$lOGIN:LOGIN.COM SYS$lOGIN:TEST.BCK/SAVE
%BACKUP-S-COPIED, copied DISK:[DIR]LOGIN.COM;3
%BACKUP-S-COPIED, copied DISK:[DIR]LOGIN.COM;2
%BACKUP-S-COPIED, copied DISK:[DIR]LOGIN.COM;1
%BACKUP-I-STARTRECORD, starting backup date recording pass
%BACKUP-W-NONEREC, no files processed on recording pass
This problem will be fixed in a future version of OpenVMS VAX.
o When performing a BACKUP using the /VERIFY qualifier on a
disk-to-disk operation, the fatal error 'ALLOCMEM' may occur once
the VERIFY pass starts. Removing the /VERIFY qualifier allows
the operation to complete successfully.
This problem has been corrected in OpenVMS VAX V6.1.
o BACKUP/IMAGE saves files with alias entries (synonym files) multiple
times.
This problem will be fixed in a future version of OpenVMS VAX.
o BACKUP runs out of channels during processing and returns a
BACKUP$_NOMSG error.
This problem will be fixed in a future version of OpenVMS VAX.
o During an IMAGE BACKUP, files which receive a FORCEDERROR are backed
up twice, once in the original directory and once in a directory
named '[]'.
This problem will be fixed in a future version of OpenVMS VAX.
o BACKUP/VERIFY indicates that files [/devices] in a disk-to-disk copy
operation were compared when no verification was actually performed
by BACKUP.
This problem is fixed in OpenVMS VAX V6.1.
o BACKUP/LIST displays a zero "used" block count for pre-allocated
files, (files which have a zero end-of-file block [EFBLK], but whose
allocated size is greater than zero). However, a DIRECTORY/SIZE=ALL,
(and DIRECTORY/FULL), shows the same number of blocks used as
allocated. A DUMP/HEADER of this file shows that the EFBLK for this
file is actually zero.
This problem is fixed in OpenVMS VAX V6.1.
o BACKUP does not save those input files specified by using relative
file versions (e.g., A.A;-1, A.A;0, A.A;-5).
This problem is fixed in OpenVMS VAX V6.1.
o BACKUP does not save (INPUT) files specified with a rooted
directory.
Example: DEV:[DIR.][SUBDIR]*.*;*
This problem is fixed in OpenVMS VAX V6.1.
o If a BACKUP user specifies the /EXACT_ORDER qualifier and does not
specify tape label(s) (e.g., does not use the /LABEL qualifier) and
uses more than 20 tape volumes in a single BACKUP operation, an
ACCVIO may occur.
This problem is fixed in OpenVMS VAX V6.1.
o In prior versions, MKDRIVER would return SS$_DRVERR if a blank SCSI
tape was read. This is the wrong error message. The message should
be SS$_OPINCOMPL. The error SS$_DRVERR can be returned by other
drives for different reasons. BACKUP special cases SS$_DRVERR as
being a blank tape and may return a NOTANSI error message.
This problem is fixed in OpenVMS VAX V6.1.
o Alias files are not being dealt with correctly if a non-IMAGE
BACKUP is done using the /FAST qualifier.
This problem is fixed in OpenVMS VAX V6.1.
o An ACCVIO may occur when performing BACKUP over a network to a
foreign operating system while using the /JOURNAL qualifier.
This problem is fixed in OpenVMS VAX V6.1.
o Primarily with unattended SLS BACKUPs and TA90s, an ACCVIO may occur
immediately after the first tape volume switch when a saveset starts
in the EOT region of the previous tap volume. Failure is very
intermittent.
This problem is fixed in OpenVMS VAX V6.1.
o An IMAGE RESTORE of a bound volume set fails to restore some
files when they span more than one volume. The files involved all
fail with the following error:
%BACKUP-E-OPENOUT, error opening $DEVICE:[DIRECTORY]xxx.yyy;1
-SYSTEM-W-DEVICEFULL, device full - allocation failure
The problem occurs only when a file that is on the volume being
backed up has no retrieval pointers in the primary header and the
extension header is on another relative volume.
This problem is fixed in OpenVMS VAX V6.1.
o After a tape volume switch with the VERIFY option selected, an
IVCHAN error may occur during the first DIRECTORY scan on the
subsequent tape volume. For example:
%BACKUP-I-RESUME, resuming operation on volume 2
%MOUNT-I-OPRQST, Please mount volume 372109 in device
_XXXXXX$MKA500:
BACKUP requests: Saveset 13MAR1993SOURCE_0, Volume number 02,
write ENABLED
%MOUNT-I-MOUNTED, 372109 mounted on _XXXXXX$MKA500:
%MOUNT-I-RQSTDON, operator request canceled - mount
completed successfully
%BACKUP-I-STARTVERIFY, starting verification pass
%BACKUP-I-RESUME, resuming operation on volume 3
%MOUNT-I-OPRQST, Please mount volume 211612 in device
_XXXXXX$MKA500:
BACKUP requests: Saveset 13MAR1993SOURCE_0, Volume number
03, write ENABLED
%MOUNT-I-MOUNTED, 211612 mounted on _BLADE0$MKA500:
%MOUNT-I-RQSTDON, operator request canceled - mount
completed successfully
%BACKUP-E-OPENDIR, error opening directory
_XXXXXX$DKA100:[DATA.LJK.LJK_SPOOLER]
-SYSTEM-F-IVCHAN, invalid I/O channel
This problem is fixed in OpenVMS VAX V6.1.
o When writing to an output tape, BACKUP incorrectly changes the
default buffer size of the tape device to a 4. After completing,
BACKUP does not dismount the tape drive. This may result in
subsequent RMS read operations failing with errors such as shown
below:
%COPY-E-READERR, error reading disk:[dir]file.ext
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-BADPARAM, bad parameter value
This problem is fixed in OpenVMS VAX V6.1.
o The change included to fix the /NOINITIALIZE qualifier and how it
deals with INDEXF.SYS on the disk causes problems for SEVMS. An
enhancement is included that will maximize the size of INDEXF.SYS if
the number of files in the saveset is larger than the INDEXF.SYS on
the target device.
This problem is fixed in OpenVMS VAX V6.1.
o The restriction to disallow the use of the qualifiers '/REWIND' and
'/EXACT_ORDER' concurrently in a BACKUP command prevents the user
from specifying the exact label for the first volume they wish to
re-use (initialize and use). This restriction has been removed.
This problem is fixed in OpenVMS VAX V6.1.
o BACKUP status messages were added alphabetically and by order of
severity. This caused messages already in the message file to be
moved and their status code numeric values to change. With this kit
installed, all new messages will be added at the end of the message
file instead of alphabetically.
This problem is fixed in OpenVMS VAX V6.0.
o BACKUP is unable to mount a continuation volume when performing a
BACKUP operation in a subprocess unless the device is explicitly
allocated. With this kit installed, a warning message will now be
returned to the user to allow them to take corrective action.
This problem is fixed in OpenVMS VAX V6.0.
o If there is a volume label problem on a continuation volume, the
user is prompted for a response. If the user enters 'QUIT', BACKUP
does not abort but initiates a RESTART condition and re-prompts the
user for another response. If the user enters 'QUIT' a second time,
the BACKUP process is aborted.
This problem is fixed in OpenVMS VAX 6.0.
o Files which have not been completely saved may be deleted (/DELETE)
or their BACKUP dates updated (/RECORD). This has occurred when the
output [disk] device runs out of space during a BACKUP copy
operation and either of the above qualifiers have been specified.
This problem is fixed in OpenVMS VAX V6.0.
o When highwater marking is enabled, BACKUP may report VERIFY errors
on index files during either a BACKUP save or restore. This occurs
when the highwater mark is less than the allocated file size. (The
"used" size is less than the allocated file size.)
NOTE: To correct this problem, both VAXBACK4_U2055 and CSCPAT_1162
must be installed. The kits can be installed in any order.
The fix for STABACKUP is included in OpenVMS VAX V6.0. The
fix for on-line BACKUP will be included in a future release
of OpenVMS VAX.
o After upgrading to OpenVMS VAX V5.4-3, a BACKUP incremental restore
may return the following error messages for every file in the
directory:
%BACKUP-S-CREDIR, created directory 'disk:[directory]'
%BACKUP-E-READATTR, error reading attributes for 'disk:[directory]'
-SYSTEM-W-ACCONFLICT, file access conflict
%BACKUP-E-INCENTERR, error creating directory entry for
'[directory], file access conflict
However, upon re-executing the BACKUP/INCREMENTAL command, the files
DO get restored because the directory WAS created the first time the
command was entered.
This problem is fixed in OpenVMS VAX V6.0.
o If an operator attempts to abort a BACKUP operation using the DCL
command 'REPLY/ABORT=nnn', BACKUP ignores the request even though an
OPCOM "REQUEST ABORTED" acknowledgment message appears. This
behavior has been specifically noted on a selective BACKUP restore
operation of a multi-volume saveset.
This problem is fixed in OpenVMS VAX V6.0.
o If the /RECORD qualifier is used and BACKUP is restarted using the
'RESTART' option, the 'Backup dates' are not updated correctly.
This problem is fixed in OpenVMS VAX V6.0.
o On SCSI devices (e.g., TLZ04), a blank tape can not be initialized
using the BACKUP/REWIND command. The following error messages are
returned:
%BACKUP-F-LABELERR, Error in tape label processing
-SYSTEM-F-DRVERR, fatal drive error
This problem is fixed in OpenVMS VAX V6.0.
o With this ECO kit installed, a new BACKUP qualifier 'EXACT_ORDER' is
introduced which allows enhanced volume label processing. Depending
on the other qualifiers you specify on the command line,
/EXACT_ORDER enables you to do the following:
- Specify the exact order of tapes and labels that you want
to use in a BACKUP operation.
- Preserve the existing volume label on a tape.
- Prevent previous volumes of a multivolume save operation
from being overwritten.
This new qualifier is included in this ECO and OpenVMS VAX V6.0.
NOTE: For more information on this new qualifier, refer to the ECO
kit release notes.
o SLS (System Storage Library) specific code was added to BACKUP and
can be accessed using the new BACKUP qualifier
'/STORAGE_LIBRARY_SYSTEM'.
This problem is fixed in OpenVMS VAX V6.0.
o Use of the /NOINITIALIZE qualifier can incorrectly set EFBLK in
INDEXF.SYS.
This problem is fixed in OpenVMS VAX V5.5-2.
o As a result of a change to the XQP in OpenVMS VAX V5.4-3,
spurious error messages are displayed if BACKUP attempts to create
directories which already exist on the disk during a restore
operation.
This problem is fixed in OpenVMS VAX V5.5-2.
NOTE: The messages have no impact on the success of the
restore operation.
o If a saveset ends exactly at the EOT (End Of Tape) and another
saveset follows immediately after, BACKUP may not initiate a volume
switch causing subsequent savesets to run the tape off the reel.
When this occurs, savesets do not contain any data, just header
information.
NOTE: No error messages are returned.
This problem is fixed in OpenVMS VAX V5.5-2.
o When using BACKUP/IMAGE/VOLUME=n to back up one volume of a bound
volume set, data corruption may occur even if the BACKUP qualifier
'/VERIFY' is specified. This results in a saveset that is unusable.
This problem is fixed in OpenVMS VAX V5.5-2.
o During a /PHYSICAL BACKUP operation, BACKUP may hang in the LEF
state at the end of the first tape volume.
This problem is fixed in OpenVMS VAX V5.5-2.
o Excessive null pad records may be added to BACKUP blocks when
small/low process quotas are used for the account where BACKUP is
run from or a large blocksize value is specified. This causes
saveset sizes to be much larger.
This problem is fixed in OpenVMS VAX V5.5-2.
o After creating a BACKUP sequential disk saveset on a drive mounted
with the /FOREIGN qualifier, the 'DISMOUNT/UNLOAD' DCL command does
not dismount/unload the disk.
This problem is fixed in OpenVMS VAX V5.5-2.
o DFS/BACKUP process hangs when saving from a DFS served device.
This problem is fixed in OpenVMS VAX V5.5-2.
o The DFS/BACKUP process may hang during a BACKUP save from a DFS
device when an error condition occurs. The LBN scan/sort is also
disabled when the input device is a DFS served disk.
This problem is fixed in OpenVMS VAX V5.5-2.
o BACKUP corrupts the first two ACEs of a file's ACL if the file is
opened for exclusive access after it has been saved, but before the
recording pass has processed it.
This problem is fixed in OpenVMS VAX V5.5-2.
o If the year specified by the BACKUP '/TAPE_EXPIRATION' qualifier is
greater than 2000, BACKUP will allow the tape to be overwritten.
This problem is fixed in OpenVMS VAX V5.5-2.
o If the BACKUP qualifier '/PROTECTION' is used, BACKUP will return a
MOUNTERR and fail to mount the tape if the process does not have
UIC-based access to the tape volume.
This problem is fixed in OpenVMS VAX V5.5-2.
o BACKUP initializes the output disk even if the BACKUP qualifier
'NOINITIALIZE is specified.
This problem is fixed in OpenVMS VAX V5.5-2.
o If a user mounts a tape, spawns a subprocess, then issues
a BACKUP command from the subprocess, continuation tape processing
fails with the OPCOM message:
_MUA0 is not available for mounting
This problem is fixed in OpenVMS VAX V5.5-2.
o If the tape that BACKUP is going to use is mounted (using a
logical name) before the BACKUP operation is initiated, and the
BACKUP operation uses more than one tape volume, the logical name
used in the MOUNT is no longer assigned when the BACKUP operation is
done, even though the tape is still mounted.
This problem is fixed in OpenVMS VAX V5.5-2.
o After a BACKUP/IMAGE restore of a common system disk, VMS$COMMON.DIR
becomes the synonym of SYSCOMMON.DIR. As a result, incorrect file
specifications for files residing in the common root are returned
when using such lexical functions as F$ENVIRONMENT or F$GETQUI.
This problem is fixed in OpenVMS VAX V5.5-2.
o Resetting a tape device to the original settings upon exiting may
cause a SYSTEM-F-SERIOUSEXCP error to be returned. For example:
$ SET VERIFY
$ SET NOON
$ TAPE :== $1$MUA0:
$ INITIALIZE/DENSITY=6250 'TAPE' A000
$ BACKUP/VERIFY/LOG/IGNORE=LABEL XX.LIS 'TAPE'XX.BCK/SAVE
$ SET MAGTAPE/REW 'TAPE'
$ SET MAGTAPE/SKIP=FILE:1000 'TAPE'
$ SET MAGTAPE/SKIP=FILE:-1 'TAPE'
$ SET NOVERSION
$ EXIT
-SYSTEM-F-SERIOUSEXCP , TMSCP Controller , Serious Exception
This problem is fixed in OpenVMS VAX V5.5-2.
o If a wildcard file specification is used with a BACKUP/LIST command,
BACKUP will display the contents of the saveset in a continuous
loop.
This problem is fixed in OpenVMS VAX V5.5-2.
o Use of a sequential disk saveset can cause BACKUP to abort if the
output disk device is mounted foreign.
This problem is fixed in OpenVMS VAX V5.5-2.
o If a BACKUP file specification contains a searchlist logical which
was defined with 16 or more elements, some files will be backed up
twice and some files will not be backed up at all.
This problem is fixed in OpenVMS VAX V5.5-2.
INSTALLATION NOTES:
The system/cluster does not need to be rebooted after this kit is
installed. However, SYS$LIBRARY:DCLTABLES is modified to include the
new BACKUP qualifiers. To take advantage of the new syntax without
having to logout and then login, a process's copy of DCLTABLES can be
updated by using the following command:
$ SET COMMAND/TABLE=SYS$LIBRARY:DCLTABLES
NOTE: A new Standalone BACKUP image has been provided. Running
@STABACKIT from SYS$UPDATE will be necessary to place it in
the proper environment. If this step has already been
performed with the superseded kit VAXBACK02_U2055
(CSCPAT_1101 V1.7), this step will not be necessary as this
new ECO kit provides the same Standalone Backup image.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxback4_u2055_backup.README
vaxback4_u2055.CHKSUM
vaxback4_u2055.a-dcx_vaxexe
|
