I do believe that MACRO in the slides refers to MACRO-11, a PDP assembler. Or maybe MACRO-32, for VAX. In either case, they have been compiling this "assembly" language for Alpha (and now I guess Itanium) since VMS has run on that architecture.
That would be MACRO-32, the VAX assembler/assembly language dialect. As a considerable part of the VMS kernel is written in VAX assembly, they treat it as a high level language and compile it to Alpha, IA64 and now x86-64.
As an old time OpenVMS user (on VAX DECstations first and on AlphaServer later) I'm looking forward to this.
I doubt it will ever come even remotely close to a "mainstream" OS, but Alpha to x86 is a much better migration path than Alpha to Itanium.
And yes, there are still many OpenVMS installs out there in the wild, from airport logistics to assembly lines, so this may make sense from a financial standpoint (versus a complete software rewrite for Linux/AIX/whatever) - provided they can market it well enough to the old users.
I wonder if the hardware is original and they simply have plenty of spares, or if boards are rebuilt with discrete logic or FPGAs/CPLDs as they break down.
The article is about PDP-11 computers (16-bit, 1M max memory, from the 1970s) which never ran VMS (runs on 32-bit VAXes with 4M+ memory from the 1980s). I don't know why the author mentions OpenVMS in the Updates section because it isn't mentioned anywhere in the article body.
I remember learning about nuclear power plants and VMS back when I was in university. I was told they were used for the nuclear sensor networks though.
I personally worked with VMS/VAX/Alpha based systems for nuclear power plant simulators, process control for petrochemical, plastics, chemicals oil & gas, semiconductor facilities till 2002. Still get requests for consulting primarily on system/program conversion projects from VMS/Fortran variants to Windows/Unix/C variants.
Nerdnit, I don't think DECstatations were (or were ever called) VAX. They were MIPS-based machines and I don't think they ever ran VMS. There was VAXStations, though, which did.
Why? Not everything is free and open source. In fact, most of the operating systems used outside the "general-purpose" Linux realm are not (e.g. OS400, z/OS, z/TPF, AIX, Solaris, NonStop, QNX, vxWorks... even Windows Server).
That said, if you're really interested, HP offers free hobbyist licenses for non-commercial use of OpenVMS, with access to the OS and compilers and usable on real hardware or SIMH.
Last time I tried (few years ago) I was contacted via email by an HP guy who asked me what architectures I needed licenses for, and then sent me a private FTP login to download all the files.
There was a project to reimplement OpenVMS under the GPL, http://www.freevms.net/ - I think the project has stagnated, though, the last commit in their git tree seems to have happened about two years ago.
VMScluster still blows away anything else. 20 years ago it was doing what you can only now do with vMotion now... And being able to set a working set per job... And a coherent story for cross-language libraries... I could go on. VMS was a technological tour de force that has yet to be rivalled.
What cluster features were in VMScluster that weren't also in TruCluster? To me the interesting part of TruCluster was the shared filesystem and the application failover. That said, I work for a company now that eschews that kind of tight coupling, because it's expensive to scale the hardware.
I have a bad habit where instead of doing something relevant I play with old stuff I read about but didn't have access to as a kid.
VMS always interested me since I first read about it in the jargon file. I recently found an alphaserver on craigslist and I just requested an openvms hobbyist license so I could play with it.
An octane running irix is another expression of this problem.
Nothing wrong with that, you simply suffer from retrocomputing.
Careful about the power bill though. Large SGI stuff (e.g. Onyx) can go in the kilowatt range under load, and an AlphaServer idles at around 200W last time I checked.
I think I remember reading or overhearing that Intel's chips somewhere in the Pentium 4 era were more efficient at converting electricity to heat than a typical hotplate. (Ratio-wise, at least.)
I love the way you phrase that! (I do suffer from that condition, too, in a way, if "suffer" is the word I want - but in my case it is select pieces of obsolete equipment sitting on my bookshelf. My favorite is an ancient IBM ISDN adapter (it still says 1TR6 instead of EDSS1 somewhere on the case) that once hooked up a mainframe to the outside world... ;-)
A friend of mine had an old Alpha years ago; was running NT4 on it. You'd watch the lights dim slightly when it turned on. I don't know the model, but the thing was huge.
AFAIK Theo de Raadt still has a bunch of racks of vintage hardware working as an OpenBSD build cluster in his basement (old photo circa 2009: http://www.openbsd.org/images/rack2009.jpg). VMS-related, OpenBSD discontinued the VAX port in the 6.0 release this year. Never touched a VAX but from what I read the OpenBSD 5.8 VAX port is a lot more recent and better maintained than the NetBSD port.
> An octane running irix is another expression of this problem
I dreamed of having a SGI after watching Jurassic Park as a child. I also remember my dad bringing me home a VHS of SIGGRAPH circa 1995 and dreaming about time on a SGI. Time to check Craigslist, I think. :)
Why not translate the PDP-11 or VAX binaries to x86-64 and emulate the memory-mapped device interfaces? Seems like less work, and more likely to produce a cheap solution for legacy installations worrying about how to run an ancient critical application on old gear.
A lot of the old VAX installations are industrial control applications, the device interfaces are exactly the things you want to keep. You can buy new VAX-compatible machines with the old Digital I/O buses and cables today: http://logical-co.com/product/ba23123-m9405-module-interconn...
I work with an old DEC guy who co-wrote a book about the BLISS compiler back in the day. He thought it made a much better "portable assembly language" than C.
He also likes to talk about the binary compatibility on VMS; e.g., VAX binaries that run unchanged on Itanium. Unfortunately, that commitment to compatibility has wavered a bit since HP offshored VMS maintenance. We've had to work around some breaking changes recently.
If I'm understanding these slides correctly, AMD64 VMS would require recompiling VAX, Alpha, and Itanium applications from source. I kind of see a chicken-and-egg problem: application vendors won't port without demand, and customers won't adopt without applications.
DEC had a tool called VEST which was used to take native VAX binaries and convert them to run on Alpha AXP. It was very cool technology. A fair amount of the system utilities for OpenVMS on AXP were VESTed VAX binaries. I'm pretty sure the EDT editor was one of these.
The VEST technology could possibly be used to convert native VAX binaries to run on X86_64, I don't know for sure how the endian-ness would be dealt with.
The roadmap on the same site shows a "dynamic binary translator for Alpha and Itanium images" planned to be available with the general release ... in 2019!
long live DEC OpenVMS, it's really rare to see an article on hacker news about OpenVMS, but it has happened before. long live DCL, ASTs. i started work in 2000, but was still able to play around with vax and alpha clusters, sometimes if i recall correctly, a mix of vax and alpha nodes in the same cluster. OpenVMS was such a stable operating system, by 2000, most of the good DEC engineers had left already for companies like Microsoft (Dave Cutler, etc), but that legacy code was still quite amazing. long live ZKO and DEC, i learned a lot from that job, great to see this coming, but not sure if it's still relevant these days with all my development on linux. could you imagine running this port on aws, like some customer migrating to the cloud all their legacy infrastructure? that would be such a niche market.
It is really quite a fascinating OS (I've had it running under a MicroVAX 4000/60 for fun -- and yes, I can truly say fun!) and feels quite modern even today.
The original VMS C compiler targeted a pre-ANSI "VAX C" dialect which had further differences. DEC C replaced it on the Alpha (I don't think it was backported to the VAX)
I have OpenVMS running under the SIMH emulator... It takes me back to the late 80's / early 90's. Hobbyist licenses are available for people who want to tinker. Fun stuff...
57 comments
[ 4.0 ms ] story [ 111 ms ] threadOther parts of the kernel are written in C (newer code) and BLISS (older code). See https://en.wikipedia.org/wiki/BLISS
I doubt it will ever come even remotely close to a "mainstream" OS, but Alpha to x86 is a much better migration path than Alpha to Itanium.
And yes, there are still many OpenVMS installs out there in the wild, from airport logistics to assembly lines, so this may make sense from a financial standpoint (versus a complete software rewrite for Linux/AIX/whatever) - provided they can market it well enough to the old users.
I wonder if the hardware is original and they simply have plenty of spares, or if boards are rebuilt with discrete logic or FPGAs/CPLDs as they break down.
Former NSA staffer and famous whistleblower, William Binney, says the DNC hack was not done by Russia but by US Intelligence.
http://investmentwatchblog.com/nsa-whistleblower-says-dnc-ha...
make youself clear
That said, if you're really interested, HP offers free hobbyist licenses for non-commercial use of OpenVMS, with access to the OS and compilers and usable on real hardware or SIMH.
Last time I tried (few years ago) I was contacted via email by an HP guy who asked me what architectures I needed licenses for, and then sent me a private FTP login to download all the files.
Some links to get you started:
http://labs.hoffmanlabs.com/node/23
https://www.wherry.com/gadgets/retrocomputing/vax-simh.html
If you want to emulate on SIMH I suggest you compile the latest from source (it's on GitHub).
VMS always interested me since I first read about it in the jargon file. I recently found an alphaserver on craigslist and I just requested an openvms hobbyist license so I could play with it.
An octane running irix is another expression of this problem.
Careful about the power bill though. Large SGI stuff (e.g. Onyx) can go in the kilowatt range under load, and an AlphaServer idles at around 200W last time I checked.
IT was no green back then :)
I blew at least three fuses between that and the RX5670 (4 x Itanium), which consumed a similar amount of power @ 110V.
I love the way you phrase that! (I do suffer from that condition, too, in a way, if "suffer" is the word I want - but in my case it is select pieces of obsolete equipment sitting on my bookshelf. My favorite is an ancient IBM ISDN adapter (it still says 1TR6 instead of EDSS1 somewhere on the case) that once hooked up a mainframe to the outside world... ;-)
I dreamed of having a SGI after watching Jurassic Park as a child. I also remember my dad bringing me home a VHS of SIGGRAPH circa 1995 and dreaming about time on a SGI. Time to check Craigslist, I think. :)
$ show developer /user=steve_jones /source=linkedin /url=https://www.linkedin.com/in/stevejonesinwashington
edit: corrected url
He also likes to talk about the binary compatibility on VMS; e.g., VAX binaries that run unchanged on Itanium. Unfortunately, that commitment to compatibility has wavered a bit since HP offshored VMS maintenance. We've had to work around some breaking changes recently.
If I'm understanding these slides correctly, AMD64 VMS would require recompiling VAX, Alpha, and Itanium applications from source. I kind of see a chicken-and-egg problem: application vendors won't port without demand, and customers won't adopt without applications.
The VEST technology could possibly be used to convert native VAX binaries to run on X86_64, I don't know for sure how the endian-ness would be dealt with.
http://vmssoftware.com/pdfs/VSI_Roadmap_20160906.pdf
It is really quite a fascinating OS (I've had it running under a MicroVAX 4000/60 for fun -- and yes, I can truly say fun!) and feels quite modern even today.
The original VMS C compiler targeted a pre-ANSI "VAX C" dialect which had further differences. DEC C replaced it on the Alpha (I don't think it was backported to the VAX)