OVNM 5.3 - Operations Agent for NonStop Event Management Guide for UNIX
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. 










