|
HP OpenVMS Systems Documentation |
|
OpenVMS System Manager's Manual
20.5.5 Producing DECevent Reports
This section contains examples of DECevent commands and reports.
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:
(/FULL is the default.) Example 20-1 shows the format of a full report.
20.5.5.2 Producing a Brief ReportTo 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:
Example 20-2 shows the format of a brief report.
20.5.5.3 Producing a Terse ReportTo 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:
Example 20-3 shows the format of a terse report.
20.5.5.4 Producing a Summary ReportTo 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:
Example 20-4 shows the format of a summary report.
20.5.5.5 Producing a Fast Error (FSTERR) ReportTo produce a Fast Error report, use the /FSTERR qualifier. For example:
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:
A Fast Error report is shown in Example 20-5.
The Fast Error report includes the information needed by a Compaq
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. 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. DECevent does not translate as input any logical defined as a search list of file names. For example:
DECevent does not automatically purge log files. Set the version limit on the files and directory to your preference. For example:
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.
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:
20.6.1 Understanding the Operator Log FileThe 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.
The following sections describe the types of messages that appear in the operator log file.
Section 20.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:
20.6.2.2 Device Status MessagesSome 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:
This message can appear for card readers, line printers, and magnetic
tapes.
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. 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:
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 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. 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:
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:
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:
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. The following table contains 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.
|