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" 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 > 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" > >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