From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 28-AUG-1989 21:57
To: MRGATE::"ARISIA::EVERHART"
Subj: Should BACKUP write its own labels? (Was Automating system backups...)
Message-Id: <8908290144.AA15381@crdgw1.ge.com>
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Mon, 28 AUG 89 13:52:12 PDT
Received: from INDYVAX.IUPUI.EDU by KL.SRI.COM with TCP; Mon, 28 Aug 89 08:09:43 PDT
Date: Mon, 28 Aug 89 10:11 EST
From: "Mark H. Wood" <IMHW400@INDYVAX.IUPUI.EDU>
Subject: Should BACKUP write its own labels? (Was Automating system backups...)
To: INFO-VAX@KL.SRI.COM
X-Vms-To: IN%"INFO-VAX@KL.SRI.COM"
>From: John Hascall <deimos.cis.ksu.edu!atanasoff!hascall@UUNET.UU.NET>
> There is nothing special about tape-labels, they are just
> ordinary records which are interpreted by the MTAACP as having
> meaning. It is a simple matter to write labels on a tape,
> just mount it foreign, and start writing records that look like
> labels (i.e., VOL1 [HDR1 HDR2 tm fileN... tm EOF1 EOF2 tm]... tm).
>
> I, for one, like this feature of backup.
Perhaps it is a matter of taste. I think that there is something very special
about tape labels, since they assist me in preventing unauthorized access and
operational errors, and I object to any "feature" that allows a simple mistake
to blow away a tape's security and identity. There are few things so
*un*amusing as to be requested to mount tape X, get the tape marked X and mount
it, and be informed that the tape is not really named X and would I please get
it right next time!
I will admit to an extreme viewpoint on this issue, as anybody at my site can
tell you.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>From: "Jamie Hanrahan, jeh@crash.cts.com"
> <hubcap!ncrcae!ncr-sd!crash!simpact!jeh@GATECH.EDU>
>In article <8908241725.AA24451@ucbvax.Berkeley.EDU>,
>IMHW400@INDYVAX.IUPUI.EDU ("Mark H. Wood") writes:
>> Am I the only one who finds it incredible that non-standalone BACKUP is even
>> *allowed* to write tape labels? I realize that BACKUP does various sneaky
>> things to optimize its use of the tape datapath and improve error recovery,
> but
>> does all that really make it impossible to use the normal MTAAACP and just let
>> VMS take care of the labels?
>
>Well, yes, it does. MTAACP could write the BOT labels just fine. But at
>EOT, BACKUP needs to close out whatever XOR redundancy group it's in the
>middle of, and write some other BACKUP-specific end-of-volume blocks,
>followed by the standard Ansi EOT labels. If it was writing to a normally
>mounted tape (under MTAAACP) there'd be no way to do this.
Couldn't one do it like this:
- Create the saveset using FIB$C_USREOT in FIB$W_CNTRLFUNC.
- when the write QIO returns SS$_ENDOFTAPE or SS$_ENDOFVOLUME,
issue IO$_ACPCONTROL with FIB$C_CLSEREXCP in FIB$W_CNTRLFUNC so that
subsequent QIOs don't abort.
- Write out the trailing information.
- Issue IO$_ACPCONTROL with FIB$C_NEXTVOL in FIB$W_CNTRLFUNC to force
out the EOV labels.
I've never attempted such a thing, but it looks to me as if that's what the
ACPCONTROL functions were designed for. Comments?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mark H. Wood IMHW400@INDYVAX.BITNET (317)274-0749 III U U PPPP U U III
Indiana University - Purdue University at Indianapolis I U U P P U U I
799 West Michigan Street, ET 1023 I U U PPPP U U I
Indianapolis, IN 46202 USA I U U P U U I
[@disclaimer@] III UUU P UUU III