EVENT Configuration Syntax

The EVENT Configuration contains the settings for how EMS events are collected, stored and retrieved by the EMS Collector (STEMS).

If an active EVENT Configuration is present, then the PROGNOSIS Configuration settings of EMS-BACK, EMS-LOG and EVENTS will be ignored.
SUBSYS EVENT

COLLECTOR (<$collector-process>[, <filter-file, ...])
COLLECTOR CPU ({<$collector-process>|*}>, {<cpu-number>|#stemscpu})
EMS-BACK (<minutes>)
EVENTS (<number-of-events>)

Syntax Elements

COLLECTOR (<$collector-process>[, <filter-file, ...])

A COLLECTOR statement is used to define each EMS collector instance and its associated filter parameters. If no COLLECTOR statements are specified, then it defaults to monitoring $0 with no event filtration.

<$collector-process>

Specifies the EMS collector to be monitored. If a collector is specified and $0 is also to be monitored, then $0 must also be specifically included with a separate COLLECTOR statement.

<filter-file>

If specified, the filter-file parameter defines the name of a filter or set of filters through which events from the EMS collector process will be passed. The types of filters that can be used are those supported by the EMSDIST process, which are:

1) A filter object file compiled by EMF - file code 845

2) Burst Detection and Suppression text file(s) - BDS, file code 101

3) Filter table text file(s) - file code 101

If this parameter is omitted, then there will not be any event filtration (i.e. all events will be processed). When filters are specified the collector will determine if each filter file exists and that it is either file code 101 or 845. Filter file names must be qualified using the normal rules of file name volume and subvolume qualification (e.g. a file name of 'table1' assumes the Prognosis subvolume, etc.). However, the collector does not examine the filter file content. Moreover, if the filter file content contains errors, then the related EMSDIST process will process them and then pass them to the Windows Client or WVLOG as appropriate.

If one or more filter files are specified for $0, then the collector will automatically insert PRGNFLT (which resides in the Prognosis subvolume) as the first filter in the sequence, this is to ensure that Prognosis receives EMS events critical to its proper execution.

Examples:

  COLLECTOR ($0)

  COLLECTOR ($ZLOG,$data.filtvol.ftable1)

  COLLECTOR ($ACOL0)

  COLLECTOR ($ACOL1,filtvol2.table2,$system.sysflts.bds)

COLLECTOR CPU ({<$collector-process>|*}>, {<cpu-number>|#stemscpu})

The COLLECTOR CPU statement defines a specific CPU assignment for an EMSDIST process (associated with its target EMS collector process) to be started in. If present, then both the <$collector-process> and <cpu-number> parameters must be specified. If no COLLECTOR CPU statement is specified for a given collector, then the specified EMSDIST process will be started in the same CPU as the associated EMS collector (this behavior also applies if the target CPU is unavailable when the EVENT configuration is restarted).

<$collector-process> or *

Specifies the EMS collector(s) that will have a CPU assignment made. This parameter can be either a specific process name or an asterisk ("*") indicating all EMSDIST processes are to reside in the nominated <cpu-number>.

<cpu-number> or #stemscpu

This parameter specifies the CPU where the EMS collector is to start the EMSDIST process. This can be specified as a valid CPU number or as "#stemscpu' (case insensitive) which means that the EMSDIST process associated with the target EMS collector will be started in the same CPU as the EMS collector (STEMS).

Examples:

  COLLECTOR CPU (*,5)

  COLLECTOR CPU ($0,3)

  COLLECTOR CPU ($ZLOG,1)

  COLLECTOR CPU ($ACOL1,#stemscpu)

EMS-BACK (<minutes>)

The EMS-BACK statement specifies the number of minutes that the EMS collector will look back in the EMS logs (listed in COLLECTOR keywords) for EMS event information. The default is five minutes and the upper limit is 32767 minutes. Although the EMS event review process is optimized to reduce performance requirements, setting a large number of minutes in the EMS-BACK statement can impact system performance if the EMS log contains too many events.

Example:

EMS-BACK (10)

EVENTS (<number-of-events>)

The EVENTS statement specifies the number of critical and non-critical event messages to keep in memory, i.e. if this is set to 500, the collector will keep 500 critical events plus 500 non-critical events. The default is 50 and the maximum is 32767. Specify zero (0) to retain no events.

Example:

EVENTS (500)
For further details please refer to Automated EMS Log File Monitoring.

Provide feedback on this article