VMS memories

It's been twenty years since I used it, but I still have fond memories of the first real operating system I got to use. When I started in my first paid job, back at the start of 1982 I accessed the VAX computers at work via a physical VT100 – the console that modern command-line windows all emulate, with varying degrees of added fanciness. This gave me twenty-five glorious lines of text, each 80 characters long. I interacted with the computer it was connected to by typing commands in DCL – the Digital command language; the VAX was manufactured by a company called Digital, since swallowed up by Compaq. DCL ran on top of the operating system, VMS (I suspect that stands for virtual memory system) so I was officially using DCL/VMS. I normally just think of this as VMS (of which a modern free version is available as OpenVMS) but most of the neat features were really in DCL. It was actually a really good system, with some features I sorely miss to this day – most especially the help command.

Help

If you were sat in front of a console (that is, a screen and a keyboard – there was no mouse yet) and you didn't know what to do, the obvious thing to do was to type help – and, if nothing happened, try hitting the enter key to get it listened to. Try that on your nice shiny modern computer – good luck with that. On DCL it actually gave you help – real, straightforward, this is helpful help. It didn't assume you knew pretty much everything and just wanted to be reminded of some details. It started from the basics and worked its way up – yet it did so without encumbering the experienced user with wading through needless pages of stuff they already knew. The command starts up the help application, which was really well thought out. Remember I said you only get 25 lines and 80 characters on each ? It knew that, and it worked hard to (mostly) not need more; I really think this was a great feature – it forces the help author to deliver help in manageable chunks that the poor clueless user can actually digest one at a time.

To make that possible, it was in fact making you navigate a hierarchy of nodes, each of which comprised a chunk of expository text providing that node's information plus a bunch of words you could type next to get to subordinate nodes giving more information on parts of the topic, or on related topics; or you could just hit return, without typing anything, to back out to the node's parent. Not that it made you think like you were navigating a hierarchy of nodes: it just was doing that, and had a UI that made it so natural you didn't need to think about it. When you first typed help it gave you about half a screen explaining how the help application worked followed by half a screen of possible topics, identified by keywords that the user was actually likely to recognise if they were what the user wanted to know about. Each of those would give high-level details on its topic and a list of sub-topics from which to learn more; and each of those did likewise, until you drilled down to the actual information you were after.

This wonderfully simple approach (which, with hind-sight, must have had some pretty serious editorial work behind it) to help meant that it was actually possible to learn the system. I didn't need a training course, I just needed access to the computer.

Versioning

The full name of a file looked (unless my memory tricks me) something like this: [root:sub.directory.name]filename.ext;123 and you usually didn't bother with the bit in square brackets, […] because you'd already typed cd root:sub.directory.name to set that as your working directory.

You also didn't usually bother with the ;123 version number; you just typed filename.ext and the system used the highest-numbered version of that available. If what you were doing changed the file, the program actually created a new file with a version number one higher, filename.ext;124 in this example. This meant that you retained old versions of your file, which was great for recovering from your stupid mistakes. Every now and again, it was time to run a command (I suspect its name was purge but it might have been clean or some other approximate synonym) to throw away older versions (it probably had options to specify how many versions of each file to keep, which files to apply to and so on). Just make sure you've got working versions of everything before you do that, because you're losing your back-ups.

This was way better than just having a single-backup system (many programs on modern systems will save filename.ext.bak or filename.ext~ or similar if you modify filename.ext, but that only lets you recover from your most recent mistake), although you did have to watch out to not fill the disk with redundant old copies.

Virtual mount-points

In the file-name above, the directory started with root: and there was some magic there, too. The name given here could be a drive name (rather like the drive letters in DOS), in which case root:sub.directory.name referred to a real physical directory (or folder, if you're more used to the desktop metaphor) called name, that was a sub-directory of directory which was, itself, a sub-directory of sub. All nice and simple.

However, you could also define a virtual mount-point; you could associate a name (I forget the exact syntax) with a sequence of directories (which could, themselves, use virtual mount-points); if root was such a name, then [root:sub] referred to the sub-directory sub of each of the directories named in root. Likewise, [root:sub.directory.name] referred to the relevant sub-directories of those; and [root:sub.directory.name]filename.ext referred to the highest-numbered file of the given name in the first of these directories that actually contained a file of that name. (Note that later directories in the list would be ignored regardless of how high their version number might be.) When you save a file, it gets saved in the first-named directory, even if you created it by editing a file that didn't exist there previously.

Let's look at a simple example, to see how powerful that is. Say there's some program a colleague has written, in a bunch of source files spread out in a directory hierarchy under some directory of hers. I chose a working directory in my file-space and make a root that refers to my working directory, then to the top-level directory under which she's keeping her program and the scripts that build it from its sources. Now I can edit any of her files I like; the editor saves the results in my file-space but all commands see all of her files, except for the ones hidden by my edited local copies. So I can make my changes and build my own version of her program – without having to copy any of the files I haven't changed. Then I can tell her where my changes are and ask her to integrate them back into her version. Before she does that, she wants to check my changes are good, of course; but she can do the same as I did, using a virtual mount-point to reference a scratch directory, then my working directory, then hers; she can build her program that way to get my version and try it out. If she's satisfied it's good, she can copy over my changed versions into her own.

You can do that to any depth. Suppose you're working on a product built from lots and lots of source files spread throughout a big file hierarchy, but your team is only working on one chunk of that, and you're only working on part of your team's chunk. Let's suppose the definitive source tree has some form of quality control on it, that ensures changes aren't integrated until they've been tested and found to be good. So there's also a general development source tree that contains changes from all teams, that are waiting for integration. When your team completes a task, it copies its work up to that for the integrator to test and copy over to the definitive version. Your team also has an area in which you all collect together your parts of what you're working on; and each member of the team has their own working area. Notice that each of these source trees, aside from the definitive one, only contains such files as are changed, in it, relative to the definitive one. So you make a virtual mount-point out of all of those – first your own work area, then the team area, then the general development area, finally the definitive source tree – and get on with your work. If what you're working on depends on some colleague's on-going work, you can throw in his working directory. If some other team breaks everything by merging up their work to the general development staging area, you can take that out of your virtual mount point and carry on working while they sort out their mistake; put it back once they have.

The combination of DCL/VMS's automatic versioning and mount-points made it easy to do things that require a distributed version control system on modern computers. (There are also ways to do the virtual mount-point trick on modern Linux file-systems, with copy-on-write semantics to ensure your changes are always local to the front directory of the stack.)

Epilogue

DCL/VMS only ever existed on Digital's computers, until OpenVMS came along, so it didn't spend the seventies and eighties having additional software written for it by others. It had plenty of applications written for it, to be sure, but it never had the commodity software industry that made DOS (and hence MS-Windows) such a success or the hacker community that enabled Unix to flourish behind corporate locked doors, ready to blossom once its free versions became available. Maybe OpenVMS will get that; but it has a lot of catching up to do.

By 1990, VMS had grown a graphical user interface that looked like everyone else's, more or less; but around the same time I was given a course in Unix (actually, as it happens, Xenix to begin with) and shortly afterwards got a job in which I moved to SunOS (now Solaris), a dialect of Unix. After a decade of mostly SunOS/Solaris (with stray doses of other Unix variants – AIX and HP-UX spring to mind) I was able to switch to Linux (which I'd been using at home for several years, by the time I switched at work), a free dialect of Unix. I never find time to play with OpenVMS but I still have fond memories of the system I used to use.


Valid CSSValid HTML 4.01 Written by Eddy.