Specifications

9032277-04 Software Superseded by CS3/MMS3
5-19
Patches Issued After the CS1/MMS1 Release
If a customer has added notes or status to and existing alarm in Alarm
Manager, the new changes are not reflected in AlarmWeb view when
they happen, although the html files are being updated when the
changes happen. The problem is that the pages are being cached in
Netscape. This has been resolved by changing the pages so that they
are not cached.
Alarm Manager is crashing intermittently and no core file is being
generated. A bad alarm node is in the table which causes the sorting
code to compare bad data and therefore crash. The bad alarm node is
in the table because an update occurred with both an ADD and a
MODIFY. The same could occur if a REMOVE and a MODIFY came in
on the same update. This has been resolved by making sure the bad
data does not get in the table and by adding additional error checking
to the sorting code to guard against crashes like this in the future.
When suppressing secondary alarms in AlarmWeb it cores. The
"showSecondaryCount" preference is not being registered for in Web
Alarm View because it is not used or needed. However, this preference
is being checked when filtering out suppressed alarms. The preference
is being retrieved and a test is being done to insure it is registered;
then it is accessed. Since it was not registered for in Web Alarm View,
the value being retrieved is NULL and hence the crash. This has been
resolved by checking to see if the preference was registered.
Over several days, Web AlarmView will consume memory until it
crashes. This was resolved by keeping a list of the event nodes used in
creating the historyDataList. This solution only affects users of the
history API.
(Also refer to the Notes on corrected anomalies, on Page 5-14.)
SPECTRUM_5.0rev1.P46
This patch number was not used.
SPECTRUM_5.0rev1.P47
Included in P48 and P51.
(Also refer to the Notes on corrected anomalies, on Page 5-14.)
SPECTRUM_5.0rev1.P48
Included in P51.