[Info-vax] Programming languages on VMS

[Stephen Hoffman]

On 2018-02-09 17:19:12 +0000, Jan-Erik Soderholm said:

> Den 2018-02-09 kl. 17:58, skrev Stephen Hoffman:
>> On 2018-02-09 15:59:57 +0000, Jan-Erik Soderholm said:
>> 
>>>  do not see "backup" and "file versioning" as two features/tools that 
>>> replaces one of the other. They are complements.
>> 
>> They are the same, differing only in the associated temporality of the 
>> copies; in how long you might choose to retain the particular copies of 
>> files.  BACKUP backups too are routinely thinned, with daily backups 
>> being more frequent and of which some are then maintained as weekly and 
>> then as monthly and then as yearly, for instance.
> 
> Our backups are done daily (each night). Each run is "incremental" (the 
> only mode recomended), but the actuall backup is always a complete copy 
> of the disks. A full restore will always restore an exact copy of the 
> disk as it looked like at the time the last backup was run.

So?  (Ignoring that you're probably not getting a restorable backup, 
though your use of Rdb likely makes that situation rather better than 
what some other folks can encounter with similar strategy.)   As for 
other approaches, I'm routinely capturing hourly backups on the other 
systems I deal with, automatically culled over time, and with a setup 
and configuration time that's measured in minutes.  That works for 
those systems, though there are still cases where folks require weekly 
or monthly captures of the backups, or other changes.  OpenVMS 
unfortunately doesn't have any opinion here, tossing the end user into 
a "figure it out yourself" situation with the BACKUP command and file 
versions and the rest of what's involved in capturing online with 
/IGNORE=INTERLOCK and its potential for corruptions, or offline with 
its disruptions, or database-integrated and consistent but with no 
platform integration and no coordination with the platform tools.

This all reminds me of the Macro32 discussion.  Wonderful VAX 
assembler.   Which is an exceptionally flexible and capable programming 
tool.  But it's also involved and error prone and time-consuming to 
use, and requires more than a little expertise.   And in a computing 
environment where many of those requirements are all becoming more 
expensive.   Where we need to automate more and more of what we're 
doing, and where we'd each prefer not to have to re-implement our 
automation.   Where we'd prefer better abstractions.   But I digress.

> 
>> Few keep daily backups for months or years, and those that do that also 
>> try to reduce that data by using incrementals and deltas and 
>> compression to reduce the volume of data.   Most folks treat file 
>> versions as little more than very transient backups...
> 
> File versions are not "backup" at all. If some uses file versions as 
> "backup", so be it. But they are not.

Yes, they are.  They're very much transient, but they're commonly used 
for recovery.  Recovery is a form of backup.   In short, versions are 
backups.

>> ...and of the effort that is involved with accessing and restoring 
>> backups on OpenVMS.
>> 
> 
> Not much effort.
> 
> To check for a file in the backup:
> 
> $ abc show backup <file spec> (add /state=inactive for deleted files)
> 
> To restore some file:
> 
> $ abc restore <file spec> (add output dir and file, if needed).
> 
> Both are subsecond operations for small files. And fully file version aware.

That's a whole lot of effort, as compared with other implementations.  
Better than loading tapes, but still a whole lot of work.


>> Sure, given file versions and the morass that is accessing files from 
>> backups on OpenVMS, versions are great.  But that's less about what can 
>> and should be, and more about contending with what is and what was.
> 
> Again, file versions are not a "backup". They are just a nice-to-have 
> that helps in the everyday work.

They are backups.   Versions are transient backups.  If they're not 
backups, then why do they even exist?   File versions are unfortunately 
uncoordinated with system backups and with the associated tools, which 
is a whole 'nother part of this discussion.

> And accessing files in the backup is just a simple command, see above.

Better than many, but still rather hideous compared with what's 
available on some other platforms.

> And to "archive" some data besides of the backups (not checked against 
> the live files in the nightly backup), there is the $ ABC ARCHIVE 
> command. Those files has to be specificaly removed from the bacup 
> server using the $ ABC DELETE ARCHIVE <file spec> command.

Your design is better than some.  It's also capturing copies rather 
less frequent than many folks are backing up their systems.  It's also 
more work than is becoming common, though the lack of a GUI system 
management interface on OpenVMS makes the whole mess more work.

You're fond of citing existing and comparatively old designs and older 
approaches, and you have seemingly worked to avoid upgrades and 
changes.   Your approach does work.  Your configuration is your 
prerogative.   What APIs and software and designs you are using here, 
however, is not going to attract a whole lot of new users, new ISVs and 
new apps.  That's not really your problem, of course.   You just need 
to keep a your legacy apps working and acceptable to your installed 
base.    If new development team had to start over again seeking to 
address what your app does for your installed base, it almost certainly 
would not be anything similar to what is in use here, too.   That's not 
your issue, of course.   In the short term, legacy apps such as yours 
are the future of VSI.  In the medium and longer term however, it's new 
ISVs and new apps, as the existing apps and existing developers 
inevitably age out.  That means better and easier backups, easier 
management, better automation, far better security, and other and 
larger issues such as rethinking what file versions and backups all fit 
together; making OpenVMS easier to use, to program and to manage.   I 
don't expect that from you.  None of this is intended as a slight 
against your skills and your situation and your apps and your preferred 
tools, either.


-- 
Pure Personal Opinion | HoffmanLabs LLC