Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp


more options
 
hp.com home
End of Jump to page title
HP Services Software Patches
Jump to content


» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

patches by topic
» DOS
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

connection tools
» nameserver lookup
» traceroute
» ping


Find Support Information and Customer Communities for Presario.
Content starts here
HP Services Software Patches - vaxback4_u2055_backup
 
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.
Files on this server are as follows:
»vaxback4_u2055_backup.README
»vaxback4_u2055.CHKSUM
»vaxback4_u2055.a-dcx_vaxexe
privacy statement using this site means you accept its terms