Used it on VAXEN
... in college in the late 80's. It was a bit of an eye-opener after Commodore BASIC.
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).
This post has been deleted by a moderator
Sounds very descriptive, in an eadonesque, self-referential way, except that he:
- will never be accepted by any group
- barely thinks
- is better suited to lock-up than lock-in. (Hmmm, maybe both.)
This is spot on, though (turning a generously blind eye to the 'special needs' linguistic ability).
I can't speak about VMS as I have never used it; but you will get no quarrel from me WRT WindblowZE.
I know someone who is stuck working in a WindblowZE shop even thought he is, at heart, a Linux fan.
Instead of the usual Windows splash screen, his work machine sports a red/black spawn of satan splash screen. Instead of the WindblowZE login sound, he has Darth Vader (James Earl Jones) saying: "Welcome to the dark side". I just love his sense of humor.
".....Instead of the usual Windows splash screen, his work machine sports a red/black spawn of satan splash screen. Instead of the WindblowZE login sound, he has Darth Vader (James Earl Jones) saying: "Welcome to the dark side"......" I find it quite ironic that you bash Windows but then don't see the quite clever programming that makes such desktop changes in Windows such trivial challenges. Especially when you lionise Linux where Gnome has copied the Windows method - right click on the desktop to open a window, select the changes you want. The Gnome method for changing the startup sound - click on Start > System > Control Center >Sounds > Sound Preferences - looks like a Windows copy too.
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
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
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.
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.
This post has been deleted by a moderator
"They should have attacked WNT with a VMS/Aplha hardware/software combo at the same price point as Compaq".
As you probably know, WNT was essentially a VMS skeleton with the Windows user interface flung loosely on top. It would have been much better if Gates had not insisted on retaining the Windows look'n'feel. In engineering terms, that was a bad decision - but in marketing terms it was absolutely right and quite inspired. It was far more important for NT to "feel like Windows" than for it to be a bit more reliable. From Microsoft's point of view, of course - they didn't much care about the users' experience as long as they went on buying licences and support (which they did).
DEC can be seen as a giant marketing experiment that proved conclusively that punters (taken as a whole) much prefer cheap and simple to good, reliable, secure and expensive.
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.
So do you we need an 'industrial archaeology' of computing?
It's good to know what wheels have been invented already, what their flaws and strengths are, and in what contexts they work best.
That way you might not end up with the Microsoft Triangular Wheel: Now With 33% Less Bumps Per Rotation than the Microsoft Square Wheel*)
*) Sale of the Microsoft Square Wheel Gold WIth Rounded Corners withdrawn pending a patents dispute with Apple.
'That way you might not end up with the Microsoft Triangular Wheel: Now With 33% Less Bumps Per Rotation than the Microsoft Square Wheel*)
'*) Sale of the Microsoft Square Wheel Gold WIth Rounded Corners withdrawn pending a patents dispute with Apple.'
I wish I had 1000 up votes to bestow on you. You just made my decade! 8-)
The divide was also cause for much infighting within IT departments. All too often "use the right tool for the job" is forgotten. Sure both could do many jobs but one would suit particular job better.
Obviously over time POSIX adoption did yield some interesting combinations like MPE/ix, which retained the solid MPE V background with the "unix like" features from POSIX which did aid in porting many applications across.
I did a lot of real-time work on systems using VAX/VMS and its 16-bit ancestor RSX11M. You could guarantee to be reading device registers within a few microseconds of that interrupt, with less urgent device driver processing put into a queue that took priority over user tasks but yielded to interrupts from other devices.
I always felt its real-time logic was far better than anything I saw in Unix/Linux, although OS/2 was pretty good.
"MS-DOS real-time logic was far better than VMS' yet"
Downvoted, for reasons which should be obvious to anyone with clue, but I'll expand anyway.
VMS had quite an installed base in real time systems, as its behaviours were useful in environments that needed both a simple priority-based scheduler and reasonable interactive performance, database stuff, etc - an uncommon mix (though Tru64 was pretty good at it too, later on).
One of the more spectacular sectors where this was seen, to those who know anything about the relevant industries, was real time control of metal-rolling (steel, maybe aluminium?) and paper mills. In these systems you have PLC-connected sensors reading the thickness of the stuff being rolled and controlling the roller separations. A VMS box reads the thickness measurements from PLC(s), does some database work to see what the next set of rollers should be set to, and commands the PLCs accordingly.
All in real time. Typically over a dedicated LAN. With VMS in the loop, often with a database too. With interactive users as well if necessary.
Get something like that wrong and the financial impact means it's not going to be popular, quite possibly not even safe.
You wouldn't want to run something like that on an emulator. Probably not on an IA64 either, their dependence on data being in cache to get decent performance (50MB of L3 cache?) meant that their predictability simply wasn't good enough for truly low latency systems.
Now tell me seriously that MS-DOS was a realtime OS like that and I'll introduce you to the clue stick.
I remember an urban myth that the reason that Windows NT was called so harked back to the 2001: A Space Odyssey thing. HAL been called HAL because it was one step behind IBM (a major sponsor/product placement partner in the movie).
Roll on a few years and the chief bod behind VMS names an OS WNT, in this case, WNT been one step ahead of VMS (as the story goes).
Would have been quirky if it were true (was it?)
There were a few bits in there that I didn't know.
I still think RSX11M was the best of the many operating systems I've developed software for in my life. The latest versions of Windows and Linux could learn a few lessons.
I used VAX/VMS as well, but the added layers of complexity made it less elegant an fun than RSX. Still, it was a viable alternative technology in the operating system world that's in danger of turning into a monoculture. I still remember the day that the DEC sales team came in to pitch their new corporate-mandated Unix message. Having spent years telling everyone that VMS left Unix in the dust, they seemed lost and confused. DEC never recovered from that.
First Iain M Banks (he finally sublimed) and now VMS (the Open was always silent). My first job was putting in a VAX 11/780, and then I worked on most of them over the next 10 years. A wonderful O/S, especially for system programmers. I loved the Bit-mapped processor in the 11/780 that allowed you to add your own instructions to the processor. That was fun but did provided for some spectacular crash dumps. Integration a massbus to a Cray-1 was also fun.
The end of an era. Linux is fun, but it is not a patch on VMS.
Still kudos to Dave Cutler for an OS that lasted 35 years.
"Still kudos to Dave Cutler for an OS that lasted 35 years."
The underpinnings live on. The Windows driver model is very closely based on the VMS one, the data structures have different names but function in the same way. When NT was released it was said that the best tutorial guide for writing a device driver was the VAX/VMS Device Driver manual.
This post has been deleted by its author
VAX support has already ended, Alpha will be supported for "at least" another 2 or 3 years, and current Integrity systems will be supported until "at least" 2020. All that letter confirms is that they won't be supporting OpenVMS on Poulson-based Integrity servers.
The hourglass may be running down, but there's still a little bit of sand in the top half.
To be pendantic, Prism was the name of the architecture (which was a sort of spiritual predecessor to the Alpha, such that some joked that the AXP moniker stood for "Almost eXactly Prism"). Mica was the name of the operating system designed by Cutler et al. which was meant to host Unix and VMS environments on top of a microkernel (much like Windows NT originally supported Win32, OS/2 and SysV Unix APIs on top of a hybrid kernel)
Some good reading here for those interested in the history -
I spent many happy years programming in MACRO32 (assembler) on a variety of VAXen, and being able to coherently share and modify a mapped memory segment between multiple VAX machines was just a delight - and this was in the mid 80s, demonstrating how advanced VMS was then and still is today.
Now, if only OpenVMS could be ported to run on the Raspberry Pi... how good would that be? :-)
" if only VMS could be ported to run on the Raspberry Pi."
If an emulator (for free) will do, it's pretty much ready and waiting.
SIMH is free (no cost, open source) emulator for various historic chips, does PDP11, VAX and loads of others too. Small footprint, has been running on PDAs since the days of the iPAQ, will run fine on Android on a decent phone (there's already a prebuilt one in the Play Store). There are also commercial emulators but they're probably not relevant here.
There is an HP-supported VMS Hobbyist program, zero cost licences for hobbyists for OS and layered products.
Will that do?
Pick a search engine and off you go, there is at least one writeup out there of a real MicroVAX clustered with an emulator on a RasPi.
VMS is different. Different isn't necessarily/always better, but there are lots of opportunities for people to learn, if they are that way inclined. Lots of VMS *is* arguably better (e.g. a rational CLI, with consistency). Some of it is a bit arcane (e.g. the original file system filename syntax goes back a long long way). Some of VMS is arguably worse than the others (forking is hard work).
Running on an emulator might be fun, but does not really lead to the state of the art in OS design advancing. I would indeed love to see VMS open-sourced, and worked on by folks like the OpenBSD crowd.
As for "forking is hard work", it _should_ be hard work. What started out as a way to minimize swap-disk load on the XDS940 by taking a "copy it all, let the child sort it out" approach to a process creation, instead pf a proper remote procedure call, has led to a lot of ugliness as we moved from a "one CPU, many users" to "one user, many CPUs" world.
""forking is hard work", it _should_ be hard work. What started out as a way to minimize swap-disk load on the XDS940 by taking a "copy it all, let the child sort it out" approach to a process creation, instead pf a proper remote procedure call, has led to a lot of ugliness as we moved from a "one CPU, many users" to "one user, many CPUs" world."
Wise words. Not popular, but wise. Cutler would probably have approved.
I have worked with sysadmins that thinks Unix to be a bit unstable, but OpenVMS has always been rock solid. Especially the clustering is praised with uptimes of decades. I am a geek, fan of great tech. And there are people whom I respect, that says OpenVMS is better than Unix, so I am a supporter of OpenVMS. An OpenVMS cluster have far better uptime than a Mainframe they say. I have only dabbled a bit with OpenVMS at work, and the shell seemed a bit arcane. But that does not really matter if it is a great OS. I wish it was open sourced so the community could take over and make it live, and never die.
The saddest thing that VMS' demise will bring, is the death of Rdb (currently known as OracleRdb).
Despite not having touched it for 6 years myself, I miss its facilities every single day. It is without doubt the finest piece of relational database software engineering ever produced. Sadly, Rdb's release on Windows NT got derailed over something as trivial as compiler support from CompaQ (bean counters to blame in fact), so Rdb has no alternative home :(
Beer: Appropriate at the wake, a sad face is a given
Rdb improved massively under Oracle ownership and a great many new significant features were added. Pretty much the entire engineering team went to Oracle from DEC and it was pretty much business as usual for 10 or more years.
Sady, the WindowsNT port, brilliantly executed, died shortly after birth (I have a rare shrink wrapped version actually) and was recalled due to BLISS compiler support being denied to Oracle as I recall. That left no second option for Rdb, and it has remained VMS only and lives on borrowed time. That time is up with the EOL of Itanium or the non-support of VMS on new Itanium kit, whichever comes first.
While I enjoy having the Windows GUI etc, I miss VMS and Rdb every single work day because of the engineering quality they represent :(
From what I remember talking with DEC tech staff a few years ago, AMD Athlon needed 2 or 3 instructions adding to support VMS. If they'd done that, even on the more expensive Opteron, it would have given a relatively cheap route to migrate away from proprietary Alpha and could have saved it (possibly).
Seems unlikely. I've heard a lot of bad things said about the x86 and its successors, but Turing incompleteness isn't one of them. I suppose if this was /quite/ a few years ago then they might have been complaining about the lack of an NX bit, either in AMD's offerings or (equally importantly, if you are trying to flog an OS) Intel's offerings. But that hole was plugged about a decade ago.
Do you recall (or can you say) roughly what sort of instructions they had in mind?
Not the OP but IIRC the problem was some atomic bit-twiddling instructions which VMS heavily relies upon. Also VMS uses four CPU privilege 'rings'; 0 = user, 1 = Supervisor (the DCL command interpreter), 2 = Executive (basically the file system), 3 = Kernel. X86 processors in theory have four rings but as most OSs only use two there are bugs in the implementation- see the Virtualbox docs for details.
The "bit twiddling instructions" may be a reference to some obscure instructions which help performance in a couple of applications, one of whose big users is in the news at the moment which I can't mention (it involves the letters A,N,S, but isn't NAS or SAN and isn't SNA and isn't ASN. Are we there yet?). Anyway their absence is not a showstopper - they weren't present on the earlier Alphas either. Look up "Hamming Weight" in Wikipedia or the Count Extensions (CIX) introduced in EV67 Alphas.
VMS uses four privilege modes which were done in hardware on VAX. They don't directly match the x86 rings, but it doesn't matter. Alpha architecturally doesn't have four processor modes, plus memory management that understands the full four. VMS works just fine on Alpha. What's missing on x86-64? There may be bugs, but AMD64 was the opportunity to fix those.
The fact that VMS never arrived native on x86-64 is almost certainly down to corporate politics (e.g. a deal between Bob Palmer, CEO at DEC, and his golfing mates at Intel, and their private long term agreement to abandon Alpha because x86-64 would never be possible and IA64 was therefore going to become the industry standard 64bit architecture. Ironically, Palmer later ended up at AMD, the people who showed that x86-64 wasn't impossible at all, and thereby left IA64 looking a bit silly).
The fact that VMS won't make it onto Poulson is again more likely due to politics and commercial factors than technical ones. Not that it matters much now; unless a white knight comes riding in from IBM, Oracle, or maybe even Dell, VMS is (commercially) toast. Thanks HP.
It was a long time ago, around the Millenium, so memory faded!
As Dave Pickles replied, the extra bit for run level privileges rang a bell - might have been just that one change required.
And related of course, Alpha was the first 64 bit processor that was affordable by the masses AFAIK.
As an ex (Open)VMS system manager from version 3.4 through 7.3 I appreciated its many features, including:
Reliability - had systems up 400+ days before computer room power downs forced a shutdown.
Command Line Interface - very consistent syntax generally made it easy to follow scripts, the very opposite of Linux/Unix in my experience.
Clustering, especially across remote LANs.
Software Volume Shadowing (across LANs too).
Rsts,RSX,VAX,VMS PDP's, 11/750/780/785's my main source of bread and butter from the 1980's through to the Alphas in 2006.
I will miss Lexical functions, batch processes, cluster nodes, tape backups, access to indexed files directly from DCL (don't tell OPS!) and the ability to create auto recoverable batch procedures for overnight peace and quiet whilst down the pub!
No more Vax/Macro and now feeling very reminiscent as I read Volume 1 Issue 1 of the Digital Review 1987, a quarterly publication dedicated to the DEC community.
Gone will be
a) the undocumented DCL $checksum and the result in checksum$checksum
b) create/dir [ ]
c) and $ @tt: to check your command syntax
so I guess in th end, for VMS, it can only be, .END and LO
Too bad they never learned how to market their best clustered environment to 24x7 businesses.
Updating the tool, improving the TCP/IP stack and putting money into the product line would have kept this a viable OS, but ever since Compaq got swallowed the printer ink salesman and HP-UX folks took over.
HP-UX isn't a really special Unix. Had they looked further into Tru64 and VMS clusters they'd have had something better than their current solutions.
Same here. My first VMS job was late 1982 or 1983 IIRC. My most recent concluded in 2007.
VMS was the technology base I specialised in and my work with VMS systems fed my family and me for a solid 20+ years (with the occasional stint in other OS lands).
What I leaned in the VMS years is and was invaluable. The advanced button pushers that surround me continue to amaze me, with how little they actually "know" about how anything works. It is astonishing actually.
I won't rant too much, but working in the WindowsServer world with SQLServer is in many ways a trip to the dustbin of bad engineering decisions, poor implementation and the sad fact that people will buy crap because they don't know any better and think that price is a stand alone factor in purchasing decisions.
Whoever mentioned "uptimes longer than Microsoft product lifespans" here got it exactly right. Microsoft's single largest contribution to the IT space, is that a solution to almost any OS issue is "rebooting the machine". Engineering and intellectual bankruptcy, successfully marketed as a feature.
Now, I have to stop here to reboot my Win7 workstation after yet another security patch. After that I will try and figure out why one of my servers works fine for about a day after rebooting and then turns into a slug :(
The coffee machine is broken. This is not shaping up to be a good day ...
anyone rememember the 'blue and cream' kit of the Systime era?
the DEC wannabes that survived until the late 1980's
saved many a company a bob or two on costs
i'll miss those line (band) printers (that frequently broke down) and the reams of forest paper for month-end reporting, that went to recycling, the following month, to save up and pay for our Christmas binges.
those top-loading disk platters were the best though - all of 10Mb wasn't it? very reliable 'dinner plates'
I fondly recall the error detection and logging features built into VMS as standard. The error log collected voluminous details of every CRC error in RAM or magnetic storage, as well as pretty well every other fault event. So it was very easy to track hardware faults as they developed, and fix them when (or before) they became critical. Neither Windows nor Linux has ever had anything faintly comparable.
In 1979 I joined the first European Remote Diagnosis Centre (RDC) at Viables in Basingstoke, where we sat at terminals and read off details of computer faults all over the UK. As time passed we gradually became more confident and learned to accomplish more.
My favourite memory is of the day when I was assigned to a VAX somewhere in the North of England that had hung up, completely unresponsive. After inspecting the output of the standard automatic scripts, I began examining memory locations and register contents, with the VMS microfiche displayed on an optical reader beside my terminal. Finding that the processor was hung at a given hardware interrupt level, I was able to determine that a specific fuse had blown in a particular tape drive, and vectored in a field service technician to change that fuse. The whole system immediately came back to life. Poor design, perhaps - we notified Engineering of the syndrome - but excellent diagnostic capabilities.
I slightly disagree with the point about Linux not having comparable trackin of memory errors.
I do agree that you are right - generix X86 hardware will never come close to having that grade of error logging.
However, my systems have ECC memory and log memory errors quite well.
"An ex-colleague here; I seem to recall your name from one of the tech/FS VaxNotes conferences".
Hi Stoneshop - Good to hear from you! Yes, I am afraid I rambled a great deal in VAXNotes. It prepared me admirably for a life of writing and lecturing after DEC. By the way, why is there nothing remotely as good as VAXNotes nowadays? I know PHBs tended to hate it because it encouraged underlings to talk direct to one another, ignoring the gatekeepers - but surely that's not a good enough reason?
Yeah, there was a wealth of info there, and not just technical. Most of the notesfiles had no official status, but at least they were a searchable source, and could point you to the right FCOs, SPDs etc. It's never even been ported to Alpha, AFAIK, which baffles me.
I think the closest comparison, functionality-wise, would be Usenet, but with one central server instead of being distributed, and with infinite retention.
Worked for DEC for 8 years and spend most of that time elbows deep in some form of VAX, MicroVAX or Alpha all running openVMS. 6 years contracting afterwards based on my OpenVMS experience and fun redeveloping OpenVMS Alpha hardware to run 64bit NT4 to support an exchange platform. Great OS from a company that only started failing by falling for the hype of UNIX!
$ show sys
OpenVMS V7.2-1 on node NS4 10-JUN-2013 22:37:36.87 Uptime 1356 08:03:02
Pid Process Name State Pri I/O CPU Page flts Pages
00000101 SWAPPER HIB 16 0 0 00:00:22.43 0 0
Mid-September, this one will go on 4 years of uptime. Turns out to be more reliable than some UPS systems.
But the official HP press release doesn't actually the say the end of OpenVMS as an OS, but the end support of OpenVMS 8.4 on the Intel Itanium processor architecture in the year 2020.
HP Project Odyssey remains a key strategy to deliver mission-critical capabilities to customers by offering the scalability, continuous availability and efficiency needed by organizations to achieve their mission-critical business goals and improve productivity.
“More than ever, our mission-critical customers face demands for uptime, performance and uncompromising choice for their most critical applications,” said Mark Potter, senior vice president, Servers, HP. “HP will continue to make innovations to our HP Integrity and HP ProLiant portfolios as well as our HP Nonstop, HP-UX and OpenVMS operating environments with mission-critical Converged Infrastructure—all part of our commitment to transform the server landscape while ensuring investment protection for our customers now and into the future.”
Various OpenVMS fans have been in touch to argue that their favourite OS isn't dead. Yet, Liam didn't write that, simply that support is coming to an end as HP sunsets the thing.
The roadmap says it all, really. If you're not on Itantium v8.4, support will have ended by 2016. If you are, you've got until 2020 and HP isn't interested in the latest Itantiums anyway. Would you stick around, or migrate?
"....Yet, Liam didn't write that....." Mr Proven most certainly more than strongly inferred it. I don't ever recall anyone describing someone being taken out back and shot as anything other than terminal. And if you think I'm grumbling you should see how much he upset our VMS dinosaurs!
".....Would you stick around, or migrate?" Migrate to Linux, just probably not yet. Dare I say it in range of our dinosaurs' hearing aids but we'll probably delay it for quite a while. There are certain jobs that even I'll admit it is simply easier to leave running on VMS, we can wait for the requirement they serve to die or look for alternatives over the next five-plus years, thanks.
Like many on here, I spent many years working on VMS. I especially enjoyed the command line interpreter (CLI), which allowed you to abbreviate all commands to the minimum distinct number of letters. So, SHOW PROCESSES became SH PROC, or as I typed many times, SH PORC. And you could use the CLI for your own code, too, so you could define long and baroque command sequences if the mood took you.
Some say that it is the operating system upon which god runs the earth simulation!
It has been good to me for over thirty years - it's command parser and meaningful error messages will be sorely missed.
I now find my beautiful, robust and secure o/s running on an emulator on windows. Uch.
My hat's off to those original vms developers still on the planet.
In fact, if I caught Dave Cutler in bed with my wife, I'd tuck him in!
the Vaxcluster was so robust that any machine on the cluster could become the controller. whatever NIC had the lowest MAC address was next in line. so one day, the whole college was running abnormally slow, and I started chasing around to find out why. turns out the 11/780, which was the usual controller, had a creepy NIU cable, and when it bumped and was blown away by the cluster when it came back, my 286 PC with Pathworks became the cluster controller. replace AUI cable, reboot the PC, and life goes on.
also taught me a valuable lesson about minimum bend radius on cables. the whole cluster start bouncing one fine Friday afternoon at end of finals week. I had a loaner SNMP 1.0 console at the time, and between that and the console printer found out all the AUI cables were shorting and bouncing both VAXes. now, this was momentary. but as I alluded, VAXclustering was so robust that it had a primitive for reboot-anything. if a node missed a heartbeat or two and then came back on, the cluster controller would send a "EFF YOU, D I E !!" message to that machine, rebooting it.
It's a nice-sounding story, thanks for telling it and giving me the opportunity to respond with this, but as written, it's fiction. The giveaway is "my 286 PC with Pathworks became the cluster controller".
That being said, back in the day there were unusual but not impossible circumstances in which the VMScluster software could end up using a low powered **cluster member** (ie a VMS box ie not an x86) as the "lock master" for some operations related to the distributed lock manager, and in certain circumstances this could cause a bottleneck visible to some applications on other cluster members.
This was sufficiently unpleasant when it happened for code changes to be made to the clustering software so that customer specified factors such as CPU power or network performance could be taken into account before allocating a particular box to be in charge of significant aspects of distributed locking.
From memory, the LOCKDIRWT system parameter is part of the picture. See e.g.
http://h71000.www7.hp.com/doc/731final/4477/4477pro_003.html (though the relevant changes go back long before V7.3).
DEC VMS ran DECnet - a far superior networking suite to anything that came out of Redmond. And DecNet Phase IV is still probably better than TCP/IP even taking into account IPv6... I'll ignore Phase V as being based on OSI it was obviously superior to TCP/IP... :-J
The need for DEC to support LAN Manager really was a sign of the changing sphere of influence, DEC by not releasing VMS into X/Open (for the basis of POSIX) and also releasing a desktop system at PC prices, basically lost out on the OS front to Microsoft, lost out on system sales to Sun, Compaq etc. and lost out on networking (as did all the proprietary systems) to TCP/IP.
$ cnt = 99
$ msg = f$fao("!UB month!1%C!%Es!%F of VMS support", cnt)
$ write sys$output f$fao("!AS on the wall!/!-!AS", msg)
$ write sys$output "Take one down and pass it around"
$ cnt = cnt - 1
$ if cnt .gt. 0
$ msg = f$fao("!UB month!1%C!%Es!%F of VMS support", cnt)
$ write sys$output f$fao("!AS on the wall!/", msg)
$ wait 00:00:02
$ goto loop
$ write sys$output "No more months of VMS support on the wall"
Another old lag here, from VMS 3.2 up to today, still the most reliable boxes in any of the organisations I've worked for.
What other OS would allow you to exit a script with:
$ exit %xB70
%SYSTEM-W-FISH, my hovercraft is full of eels
$ exit %xB72
%SYSTEM-E-FISH, my hovercraft is full of eels
$ exit %xB74
%SYSTEM-F-FISH, my hovercraft is full of eels
$ exit %xB76
%SYSTEM-?-FISH, my hovercraft is full of eels
$ exit %xB78
"the source code was available to buy"
The listings which were commercially available were not necessarily complete, and not necessarily enough to build VMS from scratch. Code licenced from elsewhere is said to be one reason stuff was/is excluded; commercially sensitive stuff (eg code related to DEC's own Mass Storage Control Protocol, MSCP) was also excluded.
Whether any *important* *irreplaceable* bits were/are missing is a different question. E.g. MSCP wouldn't be relevant to most current systems.
Access to source only fixes the VMS problem while IA64 systems continue to be available (maybe that's time enough?) Porting to a different platform with a better future than IA64 would require a few other pieces, e.g. compiler tool chain.
It's so sad.
VMS was clearly the best operating system, able to share a file system between multiple system
with automatic file locking at the record level. With wide area clusters disaster proof data centers
could easily be be created.
IT was EASY to use, with easy access to the operating system and an English like command language.
It survived for years while DEC/Compaq/ and HP tried to kill it because it was the best and customers
needed the reliability and features.
They could have marketed it and it would be the leading operating system in the world today. It takes
so few people to manage massive clusters of computers and data, as well as with X window terminals
a few people could have supported thousands of users. And the reliability would be unsurpassed.
Oh well, I'm sure I'm preaching to the choir. It proves you can build the best mousetrap and for upper management stupidity destroy the golden goose.
Dec was a special company until Ken Olson left it. It made LONG TERM decisions and it's long term
growth was planned. When bankers got to take over the board, they made it like any other company,
short term viewpoints, and destroyed such a wonderful company. It was a company that put
care of the individual, the environment, society, and quality above profits. That was a formula that
actually generated huge long term profits with incredible loyalty form employees to customers.
Bizarre. I'm glad I could have spent most of my career as a VMS Cluster Administrator and providing Mission Critical Technical Support..
Matt the Moron (tm) at it again
That project is for an Itanium emulator (just like there is SIMH which emulates amongst many other things VAX, and there is also a commercial Alpha emulator). VAX, Alpha and Itanium are chip architectures. They are also the 3 architectures under which VMS runs. When the Itanium finally dies, VMS will have no home except upon these emulators.
"Hoff" of Hoffman labs, has a legendary status in the VMS community and was pushed from HP during one of Carley's purges IIRC. You wouldn't know that of course, because you are MtM (tm).
"Matt the Moron (tm) at it again....." <Sigh> Some of the dinosaurs are just so touchie. You suggest a possible out - use an Itanium emulator to run your Itanium OpenVMS apps on x64 - and they shriek and whine. Oh, hold on a sec - it's because they're too old to actually know what an emulator is! Quick someone update them into the 21st century.
"....When the Itanium finally dies, VMS will have no home except upon these emulators....." So, hold on a sec - you're admitting the emulator is a good idea, but calling me a moron for suggesting support for it? That must mean you are calling yourself a moron! At last, something we can agree on, you indeed are a complete moron.
"....."Hoff" of Hoffman labs, has a legendary status in the VMS community...." Hey, Sherlock - how did you think I heard of the emulator?!? Senility must be hitting you hard, they probably should have taken you out the back and put you out of your misery long ago. It would have been a mercy killing. Don't worry, it will all be over soon and you can leave the real work to the Penguinistas. Just go curl up in a bathchair with a cup of Horlicks, there's a good chap.
I have such fond memories of VMS:-
I left school at 16yrs and straight in to a software house writing applications for local authorities using VAX BASIC.
DCL was a wonderful shell scripting language. So powerful. So simple.
LSE - great editor
VT420/520's - I would later replace them with Gateway 2000 PC's running Win95 and Reflection, because it was cheaper and more flexible than a 'dumb' terminal. Better? Hmm...
Lovely clean, clear manuals. With the folds half-way along them so they stood up on their own.
The "RECALL" command was a personal favourite.
Long filenames and versioning - came as a shock to me when I later moved to Windows and found those lacking.
Manipulating FDL's by hand.
Upgrades/installs that just worked.
Limited downtime, because you only needed to take down parts of the system, not all of it.
Call's to the SMG$ library - so I could create "windows" in my green-screen apps.
I would later get in to systems management, which brought me exposure to DecNET, Pathworks, Manageworks, TeMIP.
Pathworks gave me exposure to move more towards NT/Windows Server specific networks. Until in about 2002-3 when I no longer went near OVMS systems at all.
I'll never forget the first time I used Clustering on Windows. I couldn't believe how it "worked", compared to on OVMS.
I may not be using OVMS any more. But, I certainly wouldn't be sat here, aged 42 with 26yrs of professional I.T. experience crossing programming/analysis/management/networking/etc, were it not for OVMS.
I'll miss you. You were my first true I.T. <3.
Biting the hand that feeds IT © 1998–2019