skip book previous and next navigation links
go up to top of book: HP OpenVMS System Manager's Manual, Volume 2:... HP OpenVMS System Manager's Manual, Volume 2:...
go to beginning of chapter: Getting Information About the System Getting Information About the System
go to previous page: Using the Error Log Viewer (ELV) Using the Error Log Viewer (ELV)
go to next page: Using Security AuditingUsing Security Auditing
end of book navigation links

Setting Up, Maintaining, and Printing the Operator Log File  



The following sections describe the contents of the operator log file and OPCOM messages. They also explain how to perform the following tasks, which require OPER privilege:

Task Section
Setting up the operator log file
Setting Up the Operator Log File
Maintaining the operator log file
Maintaining the Operator Log File
Printing the operator log file
Printing the Operator Log File

Understanding the Operator Log File  

The operator log file (SYS$MANAGER:OPERATOR.LOG) records system events and user requests that the operator communication manager (OPCOM) sends to the operator terminal. This recording occurs even if all operator terminals have been disabled. By default, OPCOM starts when you boot your system. (For more information about OPCOM, see the HP OpenVMS System Manager's Manual, Volume 1: Essentials.)

You can use the operator log file to anticipate and prevent hardware and software failures and to monitor user requests for disk and magnetic tape operations. By regularly examining the operator log file, you can often detect potential problems and take corrective action.

The size of and access to the OPERATOR.LOG file (or to the file pointed to by the logical OPC$LOGFILE_NAME) is limited by the size and access of the disk device on which it resides. If disk device does not have enough room to write to the log file or if access to the device in any other way is restricted, records might be missing from the log file.

Understanding OPCOM Messages  

The following sections describe the types of messages that appear in the operator log file.

Type of Message Section
Initialization messages
Initialization Messages
Device status messages
Device Status Messages
Terminal enable and disable messages
Terminal Enable and Disable Messages
User request and operator reply messages
User Request and Operator Reply Messages
Volume mount and dismount messages
Volume Mount and Dismount Messages
System parameter messages
System Parameter Messages
Security alarm messages
Security Alarm Messages

Contents of an Operator Log File contains an example of typical kinds of messages found in an operator log file.

Initialization Messages  

When you enter the REPLY/LOG command, the system closes the current operator log file and creates and opens a new version of the file. The system records all subsequent OPCOM messages in the new log file.

When you create a new log file, the first message recorded in it is an initialization message. This message shows the terminal name of the operator who initialized the log file, and the log file specification. This message appears in the following format:

%%%%%%%%%%%  %OPCOM, :mm:ss.cc> %%%%%%%%%%%  
Logfile has been initialized by operator 
Logfile is <logfile-specification>
Example

%%%%%%%%%%%  OPCOM, 19-APR-2002 12:29:24.52  %%%%%%%%%%%
Logfile has been initialized by operator _MARS$VTA2:
Logfile is HOMER::SYS$SYSMOND:[SYSMGT]OPERATOR.LOG;43

Device Status Messages  

Some I/O drivers send messages to OPCOM concerning changes in the status of the devices they control. For example, when a line printer goes off line, an OPCOM message appears in the operator log file at periodic intervals until you explicitly return the device to online status.

The device status message appears in the operator log file in the following format:

%%%%%%%%%%%%  OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%%  
Device <device-name> is offline
This message can appear for card readers, line printers, and magnetic tapes.

Terminal Enable and Disable Messages  

The following sections explain commands you can give to enable and disable terminals as operator terminals (or consoles) and explanations of the corresponding messages that appear in the operator log file.

REPLY/ENABLE Messages

To designate a terminal as an operator terminal, enter the REPLY/ENABLE command from the desired terminal. OPCOM confirms the request by displaying messages in the following format at the operator terminal and in the operator log file:

%%%%%%%%%%%%  %OPCOM dd-mmm-yyyy hh:mm:ss.cc  %%%%%%%%%%%%  
Operator <terminal-name> has been enabled, username <user-name>
 
%%%%%%%%%%%%  %OPCOM dd-mmm-yyyy hh:mm:ss.cc  %%%%%%%%%%%%  
Operator status for operator <terminal-name>
<status-report>
These messages tell you which terminal has been established as an operator terminal and lists the requests the terminal can receive and respond to.

You can also designate a terminal as an operator terminal for a particular function by entering the REPLY/ENABLE=class command.

If you enter the command REPLY/ENABLE=TAPES, for example, OPCOM displays messages similar to the following ones:

%%%%%%%%%%%%  %OPCOM 19-APR-2002 10:25:35.74 %%%%%%%%%%%%  
Operator _ROUND$OPA1: has been enabled, username SYSTEM
 
%%%%%%%%%%%%  %OPCOM 19-APR-2002 10:25:38.82 %%%%%%%%%%%%  
Operator status for operator _ROUND$OPA1: 
TAPES
OPCOM confirms that the terminal is established as an operator terminal and indicates that the terminal can only receive and respond to requests concerning magnetic-tape-oriented events, such as the mounting and dismounting of tapes.

REPLY/DISABLE Messages

A terminal that you designate as an operator terminal automatically returns to nonoperator status when the operator logs out. To return the terminal to normal (nonoperator) status without logging out, enter the REPLY/DISABLE command from the terminal.

OPCOM confirms that the terminal is no longer an operator terminal by displaying a message both at the operator terminal and in the operator log file. The message, which tells you which terminal has been restored to nonoperator status and when the transition occurred, has the following format:

%%%%%%%%%%%  %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%  
Operator <terminal-name> has been disabled, username <user-name>
If you designate a terminal as an operator terminal and only partial operator status is disabled, OPCOM displays a status message. This message lists which requests the terminal can still receive and respond to. This message is displayed at the operator terminal and in the operator log file in the following format:
%%%%%%%%%%%  %OPCOM <dd-mmm-yyyy hh:mm:ss.cc>  %%%%%%%%%%%  
Operator status for operator <terminal-name>
<status-report>
For example, suppose you designate a terminal as an operator terminal that receives messages concerning magnetic tapes and disks, as well as messages intended for the special site-specific operator class known as OPER10. Later, you relinquish the terminal's ability to receive messages concerning tapes. When you enter the REPLY/DISABLE=TAPES command, OPCOM returns a message like the following one:
%%%%%%%%%%%  %Opcom 19-APR-2002 09:23:45.32  %%%%%%%%%%%  
Operator status for operator TTA3
DISKS, OPER10
This message tells you that terminal TTA3 still receives and can respond to messages about disks and messages directed to OPER10.

User Request and Operator Reply Messages  

To communicate with the operator, the user enters the REQUEST command, specifying either the /REPLY or /TO qualifier. The following table contains explanations of these qualifiers:

Command Explanation
REQUEST/REPLY
The request is recorded in the operator log file in the following format:
%%%%%%%%%%%  %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%  
Request <request-id>, from user <user-name> on <node-name>
<_terminal-name:>, <"message-text">


This message tells you which user sent the message, the time the message was sent, the request identification number assigned to the message, the originating terminal, and the message itself.
REQUEST/TO
The request is recorded in the operator log file in the format shown in the REQUEST/REPLY example, but without a request identification number:
%%%%%%%%%%%  %OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%  
Request from user <user-name> on <node-name>
<_terminal-name:>, <"message-text">


Messages also differ depending on how you reply to a user:

Command Explanation
REPLY/TO
The response is recorded in the operator log file in the following format:
response message
<hh:mm:ss.cc>, request <request-id> completed 
     by operator <terminal-name>


This message indicates how the operator responded to the user's request, as well as when the response was entered and which operator responded.
REPLY/ABORT
The response is recorded in the operator log file in the following format:
<hh:mm:ss.cc>, request <request-id> was aborted 
     by operator <terminal-name>

REPLY/PENDING
The response is not recorded in the operator log file because the request has not yet been completed (that is, the request has not been fulfilled or aborted).

When a user enters a REQUEST/REPLY command and you have disabled all terminals as operators' terminals, OPCOM records all subsequent users' requests in the log file, but returns a message to the user indicating that no operator coverage is available.

All other OPCOM responses to REPLY commands, except responses involving the REPLY/ENABLE, REPLY/DISABLE, and REPLY/LOG commands, are not logged in the operator log file.

Volume Mount and Dismount Messages  

Perhaps the widest range of operator messages occurs with volume mounts and dismounts; for example:

%%%%%%%%%%%  OPCOM, 19-APR-2002 22:41:07.54  %%%%%%%%%%%
message from user SYSTEM
Volume "KLATU       " dismounted, on physical device MTA0:
15-APR-2002 22:42:14.81, request 2 completed by operator OPA0

System Parameter Messages  

Users with the appropriate privileges can change the following sets of values for system parameters:

Values Description
Current
Values stored in the default parameter file on disk and used to boot the system
Active
Values stored in memory and used while the system is running

When the system boots, it reads the current values into memory, creating active values. An active value remains equal to the current value until you change either value.

Users can make the following changes to active and current system parameters:


NoteHP recommends that you use AUTOGEN or SYSMAN, not SYSGEN, to change system parameters, as explained in Recommended Method for Changing Parameter Values.

OPCOM logs all changes made to active and current system parameters with messages in the following format:
%%%%%%%%%%%  %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%  
Message from user <user-name>
%SYSGEN-I-WRITExxx, <system-mode> system parameters modified by process ID 
<process-id> into file <file-spec>
Example

%%%%%%%%%%%  %OPCOM 3-JUN-2002 08:11:59.55 %%%%%%%%%%%  
Message from user D_PLUTO on ANASAT
%SYSGEN-I-WRITECUR, CURRENT system parameters modified by process ID 0000020B
into file SYS$UPDATE:[SYSTEM]UPDATESYS.PAR;2
This message indicates that current system parameters have been changed.
NoteIf you have changed the format of system messages with the DCL command SET MESSAGE, these messages might not appear in the log file.

Security Alarm Messages  

Alarm messages are sent to the security operator terminal when selected events occur. See Enabling a Terminal to Receive Alarm Messages for instructions about how to enable a terminal to receive security alarm messages.

Example

The following example shows a security alarm OPCOM message after a change to JTQUOTA:

%%%%%%%%%%%  OPCOM   6-JAN-2003 10:41:21.10  %%%%%%%%%%%
Message from user AUDIT$SERVER on BISCO
Security alarm (SECURITY) and security audit (SECURITY) on BISCO, system id: 
20353
Auditable event:          System UAF record modification
Event time:               6-JAN-2003 10:41:20.69
PID:                      00600123
Process name:             SYSTEM
Username:                 SYSTEM
Process owner:            [SYSTEM]
Terminal name:            RTA1:
Image name:               BISCO$DUA0:[SYS0.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE
Object class name:        FILE
Object name:              SYS$SYSTEM:SYSUAF.DAT;4
User record:              NEWPORT
JTQUOTA:                  New:           2048
                          Original:      1024

Contents of an Operator Log File  

Sample Operator Log File (SYS$MANAGER:OPERATOR.LOG) illustrates some typical messages found in an operator log file.
Example 2  Sample Operator Log File (SYS$MANAGER:OPERATOR.LOG)  
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:26:07.90  %%%%%%%%%%%
 Device DMA0: is offline.  [1]                            
 Mount verification in progress.
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:26:20.22  %%%%%%%%%%%
 Mount verification completed for device DMA0:
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:33:54.07  %%%%%%%%%%%
 Operator '_ZEUS$VT333:' has been disabled, user JONES  [2]
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:34:15.47  %%%%%%%%%%%
 Operator '_ZEUS$VT333:' has been enabled, user SMITH
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:34:15.57  %%%%%%%%%%%
 operator status for '_ZEUS$VT333:' 
 PRINTER, TAPES, DISKS, DEVICES
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:38:53.21  %%%%%%%%%%%
 request 1, from user PUBLIC   [3]                          
 Please mount volume KLATU in device MTA0:
 The tape is in cabinet A
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:39:54.37  %%%%%%%%%%%
 request 1 was satisfied.
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:40:23.54  %%%%%%%%%%%
 message from user SYSTEM      [4]                          
 Volume "KLATU       " mounted, on physical device MTA0:
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:40:38.02  %%%%%%%%%%%
 request 2, from user PUBLIC
 MOUNT new relative volume 2 () on MTA0:
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:41:07.54  %%%%%%%%%%%
 message from user SYSTEM
 Volume "KLATU       " dismounted, on physical device MTA0:
 15-APR-2002 22:42:14.81, request 2 completed by operator OPA0
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:46:47.96  %%%%%%%%%%%
 request 4, from user PUBLIC
 _TTB5:, This is a sample user request with reply expected.
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:47:38.50  %%%%%%%%%%%
 request 4 was canceled
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:48:21.15  %%%%%%%%%%%
 message from user PUBLIC
 _TTB5:, This is a sample user request without a reply expected.
 %%%%%%%%%%%  OPCOM, 19-APR-2002 22:49:37.64  %%%%%%%%%%%
 Device DMA0: has been write locked.
 Mount verification in progress.
 %%%%%%%%%%%  OPCOM, 19-APR-2002 23:33:54.07  %%%%%%%%%%%
 message from user NETACP
 DECnet shutting down


The following messages appear in the example:

[1] Device status message

[2] Terminal enable and disable message

[3] User request and operator reply messages

[4] Volume mount and dismount messages

Setting Up the Operator Log File  

The operator log file normally resides on the system disk in the [SYSMGR] directory. You can, however, maintain the log file in a different location by defining the logical name OPC$LOGFILE_NAME.

The size of and access to the OPERATOR.LOG file (or to the file pointed to by the logical OPC$LOGFILE_NAME) is limited by the size and access of the disk device on which it resides. If the disk device does not have enough room to write to the log file or if access to the device is restricted in any other way, records might be missing from the log file.

By default, the log file is created on all systems except for workstations in an OpenVMS Cluster environment (unless the workstation is the first system into the cluster). OPCOM determines whether a system is a workstation by testing the system for a graphics device. Specifically, this test is:

F$DEVICE ("*", "WORKSTATION", "DECW_OUTPUT")
You can ensure that a log file will be created by defining the logical name OPC$LOGFILE_ENABLE to be true.

The system creates a new version of OPERATOR.LOG each time the system is rebooted. Note that one operator log file exists for each node; it is not a shared file.

Because this file is in ASCII format, you can print it. Print copies regularly and retain these copies for reference. Printing the Operator Log File describes how to print copies of the operator log file.

Creating a New Version of the Operator Log File  

You can use the DCL command REPLY/LOG to create a new version of the file at any time. The highest version is always the one in use and is inaccessible to other users. By default, messages of all operator classes are in the log file.

The following list contains guidelines for using the REPLY/LOG command:

If a log file is already open, the list of classes is preserved and enabled on the newly created log file. If a log file is not open, the value of the logical OPC$LOGFILE_CLASSES is used. If that logical does not exist, all classes are enabled on the new log file.

Note that if OPC$LOGFILE_CLASSES includes an invalid class then all classes are enabled, and a message similar to the following is displayed on the console at system startup and logged to the OPERATOR.LOG file:

%%%%%%%%%%% OPCOM 18-MAY-2002 13:28:33.12 %%%%%%%%%%%
"BADCLASS" is not a valid class name in OPC$LOGFILE_CLASSES
See the HP OpenVMS System Manager's Manual, Volume 1: Essentials for a description of the valid operator classes.

For more information, refer to the REPLY/LOG, REPLY/ENABLE, and REPLY/DISABLE commands in the HP OpenVMS DCL Dictionary.

Example

The following command opens a log file to include messages about mounting and dismounting disks and tapes:

$ REPLY/LOG/ENABLE=(DISKS,TAPES) 

Specifying Logical Names  

You can specify the default state of the operator log files by defining logical names in the command procedure SYS$MANAGER:SYLOGICALS.COM. The following table lists these logical names and their functions. For more information about SYLOGICALS.COM, see the HP OpenVMS System Manager's Manual, Volume 1: Essentials.


CautionSetting the OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logical names to FALSE severs most OPCOM traffic in the specified direction. Most OPCOM messages, as well as returned status messages that might be expected, will not be delivered.

Logical Name Function
OPC$ALLOW_INBOUND
Allows OPCOM traffic that is inbound to the node to be turned on or off. By default, this logical name is set to TRUE. If this logical name is set to FALSE, the node will not receive most OPCOM messages from other nodes in the cluster.
OPC$ALLOW_OUTBOUND
Allows OPCOM traffic that is outbound from the node to be turned on or off. By default, this logical name is set to TRUE. If this logical name is set to FALSE, the node will not send most OPCOM messages to other nodes in the cluster.
OPC$LOGFILE_ENABLE
Specifies whether an operator log file is opened. If defined to be true, an operator log file is opened. If defined to be false, no operator log file is opened. By default, a log file is opened on all systems except workstations in an OpenVMS Cluster environment.
OPC$LOGFILE_CLASSES
Specifies the operator classes that are enabled for the log file. By default, a log file is opened for all classes. The logical name can be a search list of the allowed classes, a comma-separated list, or a combination of the two. Note that you can define OPC$LOGFILE_CLASSES even if you do not define OPC$LOGFILE_ENABLE. In that case, the classes are used for any log files that are opened, but the default is used to determine whether to open the log file.

See the HP OpenVMS System Manager's Manual, Volume 1: Essentials for a description of the valid operator classes.
OPC$LOGFILE_NAME
Specifies the name of the log file. By default, the log file is named SYS$MANAGER:OPERATOR.LOG. If you specify a disk other than the system disk, include commands to mount that disk in the command procedure SYLOGICALS.COM.
OPC$OPA0_ENABLE
Overrides values of symbols for workstations in a cluster. If you define the logical as TRUE, it sets the OPA0 device to BROADCAST (overrides the NOBROADCAST default setting). For systems that are not workstations in a cluster, if you define the logical as FALSE, it sets the OPA0 device to NOBROADCAST.


NoteThe only logical that is used for more than the initial startup of OPCOM is OPC$LOGFILE_NAME. All other OPCOM logicals are ignored. For example, a REPLY/LOG command opens a new operator log file even if the logical OPC$LOGFILE_ENABLE is defined to be false. To reset OPCOM states and classes after startup, use REPLY/ENABLE or REPLY/DISABLE commands.

Maintaining the Operator Log File  

Devise a plan for regular maintenance of operator log files. One way is to start a new log file and rename the second-highest version daily. (See the example in the next section.) You might want to purge outdated versions of the operator log file on a regular basis. However, do not delete versions that you have not backed up. For more information, see the HP OpenVMS System Manager's Manual, Volume 1: Essentials.

If OPCOM is inadvertently deleted, follow these steps to start it manually:

  1. Log in to the SYSTEM account so that you have the required privileges to perform the operation.
  2. Enter the following command to execute the startup command procedure (STARTUP.COM), specifying OPCOM as the command parameter:
    $ @SYS$SYSTEM:STARTUP OPCOM 

Printing the Operator Log File  

Perform the following operation to produce a printed copy of the most recent version of the operator log file. (You must have OPER privilege.)

  1. Use the following command to enable the terminal as an operator terminal:
    $ REPLY/ENABLE
  2. Close the current log file and open a new one by entering the following command:
    $ REPLY/LOG
  3. Set the default to SYS$MANAGER and enter the following command to list all versions of the file:
    $ SET DEFAULT SYS$MANAGER
    $ DIRECTORY OPERATOR.LOG
  4. Rename the second-highest version to OPERATOR.OLD:
    $ RENAME OPERATOR.LOG;-1 OPERATOR.OLD
    The version number, -1, specifies that you want to rename the second-highest version of this file. (The highest version number is the current operator log file.)
  5. Print the operator log file by entering the following command:
    $ PRINT OPERATOR.OLD

Example

$ REPLY/ENABLE  [1]
$ REPLY/LOG     [2]
%%%%%%%%%%%  OPCOM, 19-APR-2002 12:28:20.11  %%%%%%%%%%%
Logfile was closed by operator _MARS$VTA2:  [3]
Logfile was HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;27
%%%%%%%%%%%  OPCOM, 19-APR-2002 12:29:24.52  %%%%%%%%%%%
Logfile has been initialized by operator _MARS$VTA2:
Logfile is HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;28

$ SET DEFAULT SYS$MANAGER  [4]
$ DIRECTORY OPERATOR.LOG   [5]
 
Directory SYS$MANAGER:[SYSMGT]
 
OPERATOR.LOG;28           OPERATOR.LOG;27

Total of 2 files.

$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD  [6]
$ PRINT OPERATOR.OLD   [7]

The following list provides explanations of the numbered commands and responses in the example:

[1] The REPLY/ENABLE command enables the terminal as an operator terminal.

[2] The REPLY/LOG command closes the current log file and opens a new one.

[3] The response from OPCOM verifies that it has opened a new log file.

[4] The SET DEFAULT command sets the operator default disk to the system disk.

[5] The DIRECTORY command displays the files in the directory [SYSMGT] on the system disk.

[6] The RENAME command renames the second-highest version of the operator log file to OPERATOR.OLD.

[7] The PRINT command prints the old operator log file, OPERATOR.OLD.


go to previous page: Using the Error Log Viewer (ELV) Using the Error Log Viewer (ELV)
go to next page: Using Security AuditingUsing Security Auditing