[Info-vax] OpenVMS Development Annoyances

[EVERHART at gce.name]

On Friday, February 8, 2019 at 11:08:34 AM UTC-5, Stephen Hoffman wrote:
> Things about developing for OpenVMS that have annoyed me (again) this month:
> 
> There's no preferences file API.  Which means downloading a wad of code 
> from elsewhere, or rolling my own and supporting my own state-machine 
> parser and generator.  Or as happens far too often, explicit in-line 
> code that's less than wonderful to maintain and test and extend.   And 
> no, logical names are not a preferences API.
> 
> There's no job scheduler.  Yes, I'm aware of the add-ons.  No, batch 
> isn't a scheduler.  Batch was good enough and was useful for what we 
> were doing back in the early VAX era, but our needs have changed.
> 
> There's no DCL CLI interface to the lock manager.  Yes, I'm aware of 
> the add-ons.  And the system service API follows the usual OpenVMS 
> model of glorious flexibility at the cost of simplicity and ease of use 
> for common tasks.
> 
> Itemlists.  Did I mention itemlists?  I dislike itemlists.  Passing 
> arguments in hand-rolled data structures is far too reminiscent of 
> writing assembler code.  And about as tedious and as voluminous.  And 
> then there's the lack of a parser.  And the lack of language support.  
> Descriptor support is only marginally better than itemlist support, 
> outside of BASIC and whichever other languages where it's been 
> integrated. But itemlists haven't been integrated anywhere.
> 
> Logging.  Like storing preferences, there's no single way to do this, 
> and which means that everybody does it differently.  And there's bupkis 
> for collecting logging data and app crash data from multiple OpenVMS 
> servers.  Yes, I know from syslog, syslog-ng, and ilk.
> 
> On-going grumbles including inadequate development tooling and 
> inadequate compilers and crash-handling and patch-handling also all 
> apply.
> 
> The results of these limits for app developers?  App tooling that is a 
> fraction of what it can and should be, and apps that tend to be 
> brittle, and apps that take longer than they should to develop and to 
> test.
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

I recall that some items (dcl interface to lock mgr comes to mind) that have been on the sig tapes. Those are still available.
I wonder if there is any benefit in anointing some bits of this old work for use, rather than having to redo some from scratch. I don't recall any way that existed at DEC to anoint code like this. Some of the authors are still alive, and license issues might not be too hard to solve for bits that were considered. (permissions like "use it as you please, feed it to a whale..." can be interpreted).

Even publishing what would be wanted for such anointment might elicit the occasional bit...