OVNM 5.3 - Operations Agent for NonStop Event Management Guide for Windows
HP NonStop Event Management System 14
Because the interfaces differ in purpose and use, they also differ in certain key characteristics:
• Initiator
In the command-response interface, the management application initiates communication with the
subsystem. The operator or management application also controls the flow of information, issuing the
commands necessary to accomplish the desired task.
In the EMS environment, the subsystem initiates communication, at least for reporting an event to EMS.
Although operators and management applications can control how much information they request from
EMS, they do not control the flow of information into EMS itself.
• Communication pattern (synchronous or asynchronous)
The command-response interface supports a dialog between a management application and a subsystem.
The management application starts a synchronous session with a subsystem by opening the appropriate
subsystem process and sending command messages. For each command, the subsystem returns a response
message. The management application and the subsystem communicate synchronously, in a one-command,
one-response dialog.
The EMS interface is unidirectional and asynchronous. Operators and management applications cannot use
EMS to send information to subsystems, and subsystems report event information regardless of whether or
not an operator or management application is interested in that information at the moment.
• Variable urgency
In general, commands are treated as equally urgent, in that each must be completed before the next one is
issued. The operator or management application determines what command to issue next. To the
subsystem, a request for status information is no less important or urgent than a request to stop all objects
immediately.
In EMS, although operators and management applications control the retrieval and use of EMS information,
subsystems can use certain EMS-defined conventions to convey significance or urgency. These conventions
are needed to emphasize certain conditions that the operator or management application might otherwise
not recognize as significant in the continuous flow of event information.
Because of its unique characteristics, the EMS interface is a valuable complement to the command-response
interface. The two interfaces together can provide a wide range of management services. For example, you
can use EMS to monitor a large array of subsystems. Then, when a significant situation arises, you can use
the command-response interface to initiate a dialog with the appropriate subsystem.
2-1-3 EMS Capabilities and Features
The primary function of EMS is to collect and distribute event messages. Event messages are a special category
of SPI messages used to convey information about events, which are significant occurrences in the subsystem
environment.
Event messages report many occurrences and conditions, such as:
• Changes in the subsystem environment
• Errors encountered during continuous operation (as opposed to errors encountered during an interaction
with a user or application, which are usually reported directly to the user or application)
• Conditions that might lead to a problem if not corrected
• Situations requiring operator intervention
• Significant losses of function or resources
• Indications of why a process terminated
Event messages can be reported by HP NonStop subsystems or subsystems you write. They are subsystem
specific, and hundreds of different event messages are produced by HP NonStop subsystems alone. Although this
wide range of messages provides the diversity and depth of information required to manage systems and
networks, it also creates the need for tools to manage the event messages themselves.