Previous section.

UMA Measurement Layer Interface (MLI)
Copyright © 1997 The Open Group



This document is one of a family of documents that comprise the Universal Measurement Architecture (UMA), which define interfaces and data formats for Performance Measurement. UMA was originally defined by the Performance Management Working Group (PMWG) and subsequently adopted by The Open Group.

This document is a specification for the functional characteristics of the Measurement Layer Interface (MLI), as defined in the UMA Reference Model in UMA Reference Model . The document describes the underlying semantics and the function calls that implement them. It also defines a format for headers appended to data as captured by the low-level Data Capture Interface (DCI). (These headers are part of the control and status messages sent between UMA and the applications it serves.)

The UMA is defined in the following documents:

Scope of the Universal Measurement Architecture

The scope of the Universal Measurement Architecture is:

The UMA architecture specifies two interfaces:

In addition, the architecture provides services for distributing data to multiple applications, for maintaining historical data, and for synchronising the capture of metrics from different sources.

Performance and capacity management of operating systems have been considered internal to the operating system and as such differ from one operating system to another operating system, and from one implementation to another implementation. Most operating systems have, as a matter of necessity, performance analysis modules, narrowly targeted at the type of hardware, software and networking facilities implemented within the system.

Most operating systems provide ad-hoc developed or tailored performance metrics. Some of these tools are developed as internal support tools for benchmarking or on demand of performance analysts and capacity planners. These tools are generally also confined to one machine only and can not be interrogated remotely.

The new era of networking and interoperability views performance management and capacity planning from the user's perspective. Multiple machines and operating systems can be involved in the interaction with the user. This approach requires capture and presentation of performance metrics to be clearly defined and portable between platforms and operating systems.

Definitions, Acronyms and Abbreviations

Terms, acronyms and abbreviations used in this specification are defined in the Glossary.


A conformant implementation must support all of normative requirements in this MLI specification, that is, as specified in chapters 1 - 8) except in the following respects:

  1. Support of unsolicited events:

    MLI support of unsolicited events is optional. When a measurement application requests delivery of unsolicited events from an MLI implementation which does not support this feature, status and reason codes will be returned from the call indicating the condition.

  2. Support of metric, instance tag and work unit description by metadata:

    MLI support of metric, instance tag and work unit description by metadata is optional. This information, when available, is presented in the "Subclass Attributes" subclass of the class "UMA Configuration" solicited with the umaRequestConfig() MLI call. When not supported, an attempt to retrieve this subclass will return status and reason codes indicating that the subclass is not implemented.

  3. Support of dynamic data:

    MLI support of dynamic data is optional. The availability of dynamic classes and subclasses is indicated in the subclass "Implementation" of class "UMA Configuration" by the setting of the bit flag UMA_DYNAMIC for each class and subclass. Support of dynamic data implies the MLI support of metric metadata.

  4. Support of protocol section contents in control messages:

    The only required usage of the control UDU header protocol section is that the umaCreate() and umaReconnect() logical message protocols and their acknowledgements include the protocol section field describing the sending platform's wordsize (mh_wdsize). The other fields may be used to support private protocols between MLI service layers. The presence or absence of the additional protocol fields has no impact on the use of the MLI API.

  5. MLI use of the DCI:

    Use of the DCI by the MLI for data acquisition is optional. However, if the DCI is used as a source of data, the user should refer to the DCI conformance requirements.

  6. Enhanced security services:

    These are specified external to the MLI.

  7. WorkInfo granularities:

    While MLI implementation of the Workload definition mechanism (using UMAWorkInfo) is mandatory, the availability of specific WorkInfo granularities is defined by the data provider.

    Why not acquire a nicely bound hard copy?
    Click here to return to the publication details or order a copy of this publication.

    Contents Next section Index