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
- 10
Specifies after how many sent messages the ASCII manager waits for an response from the
Event manager. The default value is 10. The ASCII manager waits for the answer of the
Event manager after 10 messages. The data is imported with the highest speed and the Event
manager is loaded the most.
1 means that the ASCII Manager waits for a response after each message and the load on
the Event manager is the lowest.
Values >1 offer 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.