EMS Manual

EMS Components and Architecture
EMS Manual—426909-005
2-3
Special Kinds of Event Messages
Every event message includes an event number that uniquely identifies that type of
event message among all the types that the subsystem is capable of generating.
The event number is the primary indication of what happened (printer out of paper,
line down, takeover by backup process, and so on).
Also, every event message includes a subject: the name or number of the
hardware or software component most directly involved in the event. Beyond this
information, the subsystem usually includes relevant details, such as error codes,
disk addresses, pool sizes, or whatever information might serve to explain the error
further.

Additional context
Because an event message might be examined long after the event it is reporting
occurred, the subsystem sometimes includes details about its environment, such
as the active path to the device or the name of a file or process it has open, even if
the path, file, or process is not directly involved in the event. This contextual
information can help you when analyzing a problem to link seemingly unrelated
event messages into a meaningful pattern.
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 Management Programming manual and Pathway Management Programming
manual. This manual describes event messages for EMS itself.
Special Kinds of Event 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 critical. These situations look identical to
the subsystem. The best the subsystem can do is identify potentially critical situations
and let you (with the help of programmatic tools you select) make the final
determination.