Hacker News Reader

Comment by ue_ | Hacker News Reader

What sort of things could/can VMS do that Unix couldn't? I know almost nothing about computer history.

VMS had early support for clustering and associated technologies like shared filesystems with a distributed lock manager.

VMS had amazing support for terminal servers, so that each terminal user could choose among several connected computers. Terminal I/O was almost completely offloaded: it was common for other users to get delays and random short freezes, but VMS terminal users had smooth responsive I/O all the time.

DEC mandated the Common Language Environment, something like the C library calling convention but much better thought out and specified. It was totally normal to write an application in two or three languages because you felt that each language had advantages for that part. Every compiler and interpreter knew how to call functions from the CLE and export their own.

> VMS terminal users had smooth responsive I/O all the time.

I recall that you could press Ctrl-T and it would instantly echo back some useful information about the running process, like CPU time and page faults. That was a nifty feature.

I loved VMS. Everything was so coherent, whereas Unix looked like it was hacked together overnight by a bunch of people who never talked to each other. These days, I like Unix, but back in the 80s, I only tolerated it.

I was 'exiled' to VMS for a couple of years, though a very nice system there was lots more typing on VMS's command line. Anyway I think it was scaling and software that allowed UNIX take over. I had a useful UNIX on a 8086 and software could be found. On VMS just about any useful programs cost $, never mind support costs for using VMS.

I really liked the VMS help system; it was hierarchical and you could start at the top and learn pretty much everything about the system by just navigating the help system. This was far better than man pages (which are mainly references for when you already know what to do).

VMS had early clustering technology, but that got added to TruCluster.

In VMS, revision control was built into the file system. It was easy to retrieve older versions of files. Unix didn't have anything like that until rcs was invented, and even then it was a tool, not something built in like what VMS had.

I wonder what the VCS landscape would have looked like if git was being developed on top of VMS rather than Linux...

filename.c;1 filename.c;2 filename.c;3

git checkout filename.c;2

Brings back memories. If I recall correctly, when you had this turned on, files would get a hidden extension of .1 .2 .3 etc. And you could specify how many revisions to keep around? I also recall on our system, most of the time this was turned off because disk space was so precious. But I do recall this feature saving my bacon a time or two...

Yep! It goes up to 32k by default, but you can limit it:

"The /VERSION_LIMIT qualifier for the CREATE/DIRECTORY, SET DIRECTORY, and SET FILE commands lets you control the number of versions of a file. If you exceed the version limit, the system automatically purges the lowest version file in excess of the limit. For example, if the version limit is 5 and you create the sixth version of a file (ACCOUNTS.DAT;6), the system deletes the first version of the file (ACCOUNTS.DAT;1). To view the version limit on a file, enter the DIRECTORY/FULL command. The version limit is listed in the File attributes: field."

OpenVMS Manual http://h41379.www4.hpe.com/doc/731final/6489/6489pro_006.htm...

I thoroughly enjoyed using DCL (Digital Command Line -- the VMS shell) and VMS (with the wall of documentation, like http://www.pkl.net/~matt/photos/machines/tn/pict0157.jpg.htm...). It always felt structured and orderly, unlike UNIX systems, which are more "organic". :) (I love UNIX too!)

This wasn't unique to VMS. Symbolics Genera had this capability. ITS, VME-B, and I think TOPS-10, also had numbered file versions.

Fair enough. My computing career started in the nineties on VMS at the Help Desk of Brandeis University, my work-study job.

Any idea if it was a full copy of the files, a rolling diff, or a Copy On Write at the block level?

The original MacOS was also supposed to copy this revision capability -- imagine, built in document versioning. Versioning was surfaced in the API but apparently never implemented. Had to always be set to 0 (1? long time ago).

This always caused me to run out of disk space (my quota was 512k).

Filesystem level versioning. TRUE async I/O. Reliability for real workloads. Plus a properly configured VMS cluster has never, ever, been hacked.

this means that back in my teenage years I never encountered a properly configured VMS cluster

cough SYSTEST/SYSTEST cough

It's been a long time since I've used VMS, but one neat feature I recall was sort of a system/group/user concept of environment variables. For example if you set an environment variable at the system level, the new value would immediately be reflected for all users. Powerful concept.

I forgot about that. Was an interesting concept. Question, how can one tell if a UN*X newbee came from VMS ? You get a question from them "How to I change an environment variable for the parent process ?" :) That was allowed in VMS but forgot which type of VMS variable that was.

You are thinking of VMS logicals. Of course they can be used for more than just environment variables! They can also be used to provide an extra level of indirection to filenames. Neat stuff!

It had fixed and variable record based files in addition to regular stream type files. All had built in versioning as well.

Also, fast loosely coupled clusters, with distributed file systems and locking...back in the early 80's.

Reply on news.ycombinator.com