Settings for the ASCII Manager
[ascii] alwaysSendCommon
- Type
- bool
- Default
- false
- Range
- 0|1
The ASCII manager sends continuously the actual state of "description" and "alias" to
the event manager, even if it haven't changed. This option serves for actualization of
the entries in the database, if they couldn't be written (e.g. RDB breakdown), but they
changed in the meantime.
[ascii] commit
- Type
- uint
- Default
- 1
Defines after how many sent messages the Ascii Manager will wait for an answer from the
Event Manager. If set to 0, no waiting will be done at all. Messages will be sent to the
Event with maximum speed but it puts the highest load onto the Event Manager. If set to
1, the Ascii Manager will wait for confirmation after each message, which puts the least
load onto the Event Manager. Values >1 give a good compromise between import speed
and load on the Event Manager.
[ascii] forceScan
- Type
- bool
- Default
- 0
- Range
- 0|1
Defines the strategy when using Dp-Filters (-filterDp). If set to 0, a list of matching
dps will be generated before the database will be read. If set to 1, the whole database
will be read and a wildcard-match will be done with every DP element (which usually is
much slower).
[ascii] multiUserMode
- Type
- bool
- Default
- 0
- Range
- 0|1
If set to 1, the database will be opened in multi user mode, if 0 then in single user
mode. On Windows this entry is ignored and the database is always opened in multi user
mode.
[ascii] noAlertConfigHist
- Type
- bool
- Default
- 0
- Range
- 0|1
If this config entry is set to 1, alert configs will be imported without increasing the
RAIMA parameterization history. The alert configs are sent with a timestamp of 0 and
overwrite the previous entry of this config in the parameterization history. For the
same purpose, the manager command line option -noAlertConfigHist can be used. The
command line option has precedence over the config entry. If noAlertConfgiHist = 0 or
the option -noAlertConfigHist is not used the known behavior of the ASCII manager
remains, i.e. new alert configs will be created in the parameterization history.
