Class CIM_DiagnosticSetting
extends CIM_Setting

DiagnosticSetting is being deprecated and replaced by an identical class that derives from CIM_SettingData. CIM_Setting is to be replaced by CIM_SettingData in future versions of CIM. Specific diagnostic test parameters and execution instructions are defined by this class. To provide more detailed Settings for a type of test (i.e., additional properties), subclassing is appropriate.

Table of Contents
Direct Known Subclasses
Class Qualifiers
Class Properties
Class Methods

Class Hierarchy


Direct Known Subclasses

Class Qualifiers

NameData TypeValue
DescriptionstringDiagnosticSetting is being deprecated and replaced by an identical class that derives from CIM_SettingData. CIM_Setting is to be replaced by CIM_SettingData in future versions of CIM. Specific diagnostic test parameters and execution instructions are defined by this class. To provide more detailed Settings for a type of test (i.e., additional properties), subclassing is appropriate.

Class Properties

Local Class Properties

NameData TypeDefault ValueQualifiers
NameData TypeValue
DescriptionstringWhen this flag is true, the test will halt after finding the first error.
DescriptionstringThis property is deprecated and replaced with an array. It provides additional information for LoopControl when its value is set to 1 ('Other').
DescriptionstringRequests the diagnostic software to reduce test coverage to the specified percentage. For example, a hard drive scan test could be asked to run at 50%. The most effective way to accomplish this is for the test software to scan every other track, as opposed to only scanning the first half of a drive. It is assumed that the effectiveness of the test is impacted proportional to the percentage of testing requested. Permissible values for this property range from 0 to 100.
DescriptionstringWhen this flag is true, the test software should attempt to run in an accelerated fashion either by reducing the coverage or number of tests performed.
DescriptionstringWhen this flag is true, the diagnostic test will report 'soft errors'. In this context, a soft error is a message from the diagnostic reporting a known defect in the hardware or driver configuration, or execution environment. Examples are: 'Not enough memory', 'Driver IOCTL not implemented', 'Video RAM compare failed during polygon fill test (A known defect in the video chipset)', etc.
DescriptionstringWhen this flag is true, the diagnostic test will report 'status messages'. In this context, a status message indicates that the diagnostic code is at a checkpoint. Examples are: "Completion of phase 1", "Complex pattern", etc.
DescriptionstringThe ResultPersistence property is a directive from a diagnostic client to a diagnostic provider. It allows the client to specify to the diagnostic service provider how long to persist the messages that result from execution of a diagnostic service. This applies to instances of DiagnosticResult as well as the preferred use of DiagnosticServiceRecord. The timeout period starts upon completion of the diagnostic action described by the DiagnosticService. Here is a summary of the choices and behaviors for different ResultPersistence values: 0 = "No Persistence": Setting the timer to zero tells the provider not to persist the diagnostic result. The diagnostic information is only available while the diagnostic is executing or at its conclusion. Value > 0 and < 0xFFFFFFFF = "Persist With TimeOut": Setting the ResultPersistenceOption to a integer will cause the DiagnosticResult to be persisted for that number of seconds. At the end of that time, the DiagnosticResult may be deleted by the diagnostic service provider. 0xFFFFFFFF = "Persist Forever": By setting the timeout value to the very large value, 0xFFFFFFFF, the provider shall persist results forever. In this case, the client MUST bear the responsibility for deleting them.
DescriptionstringIn order to ensure uniqueness within the NameSpace, the value of SettingID 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 creating/defining the SettingID, or is a registered ID that is assigned to the business entity by a recognized global authority. (This is similar to the <Schema Name>_<Class Name> 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 SettingID MUST appear between <OrgID> and <LocalID>. <LocalID> is chosen by the business entity and SHOULD not be re-used to identify different underlying (real-world) elements. If the above 'preferred' algorithm is not used, the defining entity MUST assure that the resultant SettingID is not re-used across any SettingIDs produced by this or other providers for this instance's NameSpace. A preferred value for <LocalID> is a timestamp (CIM DateTime). For example, ACME:19980525133015.0000000-300.
DeprecatedstringCIM_DiagnosticSetting.LogOptions, CIM_DiagnosticSetting.VerbosityLevel
DescriptionstringThis property is being deprecated because the TestWarningLevel and LogOptions properties serve the same purpose. It is deprecated in lieu of using the LogOptions ('Warnings') property in conjunction with VerbosityLevel to specify this information. The 'Missing Resources' and 'Testing Impacts' values are not included directly in LogOptions, but they are expected to be recorded in the resulting DiagnosticServiceRecord object. Sets the level of warning messages to be logged. If for example no warning information is required, the level would be set to "No Warnings" (value=0). Using "Missing Resources" (value=1) will cause warnings to be generated when required resources or hardware are not found. Setting the value to 2, "Testing Impacts", results in both missing resources and 'test impact' warnings (for example, multiple retries required) to be reported.
ValueMapstring0, 1, 2, 3
ValuesstringNo Warnings, Missing Resources, Testing Impacts, All Warnings
DeprecatedstringNo value
DescriptionstringThis property, along with the locale information in LocalizationCapabilities and DiagnosticServiceRecord, meets the requirement to specify locale for results produced by a diagnostic service. A locale indicates a particular geographical, political, or cultural region. The Locales property of the DiagnosticSetting class is an array of strings whose entries specify a language to be used in the formulation of information requested by or delivered to a client as a result of running a diagnostic service. It is specified by the client as an input parameter to the RunDiagnostic method, by virtue of its inclusion in this Setting class which is a parameter of the method. A single Setting object may specify more than one Locale. In this case, information MUST be returned in each language specified. Each array entry consists of three sub-strings, separated by underscores: - The first sub-string is the language code, as specified in ISO639. - The second sub-string is the country code, as specified in ISO3166. - The third sub-string is a variant, which is vendor specific. For example, US English appears as: "en_US_WIN", where the "WIN" variant would specify a Windows browser-specific collation (if one exists). Since the variant is not standardized, it is not commonly used and generally is limited to easily recognizable values ("WIN", "UNIX", "EURO", etc.) used in standard environments. The language and country codes are required; the variant may be empty.
DescriptionstringThe LogOptions property is used to specify the types of data that SHOULD be logged by the diagnostic service. Any number of values may be specified in the array. Note that the default behavior is for nothing to be logged. The AMOUNT of data to be logged can be controlled for each value selected by specifying a VerbosityLevel value. Verbosity may not apply to all LogOptions values, in which case the default VerbosityLevel of "Standard" SHOULD be used. The RecordForLog produced by running a service MUST be tagged with a RecordType that corresponds to one of these log option values. Following is a brief description of the available log options: * "Other" (value = 1): Details are given in the corresponding OtherLogOptionsDescriptions entry. * "Results" (value = 2): Log the results obtained by running the service. This is the most common value for reporting the service results. * "Subtests" (value = 3): Log a test summary report upon completion of each subtest and each loop iteration. The summary reports SHOULD state whether the individual subtest or iteration passed or failed and list relevant error codes and respective error counts. * "Actions" (value = 4): Log corrective action and instructional messages to guide service personnel; for example, a prioritized list of actions to perform in order to isolate a failure or correct a problem. When ordering steps or prioritizing actions, a number should proceed the text; for example, 1) Do this first, 2) Do this next, etc. * "Warnings" (value = 5): Log warning messages; for example, 'device will be taken off line', 'test is long-running' or 'available memory is low'. The VerbosityLevel value specified for the Warnings option is related to the severity of the warnings logged; for instance, one would specify a high level of verbosity to get all warnings logged, regardless of severity, and a low level of verbosity to have only the most severe warnings logged. * "Status" (value = 6): Log status messages; for example, state information for the driver, device, or system. * "Device Errors" (value = 7): Log errors related to the managed element being serviced. * "Service Errors" (value = 8): Log errors related to the service itself rather than the element being serviced, such as 'Resource Allocaton Failure'. * "Setting Data" (value=9): Log the property values of the DiagnosticSetting object used to configure the service. * "Statistics" (value = 10): Log statistical messages; for example, packets sent per second. * "Hardware Configuration" (value = 11): Log messages that contain information about the hardware configuration as viewed by the service; for example, vendor, version, FRU identification, and location information. The format and contents of this property is element dependent. Examples are: SCSI ID, LPTx, PCI Slot Number, and Dimm#. * "Software Configuration" (value = 12): Log messages that contain information about the software environment as viewed by the service; for example, the name and version of all the critical software elements controlling the device under test. Each configuration message SHOULD have the following common format: Element name; element type; manufacturer name; version; for example, 'Miniport driver; SCSI; Intel; Version 1.2'. * "Reference" (value = 13): Log the keys of an CIM object of of interest; for example, the element under test, or a data file. * "Debug" (value = 14): Log debug messages. These messages are vendor specific.
ModelCorrespondencestringCIM_DiagnosticSetting.OtherLogOptionsDescriptions, CIM_DiagnosticServiceCapabilities.SupportedLogOptions, CIM_DiagnosticServiceRecord.RecordType, CIM_DiagnosticSetting.VerbosityLevel
ValueMapstring0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 0x8000
ValuesstringUnknown, Other, Results, Subtests, Actions, Warnings, Status, Device Errors, Service Errors, Setting Data, Statistics, Hardware Configuration, Software Configuration, References, Debug, No Log Options
DescriptionstringThe LogStorage setting property indicates which types of supported storage should be used by the Diagnostic Service for logging of the data specified in LogOptions. The values are: "DiagnosticLog" (Value = 2): Use the DiagnosticLog and DiagnosticRecord classes. "MessageLog" (Value = 3): Use the MessageLog class and its methods. "File" (Value = 4): Write data to a file.
ModelCorrespondencestringCIM_DiagnosticSetting.OtherLogStorageDescriptions, CIM_DiagnosticServiceCapabilities.SupportedLogStorage
ValueMapstring0, 1, 2, 3, 4
ValuesstringUnknown, Other, DiagnosticLog, MessageLog, File
DescriptionstringLoopControl, used in conjunction with LoopControlParameter, sets one or more loop control mechanisms that limits the number of times a test should be repeated with a single invocation of a test method by a CIM client. There is an array-positional correspondence between LoopControl entries & LoopControlParameter entries. The entries in these coupled arrays of loop controls can be used in a logical OR fashion to achieve the desired loop control. For example, if a client wants to loop a test 1000 times, but quit if a timer runs out, it could set both controls into the LoopControl array as two separate entries in each array. The looping test will terminate when the first of the two Ored conditions are met. The descriptions for each loop control are given below: Unknown (= 0) Other (= 1) : Additional detail may be found in OtherLoopControlDescriptions. Continuous (= 2) : The corresponding LoopControl Parameter is ignored and the test will execute continuously. Tests that use this control should also support DiscontinueTest. Count(=3) : The corresponding LoopControlParameter is interpreted as a loop count (uint32), indicating the number of times the test should be repeated with a single invocation of a test method by a CIM client. Timer (= 4) : The corresponding LoopControlParameter is interpreted as an initial value (uint32) for a test loop timer, given in seconds. The looping is terminated when this timer has lapsed. ErrorCount (= 5) : The corresponding LoopControl Parameter is interpreted as an error count (uint32). The loop will continue until the number of errors that have occurred exceeds the ErrorCount. Note: the ErrorCount only refers to hard test errors; it does not include soft errors or warnings.
ModelCorrespondencestringCIM_DiagnosticSetting.LoopControlParameter, CIM_DiagnosticSetting.OtherLoopControlDescriptions, CIM_DiagnosticServiceCapabilities.SupportedLoopControl
ValueMapstring0, 1, 2, 3, 4, 5
ValuesstringUnknown, Other, Continuous, Count, Timer, ErrorCount
DescriptionstringArray entries contain parameters corresponding to entries in the LoopControl array, limiting the number of times a test should be repeated with a single invocation of a test method by a CIM client.
DescriptionstringProvides additional information regarding the types of test messages that are logged when the property LogOptions includes the value 1 ("Other").
DescriptionstringThis property provides additional information for LogStorage when the corresponding value is set to 1 ("Other").
DescriptionstringThis property provides additional information for LoopControl when the corresponding value is set to 1 ('Other').
ModelCorrespondencestringCIM_DiagnosticSetting.LoopControlParameter, CIM_DiagnosticSetting.LoopControl
DescriptionstringA client may want to specify the desired volume or detail logged by a diagnostic service. This property is applied to a corresponding logging option, acting as a qualifier on its description. Three levels of verbosity are defined as follows: * "Minimum" (value=2): Specified if the least amount of information is desired; for example, Pass or Fail. * "Standard" (value=3): This is the standard level of messaging provided by the service. It is the form most likely to be used if no verbosity value is specified (default). * "Full" (value=4): Specified when all information, regardless of size, is desired. Note that VerbosityLevel is a subjective property and relates to the degree of detail, not an absolute metric. A client simply specifies its desired level of detail and the provider publishes its data in accordance with this desired level of detail. Verbosity may not apply to all LogOptions values, in which case the default VerbosityLevel of "Standard" SHOULD be used.
ValueMapstring2, 3, 4
ValuesstringMinimum, Standard, Full

Inherited Properties

NameData TypeClass Origin

Class Methods

Inherited Class Methods

NameReturn TypeClass Origin