Specifications

9032277-04 Software Superseded by CS3/MMS3

5-43

Patches Issued Since the CS2/MMS2 Release

This problem was two-fold:

There was an attribute, PORTS_STATE that did not exist for any

SS2000 model type that was NOT derived from MicroLANModule

(most 2000 devices). The intelligence tried to read this attribute

before it got through any of the application association processes.

When the attribute read failed (on a device that didn't have the

attribute), the association process was bypassed altogether, and the

model state never reached the active state.

The second issue was similar. The SS2000 devices in question did not

have a DEVICE_MDL_HANDLE attribute (again, because they were

not derived from MicroLANModule). The appropriate IH tried to

didn't exist, the error code was set to FAILURE and the IH never got

attached to the model. As a result, again, the proper model states

were never written to as CS_MODEL_ACTIVE.

The resolution to the ﬁrst part was to create a new PORTS_STATE

attribute at the SS8H level so that all SS2000 devices picked up this

attribute. The conﬁguration process could then continue as normal.

The second issue was solved by not setting the error condition for the

IH to FAILURE when it saw the DEVICE_MDL_HANDLE attribute

did not exist.

SPECTRUM_5.0rev1.P73

Included in SPECTRUM_5.0rev1.P101

The problem was the ctUPSApp model was not appearing in the

MicroMMAC's Application View even though a UPS was physically

connected to the com 1 port of a MicroMMAC. The ctUpsID oid had to

be set through mibtools before the model would appear. Until this

application appears, a user cannot set the appropriate "UPS Model" in

the Performance View.

The resolution was to add CtUPSMib as a base model type. If it fails

to get read during the creation process of the ctUPSApp model the

SPECTRUM will try to write to it. This action would then cause the

CtUPSApp to be activated.