Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXBACK02_060 VAX V6.0 BACKUP ECO Summary
Copyright (c) Digital Equipment Corporation 1994. All rights reserved.
PRODUCT: OpenVMS VAX
COMPONENT: BACKUP utility
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXBACK02_060
ECO Kits Superseded by This ECO Kit: VAXBACK01_060 (CSCPAT_1167)
ECO Kit Approximate Size: 500 Blocks
Kit Applies To: OpenVMS VAX V6.0
System Reboot Necessary: No
ECO KIT SUMMARY:
An ECO kit exists for BACKUP on OpenVMS VAX V6.0. 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 in the VAXBACK02_060 (Special Release 9) 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 address in the VAXBACK01_060 (Special Release 8) 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.
Problems addressed in Special Release 7.1:
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 change is included 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 also uses more than 20 tape volumes in a single BACKUP
operation,an ACCVIO may occur.
This change is included 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.
The following error messages will occur if this function is
performed:
BACKUP-W-AFNOTSAVED, alias files not saved
BACKUP-W-ADNOTSAVED alias directory tree not saved
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.
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in the
OPENVMS database. To view these articles, open the appropriate product
database and perform a query using either of the following
search strings: 'VAXBACK02_060' or 'VAXBACK'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
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
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| BACKUP.EXE |%X2494FCA7| VAX V6.1-008 | 21-OCT-1994 |
| | | 06:55:52.89 |
+----------------------------+----------+-----------------+--------------+
|
