Saveset blocksize on tape to allow COPY to disk

[John Gillings]

Art,

>I guess I realize a saveset is a
>"special" file, but in the end, one
>could argue a file is a file. If
>savesets can be resurrected after
>an "unsanctioned" zipping and
>transportation

Note, there is a BIG difference between a saveset on DISK and a saveset on TAPE. When BACKUP was architected, tape drives lacked many of the error detection and recovery features of disk subsystems of the day, so BACKUP had to compensate. See all the extra stuff BACKUP has /CRC, /GROUP etc... (and a few more "under the hood"). That a tape created by BACKUP looks like a "real" Files-11 tape is almost a coincidence.

The unsupported COPY issue is just for savesets on *TAPE*. Once the saveset file is on a disk, yes, it's just a file, and you can do what you like with it, with whatever utilities and programs you like.

Please make sure you understand the distinction here.

FWIW, I believe that magnetic tape technology has reached its use by date. The only reason it was ever worthwhile was price. You traded cheap media for long save and recovery times.
Given the cost of hard disk drives and optical media is almost as cheap as those expensive tape cartridges, I'd recommend everyone stops considering a tape drive as a requirement and seriously considers a backup strategy that is entirely disk based. Huge advantages, just plug the disk module into the shelf and go. No messing around with arguments like this thread, no waiting for restores, no potential broken tapes or dropouts.

[Uwe Zessin]

> That a tape created by BACKUP looks like a
> "real" Files-11 tape is almost a coincidence.

Yep, I recall from a discussion with Andy G. some years back that it was rather meant for debugging purposes.

Ho, btw: I'd be very careful when creating savesets over a DECnet link. It's been a number of years now (10+), but I had a situation when BACKUP did create corrupted savesets that way - better use a /VERIFY.

[Art Wiens]

Peter:

That's _exactly_ what I did with the exception of the last image backup of the LD disk.

The reason this whole thing came up is I did _exactly_ that and I ended up with a "corrupt" restore. Both VMS$COMMON.DIR and all the SYSCOMMON.DIR aliases were broken - No such file message if any of them were referenced. The only thing that "worked" was a DIR/FILE which showed they were all one in the same FID.

I fixed the above "corruption". I was very tempted to start another thread entitled "Unsupported action, LD Driver bug, Bad source disk or Bad tape/drive" but I wanted to try it a few times to see if it was consistent and/or if it behaved differently if I restored from a saveset on disk. Plus the title was too long ;-)

Cheers,
Art

[Art Wiens]

John:

Thanks for even more insight! I understand.

I'm with you on pitching out tape technology ... have a look at my personal quote in my profile ;-)

I haven't had a chance to try the tape with the smaller block size yet. I'll load it up before I go home and give it a whirl tonight.

Art

[Ian Miller.]

RE: "Unsupported action, LD Driver bug, Bad source disk or Bad tape/drive"
why not report it here
http://www.openvms.org/phorum/list.php?f=5

and the author may reply.

[Uwe Zessin]

> ... from a VAX v6.2 system ...
> ... on my test v7.3-2 Alpha ...

> Both VMS$COMMON.DIR and all the SYSCOMMON.DIR aliases were broken

Sigh, it is not an LD driver bug - the fault is in BACKUP!

It is too bad that compatibility is lost and a simple BACKUP/IMAGE save & restore does not work any longer. Now you have to try and understand those cryptic descriptions of the /noALIAS qualifier :-( :-(

[Art Wiens]

Ok, we've determined that 32256 is a "good" blocksize to use. I was able to successfully copy the saveset from tape to disk.

Now this "minor" issue of my disk being unusable!!

Time for a new thread.

Thanks very much on this one,
Art