Here's a couple of examples for you:

I Sysadmined a VMS box running on a couple of AlphaServers (2100 and 2100A) if I recall.

At one point a disgruntled employee had taken a 22 rifle into the server room and shot several rounds at the equipment, only 1 bullet hit, but it went through a RAM bank, the system disabled the faulty hardware and continued running.

The other cool part was the interchangeable boards - the system had a case that swung open on the side and you could insert cards much the same way as you slot in PCI cards today, except one of the cards could be a CPU block, or it could be RAM, so if you had a CPU intensive workload you could disable a physical board of ram, take it out, and replace with a CPU board - without halting or rebooting the OS

Ever work with Sun servers? Yeah, you could swap out cards, CPU, ram, drive, power, without halting or rebooting the OS. But not just Sun servers. This is not a feature unique to Alphaservers/VMS.

It was originally a DEC specific design copied/stolen by others. DEC created the design concept of a common back plane. Other than some logic switches to control power/enabling, there was nothing it provided. Every machine was completely customizable.

I'm not a hardware buy, but I believe this is a carry over from the VAX days long before there was SUN.

Nope! I didn't know that. Very interesting.

The Alphas had a motherboard and daughterboard - and the daughterboard was a generalized bus, so a single slot could have a RAM or CPU slot in it --- were Sun servers capable of this too? Or was a RAM slot a RAM slot and a CPU slot a CPU slot and they were not interchangeable?

I'm curious because I've never seen any other machines with a generalized CPU/RAM bus, I'm curious if Sun hardware supported this? If it did, can you remember the model numbers so I can read up on it?

discussions here too - https://www.reddit.com/r/talesfromtechsupport/comments/1jlmn...

http://www.serverwatch.com/hreviews/article.php/3688771/Serv...

What happened to the processes using the RAM?

Imagine server that has been up for decades. It can remain live through OS upgrades, hardware upgrades and I believe even architecture changes.

It's like places that use mainframes it's probably not a good idea to build a new bank on mainframes but if you have one it's far less risk to keep the mainframe than rewrite everything.

OpenVMS has some very unique features but truthfully it's most valuable feature is it runs the software they have.

But that's the thing: places which fit those requirements usually run some IBM solution (AS/400 and the likes). I've never encountered VMS in production before, so I'm really curious to some concrete examples of companies using it.

I used to work as a software developer in the UK insurance industry, and I can tell you that we (and hence several of the insurers/brokers we dealt with) used OpenVMS.

In contrast to some of the other comments here, we weren't using it because moving to another OS - or architecture - would have been a pain. In fact, our software originally ran on x86 machines at some point in the distant past, before we migrated it to OpenVMS relatively recently.

I don't know why OpenVMS was given preference over GNU/Linux, *BSD, or Windows; I'm guessing that the technical managers above me had their reasons, but I couldn't say what they were.

I left that job a few years ago, but I think that they did intend to eventually phase out the VMS systems as our new, GUI-based product slowly replaced the older text-based one.

We use it at our company (financial software). One of the reasons being that the code is older than Linux and VMS was a good bet at the time.

We have almost entirely moved away from it and onto Linux but considering the decades of code and systems built on and around it, it is truly a monumental task to move off VMS while keeping a system used by very high paying clients running smoothly.

If your employer is who I think it is - you still have many years to go. :-)

I haven't used other mainframe solutions, but one of my favorite features of VMS is logicals. Logicals are environment variables backed by a clustered key value store that's safe to use for distributed locks. Logicals appear to your process in a hierarchy of tables that inherit from one another, by default you have: job (shell subprocess) > process (shell session) > user > group > system (node) > cluster. You can also build your own tables stored with which ever chosen locality (system, cluster, etc) in the hierarchy. Meaning if you follow "12-factor" design, well it didn't have fancy name then, you could do things change configuration cluster wide in an instant.

We used to have a CNC machine controlled by a VMS box. I almost burst into tears when it was unceremoniously decommissioned while I was on holiday - that thing had been up for more than six years! (Which is not at all uncommon in VMS circles!)

Non military example: IKEA.

VMS was widely used in healthcare.

Some cable companies run it

In the days when I used VMS it was common for applications to be tied into the hardware. Therefore you only really ran a fairly bespoke set of applications that were specific to your business. Therefore it is never possible to eulogise fully about the cool wonders of VAX VMS as everything was domain specific.

I worked in remote sensing at a time when UNIX workstations were taking over the show. Again applications were tied into the hardware so if you needed an SGI for your code, that was what you had and again it was hard to fully explain the merits of a given platform in a way that makes sense to a Windows user.