The CMS library directory is created then the library itself is created with the CMS CREATE LIBRARY command.

$ CREATE/DIRECTORY DISK:[PROJ.CMSLIB] $ CMS CREATE LIBRARY DISK:[PROJ.CMSLIB]

5.5.3.3 Security Policy and Implementation

UIC-based protection

Because we will be using OpenVMS ACLs to explicitly grant or deny access to all classes of users, the UIC-based protection is not relevant in most cases because the access control list overrides the UIC-based protection. There are three exceptions to this rule. The UIC-based protection mask is evaluated to determine file access rights if a user in one of the following categories is denied access by the ACL:

• The user has a System group ID
• The user's UIC is the same as the file owner
• The user has file access privileges (BYPASS, READALL, SYSPRV, or GRPPRV)

In the case of a user with BYPASS or READALL privileges, the corresponding file access rights are granted without regard to the file protection mask.

For a more thorough discussion of how file access rights are determined, see Chapter 4 of the OpenVMS Guide to System Security.

Because of these cases where the UIC file protection overrides the access rights specified in the access control list, it is important consider the following when creating the CMS library:

• The CMS library should be owned by either Librarian's UIC or a system UIC.
• If the library is owned by the Librarian, no other user should be assigned the same UIC. (In general, it is not a good idea for multiple users to have the same UIC in any situation.)
• The System field of the UIC protection mask must be changed if it is desired to restrict library access for users with a System UIC group or SYSPRV privilege. Note that users in either class can modify the file protection or the access control list.
• Any library access control mechanism will be overridden by users with the BYPASS privilege.

OpenVMS ACLs

The following example shows how to set the OpenVMS ACLs on the library directory and files. For details of the file access permissions required to execute each of the CMS commands, see Chapter 7 of the Guide to DIGITAL Code Management System for OpenVMS Systems.

• Set the library access ACL

  $ SET SECURITY DISK:[PROJ]CMSLIB.DIR - _$ /ACL=((IDENTIFIER=PROJ_LIBRARIAN, ACCESS=READ+WRITE), - _$ (IDENTIFIER=PROJ_DEVELOPER, ACCESS=READ+WRITE), - _$ (IDENTIFIER=PROJ_USER, ACCESS=READ), - _$ (IDENTIFIER=*, ACCESS=NONE))

• Set the library default ACL (gets propagated to all files created in the library)

  $ SET SECURITY DISK:[PROJ]CMSLIB.DIR - _$ /ACL=((IDENTIFIER=PROJ_LIBRARIAN, OPTIONS=DEFAULT, - _$ ACCESS=READ+WRITE+DELETE),- _$ (IDENTIFIER=PROJ_DEVELOPER, OPTIONS=DEFAULT, - _$ ACCESS=READ+WRITE+DELETE),- _$ (IDENTIFIER=PROJ_USER, OPTIONS=DEFAULT, ACCESS=READ), - _$ (IDENTIFIER=*, OPTIONS=DEFAULT, ACCESS=NONE))

  Note The CMS REPLACE command requires DELETE access to element data files. For this reason PROJ_DEVELOPER is given DELETE access permission in the DEFAULT ACL. Access to the CMS DELETE command will be restricted by use of CMS ACLs.

• Apply the default ACL to the CMS library subdirectories (which contain the element data files):

  $ SET SECURITY DISK:[PROJ.CMSLIB]*.DIR /DEFAULT

• Set the ACLs on the CMS library control files:

  $ SET SECURITY DISK:[PROJ.CMSLIB]*.CMS - _$ /ACL=((IDENTIFIER=PROJ_LIBRARIAN, ACCESS=READ+WRITE), - _$ (IDENTIFIER=PROJ=DEVELOPER, ACCESS=READ+WRITE), - _$ (IDENTIFIER=PROJ_USER, ACCESS=READ), - _$ (IDENTIFIER=*, ACCESS=NONE)) $ SET SECURITY DISK:[PROJ.CMSLIB]*.HIS - _$ /ACL=((IDENTIFIER=PROJ_LIBRARIAN, ACCESS=READ+WRITE+DELETE), - _$ (IDENTIFIER=PROJ=DEVELOPER, ACCESS=READ+WRITE), - _$ (IDENTIFIER=PROJ_USER, ACCESS=READ), - _$ (IDENTIFIER=*, ACCESS=NONE))

CMS ACLs

CMS ACLs are used to provide finer granularity restrictions than are available using the OpenVMS file system access control mechanisms. For our project, we need to restrict the CMS DELETE commands to the project librarian.

$ CMS SET ACL /OBJECT_TYPE=COMMAND - _$ DELETE_ELEMENT, DELETE_CLASS, DELETE_GENERATION, MODIFY_ELEMENT - _$ /ACL=((IDENTIFIER=PROJ_LIBRARIAN, ACCESS=EXECUTE+CONTROL), - _$ (IDENTIFIER=*, ACCESS=NONE))

Section 7.2 of the Guide to DIGITAL Code Management System for OpenVMS Systems contains detailed information about CMS ACLs.

The security configuration of the project CMS library is complete.

5.5.4 CMS and Protected Subsystems

In a protected subsystem, users have no access to the subsystem's objects unless they execute the application serving as a "gatekeeper". For example, for CMS, users have no access to the library and its files outside of CMS. (see Chapter 13 of the OpenVMS Guide to System Security).

The advantage protected subsystems have is that they ensure that protected objects (e.g., files) can be accessed only via the "gatekeeper" application.

The steps below describe how a CMS library may be created as a protected subsystem on an OpenVMS system running Version 6.2 or later:

1. Create the identifier(s) for the subsystem using the subsystem attribute:

   $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER cms_subsystem/ATTRIBUTES=(RESOURCE,SUBSYSTEM) %UAF-I-RDBADDMSG, identifier CMS_SUBSYSTEM value %X8001003E added to rights database UAF> SHOW/IDENTIFIER cms_subsystem Name Value Attributes CMS_SUBSYSTEM %X8001003E RESOURCE SUBSYSTEM

2. If required, grant the subsystem identifier to anyone who will manage the library, allowing them to assign the subsystem identifier to the images comprising the subsystem and access the library files outside of CMS if required.

   UAF>! Grant the librarian access UAF> GRANT/IDENTIFIER CMS_SUBSYSTEM librarian/ATTRIBUTE=(RESOURCE,SUBSYSTEM)

   
   Add the identifier to your rights list and assign the subsystem identifier to the CMS images:

   $ SET RIGHTS_LIST/ENABLE cms_subsystem/ATTRIBUTE=(RESOURCE,SUBSYSTEM) $ ! $ SET SECURITY/ACL=(SUBSYSTEM,ID=cms_subsystem,ATTRIBUTES=RESOURCE) - _$ SYS$SYSTEM:CMS.EXE $ SET SECURITY/ACL=(SUBSYSTEM,ID=cms_subsystem,ATTRIBUTES=RESOURCE) - _$ SYS$SYSTEM:CMS$DW.EXE $ ! $ ! If CMS Client is being used, assign the identifier to the server image $ SET SECURITY/ACL=(SUBSYSTEM,ID=cms_subsystem,ATTRIBUTES=RESOURCE) - _$ SYS$SYSTEM:CMS$SERVER.EXE

3. Create the directories, assign them the identifier, and create the library (the library creation may be performed from any user account):

   $ ! Create the directory $ CREATE/DIR disk$:[protected.secure_lib] $ ! $ ! Assign the identifiers $ SET SECURITY/ACL=( - _$ (ID=cms_subsystem,ACCESS=READ+WRITE+EXECUTE+DELETE), - _$ (ID=*,ACCESS=NONE)) disk$:[000000]protected.DIR $ SET SECURITY/ACL=( - _$ (ID=cms_subsystem,ACCESS=READ+WRITE+EXECUTE+DELETE), - _$ (ID=*,ACCESS=NONE)) disk$:[protected]secure_lib.DIR $ !! $ ! ****** from any (non-privileged account) $ !! $ CMS CREATE LIBRARY disk$:[protected.secure_lib] _Remark: "CMS Library as a Protected Subsystem" %CMS-S-CREATED, CMS Library DISK$:[PROTECTED.SECURE_LIB] created %CMS-I-LIBIS, library is DISK$:[PROTECTED.SECURE_LIB] %CMS-S-LIBSET, library set $ ! $ CREATE test.ele this is just a test $ CMS CREATE ELEMENT test.ele "Testing the library's security" %CMS-S-CREATED, element DISK:[PROTECTED.SECURE_LIB]TEST.ELE created $ DIRECTORY DISK:[PROTECTED.SECURE_LIB] %DIRECT-E-OPENIN, error opening DISK:[PROTECTED.SECURE_LIB]*.*;* as input -RMS-E-PRV, insufficient privilege or file protection violation

Using CMS access control lists entries, you can detect events (CMS operations) and specify actions to be taken when these events occur. Event handling can be used for all operations involving one or more of the following objects:

• All elements (element_list), groups (group_list), or classes (class_list)
• Specific elements, groups, or classes
• History, commands, and library attributes

Once an event has been handled, selected information can be extracted to update a database, notify specified accounts, modify a report, and so on. Appendix B contains two sample programs that further illustrate CMS event handling.

Figure 5-2 provides a flow diagram of how the event handler is activated. The rest of this section describes how the event handler is built and used.

Figure 5-2 CMS Event Handling Flow Diagram

+------------------+ Reservation | | element reserved ----------------> | CMS LIBRARY | -------------------> | | +---------+--------+ | | +---------v--------+ | CMS$EVENT_ACTION | Defines: CMS$EVENT_LIBRARY_SPEC | {user-written | CMS$EVENT_PARAMETER_ID | action image} | CMS$EVENT_HISTORY_RECORD +---------+--------+ | | +---------v--------+ |{executes external| | file to generate | | the report } | +------------------+

The commands below show the event handler being built:

$ CC/NODEBUG cms_event.c $ LINK cms_event/SHAREABLE, SYS$INPUT/OPTIONS SYMBOL_VECTOR=(CMS$EVENT_ACTION=PROCEDURE) ! Alpha only Ctrl/Z

On OpenVMS VAX, the options file would contain UNIVERSAL=CMS$EVENT_ACTION. For the purposes of this example, assume the image has been built in DISK$:[CMS.ALPHA].

The next step is to define the logical names CMS$HANDLER to point to the location of the command file and SYS$SHARE to point to location of the event handler:

$ DEFINE/TABLE=LNM$JOB CMS$HANDLER disk$:[cms] $ DEFINE/TABLE=LNM$JOB SYS$SHARE disk$:[cms.alpha], SYS$LIBRARY

Then assign the access control list:

$ CMS SET LIBRARY disk$:[cms.cmslib] $ CMS SET ACL/OBJECT_TYPE=ELEMENT t.t - _$ /ACL=(ACTION=CMS_EVENT,PARAMETER="my string value",ACCESS=RESERVE+REPLACE) _Remark: "Adding the ACL" %CMS-S-MODACL, modified access control list for element DISK$:[CMS.CMSLIB]T.T $ ! $ CMS SHOW ACL/OBJECT_TYPE=ELEMENT T.T ACLs in CMS Library DISK$:[CMS.CMSLIB] T.T (ACTION=CMS_EVENT,PARAMETER="MY STRING VALUE",IDENTIFIER=*, ACCESS=REPLACE+RESERVE) CMS> EXIT

What happens now when T.T is reserved is illustrated below:

$ CMS RESERVE t.t "this is my remark" An interesting event has occurred: DISK$:[CMS.CMSLIB] 3-AUG-1995 13:36:52.68 TOWNSEND RESERVE T.T(2) this is my remark MY STRING VALUE %CMS-S-RESERVED, generation 2 of element DISK$:[CMS.CMSLIB]T.T reserved

The testing of DECwindows applications using Compaq Digital Test Manager for OpenVMS (DTM) contains many pitfalls. This document identifies some common problems and gives advice on how best to avoid them.

Section 6.1 gives general advice on test organization.

The objective is to build tests which reliably produce the same output, so that the testing does not require manual intervention to conduct the tests or to check the results, and which execute efficiently. Section 6.2 and Section 6.3 discuss ways of achieving this.

When a single workstation is used for both the application under test and to run DTM, it is difficult to prevent DTM output from interfering with the tests. If possible, a second workstation or an alternative should be used to run DTM. This is described in more detail in Section 6.4. If this is not possible, there are ways to reduce the impact, and these are described in Section 6.5. This can also affect how the application to be tested should be started, which is discussed in Section 6.6.

Section 6.7 comments on the use of the Play/Record User Interface.

6.1 Test Organization

Identify a standard screen configuration which will be the start and end screen for all tests. This will include the set of visible windows, their position and which window is currently selected. This configuration will need to be set up before each run of the tests, so needs to be manually reproducible. Tests should tidy up the screen to return it to the original configuration.

Keep tests small, for example by testing one function per test. While it is true that this could result in many tests requiring changes when general, global changes are made to the application, it also makes it less likely that a particular test will be affected by a change. More importantly, when tests fail, it is much easier to find the reason when the test is small.

Some changes to the application to be tested may cause the result to change, in which case the benchmark can be updated. More serious is when the change to the application interferes with the operation of the test, which can result in the test not only failing, but leaving windows on the screen which cause later tests to fail. This is also a consideration when implementing changes to the application, for example, where possible, add to the end of menus.

Keep a record of the purpose, method and actions of each test. This is particularly important if tests need to be rerecorded for some reason, and can help with understanding test failures. The information can be in a separate file, or included as comments in the test session file.

Test session files are simple text files that can be edited with a text editor. For some changes to the application, it may be possible to edit the file rather than rerecording the test. For example, if a button changes position, the coordinates of a button press and release could be changed. See Chapter 9 of the Guide to DIGITAL Test Manager for OpenVMS Systems for more information.

6.2 Making Tests Reproducible

Creating DECwindows tests which pass reliably is difficult. This section points out some of the problems and gives some suggestions as to how do avoid them.

6.2.1 Workstation Options

Most users will configure workstation options to suit their own preferences. However there is a danger that this will cause DTM DECwindows tests to fail if another user runs the tests, or if the user alters options between recording and running the tests.

The best arrangement is to have a separate user account for DTM DECwindows testing, with no options set, and to use this account for recording and running all tests. A few exceptions to this rule are noted below.

Similar considerations apply to any options in the applications which are to be tested or otherwise displayed during testing, for example DECterm options.

If a second display is used to control the testing, then it is the user account that is running the Session Manager on the display under test that these considerations apply to. The display running DTM could be under control of a different account with user-specific options. Note that you will need to set security options on the display under test if you use a different account to run DTM.

The exceptions to using default options are as follows:

• Select Cursor Blink Disable on the KeyBoard Options (accessed from the Options menu on the session manager). If the DECterm application is used, also disable the cursor blink using the Options, Display screen. Similarly disable cursor blink in any other applications to be used.
• If the test does not require interaction with icons, from the Workspace: Icons Options screen, select Display the Icon Box. During testing, minimize all windows which are not part of the test, including the Icon Box window itself.
• Set the Mouse Double Click Timeout value to the highest allowed value. For further information on problems associated with double clicks, see Section 6.2.2.

There is a feature of DTM DECwindows testing associated with double clicks of the mouse. This can result in what was originally a double click being processed as two single clicks when the test is run.

The problem occurs when the first click causes some program action and updating of the screen. For example, in the SCA Cross Reference Results screen, double clicking on a name causes all occurrences of the name to be displayed. However the first click also causes the name to be displayed in inverse video. Any previously selected name is deselected.

The problem occurs when the time taken to switch from DTM to the application, perform the action, update the screen and switch back to DTM exceeds the Mouse Double Click Timeout period. The problem is therefore more likely to occur when DTM is running on the same workstation as the application under test.

The risk of this problem occurring can be reduced by performing a single click first, waiting for the action and screen update, and then performing the double click.

Similar problems can also occur with other multiple click operations, for example triple clicking to highlight a line of text.

6.2.3 Copyright Notices

DECwindows applications normally display a copyright notice in the window title on startup, which is replaced by a normal title on certain actions or after a certain period of time. This change of title can lead to synchronization delays and failed screen comparisons.

Unless the copyright notice is the subject of the test, it is best to trigger the normal message at the start up the test. This can usually be done by clicking on a menu item, then elsewhere to cancel the menu.

6.3 Improving Test Performance

Much of the time to run tests is a reflection of the time the user took thinking what to do next. This time can be reduced by editing the session file to modify the value in the SetDelay record. The value indicates the percentage of the original time to wait, for example a value of 100 means play at the original speed and a value of 20 means reduce user thinking time to one-fifth of the original time.

The actions affected by the SetDelay record are key presses and releases, mouse button presses and releases, mouse movements and screen saves. A value of 5, indicating a reduction to one-twentieth of the original delay that proceeded these actions, has been seen to work well. However it may be necessary to use a higher value if synchronization using text is insufficient for the test to operate correctly, or it may be possible to use a lower value for greater speed. If necessary, the value can be changed dynamically during the test by adding further SetDelay records.

From DTM Version 3.9, all unnecessary mouse movements can be eliminated when a test is recorded in order to further enhance performance when the test is run. This option is controlled with the /POINTER_MOTION qualifier or the Pointer Motion button in the DECwindows interface Record Window. This option is not compatible with applications that respond to mouse movements without button presses.

6.4 Using a Remote Display

The best way of using DTM for DECwindows testing is to employ a second workstation or a PC running eXcursion to control the testing. This prevents the DTM windows from interfering with the testing of the application.

The method for testing on a remote display varies between the DTM commands and between the character cell and DECwindows interfaces to DTM.

For RECORD and PLAY commands, the display to be used can be specified. When using the DTM character cell interface, the display can be specified with the /DISPLAY qualifier. When using the DECwindows interface to DTM, the "Display" field in the Record/Play Window can be used. Note that the string identifying the display should include "::0", for example "WS01::0".

For RUN commands, the DECW$DISPLAY logical name can be defined to the required display. This works well for the character cell interface. However if the DECwindows interface to DTM is used, defining this logical name will also cause the DTM windows to be displayed on the same display, which nullifies the advantage of using a second display.

For SUBMIT commands, the DECW$DISPLAY logical name could be defined in the LOGIN.COM file, or the collection or test prologue files.

A better solution for the RUN and SUBMIT commands, which works for both the character cell and DECwindows interfaces, is to define a global, logical DTM variable called DECW$DISPLAY. For example:

$ DTM CREATE VARIABLE/LOGICAL/GLOBAL DECW$DISPLAY WS01::0 This will cause the logical name DECW$DISPLAY to be defined when collections are run. The default value can be overridden when a collection is created.

6.5 Using DTM on the Display Under Test

When only a single workstation is available for both the application under test and to run DTM, the DTM windows will affect the tests. However there are ways of reducing the impact on the tests. The method depends, to some extent, on whether the character cell interface or the DECwindows interface to DTM is to be used.

DTM outputs informational and other messages when tests are recorded, played and run. If the character cell interface is being used, these messages are output to the DECterm where the DTM command was entered. When the DECwindows interface is in use, a window is created to output the messages. There is a choice as to whether or not to have these windows visible while the tests are running.

If the windows are visible, they will appear in the screensaves, and will need to be masked in order to give successful comparisons. The messages output to these windows during recording, and any text which is redrawn when the window is exposed after being hidden, will become synchronization text for the test. Since the messages output during play or run commands will usually not match those during recording, the test will wait for the timeout period for each synchronization point, which may slow the test down considerably.

One resolution to this problem is to update the session file to remove the synchronization text that does not occur on playback. This can be done automatically by using the PLAY/AUTOSYNC command, or by checking the Auto synchronize box on the DECwindows Play window. Whilst the test is playing, the F9-F key sequence can be used to avoid waiting for the timeout period.

As an alternative, testing can be conducted with the message windows minimized. This has the disadvantage that if errors are reported, the messages are not immediately visible. In addition, it may not be apparent when tests have completed. However these are probably outweighed by the advantage of not needing to mask the windows.

The simplest way of minimizing the message windows is to include the click on the minimize button in the test. From DTM Version 3.9, the window position is fixed and under user control as described in the DTM Release Notes. For earlier versions, the position varied according to the tiling algorithm built into DECterm, so this method would not work.

An alternative is to pause the test, minimize the windows, and resume the test. This can be done using the key sequences F9-A to pause, and F9-B to resume.