Slashdot Mirror
An Interview With Mark Gorham Of OpenVMS
Ken Farmer writes "There's already been one press interview with Mark Gorham, but that encounter with HP's VP of the OpenVMS Systems Division omitted some technical details that warrant further attention. Hence, SKHPC thought it appropriate to go on a deep dive with one experienced in OpenVMS and SCUBA diving as well."
I don't think it's necessarily more painful than other systems, but it does seem to be pain that is easier to schedule (more work during your day, fewer middle of the night emergencies).
Of course, you can't play a lot of games on it...
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I really enjoyed using OpenVMS and although I no longer use it on a daily basis I do still have an account on a friend's system that I log into from time to time. That interview reminded me of how wonderfully supportive the OpenVMS community is, even if you don't like OpenVMS you have to love the spirit, dedication and willingness to help of these guys. I especially remember the USENET posts by the recently departed John Wisniewski. Here is one of his posts in which he names the top "F" reasons OpenVMS is not going to die.
I started working on VMS systems in 1997, so I was a relative latecomer to the OS. Still, I quickly learned to appreciate what it's capable of. The ancient hardware I've got in my garage (VAX 6000, VAXstation 3100s, MicroVAX IIs, AlphaStation 200) is capable of more useful and reliable clustering, out of the box, than Windows 2000 AS. Almost undoubtedly better than 2003 as well.
I've had to migrate a legacy VMS application to a Windows 2000 AS cluster, and after 10 years of operation with no more than a few hours' downtime at any given time, the old Alpha cluster is ready to be shut down next week. It's sad to see it go - the Windows version will probably never be as solid and reliable, but what counts to management is that for the price of annual hardware and software maintenance on the old cluster we can buy all new Dell servers with 3-year warranties every year or two.
I did once set up an OpenVMS machine with the intent of taking it to DefCon, but never got around to it. Others did, though, and there's nothing like watching a bunch of hotshot Unix crackers pounding their heads on their keyboards out of frustration.
(And that's just trying to get a volume listing, not breaking in!)
Many, many posts come from people who have _never_ touched OpenVMS. For these people, I invite you to the Deathrow OpenVMS Cluster. This is a OpenVMS cluster (running OpenVMS 7.2) or VAXen and Alphas. It's free for use by the general public. Yes - you get access to the compilers (COBOL, Java, C, FORTRAN, BASIC, MACRO, and much more!). The entire point of the system is for people unfamiliar with OpenVMS to have the change to _play_ with OpenVMS.
Check out http://deathrow.vistech.net for how to open your own account.
Well, I'll admit to liking VMS. It has been a few years since I've used it, but there were definately some nice things about it. It was definately designed to be used in large systems with lots of users, unlike Unix. It had features like privileges for just about everything that you can think of - much finer granularity than all or nothing. It had a fairly well developed system of ACLs that could be attached to operating system objects other than files (unlike Unix, not everything is a file in VMS). One of my favorite things to play with was logical name tables (something that doesn't really have a Unix equivalent).
On the other hand, there were some things about it that were rather clunky. Spawning a sub-process took a while. There was no easy equivalent to piping the output of one command into another.
I guess the thing to do is to learn about other options and use the best too for the job. Don't get locked into a single solution for everything.
un-ALTERED reproduction and dissimination of this IMPORTANT information is ENCOURAGED
I looked and looked but could not find whether or not a 64 bit x86 version of open vms is available.
VMS presumes CPU functionality that does not exist in x86. Mainly, this has to do memoy management and "ring" protection.
A VMS engineer told us (at an Oracle Rdb conference in Nashua) that Intel purposfully made certain parts of the Itanium look like the VAX. That made it possible to port VMS to Itaniac.
"I don't know, therefore Aliens" Wafflebox1
If VMS also worked on Alpha, what were the barriers for VMS that allowed UNIX to gain more share? UNIX was expensive back then, so unless VMS was really expensive, that couldn't have been a barrier. Was it just DEC's infamous marketing dept.? It seems that other comments make VMS out to be a pretty nice OS.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
I don't know how much of Cutler's original work was in Assembler and how much was in BLISS, since that too was a popular language at DEC. I heard long ago (around the time of VMS v3) that Cutler's original work was really crude -- he was the master of a quick V1, but his code was inefficient, so it had largely been rewritten early on. Maybe he did just use Assembler and leave BLISS to other "wimpier" coders.
Also bear in mind that the original VAX instruction set was really huge, allowing one assembler instruction to do things that were quite long on other systems. It turned out, in most cases, that a macro of small instructions could do it faster than the VAX microcode, so instructions fell out of the ISA over time (mainly when the MicroVAX chips came out), but it didn't hurt performance. The VAX-11 was the apotheosis of CISC, a philosophy that probably was designed to help assembly-language coders.
VMS didn't even have a C complier for years, and it wasn't much good for a long time. But it did have a lot of other strange languages. Those were the "we ain't Unix and we like it that way" days.
Your post: "Plus, if you know the Windows NT kernel, you pretty much know the VMS kernel [wink wink]."
My puzzlement: Windows NT == VMS? Really? Are you serious?
More of a stab at M$FT - I think the gentleman's agreement they reached was that DEC wouldn't sue them over theft of proprietary trade secrets [i.e. theft of "Intellectual Property"] if M$FT agreed to port NT to Alpha hardware.
But as to the underlying question of the NT kernel: Folks, it ain't all that bad. In just about every test anyone ever throws at it, the NT kernel bitch slaps the competition.
Compare e.g.:
Now the decision in NT 4.0 to break the pure client/server model, and bring the windows/graphics stuff into "Ring 0", may have contributed to some system instability [particularly if you're using a bleeding-edge video card], and the NT Domain/Active Directory network infrastructure may be a pale imitation of a true directory like what Novell can offer you, but the underlying Windows NT kernel itself ain't nothing to laugh at.The killer blow was when the architect of VMS, Dave Cutler, moved over to Microsoft.
Security suffered from the transition because Vax/VMS had KESU shells and the Intel platform didn't support the Exec mode. Each shell had specific instructions that could only run in that shell, and it's own discrete address space. A user program couldn't write to the kernel, or to a device driver, or to any structures managed by the Supervisor layer. Since user mode exe's were not able to reach protected address spaces where the other bits lived, exploits were few and far between.
Do not mock my vision of impractical footwear
There was a Jurassic Era in which T-Rex was the biggest and baddest. All that remains of T-Rex V1.0 is fossils and a few skeletons in the world's best museums of science.
There was a Jurassic Park, which was a work of fiction by Michael Chricton (and not one of his best, either). All sorts of dinosaurs roamed that fictional evolutionary leap forward into the past. The theatrical verion was worse than the book, and you're more likely to see black helicopters hovering over your house than you are to have a close emcounter of the worst kind with a rabid velicoraptor, or whatever those things were called.
In the IT industry, dinosaurs can evolve. The mainframe did, as did VMS amd UNIX. They aren't new, but they sure are improved and have adapted quite nicely. They are neither obsolete nor extinct. The Commodore VIC-20, which materialized in the 1980s--well after mainframes and VMS and UNIX showed up--is both obsolete and extinct. And nobody's booting any OS on a Convex or PRIME box any more.
So being a VMSasaurus Version 8.2 isn't a bad thing to be ;-}
IT Consultant and Publisher, Shannon Knows HPC
*** Quantum Mechanics: The Dreams of Which Stuff is Made ***