Previous section.

UMA Data Pool Definition (DPD)
Copyright © 1997 The Open Group

About the Datapool

Data Organisation

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 necessary.

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. In particular, the arrangement of data items in these structures is done in such a fashion that new items may be added without requiring recompilation of existing applications. Items that become obsolete will be zero-filled, whereas new items are added at the end.

Data Standards

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 four categories:

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

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:

UMA (1.2.826.0.1050.7) | datapool (1) | +-----------+----------+- ---| | | | processor memory (2) (3)

The use of object identifiers allows for standard 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 registration authority.

It is anticipated that, in the future, further standard metrics will be defined, and mechanisms will be established for the administration of the namespace.

Default UMA WorkInfo Types

The default UMAWorkinfo enumeration has the following fields:

UMA_WORKINFO_PROJECT

UMA_WORKINFO_GROUP_ID

UMA_WORKINFO_EFFECTIVE_GROUP_ID

UMA_WORKINFO_USER_ID

UMA_WORKINFO_EFFECTIVE_USER_ID

UMA_WORKINFO_SESSION_ID

UMA_WORKINFO_TTY

UMA_WORKINFO_NQS

UMA_WORKINFO_SCHEDULING_CLASS

UMA_WORKINFO_SCHED_GRP

UMA_WORKINFO_TRANSACTION_ID

UMA_WORKINFO_PROCESS_GRP

UMA_WORKINFO_PARENT_PROCESS_ID

UMA_WORKINFO_COMMAND_NAME

UMA_WORKINFO_PROCESS_ID

UMA_WORKINFO_THREAD_ID


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