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 - vaxback02_060_backup
 
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.

    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.
 

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

Files on this server are as follows:
»vaxback02_060_backup.README
»vaxback02_060.CHKSUM
»vaxback02_060.a-dcx_vaxexe
privacy statement using this site means you accept its terms