Specifications

9032277-03 Software Superseded by CS2/MMS2
5-15
and some default values, for unsuccessful attributes. The result of such a
capture operation is "NON_FATAL_ERROR". This does not prevent writing
the configuration to database and also shows up as successful, but sends an
event to the SS indicating capture “not successful.” This is how this will work
now:
The capture detail window indicates status, which could be either success,
partly successful, or failed
In all cases, the capture detail window shows the result of each attribute
captured, and the configuration is written to the server.
In the event of partial success, an additional event is posted to the SS. A
new CsEvFormat file (Event00820012) has been added for this purpose.
However no alarm is generated.
A few non-critical problems that show up:
a. When capture reports failure, a pop-up dialog box shows up a
message “Error capturing configuration from?" This message can be
safely ignored.
b. In the event of partial success of a configuration, the host
configuration (in cisco routers) is not captured at all. Once more this is
not important, as in any case, one of solutions was to "not write the
unsuccessful configurations to the server".
(Also refer to the Notes on corrected anomalies, on Page 5-12.)
SPECTRUM_5.0rev1.P45
When opening an Enterprise Alarm Manager, the application retrieves the
current list of alarms, but it never updates this list subsequently - it remains
static until the alarm manager is restarted. If multiple alarm managers are
running, they'll show different lists of alarms. The problem stems from sounds
turned on for the Alarm Manager but the sound function not working on the
system. The resolution is to add code from Sun to work around the threading
problem and to delete the object that does the threading when disabling the
sound.
WEB Alarm View sorting on day instead of date. This is because the sorting is
done on the date/time string instead of the date/time value. This has been
resolved by changing the sort to sort on the date/time value.
AlarmView retains all the event, location, pcause information of a selected
alarm after clearing all alarms. This only occurs in the Events and History
tabbed pages. This scenario occurs when the event and/or history request has
not yet completed and all alarms in the view are removed. When the callback
for the event/ history data finally occurs, it fills in the tabbed pages as if the
alarm were still displayed. This has been resolved by checking to see if the
alarm has cleared before displaying the data.
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.