Previous section.

UMA Data Capture Interface (DCI)
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 defines the requirements for a programming interface for the lowest layer in the UMA performance metrics architecture. The purpose of this document is twofold. The first is to provide sufficient background for the reader to understand the problem being solved and the source of the programming interface requirements. The second is to provide a specification of an interface that would meet these requirements.

The UMA is defined in the following documents:


Performance and capacity management of operating systems have been considered 'internal' to the operating system and as such differ from operating system to operating system and from implementation to 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 and tools. 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 the capture and reporting of performance metrics to be clearly defined and portable between platforms and operating systems.

Historically, many operating systems have not had a well defined interface for acquiring information about system performance. These systems typically provide a number of user commands for obtaining the status of system resources, such as ps, sar and the stat commands of UNIX. However, programs which require instrumentation beyond that provided by these utilities, or applications which require higher metric acquisition rates, have resorted to interrogating the operating system themselves. In these cases, privileged access to system memory (for example, kernel memory in UNIX, system control blocks for MVS) is the only available mechanism. Such access is notoriously slow, and can require the development and maintenance of specialised subsystems linked in with the operating system. Clearly, a flexible, extensible interface to system metrics is required.

The Performance Management Working Group has provided a solution to this problem. This solution, the Universal Measurement Architecture (UMA), specifies two architectural layers for system performance metrics. The uppermost layer specifies an API for the transfer of formatted measurement data. The lower layer specifies the interface for acquiring raw measurement data. The term formatted implies that the upper layer provides measurement services that modify the content and format of the data on behalf of the user. For details, see the Measurement Layer Interface specification (reference MLI). Raw implies that the measurement data is acquired in its original, unchanged form.

The Data Capture Layer is the term used for this lowest layer in this performance metrics architecture. The programming interface for the Data Capture layer is called the Data Capture Interface, or DCI. Measurements provided by the DCI are intended to be collected, interpreted, or distributed by higher level applications or services before their consumption by a user. The DCI provides an alternative to, and eventually a replacement for, older mechanisms such as reading the kernel memory device on UNIX systems.

The DCI is intended for anyone writing system performance monitoring or management tools. A correctly specified Data Capture Interface provides several benefits to the performance community. The first is that they will be able to write portable measurement applications because they will not have to adapt the application to each operating system variant and release. Another benefit is that the DCI will allow toolmakers to provide services beyond those that could be supported by the current state of metric acquisition. Also, by establishing a solid foundation, higher levels of standardisation, as described by the UMA, can be specified. Finally, DCI can become part of the lowest layers of the emerging effort to standardise distributed system management.


There are two classes of goals for the DCI. The first class consists of those goals that meet the needs of the performance community. The second class consists of those goals that must be met to satisfy requirements that the system imposes on any new interfaces.

The DCI application programming interface must meet the following goals to satisfy the needs of the performance community. (A detailed description of each goal follows this section.)


The addition and use of the DCI should not significantly alter the performance of an existing system.


Standardise the interface for retrieving performance data.


The DCI should be implementable on a wide variety of systems.


The DCI should allow for metric providers other than the operating system.


The DCI should have little or no inherent knowledge of the structure of the data being provided.


The DCI, while limiting its scope to metrics provided by a single system, must allow for an efficient multi-system measurement solution.


Both passive and interrupt driven metrics acquisition must be supported.


The DCI should allow for the possibility that metrics, such as configuration values, be modified by a properly privileged MAP. It is implementation defined whether such modification requests are honoured.

The following are requirements imposed by the current state of operating system software.


The interface should not preclude a secure implementation.


The interface should not preclude implementation on multiprocessor architectures.


Any textual information should be capable of supporting an internationalised implementation.


The interface should fit into a distributed environment.


The addition of any metrics acquisition subsystem should not noticeably affect the performance of the measured system. (Many performance tool builders assert that system performance should not be altered by more than 5% when there is measurement activity.) Although it is beyond this specification to stipulate a performance degradation figure, that figure belongs in an implementation's design specification, the performance goal does impose a requirement that the programming interfaces specified in this document be capable of being implemented in the most efficient manner possible on the target operating system.

Standardisation and Portability

The reason for these two goals stems from a desire to have this API be accepted as a standard for system metrics acquisition. The intent is to propagate the Data Capture Interface across a wide range of systems so that performance applications can themselves be ported to those systems. To do so, the specification of the programming interface cannot impose constraints which would make implementations difficult. An example of such a constraint would be a requirement that the entire DCI be implemented in either the system or user address space. Such a requirement unnecessarily limits the implementor's options, possibly precluding implementation on some systems, and would thus decrease DCI availability to the performance community.

Multiple Metrics Sources

The goal of allowing non-operating system information providers arises from practical considerations. Metrics collection and management is a system problem. Not all metrics necessarily reside in the operating system. Many metrics also exist in user space server programs or in applications. This decentralised information is exaggerated in the case of microkernel operating system architectures, although it also exists in operating systems with traditional structures. This goal allows the API to not only cover a wide range of system types but also allows for the introduction of vendor supplied metrics to a local system. This goal requires that loadable subsystems, such as device drivers, streams modules, and transaction processing applications, be able to register and provide their metrics.


One of the keys to extensibility is to allow variable representations of metric data. If the API requires that applications have prior knowledge of the availability of metrics and their data types, then this information would have to be maintained separately. When the metadata (information that describes a data structure) and the data it describes are disjoint, then possible version skew problems are introduced. Therefore it is a requirement that the API specify "self-describing" data structures. The solution should allow applications to read both the metrics metadata and the data it describes and not require prior knowledge of the metadata contents.

Efficient Enablement for Multi-system Measurement

The limitation of this API's scope to the information coming from a single system is motivated by practicality. (In this document, a single system refers to any machine or machines which use a single operating system image and could be uniquely identified on a network.) The Data Capture API provides the most basic of services: locating system information and providing that information to a higher level application. More complex services, such as distributing the information across a network of machines or data reduction, will use the information gathered by this API and should be provided by higher layers. Limiting the scope of this specification to a single system has the added benefit of deferring the problems of heterogeneous data representation to higher layers, where they belong. However, defining the scope to cover a single system should not prevent solutions of multiple system issues at the higher layers.

Polled Metrics and Events

Much of performance monitoring consists of polling activity counts. However it is also useful to provide event driven information. An application should be able to request notification of one or more events. The event features should not preclude supporting a wide range of event throughput requirements; from low speed events such as disk mounting and unmounting to the high bandwidth required by trace packages.

Modification of Configuration Data

Often the application measuring performance may wish to take steps to address a perceived performance problem. This might take the form of configuration changes (e.g., widening network timeout windows). The DCI can offer a front-end to simple configuration management, if the underlying implementation supports it.


It is now a computer industry requirement that security issues be addressed whenever specifying the collection and distribution of information. The information specified by the Data Pool document (see reference DPD) covers the activity of an entire system. A secure system implementation must concern itself with discretionary and mandatory access control between objects (metrics) and subjects (metrics requesters) before allowing the metrics to be propagated. This specification has been designed to be implemented on systems with the full range of security requirements: from no security to the highest security levels. Note that although this specification must allow for highly secure implementations the choice of security level is dependent on the target system.

Multiprocessor Systems

Multiprocessor systems are becoming commonplace in the computing world. Any programming interface must take into account these systems and allow for the provision of a thread-safe environment. When designing with multiprocessor systems in mind, one should avoid the introduction of global variables. Global variables work perfectly well in single threaded environments but require synchronised access in multi-threaded environments. Beyond taking care to not introduce functions which require undue synchronisation, multiprocessor support should be relatively straight forward.


It is no longer acceptable in the world of computing to limit textual output to English. Should the specification call for the use of any text fields, these fields should be capable of providing the native system's ability to support internationalised text. As with security, the decision to provide internationalised text is dependent on the target implementation.

Such is the frequency of use of the word internationalization, that it it commonly abbreviated in this and other documents to i18n or I18n.


Although this API is intended to be a single machine interface, it should provide the metrics in a format that does not make it difficult to transport those values in a heterogeneous, networked environment. Furthermore, application software should be capable of operating upon the data regardless of the machine that is eventually used for the operation. It is intended that this interface work well as low level support for a range of distributed management and performance applications.


This section describes features which are considered to be out of the scope of this specification.

Definitions, Acronyms and Abbreviations

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


A conformant implementation must support the basic support functions as listed in DCI Routines, Grouped by Implementation Subset of this specification. In addition, an implementation may support any of the following DCI API subsets:

These are also listed in DCI Routines, Grouped by Implementation Subset .

For each of these additional capabilities supported in an implementation, all DCI APIs in the corresponding subset must be implemented in their entirety.

Functions in unsupported subsets must be implemented to the extent that they return the [DCI_NOIMPLEMENTATION] error code.

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