[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS System Manager's Manual


Previous Contents Index

18.5.4 Using Additional DECevent Commands

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

18.5.5 Producing DECevent Reports

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.


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6017PRO_081.HTML