The wider question: where would one look at these days for VMS documentation online?
The more precise question: I would like to read about its ABI design, how it managed to stay stable across operating system releases, across multiple architectures, and across multiple languages. Calling modules compiled with Pascal from C or Cobol, no problem.
My personal relationship to VMS for always curiousness, compared to the minimalist UNIX it certainly looked way more complex, but looking at the walls of orange/grey manual folders it was obviously well documented, and from my quick browsing (and I was a wee systems programmer at that point) it looked well designed and solidly built.
I found the 1985 VMS Language and Tools Handbook (261 page PDF)
and it makes reference to the VAX Calling Standard and the Guide to Modular Procedures, which might be good terms to look for.
The VAX Calling Standard, the Guide to Modular Procedures, and the VAX Condition and Exception Handling Standard are the basis of the VAX Common Language Environment. The calling standard defines the mechanisms for passing arguments between program modules, The Guide to Modular Procedures provides a consistent set of software programming pragmatics, and the Condition and Exception Handling Standard defines the mechanisms that ensure consistency in error and exception handling routines, regardless of the mix of programming languages in use. For example, in no other program development system on the market today, can you write a program module in Basic that calls another module in written FORTRAN and then calls a math routine written in Pascal - all in one Ada program.
Edit: this leads us to Macro Made Easy:
Edit: VMS diagram from the Handbook (page 27) includes the RTL (run time library) which might be of relevance…
Mentioned in the Macro article: Introduction to VMS System Routines (151 page PDF, 1990)
gives, I think, full details of the calling conventions. This doesn’t necessarily answer the question about stability and interoperability between versions - this is for VMS 5.4 - but it might be a way in.
After leaving Digital, I was shocked that each language out there on Windows etc. didn’t all interact with each other. We had systems inside DEC written in VAX C, Pascal etc. and they all worked together, but afterwards, no chance!
COM tried to unify this a bit but was too complex. About the only common interface around is at C level, never mind C++ level.
At uni, c1980, using their PR1ME system I was able to get Pascal to call FORTRAN and vice-versa, so it was possible then. I think you could also call Pascal from COBOL too - at that time, I’d written a vdu library to allow for a sort of form-maker thing (goto XY, get a line of text with editing, the usual stuff) - I wrote it in Pascal but it was used by others.
I didn’t really think about it on other systems back then - Unix on a PDP11, but that was just C, although it did support Pascal.
I remember needing to write a shim, on the Amiga, for some purpose. Possibly to call into a library from C. It was the only machine code I wrote for the machine, I think - and I hand-assembled it, I’m fairly sure.
But it does sound as if the VAX, and VMS, were carefully architected and documented. Interoperability doesn’t just happen!
It did not feel rigid, it was a nice set of logical and consistent guidelines, followed by the engineers intern in Digital (I was in Local Engineering for 10 years).
In the Unix world there are much less guidelines agreed upon by all, it is all about freedom.
Only the Linux kernel is strict in the hands of Linus (and friends!), the user part is not.
So yes, creativity, lots of freedom for new ideas and also chaos and inconsistency is the result.
There is one VMS, there are so many Unix flavours/distributions.
VMS is not dead, but it is close. Unix is the king of the mountain.
You can characterize them in different ways, but VMS and Unix are similar solutions to a problem that were developed within different cultures, and for better or worse it shows.
I have heard the difference characterized as the dominant design principle in Unix was always to give the operator enough rope to hang himself, while the VMS designers assumed it was always Monday morning and the operator has a hang-over and not enough coffee.
“This standard defines the requirements, mechanisms, and conventions that support procedure-to-procedure calls for OpenVMS x86-64, OpenVMS Industry Standard 64, OpenVMS Alpha, and OpenVMS VAX. The standard defines the run-time data structures, constants, algorithms, conventions, methods, and functional interfaces that enable a 32-bit or 64-bit native user-mode procedure to operate correctly in a multilanguage and multithreaded environment on x86-64, Intel® I64, Alpha, and VAX processors.”
The use of descriptors made it much easier for modules to interact with each other. It also allowed you to do the equivalent of reflection in a limited manner. You could determine a lot about the data being passed to a routine by examining the descriptors for the arguments.
You’d get a type, size, and address for the passed data, along with scalar information.
Those of us from Edinburgh have the same expectations - all our locally-written systems allowed cross-calling; the most significant one being EMAS but the 68000-based Advanced Personal Machine was also multilingual. Also, at Acorn the calling conventions for the 32016 system were language independent - no coincidence that a bunch of us there were from Edinburgh, as were the compiler-writing team. In fact here’s the Acorn linker which supported the calling standard, that’s written in (and supoprted) Imp but was used to link C, Pascal and ModulaII objects!: https://gtoal.com/history.dcs.ed.ac.uk/archive/staging-area/EDINBURGH_REUNION/mark%20taunton%20linker/ I’m not 100% sure but I think some of that philosophy survived into the ARM days and the ARM calling standard.
