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.

Re:VMS?

[Anonymous Coward]

VMS is officially undead, and I should know, I still have a massive lineprint of all the 13 digit JANET addresses we used to add in at the end of SET HOST /X29, you know young people today have never felt the sheer joy of using up days of runtime on a VAX with a SPICE simulation...

Re:VMS?

[Anonymous Coward]

Sorry to hear that.

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!

Re:cool!

[Anonymous Coward]

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!

Amen! DIR/DATE/SIZ=ALL/EXCLUDE=MAIL.MAI is about as un-cryptic and easy as can be!
Then, you put that long command into a "symbol", and make it easier...
$ DIR :== DIR/DATE/SIZ=ALL/EXCLUDE=MAIL.MAI

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

[Anonymous Coward]

You seem to misunderstand. You can't use their systems for business. They are there for hobbyists. VMS on the other hand can be used for business. You just have to get your own server.

Re:You can't use it anyway

[Anonymous Coward]

So if you want to have anything to do with this project, you can't use the OpenVMS they are distributing for business. That makes working on the project a counterproductive endeavor.

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.

Re:You can't use it anyway

[Anonymous Coward]

'Any OS can be cracked' sounds suspiciously like a generalization for something for which you have no evidence other than your own unsupported opinion. While I wouldn't go as far as to suggest that VMS *cannot* be cracked, I'll suggest that relative degrees of security are still of significant practical importance and that VMS is more secure than any other general-purpose OS out there. If you wish to contend otherwise, it behooves you to present evidence of some sort rather than simply assume that your own intuition carries more weight than the experience of people who have some actual acquaintance with such matters.

- bill

The state of VMS

[Anonymous Coward]

We have multiple OpenVMS machines at work, OpenVMS is very much alive.

Re:The state of VMS

[Anonymous Coward]

me too. We also sell million dollar software to companies and institurions. It runs on aix, vms, and (ack!) windows 2k advanced datacenter. Almost all our clients buy a new alpha. Compaq even subsidizes our advertisements!

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

[Anonymous Coward]

no.

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

[Anonymous Coward]

There are lots of contracts like that out there, don't sign them whatever you do!!!

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]

Most of the incredible smart guys had probably been there since the days of DEC

It's the same with Rdb, the relational database that DEC sold to Oracle back in ~1997. All of the engineers and tech support people are at least in their mid-40's and have been working on DEC products (sometimes even the same product) since the mid-80's.

And in Nahua, DEC/Compaq/HP's VMS engineers are a short walk thru the woods to the Oracle engineers that work on Rdb....

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

Re:VMS is 1337

[Anonymous Coward]

Kirby is that you?

Rawn

Re:Next on Slashdot...

[Anonymous Coward]

Actually, VMS is still very good for some tasks.

It has stability and security like nothing Linux or Windows will ever reach. However, it quite primitive so it's kind of hard to use.

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?

[Amiga Trombone]

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.

It does seem to have quite a fan club among people who are familiar with it. Considering that, I wonder why no one has attempted an open-source implementation of it. Particularily since it seems to have been neglected by it's last two owners.

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 Coward]

There actually are a couple of projects, no one looks like they got very far. Try a google search.

Re:VMS better than *NIX?

[Anonymous Coward]

A brief Google search reveals this comparison.

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?

[Anonymous Coward]

Clustering, high quality SMP, and a fine grained security model.

The security in paricular, was much, much better than that of Unix -- it was a far more secure OS.

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]

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?

In a nutshell, VMS is not case sensitive.

Re:VMS better than *NIX?

[Anonymous Coward]

DOS is not case sensitive. Therefore, DOS is better than *NIX.

Re:VMS better than *NIX?

[Anonymous Coward]

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?

While I don't have any trouble modifying VMS security on boxes I control, certainly someone else might have a different view depending on their experience.

A significant difference from Unix, however, is that somebody with minimal experience is less likely to have problems securing a VMS box.

The world is full of administrators with minimal experience. Maybe it shouldn't be, but until you get to be Global Personnel Officer that is the way it will stay.

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?

[Anonymous Coward]

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?

As of early June, Compaq and Oracle were busy porting. If they didn't port it, a lot of big companies, and the DoD, would squeal like pigs...

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 Coward]

Though I doubt that anyone's opinion is going to change on the matter of file name case-sensitivity any time soon, the allegation that case-insensitivity is some kind of problem for programs attempting to match file names for equality rises to the level of incompetence. It is far more trivial for a program to convert both names to single-case and compare than it is for a human to remember *exactly* the name s/he gave a file, including case - *especially* if names are presented in a directory either in no particular order or in binary collating order (rather than in a special order that collates letters that differ only in case together, because of the problem that naming case-sensitivity introduced).

- bill

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?

[Anonymous Coward]

RMS could have worked just as well as a library. It was a fine ISAM implmentation. Alas, I happened to be a fan of RDB, but that cost $$ and RMS came with.

RMS was integrated into the OS, so there were any number of basic file-to-file operations that the OS deemed "incompatible". Programs in 'C' might be able to seemlessly deal with the data in any of a number of RMS file formats, and the choice made by one programmer was arbitrary -- yet different from the sensibilities of another. But the OS would get all particular about handling each file type in each file type's particular way.

Not that it made life horrible. It was just another point of development contention and operational planning that didn't really have to be forced by the OS.

Re:VMS better than *NIX?

[Anonymous Coward]

How right is that assertion (VMS is more secure)?

Hell... Unix doesn't really know what security
is or there wouldn't be a plethora of third
party crap to make it a go.

In VMS:

$ help analyze/audit

ANALYZE /AUDIT

The Audit Analysis utility (ANALYZE/AUDIT) processes event
messages in security audit log files to produce reports of
security-related events on the system.

Format

ANALYZE/AUDIT [file-spec[,...]]

file-spec[,...]

Specifies one or more security audit log files as input to
ANALYZE/AUDIT. If you specify more than one file name, separate
the names with commas.

If you omit the file-spec parameter, the utility searches for the
default audit log file SECURITY.AUDIT$JOURNAL.

Press RETURN to continue ...

The default audit log file is created in the SYS$COMMON:[SYSMGR]
directory. To use the file, specify SYS$MANAGER on the ANALYZE /AUDIT command line. If you do not specify a directory, the
utility searches for the file in the current directory.

You can include wildcard characters, such as the asterisk (*) or
percent sign (%), in the file specification.

The audit log file can be located in any directory. To display
the current location, use the DCL command SHOW AUDIT/ALL.

Additional information available:

Qualifiers /BEFORE /BINARY /BRIEF /EVENT_TYPE /FULL /IGNORE /INTERACTIVE /OUTPUT /PAUSE /SELECT /SINCE /SUMMARY

ANALYZE /AUDIT Subtopic? /select

ANALYZE /AUDIT /SELECT

Specifies the criteria for selecting records from the audit log
file. See the OpenVMS Guide to System Security for a description
of how to generate audit records.

Format /SELECT=criteria[,...] /NOSELECT

criteria[,...]

Specifies the criteria for selecting records. For each specified
criterion, ANALYZE/AUDIT has two selection requirements:

Press RETURN to continue ...

o The packet corresponding to the criterion must be present in
the record.

o One of the specified values must match the value in that
packet.

For example, if you specify (USER=(PUTNAM,WU),SYSTEM=DBASE) as
the criteria, ANALYZE/AUDIT selects an event record containing
the SYSTEM=DBASE packet and a USER packet with either the PUTNAM
value or the WU value.

If you omit the /SELECT qualifier, all event records selected
through the /EVENT_TYPE qualifier are extracted from the audit
log file and included in the report.

You can specify any of the following criteria:

Additional information available:

Press RETURN to continue ...

ACCESS ACCOUNT ALARM_NAME ASSOCIATION_NAME AUDIT_NAME
COMMAND_LINE CONNECTION_IDENTIFICATION
DECNET_LINK_IDENTIFICATION DECNET_OBJECT_NAME
DECNET_OBJECT_NUMBER DEFAULT_USERNAME DEVICE_NAME
DIRECTORY_ENTRY DIRECTORY_NAME DISMOUNT_FLAGS
EVENT_CLUSTER_NAME FACILITY FIELD_NAME FILE_NAME
FILE_IDENTIFICATION FLAGS HOLDER IDENTIFIER
IDENTIFIERS_MISSING IDENTIFIERS_USED IMAGE_NAME INSTALL
LNM_PARENT_NAME LNM_TABLE_NAME LOCAL LOGICAL_NAME
MAILBOX_UNIT MOUNT_FLAGS NEW_DATA NEW_IMAGE_NAME
NEW_OWNER OBJECT PARENT PASSWORD PRIVILEGES_MISSING
PRIVILEGES_USED PROCESS REMOTE REQUEST_NUMBER
SECTION_NAME STATUS SUBJECT_OWNER SUBTYPE
SYSTEM SYSTEM_SERVICE_NAME TARGET_DEVICE_NAME
TARGET_PROCESS_IDENTIFICATION TARGET_PROCESS_NAME
TARGET_PROCESS_OWNER TARGET_USERNAME TERMINAL TRANSPORT_NAME
USERNAME VOLUME_NAME VOLUME_SET_NAME Examples

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

[Amiga Trombone]

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.

Yes, his name is Dave Cutler - and there goes his reputation!

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

[Anonymous Coward]

It was implemented by a bunch of the programmers, lead by a project leader. Now that project leader happened to be the same guy who was responsible for VMS, but it doesn't stop there: also several of the programmers were the same ones that wrote VMS.

Whether their salaries were paid by Digital or by MS can't make too much difference IMO, they were working for a big corporation that wanted them to come up with a good OS in both cases.

MS allowed them to go way over schedule and finish the details before it was shipped, something I doubt would have been true at Digital.

with cars, they issue recalls, with MS Operating systems, they issue Service Packs

MS call it a service pack, and keep the name and version of the OS (or software) the same.

In the *n*x world they call it a new release and bump the version number.

Besides that, I don't see much difference.

Re:but VMS lives

[Anonymous Coward]

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

That was Dave Cutler's original intention, but NT mutated considerably from its VMS roots, and now VMS and NT only share the name of the original architect.

And NO, the VMS and NT command lines are considerably different - VMS is comparable in functionality to a Bash shell; I can't make any such comparision for the NT commandline shell except DOS.

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

[Anonymous Coward]

The command line shell was out sourced to some other company. It is just a shell that sits on top of the Kernel, such as UNIX, and is not tied to the system. That is why it is called CMD.exe.
Remember when Microsoft stated in some sort of conference that their shell was more "Kornshell than Kornshell" and David Korn told them "NO".

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

[Anonymous Coward]

Doesn't NT have a REXX interpreter? (from OS/2)?

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

[Anonymous Coward]

The only real similarity between VMS and NT are the kernels.

The internal data structures and names are remarkably similar between the two. Everything else is different, since DOS, win16 & win32 had to be added to NT.

Re:but VMS lives

[Anonymous Coward]

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.

Looping in DCL is implemented using GOTO. What makes DCL a good scripting language a symbols, logicals and lexicls (system service calls). For example, here is a script that I wrote yesterday that sorts all .UNL files into .SRT files, then deletes each .UNL file only if the SORT command succeeds:
$ set ver
$ on error then $goto bend
$ DEFI SORTWORK0 DKD202:[SORTWORK]
$ DEFI SORTWORK1 DKD101:[SORTWORK]
$ DEFI SORTWORK2 DKD202:[SORTWORK]
$ DEFI SORTWORK3 DKD101:[SORTWORK]
$ DEFI SORTWORK4 DKD202:[SORTWORK]
$ DEFI SORTWORK5 DKD101:[SORTWORK]
$ DEFI SORTWORK6 DKD202:[SORTWORK]
$ DEFI SORTWORK7 DKD101:[SORTWORK]
$ DEFI SORTWORK8 DKD202:[SORTWORK]
$ DEFI SORTWORK9 DKD101:[SORTWORK]
$!
$!
$ set def DKD101:[DBMAINT.REORG.DBL]
$ltop1:
$ file = f$search("*.unl")
$ if file .eqs. "" then $goto lend1
$ fname = f$parse(file,,,"NAME")
$ lrl = f$file_attrib("''fname'.UNL", "lrl")
$ eof = f$file_attrib("''fname'.UNL", "eof")
$ sort/stat/work=10 - /key=(pos:1,size:4,binary,signed) - /key=(pos:5,size:2,binary,signed) - /key=(pos:7,size:8,binary,signed) -
'fname'.UNL/form=(rec:'lrl',file:'eof') -
'fname'.SRT
$ hstat = $status
$ if hstat .eq. 1
$ then
$ del/log 'fname'.UNL;
$ goto ltop1
$lend1:
$ exit

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

[Anonymous Coward]

The guards' guards will guard the guards.

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

[Anonymous Coward]

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

Because Dave Cutler wasn't the only one who had a hand in NT - recall the move of video drivers into the kernel, as if NT was supposed to be a Win98-style gamers platform. Too many marketing-related "requirements" that compromised the engineering.

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.

Re:It makes you wonder...

[Anonymous Coward]

Why does it suck so badly? They had to carry
a lot of baggage for one (MS-DOS). Secondly,
Cutler actually went his own way very early on.
He never touched cluster code, basically did
V1.0.

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.

n/s

[U R TEH SUX]

n/m

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?

[Anonymous Coward]

No, it wasn't a single-used shell.

It was just the cluster interface, anyone can access it, and it has no privs.

Please don't post about things you obviously know nothing about.

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.

Re:why bother?

[Anonymous Coward]

Correct me if I'm wrong, but you mention exactly the conversational boot procedure which is meant _exactly_ for recovering a lost system. So of course it works :) it would be plain silly to throw a system away when one forgets the system password, and silly also to call security leak a standard recovery procedure.

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

[Anonymous Coward]

No, it's not dead. Dying, yes, but not dead yet. I maintain databases on 4 Alpha VMS boxen daily (am working on 2 of them right now, on the 3 day weekend), and maintain databases on 4 others when the other DBA is on vacation.

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

[Anonymous Coward]

Most schools still have some VMS systems. A lot of vital records systems are still VMS and many schools still have some public vax servers. They are actually very common still.

Re:VMS Still in Use at RIT

[Anonymous Coward]

for example, campus email, internet browsing (via lynx) and word processing (wordperfect) was (and is, to some extent) all done on VMS systems (with text-terminals in the dorms) at Interlochen Arts Academy

talk about a bunch of high-schoolers being confused when first starting with a text-based interface!

but now that students are able to dial up isps in their rooms, the terminals are becoming less relevant.

Re:VMS Still in Use at RIT

[Anonymous Coward]

Interlochen Arts Academy? Now there is a school as gay as a day in May.

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

I switched from VMS

[Anonymous Coward]

to LSD.
And I never looked back.

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

[Anonymous Coward]

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

You could pipe DCL. It wasn't pretty, but you could. You had to understand logical names (an utterly non-unix concept, something of a cross between a path and a environment var that was known to the file name handling syscalls, like,"open").

Then, of course, you could just fire up a UNIX shell of your choice. Borne and ksh were both available.

VMS does have a number of things that would better left on the scrap heap. DCL, as a whole, sucked but the command parser itself got a few details right. You can burn RMS at the stake, what a complete waste. The filename style device:[directory.directory]filename.ext convention sucked, the UNIX way is much better, I think.

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

[Anonymous Coward]

clustering, VMS had it way before (and it still is bettter than most versions of unix)

Does any OS do clustering as good as VMS? The Distributed Lock Manager is a bit of a resource hog, but is VERY powerful. Likewise, TMSCP is a slow protocol, but solid. Shared disks and coherent locking among 96 nodes is transparent to the user and the application programmer, i.e., any high-level application you write is automatically cluster-aware. Mucho handy...

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

[Anonymous Coward]

The file.ext;1 are version numbers, if you open a file without specifying a version number it defaults to the largest number after the ';'

foo.c;1 foo.c;2 foo.c;3

gcc -o foo foo.c

will use foo.c;3 as default, but if you screw up, you can always 'delete foo.c;3' and then it will use ;2. version numbers in filenames, a GREAT IDEA. use 'purge' to get rid of the old ones.

Re:VMS didn't leave

[Anonymous Coward]

Well the reason it's similar to MS-DOS (hak. spit) is because MS-DOS v1 was a poor copy of CP/M which itself was influenced by RSX (also a Dave Cutler OS) one of the ancestors of VMS.
For further reading I'd recommend "Showstopper!" (ISBN 0-7515-1629-5) Full of interesting info on the development of NT and some about VMS too.

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

[Anonymous Coward]

RSX-11M happened to be my first OS, I didn't know Cutler was co-resposible for the torturing I went through there ;-)

But as to "Digital got very little from MS", that depends on whether you call $150 million "very little".

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

[Anonymous Coward]

WOW! RSTS/E was a really great and wonderful system!
It was the first system I saw in my life and it's much superior to all RSX VMS and NT crap.
I hate Dave Cutler's ideas on heavyweight processes and other stuff that made systems so slow and his approach and I think he deserves the title of Dr. Evil of computing...

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

[Anonymous Coward]

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.

If you edit the file, then you will get a whole new version of the file. From within a program, it depends on whether the file is opened in append mode or not. A sysadmin can limit the number of versions retained, so that you don't accidentally consume all of the space on a device. If it is set to 5, the 6th disappears into nl: (VMS for /dev/nul).

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

[Anonymous Coward]

The "SET DEFAULT" command always amused me. I really liked VMS when I was using it on a daily basis in the early 90s, but an old VMS guy and I always argued about whether Unix or VMS had the better approach. I never let him forget that VMS would let you change to a directory that didn't actually exist! It would let you set default anywhere you wanted, whether the directory existed or not, and would only complain when you tried to do anything in that directory!

Re:VMS didn't leave

[Anonymous Coward]

> If you edit the file,

If you open a file for 'append', or 'update', no new version is created.

If you 'created' a file, and a version already existed, a new file with the next higher version number was created. Otherwise, a file with version ;1 was created.

That's it, nothing more.

Programmers could decide how this was used in their programs. File/Text editors usually copied the file into a new version before they made changes to it. Some did not, or made it an option.

Many things naturally 'create' output files from scratch each time they run. Things like compilers and the OS 'copy' and backup/restore tools.

The user, not just sysadmin, could limit the depth of the file versions. sysadmin could, however, set a max that the user could not exceed.

Re:VMS didn't leave

[Anonymous Coward]

Ok.

So in UNIX you have to error trap the 'cd' command, and in VMS you didn't.

In VMS you could set yourself to an arbitrary, non existent, place; then create the directory, '.' to UNI types, and the required tree would appear in a single stroke.

Better? Worse? I dunno, but if that's the best "I never let him forget" argument you have I'll bet that "old VMS guy" is quietly laughing at you.

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.

Re:Next on Slashdot...

[Anonymous Coward]

It has stability and security like nothing Linux or Windows will ever reach. However, it quite primitive so it's kind of hard to use

Linux is not primitive!

elegance

[Anonymous Coward]

VMS was a truly elegant operating system. Not something you see much with OSs these days.

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

[Anonymous Coward]

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

Almost; "OpenVMS" was first used when VMS was ported to the (then) new Alpha systems; the "open" referred to both the OS's strong POSIX support and it's newly-aquired cross-platform (..well, yes, both of them ;-) abilities. "Open" never referred to the source, VMS has never been open source.

The name wasn't ported to the original VAX flavor at the same time it was used on the Alpha, and that led to some confusion.

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

How secure?

[Anonymous Coward]

"considered one of the most secure"

I wonder is that reputation will last when everyone is running it and all hackers are looking for holes.

After all, windows (NT) is nothing more than the "next generation" of VMS, and some concepts of windows (like a registry) even found their way back into VMS (did they actually go through with that? It was on the promise list when Compaq bought Digital).

Not going anywhere, trolls!

[Anonymous Coward]

VMS has been around forever, its still under development. It hasnt gone away. Its not going away for a long time, too many companies have their money invested in VMS. If it is not broke dont fix it. It does its job very well thank you.

Stop.. my ribs!

[Anonymous Coward]

and it's considered one of the most secure OS's around...

VMS secure.. holy damn that's hilarious. Quick tell me another one.

Re:Stop.. my ribs!

[kbarrett]

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

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.

Re:VAX/VMS recollections

[Anonymous Coward]

And bindnings for all the system routines in all the languages.The way to talk to a VAX is not through DCL, but directly from a program in some nice high level language. e.g. Ada :-)

Re:VAX/VMS recollections

[Anonymous Coward]

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

More like a [Blue|Orange|Grey] Wall.
Blue = v4.x
Orange = v5.x
Grey = v6.x

The v7.x documation are as well written as the earlier documentation (VERY GOOD technical writers!), but are full height paperback (blech!) instead of medium-sized binders. The on-line documentation at compaq.com is much better...

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.

An ex-Deccie remembers

[Anonymous Coward]

you know, just looking at that website made me yearn for DCL, and its ever so consistent command qualifiers, which could be shorted or spelled out in full as you wanted.

One of Unices weakest asthetic points, and I never understood how it got these, are the little command line -h switches.

Was it Cal or AT&T that was to blame ? :-)

Winton

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.

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

[askii64]

I thought 2000 was when they started putting crap in the kernel. Or did that have something to do with video card drivers?

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

UNIX advantages.

[Anonymous Coward]

Unix has its advantages over VMS too.

One, the "unified" file system. VMS used a nasty file name format, like

SYS$USERS:[SLASH-ME.MYSUBDIR]FILE.EXT;3

Whereas UNIX would be something like.. /users/slash-me/mysubdir/file.ext

(But, not all UNI* support versioning and VMS had a number of nice file management tools not found in UNI*, like logical name tables, search lists, and such).

In practice I find the UNIX concept is much easier to handle.

UNI* had TCP way before VMS. DEC simply didn't want to accept the idea that TCP might eat their lunch. Even so, DECnet pre-dated VMS and had a number of scalability flaws that TCP did not.

Re:UNIX advantages.

[spitzak]

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

On Unix I could easily determine exactly what files existed with a few commands, easily open any file on the system with the same call, and parse a filename into it's parts with 3 lines of C. A program to copy a file was ten lines at most, while due to RMS "pip" on VMS was larger than any other program on the system and an absolute nightmare of bugs and patches.

It was also trivial to run a program in the background, and fork allowed me to experiment with multithreading, something that only the ultimate wizards could try on VMS.

From more advanced programmers I heard the CLU compiler used a method of calling that was as much as six times faster than the calling sequence VMS required and that one of the big problems was cutting down the number of function calls Clu generated to get the speed acceptable because of this.

Unix had "man", a way to look at documentation using the computer (another revelation at that time), and you could really find what you needed. Also all the documentation fit in two 3-ring binders, while VMS had an entire wall of books.

I never heard a single statement by anybody that Unix failed relative to VMS and I was dumbfounded that Dec did not scrap VMS right then and there and switch to this better system.

Now I was in high school, and I did not know much then. Quite likely I missed the advanced areas where VMS was better. But to a novice there was no comparison and no competition, Unix blew VMS away completely and utterly.

Re:UNIX advantages.

[Anonymous Coward]

Hmmm. I'm afraid that this post as well rises to the level of incompetence. Let's see:

Given that the C run-time system provides the standard interface on VMS, a C program to copy a file on VMS should be the same size as one to copy a file on Unix. Now, 'pip' is (or was) indeed a sizable program, and the reasons were 1) that it was an old and much-modified RSX program running in 'compatibility mode', complete with PDP-11 RMS, rather than a VMS-native utility, and 2) because 'pip' stood for 'peripheral interchange program', and it understood virtually the entire range of disk, tape, and unit-record devices DEC offered and how to convert record formats (including the RMS Relative and Indexed file formats) among them, rather than merely being a mechanism to 'copy files'. And this ability to understand records as well as simple byte-streams made gave VMS considerably more comprehensive (though also more complex) data-management mechanisms than Unix had.

If you believe that fork allowed you to 'experiment with multi-threading', you don't understand the meaning of the term. And if you considered the Unix on-line 'man' facilities a 'revelation', I guess you never even noticed VMS's on-line Help mechanism.

It is true that Unix is a much simpler system than VMS, and to the degree that this simplicity still satisfies a given user's needs that's a real Unix advantage. So it's easy to understand why a high-school student might incorrectly conclude that Unix was generally superior across the board.

It's also true that over the 25 years since VMS was designed major changes have occurred (such as decreases in memory and disk costs by more than a factor of 10,000) that make some of the complexity of VMS no longer necessary, and some of its default trade-offs less than ideal for today's environment (hence exposing the complexity of changing those defaults to people who only need to perform simple tasks, if they want to perform them at maximum speed). These are things that VMS should have addressed long ago and is only finally starting to address now - but that's more an indication of a decade's lack of interest by VMS's parent corporation in pushing VMS as a general-purpose solution, and certainly wasn't an issue for you back in 1982.

- bill

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.

[Anonymous Coward]

Ok, so there's the big fuss about the VMS being unfriendly to the beginner. Now how about the things you can do when you _know_ the system? I mean please get over the help and man issues, and forget the simple calculations in the background. VMS is for professionals, not for highschool thesis. If all you want from an OS is the user-friendliness, take Windows or even better Mac. Have you ever tried to deal with unix system libraries versions compatibility? Only once you try to develop a _real_ product under any OS you'll start to see its limitations. If all you know about it is how help and man work, or how to write three-lines C programs, sorry that's NOT system knowledge.

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.

Spare Me.

[Anonymous Coward]

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

His name was Dave Cutler. He was ONE resource on an otherwise substantial staff that build VMS. The "brain trust" behind VMS was about 8-12 people, and Dave was but one of them.

NT is a poor showing of VMS. Yes, Dave clearly brought a number of ideas with him. But, the implementations are shoddy in comparison, the list of VMS features in NT is incomplete, and of features that did make it many are incomplete in themselves.

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.

Re:Spare Me.

[Anonymous Coward]

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

I think 'bringing ideas', in prior post, is probably the right term. As you said, Mica was an unrealeased follow-on - an idea. The term is relative.

VMS is built up from a dozen distinct language environments. In fact, it is usually easer to list what languages weren't used. That fact, alone, suggests a highly distributed source of creative contribution beyond Dave.

No to tear Dave down, but many people joined to make VMS what it is/was. It is grossly unfair to a great many others to raise him to celeb status while forgetting the rest. It may make for useful marketing collateral, but "the God of VMS" he is not.

Re:Spare Me.

[Anonymous Coward]

You may choose not to differentiate between 'bringing ideas' and 'bringing architecture, detailed design, and running code', but I suspect you'd be in the minority. The fact that it was not *released* code, and was in part code that had been redone (but not necessarily redesigned, given that it was indeed intended to implement a VMS-compatible system), does not demote it (or the mature and decidedly VMS-specific architecture or design) to the status of just an 'idea', as any software engineer can attest.

It would be silly to suggest that any one person wrote a dominant percentage even of just the VMS operating system code (which IIRC initially comprised only assembler and Bliss: language diversification in the system came later, mostly during the port to Alpha when a small amount of earlier C code exploded into a significant portion of the system). But no one was more - or arguably even as - central to its initial architecture and design than Dave, and he did in fact write a prodigious amount of its original kernel code. So he was in a position to bring that architecture and design (and a significant amount of actual code) to NT, and he did.

He also unquestionably deserves celebrity status for his VMS (and other) accomplishments: this in no way implies 'forgetting' the rest of the people who helped realize them, but it does recognize that almost all of them were replaceable to a far higher degree than he was (which is a *relative* comment in no way intended to suggest that good lower-level engineers can easily be replaced on a whim). And one of the reasons for this was his unique (and this is a far more appropriate use of this adjective than most are) combination of technical ability and managerial drive.

VMS certainly continued to evolve after Dave's departure, and many aspects of that evolution (such as clustering) aren't reflected in NT (as an addendum to my previous comment on that, I just recalled that in September of 1999 Compaq gave Microsoft some additional code that had been being developed by DEC for use in a common file system for VMS and NT, which Microsoft proceded to dump into a closet because its shared-disk basis didn't fit their model of clustering for NT). However, this in no way negates the fact that NT's architecture, design, and even some of its code came from VMS, via Cutler: it just indicates that NT is in some respects a subset rather than an identical clone.

I've heard comments like yours before from people who had no direct or (close) indirect acquaintance with Dave and couldn't imagine that a person that pivotal could exist. But the failure is in the imaginations of such people, not in my description of his contributions. He's certainly not a 'God', and was (and I've heard remains) an abrasive, difficult task-master. But in technical ability he pretty much equaled the best DEC had to offer when DEC was in its prime, and combined with his managerial drive that made him the most significant software engineer in the company - which you had better believe is saying a lot, because the breadth and depth of technical talent DEC had then was utterly awesome.

- bill

example of VMS version control

[Anonymous Coward]

FOO.BAR;3
FOO.BAR;2
FOO.BAR;1

$ ed foo.bar ! edits top version (3)
$ ed foo.bar;-1 ! edits version 2
$ delete foo.bar; ! deletes top version (3)
$ purge foo.bar ! deletes all but top version
$ delete foo.bar;* ! deletes all versions

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

FreeVMS

[Anonymous Coward]

This project uses Linux 2.4.x to develop a free stand-alone VMS environment. I am hopeful to see this project succeed. I think they're also in need of developers.

If you're interested:

FreeVMS Project Homepage

freshmeat.net: Project details for FreeVMS

The FreeVMS Archive: By Date

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.

What the heck are you smoking?

[Anonymous Coward]

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

I spent a substantial amount of time designing and programming a user-mode analog to VMS's QIO/AST features for UNIX.

I dispare daily at working around VMS's process priority and memory control features, along with a host of others, that UNIX simply lacks.

Having spent 20 years growing from RSX, VMS, then to UNIX and Linux exclusively for the last 10, I can tell you... VMS is far from perfect, but UNIX truly sucks in many, many ways.

But, the Linux types are starting to learn that the UNIX way isn't always workable (VM subsystem and Scheduler issues, to start). I expect they will, if slowly, come to discover that RSX/VMS has been there, done that, and spent good deal of effort working out a problem, or two.

"Open"VMS

[bryam]

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

Re:"Open"VMS

[Anonymous Coward]

yes please!
Come on, HP (yeah, it's HP now!!!), your users are leaving in droves to other systems...

Could be worse

[Anonymous Coward]

They could have made you use TECO!

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.

Ah, VMS...

[Anonymous Coward]

Speaking as an ex-DECcie, VMS had all the benefits that a closed proprietary architecture can deliver on a good day. The operating system and the hardware were developed in tandem, so the hardware supported the basic primitives that made the OS work efficiently. They were developed in the days when 1M of memory was expensive, so there's not a lot of code bloat. The compilers and runtime were developed so that every language could call every other. A whole raft of innovations in "distributed" computing (from tighly-coupled multiprocessing through to loosely-coupled clustering). Logical naming in the filesystem (or strictly speaking, above the file system) made it easy to test and change software configurations.

But of course, all of the disadvantages of a closed propietary architecture - it became relatively expensive for customers compared to the PC and also increasingly expensive for the company to develop the hardware. Plus a limited market for 3rd party applications (remember OS/2?). There was 3rd party hardware (specs for system buses were made available) - quite a lot of it, but the departmental computer market (which is what we're taloking about) was never going to be viable in the brave new PC world.

Digital had a history of extremely well-respected operating systems (VMS, TOPS, RSX-11M) as well as a few duds (RSTS, anyone??).

Like many technology companies, Digital got taken unawares by a technology shift and was stuck with the costs of supporting "old technology" customers and the additional costs (some organisational rather than financial) of preparing for a "new technology" future. A few decisions taken differently and many of those Internet web servers might be running VMS rather than Linux. But that's business.

Those who are strongly anti-VMS in the (sterile) VMS vs Unix debate should remember that at the time VMS was in widespread use, Unix was also expensive for non-academic use (and available in incompatible flavours) and simply did not have the range and quality of software development tools that VMS had AT THE TIME.

Re:Ah, VMS...

[Anonymous Coward]

> Digital had a history of extremely well-respected operating systems (VMS, TOPS, RSX-11M) as well as a few duds (RSTS, anyone??).

RSTS/E has it's following. A University, or two, used it in their Computer courses and it had a fair following, and a number of 3rd party applications, in the business and accounting circles.

The glory of RSTS was that it was, basically, 63 remarkably stable "Dos Boxes" sharing a PDP-11, and generally running Basic. A simple, no frills, and cheap (at the time), business computing platform.

Network Security

[Anonymous Coward]

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.

The basic design of DECnet is that accessing a system either requires authentication (e.g., a password) or that a privileged user with access to the system set up a service to allow your connect.

By contrast the design of IP allows an unprivileged user to set up a service/process/whatever to allow others to connect.

IP may seem more attractive if you are an unprivileged user, but it is worse for the administrator trying to secure the machine against network attacks. It does not take a malicious individual to open a security hole, just an incompetent one.

Cutler left the project early

[Anonymous Coward]

His name was Dave Cutler. He was ONE resource on an otherwise substantial staff that build VMS. The "brain trust" behind VMS was about 8-12 people, and Dave was but one of them.

And he was one who bailed out at the end of VMS V1. Some others who were there in the beginning were still around when VMS got to V7.

PL/I, VAX/C and David Cutler

[Anonymous Coward]

Some of their stuff, frankly, sucked. For example, the early implementations of PL/1 and VAX/C.

Strange you should mention that - the PL/I and C compilers were built by a team led by David Cutler after he left the operating system group. In those days the compiler groups were responsible for providing debugger support for their compilers, and C went 4 years without debugger support.

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

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?

[Anonymous Coward]

After all isn't this is the secure OS that Kevin Mitnick was adept at cracking.

Mitnick's exploits were based on social engineering which certainly bears on the quality of DEC training for employees, but not on the OS security.

Re:Is VMS really that secure?

[Anonymous Coward]

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?

Well, the sysadmin actually has to implement the features for them to be effective...

What makes VMS so secure?M

ACLs (has had them since at least 1988) and multiple levels of priviledge. As an earlier poster elucidates quite nicely, in *ix, you are either root or normal.

If root, you can run any program. In VMS, there are ~30 different priviledges that can be granted. For example, a Customer Engineer can be given the DIAGNOSE priviledge, but not the MOUNT priviledge, so he can run diagnostics, but not mount disks or tapes.

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.

Re:Is VMS really that secure?

[Anonymous Coward]

What makes VMS so secure?

The fact that almost no-one uses it anymore...

case insensitive beast ....

[Anonymous Coward]

Ya know, the last time I touched VMS was on an old DEC 6340. What I really remember about it was the clunky feel of the upper case operating system -- I always felt like I was shouting.

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.

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:VMS Secure?

[Anonymous Coward]

Try looking up the DEFCON results last year. There was a VMS box there and they couldn't break into it.

Though for networked systems there is one insecurity, in that if you run the Compaq/HP TCPIP stack (which most people will), you don't get SSH. If you run the Multinet or TCPware stacks, then you get SSH, plus the same company that makes those two stacks sells an SSH addon for Compaq/HP TCPIP.

VMS is my main OS at home, I do have a Linux system, but it's for running PDP-10 and PDP-11 emulators.

Z.

Re:VMS Secure?

[Anonymous Coward]

There was a Vax on the net years ago. Break in, get a copy of the encripted file, show the man how you did it, collect several thousand dollars. After 4 years, he gave out a username/password, and increased the dosh. After another 3? years, it was shut down. Zero breakins total.

Re the Mitnik comments, he was a good part of why VMS is now near bulletproof. And if that is not good enough, you can run Secureity Enhanced VMS. But you won't want to!!

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

[Anonymous Coward]

Cutler has acknowledged no such thing, and has in fact flatly denied it. The project was conceived as the successor to OS/2 and was called "OS/2 NT" for much of its development. (The "NT" designation was derived from the original build target, the Intel i860, a/k/a "N-Ten"; the marketroids later backronymed this to "New Technology".)

Incidentally, Clarke similarly insists that HAL had nothing to do with IBM, and was instead a contraction of "Heuristic ALgorithmic".

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

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.

Why the past tense?

[Anonymous Coward]

In reading the comments here, I'm wondering why so many people are saying how great VMS was. It's never gone away, it still has all those features that people are saying were so great, and it has many more new features. If you need rock solid stability, clustering and strong security, you can't beat OpenVMS!

BTW, for an idea of the quality and depth of documentation, check out the documentation website . Of course, if you're serious about VMS, you've got a fullsized bookcase or two full of the doc's like I do :^)

Sure the cost of getting into VMS is high, but check out the TCO compared to Unix or Windows. With VMS a couple people can manage a very large cluster, while the same number of Unix systems would take more people, or a hoard of people if you're running Windows.

Also, don't forget, the port to the Itanium processor is well underway. VMS has a lot of life left in it!

Oh, and it's really not that hard to use VMS, prior to getting married, my wife had only used Windows, now she regularly uses OpenVMS.

Zane

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

VMS was fantastic

[Anonymous Coward]

I spend many years working with a VMS based control system. The kind that can't fail, or big equipment could be destroyed.

It was amazingly stable. Disk full? Keeps on running. Process spinning out? Kill it without affecting anything else. Networking - need to know what's going on far away in the plant, hop on the user's console and see. You could yank network cables on and off at will - nothing tanked as a result. Machines ran for years.

Commands were logically designed and almost felt like actual english language. A bookcase was filled with accurate detailed documentation you could understand. Want to know what changed today? DIR/MOD/SINCE=TODAY. Unix has a lot of the same functionality, but relearning commands in more cryptic forms was a pain.

Backup and Restore. The Image backup took a drive to a tape and back to the drive perfectly - one step operations that always worked. Far and away the best system I've ever seen.

As for NT and VMS. I have no idea what the connection was supposed to be, but I see very little in common. There is certainly no connection at the command line interface. NT has "Tasks" you can sort of manage, but not much else.

I'd love to use it again on a real project. Bring back VMS!

Re:VMS was fantastic

[Anonymous Coward]

I would like to join in with the "what's this WAS stuff !!!!!" and "It never left!"

VMS is alive and ok and should last another decade at least (assuming it survives the move to Itanium hardware this/next year & Itanium itself survives.).

Sure... it has a smaller market share than something free like Linux (Digital/Compa/HP have been claiming 400,000 active systems out there for the past couple years) and advertising has been fairly low for a while but lack of advertising or media popularity does not mean it's dead. (If it was I'd have to go job hunting )

And it may require a different mindset to get the best out of it (I wasn't a BIG VMS fan until I really understood it) but it's worth it.

Anyone who wants to play with it can always check out one of the free VAX emulators or get actual hardware from ebay. (Details on the VMS Hobbyist program can be found in the FAQ at www.openvms.compaq.com.)

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.

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.

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:Many misconceptions here

[Anonymous Coward]

Thought that sounded like you, Dave.

I was tempted to reply to another poster who complained about VMS's lack-luster file system performance w.r.t. Unix, but your comments bring in the added dimension of reliability, so here goes:

VMS's *default* file access performance is indeed a lot slower than Unix's for common access patterns. This is primarily due not to excess zeal in data integrity (contrary to what even many VMS enthusiasts believe, for operations on typical files VMS uses write-back caching just as Unix does) but to antiquated defaults in the file system (8 KB buffers for reads and writes that date back to a time when 8 KB was a lot of memory).

The good news is that you can change these defaults to something reasonable. The bad news is that something reasonable isn't the default in the first place, and many people never bother finding out that they could do better. VMS engineering has said it's reluctant to change the default because it would affect process virtual address space use and hence potentially cause something cease working if the system was right on the hairy edge of space use, but there are clearly ways to provide better defaults that would not affect old programs without permission.

VMS is *finally* moving closer to a central file system (unified) cache with some similarity to Unix's. But once again, a user who knew what they were doing could have achieved something somewhat similar (using 'global buffers') for the past 20+ years: the problem is less lack of facility than the fact that the facility is not transparent but requires user set-up. When the new central cache facilities are complete (the read optimizations are already shipping) VMS file I/O should at least start approaching Unix's in speed.

On the integrity front, VMS should remain solider (and in consequence a slower) than traditional Unix file systems like UFS and ext2fs (where unordered metadata write-back can, though very rarely, do things like lose files) and equal to more reliable Unix file systems (such as those protected by transaction logs or by the Berkeley 'soft update' mechanism), though it may be a bit slower than them as well (its 'careful update' sequencing still costs a bit - that's why I referred to it as a bit out-dated elsewhere).

In sum, VMS's main file system performance problems when compared with Unix are that a user has to expend sometimes considerable effort on VMS to obtain the same performance that comes by default on Unix, rather than that near-equivalent performance is not possible on VMS. If VMS's owner had had the slightest interest over the past decade in making VMS generally competitive, rather than just milking it in its narrowing niche, such a situation would have been addressed long ago.

- bill

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!

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

Two cultures

[Anonymous Coward]

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)

Well, Digital was always a mixture of cultures. One of the principle divisions was between the *6-bit groups (12, 18 and 36-bit processors) and the *8-bit groups (8, 16, 32 and 64-bit processors). DEC had development groups coming out of its ears, many of them doing similar things in different ways (and sometimes doing similar things in similar ways, unaware of each other's existence). At different times there were at least two different Un*x strategies. Most of these groups rubbed along together pretty well.

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

Only if "everyone" has no experience of running a commercial computer system in a production environment

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.