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

[Kerry Main]

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

Also, being able to shadow across two SAN's is a nice feature for those
config's that need really high HA (every SAN usually has a number of
SPOF scenarios that can take out the entire SAN)

Most HA config's I have seen on mission critical environments will use
both HW RAID and HBVS. There are cases for both. As an example, use HW
RAID for system disks, HW RAID for user disks and then HBVS across SAN's
(locally or remote). This way if a drive fails, the impact of rebuilding
a new volume is only at the SAN level and not across the FC HBA's and
the host servers.

> >> clustering,
> >
> > Yes (big time)
> 
> There's a whole lot of work necessary here.
> 
> On OpenVMS, I'd suspect that the pricing killed clustering.
> 

Agree - OpenVMS's biggest strength was priced astronomically. Given the
long history of OpenVMS stability, it was hard to justify paying huge
$'s for minimal benefit when the servers / OS were so reliable. 

Same thing goes for VAX's btw. Some Cust's would laugh when you tried to
get them to cluster their VAX's for "availability" reasons.

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

A good example of a multi-platform job scheduler that includes OpenVMS:
https://www.enterpriseschedule.com/EnterpriseSCHEDULE/index.html>

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

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.

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

[snip..]
> 
> >> 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.
> 

Ask any OpenVMS Customer what 100 things need to be fixed on OpenVMS
(with 1 being highest priority) and DCL would be about 98 on the
priority list.

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

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

Other than if there is a critical bug that emerges, no one is saying
DECnet is going to get any future development resources. Having stated
this, some Customers still use DECnet in very critical environments
because it works. In addition, these are often air gapped environments
with firewalls and even network ACL's to mitigate any security risks. 

Personally, I like the idea of a second network stack on a critical
server for remote access in case the OS TCPIP stack gets hosed or
misconfigured for whatever reason.

The new IP stack is due later this year according to the roadmap. Keep
in  mind that this "new" stack is based on Multinet which is reasonably
current with most TCPIP standards today - including security features
like IPSEC (Richard should like this). Of course, one should expect
there will be more work to do even after its initial release.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com