CIM_SettingData class
Represents configuration-related and operational parameters for one or more managed elements. A managed element can have multiple SettingData objects associated with it. The current operational values for the parameters of the element are reflected by properties in the Element itself or by properties in its associations. These properties do not have to be the same values that are present in the SettingData object. For example, a modem might have a SettingData baud rate of 56 KB/sec but be operating at 19.2 KB/sec. Note: The CIM_SettingData class is very similar to CIM_Setting, yet both classes are present in the model because many implementations have successfully used CIM_Setting. However, issues have arisen that could not be resolved without defining a new class. Therefore, until a new major release occurs, both classes will exist in the model. SettingData instances can be aggregated together into higher-level SettingData objects using ConcreteComponent associations.
Important The DMTF (Distributed Management Task Force) CIM (Common Information Model) classes are the parent classes upon which WMI classes are built. WMI currently supports only the CIM 2.x version schemas.
The following syntax is simplified from Managed Object Format (MOF) code and includes all of the inherited properties.
Syntax
class CIM_SettingData : CIM_ManagedElement
{
string Caption;
string Description;
string ElementName;
InstanceId;
};
Members
The CIM_SettingData class has these types of members:
- Properties
Properties
The CIM_SettingData class has these properties.
Caption
Data type: string
Access type: Read-only
Qualifiers: MaxLen ( 64)
A short textual description of the object. This property inherits from CIM_ManagedElement.
Description
Data type: string
Access type: Read-only
A textual description of the object. This property inherits from CIM_ManagedElement.
ElementName
Data type: string
Access type: Read-only
A user-friendly name for the object. This property enables each instance to define a display name in addition to its key properties, identity data, and description information. Be aware that the Name property of ManagedSystemElement is also defined as a display name. However, it is often subclassed to be a Key. The same property can convey both identity and a user-friendly name, without inconsistencies. Where Name exists and is not a Key (such as for instances of LogicalDevice), the same information can be present in both the Name and ElementName properties. This property overrides the property from CIM_ManagedElement.
InstanceId
Access type: Read-only
Within the scope of the instantiating Namespace, InstanceID opaquely and uniquely identifies an instance of this class. To ensure uniqueness within the NameSpace, the value of InstanceID should be constructed using the following "preferred" algorithm: OrgID:LocalID Where OrgID and LocalID are separated by a colon (:), and where OrgID must include a copyrighted, trademarked, or otherwise unique name that is owned by the business entity that is creating or defining the InstanceID or that is a registered ID assigned to the business entity by a recognized global authority. (This requirement is similar to the SchemaName_ClassName structure of Schema class names.) In addition, to ensure uniqueness, OrgID must not contain a colon (:). When using this algorithm, the first colon to appear in InstanceID must appear between OrgID and LocalID. LocalID is chosen by the business entity and should not be reused to identify different underlying (real-world) elements. If the above preferred algorithm is not used, the defining entity must assure that the resulting InstanceID is not reused across any InstanceIDs produced by this or other providers for the NameSpace of this instance. For DMTF-defined instances, the "preferred" algorithm must be used with the OrgID set to CIM.
This property overrides the property in CIM_ManagedElement.
Requirements
Namespace |
Root\virtualization |