DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Introduction to the desktop management interface

The component MIF data store

A DMI component provider is any product that provides management information to the DMI. Components provide their information in MIF files that are installed in the component MIF data store. Attribute values may exist statically or be derived dynamically through component-specific instrumentation.

The DMI-SP builds, maintains and represents the management data of DMI-enabled components in its MIF data store.


NOTE: The DMI-SP provided with this package maintains the MIF data internally in a database format. This guide refers to this data store as either the ``component database'' or ``the MIF database.''

The MIF data store model

The components of a product are described with a language called the ``Management Information Format'', or MIF. The MIF has a defined grammar and syntax. A MIF file is an ASCII text file describing a product's manageable ``attributes'', classified into meaningful ``groups'' (see ``The MIF data store model'' above.) A group ID must be a non-zero, 32-bit unsigned integer and must be unique within the scope of the containing definition. As shown in the figure, the groups found in a MIF do not have to appear in sequential order, nor is a Group 1 required; however, sequential ordering is more readable and easier to maintain.

Manageable products as component MIFs

Each product provides its own MIF file. When a manageable product is initially installed into the system, the information in its MIF file is added to the database and is then available to the Service Provider and thus to management applications.

The values associated with each MIF attribute are either stored directly in the database or provided by program code (instrumentation) that runs when the value is requested.

An attribute can be accessed individually, or as an entry in a ``table'' (with particular instances of that attribute within the table designated by their ``keys''). Values can also be designated as read-only, read-write or write-only.

Each group definition includes a ``class name'' string. The generic formula for constructing a class name is as follows:

Defining body|specific name of group|version number of this group definition

For example, the class name string ``DMTF|ComponentID|001'' for the required Component ID group shows that the DMTF defined the MIF encoding for this group; that this group defines the attributes about the identity of the component this MIF defines; and that this definition is the first formal version released for use with the DMI.

Different components can have similar attributes, such as peripheral devices that use a serial port, even though they may serve different needs (a serial printer versus an external faxmodem). If the attributes are grouped into well-focused categories, then dissimilar components that share a common set of attributes still can be categorized by class name for management applications that want to manage that class of attributes.

Because the DMI categorizes components by class name at the group level rather than the component level, we recommend that a MIF developer use DMTF-approved Standard Groups definitions to express product attributes whenever possible. Developers can augment their component MIFs with additional private groups for attributes that are unique or proprietary to their products.

Language support

To facilitate the needs of the international marketplace, a component developer can create alternate language versions of the same component's MIF data. All DMI 2.0 Service Providers support the component-level language functions, DmiAddLanguage(3dmi) and DmiDeleteLanguage(3dmi), that enable a component's installation program to expand the languages defined for a single component's MIF data.

DMI language expressions are encoded in ISO 8859-1 format. Multiple language support enables the DMI user to:

Pragma support

MIF Pragma definitions provide additional information about the component, group or attribute. As far as the DMI Service Provider is concerned, the literal value assigned to the pragma statement is simply an octet string. Refer to the DMI Specification for a discussion of DMTF conventions for using pragma statements.

MIF definition tips

MIF file grammar, requirements and restrictions are described completely in the DMI Specification. In this document, ``Modeling products with MIF files'' gives some basic guidelines for writing effective MIF files. Additional documents describing MIF definitions and MIF samples are available from the DMTF home page.

Component instrumentation

A MIF file that contains only static data (data coded into the MIF file at the time of its creation) quickly becomes outdated, since the manageable aspects of most products change over time. A DMI component's ``instrumentation'' consists of code that maintains attributes with up-to-the-minute values.


Next topic: Remoteable DMI service users
Previous topic: The role of management applications

© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 27 April 2004