Re: Help Needed: Tape Backup Save Set

From: Brad Hamilton (brMadAhamPiltSon_at_coMmcaAstP.neSt)
Date: 08/11/05 

Date: Wed, 10 Aug 2005 22:12:44 -0400

Steven M. Schweda wrote:
> From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt>
>
>>>>$backup/list (tape device)/save_set
>>>> ^^^^^^^^^
>>>
>>> If anyone ever finds a case where /SAVE_SET is actually required for a
>>>tape device, please provide the details.
>>
>>I remember that back in the VMS 5.* days, this used to be a requirement.
>
>
> Those are details? In any case, you mean like this?

They are "details" for me - since I have no access to v5.* any more, and
since I had problems restoring files _without_ using /SAVE_SET, and had
_no_ problems restoring files _with_ /SAVE_SET, this is what I am
reporting to you. Sorry if it doesn't tally with your experience.

>
> WIMP $ write sys$output f$getsyi( "VERSION")
> V5.4
>
> WIMP $ backup /noass /list mua0:
> Listing of save set(s)
>
> %MOUNT-I-WRITELOCK, volume is write locked
> %MOUNT-I-MOUNTED, WUSS02 mounted on _WIMP$MUA0:
> %BACKUP-W-NOT1STVOL, MUA0:[000000].; is not the start of a save set
>
> Save set: WUSS062.BCK, volume 2
> Written by: SYSTEM
> UIC: [000010,000040]
> Date: 28-MAY-2000 13:42:19.97
> Command: BAC/VER/IMA DKA200: MKA100:WUSS062.BCK/REW
> Operating system: VAX/VMS version V6.2
> BACKUP version: V6.2 (standalone)
> CPU ID register: 0A000005
> Written on: _SABKUP$MKA100:
> Block size: 8192
> Group size: 10
> Buffer count: 223
>
> Image save of volume set
> Number of volumes: 1
>
> [VMS$COMMON.SYSEXE]SYS.STB;1 199 15-MAY-1995 11:14
> [...]
>
>
> WIMP $ show device /full MUA0:
>
> Magtape WIMP$MUA0:, device type TK50, is online, allocated, deallocate on
> [...]
>
> And I remember _not_ needing it since at least as far back as VMS
> V5.0.
>

Good - but can you reproduce this behavior consistently? My experience
showed me at the time that using /save_set allowed me to _consistently_
restore files without error, while others in the same environment who
did _not_ use /save_set had problems.

<snip>

>>I know some of our Operations folks in the V7.1 era had problems
>>restoring files from tape savesets without /SAVE_SET, and had no
>>problems restoring files _with_ the qualifier.
>
>
> Sure you do. Sure they did. I'll believe it when I see it.
>

Again, my experience - please don't tell me that I _didn't_ experience
this behavior. Were you there??? :-)

<snip>

>>You'll notice, however, that almost all the other answers in this thread
>>have specified /SAVE_SET as an output qualifier for tape devices.
>
>
> And just how much help do you think that that was to the fellow with
> the problem? (Hint: Did he complain about an error message like
> "%BACKUP-F-LISINPSAV, /LIST requires save set as input", or did he ask
> about "No files found"?) And it was an _input_ qualifier.
>

My fault - I'm used to referring to /save_set as an output qualifier on
backup, not restore. /Save_set is of course an input qualifier on
restore. Oops. Still, many replies to this thread have specified
/SAVE_SET, and there is nothing _preventing_ someone from using it. So
it's pedantic. So it's overkill. It works. 'Nuff said.

All I'm really trying to say here is that it is my _belief_ that BACKUP
sometimes produces "funny" behavior in the "restore" and "list" "modes"
if the /SAVE_SET qualifier is not used. I've seen such behavior, enough
times to make sure that I always use /save_set. I've yet to "lose" a
file for a customer by adhering to this behavior. I've seen others
"lose" files for customers in this way, and have been able to
subsequently retrieve files previously considered "lost".

>
>>Can 50 million VMS manglers be wrong? :-)
>
> Well, let's look at the record. When I first reported here the
> long-time problem of Zip "-V" archives not working well on non-VMS
> systems, how many of them said, "Gee, Steve, good catch.", and how many
> chanted, "But that's not _supposed_ to work!" and/or "But that _can't_
> work!"? As I recall, the ratio was approximately 0:several. I'm still
> waiting for the (inevitable) flood of complaints from the users of Zip
> 2.31 and up when they discover that I broke it.
>

I haven't seen any breakage, and have used Zip 2.3-1 for a while now.
  Thanks. :-) I've probably not been able to find a mode in which to
break it, of course.

> And I'm still waiting for a counter-example on /SAVE_SET, and I still
> won't be holding my breath.
>

I'm sorry my humble experience does not count - but it did happen. I
never documented it at the time, because I did not know of the existence
of c.o.v., or that someone would challenge my experience as non-valid. :-) 

-- 
Bradford J. Hamilton
"All opinions are my own"
"Lose the MAPS, and replace '-at-' with @"