Document revision date: 30 March 2001

## OpenVMS System Manager's Manual

Previous | Contents | Index

### 20.5.5 Producing DECevent Reports

This section contains examples of DECevent commands and reports.

#### 20.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/FULL

    $ DIAGNOSE

(/FULL is the default.)

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

Example 20-1 Full Report Format

    ******************************** ENTRY    1 ********************************

    Logging OS                        1. OpenVMS
    System Architecture               2. Alpha
    OS version                           V7.3
    Event sequence number          1583.
    Timestamp of occurrence              18-APR-2000 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
    ****************************************************************************

#### 20.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/BRIEF

Example 20-2 shows the format of a brief report.

Example 20-2 Brief Report Format

    ******************************** ENTRY    1 ********************************

    Logging OS                        1. OpenVMS
    System Architecture               2. Alpha
    OS version                           V7.3
    Event sequence number          1583.
    Timestamp of occurrence              18-APR-2000 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
    *****************************************************************************

#### 20.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/TERSE

Example 20-3 shows the format of a terse report.

Example 20-3 Terse Report Format

    ******************************** ENTRY    1 ********************************

    Logging OS                           1.
    System Architecture                  2.
    OS version                  V7.3
    Event sequence number             1583.
    Timestamp of occurrence     2000041809211800
    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

    **********************************************************************

#### 20.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/SUMMARY

Example 20-4 shows the format of a summary report.

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

#### 20.5.5.5 Producing a Fast Error (FSTERR) Report

To produce a Fast Error report, use the /FSTERR qualifier. For example:

     $ DIAGNOSE/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 20-5.

Example 20-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.

### 20.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.

## 20.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 20.6.3
Maintaining the operator log file | Section 20.6.4
Printing the operator log file | Section 20.6.5

### 20.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.

### 20.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 20.6.2.1
Device status messages | Section 20.6.2.2
Terminal enable and disable messages | Section 20.6.2.3
User request and operator reply messages | Section 20.6.2.4
Volume mount and dismount messages | Section 20.6.2.5
System parameter messages | Section 20.6.2.6
Security alarm messages | Section 20.6.2.7

Section 20.6.2.8 contains an example of typical kinds of messages found in an operator log file.

#### 20.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-2000 12:29:24.52  %%%%%%%%%%%
    Logfile has been initialized by operator _MARS$VTA2:
    Logfile is HOMER::SYS$SYSMOND:[SYSMGT]OPERATOR.LOG;43

#### 20.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.

#### 20.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-2000 10:25:35.74 %%%%%%%%%%%%
    Operator _ROUND$OPA1: has been enabled, username SYSTEM

    %%%%%%%%%%%%  %OPCOM 19-APR-2000 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-2000 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.

#### 20.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

| privacy and legal statement |
6017PRO_085.HTML