Everhart, Glenn (FUSA)
From:	Andy Goldstein [Goldstein@star.zko.dec.youknowwhere]
Sent:	Monday, May 10, 1999 10:54 AM
To:	Info-VAX@Mvb.Saic.Com
Subject:	Re: Zipping BCK files
GWDVMS::MOELLER wrote:
> 
> And nonetheless, BACKUP in VMS V3 knew to use RMS I/O on 'regularly'
> mounted tapes; this capability got completely removed (instead of
> being 'protected' by some qualifier, which likely was the intention)
> in V4. This hurt us quite a bit at the time, having to teach _users_
> (who commonly used BACKUP as an 'archiver' tool) all of the secrets
> of foreign tape handling, with associated procedures to check & preserve
> tape labels, in spite of the foreign mount (and disk space was rare enough
> then, which usually precluded COPYing save sets from/to tape).

The ability to write on normally mounted tapes was deliberately removed
in one of our attempts to "legislate morality" (my term for protecting
users from using the system in ways that we didn't intend and that don't
quite work). The following aspects of BACKUP's tape handling don't work
on normally mounted tapes:

(1) XOR recovery reading a tape. BACKUP assumes that an RMS file save
set is on a disk and uses RFA addressing to back up to the beginning of
an XOR group to do recovery of a bad block. RMS doesn't support RFA
addressing on a tape.

(2) Write error recovery. BACKUP used to write tapes with error recovery
inhibited, using its own error recovery. The purpose of this design was
to eliminate the risk of losing a good record during the normal
backspace - erase - rewrite error recovery on the old 9-track drives.
This feature is not available through RMS. This issue is obsolete with
present day tape drives and BACKUP now writes with normal error
recovery.

(3) Proper save set format on a multi-tape set. When a save set crosses
volumes, BACKUP completes the current XOR group on the tape being
finished and writes a copy of the backup summary record on the start of
th continuation tape. Obviously, to do this BACKUP has to be aware of
the tape switch. This feature is not available with RMS access to tape
files (or indeed with any access to a tape file through the tape file
system). Correspondingly, BACKUP is not capable of doing an XOR recovery
across two tape volumes. (Attempting such would drive the operator nuts
anyway.) Thus, when you write a multi-tape save set on a file-mounted
tape, the XOR group that crosses the two tapes is not recoverable.

Chalk this one up to a fanatic dedication to data integrity. And we did
add label checking to BACKUP tape handling.