[Info-vax] OpenVMS Development Annoyances

Mon May 6 18:05:47 EDT 2019

On 5/6/2019 11:51 AM, Stephen Hoffman wrote:
> 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.
>
>

I guess I see two issues with the references to macOS.

Apple doesn't do servers anymore, right?

I've got maybe 40 years of one environment, why should I give that up 
for another?

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486