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.

Comments

VMS?

[FreeLinux]

And the trolls say BSD i dieing.

Re:VMS?

[evilviper]

At least the trolls can spell "is dying" correctly.

cool!

[Sk3lt]

I say we give them all the support they need! If it was stable back then, then revitalizing it can't do any harm can it?

Re:cool!

[larry bagina]

that's a bad idea. VMS DCL commnds are much more cryptic than standard unix (or linux) commands. A revitalized [Opsn]VMS could siphon away 3l1te linux users!

Re:cool!

[Mister Transistor]

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 can't use it anyway

[ObviousGuy]

You can only use it if you aren't planning on using it in a business setting.

The DeathRow OpenVMS Cluster operates under the hobbyist program. If you intend to use these reasources for commerical reasons (for example: porting commercial code, or running a company web page), you will be removed. This would violate our hobbyist agreement/license, and we can't afford to let that happen.

So, it's useless as a replacement for anything.

Re:You can't use it anyway

[msobkow]

OpenVMS was named in a time when "open" meant that your OS supported open standard APIs. That would mean ANSI and ISO standards for languages, POSIX APIs, etc. While the core services (file management, process scheduling, etc.) were nothing like Unix, they were equally powerful and had some extra concepts that were rather useful at times.

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.

Re:You can't use it anyway

[langed]

A certain midwest university still uses VMS for the primary mailserver and public access dialup internet service. I happen to have been a student there for a few years, and the systems have been reliably serving up mail and such to approximately 13,000 students and professors for nearly a decade.
Now, having grown up on MS-DOS, the DCL prompt was somewhat second nature for some trivial operations.

However, I soon discovered that one of the nicest features of VMS that we had on those systems was also one of the most dangerous for my account. The system appeared to have some form of revision control. Anytime you saved a file, a ";1" was attached if you had no existing file by that name. Otherwise the next-lowest number was appended to ensure a unique filename. This was good in that you never corrupted a file or overwrote it accidentally (and if you save your files often, if one is corrupted you can back up to the next most recent version) but with a pithy 1.5MB disk quota, it meant that you had to frequently clean out old files. And unpriviledged user backups were nontrivial tasks, because ftp was disabled, and you were limited to using Kermit for file transfers on a 9600 baud line.

Nevertheless, VMS had a good number of benefits to it--and to this day it seems to handle the immense load of our users quite well.

But I should make a point here--don't go calling VMS secure. It can be cracked. Any OS can. The simple fact that it's not used much nowadays may very well be the reason we don't hear much in the way of exploits and cracks for these machines. And further, if the VMS cracking docs you're reading are not modern (within the last 2 years, even for VMS) they are certainly not current--and there are people out there who do, can, and will exploit this OS. Sure, it's not so easy as downloading some program and running it, but it's clearly quite possible. It just might take a bit more effort.

VMS Hacked

[CptSkydrop]

Does this mean that all those l33t hax0r txtz I got nocking arround and make out like it runs every computer system on the net can be put to some purpose?

Re:VMS Hacked

[GigsVT]

When they were written, it did. That's the point of the story at hand. Most of your hacker texts were written in the early to mid 80s.

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.

Re:Stupid Contracts

[Zack]

I didn't! Now I've got a job making 50% more than they were offering.

But still.. being a kernel hacker on VMS would have been fun.

Re:Stupid Contracts

[cheese_wallet]

kinda funny that a bunch of "incredibly smart" guys accepted the job, and you didn't.

Re:Stupid Contracts

[Querty]

"Incredibly smart" guys at kernel hacking tend to be incredibly stupid/naive when it comes to things like contracts.

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: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....

Re:Stupid Contracts

[CaptainCarrot]

Look at it this way: if they'd had a clause like that in their contracts years ago, DEC would have gained ownership of Windows NT. They're probably still kicking themselves over that one at whatever hamburger joint the DEC management of the time is now wielding a spatula...

Re:Stupid Contracts

[Zack]

That's true... but it's also possible that if they had a clause like that in their contracts years ago that all the people they have working for them now wouldn't have agreed to it. At least the poor guy flippin' burgers can know that he hired smart people, rather than people too stupid to read a contract and understand the implications of it.

Anyway, I harbor no ill feelings towards Compaq (HP?) for their refusal to discuss the contract terms. In my ever so humble personal opinion, it's their loss. They're losing people because of their horrible contracts.

I will give it a try atleast

[jukal]

..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.

VMS is 1337

[Graspee_Leemoor]

Whoohoo! Now I can write all them cool apps in VMS Basic like fake logon progs to steal passwords, and leave 'em running on WYSE terminals! Muhahahahah!

Oops, sorry, it's not 1988 anymore, is it ?

graspee

Re:VMS is 1337

[anonymous cupboard]

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.

Re:VMS is 1337

[Graspee_Leemoor]

A major feature of my logon faker that I wrote in 1988 was that I logged on as myself, ran the program then went away. If the user hit the break key (whatever that was- it's been so long...) they ended up in my account with a prompt.

Just goes to show how elite I was in 1988!

I did steal some passwords from members of staff who logged on though, and nearly got thrown out of university for it. I was only in my 3rd week as a fresher!

I suppose that's what happens when you meet a multi-user system for the first time when you're used to messing about on ZX-Spectrums- there is a desire to do evil!

graspee

VMS better than *NIX?

[The Original Yama]

Can somebody please explain to me (or tell me to RTFM/STFW and point me to the relevant resource) what makes VMS better than *NIX? I hear a lot of 'old timers' say this, but having discovered *NIX only five years ago I have no real idea what they're talking about.

Re:VMS better than *NIX?

[njm]

There in fact is an open source effort to recreate it: here. I was just about to describe the complete lack of activity for the project, but, upon checking the last update for the website, it was only four days ago, so who knows. =)

I would be interested in finding out whether HP is planning on continuing to support OpenVMS; I know that Compaq had been planning to port it to the Itanium. Can anyone comment?

Re:VMS better than *NIX?

[anonymous cupboard]

Just hunt around for references to VMSclusters and the Distributed Lock Manager. There are attempts at copying both but they really aren't as well implemented. SMP was also very good on VMS. The exec (kernel) of VMS was a nvery neat piece of engineering which was positively anal about parameter checking, so not a lot went wrong that way.

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.

Re:VMS better than *NIX?

[The Original Yama]

I've read it was more secure, but also that its security was harder to implement/modify, so that in real world usage *NIX was actually more secure since it was easier to use and implement. How right is that assertion?

Re:VMS better than *NIX?

[Anonymous Coward]

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.

Re:VMS better than *NIX?

[io333]

Hey, 'cmon, who the f*ck modded me down for that? I was totally serious. When I was end-using, I always found VMS to be less of a PITA 'cause I didn't have to worry about case.

Lame mods.

Re:VMS better than *NIX?

[The Original Yama]

Darwin and MacOS X isn't case sensitive for the same reason. In most instances, case sensitivity can be more annoying than beneficial, particularly for people who aren't used to *NIX (i.e. most people).

Re:VMS better than *NIX?

[spitzak]

Case-insensitivity is a user-interface issue that has unfortunately infected many systems other than Unix. It is a HUGE security bug and makes programming much, much harder. This is because a program can no longer assumme that non-matching series of bytes name different files. (these bugs also infect any system that tries to interpret sequences of bytes, for instance systems that take UTF-8 but consider different encodings of the same Unicode to be equal have this problem and should be fixed).

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.

Re:VMS better than *NIX?

[anonymous cupboard]

I would disagree with you about RMS, but then I would, having used it to coordinate shared access to indexed files across processes and a cluster. The only solution under any Un*x system is to use a DBMS. Oh and recovery unit journalling, you could even have that too! The end result is a lot faster than any DBMS.

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.

Re:VMS better than *NIX?

[spitzak]

Okay, please list all the filenames that match a name containing the ISO-8859-1 character for the lower-case german double-s. The upper-case version is two letters, "SS". Now, does "ss" match? How about "Ss" or "sS". And does this mean that any file with "ss" in it matches a file with a german double-s? And can you figure out an algorithim that reliably does this with 100% accuracy. And once you have done this, how do you prove that the file system's algorithim is doing exactly the same thing?

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

Re:VMS better than *NIX?

[koadic]

Source listings are still available, but they're no longer given away. These days, I think a listings CD will cost you on the order of $2000. (I can't find a price online.) $2K is expensive, but it's all relative; other commercial OS's (such as the ones from Redmond) won't give you access to their source listings at all.

Re:VMS better than *NIX?

[koadic]

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.

As of OpenVMS V7.2 (the ODS-5 filesystem), you can use pretty much the same character set for filenames on VMS as you can on UNIX or Windows. The filesystem is still case-INsensitive, though. (A good thing, IMHO.)

Re:VMS better than *NIX?

[anonymous cupboard]

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.

but VMS lives

[g4dget]

The same guy who was responsible for VMS is responsible for Windows NT. You can think of NT as an attempt of a next generation VMS, with a DOS-like command line and a Windows GUI.

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.

Re:but VMS lives

[Ggggeo]

The same guy who was responsible for VMS is responsible for Windows NT. You can think of NT as an attempt of a next generation VMS, with a DOS-like command line and a Windows GUI.

A computer prof I had pointed out the above fact as well as the letters VMS shifted up one is:
VMS -> WNT (WinNT)
Interesting...Intended...or accidental?

Re:but VMS lives

[farrellj]

Sure, the same person may have designed NT, but it was implemented by Microsoft. And that was it's downfall. MS is a production line, like a car production line...with cars, they issue recalls, with MS Operating systems, they issue Service Packs.

ttyl
Farrell

Re:but VMS lives

[anonymous cupboard]

Actually it was remarkable easy to set up security on VMS. The real issue was monitoring the security alarms.

Most of the hacks were through social engineering. The others were due to imperfect parameter checking. As the system matured, it got even more tight on the hecks and most of the holes disappeared.

Re:but VMS lives

[Jack Auf]

The same guy who was responsible for VMS is responsible for Windows NT

Yes, his name is Dave Cutler. IIRC he quit working for M$ in discust about the time NT 3.5.1 was released (please correct me here).

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.

No. The Win cmd shell is nothing like VMS. Not even close. It's really a glorified DOS shell, and has nothing whatever to do VMS. Ever used a logical under a Win cmd shell? I thought not.

I was a sysadmin on VMS systems for about 1 1/2 years, and right after that I wrote desktop apps that used RDB on VMS as a data source for about 3 years. I have at least a passing familiarity with it. It is without a doubt the most stable OS I've ever used including SunOS, Solaris, Linux, and WinNT*.

It's really too bad that DEC/Compaq continually bled their VMS/Alpha customers dry. Software, hardware, support were all obscenely expensive, and this more than anything else is what killed VMS and DEC in the long run.

Re:but VMS lives

[RatFink100]

The only real similarity between VMS and NT are the kernels. That's what Dave Cutler worked on.

DOS command line is more like unix that VMS

Re:but VMS lives

[Graspee_Leemoor]

" 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."

Beyond 'dir' and 'type' it's very different.

Ha! There's a thought... Maybe all those people who keep on insisting that Linux is not unix should have a go at VMS so they could see exactly how different an OS that's NOT UNIX really is.

Hell, I'd been using it for 5 minutes and managed to 'type' some garbage to the screen, and spent the next 10 minutes trying to figure out how to reset the terminal...

It's good to see that 'basic' still works, though java looks strangely out of place...

graspee

Re:but VMS lives

[DonalGraeme]

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.

Oh, give me a *break*. VMS had a proper scripting language. NT doesn't. VMS came with a proper queue management subsystem, for both batch and print jobs. NT doesn't. VMS had access to system commands from the command line (if you had the appropriate privileges). NT doesn't.

Re:but VMS lives

[joshki]

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. uhmm... no. It's not. I worked with VMS for a couple of years learning to program FORTRAN back in the late eighties -- the commands are not even close. The only similarities between VMS and NT are due to the fact that Dave Cutler(I think) worked on both -- the interface for NT is mostly copied from DOS.

Re: but VMS lives

[Black Parrot]

> The same guy who was responsible for VMS is responsible for Windows NT. You can think of NT as an attempt of a next generation VMS

Except that Windows clustering still hasn't caught up to where VMS was 15 years ago.

Re:but VMS lives

[quark2universe]

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!

Re:but VMS lives

[Dynamoo]

Windows NT and VMS do actually share a common heritage (see here.)

I ran VMS systems for years and it's a lot less friendly the *nix, but it's a hugely stable and coherent OS. In four years of running VAXes I had *two* occassions where the thing crashed unexpectedly, and both times Digital took away the dump tapes for analysis because they treated system crashes seriously.

In the business I work in, we use OpenVMS on Alphas to run our warehouse system. It's a solid, reliable and very dull OS which is exactly what we want.

And for security, OpenVMS is a DoD certified C2 product, with a variant (called SEVMS) which is certified B1. I have a list here which includes current-ish product links.

Look, the VMS vs Unix argument has been raging since 1978 when the VAX-11/780 came out. The fact that both these OSes are decades old means that they're both strong OSes and have a lot of life in them yet.

Re:but VMS lives

[g4dget]

The NT command interpreter is a full scripting language. There are command line equivalents for NT system management. Of course, NT comes with print queues. Command queues are a third party add-on.

Re:but VMS lives

[PD]

Word games

Linux shifted up:
MJOVY

and down:
KHMTV

GNU up:
HOV

GNU down:
FMT

DEBIAN up:
EFCJBO

DEBIAN down:
CDAHZM

Nothing good.

Re:but VMS lives

[g4dget]

Beyond 'dir' and 'type' it's very different.

It's the feel, not the commands, that are similar: non-uniform pathname notation, distinguished command/scripting language, pathname expansion by commands, an plethora of security bits, lots of special cases all over the place.

should have a go at VMS so they could see exactly how different an OS that's NOT UNIX really is.

Indeed. While details differ, VMS has many of the same complexities of other mainframe and minicomputer operating systems of yore. UNIX was explicitly created as a reaction to that style of design. I just don't get why people think systems like VMS were ever a good design.

Re:but VMS lives

[DonalGraeme]

I'm sorry, but the NT command intepreter is a sorry excuse for a scripting language. Loops need to be implemented using "goto" (ugh!), error handling is sparse, and string manipulation sucks. That's a few things off the top of my head. Don't get me wrong, I'm not saying you can't write scripts for NT. I am saying though that it's like trying to paint a car with a kids paintbrush.

Regarding command queues being third party addons, they shouldn't be! The ability to submit batch jobs through something more stable and useable than "at" is something that any OS that wants to be used for something more than playing games or writing documents should have. The fact that you have to pay extra for something that should have been there in the first place is both annoying, and also means that when I as a developer write something for NT/Win2K/XP, there is no standard I can expect to be there.

Re:but VMS lives

[Anonymous Coward]

The NT command interpreter is a fucking piece of shit, dude. Sure it works, but Christ does it ever suck dick.

Re:but VMS lives

[grumpygrodyguy]

Sure, the same person may have designed NT, but it was implemented by Microsoft. And that was it's downfall

Downfall? What world are you living in?

Re:but VMS lives

[Graspee_Leemoor]

"I just don't get why people think systems like VMS were ever a good design."

I think once you get used to any OS, unless it really really sucks, you get used to working productively in it and can't see why it should be any other way.

That's if you meant the reaction of users of VMS. If you meant the designers of VMS then, hmm, I don't know. Language and OS designers tend to get a bit carried away with personal preferences and are a bit blind to how users who haven't programmed the system will view it.

A good example is to look at Tanenbaum's Minix and the explanation of design considerations in the book he wrote. Even though it was always designed as a teaching OS some of the design decisions are a bit weird. (Well, that's just my opinion).

At least if nothing else, VMS is fun to use if you never have, because it's different and novel. Also, I do think it's important to preserve computing history. (Even thought that's not their intention).

The main thing that still freaks me out though is how lost I am without familiar unix commands and file paths. Irix to *BSD, there's really little difference, despite everyone's moans to the contrary.

graspee

Re:but VMS lives

[g4dget]

That's roughly how I felt about DCL compared to UNIX shells back when I was occasionally using VMS.

Sorry, but from a UNIX perspective, I just don't see that much difference between NT and VMS: to me, they both embody roughly the same approach to OS design, an approach that I don't like. The fact that between the two, VMS is a much better and more mature OS doesn't change that opinion.

But obviously someone must like something about it, since a lot of people are paying a lot of money for both VMS and NT.

Re:but VMS lives

[Ivop]

I'm sorry, but that syntax is almost as bad as Perl. --Ivo

Re:but VMS lives

[Mr. Piddle]

You can think of NT as an attempt of a next generation VMS...

Even though I have never used VMS, I find it very hard to believe that it could have sucked so bad that Win NT is really the "next generation." Win NT is so bad that the VMS people must be embarrased about it.

Re:but VMS lives

[spitzak]

On the shells: The NT shell (command.exe) has nothing to do with the VMS one. It was designed to be compatable with the DOS command line. The DOS command line was designed mostly to match CP/M. As far as I can tell, CP/M was mostly influenced by RSX-11M from Dec. DOS version 2.0 also introduced a lot of Unix C-shell like things into the command line. The Unix C-shell was also influenced by RSX-11M and perhaps other companies command lines from the 70's. But there is no way that the NT shell would have been influenced by the VMS one at all.

Re:but VMS lives

[ggeens]

Yes, his name is Dave Cutler. IIRC he quit working for M$ in discust about the time NT 3.5.1 was released (please correct me here).

IIRC, MS hired him back to work on W2k.

The Win cmd shell is nothing like VMS.

True. The kernel underneath is similar - some of the internal structures have the same names (that's Cutler's heritage), but the user interface is different. Even the kernel has a different design: WinNT is a microkernel, while OpenVMS is monolithic.

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:It makes you wonder...

[Vengie]

FYI,
i find your sig derogatory to homosexuals everywhere
they get far more sex than bill gates.

Re:It makes you wonder...

[The Original Yama]

Dude... calm down, it's only a joke :)

Some of my best friends are homosexual. I'm not homophobic by any means.

I thought VMS became WNT

[mab]

Wasn't one or more of the head Engineers of VMS responsible for the mess that is Windows NT/2000?

Maybe there could be a UNI course OS101 how to turn a secure OS into a virus infested shatered mess. Bill can hand out the degrees

Re:I thought VMS became WNT

[anonymous cupboard]

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.

VMS++ = WNT

[Baldrson]

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.

Re:VMS++ = WNT

[Winnipenguin]

Great article at osopinion written by Adam Barr, found here:

http://www.osopinion.com/perl/printer/17154/

Quote:
"Gordon Bell, who led the development of the VAX architecture at Digital, came to talk to the NT group in April 1994. At the time, I was on the team, working on the second version of NT. Bell warned the troops to forget about OS/2 and Netware. If we beat Unix, Bell told us, we would easily defeat the others in the process."

Fav quote:
'It wasn't always like this. Microsoft used to sell a version of UNIX called XENIX. Consider the following quote from Paul Allen, Microsoft co-founder, in the 3rd issue of PC Magazine, June/July 1982:

"It's important to realize that MS-DOS is part of a family of operating systems.... Providing the user with a family of operating system capabilities means a clear migration path from MS-DOS to XENIX. That means compatibility for both the terminal end user and the systems programmer.... A standard library for XENIX-86 C will allow compilation of a program on XENIX ... and then execution on MS-DOS.... XENIX systems will be able to function as network file servers." '

I wrote C programs on Xenix (Tandy box) during the early 80's and it was very fine.

Re:VMS++ = WNT

[karl.auerbach]

Don't forget Dave Kashtan (sp) and the SRI and TGV [Two Guys and a VAX] folks - they added enough Unix-layers to make it possible to avoid DCL and created a decent networking stack as well.

(TGV was also a contributing source to one of the original two Internet Toasters - yes they really existed - in 1988. The other Toaster was built by John Romkey [FTP Software] [Both Toasters used my SNMP software in their controllers.])

Docs, if jumping into the free shell

[inkfox]

If you dive into the free shell accounts they're offering, you might want to spend a little time here. It's the master documentation site for all your OpenVMS needs.

This seems to be the best guide for a user who's never even looked at VMS before.

why bother?

[SHEENmaster]

I was able to break from the login shell by hitting ^something, prob. ^C, a bunch of times.

It gave me a prompt, which I assume was like a root or single-user-mode prompt. Too bad I didn't know many VMS directives.

The thing's error message is longer than the DOS one in winshit2k.

I still think the project should go on, but my time will be spend on more pressing matters. UNIX one the OS war by being superior. It didn't do it by blackmailing other companies to include it(M$). It didn't stay alive by forcing it on users of its hardware(Apple, Sun). Linux survived because anyone could get a hold of it. BSD kept up with the best of them, and would still be going strong if Linux didn't have a cooler name.

Re:why bother?

[Mister Transistor]

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

Re:why bother?

[Zero__Kelvin]

"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 ... I'm trying to remember back over a decade here) at boot time, and as long as the system administrator hasn't set up an alternate User Authorization File (UAF), you can get the equivalent of UNIX root as long as you have proximity.

VMS is dead

[Archfeld]

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.

Re:VMS is dead

[Archfeld]

ok i got ammend that too, I went for a walk thru the Mini computer area and found numerous VMS boxes still in use as well. 8 bit SCSI arrays and all but lots of storage works stuff about as well.

VMS Still in Use at RIT

[PeekabooCaribou]

The Rochester Institute of Technology still uses VMS for a few of it's systems. 100% of class registration runs through the VMS, and students have the option of using VMS for their e-mail. Personally, I think it's one of the most confusing operating systems I've ever had the displeasure of sitting at, but I guess I thought the same thing about Linux at first..

Re:VMS Still in Use at RIT

[ZorinLynx]

At FIU, VMS was in use until around 1997. Back in 1995 they still had text terminals in some of the computer labs. They were connected to DECServers and could only directly connect to the VMS machines. They had a HUGE (physically) VAX 8800 (SERVAX) and also a DEC Alpha box of some sort (SERVMS). I never really gave VMS the time of day, though, other than to log into other systems. My typical VMS session looked like this:

Local> C SERVAX

Username: JFLYNN02
Password: *******

SERVAX $ TELNET SOLIX.FIU.EDU

SunOS UNIX 4.1.4

Login: ...so essentially the VMS system was just used to hop over to the UNIX ones...

I sometimes wish I had given VMS the time of day back then. I guess this free server is a chance to really play with it some...

It sure brings back memories, though... VMS looks simply bizarre to a UNIX user.

Re:VMS Still in Use at RIT

[xtremex]

I first used VMS in my high school back in 1985. The school ran on it and the Fortran classes were taught on it (...teletype...).
I used to go to the local university (University of Stonybrook) and learn VMS there from the terminals and the books on the shelves in the computer room...That was my first experience with a REAL OS....I hated it back then..I hate it now,,,UNIX was a breath of fresh air ;)

VMS was my first OS too

[Baki]

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.

Re:VMS was my first OS too

[fallacy]

I find that odd, saying how UNIX was a joy and VMS brings nightmares. Perhaps it's because I went the other way round (of sorts) in terms of experience: Amiga -> UNIX -> VMS.

Whilst I use and prefer UNIX/Linux, I appreciate that VMS isn't a bad OS at all.
But perhaps it's simply because the first time I did a 'sh log' on an Alpha at work (which we have only recently switched off after 10+ years of use) a smile can across my face as it took me back to the good ol' 'assign' of my beloved Miggy ;-)

Re:VMS was my first OS too

[bungo]

Everyone who likes UNIX and who knows both UNIX and VMS well cannot but hate VMS.

Ok, let me first tell you about my personal collection of computers. I have

HP-9000 J-210 - 2 processor HP/UX
RS/6000 J-40 - 8 processor AIX (run *very* hot)
3 x Sun SS-20 - 2 processor Solaris
1 x SunBlade 100 - single procssor Solaris
2 x Sun LX - singal processor Solaris
2 x Tadpole 3GX - laptops, Solaris
Alpha 2100 - single processor Tru64
intel - single processor SuSE 7.1

I've run Linux since the .99 days, before then I ran Coherent (unix clone, now dead), SCO Unix, SCO Xenix.

I use unix everyday in my job. I love unix, if it weren't for unix, I probably wouldn't be working in the computer industry.

My other remaining box is a VAX 7000/90 running OpenVMS.

I love VMS. It can do everything that unix can do, but it just does it differently. You wouldn't program in lisp the same way you would program in C. You have to think in VMS when using VMS and don't try to apply unix ways of working to it.

My guess is that you just didn't learn enough about how VMS works to really understand it. Not surprising since you only used it for a year. Maybe if you'd learnt it more and had to do system admin tasks in it, you'd appreciate it better.

VMS was ahead of unix in so many way - access control list security, VMS had it way before, clustering, VMS had it way before (and it still is bettter than most versions of unix). VMS was set up from the start to monitor and control users and their cpu usage, for unix, you get vendor-created add-ons which do the job and are no way near integrated.

From a captive end-user perspective, maybe VMS was not so much fun, but from an admin perspective, if was fantastic.

Re:VMS was my first OS too

[RatFink100]

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.

I'm not quite sure what you mean by that but HP now have two Unix groups (HP-UX and Tru64) and a VMS one.

I work for a large software company that sells software on many platforms and I can tell you that there's still a heck of a lot of VMS out there. Until I hear differently I'm assuming HP will be honouring Compaq's commitment to port VMS to Itanium so that VMS users have an upgrade path.

Re:VMS was my first OS too

[Gerald]

I love VMS. It can do everything that unix can do, but it just does it differently.

If, by "differently" you mean "not in the slightest eensy bit" then yeah, VMS does simple things like command line piping "differently."

Re:VMS was my first OS too

[astaines]

Well almost, my *first OS* was TOPS-10 using Pl/1.
My first OS at work was VMS on Vaxen. We used it to run large health related databases. I was a user, and I still miss TPU. There is a Windows port, but it wasn't very good.
On the other hand R-DBMS, while effective was a pain to deal with. But I did love the Dec-C compiler. I still have a lot of stuff that I wrote for this compiler, and it just runs everywhere else.
Oh I miss ny Vaxes..

Anthony Staines

Re:VMS was my first OS too

[Baki]

Yes, clustering was ahead of its time.

The other 'features' like ACL and other control-freak tings, they were only an annoyance (in fact ACL still is one of the things I generally despise; they encourage an admin to make a quick permission exception, leading to a mess without concept in a short time).

I remember end of the 80s, every physics department was dumping VMS and moving to UNIX (sometimes on new hardware, sometimes on VAX hardware). We all were so relieved to get a nice and elegant environment instead.

For VMS with its lead-heavy process model for example, the "UNIX building box" philosophy is alien. You don't have a shell starting small subprocesses all the time, possibly combining them using pipes. The 'everything is a file' concept doesn't exist, so you have different system calls for handling each kind of device (i.e. multitudes of system calls compared to the small and orthagonal well though out set of UNIX system calls). In short, it is just like WNT :)

Re:VMS was my first OS too

[Disemboweler]

Command line piping works just fine under VMS. See the PIPE command:

http://vmsbox.cjb.net/help?key=PIPE

Admittedly this was added on in response to Unix, but has been available in VMS for quite a while.

I always hated VMS

[SoftwareJanitor]

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.

Re:I always hated VMS

[mikefoley]

Thanks for your comments Linus..

Former system admin in the VMS Group

Re:I always hated VMS

[lophophore]

You should have tried LSE. It was a fabulous "Language Sensitive Editor", built on TPU. At least the editor was called EDIT, and not some strange name like "vi".

Had you read the documentation, you would have found that you could have used the
SET DIRECTORY/VERSION_LIMIT=1 command to turn off the versioning. However, if you have ever wanted to revert back two levels when editing, you would understand why the old versions were kept.

Re:I always hated VMS

[Cato]

I had forgotten about EDT - actually it was a huge step up just having a screen editor on RSX-11M, before that we had some horrible line editor. Shortly after that I got into Unix System III and learnt vi, and have never stopped using it...

VMS didn't leave

[Sivar]

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.
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 /., ironically) }:>

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; .exe, .obj, etc.) but unlike DOS is very good at having a ton of simultaneous users.
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.

Re:VMS didn't leave

[anonymous cupboard]

VMS didn't go anywhere

This is why the largest electronic derivatives exchange in the world runs on VMS. Many other exchanges also use VMS. They do so for a reason, it takes on a bundle of work and doesn't die. If you have redundant hardware, it will stay up for ever, just failing over between hardware when it craps out.

Incidentally, Cutler started by writing RSX-11M then 11M+, a 16-bit operating system. He then went onto writing VMS and later the Digital PL/1 compiler before he left.

Digital got very little from MS apart from the promise to use their hardware platform for NT. The Windows API definitely has no relation to any of the APIs on VMS although some bits may be similar because of the former Digital engineers.

As the for command language, the original DOS/CPM commands derived from another 16-bit Digital operating system, RSTS/E. Both RSTS/E and M+ eventually started supporting Digital Command Language (DCL) which became fully developed under VMS (much like a Unix shell). The file types go back to the RSTS/E and RSX days.

The version numbers that you complain about are a feature of the VMS file system. They allow you to keep a few old versions of files around easily so you always have the possibility to revert to a previous version.

They memory manager is not particularly slow unless there is a high demand for memory and not enough physical memory available, and even Linux has problems there. The real issue of VMS as a platform is the overhead associated with process creation, now partly circumvented with threads.

Re:VMS didn't leave

[dhogaza]

RSTS/E was DEC's 16-bit BASIC operating system. You're probably thinking about RT-11. You could run an RT-11 emulator as an alternative to the BASIC interpreter under RSTS/E, thanks to a group of us in Oregon who made this available in the early 1970s. Perhaps you had the opportunity to do so. But RSTS/E out of the box announced itself as being "Ready", just like any other BASIC interpreter environment at the time (like the one I wrote for the PDP-8). RSTS/E had a relatively modern design, though, with the kernel and shell (if you will) fully separated. This design is what made it possible to dispense with the BASIC interpreter ("shell" in Unix terminology) and replace it with an RT-11 one. It also supported shared read-only executable segments in 8KB chunks (matching the memory mapping hardware of the PDP-11) so one copy of the RT-11 or RSTS/E BASIC "shell" was shared by all users. Not bad for 1970 technology on a 16-bit mini-computer.

All of these owe the basic structure of the CLI and file naming conventions (forward slash for parameters, 3-letter file extensions, etc) to the older PDP-10 operating system which dates back to the 1960s. The same basic CLI and file naming conventions were also supported by OS/8, DEC's PDP-8 operating system written mostly by Richie Lary.

OS/8's sources named it the "*bleep*" operating system, otherwise known as the First Upward Compatible Keyboard Monitor, or FUCK'M, operating system for the PDP-8. When Richie first proposed writing a PDP-8 operating system that was command-level compatible with the 36-bit PDP-10 timesharing operating system (thus the "upward compatible keyboard monitor" moniker), he was told "no" so wrote the first version of OS/8 on the sly. The acronym described his personal feelings towards management at the time, and later it became the standard single-user PDP-8 operating system.

Personally I think all of Dave Cutler's OS's more or less sucked, starting with RSX-11M and still true today with NT.

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.

Re:VMS didn't leave

[octalgirl]

No it didn't. It is still heavily entrenched in DoD and other fed offices. They have moved to Windows OS's mostly for client/business end of things, like office, email and shared files. In one area that I know, they are still used for travel orders and some old-timers still prefer it's DOSsy mail. They also use a very healthy dose of Unix for engineering (and now Linux for servers are popping up, at least at the experimental level), and the management and graphics depts. still prefer macs. Heck, there are even punch card systems tucked here and there, performing really big tasks, like payroll!

Re:VMS didn't leave

[mpe]

The real issue of VMS as a platform is the overhead associated with process creation, now partly circumvented with threads.

Which is an issue NT inherited... Hence all the fuss made comparing NT and Linux thread handling.

Re:VMS didn't leave

[Sivar]

"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."
That is what I was referring to is the CLI. Regarding the underlying architecture being dissimilar to DOS: My post illustrated that itself. I know. Just the fact that VMS is, as I said, a multiuser OS makes it vastly different underneath.
Just as many people see little difference between Windows ME and Windows NT and talk about interface similarities, so too was I talking about interface similarities. The difference being I know the differences are more than skin deep.

"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."I wasn't referring to the speed of code generated as much as the irritation of using it. Granted, I did not check what version of the C compiler I was using, but it was lacking in some features. It's fflush(); worked erratically (though that has more to do with the libs than the compile I bet) and it didn't even support "//" comments. Granted, "//" was a C++ (not C) standard until C99, but nearly every other compiler I have used supports it perfectly. Looking back these may seem to be very minor but did not leave a good impression about the software. Perhaps saying that the compiler sucks was a bit of an overstatement. :)

"It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. Yes some people really like this feature--I am sure it has saved many people from a horrible death, but many people including myself actually find it irritating. This would probably not be the case were I more used to it, but I have become accustomed to my own ways of versioning and do not particularly like the extra step. Additionally, the file names generated for versioning are often difficult to associate unless one keeps close mental track of their saves. My foo() function isn't working now, but it was working three days ago. Was that in bar.c;27 or bar.c;39?
Yes, you can still version yourself, for example simply making copies of files at important points in time and naming them appropriately, but having a default system tends to discourage people from using that, just as a PC coming with Windows 98 discourages use of something better like Win2K or an alternative OS. Human laziness? Probably.

Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.I can't read. Sorry. :)

I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.So am I, and no problem here. You clearly know more about VMS than I, and I appreciate your input.

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.

Re:VMS didn't leave

[skuenzli]

I found this regarding SnapFS, which is a layer that can sit between the Linux VFS and a journaled filesystem to perform (not just) versioning. Copied from LWN.net:

Whenever a file is to be modified, and its contents must be preserved in a snapshot, SnapFS creates a new inode in the filesystem to hold the snapshot version. An extended attribute which points to the snapshot inode is then attached to the visible version of the file. The actual blocks of the file are shared between the current file and the snapshot until they are changed; at that point the SnapFS "copy on write" mechanism makes copies of the affected blocks . Snapshots are thus relatively efficient in their use of storage, especially in situations where only parts of files are changed. For example, a snapshot of that huge web server log file, which is only appended to, does not duplicate the log entries that are shared between the current and archived versions.

Unfortunately, I think this project may be stalled as noted in the developer's project notes.

I still don't konw what OpenVMS does as I couldn't determine that after over an hour with Google. However, looking at the semantics of the DELETE and PURGE commands it looks like you can get remove arbitrary versions of files. So, I guess each version is a complete copy (or can become one when you delete earlier versions).

Ok. Ziti and Sopranos time. Let's hear it for season 3!

Regards,
Stephen

Re:VMS didn't leave

[lophophore]

Cutler wasn't bored. He was pissed. His pet project, "Prism", (which was a RISC archtecture being developed at DECwest) got killed off, just like many projects got killed at DEC. He gave his whole crew a month off, then bailed to MS.

Re:VMS didn't leave

[hughk]

M shipped with complete source code and Cutlers name was on most of the exec modules.

Re:VMS didn't leave

[jbolden]

You can remove intermediate version in RCS too, and thats using diff for storage. So I don't think it means much.

Re:VMS didn't leave

[anonymous cupboard]

I'm curious as to why you didn't like Cutler's systems. RSTS/E was one gigantic hack and proved as difficult as RSX-11D to support (as reflected in the prices). The M exec was lightweight and was used as the basis of one of the most successful healthcare systems of all time (MUMPS). It was a building block rather than a solution in its own right which was it was much loved by solution providers. I have seen steel mills, ATC systems, chemical plant control systems all based around the 11 and RSX-11M/S.

M support for paged memory (necessary for the PDP-11/60 and 70) was officially opposed by management because of the RSX-11D system (similarly named but no relation) had the place at the top of the range. Cutler implemented the changes in a weekend "for in-house debugging purposes because Digital had a lot of 11/60s around at one stage". The hack became known outside (the customers had the Exec source code and the SYSGEN tool so it was obviously there) and Digital was pressed to support it. Towards the end RSX had shared libraries, I and D space support and many other neat ideas (including a modularised exec). Many of these concepts didn't travel again to VMS until comparatively recent times.

Whilst Cutler was a good exec 'hacker', I guess he had problems in larger teams and this is perhaps why NT sucks so much. Many of the issues with NT seem to come down from weak leadership, leading to the API of the month competition. Note that the original NT design had the GUI running in user-space. It was too slow, so MS moved it to kernel space, bugs and all, which then haunted NT up until Win2000.

Re:VMS didn't leave

[koadic]

Each version of a file is completely independent of other versions. Thankfully, disk space is cheap these days.

Re:VMS didn't leave

[koadic]

Re: compilers - The OpenVMS C compilers are extremely flexible. Perhaps the system you were using was set up to use STANDARD=ANSI89 or more likely, STANDARD=VAXC, both of which prohibit C++-style comments. The default is STANDARD=RELAXED_ANSI89, which does allow them. Re: versioning - if you really want to, you can disable versioning on a per-file or per-directory basis, and not use them at all. You still see a trailing version number, but can ignore it.

One the best proprietary systems going

[aero6dof]

To me VMS was one of the technical best of the proprietary systems. They cost an arm and a leg but you got value for what you paid for. Their OS, compilers, and other software had top notch documentation and were more stable than just about anything out there.

Re:One the best proprietary systems going

[anonymous cupboard]

Largely, yes. Some of their stuff, frankly, sucked. For example, the early implementations of PL/1 and VAX/C. In the latter case, we just used GCC for VAX/VMS and it worked fine. The docs were excellent and unlike MS, there were very few really internal APIs and they weren't being revised every six months.

And it is still stable which is why it is being used for electronic trading.

they aren't distributing it

[RatFink100]

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.

Re:they aren't distributing it

[ObviousGuy]

Maybe you saw 'OpenVMS' and thought it was Open Source?

Can't speak for the AC, but I did. Thanks for pointing that out.

Re:they aren't distributing it

[RatFink100]

Maybe someone else can tell us exactly but I'm pretty sure that Digital started using OpenVMS instead of VMS. I'm thinking it was back in the days when Unix collectively was often called 'open systems' - describing open operability (i.e. standards) rather than open source.

Re:they aren't distributing it

[Meowing]

Yep, that's exactly it. The name came about around the time when POSIX, CORBA and DCE support were added.

Re:they aren't distributing it

[Alien Being]

Perhaps I'm mistaken, but I think the "Open" part was also referring to the fact that VMS, which had previously been tied tightly to the VAX architecture had received a HW abstraction layer to allow it to run on Alpha.

Re:they aren't distributing it

[ggeens]

Correct, at one point in time, Digital's marketing division decided to rename it to OpenVMS. The change was made retroactively for all versions.

Digital vision on the word "Open" was "support all industry standards". Technically, a lot of things were changed as well. (TCP/IP, POSIX support, DECNET V that ran on top of TCP/IP instead of it's own transport...)

This name change happened at the same time as the introduction of the Alpha AXP, causing many people to believe this caused the change. The new name applies to all VMS versions, even the ones that only run on VAX. (IIRC, Alpha support was added in version 6.)

VAX/VMS recollections

[Foozy]

* Excellent documentation. Used to fill several shelves. Writtent by engineers, and very well cross referenced.

* Very good C compiler *for the time*. Used it extensively in early 80s at EDS & GM

* Excellent system level IPC. The Message Box interfaces were extremely easy to use. Easily built large distributed systems with these.

* Excellent, multi-layer security model. Much better than the Unix model(s) even today.

* Good network *at the time*. DecNet beat the pants off IBM SNA for engineering and distributed systems work. Faded gradually with the rise of IP. Don't know if anyone still builds DecNet networks except in the CCIE labs.

Add a letter to VMS...

[bhsx]

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.

Re:Add a letter to VMS...

[Krilomir]

I've always been told NT meant New Technology

Re:Add a letter to VMS...

[Mad Marlin]

Not Trustworthy :)

Re:Add a letter to VMS...

[cqnn]

Hmph, IIRC it was called OS/2-NT before
MS changed back to a Windows centric focus.

From what I heard, David Cutler left DEC
to work on some ideas he had to go beyond VMS.

Re:Add a letter to VMS...

[wik]

Nice Try.

I wouldn't use them.

[praxim]

Each host has the name of a serial killer and the page mentions "loose hits." With that in mind, I wouldn't touch those systems with a ten foot pole.

Re:I wouldn't use them.

[Beave]

Sorry... Disney characters got old, so yes.. We use serial killers... Also, it says "Loose nit".... Yesh..

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

Thevax.org

[paranoidia]

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.

If you like VMS, run NT 3.51 SP 5

[Animats]

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.

Re:If you like VMS, run NT 3.51 SP 5

[codingOgre]

FYI: the machine wasn't connected to a network and had no floppy drive.

Must not have been that good.

[$lashdot]

> 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.

I'm surprised that any DEC people left. I mean, what with so much on the team getting sex at work. Gives new meaning to getting "screwed by corporate."

on spelling...

[RevDobbs]

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...

Still use VMS.

[Rotten168]

My school runs most of it's webpages on VMS... other than the home page... which runs Windows2000. Blaugh.

Test Drive

[Compaq Test Drive]

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.

"Open"VMS

[bryam]

If they want OpenVMS live...then Open Sourced OpenVMS!

Technically superior? Maybe, not that it matters

[XiaouTuzi]

VMS does seem to be a well thought out OS that was once popular due to the donations of vaxen to colleges. When that stopped it hurt the future of the OS. Nowadays considering VMS as a well engineered application serving tool or UNI* as a massively popular programming tool that has evolved tons of capability is irrelevant.
Technical superiority is dependant on what you need to get done and the largest measure of what is accomplished isn't necessarily the OS but rather the OS user.
My company has dozens of both OpenVMS and Unix systems. If VMS is technically superior it is completely irrelevant because of its diminished popularity the number of choices for applications to run on it is so limited that the ones we have are TERRIBLE and no alternatives exist in the market. I work with _extremely_ smart and talented career VMS system managers but barely a week goes by without some sort of outage occurring thanks to poorly written vendor applications. By far the bulk of skill in my company is on VMS support over Unix support. Everyone says VMS is technically superior becuase of the organizational approach it was created under. I'm saying it doesn't make a damn bit of difference now because its not popular and therefore has crap applications.
People seem to typically bond with and prefer one OS over others and that probably has a hell of alot more to do with what they have in common personality wise with the creators of that OS than anything else. If a command "made sense" to the creator you'll expect to find it and will get great use from it, etc.
I wonder if I'll be the old-timer in a future post like this tenaciously clinging to my legacy red hat systems while they gripe and moan so confident that we should be moving servers to OpenBeOS. The thing is they may have a point. If you're toying with the idea of moving work off your present platform you may as well attempt to find one using modern industry standars and avoiding pointless legacy code.
Has anyone addressed the fact that the alpha processor line is being discontinued in like five years or so? Without a port to the IA-64 that issue alone seems to make this idea suspect.

Is VMS really that secure?

[qx49]

CowboyNeal writes of VMS:
"...and it's considered one of the most secure OS's around."

I've often heard this claim. But is it really? After all isn't this is the secure OS that Kevin Mitnick was adept at cracking. Didn't he have full access to the VMS Systems on Digital's network for over a year before they discovered his intrusion?

What makes VMS so secure?

--Wulf

Re:Is VMS really that secure?

[DJBenedict]

It appears that your information is in error.

Kevin Mitnick testified before Congress that VMS was the one o.s. he could *NOT* crack without social engineering.

Last year's DEFCON proved that VMS stands alone as the most difficult o.s. to crack.

VAX Memories

[PingXao]

Back in the mid-80s I was a consultant at a company that had several dozen tech-writers working for a guy who himself was a consultant. We were all doing tech documentation for a mil-spec project. The head guy had a cool sense of humor. As the project entered its final 6 months he would regularly update a file on one of the system disks called LAYOFF.LST

It was gibberish but looked like it was encrypted data. What a hoot watching everybody squirm as the revision numbers went up and up and up week by week. Of course, nobody ever really got laid off.

Look, listen, think

[njdj]

...VMS...

Did you ever hear a proverb about flogging a dead horse?

Re:Look, listen, think

[DJBenedict]

Of course, VMS is not dead. See http://www.openvms.compaq.com/

Memories and other missing data

[fm6]

This page really brings back some memories, both good and bad.

Now that comment demands amplification. I'm also frustrated by all the posts talking about NT's VMS roots, but few specifics as to what features and technologies NT inherited from VMS.

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!

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:some things I miss about VMS

[joefrench]

And I thought MS were breaking new ground with their common calling support...I didn't realize that VMS had the support. If only I had paid more attention all those years ago...

Re:some things I miss about VMS

[lophophore]

I was a VMS system manager for a couple of years. One of the things I remember was going out into the lab to find the Field Circus guy swapping out a disk drive. I had never called him, or even been aware that there was a problem. The system had discovered that the drive was failing (the error counts were up) and had notified field service itself. The engineer came out and swapped the drive before any system users became aware of the problem.

The documentation truly was outstanding. The VMS 5.2 doc set was over 10 feet of three-ring binders.

I also remember the 4-hour reboot times for our 120-node MIVC (mixed-interconnect vax cluster) after power failures. (it typically took a catastrophe to bring down a vax cluster.) Our whole team would bail to a brewpub.

Re:some things I miss about VMS

[spitzak]

I worked at Dec in 1982-4 and part of that time worked with a group on porting the Clu compiler (Clu was an early smalltalk-like OO language) from BSD Unix to VMS. The calling convention really bit bad as it was as much as six times slower than what Clu was using for BSD. You could not use the Clu convention because they wanted to call existing services without a wrapper, also I think the functions relied on register layout different than VMS used, or trapped, or something.

The project apparently died because it was unreasonably slow due to the fact that the Clu compiler produced lots of function calls, like for every multiply.

So I'm not sure if the uniform calling convention is a win. Linux actually is doing ok with wrapper libraries around C code like all the Perl and Python wrapper libs.

I would, but ...

[Pegasus]

Just where the hell can i get it? At my company, i can only find nt4 cds and i can't expect my local warez dealer to have a 0day copy of something like nt3.51.
So please, if someone can at least *hint* me where to get it ... now if that would be a copy for some other than x86 architecture, it would be even more l33t. I have the hardware ;)
Um, nt3.51 are unmaintained now, right? Does that give them the 'abandonware' status? :)

Re:I would, but ...

[joekool]

check you nt4 server CD's--3.5 is on there, along with other old crap, if I remember correctly

Nested Threads

[DrSkwid]

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

Re:Nested Threads

[cqnn]

> or Windows XP based on New Technology Technology

Actually no...

Due to FTC regs, they cannot use the "New"
anymore becuase the underlying OS is not new
anymore. They can still use "NT" as long as
they claim it doesn't have a real meaning
anymore.

Re:Nested Threads

[DrSkwid]

from O/S2 and Xenix comes VMS kernel alike posix compliant "NT" and they call *that* new!

well, like I say, it stood for Nested really anyway. Even some people from microsoft claim it's a Digit shift to VMS but I doubt that story too.

NT is a 386 mnemonic - Nested Threads

[DrSkwid]

marketing turned it into New Technology

VMS Secure?

[jmcnamera]

How do we know VMS is secure?

Many of the hacks on all the OS's are found by people looking for them for fame, fortune, glory and malice.

Has VMS had the attention of these folks to find things?

In other words, if only a few thousand people used Windows, they'd say it was the most secure OS in the world.

Re:Spare Me.

[Anonymous Coward]

Just to set the record straight (since I happened to be working in the OS group at DEC at the time, though in the RSX rather than the VMS group):

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.

they were the smartest people I ever met

[lophophore]

I worked there for 5 years, all on VMS. There were many of the smartest people I have ever met there. In my opinion, it was your loss. It's really too bad.

Re:they were the smartest people I ever met

[Zack]

I really did want to work there, but the contract they offered was entirely unacceptable to me. I could not turn over every idea I ever had, have, or will have to some company I was about to start working for. I had worked as an intern at Compaq in Houston the year before. But they were unwilling to work out a decent contract. I have no problem with them owning everything that I make for them, but what I make on my own time is mine.

Now I've got a job with 50% higher pay. You can't attract the best of the best with stupid contracts.

I know they were smart, I talked to a bunch of them and was very impressed. Maybe they had a better contract than that one they gave me.

the glorious orthagonality of DCL

[lophophore]

One of the nicest things about VMS is the glorious orthagonality of DCL. Everything worked in a similar manner. For example:

show system - kind of the same as ps -ef
show network - sort of the same as netstat -i
show users - kind of the same as who
show queue - kind of like lpq
show display - like printenv DISPLAY
show terminal - like printenv TERM

to set your terminal type, you would use
SET TERMINAL/DEVICE_TYPE=VT100.

The keywords could be abbreviated to as many letters that made them unique; the above would work as SET TERM/DEV=VT100

My point is, the UI was consistent; it was *engineered*, and it showed. If you wanted to SHOW something, and you did not know what it was, you could just type HELP SHOW.

VMS is in the sorry state it is in today because DEC believed in just how good it was. Ken Olson always called unix "snake oil," and never considered the unix vendors real competition, since unix was never considered to be robust and reliable enough to compete. But the customers thought they wanted a lower priced "commodity", "standard", "open" operating system... Maybe they were right. But that does not mean that unix was ever technically superior.

VMS (hacking, stability, etc.)

[kbarrett]

I was a VMS engineer for 13 years (I worked at DEC for 5 of them), have been involved in Linux for 10 years, and a user of other unix's for more than 5 years. I have written fairly well known products for all 3. NT, VMS, and unix all have strengths and weakness that give them niches, but let me report my personal experience on VMS. I can tell many people voicing opinions on VMS have no real experience with it.

First; I can tell you that VMS and NT has nothing in common from the perspective of an end-user or programmer. The architcture in common is in the OS level, and NT is a bastardized version of it. Do NOT believe that if you are familiar with NT that you have any experience in VMS.

Second; VMS is much more secure than NT or unix. Why? Well; first by default it came secure "out of the box" (except for default passwords). Networking did not allow free access into the system unless you set it up that way. Also, there were 32 individualized levels of privileges, not 2 (root or non-root, or the weird levels of NT). Privileges and file securities were defined in a manner that ryou really could set up a printer admin, password admin, backup operator, etc. without compromising system security. You controlled what people could get to and how much of the system resources there were limited to. In no way was this because people are more savey now or do it for fame -- people have always been savy and tried to claim fame. Unix came originaly from a universe where the goal was to share information. VMS originated from a universe for business applications and where sharing was to be "set up". It was frowned on to do things like preview email and automatically run shells on network connects. Logging was decent, controls were good, and systems fairly secure by default (provided the admins changed the stupid passwords). ACLs, disk quotas, and "temporary privileges" were the norm in VMS. Sure there were hacking break-ins, and with the internet audience larger now than in VMS days there are more of them, but I believe VMS would have held it's own just slightly ahead of unix today.

Third; VMS was stable (unlike NT). I was personally aware of VMS systems that had not been rebooted in over 5 YEARS! Like unix, software installs and process terminations did not require the OS to fail or reboot.

Fourth; The language calling standard. Anything could call easily anything! :-)
Fifth; It was much more user friendly. Commands were obvious, and switches were universal. For those being honest, unix commands are the most cryptic of all OS's (mv for rename, cp for copy, ls for directory or list, man for help?). You have to learn to use unix -- vms you could pretty much type broken english or "help".

Sixth; Clustering. Even today, nothing matches the ease and functionality of VMS clustering. All the computers looked and acted as one, and a device on one was availabel to anyone. And talk about single sign-on.

Seventh; DECnet networking was better than anything before it, and was as good as tcp/ip. Today, networking has surpassed it. But this did not really matter, and VMS supported both well.

Eighth; Like unix, the GUI is a tool, not a necessity.

Nineth; great documentation, and plenty of it, all in a standardized layout.

Tenth; portability. VMS ran perfectly on VAX and Alpha CPUs, and programs written for one ran unchanged on the other. The only reason that there was no VMS/intel was due to business situations, not technology.

But there were downsides...

The main reason VMS died was that it ran on expensive, proprietary hardware. Microsoft made it's way into the server room and intel hardwaqre was cheaper and multi-os compatible. If DEC has released VMS on intel as a product (it did exist internally, after all we are engineers), we might actually have 3 competing server OS's today.

File I/O. VMS I/O was designed to be reliable, with lots of abilities for control, recovery, and logging. The result was that it sucked in performance. unix I/O beats the pants off VMS I/O, even when you turned all the VMS features off. VMS systems make terrible file servers.

Licensing. It was DEC that introduced software licensing (as a software enforced tool with database). This was a side-effect of networking and clustering becoming the norm. Before this; you bought something you owned it. I remember cringing the first time I installed a license -- knowing that it artifically crippled software to limit it to nn users. It was much more fun before this nonsense.

Poor kernel Customization. While MicroVMS broke up the "kernel" into 4 major pieces that could be installed or left out, linux allows to build a kernel that does or has nothing you don't want in it.

Hardware detection. All VMS administrators remember the horrors of making sure VAX boards were installed in the correct slots and in the correct order so that SYSGEN could discover them, and still having to enter manual overrides to get it all working.

Performance tuning was an art. There were so many parameters that could be manipulated, and so many inter-dependencies, that tuning was quite a feat. SYSTEM FEEDBACK helped a lot!, but you really needed to learn the tools (SPA).

VMS also would have all the same difficulties that unix and linux have competing with Microsoft today (compatible office apps, desktop GUI, etc.).

When I worked at Red Hat and had talks with Compaq on HA technologies, I did ask on several occassions for them to consider releasing VMS (or at least VMS clustering) into Open Source. Never happened though :(

Re:VMS (hacking, stability, etc.)

[anonymous cupboard]

I don't think I ever had a major problem with SYSGEN. It seemed to work ok most of the time with me and definitely was easier than most versions of Win until Win2K.

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

Scary Thought

[Quill_28]

Where i used to work VMS machines ran the "lines." Each hour that these "lines" were down cost the company about 1 million. I left about 3 years ago and at that time they were planning on moving everything to Windows NT(2000 wasn't out yet). I don't hate Windows by why risk that much money on Windows? Seems funny now.

btw this is one of the largest companies in the world.

nice things about VMS

[sjanich]

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.

Re:nice things about VMS

[sjanich]

I forgot to add...

9) easy clustering

10) RMS a flat indexed file system the was greate for that world of programs that just don't need a rdbms.

Re:nice things about VMS

[WWWWolf]

5) Good on-line help that was nested. You didn't have to eyeball pages of "man" output.

My apologies if I'm incorrect about the following. My idea of VMS help was from one 1980s book, with near-complete session logs and remarks, where a cracker "obtained" axx0ss for a VMS machine and spent pages and pages and pages on examining the help system and trying to figure out how to f%$#@k this thing is supposed to be used... =)

Judging from the book, the VMS help system was somewhat similar to the help system found in GNUPLOT - a help system that seemed neat at first glance, but was seriously unfunny to use. =( I personally prefer either a man-style documentation (man, perldoc), or hypertext (info, or any html manual) - topics and subtopics required additional dexterity to navigate.

8) I'll take EDT or LSE over vi any day!

Granted, xemacs needs a second (!) to start up on my PIII-600MHz, but it's the best editor, ever. Argh, I'd personally not get into the Editor War, everyone knows no one can agree on those kinds of opinions... except that, yes, vi sucks. ::duck:: =)

...have no right to complain here, I use vim as the editor launched by whatever needs an editor, and xemacs as the operating system, er, editor that is running all the time for general editing.

Re:nice things about VMS

[cotodoso]

sjanich on Saturday August 31, @10:30PM wrote:

> 1) Multiple account-by-account security systems
There is one of VMS's security features I'm a little divided on: the ability to specify privileges on an account-by-account basis. It makes it easier to tailor each account's abilities, but it also makes it harder to track who has "rootly" powers. You can create a lot of accounts that have all privileges enabled, and the file that this info is stored in is a binary one. Not ideal, IMHO.

> 3) DCL scripting language was pretty good for its type (better then sh)

I don't care for it much. I just spent a day last week trying to emulate a Unix shell pipe in DCL. I couldn't (Yes, I know about the DCL PIPE command...). I was trying to capture the output of a DIRECTORY listing, so I could use COPY/RCP. (And another thing, why does COPY have a /SINCE=YESTERDAY option, but COPY/RCP does not?)

>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.

I'll grant you both points. The help pages are really well-structured and end in a page or two of examples. The reliability is really up there, too. Where I work we have an old Alpha that needed a firmware upgrade; one of my fellow admins put off the work a few days so he could see the uptime hit 1000 days.

> 8) I'll take EDT or LSE over vi any day!

I'd take ANYTHING over vi any day, up to and including shouting and gesturing at the screen...

cotodoso
(Solaris/Linux/OpenVMS admin)

Re:nice things about VMS

[sjanich]

Yes, the Unix "|" is definetly better then anything in the DCL wolrd. I much prefer the DCL logic controls to that of sh. Of course, today I wrap perl around commands a instead of sh.

Re:case insensitive beast ....

[kbarrett]

You remember wierdly then. It was not an uppercase only system. Perhaps you were on an upper-case only terminal. VMS was case insensitive on input, but displayed and accepted lowercase as normal. Even the very first thing you saw, "Username:", was not in uppercase.

Re:Stop.. my ribs!

[kbarrett]

Obviously someone under 35 years old with no real experience in VMS.

Many misconceptions here

[DJBenedict]

Upon reviewing these comments, it appears that many misconceptions prevail about VMS, what it is and what it is not.

I can tell you with the authority of 22 years experience that NT is *NOT* and never will be VMS. NT's feeble CMD cannot even dream of approaching DCL.

VMS is not UN*X, nor is UN*X VMS. VMS is acquiring many new capabilities to make the operating environment look very UN*X-like, including giving the appearance that all of the devices MOUNTed to the system are just one big, happy filesystem.

VMS is not "tied to DECnet". Many systems around the world are running quite happily using only TCP/IP, without either DECnet or LAT.

VMS is not dead, although Bobby "GQ" Palmer tried his damnedest to kill it. He couldn't.

VMS is secure. Kevin Mitnick tried his damnedest to hack it without "social engineering". He couldn't, and so testified to Congress.

VMS is "proprietary", but then the same argument can be made for WhineBloze and UN*X. VMS's biggest problem is that has never been ported to the processor that lives in 10's of millions of servers the world over (Intel/x86). It is being ported to Itanic; however, Intel has been birthing IA64 since shortly after the arrival of mass-produced commercial Alpha machines. Remember: Alpha has a ten-year+ history of being what Itanic aspires to be.

VMS is stable. A non-continental European railroad I believe holds the record at 18 years of continuous operation with no reboot. My personal record is just shy of three years.

VMS has the kind of clustering that Oracle, WhineBloze and UN*X can only dream about. Tru64 comes close with TruCluster, but the functionality has not yet reached full parity with VMS, AFAIK.

VMS is reliable. Some of VMS's data protection schemes cause evaluators to incorrectly report that the I/O performance is "lack-luster". However, the VMS paradigm is that data integrity is the more valuable ideal. Current I/O subsystems are providing throughput that matches or equals that achieved by lesser o.s.-es; so, this is really a non-issue.

VMS has survived the attacks of its own "parent" under command of GQ Bobby, the shameful mis-management it suffered under the Compaq regime, and still tries to overcome the artificial limits set on it during the transition to HP.

We, the OpenVMS faithful hold great hope that the response by HP to our pleadings will cause us to see a resurgence of VMS as a stable, secure, reliable, scalable platform.

Whether that platform is built on an Alpha or Itanic foundation makes little fundamental difference.

My home page: http://www.djesys.com/

Re:Next on Slashdot...

[DJBenedict]

VMS is *NOT* primitive by *ANY* stretch of the imagination! You may not know how to use the advanced features of VMS, but that does not mean they are not there!

UN*X (including Linux!) and WhineBloze are, by comparison, barely a stone's throw from stone-age computing, IMO.

Don't believe me? Try this in UN*X (Linux, *BSD, AIX, etc.) (DOS/Win's mechanisms are similar to VMS and DCL, just greatly more limited): write a short shell script to create 10,000 files or more in any single directory such that the filenames are at least 10 characters long. Then, cd to that directory, enter "echo *" at the shell prompt, and watch the fun!

Re:VMS was fantastic

[shibboleth]

You're correct about everything here except that the code examples in their docs very often didn't work (typos and such). Which was strange, but evidently the writers had to retype the programs provided them from hardcopy.

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.

From a button

[karl.auerbach]

From a button seen sometime and somewhere in late 1980's or early 1990's:

VAX/VMS - Software for the Sixties.

Re:From a button

[Beave]

For a operating system that didnt come about until the late/mid 70's... pretty stupid button..

Re:PL/I, VAX/C and David Cutler

[anonymous cupboard]

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

Re:UNIX advantages.

[spitzak]

A simple C program to copy files on VMS would only copy some files, those designed to run with the C subsystem. The revelation for Unix was that this was all files.

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.

Re:UNIX advantages.

[spitzak]

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.

Re:UNIX advantages.

[koadic]

Actually, it's the other way around; VMS never had an "apropos" sort of command to search for keywords, but to get help on, say, the DIRECTORY command, you just type "HELP DIRECTORY".

On the plus side, VMS help is hierarchical, so you can usually navigate your way down to what you're looking for by choosing the appropriate item from a list.

Re:You're wrong (or, VMS++ != ONT)

[Baldrson]

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

OpenVMS security

[akita147]

wrt OpenVMS security, our company has just released the first in a range of VMS security
tools. The demo version is available at:

http://www.akita-security.co.uk/stoat

and there is a mailing list for the discussion
of OpenVMS security available at the same URL.