Used it on VAXEN
... in college in the late 80's. It was a bit of an eye-opener after Commodore BASIC.
RIP
Digital Compaq HP has announced the end of support for various flavours of OpenVMS, the ancient but trustworthy server operating system whose creator went on to build Windows NT. OpenVMS started out as VAX/VMS on Digital Equipment Corporation's VAX minicomputers, then later was ported to DEC's fast Alpha RISC chips – before …
The technical college in my home town kept their Vax for programming classes despite its age, as it provided a perfect environment for teaching C programming - text editor, compiler, debugger and profiler all accessed via VT320 terminals. They were even able to reboot it into Unix (2.11BSD I think) when the need arose.
So OpenVMS is now shut :)
I had to write a driver for our recovery software for VMS. You could see how much NTFS was based off Files-11. Having to deal with VMS attributes was no fun but we came up with a scripted solution eventually so we could do VMS recoveries under Windows but I also had to generate the VMS script and it doesn't even use 'standard' path syntax from what I remember.
Bloody worked though :)
Yeah, I remember working on an OpenVMS machine (running a DEC RDB server no less) in the early 2000's and thinking its path syntax was really awkward. I was also taken aback by the inbuilt file versioning, though time and again I've come to think modern OS'es could do worse than implementing something of the sort – as indeed they do.
It is sad to see a venerable operating system like this go. I expect it will be kept alive somehow, though.
I remember when you could run an operating system *plus* programs in just a couple thousand bytes. People coming to this from later years should know that the monstrously bloated systems we have now are not like that because of some law of nature or mathematics. They are like that because we honored people like Steve Jobs instead of people like Dennis Ritchie.
The forces driving early development are not what drive it now. However, there are, most certainly, software developers who honor the legacy of the generation before. They do their best under the current monstrous systems to produce things with small footprints and elegant design.
I remember when your programs came on listings you typed in from the magazine. I think the new way is better.
Users want features. We give them features. This makes the programs bigger.
The easiest way to make features is to build re-usable layers of components. This makes all the programs much bigger.
The way to make the programs smaller with all the features that the users still want is to remove all the encapsulation from all layers of the program. This makes the program buggier.
"...the monstrously bloated systems we have now are not like that because of some law of nature or mathematics. They are like that because we honored people like Steve Jobs instead of people like Dennis Ritchie."
Got THAT right. And others like him and the corporate whore-ti-culture that went with it.
I started programming on a PDP 11/40 in 1974. Now I'm nearing retirement age it is really sad to see such a wonderful O/S pensioned off.
Add to that the fantastic 20 years I spent at DEC in Reading then you can see that VMS was a big part of my working life.
Pretty well everything else since then has been downhill.
VMS Clustering still takes a lot to be beaten if you ask me.... Introduced in 1983, dies in 2013 RIP
"......OpenVMS taken out back, single gunshot heard" We've been winding up our VMS dinosaurs that they didn't need a bullet - the old stuff justed needed a loud "boo!" to drop dead! It will be missed, a bit like that old Mini that was fun and just kept going you had "back in the day". Of course, take off the rose-tinted specs and you probably wouldn't be swapping your modern motor for that old British Leyland product!
But VMS does live on, it is now OpenVMS (www.openvms.org), where you can read the hp letter (http://www.openvms.org/stories.php?story=13/06/06/2422149) that Mr Poven seems to have missed whilst rushing to write VMS's obituary:
".....We are committed to providing you updates and support for the V8.4 OpenVMS operating environment through at least December 31, 2020......"
So not quite dead just yet.
"The letter that is the *first link in the story,* you mean?...." Most sorry, I though that had been added by the editor, seeing as I couldn't grasp how anyone could have read the letter but still insisted the "killing" was immediate. Apologies for assuming that you had merely been ill-informed rather than deliberately misleading.
".....another small thing given your immense attention to detail....." You want to quibble over a typo after deliberately ignoring the seven plus years until VMS is really dead? Surely passing on that quite key bit of information was more important to the majority of the readers rather than the spelling of your name. Are we maybe a little egocentric? Forget the pot, that's like the chimney calling the kettle "slightly dark"!
You need to learn when to stop digging and keep a discreet silence, Mr Bryant.
But since you didn't do that here...
"We are committed to providing you updates and support for the V8.4 OpenVMS operating environment through at least December 31, 2020..."
A year or so ago, HP were saying in public that they were "committed" to delivering VMS on Poulson (that's the next generation Itanium, for those who have understandably been ignoring the world of IA64).
HP have reneged on that announced commitment. They're now saying that the "port" to Poulson is too expensive (?!).
In that context, and given that VMS engineering and support was offshored from New England a few years back, what sensible VMS customer is going to believe the 2020 commitment?
Sensible customers will see 2020 and realise it's a high risk gamble. I expect IBM will be getting a little unexpected new business in the next few years.
This post has been deleted by its author
".....digging....." More like taking a dig at Mr Poven - oh, sorry, that's Proven, wouldn't want to upset him again. ;)
".....They're now saying that the "port" to Poulson is too expensive (?!)....." Agreed, I suspect it is more a case of a little less will than any actual great difficulty. The Poulson cores aren't different enough from Tukwila to require a port, but spending the lab time and money on verifying OpenVMS with the new i4 servers seems to be a task hp can't be bothered with (they have to verify the new servers before they can offer support on them). With hp not offering support for the new i4 servers that leaves current OpenVMS customers with the Tukwila kit at best until December 2020. Maybe hp just weren't seeing enough new OpenVMS licences going out the door to make it commercially viable.
".....I expect IBM will be getting a little unexpected new business in the next few years." LOL, now that's just wishful thinking! Customers porting off OpenVMS will probably be going to x64Linux rather than opting for the equally unsure route of AIX-Power, and IBM is trying to sell off their x64 server biz. If they're miffed enough with hp they might call Dell, but probably not IBM. Nice attempted troll though.
@Steve Davies 3: "Pretty well everything else since then has been downhill".
Very true indeed. I still marvel at the spectacle of Microsoft and others struggling to solve problems that DEC had dealt with in 1985. VMS reminds me strongly of Professor Hoare's remark about ALGOL 60:
'The more I ponder the principles of language design, and the techniques that put them into practice, the more is my amazement at and admiration of ALGOL 60. Here is a language so far ahead of its time that it was not only an improvement on its predecessors but also on nearly all its successors'.
- C.A.R. Hoare, "Hints on Programming Language Design", 1973
About VMS Clustering - I haven't seen anything quite as flexible since. Clustering via disk or network interfaces. You could share any resource that could be given a name.
There were many other nice features, such as automatic file versioning and a very comprehensive and easy to use help system.
Pathworks had versions for both MS-DOS and MAC - to my knowledge, the first to allow DOS and MAC systems to share the same folders and printers.
"The architect of RSX-11M and VMS was Dave Cutler, who planned a portable, object-oriented successor, PRISM"
It's a testament to the longevity of VMS that the NSA managed to integrate PRISM into Google/Microsoft/Facebook. Why isn't Dave Cutler answering privacy questions.
Google CDEbian for a live iso/VM image of Debian Squeeze with CDE 2.2.0 as the desktop (desktop manager appears to be Slim). Boots in 55Mb of Ram on my thinkpad off a USB stick made using unetbootin.
I've added that iso to my User Interface Museum... but I'll stick with xfce for normal use!
> The you'll be glad to know that CDE was open sourced a little while ago :)
The fact that CDE was closed source was one of the things that led to the creation of KDE and GNOME.
CDE only was liberated when it became painfully obvious that everyone had moved on (including the likes of Sun).
I remember Vax Notes fondly. And Vax Phone. Wasted many a happy afternoon during my university days, thanks to those two .....
And VAX/VMS had proper file versioning! A full filename was something like "LOGIN.COM;43" but this could be shortened to "LOGIN.COM" which would use the most recent version. If you created a new LOGIN.COM then it would become version 44 -- version 43 would not be deleted, until you had accumulated too many versions of the same file.
"version 43 would not be deleted, until you had accumulated too many versions of the same file."
That rather depended on your sysadmin. A friend of mind found she was working with a BOFH who had PURGE as a scripted nightly (*) task, just to keep the disc lean you understand.
(* OK, I don't think it actually survived to run a second night, but that was the original intention.)
>A friend of mind found she was working with a BOFH who had PURGE as a scripted nightly
Can't have been a very good BOFH. All you'd need to do was after the first purge change the version limit property of the directory to 1. This would ensure that no matter when a file was edited there'd only be the latest version.
All you'd need to do was after the first purge change the version limit property of the directory to 1.
That would need a rather crafty setup, as any directory from your home directory down would be owned by you, so you'd be able to change the file limit back, and he'd need to have a batchjob running that sets the file limit on any directory you've created that day, plus purge the files in it anyway. Having directories not owned by you but writable by you (so you can't change the file limit) requires more acl-fu than I'd care to think up after working hours.
Shit. Not just the end of VMS (the Open is silent), but in a way, the final nail in a great company, laid low by beancounters in the executive suite destroying the good efforts of engineers at the working face.
For what it's worth, OpenVMS runs very well on the remarkable SIMH emulator. No telling how long HP will make available the disk images, but a search for 'OpenVMS Hobbyist' should prove useful to anyone who wants to see the OS running on their own PC.
SIMH is great. Although I do prefer to run mine on KA49 in my VAXstation 4000, much to the delight of the beancounters of the electricity supplier. Especially when running cluster of them.
>>> show config
KA49-A V1.2-09D-V4.3 83 MHZ
08-00-2B-C0-FF-EE
128MB
DEVNBR DEVNAM INFO
------ -------- --------------------------
1 NVR OK
2 LCSPX OK
Highres 72Hz - 8 Plane 4Mpixel FB - V1.1
3 DZ OK
4 CACHE OK
5 MEM OK
128MB 0A,0B,0C,0D=16MB, 1E,1F,1G,1H=16MB
6 FPU OK
7 IT OK
8 SYS OK
9 NI OK
10 SCSI OK
6-INITR 7-L0-RZ26B
11 AUD OK
How terribly sad. I have fond memories of VMS, both as a DECcie and before: it was my first "real" computer system back when I was at college in the '80s. Unix was more fun to hack around on, but VMS had a nice reassuring solidity to it.
Sounds like DEC's classic old marketing strategy is still living on at HP, at least: "we don't know how to sell this thing, so we'll get rid of it."
That's sad news.
VMS was really good - as the article says they clustered together easily.
When I was a graduate student at CERN my experiment used VAX clusters - we got to the bigegst size you could run (somewhere near 120 machines if I'm not wrong) and then started on the next!
In the later days we were using Alphas in the clusters also.
Wrote my thesis on a Vaxstation 3000. Sniff. I still have it on a TK50 tape somewhere!
96 members in the cluster was what had been formally tested, and thus was in DEC's legally binding Software Product Description, and therefore what was formally supported.
It was often the case that things that were technically possible in principle but weren't formally supported would likely work anyway, either immediately or after a bit of tinkering .Over 96 nodes in a cluster was a "works right away" case, if I remember rightly.
There was nothing magic about 96. You could have more than 96 nodes. People did. But if it didn't work, it hadn't been tested, wasn't supported, and it wasn't necessarily going to be fixed. Properly testing a 96node cluster needed a certain amount of kit, and time, and skill.
A cluster of that size wasn't necessarily a bright idea anyway unless you knew what you were doing. But in the right hands they could, and did, work.
Happy days.
In the cluster internals the node number is a single byte, which can't be 0 or 255 (and 254, I think), so theoretically you could go up to 253, but that includes cluster storage controllers.
You'll need a serious amount of kit, and need to spend some time on storage and interconnect layout, but after that it'll Just Work.
Whether a sane setup needs a cluster that big is another matter entirely, but the IT definition of 'sane' is anything but, anyway.
A previous employer wrote warehouse management systems in a mixture of C and FORTRAN, originally for the PDP-11 and later for VMS on the Vax. Despite the company having moved onto coding C and C++ for Tru64 on Alpha hardware, one client insisted on continuing with their Vax system because of the reliability. As a result my employer had to keep an experienced FORTRAN programmer on the payroll just for that one client.
My first "real" job was on VMS for a well-regarded engineering firm. One thing I learned is that fighting the philosophy of the design is a waste of time -- the OS wasn't Unix? Fine, use what the OS provides, stop trying to make it behave in a way it wasn't designed for. As I shifted between jobs using VMS and jobs using Unix, I came to appreciate and embrace the differences. This became particularly important as VMS started adding security features that Unix hadn't figured out yet.
Eventually Unix won, of course (and got more secure). I think that's a deserved win, but every once in a while I do think "What would VMS do?" and it helps in the design process.