Slashdot Mirror
Revitalizing the Internet and VMS
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.
No account of VMS would be complete without acknowledging that Dave Cutler took VMS from DEC to Microsoft to create Windows NT. He acknowledges the acronym WNT was a pun on VMS++ (add one to each leter of VMS ala HAL++ => IBM in 2001 a Space Odyssey.
Seastead this.
This seems to be the best guide for a user who's never even looked at VMS before.
Says the RIAA: When you EQ, you're stealing bass!
VMS didn't go anywhere. Windows NT is based so closely on VMS that some have called it a new version of VMS with a GUI tacked on.
/., ironically) }:>
.exe, .obj, etc.) but unlike DOS is very good at having a ton of simultaneous users.
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.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
NT 3.51, with the last service pack SP5, is the purest expression of the VMS model in NT. That's the last version before Microsoft let the kode kiddies from the Windows 95 group put their stuff in the kernel. In NT 3.x, all the GUI stuff is outside the kernel and untrusted, so there's some hope of securing the thing. In NT 4, all that crap went inside the kernel. A version of NT 3.51 without networking once passed NSA's lowest level of security testing.
Off the top of my head...
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.
I disagree about VMS being less secure. In the hands of a novice, ANY system is insecure. VMS is/was one of the most secure operating systems around. That is partially due to the fact that it didn't have a native TCP/IP stack (at least it didn't when I worked with it). How many DECnet hackers are out there, raise your hands. And face it, most security issues now stem from network attacks, not from a file system or process scheduler standpoint. And another thing, compare the authentication mechanism and the options you have with the VMS UAF facility vs. the passwd/shadow files on Unix. VMS wins.
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!
Believe in things of which no person has ever learned
1) Multiple account-by-account security systems (unix really needs to swipe this)
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.