Envoy Application Programming Manual

Application Programming With Envoy
Envoy Application Programming Manual—427159-001
1-6
Event-Management Interface
As shown in Figure 1-4, SCP sends each Envoy command to the appropriate process.
Management applications send programmatic commands formatted as SPI buffers, and
receive responses from the subsystem in the same format.
In addition to communicating with SCF and your management application, TSM
communicates with Envoy through the SCP process. TSM is an online diagnostic system
that analyses the activity of hardware devices, such as those used with Envoy. For an
overview of TSM, refer to TSM Manuals and Online Help
.
Event-Management Interface
Envoy subsystem processes generate event messages when they detect significant events,
such as a trap caused by a hardware or software error, a failure to establish
communications on a line, or a timeout counter that reaches its threshold. The subsystem
processes send these event messages in SPI format to the Event Management Service
(EMS), which makes them available to management applications upon request.
EMS collects, logs, and distributes event messages that provide information to help you
monitor the network environment, analyze failures, and recognize and handle critical
problems.
See the Operator Messages Manual for a detailed description of the contents of the
event messages that the Envoy processes can issue.
Figure 1-5
on page 1-7 shows the event-management interfaces to Envoy. The activities
that occur during event management are:
1. An event occurs in the subsystem environment.
2. A subsystem process reports the event by sending an event message, formatted as an
SPI buffer, to the local EMS collector. Note that these processes send event
messages directly to the collector, not through SCP.
3. The collector stores the event message in a disk file called the event log.
4. If a forwarding distributor is present, this distributor forwards the event message to a
collector on a remote node. The remote collector stores the message in an event log
on its own node, so that the message exists on both nodes.
5. An application installs an EMS filter that specifies the event messages that the
application wants to receive. (Filters are optional, but recommended. If no filter is
installed, all event messages will be delivered to the application.)
6. The application can then open an EMS consumer distributor and request an event
message.
7. The distributor reads the log and returns to the application the next event message
that satisfies the conditions of the filter.
8. The application can present the message to the operator or take action itself.