Revitalizing the Internet and VMS 267
Da Beave writes "Similar to the
"Going Back to the Past of the Internet" /. post,
these guys want
to not only revitalize the Internet, but the
OpenVMS Operating
System (Started by Digital, then to Compaq, now to HP....).
They have a cluster of VAXen (32 bit) and Alphas (64 bit) for public
(non-commercial) usage.... With more compilers than you can
shake a stick at, and it's considered one of the most secure
OS's around....." VMS was one of the first operating systems I learned to use. This page really brings back some memories, both good and bad.
VMS++ = WNT (Score:4, Informative)
Docs, if jumping into the free shell (Score:4, Informative)
This [compaq.com] seems to be the best guide for a user who's never even looked at VMS before.
VMS didn't leave (Score:4, Informative)
David N. Cutler, the chief software architect of NT, worked for DEC in the 70's. He had designed VMS and worked on releasing newer versions. Cutler became bored doing this so DEC gave him several hundred engineers and computer scientists to work on a next generation CPU and OS.
In 1988, DEC laid many on David N. Cutler's team and nuked both projects. He was fairly ticked off and left Digital only to be hired by Microsoft, bringing quite a few former DEC guys with him.
Cutler designed NT very similarly to how he designed VMS and Microsoft actually licensed several parts of VMS from DEC in a cross-licensing agreement in which DEC got the chance to use some of the Windows API in pure VMS. (How useful this was to DEC is questionable...)
So despite Microsoft marketing that NT is a cutting-end OS and even naming it "New technology," like Unix it is still based 1970's ideas and code.
As for pure VMS, my school uses it for both the C and the Pascal classes.
DirecTV uses it for their billing system called STMS. (How I found this out has plenty to do with
I have found that it is very similar to DOS on steroids. It uses very similar commands, uses forward slashes `/' for parameters, uses extentions for file names (the same ones as DOS;
Some differences: Its C compiler sucks, it never overwrites old files but instead makes files of a similar name (foo.c, foo.c;2, foo.c;3 etc.), its memory manager is famous for being fairly slow (though DOS has no memory management to speak of), and it makes a good server OS. Unfortunately if you want to run it, you have the choice between VAX and Alpha, neither of which are particularly common machines.
You can run quite a bit of Unix software on these things just fine if you compile it letting the make script know that the system is VMS.
Thevax.org (Score:2, Informative)
If you like VMS, run NT 3.51 SP 5 (Score:3, Informative)
Re:VMS better than *NIX? (Score:4, Informative)
VMS was an engineered solution, by engineers, for engineers. UNIX is a organic one, slanted towards experimentation and diversity. In Unix you have a plethora of high level tools to accomplish the same things, in VMS you had one very well though out generic one. Usually a high fidelity implementation taken directly from the core of Computer Science theory that was hard to find fault with. For example, queue management. In Unix you have a dozen print tools, batch tools, etc. each with their own unique configuration nightmare. In VMS you had Queue Manager, a single thought out queueing management tool that didn't press "printness", "batchness", "uucp polling", or whatever, into the equasion. Some of these included...
Queue Mangement
Distributed Lock Management
Object Access Control and Rights Management
Record Management Services (File structures) (RMS)
Some question the RMS bit, myself included. Although it was one "well thought out tool" the idea of integrating file structure into the OS simple did not return on the promise. Hey, not everything can be perfect.
At a lower level, VMS had a number of nice features too. For example, every system call that could, possibly, be interrupted had the ability to complete by calling a function by name (AST). Sorta like sigio but far more powerful since each and every call specified its own handler and parameter block. Noise like Apache's "wake once" event wakeup problem simply could NEVER have been become an issue under VMS. The design flaw that lead to the "Apache problem" didn't exist.
VMS had some powerful per process management features, which many UNI* types don't even grok, let alone implement, yet. They were, however, complicated -- but most useful when you knew what you were doing and needed to do it. UNI* tries to "just work", but as the VM types in Linux are learning it isn't always that easy.
Unlike UNI*, VMS has a very powerful scheduler, and it let it's owner call the shots. Unlike UNI*, you had priority and runtime quantum and VMS never confused the two. So, something was priority 0 WOULD NOT run, ever, if something at priority 1 could. Lock your resources if you want, it's was your machine. UNI* takes gargantuan steps to save people from themselves.
Then, the VMS scheduler was IO sensitive. If you genererated a keyboard interrupt, your process was temporarally bosted a few priority points for a quick burst of responsiveness. Again, like every tool in VMS there was ONE scheduler and it offered a single, complete, and unified, end-user experience that deftly handled batch, timeshare, and real-time programming.
Re:but VMS lives (Score:3, Informative)
And, no, you can't just fire up CMD and get that "old VMS feeling". Case in point, type help on Windows and compare that to help on VMS. Light years apart buddy!
Test Drive (Score:2, Informative)
Re:Spare Me. (Score:1, Informative)
Dave was certainly as influential as anyone in the creation of VMS; there were only a couple of others with anything close to an equal claim. And despite the assertion in another response, he remained closely associated with VMS (including contributing to and reviewing code) through at least V3, though nominally working in other areas.
As for only 'bringing ideas' to NT, rubbish. Dave brought along quite a few DEC engineers as well, plus code from the Mica (VMS follow-on) project the cancellation of which drove him to Microsoft (Microsoft later settled with DEC for the use of that code, which was readily identifiable from being identical right down to the comments...). Incidentally, NT owes nothing to OS/2 (yet another comment seen elsewhere), beyond what Microsoft required for interface compatibility (and most of that is in the OS/2 personality subsystem, not in privileged code). The confusion may stem from the fact that an OS/2 project existed at Microsoft before (and was eventually replaced by) NT.
Let's see - might as well bring all my comments together here: As for not bringing the the file system along, that's true: not only did Microsoft require FAT file system support for interoperability with existing Windows environments, but VMS's ODS-2 file system, while absolutely top-notch for a late-'70s product, was a bit behind the times for the early '90s (though still absolutely rock-solid and an achievement Andy can justly be proud of 25 years later). While I don't consider NTFS to be the ultimate file system either, its log-protected nature and b-tree-structured directories are steps forward and at least form a foundation from which further progress can be made.
As for security, NT's is quite similar to VMS's. And the use of 'personalities' for the various environments supported by the NT kernel and Executive *may* have borrowed from Andy's work on a common security kernel for VMS and DEC Unix (though that's purely a guess on my part).
It is true that the distributed lock manager didn't get a second home in NT, possibly because Dave never seemed to adequately appreciate clusters (I have no idea why), or possibly because other luminaries at Microsoft (Jim Gray being a very prominent one) don't consider shared-disk environments (one of the driving forces behind the use of the DLM on VMS) to be the right way to go (though the DLM is far from useful only in that area). I suspect that this will eventually prove to have been a bad decision on their part (even though it may well not be because of the need for shared disks, since new technology may remove that consideration), but it appears to have been a conscious one, not simply the result of Dave's not having been involved with developing the DLM (because its implementation has been exhaustively described in public literature, and in fact IBM cloned it back in 1994 to use on AIX to support Oracle Parallel Server there).
By all accounts the NT kernel is the usual efficient, rock-solid product typical of Dave's efforts. Much of the rest of the privileged (Executive) code in the system was also carefully honed under his supervision, but a fair amount was not, and it shows. And, of course, it was required to support the defined Microsoft interfaces, which themselves open up gaping security holes in areas (such as the trusted personality subsystems) that the kernel and Executive cannot easily plug from beneath.
Contrary to the assertion in yet another post, Dave is still (or at least was the last I knew, which was fairly recently) at Microsoft. So are an impressive number of other industry legends, though most of them seem to be in its research division rather than doing production work. If Microsoft ever actually managed to put the talent it has to good use (something DEC was very good at, at least until the early '80s), the result would be phenomenal.
It's not worthwhile to get into the Unix vs. VMS war, especially as I believe that both have major strengths, and weaknesses where they could benefit from learning from each other. But it is nice to see that at least some knowledge of VMS's strengths still exists, even in such a Unix-oriented community (where the additional presence of a great deal of misinformation about VMS is hardly surprising).
Bill Todd
P.S. Just to be complete: versioning is implemented such that when a process creates a file (rather than opens an existing one) a new version is created. This leaves it up to the process whether to update an existing file in place or (as is pretty common even in non-VMS environments with, e.g., editors) create a new one to work on (copying the contents of the old one) while leaving the old copy untouched.
nice things about VMS (Score:4, Informative)
2) Wonderfull Batch/Print queue system (unix is nowhere close). Easy to use, easy to create/manage queues, full featured.
3) DCL scripting language was pretty good for its type (better then sh)
4) A Command Line Interface that was pretty predicatable in its use, which was great for causual users.
5) Good on-line help that was nested. You didn't have to eyeball pages of "man" output.
6) Uptime reliabiity that Unix has only recently started to approach.
7) MMS was superior to make. CMS was a superior source code library. MMS and CMS were integrated.
8) I'll take EDT or LSE over vi any day!
I haven't admin'd VMS for 7 years but I have fond memories of it.