Just spoke with Core leadership about this. The use of separate status
variables seems to be the new direction, rather than the use of arrays
of status enums. There are several new status variables being added
(proposed, anyway) to EnabledLogicalElement in a new CR. I think this
is a reasonable directon for us to take. If someone has a better
partitioning of the items than this traditional one, please elaborate.
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org] On Behalf Of
Richard_Landau at Dell.com
Sent: Thursday, January 11, 2007 15:52
To: wims at pwg.org
Subject: WIMS> CIM> How to represent SubUnitStatus in CIM?
Ira, regarding our discussion on SubUnitStatus today, I think that there
are (at least) two choices: either a vector of enum values or several
separate variables. It might not be thoroughly unreasonable to break it
into five variables representing the five sections that were or-ed
together in the first place.
1 on request, unavailable
3 broken, unavailable
It's an idea, anyway. Whaddyathink?
For comparison, here is the section from the MIB intro, from which I
cribbed the text above.
The PrtSubUnitStatusTC is an integer that is the sum of 5 distinct
values, Availability, Non-Critical, Critical, On-line, and
Transitioning. These values are:
Available and Idle 0 000'b
Available and Standby 2 010'b
Available and Active 4 100'b
Available and Busy 6 110'b
Unavailable and OnRequest 1 001'b
Unavailable because Broken 3 011'b
Unknown 5 101'b
No Non-Critical Alerts 0
Non-Critical Alerts 8
No Critical Alerts 0
Critical Alerts 16
State is On-Line 0
State is Off-Line 32
At intended state 0
Transitioning to intended state 64
Richard_Landau(at)dell(dot)com, Stds & System Mgt Arch, CTO Office
+1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682
-------------- next part --------------
An HTML attachment was scrubbed...