Specifications

Software Superseded by CS2/MMS2 Software Release Notice for 5.0rev1
5-6 CS2 and MMS2
SM-COMRPTR, SM-GENTR, SM-COMMAN, SM-GNBDG, SM-GNRTR1, SM-
MMSW, seh, SM-CSI1000 and SM-TRHUBSTK.
Not all DLCI port models appearing on Rtr_Bay_Wflet DTE. The user is
unable to edit a default SpectroWATCH off of the DLCI_Port model type.
Destroying any model after performing a find_attr_by_oid crashes the
SpectroSERVER.
Purify reports leak in CsIHLostAndFoundDestroy::do_destroy.
SpectroWATCH calculation causes erroneous overflow error.
Cisco routers don't send link up event to clear link down alarm.
SpectroSERVER crashes due to problems with SpectroWATCH.
Other Resolutions Included in CS1/MMS1
The following additional problem resolutions were incorporated into the CS1/
MMS1 software and are being superseded by the CS2/MMS2 software.
1. Incorrect SpectroWATCH formulas for PacketRateIn and PacketRateOut
2. Cleaned up memory leaks in ECM
3. Support was added for an indirect Component OID specification attribute.
A 3Com device for which a MM is now being developed does not support a
standard table of Board.Ports. The instance IDs of the ports are generated
randomly by the device and it is up to the MM developer to translate them
into standard Board.Port (e.g. 1.1 1.2 1.3 etc...) mappings. This value is
stored in a separate attribute created by the MM developer to be displayed
on icons for numbering boards and ports in the UI. The problem is that the
ordering done for the chassis view is based on the Component_OID
attribute value of the ports. Here is an example:
Component_OID (randomly assigned by device) Actual Board.Port
===============================
As you can see, if we order the ports by the randomly assigned
Component_OID value in the device's MIB, the ports will NOT be ordered
in the chassis view.
12563 1.2
14567 1.1
239099 1.3
etc.......