This introduces CMS, the second SCM system I used. Readership is public.


It is the early 1980s. I am working at Queen Elizabeth College with a Modular One. The Physics department has a VAX-11/780 and the Computer Unit Modular One is being replaced by a VAX-11/750, which I will manage. At ULCC, the CDC systems are about to be replaced by an Amdahl machine. To me, that is quite beyond the pale and I will have no truck with it. But Digital, VAXen and VMS are inspiring and hold a lot of promise for my future computing enjoyment. They are to be as influential to me as CDC had been before.

I need to change my SCM focus and a friendly Digital person introduces me to CMS.

CMS overview

Image of a CMS manual spine insert
This is my first encounter with something a lot closer to what we might today recognise as SCM software. CMS maintains entities called libraries which are equivalent to a Repository in current systems. Libraries contain elements, which essentially are versioned files. One can FETCH a generation of an element to use the file or RESERVE it to make changes and then REPLACE it to return any changes to the element and create a new generation of it.

Other metadata in the library include named groups to help you refer to a set of elements and classes, which are similar in purpose to the Labels of current systems.

CMS has the usual features of a VMS application:

CMS is fully usable from its command interface, but when DECwindows emerged, it acquired a nice graphical interface too. In addition to the GUI features, the command interface remained integrated, so that one could enter a CMS command and see the results in windows where appropriate. It still strikes me that many modern applications could benefit from this hybrid approach to interfaces. Nowadays, the two interfaces tend to be treated separately, assuming your application designer has bothered to expose a scriptable interface at all.

Interesting features

CMS events
CMS ACLs not only contain ACEs to control access, they may also define CMS events. Thus, whenever a CMS object is accessed, it is possible to trigger an action to be performed. These actions may be user written software. This allows a CMS library to be endowed with extra behaviours as part of its function. For example, replacing elements in a library might be used to trigger an automatic build.
CMS review
CMS elements can be marked for review and there are commands specifically aimed at supporting a review process. This is a feature that seems ahead of its time. Nowadays, review processes tend to be supported through integrations of an SCM system with other software. That's now the right architectural choice. But back then, I wasn't aware of anything that automated the sort of software production workflows we see today.
Internal model
Like UPDATE, CMS objects are not a full reflection of an external filing system. CMS elements do come from files and are exported as files, but the workspace is flat, without a mapped directory structure. This is not dissimilar to other SCM systems that were around at the time, but seems limited today.
Branching and merging
CMS supports branching and merging, but refers to branches as variant lines of descent.
DECnet access
CMS library access is not supported over DECnet. If you try it, you'll get -CMS-E-NETNOTALL, network access not allowed. At the time, I don't recall worrying about that - I tended to work with clusters. But in today's heterogeneous computing world the limitation seems surprising.
CMS allows comments to be stored for any library-changing action, not just "Checkins". This makes it easier to communicate your intentions to other users of the library.

CMS has an option to insert the entire CMS history of an element as a comment stream in that element. That's a feature I would like to see in my current SCM system.

CMS use, then and now

It wasn't long before everything I was working on under VMS would be committed to a CMS library.

At least, that's how I remember it. For many years, I have adhered to the discipline of "Version everything", well before Perforce made that a catchphrase. But the evidence of the history in my own CMS libraries suggests that this was a slow process to start with. The earliest CMS comment I can find is this:

"For transfer of source from ULCC UPDATE OLDPL necessary
 because of demise of CDC machines."
but I didn't create an element for my own LOGIN.COM until 22-AUG-1986! These days, I get nervous about anything I change that isn't hosted in SCM and I can't imagine how I survived for so long without managing my LOGIN.COM that way.

In 1985, I left the academic community and went to work for BP Exploration. I had been seduced by a large hall packed full of VAXen and a seemingly limitless budget for more, together with the planned arrival of a Cray-XMP. BPX were as near to the leading edge of a large-systems Digital customer as I was ever going to get.

Managing all these clusters reliably and coherently was a challenge and I introduced the use of CMS to manage all the system command procedures that were locally modified.

Something that CMS has in common with today's DVCS repositories is that a typical CMS library represents just a subset of the versioned material in an enterprise. In writing this article I'm examining a number of CMS libraries together to find evidence of what really went on, compared with my unreliable memories of the past. This is a programming opportunity for the future - my retrochallenge clock is ticking too fast right now. So at present, I'm not sure exactly when all of the system procedures moved into CMS and it probably wasn't as quickly as my memory indicates. I do remember giving a workshop about it at a UK DECUS symposium, which may have been in April 1989 at Exeter.

Image of a TK50
One of my TK50 archives.
I left BPX in 1992. I had usernames in various VAXen in odd places which I used to play with for sanity's sake, but I was sadly leaving VMS behind as part of my working life. My CMS libraries were stored on magnetic tape - mostly TK50s which I kept for years in the hope that one day I would retrieve the data. In 2013, through fortunate contact with DEC Legacy and the kind efforts of Matthew Burke I got the data back from those TK50s.

Now I can pick up from where I left off. I run SIMH systems and a few actual small VAXen and my goal is to integrate them fully into my current computing framework. For SCM, I shall continue to use CMS in this context, though I will also engineer client software to access my Perforce repository from VMS.

CMS now

How does CMS compare to current SCM systems? Broadly speaking, it is similar to many of the older systems that provided something of modular rather than enterprise-wide scope. The sort that weren't servers but tend to store SCM metadata in a dedicated filing system directory, which is what CMS does. But it is more powerful than many of those because of its programmability at all levels and its built in security.

However, CMS would need to evolve somewhat to scale to the demands of a modern software development enterprise. I would be interested to know what VMS engineering used for SCM. Whether it should evolve into a client-server system or a DVCS is an interesting topic for speculation.


[1] HP DECset Version 12.8 Documentation
CMS is part of a set of products called DECset. The "Set" stands for "Software Engineering Tools". Other products in the set include a Test Manager, a Module Management System, Performance and source code analysers and a Language-sensitive editor.
[2] Guide to the Code Management System (PDF at HP)
This gives a very good overview of CMS and its capabilities.
[3] Code Management System Reference Manual (PDF at HP)
The CMS command interface and related material.
[4] Code Management System Callable Routines Reference Manual (PDF at HP)
Documentation for the CMS API.


This document is maintained by Pute. Comments should be addressed to PNJ at XQWV dot ORG dot UK.
  1. PNJ, 2014-07-24. Original version.
  2. PNJ, 2014-07-28. More detailed description.
  3. PNJ, 2014-07-29. More narrative and images.

Any text you see at this point onwards is the result of the style sheet used by this document being inaccessible or corrupt. The document content above is usable but probably renders less elegantly than the author intended.