HP OpenVMS System Manager's Manual, Volume 2:...

Getting Information About the System

Using Security Auditing

Tracking Resource Use

Monitoring Operating System Performance  

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

Task	Section
Invoking the Monitor utility	Invoking MONITOR
Using live display monitoring	Using Live Display Monitoring
Using live recording monitoring	Using Live Recording Monitoring
Using concurrent display and recording monitoring	Using Concurrent Display and Recording Monitoring
Using playback monitoring	Using Playback Monitoring
Using remote playback monitoring	Using Remote Playback Monitoring
Rerecording monitoring	Rerecording Monitoring
Running MONITOR continuously	Running MONITOR Continuously
Using remote monitoring	Using Remote Monitoring

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

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 Running MONITOR Continuously.

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 HP 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. Types of MONITOR Classes compares the two MONITOR class types.

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

MONITOR Classes describes each MONITOR class and indicates whether it is a system or component class.

Table 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
VBS1	System	Virtual balance slot statistics
VECTOR	System	Vector processor scheduled usage

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.

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.

Invoking MONITOR  

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

$ MONITOR

MONITOR>

Example

MONITOR> MONITOR PAGE

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.

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:

                         OpenVMS Monitor Utility
                          TOP CPU TIME PROCESSES
                               on node BOMBAY
                           20-JAN-2002 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.

   ---

   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.

Using Live Recording Monitoring  

Use live recording to capture MONITOR data for future use. Possible uses include the following ones:

• Installation checkout, tuning, troubleshooting; that is, all the uses that are listed for live display monitoring.
  
  Choose recording over display when you want to capture more classes than you can reasonably watch at a terminal, when a terminal is not available, or when you want to gather data about the system but cannot spend time at the terminal until later.



• Routine performance data gathering for long-term analysis.
  
  You can record MONITOR data on a routine basis and summarize it to gather data about system resource use over long periods of time.

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

Example

$ MONITOR/NODE=(LARRY,MOE)/NODISPLAY/RECORD MODES+STATES

Using Concurrent Display and Recording Monitoring  

Use the concurrent display and recording mode of operation when you want to both retain performance data and watch as it is being collected. Because MONITOR allows shared read access to the recording file, a separate display process can play back the recording file as it is being written by another process.

The following examples show how to use the concurrent display and recording mode of operation. The first example both collects and records data in the same command. The second and third examples show how you can perform concurrent recording and display using two separate processes: the process in the second example performs recording; the process in the third example plays back the file to obtain a summary.

Examples

1. $ MONITOR/RECORD FCP/AVERAGE,FILE_SYSTEM_CACHE/MINIMUM

   This command collects and records file system data and file system cache data every 3 seconds. It also displays, in bar graph form, average FCP statistics and minimum FILE_SYSTEM_CACHE statistics. The display alternates between the two graphs every 3 seconds. You can obtain current statistics in a subsequent playback request.

2. $ MONITOR/RECORD=SYS$MANAGER:ARCHIVE.DAT -
   _$ /INTERVAL=300/NODISPLAY ALL_CLASSES

   This command archives data for all classes once every 5 minutes. You might find it convenient to execute a similar command in a batch job, taking care to monitor disk space usage.

3. $ MONITOR/INPUT=SYS$MANAGER:ARCHIVE.DAT: -
   _$ /NODISPLAY/SUMMARY/BEGINNING="-1" PAGE,IO

   The command in this example produces a summary of page and I/O activity that occurred during the previous hour, perhaps as part of an investigation of a reported performance problem. Note that because the recording process executes an OpenVMS RMS flush operation every 5 minutes, up to 5 minutes of the most recently collected data is not available to the display process.
   
   You can specify the time between flush operations explicitly with the /FLUSH_INTERVAL qualifier. Note also that the display process must have read access to the recording file.

Using Playback Monitoring  

Use playback of a recording file to obtain terminal output and summary reports of all collected data or a subset of it. You can make a subset of data according to class, node, or time segment. For example, if you collect several classes of data for an entire day, you can examine or summarize the data on one or more classes during any time period in that day.

You can also display or summarize data with a different interval than the one at which it was recorded. You control the actual amount of time between displays of screen images with the /VIEWING_TIME qualifier. The following examples show how to use the playback mode of operation.

Examples

1. $ MONITOR/RECORD/INTERVAL=5 IO
   .
   .
   .
   $ MONITOR/INPUT IO

   The commands in this example produce system I/O statistics. The first command gathers and displays data every 5 seconds, beginning when you enter the command and ending when you press Ctrl/Z. In addition, the first command records binary data in the default output file MONITOR.DAT.
   
   The second command plays back the I/O statistics display, using the data in MONITOR.DAT for input. The default viewing time for the playback is 3 seconds, but each screen display represents 5 seconds of monitored I/O statistics.

2. $ MONITOR/RECORD/NODISPLAY -
   _$ /BEGINNING=08:00:00 -
   _$ /ENDING=16:00:00 -
   _$ /INTERVAL=120 DISK
    
   $ MONITOR/INPUT/DISPLAY=HOURLY.LOG/INTERVAL=3600 DISK

   The sequence of commands in this example illustrates data recording with a relatively small interval and data playback with a relatively large interval. This is useful for producing average, minimum, and maximum statistics that cover a wide range of time, but have greater precision than if they had been gathered using the larger interval.
   
   The first command records data on I/O operations for all disks on the system for the indicated 8-hour period, using an interval of 2 minutes. The second command plays the data back with an interval of 1 hour, storing display output in the file HOURLY.LOG. You can then type or print this file to show the cumulative average disk use at each hour throughout the 8-hour period.

   ---

   The current statistic in HOURLY.LOG shows the current data in terms of the original collection interval of 120 seconds, not the new collection interval of 3600 seconds.

   ---

3. $ MONITOR/INPUT/NODISPLAY/SUMMARY=DAILY.LOG DISK

   The command in this example uses the recording file created in the previous example to produce a one-page summary report file showing statistics for the indicated 8-hour period. The summary report has the same format as a screen display. For example:

                               OpenVMS Monitor Utility
                                 DISK I/O STATISTICS
                                    on node TLC          From: 25-JAN-2002 08:00:00
                                       SUMMARY           To:   25-JAN-2002 16:00:00
    
   I/O Operation Rate                         CUR        AVE        MIN        MAX
    
   DSA0:                 SYSTEM_0            0.53       1.50       0.40       3.88
   DSA1:                 SYSTEM_1            0.00       0.39       0.00       8.38
   DSA4:                 WORK_0              0.00       0.11       0.00       1.29
   DSA5:                 WORK_1              0.03       0.87       0.00       5.95
   DSA6:                 WORK_2              0.03       0.25       0.00       2.69
   DSA7:                 WORK_3              0.04       0.97       0.00      20.33
   DSA17:                TOM_DISK            0.00       0.04       0.00       0.80
   DSA23:                MKC                 0.00       0.00       0.00       0.13
   $4$DUA0:     (RABBIT) SYSTEM_0            0.20       0.65       0.17       1.97
   $4$DUA2:     (RABBIT) SYSTEM_0            0.20       0.65       0.17       1.97
   $4$DUA3:     (RABBIT) SYSTEM_1            0.00       0.14       0.00       2.49
    
    PLAYBACK                         SUMMARIZING

Using Remote Playback Monitoring  

If suitably privileged, you can collect MONITOR data from any system to which your system has a DECnet connection. You can then display the data live on your local system. To do so, follow these steps:

1. In the default DECnet directory on each remote system, create a file named MONITOR.COM, similar to the following example:

   $ !
   $ !    * Enable MONITOR remote playback *
   $ !
   $ MONITOR /NODISPLAY/RECORD=SYS$NET ALL_CLASSES

2. On your local system, define a logical name for the remote system from which you want to collect data. Use the following syntax:DEFINE remotenodename_mon node::task=monitorYou might want to define, in a login command procedure, a series of logical names for all the systems you want to access.
3. To display the remote MONITOR data as it is being collected, enter a command using the following syntax: MONITOR/INPUT=remotenodename_mon classnames

You can also place MONITOR.COM files in directories other than the default DECnet directory and use access control strings or proxy accounts to invoke these command files remotely.

When you invoke MONITOR on your local system, a process is created on the remote system that executes the MONITOR.COM command file. The remote system therefore experiences some associated CPU and DECnet overhead. You can regulate the overhead in the MONITOR.COM file by using the /INTERVAL qualifier and the list of class names.

Using Remote Monitoring describes remote monitoring in a mixed-version cluster system.

Rerecording Monitoring  

Rerecording is a combination of playback and recording. You can use it for data reduction of recording files. When you play back an existing recording file, all MONITOR options are available to you; thus, you can choose to record a subset of the recorded classes and a subset of the recorded time segment and a larger interval value.

All these techniques produce a new, smaller recording file at the expense of some of the recorded data. A larger interval value reduces the volume of the collected data, so displays and summary output produced from the newer recorded file will be less precise. Note that average rate values are not affected in this case, but average level values are less precise (since the sample size is reduced), as are maximum and minimum values. The following example shows how to use the rerecording mode of operation:

Example

$ SUBMIT MONREC.COM

$ MONITOR/NODISPLAY/RECORD/INTERVAL=60 /BEGINNING=8:00/ENDING=16:00 DECNET,LOCK
$ MONITOR/INPUT/NODISPLAY/RECORD DECNET

Running MONITOR Continuously  

You can develop a database of performance information for your system by running MONITOR continuously as a background process. This section contains examples of procedures that you, as cluster manager, might use to create multifile clusterwide summaries.

You can adapt the command procedures to suit conditions at your site. Note that you must define the logical names SYS$MONITOR and MON$ARCHIVE in SYSTARTUP.COM before executing any of the command files.

The directory with the logical name SYS$EXAMPLES includes three command procedures that you can use to establish the database. Instructions for installing and running the procedures are in the comments at the beginning of each procedure. MONITOR Command Procedures contains a brief summary of these procedures.

Table 10   MONITOR Command Procedures

Procedure	Description
MONITOR.COM	Creates a summary file from the recording file of the previous boot, and then begins recording for this boot. The recording interval is 10 minutes.
MONSUM.COM	Generates two clusterwide multifile summary reports that are mailed to the system manager: one report is for the previous 24 hours, and the other is for the previous day's prime-time period (9 a.m. to 6 p.m.). The procedure resubmits itself to run each day at midnight.
SUBMON.COM	Starts MONITOR.COM as a detached process. Invoke SUBMON.COM from the site-specific startup command procedure.

While MONITOR records data continuously, a summary report can cover any finite time segment. The MONSUM.COM command procedure, which is executed every midnight, produces and mails the two multifile summary reports described in MONITOR Command Procedures. Because these reports are not saved as files, to keep them, you must either extract them from your mail file or alter the MONSUM.COM command procedure to save them.

Using the MONITOR.COM Procedure  

The procedure in MONITOR.COM Procedure archives the recording file and summary file from the previous boot and initiates continuous recording for the current boot. (Note that this procedure does not purge recording files.)

Example 3  MONITOR.COM Procedure

$ SET VERIFY $ ! $ ! MONITOR.COM $ ! $ ! This command file is to be placed in a cluster-accessible directory $ ! called SYS$MONITOR and submitted at system startup time as a detached $ ! process via SUBMON.COM. For each node, MONITOR.COM creates, in $ ! SYS$MONITOR, a MONITOR recording file that is updated throughout the $ ! life of the boot. It also creates, in MON$ARCHIVE, a summary file from $ ! the recording file of the previous boot, along with a copy of that $ ! recording file. Include logical name definitions for both cluster- $ ! accessible directories, SYS$MONITOR and MON$ARCHIVE, in SYSTARTUP.COM. $ ! $ SET DEF SYS$MONITOR $ SET NOON $ PURGE MONITOR.LOG/KEEP:2 $ ! $ ! Compute executing node name and recording and summary file names $ ! (incorporating node name and date). $ ! $ NODE = F$GETSYI("NODENAME") $ SEP = "" $ IF NODE .NES. "" THEN SEP = "_" $ DAY = F$EXTRACT (0,2,F$TIME() ) $ IF F$EXTRACT(0,1,DAY) .EQS. " " THEN DAY = F$EXTRACT(1,1,DAY) $ MONTH = F$EXTRACT(3,3,F$TIME() ) $ ARCHFILNAM = "MON$ARCHIVE:"+NODE+SEP+"MON"+DAY+MONTH $ RECFIL = NODE+SEP+"MON.DAT" $ SUMFIL = ARCHFILNAM+".SUM"$ ! $ ! Check for existence of recording file from previous boot and skip $ ! summary if not present. $ ! $ OPEN/READ/ERROR=NORECFIL RECORDING 'RECFIL' $ CLOSE RECORDING $ ! $ ! $ ! Generate summary file from previous boot. $ ! $ MONITOR /INPUT='RECFIL' /NODISPLAY /SUMMARY='SUMFIL' - $ ALL_CLASSES+MODE/ALL+STATES/ALL+SCS/ITEM=ALL+SYSTEM/ALL+DISK/ITEM=ALL $ ! $ ! $ ! Compute subject string and mail summary file to cluster manager. $ ! $ ! $ A=""" $ B=" MONITOR Summary " $ SUB = A+NODE+B+F$TIME()+A $ MAIL/SUBJECT='SUB' 'SUMFIL' CLUSTER_MANAGER $ ! $ ! $ ! Archive recording file and delete it from SYS$MONITOR. $ ! $ COPY 'RECFIL' 'ARCHFILNAM'.DAT $ DELETE 'RECFIL';* $ ! $ NORECFIL: $ SET PROCESS/PRIORITY=15 $ ! $ ! $ ! Begin recording for this boot. The specified /INTERVAL value is $ ! adequate for long-term summaries; you might need a smaller value $ ! to get reasonable "semi-live" playback summaries (at the expense $ ! of more disk space for the recording file). $ ! $ MONITOR /INTERVAL=300 /NODISPLAY /RECORD='RECFIL' ALL_CLASSES $ ! $ ! $ ! End of MONITOR.COM $ !

Using the SUBMON.COM Procedure  

The procedure in SUBMON.COM Procedure submits MONITOR.COM as a detached process from SYSTARTUP.COM to initiate continuous recording for the current boot.

Example 4  SUBMON.COM Procedure

$ SET VERIFY $ ! $ ! SUBMON.COM $ ! $ ! This command file is to be placed in a cluster-accessible directory $ ! called SYS$MONITOR. At system startup time, for each node, it is $ ! executed by SYSTARTUP.COM, following logical name definitions for $ ! the cluster-accessible directories SYS$MONITOR and MON$ARCHIVE. $ ! $ ! $ ! Submit detached MONITOR process to do continuous recording. $ ! $ ! $ RUN SYS$SYSTEM:LOGINOUT.EXE - /UIC=[1,4] - /INPUT=SYS$MONITOR:MONITOR.COM - /OUTPUT=SYS$MONITOR:MONITOR.LOG - /ERROR=SYS$MONITOR:MONITOR.LOG - /PROCESS_NAME="Monitor" - /WORKING_SET=512 - /MAXIMUM_WORKING_SET=512 - /EXTENT=512/NOSWAPPING $ ! $ ! $ ! End of SUBMON.COM $ !

Using the MONSUM.COM Procedure  

The procedure in MONSUM.COM Procedure produces daily and prime-time clusterwide summaries.

Example 5  MONSUM.COM Procedure

$ SET VERIFY $ ! $ ! MONSUM.COM $ ! $ ! This command file is to be placed in a cluster-accessible directory $ ! called SYS$MONITOR and executed at the convenience of the cluster $ ! manager. The file generates both 24-hour and "prime time" cluster $ ! summaries and resubmits itself to run each day at midnight. $ ! $ SET DEF SYS$MONITOR $ SET NOON $ ! $ ! Compute file specification for MONSUM.COM and resubmit the file. $ ! $ FILE = F$ENVIRONMENT("PROCEDURE") $ FILE = F$PARSE(FILE,,,"DEVICE")+F$PARSE(FILE,,,"DIRECTORY")+F$PARSE(FILE,,,"NAME") $ SUBMIT 'FILE' /AFTER=TOMORROW /NOPRINT $ ! $ ! Generate 24-hour cluster summary. $ ! $ ! $ MONITOR/INPUT=(SYS$MONITOR:*MON*.DAT;*,MON$ARCHIVE:*MON*.DAT;*) - /NODISPLAY/SUMMARY=MONSUM.SUM - ALL_CLASSES+DISK/ITEM=ALL+SCS/ITEM=ALL- /BEGIN="YESTERDAY+0:0:0.00" /END="TODAY+0:0:0.00" /BY_NODE $ ! $ ! $ ! Mail 24-hour summary file to cluster manager and delete the file from $ ! SYS$MONITOR. $ ! $ ! $ MAIL/SUBJECT="Daily Monitor Clusterwide Summary" MONSUM.SUM CLUSTER_MANAGER $ DELETE MONSUM.SUM;* $ ! $ ! Generate prime-time cluster summary. $ ! $ ! $ MONITOR/INPUT=(SYS$MONITOR:*MON*.DAT;*,MON$ARCHIVE:*MON*.DAT;*) - /NODISPLAY/SUMMARY=MONSUM.SUM - ALL_CLASSES+DISK/ITEM=ALL+SCS/ITEM=ALL- /BEGIN="YESTERDAY+9:0:0.00" /END="YESTERDAY+18:0:0.00" /BY_NODE $ ! $ ! $ ! Mail prime-time summary file to cluster manager and delete the file $ ! from SYS$MONITOR. $ ! $ ! $ MAIL/SUBJECT="Prime-Time Monitor Clusterwide Summary" MONSUM.SUM CLUSTER_MANAGER $ DELETE MONSUM.SUM;* $ ! $ ! End of MONSUM.COM $ !

Note that Mail commands in this procedure send files to user CLUSTER_MANAGER. Replace CLUSTER_MANAGER with the appropriate user name or logical name for your site.

Because summary data might be extensive, HP recommends that you print out summary files.

Using Remote Monitoring  

MONITOR is capable of using both TCP/IP and DECnet as a transport mechanism. Beginning with OpenVMS Version 7.0, to use TCP/IP, you must start the TCP/IP server by issuing the following command inside SYS$STARTUP:SYSTARTUP_VMS.COM:

$ @SYS$STARTUP:VPM$STARTUP.COM

Remote Monitoring in a Mixed-Version OpenVMS Cluster System

You can monitor any node in an OpenVMS Cluster system either by issuing the MONITOR CLUSTER command or by adding the /NODE qualifier to any interactive MONITOR request.

Remote monitoring in an OpenVMS Cluster system might not be compatible, however, between nodes that are running different versions of OpenVMS. Remote Monitoring Compatibility in an OpenVMS Cluster System shows the compatibility of versions for remote monitoring.

Table 11   Remote Monitoring Compatibility in an OpenVMS Cluster System

Versions	OpenVMS Alpha, I64, and VAX Version 6.n or 7.n	OpenVMS Alpha Version 1.5 and VAX Version 5.n
OpenVMS Alpha, I64, and VAX Version 6.n or 7.n	Yes	No
OpenVMS Alpha Version 1.5 and VAX Version 5.n	No	Yes

If you attempt to monitor a remote node that is incompatible, the system displays the following message:

%MONITOR-E-SRVMISMATCH, MONITOR server on remote node is an incompatible version

Another difference exists when you monitor remote nodes in an OpenVMS Cluster system. Beginning with OpenVMS Version 6.2, the limit on the number of disks that can be monitored was raised from 799 to 909 for record output and from 799 to 1817 for display and summary outputs. If you monitor a remote node running OpenVMS Version 6.2 or later from a system running a version earlier than OpenVMS Version 6.2, the old limit of 799 applies.

For more information about MONITOR, refer to the HP OpenVMS System Management Utilities Reference Manual.

1	VAX specific

( Number takes you back )

Using Security Auditing

Tracking Resource Use