[Info-vax] OpenVMS (was: Re: DCL enhancements)

[Stephen Hoffman]

On 2021-01-26 14:07:33 +0000, Jon Pinkley said:

> On Monday, January 25, 2021 at 12:05:38 PM UTC-5, Stephen Hoffman wrote:
>> On 2021-01-25 13:40:25 +0000, Phillip Helbig (undress to reply said:
>> 
>>> What about some easy-to-implement DCL enhancements?
>>> 
>>> With PURGE/CONFIRM, there is Y, N, and A. Why not R, for "rest", which 
>>> would be A but only for the current file name and extension, then it 
>>> would ask again for the next one?
>> 
>> Or set the default version limit to one on all volumes newly 
>> initialized, maybe fix the inexplicable SYS$SCRATCH default of 
>> SYS$LOGIN, and force the user to enable and accept the costs and messes 
>> of multiple versions manually.
> 
> Hoff, I am tempted to ask if there is anything about VMS you do like.

Yes. There is.

Yes, OpenVMS is worth the effort, which is why there are specific 
comments and suggestions made here. Otherwise, why bother with the 
feedback?

With previous millennium expectations and then-contemporaneous apps, 
OpenVMS does quite well. For folks being familiar with various 2021-era 
platforms and tooling, OpenVMS needs help. It is showing its age.

Of what exists now and that works well?

Distributed software RAID-1 (known unfortunate acronym HBVS), and 
clustering, and a few other bits. A discussion of the value of and 
relative rarity of an integrated parser arose elsewhere recently. And 
of the doc for same.

The OpenVMS compilers are roughly average now, options for integrating 
with development tooling are poor, and standards support is lacking, 
but what's present is robust. VSI is working toward compiler updates 
and toward replacement.

What works less well with OpenVMS?

Networking and security all need help. What exists now is solid, though 
security is designed for 1980s-era risks and poorly documented, newer 
bits are either grafted-on, or stale, or variously both; see CDSA, 
certificates, ~all of IP networking.

While still workable and reliable, RMS and the XQP are showing their 
age (2 TiB, HDD-focused, encryption, etc), as are the related API 
designs, as is the OpenVMS calling standard, and many other details.

Calling standard? There are echos of the OpenVMS calling standard in 
some newer competing platforms too, and those platforms have developed 
this area well past OpenVMS here. q.v. Microsoft. What's there within 
OpenVMS is good. For newer apps and for overhauls, better is needed.

What works not well at all with OpenVMS?

The OpenVMS development and OpenVMS end-user fondness for complete 
compatibility over all other app considerations is a problem and a 
liability.

As an end user, forever-upward-compatibility is great, right up until 
realization of the end-user costs for the associated the messes, the 
complexity, the API chaos. And variously, decisions to deploy 
else-platform. All of which falls out of that particular prioritization.

Where to, with OpenVMS?

In 2021, there's little that would attract me to OpenVMS for a 
wholly-new deployment, outside of a few specific areas and cases; 
outside of existing apps, etc. And that's somewhat problematic for 
platform longevity.

In 2026 or 2031, the possibility of a substantial refurbishment making 
OpenVMS far more interesting exists, though that'll mean stepping away 
from some longstanding approaches and limits and designs. Breaking 
changes. Of selectively breaking and fixing some of the most 
problematic parts of OpenVMS, and which'll require some apps to migrate 
to newer changes over (say) a five or ten year transition. VSI doesn't 
have the resources to create a wholly new deployment either, so 
incremental refurbishment would be necessary.

> And setting the version to one is really an autopurge, it still creates 
> new version numbers that will eventually get to ;32767 and then 
> possibly cause problems.  The point is ODS is not NTFS or some 
> unix/linux versionless file system.  And there are many vms 
> applications that rely on versions.

Yep. But that ;32767 mess arises either way; with versions shut off and 
limits set to one, or with versions enabled, within the current file 
system. Reportedly to eventually become the ;65535 mess per some boot 
camp comments, too.

There are other systems with the ability to rollback to previous 
versions of the contents—which is the fundamental reason for the 
ODS-2/ODS-5 file version scheme, after all—those other designs 
expecting that the user will not want nor need to manage all that. 
Folks do need to revert file versions, but the ODS-2/ODS-5 version 
scheme is not the only approach to that, and ODS-2/ODS-5 approach is 
poorly integrated and manual, and the ODS-2/ODS-5 approach doesn't even 
easily do what folks really want when we're increasingly working across 
more than one file at a time. And recently having had multiple cases 
where a multi-file file reversion is needed, ODS-2/ODS-5 version scheme 
is less than easy to get the matching source code versions across all 
the edits across all the files. git—for all its arcana and its 
problems—does better.

In that intended file-version rollback usage, file versioning is also 
directly related to the frequency of data backups, and variously also 
to app undo commands on those platforms (and databases) that implement 
rolling forward and rolling backwards. Easier and more frequent 
backups—and backups that the end-user can easily restore without 
operator intervention—means less interest in ODS-2/ODS-5 file versions, 
too. Some forty years ago, the trade-offs here differed.

> I agree there are many things that could be done better than the way 
> that  VMS does things.  My pet peeve is how much user involvement is 
> needed for  updating and trying to determine dependencies. windows and 
> linux make that much easier and less error prone.

I'm seeing exactly this case, and in various environments. At various 
sites, I'll (re)create a log-rolling tool to handle the worst of the 
mess. (Which tends to annoy me, as I routinely work on systems that 
deal with this drivel automatically.) And among those sites that do 
have home-grown version and log-rolling management, each site differs. 
SYSTARTUP_VMS, SYSMAN, etc, and it all diverges from there. Which is 
part of what makes writing reliable installers and cross-platform 
tooling that much more interesting. That, or follow tradition and toss 
the mess at the end-user, which I'd really rather not do. Writing 
installers and configuration tools that aren't half-assed—and that 
don't punt work to the installer—is hard. As I've previously grumbled 
about SYSMAN and the lack of kitting integration, too.

OpenVMS is just an immensely manual system to install and configure and 
manage, or reinstall and reconfigure, and the configuration knobs and 
settings can most charitably be referred to as being scattered and 
arcane. Even knowing the knobs, this all takes far too long. And far 
too error prone. I'd much prefer OpenVMS load, ask for the IP details, 
AUTOGEN itself, configure (but not start) all IP services, and just... 
install OpenVMS.

In a better place, most of the questions in the existing OpenVMS 
installer (and various of the product installers) could be removed, as 
most of those are opinion-avoidance; choosing not to decide about 
whether some newer feature or knob should be default. Each choice added 
adds complexity for the default path, too.  (And don't get me started 
about the questions scattered all through the installer. That's 
painful. At least the hardware is faster than it once was. Oh, and this 
all ties into a lack of integrated menuing support, a grumble I've 
mentioned in years passed—everybody gets to roll their own, usually 
stopping at the good-enough stage, as per usual. But I digress. BTW: 
Try using PCSI to install apps on another disk. Fun times, that. But I 
digress. Again.

TL;DR: What do y'all think the point of my having been pointing at 
various areas in recent years, as being areas ripe for overhauls, 
refurbishments, and/or re-thinking? If OpenVMS was worthless, why 
bother suggesting? Why bother with specific suggestions? Whinging of 
what and why is work. Want benign or vacuous feedback? That's easy. 
Find yourself a sycophant. Or worse, find yourself a conference room 
full of sycophants, as some managers learned too late. Whether the 
suggested changes and investments are considered affordable is another 
matter. But little of what I've suggested doesn't already exist 
else-platform.


-- 
Pure Personal Opinion | HoffmanLabs LLC