VMS Software prunes OpenVMS hobbyist program Bad news for those who want to play with OpenVMS in non-production use. Older versions are disappearing, and the terms are getting much more restrictive. The corporation behind the continued development of OpenVMS, VMS Software, Inc. – or VSI to its friends, if it has any left after this – has announced the latest Updates to …
Well that sucks, though as I was already long since resigned to never being able to run VMS on my Vaxes again I guess I'm already pre-disappointed. In the case of the Vax, I'm still not sure if that was even a policy decision or because HP were alleged to have lost track of who has the rights to it.
Regarding 32-bit Unix, I have a vague memory that the Vax wasn't the first 32-bit platform as they really didn't want to risk it being a DEC-only OS; but the details of what might have been currently elude me. I still have fond memories of my first encounter, Ultrix on the college's Vax 8650. Of course we hated each other at first, all the most lasting friendships are like that.
The University of Wollongong's port of 6th edition Unix to an Interdata 7/32 completed July 1977 (reputed to be the first port from the pdp11), was to a 32 bit system https://documents.uow.edu.au/content/groups/public/@web/@inf/@scsse/documents/doc/uow103747.pdf"
I don't know whether the kernel and userland was 16 or 32 bit.
Thank you, that's the system I was trying to remember (I think). Good point about the bitness of the software, I hadn't actually thought about that; and I should probably curtail my inclination to "I seem to remember" given the demonstrable unwillingness of my memory to ever divulge any useful details.
> I don't know whether the kernel and userland was 16 or 32 bit.
Excellent point, well made.
(As an IMHO wonderful intersection of the historical and the personal, the same Richard Miller did the original port of Plan 9 to the Raspberry Pi!)
I did know of this but overlooked it.
I suspect that, as the machine had 192kB of RAM and 2 x 5MB disks or so, it was a straight 16-bit port, but I don't know that. I quickly reread the essays from the time about the port but they don't clarify.
I dunno, Liam. The Interdata 7/32 that I was familiar with (and did a good bit of programming on) were strictly 32-bit machines. Well, actually they were 24-bit bit-sliced machines, with a good bit of microcode to make them look a bit like IBM 360s, without the dreaded base-register addressing architecture. (PC-relative addressing, FTW!) I suppose it would have been possible for Perkin-Elmer to supply microcode to make that beast a 16-bit machine, but I'm not sure they would have; the main (marketing) point of the Interdata machines of that time was to pack 32-bit computing power into the footprint of a 16-bit PDP-11.
Interesting. The only other 24-bit machine I know of is the ICL 1900 (definitely not IBM compatible as some assume; all they had in common was EBCDIC) which I know so little about; I guess it's rarely mentioned in computer history sites as they never made much headway in the US. My gf's mum worked on the OS just before it was released to market, she wrote various system libraries and stuff back when they were still ICT (this would've been around 1963) but sadly died when she was young so I never had a chance to ask about it; she didn't even know her mum was a programmer until I found out quite recently, in spite of following in her footsteps. I wonder if that did something similar or if "24 bits are enough for anyone"; at least until the 2900, which I presume had more.
"FRUSTRATIONS:
In the years 1977-1980 I tried in vain to interest our industry, our university, and our government in the remarkable lead that we had on the rest of the world."
The more things change, the more they stay the same, eh?
And I was going to make a joke about "does Linux support Interdata 7/32?" but I'm just too sad, now.
> I was already long since resigned to never being able to run VMS on my Vaxes again
Far be it from me to advocate anything but I have successfully licensed OpenVMS 7 in a VAX SimH session. It can be done and it's not hard.
Next I have to work out how to cluster the 3 VAXstation 4000VLCs in my basement in Prague, and netboot them from SimH...
I still have my internal PAKs from DEC (well, in theory) so my Vaxes could just go 30 years back in time, I suppose. But apart from being a bit naughty from a licensing point of view, I'd just be all "but that's not right!" when I see the date. Currently running ITS on the PiDP-10 emulator (it has flashing lights and everything! Everyone here should have one, etc) which handles 21st century dates randomly well: sometimes it does it correctly, other times the year comes out as 124, but at least it tries. And is quite trying, as much as it's interesting to see the origin of so much stuff we take for granted.
There were a number of groundbreaking OSes from around that time, that I think I still worthy of study today: TENEX, ITS, MULTICS and of course UNIX. (Interesting that 3 of them were, at least initially, developed for DEC platforms.)
Of those, only one is still alive in some form today. It was also the only one to go portable, while all the others died along with the particular hardware platforms they were implemented on.
Coincidence? I think not.
Yeah, the Unix team foresaw that risk, probably as a direct result of their experiences with Multics, which is one reason why they wanted to diversify away from DEC-only hardware as early as they did. There was a huge furore about the PDP-10 line being canned completely and a lot of people never forgave DEC for that; and while that was a few years after Bell/AT&T had already decided to be hardware independent, it was a good reminder of its importance.
You'd think DEC would know better after the Massbus fiasco (they decided that, unlike Unibus, they'd keep it proprietary as some suit could only see how much income they'd "lost" by anyone being allowed to use the Unibus standard) but by that time it was already a company at war with itself.
《Those licenses run out in 2025, and they won't be renewed. If you have vintage DEC Alpha or HP Integrity boxes with Itanic chips, you won't be able to get a legal licensed copy of OpenVMS for them, or renew the license of any existing installations – unless you pay, of course.》
I suspect DEC's lmf licensing is clever enough to detect reset clocks but surpring how many systems aren't.
If you were just running VMS to keep the hardware functional and preserve computing history you don't really require updates, maintenance or support. Using a ground hog day loop between 2024-01-01 and 2024-12-31 (or licenses' range) isn't likely to deprive VSI of any conceivable benefit whatever the the legal position.
Bit like running Multics not that you would have a GE 645 in the basement. ;)
As I recall, it was actually a GE 635 modified with special memory-management hardware to cope with the advanced demands of MULTICS.
Just like TENEX didn’t run on a regular PDP-10, it needed one with the “BBN Pager”, again for the advanced memory-management functions to support the OS.
This was back when virtual memory and demand paging were still some kind of exotic novelty.
I don't know a lot about the BBN pager, except that they were disappointed that the virtual memory system DEC finally produced in house was supposedly too simple; but when even MIT (I think) described BBN's pager as being complicated I'm left wondering what it did. I think the PDP-6 & 10's hardware team were always in a slightly awkward position as the original remit was for a minicomputer and they accidentally got carried away and created a mainframe, but DEC's whole purpose was to not put potential customers off by being one of the companies who were already being seen as infamously expensive. They still marketed the 10 as a mainframe but had to be mindful about anything too "exotic" (i.e. costly).
I suppose a similar story with the albeit not officially sanctioned VM at IBM; back when it was still called CP, it needed to run on a 360/67. Can't remember if the virtual memory came with the 67 as standard (which would've made it a very non-standard standard as virtual memory wasn't a System/360 thing) or whether that was an additional requirement. Even now, IBM still seems to resent VM for providing an alternative to its MVS-influenced universe, even though it's probably just as influential to their current offerings thanks to it being the basis for LPARs and what-not.
According to what I’ve read, the PDP-6 was an expensive project on which DEC lost money. So they announced they were not going to bother with another 36-bit machine ever again.
Then, two years later, the PDP-10 came out.
So I would say, by that time, DEC knew full well what it was doing. The PDP-10 was a “large system”, but nobody would call it a “mainframe” in the IBM sense of surrounding the CPU with a bevy of intelligent I/O controllers that could perform a lot of complicated tasks without central intervention. IBM systems were always batch-oriented, but if any company could be said to have absorbed the ethos of interactive timesharing into its very DNA, it had to be DEC. And that applied to the PDP-10 as well.
PDP-6 had reliability issues due to its complexity; PDP-10 was essentially the same system (they were binary compatible, at least for the most part IIRC) but redesigned with newer components.
It was called a mainframe by DEC, and by most people who used it. It's only people who see "mainframe" and "IBM System/3x0" as synonyms who would suggest otherwise. Not even all IBM systems were batch-oriented; apart from the large market in transaction processing, the whole point of VM was to put a "conversational" interface on everyone's desk. PDP-10 also had increasingly sophisticated batch processing from the outset fwiw.
The only exception to "the PDP-10 is a mainframe" would be the small KS10, which I think DEC was a bit optimistic about describing as a mainframe, even in the context of "the smallest". But the rest of them were huge beasties capable of dealing with enormous workloads.
What ultimately killed off the 36-bit line was the decision to focus on the Vax. I've heard various stories about performance problems with the KC10 (a.k.a. Jupiter) but know that there was a long and ugly battle going on behind the scenes between the "large" and "mid-size" systems groups, so the exact truth of the matter seems hard to pin down; but certainly having one standard architecture that (eventually) spanned all system sizes was more convenient for DEC.
VM/CMS (or earlier CP/CMS) did that in a typically clunky IBM way: CMS was strictly a single-user OS, so the VM part allowed for multiple instances to be run, each dedicated to a different user.
Remember that DEC had already figured out how to do multiuser support in TOPS-10 and RSX by about this time.
IBM seems to get credit for pioneering the concept of “virtual machines”, but they only did it to avoid having to create a proper multiuser timeshared OS.
I quite liked CMS. It could also do system calls, albeit called "VM assists" because IBM would've had an existential crisis if they used other people's terminology (okay, it appropriated an unused DIAG instruction, but much same thing), and though it sounds clunky, its virtual card-punch/reader interface provided pretty handy and efficient communication channels. PROFS was a reasonably nice office system for its day, and while not as good as VISTA (okay, I'm biased) it was pretty popular. I was much less keen on TSO for MVS, which looked to me like a pseudo-interactive batch-job. And it was expensive, as I discovered when my idle exploration caused the department's bill to skyrocket. Oopsie.
From an end-user POV, CMS doesn't really seem that different to TOPS-10 IMHO, with the caveat that I didn't quite appreciate what I had when I used them on real hardware and now regret that I didn't familiarise myself as much as I did with VMS and Unix back in the day; and both of them influenced the CLI component of CP/M. ISTR TOPS-10 could support more interactive users on equivalent hardware tho' (but again I may be biased).
Edit: ironically, when I worked at DEC, there were no longer any PDP-10s running (at least not that I knew of) but they did have an IBM mainframe that was really for compatibility & comms testing but available to anyone who wanted an account. So I got to use CMS more when I was at DEC than I did at my previous employer who used multiple VM systems in their production environment.
Bitsavers recently added some issues of a publication called “Mainframe Magazine”. Out of curiosity, I read the first issue—totally IBM-oriented. There was an article about how CP/CMS worked, and I was surprised to discover that users could write their own privileged “channel programs” within their dedicated VMs. That wasn’t so bad, but the CP hypervisor would also trust these privileged programs and run them!
In other words, the idea of protecting users, and hence VMs, from each other—one of the key points about virtualization, I would have thought—was completely alien to this supposedly pioneering IBM implementation of the concept.
They could only write to channels they were given permission to access in the CP directory. It was handy for running entire systems like MVS under VM, for instance, but all virtual machines were protected from each other from the outset (the latter AFAIK but certainly by the time it was in production; which tended to use RACF to manage/enforce. Bleh.)
Maybe, but remember a “channel” was a hardware thing. For example, it would refer to an entire disk, not some part of the disk--the virtualization didn’t extend to storage, and there was no file-level protection either.
Is that that pakgen.c program? I went through the source: it looked like someone had disassembled a bunch of VAX machine code, and did a straight transliteration to C. For example, recreating LIB$EMUL and LIB$ADDX, when any modern C compiler already offers built-in 64-bit arithmetic?
I did a cleanup of the code, filled in a few extra functions, and also created a Python version that copes better with non-ASCII text and can be used in a more flexible way. And I created man pages for both versions.
Am I allowed to mention where you can find it?
Perhaps mention where you can mention where we can find it! As it's kinda in Big Licensing™ territory, HP & VSI are ongoing concerns and (at least) the former is litigious and the latter can be a little surly, even if El Reg would like to turn a blind eye, it could put them in a bit of an awkward position.
The other thing I remember about running my Vax was its enthusiastic power consumption: DEC installed a leased line to my house back in the '90s and I decided to put some VaxNotes stuff on there so I kept it running 24/7. Even when electricity was much cheaper than now, the bills could be a bit eye-watering. Kept the house nice and warm, though; albeit not so useful at the height of summer. I could also hear email arriving wherever I was in the house thanks to those big RZ56(? I think) HDDs rumbling and clunking away.
I'm the old VMS enthousiast who posted a letter to Meg Witman in 2013 against the killing of VMS. And I have been thrilled about the the promise of making a VMS ecosystem relaunch.
But we see VSI doesn't consider the ecosystem as a whole, and it seems VSI applies a standard business plan for legacy applications: helping some surivors, and making good business because of the rarity.
The rare quality of VMS ecosystem has always been a huge backward compatibility, which explains a special loyalty of users, and a realm alltogether old and new. Cuting in it to get something thinked of as profitable just demonstrate ignorance of the realm you are supposed to deal with.
We have really thought that the reborn of VMS was a unique opportunity of getting old chaps explaining hints to new generations. Something which could create an important innovation in the way "legacy" is dealt. Now it seems impossible to motive any of the old chaps, and more impossible to explain VMS as something of interest to new generations.
We have seen how Digital died. We have hoped we had a chance not seing the VMS survivor to dye. Is it still possible? Perhaps there is someone, somewhere, who still knows the VMS realm.
Obviously you know these enterprise operating systems big irons etc.
There is only one thing I had to double check the source on Wikipedia. It seems that while Alta vista was the number one search engine and serving as a ultra Alpha server advertisement, Google inventors demo to Digital to acquire the technology and gets rejected. Why? Because search isn't core part of Digital business.
[Author here]
> Thats a great way of marketing "shite hardware support".
Well, kinda sorta, yeah.
A shockingly long time ago now I wrote this:
https://www.theregister.com/2013/02/11/guide_to_windows_server_2012_ebook/
At that time, MS said that it was surprised anyone ran on bare metal any more, and it expected the large majority of deployments to be in VMs. Ideally for them, Hyper-V ones, of course.
That was well over a decade ago. I think it is the rule now.
AIUI VMS 9 has some degree of understanding that it's in a VM and drives the hypervisor via VirtIO.
This seems pragmatic to me, as I wrote at the time it shipped:
https://www.theregister.com/2022/05/10/openvms_92/
Why try to support a million hardware variants in your ultra-niche OS when KVM, Hyper-V, VirtualBox and VMware between then can run on pretty much anything?
Consider it a universal hardware shim. Make driving the real kit SEP: Someone Else's Problem, that time-honoured way of making the difficult bits just go away...
This post has been deleted by its author
In 1981, I was an early recruit to one of BT's fledgeling software centres. The group I was seconded to for my software (ahem) skills had a budget surplus, so they bought a VAX 11/780, only to realize that they didn't have anywhere to keep it. It was installed in the software centre's otherwise empty machine room, and I had my own personal VAX for a couple of years.
It would be fun to have a VMS VM to play with again.
SIMH offers open-source emulators for a whole bunch of classic machines, including VAX, PDP-11, PDP-10 and PDP-8, among the DEC ones. It’s included in the standard repos of the major Linux distros. And you know where to find images of tapes (paper or magnetic) and disks of the corresponding vintage OSes. Go wild.
Even better, replicas of the front panels for PDPs 8, 10 and 11 exist and can be driven by the I/O connector of a Raspberry Pi running the emulation (not SIMH AFAIK but others with equivalent functionality) so that the lights and switches work as they should. They're ⅔ scale; as much as part of me would like full-size, the 10's panel (the KA10 model) is already quite big as it is. They'll even do the soldering for a (small) fee, which is just as well as I'm hopeless at it. I think the last thing I soldered was a SCSI cable I accidentally chopped in half thanks to not noticing it was still hanging out of a minicomputer I slammed shut; I'm astonished it worked afterwards. It was a then new LVD cable, expensive at the time, though I think telling me to repair it was more a lesson to remember to be more careful in future...
Er anyway. Not sure what's planned next as the 10's just been released and everyone's still buzzing about it, but there probably won't be a Vax as they never had the pretty lights. Bah.
I’ve been occasionally hanging out on comp.os.vms for some years, and making myself unpopular by pointing out that VSI could have cut many years (and corresponding customer defections) off the time it took to create VMS for x86 by building it on top of a Linux kernel.
It wouldn’t be a complete VMS recreation: I figure, the only parts most (remaining) customers care about is their user-mode code and DCL command procedures (shell scripts). Everything else can be emulated, while the original VMS code can be dumped.
Personal view, so no [AH] tag or anything:
The Linux kernel is an extremely rapidly moving target. It has well over 450 and nearly 500 syscalls. It comprises some 20 million lines of code.
It needs constant updating and the problem is so severe that there are multiple implementations of live in-memory patching so you can do it between reboots.
Meanwhile, VMSclusters can have uptimes in _decades_ and you can cluster VAXen to Alphas to Itanium boxes and now to x86-64 boxes, move workloads from one to another using CPU emulation if needed, and shut down old nodes, and so you could in principle take a DECnet cluster of late-1980s VAXes and gradually migrate it to a rack of x86 boxes clustered over TCP/IP without a single moment of downtime.
Linux is just about the worst possible fit for this I can imagine.
It has no built-in clustering in the kernel and virtually no support for filesystem sharing in the kernel itself.
It is, pardon the phrase, as much use as a chocolate teapot for this stuff.
VMS is a newer and more capable OS than traditional UNIX. I know Unix folks like to imagine it's some eternal state of the art, but it's not. It's a late-1960s OS for standalone minicomputers. Linux is a modernised clone of a laughably outdated design.
VMS is a late 1970s OS for networked and clustered minicomputers. It's still old fashioned but it has strengths and extraordinary resilience and uptimes is one of them.
No it doesn’t. Remember, there are LTS versions with lifetimes measured in years. Just because the Linux kernel is an active project, doesn’t mean it is an unstable project ( which I think you were trying to insinuate).
And nobody ever ran VMSclusters with uptimes measured in years, let alone decades. My former employer certainly never did. There were updates every few months, and we had to take the system down to apply them.
“VMS is a newer and more capable OS than traditional UNIX” — note that I have actually used VMS, so I am not easily distracted by superficial things like calendar dates. I have also had to support ordinary users trying to cope with the oddities of VMS. Like why, after they had transferred files from their microcomputer systems, the VMS software didn’t want to look at it? It was because they hadn’t applied the right RMS record attributes to the file!
VMS “clustering” never scaled beyond, say, half a dozen nodes sharing an HSC-50 or HSC-70 disk controller. Linux “clusters” scale to supercomputers with millions of interconnected nodes.
Linus Torvalds used VMS for a while, and hated it, for one simple reason: there was no easy way to tell how many bytes of data you had in a file. VMS always allocated files in whole blocks, and then you had to look at the RMS attributes to figure out how much of the last block was actually used, and then add it all up. Contrast UNIX, which pioneered the idea that userland programs didn’t need to worry about keeping track of how many bytes were used in that last block: let the OS take care of it.
UNIX became popular because it did so many things so much more logically. That’s why Linux started as a copy of UNIX, not VMS. Of course, Linux has since outgrown that origin, and continues to evolve in new directions, for new application areas that those smart folks at Bell Labs could never have envisioned. But it couldn’t have done it if it had been built on any other base.
Thinks of why Windows nowadays is at an evolutionary dead end: it is because Dave Cutler made it a spiritual successor to his previous brainchild, VMS. Why has Microsoft found it necessary to introduce an actual Linux kernel into Windows with WSL? Because the only path forward for Windows is to wrap it more and more around Linux.
Yeah, no. To refute a few points:
> Remember, there are LTS versions with lifetimes measured in years.
Point missed error. "This is a single point release! We are now on 4.42.16777216." You still have to update it. Even if with some fugly livepatch hack.
> And nobody ever ran VMSclusters with uptimes measured in years
Citation: 10 year cluster uptime.
https://www.osnews.com/story/13245/openvms-cluster-achieves-10-year-uptime/
Citation: 16 year cluster uptime.
https://web.archive.org/web/20120203204940/http://uptimes-project.org/hosts/os_breakdown_list/OpenVMSClust
> Linux “clusters” scale to supercomputers with millions of interconnected nodes.
Point missed. Linux clusters are by definition extremely loosely clustered. VMSclusters are a tight/close cluster model where it can be non-obvious which node you are even attached to.
> Linus Torvalds used VMS for a while, and hated it
I find it tends to be what you're used to or enounter first.
I met VMS before Unix -- and very nearly before Windows existed at all -- and I preferred it. I still hate the terse little commands and the cryptic glob expansion and the regexes and all this cultural baggage.
I am not alone.
https://xkcd.com/1168/
> UNIX became popular because it did so many things so much more logically
I call BS. This is the same as the bogus "it's intuitive" claim. Intuitive means "what I got to know first." Douglas Adams nailed it.
https://www.goodreads.com/quotes/39828-i-ve-come-up-with-a-set-of-rules-that-describe
> Thinks of why Windows nowadays is at an evolutionary dead end
Linux is a dead end too. Unix in general is. We should have gone with Plan 9, and we still should.
VMS clusters were far more limited than you seem to think. You don’t have to take my word for it: go read the docs for yourself, at Bitsavers and elsewhere.
DEC created its original VAXcluster concept back when other vendors were offering proper file servers. Instead of doing the same, it created a shared disk controller, with the same filesystem mounted in parallel across multiple nodes. To avoid stepping on each others’ toes, the nodes communicated via a protocol called SCS, which implemented distributed locking. What made things simpler was there was no data caching going on at the time.
Note that none of the other usual VMS IPC mechanisms—mailboxes, shared memory, common event flags—worked clusterwide. In no sense did a cluster look like one big machine. Looking at processes and terminals and other devices on one machine did not show you those on other machines. They were still very much separate machines. Even doing remote admin between them required a separate DECnet connection!
About ten years later, the next big innovation was the addition of clusterwide logical name tables.
And that was it. That was the sum total of what VMS clusters did for you. And, like I said, it never scaled beyond the maximum number of nodes you could attach to the same shared disk controller.
It was Linux that offered the choice of tight or loose clustering, not VMS.
And yes, UNIX became popular on its own merits. There was no big corporation pushing it: remember, it came from AT&T, which didn’t even have a presence in the computer market. It was the customers who forced the vendors into adopting it.
“We should have gone with Plan 9” ... nothing’s stopping you from joining that “we”. Go on, try making it your daily driver for a few months, and let us know how you go.
Ugh, I always hated the fad for prefixing everything with "Open" in that era. I forget if there was even much difference been VMS and, er, VMS (I still refuse to call it that) other than UCX being included by default. And even that I'm not 100% certain of. All I remember is the warning that it would no longer fit on a single 100MB HDD (which included space for its paging and swap files) which seems microscopic by today's standards.
Context: I have fond memories of VMS 4.X on an 11/750, in 1985-87. In 1984 I first saw Unix on an AT&T 3B20, then DG/UX on an MV4000. Yes, there was a version of DG/UX for 32 bit Eclipses, though I don't know if they ever offered it for sale. As late as '87 it was unusably buggy. Oh, and Venix - which would have been Unix V6 on a DEC Pro/350. I got my first exposure to MSDOS and the original Mac OS in the same three-year window. I was young and it was like drinking from a firehose.
Point being, I liked all of them and still do. It broke my heart seeing DG get bought by EMC just for the CLaaRION storage array business. I'd hate to see any of the others go.
So I ask from a position of respect and genuine curiosity: How much VMS is still running out there? Presumably enough to keep a company running, but how big? One person? Ten? Twenty? How many commercial VMS operators does it take to support one VSI employee? (If the answer is "The Navy" then that changes everything, doesn't it?)
My gut feeling is that developing a hotspot re-compiler and emulator for Alpha might be a faster way to go. I don't how advanced the emulator was for the Student License, though, so maybe that proved to be a dead end. I guess it would have precluded ever making the move to 64 bits, but then I doubt the application software was ever going to make the move anyway.
I know a consultant who was keeping Wang VS systems running until he retired about 15 years ago, so I know how long it can take for businesses to decide to get rid of working stuff.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
