UMA Data Pool Definition (DPD)
Copyright © 1997 The Open Group
About the Datapool
In this data organization, data is grouped into "messages".
These messages contain a standard header followed by one or
more data items.
A message class and subclass uniquely identify the contents
of these messages.
The rationale behind this organization is the need to provide a
well defined format suitable for postprocessing either locally or
at another system.
This format facilitates the writing of data reduction and
display programs and would not require any program modification or
recompilation merely because new data is made available.
Current operating technologies do not lend themselves to this
function and a different type of structure was perceived to be
The fact that the data uses a message format does not imply that the
underlying implementation uses message passing.
Any implementation is allowed so long as the data presented by
the UMA Measurement Layer Interface (see reference MLI)
is in the correct format.
The actual layout of the structures
allows for both forward and backward compatibility.
the arrangement of data items in these structures is done in such a
fashion that new items may be added without requiring recompilation of
Items that become obsolete will be zero-filled, whereas new items
are added at the end.
Data items have been categorized, in part, by the degree of
standardization deemed necessary. This process included the division
of the data items of each subclass into groups:
The basic data items are those that should be given first
priority to be made available in every implementation.
To distinguish technology currently available form future products, this group is further subdivided into Level 0 and Level 1.
The optional data items are those that may be
implemented in every implementation (that is, they are standard but optional).
There are also extension data items, which are those that may
be implemented by at least one vendor (that is, vendor specific).
No data items of this type are defined in this document.
Therefore, each metric belongs to one of the following
The first three categories are part of the Datapool Standard.
The prefix in the DatumID of each metric reflects its level -
with a "0" for Level 0, a "1" for Level 1 and the
string "opt" for Optional.
Level 0 Metrics (UMA DP95)
The level 0 specification is an attempt to formalize
existing common practice, and should be implementable on the bulk of the UNIX
installed base, using OS releases that were available in 1995.
To comply with the UMA Datapool standard, an implementation must provide
all applicable level 0 subclasses, and all of the level 0 metrics in those
subclasses must be provided.
Level 1 Metrics (UMA DP97)
To provide direction for OS vendors, a common
set of metrics that are needed to implement performance management tools is
defined. These should be implementable in a reasonable timeframe, such that a
future (1997 or later) release of the OS could be expected to provide the
additional metrics. It is expected that many OS vendors will provide some of
the level 1 metrics on their intermediate releases. Individual level 1 metrics
should be provided where available in advance of the full set. To be compliant
with the level 1 standard, all applicable level 1 subclasses must be provided.
Optional metrics are defined to be implementation specific.
They will never be required on all OS platforms, but they are expected to be
available on platforms that share common implementations. To ensure
consistency they are defined as optional rather than as platform specific.
Optional metric identification numbers start at 85.
Platform or Vendor Specific Metrics
Metrics that are only expected to exist on one platform will
not be considered for inclusion in the UMA Datapool standard. They can be
specified and provided as vendor extensions in vendor specific classes.
Management Application Assumptions
A management application can assume that
all level 0 metrics will exist in a class. When interfacing with UMA DP95
compliant systems, existence of additional level 1 and optional metrics will
need to be determined at run time. When interfacing with a UMA DP97 compliant
system, the management application can assume that all level 1 metrics will
exist, and only need test for optional metrics.
Uniqueness of Identifiers
In order to provide a mechanism for the assignment of unique identifiers to
metrics, a naming convention based on object identifiers has been adopted.
The following prefix has been allocated:
ISO(1); National Member Body(2); UK(826); DISC(0); X/Open(1050); UMA(7)
The resultant naming structure is shown below:
| | |
The use of object identifiers allows for
metrics to be allocated
identifiers within the UMA naming tree. It provides for extensibility by
allowing implementors to define identifiers within their own parts of the
naming tree. Thus vendor-specific metrics can be easily incorporated into the
UMA without the need to have an identifier allocated by an external
It is anticipated that, in the future, further standard metrics will be
defined, and mechanisms will be established for the administration of the
Default UMA WorkInfo Types
The default UMAWorkinfo enumeration has the following fields:
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.