PDGuide - The Desktop Management Interface (DMI)

Problem Determination Programmer's Guide
Introduction to Collecting and Managing Problem Determination Data Guide to Instrumenting Your Code Controlling FFSTProbe Calls Viewing and Analyzing Error Log Entries Analyzing Performance and Debugging Problems Using Trace Capturing and Saving Failure-Related Information through Dumps The Desktop Management Interface Summary of Functions and Interfaces Problem Determination APIs

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

This chapter provides background about the DMI, information about the relationship between DMI and VPD (vital product data) and coding examples.

DMI Overview

The Desktop Management Interface (DMI) provides the means for software and hardware components to define VPD information. DMI also provides a standard function set that management applications can use to access that information.

The DMI consists of four elements:

• Format for describing information
• Format for data transfer
• Mechanism for data transfer
• Set of services for facilitating communication

You define component descriptions in a language that is called the Management Information Format (MIF). Each component has a MIF file that describes the manageable characteristics of the component.

Component providers use the Component Interface (CI) to describe how to access management information and enable a component to be managed.

Applications use the Management Interface (MI) to manage components.

The CI and MI are data interfaces, as opposed to procedural interfaces.

The Service Layer (SL) is an active, resident code that runs on the system. The SL mediates between the MI and the CI and performs services on behalf of each.

The DMI is a local interface that is used within a single system. DMI does not replace existing network management protocols. DMI provides a consistent method for providing instrumentation to those protocols. The Service Layer is the broker of local instrumentation.

DMI provides the following:

• Independence of a specific computer, operating system, or management protocol
• An easily adopted interface for application developers
• Does not require a network
• Mapping to existing management protocols.

The DMI does not address or specify a protocol for management over a network.

DMI Structure

The DMI is a local interface for single-system use, regardless of being a standalone desktop system or part of a network. The interface consists of the following parts:

• Service Layer (SL): A local program that collects and manages product information in the MIF database. The Service Layer distributes requested information to management applications through the Management Interface (MI) and to manageable products through the Component Interface (CI).

• MIF database: The database containing the installed or attached manageable product information. MIF files contain the information, and the Service Layer manages the information.

• Management applications: Remote or local programs used to interrogate, track, control, and list the elements of a desktop system. A management application can be any of the following:
  • a graphical user interface program
  • a network management agent
  • an installer program
  • a diagnostics program
  • a remote procedure call.

• Manageable products: Components that are connected to or part of a desktop computer system or network server. Components can be part of the system code, or you can add them later. Each product has a MIF file in the MIF database that contains pertinent product management information.

The following figure shows the DMI structure:

DMIFunctionalDiagram

Enabling Manageable Products for DMI

The product manufacturer needs to decide which attributes of the product are manageable. To enable a product for DMI you write a MIF file that contains descriptions of these manageable attributes. Group the attributes logically so you can write instrumentation code to provide attribute data.

Use the SystemView Agent Programmer's Guide in the Toolkit in the Problem Determination Tools folder as a reference for enabling products. This book defines requirements for products that communicate with the Service Layer. To develop such a product:

• Read the SystemView Agent Programmer's Guide to get an understanding of how components interface with the Service Layer and the supported commands.
• Define manageable attributes and specific features of your product. Look for existing MIF groups that may apply to your product.
• Begin with the ComponentID group and define MIF groups that are based on the features of your product. Use as many of the existing standard groups that apply to your product as is possible. Standard groups are available from the Desktop Management Task Force (DMTF). If needed, add proprietary groups for unique features of the product.
• Decide if the attributes are read-only, read-write, or write-only, and define MIF attributes for each group.
• Use the syntax that is defined in the SystemView Agent Programmer's Guide to create your MIF file.
• Determine whether to use run-time programs or the direct interface to provide component information to the Service Layer. Write your instrumentation code accordingly.
• Change the programs that install or delete MIF database file for your component.
• Decide which errors, exceptions, or problems are to be sent to the Service Layer as indications and the attribute information to include. Real-time, intelligent product management is made possible by using indications because the system immediately notifies management applications when a problem occurs. Add code to your product to send these indications to the Service Layer. The system uses the DmiIndicate command block to pass events to the Service Layer. See the SystemView Agent Programmer's Guide in the Problem Determination Tools folder on the system for information about the DmiIndicate command block.

Designing MIF Files

MIF files are the key to enabling your product to be managed by the desktop system. A well designed MIF file is important.

The DMI requires that the MIF file be an ASCII text file that contains the groups and attributes that you defined for your product. You must provide all meaningful information by using the MIF file. The text in the file must follow the defined syntax and grammar.

After you decide which product attributes are manageable, define the attributes into standard groups as much as possible in the MIF file.

The DMI Specification describes attribute characteristics and options. All attributes must have these four items defined:

Name

The name of the attribute

ID

The unique, sequential attribute ID within the group containing the attribute

Type

The attribute's data type. The type is either a specific data type that DMI supports or an enumerated list that provides flexibility in the attribute definitions

Value

The actual value (to be put into the database) or a pointer to the instrumentation that gets the value

In addition, you can optionally define description, access, and storage attributes.

The description can be one or many lines. The description text should be as clear and informative as possible to provide management applications with complete information about the attribute. You need a good description at the component level and group level.

The system uses an access statement to determine whether the attribute's value is read-only, read-write, or write-only.

The storage statement provides a hint to management applications about whether to assist in optimizing storage requirements. Two options are available:

• common - you use this option to signify that the attribute value is typically limited to a small set of possibilities that you can be optimize.
• specific - you use this option to signify that the attribute value is not a good candidate for optimization because of the possibility of a large number of different values.

You can find the MIF file requirements in the SystemView Agent Programmer's Guide in the Toolkit in the Problem Determination Tools folder.