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

[Stephen Hoffman]

On 2018-05-29 02:45:03 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Stephen
>> Hoffman via Info-vax
>> Sent: May 28, 2018 12:42 AM
>> To: info-vax at rbnsn.com
>> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
>> Subject: Re: [Info-vax] The best VMS features, was: Re: openvms renaming file
>> 
>> 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.
>> 
> 
> You forget to note the multi-site clustering features that HBVS 
> provides. Developers do not need to know or code anything in their App 
> code with respect to replication and odd things like "eventual 
> consistency".

For specific configurations and requirements, definitely.   For many 
other common configurations, no.

HBVS is one of the few remaining competitive features in the platform, 
though the applicability is becoming narrower due both to hardware 
RAID, and due to the inherent and inefficient behaviors of HBVS RAID-1. 
 And due to differences in the requirements for consistency and 
availability.  And differences in what's acceptable for disaster 
recovery.

Clustering can be much less transparent than many experienced OpenVMS 
users might realize.  I've become quite familiar with many of the 
problems that new-to-OpenVMS developers encounter with clustering and 
HBVS.  Or with those that even experienced OpenVMS folks encounter, 
when they're not in some dusty corner case sufficiently frequently to 
remember the details.   And the configuration and management of 
clustering is weak and arcane.   Managing the disks and volumes — that 
whether standalone or clustered — is absurdly manual, too.  Distributed 
authentication.  And I'm working with apps that just aren't ever going 
to be cluster-compatible; not without significant efforts toward 
refactoring or redesign.


>> 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.
> 
> Customers do not want platform specific job management.  They want 
> commercial job schedulers that are multi-platform and have the same 
> look-n-feel across platforms.

VSI isn't big enough to roll their own, which likely means integrating 
with open source.

But that many of us are using the batch queues for job management 
should be a clear indication there are weaknesses lurking.


>>>> 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.
>> 
> 
> One can always pick apart any feature when not used properly. Most 
> OpenVMS environments today use logical names extensively. They are 
> planned to be used in ways that are specific to the needs of each 
> environment.

I'm not sure that there can be a way to properly use logical names as a 
configuration mechanism.   There are various ways to survive that 
usage, certainly.

But even a properly-implemented approach toward using logical names for 
configuration data — and I'm very skeptical that such an approach even 
exists — is mess in comparison to what's become available elsewhere.

>>>> decent HELP and other documentation,
> 
> As I recall, many of the OpenVMS Help doc's are being re-written and/or 
> updated with an SDML tool, so a work in progress.

Porting out of DEC Document and over to DocBook is very necessary.

The DocBook port does little for the issues cited around navigation and 
access, nor about examples or otherwise.

The OpenVMS documentation contents, information architecture and 
tooling are all showing their age.

VSI will be working on that.

>> 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.
> 
> No one will argue this, but that is why the new file system VAFS is in 
> development.

As essential as it is, VAFS is ~twenty years late.  The design is not 
targeting current-generation storage.  It's also not a database.  It's 
very necessary.  But it's very far from a differentiator.

> DEC should never have sold of Rdb (or arguable any of the Polycenter 
> Mgmt. products to CA - which included DECscheduler btw), but DEC was 
> slimming down getting ready for merger with Compaq, so everything else 
> was not a priority.

I'm ambivalent around the sale of Rdb.  That was yet another 
comparatively large development effort that was specific to OpenVMS.  
Running a competitive database is not a small investment for a vendor.

Downside of the Rdb sale is that even more of the OpenVMS customers are 
now tied as much to Oracle — for Rdb or for classic — than to OpenVMS.

But that's all in the past, which means VSI needs Oracle to port its databases.

Though as you stated around job management, customers are also 
interested in cross-platform.   Which is Oracle for some.  For folks on 
other platforms that might be looking at OpenVMS in the future, they'll 
be looking at Oracle and at various open-source options including 
PostgreSQL.

> The new IP stack is due later this year according to the roadmap.

It's still not integrated.



-- 
Pure Personal Opinion | HoffmanLabs LLC