Post by Jon Schneider
I would really like to see a developers' guide Wiki for OpenVMS for
those of us, and I think there are quite a few, who have been writing
software for decades yet don't have a feel for doing so under (Open)VMS.
The VSI OpenVMS Programming Concepts manuals are the introduction to
this, and the OpenVMS Calling Standard manual.
The old Modular Procedures manual (no longer part of the doc set) and
the really-hard-to-find DIGITAL Software Engineering Manual,1988,
document identifier A-DG-ELEN571-00-0, have some more information on
how DEC envisioned designing, packaging, shipping, and supporting apps.
https://www.nassi.com/VAX-11_SoftwEngrMan_Feb77.pdf (this is the 1977
predecessor version, though the 1988 version is vastly improved)
OpenVMS itself has no opinion on build procedures, though builds
inherently do presume compilers and related tooling and which may not
be or will not be available.
Compilations weren't something most DEC layered products did.
Which is why you see suggestions around a procedure for building and
another for linking.
Oh, and for C code there's one of my absolute favorite OpenVMS feature
of all time, the absolutely spectacular idea that are the feature
logical names. A mechanism which allows an out-of-band setting from
elsewhere in the build environment to re-tune or alter your source
build output and app run-time behavior in exceedingly arcane and subtle
ways. Even better, this is built atop logical names for app
configuration, a scheme which fell out of the 1970s and the corpse of
RSX-11M, and—outside of _maybe_ redirecting file paths—somebody should
dig up that corpse and re-bury the whole idea with it, then pour some
concrete over the grave with some engraved warnings for future
generations of developers that some ideas can come at too high a cost.
Some PCSI kits might link objects at install time, but providing
executables within install kits is commonplace.
Troubleshooting site-built executables is more difficult than
vendor-built executables, too—kits and users might build the necessary
listings and maps, or might not, or those files might get deleted and
which makes symbolicating and debugging crashes that much more
There are various means to start apps. One being a manually-edited
startup file and a pair of manually-edited shutdown files, which is
common and quaint and error-prone. The other means is using the SYSMAN
tool, which would be preferred but for ~nobody using it, including PCSI
kits having had some hooks here but not using this. (I can think of
better ways to deal with all of this startup stuff, but manual edits
and PCSI—or maybe VMSINSTAL—is what we have.) There are other and
somewhat less-common means too, such as the auxiliary server (inetd).
There are many discussions of how to package and structure installed
apps too, though again OpenVMS itself and its tooling has few or no
opinions here. Some apps and kits scatter files through the system
directories, some create an app-specific directory structure. And
clustering complicates this, as now you can have two or more different
object file formats and executable formats involved, and can have both
a host-specific and a cluster-shared common directory. About the
biggest opinion in the PCSI tooling is a flat filename address space,
multi-architecture kits aren't all that well documented, and there can
be comparative difficulty in installing apps anywhere but on the system
For building, look around, and you'll find a mix of DECset MMS, MMK,
DCL, gmake, bash, and other tools used to build the apps, too.
OpenVMS has no means to package together and isolate app-related
features and dependencies (e.g. sandbox, container, jail, app bundle,
etc), and conflict avoidance is via facility prefixes and naming
conventions. Manual. No automation. Collisions with usernames and IP
ports and UICs and such can and do and have arisen. There's no facility
name coordination and no facility registrar at present AFAIK—x86-64
might be a good time to see that restarted—and which means name
collisions are possible. (These collisions happen less often due mostly
to few OpenVMS servers and few layered product kits and comparatively
few apps. This manually-coordinated by-convention model doesn't scale
all that well, but that hasn't been a problem in this millennium.)
One of the biggest mistakes I've encountered with OpenVMS apps is
incorporating flexibility around meaningless details—TCP/IP Services
configuration tool is one such example, where it's massively flexible
around what clients and what services get configured and how, and for
no benefit, and—with the different UICs and the rest of the
differences—with added complexity and costs. In 2021, nobody cares
about that, and it'd be easier to have everything configured, with the
only remaining decision being whether to start a particular service at
boot. And we still trip over the occasional bugs in all that
complexity. For... naught. The other is maintaining old and bad ideas
and broken APIs and limited APIs for far too long if not for forever,
but that's all fodder for several other debates.
Until and unless OpenVMS itself and the OpenVMS tooling has some
opinions here, I'd expect there can and will be as many different
opinions on how to name and organize and label build procedures and
source code distributions as there are developers involved. If not
more. Above comments obviously included.
BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.
Pure Personal Opinion | HoffmanLabs LLC