Specifications

9032277-03 Software Superseded by CS2/MMS2

5-23

agent was capable of handling, the DCM did successfully process all of the

data:

1. Through an arbitration type process the DCM removed attributes that

were roughly equal to 25% of the total packet size during each iteration,

until it ﬁnally sent a packet that was small enough to be processed by the

Liebert Agent.

2. The remaining attributes were then packed into subsequent packets and

sent to the agent for processing.

3. The successful packets were reused by the DCM, rather than having to

repeat the arbitration process for each refresh cycle of the GIB.

When moving to 5.0 the customer has reported that the way in which the

DCM processes packets which are too large for the agent has changed

markedly:

1. The arbitration process uses a ~10% reduction factor in each iteration.

2. The remaining attributes are dropped and not resent.

This has been resolved by restoring the old behavior.

Support has been added for the Catalyst wsx5030 board.

A memory leak occurs on every poll of a port's Internal_Link_Status when

LivePipes is turned on. The default polling interval is 1 minute for each port

in the database with Live Pipes enabled, which can become a severe memory

issue for customers who use LivePipes.

Bringing up the I/O Statistics View from the VNM Performance View causes

the following errors to appear in the VNM.OUT:

Cs_get_diskio: kstat_read: No such device or address

Solaris 2.6 and beyond allows ﬁner 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 speciﬁed 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 ﬁrst

checking to see if this "automatic contact lost model destruction" service is

enabled. This has been resolved by adding the check.