[Info-vax] OpenVMS Development Annoyances

[Stephen Hoffman]

On 2019-05-06 02:21:08 +0000, Dave Froble said:

I do not find OpenVMS easy to develop for and I do have a passing 
familiarity with same, what with the extra effort and state of the 
development tooling meaning trade-offs around money and/or development 
time and/or features and/or added code.

As for SYSUAF and logical names, I've been working with far better 
approaches than what those provide, and for many years.  And logical 
names are commonly misused for app configuration data.  So... not 
selling it.  Not selling it to me, that is. As was mentioned.

> Just what is so horrible?  If it was hard to use, then I would not like 
> it.  Do I need to post examples to show just how easy it is to use?

The surprise to me here was in seeing how little glue code was needed 
for similar tasks on other platforms, and seeing vendor efforts toward 
reducing even that amount of glue code.  I had habituated to that glue 
code on OpenVMS, too.

On OpenVMS, itemlists shove a whole lot of complexity and overhead of 
the flexible API—and a whole lot of source code glue—into the user 
code, as part of maintaining API compatibility.

As for examples?  I know well how to use itemlists.  I routinely 
encounter and routinely write pages of source code to do a few simple 
system service API calls, too.

And the itemlist APIs can fail at even that upward-compatibility task, 
with fixed-length buffers being ubiquitous.  Which means a two-pass 
call, with added memory allocation and deallocation glue code.

We all always get all of our memory allocation and memory deallocation 
entirely right, too.  I'm not the only one that's ever made mistakes 
here, whether leaks or missing access checks—itemlists are really fun 
across mode changes.  And I know I'm not alone here with these 
mistakes, having fixed various leaks and itemlist parsing written by 
other folks.   It's forty years in and we still don't have a freaking 
itemlist parser-generator?  Ah well, what I'm using elsewhere 
eliminates this mess, and is a whole lot less glue code for callers to 
write.

As for the DLM, it's a wonderful low-level API—discussions of itemlists 
and the rest of the mess aside—but it's far from obvious to new users, 
and it's not as easy to use as it should be for some of the most common 
tasks.

Process management using DLM, for one.  Some better APIs for typical 
usage would be helpful, both to new users and to experienced users.

The DLM doc needs a whole lot of help here, too.

One of the pinnacles of the OpenVMS API design is ACME.  That API can 
do everything.  Downside: that API can do everything, and it's hard to 
use to do simple and common tasks.

One of the most common tasks being password verification.

And ACME callers still routinely embed hard-coded buffers such as that 
for the password hash buffer.

(Why am I even dealing with the blasted password hash buffer?  Whole 
'nother question, that one.)

> Usable from Basic?

Spent many years in BASIC.  It works well, but it really needs to be 
dragged forward a couple of decades in terms of features and 
capabilities.  The last notable changes to BASIC were in the last 
millennium.  UTF-8 has been mentioned before, as have other extensions. 
 OO is a good fit here, too.

> Logicals are great, if used appropriately.

Logical names are a limited and volatile key value store—discussions of 
itemlists and the rest of the mess aside—and are routinely one of the 
most misused APIs on the platform.

> OO is overrated ....

On various other platforms, OO is what the OpenVMS-style calling 
standard looks like now.

> Primitive?  If [BACKUP] "just working" is primitive, then I'm all for 
> primitive.   It's also "just there".
...
> Available, yes.  Part of the base OS distribution?  Not that I'm aware 
> of.  I'm still unable to copy a WEENDOZE system disk.

macOS completely blows away BACKUP.    Utterly.  Completely.   You can 
boot the equivalent of Standalone BACKUP directly from firmware and 
remotely over the internet, and access and download an installation kit 
remotely over the internet, and install it.

The analog to Standalone BACKUP contains tools to back up, to recover, 
to initialize disk volumes and to restore a local copy of the system 
environment from a network-attached storage server.

Among other options.  And the backup tools can restore a complete 
backup to a different system, and the backup tools can also restore 
(just) the user files to a newly-generated installation.

What Microsoft offers with Windows, I'm not familiar.  If you're 
pondering copying an install to a different system, that once commonly 
ran afoul of Microsoft licensing, but it's been a while since I've 
dealt with Windows at this level.  And as I've stated before, comparing 
against a bad option might look good to a marketeer, but it's a poor 
choice as the foundation for an end-user feature discussion, or as the 
foundation for a feature-implementation discussion among developers.   
Windows has some really good ideas.  And some bad ones.  The Windows 
File History feature does look better than what OpenVMS offers with 
BACKUP, though.

> Not VMS Clustering.  A few may have shared everything capabilities, but 
> most don't.

macOS does, with Xsan.  As for network-attached storage and file 
shares, that's far more common.  OpenVMS offers NFS there, but the rest 
of the world is largely using SMB for file sharing.

> RMS is always there on VMS.

Which was a great selling point many years ago.

Now?  PostgreSQL and SQLite and MariaDB and MySQL are quite commonly 
used, and various platforms integrate one or more of those databases.

> Are you sure about that time?  Just how long of a password is needed 
> for that?  Perhaps one where you fall asleep before finishing typing?

10 to 12+ characters is a typical recommendation against brute-forcing, 
with a filter of common passwords customized to local usage.

nómithepri — Niccoló Machiavelli The Prince.  Or NóMiThePri1513 if 
you're working with older password recommendations.

> Regardless, the time doesn't matter, if it can be done.

Usual calculation is one of cost.  How much somebody is willing to 
spend on the effort, and whether there are better targets for the 
breach either within the organization, or in other organizations.

Modern password hashes can take years to brute-force—and variously much 
longer—using higher-end gear.  Select argon2, scrypt, bcrypt, etc.  
Purdy is far to efficient.

https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40

https://eprint.iacr.org/2016/104.pdf

Somewhat related, it looks like the cost of generating SHA-1 hash 
collisions has dropped below a half million dollars or so, thanks to 
the cryptocurrency crash.


-- 
Pure Personal Opinion | HoffmanLabs LLC