Differences Between SMS and the DMI 4.5 MIF Specification

In general, the SMS system can use any MIF file that complies with version 4.5 of the Desktop Management Interface (DMI) specification. However, SMS treats some aspects of the MIF syntax in a way that is unique to SMS. In addition, although the full DMI 4.5 syntax is accepted by the SMS MIF parser, some fields are not used. The following sections outline the differences between SMS and DMI MIF files:

ComponentID group is supported but not enforced.

DMI 4.5 requires this group; however, the SMS MIF parser does not enforce this requirement. The ComponentID group is checked for correct syntax only. If the group does not exist in the MIF file, the parser will not report an error.

Some data types are simplified or merged.

DMI 4.5 has numerous data types: five types of integers, three types of strings, and one date type. SMS handles these data types in the following manner:

• All integer types (int, integer, int64, integer64, gauge, counter, and counter64) are treated as signed 32-bit values. Therefore, values exceeding 32 bits will not be correctly evaluated. Likewise, 32-bit unsigned values above 0x7FFFFFFF will be variously interpreted as unsigned 32-bit values or signed 32-bit values, depending on the context. However, the MIF parser will forward these values to other components as signed 32-bit integers.
• All string types (displaystring, string, octetstring) are treated as the same type for database purposes. Because SQL Server places a limit of 255 characters on strings, any strings longer than 255 characters in the MIF file will be truncated. However, there is no string length limitation in the syntax itself for attribute values. Strings should not exceed 255 characters in length, and they should not contain embedded NULL characters via an escape sequence.
• Enumeration types are evaluated as the symbolic string and not as the integral value represented by the enumeration string. The enumeration string is preserved as a database item. Enumeration types take on the string type when the MIF file has been parsed and evaluated. Enumeration types may be specified by using either the integer symbol or the enumeration string itself in all contexts where an attribute value is required.

Unicode MIF files are detected but not supported.

DMI 4.5 allows Unicode MIF files. The SMS Inventory Processor will not process a Unicode MIF file, and will report an error. The MIFCHECK utility will report that Unicode MIF files are not supported.

The Language statement is parsed but not used.

DMI 4.5 allows a Language statement that describes the language of the MIF file. SMS parses the Language statement but does not use it for any purpose.

PRAGMA is a keyword for SMS.

DMI 4.5 does not specify PRAGMA as a keyword. SMS uses the PRAGMA keyword to send commands between components. The PRAGMA statement can be used in a MIF group definition. The PRAGMA statement specifies a string that contains a command. The PRAGMA string is case-insensitive. If no PRAGMA is specified, the command is Add by default.

SMS supports three pragma types:

· Pragma SMS:Add adds the group to the computer's inventory in the database.

· Pragma SMS:Update updates the group in the database with the information in the Delta-MIF file.

· Pragma SMS:Delete removes the group from the computer's inventory in the database. Deleting the Identification group removes all records for the computer from the database.

Description statements are not used in SMS.

With DMI 4.5, you can use a Description statement to describe a component, group, or attribute. SMS parses Description statements but does not use them for any purpose.

The class string is converted to uppercase but not checked for internal format.

The class string is converted to uppercase, but not checked for internal format, because this is not a strict requirement in the specification. The conversion to uppercase is done to force all subsequent users of the CLASS string to treat it in a case-insensitive manner. Rather than relying on other components to do this, the parser converts the string to uppercase.

Path definitions are parsed but not used.

With DMI 4.5, you can use a Path statement to locate component instrumentation files. SMS parses Path statements but does not use them for any purpose.

Attributes that use Instrumentation Symbolic Names are parsed but not used.

With DMI 4.5, you can use a Path statement to specify Instrumentation Symbolic Names to specify paths to libraries that contain the actual value of an attribute. SMS parses attributes that use Instrumentation Symbolic Names but does not use them for any purpose.

The Unsupported keyword forces an attribute to be ignored in the SMS system.

With DMI 4.5, you can specify the keyword Unsupported to tell the DMI service layer that an attribute is not supported by a component.

For SMS, an Unsupported keyword applied to an attribute value causes that attribute to be specially marked. The MIF parser will retain the Unsupported tag; however, the Inventory Processor will ignore such attributes, treating them as though they were not present in the MIF file.

The Access statement is parsed but not used.

DMI 4.5 lets you use an Access statement to specify the access to an attribute. SMS parses Access statements but does not use them for any purpose. The Access statements have meaning only to the DMI service layer. However, the restrictions in the DMI specification on the correct or incorrect placement of these values with regard to enumerated types or key values are still enforced.

There are several restrictions on the Date data type.

The Date data type has the following restrictions:

· The value for an attribute with the Date data type must be represented using the full 25 octets required for the Date data type. You should pad values with zeroes if necessary (for example, the month of May should be represented as 05, not 5). If a date field has no value, you should place zeroes in that field.

· The microsecond field is ignored. SMS will store dates only to the resolution of one second. However, you must still specify zeros in the microsecond field.

· The UTC offset is parsed and available for use by SMS components, but currently no SMS components use the UTC offset information.

· An attribute cannot contain a date before 1980 or after 2030. Date attributes outside of this range will be considered errors by the SMS MIF parser.

· The asterisk character (*) in a date field is replaced with the value for the current date in the corresponding field on the computer where the MIF parser is running.

With DMI 4.5, you can use asterisks to avoid specifying a part of a date. SMS requires that a date value be a complete date value because SQL Server cannot store partial date values. An attribute that contains all asterisks will be considered a NULL or blank date in the SMS database.

For example, if the current date is November 11, 1995, the value 1995**01130000.000000+000 would be processed as 1:00 P.M., November 1, 1995 (** is replaced by 11, the current month).

· For non-English versions of SMS, the MIF syntax and keywords must be in English, but the string data can be in the localized language of the client.

For the String data type, you should use escape characters for characters outside the standard ANSI range (32 through 127).

Literal (non-escape) characters embedded in quoted strings outside of the range 32 to 127 will be parsed and passed on to the rest of the system. These values may have different appearances, depending upon the active display font. Strictly speaking, for string types, you should restrict the characters to the ISO 8859-1 character set. However, the parser does not currently enforce this particular character set.

All escape characters are fully interpreted as the correct 8-bit value. You should be careful when using escape characters. For example, a NULL in the middle of a string "abc\0abc" causes SMS to interpret the string as having a length of only three characters. Although the parser supports a stream of bytes by this mechanism, SMS truncates the string when it detects an escape NULL.

Also note that how the escape character is stored in the SMS database depends on the character set used by the SQL Server containing the database. How the escape character is displayed depends on the code page used by the computer running the SMS Administrator.

For the String data type, you should explicitly declare the string length, which must be 255 characters or less.

DMI 4.5 does not require you to specify the string length of an attribute with a String data type, and it does not impose limits on the string length. However, for SMS you should explicitly declare the length of all String data types, and you should limit the string length to 255 characters or less.

Because of the 255-character limit for SQL Server, the Inventory Processor does not support string lengths longer than 255 characters. Any string that is longer than 255 characters will be truncated to the first 255 characters. The SMS MIF parser will not report an error if the declared string length exceeds 255 characters.

If an attribute with a String data type does not have a declared string length, SMS will use the string length of the value that is specified for the first occurrence of the attribute. This string length will be used as the declared string length of the attribute. Any attributes of the same type will use the declared string length as the string length of the attribute.

For Groups and Tables, the SMS MIF parser does not enforce the uniqueness of key attributes.

DMI 4.5 requires that the key attributes be unique. You should follow the DMI recommendations. If a key attribute is not unique, SMS will store only the last instance of the duplicated key attribute.