OVNM 5.3 - Operations Agent for NonStop Object Configuration Client Guide

Object Configuration Client: The Understanding 50
Process Until Burst
Use this option if you want the first EMS message to cause an email, recovery or message sent to
Console and the Enterprise Management system (such as HPOM). This option will process every EMS
message until the burst is detected.
Ignore Until Burst
Use this option if you do not want any of the EMS messages processed at all until an excessive number
of them are seen. For example, if an application generates error messages occasionally, and you
don’t care about them until more than 100 of them are generated in short time duration, then you
would use this option. Using this option will prevent emails, recoveries and messages to Console and
the Enterprise Management system until an excessive number are consumed.
Burst = x events within y minutes
This is the actual burst definition. This describes how many events in what time frame need to be
consumed before a burst is declared as active.
Event Subject
• BLANK
If you leave this field blank, the burst detection logic will not consider the value in the subject of the
EMS message when creating ‘burst threads’. In this case, all events from the same SSID, regardless
of the subject will be counted towards the burst. The ‘subject’ of an EMS message is defined as the
one with the ‘subject token’ marker. For example, TANDEM.PATHWAY TCP stop EMS messages
will contain the name of the TCP as the subject. You must determine what the subject of an EMS
message is before using this feature – some applications do not use what you might expect to be
the subject. To determine the token that contains the subject marker, you can use EMSA, or some
other utility that shows the subject marker.
• ASTERISK
If you enter an asterisk, you are asking OVNM to maintain separate burst threads for each unique
subject. So if Pathway generates 100 TCP down EMS messages, one for each TCP, then OVNM
will create 100 burst threads, each with a count of one event. Therefore, no burst will be detected,
since only one EMS message was consumed for each individual subject.
• A SPECIFIC VALUE
If you enter a specific value here, only the EMS messages that also match the subject you specified
will be considered when deciding if there is a burst.
Reset
This is used to define when the burst should be considered as expired. Once a burst has been
detected, no more EMS messages will be processed until after the amount of time defined in this field.
The start of the burst will be defined as the EMS generation time of the first EMS message that is part of
the burst criteria. So if the burst is defined as 5 messages in 5 minutes, the reset time is defined as 30
minutes, and the very first EMS message is generated at 12:00, 2 more at 12:02 and 2 more at 12:03
(5 total), the reset time will be at 12:30 – 30 minutes after the first message that was part of the burst
criteria. Using the same burst criteria, if a message was consumed at 12:00, 12:01, 12:02, 12:04,
12:06, 12:08, 12:09; 12:10: 12:10, then the first message that is part of the burst will be at 12:06,
the burst detected message would be generated at 12:10 (the second 12:10) and the burst will be
‘over’ at 12:36.
Generate start/end EMS burst notification messages
If this check box is checked, then both ACC ($OVOCC) and EMON ($OVEMN) will generate EMS
messages when they detect a new burst and when the burst expires. If this box is not checked, then these
messages will not be generated by OVNM.
Object Configuration Client:
The Understanding