When used with DTM, PCA can evaluate the code coverage of your test system. Additionally, you can use the regression tests as performance tests for PCA.

You can also use PCA to analyze programs that are composed of modules written in different languages. Additionally, from PCA you can invoke LSE and have access to all of its features, such as the links to SCA and CMS.

A recurring request from CMS users is for better configuration management support. This chapter attempts to answer these requests by explaining the general philosophy of CMS in regards to configuration management. It also illustrates ways to fulfill various configuration management requirements not directly supported by CMS.

Specifically, this chapter describes the following:

• The Software Configuration Management (SCM) system
• Functions of CMS and its intended role in configuration management
• Useful CMS commands and callable routines for configuration management and how they are used
• Various methods for securing a CMS library and its contents

This description of a Software Configuration Management (SCM) system is based on the Level 2 SCM process area described in the Software Engineering Institute's (SEI) Capability Maturity Model (CMM). See the The Capability Maturity Model: Guidelines for Improving the Software Process (Carnegie Mellon University / Software Engineering Institute (1995) ) .

The following list of requirements is based on the key SCM activities described in the CMM:

• A configuration library system for a software baseline repository providing support for such things as:
  • Multiple control levels of SCM
  • Storage and retrieval of configuration items
  • Sharing and transfer of configuration items
  • Storage and retrieval of archive versions
  • Ensuring the correct creation of products
  • SCM reports
  • Maintenance of the library structure and contents
• Change requests and problem report tracking, recording and reviewing
• Controlled and managed changes to software and its release
• Check in/out procedures that maintain the integrity of the software baseline

While this list is not exhaustive, it does provide a basis for evaluating an SCM tool, or in this case, CMS.

5.2 The Goals of CMS

CMS was not designed to be a standalone SCM system but to be part of such a system. CMS is a code management tool that provides an efficient and reliable system for storing and tracking all changes to a set of files. To this end, the main goal of CMS is to ensure the integrity of the files within a library. It is this library which forms the base of CMS.

Most of the interaction with the library (from the command line, the DECwindows Motif interface, or the CMS Client interface) is performed using public, callable routines. The routines can be used to write an interface to a CMS library. Section 5.4 briefly describes and provides an example of using the callable routines.

Many of the requirements identified for SCM are directly supported by CMS:

• OpenVMS and CMS ACLs may be used to provide multiple control levels (see Section 5.5).
• The library supports storage and retrieval of configuration items.
• CMS, combined with the OpenVMS environment and the other DECset tools, supports the sharing and transfer of configuration items.
• Storage and retrieval of archive versions is provided through generations and classes.
• Correct creation of products can be ensured by using CMS classes and MMS.
• Maintenance of the library structure and contents is supported via the CMS VERIFY REPAIR and RECOVER procedures.
• Check in/out procedures that maintain the integrity of the software baseline are supported through combinations of these features.

Although CMS meets most of the version control and reliability requirements of an SCM system directly, additional effort is required in the areas of SCM reporting, change requests, and problem report tracking.

5.3 Common CMS Commands for Configuration Management

The following sections describe the CMS commands most often used for configuration management.

5.3.1 Generate a CMS History File (SHOW HISTORY)

A record is generated in a library's history file whenever a CMS command alters the state of the library or is entered with a remark.

The SHOW HISTORY command allows you to review the history file and display a chronological list of the transactions performed on a library. It allows you to select the transactions that are displayed through different parameters and qualifiers on the command.

For example, you can display information on a particular transaction (such as REPLACE) on transactions occurring within specified dates, on a particular object (element, class or group), or on any combination of the following:

SHOW HISTORY [object-expression] /BEFORE=date-time and /SINCE=date-time /TRANSACTIONS=(keyword,...) Displays all transaction records generated by a specific command. You can specify the following keywords with this qualifier: ACCEPT FETCH REMOVE ALL INSERT REPLACE CANCEL MARK RESERVE COPY MODIFY REVIEW CREATE REJECT SET DELETE REMARK UNRESERVE VERIFY /UNUSUAL Displays the history records related to unusual occurrences and transactions, such as: o A RESERVE command specifying an element that is already reserved o A concurrent replacement o A VERIFY/RECOVER command o A VERIFY/REPAIR command o A CONVERT LIBRARY command o A REMARK/UNUSUAL command /USER=name Displays all history records generated by a specific user.

5.3.2 Report on a Single Element (DIFFERENCES and ANNOTATE)

In addition to the SHOW HISTORY command, CMS provides the DIFFERENCES and ANNOTATE commands which generate information about changes made to individual elements. ANNOTATE documents the development of an element by creating a line-by-line file listing the changes made in each specified element generation. DIFFERENCES compares files, element generations, or a file and an element generation.

5.3.3 Track File Development (CREATE or MODIFY ELEMENT/REVIEW)

Development status may be maintained and monitored in CMS if schemes are devised to do so. For example, elements may be placed into release or testing classes when ready. As long as these schemes are followed, showing the contents of these classes will reveal the current status of the elements. Changes to elements or classes may also be tracked through the review attribute or notification access control entries (see Section 5.5.5).

Using the CREATE or MODIFY ELEMENT /REVIEW qualifier, you can specify that newly-created generations of elements are marked for review by placing them on a review pending list. If an attempt is made to reserve or fetch a generation under review, CMS displays a message and prompts for confirmation to continue:

CMS> RESERVE test-element "remark" Generation 1 of element TEST-ELEMENT has a review pending Proceed? [Y/N] (N):

These messages are issued for all attempts to access the generation until the review status is resolved. Table 5-1 provides a summary of the review commands, which are available from the command line, DECwindows Motif interface, and callable routines:

Table 5-1 CMS Review Commands

Command	Action
ACCEPT GENERATION	Changes the review status of each specified element generation from "pending" to "accepted" and removes it from the review pending list.
CANCEL REVIEW	Changes the review status of each specified element generation from "pending" to "none" and removes it from the review pending list.
MARK GENERATION	Marks each specified element generation for review and adds it to the review pending list.
REJECT GENERATION	Changes the review status of each specified element generation from "pending" to "rejected" and removes it from the review pending list.
REVIEW GENERATION	Associates a review comment with one or more specified element generations.
SHOW REVIEWS_PENDING	Displays a list of element generations that currently have review pending status.

If a review is accepted or canceled, CMS halts the review-related messages and confirmation on subsequent reservation attempts. If the review is rejected, CMS issues a message that the generation was reviewed and rejected. However, the generation is still accessible so that the problems within it may be corrected:

CMS> FETCH test-element "remark" Generation 1 of element TEST-ELEMENT has been rejected %CMS-S-FETCHED, generation 1 of element TEST-ELEMENT fetched

5.4 CMS Callable Routines

Figure 5-1 shows the relationship between the callable routines, the other components of CMS, and a CMS library.

Figure 5-1 CMS Callable Routines Interfaces

+-------------------+ | CMS Client | +---------^---------+ | +---------V---------+ | CMS Client Server <----+ +-------------------+ | | | +-------------------+ +-------------------+ +----> | +-------------------+ | CMS command-line <---------> | | | +-------------------+ | | | | | Callable Routines <-----> CMS LIBRARY | | | | | +-------------------+ | | | | | CMS DECwindows <---------> | +-------------------+ +-------------------+ +----> | | +-------------------+ | +-------------------+ | | User Program <----+ +-------------------+

The callable routines are described in DIGITAL Code Management System Callable Routines Reference Manual. These routines can be called from the majority of the languages supported on OpenVMS, and the documentation reflects this by having examples in different languages.

In general, there is an entry point into CMS for each command at the DCL level, for example:

• CMS$ANNOTATE for CMS ANNOTATE
• CMS$REVIEW_GENERATION for CMS REVIEW GENERATION
• CMS$SHOW_HISTORY for CMS SHOW HISTORY

The routine CMS$CMS allows calling programs to pass a complete CLI to CMS.

Appendix A contains several programs that demonstrate how the CMS callable routines can be used.

A CMS library is composed of a single directory. This directory, along with the files and subdirectories contained in it, is known as the CMS library directory. This section describes different methods that can be used to control access to a CMS library and its contents.

Access to a CMS library can be controlled by using one or more of the following methods:

• OpenVMS file access controls
• CMS file access control
• OpenVMS protected subsystems (OpenVMS Versions 6.2 and later)

Each of these mechanisms is discussed in more detail below. The rest of this section assumes the reader has a basic understanding of OpenVMS file access control. For detailed information on this topic, see the OpenVMS Guide to System Security.

5.5.1.1 OpenVMS File Access Controls

The OpenVMS file system provides the lowest level of access control to a CMS library. A user cannot perform CMS operations requiring file access if the appropriate permissions have not been granted by the file system. This also means that any user who has sufficient access privileges to modify a CMS library (for example, to create or reserve and replace elements) can also modify the library files without using CMS.

OpenVMS provides the following mechanisms to control file access:

• UIC-based protection
  This is the mechanism most OpenVMS users are familiar with -- the READ, WRITE, EDIT, and DELETE (RWED) file protections. UIC-based protection is simple to manage but does not permit detailed access control. UIC-based protection is often inadequate in situations where multiple users with different library security profiles have the ability to create and replace elements in the library. When an element is created or replaced, a new file is created in the CMS library. The file is owned by the user who performed the operation. This can make it difficult to ensure that all users have the same access rights to all elements without the use of ACLs.
• Access control lists (ACLs)
  An ACL defines the access rights to an object based on the user's identity (UIC) or the rights identifiers granted to the user's process. The access identifiers can be granted to the user in the system RIGHTSLIST database, be assigned by OpenVMS based on a process characteristic (such as, Interactive, Local, Dialup), or can be assigned to a gatekeeper application for a protected subsystem. In the last case, the user process inherits the rights granted to the application only while the application is executing.
  Each ACL consists of one or more access control entries (ACEs). There are several types of ACEs; of note, the Identifier ACE consists of three main components:
  1. Identifier---specifies to whom the ACE applies
  2. Access Rights---the access to be granted or denied to users holding the specified identifier
  3. Options--- provide further information on how the ACE is to be applied
  
  An ACL may have multiple ACEs for a given user. If this is the case, the user's access rights are determined by evaluating each Identifier ACE in order until one is found that matches an identifier held by the user. Once a match is found, the access rights specified in that ACE determine the user's access to that object; no further ACEs will be examined. For this reason the ordering of ACEs in an ACL is very important.
  For more information on OpenVMS ACLs in general, see the OpenVMS Guide to System Security. For information on how OpenVMS file protections interact with CMS commands, see the Guide to DIGITAL Code Management System for OpenVMS Systems.

An OpenVMS user may possess one or more privileges that override file protection settings: BYPASS, READALL, SYSPRV, or GRPPRV. For example, a user with BYPASS privilege has full access to any file on the system regardless of the file protection. A user with READALL privilege can read all files; all other file access rights are determined by the normal file access controls. For more information on OpenVMS privileges and how they affect file access rights, see the OpenVMS Guide to System Security.

5.5.1.2 CMS Access Control

Access to CMS can also be controlled by CMS ACLs. CMS ACLs provide more flexible control of individual CMS commands, CMS library objects (elements, groups, and classes), and objects lists. CMS ACLs refine access granted by OpenVMS file access control mechanisms; they do not override file access restrictions imposed by the OpenVMS file system.

In the absence of CMS ACLs, all users have full access to a library, subject to the file system access controls. If any CMS ACLs are present for a command or object, all access to that command or object is denied unless an access control entry (ACE) specifically granting access is present. This is an important point to remember, as it is easy to inadvertently create conditions where all users are prevented from operating on an object or class of objects.

For example, consider the following situation:

CMS> SET ACL/OBJECT_TYPE=COMMAND CREATE_ELEMENT - _CMS> /ACL=(IDENTIFIER=USER1, ACCESS=EXECUTE+CONTROL) CMS> SET ACL/OBJECT_TYPE=LIBRARY ELEMENT_LIST - _CMS> /ACL=(IDENTIFIER=USER2, ACCESS=CREATE)

The first CMS command gives USER1 access to execute the CREATE ELEMENT command; all other users are implicitly restricted from using this command because there are no ACEs granting any other user EXECUTE permission. Similarly, the second CMS command gives only USER2 access to add element to the library element list.

Creating an element in a CMS library requires access to both the CREATE ELEMENT command and the library element list. In this library, no users have access to both the command and the element list; therefore, no one will be able to create elements in the library.

CMS ACLs are only checked for operations performed by CMS and the CMS callable routines; they have no effect on OpenVMS utilities or user programs that access the library files by any other means.

See the Guide to DIGITAL Code Management System for OpenVMS Systems for a detailed description of CMS ACLs.

5.5.1.3 OpenVMS Protected Subsystems

Protected subsystems provide a mechanism by which the OpenVMS file system restricts access to certain files related to predefined applications. They allow a CMS library to be configured so that it can only be accessed by CMS (or a suitably privileged user).

In a protected subsystem, file access is denied to all users; access is only allowed via a special subsystem identifier. Rather than being granted to users, the subsystem identifier is assigned to executable images. Only the images that have the appropriate subsystem identifier are able to access the controlled files.

Protected subsystems are available on systems running OpenVMS Versions 6.2 and later. For more information on protected subsystems, (cms_prot_subsys) or the OpenVMS Guide to System Security.

5.5.2 Performance Considerations

The use of ACLs provide a great deal of flexibility in configuring the security profile of a CMS library. However, that flexibility comes at some cost. Large access control lists can be expensive in terms of disk storage space and execution speed.

Each ACE occupies disk space in the file header for OpenVMS ACLs and in the CMS library control files for CMS ACLs. When large ACLs are applied to many objects, the cumulative storage requirements can be significant.

Each time an object with an ACL is referenced, each ACE in the list must be compared to the identifiers held by the user until either a match is found or all of the ACEs in the list have been checked. This can be a very time consuming process when the ACLs are very long and/or the checks are performed frequently.

It many cases it may be possible to improve the performance of CMS library access by adhering to following guidelines:

• Keep ACLs as short as possible. If there are many users who have the same access rights, use a rights identifier to identify sets of users rather than creating an ACE for each user.
• Whenever possible, place CMS ACLs on commands rather than on individual objects. When a command is executed on multiple objects (e.g., FETCH *.*), a command ACL is checked once; the object ACLs must be checked once for each object accessed.
• Order ACEs so that the most heavily used are closest to the top of the ACL. This reduces the number of lookups in the most frequent cases. For example, the ACE for a project builder would be before that of a developer, which would be before that of an occasional reader.
  The order of ACEs in an ACL also has security implications that must be considered ahead of the performance implications. In general, ACEs should be specified in the following order:
  • ACEs giving access to critical users belong at the top of the list.
  • ACEs giving specific access to smaller groups belong before ACEs giving access to larger groups.
  • ACEs giving more access rights belong before ACEs giving fewer access rights, unless you mean to selectively deny access.
  
  More information on ACE ordering can be found in the OpenVMS Guide to System Security. The same principles apply to the ordering of ACEs in CMS.

  Notes The default behavior of both the OpenVMS SET ACL command and the CMS SET ACL command is to add an ACE to the beginning of an existing ACL. If this is not the desired behavior, the position of the ACE can be specified using the /AFTER qualifier (for OpenVMS and CMS) or the /BEFORE qualifier (for OpenVMS only). Adding an OpenVMS ACL to existing files within a CMS library will update the file headers. This causes CMS to generate "File not closed by CMS" error messages. Once the ACLs have been added, run VERIFY/REPAIR on the library to eliminate the "not closed by CMS" messages on the files.

• Consider using a protected subsystem instead of large OpenVMS ACLs.
  If your security policy requires large OpenVMS ACLs, consider using a protected subsystem where the user access ACLs are applied to the CMS executable images rather than to each file in the CMS library. The overhead for the ACL check is once per image activation rather than once per file access. To minimize the overhead, multiple CMS commands should be issued from within CMS rather than on separate DCL command line.