Filter File

The filter file defines which system event messages are sent to Operations Sentinel. A default filter file is included with the interface software release. Use the default filter file or change it to satisfy your site’s specific requirements.

The filter file contains a list of Major type, Minor type SUMLOG message identifiers. The corresponding message events are captured by the interface software on the host system and sent to Operations Sentinel in real time. This file enables your site to define the messages that it wants to monitor. The default name of the filter file is D/SINGLEPOINT/FILTER. The name of the filter file must appear in the configuration file.

You can use a file with a different name for the filter file. If you do, you must change the filter file name in the configuration file. After you change the name, you must terminate execution of the interface software and restart it for the change to take effect. See 3.4 for a description of how to initiate and terminate the interface software.

You can change the parameters loaded from the filter file dynamically. See Section 5. To make permanent changes, edit and replace the file. The new file must be loaded using the RELOAD command.

Nonexistent combinations are ignored. The interface software does not attempt to check types when loading the filter file.

To avoid run-time faults, the interface software checks for a valid integer in the legal range, as defined in the ClearPath Enterprise Servers System Log Programming Reference Manual. Possible errors include a noninteger type, a major type greater than 4095, or minor type greater than 65535.

If the interface program cannot reload the filter file, it displays a message on the operator’s ODT stating that the file is not available and that the default filters have been assumed (no file is loaded). The program then continues executing.

Loading of the filter file can cause the following messages to be displayed.

If no valid filter types are found in the filter file:

<<ASPO>> NO VALID FILTER TYPES FOUND IN FILTER FILE.

If default filter types are loaded:

<<ASPO>> LOADING DEFAULT FILTERS.

Normal filter file load messages:

<<ASPO>> START OF FILTER FILE LOAD.
<<ASPO>> END OF FILTER FILE LOAD.

If the filter file is loaded with the RELOAD command:

<<ASPO>> START OF FILTER FILE LOAD.
<<ASPO>> END OF FILTER FILE LOAD.

Following is the format of the filter file. The major-type,minor-type identifiers determine the types of messages that are to be monitored:

FILTERTYPES
major-type,{minor-type|ALL} [LOG_COMPATIBILITY {1|2}]
.
.
.
ENDFILTERTYPES

The FILTERTYPES and ENDFILTERTYPES statements must be included in the sequence shown in order for the filter file to load properly.

Each line between FILTERTYPES and ENDFILTERTYPES can optionally include the phrase LOG_COMPATIBILITY {1|2}.

Log Compatibility Option

Any line that includes major-type,minor-type, or major-type,ALL can also include one of the following options.

LOG_COMPATIBILITY 1
LOG_COMPATIBILITY 2

LOG_COMPATIBILITY 1 instructs the interface software to send the log entry message in a form that is compatible with levels prior to level 2.0 of the interface. If the log type was not supported prior to level 2.0, the option LOG_COMPATIBILITY 1 is ignored. If the log type was supported prior to level 2.0, LOG_COMPATIBILITY 1 is the default.

LOG_COMPATIBILITY 2 instructs the software to send the log entry message in Job Formatter format. If the log type was not supported prior to level 2.0, LOG_COMPATIBILITY 2 is the default and is the only meaningful option for this release.

For example, the line

14,ALL LOG_COMPATIBILITY 2

instructs the interface software to send all messages with major type 14 to Operations Sentinel in Job Formatter format.

Refer to 3.5.2 for a listing of the Major and Minor types that are in the filter file supplied in the release of the interface software. These are also the log types that were supported prior to level 2.0, and as such are the log types for which LOG_COMPATIBILITY 1 is the default. These types are also described in 6.3.2.