Document revision date: 19 July 1999

In addition to the qualifiers listed in Table 18-5, DECevent contains a set of DIRECTORY commands and a set of SHOW commands:

• DIRECTORY commands
  These commands allow you to display a list of rulesets that DECevent needs to translate events into a readable format. (A ruleset is a software routine or function that is analogous to an executable file.)
  The following DIRECTORY commands are currently implemented in DECevent:
  • DIRECTORY EVENT
    This command lists all rulesets associated with event translation.
  • DIRECTORY CANONICAL
    This command lists all rulesets associated with event reports.
• SHOW commands
  These commands allow a user to view specific settings and selections. The following SHOW commands are currently implemented in DECevent:
  • SHOW SELECT
    By appending a specific selection keyword name to the SHOW SELECT command, you view only that selection keyword.
  • SHOW SETTINGS
    By appending a specific setting's name to the SHOW SETTINGS command, you view only that setting's name and value.

This section contains examples of DECevent commands and reports.

18.5.5.1 Producing a Full Report

To produce a full report, use the /FULL qualifier. The full report format provides a translation of all available information for each entry in the event log. The full report is the default report type if a report type is not specified in the command line.

Both of the following commands will produce a full report format:

$ DIAGNOSE/TRANSLATE/FULL $ DIAGNOSE

(/TRANSLATE and /FULL are defaults.)

Example 18-1 shows the format of a full report.

Example 18-1 Full Report Format

******************************** ENTRY 1 ******************************** Logging OS 1. OpenVMS System Architecture 2. Alpha OS version V7.2 Event sequence number 1583. Timestamp of occurrence 18-APR-1998 09:21:18 System uptime in seconds 58004. Error mask x00000000 Flags x0001 Dynamic Device Recognition present 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 Entry type 100. 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 ---- IO SW Profile ---- VMS DC$_CLASS 1. VMS DT$_TYPE 175. ---- MSCP Logged Msg ---- 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 ****************************************************************************

18.5.5.2 Producing a Brief Report

To produce a brief report, use the /BRIEF qualifier. The brief report format provides translation of key information for each entry in the event log. For example:

$ DIAGNOSE/TRANSLATE/BRIEF

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.2 Event sequence number 1583. Timestamp of occurrence 18-APR-1998 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 *****************************************************************************

18.5.5.3 Producing a Terse Report

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.2 Event sequence number 1583. Timestamp of occurrence 1998041809211800 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 **********************************************************************

18.5.5.4 Producing a Summary Report

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-1998 09:21:18 DATE OF LATEST ENTRY 12-MAY-1998 10:44:54

18.5.5.5 Producing a Fast Error (FSTERR) Report

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 Compaq support representative to troubleshoot a problem with a tape or disk device.

18.5.6 DECevent Restrictions

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.

18.6 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	Section 18.6.3
Maintaining the operator log file	Section 18.6.4
Printing the operator log file	Section 18.6.5

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

18.6.2 Understanding OPCOM Messages

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.

18.6.2.1 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, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%% Logfile has been initialized by operator <terminal-name> Logfile is <logfile-specification>

Example

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

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

18.6.2.3 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-1998 10:25:35.74 %%%%%%%%%%%% Operator _ROUND$OPA1: has been enabled, username SYSTEM %%%%%%%%%%%% %OPCOM 19-APR-1998 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-1998 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.

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

	privacy and legal statement
6017PRO_081.HTML