[Info-vax] Programming languages on VMS

[Stephen Hoffman]

On 2018-02-09 22:49:12 +0000, Jan-Erik Soderholm said:

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

Because it's been my experience that online backups are less than 
transparently restorable, and files captured with /IGNORE=INTERLOCK are 
not guaranteed internal consistency nor are related files necessarily 
captured consistently across other related files.

But I'm really not interested in bringing your site forward, as it's 
very clear you're not interested in that task.

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

No, it's not.   It's only different because there's been effectively 
zero thought given to this whole area and there's been a pile of 
disparate pieces patched and otherwise taped together over the decades.

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

That's because you haven't used the tools that others have.  Which in 
various cases involves little more than "here's the target device or 
target server for backups, have at" and the backups then defaulting to 
and taking care of everything else, including frequency and pruning 
among other details.

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

Can't say I find creating backup scripts and dealing with tapes and 
tape libraries entirely straightforward nor particularly easy, but then 
that's me.   In comparison with the complexity of OpenVMS, the 
capabilities and the simplicity of Time Machine was a pleasant 
surprise, for instance.

> *I* think that you are often exaggerating that OpenVMS is that far 
> behind in many areas.

What I mention is already available and already in use.   Servers and 
enterprise gear does commonly tend to trail what's available, and for 
various reasons.  But expectations can and do shift.

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

Have you considered how you yourself and your systems fit into that?  
Have you pondered how you'd replace your entire system from within and 
incrementally, and how you'd work to get there?

Expectations and experience here differs, too.   Some folks only know 
OpenVMS and Windows.   Some folks and some apps are cruising into 
retirement.  Some folks and some apps have effectively retired in 
place.  Other folks and other apps...  are headed to other platforms 
and tools.   As is typical.   OpenVMS needs to attract enough new folks 
and new apps to offset the inevitable losses.  What we have now with 
OpenVMS is not all that and a bag of chips.

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

Microsoft is a good source of ideas, some to emulate and some to avoid. 
  They're also very far from the only source of ideas in this business, 
good and bad.   OpenVMS is never going to directly complete with 
Windows nor replace Windows Server, and OpenVMS will have to coexist 
with for the foreseeable future, and preferably far better than it does 
now with features added such as with support for current SMB clients 
and servers, and far better Active Directory integration.   It'd be 
handy to have a way to write backups to SMB shares and to allow those 
same backups to be restored and reused without the current rigamarole 
usually required, too.




-- 
Pure Personal Opinion | HoffmanLabs LLC