Sujet : Re: OpenVMS system programming language
De : seaohveh (at) *nospam* hoffmanlabs.invalid (Stephen Hoffman)
Groupes : comp.os.vmsDate : 28. Dec 2024, 04:47:58
Autres entêtes
Organisation : HoffmanLabs LLC
Message-ID : <vknsde$4hij$1@dont-email.me>
References : 1
User-Agent : Unison/2.2
On 2024-12-19 06:56:43 +0000, David Meyer said:
Does VSI have a preferred or official language for system programming for OpenVMS?
Starting in the early 1990s, the language choice for DEC OpenVMS was C.
I know system programming for VAX/VMS was done in MACRO-32 and BLISS-32, and at least some system programs were written in C when Alpha was introduced.
VSI has the BLISS reference manual on the Legacy shelf.
BLISS was retired as a salable layered product long ago.
The BLISS compilers became available on the Freeware.
BLISS remains necessary for OpenVMS itself. As is MACRO-32, and some layered products including Notes.
Have all the MACRO and BLISS programs been ported to C or C++, or will they be in the future?
No, and no.
Back around Y2K, MACRO-32, BLISS, and C were roughly divided in thirds of the ~64K source modules in OpenVMS Alpha and OpenVMS I64 source pool, with the percentage of C rapidly increasing starting with the C system programming work introduced at V6.1.
VSI is likely still following those longstanding DEC OpenVMS practices here, and will be writing new code in C, rewriting existing code being overhauled into C, and maintaining and modifying the rest of the existing code in the original language as needed.
Some code gets rewritten due to other constraints, such as the PL/1 code, and the Ada code.
Rewriting existing code is best approached with great caution, as it can very easily become exceedingly expensive, and tedious. It also requires immense resources. And even the best results can be perilous.
In a manner of consideration, rewrites are a whole lot like platform ports, though rewrites are far bigger and far riskier and far more costly projects. And keep other development work constrained for even longer than the port tends to cause.
There are, of course, other and even better ways to spend vast sums for negligible benefits for the OpenVMS vendor, such as a Linux "kernel transplant" that was suggested by a few folks around here. Though if you do want that something akin to that approach, have a look at Sector 7 product.
I'd suggest reading some of Martin Fowler's writings in the area of incremental rewrites and refactoring, as that might help avoid some common missteps.
-- Pure Personal Opinion | HoffmanLabs LLC