![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Example 18-2 shows the format of a brief report.
Example 18-2 Brief Report Format
******************************** ENTRY 1 ********************************
Logging OS 1. OpenVMS
System Architecture 2. Alpha
OS version V7.1
Event sequence number 1583.
Timestamp of occurrence 18-APR-1996 09:21:18
System uptime in seconds 58004.
Error mask x00000000
Host name COGENT
Alpha HW model DEC 3000 Model 400
System type register x00000004 DEC 3000
Unique CPU ID x00000002
mpnum x000000FF
mperr x000000FF
Event validity -1. Unknown validity code
Event severity -1. Unknown severity code
Major Event class 3. IO Subsystem
IO Minor Class 1. MSCP
IO Minor Sub Class 5. Logged Message
---- Device Profile ----
Vendor
Product Name RAID 0 - Host Based
Unit Name COGENT$DPA
Unit Number 10.
Device Class x0001 Disk
Logged Message Type Code 22. RAID Message
RAID Event Type 8. Remove Member
Distinguished Member 0.
Member Index 1.
RAID Urgency 4. Global Disk Error
RAID Status x00180009 Bit 00 - Reduced
Bit 03 - Striped
Bit 19 - FE Dis FE
Bit 20 - BC Buff Copy Off
RAIDset Name KGB
*****************************************************************************
To produce a terse report, use the /TERSE qualifier. The terse report format provides binary event information and displays register values and other ASCII messages in a condensed format. For example:
$ DIAGNOSE/TRANSLATE/TERSE
Example 18-3 shows the format of a terse report.
Example 18-3 Terse Report Format
******************************** ENTRY 1 ******************************** Logging OS 1. System Architecture 2. OS version V7.1 Event sequence number 1583. Timestamp of occurrence 1996041809211800 System uptime in seconds 58004. Error mask x00000000 Flags x0001 Host name COGENT Alpha HW model DEC 3000 Model 400 System type register x00000004 Unique CPU ID x00000002 mpnum x000000FF mperr x000000FF Event validity -1. Event severity -1. Entry type 100. Major Event class 3. IO Minor Class 1. IO Minor Sub Class 5. ---- Device Profile ---- Vendor Product Name RAID 0 - Host Based Unit Name COGENT$DPA Unit Number 10. Device Class x0001 ---- IO SW Profile ---- VMS DC$_CLASS 1. VMS DT$_TYPE 175. ---- MSCP Logged Msg ---- Logged Message Type Code 22. RAID Event Type 8. Distinguished Member 0. Member Index 1. RAID Urgency 4. RAID Status x00180009 RAIDset Name KGB **********************************************************************
To produce a summary report, use the /SUMMARY qualifier. The summary report format provides a statistical summary of the event entries in the event log. For example:
$ DIAGNOSE/TRANSLATE/SUMMARY
Example 18-4 shows the format of a summary report.
Example 18-4 Summary Report Format
SUMMARY OF ALL ENTRIES LOGGED ON NODE COGENT
IO Subsystem
MSCP 9.
Host Based RAID 3.
DATE OF EARLIEST ENTRY 18-APR-1996 09:21:18
DATE OF LATEST ENTRY 12-MAY-1996 10:44:54
To produce a Fast Error report, use the /FSTERR qualifier. For example:
$ DIAGNOSE/TRANSLATE/FSTERR
The Fast Error report provides a quick, one-line-per-entry report of your event log for a variety of disk devices. This makes event analysis and system troubleshooting much easier by eliminating extraneous event information. For example:
$ DIAGNOSE/FSTERR [infile]
A Fast Error report is shown in Example 18-5.
Example 18-5 Fast Error (FSTERR) Report Format
Drive/
MSCP Physical HSC Volume
Drive Name yymmdd hhmmss Entry Evnt LED LBN Cyl Hd Sec RA RP Serial
============= ============= ===== ==== === ======= ==== == === === == ======
LUKE$DUA070 921119 160754 3 00EB 255 70 71 V00717
LUKE$DUA070 921119 160754 4 00EB 255 70 71 V00717
HSC015$DUA028 910323 113204 5 00EB 70 51 V15039
HSC015$DUA028 910323 113204 6 00EB 71 51 V15039
BATES$DUA197 921118 002116 7 00EB 72 32 V17524
CHEWIE$DUA101 911205 114908 8 00EB 73 81 V 17
PMASON$DUA006 921207 165007 15 00EB 255 90 42 D23387
PMASON$DUA006 921207 165007 16 00EB 255 90 42 D23387
C3P0$DUA242 870218 060031 17 01AB 90 40 D48575
CHER$DU2132*901008 231053 18 00EB 92 81 D 2345
The Fast Error report includes the information needed by a Digital support representative to troubleshoot a problem with a tape or disk device.
When you use the DECevent utility, note some of the restrictions listed in this section.
Page File Quota
Sometimes, if the page file quota is exceeded, DECevent will terminate and return you to the system prompt. If this happens, invoke the last command.
Logical File Names
DECevent does not translate as input any logical defined as a search list of file names. For example:
$ DEFINE EVENT_LOG DISK1:[EVENTS]EVENT_LOG1.SYS,DISK1:EVENT_LOG.SYS $ DIAGNOSE/ANALYZE EVENT_LOG DECevent T1.0 FT2 _DIAGNOSE-FAT: Analyze - No files found ' event_log ' _DIAGNOSE-FAT: An error occurred while executing a command ruleset _DIAGNOSE-INF: No Error Messages to send in thread 1
Log File Purging
DECevent does not automatically purge log files. Set the version limit on the files and directory to your preference. For example:
$ SET FILE/VERSION=3 DIA_ACTIVITY.LOG
System-Initiated Call Logging
When a system running DECevent is shut down and rebooted, DECEVENT$STARTUP.COM does not define FMGPROFILE logicals. This can interfere with proper logging of system initiated call logging (SICL) due to missing customer profile information in the SICL message text.
Unrecognized Messages
The DIAGNOSE command does not recognize error log messages logged using the $SNDERR system service.
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 | Section 18.6.3 |
| Maintaining the operator log file | Section 18.6.4 |
| Printing the operator log file | Section 18.6.5 |
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 on OPCOM, see Section 2.4.)
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.
The following sections describe the types of messages that appear in the operator log file.
| Type of Message | Section |
|---|---|
| Initialization messages | Section 18.6.2.1 |
| Device status messages | Section 18.6.2.2 |
| Terminal enable and disable messages | Section 18.6.2.3 |
| User request and operator reply messages | Section 18.6.2.4 |
| Volume mount and dismount messages | Section 18.6.2.5 |
| System parameter messages | Section 18.6.2.6 |
| Security alarm messages | Section 18.6.2.7 |
Section 18.6.2.8 contains an example of typical kinds of messages found in an operator log file.
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, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%% Logfile has been initialized by operator <terminal-name> Logfile is <logfile-specification>
Example
%%%%%%%%%%% OPCOM, 19-APR-1996 12:29:24.52 %%%%%%%%%%% Logfile has been initialized by operator _MARS$VTA2: Logfile is HOMER::SYS$SYSMOND:[SYSMGT]OPERATOR.LOG;43
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.
Following are explanations of 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:
%%%%%%%%%%%% %OPCOM 19-APR-1996 10:25:35.74 %%%%%%%%%%%% Operator _ROUND$OPA1: has been enabled, username SYSTEM %%%%%%%%%%%% %OPCOM 19-APR-1996 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:
%%%%%%%%%%% %Opcom 19-APR-1996 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.
To communicate with the operator, the user enters the REQUEST command, specifying either the /REPLY or /TO qualifier. Following are explanations of these qualifiers:
Messages also differ depending on how you reply to a user:
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.
Perhaps the widest range of operator messages occurs with volume mounts and dismounts; for example:
%%%%%%%%%%% OPCOM, 19-APR-1996 22:41:07.54 %%%%%%%%%%% message from user SYSTEM Volume "KLATU " dismounted, on physical device MTA0: 15-APR-1996 22:42:14.81, request 2 completed by operator OPA0
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:
Note
Digital recommends that you use AUTOGEN or SYSMAN, not SYSGEN, to change system parameters, as explained in Section 14.2.
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-1996 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.
Note
If you have changed the format of system messages with the DCL command SET MESSAGE, these messages might not appear in the log file.
Alarm messages are sent to the security operator terminal when selected events occur. See Section 18.7.6 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-1996 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-1996 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
Example 18-6 illustrates some typical messages found in an operator log file.
Example 18-6 Sample Operator Log File (SYS$MANAGER:OPERATOR.LOG)
%%%%%%%%%%% OPCOM, 19-APR-1996 22:26:07.90 %%%%%%%%%%% Device DMA0: is offline. (1) Mount verification in progress. %%%%%%%%%%% OPCOM, 19-APR-1996 22:26:20.22 %%%%%%%%%%% Mount verification completed for device DMA0: %%%%%%%%%%% OPCOM, 19-APR-1996 22:33:54.07 %%%%%%%%%%% Operator '_ZEUS$VT333:' has been disabled, user JONES (2) %%%%%%%%%%% OPCOM, 19-APR-1996 22:34:15.47 %%%%%%%%%%% Operator '_ZEUS$VT333:' has been enabled, user SMITH %%%%%%%%%%% OPCOM, 19-APR-1996 22:34:15.57 %%%%%%%%%%% operator status for '_ZEUS$VT333:' PRINTER, TAPES, DISKS, DEVICES %%%%%%%%%%% OPCOM, 19-APR-1996 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-1996 22:39:54.37 %%%%%%%%%%% request 1 was satisfied. %%%%%%%%%%% OPCOM, 19-APR-1996 22:40:23.54 %%%%%%%%%%% message from user SYSTEM (4) Volume "KLATU " mounted, on physical device MTA0: %%%%%%%%%%% OPCOM, 19-APR-1996 22:40:38.02 %%%%%%%%%%% request 2, from user PUBLIC MOUNT new relative volume 2 () on MTA0: %%%%%%%%%%% OPCOM, 19-APR-1996 22:41:07.54 %%%%%%%%%%% message from user SYSTEM Volume "KLATU " dismounted, on physical device MTA0: 15-APR-1996 22:42:14.81, request 2 completed by operator OPA0 %%%%%%%%%%% OPCOM, 19-APR-1996 22:46:47.96 %%%%%%%%%%% request 4, from user PUBLIC _TTB5:, This is a sample user request with reply expected. %%%%%%%%%%% OPCOM, 19-APR-1996 22:47:38.50 %%%%%%%%%%% request 4 was canceled %%%%%%%%%%% OPCOM, 19-APR-1996 22:48:21.15 %%%%%%%%%%% message from user PUBLIC _TTB5:, This is a sample user request without a reply expected. %%%%%%%%%%% OPCOM, 19-APR-1996 22:49:37.64 %%%%%%%%%%% Device DMA0: has been write locked. Mount verification in progress. %%%%%%%%%%% OPCOM, 19-APR-1996 23:33:54.07 %%%%%%%%%%% message from user NETACP DECnet shutting down
The following messages appear in the example:
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.
Because this file is in ASCII format, you can print it. Print copies regularly and retain these copies for reference. Section 18.6.5 describes how to print copies of the operator log file.
The system creates a new version of OPERATOR.LOG each time the system is rebooted (except on workstations in an OpenVMS Cluster environment, where the log file is not opened by default). Note that one operator log file exists for each node; it is not a shared 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.
Following are 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$ENABLE_LOGFILE_CLASSES is used. If that logical does not exist, all classes are enabled on the new log file.
6017P058.HTM OSSG Documentation 22-NOV-1996 14:22:42.09
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.