[Info-vax] fixing a saveset's attributes: attachment, not ftp

[Stephen Hoffman]

On 2015-06-23 04:32:55 +0000, David Froble said:

> I would agree that it's rather trivial to get the blocksize from the 
> saveset.  The record format might be a bit more of a problem.  After 
> all, it is VMS, which has file attributes as a standard feature, and 
> it's not expecting too much for BACKUP to need a few things "right".

FWIW, BACKUP does have integrity checks on the savesets.   It runs 
those checks after we whack the saveset settings, and re-feed the 
saveset into BACKUP.   As should be obvious, my preference here would 
be to not have to manually whack the settings.  Just do the right thing 
with the saveset.

I've become quite fond of mapping entire files into memory.   Of 
avoiding the punched card I/O emulation, where I can.  For tasks 
involving blobs of data smaller than the current virtual memory limits, 
it's speedy, simple and surprisingly effective.   The resulting source 
code is often much simpler and clearer, too.  For more than the current 
virtual memory limit, I've found that entirely isolating the sliding 
window mapping calls or the RMS calls into unmarshalling and 
marshalling routines, and then dealing with the data entirely apart 
from the mapping routines or the RMS calls is often appropriate.   That 
separation can also let me swap out the mapping calls or RMS calls for 
database calls, too.

Now mapping an entire saveset might not work well as these files can 
potentially exceed the available virtual memory, but mapping the first 
sector or three of the saveset and accessing what should be the BACKUP 
saveset data structures for a "look around" is trivial.  The downside 
is that BACKUP is probably lodged in the punched-card era — that's 
certainly easy to infer from the introduction of BACKUP /REPAIR, rather 
than an actual and transparent and just-does-what-you-expect fix.

As for more substantive changes to OpenVMS...

There are more general issues elsewhere with the current BACKUP design. 
  Not the least of which is unified, reliable online data backups; what 
some folks erroneously believe /IGNORE=INTERLOCK does.  VSI will 
probably eventually have some roadmap items and quite possibly some 
wholesale replacement software planned.

Then there's integrating newer data storage and approaches for 
accessing data past the punched card emulation that RMS provides.

OO frameworks make this much easier, as they just present you an object 
that's all of the file data, and you don't have to deal with getting 
punched cards, err, file records from or to storage.  Just the 
in-memory data and data structures.  The framework deals with these 
transfers and with unmarshalling and marshalling the data.  This 
analogous to how many readers here moved to RMS to avoid dealing with 
what RMS provides for us, and how various folks have moved from RMS to 
(for instance) relational databases.


-- 
Pure Personal Opinion | HoffmanLabs LLC