Story time. My first job out of college, working on the port of VMS from VAX to Alpha AXP. This was before it was renamed OpenVMS (Posix team in Italy!) and when Alpha was still a codename (possible alternates for final choice of product name included VAX-2000, and MondoVAX (still my favourite)).
I was assigned to port the Bad Block Detector (BADBLK? I don't remember exactly) to the 64 bit architecture. The 'port' turned out to be change the build files to use the correct compiler and flags. I don't remember if the tool was written in PL/1, Bliss or VAX assembler, but we had compilers (yes, even for VAX 32 bit assembler) for all of them. The interesting part was the testing.
A Bad Block Detector is a piece of software that watches for disk blocks going bad, and remaps them to spare capacity (your spinning rust disk is lying about its size - don't know if this is true for SSDs). It might even try to copy data from the failing blocks to the remapped space if there's time. More modern h/w does this in the firmware on the drive. It's transparent to the OS. Testing this behaviour is... challenging.
Recipe: Test the Bad Block Detector
Serves: millions
Time: A couple of hour elapsed
Ingredients:
- a VAXstation - i.e. a biggish desktop machine that can run Alpha emulation well enough for our purposes. All of its disks are connected on a SCSI bus.
- a 3.5inch floppy drive with a SCSI connection (yes, you read that right)
- a box of 3.5 inch disks
- a paperclip
Method:
Boot emulated environment. Set cross compiled Bad Block Detector running. It watches for 'interesting' disk related events.
Insert floppy disk. Note the Bad Block Detector does nothing (because disk has no bad blocks.)
Take paperclip in right hand.
Take fresh disk in left hand. With pinky finger, push back the sliding cover that protects the delicate rusty surface.
Using paperclip, gouge a few hundred kilobytes of damage into rusty surface.
Replace good disk with scratched disk.
Watch console for proof that Bad Block Detector woke up, spotted the badness, and remapped its little heart out.
Serve to delighted and amazed customers.
Loose billions of dollars, arrange purchase by Compaq, rinse, repeat.
In a not very big town in Northern Europe, I cycled past Digital Equipment offices on my way to school. They had such a huge work force all over the world, and sunk into the ocean almost without a trace.
You had to be the best of the Best to work for DEC —not a nerd-hipster (like the talented, but not trained or experienced techies at Apple and Microsoft). Apple and Microsoft were all over us trying to get us to quit DEC by falling for their limos and food courts (our CEO drove a Pinto and we wore suits because it neutralized people coming from different backgrounds as being equal, so we could truly work together regardless of our socioeconomic background, not because we were jerks like LSD-dropping Steve Jobs, who was off screwing Japanese investors out of $100 million in 1989s money with in his magnesium Cube at the time). A couple things happened to change it all, but the gist of it is that Dave Cutler finally cracked and defected to Microsoft (he’s the Ace of Aces behind all major DEC systems from 1970s forward and now behind NT and Azure) and the DEC boardroom was anxious about Intel having appropriated DEC’s revolutionary RISC processor tech that would go on to give us the last 35 years of the otherwise dead X86 tech that was cheaper because it was being sold in high volume by an army of PC clone makers. First the Board sold DEC’s Hudson division that made the groundbreaking Alpha and StrongARM chips to Intel (as a settlement), and then they sold DEC itself. There is a lot more to the story, but that’s pretty much the bottom line. What happened to the people? Cutler took many, when Google and Amazon became a thing, they tracked some or us down (including YouTube founders) and took some. The vast majority were sent to the benches (permanently). I heard a rumor that DEC’s then youngest senior level worker ever today hangs out on here sometimes and has a reputation of like 11 because truth sort of conflicts badly with all the crap that bloggers wrote for the current generation over the past 35 years. You see, those bloggers were maybe computer store (like shoe store) salesmen, but probably were just slightly smart school children when all of that reality was goin’ on. RIP Ken Olsen. FU Dave Cutler.
Intel is having a heck of a time now getting rid of that campus in Hudson. They're trying to sell it to Portman Industrial, who want to redevelop it as a warehouse and trucking facility. But folks at the abutting senior living developments have put up a huge stink, suing Intel and the town and picketing on the street outside the location.
I worked with an ex-DEC guy up in Nashua NH, and even he knew that DEC screwed up big time by being too engineering driven. The NIH was so strong there that they made their own in-wall receptacles (probably apocryphal).
Bob apparently hired Bricklin (the visicalc guy) at DEC. Hi bob if you're out there!
You seem bitter. Maybe you should grow out of this weird believe system that only hard-core techies are worth their salt or something. The world works different than you want, which seems to frustrate you greatly. Maybe accept it and be a bit happier?
Posting a salty anecdote of loss and missed opportunity from the early (presumably) days of ones career doesn't necessarily mean someone is bitter in general.
Fair point, but inferring from a comment or two that someone must use the wrong brand of paper towels at home and then constructing an ad hominem around that is the true soul of HN discourse.
One of the primary uses for computer technology today is displaying ads at any cost to society. This isn't what those who worked in the field in the early days envisioned. You can't blame them for being mad about it. I wasn't even there and I'm mad about it.
- GMT
- GMT-0
- GMT for a second time
- GMT0
- GMTPLUS0
- GREENWICH
- UCT
- UNIVERSAL
- UTC
- ZULU
and "FACTORY" that likely is either UTC or a semi-random US timezone. Overall this thing has a strong enterprise smell from the eighties and nineties, and not in a good sense.
Edit: on another glance, it's funny how much the linked article, online documentation and UI put emphasis on license management. We're here to make money, son!
VMS goes back to the 70's, now across 4 architectures: VAX, Alpha, Itanium, and now x86. I'm sure it has accumulated a ton of cruft for backwards compatibility.
I worked at a VMS shop for a bit during college and shortly thereafter! It's fun to play around with, but nothing I'd want to deal with full time.
That's what I did and this was the reply: "For now, we are gradually providing the community license to existing applicants, so currently we cannot say how soon we start giving the x86 license to new users. Still, we recommend you to wait until the new form is available and apply for a personal license."
“Open” in the 80s and early 90s sense of “open systems”, i.e. it implements open standards such as POSIX. Back then, it was common for vendors to incorporate “Open” in their product name when they added POSIX support. As well as OpenVMS, other examples included ICL’s OpenVME, IBM’s MVS OpenEdition (now known as z/OS Unix Systems Services) and z/VM OpenExtensions (originally also named OpenEdition), and Softway’s OpenNT (an add-on which improved the POSIX subsystem of Windows NT, predecessor to Microsoft’s SFU/SUA). Another less obvious example was Siemens BS2000/OSD - the “O” in OSD stands for “Open”
Other products were labelled “Open”, not due to POSIX, but rather because they implemented the Open Systems Interconnection (OSI) protocol suite. Or Apple’s OpenDoc, which was intended as a cross-platform open standard alternative to Microsoft’s Windows-only OLE (and indeed was adopted as an open standard by OMG, albeit it didn’t last long)
Remember the term “open source” wasn’t even invented until 1998, so criticising something which was first named OpenX pre-1998 (as OpenVMS was) for not being open source is rather anachronistic
I still find BS2000 to be the coolest name of any OS out there. Siemens being a German company, and the system going back to the 1970s, I'm almost certain it stood for "Betriebssystem 2000" originally (Betriebssystem being German for operating system), which is so quaint. And of course, in English speaking countries the acronym BS has another meaning that makes it even more delicious. ;-)
> I'm almost certain it stood for "Betriebssystem 2000" originally (Betriebssystem being German for operating system), which is so quaint
Indeed it does. In fact, Siemens used to also sell BS1000 and BS3000.
BS3000 was a rebranding of Fujitsu's MSP operating system. Fujitsu claimed that MSP was a "clone" of IBM MVS, but it turned out that they'd actually stolen a lot of the copyrighted MVS source code from IBM and made minor changes to try to hide the theft. When IBM sued Fujitsu, Siemens stopped selling BS3000; Fujitsu ended up having to pay IBM hundreds of millions in damages (and Hitachi too, who were doing the same thing independently). I don't know if IBM sued Siemens, they may have accepted their claims that they didn't know the code was stolen and were a victim of Fujitsu's lies about its origin.
Both BS2000 and BS3000 were for IBM S/370-compatible mainframe hardware (albeit only partially compatible in the case of the BS2000 machines). But while BS3000 was an illegal copy of MVS, BS2000 was a completely incompatible operating system, which Siemens had bought from RCA, being originally RCA's TSOS operating system for its RCA Spectra 70 mainframe line. Siemens' mainframe business started out first by reselling and then by licensing RCA's, but ended up surviving a lot longer than RCA's did. Like Siemens' mainframes, the Spectra 70 was compatible at the instruction set level (at least for unprivileged code, there were some incompatibilities in privileged instructions), but had an incompatible operating system–in fact the first Siemens mainframes were just rebadged RCAs, but later Siemens went on to design their own machines. Another vendor who copied the IBM S/370 ISA but with an incompatible OS was Wang (with their Wang VS machines).
BS1000 was a lower-end operating system for the same hardware, I don't know much about it. It was for the Siemens 4004, which was a rebadged RCA Spectra 70. Random fact, the computer shown in the 1971 film "Willy Wonka and the Chocolate Factory" was a Siemens 4004.
In 1990, Siemens ended up buying Nixdorf, who had their own line of operating systems for clone IBM mainframes, which Nixdorf had acquired by buying the US firm TCSC in 1980. However, shortly before the Siemens acquisition, Nixdorf decided to kill its own IBM mainframe clone business, because it wanted to focus on Unix instead. And then in 1999, Siemens transferred their computing business to a joint venture with Fujitsu, and then 10 years later Fujitsu bought Siemens out, so now BS2000 belongs to Fujitsu. BS1000 and BS3000 died years ago. Fujitsu also has the ICL VME (aka OpenVME) operating system they got by buying the UK mainframe manufacturer ICL, and they still have MSP, their stolen copy of MVS – IBM agreed they could keep on selling it in Japan if they paid compensation and licensing fees to IBM. But while Fujitsu MSP still exists in Japan, it is stuck in the 1980s, it hasn't received any new features IBM introduced post-1990, and Fujitsu never managed to keep up with IBM's advances. In 2001, MVS (or OS/390 as it had been effectively rebranded) went from 31-bit to 64-bit addressing and in the process became z/OS; Fujitsu MSP is stuck on 31-bits. (Yes, not 32, 31–IBM decided to reserve a bit for use as a flag in every memory address.)
IIRC, Nixdorf was - alongside Fujitsu - an early investor in Amdahl. Both companies went on to resell Amdahl machines under their own brands in their respective home countries. I didn't know about TCSC, though.
VAX assembly is much higher level than x86. It’s closer to like B than assembly we’re familiar with. I believe they ported the kernel to C or Bliss in the alpha transition in the 90s because well alpha doesn’t speak VAX and no one wants to write an OS in RISC assembly
"Digital developers wrote the VMS kernel almost entirely in VAX assembly language. To be portable across different CPU architectures, Microsoft developers wrote NT's kernel almost entirely in C. In developing NT, these designers rewrote VMS in C, cleaning up, tuning, tweaking, and adding some new functionality and capabilities as they went."
Whoever owns VMS now: please bring back VAX (not x86, subject of this article) hobby license paks. Some of us want to keep our hardware running with the clock set to the correct date.
IIRC VSI never got the VAX stuff in the deal with HP. I don't think HP will ever bother to bring back the hobbyist program just for VAX, unfortunately.
There are easy ways around this lack of official licenses. Ways that I can't/won't go in to here.
Obviously a 1990s signature scheme can likely be brute forced today or has some known vulnerability. I remember back in the day discovering that the license key scheme for Sun's NFS for DOS had the property that re-ordering bytes from one valid key created a second also valid key.
This presentation from a few years ago says their x86 porting approach is based on utilizing LLVM (and clang for C++) rather than writing an x86 backend for their existing compiler. Has this been done by now, and is it the way it was eventually done?
Yes, the native compilers are now LLVM based. Reading between the lines, it seems like this migration was one of the reasons this release has been delayed by a few years.
I had only used my Atari 800, Apple II,DOS PCs and Macs in the 1980's.
In 1991 I went to a new high school and we had a VAX running VMS. I was amazed that hundreds of users could be logged into the same machine all doing their own thing. A buggy program could crash with no threat to any other program you ran or any other user running their programs. Sending email and phone / chat messages was really cool.
Then I found the Unix SunOS and AIX systems and liked them far more.
I learned that multi user systems went back decades but at the time I didn't really know and felt like something very powerful was lost going to these small personal computers with so many memory and operating system limitations. Of course learning about the vast price differences quickly made me realize why.
It's probably the other way around. Keeping it non-free requires doing nothing, so it is the default.
OTOH, freeing such a code base is costly, especially if multiple licenses cover different parts of the code or if the code contains references to stuff that you don't want to go public.
VMS Software's intention in porting VMS to x86 was certainly to capture commercial sales. It was an expensive undertaking; there would be no other reason to spend the money besides expecting to recoup it in sales. The whole company's existence is because of the existing commercial customer base. They acquired the rights to VMS from HPE with the expectation that they'd make money with it. They have a press release talking about all the support contracts they inherited from HPE.
The real question is: what do they get out of offering a hobbyist license? I honestly don't think they get anything and it's just a nice gesture of goodwill. Nobody is going to pick up the hobbyist VMS license and then decide to adopt VMS at work. I bet it doesn't lead to a single extra commercial sale. It's nice that they're offering it despite that.
> Nobody is going to pick up the hobbyist VMS license and then decide to adopt VMS at work. I bet it doesn't lead to a single extra commercial sale. It's nice that they're offering it despite that.
While I think you're probably right, having the hobbyist x86 option might help with testing and identifying bugs though, due to the larger user base.
> The real question is: what do they get out of offering a hobbyist license?
Commoditize your complements: If you sell VMS software, it stands to reason you would like there to be people who know how to use it. Even better if you don’t have to pay the train them.
Tons of people know how to use Linux because you can just download a distro and start using it… It’s the same reason MS and Cisco have all those certificate programs.
I never understood why IBM didn’t make a hobbyist version of their mainframe OSes for Hercules.
Yes, I know. Linux already having won is my point. The window for VMS's mainstream relevance ended decades ago. New companies won't be adopting VMS today no matter how many free hobbyist licenses you offer. It's just not going to happen. So VMS in 2023 exists to service the existing customer base. We're way past the point where VMS can hope to roll up to the commercial level at new companies by offering free licenses to a few scrappy hobbyists. Decades ago that could have worked. Today the landscape is different.
VSI knows all of this, of course. I really don't think they intend to compete with Linux in 2023 with hobbyist licenses. That was never in the cards.
Will be sold until the end of time, though swapping the hardware out from under the software is a no-brainer. I wonder what this puppy looks like running on a couple 7,529 pin 120 core Intel Xeons —going to need a bigger monitor to run SHOW PROCESS on!
I worked on an openvms system rubbing a lab at a hospital in 2019. Damn that thing was rickety. DCL saved my bacon for a while, since their COBOL compiler was broken. I did miss command-line history. I was watching this project like a hawk, hoping that I could set up a VM for testing. I'm glad that they finally released something but I their number of users has to be in the hundreds at most.
According to a post on the VSI forum from one of their staff, there are about 1,300 people registered fro the hobbyist license. There are dozens of us... dozens!
Ok my story. I touched real a VAX/VMS system exactly once. Was working as a sysad at an aerospace concern in the mid 90s. There was an old curmudgeon scientist named Norm with a comb-over who so-far refused give up his VAX—much to the chagrin of the IT dept. :-D
He finally did, but not yet on this day.
I came in to his office one summer, probably to help with a Mac or PC, and was intrigued by the unique machine. He let me poke at it and look around. Not sure what I expected... some kind of mainframe kind of thing? To my surprise was a graphics terminal with the X Window system running along with the CDE desktop. Believe the main box was in a lab somewhere else. Kinda blew my mind because I had recently tried CDE out on a cheap Lintel PC I had in my office. Slackware? Maybe had seen it on a Sun as well. (Was a great place to work and learn, the "UN of computers" I called it.)
So it was familiar in that sense. Started up a character terminal and poked around. Had the crazy prompt [SYS$FOO...Bar] or something and verbose uppercase commands. Had versions numbers in the filenames after semi-colons. I think there was very good help system as well. In total, a fascinating combination of archaic sophistication.
Unfortunately, a lot of great ideas from the old days were lost in the drive to standardization. I think I preferred VMS' named volume approach also taken on Amiga, Netware, and limited in DOS/NT. (Been on Unixen for decades now, so don't hate the single root, but find it less obvious where I am.)
On the other hand, later I read ESR's take of VMS and it wasn't all that positive:
The gold old days. My first real corporate gig was programming (Fortran, DCL, and odd bits of Ada) AND operations on various VMS clusters. Fun times. I have occasionally created a Hobbyist cluster and played around with it just long enough to remember when went towards UNIX.
I have been at several gigs where somebody has said, "Oh yea, that connects to a VMS system for x,y,z," and I know enough to sound competent. Still kind fun to find it out in the wild from time-to-time.
But I'll have to give this a look see, there is still some fascinate technology at work there.
This world of Unix operating systems was way before my time (I got started with Linux in 2008). One dumb question I have is why does something like this exist in 2022? We have tons of other Linux distro's that can run any number of workloads, is it just a matter of you have all your legacy stuff on OpenVMS and it would be easier to stay on it? Or does OpenVMS provide some feature that you just can't get in Ubuntu, Debian, Fedora, etc.
First: It's not a Unix system. It's a whole different tradition. For practical reasons it got "invaded" by the unix userland, though.
But you already answered it yourself. Legacy stuff. And because it is NOT a unix system porting the legacy stuff running on it would be even more difficult.
One one hand, this is mostly for legacy purpose, like OS 2200 for the current Dorados (Univac 1100), Z/OS for the IBM 360/390/Z line, or GECOS on some Bull/GE hardware, all originating from the early 60s and still alive nowadays. Heck, you can even still find TOPS-20 running on some network gear.
On the other hand, VAX is pretty much dead by now and I don't think VMS really was a thing on x86.
The agronomy research company I worked for in college had a small IT department of three programmers/DBAs. They ran Oracle on a big Alpha with some older vaxen serving in auxiliary roles. They had bunches of programs written in VAXBASIC over a couple decades that ran the company, managing the hundreds of thousands of seed strains they were testing.
I’m sure they’ve transitioned in the two decades since, but back then there wasn’t any off the shelf software for their purposes and it would have been an enormous time sink to port over all those old programs.
DEC’s role in the tech industry was enormous and platform transitions can’t happen overnight. OpenVMS provided DEC customers with a lifeline. (Also, VMS != Unix)
Today’s tax day in the US and my bet is that some 50 year old COBOL program running on an IBM zServer is computing over your data.
Register for a hobbyist license for Alpha and Itanium, and you’ll also get an x86-64 hobbyist license. You can then download it all via the support portal at sp.vmssoftware.com and set up a VM to boot the installation ISO.
I "registered" for an Alpha license last week (I own several systems), but all I got was an email with credentials to access VSI's SFTP server, using a shared 'ACOMMUNITY' username. I cannot access the portal with the email address I used for this, and attempting a 'Forgot password' just returns "Error 404: Email not found.". You can see 'ICOMMUNITY' and 'XCOMMUNITY' directories in the server, but I'm not able to access them.
Has anyone that has requested a license (Alpha/Itanium) in the last few weeks actually been able to log in to the portal?
I was assigned to port the Bad Block Detector (BADBLK? I don't remember exactly) to the 64 bit architecture. The 'port' turned out to be change the build files to use the correct compiler and flags. I don't remember if the tool was written in PL/1, Bliss or VAX assembler, but we had compilers (yes, even for VAX 32 bit assembler) for all of them. The interesting part was the testing.
A Bad Block Detector is a piece of software that watches for disk blocks going bad, and remaps them to spare capacity (your spinning rust disk is lying about its size - don't know if this is true for SSDs). It might even try to copy data from the failing blocks to the remapped space if there's time. More modern h/w does this in the firmware on the drive. It's transparent to the OS. Testing this behaviour is... challenging.
Recipe: Test the Bad Block Detector
Serves: millions
Time: A couple of hour elapsed
Ingredients:
- a VAXstation - i.e. a biggish desktop machine that can run Alpha emulation well enough for our purposes. All of its disks are connected on a SCSI bus.
- a 3.5inch floppy drive with a SCSI connection (yes, you read that right)
- a box of 3.5 inch disks
- a paperclip
Method:
Boot emulated environment. Set cross compiled Bad Block Detector running. It watches for 'interesting' disk related events.
Insert floppy disk. Note the Bad Block Detector does nothing (because disk has no bad blocks.)
Take paperclip in right hand.
Take fresh disk in left hand. With pinky finger, push back the sliding cover that protects the delicate rusty surface.
Using paperclip, gouge a few hundred kilobytes of damage into rusty surface.
Replace good disk with scratched disk.
Watch console for proof that Bad Block Detector woke up, spotted the badness, and remapped its little heart out.
Serve to delighted and amazed customers.
Loose billions of dollars, arrange purchase by Compaq, rinse, repeat.