Who, and why?
I mostly worked with OpenVMS on VAX in mid-90s. They were the workhorse of manufacturing/process control systems.
21–30 of 108 posts
Who, and why?
I mostly worked with OpenVMS on VAX in mid-90s. They were the workhorse of manufacturing/process control systems.
Volume 4 issue 4 introduced the Alpha architecture and includes an article describing the effort to port OpenVMS: http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art7.pd...
Earlier quoted context omitted.
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 run…
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.
Earlier quoted context omitted.
Clustering - OpenVMS does clustering amazingly well. that is one thing that NT, Linux, and the BSDs could learn. Although, DragonFly BSD is working on the file system clustering with HAMMER 2.
Could you elaborate on how it did things better than the common cluster file systems of today? (OCFS2, Hadoop, Ceph, etc.)
It was physical PC clustering. So I group of networked computers appeared like 1 physical computer. While a MESO or DCOS can do this today, they don't offer durability.
On OpenVMS clusters if the machine running a job physically explodes you don't lose data. RAM and process state is network synchronized.
This allows for rolling upgrades. Your cluster can update and reboot 1 box at a time, but your apps never actually stop, TCP connections are never dropped ETC. For large corporations who've gotten used to these features they're awesome to hold onto.
Earlier quoted context omitted.
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 run…
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.
Earlier quoted context omitted.
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.
Non military example: IKEA.
Who, and why?
OpenVMS is more reliable than Unix, and bears a more sophisticated kernel design intended to handle real-world workloads. In particular, unlike every extant Unix except Solaris, async I/O is handled the correct way in OpenVMS (and Windows NT), with real async system calls and completion-based notification.
So Linux is not intended to run real worldloads?
Earlier quoted context omitted.
Could you elaborate on how it did things better than the common cluster file systems of today? (OCFS2, Hadoop, Ceph, etc.)
Okay so OpenVMS wasn't just FileSystem clustering. It was physical PC clustering. So I group of networked computers appeared like 1 physical computer. While a MESO or DCOS can do this today, they don't offer durability. On OpenVMS clusters if the machine running a job physically explodes you don't lose data. RAM and process state is network synchronized. This allows for rolling upgrades. Your cluster can update and r…
One thing I wonder now: how can this work?
Is there a physical load balancer in front or something?
Who, and why?
There are still a non-trivial pile of organizations out there that rely upon VMS. I still can hardly believe it myself when I run into them, but as I understand the situations when I ask out of curiosity, these are relatively lower-margin organizations, and the cost of rewriting their VMS applications for them greatly exceeds the cost of adopting a platform that is a port to a major chip architecture and emulating th…
Migrating it to a new architecture would not be trivial. That software is extremely tied into the underlying inter-process messaging protocols and data file formats provided by the operating system. You're not just working with a single monolith and flat files or any known database system for example. Though I think some were available much later.
The company did split and build a new piece of software from the ground up to replace it. That effort took nearly a decade and millions of dollars - way longer than anticipated - and so long that it was sold off to private investors for continued funding long before it ever became marketable. It does well now though and bears little resemblance to the original system except in the UI concepts and screens.
OpenVMS was a pleasure to use though I was more on the support side and didn't have anything to do with the admin level maintenance. I did manage to accidentally shut down a production timeshare instance in the middle of the day once though and impact thousands of users.
Which reminds me it had its own networking, and networking hardware, so a dealership would have VT terminal green screens and the DECnet protocol would route it over IP directly into the server. It was pretty awesome.
You don't really hear of systems that "small" these days serving thousands of simultaneous connections and tonnes of back end processing.
It had nightly batching for accounting which was a common source of problems when something went wrong because nobody really understood how it worked anymore and THAT code was mostly the very old shit.
Earlier quoted context omitted.
Could you elaborate on how it did things better than the common cluster file systems of today? (OCFS2, Hadoop, Ceph, etc.)
Okay so OpenVMS wasn't just FileSystem clustering. It was physical PC clustering. So I group of networked computers appeared like 1 physical computer. While a MESO or DCOS can do this today, they don't offer durability. On OpenVMS clusters if the machine running a job physically explodes you don't lose data. RAM and process state is network synchronized. This allows for rolling upgrades. Your cluster can update and r…
Is this as slow as it sounds?