This section shows how to setup a CMS library for a project where different classes of users have different access privileges to a library and its contents. A combination of OpenVMS ACLs and CMS ACLs are used to control access.

5.5.3.1 Access Policy

For this project there are four classes of users with regard to CMS library access:

• Librarian, has complete access to the library and all CMS commands
• Developer, full access except for the DELETE commands
• User, read-only access to the library
• All others, no access

The users in each class are identified by means of OpenVMS rights identifiers. The following rights identifiers are used in this example:

• PROJ_LIBRARIAN
• PROJ_DEVELOPER
• PROJ_USER

The following commands can be used to create these rights identifiers and assign them to users:

$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER PROJ_LIBRARIAN UAF> ADD/IDENTIFIER PROJ_DEVELOPER UAF> ADD/IDENTIFIER PROJ_USER UAF> GRANT/IDENTIFIER PROJ_LIBRARIAN librarian UAF> GRANT/IDENTIFIER PROJ_DEVELOPER devo1 UAF> GRANT/IDENTIFIER PROJ_DEVELOPER devo2 UAF> GRANT/IDENTIFIER PROJ_USER user1 UAF> EXIT

5.5.3.2 Library Creation

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 OpenVMS ACLs are used to grant or deny access to different classes of users, UIC-based protection is not particularly relevant. In most cases, the ACL overrides the UIC-based protection; however, 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 regardless of the file protection mask.

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

Since the UIC file protection can potentially override the access rights specified in an ACL, 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 you need to restrict library access to users with a System UIC group or SYSPRV privilege. Note that users in either class can modify the file protection or the ACL.
• Any library access control mechanism will be overridden by users with the BYPASS privilege.

OpenVMS ACLs

The following example shows how to set OpenVMS ACLs on library directory and files. For details of the file access permissions required for each of the CMS commands, see 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 more granular 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))

The security configuration of the project CMS library is complete. See the Guide to DIGITAL Code Management System for OpenVMS Systems for detailed information about CMS ACLs.

5.5.4 Implementing a CMS Library as a Protected Subsystem

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

The following steps describe how a CMS library can be created as a protected subsystem.

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 ACEs, 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 on an OpenVMS Alpha or OpenVMS I64 system:

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

On an OpenVMS VAX system, 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 ACL:

$ 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

Testing DECwindows Motif applications using the Digital Test Manager for OpenVMS (DTM) contains many pitfalls. This chapter identifies some common problems and gives advice on how best to avoid them.

The objective of DTM is to build a test suite that does not require manual intervention, runs efficiently, and reliably produces the same output. Section 6.1 gives general advice on test organization. Section 6.2 and Section 6.3 discuss ways of reproducing reliable test results and optimizing performance.

When a single system is used to run DTM and test the application, it is difficult to prevent DTM output from interfering with the tests. If possible, DTM should be run from a display other than the test display, as described in Section 6.4. If this is not possible, there are ways to reduce the impact of DTM output. Section 6.5 describes how to configure DTM to run on a single system when the option of running the application on two displays is unavailable.

Section 6.6 and Section 6.7 describe how to start the application to be tested and discuss the use of the Play/Record User Interface.

6.1 Test Organization

Use the following guidelines when designing a DTM test suite:

• Identify a standard screen configuration.
  This will be used for the starting and ending screen state for all tests. Determining a standard configuration includes identifying the:
  • Set of visible windows
  • Position of each window
  • Window currently in focus
  
  This screen configuration will need to be setup before the start of the test suite, so it must be reproducible manually. After completion, the tests should tidy up the screen to return it to the original configuration.
• Keep tests small.
  Try to analyze only one function per test. Although this could result in a large suite of many detailed tests, it also makes it less likely that a particular test will be affected by a change in the application. More importantly, when a test fails, finding the cause is quicker and easier when the test is only comprised of a few functions.
• Consider how application changes may impact test results and operation.
  Application changes may not only require benchmarks to be updated. Functional or design changes can also interferes with the operation of the test. This can result in the test not only failing, but leaving windows on the screen which cause later tests to fail. Keep test design in mind when updating an application. For example, when making changes to a menu interface, add new commands to the end of menus, where possible.
• 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 the Guide to DIGITAL Test Manager for OpenVMS Systems for more information on test organization.

6.2 Creating Reproducible Tests

Creating DECwindows Motif tests that succeed reliably is difficult due to the many variables involved. This section presents some important points to consider when creating tests and provides suggestions on increasing successful test reproduction.

6.2.1 Configuring System Options

Most users will configure system options to suit their own preferences. However, in some cases, this can cause DTM DECwindows Motif tests to fail if another user runs the tests, or if the user alters options between recording and running the tests. Similar considerations apply to configuring any options in the applications to be tested or otherwise displayed during testing, such as DECterm options.

The best arrangement is to establish a separate, generic user account for DTM DECwindows Motif testing that uses the default options. This account can then be used to record and run all tests. If DTM is run from a second display device, the other display running the DTM test should be using a DTM account with generic options. Otherwise you may need to configure the account and set security options.

Note, however, there are a few exceptions to using the default options. You should make the following minimal changes to optimize the display for testing purposes:

• Disable cursor blinking.
  Select Cursor Blink Disable on the KeyBoard Options dialog box (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.
• Minimize all windows.
  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.
• Increase double-click timeout value.
  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 Motif 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 a program action that updates the screen. In some cases, 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 system as the application under test.

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

To prevent this problem from occurring, perform a single-click first, wait for the action and screen update to occur, and then perform the double-click.

6.2.3 Hiding Copyright Notices

DECwindows Motif 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 by clicking on the desktop outside the menu to cancel the menu action.

6.3 Improving Test Performance

Much of the time spent running tests is actually a reflection of the time spent by users deciding which action to perform next. This time can be reduced by editing the session file and modifying the value in the SetDelay record. This value indicates the percentage of the original time to wait. For example, a value of 100 means play all tests at the original speed, and a value of 20 means reduce the think 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 often works well, which represents a reduction to one-twentieth of the original delay. However, you may need to use a higher value if text synchronization is insufficient for the test to operate correctly. Or, you may need to use a lower value for greater speed. If necessary, the value can be changed dynamically during the test by adding further SetDelay records.

On systems running DTM Version 3.9 or later, you can further enhance performance by eliminating all unnecessary mouse movements when a test is run. This option is controlled on the command line using the /POINTER_MOTION qualifier or from the DECwindows Motif interface using the Pointer Motion button on the Record window. Note that this option is not compatible with applications that respond to mouse movements without button presses.

6.4 Using an Alternate Display for Testing

The best way of using DTM for DECwindows Motif 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 an alternate display varies between the DTM commands and between the character cell and DECwindows Motif interfaces to DTM.

For RECORD and PLAY commands, you can directly specify the display to be used. When using the DTM character cell interface, specify the display using the /DISPLAY qualifier. When using the DECwindows Motif interface to DTM, use the Display field in the Record/Play window. Note that the string identifying the display should include the value ::0, for example, WS01::0.

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

For SUBMIT commands, you can define the DECW$DISPLAY logical name in either 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 causes the logical name DECW$DISPLAY to be defined when collections are run. The default value can be overridden when a collection is created.