HP OpenVMS Systems Documentation

Content starts here

OpenVMS System Manager's Manual

Previous Contents Index

20.7.3 Delaying Startup of Auditing

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:


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:


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

20.7.4 Enabling Security Auditing for Additional Classes

To enable security auditing for classes in addition to those shown in Table 20-7, 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 21 for more information.
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 20-7 are sent as both alarms and audits.

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


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

  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.


20.7.5 Disabling Security Auditing

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


20.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:



The following example shows a security alarm message:

%%%%%%%%%%%  OPCOM  25-MAY-2000 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-2000 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]

20.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:

$ MAIL/SUBJECT="Security Events" 31JAN2000.AUDIT SYSTEM

20.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. 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:


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


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.

20.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 20.8.2
Using live display monitoring Section 20.8.3
Using live recording monitoring Section 20.8.4
Using concurrent display and recording monitoring Section 20.8.5
Using playback monitoring Section 20.8.6
Using remote playback monitoring Section 20.8.7
Rerecording monitoring Section 20.8.8
Running MONITOR continuously Section 20.8.9
Using remote monitoring Section 20.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.

20.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 20.8.9. 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 20-8 compares the two MONITOR class types.

Table 20-8 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 20-9 describes each MONITOR class and indicates whether it is a system or component class.

Table 20-9 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

+VAX specific Display Data

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


Be careful when you use the /DISPLAY qualifier. Because MONITOR enters display information into the file continuously, its size can grow very quickly.

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.

20.8.2 Invoking MONITOR

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


MONITOR then displays the following prompt:


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.



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.

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



    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-2000 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:


    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:


    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.


    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.


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

  3. $ 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.

Previous Next Contents Index