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

[Stephen Hoffman]

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