EMS Manual

Event Routing
EMS Manual—426909-005
16-2
Formatting Selection
The startup failed event contains a special token, ZEMS-TKN-STARTUP-LOGTIME,
which is set to the log time retrieved from the event that the distributor could not send.
When the next event trigger occurs for this destination, the distributor attempts to start
the process again. If it fails, the event is skipped, but no messages are generated. If
eventually the startup succeeds, a message is sent to the OUT device indicating that
the process launched. An event (ZEMS-EVT-STARTUP-OK) is also generated. It
contains a token (ZEMS-TKN-STARTUP-LOGTIME) with the log time of the event to be
forwarded to the destination. To determine which events were not forwarded, examine
the ZEMS-EVT-STARTUP-FAILED and ZEMS-EVT-STARTUP-OK messages.
If the distributor cannot start or restart a destination, it retries after 10 seconds. If the
retry fails, a message is sent to the OUT device indicating that the startup has failed.
An event (ZEMS-EVT-STARTUP-FAILED) is also generated and sent to a user
selected set of destination collectors; for instance, $0 or $ZLOG. These collectors are
selected using ADD DEFINE. For details, see User Interfaces on page 16-3.
If the distributor cannot write an event to an existing destination, it retries every two
seconds until a configurable time limit is reached (the default is two minutes). This
time-out can also occur if the intended recipient of the event does not acknowledge the
request by reading its $RECEIVE file. In either case, to prevent flooding of the event
log, a message is generated when the first timeout occurs and after 24 hours if retries
are unsuccessful. The event (ZEMS-EVT-WRITE-FAILED) contains a counter (ZEMS-
TKN-WRITE-FAIL-COUNT) with the number of timed out write operations that occurred
during the 24 hours. When the first timeout is detected, the event reports a fail count of
one (1). After a timeout, the current event is skipped.
If a write error occurred, it is reported the first time it is encountered.
Formatting Selection
You can configure a routing distributor to send events formatted or unformatted; that is,
it functions either as a printing or forwarding distributor, with the difference that events
can be sent to a set of targets that are selected dynamically. For formatted events, you
can also configure some other formatting attributes such as record length (number of
columns) and indentation.
Multiple Filters
To allow filter tables and burst filters in conjunction with compiled filters, and to
minimize maintenance cost and effort, the distributor supports loading of multiple
filters. Decide how many destinations a specific filter will support; for instance, TMDS
plans to collect separate filters from each group that is responsible for a particular fault
analyzer. This way, there is no problem with merging filter sources for different fault
analyzers; however, there might be a slight overhead in executing multiple filters. They
are executed one after another, and each filter's exit conditions such as PASS/FAIL
and routing IDs are preserved. You can specify filter file names in the startup line or as
multiple objects in a SPI command. If parameters are required for more than one filter,
you must submit them all as one set. Parameters can be shared among filters.