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

Background

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

CMS overview

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:

• It is carefully designed and comprehensively documented^{[1] [2]};
• It has a clear and consistent command set^[3];
• It has full ACL-based security^[2];
• Its full functionality is available through a documented API^[4].

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.

Comments

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

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:

7-FEB-1984 16:26:08 UFAA220 CREATE LIBRARY [.FRMATPL]
"For transfer of source from ULCC UPDATE OLDPL necessary
 because of demise of CDC machines."

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.

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

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.

References

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