Differences Between SMS and the DMI 4.5 Specification

Although SMS accepts the full DMI 4.5 syntax, the SMS MIF parser does not use some fields, and the SMS system may use the information in a way that differs from the DMI 4.5 specification.

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.

Multiple Identification and Architecture groups are not allowed.

DMI 4.5 allows multiple Identification and Architecture groups within a component. SMS allows only one Identification group and one Architecture group within a component.

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 Microsoft® SQL Server™ places a limit of 255 characters on strings, any strings longer than 255 characters in the MIF will be truncated. However, there is no string length limitation in the syntax itself for attribute values. It is recommended that strings not exceed 255 characters in length, and that they not contain embedded NULL characters through 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 has been parsed and evaluated. Enumeration types can be specified by using either the integer symbol or the enumeration string itself in all contexts where an attribute value is required.

These simplifications are for compatibility with SQL Server data types, and to compensate for the fact that the MIF is being compiled and transmitted to a remote database where the original hardware context of the MIF is lost. Also, there is no purpose served (for SMS inventory purposes) in distinguishing between some of these types. Finally, SQL Server supports a different set of types—so the SMS MIF compiler must map the DMI types to suitable SQL Server types, and the mapping is not necessarily on a one-to-one basis.

Unicode MIFs are detected but not supported.

DMI 4.5 allows Unicode MIFs. The SMS Inventory Processor will not process a Unicode MIF, and will report an error. The MIFCHECK utility will report that Unicode MIFs 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. 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.

For example, the following PRAGMA statement tells the Inventory Processor and Inventory Dataloader components to update a group by using the information in the group definition specified in the MIF file:

PRAGMA = "SMS:Update"
 

If no PRAGMA is specified, the command is "Add" by default.

PRAGMA	Meaning
SMS:Add	Adds the group to the computer's inventory in the database.
SMS:Update	Updates the group in the database with the information in the Delta-MIF file.
SMS:Delete	Removes the group from the computer's inventory in the database.

Description statements are parsed but not used.

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 uppercased, but not checked for internal format, because this is not a strict requirement in the specification. The uppercasing 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 uppercases the string, forcing the issue.

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 SMS 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.

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 zeros 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 zeros in that field.
• For the Date data type, the microsecond field is ignored.
• SMS will store dates only to the resolution of 1 second. The microsecond field will be ignored. However, you must still specify zeros in the microsecond field.
• For the Date data type, 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.

  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).

  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 Microsoft 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 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.

For the String data type, escape characters are fully interpreted.

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, the string length should be 255 characters or less.

DMI 4.5 has no limits on string length. For SMS, you should limit the string length to 255 characters or less. Because of the 255-character limit for SQL Server, the SMS 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.

For the String data type, you should explicitly declare the string length.

Although the DMI does not require you to specify the string length of an attribute with a String data type, you should explicitly declare the length of all String data types for MIFs used with SMS.

If an attribute with a String data type does not have a declared string length, the SMS Inventory Processor 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.

If no string length is declared for an attribute, the Inventory Processor will use the following rules to set the string length (in the specified order):

1. For an attribute with a String data type that does not explicitly specify the string length, the SMS MIF parser will set the maximum string length of the attribute to the length of the value specified for that attribute.

   The exception is any Name statement for a component, group, attribute, path, enum, or table. These statements have a maximum length of 255 characters.

   If the group containing this unsized attribute is part of a group template, then the length of the default string becomes the defining size, as if the string had been declared with a length of that value. So, if you declare no default string size and no default string value, this sets the maximum string length to zero in the table declarations.

2. For Group templates and tables, if a default string length is specified, no initializer value in a table may exceed this length.

   If a string length is not declared, the default string value's length will be used implicitly as the maximum length, and any initializers in a table may not exceed this length.

3. If no default value and no default initializer are specified in a Group template, the length is derived from the actual string length of the string initializer in the table row.

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.