Post by John ReaganHoff,
You skipped the one question I would have also considered interesting.
Yes, I did.
Long answer:
That's because I didn't think the question was interesting enough to
warrant the research, nor sufficiently relevant to the rest of what
David was seeking of the distributed lock manager; of the DLM. Seemed
a good way to distract from what David was seeking, if I had researched
and had addressed it.
The OpenVMS operating system is written largely in a mixture of
Macro32, Bliss and C.
As of twenty years ago, the bulk of the source code was in thirds,
among those three languages. Plus far smaller numbers of a whole slew
of minor languages, of course. Macro32 and Bliss are the oldest, and
C became more prevalent in the 1990s, as a decision was made to create
new and overhaul existing and to migrate development to that language.
I'd expect C to have become the predominant programming language used
in OpenVMS and is continuing to supplant Bliss and Macro32, but I'd
doubt that anybody has run the line-counting tools and the statistical
reporting tools in the OpenVMS source code control system — not since I
last did that ~twenty years ago.
What language the DLM is written in is not relevant to calling
programs, as the APIs are classic OpenVMS. Not particularly modern,
requires lots and lots of glue code, but typical among APIs. VSI is
not going to change the implementation languages, either.
As for determining what mixture of languages where used, I don't know
and would have to rummage the source listings. I'd guess a mix of all
three languages here, given both the vintage and the ongoing work in
the DLM.
Post by John Reagan"Any idea what language(s) were used to implement the DLM? "
I see both Macro-32 and C (ie, SYSENQDEQ.MAR and LOCK_UTILS.C)
If it's not in Rust or something else equivalently newer, it's not
really all that interesting (to me). Why? Because it's all been
discussed and debated before, and I well remember the debates inside
OpenVMS development particularly from the folks fond of Bliss too.
Because it's all very familiar. Because there hasn't (yet) been a
shift in the OpenVMS developer mindset and the internal practices.
Either at VSI, or among OpenVMS customers. And even knowing there's
Rust or otherwise in use is not relevant to application use of the DLM.
Macro32, Bliss, C and how all of OpenVMS and most of the OpenVMS
applications are developed are pretty crufty, and the devops tools are
very old and comparatively very problematic. (More than a few OpenVMS
folks don't use IDEs, but many developers on other platforms do.)
They were good for their time certainly and the implementations still
work well, and there are excellent reasons to avoid any wholesale
rewrites of these and of other existing OpenVMS hunks into newer
languages. Incremental rewrite-migration-retirements, on the other
hand...
There are definite considerations around the scale of the operating
system source code base and its builds and the substantial test suite
certainly, but the languages and development tools are poor and —
compared with what's available now — dated. The scale of the OpenVMS
source code alone is something that most folks here don't have to deal
with. It wouldn't surprise me to learn that sometime over the next
decade or so, VSI will look at migrating some of their internal tooling
to git, mercurial or fossil, for instance. Both for their own internal
use, and for community and shared development, They'll also likely
consider implementing easier migrations from CMS to one or more of
those tools, too. But I digress.
The languages and tools available to and used by many of the OpenVMS
customers aren't comparatively very good or very efficient to use or
very capable by contemporary standards, either. Certainly not in
comparison to the languages and frameworks I'm working with elsewhere.
I'd wager those sites haven't looked at this topic in a decade too,
not that there are very good alternatives presently available on
OpenVMS.
VSI is addressing parts of this conundrum with updates to the existing
languages and tools and the migration to LLVM, but — given how busy the
next five years will undoubtedly be in Bolton, and how tight their
budget will be — they're likely not in a position to start working with
more modern tools and API designs themselves, nor to start to introduce
those to their customers, and they'll also want and need to preserve
the installed base. Which means rolling forward the languages and tools
they have is the best of bad choices, and they're probably not soon
going to be introducing Rust or Go or such into OpenVMS, or into the
OpenVMS community. Then there's whether the community is even
interested, and whether enough younger developers can become interested
in OpenVMS as a viable and serious platform for serious applications;
as something other than a candidate for OS tourism or retrocomputing or
schadenfreude.
I'd hope we'll see Python, Lua and a few tools added into the base
install, kits for git and mercurial and such, but then similar hope
holds for fully integrating IP networking and many other necessary
improvements into the platform; the work necessary to make development
and deployment and maintenance on and for OpenVMS less problematic and
less uncompetitive. (n.b. I'm aware of the ports and implementations
of these and other tools on OpenVMS and have looked at or used most of
these, too.)
In summary.... Debating whether two-revisions-of-the-standard-back C,
or Macro32, or Bliss — or any other languages of similar vintage — was
an appropriate choice for the DLM seemed somewhat uninteresting.
Now y'all better know why i expunged that part of the question.
https://www.fossil-scm.org
https://www.rust-lang.org
--
Pure Personal Opinion | HoffmanLabs LLC