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

HP NonStop Event Management System 17
2-2 EMS Components and Architecture
This section describes the processes, files, and interfaces that together provide the event management capabilities
described in Introduction to EMS section.
Before working with the process architecture, you must understand more about event messages because they are
what EMS exists to manage.
2-2-1 Event Messages
Event messages are based on tokens that convey information about events, which are significant occurrences in
the subsystem environment.
Because of their token structure, event messages are much more convenient and efficient for applications to
process than text messages. Information is easier to find and in a more convenient form. Character-by-character
scans or conversions to internal form—typically required by text messages—are not required by event messages.
In addition, EMS provides facilities that derive display text from message tokens. Therefore, with EMS, event
information can be presented both to operators and to applications in the format most appropriate to each.
Another advantage of event messages is that they are subsystem specific, so the information they contain can be
tailored to provide an exact and complete specification of the event circumstances.
Before EMS, the NonStop Kernel supported only text messages (numbered and unnumbered console messages).
These messages are still supported for the benefit of subsystems and applications that have not yet migrated to
EMS. These messages have the subsystem ID of EMS and have event numbers in the range 1 through 512.
2-2-2 Information Contained in Event Messages
A subsystem generates an event message whenever it detects a significant occurrence. The subsystem sends the
event message to EMS, which stores the event message indefinitely (depending on how long the log files are
kept).
An event message includes many kinds of information besides what happened, such as:
• Information about the message itself
For example, the message contains a value identifying it as an event message (as opposed to a command
or response message), a count of how long the message is, and a time stamp indicating when the message
was generated.
• Information about the subsystem reporting the message
All event messages include a subsystem identifier, process identifiers, and other relevant information about
the creator of the message.
• Information specifying how the message should be handled
EMS includes some conventions that determine how each message is interpreted after it is reported. These
conventions, triggered by certain token values, include whether the message is critical and whether
operator action is required.
• Information about the actual event (occurrence)
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.
HP NonStop Event Management System