Oh, damn. The OpenVMS hobbyist license is actually why, a long time ago, I joined DECUS Munich. It was a very complicated affair: DECUS Munich was one of the few DECUS organizations that accepted members from outside their area (I was nowhere near Munich, and there was no DECUS organization anywhere near me -- ironically, I think DECUS Munich was the closest one). I am pretty sure they had an age restriction so I may have lied on my application form, as I was 14 or 15 at the time or something like that. Also I didn't speak or write any German so the application form wasn't exactly easy to fill in. This was before Google Translate, so I had to go out and buy a German dictionary. Thankfully, a lot of its members spoke English and they were extremely nice to me.
It then took about two months for the thick envelope containing a booklet, some promotional material from a bunch of sponsors, and my membership card to reach me by snail mail. I'd given up hope by then -- the local post service is extraordinarily bad and I assumed they'd lost it.
I still carry my DECUS member card in my wallet, and it's getting harder and harder to explain what it is...
Edit: the world is a very small place. Many after that, it turned out that one of my colleagues at the time was also a DECUS Munich member. He was an extraordinarily bright German physicist, many years older than me, doing research at the same lab where I was working at the time. I don't know how many members DECUS Munich has, or had, but oh boy!
I have fond memories too, it was around 2002/2004 ish when I inherited an alpha server 2100A from a friend and wanted to put OpenVMS on it, being in a small town in New Zealand I went to the HP building in the closest city and asked to speak to someone about OpenVMS
They of course had no idea what I was talking about, and after 5 cycles of (10: explain what I want, let me get someone technical for you, I don’t know what you’re talking about, go to 10)
I finally managed to get someone to point me at the OpenVMS hobbiest programs.
Eventually a managing to get the install media I got the system running and spend 2/3 years coding applications for this weird system, while also working on the Linux port for the alpha chips.
So much fun and positive memories, I’m sad to see the hobbiest program come to an end
At least you can run Linux on an LPAR (and these machines are ridiculously fast Linux boxes). I wonder how a couple racks of z15 systems would compare to performance-equivalent racks of commodity x86 servers. I suspect that, per watt and area, these machines can host a lot more VMs than commodity racks.
You can run z/VM under the LPAR and host multiple Linux images under it, or host Linux directly on the LPAR and use KVM to split it into smaller VMs. The penalty for CPU oversubscription seems relatively small with the almost a gigabyte of L4 cache in every processor drawer.
I'm not buying one (sadly it's a bit over my impulse buy threshold), but I'd love to play with one.
I rescued a Multiprise 3000 from a scrap metal dealer. It's seemingly impossible to get the OS/2 Warp software just to be able to bring the mainframe hardware up. I can't even get to the point where I might actually be able to use an OS.
Excuse my ignorance on this topic, but what exactly can you do with OpenVMS that you cannot do with a FreeBSD, Linux, or even Windows server? What's the specific advantage of OpenVMS?
OpenVMS has real asynchronous I/O supported directly by the kernel. Under Linux, all I/O is synchronous but possibly nonblocking, and all disk I/O is blocking. OpenVMS also has a comprehensive, fine-grained security model involving a database of subjects, actions, and objects, giving administrators fine control over who may do what to what. In short, ACLs built into the OS from the ground up. In Linux, ACLs are a bag on the side; their inclusion in BSDs varies. OpenVMS also automatically logs all events, providing an audit trail for security incidents. OpenVMS clusters easily (called a VAXcluster in the VAX days); support for failover and load balancing is built into the OS. OpenVMS's command line interface is designed around a mistake-prone operator who hasn't had their coffee. It doesn't have, say, the 'rm -rf /' problem. Unix's CLI assumes a perfect operator who gets everything right the first time. "Fat fingering" a command could have disastrous consequences; in most cases on VMS, the command interpreter will raise a syntax error. OpenVMS also has file versioning built into the file system; again, this is a bag on the side (formerly: SCCS/RCS, today: git) in Unix.
Oh, and OpenVMS doesn't crash. Like, ever.
Windows Server has some of these features. The NT kernel has the same designer as VMS -- Dave Cutler, a man whose contempt for the Unix design philosophy is well documented.
> OpenVMS's command line interface is designed around a mistake-prone operator who hasn't had their coffee. It doesn't have, say, the 'rm -rf /' problem. Unix's CLI assumes a perfect operator who gets everything right the first time.
Funny you should say that. On a VMS build server, I was once cleaning up a build and ran a "DEL [...]* .OBJ;*" (HN auto-formatting doesn't allow me to display this properly without inserting a space after the first asterisk). I started to wonder why it was taking a very long time to complete when it hit me... I had run it from the root-level of DKA0:, not from the build directory. Needless to say, the entire OS had to be restored/rebuilt.
This is easily the biggest mistake I have made in my 20-year career as a sysadmin (or system manager as we call it in the VMS world). Don't get me wrong, I love VMS for many of the reasons you've stated, and more; I wish it was more widely used in the industry. But don't be fooled; you don't need to be on a Unix system to make mistakes of disastrous consequences. They can happen anywhere!
Actually, M. Cutler's contempt for Unix design philosophy is not well documented. It's an unsupported edit to Wikipedia, and lots of recycling of that.
The subject came up on StackExchange recently, with someone asking for the meaning of the Wikipedia claim. No-one could find it actually documented. There's documentation of an incident where M. Cutler showed contempt for people who were connected to DEC Ultrix, calling them "sorry excuses for engineers". However the source for that is an anecdote, related in a book years later, told by one of the very people so addressed, who might have had an incentive to thumb xyr nose at M. Cutler.
The book "Show-stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" (1994, G. Pascal Zachary) quotes: "Unix is like Cutler's lifelong foe," said one team member who'd worked with Cutler for nearly two decades. "It's like his Moriarty. He thinks Unix is a junk operating program designed by a committee of Ph.D.s. There's never been one mind behind the whole thing, and it shows. So he's always been out to get Unix."
The Armando Stettner named in https://en.wikipedia.org/wiki/Special:Diff/320396668 and other edits by the same person is the person who told the "sorry excuses for engineers" anecdote about xyrself, recorded in A Quarter Century of UNIX by Peter H. Salus.
The irony is that there is better, more specific, documentation of M. Cutler's opinion of OS/2 (specifically its mutex mechanism) than there is of M. Cutler's opinion of Unix.
I'd point out that at least one reference to Cutler and Unix in the book purports to be a direct quote from one of the team. If you're going to argue that he just made that quote up, I guess I can't argue with you of course.
> at least one reference to Cutler and Unix in the book purports to be a direct quote from one of the team
It could still be taken out of context, which was a common tactic of Zachary's when he wanted to misrepresent something. Or the team member the quote purports to be from could have been misunderstanding or misrepresenting or exaggerating Cutler's actual views, and Zachary could have picked that particular team member to quote from because it fit the narrative he was trying to construct, and ignored other team members who were saying different things.
OpenVMS absolutely does crash. I was actively involved with a very large cluster - and with enough abuse - individual nodes will tip over - and if you aren't careful - you can take down an entire cluster.
It was an interesting OS. Some different ideas in there. But the idea that it never crashes is simply false.
Anecdotally, VMS had a command to exclusively allocate resources which I learned on a predecessor OS RSTS/E. Predecessor in the sense that some command syntax carried over; I have no clue how much RSTS/E source if any made its way into VMS. Regardless, the idea was you would ALLOC the line printer or tape drive to prevent anyone else from stepping on you.
At Digital's NCC booth in 1981 or 1982 (I forget) they were showing off clustered VAXes with the nodes named after colors. I jokingly typed ALLOC RED:: and discovered that allocating an entire node to yourself crashed the cluster.
I cracked "root" on ours as an undergrad, so going to claim that the security wasn't all that, at least lacking a perfect operator. (And didn't they distribute it with vendor backdoors for a long time?)
Beyond that, AFAIK it didn't have pipes, which was a real limitation for creating, well, pipelines to stream process data far larger than available RAM.
Somewhere I have a printout (green ruled 132-column line printer of course) of the SYS$SYSTEM:SYSUAF.DAT file showing my account with all 32 privilege bits set (including of course: "change mode to kernel"). This after spending the weekend writing a perfect VT-100 "trojan" that I left running on an operator terminal with some social engineering, grabbing the system user password which I then used to escalate my account's privileges.
Coincidentally, a few minutes later, the 780 threw a fatal memory error and shut down. My 17 year old self assumed he had broken the VAX, returning to work (I was an intern) on Monday morning expecting to be fired.
Writing the trojan, which had to correctly implement all the terminal timeouts, responses to ctl-y and so on, was quite a challenge. Required me to understand $QIO, by reading the microfiche copy of the terminal handler BLISS-32 source code.
I remember when I developed Java for OpenVMS. On Unix you send a kill signal to get a thread dump from the Java process. On OpenVMS you sent a mail to the process! Something like a mail, it was not a SMTP mail but mail-like.
It wasn't entirely true even before io_uring. The previous Linux AIO API has too many caveats and pitfalls, but there were narrow use cases where it could do genuine non-blocking asynchronous disk IO.
Yup - assuming you had filesystem support anyway. Seastar has a useful tool named “fsqual” for determining whether a given filesystem is capable of using kernel async IO in a non-blocking fashion.
Yes and TCP/IP support in general on VMS was not great. Performance was a consistent problem. It was clearly a second class citizen for a very long time.
Part of my day job is maintaining our home-grown data processing system on an old VMS (Itanium) cluster. We've been trying to get rid of it for close to 7 years now but don't seem much closer than when we started.
For things that OpenVMS is good at, it is REALLY good at. Everything else... is pretty antiquated.
Did VMS TCP/IP support suffer due to poor effort from Digital, or as an inherent side-effect of the kernel design?
Could poor TCP/IP performance have been a consequence of 'real asynchronous I/O support'?
Berkeley sockets is obnoxious [Example]. But the advanced user can get fine control over it. If you have a use-case that is vulnerable to back-pressure, with Berkeley sockets you can manage that away. Some friendlier API designs would have worse options.
Berkeley sockets is ubiquitous, and there is not much to compare it to. Insights from VMS would be interesting.
--
:Example. A selector indicates that a socket is ready for read/write. But what that actually means is contextual, depending on whether it was created as a client or server socket. You can't attach metadata to the socket to assist with that. Rather, you have to maintain parallel structures.
IMO, one of the significant scaling bottlenecks for VMS was there were only a handful of spinlocks that governed kernel activity. The one that I remember was IOLOCK8 (sp?). Any ethernet frame handling would have to hold that for a period of time. The underlying code that those stacks use to manage their inbound ethernet frames is likely quite old and would require significant work to reduce contention around that lock.
To put it differently, a modern 10 gig ethernet card likely generates too much traffic to be effectively handled by that code. And if you had more than one 10 gig card in a box, they would contend around that common spin lock.
I'll add in that you could run a fairly simple program on Linux that simply blasted out very small UDP packets and point it at a VMS node - any port is fine - you'll drive up the interrupt mode on that box. You won't need much traffic. Smaller packets are better because you want to punch it with lots of packets. It won't be much actual bandwidth. VMS performance here is kind of sad.
As a bonus feature, if your VMS TCP/IP stack is configured to send ICMP replies when there is nothing there at the given port, you'll create even more grief because now the stack is busy trying to receive the blast you give it and send out replies too.
Are you talking about a lock held for regular interrupt-driven packet delivery, or a lock held even when an Ethernet card wants to DMA into a kernel ring buffer?
I don't think DMA is an option in VMS land. Just a lock held for regular interrupt driven packet delivery. Been a while since I've dealt with it.
This provides an in-depth description of the VCI API which is used to write your own ethernet frame handler. Some descriptions of when IOLOCK8 is held.
> "Fat fingering" a command could have disastrous consequences; in most cases on VMS, the command interpreter will raise a syntax error. OpenVMS also has file versioning built into the file system
For all this talk of fat fingering, you failed to mention that a simple purge is all it takes for all that file versioning to disappear...and you don't even have to type out the whole 5 letters. Besides, file versioning != revision control, and there are modern interoperability nuisances with it too.
Perhaps the most annoying thing with VMS is it'll allow you to set default (equivalent to cd for those unfamiliar with VMS CLI) to a directory that doesn't exist without even a courtesy warning. It was so batshit annoying that I wrote my own implementation of cd in DCL to ensure that never happened, along with updating command prompt to reflect current directory (just like Windows cmd) and certain bashisms like ~ for home directory, etc.
The VMS directory structure is bizarre when you first see it. dev:[dir1.dir2.dir3]file.ext;rev for a full path... Don't forget about [000000] for the root directory.
None of those things are helpful when it's a restrictive commercial endeavor. There are many things that are technically very fancy but simply unreachable by most people due to administrative restrictions. Those restrictions are a far bigger barrier to usage and success than the technical capabilities, especially in a dynamic, fast-moving and interconnected world.
I suppose that is also why this was posted here on HN: being tied to the grace of some commercial entity isn't exactly pleasurable.
But there are high end applications where companies are willing to take that hit. OpenVMS is used in some nuclear power plants. When you have data coming in from tens or hundreds of thousands of sensors, and processing that data is vital to keep things from exploding, you want something that can process it all in real time and never crash.
BASF's STOP is another example of a very specific purpose operating system geared entirely around security.
Are you familiar with the instrumentation on nuclear plants? I can’t imagine there are high tens of thousands or hundreds of thousands of variables let alone sensors to be monitored. On the hydro plants I work on there are about 1000 variables per turbine generator unit and another 1000 for the substation and river system that are centrally recorded.
Yes, but that doesn't have much to do with hobbyist or student licensing, does it. If you are an energy company you probably have some sub-sub-sub budget line somewhere for 'computer license' stuff.
You can run elderly software that was written for it.
At one point there was a paid app on Android that ran a VAX emulator. (A port of simh I think.)
A 1GHz phone ran the emulator faster than any real VAX ever was.
I once offered to set up a copy of an old corporate accounting "app" on said emulator for our accounting dept. (They occasionally needed to refer to old reports still available on the old VAX system.). On the chief accountant's own phone.
I have no experience with VMS, but I always thought a similar limitation was weird on Windows. On Unix you can replace an active descriptor with dup2(2). On windows, whatever HANDLEs you have at CreateProcess you are stuck with forever. You can replace the CRT's integer descriptor or SetStdHandle, maybe they have freopen these days too, but these are usernode abstractions. Sometimes I would like to swap the kernel structure backing a HANDLE after it's created.
You do have to take care if you're replacing a handle underneath an active program even with dup2, though. The file descriptor replacement is atomic, but higher-level code in the process (such as struct FILE in libc, or similar in other languages) may have buffers that it hasn't finished flushing yet.
Not having dup2 is annoying though. With win32 you cannot make the change automatically propagate to child processes. You need to specify the handles in every CreateProcess call. Sometimes that happens deep inside a library and you can't modify it.
Assuming you know exactly what buffering everything in the process does. But you just mentioned a case of something that "happens deep inside a library".
I absolutely agree that dup2 should be possible; I only mentioned that replacing a "live" file descriptor isn't necessarily simple (unless your program is currently quiesced).
> But you just mentioned a case of something that "happens deep inside a library".
Well, if we're talking C, if you have the same libc as all your libraries [not true on Win32, but true on recent popular Unix-like OSs], you should be able to safely fflush and dup2, then call into any applicable library code ...
But anyway, I think the difficulties with it are much larger in the kernel than in user land.
I could very well imagine a scenario in which supporting dup2(2) required more locking and reference counting of kernel objects. I.e. any kernel thread currently operating against the data structure backing a descriptor must have that operation survive a dup2.
freopen() has been around and working as intended on Win32 for ages. And this works for all userspace in the same process (i.e. it's not just FILE* that gets redirected, but everything going to stdout regardless of how it gets there). So I'm not sure why the kernel side of it would matter?
It had lovely first-class support for batch queues, local and distributed, with load balancing, quotas, forwarding, etc, which you still cannot get on a Linux system.
It had great shared/cluster filesystems, that came standard, that have only been replicated in about the last 5 years in Linux (see Gluster/Ceph/etc), and the Linux equivalents are (still!) less well documented with much higher admin overhead.
The downside was, of course, that all those great features worked only with VMS software and hardware, and only with specific combinations of the above.
I take it as diversity thing. Everything is so alien to Windows-GNU-Linux mental model. Not sure if there’s any immediate value to it but fossils of dinosaurs tells us what we did right or wrong.
I'll just say that it's fun to play around with... something different. It's like an alternate dimension. One of the first multi-user machines I worked on, back in the late 80's, was a VAX running VMS so I have fond memories of it.
Use an almost memory safe for systems programming (BLISS) for example (from the point of view of ALGOL linage).
While it kind of applies to Windows with C++/.NET Native, UNIX clones are relatively far from it. Although Apple and Google's forks are also moving into that direction.
Then the OS is relatively quite robust, there are several histories of uptimes measured in years with VMS systems.
Someone may correct me if I'm wrong, but I think OpenVMS is used for real time testing of embedded controllers, for instance automotive computer modules.
VSI (the new owners of VMS) have created a new Hobbyist program. It is intended to run inside a emulator, but I imagine with some creativity it could be deployed onto real hardware.
The big downsides are:
A) You have to reinstall/recreate the emulator image when it expires - they don't hand out new keys.
B) No images for VAX (probably the most popular platform for emulation due to SIMH)
Seriously though - looking at VSI pages it looks like basically the VMS systems team greybeards spun off into a company.
If they want to see their whole life's work survive instead of fading into increasing irrelevance, they should just open source it under a 'freemium' model. With a bit of polish/tlc and focus on that area + maybe linux container emulation support to ease compatibility issues, it would make a pretty amazing basis for a 'cloud native' and 'iot' OS in addition to the ways that it's currently used.
So they don't want hobbyists anymore? Interesting approach to growing the userbase and providing at-home labs. But maybe this is the purpose. Perhaps it is a precursor to sunsetting openvms into obsolescence?
I wonder how much bitrot and technical debt there is now accumulating in openvms?
Reminds me of IBM and z/os where they are positively hostile. Then they wonder why they can't find young COBOL programmers etc. Especially those with workable familiarity with a platform and ecosystem.
HPE licensed all rights to the OpenVMS operating system and codebase, including ongoing support and all future distribution, to the new company, VMS Software Inc., who among other things is working on an x86_64 port.
So I don't think it's so much that HPE "doesn't want hobbyists" anymore as it is I'm guessing it's a natural (and probably contractual) part of HPE getting entirely out of the OpenVMS business.
The new hobbyist program is somewhat useless to people who want to tinker with old retro hardware. I suppose you could extract the install from the VM, but that's more trouble than it sounds. If you bought a VAX or Itanic box off of ebay, you're still out of luck.
Yeah, perhaps I should have more strongly stated my "but I prefer how HPE did it point", because I agree the current VSI hobbyist program is useless to me. Hopefully by the time the current round of hobbyist licenses expire (HPE is now issuing one last round of hobbyist keys through Dec 31, 2021) VSI will have a better story for their hobbyist program for folks with old hardware (like me).
If not... VMS PAKs aren't hard to generate on your own. I always appreciated that HP provided a "legal" path, though.
Ok, I'll watch and see. I have a few old machines in the fleet which are kept running for some reason. They're mainly for fun from what I can see. Similar to the old quake server we used to have for "network testing" at the end of the day.
> With the change in ownership of OpenVMS — HP Enterprise turned over the business to VMS Software Inc. — the hobbyist program is ending at HPE. VSI is considering one option to continue hobbyist-class licenses.
It looks like HP offloaded OpenVMS and future decisions to VSI, which doesn't appear to be an HP subsidiary. Am I missing something? HPE giving out licenses for another 2 years (end of 2021) is probably what was agreed with VSI.
> Users who wish to avail themselves of HPE OpenVMS long term licenses are encouraged to purchase permanent licenses at standard prices.
It seems like HP still have the ability to issue licenses, and from the VMS Software Inc. FAQ [0]:
> VMS Software, Inc. (VSI) is the sole provider of the OpenVMS operating system and layered products. In 2014, VMS Software, Inc. licensed exclusive rights from Hewlett Packard Enterprise Company (HPE) to develop new versions of the operating system.
Edit: after carefully re-reading, I get where you're coming from: HP sold off the exclusive rights, and the company who has the rights might not want to support hobbyists.
Well, if only HP had included a stipulation that hobbyist licenses remain available in their license terms, especially since "The community support OpenVMS has received over the years has been instrumental in the success of the product".
> It seems like HP still have the ability to issue licenses
I expect they may retain the ability to issue licenses but surely not in a way that undermines VSI's business model, like giving them away for free. So they probably aren't allowed to undercut VSI in any way.
Unfortunately VSI will not be releasing any VAX processor support, so this will leave any hobbyists maintaining vintage systems in the lurch. From what I have seen, no one in the OpenVMS hobbyist community is really upset about this decision, except for the people maintaining VAX hardware. The expectation for those using Alpha and ia64 systems is that VSI will take up some kind of opensource developer license or hobbyist license before the current hobbyist licenses expire from HP.
Yeah -- when I saw a redesigned website at freevms.net, my heart skipped a beat, I thought FreeVMS might still be alive. I couldn't track jkb's original tree anymore and figured I'd link to that Github project instead, as it had a few additional commits and, thus, a higher chance of running on more recent emulators.
First, the code around the L4 kernel (Pistachio) is still available. I've cloned it to github here so as to not overload jkb's personal server (still in the origin):
The "Open" was added to suggest harmony with POSIX, Motif/CDE and other standards. OpenVMS was a proprietary OS used on VAX and Alpha computers long before DEC was bought by Compaq (and then HP) and the name was not suggesting open source the way OpenSolaris does.
(Most of) the source was distributed with the operating system binaries, as microfiche.
I spent a few days peering at an old 'fiche reader figuring out how VMS stored user-defined account text in the process control block. We were doing chargeback you see...
The fun bit was the explanation of how a VAX booted VMS. The Cheshire cat was the mascot: the CPU was set up to have real and virtual addresses line up, then the VM bit was turned on, and...presto, no cat.
I know there are places that still offer support for MPE/ix so I am sure people are relying on it. HP EOL'd in 2006 and stopped all support in 2010. System was around for about 40 years and I spent about 4 years in the mid-90's working on a few of them at a manufacturing company. I was working on a pair of HP-3000 that were bought in the last 70's. I got invited to the last powering off in 2002.
Nice unique little systems. If I remember right, by the mid 80's the CPU was emulated on a PA-RISC chip. Also, at some point the HP-3000 ran MPE XL and the HP-9000 ran HP/UX using the same hardware. SPL (system programming language .. cr native name there) was .. interesting. I still have some of the OS manuals lying around attic.
It then took about two months for the thick envelope containing a booklet, some promotional material from a bunch of sponsors, and my membership card to reach me by snail mail. I'd given up hope by then -- the local post service is extraordinarily bad and I assumed they'd lost it.
I still carry my DECUS member card in my wallet, and it's getting harder and harder to explain what it is...
Edit: the world is a very small place. Many after that, it turned out that one of my colleagues at the time was also a DECUS Munich member. He was an extraordinarily bright German physicist, many years older than me, doing research at the same lab where I was working at the time. I don't know how many members DECUS Munich has, or had, but oh boy!