HP-UX Event ManagerProgrammer's Guide

4. Write a detailed description of each event for documentation purpose, and include
information about the following:
• What the event means
• When the event can occur
• Any actions the user or responsible subscriber must take in response to the event, and
• The contents of the event (particularly any variable data items)
The explanation text is usually captured in a catalog file and can be accessed for display.
For more information about explanation text, see “Writing Event Explanation Text” (page 24).
5. For each event, decide the data items that go into the template and the data items that are
coded by the poster. Except for the event name, all items in both posting code and templates
are optional. If an optional data item is declared in both places, the poster's declaration has
precedence. For information about templates, see “Designing Event Templates” (page 24).
For information about event items that are commonly posted, see “EVM Event Content”
(page 15). For information about how data items in templates and posted events are merged,
see “Merging Data Items from Templates and Posted Events” (page 26).
6. Decide whether the events must be internationalized. If so, choose a name for the I18N
catalog file and establish any required message sets within the catalog. For information
about internationalization of events, see “Establishing Translations for Event Text (I18N)”
(page 28).
Designers must recognize that an EVM event is an interface on which other programs or
subsystems may rely on. Therefore, once established, the interface must not be changed.
Deciding Which Status Changes are Eventworthy
The importance of an event can vary from application to application, and it may be difficult in
some cases to decide whether a status change recognized by your code is important enough to
communicate to others.
EVM recommends that you post events for the following types of occurrences:
• When a component makes a change to the system. For example, a System Management
program can post an event if it adds a new user to the system, or changes the network
configuration.
• When a potentially significant error occurs. For example, a System Management program
must post an event if it finds that a key system file is missing, and a Device driver must post
an event if it detects a disk failure.
• When a threshold limit is reached and a failure is likely to occur. For example, File System
Management software may post a warning event when it detects that a file system has
reached a threshold limit, and has become at least 95 percent full. However, you must avoid
posting repeated events of this nature if the state oscillates around the threshold limit. Your
code must typically post the same event again if the condition is still true after some preset
time interval has elapsed; even if the state has dropped below the threshold limit and
recovered several times within the time interval.
• When a user is granted a privilege or takes some action that affects the operation of the
system. For example, a System Management program may post an event when a disk is
mounted or unmounted, or when the system is closing down.
Do not post events for the following types of occurrences:
Designing a Set of Events 23