EMS Manual

Standard Events
EMS Manual426909-005
9-10
Underlying Philosophy of Standard Events
4. The operator corrects the problem. If the subsystem cannot detect the operator
has corrected the problem, it should provide an interface, like the command-
response interface, so the operator can notify the subsystem when the problem is
corrected.
5. The subsystem creates and sends the Operator Attention Completed event
message, specifying the completed service and the same ID as in the original
request.
6. The management application finds and dims the display of the outstanding
Operator Attention Needed event that matches this Operator Attention Completed
event.
Because the operator might overlook a displayed event message or, rarely, an event
message might be lost, the subsystem should reissue any Operator Attention Needed
event that is not attended to within an appropriate period of time. The operator treats
the old copy of the event as inactive so that only one Operator Attention Needed event
from the subsystem is active at a time.
Underlying Philosophy of Standard Events
All subsystems and applications should report and display certain conditions in the
system and event messages to support the management functions described in
Requirements for Standard Events on page 9-3. The conditions being reported are
indicated by the names of the standard events:
Object Available event
Object Other State Change event
Object Unavailable event
Operator Attention Completed event
Operator Attention Needed event
Transient Fault event
Usage Threshold event
An event message describes what happened in a system. The subsystem or
application that detects the condition formats and sends the event message to EMS,
which stores it in a log file. Management applications (including operators) use these
messages to determine what actions to take in managing the system.
An event message includes many kinds of information besides what happened.
Information generally found in every event message is:
Information about the message itself—a value identifying it as an event message
(as opposed to a SPI command or response message), a count of how long the
message is, and a timestamp indicating when the message was generated.