[Info-vax] The best VMS features, was: Re: openvms renaming file

[Jim Johnson]

On Sunday, May 27, 2018 at 9:41:37 PM UTC-7, Stephen Hoffman wrote:
> On 2018-05-27 23:32:18 +0000, Simon Clubley said:
> 
> > On 2018-05-27, Phillip Helbig (undress to reply) 
> > <helbig at asclothestro.multivax.de> wrote:
> >> 
> >> Certainly in the top-ten list of most useful VMS features.  Off the top 
> >> of my head, others would be:
> >> HBVS,
> > 
> > Yes
> 
> Sort of.  For specific configurations and requirements, definitely.   
> For many other common configurations, no.   Outside of multiple paths 
> across multiple hosts, hardware RAID solved what HBVS provides long 
> ago.  HBVS is simple and synchronous and inefficient approach toward 
> replication.   For single-path access, file shares and hardware RAID 
> all work fine, and various of those configurations can be replicated.  
> Which reduces the cases and the configurations that really want and 
> need HBVS.  Other platforms replicate data differently.  And some apps 
> want or need asynch replication.  Or want to avoid the overhead of 
> whole-disk replication.  Or the overhead of synchronous write-thru I/O, 
>  whether due to geographic latencies or otherwise.
> 
> >> clustering,
> > 
> > Yes (big time)
> 
> There's a whole lot of work necessary here.
> 
> On OpenVMS, I'd suspect that the pricing killed clustering.
> 
> An integrated DLM is handy, but clustering and its APIs and management 
> and integration is far too firmly stuck in the 1990s.  No job 
> management.  No LDAP integration past authentication.
> 
> On other platforms, there are add-on packages that provide distributed 
> coordination, file shares, replication, backups and other features.  
> Which reduces the numbers of combinations where clustering really still 
> shines.
> 
> >> logical names,
> > 
> > Yes
> 
> Logical names?  Definitely not.  Logical names are a disaster, in most 
> of the ways that they're commonly used.   There are better ways to do 
> most or all of what logical names are used for, too.  Just not as 
> easily on OpenVMS, unfortunately.   They're complete dreck when used 
> for app settings, flags and related configuration data.
> 
> I used to think that logical names were pretty handy.  Then I started 
> working with property lists (YAML or otherwise) and with settings that 
> were integrated into the image activator, and with file links.  Vastly 
> preferable, far more capable, and lacking the out-of-band and 
> collision-avoidance-by-convention issues of logical names.   All of 
> which OpenVMS lacks.
> 
> >> decent HELP and other documentation,
> > 
> > The HELP command on VMS is utterly useless unless you already know 
> > exactly what you are looking for and don't need to navigate between 
> > topics.
> 
> The HELP tool is utterly archaic on OpenVMS, and the documentation 
> lacks navigation, recipes, example code, IDE integration and related 
> APIs, and the ability to be kept cached and updated.  More than a 
> little of what's documented is stale, too.
> 
> For a third-party tool for another platform...
> https://kapeli.com/dash
> https://itunes.apple.com/us/app/dash-offline-api-docs/id1239167694?mt=8
> 
> IDEs are up in this same range for documentation access, example code 
> and related materials, too.
> 
> >> fine-grained privileges,
> > 
> > They are ok, but it's still DAC security instead of MAC security.
> > 
> > They would also be more effective if VMS was a 4-mode operating system 
> > instead of just being a 2-mode operating system with one of the modes 
> > split across 3 hardware modes.
> 
> I don't see particular benefits of the forest of privileges.   Other 
> than the morass of the NOPRIV error.   Few (no?) folks are managing 
> servers that way, either.   We're past the era of timesharing and 
> semi-privileged users.  Privileges don't work even remotely well for 
> installed images or for app isolation, either.  Privileges aren't 
> particularly tied to the access modes, beyond the memory management 
> controls being the foundation for all security.
> 
> >> EDT,
> > 
> > You are kidding, right ?
> 
> For most folks, pico or nano would be preferable to EDT.   vim or emacs 
> or a WYSIWYG editor for others.  Or an IDE.   DEC deprecated EDT a 
> quarter-century ago.
> 
> >> lexical functions,
> > 
> > Lexical functions are a good idea but limited. It would be nice if it 
> > were possible for a site to create a library of site specific lexicals 
> > that could be used in site specific code.
> > 
> > Maybe after VSI fixes everything else that is wrong with DCL.
> 
> Lexical functions are what you get when your command output can't be 
> processed directly as text, nor as objects.
> 
> >> Rdb (almost a part of VMS),
> > 
> > It would have been nice to have a proper database instead of the RMS 
> > implemention of indexed files (which have _not_ aged well) as a 
> > guaranteed part of VMS and which _any_ application could use.
> 
> SQLite minimally, preferably also with PostgreSQL and MariaDB around.   
> The Oracle databases available for purchase, for those folks that want 
> or need those.
> 
> >> DECnet (almost a part of VMS).
> > 
> > Maybe in the 1980s. Totally unsuitable for any modern network.
> 
> DECnet is dead.   For various reasons.  Not the least of which is 
> security.  VSI will probably be integrating IP into OpenVMS akin to 
> what's been done on other platforms, but much of that work will happen 
> some years into the future.
> 
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Setting aside the active discussions on bundled relational databases ...

VMS clustering has a feature that I'd argue is still state of the art - its handling of state during rolling upgrade.  The actual state handling is mostly an internal detail, and mostly uses schema patterns that are now well known (existing field definitions are invariant, expand and then shrink across versions).  And VMS has a very clear idea of a basement version, to support schema and data cleanup.  However, it is the fact that it is not purely primary-secondary at the node level that really helps - it means that rolling upgrades and downgrades happen on a millisecond by millisecond basis, which make them uniquely testable (again, in my experience).  I'm certain that helped the upgrades be as stable as they were, at least in the early days.

Beyond that, comparisons for clustering, in whole and in parts, suffers from the design trends that disagree with where the functionality best belongs.  Cluster features at the OS level fit when the applications, their interactions, and their nodes all matched with high fidelity.  If they don't, then splitting features, like DLM, out from the OS makes sense.  As time has gone on we've seen more and more of that happen - external coordination services rather than an OS service, external replication services rather than OS volume shadowing, TM services rather than an integral OS service.  And, freed of the node tie in, which forced support for a mixed pool of applications, there's been a tendency towards simplicity, both of those services and the application structures.

Weirdly, containerization may start to restore the application<->node pairing, but I don't think we'll see much deep integration again, unless there is some truly amazing benefit.


I'd also say that there's _a_ feature of logical names that I miss to this day - the construction of searchlists.  I agree that a lot of the other uses are better served with more recent application configuration models.  But the ability for me to decide to take a directory tree and preface it with a writable level for exactly my use at this moment is a great feature.

Fwiw,
Jim.