HP NonStop G-Series - Manual (Page 119)

Appendix L: EMS Burst Suppression 119
BURSTLINKCOUNT is used to define the number of entries in the burst link list table. For each unique Burst
Thread, an entry will be added to the burst link list for each EMS message received before the burst is
declared. These entries are rather small and consist of the time that the EMS message was generated. So if
you expect 20 individual burst threads, and each of your EMS threshold eBurst definitions say that the burst
requires five messages, then this value will have to be at least 100 (20 * 5). If this table fills up, OVNM will
generate EMS Event 143 “Burst Link List Table is full. Increase BURSTLINKCOUNT."
When setting the values for THREADTABLECOUNT and BURSTLINKCOUNT you should always leave plenty
of extra room. If either of those tables becomes full, the burst definition feature may not work properly.
BURSTCLEANUP-INTERVAL is used to tell OVNM how often to spin through the various tables to delete
entries that have expired (are longer than the burst reset time or the “within” time of the burst definition).
The default for this parameter is 1 hour (60 minutes). The value you specify here is in MINUTES. When this
timer expires, OVNM will spin through all the burst tables and delete any entry that is no longer required. It
will also check to see if there are any active bursts whose Max Burst Reset time has been exceeded. If so,
that burst will be reset (and the end of burst message will be generated). Cleaning up the old entries will
make room for new entries. This is really only important when events are consumed that are potential burst
messages. When they are consumed, they will take up entries in these tables. If OVNM never sees them
again, this is the only way to delete those entries.
There are other parameters that can help improve the efficiency of OVNM as it processes EMS thresholds.
EVENTRULEFILEREADLEVEL is a flag that signifies whether or not OVNM should maintain the contents of the
EVNTRULE File in memory. This is the file that describes the EMS thresholds and is linked to the Burst
Definition records. If this is not in memory, then every time an EMS message is received, OVNM must read
this file to determine if the EMS message should be processed any further.
EEVENTSFILEREADLEVEL provides the same function for the eEvents file. This is the file that contains the data
from the eEvents panel in the OCC.
When the memory feature is turned on, then changes to these files will NOT be recognized by OVNM for
a period of time after the change was made. This is coded this way to reduce the likelihood of reading
these files into memory multiple times as you are making updates. A parameter (UPDATE-WAITTIME-MINS)
can be modified to adjust the wait time between the time the last update was made and when OVNM will
re-read the files into memory. OVNM will re-read the file into memory once that number of minutes has
gone by with no additional changes. In other words, if this is set to 5 minutes (the default), and you make a
change every minute for 10 minutes, OVNM will not re-read the file until 15 minutes have expired since the
first update – which is 5 minutes after the last update. With the default value, there will be at least a 5
minute delay between the time a record is changed and when OVNM recognizes the change. You can set
this lower if you want, but if you set it too low, then OVNM could end up reading the file before you are
actually done with your changes, causing it to re-read the file multiple times. If you do not have very many
eEvents or EVNTRULE records, then it may make more sense to have a very small value (1 minute). If you
have 1000’s of records, then you will want a higher value to limit the chances of re-reading the file multiple
times. When making changes to this parameter, you need to add the SET statement between the
CUSTOMER CHANGES #1 lines. If you make it to the SET statement that is already in the
OCCCONF/OVNMCONF file, then the next time a change is made via the HIC or ALTROVNM, your
change will be lost.
When the BURSTDEF file is re-read into memory, all information regarding bursts is lost – everything is reset
to zero, so you will want to be careful when making changes that impact the BurstDef file. When this
happens, OVNM will generate EMS Event 148 “Reloading burstdef file – all burst info will be reset”. In
addition, any existing burst will end, but no ‘expired’ message will be generated – the internal tables are
not reviewed before wiping them clean.
If you have checked the “Generate start/end EMS Burst notification messages” check box in the eBurst
panel, then OVNM will generate messages whenever a burst is detected and when the burst has expired
(exceeded the reset time specified). Some of these messages will also include the number of messages that
were suppressed. When it is a “process until burst”, only the burst-expired EMS message will contain the
number of messages suppressed. For “ignore until burst”, both the ‘burst detected’ and ‘burst expired’
messages will contain the number of messages suppressed. This counter is reset whenever the EMS
message is displayed and whenever the BURSTDEF file is re-read into memory.
When the burst is detected, OVNM will generate event 146 (for process until) or 147 (for ignore until). The
message will look like one of the following:
Process Burst Detected SSID/Event: TANDEM.PATHWAY.D44/1043 Subject: TCP1
Ignore Burst Detected - Suppressed 9 events. TANDEM.PATHWAY.D44/1043
Subject: TCP1
A
pp
en
di
x L