I just hope they are doing drivers only for devices found in mainstream VMs. It would be a fool's errand to try to keep drivers up to date with real hardware. There is no practical benefit to anyone to run VMS outside a VM, but there are still important VMS applications that would run perfectly happily and reliably on maintained equipment in VMs forever.
IBM's AS/400 system (now called i series?) was designed for that from the start. There never was an AS/400 machine, it was always emulated. Programs started in the '80s are still running, migrated from one physical host generation to the next without ever being shut down.
There absolutely was, and is, an AS/400 machine. Originally, it was a custom (and kinda weird) CISC processor and associated specialized I/O architecture. Now it's a customized Power derived processor and a somewhat more standards oriented I/O architecture. There is an extremely well defined abstraction layer that the applications run on top of that allowed them to be migrated, but it's intimately tied to the physical implementation of the underlying AS/400 hardware.
I'm not an AS/400 expert, but did work in one of the largest AS/400 shops in the world for quite a while. The AS/400 folks definitely didn't live migrate apps CISC->RISC when they upgraded. Sat is lots of change management meetings there. Could they have? Dunno. But they sure operated like that was SOP.
Within the last few years, the IBM i systems use exactly the same CPUs as the AIX systems. In fact, I believe they sell the same models of servers to support both OSes.
AS/400's were physical boxes - I worked on them back in the late 80s, as well as system/36(38?). They even had a PL/1 compiler, if you couldn't stomach RPG :-D
I guess IBM must have offered that since a long time ago. I always find that whatever is new under the sun, IBM did it a long time ago. And their name for it is always something else than what it's called nowadays.
I'm genuinely looking forward to this. I used VMS back in the 90's and loved it as an OS. Clustering, versioned file systems, reasonably well formed error messages; it seemed very civilised.
It'd be nice to be able to run it in a VM and see how much I've forgotten. I've got an old workstation in my loft, but haven't really got the room to have it setup.
VMS Clustering was very interesting. It was basically baked in to all layers of the OS, if I remember. You could access devices, file systems, users, batch queues, processes, etc. across the cluster. It felt very well designed.
That's one of my enduring memories of VMS, and something that came as a shock when I came to different OS - the lack of clustering. We had (As far as I remember) two vast servers called Alpha and Beta (With Gamma as a dev server). They were the size of a full-size rack for a single server. But from a developer perspective, my processes would run seamlessly across both of them and see a single FS, a single set of processors and RAM.
That and developing in Vista4GL. I'd kill to get hold of some manuals for that to remind myself what my first professional language was like.
DEC had some innovative ideas with VMS, for sure... 40 years later, we still don't see anything quite like its clustering with Unix / Linux. I'm happy VMS Software is keeping it alive.
I used TruCluster (late 90s thru 2006) which was Tru64 UNIX (from DEC UNIX), I think it shared a lot of tech with VMS clustering. Many interesting ideas, such as being able to write to the filesystem with a guaranteed IO rate from any cluster node (100MB/s at a tiime when that was a lot) and many other things that are less interesting after you rewrite your software around not needing clustering.
the VMS HELP system was my introduction to "learn a system by using depth-first HELP". I also recall eventually coming across the page which explained dynamic linking (I couldn't even link hello world with my 2 block disk quota).
128 MB memory. The alpha emulator. Suddenly wake up.
Still remember for old time sake do some 360 assemble on an emulator. Suddenly I aware that is 16 MB not GB ... and I use a 24 MB one to support thousands of users in 1980s.
Yup - having started with early Mac's and PC's in the late 80's and 90's, running into VMS in the 90's and experiencing a "real" operating system was an eye opener. The versioned file system was so cool and obvious I can't believe it never caught on with other platforms. Much nicer than snapshots since it was at the file level (different solutions for different problems!)
I bet VMS's versioning could have been the foundation for a fast, powerful and reliable de-dupe too. Hmm...
I hammer at OpenVMS for 40+ hours/week and this is exciting!
We hit 99.99% uptime with new software features being installed being the reason for the downtime we've had (except for one instance a bunch of years ago, but at that time I would have been in middle school. I do worry about a slowly increasing reaction time to user actions though.
Running on X86 we wouldn't have to worry about the future.
We store the critical customer data (their personal info, what they are paying us for and their settings), build the interfaces for customer service, apis for s that are used on customer web/apps and logic for what is to happen for each call. I'm a dev but including our devs, database and hardware people we are less than 0.05% of the company employees.
I'm the youngest and almost everyone is 2x+ my age. We've lost 40% of the team to retirements since I joined two years ago.
It's a tight team but communication is oh so inefficient whenever someone is working remote and between our two locations.
We have other services now that we make calls to to get for example mail and email sent to customers, but now and then I still see customers receiving plain text email from the production machine D:
And I guess the process of requesting and installing a license changes from time to time. This page describes a slightly different process for activating the license which worked for me:
While security is being mentioned as one of the strengths, and I certainly agree with that, there was a version of VMS in the late 80s which wouldn't let you create a password if another account already used it. In a small department it wouldn't take more than 15 minutes to hack into someone's account.
It's cool that this exists. I might even try to port a program to it, for my own amusement. But I don't see the big draw.
VMS had its pros and cons as compared to Unix/Linux. VMS' help system is really nice. However, VMS filenames are baroquely complex (yes, automatic versioning can be nice, but the rest of it was insane). Even at its height, VMS lost to Unix, and Unix plus Linux are now completely dominant in the areas VMS once filled and has had decades to fill in missing capabilities. I don't see what the big draw of VMS would be over Unix/Linux, at least enough to justify it. The world doesn't need another proprietary operating system, especially one incompatible with what people have now been doing for decades.
I don't think its going to get any design starts, nor is that the intent. There are companies with rock solid legacy applications that want to continue to run them on newer hardware. VMS first ran on the VAX (long dead), then Alpha (dead), and finally Itanium (recently dead). x86 will let these legacy apps run for a few more decades.
As much as anything I believe it's a mix of nostalgia and appreciation for what came before. I don't think anyone is suggesting Amazon crank up micro VMS instances for taking on modern workloads. Although as the person below me suggests there may also be a niche market for hosting legacy applications a little while longer.
This used to be my favorite OS. I am pleasantly surprised to see it is still around. The security model at the time was vastly superior to Unix. I maintained the SMS gateway for a mobile provider on it. OpenVMS on Alpha had incredible performance and stability compared to the Unix system counterparts at the time. (comparing rack space real estate that is)
I'm totally looking forward to this. I got access to the VAX and Alpha kits from HPE, but I've always wanted to run it natively on x86. :) OpenVMS rocks.
> I'm very interested to know why this port is taking so long. Few human resources?
That would be my guess. I don't know how big VMS Software is, but I doubt they are that big. The market they are addressing is limited in size, and is almost certain to shrink rather than grow, so it would be difficult to justify a massive investment in developers.
OTOH, how long did the VAX->Alpha port take? How long did the Alpha->Itanium port take? How long would have HP taken if they'd decided to commit to an x86 port themselves?
It sounds like both took about two years to reach first boot on the target platform. Both involved considerably more people and resources than the VSI port to x86.
Also consider DEC and HP had enormous engineering organizations. And Alpha was designed as extension of the VAX architecture, so presumably the port was less complicated. You can still find references to "EVAX", for "Extended VAX" in some of the headers, along with the EV* CPU model numbers. Itanium I know less about...
It’s still unmatched for seamless language interoperability.
vMotion is a sort of crude version of VMS live process migration between nodes.
The security model is very well thought out, beats rwxrwxrwx and setuid hands down. Versioning filesystem, and RMS means the filesystem is a simple database too.
DCL seems weird but all the commands work the same way, take the same arguments and so on. You can guess with a very high chance of being right. And if you can’t the help/error message is actually useful.
Rock solid stability. Generally very easy to manage, one sysadmin can do a lot.
> It’s still unmatched for seamless language interoperability.
I don't know about how it works on VMS, but Microsoft's COM is the only other attempt of language interop I know of. Recently I implemented a COM server, added `IDispatch` to its interfaces and suddenly I could control and test it from Porwershell with no extra effort on my part. Like, magic.
I’ve used COM (and before that CORBA) but these operate at a different level of abstraction. On VMS calling a Pascal function from FORTRAN “just worked” and then you could pass the return value to a C function or BASIC and it was fine.
VMS IPC was done via mailboxes, send a message to a person or a program was the same. Which sounds weird to anyone used to the way Unix does mail, but it worked very well.
(Yep, VAX BASIC was a serious language used for real, production applications)
A lot of modern Windows kernel API looks exceedingly familiar to Unix. I would think perhaps early Windows was close to VMS, but as they tried to bolt on a POSIX layer it seems it has drifted.
Features of VMS like transparent clustering are missing, for example.
As you move up the stack it looks more Unixy. The core is VMS-like and I can see the similarity, but it seems to me the majority of the code actually written exists in a middleware layer that is maybe not as far from VMS as Linux, but not quite VMS.
Names can be quite different. I remember looking at the disk stack and thinking it looked quite similar, save for completion ports.
The pragmatic reason is that there are enough organizations out there that depend on it and porting away from it is expensive enough that it is cheaper to stay.
Nothing, really. The world moved on but a lot of fanbois didn't. I learned to code C on a VT420 and used VMS for quite a few years, many professionally. I never felt it was anything superb at all. As soon as I learned UNIX (and I've used every brand and flavor of it), there was just no comparison at all. SunOS and later Solaris were my favorite until Linux matured.
One of the first multi-user systems I worked with ran OpenVMS, so I have a fondness for it and related nostalgia... DECnet, VAX BASIC, etc. I've run it at home on Alpha and VAX emulators.
I needed to "get around" on OpenVMS in a previous assignment. Some java processes executed there and needed my attention from time to time. I never became good friend with it and never "saw the light". I much prefer Linux.
I think we all prefer what we're most familiar with. VMS hearkens back to an era before tab completion was common and it still throws me when I have to type DIR instead of ls.
But... VMS does have some interesting features. Even if you prefer Linux, it's interesting to compare the two and read about why the VMS designers did what they did.
To follow up on the previous reply, there are OpenVMS instances that have uptimes measured in decades. Not everyone needs this; in the past 20 years we've all learned how to distribute applications onto arrays of consumer PCs. But for some organizations and some applications, long uptimes are a BIG DEAL(tm).
Also... VMS makes sense in a way that Unix never did.
Applications that run on OpenVMS tend to be really important and have been in continuous operation (including upgrades where new ISA's were introduced) for decades. It was ported to Itanium and missed out on taking advantage of the 64-bit x64 wave. As Intel has moved high end reliability features to the Xeon line OpenVMS applications can be moved over to modern hardware.
It's not so much that it's relevant to everyone, but it's a super interesting topic watching it get ported.
Maybe in some respects.
Though I don't remember too much VMS, I know enough to remember what a god-send the Unix shells (and associated stdio tools) were compared to other command environments spawned (pardon the pun) by batch systems.
(The versioned files were both cool and annoying FWIR)
I don't think it is possible to back up that statement. In 1999, machine interoperability was not as critical as it is today.
Last time I worked with OpenVMS was 2014 going into 2015. The system in question was an orders management system for an online pharmacy. It. Was. Hell. The Alpha-based cluster was being rebooted daily because it would run out of memory constantly. They would purchase spare parts for their cluster from a local company that specialized in NOS and recovered boards bought on eBay. We had some laughs about that!
The code was ancient--some of the earliest comments in the sources dated to the 1970s. There was no source control, no modern compiler, no debugger, no anything. We used sockets to communicate to a sort-of SOAP service to get data out for reporting but it was incredibly, tearfully s-l-o-w.
The UI was terrible. The users of it complained endlessly, and rightly so. We're talking about a time when most everything out there was built on a HTML Web-based system for at least a decade already and people were well used to Web interfaces. And here these poor souls were still using terminal emulators to connect to a green screen application and had to to have all kinds of odd work-arounds and policies to get by with all the bugs and strange anomalies. Did I mention the horrible uptime?
The management kept wanting more, more, more out of the enterpise Java team but all the technical limitation were on the VMS side. Meanwhile, the syadmin who ran it was a complete turd of a human being, only trying to keep his job there lest he be forced into retraining into some actually useful technology. Worse, he actively campaigned against any technical changes we wished to make (for fear of losing his fiefdom) and so undermined my team to the point where management became openly distrustful of us. "Can't trust that new-fangled Java stuff!" "You mean the actually reliable, high-performance stuff? That stuff?"
The company unbelievably doubled down on this odious mess by purchasing the source code for the system from the vendor that owned because that vendor wanted to wash their hands of it and get out from under the hell of supporting it. When I heard what my company paid for that code I nearly had a breakdown because it was eye-watering. I could have re-written the thing 5X over and extracted the data for that kind of coin. If that's the kind of idiocy it takes to manage a large corporation in America these days then I should be a CEO because I am far more than qualified! I could show up one day a week and do less damage. Had I had a free hand at that company I could have done incredible things, but it was not to be.
Worse still, now that they owned the sources, they thought they could do something useful with it and hired a contractor who had once sort of worked on this same trash at another firm. He was charging $250/hr to be there and was the most obnoxious developer I have ever worked around. He set the bar very low on personal hygiene, decorum, and general bad behavior around the office. They had to move him out of the cubes and give him his own room because of so many complaints about odors and um, noises.
Looking back, it seems like everything related to VMS was these kind of obnoxious people--I used to hang out with the sysadmins who managed the clusters at the college I attended and they, too, had that VMS/DEC obnoxiousness disease. I don't get it, I'll never get it, am happy to be far away from it. DEC had its day, they failed to adapt and modernize and went away. You don't see this same nostalgia for Wang Computers and Wang was the true original in the mini space.
This is kind of a weird story bro. Like you’re at a deeply dysfunctional organisation with management and coworkers that you hate (maybe for good reason) but your anger is directed towards an OS that even running on junk hardware is still making your company money with perfect backwards compatibility over 40 years? Huh.
IBM's AS/400 system (now called i series?) was designed for that from the start. There never was an AS/400 machine, it was always emulated. Programs started in the '80s are still running, migrated from one physical host generation to the next without ever being shut down.