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.

Stupid Contracts

[Zack]

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.

It makes you wonder...

[The Original Yama]

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?

Re:VMS didn't leave

[PinkHeadedBug]

Umm... in a word, "no".

VMS is not similar to DOS on steroids; maybe DCL looks like a DOS interpreter to you, but the underlying operating system is vastly different from that toy program loader called DOS. Calling them similar is just wrong. Besides, very few people have ever seen the aspects of Windows NT that resembled VMS; it most certainly isn't in the command line.

"It's C compiler sucks" You must be joking. DEC is famous for having some of the best compiler gurus; historically, their compilers have always been among the best, both in speed and code generation. Tartan was the only company I recall that could beat DEC on a VAX, and no one's yet matched them for code generation on Alpha. That VMS would somehow ship with inferior compilers doesn't make sense.

"It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. When you're certain you don't need the old versions any longer, you can clean up with a single command. And, finally, if you really don't like it, you can turn it off.

"It's memory manager is famous for being fairly slow..." I don't get this one at all. Are you referring to the system pager? Packet lists and non-dynamic pages? Page files? All of these size parameters are well-known (famous?), but more importantly, all can be tweaked via SYSGEN to your heart's delight. Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.

"You can run quite a bit of Unix software on these things just fine..." It would be better to say that you can get POSIX compatibility under VMS. If you write for POSIX, yeah, you could get your code going under VMS. But many Linux/*BSD hackers these days neither know nor care about POSIX (not without good reason, I might add, POSIX.1 was seriously flawed in some respects), so I really have to question "quite a bit".

I don't like to nitpick, but your post does a real disservice to the VMS folks out there. I haven't seriously used VMS since the 4.x days, and am only marginally aware of the current state of OpenVMS, so I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.

VMS lives in MI

[cascadingstylesheet]

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 ;)

Re:VMS didn't leave

[skuenzli]

"It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. When you're certain you don't need the old versions any longer, you can clean up with a single command. And, finally, if you really don't like it, you can turn it off.

Do you know how the versioning is implemented? I am a 'casual' user of VMS 7.2-1/7.3 at work, and this I think the automatic file versioning is a really cool feature. However, I've always wondered if I make a small change to a large file, does it copy the whole file? I'm guessing there are some configurable limits on file size for what gets versioned and what doesn't. I suppose you could use some sort of diff/patch implementation, but that would get a bit messy if you have (to borrow an example from elsewhere in this thread) foo;1 foo;2 foo;3 and delete foo;2.

Another feature I really like about VMS is the performance reporting tools that are built (??) into it. Every time I run load tests without telling my admin, he starts sending me graphs about what I did to the machines and do I know anything about it, plus if I can ask him for data from 2 months ago, and he's likely to have it.

Stephen

P.S. I say 'casual' because I just can't get into the 'set def mylogical:[sub_dir]' sort of stuff that our applications require.

some things I miss about VMS

[new death barbie]

1. Common calling standard -- a mainline written in, say, Fortran could call subroutines written in C or Cobol or Pascal or Bliss or Basic or Assembler -- or almost any other language; they all used the same method for passing args on the stack. Foresight, or what?
   
2. Clusters -- VMS systems have been clustering for longer than any other OS -- and the functionality any VMS cluster had a decade ago far outstrips the capabilities I've seen in any Microsoft or Unix cluster today.
   
3. Asynchronous Traps (ASTS) -- man, they made network and I/O programming easy -- just start an I/O operation, and specify the routine to be invoked when the operation completes -- then just forget about it, go and do something else.
   
4. DECnet -- VMS was the first DEC O/S to have DECnet built in from the ground up. This meant that copying/reading/writing network files was a trivial exercise -- if you could do it on a local file, it would work over the network without any extra effort. FTP, pfffft!
   
5. TECO -- it didn't start on VMS, but hey, now there was a real programmer's editor. Forget about EDT or SOS or VI or even EMACS. TECO ruled.
   
6. Documentation -- the doc set weighed more than a lot of the workstations -- and needed a whole lot more shelf space. Good, too. Way, WAY better then Microsoft, or any Unix variant I've come across. IBM's docs were almost as good -- but then, IBM programmers need docs more ;-)
   

Re:Stupid Contracts

[rodgerd]

Most of the incredible smart guys had probably been there since the days of DEC and didn't have crap like that in their contracts.

It's an interesting social phenomenon in many companies - first and second class employees. The first class ones are the older staff, with older contracts that don't rape them of anything they've ever thought of, have decent redundancy provisions, and so on. The newer employees get the second class contract which make it clear they should consider themselves lucky they aren't ebing used for organ harvesting.

Re:UNIX advantages.

[spitzak]

Absolutely agree. I worked on VMS at Dec and first encountered Unix when they broght in BSD Vaxen in order to port the compiler for the Clu language. This was in 1982. I (and some other people unfamiliar with Unix) were blown away by the absolutly absurd amount it was easier to program using Unix.

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.

Re:Stupid Contracts

[Anonymous Coward]

Interestingly, when I joined DEC I got an exemption from these fairly standard clauses and worked for them for about 10 years. Then they got precious about IP, tried to change my contract, and I left, but it was kind of obvious they were on the skids by then.

Quite a lot of DEC's better products were originally midnight projects that engineers were only too happy to see making money for the company and I don't recall any IP disputes arising.

It's always when a company is in trouble (be it called Digital or Compaq) that the suits try to fix the wrong things....