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.
And the trolls say BSD i dieing.
I had a job offer from Compaq to work on the OpenVMS kernel. Sounded like a good deal. I got a chance to fly to Nashua, New Hamshire to check out the facilities and meet the people I would potentially be working with. Let me tell you, these guys were incredibly smart.
Then I got the contract. It had a clause stating that any idea I ever had as well as any ideas I had while I worked for them belonged to them. As well as a non-compete clause. They wouldn't budge on it, so I turned down their offer.
Oh well. I really would have liked a chance to work on their OS, but they weren't interested. Really too bad.
..also, I would like to ask everyone to think what would they like to be added/enhanced to/in OpenVMS, and publish these requests at openchallenge.
And the relationship between VMS and UNIX is analogous to the relationship between Windows NT and Linux. VMS was indeed considered very secure--probably because it had lots of "security features". In real life, however, VMS systems were often a lot less secure than UNIX systems because it was nearly impossible to get all the security setting right. More generally, UNIX was built around a small number of simple ideas and paradigms, while VMS attempted to be the all-singing-all-dancing operating system.
So, if you want to get that "old VMS feeling", just fire up a Windows NT or XP machine and type at the command line--it's roughly the same.
If Windows NT was built by a bunch of VMS people on top of OS/2, using VMS concepts, why does it suck so badly?
OLPC Australia
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!
Yes, Dave Cutler engineered the VMS Kernel and the NT Kernel. He was not responsible for all of VMS so could not bring all the knowhow with him (in the early days, Digital and Microsoft were good friends as NT was also targeted at their Alpha chip). In particular, he didn't bring along the file system or security concepts (Andy Goldstein was responsible for that) and he didn't bring along the distributed lock manager, which was essential to the smooth running of VMS Clusters.
even at the bank I work at and we milk things for a Loooong time. I've a dually alpha, but I loaded debian on it. That was a huge pain...only got it done thanks to MadHack, but man that thing flies.
errr....umm...*whooosh* *whoosh* Is this thing on ?
And this article brings back bad memories, nightmares. I have always hated this unelegant, bulky and heavy operating system.
At the time I didn't know better, but had a vague idea that it must be possible to make something better. Luckily other VAX users had thought so a long time ago, and ported UNIX to VAX.
Then after 1 year of VMS we got our first UNIX machine (a Convex minisuper) and then I saw the light. In my opinion, UNIX and VMS were two opposites in almost any aspect. Using UNIX was a joy, it was elegant, efficient and interesting.
I have never been able to understand how (later) in a single company two such opposite culters could stay together (in DEC, the UNIX and VMS groups) and it turned out, not surprisingly, they could not.
Everyone who likes UNIX and who knows both UNIX and VMS well cannot but hate VMS. I bet many, like me, still wake at night sometimes due to a nightmare about VMS. In that respect, WNT is a worthy VMS++ indeed.
The problem is that although for many years, Digital didn't give sources, but they gave away source listings. Regrettably they stopped after VMS 4.5. However the system was exceptionally well documented and it was possible to write some neat hacks (for example, I did one to fetch somebody elses command line history buffer). It was far from as open as Linux. However, many old VMS people have fallen in love with Linux because it is so accessible.
I had to use it when I was in college. I found its user interface to be absolutely wretched. Horrid abominations for editors like SOS, EDT and TPU. And the VMS mail client was absolutely bletcherous. A lot of the things other people liked like the versioning file system I found more of an annoyance, if I want version control I'll use something that lets me check things in and out when I want to.
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
Even in 88 all you have to do was to enable the secure attention logon. You then got the logon prompt with a break key and nothing could intercept that.
They aren't distributing OpenVMS - they've just running it on some computers and allowing public access.
Their software license doesn't allow them to let you use it as a business platform.
Maybe you saw 'OpenVMS' and thought it was Open Source? It's not - it's proprietary, commercial software.
And it is still stable which is why it is being used for electronic trading.
One of the first things I remember ever being told about Windows NT was that it was a direct rip-off of VMS. In fact, if you ever wondered what NT meant (Network Technology?) it supposedly doesn't really mean anything...
Microsoft supposedly named it NT because WNT is simply +1ing the letters VMS.
put the what in the where?
Michigan's child support system runs on it, or most of it does. Finally last year pieces of it started getting replaced with an Oracle back end and Java (urg) front end. But at this moment most of the state's child support personnel log onto a VMS system via terminal emulators.
Frankly I find the old application much more responsive and pleasant to use. I'm sure in just 5 or 10 years of bug fixes the new system will be just as good ;)
Another great free site is thevax.org these guys have set up some VAXen machines on the internet for free for people to use. All you need to do is submit a form for a free account. So if you want some alternatives, here they are. Already a lot of users from around the world.
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.
Yah, they're really cryptic and difficult; about as tricky as MS-DOS. "dir" to see your files, "type" to list a file, "copy" to copy a file, etc. Real obscure syntax since everyone got bit with point-and-click disease!
-- You are in a maze of little, twisty passages, all different... --
I could never get over the command completion in VMS... get the first three chars of the command correct, and it would usually run. Sometimes I'd swear I only got the first three letters of my password correct, and it would let me in.
Then there was the campus gripe about the "longest email addresses on the internet": @sitvax.stevens-tech.edu. My gripe is I started too late to get a bang path address...
VMS was/is the most secure operating system ever written. I know, I tried to hack one that I bought at a hamfest. I tried everything. Every hacker text file from the 80's I consulted said "forget it". The ONLY way to hack a VMS system is to social engineer a password or use a dictionary cracker for weak passwords. There are no maint. backdoors, single user mode boot hacks, etc. and believe me, a simple ^C is not sufficent. I have two Micro-VAXen and I wound up having to reload VMS from scratch, just for want of a supervisor password. Also, the error messages were deliberatly long and informative, very helpful if you actually read and act on them (i.e. troubleshoot a problem).
-- You are in a maze of little, twisty passages, all different... --
You can also try out OpenVMS in the HP Test Drive Program (http://www.testdrive.compaq.com/), where it has been there for several years now running on a cluster of Alphas. In fact, for most of the past month, we had it running on an EV7 prototype, although unfortunately that system is now offline. If you're interested in VMS, I'd also suggest you check out http://www.openvms.compaq.com/. And by all means, if there's something you'd like to see in our program, let us know.
While it was quite easy to port well-written code between OpenVMS and Unix systems, OpenVMS just didn't maintain the market share to survive. The world focused on *nix vs. Windows, with a stable core of corporate mainframes, and a few specialist markets (Apple in media content, SGI in CGI editing.) Much like OS/2, it was a victim of poor marketting that didn't show the computing public what the real benefits of their advanced features were.
While I wouldn't mind seeing OpenVMS on a client site, I really don't expect it will ever happen. Business does not buy orphans, and they're the only market that needs the benefits of OpenVMS features. *nix systems already have add-on packages and projects to address those needs in other ways.
I do not fail; I succeed at finding out what does not work.
"There are no maint. backdoors, single user mode boot hacks, etc. and believe me, a simple ^C is not sufficent. I have two Micro-VAXen and I wound up having to reload VMS from scratch, just for want of a supervisor password. "
This is untrue. In almost all cases one can use set UAFALT (IIRC, else it is some similiar command
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I never used VMS, and I was ignorant of the VMS-NT connection. I lost my chance to use VMS when my school got its first VAX, and decided to run Unix on it instead of VMS. The decision was not universally popular on campus! Unix was still a work in progress. In particular, Bill Joy and his bunch at Berkeley were still hacking out a Unix that could make proper use of the VAX's memory management hardware.
It's funny. We think of the rivalry between Linux and NT as part of the broader conflict between Microsoft and various anti-Microsoft forces: the open-source community, MS's competitors and detractors, etc. But it seems that it's partly a continuation of the decades-old rivalry between Unix and VMS!
It's supposed to be completely automatic, but actually you have to press this button.
close but no banana
NT is named after the NT register in the 386
where NT stands for Nested Threads.
of course marketing spin turned it into
"New Technology"
so we now get "WindowsXP based on NT Technology"
or Windows XP based on New Technology Technology
a bit like PIN Number
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
On Unix I could easily determine exactly what files existed with a few commands, easily open any file on the system with the same call, and parse a filename into it's parts with 3 lines of C. A program to copy a file was ten lines at most, while due to RMS "pip" on VMS was larger than any other program on the system and an absolute nightmare of bugs and patches.
It was also trivial to run a program in the background, and fork allowed me to experiment with multithreading, something that only the ultimate wizards could try on VMS.
From more advanced programmers I heard the CLU compiler used a method of calling that was as much as six times faster than the calling sequence VMS required and that one of the big problems was cutting down the number of function calls Clu generated to get the speed acceptable because of this.
Unix had "man", a way to look at documentation using the computer (another revelation at that time), and you could really find what you needed. Also all the documentation fit in two 3-ring binders, while VMS had an entire wall of books.
I never heard a single statement by anybody that Unix failed relative to VMS and I was dumbfounded that Dec did not scrap VMS right then and there and switch to this better system.
Now I was in high school, and I did not know much then. Quite likely I missed the advanced areas where VMS was better. But to a novice there was no comparison and no competition, Unix blew VMS away completely and utterly.
I find it incredible that people will keep saying this crap, the same people that say "Unix is hard because you have to use the CLI". They then bring up this case-sensitivity issue, a feature that is useless except if a CLI is used. The average dummy using Windows would never notice if files were case-sensitive, and in fact would never notice if the file system allowed more than one file to have the same name!
It is also trivial to provide the ability at the program level rather than in the system. While you are at it you can provide spelling correction of file names, filename completion, and lots of other things that are enormously more user friendly than just the fact that 'a' and 'A' can be interchanged.
VMS did not let you put a lot of nice characters like space or multiple periods in the filenames, a far, far worse problem for the user than case sensitivity.
From a button seen sometime and somewhere in late 1980's or early 1990's:
VAX/VMS - Software for the Sixties.
The oneness applied to RMS as well, whichever language you used, you could always access an RMS file. If you really didn't want RMS, you could just open a file on a block level and DIY, which what many DBMS systems did.
Yes, the PL/1 and VAX C compilers used the CODEGEN project which had the idea of using a common compiler backend and to make it responsible for optimisation, etc. I *really* don't understand why because I put some VAX Debug Symbol Table (DST) support into GCC and that worked fine. What I couldn't do was to fix the bugs in the VAX debuggers C language module (it does the expression and address parsing).
Digital really screwed up with their earlier IP support under VMS. It seems to work ok now, but rgrettably much of the port seems to have been done by people who didn't understand VMS well enough or the Unix implementation layer.
I take issue with what you say on the I/O. The problem is that few people worked out that in VMS, an I/O operation is expensive so it is advqntageous to transfer more than a byte at a time. I agree that the checking and logging costs, but how often did you have to do an ANALYZE/DISK/REPAIR on VMS? Even on a disk that was cluster mounted, the files seemed quite safe since VMS V3.1.
RMS is great too, as long as you use it and don't try to layer another file system on top of it.
This and VMS clusters is why some people I know can't get away from it yet. All of this could be implemented under Linux (roll your own file system - no worries). The trouble is that management is worried about large scale systems programming, they want a vendor to do it (and be blamed if things go wrong).
Now you are surely saying "but we won't change the case of the german double s". But again there is no guarantee that nobody else does. There are rules, but the rules are complicated and keep changing. Currently the most common rule for Unicode is to ignore any attempts at case matching except for the ISO-8859-1 characters that have matching case. But there are others who say that only the ASCII characters should case-match. And there are others that say that we should obey the complete rules of Unicode. Then there is UTF-8 and the fact that the same Unicode character can be encoded multiple ways. Are these equivalent?
Even in Ascii you will find systems that consider '@' and backquote to be the same character, and '[' and '{' to be the same character, due to simple bit masking algorithims. You even get sorting bugs if systems disagree about whether tolower() or toupper() is done before comparing.
The truth is that this is a terrible problem and it is complete nonsense that a bit of "user friendliness" needs to be buried in a deep part of the OS where it can complicate implementations and produce security errors.
Also there is absolutely no reason for this. People want a friendly GUI that does this for the user (and also does filename completion and spelling correction and version numbers and many other nice things) and case independence in the system is at best irrelevant, and at worst a hinderance to such things (I know as I have written file choosers for both systems and Unix is immensely easier to deal with because of this).
Several people have mentioned "help" and I do remember using it. I do not remember what the problem was but "man" did work better at least on the systems I was using. The main advantage of "man" was that you could do "man blah" where blah was the name of a system call and you got information about it, and you could do "man cmd" where cmd was a shell command and you would get percise information about the switches that command took. I don't think this was true about "help" as it was set up. However "man" certainly was useless if you did not know the name of a command or call, I think "help" did much better here, but once you knew something "man" was used much more often. I have never figured out why nobody made a system that did both commands and concepts as keywords, the sets don't intersect. Man pages also had "see also" on the bottom that did not really exist in Help, I really relied on this a lot, and later Unixes where "less" cleared the screen on exit really drove me crazy because it made the "see also" stuff useless. I have to admit "help" is a much better name than "man", I think a lot of the Unix stupid names is due to the fact that they chose the obvious name for a first version of the program, and it was broken but they could not delete it without breaking scripts using it, and K&R and so on are too embarrassed to admit they made these mistakes.
Fork at least allowed me to get two programs running at the same time. I did nothing more than calculate in the background and wait for exit. But this was way more than I ever did on VMS where getting any kind of parallel execution required months of study of complex stuff.
That was my point. The problems with simple stuff prevented me from ever finding out if VMS provided technical advantages. RMS and those filenames made it impossible.
They used to be a lot more expensive, at leats around the time of VMS V6.0 when I last had access to them. The listings were incredibly useful and with a little massaging, you could get source code. We couldn't use this in production, but we certainly could make some experiments during development.
I gave my source for the claim that Cutler admitted the VMS++ == WNT myth was fact. The source for your claim that Cutler "flatly denied it" will be of interest if you provide it. Certainly the myth is attractive due to Cutler's background and that the 3.51 architecture so closely resembled VMS -- enough so that a handy reference to Cutler's flat denial would be valuable for those interested in accuracy (even if on a trivial point of history).
Seastead this.