Specifications

Patches Issued After the CS1/MMS1 Release
Software Superseded by CS3/MMS3 Software Release Notice for 5.0rev1
5-12 CS3 and MMS3
This has been resolved by building up the event filter object so that
the model handle filter node is at the base of the filter hierarchy with
the date/time filter nodes.
SPECTRUM_5.0rev1.P30
Unable to assert ORANGE alarm on DLCI_Port w/watcheditor
A threshold watch on a DLCI_port model type will not assert an
Orange alarm. It will assert a Yellow or Red but not an Orange.
sets to FRX dev is bringing down network
Models will now reg_watch_change after the first successful read of
the model's attributes. When a change does occur, the IH ensures that
a write is necessary by checking the current value of the external
attribute before writing.
FrameRelay DTE models were disappearing. Added code to check that
DLCIs are unique before attempting to shift the modeling.
SPECTRUM_5.0rev1.P31
Included in P34, P41, and P48.
SPECTRUM_5.0rev1.P32
After editing a policy, any attempt to exit the application causes it to
hang forever. It appears that this only happens after saving a policy,
not when just viewing them.
The issue is that when GET_EXISTING_ALARMS was set to “false”
in the .alarmrc and then AlarmNotifier was started, sometimes the
user would see alarms come through that had a time stamp of earlier
than when AlarmNotifier was started.
To resolve this, when AlarmNotifier makes the initial request to the
SpectroSERVER explaining what kind of alarms should be received, if
GET_EXISTING_ALARMS is false, a filter specifying
ALARM_DATE_TIME > (startup time) is added. With this filter added
to the criteria, even if an update on an existing alarm comes in, it will
not pass this filter and not be sent to AlarmNotifier. This seems to
work as expected. The additional filter is not added if
GET_EXISTING_ALARMS is true.