Specifications

9032277-04 Software Superseded by CS3/MMS3
5-29
Patches Issued After the CS1/MMS1 Release
Cs_get_diskio: kstat_read: No such device or address
Solaris 2.6 and beyond allows finer granularity of performance
statistics on disks. Two things can happen, both of which are
unnecessary. Items can be subdivided into partitions, and the software
can try to collect information on NFS mounted directories. This does
not stop the information from being collected; it just places a message
into the VNM.OUT every 10 seconds while the I/O Statistics GIB is
open. This has been resolved by checking to make sure that the disk is
an actual disk and not a partition or NFS mount point.
Devices are being destroyed because the device has been down
(Contact_Status is Lost) for longer than the specified destruction
delay of 604800 seconds. This feature is disabled for the customer and
the models are still being destroyed. During a VNM restart, the
intelligence checks to see if the model has its CONTACT_STATUS set
to LOST. If so, we register a timer to start timing the amount of time
the model has been lost without first checking to see if this "automatic
contact lost model destruction" service is enabled. This has been
resolved by adding the check.
In SPECTRUM 5.0 and beyond, we do not examine the state of the
connected ports during a WA_Link's Fault Isolation process. We
simply look at the status of the connected devices. If both devices are
up, then the WA_Link will be GREEN. This causes problems when the
VNM has a redundant connection to the remote device. When the wide
area connection goes down, the VNM will have a second way to contact
the remote device, thus we won't lose contact with it. This results in no
alarms even though the WA_Link went down. In 4.0rev3, WA_Links
used to monitor the status of the connected ports and generate an
ORANGE "Probable Link Failure" alarm when one of the ports went
down. This patch adds this type of functionality back in for WA_Links.
When modeling a HubCat 5500 device, the SpectoGRAPH crashes
when opening the Configuration View. This was resolved by modifying
the GIB view to prevent the crash.
On startup, the SpectroSERVER randomizes the first poll for all
devices over a fixed ten minute period. While this works well to
distribute the load when polling and logging are at the Spectrum
defaults, it does not work well on very large databases where the
polling interval has been extended beyond ten minutes. This results in
a very cyclic SpectroSERVER workload, and decreases overall