[Info-vax] STARTREK.BCK Restore - How?

[Stephen Hoffman]

On 2019-06-12 09:08:44 +0000, Tom Wade said:

> On 2019-05-11 19:32, Stephen Hoffman wrote:
> 
>> Packaging the files directly into the zip archive removes an 
>> unnecessary nested unpacking operation of the BACKUP saveset,
>> ...and also allows search engines to index the zip archive contents,
>> ...and allows folks on other platforms a way to access the zip archive 
>> contents without having to figure out how to unpack a saveset.
>> 
> On the other hand, packing the individual files into a ZIP archive 
> means you now have to worry about the preservation of file attributes 
> of all the files, rather than a single one. If the ZIP archive hasn't 
> been created correctly, it could result in a particular file (indexed 
> sequential?) being hosed.  At least with a saveset, you know pretty 
> quickly if it's bad, and if it is OK, I trust Backup to have the files 
> stored correctly. Backup itself can also recover if the archive has 
> been poorly created, whereas finding and fixing individual files is a 
> lot trickier.

At the cost of thwarting indexing for search engines and thwarting 
anybody trying to unpack the file elsewhere, sure.

I trust zip and unzip as much as I trust BACKUP, in this era.  And I 
trust zip and unzip to allow the files to traverse other systems.  I 
don't trust BACKUP to do that.  Not without having to coach an 
inexperienced user around the corruptions.

And the root cause of my annoyance here is that BACKUP is still unable 
to transparently deal with the world that we're all in.

Alas, BACKUP fundamentally fails at being able to toss files around 
without extra tooling or without BACKUP /REPAIR, and—much like 
developers and glue code—experienced OpenVMS folks just don't see it.

As for zip and unzip...  When you use zip "-V" to pack the files, all 
of the files get the metadata saved.  So there's no extra effort there.

And I've seen issues with the BACKUP command syntax.  I know the 
command well and have used it for far too many years, and routinely 
look up some of the sequences.

As for potential corruptions of zip archive and potential corruptions 
of BACKUP savesets, or of other files, ponder too how many isolated 
file corruptions you've encountered in recent years.  This outside of 
catastrophic storage failures or ilk.  Even with tape storage and with 
network transfers, those corruptions are far less common than they once 
were.   If you're concerned about these—and some number of hard errors 
per terabyte is probably to be expected—protecting all files and not 
just archives is usually the best course.  Which usually means adding 
storage redundancy of some sort.  Not just within the BACKUP itself, 
but adding a second set of BACKUPs and separately stored.  Etc.  But 
that's not common when tossing around kit files and source 
distributions such as STARTREK.BCK and such.  Which would work far 
better if it were zipped with zip "-V".

We're well headed into a world of replicated data, too.  Increasingly 
with file copies all over the place,  I still think a torrent would be 
a good software distribution mechanism, but then that has been too 
radical for some folks. But I digress.

> Also, if you're shipping VMSINSTAL kits (please, lets not get into PCSI 
> vs VMSINSTAL) you need Backup savesets.

Yet I've encountered BACKUP savesets of those VMSINSTAL kits, and the 
folks mess up that omnibus BACKUP during the transfer.  Or they get it 
right and zip "-V" the omnibus BACKUP.  Which gets a zip of a backup of 
backups of files.  Which is part of what I grumble about.  Just use zip 
"-V" on the whole thing, rather than interposing BACKUP.  And if the 
transfer is corrupted, fetch a new copy, or generate a new copy and 
transfer that.

>> I've occasionally wondered whether making "-V" the default on OpenVMS 
>> would be worth the hassles that'd cause, too.
> 
> Yes, I agree, but it should be /VMS not "-V".  I find it constantly 
> irritating that programs are 'ported' onto VMS without providing decent 
> DCL parsing, and forcing us to use Unix style 
> single-character-hieroglyphics for arguments.

Why should I bother learning a second and platform-specific syntax for 
a common tool?

This same debate arose with the TCP/IP Services tools.  Where the folks 
that wanted to avoid learning the ubiquitous syntax had OpenVMS syntax. 
 So there were and remain parallel command implementations akin to what 
zip and unzip provide.

If you want to remember more letters with the existing zip and unzip 
tools, you can use --VMS-portable in place of -V.  Works fine.  Long 
switch names have been common for many years, too.

The reason why more tools don't have OpenVMS command syntax shouldn't 
be lost on anybody, though.  Slogging through writing and supporting an 
OpenVMS command parser is extra work.  That whole OpenVMS CLI parsing 
API could be made far simpler, too.  And I know well how to use it.  
Preferably with an implementation that provides both switch and 
qualifier parsing, so that more folks trying to be nice to the OpenVMS 
folks don't have to spend extra effort maintaining parallel 
implementations.

(zip and unzip drag around their own getopt_long() too, as OpenVMS 
lacks that.  Maybe some future getopt_long can also provide 
/VMS_Portable or some such, too.)





-- 
Pure Personal Opinion | HoffmanLabs LLC