OVNM 5.3 - Operations Agent for NonStop Event Management Guide for UNIX

HP NonStop Event Management System 18
The exact contents of all messages generated by a subsystem are described in the management programming
manual for that subsystem (which is often a separate book with that title). For example, the event messages for
Pathway are described in the TS/MP and PATHWAY Management Programming Messages Manual. This manual
describes event messages for EMS itself.
Special Kind of Messages
There are two special categories of events:
• Critical events are indicated by assigning the value TRUE to the emphasis token.
• Action events are indicated by including an action-needed token.
Messages with neither of these indicators are reporting events that are neither critical events nor action events.
Subsystems rarely report an event that is both a critical event and an action event.
Critical Events
A subsystem designates an event as critical when the consequences of the event might be severe. The
subsystem itself cannot accurately determine what conditions you would consider severe for your particular
system or network.
For example, you might not consider loss of a rarely used data communication line between two test
systems a critical situation, but you would consider loss of a heavily used line between two production
systems as critical. These situations look identical to the subsystem. The best the subsystem can do is to
identify potentially critical situations and let you (with the help of programmatic tools you select) make the
final determination.
Subsystems typically identify these events as critical:
• Potential or actual loss of data
• Loss of a major subsystem function
• Loss of a fault-tolerance capability, such as a redundant resource or failure recovery function
• Loss of subsystem integrity (for example, an unrecoverable internal error in a subsystem)
To indicate a critical event, the subsystem assigns the value TRUE to the ZEMS-TKNEMPHASIS token. The
ViewPoint application highlights critical events in its event display. (For details, see the ViewPoint Manual.)
Action Events
A subsystem reports an action event when a situation arises that the subsystem cannot resolve without
operator intervention. For example, a subsystem might report an action event when it cannot proceed until
a tape is mounted or a printer ribbon is replaced.
Action events are reported in pairs of event messages. The first message, called an action-attention
message, reports the problem. The second message, called an action-completion message, reports that the
appropriate action has been taken. (In some cases, the subsystem can directly detect that the situation has
been corrected. In other cases, the operator has to inform the subsystem of the action taken.)
Action events are designated by the presence of the ZEMS-TKN-ACTION-NEEDED token:
• The value TRUE designates an action-attention message.
• The value FALSE designates an action-completion message.
Another token, ZEMS-TKN-ACTION-ID, should be included in each pair of action-attention and action-
completion messages with the same value in each message. (If the subsystem generates the completion
message, it includes the correct action ID automatically.)
The action ID lets the operator or management application retrieving an action-completion message,
identify the action-attention message to which it corresponds.
The ViewPoint application counts and highlights action-attention messages in its event display,
decrementing the count and dimming the message when the corresponding action-completion message is
retrieved. (For details, see the ViewPoint Manual.)