Stephen Hoffman
2019-02-08 16:08:30 UTC
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.
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
Pure Personal Opinion | HoffmanLabs LLC