Document revision date: 19 July 1999

Ordinarily, the system turns on auditing in VMS$LPBEGIN just before SYSTARTUP_VMS.COM executes. You can change this behavior, however, by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.

To change the point at which the operating system begins to deliver security-event messages, add the following line to the SYS$MANAGER:SYLOGICALS.COM command procedure:

$ DEFINE/SYSTEM/EXECUTIVE SYS$AUDIT_SERVER_INHIBIT YES

You can initiate auditing during another phase of system startup, perhaps at the end of SYSTARTUP_VMS.COM, by editing the command file to add the following line:

$ SET AUDIT/SERVER=INITIATE

For information about editing SYSTARTUP_VMS.COM, see Section 5.2.7.

18.7.4 Enabling Security Auditing for Additional Classes

To enable security auditing for classes in addition to those shown in Table 18-6, use the following format:

SET AUDIT/ENABLE=keyword[,...] {/ALARM | /AUDIT}

The OpenVMS Guide to System Security contains descriptions of event classes that you can enable.

When you enable auditing for additional event classes, you must specify two qualifiers:

1. /ENABLE
2. Either /ALARM or /AUDIT (Although you must specify one qualifier, you can specify both.)

The following table contains explanations of the /ENABLE, /ALARM, and /AUDIT qualifiers.

Qualifier	Explanation
/ENABLE	Defines which event classes you want audited. See Chapter 19 for more information.
/ALARM /AUDIT	Defines the destination of the event message. /ALARM directs the message to all enabled security operator terminals. /AUDIT directs the message to the security audit log file. Use the /ALARM and /AUDIT qualifiers to report critical events. Less critical events can be written only to the security audit log file for later examination. The default event classes listed in Table 18-6 are sent as both alarms and audits.

The system begins auditing new events on all nodes as soon as you enable them.

Examples

1. The command in the following example enables auditing for volume mounts and dismounts and sends messages to the security audit log file.

   $ SET AUDIT/ENABLE=MOUNT/AUDIT

2. The command in the following example enables auditing of unsuccessful file accesses and sends messages to all enabled security operator terminals as well as to the security audit log file.

   $ SET AUDIT/ALARM/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE

The system continues auditing until you explicitly disable the classes with the /DISABLE qualifier using the following syntax:

SET AUDIT/DISABLE=keyword[,...] {/ALARM | /AUDIT}

18.7.6 Enabling a Terminal to Receive Alarm Messages

The system sends alarm messages to terminals enabled for security class messages. Security alarm messages are not written to the operator log file. They appear only on terminals enabled for security class messages.

In most cases, security alarm messages appear on the system console by default. Since messages scroll quickly off the screen, it is good practice to enable a separate terminal for security class messages and disable message delivery to the system console.

Either choose a terminal in a secure location that provides hardcopy output, or have dedicated staff to monitor the security operator terminal. You can enable any number of terminals as security operators.

To set up a terminal to receive security class alarms, enter the following DCL command from the designated terminal:

$ REPLY/ENABLE=SECURITY

Example

The following example shows a security alarm message:

%%%%%%%%%%% OPCOM 25-MAY-1998 16:07:09.20 %%%%%%%%%%% Message from user AUDIT$SERVER on GILMORE Security alarm (SECURITY) on GILMORE, system id: 20300 Auditable event: Process suspended ($SUSPND) Event time: 25-MAY-1998 16:07:08.77 PID: 30C00119 Process name: Hobbit Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTA1: Image name: $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE Status: %SYSTEM-S-NORMAL, normal successful completion Target PID: 30C00126 Target process name: SMISERVER Target username: SYSTEM Target process owner: [SYSTEM]

18.7.7 Generating Security Reports

The most common type of report to generate is a brief, daily listing of events. You can create a command procedure that runs in a batch job every evening before midnight to generate a report of the day's security event messages and send it to the system manager via Mail.

The following example shows the ANALYZE/AUDIT command line you would use to generate this type of report:

$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31JAN1998.AUDIT - _$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL $ MAIL/SUBJECT="Security Events" 31JAN1998.AUDIT SYSTEM

18.7.8 Creating a New Version of the Security Audit Log File

Because the security audit log file continues to grow until you take action, you must devise a plan for maintaining it.

Use the SET AUDIT command to create a new version of the clusterwide security audit log file. To prevent the loss of audit messages, the previous version of the audit log file is not closed until all audit messages stored in memory are written to the file.

18.7.8.1 Creating a New Clusterwide Version of the Log File

To open a new, clusterwide version of the security audit log file, use the following command:

$ SET AUDIT/SERVER=NEW_LOG

The audit server process opens a new version of the audit log file on each cluster node.

After you open the new log, rename the old version, using a naming convention for your files that incorporates in the file name a beginning or ending date for the data. Then copy the file to another disk, delete the log from the system disk to save space, and run the Audit Analysis utility on the old log.

By archiving this file, you maintain a clusterwide history of auditing messages. If you ever discover a security threat on the system, you can analyze the archived log files for a trail of suspicious user activity during a specified period of time.

18.7.8.2 Creating a New Node-Specific Version of the Log File

In some cases, OpenVMS Cluster nodes might not share the same system security audit log file. To create a new, node-specific version of the security audit log file, use the following commands:

$ SET AUDIT/DESTINATION=filespec $ SET AUDIT/SERVER=NEW_LOG

where filespec is a logical name that points to a node-specific file; for example, SYS$SPECIFIC:[SYSMGR]SECURITY. System security audit log files on other nodes are unaffected.

18.8 Monitoring Operating System Performance

The Monitor utility (MONITOR) is a system management tool that you can use to obtain information about operating system performance. Various MONITOR qualifiers collect system performance data from the running system or play back data recorded previously in a recording file. When you play back data, you can display it, summarize it, and even rerecord it to reduce the amount of data in the recording file.

Following an explanation of the Monitor utility are sections that tell how to perform these tasks:

Task	Section
Invoking the Monitor utility	Section 18.8.2
Using live display monitoring	Section 18.8.3
Using live recording monitoring	Section 18.8.4
Using concurrent display and recording monitoring	Section 18.8.5
Using playback monitoring	Section 18.8.6
Using remote playback monitoring	Section 18.8.7
Rerecording monitoring	Section 18.8.8
Running MONITOR continuously	Section 18.8.9
Using remote monitoring	Section 18.8.10

For additional information about interpreting the information the Monitor utility provides, refer to the OpenVMS Performance Management. For additional information about using the Monitor utility, refer to the OpenVMS System Management Utilities Reference Manual.

18.8.1 Understanding MONITOR

Using MONITOR, you can monitor classes of systemwide performance data (such as system I/O statistics, page management statistics, and time spent in each of the processor modes) at specifiable intervals, and produce several types of output. You can also develop a database of performance information for your system by running MONITOR continuously as a background process, as explained in Section 18.8.9.

18.8.1.1 MONITOR Classes

Each MONITOR class consists of data items that, taken together, provide a statistical measure of a particular system performance category. The data items defined for individual classes are listed in the description of the MONITOR command in the OpenVMS System Management Utilities Reference Manual.

To monitor a particular class of information, specify a class name on the MONITOR command line. The information MONITOR displays depends on the type of class you select. Table 18-7 compares the two MONITOR class types.

Table 18-7 Types of MONITOR Classes

Type of class	Description
System	Provides statistics on resource use for the entire system
Component	Provides statistics on the contribution of individual components to the overall system or cluster

As an example of the distinction between types of MONITOR classes, the IO class includes a data item to measure all direct I/O operations for the entire system, and is therefore a system class. The DISK class measures direct I/O operations for individual disks, and is therefore a component class.

Table 18-8 describes each MONITOR class and indicates whether it is a system or component class.

Table 18-8 MONITOR Classes

Class	Type	Description
ALL_CLASSES	System or Component	Statistics for all classes
CLUSTER	System	Clusterwide performance statistics
DECNET	System	DECnet for OpenVMS statistics
DISK	Component	Disk I/O statistics
DLOCK	System	Distributed lock management statistics
FCP	System	File control primitive statistics
FILE_SYSTEM_CACHE	System	File system cache statistics
IO	System	System I/O statistics
LOCK	System	Lock management statistics
MODES	Component	Time spent in each of the processor modes
MSCP_SERVER	System	MSCP server statistics
PAGE	System	Page management statistics
PROCESSES	Component	Statistics on all processes
RMS	Component	Record Management Services statistics
SCS	Component	System Communications Services statistics
STATES	System	Number of processes in each of the scheduler states
SYSTEM	System	Summary of statistics from other classes
TRANSACTION	System	DECdtm services statistics
+VBS	System	Virtual balance slot statistics
VECTOR	System	Vector processor scheduled usage

Except in the PROCESSES class, all data item statistics are displayed as rates or levels:

• Rates are shown in number of occurrences per second.
• Levels are values that indicate the size of the monitored data item.

You can request any or all of four different statistics for each data item:

Statistic	Description
Current rate or level	Most recently collected value for the rate or level
Average rate or level	Measured from the beginning of the MONITOR request
Minimum rate or level	Measured from the beginning of the MONITOR request
Maximum rate or level	Measured from the beginning of the MONITOR request

For the DISK, MODES, SCS, and STATES classes, you can optionally express all statistics as percentages.

In the PROCESSES class, MONITOR displays descriptive information, level information, and counters that increase over time.

18.8.1.3 Output Types

MONITOR collects system performance data by class and produces three forms of optional output, depending on the qualifier you specify:

Qualifier	Description
/DISPLAY	Produces output in the form of ASCII screen images, which are written at a frequency governed by the /VIEWING_TIME qualifier.
/RECORD	Produces a binary recording file containing data collected for requested classes; one record for each class is written per interval.
/SUMMARY	Produces an ASCII file containing summary statistics for all requested classes over the duration of the MONITOR request.

If you specify /INPUT with any of these qualifiers, MONITOR collects performance data from one or more previously created recording files; otherwise, data is collected from counters and data structures on the running system.

You use the /BEGINNING and /ENDING qualifiers to specify, respectively, when you want a MONITOR request to begin and end.

Using the /DISPLAY Qualifier

Information collected by MONITOR is normally displayed as ASCII screen images. You can use the optional /DISPLAY qualifier to specify a disk file to contain the information. If you omit the file specification, output is directed to SYS$OUTPUT.

Refer to the OpenVMS System Management Utilities Reference Manual for a discussion of the /DISPLAY qualifier.

Using the /RECORD Qualifier

When you use the /RECORD qualifier, all data pertaining to the class is recorded, even if you are concurrently displaying only a single statistic or a single item of a component statistics class. The file is created when a MONITOR request is initiated and closed when a request terminates. You can use the resulting file as a source file for later requests to format and display the data on a terminal, to create a summary file, or to create a new recording file with different characteristics.

18.8.2 Invoking MONITOR

To invoke the Monitor utility, enter the following DCL command:

$ MONITOR

MONITOR then displays the following prompt:

MONITOR>

In response to the prompt, you can enter any of the MONITOR commands, which are described in OpenVMS System Management Utilities Reference Manual. The most frequently used MONITOR command, however, specifies a class name.

Example

MONITOR> MONITOR PAGE

In this example, you specify the PAGE class name in the MONITOR command to monitor page management statistics.

You can also use the MONITOR command from DCL command level.

How to Override or Terminate a MONITOR Request

Generally, each MONITOR request runs until the time specified or implied by the /ENDING qualifier. However, to override or terminate a MONITOR request, you can press one of the following conbinations of keys:

Keys	Description
Ctrl/W	Temporarily overrides a /VIEWING_TIME value and generates a new display immediately following the current one. This feature is useful when a broadcast message overwrites the MONITOR display area. You can also use Ctrl/W in conjunction with a large /VIEWING_TIME value to generate display events on demand.
Ctrl/C	Terminates the current request without exiting from the utility. You can then initiate a new request or enter any MONITOR command at the MONITOR> prompt.
Ctrl/Z	Terminates the current request and exits from MONITOR.

18.8.3 Using Live Display Monitoring

Use the live display monitoring mode of operation when you want to examine the activity of a running system, either on a routine basis or as part of an installation checkout, tuning, or troubleshooting exercise. The system does not keep a historical record of output. The following examples show how to use the live display monitoring mode.

Examples

1. $ MONITOR PROCESSES/TOPCPU

   
   The command displays a bar graph showing the eight processes that were the top consumers of CPU time during the period between displays. It also displays the amount of CPU time each process used.
   The command might produce a display similar to the following one:

   OpenVMS Monitor Utility TOP CPU TIME PROCESSES on node BOMBAY 20-JAN-1998 10:06:49 0 25 50 75 100 + - - - - + - - - - + - - - - + - - - - -+ 07E00181 CAFARET 100 **************************************** | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + - - - - + - - - - + - - - - + - - - - -+

   
   This example shows that user CAFARET is using 100 percent of the CPU time available. To display more information about the computer resources a user is using, use a command similar to the following one:

   $ SHOW PROCESS/CONTINUOUS/ID=07E00181

   
   For this example, the most useful information in the resulting display is the name of the image at the end of the display; for example:

   . . . $1$DUA1:[SYS1D.SYSCOMMON.][SYSEXE]RODAN.EXE

   
   This example indicates that CAFARET is running RODAN.EXE, which might be new software that is unintentionally running in a loop. This situation would occur if CAFARET were a privileged user running a process at a higher priority than other users.

2. $ MONITOR/DISPLAY=PROCESSES.LOG PROCESSES

   
   You can route MONITOR display output to any supported terminal device or to a disk file. This command writes MONITOR's display process statistics to the file PROCESSES.LOG. You can then print this file on a hardcopy device.

   Caution Because data is continuously added to the display file, be careful that the file does not grow too large.

3. $ MY_CLASSES :== - _$ "DECNET+FCP+IO+LOCK+MODES+PAGE+PROCESSES+STATES" $ MONITOR/NODE=(CURLEY,LARRY)/INTERVAL=20/VIEWING_TIME=8 'MY_CLASSES'

   
   You might find it convenient to establish DCL symbols for frequently used combinations of class names, as in this example. The MONITOR command collects selected classes of data for OpenVMS Cluster nodes CURLEY and LARRY every 20 seconds. Every 8 seconds, the system displays the most recently collected data for one of the classes. MONITOR predetermines the ordering of the classes for display.

	privacy and legal statement
6017PRO_083.HTML