[Info-vax] OpenVMS app development, kitting (was: Re: Making Open Source Tools Work for VMS)

[Stephen Hoffman]

On 2021-11-22 10:12:59 +0000, Jon Schneider said:

> 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.

https://docs.vmssoftware.com

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.computerhistory.org/collections/catalog/102773805
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 
difficult.

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 
disk.

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