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

[Stephen Hoffman]

On 2019-05-09 22:54:06 +0000, rsgoodin at gmail.com said:

> Has anyone successfully restored these files? What the heck am I doing wrong?

You're running into the same sorts of problems that most everybody else 
has run into with OpenVMS.

OpenVMS lacks basic and common tools, and that even on releases far 
newer than what you're working with here.

OpenVMS RMS file metadata gets stripped off by common network file 
transfer operations, and by storing RMS files even briefly on other 
operating systems.

Get a copy of the unzip executable for OpenVMS VAX from the Process 
Software http://process.com OpenVMS resources, or from the OpenVMS 
Freeware distributions.

Maybe download the Freeware disk images and use those to generate disk 
images containing the Freeware, and mount those in OpenVMS VAX on SIMH.

Why the Freeware? The Freeware distributions contain a 000TOOLS 
directory area with the tools you'll need here.

Or download unzip for OpenVMS VAX from the Process archives, or from elsewhere.

Once you have that unzip tool loaded, unzip the saveset ON OpenVMS, and 
the unzip tool *should* have the correct metadata.

Why?  Most OpenVMS-related savesets are created with the "-V" switch 
used to preserve the RMS metadata.

Yes, you have to double-quote the "-V" option when you use that switch 
with zip, too.  Or select extended parsing.

BACKUP itself is dependent on that RMS metadata.

If the saveset doesn't end up with the correct RMS metadata attributes 
after the unzip command—if the archive wasn't created with the "-V" 
metadata-preserving switch—then use the 
RESET_BACKUP_SAVESET_ATTRIBUTES.COM tool also found in the 000TOOLS 
directory on the Freeware.

OpenVMS sort-of fixed that second RMS metadata issue with V8.4 or so, 
with the BACKUP /REPAIR qualifier and a separate invocation to correct 
the metadata.

But BACKUP itself can't automatically deal with this for reasons.

With the path you're on, the saveset may well be corrupted, as some FTP 
transfers can hose the saveset itself.

But sometimes the RESET_BACKUP_SAVESET_ATTRIBUTES.COM tool works there, too.

> How did you do this?

Same way everybody else did. By making the same mistakes everybody else 
does, and then by rummaging around for previous discussions of these 
and other common problems, and by asking questions.

And by learning that OpenVMS itself prefers to preserve old choices and 
old mistakes and old limits, and the inevitable trade-offs here 
variously also at the expense of new development and new users and new 
updates.

Hopefully VSI changes the long-standing course here, and starts 
incorporating common tools in the VSI OpenVMS releases.

But the candidate VSI OpenVMS releases here are a while into the future 
as yet, and these and other changes likely won't ever involve VAX.

Fixing BACKUP will probably best be done with a wholesale replacement 
for what BACKUP provides, as the present BACKUP I/O design is close to 
the theoretical performance limits, so spending a great deal of effort 
updating BACKUP could seem unwise.

ps: unzip can directly unzip zip archives with the self-extracting 
unzip prefix tool whether for the current or any other architecture.  
This can be handy if you need to poke into an archive with a 
self-extracting unzip for another platform.

pps: welcome (back) to OpenVMS.

-- 
Pure Personal Opinion | HoffmanLabs LLC