EMS Subsystem

The Event Management System (EMS) retrieves and reports on system events. An event is any significant occurrence in the system environment. Event messages are based on tokens that define information about events. The information can be used to:

Monitor the system or network environment

Report and research system problems

Report and analyze changes in the run-time environment

Caution

The EMS log is similar to a UNIX syslog.

EMS provides facilities that derive display text from message tokens so that EMS information can be presented both to operators and to applications in the format most appropriate to each.

EMS messages are subsystem specific, so the information they contain can be tailored to provide an exact and complete specification of the event circumstances.

There are three categories of events:

Critical

Action

Informational

Critical Events

A subsystem will designate an event as critical when the consequences of the event might be severe. The subsystem itself cannot accurately determine what conditions should be considered severe for a particular system or network.

Subsystems typically identify these events as critical:

Potential or actual loss of data

Loss of a major subsystem function

Loss of a fault-tolerance capability, such as loss of a redundant resource or loss of a failure-recovery function

Loss of subsystem integrity (for example, an unrecoverable internal error in a subsystem)

Action Events

A subsystem reports an action event when a situation arises that the subsystem cannot resolve without operator intervention. For example, a subsystem might report an action event when it cannot proceed until a tape is mounted or a printer ribbon is replaced .

Action events are reported in pairs of event messages:

The first message, the action-attention message, reports the problem.

The second message, the action-completion message, reports that the appropriate action has been taken.

EMS Components

The EMS Subsystem is made up of the following components (See Figure 6-5):

Event Message Collectors

Event Message Distributors

EMS Filters

EMS Object Files

EMS Utilities

RISK The EMS subsystem is used for reporting only. It does not pose any security risks.

Figure 6.5: EMS Components

Event Message Collectors

The Collector processes accept event messages from subsystems and logs them.

There is always one primary collector. System managers can define one or more alternate collectors. Both the primary and alternate collectors provide:

Subsystem support

Pre-log filtration (PLF)

Log file management

Distributor support

Pre-log filtration makes it possible to detect and discard all event bursts with specified attributes or specific unwanted events.

Primary Collector ($0)

Each system (or node) has only one primary event message collector, named $0. It is initiated at system generation, and provides a central collection point for all events from all subsystems in a system.

It uses the $ZOPR process to perform waited operations. It has no user interface.

$ZOPR exists on every node and is initiated at cold load.

Alternate Collectors

One or more alternate collectors can be started on a system.

Alternate collectors offer an alternative to the central collection point provided by the primary collector, $0. The separation of events into several log files speeds up event processing because a network application program does not have to read a single large file containing many events unrelated to that application

Each alternate collector maintains its own log files in a structure identical to that of the primary collector.

Alternate collectors are started with a TACL RUN command. They have user- defined process names .

Event Message Distributors

The Distributors filter event messages and return selected messages to the operations environment. Distributors have three basic functions:

Accessing one or more log files

Filtering event messages

Routing the selected event messages to the appropriate destination

Depending on the nature of the destination, one of four types of distributors can be used:

Consumer Sends selected event messages to a requesting management application.

Forwarding Sends selected event messages to an EMS collector on another node in the network or to an alternate collector on the same node.

Printing Obtains formatted text for selected event messages and writes it to a printer or other display device, or to a file. When a routing filter is used, unformatted events can be routed to selected distributor processes.

Compatibility Filters event messages according to a fixed (rather than a user- specified) criterion, obtains formatted text for the selected primary collector event messages, and writes it to a console device.

Compatibility Distributor ($Z0)

The Compatibility Distributor facilitates viewing console messages during cold loads. $Z0 is the only method available to view these messages.

There is only one Compatibility Distributor per system and it must be configured during SYSGEN.

The Compatibility Distributor has no interactive or programmatic command interface. It is controlled indirectly via commands to the primary collector, which can change certain parameters that affect the Compatibility Distributor. $Z0 can be stopped with the EMSCCTRL facility.

EMS Filters

EMS Filters are used to select the messages that are sent to various EMS Logs. Each EMS collector can use one or more filters, which can be customized to filter out all events of a certain type or from a certain application.

There are three types of filters:

Compiled Filters Compiled filters are created in EDIT files using the Event Management Service filter (EMF) language and compiled.

Filter Tables Filter tables are EDIT files that can be loaded into a collector or distributor, which then automatically converts it into an object representation that is then evaluated for each event processed by a collector or distributor.

Burst Filters Burst filters are used to suppress EMS messages when duplicate messages arrive in a short period of time.

EMS Object Programs

Two object files are used to start EMS:

EMSACOLL The EMSACOLL (EMS Alternate Collector) starts an alternate collector when invoked by a TACL RUN command.

EMSDIST The EMSDIST (EMS Distributor) is the object program for starting printing distributors, forwarding distributors, or consumer distributors.

EMS Utilities

These utility programs are provided as part of the EMS Subsystem. They are used for interactive queries and controlling collectors and distributors.

EMSCCTRL The EMS Collector Control is used to change the parameters that control the primary collectors and the compatibility distributor.

EMSCINFO Displays event-message statistics and collector status and configuration.

Securing EMS Components

BP-FILE-EMS-01 EMSCCTRL should be secured "UUNU".

BP-OPSYS-OWNER-01 EMSCCTRL should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 EMSCCTRL must reside in $SYSTEM.SYSnn.

BP-PROCESS-EMSACOLL-01 $ZPHI process should be running.

BP-FILE-EMS-02 EMSACOLL should be secured "UUNU".

BP-OPSYS-OWNER-01 EMSACOLL should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 EMSACOLL must reside in $SYSTEM.SYSnn.

BP-FILE-EMS-03 EMSDIST should be secured "UUNU".

BP-OPSYS-OWNER-01 EMSDIST should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 EMSDIST must reside in $SYSTEM.SYSnn.

BP-FILE-EMS-04 EMSCINFO should be secured "UUNU".

BP-OPSYS-OWNER-01 EMSCINFO should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 EMSCINFO must reside in $SYSTEM.SYSnn.

	Discovery Questions	Look here:
PROCESS-EMSACOLL-01	Is the $ZPHI process running?	Status
PROCESS-ZOPR-01	Is the $ZOPR system process running?	Status
OPSYS-OWNER-01	Who owns the EMSCCTRL file?	Fileinfo
OPSYS-OWNER-01	Who owns the EMSACOLL file?	Fileinfo
OPSYS-OWNER-01	Who owns the EMSDIST file?	Fileinfo
OPSYS-OWNER-01	Who owns the EMSCINFO file? Fileinfo
FILE-POLICY	Who is allowed to use EMS on the system?	Policy
FILE-EMS-01	Is the EMSCCTRL file secured correctly?	Fileinfo
FILE-EMS-02	Is the EMSACOLL file secured correctly?	Fileinfo
FILE-EMS-03	Is the EMSDIST file secured correctly?	Fileinfo
FILE-EMS-04	Is the EMSCINFO file secured correctly?	Fileinfo

Related Topics

EMSA