[Info-vax] Programming languages on VMS

[Jan-Erik Soderholm]

Den 2018-02-09 kl. 22:47, skrev 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,...

Why would it not be "restorable"? Yes, we have some fairly static data
still in RMS files (shouold be moved into Rdb). This is of course highly
site specific and each environment has to evaluate the possible risks
in getting some files that are "out of sync". It is all about risk
analysing.

 > though
 > your use of Rdb likely makes that situation rather better than what some
 > other folks can encounter with similar strategy.)

Right. I see backup/restore of the file system, and backup/restore of the/a
database as two separate entities. The backup of Rdb through RMU/BACKUP
and RMU/RESTORE (including handling of AIJ journaling files) is quite
different from regular backups of your file system.

 >> 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.
 >

OK, right. If you think that giving the system *one* command to restore
what has been deleted by accident, as "a whole lot of work". Fine. Hard
to argue there... :-)

 >
 >>> 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...

I do not understand what you are saying here. Uncoordinated? All files
are considered equal by the backup process. Doesn't matter if they have
different file names or just different versions.

 >> 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,...

Not sure how you define "work" here. Work by me or by the system?
There is one script running each night doing the backups. This has been
running with some minor changes since 2010 (when we switched from local
tape station with weekly manual tape changes) to:

$ abc
Archive Backup Client for TSM on OpenVMS, Version V4.2.0.9
Copyright 1996-2010, Storage Solutions Specialists, Inc.

ABC>
$

I couldn't be less work than that.

 > though the lack of a GUI system management
 > interface on OpenVMS makes the whole mess more work.

Since there is close to none work to do, I do not see the lack of a
GUI as a major issue. And besides, if there is an issue and I would
have fix something (even over the console), I'm just happy that I am
*not* forced into using some GUI.

 > You're fond of citing existing and comparatively old designs and older
 > approaches, and you have seemingly worked to avoid upgrades and changes.

Running OpenVMS V8.4-2L2 from VSI at the moment. But yes, we do not
upgrade just for the sake of doing an upgrade. Ths time (last summer)
it was from 8.2...

 > 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,

All other platforms, not only VMS, at this site uses the IBM Tivoli
TSM backup platform. Maybe they have some GUI support on other client
platforms. Maybe that is because the lack of a function and working
CLI environment. I don’t know. All I know is that this works just fine.

 > 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.
 >

Thanks. Actually, sometimes I find "our" (the small VMS group) platform
to have *less* issues with adopting to new requirements. As an example,
there is a new server running for a specific task that has its interfaces
implemented as http REST calls. We have a working solution (based on the
"requests" module in Python) while other "modern" ERP systems struggles
to find a way to talk to this server.

*I* think that you are often exaggerating that OpenVMS is that far behind
in many areas. The *main*, as I see it, problem is that many of those
working with OpenVMS have let *themselves* falling behind when it comes
to what is happening in the IT business. Such as believing that Windows
(and its supplier) is some kind of “enemy”, that only adds to the view
that VMS (and in particular those who works with it) are fossils.