Specifications

Patches Issued Since the CS2/MMS2 Release
Software Superseded by CS3/MMS3 Software Release Notice for 5.0rev1
5-50 CS3 and MMS3
SpectroSERVERs as well. To test the the primary/backup switchover
they did the following:
a. brought down the MOM SpectroSERVER
b. watched as the secondary SpectroSERVER took over
c. brought back the MOM SpectroSERVER and saw the map storm
d. If the mapstorm in the previous step occurred - the
e. If the mapstorm in the previous step occurred - the AlarmNotifier
did not connect successfully.
The resolution to these problems was first to make sure the backup
SpectroSERVERs hostname was added to each landscapes host list.
Second, the map storm messages we're being seen because the map
storm parameters were set conservatively so that natural sequences of
updates we're being mistaken for storms. The detection parameters
were tweaked and the false storms are not being reported anymore.
And third, the timeout of the AlarmNotifier was customized to be 60
seconds versus five or 30 seconds.
--
The problem was that a customer had 22 different distributed
SpectroSERVERs, all with individual AlarmNotifiers running and
individual policies setup. The customer said that the policies were
being changed all the time so the needed functionality to accommodate
the following scenario:
Set up two distributed SpectroSERVERs, serverA and serverB, and
have distinct policies set up for each, policyA for serverA and policyB
for serverB. Then set up two different applications (AlarmNotifiers)
associated to the respective policies, AlarmNotifierA and
AlarmNotifierB.
If AlarmNotifierA is started on serverA and AlarmNotifierB is started
on serverB, and then a change is made to the respective policies on
both policyA and policyB on the respective SpectroGRAPH of each
server (serverA for policyA and serverB for policyB). AlarmNotifierA
on serverA performs correctly and updates the already running
AlarmNotifierA dynamically. However, AlarmNotifierB on serverB
does not update correctly and it is necessary to bounce (stop and start)
AlarmNotifierB (with theGET_EXISTING_ALARMS=true in the
.alarmrc file) in order for it to take into account the new alarms.