JPH06208487A - ディスプレイ方法及びディスプレイシステム - Google Patents

ディスプレイ方法及びディスプレイシステム

Info

Publication number
JPH06208487A
JPH06208487A JP5238545A JP23854593A JPH06208487A JP H06208487 A JPH06208487 A JP H06208487A JP 5238545 A JP5238545 A JP 5238545A JP 23854593 A JP23854593 A JP 23854593A JP H06208487 A JPH06208487 A JP H06208487A
Authority
JP
Japan
Prior art keywords
data
console
context
instrument
statistics
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP5238545A
Other languages
English (en)
Inventor
James N Chen
ニューマン チェン ジェイムズ
Niels Christiansen
クリスチャンセン ニールズ
Joseph C Ross
クリントン ロス ジョゼフ
Albert T Rowan
テランス ロワン アルバート
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JPH06208487A publication Critical patent/JPH06208487A/ja
Pending legal-status Critical Current

Links

Abstract

(57)【要約】 【目的】 データ処理システムに柔軟性の高い解析ツー
ルを提供すること。 【構成】 データ処理システムの記録されたシステムパ
ラメータデータを図形コンテクスト内にディスプレイす
る方法及びディスプレイシステムであって、データ処理
システムから記録されたシステムパラメータデータを読
み取り、かつ情報をディスプレイするためのディスプレ
イ手段上に可変速度でシステムパラメータをディスプレ
イする方法及びシステムを備える。

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は、一般に、データ処理シ
ステムに係り、特に、データ処理システムの動作を解析
するために使用されるパフォーマンスツールのフィール
ドに関する。
【０００２】
【従来の技術】関連特許出願のクロス・リファレンス 1991年 6月10日に出願された出願番号第07/713,484号 1991年 6月10日に出願された出願番号第07/713,471号 1991年 6月10日に出願された出願番号第07/713,486号 1992年10月23日に出願された出願番号第07/965,982号 1992年10月23日に出願された出願番号第07/965,956号 1992年10月23日に出願された出願番号第07/965,960号 1992年10月23日に出願された出願番号第07/965,954号 1992年10月23日に出願された出願番号第07/965,981号 1992年10月23日に出願された出願番号第07/965,953号
【０００３】データ処理システムは計算量が成長を続け
ているが、この種のシステムの開発、設計、及びデバッ
グにおいて使用されている従来のツールは、使用する
際、あまり実用的でなくなってきている。例えば、パソ
コンの開発及び設計において、エンジニアは、ハードウ
ェア及びソフトウェア内の誤差を捜し出すのを補助する
ために、論理解析器及びオシロスコープを使用する。こ
れらのデータ処理システムを実行するソフトウェアがよ
り複雑になるので、回路内エミュレータのようなツール
が開発され、これによって、中央処理装置（ＣＰＵ）の
命令の流れが捕獲されかつ解析される。これらのタイプ
のツールは、問題解決を補助するために、大量の人間の
介入及び人間の解析をさらに必要とする。
【０００４】種々のタイプのソフトウェアツールが、IB
M 社のシステムパフォーマンスモニター／２のようなデ
ータ処理システムをモニタする際に補助する為に、市場
に導入されている。このツールは、データ処理システム
の種々のアスペクトを描写するために図形インターフェ
ースを提供し、かつデータ処理システムの動作を解析す
るために必要とされる時間を大幅に削減する。これらの
システムが、データ処理システムをモニターし、かつ解
析するための従来の方法に対して実質的な改善点を提供
しているが、まだいくつかの欠点がある。第１に、これ
らはデータ処理システムにおいてハードウェア資源へ適
合され、かつソフトウェア処理又はアプリケーションを
モニタするための能力に十分にはアドレスしない。第２
に、提供されるフレキシビリティ及び粒状度は限定され
ている。さらに、パフォーマンスデータは、ユーザディ
スプレイデバイスへ出力されるだけであり、これによっ
て捕獲されるデータを解析する際に完全なフレキシビリ
ティを提供するわけではない。
【０００５】IBM NetView （ネットビュー）／6000（Ｔ
Ｍ）プログラムのようなネットワークモニタリングツー
ルは、主に、ネットワーク資源を利用可能でありかつア
クセス可能であるように保持することを目的とする監視
及び訂正動作に関連している。資源の使用可能性は資源
利用よりむしろこの種のツールの問題である。例えば、
IBM ネットビュー／6000はディスクの自由空間の量をト
ラックする。
【０００６】フレキシブルでかつ使用が簡単でハードウ
ェアだけでなくソフトウェアの事象及びプロセスアクテ
ィビティをモニタすることができ、引き続く検索及び解
析のためのデータ（例えば、読み取りサンプルデータ）
を捕獲することができ、かつこの種の捕獲されたデータ
をさらに解析しかつ類別するために他の機能を提供する
データ処理システムパフォーマンスツールを提供する必
要がある。
【０００７】
【発明が解決しようとする課題】本発明の目的は、デー
タ処理システムに高度にフレキシブルな解析ツールを提
供することにある。
【０００８】本発明の他の目的は、データ処理システム
にパフォーマンスツールを提供することにある。
【０００９】本発明のさらに他の目的は、データ処理シ
ステムの動作のモニター、捕獲、検索、及び解析のため
のツールを提供することにある。
【００１０】
【課題を解決するための手段】これらの種々の目的は、
パフォーマンスツール及びその関連するアプリケーショ
ンプログラミングインターフェースによって達成され、
かつパフォーマンスデーモンは、コンピュータシステム
のネットワークを介してパフォーマンス統計の対話形選
択、パフォーマンスデータの流れの制御、動く（ライ
ブ）図形における遠隔ホストパフォーマンスのモニタリ
ングのために設計される。
【００１１】設計のキーアスペクトのうちのいくつか
は、（１）プロットスタイルの組合せ可能な高度にカス
トマイズできるグラフにおいて遠隔データを図形的にモ
ニタすること、（２）モニタリングプログラムが、ネッ
トワーク内のどのホストが統計を供給することができる
か、及び各ホストからどの統計が入手可能なのかを知る
ことが必要とされないこと、（３）ネットワーク上の統
計の源の対話形探究、及び各源から入手可能な統計の収
集、並びに（４）ネットワークをモニタするためにデー
タシステムが何を処理するかの交渉、の組合せの中にあ
る。
【００１２】コンピュータシステムは、ネットワークノ
ード、複数のCPU （中央処理装置）、メモリ、複数のプ
ロセス、その他のごとき様々な異なるタイプのハードウ
ェア及びソフトウェアの構成要素から成る。パフォーマ
ンス解析の分野においては、これらのオブジェクトは、
パフォーマンスデータの収集、及びパフォーマンス統計
の計算に対して異なるコンテクストを示す。
【００１３】計算環境は連続的に一層より小さな構成要
素へと分解され得るので、これらのパフォーマンス解析
コンテキストの階層を定義する。本明細書中に開示され
ている xmperf パフォーマンスツールにおいては、全て
の統計が特定のコンテキストに対応しており、かつこれ
らのコンテキストは、トップレベルコンテキストからこ
のコンテキストへ向かって移動する全てのコンテキスト
をテーブル（表）に記載することによって識別される。
例えば、ネットワークベースの計算環境の場合において
は、“ultra ”と呼ばれるホスト上の“hdisk0”と呼ば
れるディスクは以下のパスを用いて参照される。
【００１４】/hosts/ultra/disks/hdisk0 次に、このディスク上の読み取り動作の数に対する統計
は、上記パスに統計名を付け加えることによって参照さ
れ得る。
【００１５】/hosts/ultra/disks/hdisk0 /reads 特定のネットワークにおけるホストのセット、及びどれ
か一つのシステムの構成はその環境や時間によって大き
く変わることもある。さらに、資源モニタリングツール
は、動的に生成され、かつ警告せずに消えるプロセスの
ようなモニタリングエンティティの問題に直面する。こ
れによって、統計的に定義されるコンテキストの階層は
十分ではないが、その代わりに、コンテキスト階層が動
的に生成されかつ実行時に変更可能でなければならない
ことがはっきりする。
【００１６】パフォーマンスツール（ xmperf ）におい
て、この問題は、オブジェクト用モデルを使って取り扱
われる。このモデルにおいて、パフォーマンス統計コン
テキストの総称階層はコンテキストクラスの階層を用い
て定義される。統計は、これらのクラスの属性であり、
かつ一般に、特定のコンテキストのクラスの全例が同じ
セットの統計を有する。例えば、“disks ”のクラスに
関連する統計は、“busy time（ビジータイム）”、
“average transfer rate （平均転送レートを平均せ
よ）”、“number of reads （読み取り数）”、“numb
er of writes（書き込み数）”、その他を含むこともあ
る。各クラスは、各統計ごとに、その統計が計算される
必要がある時はいつでも呼び出すことができる“get
data( )”方法（関数）も有している。
【００１７】xmperf においては、コンテキストクラス
はそのクラスのオブジェクト例を生成するために呼び出
される“instantiate( )（例示せよ）”方法を含む。例
えば、この方法は、特定のシステム内の各ディスク
（例：“hdisk0”、“hdisk1”、その他）にデータを収
集するために、パフォーマンス解析コンテキストを発生
するように、“disks ”のクラスのために使用される。
これらのディスクコンテキストは全て、これらのコンテ
キストが“disks ”クラスから引き継ぐ同一セットの統
計及び“get data( )”方法を有する。
【００１８】クライアント／サーバモデルは、一般的に
は（必ずしもそうではないが）ローカルエリアネットワ
ーク（ＬＡＮ）などのネットワークをモニタするパフォ
ーマンスを許容するために実行される。このモデルは、
モニタリング機能を提供する“Data Consumers（データ
消費者）”と呼ばれるサーバシステム及び一つ以上のク
ライアントプログラムにおいてデーモンとして実行され
る“Data Supplier （データ提供者）”として公知のサ
ーバプログラムによって供給される。
【００１９】Data Supplier （データ提供者）デーモン
は、 ・ データの論理的グループ化を提供するために、階層
において編成されるその統計データを有する。 ・ ネットワークに対して要求があり次第、及びデーモ
ンがどの統計を使用できたかを選択的ベースで示す。 ・ 交渉できる頻度でパフォーマンスデータの一つ以上
のセットの連続的な流れについてサブスクリプション
（予約）を受け入れる。 ・ 単純アプリケーションプログラミングインターフェ
ースを介して統計の在庫管理の動的拡張を提供する。
【００２０】Data Consumer Programs（データ消費者プ
ログラム）は、 ・ 以下により詳細に記述されるように、開発された図
形モニタリングプログラムである。 ・ 一つ以上のデータ提供者（Data Supplier ）デーモ
ンの関心の対象である一つ以上のセットの統計と交渉す
るため、及びネットワークに対するデータ提供者からこ
れらの統計が受け取られた時の統計に基づいて、正確な
動作を受け取り、処理し、ディスプレイし、かつ実行す
るため、開発されたアプリケーションプログラミングイ
ンターフェースを用いたユーザ開発（アプリケーショ
ン）プログラムであり得る。
【００２１】重要な設計の目的は、データ消費者プログ
ラムが、データ提供者から利用可能な統計について前知
識をもつことを全く必要としないことを確実とすること
であった。これは、ネットワークにおける全てのホスト
が同一の構成及び能力を有しているわけでなく、これに
よって統計の同一収集を提供することができないという
事実によりさらに強調された。解決法は、データ消費者
がポテンシャル（潜在的）データ提供者と協議すること
であった。実践は、以下のメッセージタイプを有するプ
ロトコルに基づいた低コストのトランスミッション制御
プロトコル（ＴＣＰ）及びユーザデータグラムプロトコ
ル（ＵＤＰ）である。 ・ ネットワークへの潜在的データ提供者を識別し、か
ついづれのパートナーがまだ実行中かをチェックするた
めのコントロールメッセージ。 ・ 識別された提供者から利用可能な統計を調べ、かつ
データに対するサブスクリプションを定義するための構
成メッセージ。 ・ ネットワークに対するデータの連続的な流れを制御
するためのデータ送り及び送り制御メッセージ。 ・ データ提供者の状態を問い合わせるための状態メッ
セージ。 ・ データ提供者デーモンによって付加的統計をレジス
タするためのメッセージ。
【００２２】プロトコルは、１２４個までの個々の値
が、一つのセットへグループ化され、かつ単一パケット
内へネットワークを介して送られるのを許容する。ある
値はモニタされる統計の最も繊細な細分性であり、かつ
それに対応する属性を有している。単純なアプリケーシ
ョンプログラムインターフェースはアプリケーションプ
ログラマからプロトコルを隠蔽し、かつプロトコルをア
プリケーションプログラムから隔離させる。この隔離
は、主として、アプリケーションプログラムに未来のプ
ロトコル拡張を知らせないようにし、かつ他のベースプ
ロトコルを支援する。
【００２３】パフォーマンスモニタツールは、このプロ
ジェクトの最可視部分である。これは、ユーザが、モニ
タと関連しているデータを対話式に選択することを可能
とすると共に、所定セットのモニタ“devices （デバイ
ス）”が保持されることも許容するプログラムに基づい
たOSF/Motif （OSF/Motif はオープンソフトウェアファ
デーション（Open Software Foundation) の登録商標）
である。このツールはデータ処理システム内での処理を
制御するためにユーザと対話するためのインターフェー
スも提供する。
【００２４】基本的モニタリングデバイスはモニタと呼
ばれる。このモニタは、ディスプレイにウィンドウとし
て表され、かつポップアップ又はプルダウンメニューか
ら活動化されたり、非活動化され得る。
【００２５】複数のモニタは一度に活動状態（アクティ
ブ）となり得る。モニタ内では、一つ以上のセットのデ
ータ処理システム統計が、計器と呼ばれるサブウィンド
ウ内で監視され得る。計器は、データ提供者デーモンを
実行するネットワークのいづれのホストからも提供され
る１セットの統計をモニタすることができる。１セット
の統計は、データ提供者から利用可能な統計の完全な収
集の中から選択され得る。計器は、多くの異なる図形形
式において、計器の統計のセットを図形的にディスプレ
イすことができる。
【００２６】最も汎用な図形形式は、各統計値が四つの
描画スタイルの内の一つにおいて作図されるタイムスケ
ール上で統計を示す。 ・折れ線グラフ ・スカイライングラフ（角ばった折れ線グラフ） ・エリア（区分）グラフ（折れ線グラフで書き込まれ
る） ・棒グラフ
【００２７】作図スタイルの適切な選択によって、他の
データ値を重畳することが可能となり、これによってパ
フォーマンスデータの容易な相互関係を提供する。他の
機能は、あるセットにおける値の部分集合の累積作図を
可能とする。
【００２８】本発明の一つの態様は、データ処理システ
ムの記録されたシステムパラメータデータを図形コンテ
クスト内にディスプレイする方法であって、前記データ
処理システムから前記記録されたシステムパラメータデ
ータを読み取るステップと、情報をディスプレイするた
めのディスプレイ手段上に可変速度で前記システムパラ
メータデータをディスプレイするステップと、を備える
ディスプレイ方法である。
【００２９】本発明の他の態様は、データ処理システム
の記録されたシステムパラメータデータを図形コンテク
スト内にディスプレイする方法であって、前記データ処
理システムから前記記録されたシステムパラメータデー
タを読み取るステップと、情報をディスプレイするため
のディスプレイ手段上に指定された可変速度で前記記録
されたシステムパラメータデータのある部分をディスプ
レイするステップと、を備えるディスプレイ方法であ
る。
【００３０】本発明の他の態様は、図形コンテクスト内
にデータ処理システムのシステムパラメータデータをデ
ィスプレイする方法であって、情報をディスプレイする
ためにディスプレイ手段上に前記システムパラメータデ
ータのある部分をディスプレイするステップと、前記デ
ィスプレイ手段上に前記システムパラメータデータの第
２の部分をディスプレイし、かつ新しいノードに対して
オブジェクトを再マウントすることによって、前記第２
の部分に対応するパラメータデータコンテクスト変更す
るステップと、を備えるディスプレイ方法である。
【００３１】本発明の他の態様は、データ処理システム
の記録されたシステムパラメータデータを図形コンテク
スト内にディスプレイするためのシステムであって、
前記データ処理システムから前記記録されたシステムパ
ラメータデータを読み取るための手段と、情報をディス
プレイするためのディスプレイ手段上に指定された可変
速度で前記システムパラメータデータをディスプレイす
るための手段と、を備えるディスプレイシステムであ
る。
【００３２】本発明の他の態様は、データ処理システム
の記録されたシステムパラメータデータを図形コンテク
スト内にディスプレイするためのシステムであって、前
記データ処理システムから前記記録されたシステムパラ
メータデータを読み取るための手段と、情報をディスプ
レイするためのディスプレイ手段上に指定された可変速
度で前記記録されたシステムパラメータデータのある部
分をディスプレイするための手段と、を備えるディスプ
レイシステムである。
【００３３】本発明の他の態様は、データ処理システム
のシステムパラメータデータを図形コンテクスト内にデ
ィスプレイするためのシステムであって、情報をディス
プレイするためのディスプレイ手段上に、前記システム
パラメータデータのある部分をディスプレイするための
手段と、前記ディスプレイ手段上に前記システムパラメ
ータデータの第２の部分をディスプレイし、かつ新しい
ノードへオブジェクトを再構築することによって、前記
第２の部分と対応するパラメータデータコンテクストを
変更するための手段と、を備えるディスプレイシステム
である。
【００３４】本発明の他の態様は、データ処理システム
の同一パフォーマンス統計の複数のビューを同時ディス
プレイするための方法であって、ある抽出インターバル
においてシステム統計の第１のサンプル値を捕獲するス
テップと、異なる抽出インターバルにおいて前記システ
ム統計の第２のサンプル値を捕獲するステップと、デー
タをディスプレイするためのディスプレイ手段上に前記
第１のサンプル値と前記第２のサンプル値を同時にディ
スプレイするステップと、を備える同時ディスプレイ方
法である。
【００３５】本発明の他の態様は、データ処理システム
の同一パフォーマンス統計の複数のビューを同時ディス
プレイするためのシステムであって、ある抽出インター
バルにおいてシステム統計の第１のサンプル値を捕獲す
るための手段と、異なる抽出インターバルにおいて前記
システム統計の第２のサンプル値を捕獲するための手段
と、データをディスプレイするためのディスプレイ手段
上に前記第１のサンプル値と前記第２のサンプル値を同
時にディスプレイするための手段と、を備える同時ディ
スプレイシステムである。
【００３６】
【実施例】図１に示されているように、パフォーマンス
ツール９０は五つのサブシステムと二つのインターフェ
ースからなることが理解され得る。以下の部分はこれら
の構成要素の各々を記述している。
【００３７】パフォーマンスツールの図形ユーザインタ
ーフェース（GUI ）８０は、ユーザが、ポインティング
デバイス（例：マウス又はトラックボール）を使用する
ことによってほぼ全体的にモニタリングプロセスを制御
するのを許容する。GUI ８０は広範囲にメニューを使用
し、かつ以下の四つのサブシステムと直接通信する。
【００３８】記録サブシステムへのGUI GUI ８０は、ユーザが、任意のアクティブモニタリング
コンソールと任意のアクティブなモニタリング計器から
の記録を開始しかつ停止するのを許容する。記録が記録
サブシステム２０で開始される時、全体のモニタリング
コンソールの構成は記録ファイル（図２の参照番号１０
０）へ書き込まれる。記録ファイル１００それ自体は、
ネームが記録されているモニタリングコンソールのネー
ムからネーミングされる。
【００３９】モニタリングコンソールの構成に関する全
ての情報が記録ファイル１００に格納されるので、ユー
ザと再生サブシステム５０の間で冗長な対話を行なわず
に再生が開始され得る。GUI ８０を介して、ユーザは要
求に従って、記録の開始及び停止を行なうことができ、
かつ記録がモニタリングコンソールに必要とされる時
に、既に記録ファイルが存在しているならば、現存ファ
イルに追加するか又はファイルを置き換えるかの選択が
ユーザに与えられる。
【００４０】構成サブシステムへのGUI 構成サブシステム３０はコンソール及び計器のモニタリ
ングについて情報を得るために二つの手段を有してい
る。第１に、構成ファイル（図３の参照番号１１０）は
多くのモニタリングデバイスに対する構成情報を含むこ
とができる。これらは、骨組み（スケルトン）コンソー
ルか又は固定コンソールであってもよい。第２に、ユー
ザは、GUI ８０を介して直接固定コンソールについて構
成を付け加え、変更し、かつ削除することができる。構
成情報が、構成ファイルから読み取らるか、又はユーザ
との対話において確立されたかのいづれにせよ、構成情
報は、構成メッセージを、構成サブシステム３０及びネ
ットワーク送信／受信インターフェース７０並びに遠隔
データ提供者デーモン（図８の参照番号２１０）の間で
交換させることになる。
【００４１】スケルトンコンソールはディスプレイすべ
きパフォーマンスデータの正確な選択が開かれたままで
あるモニタリングデバイスである。スケルトンコンソー
ルを起動させるためには、ユーザは、プロセス、遠隔ホ
ストシステム、又はモニター用物理的ディスクのような
利用可能なパフォーマンスデータの一つ以上の例を指定
しなければならない。
【００４２】スケルトンコンソールが起動される度に、
新たな例が生成される。この新たな例は、ユーザが、複
数の同様の外観のコンソールを起動させるのを可能と
し、これによって各コンソールが一つのスケルトンコン
ソールから異なるパフォーマンスデータをモニタするこ
とができる。
【００４３】データディスプレイサブシステムへのGUI モニタリングデバイスを構成することに加えて、ユーザ
はモニタリングデバイスを起動させたり又は閉じたりす
るためにGUI ８０を使用し、これによって構成サブシス
テム３０とネットワーク送信／受信インターフェース７
０の間でネットワークメッセージを交換させる。これら
のメッセージは、主として、遠隔データ提供者デーモン
（図８の参照番号２１０）への、どのパフォーマンスデ
ータをどの位の頻度で送るべきかについての命令からな
る。
【００４４】データディスプレイサブシステム４０は、
構成サブシステム３０からモニタリングデバイスについ
ての情報を受け取り、この情報をユーザが選択するため
のモニタリングデバイスのリストをユーザに提供するた
めに使用する。スケルトンコンソールの場合において、
GUI ８０は、スケルトンコンソールを例示する時、ユー
ザが選択できる項目のリストも提供する。
【００４５】再生サブシステムへのGUI 最終的に、GUI ８０は参照番号５０において記録する再
生を開始するために使用される。記録は、ディスクファ
イル内に保持され（図２の記録ファイル１００）、かつ
これらの記録を再生するために使用される同じホストシ
ステムにおいて生成されたり、又は他のホストにおいて
発生したりする。このフレキシビリティは、遠隔カスト
マー又はユーザが、ある作業負荷のためにパフォーマン
スデータを記録し、かつパフォーマンスデータを解析す
るためにサービスセンターや技術支援グループへ郵送す
るのを許容する。
【００４６】記録１００は、当該情報が記録されるモニ
タリングコンソールの正確なレプリカを再生するために
全ての必要な情報を含む。記録ファイルがディスプレイ
のために選択される時、埋め込まれた構成データはデー
タディスプレイサブシステム４０へ渡されかつ再生コン
ソールが図形ディスプレイ上で構築される。
【００４７】一旦再生コンソールが開かれると、ユーザ
は、殆どあらゆる速度で記録を再生できると共に、巻戻
したり、記録上のタイムスタンプを捜し出したり、記録
を消去したり、記録の再生を停止したりすることができ
る。
【００４８】構成サブシステム 図３に関しては、構成サブシステム３０は、パフォーマ
ンスツールにおいて幾つかの重要な機能、即ち図形ユー
ザインターフェース８０、構成ファイル１１０、ネット
ワーク送信／受信インターフェース７０、及びデータデ
ィスプレイサブシステム４０を有している。各機能は、
以下に示されているように、インターフェース又は他の
サブシステムのうちの一つと密接に関わっている。
【００４９】図形ユーザインターフェース（GUI ）８０
を介して、ユーザは、使用するモニタリングデバイスを
設計し、スケルトンコンソールを例示し、コンソールを
起動させたり閉じたりし、かつネットワーク２００にお
けるデータ提供者デーモン（図４の参照番号２１０）の
いづれからも利用可能なパフォーマンスデータの階層を
走査することができる。これは、GUI ８０、構成サブシ
ステム３０、及びネットワーク送信／受信インターフェ
ース７０の間で密接に協働しあって実行される。
【００５０】GUI は、ユーザに、図形パフォーマンス
「コンソール」の外観と内容を完全に指定することを許
容する一連の図形メニューを提供する。メニュー選択に
よって、ユーザは新たな「コンソール」ウィンドウを生
成し、新たな「計器」サブウィンドウズを付け加え、か
つ任意の計器に対する複数の計器値を付け加えることが
できる。値は、モニターされ、ディスプレイされ、かつ
／又は記録される個々の統計であるとともに、ＣＰＵ、
メモリ、頁空間、ディスク、ネットワーク、プロセス、
システムの呼び出し、システムの入力／出力、プロセス
間通信、ファイルシステム、通信プロトコル、ネットワ
ークファイルシステム、又は遠隔手順呼び出しのような
システム要素に対するこの様な統計を含んでいる。ユー
ザは、カラー、値の範囲、ディスプレイスタイル、抽出
頻度、ラベリング、及び他の値の属性に対するメニュー
制御も有している。この情報の全てが Motif資源ファイ
ルと同様の「スタンツァ（Stanza) （状態）」形式にお
いて ASCII（アスキー）構成ファイル１１０に格納され
る。ユーザが遠隔統計にアクセスしたい場合、遠隔ノー
ドは、これらの遠隔統計が利用可能であることを確実と
するため、ネットワーク送信／受信インターフェース７
０を介して接触され、かつ一般的に、局所構成ファイル
における「スケルトン」コンソールによって指定される
その必要とされる統計を得る。ユーザがGUI を介してこ
れらの選択を行なった後、要求されたコンソールがディ
スプレイされ、かつライブデータが図形コンソールへ送
られる。ユーザがコンソールを見るのが終了した時、そ
れは「閉じ」られ、又は「消去」され得る。コンソール
を閉じることによって、後で（ユーザが）起動させかつ
見るために、構成ファイル１１０においてコンソールを
使用可能にしておく。コンソールを消去することによっ
て構成ファイルからこのコンソールが除去されるので、
コンソールはスクラッチ（ファイル）から再構築されな
ければならない。
【００５１】ユーザがコンソールを設計した時、最終的
な構成が構成ファイル１１０に書き込まれることがで
き、これにより、パフォーマンスツールの将来の呼出し
は、このツールが動作を開始する時、このファイルを読
み取ることによって構成の情報を得ることができる。
【００５２】構成ファイル１１０はパフォーマンスツー
ルユーザにとって重要なツールである。このファイルは
以下の三つのタイプの情報を含む。 ・ 実行可能プログラム 任意の数の実行可能プログラム及びスクリプトは、各々
の短い定義を構成ファイルに入力することによって、パ
フォーマンスツールのプルダウンメニューに配置され得
る。プログラムは、それらのコマンドラインオプション
の種々の部分集合によって複数回入力され、かつプログ
ラムが実行される前に、ユーザがコマンドライン引き数
に対して指示されるように、プログラムが定義される。
プロンプティング（指示）は、必要な又はオプショナル
な引き数のために提供され、定義されたデフォルト（省
略値）を有することもあり、かつMOTIF スタイルダイア
ログウィンドウズから供給される。プログラムの定義
は、現在は、手動により構成ファイルに入力されなけれ
ばならない。 ・ 固定コンソール このコンソールタイプはモニタするために所定セットの
パフォーマンスデータによってコンソールを定義する。
固定コンソールは、構成ファイルへ手動で入力され得る
か、又はオンライン構成セッションの結果としてGUI を
介してユーザによって保管され得る。 ・ スケルトンコンソール スケルトンコンソールは、ディスプレイするためのパフ
ォーマンスデータの正確な選択がユーザによって指定さ
れるように開かれたままにされたモニタリングデバイス
である。スケルトンコンソールは現在は手動で構成ファ
イル内へ入力されなければならない。
【００５３】大部分の構成タスクは、ネットワーク送信
／受信インターフェース７０を用いてネットワークを介
する構成情報の交換を含む。全ての構成タイプのメッセ
ージは「要求／応答」タイプのものである。これは、コ
ンソール内にディスプレイするためにデータを選択する
前にどれが利用可能かを調べるために、ユーザが、パフ
ォーマンスデータの階層を走査するのを可能とする独特
のメッセージにも成り立つ。「要求／応答」タイプのプ
ロトコルは、クライアントとサーバの間の双方向通信で
ある。データクライアントは、「データ要求」メッセー
ジをデータサーバへ送り、次いでサーバから「応答」を
待機する。サーバが指定された時間制限内で応答しない
場合、クライアントはリトライを試みるか、又はエラー
によって終了することもある。
【００５４】最後に、構成システム３０は、ユーザがコ
ンソールが起動されることを要求する時はいつでも、構
成情報をデータディスプレイサブシステム４０へ提供す
る。ユーザが「コンソール」が起動されるのを要求する
時、構成ファイル１１０からメモリへ元来読み取られた
詳細なコンソール仕様が、メモリ制御ブロックエリア内
のデータディスプレイサブシステム４０へ渡される。構
成サブシステム３０も、同様に、構成ファイルから読み
取られたスケルトンコンソールデータを、メモリ制御ブ
ロックエリア内のデータディスプレイサブシステム４０
へ渡すことができる。
【００５５】構成サブシステムは、スケルトンコンソー
ルを例示するために、可能性のあるパフォーマンスデー
タのリストを、データディスプレイサブシステム４０に
提供する。
【００５６】データディスプレイサブシステム データディスプレイサブシステム４０の主な役割は構成
サブシステム３０によって記述される形式においてパフ
ォーマンスデータをディスプレイすることと、再生サブ
システム５０又はデータ値受信者サブシステム６０のい
ずれかによってこのデータが受け取られるや否やそれを
ディスプレイすることである。図４に示されているよう
に、データディスプレイサブシステム４０は、他の三つ
のサブシステム３０、５０、及び６０、並びにGUI ８０
とインターフェースする。データディスプレイサブシス
テム３０は、主として、他のサブシステムのうちの二つ
からの情報の受信者である。GUI ８０に対する一つだけ
のインターフェースと、ある程度までの構成サブシステ
ムインターフェース１２２はダイアログタイプのインタ
ーフェースである。
【００５７】構成サブシステム３０は、構成情報の提供
者であり、かつパフォーマンスデータの階層を走査する
ための乗物（ビークル）である。前者は、図形ディスプ
レイ上のモニタリングデバイスのウィンドウズ及びサブ
ウィンドウズを構築するために使用される。後者は、ス
ケルトンコンソールが生成される時、又は普通のコンソ
ールを設計したり、変更したりする時に選択リストを提
供するために使用される。データ階層の走査は、要求／
応答ネットワークインターフェースを用いて、構成サブ
システム３０と、関連するデータ提供者デーモン２１０
との間のネットワークメッセージの交換を必要とする。
【００５８】最後に、パフォーマンスデータの開始、変
更、及び送信停止に対する要求が、図４のデータ提供者
デーモン２１０へのネットワーク送信／受信インターフ
ェース７０を介してデータディスプレイサブシステム４
０から構成サブシステム３０へ渡される。
【００５９】データ値受信者サブシステム６０へのイン
ターフェース１２４上のデータフローは、常に、データ
値受信者サブシステム６０からデータディスプレイサブ
システム４０への単方向フローである。データパケット
は、ネットワーク送信／受信インターフェース７０から
受け取られるので、データ値受信者サブシステム６０
は、受け取られたパケットからStatSetID を使用して共
通のパラメータ記憶装置領域からすべてのアクティブデ
ィスプレイコンソールのリストを検索し、コンソール制
御ブロックへポインタを指し示し、次いでインターフェ
ース１２４においてこの情報をデータディスプレイサブ
システム４０へ渡す。
【００６０】再生サブシステム５０はデータ値受信者サ
ブシステム６０を模倣して動作する。後者がネットワー
クを介してデータのパケットを受け取るところで、再生
サブシステム５０は記録ファイル１００からインターフ
ェース１２６でそれらを読み取り、かつデータ値受信者
サブシステム６０が使用する同じデータ形式でデータデ
ィスプレイサブシステム４０へインターフェース１２８
でそれらを手渡す。これによってデータディスプレイサ
ブシステム４０が、二つのデータ資源を、まるでこれら
が同一であるかのように処理することが可能となる。
【００６１】パフォーマンスツールの幾つかの独特な機
能がデータディスプレイサブシステム４０において実行
される。これらは、ユーザがその希望を通信するため
に、乗物としてのGUI ８０に全て依存している。これら
のうち以下が説明される。 ・ 変更可能グラフスタイル GUI を介してユーザによって指定され、データディスプ
レイサブシステムはいづれのコンソールにおいても任意
のモニタリング計器のグラフスタイルを瞬時に変更する
ことができる。一秒間でチャートグラフごとに見られる
データは次にはタイムスケールグラフとして見られる。 ・ 作表（タビュレーション）ウィンドウズ いかなるモニタリング計器も、その受け取られたデータ
をグラフに示す他に、それが受け取るデータを作表する
ように命令され得る。作表は特別なウィンドウズにおい
て行なわれ、かつ一対のマウスクリックでユーザによっ
てオン／オフされ得る。 ・ スケルトンの例示 ユーザがスケルトンコンソールを例示したいとする時は
いつでも、データディスプレイサブシステム４０は可能
性のあるデータ値のリストをユーザへ提供するためにGU
I ８０を使用する。次いで、ユーザはインターフェース
１３０でリストから所望されるデータを選択し、これに
よって例示されるコンソールが生成される。選択リスト
の内容は、スケルトンコンソールが構成ファイル１１０
においてどのように定義されたかに依存し、かつホスト
同士の間で又はパフォーマンスツールの複数及び異なる
実行同士の間で、変化し得るデータ階層において任意の
ノード（コンテキスト）をディスプレイし得る。
【００６２】記録サブシステム 図５の記録サブシステム２０は、インターフェース１４
０を介してGUI ８０から制御される。記録がインターフ
ェース１３０でユーザによって要求された時に最初に生
じることは、構成情報１１０が記録ファイル１００内に
格納されることである。この構成情報１１０はメモリ制
御ブロックの現在（ファイル）から抽出され、かつ以下
の制御ブロックからなる。 ・ コンソール情報 モニタリングコンソールウィンドウの大きさ及び位置を
記述する。 ・ 計器情報 モニタウィンドウ、カラー、タイリング、その他の内部
の計器が関連する位置を含むモニタリングコンソールの
モニタリング計器の各々を記述する。 ・ 値ディスプレイ情報 モニタリング計器にディスプレイされる統計値の各々の
ディスプレイ形式に関連するパスネーム、カラー、ラベ
ル、及び他の情報を記述する。 ・ 値の詳細情報 値が使用されているモニタリング「計器」から独立して
いる統計値についての情報を提供する。これは値の記述
的ネーム、データ形式、その他を含む。
【００６３】実データ記録は第５番目と最終の制御ブロ
ック形式（フォーマット）を使用する。この形式は可変
長ブロックがファイル空間を保護するために書き込まれ
ることを許容する。
【００６４】この設計は、長い識別子を格納するという
よりも、各データ記録データブロックを、記録ファイル
内の構成情報に象徴的に参照することによってデータ容
量の必要条件を抑制する。各データブロックの内容はテ
ーブル５によって以降に説明される。
【００６５】記録を起動させたコンソールごとに、記録
サブシステム２０には、データ値受信者サブシステム６
０によって処理される時、インターフェース１４２で実
データ送り情報が渡される。記録がコンソールに対して
アクティブである限り、データは一緒にパスされる。
【００６６】再生サブシステム 図６の再生サブシステムは、任意の記録ファイル１００
からの現実的な再生を許容するための論理を有する。こ
の論理は、多くのホストからのデータを有する記録にお
いて、記録が作り出された時には異なるクロック設定を
有していたタイムスタンプを捜し出すことも可能とす
る。データディスプレイサブシステム４０から見られる
ように、それ以外に、再生サブシステム５０はインター
フェース１２８を通るデータパケットの他の提供者であ
る。
【００６７】パケットはユーザ制御１３０でユーザによ
って要求される速度で記録ファイル１００から読み取ら
れ、かつインターフェース１２８を介してデータディス
プレイサブシステム４０へ送られる。
【００６８】GUI ８０は再生サブシステム５０と参照番
号１２９においてインターフェースする唯一の他のサブ
システムである。これは参照番号１３０においてユーザ
に以下のことを許容する。 ・ 記録のリストからどの記録を再生すべきかを選択す
る。 ・ 記録を再生し、かつ再生速度を加速したり減速した
りする。 ・ 記録を巻戻したり、任意のタイムスタンプへ前送り
したりする。 ・ 選択された記録を消去する。
【００６９】データ値受信者サブシステム 図７のデータ値受信者サブシステム６０は、ネットワー
ク２００から到着する全てのデータ送りパケットを受け
取り、かつ全ての対象となるサブシステムが各データ送
りパケットの複写を得ること確認するための責任があ
る。パケットが渡される前に、パケットは、それが目的
とするターゲットコンソールを識別する情報によってタ
グ付けされる。ターゲットを見つけることができない場
合、そのデータパケットは廃棄される。他のサブシステ
ム及びネットワーク送信／受信インターフェースへのイ
ンターフェースは以下に記述される。
【００７０】ネットワーク送信／受信インターフェース
７０は、ＡＰＩライブラリ関数（後に図８の参照番号１
６１によって説明される）を使用してネットワーク２０
０へアクセスする。これは、データ送りパッケージが受
け取られた時はいつでも制御を受けるＡＰＩコールバッ
ク機能を含む。データ値受信者サブシステム６０は、パ
フォーマンスツールにおいてインターフェース１５０で
データパケットを受け取る唯一の機能である。サブシス
テム６０は、ポーリングする必要はないが、受け取られ
るデータ送りパフォーマンスデータごとに自動的にスケ
ジュールされている。
【００７１】データ送りパケットが応答を必要としない
ので、インターフェース１５０におけるネットワーク送
信／受信インターフェース７０との通信は厳格に単方向
である。この単方向性とポーリング／応答の欠如によっ
て、データは非常に高いデータ転送率でインターフェー
ス１５０を介して提供されることができ、これにより、
遠隔供給統計の実時間モニタリングを許容することがで
きる。
【００７２】データパケットが受け取られた時、データ
値受信者サブシステム６０は、データディスプレイサブ
システム４０によって維持されているアクティブコンソ
ール１５６のテーブルを調べる。アクティブモニタリン
グコンソールと結びつかないデータパケットは、それら
がコンソールが閉じてから到着したものと仮定して廃棄
される。コンソールが識別された場合、記録がコンソー
ルに対してアクティグならば、記録サブシステム２０が
呼び出される。次いで、パケットは、インターフェース
１５２で、さらなる復号がデータ値の実ディスプレイの
一部として実行されるデータディスプレイサブシステム
４０へ渡される。これによって、この設計は、局所及び
遠隔供給パフォーマンス統計を実時間で同時にディスプ
レイしかつ記録するための能力を提供する。
【００７３】データパケットが、記録中のモニタリング
コンソールに属しているものと識別されるならば、記録
サブシステム２０は、記録ファイル１００にデータパケ
ットの複写を書き込むためにインターフェース１５４で
呼び出される。記録ファイルがコンソール内の計器のう
ちのあるものに対してのみアクティブである場合、これ
らの計器に属しているデータのみが記録ファイル１００
に実際に書き込まれる。
【００７４】ネットワーク送信／受信インターフェース 図８に関しては、ネットワーク送信／受信インターフェ
ース７０は、（i）パフォーマンスツールのアプリケー
ションプログラミングインターフェース（ＡＰＩ）１６
０のライブラリ関数１６１、及び（ii）ＡＰＩライブラ
リ関数１６１を呼び出すためにパフォーマンスツールの
モニタリングプログラムに対して特に書き込まれるコー
ドからなる。インターフェースはいくつかの責任を有し
ており、その主なものが以下に記述されている。 ・ データ提供者の識別 インターフェースはネットワーク２００において使用可
能なデータ提供者デーモン２１０を識別するためにＡＰ
Ｉ同報通信機能を使用する。送信勧誘パケットは、イン
ターフェース１６２を介してＡＰＩ「ホストファイル」
によって指定された通り遠隔ホストへ伝送され、ここで
ユーザが全ての局所インターフェースにおける普通同報
通信を要求するか、及び／又は、特定のホスト又はサブ
ネットが送信勧誘されるように要求し得る。ＡＰＩ「ホ
ストファイル」は、どの副区域ネットワークへ送信勧
誘、“are you there （いますか）”メッセージを
同報通信するかを指定するためにユーザによって設定さ
れ得るファイルである。ＡＰＩ「ホストファイル」は、
接触又は「非同報通信」するために個々のホストも指定
することができる。送信勧誘同報通信は、全ての潜在的
データ提供者ホストが識別されることを確実とするため
の周期的に行なわれる。 ・ データ階層の走査 ＡＰＩ要求／応答インターフェース１６０は、ユーザが
GUI ８０及び構成サブシステム３０を介してインターフ
ェース１３０においてこれを要求するときはいつでもデ
ータ階層を走査するために使用される。 ・ 統計のセットについての交渉 ユーザによって起動される各計器ごとに、ＡＰＩ要求／
応答インターフェース１６０はどのデータ値がそのセッ
トに属しているかを交渉するために使用される。データ
提供者デーモン２１０が再スタートする場合には、パフ
ォーマンスツール９０は、セットと再交渉するために同
じインターフェースを使用する。データ送りがアクティ
ブである間、及びいくつかのケースにおいてアクティブ
ではない時には、パフォーマンスツール９０とデータ提
供者デーモン２１０は共にそのセットの情報を保持す
る。データ提供者デーモンは、どのデータ値を送るべき
かを知るためにそのように動作すると共に、構成サブシ
ステム３０はその情報を必要とし、これによってそれが
データパケット内に何があるかをデータディスプレイサ
ブシステム４０に指令することができる。 ・ データ送りの開始及び停止 GUI ８０（図４）を介してインターフェース３０でユー
ザによって指定されるように、データディスプレイサブ
システム４０（図４）は、ＡＰＩ要求／応答インターフ
ェース１６０を使ってデータ送りパケットへの開始、停
止、及び頻繁な変更に対する要求を構成サブシステム３
０を介してネットワーク送信／受信インターフェース７
０へ渡す。 ・ 接続を生かしておく ＡＰＩ１６０はアクティブモニタがアクティブであるこ
とをデータ提供者デーモン２１０によって知られている
ことを確実とするための関数（機能）を含む。これらの
関数はパフォーマンスツール９０から妨害されずにＡＰ
Ｉライブラリ１６１によって処理される。 ・ データ送りパケットを処理する データ送りパケットは一方向インターフェース１６２を
介するＡＰＩライブラリ関数によって受け取られ、かつ
さらなる処理のためにデータ値受信者サブシステム６０
へ渡される。ネットワーク送信／受信インターフェース
７０においては直接処理が行なわれることはない。
【００７５】図９に関しては、コンソール内の一つ以上
の計器に対して、又はコンソール内の全ての計器に対し
て統計の記録が開始され得る。記録は一度に一つを超え
るコンソールに対してアクティブであることができる。
任意の一つのコンソールからの全ての記録は、コンソー
ルのネームが後に続く“Ｒ. ”のネームの接頭語を有す
るディレクトリ“$HOME/XmRec ”内のファイルへ常に進
む。例えば、“RemoteIP Load”に対する記録ファイル
は以下のように記述される。
【００７６】$HOME/XmRec/R.RemoteIPLoad
【００７７】一つの好ましい実施例において示唆するた
め、記録プロセスの多数のファセットがある。まず第１
に、コンソールは、（ファイルの）ネームがコンソール
と一致するファイルから再生される間、記録できない。
第２に、ファイルが作られる時はいつでも、コンソール
全体の全記述がファイルの第１の記録として書き込まれ
る。これは、記録がコンソール全体に対して又はコンソ
ール内のある計器対してのみ開始されようが変わらない
ことである。第３に、記録動作が例示された時、ファイ
ルが存在している場合、システムは、ユーザにユーザが
ファイルに（データを）追加したいか又はファイルを再
作成したいかを促す。ファイルへの追加が選択された場
合（図９のブロック１７４及び１８２によって決定され
るように）は、コンソールの記述がファイル内に既に存
在していると仮定される。第４に、記録ファイルは、ユ
ーザのホームディレクトリ内の“XmRec ”とネーミング
されたサブディレクトリ内に位置している。記録が試行
される時にこのディレクトリが存在しない場合、可能で
あるならばファイルが作成される。
【００７８】ユーザがメニューから記録を選択する時、
GUI を使って以下の選択がユーザへ提供される。次いで
GUI はユーザ選択のオプションを対応する機能呼び出し
へ変換し、次いでこの機能呼び出しは、図９のブロック
１７０において記録システムへ送られる。記録は以下の
選択によってメニューから制御される。バッファ保管 このオプションは、選択されたコンソール又は計器の履
歴バッファの内容を記録ファイル１００へ転送する。こ
のオプションは、コンソールから記録がもはやアクティ
ブではない時にのみ使用可能である。そうでない場合
は、バッファから保管された値が進行中の記録の値との
同期から逸脱してしまう。オプションはコンソールにお
ける興味深いパターンが検出された状況に向けられてお
り、かつこれ以降の解析に向けてその状況を捕えること
が所望される。バッファの記録が終了した時、記録ファ
イルは閉じられる。記録開始 このオプションはデータ値が受け取られた時、記録ファ
イルにデータ値を書き込み始める。データが遠隔データ
提供者又は局所のいづれかから受け取られたかは無関係
である。記録は、（ブロック１３０によって指定されて
いるようにGUI８０を介して）ユーザによって停止され
るか又はコンソールが閉じられるまで継続する。記録保管及び開始 先行する二つのオプションをディスプレイ履歴バッファ
データをファイルに最初に保管することによって結合
し、これによって記録を開始する。記録終了 コンソール内の他の計器がもう記録されないならば記録
を停止しかつ記録ファイルを閉じる。
【００７９】コンソール又はコンソール計器のうちの一
つのいづれが現在記録中であるかによって、及びどの記
録メニューが選択されたかによって、記録サブメニュー
内の異なる項目がアクティブとなる。メニュー項目の状
態は、次に記述されるように、コンソール記録及び計器
記録の間の差に密接に関連している。
【００８０】第１において、記録サブメニューが図９の
ブロック１７２において検出されるように、“Start Co
nsole Recording （コンソール記録を開始せよ）”メニ
ューから得られる場合は、サブメニューにおける全ての
メニュー項目は全体的にコンソールと関係していると仮
定される。従って、コンソールにおいて、一つ以上の計
器又は全ての計器のいづれが現在記録中であっても、ブ
ロック１８８の“EndRecording （記録終了）”の選択
によって、全ての計器に対する記録が停止される。同様
に、一つ以上の計器が現在記録されていても、ブロック
１７８のサブメニューからの“Begin Recording （記録
開始）”の選択によって、この時点から、コンソール内
の全ての計器が記録されることになる。
【００８１】第２において、（図９のブロック１８０に
おいて決定されるように）記録サブメニューが“Start
Instrument Recording（計器記録を開始せよ）”から到
着された場合は、サブメニュー内の全てのメニュー項目
が、現在選択されている計器に追加されるように考慮さ
れる。従って、選択された計器が現在記録されていない
場合は、ブロック１８６の“Begin Recording （記録開
始）”の選択がその計器の記録を開始する。この計器が
記録されている場合に、完全なコンソール記録が開始さ
れている結果としてその記録が開始されていようとも、
ブロック１９０の“End Recording （記録終了）”の選
択によって、選択された計器に対する記録は停止される
ことになる。いづれの場合においてもその動作がコンソ
ール内の他の計器に何ら影響を与えることはない。
【００８２】第３において、“Save Buffer （バッファ
保管せよ）”のサブメニュー項目は、コンソール内のい
かなる計器に対しても記録が現在全く進行していない場
合にのみ有効となる。これは時ならぬ制限に見受けられ
るかもしれないが、履歴データを“real-time （実時
間）”記録と混合した結果は何ら実践的な有効性をもた
ないと思われる。
【００８３】上記の全てのルールは、任意の時点におい
てどのサブメニュー項目がアクティブであるかについて
影響を与える。図１１は可能性のある組合せを示してい
る。許容可能な選択は '＋' によって示され、かつ許容
されない選択は '−' によって示されている。
【００８４】記録が進行中であることをユーザに思い出
させるために、テープリールを図示するシンボルが記録
をアクティブにする（“State light ”計器を除く）全
ての計器の下部右側コーナに示される。
【００８５】記録ファイルは五つのタイプの記録を含
み、各記録がパフォーマンスツールの内側にある制御ブ
ロックをミラリング（鏡映）する。記録タイプは以下に
示されている。 １． コンソール情報 ２． 計器情報 ３． 値のディスプレイ情報 ４． 値の詳細情報 ５． データ値の記録
【００８６】テーブル１は、コンソール記録のレイアウ
トを記述している。この記録は、（ディスプレイの左側
からの画素内で測定された）コンソールの左及びトップ
のオフセット、（画素内の）コンソールウィンドウの高
さと幅、このコンソール内の計器の数のカウント（計
算）、及び大小のプロトコルバージョンのような情報を
含む。大小のプロトコルバージョンフィールドはリリー
スを走査して異なるプロトコルバージョンを識別するた
めに用いられる。記録形式が大きな変更を有する場合、
“Major （大）”プロトコルバージョンの数が増分され
る。小さな変更、又は異なるシステムに対するバージョ
ンは“Minor （小）”プロトコルバージョンの数を増分
させる。それゆえ、これらのフィールドは、再生サブシ
ステムが、互換性レベルに属する記録を識別することを
可能とする。このコンソール情報は、ブロック１７４で
決定されるように新しい記録ファイルが作成される場合
には、ブロック１７６（図９）において記録ファイルに
書き込まれる。（注：以下テーブル１乃至６６におい
て、表中に現れる英文字の列はコマンドなどを表わす記
号であり、翻訳できない） ------------------------------------------------------------------------ unsigned short left ； /* 形状寸法：左オフセット */ unsigned short top； /* 形状寸法：トップオフセット */ unsigned short width； /* 形状寸法：ウィンドウ幅 */ unsigned short height ； /* 形状寸法：ウィンドウ高さ */ unsigned short count； /* 計器のカウント */ unsigned short major； /* 大プロトコルバージョン */ unsigned short minor； /* 小プロトコルバージョン */ ------------------------------------------------------------------------ テーブル１ コンソール情報
【００８７】記録されているコンソール内の計器ごと
に、テーブル２の情報は記録ファイル１００に書き込ま
れ、これによって内部制御ブロックの一貫性の形式がサ
ブシステム同士の間で維持される。この情報は、ブロッ
ク１８２において決定されるように新しい記録ファイル
が作成される時にブロック１８４（図９）に書き込まれ
る。
【００８８】テーブル２に関しては、図形タイプがモニ
タタイプ（例えば、固定）かスケルトンタイプ（骨組み
から作成される）かを示す。グラフの収集ネームはこの
計器が属するコンソールのネームである。副図形番号は
計器がコンソール内のどの位置における計器であるかを
示す。オフセットは、高さのパーセント（頂部及び底部
オフセットに対して。頂部は０％）及び幅のパーセント
（左右オフセットに対して。左が０％）として指定され
るコンソール内の計器の位置である。シフト画素数は、
引き続くデータ記録監視間においての時間グラフをシフ
トするための画素数を指定する。棒パラメータ同士の間
の空間は、ディスプレイされている棒グラフ要素同士の
間を離間するための画素の数である。履歴パラメータ
は、計器に対するディスプレイバッファ内に保管するた
めの監視数を指定する。ディスプレイ履歴バッファは、
ディスプレイにディスプレイされた最近のデータを維持
する'cache-like （キャッシュ擬）' バッファである。
時間間隔パラメータは、ミリ秒単位でデータ記録サンプ
リング周波数を指定する。この時間間隔は、サンプルの
細分性が実時間で変化されるのを可能とし、さらに、異
なる計器が、異なる細分性又は周波数において、同じ値
を記録することを可能とする。タイル（区切り）配列の
索引は、タイルパターン（縦縞、横縞、斜め縞、チェッ
ク、方格、クロスハッチ、その他）の配列におけるタイ
ル「パターン」を識別する数である。これらのパターン
は、統計をある計器における他の統計と区別するのを助
けるためにディスプレイされる統計の前景及び背景と結
合され得る。スタイルパラメータは、線グラフ、領域グ
ラフ、スカイライングラフ、棒グラフ、状態棒グラフ、
状態ライト（光）グラフ、速度計グラフ、又はパイ図表
のような計器の基本スタイルを表わす。スタックされた
パラメータは、どのスタッキングが基本スタイルを用い
る値に使用されるべきがを指定する。 ------------------------------------------------------------------------ char *typ ； /* 図形タイプ */ char *id； /* 図形収集ネーム */ unsigned int seq； /* 副図形番号 */ unsigned int x； /* 形式の左からのオフセット */ unsigned int y； /* 形式の頂部からのオフセット */ unsigned int x2 ； /* 形式の右からのオフセット */ unsigned int y2 ； /* 形式の底部からのオフセット */ unsigned int br ； /* シフト／監視用画素なし */ unsigned int sp ； /* 棒と棒の間の空間 */ unsigned int hist ； /* 履歴、監視の数 */ unsigned int t； /* 時間間隔、ミリ秒 */ char foregr 64 ； /* 前景カラーネーム */ char backgr 64 ； /* 背景カラーネーム */ short tile ix ； /* タイル配列への索引 */ graph style style； /* グラフの基本スタイル */ boolean stacked； /* スタッキングが使用可能な場合に真である* / ------------------------------------------------------------------------ テーブル２ 計器情報
【００８９】計器の値の各々の基本的な記述は、テーブ
ル３に示されている記録タイプ内に記憶される。svp フ
ィールドは計器内の値を識別し、かつ（テーブル４及び
テーブル５において定義されている）以下の二つの記録
タイプがこの値と一致するように使用される。このフィ
ールドは二つの１６ビットの値として変換され、ここで
一つの値が計器を識別し、他は計器内に関連する値の数
を提供する。再び、この同じ原理が次に記述される二つ
の記録タイプのために使用される。ｒ１及びｒ２の値
は、記録され／ディスプレイされているデータと一致す
るようにグラフの拡大縮小（スケーリング）を許容す
る。以下に説明されているように、動作をトリガするた
めのしきい値警報値がある。タイル配列に対する索引
は、グラフ記入に使用されるようにタイルパターンを異
ならせる。グラフスタイルは、引き続く再生でディスプ
レイされるために、グラフのスタイルを保管する。重み
付けは、ある時間に対して抜き出された複数のサンプル
の結果を含むために、一つを超えるサンプル値を平均化
することを可能とし、これによって広範囲に変換するデ
ータサンプルを安定化及び平均化するための方法を提供
する。降順フラグは、警報がサンプル値がしきい値より
下に下がる（上昇するのとは対照的に）時にトリガされ
ることを示す。パス、レベル、及びカラーフィールドは
自明である。 ―−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− struct StatVals *svp; /* 統計値ポインタ * / unsigned long rl； /* 最小値スケーリング * / unsigned long r2； /* 最大値スケーリング * / unsigned long thresh ； /* 警報に対するしきい値 * / short tile ix ； /* タイル配列の索引 * / unsigned style； /* この値に対するグラフスタイル */ unsigned weighting； /* 重み付け／平均化した場合真である */ unsigned descending; /* しきい値が降順した場合真である */ char path 128 ； /* 統計のパスネーム */ char label 64 ； /* 任意のユーザ定義ラベル */ char color 64 ； /* 値を作図するためのカラーネーム */ ------------------------------------------------------------------------ テーブル３ 値ディスプレイ情報
【００９０】テーブル４の記録タイプの内容も、テーブ
ル３の前者の記録タイプ内に含まれている。現在形式
は、この形式がパフォーマンスツール（即ち、構成によ
って構成ファイルから作成されるブロックと同じ）の内
部制御ブロック形式と一致しているために選択される。
コンソール内で定義される各値に対するこの記録タイプ
の一例がある。値のネーム及び記述は自明である。デー
タタイプフィールドは、記録されたカウンタ（計数／時
間間隔）又は量のデータ（累積計数）であるデータのタ
イプを指定する。データ形式領域はデータの内部形式
（例：浮動小数点、ロングワード、ショートワード、文
字その他）を指定する。 ------------------------------------------------------------------------ unsigned long svp; /* 統計値ポインタ * / char name SI MAXNAME ; /* 値のネーム * / char descr SI MAXLNAME ; /* 値の記述 * / enum ValType value type； /* 値のタイプ * / enum DataType data type； /* データ形式 * / ------------------------------------------------------------------------ テーブル４ 値詳細情報
【００９１】一組のデータ値が現在記録している計器の
ために受け取られた時は必ず、テーブル５において示さ
れている記録は記録ファイル１００に書き込まれる。sv
p ポインタは前もって記述されている。実際のデータ及
びデルタ値は自明である。計器識別子フィールドは、ど
の計器に記録された値のこの配列が属するかを伝える識
別子値である。計数はこの記録内に含まれる値の数であ
る。二つの時間フィールドは自明であり、かつ捕獲され
た値をタイムスタンプ（時刻表示）するために使用され
る。 Instr Def データ構造は、（「計数」フィールド
によって指定されるように）「ｎ」個の記録を有する
「データ読み取り配列」を定義し、記録はテーブル５に
示されている Per Val Rec 構造によって定義される
形式のものである。 ------------------------------------------------------------------------ typedef struct ｛ long svp; /* 統計値ポインタ * / union Value val; /* 実際データ読み取り * / union Value val change; /* デルタ値（値変化） * / ｝Per Val Rec; typedef struct｛ unsigned short ssp; /* 計器識別子 */ unsigned short count; /* 記録における値の計数 */ struct timeval time; /* データ読み取り時間 */ struct timeval time change; /* 前の読み取りから経過した時間 */ Per Val Rec r MAX PLOTS PER GRAPH ; /* データ読み取り 配列 */ ｝Instr Def; ------------------------------------------------------------------------ テーブル５ データ値記録
【００９２】図５の記録サブシステムインターフェース
は図１０においてさらに拡張される。GUI ８０と記録シ
ステム２０の間のインターフェース１４０は、コンソー
ル記録を開始／停止し、かつ計器記録を開始／停止する
ために、GUI ８０からのメッセージを備える。記録サブ
システム２０は、ユーザが記録ファイルを追加したいか
又は置換したいかのメッセージがパフォーマンスツール
のユーザ／オペレータへ提供されるようにGUI ８０へ送
る。
【００９３】データ値受信者サブシステム６０と記録サ
ブシステム２０との間のインターフェース１４２はデー
タブロックを備える。記録サブシステム２０は、この動
作がデータ値受信者サブシステムによって行なわれるの
で、データの原点を心配したり、維持しようとする必要
はない。記録サブシステム２０は、局所及び遠隔データ
統計も等しく処理し、さらにデータを記録する時には最
小限のオーバヘッド遅延も提供する。これは、局所であ
ろうと、遠隔であろうと、全てのデータがデータ値受信
者サブシステム６０によって同一に処理されるためであ
る。これによって、このモジュラ設計に基づいて、デー
タは、データパケットを受け取りかつ記録ファイル内に
記憶するためのオーバーヘッドが最小限なので、実時間
で迅速に記録されることができる。さらに、オーバーヘ
ッドが最小限なので、記録は以下に記述されるように、
データのディスプレイと同時に生じることができる。
【００９４】記録サブシステム２０と記録ファイル１０
０の間のインターフェース１４１は、（上記の）記録さ
れるべきデータだけでなくコンソール、計器、値ディス
プレイ、値詳細情報などを備えており、これによって記
憶された記録データのコンテキストを維持する。この情
報（コンソール、計器、値ディスプレイ、及び値詳細）
は、記録サブシステム２０からの構成情報に対する要求
によって開始される構成サブシステム３０からインター
フェース１４３を介して得られる。
【００９５】再生サブシステムの実施 まず図１２に関しては、プレーバック（再生）２３４
が、図１２に示されているように、パフォーマンスツー
ルユーザインターフェース２３０の主ウィンドウのファ
イル２３２メニューから開始される。「再生」メニュー
項目が（GUI によって決定されて）選択される時、再生
のために利用可能であるファイル２４０のリストが図１
３に示されているように提供される。ファイルリスト
は、接頭語“R.”を有する“$HOME/XmRec ”ディレクト
リにおける全てのファイルからなる。ユーザは、ユーザ
が欲するいづれかのディレクトリにおいて他のマスクを
捜し出すために、フィルタ選択又はボタン２４８、及び
参照番号２４２のファイル選択ボックスのフィルタ部分
を使用することができる。再生するためにファイルを選
択するため、ユーザは示されているようにファイルをク
リックし、次いでＯＫボタン２４４をクリックするか又
はファイルネームをダブルクリックする。選択ボックス
は、ユーザが再生するためにファイルを選択した後はオ
ープンのままである。これはユーザが一つ以上のファイ
ルを選択するのを許容する。選択ボックスを消去するた
めに、ユーザは「キャンセル」ボタン２４６をクリック
する。
【００９６】ユーザが有効な再生ファイルを選択する
時、ブロック２５２で検出されるように、GUI は再生シ
ステムにファイルを開くように命令する。パフォーマン
スツールは、記録ファイルからコンソール構成を読み取
り、かつ図１９のブロック２５４においてコンソールを
生成する。再生コンソールは、コンソール、計器、値デ
ィスプレイ、及び各記録の開始から読み取られる値の詳
細情報記録から構築される（テーブル１乃至４に記述さ
れている情報構造）。このデータは、データディスプレ
イサブシステムが、コンソール構成ファイルからサブシ
ステムが読み取るデータから正則コンソールを構築する
のと同じ方法で再生コンソールを構築するために使用さ
れる。主な差は、再生コンソールの生成が、正規のコン
ソールコマンドのプルダウン又はポップアップメニュー
を許容しないが、代わりに、図１４のブロック２５０に
示されているように、再生機能（例：取り出し、消去、
巻戻し、探索、再生、停止、高速化、及び低速化）を制
御するために特別なセットのボタンを作成する。再生は
ユーザが「再生」ボタンをクリックするまでスタートし
ない。
【００９７】ユーザによって選択されるボタンの機能、
及びその結果的な動作は以下に示されている。取り出し すぐに再生を停止し、コンソールを閉じ、かつ再生ファ
イルを閉じる。再生を再スタートするためには主要ウィ
ンドウの「ファイル」メニューから「再生」を再選択
し、かつ再生ファイル１００を再選択しなければならな
い。パフォーマンスツールの内部、即ち図４に関して
は、GUI ８０構成要素は、ユーザ制御１３０を介して
「取り出し」ボタンが押されたことが知らされ、かつ図
１９のブロック２５６において検出されるように再生を
停止するように再生サブシステム５０へメッセージを送
る。次いで、再生サブシステム５０は、図１９のブロッ
ク２５８において、関連する再生コンソールを除去し、
かつクリーンアップするためにデータディスプレイサブ
システム４０を呼び出す。次いで、再生サブシステム５
０は、関連する記録ファイル１００を閉じかつこのファ
イルを出る。消 去 ユーザが再生ファイルを消去するのを許容する。このボ
タンが選択された時、ダイアログウィンドウがポップア
ップする。ダイアログウィンドウは、ユーザが消去機能
を選択したことを警告し、かつそこから現在再生してい
るファイルネームを示す。ファイルを消去し、かつ再生
コンソールを閉じるためには、ユーザは「ＯＫ」ボタン
を選択する。ファイルの消去を阻止するために、ユーザ
は「取消し」ボタンを選択する。パフォーマンスツール
の内部には、GUI ８０の構成要素が「消去」ボタンが押
されたことをユーザ制御１３０を介して知らされ、かつ
再生サブシステム５０へメッセージを送る。再生サブシ
ステム５０は、情報を伝えかつユーザからの応答を請求
するためにダイアログウィンドウをディスプレイするた
めにGUI ８０にメッセージを送る。ユーザは記録ファイ
ル１００の消去又はそれらの要求の取消しを確認するよ
うに促される。ユーザが（ユーザ制御１３０を介して）
記録ファイルを消去したいとする希望を確認するなら
ば、再生サブシステム５０は、ブロック２８２（図１
９）において記録ファイルを消去し、次いでディスプレ
イから関連する再生コンソールを除去しかつクリーンア
ップするためにデータディスプレイサブシステム４０を
呼び出す。巻戻し 全ての計器をクリアすることによってコンソールをリセ
ットし、かつ記録ファイル１００をそのスタートまで巻
戻す。再生はユーザが「再生（Play）」を選択するまで
スタートしない。「巻戻し」ボタンは再生が進行中であ
る間は起動されない。パフォーマンスツール内部には、
GUI 構成要素８０が「巻戻し」ボタンが押されたことを
ユーザ制御１３０を介して知らされる。GUI はこの選択
を示すメッセージを再生サブシステム５０へ送る。再生
サブシステム５０はこれを検出し（図１９のブロック２
６８）、かつ全てのコンソール計器をその初期状態へリ
セットするためにデータディスプレイサブシステム４０
へメッセージを送る（図１９のブロック２７０）。次い
で、再生サブシステムはポインタを記録ファイル１００
の最初にリセットする。記録の再生は、ユーザが「再
生」メニューボタンを選択するまでスタートしない。探 索 「探索」のユーザ選択は、ユーザが、再生ファイル１０
０内を探索するために所望される時刻を指定するのを許
容するダイアログボックスをポップする。時刻は、
「時」又は「分」ボタンをクリックすることによって設
定され得る。各クリックは時又は分を１だけ進ませる。
ユーザが一秒間以上ボタンを押し続けることによって、
時又は秒カウンタが高速で進む。ディジタルクロック
が、一旦、探索するために所望される時刻を示すと、ユ
ーザは「進行」ボタンをクリックする。これによってコ
ンソール内の全ての計器がクリアされかつ指定時刻に対
して再生ファイルが検索される。パフォーマンスツール
の内部には、GUI 構成要素８０がユーザ制御１３０を介
して、「探索」ボタンが押し下げられたことが通知さ
れ、再生サブシステム５０ヘメッセージを送る。再生サ
ブシステム５０は、ユーザが「探索する」ための記録時
刻を指定することを許容するためのダイアログボックス
をディスプレイするために、GUI 構成要素８０にメッセ
ージを送る。記録内の各データ要素は、データがデータ
提供者によって集められた時にデータ値に付けられたタ
イムスタンプを有する。記録サブシステム２０がデータ
を記録する時には、このサブシステム２０がオリジナル
タイムスタンプを保護する。ユーザが「探索」時刻を選
択した後には、GUI ８０はこのパラメータを再生サブシ
ステム５０に渡す。再生サブシステム５０はブロック２
７２（図１９）においてこれを検出し、次いで記録コン
ソール計器をそれらの初期値にリセットするためにデー
タディスプレイサブシステム４０を呼び出す。次いで、
再生サブシステムは記録ファイル１００を開き、記録図
形コンテキスト内でそれを読み取り、このデータをデー
タディスプレイサブシステム４０へ渡し、かつ記録デー
タが指定された「探索」時刻を発見するまでこの記録フ
ァイルから記録データを読み取る。再生サブシステム５
０がこの記録されたデータをメモリへ読み取る時、再生
サブシステム５０は、各データ入力のタイムスタンプを
チェックし、これによって記録の時刻における特定のポ
イントを探索することができる。次いで、再生サブシス
テム５０は、ブロック２７４（図１９）において、再生
時刻ポインタをこの「探索」されたデータ記録を設定
し、かつユーザが、この記録時刻記録から再生を開始す
るため、GUI ８０を介して「再生」ボタンを選択するの
を待機する。
【００９８】再生ファイルが深夜に及んでスパンし、こ
れによって再生ファイルにおいて同タイムスタンプが一
回以上存在するような状況においては、探索は再生ファ
イルにおける現在位置から進行し、かつこの時刻が発見
されないならばラップする。複数のデータ記録が時／分
に対して存在し得るので、「再生」は、同時に追加的な
探索を行なう前に次の分へ進むか、又は現在再生時刻よ
りも一分間早い時刻を探索するように使用されるべきで
ある。「探索」ボタンは再生中は起動されない。再 生（プレイ） 再生ファイルの現在位置から再生を開始する。再生中
は、ボタンのテキストは、再生がボタンを再びクリック
することによって停止され得ることを示すために「停
止」へ変化する。再生コンソールを開いた直後は、現在
位置が再生ファイルの始まりである。同じことが巻戻し
後にも行なわれる。パフォーマンスツール内では、GUI
８０の構成要素は、「再生」ボタンが押し下げられたこ
とをユーザ制御１３０を介して通知され、かつ再生サブ
システム５０へメッセージを送る。再生サブシステム５
０は、ブロック２６０でこのメッセージを検出し、かつ
GUI サブシステム８０に「再生」ボタンを「停止」ボタ
ンヘ変えるように告げ、次いでブロック２６２（図１
９）において、記録ファイルの現在位置から記録データ
を有するデータディスプレイサブシステム４０を送るの
を開始する。最初は、再生がデータが元来記録された速
度とほぼ同じ速度で試みられる。速度は、「高速化」及
び「低速化」ボタンを使うことによって変更され得る。
再生中は「巻戻し」又は「探索」ボタンのいづれも活動
化されない。再生サブシステム５０は、これが記録ファ
イル１００の終わりに到達するまで、或いはユーザ制御
１３０を介してユーザが「停止」ボタンを押すまで、記
録データをデータディスプレイサブシステム４０へ送り
続ける。ユーザが「停止」ボタンを押す場合、GUI ８０
は通知され、かつ再生サブシステム５０へメッセージを
送る。「停止」ボタンがシグナルされた場合、再生サブ
システム５０はGUI に「停止」ボタンを「再生」ボタン
に変えることを告げ、次いで記録データを有するデータ
ディスプレイサブシステム４０を送ることを停止する。
次いで、再生サブシステム５０はユーザが他の動作を選
択したという表示を待機する。低速化 ユーザは現在速度の半分へ再生速度をカットするために
このボタンをクリックする。GUI ８０は、ユーザ制御１
３０を介して「低速化」ボタンが押されたことが通知さ
れ、かつこのメッセージを再生サブシステム５０へ送
り、ここでブロック２７６（図１９）においてメッセー
ジが検出される。再生サブシステム５０はブロック２７
８（図１９）でその再生速度パラメータを半分に分割
し、これによってサブシステム５０はデータをその現在
速度の半分の速度でデータディスプレイサブシステム４
０へ送り、次いで可変再生速度を提供する。高速化 ユーザは、再生速度を倍にするために、このボタンをク
リックする。GUI ８０には、「より高速」ボタンがユー
ザ制御１３０を介して押し下げられたことが通知され、
かつメッセージを再生サブシステム５０へ送り、ここで
メッセージがブロック２７６（図１９）において検出さ
れる。再生サブシステム５０は、ブロック２７８（図１
９）においてその再生速度パラメータを倍にし、これに
よりデータをその現在速度の倍でデータディスプレイサ
ブシステム４０へ送り、これによって可変再生速度を提
供する。00:00:00 コンソールのはるか右側にはディジタルクロックがあ
る。これは、ファイル１００の最初にある場合は、再生
ファイル１００における現在位置に対応する時刻又はゼ
ロを示す。再生が進行するにつれて、クロックは更新さ
れる。これは、記録／再生ファイルから読み取られる再
生データと対応しているタイムスタンプを読み取ること
によって実施される。
【００９９】計器からの記録は、前に記述されているよ
うに、記録が実行されている計器及びコンソールを記述
する制御ブロックを含む。ユーザが有効な構成及び／又
は統計データを含まないファイルから再生を試みる時に
生じ得るいくつかの驚異的な可能性がある。保管されたバッファからの再生 計器又はコンソールのバッファが保管される時、このバ
ッファはモニタリングが長期の十分な時刻に対して進行
してないので完全ではないかもしれない。このような記
録が再生される場合、再生は、実データが使用可能であ
るポイントまでのゼロの値を示す。同期化されない計器 一つのコンソール内の複数のデータ提供者ホストの記録
からの再生は、タイムスタンプが、データから読み取ら
れた時に各計器に適用される（この場合適用可能な）実
コンソールのように振る舞う。これは、データ提供者ホ
ストにセットされた様に日時における差を反映してお
り、従って驚異的ではない。しかしながら、これらの
「タイムワープ」は「探索」機能と現在位置クロックに
影響を与える。例示されたスケルトンコンソールからの記録 スケルトンコンソールが例示される度に、実際に行なわ
れた選択が非常に変化しやすい。例えば、二つの例示に
おける同じ三つの遠隔ホストが選択された時にさえも、
通信ネットワークを介して相互接続される多重コンピュ
ータデータ処理システムにおいて固有である種々の応答
遅延によって、ホストがこの例示されたコンソール内に
現れるシーケンスは非常に異なる傾向を有する。新しい
記録が各例示されたコンソールに対して作成されている
限り問題はない。しかしながら、記録が同一ネームを有
する以前のコンソールに追加される場合は、事は複雑に
なる。これはは、記録がコンソールの定義を一度だけ、
記録の開始時に含むためである。再生の間、即ち異なる
例示が前の記録に追加される位置が達成される時、計器
及び値の関連する位置は変化しないと仮定される。
【０１００】図１７は、図６に示されている再生システ
ムのインターフェースをさらに拡張する。GUI ８０と再
生サブシステム５０の間のインターフェース１２９は、
記録を開いたり／閉じたりするためにオペレータによっ
て開始されるメッセージを備える。再生サブシステムは
使用可能な記録のリストを有するGUI に応答し、かつユ
ーザの選択はGUI ８０から再生サブシステムへリターン
される。オペレータによって開始されるように、GUI か
らのさらなるメッセージは、記録ファイル１００の再生
／停止、巻戻し、探索、低速化／高速化、及び消去する
ことである。
【０１０１】記録ファイル１２６及び再生サブシステム
５０の間のインターフェース１２６は、図１４に示され
ているコンソールのようなコンピュータコンソールにデ
ィスプレイされる実際のデータを提供する。記録ファイ
ル１００から読み取られるさらなる情報は、コンソー
ル、計器、値ディスプレイ、及び値詳細情報を含む。ま
た、この情報はユーザに提供されるデータのディスプレ
イコンテキストを保護するために使用される。
【０１０２】インターフェース１２６において読み取ら
れる全ての情報及びデータは、インターフェース１２８
においてデータディスプレイサブシステム４０へ直接渡
される。最小限のシステムオーバーヘッドは、データを
読み取りかつディスプレイするように要求され、かつ他
のサブシステムアクティビティ（活動）が、同一又は他
のパフォーマンスデータのようなデータの実際のディス
プレイによって生じることを許容する。
【０１０３】記録による再生の同時性 磁気テープのような線形の媒体へ記録したり、それから
再生したりする時、テープ機構が移動している間は、
「読み取りヘッド」が「書き込みヘッド」に続くので、
記録中は、ユーザは限定された再生制御だけしか有する
ことができない。このアレンジメント（構成）はあまり
フレキシブルではないので、記録中の巻戻し、探索、高
速化、低速化、又は再生／停止のような機能を許容しな
い。本明細書中に開示されている好ましい実施例におい
ては、記録は、共通のファイルへの同時の読み取り／書
き込みを許容するファイルシステムにおいて実行され
る。従って、記録及び再生機能は、線形媒体の機能より
もその操作においてもっと独立している。記録機能は継
続的に前もって指定されたデータを記録すると共に、再
生機能は、既に記録されたデータを、記録プロセスを妨
害せずに、現在記録中のデータ記録に達するまで同時に
読み取ることができる。記録ファイルの複写が他のファ
イルに対して実行された場合には、再生は、全体的にオ
リジナル記録ファイルと同時にかつ独立して実行され得
る。使用され得る他の技術は、記録されるデータのコン
テキストを複写し、かつ同じデータに対する二つの記録
セッションを生成することである。次いで、再生セッシ
ョンは一つのセッションに呼び出されることができると
共に、他のセッションはデータの記録を継続する。図１
８に示されているように、この技術は、複数の遠隔マシ
ン２１８にも同様に延長されることができ、これによ
り、いかなるマシン２０１もデータを記録すると共に、
他のいかなるマシン２０３も遠隔マシン２１８上の同一
データ源２１０からデータを同時再生することができ
る。この技術は、単一データ源２１０が複数の消費者ア
プリケーションを同時に送ることができるので可能性が
高い。さらに、データ消費者及びデータ提供者は単一マ
シン２１９内に共存することができ、かつ他のデータ消
費者及びデータ提供者をネットワークに同様に提供する
ことができる。結合されたデータ消費者とデータ提供者
の一つの例が、フィルタ及び警報の説明において後述さ
れる。
【０１０４】データディスプレイサブシステムの実施 計器 ある計器は、コンソールを表示するウィンドウ内の矩形
領域を占有する。各計器は、同時に取られた全ての値を
読み取ることによって、好ましい実施例において２４個
の値まで同時に作図（プロット）し得る。この計器にお
ける全ての値は、同じ遠隔ホストから提供されなければ
ならない。これは、処理オーバーヘッドがこの制限を維
持することによって最小となるように、遠隔ホストから
の統計のライブ（実時間）ディスプレイ及び記録を許容
する。
【０１０５】モニタリング計器に複数のデータ統計を動
的に付加し、変更し、かつ消去するための能力は、公称
的に非結合パラメータ同士の間の相互関係を可視化する
際に非常に強力で有用な助けとなる。異なるカラー及び
表示スタイル（例：線、棒、区分、スカイラインその
他）における各パラメータを実時間時刻グラフでディス
プレイする能力と結合された結合機能は、最小限の説明
でも理解され得るデータの非常に複雑な表示を可能とす
る。実際に、計器のコンソールは、個々のプロセスにお
ける統計を含む局所及び遠隔ホストからのデータを示す
ために構築され得る。さらに、データサーバデーモンに
よって登録されたアプリケーションからのカストムデー
タは、（やはり局所又は遠隔ホストからの）正規のシス
テム統計を示すビューイング計器に追加され得る。この
動作の全ては、計器がデータ提供者からデータを受け取
っている間に実行されることができ、次いでディスプレ
イビューは実時間で更新される。同じ基本スタイルのデ
ータ値はデータの受信を妨害することなく、スタックさ
れたり、スタックされなかったりする。
【０１０６】記録グラフ／計器は、図１５における参照
番号２４９に示されているように時間周期の間のシステ
ム資源に対する統計を示す。記録グラフは右側に現在時
刻を有するタイムスケールを有する。作図された値は新
たな読み取りが受け取られる時に左側へ移動する。
【０１０７】図１６の状態グラフ／計器２５１は、任意
ではあるが、重み付け平均としてシステム資源に対する
最新の統計を示す。これらは統計を時間で示さないが、
グラフを記録グラフに変更したいと所望された場合には
このデータを収集する。
【０１０８】計器はメニューベースのインターフェース
を介して構成され得る。計器によってモニタされるべき
値から選択するだけでなく、以下の特性が、計器のため
に全体的に確立される。スタイル グラフの基本スタイル。グラフが記録グラフである場
合、グラフによって作図される全ての値がこのグラフス
タイルを使用する必要はない。状態グラフの場合、全て
の値が計器の基本スタイルを使用するようにさせられ
る。
【０１０９】デフォルト＝領域グラフ。前 景 計器の前景カラー。大部分が、タイムスタンプと、グラ
フ限界を定義するためのラインをディスプレイするため
に使用されるのが注目される。
【０１１０】デフォルト＝ホワイト。背 景 計器の背景カラー。
【０１１１】デフォルト＝ブラック。タイル 計器の背景を「タイル」配列するために使用されるパタ
ーン（ピクセルマップ）。タイルは状態ライトタイプの
計器に対しては無視される。タイル配列が使用される
時、計器の前景カラーと背景カラーを混合して１１個の
使用可能なパターンのうちの一つを生成することによっ
て常に実行される。インターバル（間隔） 監視から監視までのミリ秒の数字。
【０１１２】デフォルト＝2,500 ミリ秒。履 歴 計器によって維持されるべき監視の数。例えば、監視間
の間隔が2,500 ミリ秒であり、かつ（ユーザが）履歴が
1,000 回の読み出しであることを指定した場合、グラフ
によってカバーされる時間周期は、従って、1,000 ×2.
5 秒即ち約４２分となる。
【０１１３】履歴特性は記録グラフのみを示している。
計器の現在寸法が履歴特性によって定義される時間周期
全体を示すには小さすぎる場合、履歴特性はより古い値
を検索するためにスクロールされ得る。状態グラフは、
履歴特性がこれらのグラフのみを示さないように最新の
読み出しのみを示す。しかしながら、ユーザはいつでも
計器の基本スタイルを変更することができるので、デー
タ値の実際の読み出しはやはり履歴特性に応じて保持さ
れる。これは、基本スタイルが状態グラフから記録グラ
フへ変更されない場合はデータは失われないことを意味
する。グラフ画像はビューイング領域（ウィンドウ）に
おいてより大きくなり得るので、適切な部分を見えるよ
うにするために、スクローリング（画面移動）は、Moti
f スクロールバーウィジットを使用することによって達
成される。スクロールの間、データディスプレイサブシ
ステムは実時間データを有するグラフ画像を更新し続け
る。それゆえ、データの完全性はスクロールの間保持さ
れる。次いで、このデータは、GUI を用いてディスプレ
イ上でユーザに提供される。監視の最少回数は５０であ
り、かつ最大回数は 5,000である。
【０１１４】デフォルト＝500 読み出し。スタッキング スタッキングの概念はデータ値が互いの「頂部」で作図
されることを許容する。スタッキングは基本スタイルを
使用する値に対してのみ動作する。図示するために、カ
ーネル（核）cpu 及びユーザcpu 時間がスタックされた
として作図される棒グラフを考える。時間のある点で、
カーネルcpu は１５％で、かつユーザcpu は４０％であ
るならば、対応するバーは、カーネルcpu のカラーにお
いて０％乃至１５％から、かつユーザcpu を描写するた
めに使用されるカラーにおいては１６％乃至５５％から
始まる。
【０１１５】要求されるページ数によってこのグラフを
オーバーレーすることが所望されたならば、これは、こ
の値に、例えば、スカイライングラフスタイルを使用さ
せることによって実行できる。値が定義されるシーケン
スにおいて、値が作図されることが重要である。従っ
て、ユーザが上記の cpu測定を切り換えたいならば、こ
れらの測定は、カーネル cpuを定義する前にユーザ cpu
を単純に定義する。異なるスタイルにおいてグラフをオ
ーバーレーするための値は、基本スタイルのグラフによ
って見えなくなることがないように常に最後に定義され
るべきである。シフティング この特性は記録グラフのみに対して重要である。値の各
読み出しが受け取られる時にグラフが移動するさせるべ
き画素数を決定する。この特性の大きさは、ピクセルマ
ップ（画像）の寸法が以下の積によって決定されるの
で、グラフをディスプレイするために使用されるメモリ
の量に画期的な影響を与える。
【０１１６】履歴×シフティング×グラフの高さ シフティングが一つの画素に設定された場合、ライング
ラフはスカイライングラフと同じに見え、領域グラフは
棒グラフと同じに見える。最大のシフティングは２０画
素である、最少のシフティングは１画素である。
【０１１７】デフォルト＝４画素。スペーシング 棒グラフに使用される特性。あるバー（棒）から次のバ
ーへと読み取られるバーを分離させる画素の数を定義す
る。バーの幅が常に（シフティング−スペーシングす
る）画素であることに留意されたい。特性は、常に、ゼ
ロから、シフトする画素数より１少なくなければならな
い。
【０１１８】デフォルト＝２画素。
【０１１９】メニューインターフェースを介して変更さ
れ得る上記の特性に加えて、四つの特性がコンソール内
の計器の関連位置を決定する。これらは、計器の頂部、
底部、左側、及び右側がどこに位置するかをコンソール
の幅と高さのパーセントで記述している。このように、
計器のサイズはモニタウィンドウの寸法のパーセントと
して定義される。
【０１２０】計器の相対位置は、MOTIF のようなユーザ
インターフェースにおいて一般に実行され、かつ以下に
示されるように、その位置を移動させかつ大きさを再決
定することによって変更され得る。
【０１２１】状態ライトグラフタイプに関しては、前景
と背景のカラーが特別な方法で使用される。この方法を
理解するためには、掲示板に取り付けられている用紙ノ
ートのように、状態ライトが、背景ウィンドウ領域に
「スタック」されたテキストラベルのように示されてい
るのを考慮されたい。背景ウィンドウ領域は、背景カラ
ーによるよりもむしろ計器の前景カラーによってペイン
トされている。背景カラーウィンドウ領域のカラーは決
して変化しない。
【０１２２】各状態ライトは、二つの状態、明（オン）
状態又は暗（オフ）状態のうちの一つの状態にある。ラ
イトが「オフ」の時、値は、計器の背景カラーにおける
ラベル背景及び計器の前景カラーにおけるテキストによ
って示される。計器の前景カラー及び背景カラーが同じ
である場合は、このカラーによってペイントされている
計器のみが見えること（テキスト又はラベルの輪郭は全
く見えない）に留意されたい。二つの計器カラーが異な
る場合は、ラベルは計器背景に対して見られ、かつラベ
ルテキストも見える。
【０１２３】ライトがオンである時、計器の背景カラー
はテキストをペイントするために使用されるが、値のカ
ラーはラベル背景をペイントするために使用される。こ
れによって、状態ライトに対するカラーの特別使用が、
トリガされない時に見えない警報の定義、又は常に見え
る警報の定義を許容する。選択されたカラーはセットア
ップ（設定）の間に行なわれる選択に依存する。
【０１２４】スケルトン計器 あるコンピュータシステムオブジェクトは時間を通じて
変化する。これらの変化の一つの顕著な例は、システム
において実行されるプロセスのセットである。新しいプ
ロセスが開始されると、プロセスの数がオペレーティン
グシステムによって割当てられるので、プログラムの実
行がどのくらいの処理数に割り当てられるかは知られて
ない。これによって、構成ファイルにおける処理に対す
るコンソールと計器を予め定義することが困難になるこ
とは明確である。
【０１２５】この状態に対処することを補助するため
に、コンソールの特別な形状がスケルトン計器を定義す
るために使用され得る。スケルトン計器は、値を定義す
るパスにおける階層レベルの内の一つに代わって「ワイ
ルドカード（wild card ）」を有するものとして構成フ
ァイル内に定義される。例えば、ユーザは、以下の二つ
の値を定義させるプロセスに対してスケルトン計器を指
定する。
【０１２６】Proc /* /kern Proc /* /user
【０１２７】「ワイルドカード」はアスタリスクによっ
て示される。上記の実施例においては、完全修飾された
パスネームがプロセスＩＤを有する場所に現れる。ユー
ザがこの種のワイルドカードによってコンソールを開始
しようとする時はいつでも、ユーザがプロセスのリスト
を提供される。このリストから、ユーザはユーザは一つ
以上のプロセスを選択することができる。選択された各
プロセスは完全修飾されたパスネームを発生するように
使用される。次いで、各パスネームは作図されるべき
値、又はコンソール内の新たな計器のいづれかを定義す
るために使用される。
【０１２８】スケルトン計器は異なるシステムによって
又は時間を通じて資源構成を変更する問題を取り扱うた
めにも有用である。スケルトン計器が定義され、ここ
で、任意のシステムにおける任意のディスク構成のモニ
タリングを可能とするためにディスクネームがワイルド
カードによって置換される。
【０１２９】定義されたスケルトンのタイプはどのスケ
ルトンのタイプが選択されたかを決定する。次のセクシ
ョンにおいて記述されるように二つのタイプのスケルト
ンがある。
【０１３０】“All （全て）”とネーミングされたスケ
ルトンタイプは、このタイプの計器がこの計器の中へ選
択されるワイルドカードの全ての例を含むのでこう呼ば
れる。プロセスの場合においては、これは全ての選択さ
れたプロセスを含む。スケルトン計器は計器の一つの例
を生成し、かつこの計器は全ての選択されたプロセスに
対する値を含む。
【０１３１】コンソールは両スケルトン計器タイプによ
って定義され得るが、同じコンソール内のいかなる非ス
ケルトン計器も無視される。定義された計器の相対的配
置は不変のままである。これによって、多くのプロセス
が選択される時に非常に混雑した計器を生じることにな
るが、このコンソールの寸法変更するのは簡単である。
“All ”タイプスケルトン計器のみが定義される時は、
パフォーマンスツールはコンソールの大きさを再決定し
ない。
【０１３２】“All ”タイプスケルトン計器に最も適す
る計器のタイプは状態バーであるが、カラーが自動的に
値に割り当てられるのを許容するためにユーザが選択す
る場合には、他のグラフタイプが有用であり得る。後者
を実行するためには、スケルトン計器が定義される時に
は、カラーはユーザによって“default （デフォル
ト）”と指定される。
【０１３３】“Each（各）”スケルトンタイプは、選択
されるワイルドカードオブジェクトの各例が計器の一つ
の例を生成するので、このようにネーミングされる。プ
ロセスの場合には、五つのプロセスがユーザによって選
択された時には、“Each”スケルトンの各タイプが、プ
ロセスごとに一つずつ五つの計器を発生する。
【０１３４】再び、あるコンソールは一つを超える計器
を定義し、かつ複数のコンソールが両方のスケルトン計
器タイプによって定義され得るが、同一コンソール内の
いかなる非スケルトン計器も無視される。定義される計
器の相対配置は不変のままである。これによって、多く
のプロセスが選択された時には極めて小さな計器を生じ
ることになるが、コンソールの大きさを再決定すること
は容易である。或いは、発生された計器があまりにも小
さくなった場合は、パフォーマンスツールはコンソール
全体の大きさを再決定しようと試みる。
【０１３５】“Each”タイプのスケルトン計器に最適な
計器のタイプは（図１４に例示されているように）記録
計器である。これは、計器がスケルトンから作成される
以下の方法によってさらに強調される。
【０１３６】１． 相対水平配置は決して変化しない。 ２． スケルトンによって定義される相対垂直位置は変
化しないが、スケルトン計器は作成されるべき計器の数
へ細分化される。
【０１３７】３． 各作成された計器は、スケルトン計
器の完全な幅を有する。 ４． 各作成された計器は、図１６の参照番号２５１に
おいて示されているように、選択されたオブジェクトの
数によって分割されたスケルトンの全体高さである高さ
を有する。
【０１３８】ワイルドカードは、パスの終点ではない値
のパスネームの一部を示さなければならない。ワイルド
カードはパスの任意の他の部分を示すが、この部分が時
間経過によって又はシステム同士の間で変化し得る場合
にのみ重要となる。標準統計の場合は、以下のワイルド
カードが使用される。
【０１３９】PagSp /* /... 頁空間 Disk /* /... 物理的ディスク NetIF /* /... ネットワーク（LAN ）インターフェ
ース Proc /* /... プロセス hosts /* /... 遠隔ホスト
【０１４０】コンソールがスケルトン計器を含む時に
は、全てのこのような計器は同じワイルドカードを使用
しなければならない。ワイルドカードを混合すると、全
く理屈が通らない程に選択プロセスを複雑化してしま
い、これによって生じる図形ディスプレイは不可解とな
る。
【０１４１】単一のワイルドカードの注釈の概念へ拡張
することは、システムオブジェクトのクラスに対して全
ての統計を指定するために複数のワイルドカードを使用
することである。この機能は、クラスの特定例を識別す
るのをユーザに要求せずに、システムオブジェクト
（例：ディスク、プロセス、頁空間、ネットワークホス
ト、その他）のクラスをモニタするために、ユーザが総
称スケルトンコンソールを定義するのを許容する。
【０１４２】この機能は、複数レベルのシステムオブジ
ェクトのクラスの仕様を可能とする。
【０１４３】次いで、これらのスケルトンコンソール
は、特定時刻において、どのシステムオブジェクトが特
定のマシン又はセットのネットワークマシン（例：全て
のサブネットノードに対して、hdisk０、X process、/d
ev/hd6、abc.aus.ibm.com、その他）上に存在するかを
モニタするため、実行時に例示され得る。
【０１４４】これらのスケルトンコンソールは以下の情
報を指定することによってテキスト構成ファイル内で定
義される。
【０１４５】１． 全てのディスプレイパラメータ
（例：カラー、位置、寸法、グラフ形式、その他）。
【０１４６】２． システムオブジェクトクラス（例：
ディスク又はプロセス）。 ３． 各グラフにディスプレイされる特定の統計。 例えば、複数のネットワークノードにおける個々のプロ
セスによるメモリの使用をモニタするために、スケルト
ン形器からなるモニタを定義し得る構成ファイルライン
（行）は以下に示される。
【０１４７】モニター．局所プロセス．１．各．１：*
/Proc /* /workmem
【０１４８】上記の行は、複数のホストマシン上の特定
のプロセスの作動メモリ使用をモニタするためのパフォ
ーマンスツールに対する情報を有する。ホストネーム及
びプロセスＩＤは、モニタが開かれた時に特定のホスト
及びプロセスが決定されることをパフォーマンスツール
へ知らせるために、アスタリスク（例：* /Proc /* ル/w
orkmem）と置換される。
【０１４９】計器内の全ての値が共通の値のパスネーム
の全て又は一部を有する時、パフォーマンスツールは、
計器内にディスプレイされた値ネームからネームの共通
部分を決定し、かつ好適な場所において共通の部分をデ
ィスプレイする。この実行方法を決定する際には、パフ
ォーマンスツールは、コンソール内に含まれている全て
の値のネームを検討する。図示するためには、単一の計
器がコンソール内にあり、かつこの計器が以下の値を有
すると仮定する。
【０１５０】PagSp/paging00/%free PagSp/hd6/%free ネームは以下のようにチェックされる。
【０１５１】１． コンソール内の全ての値がパスネー
ムの始めのどれかを共通に有しているか否かが最初にチ
ェックされる。この場合、コンソール内の全ての値が共
通のその部分PagSp を有する。このストリングがコンソ
ール内の全ての計器に対して共通なので、好ましくはコ
ンソールを含むウィンドウのタイトルバーへ移動され得
る。このストリングはコンソールのネームの後ろにディ
スプレイされ、かつ以下のような角括弧で閉じられる。
【０１５２】＜PagSp/＞ 従って、計器内にディスプレイされるために残された値
のネームの残りは以下ののように示される。
【０１５３】paging00/%free hd6/%free ２． 次いで、コンソール内の各計器は、計器の全ての
値のネームが共通の終了を有するか否かを調べるために
チェックされる。この例においては、両方の値が%free
をディスプレイするので以下のように示される。結果的
には、値のカラーにおいてディスプレイされるべき値の
ネームの一部が以下のように短縮される。
【０１５４】paging00 hd6 （分離するスラッシュを用いない）値ネームの共通部分
は、計器の背景及び前景カラーを用いて反転映像におけ
る計器内にディスプレイされる。共通の部分をディスプ
レイするために使用される実際の場所は計器のグラフの
タイプに依存する。
【０１５５】３． 値ネームの共通部分をチェックする
最終タイプは、ネームの終わりが共通部分を所有しない
場合のみ実行される。この例を用いたとき、このような
チェッキングは実行されない。チェッキングが行なわれ
る時、以下のように処理される。
【０１５６】（上記に１とナンバリングされた点におい
て記述されているチェッキングを用いて四捨五入された
後で）値ネームの始まりが共通部分を有する場合、この
部分は値のパスネームから除去され、かつ計器内の反転
映像にディスプレイされる。
【０１５７】図示するために、二つの計器を有するコン
ソールを仮定せよ。第１の計器は以下の値を有すると共
に、 Mem /Virt /pagein Mem /Virt /pageout 第２の計器は以下の値を有する。
【０１５８】Mem /Real /%Work Mem /Real /%free 値ネームの共通部分を検出するために三つのルールを適
用した結果によって、コンソールウィンドウのタイトル
バーに＜Mem / ＞をディスプレイさせる。第１の計器
は、次いで、反転映像にディスプレイされたテキスト
“Vert”を有し、かつ値ネームは以下のように短縮され
る。
【０１５９】Pagein Pageout 第２の計器は反転映像に“Real”とディスプレイし、か
つ以下の値ネームを使用する。
【０１６０】%Work %free
【０１６１】コンソール 計器のようなコンソールは図形ディスプレイにおける矩
形部分である。これらは、OSF/MOTIF ApplicationShell
（アプリケーションシェル）クラスのトップレベルウィ
ンドウ内に作成され、これは各コンソールが完全なOSF/
MOTIF ウィンドウマネージャデコレーションを有するこ
とを意味する。これらのウィンドウデコレーションは、
ユーザが、コンソールの寸法を再決定し、コンソールを
移動し、アイコンし、かつ最大限とするために、mwm ウ
ィンドウマネージャ機能を使用するのを許容する。ウィ
ンドウマネージャの Close（閉）機能は、ファイルメニ
ューから使用可能なExit xmperf 機能を引き出す。
【０１６２】コンソールは計器の有用な“container
（容器）”である。ユーザは以下を操作できる。 １． 便利なバスケットとしてコンソールを用いて、コ
ンソール内で計器の収集を移動させ回る。 ２． コンソールを寸法を再決定し、コンソールが含む
計器の相対寸法及び位置をさらに保持する。 ３． 履歴データが収集され、かつコンソールが見えな
い時でも入力データの記録が継続するように計器のグル
ープをアイコンする。これはシステムへのロードをでき
るだけ少なくすることも助ける。 ４． コンソールを閉じ、かつ履歴データを含むコンソ
ールに割り当てられた全てのメモリ構造をフリーにす
る。閉じられたコンソールは、コンソールの定義を保持
するためにメモリ以外のシステム資源を全く使用しな
い。
【０１６３】コンソールは非スケルトン計器又はスケル
トン計器のいづれかを有するが、両方は含まない。これ
によって、コンソールを非スケルトン又はスケルトンコ
ンソールのいづれかに分類するのに有用となる。この二
つのコンソールは以下に記述されるように少し異なる動
作を行なう。
【０１６４】非スケルトンコンソールは、恐らく開又は
閉の二つの状態のうちの一つにある。コンソールはモニ
ターメニューからユーザが選択することによって開かれ
る。コンソールが一旦開かれると、コンソールはアイコ
ンされ、移動され、最大とされ、かつ mwmを介して寸法
が再決定される。これらの動作のいずれもコンソールの
状態を変えない。ディスプレイ上ではコンソールは見え
ないかもしれないが、まだ開状態であると考えられ、次
いで記録が開始されたならば、この状態がさらに続く。
【０１６５】一つ以上の非スケルトンコンソールを開い
た後には、モニターメニュー上のコンソールのネームは
今度はアスタリスクが前にくる。これはコンソールが開
いていることを示す。ユーザがアスタリスクが先行する
ネームのうちの一つを選択する場合、対応するコンソー
ルは閉じる。
【０１６６】スケルトンコンソールそれら自体は決して
開くことができない。ユーザがモニターメニューからコ
ンソールを選択する時にはコンソールは開かないが、そ
の代わり、スケルトンコンソール内の計器に対する値ネ
ーム内のワイルドカードと一致するネームリストをディ
スプレイさせる。このネームリストから一つ以上のネー
ムを選択した場合は、新たな非スケルトンコンソールが
作成され、かつモニターメニューへ追加される。この新
たな非スケルトンコンソールは自動的に開き、次いでシ
ーケンス番号が後置表記されたスケルトンコンソールネ
ームから構築されたネームが付与される。
【０１６７】スケルトンコンソールは他のいづれのコン
ソールとも同様に定義される。コンソールを定義するキ
ーワードも計器を定義するキーワードも異ならない。唯
一の差はコンソールの計器内の値を定義するために使用
される一つのキーワード内にある。異なるキーワード
は、“all （全て）”及び“ each （各）”のうちの一
方へ変更されなければならない「入力(input) 」キーワ
ードである。
【０１６８】異なる他のものは値のパスネームが一つの
（一つだけの）ワイルドカードを含まなくてはならず、
かつ一つのコンソール内の全ての“all （全て）”及び
“ each （各）”のキーワードのパスはワイルドカード
に至るまで同一であり、かつワイルドカードを含まなけ
ればならない。
【０１６９】一つ又は他のキーワードを使用するかどう
かはどのタイプのスケルトンを利用者が求めるかによ
る。
【０１７０】スケルトン定義の二つの例が以下に示され
ている。 monitor.Single-host Monitor.3.each.1: hosts /* /C
PU/kern monitor.Single-host Monitor.3.each.2: hosts /* /S
yscall/total monitor.Remote Mini Monitor.1.each.4: NetIf /* ip
acket monitor.Remote Mini Monitor.1.each.5: NetIf /* /o
packet monitor.Disk Monitor.1.all.1: Disk/ * /bu
sy
【０１７１】コンソール内のスケルトンタイプが混合さ
れ、かつワイルドカードに到る全てのパスは、計器内だ
けでなくコンソール内の全ての計器において同一でなけ
ればならない。
【０１７２】既に指摘されているように、“all ”タイ
プのスケルトン計器は一つ値だけを定義している。引き
続いて、例示された計器内の全ての値は、スケルトン計
器内の値に対して定義されているのといわゆる同じカラ
ーを有する。これはかなりどんよりしている。さらに悪
いことには、状態バーグラフタイプを使用することは、
“all ”タイプのスケルトンを効率的に制限してしま
う。さもなければ、利用者が一つの値を他の値と区別す
ることができない。
【０１７３】これを阻止するために、利用者はタイプ
“all ”のスケルトン計器内の値に対するカラーを“de
fault （デフォルト）として定義することができる。従
って、xmperfを用いて、値がスケルトンの例示の間に挿
入される時に複数のカラーをこれらの値に動的に割り当
てる。この機能を使った完全値の定義の例が以下に示さ
れている。
【０１７４】monitor.Processes.1.all.1: hosts/my
host/Proc/* /kerncpu monitor.Processes.1.color.1: default monitor.Processes.1.range.1: 0-100 monitor.Processes.1.label.1: cmd
【０１７５】スケルトンから作成された非スケルトンコ
ンソールはスケルトンコンソールの“Instance（インス
タンス）”であるといわれ、非スケルトンコンソールは
スケルトンから例示されている。例示された非スケルト
ンコンソールは、ユーザが行なう変更が構成ファイルに
全く影響を与えないことを除いては、他のいかなる非ス
ケルトンコンソールとも全く同様に動作する。ユーザは
新たなコンソールを閉じることができ、かつ所望される
時はいつでも再開するだけでなく、寸法を再決定し、ア
イコンし、最大とし、かつそれの寸法を再決定する。
【０１７６】スケルトンコンソールがモニターメニュー
から選択される度に、各々が固有のネームを有する新た
な例示が作成される。例示ごとに、ユーザはワイルドカ
ードのために値を選択するように促され、従って各例示
はすべての他の例示とは異なり得る。
【０１７７】作成されたスケルトンコンソールを非スケ
ルトンコンソールへ変更し、かつその変更内容を構成フ
ァイル内に保管するように所望された場合、変更及び保
管の最も簡単な方法は、コンソールメニューから“Copy
Console（コンソールを複写せよ）”機能を使用するこ
とにある。これによってユーザは新たなコンソールのネ
ームを指定し、かつ複写はコンソールから複写されかつ
例示されたスケルトンコンソールと全く同じ外観を有し
た非スケルトンコンソールである。コンソールが一旦複
写されると、ユーザは例示されたスケルトンコンソール
を削除し、かつ構成ファイル内においてその変更内容を
保管する。
【０１７８】すべてのコンソールは、XmFormクラスのOS
F/MOTIF ウィジットとして定義され、かつこの容器ウィ
ジット内の計器の配置は関連する位置決めとして実行さ
れる。
【０１７９】コンソールに計器を追加するためには、ユ
ーザは新たな計器を追加するか、又はすでにコンソール
内にある計器を複写するかのいづれかを選択することが
できる。“Add Instrument（計器追加）”が選択された
場合、以下のことが生じる。 １． コンソールの高さの２４％の高さを有する計器を
作成するために十分な空間があるか否かがチェックされ
る。この空間はコンソールの全体の幅において使用可能
でなければならない。この場合、新たな計器が使用可能
な空間に作成される。 ２． 十分な空間が得られない場合は、コンソール内の
現行の計器があたらな計器に空間を提供するために再度
寸法決定される。次いで、新たな計器がコンソールの底
部で生成される。 ３． 新たな計器が１００画素より少ない高さを有して
いる場合、コンソールは新たな計器が１００画素の高さ
になるのを許容するために寸法が再決定される。
【０１８０】“Copy Instrument （計器複写）”が選択
された場合、以下のことが生じる。 １． 現行の寸法と同じ寸法の計器を生成するのに、十
分な空間があるか否かがチェックされる。ある場合にお
いては、新たな計器がその利用可能空間内に生成され
る。新たな計器を追加する場合に起こることと異なる場
合は、複写（コピー）は、完全なコンソール幅で利用で
きる空間を有することは必要ないので、新たな空間を含
むのに十分な幅である空間を利用する。 ２． 十分な空間が得られない場合は、コンソール内の
現存する計器が新たな計器に空間を提供するために再度
寸法決定される。次いで、新たな計器が作成される。新
たな空間は常にコンソールの底部で作成され、かつコン
ソールウィンドウの完全な幅以内に配置される。 ３． 新たな計器が１００画素より少ない高さを有して
いる場合、コンソールは新たな計器が１００画素の高さ
になるのを許容するために寸法が再決定される。
【０１８１】計器が一旦選択され、かつその寸法の再決
定が決まると、計器は消去されると共に、計器のゴムバ
ンドのアウトラインと置換えられる。ユーザはマウスボ
タン１を押し下げ、マウスを動かすことによって計器の
寸法を変える。ユーザがボタンを押す時、ポインタはア
ウトラインの底部右側コーナへ移動し、寸法の再決定は
アウトラインの上部左側コーナは置かれたまま、このコ
ーナを移動させることによって常に実行される。
【０１８２】ユーザがマウスボタンを放す時、計器はそ
の新たな寸法において再度描写される。上部左側コーナ
が寸法の再決定の前に所望される位置に置かれるよう
に、コンソール内で計器を移動することは通常は好まし
い考えである。
【０１８３】再度大きさが決定された計器の位置は、コ
ンソールサイズのパーセントで表示可能となるように四
捨五入（ラウンド）されなければならない。それゆえ、
計器が、ゴムバンドのアウトラインが示したものから僅
かに寸法を変更することになる。
【０１８４】計器はこれらが他の計器とオーバーラップ
するように寸法を変更するとはできない。もしオーバー
ラップするような場合には、その寸法はオーバーラップ
を避けるために縮小される。
【０１８５】計器が移動されるように選択される時、計
器は消滅し、計器のゴムバンドアウトラインによって置
換される。計器の移動を開始するために、ユーザはマウ
スカーソルをアウトライン内に配置し、かつ左マウスボ
タンを押す。アウトラインが所望の位置にくるまでマウ
スを動かしている間、ボタンは押し下げらている。次い
で、ボタンは計器を再び描写するために放される。
【０１８６】計器は、他の計器の上を移動することがで
きるが、マウスボタンが放された時は計器にオーバーラ
ップすることは決して許容されない。オーバーラップが
生じたならば、計器はオーバーラップを除去するために
切捨てられる。
【０１８７】最初に図４を参照すると、データディスプ
レイサブシステム４０は、GUI サブシステム８０、デー
タ値受信者サブシステム６０、及び再生サブシステム５
０から入力され、構成サブシステム３０によって記述さ
れた形式においてパフォーマンスデータを示すことが必
要とされるディスプレイを生成する。データディスプレ
イサブシステム４０は、構成ファイルからディスプレイ
形式情報を得るため、及びシステム構成情報に対する要
求をデータ提供者デーモン２１０へ送るために、構成サ
ブシステム３０を呼び出す。
【０１８８】図２０に関しては、データディスプレイサ
ブシステムは、ブロック３００において、データが、受
け取られたデータ値又は再生サブシステムのどちらから
受け取られたかをチェックする。これらのサブシステム
の各々からの入力データ形式は一致しており、従ってデ
ータがどこを起源とするかを区別するために特別なコー
ドを必要としない。データディスプレイサブシステム
は、ディスプレイデータ及び対応するコンソールへポイ
ンタを入力パラメータからピックアップし、かつブロッ
ク３０２においてディスプレイコンソール計器内のデー
タを更新し、次いで終了する。ブロック３０２で受け取
られたデータに関しては、データディスプレイサブシス
テムは図１９のブロック２６２において再生サブシステ
ムからも呼び出され、ここで、オペレータはデータを
「再生」するように要求するか、又は図２２のブロック
４０８において、データ値受信者サブシステムからデー
タが伝送されてくる。この状態（図２０のブロック３０
２）においては、データディスプレイサブシステムは統
計データをディスプレイするために最小のオーバーヘッ
ドを有しており、かつデータディスプレイサブシステム
は、システムへの影響を最小に抑えながら、局所又は遠
隔ホストへデータを提供することができる。
【０１８９】ブロック３０４で決定されるように、図形
ボタン選択によって“console monitor （コンソールモ
ニター）”を開いた場合、GUI サブシステムはこの入力
を捕獲し、かつディスプレイサブシステムへこの入力を
渡す。ブロック３０６において決定されるように、固定
コンソールに対してこの選択が行なわれた場合には、デ
ィスプレイコンソールを作成するためにコンソール構成
データを得るようにブロック３０８において構成サブシ
ステムが呼び出される。ブロック３１０における統計に
関するデータ提供者との交渉は、データディスプレイサ
ブシステムから開始されるが、ネットワーク送信／受信
インターフェースを介してデータを得るために構成サブ
システムを使用する。ディスプレイサブシステムは、ブ
ロック３１２において固定ディスプレイサブシステムコ
ンソールを作成し、かつ開く。次いでディスプレイサブ
システムは、ブロック３１４においてデータ提供者デー
モンからデータ送りを開始するためにネットワーク送信
／受信インターフェースを呼び出し、そして終了する。
【０１９０】ブロック３０６において決定されるよう
に、オペレータが“Skeleton Console（スケルトンコン
ソール）”を開いたならば、データディスプレイサブシ
ステムは、ブロック３１６においてコンソール構成デー
タを得るために構成サブシステムを呼び出し、次いで、
構成ファイル内のスケルトンテンプレートによって指定
されるように、ブロック３１８において現在スケルトン
パラメータを得るためにネットワーク送信／受信インタ
ーフェースを呼び出す。次いで、データディスプレイサ
ブシステムは、ブロック３２０において、オペレータが
どのスケルトンコンソールを見たいかを選択するのを可
能とするために、スケルトンパラメータを有するGUI サ
ブシステムを呼び出す。GUI サブシステムからオペレー
タ選択を受け取った後に、データディスプレイサブシス
テムは、スケルトンコンソールパラメータを例示するた
めの要求を、ネットワーク送信／受信インターフェース
を介してデータ提供者デーモンへ送るために構成サブシ
ステムを呼び出す。データ提供者からデータを受け取っ
た後には、データディスプレイサブシステムは、ブロッ
ク３２２においてスケルトンディスプレイコンソールを
作成すると共に開く。最後に、データディスプレイサブ
システムは、ブロック３１４において、構成及びネット
ワーク送信／受信インターフェースを介して“Start da
ta feed （データ送り開始せよ）”要求をデータ提供者
デーモンへ送り、そして終了する。
【０１９１】ブロック３２４において決定されるよう
に、オペレータが図形ボタン選択を介して“close cons
ole （コンソールを閉じよ）”オプションを選択した場
合、GUI サブシステムはこの入力をデータディスプレイ
サブシステムへ渡す。次いでデータディスプレイサブシ
ステムは、ブロック３２６において、構成及びネットワ
ーク送信／受信インターフェースを介して、データ提供
者デーモンへ“stop data feed（データ送りを停止せ
よ）”要求を送る。最後に、データディスプレイサブシ
ステムはブロック３２８においてディスプレイコンソー
ルを閉じ、そして終了する。
【０１９２】ブロック３４０において決定されるよう
に、オペレータが、“change graphstyle （図形スタイ
ルを変更せよ）”オプションのうちの一つを選択した場
合は、GUI サブシステムはこの入力を捕獲し、かつ選択
された新たな図形スタイルオプションと共にこの入力を
データディスプレイサブシステムへ渡す。次いで、デー
タディスプレイサブシステムは、ブロック３４２におい
て、現在コンソール、計器、及び値の属性が新しい値に
よって更新されかつディスプレイされるように、ディス
プレイモードを動的に変更する。構成ファイルは、オペ
レータが構成ファイルが保管されることを明示的に要求
するまで更新されない。
【０１９３】ブロック３４４において、オペレータが
“Tabulation window （作表ウィンドウ）”（作表形式
における図形データの数値ディスプレイ）を開くことを
選択した場合は、GUI サブシステムは、ブロック３４６
において、選択された計器に対する作表ウィンドウを開
くようにデータディスプレイサブシステムへこの入力を
渡し、かつブロック３４８において、このウィンドウ内
にディスプレイされるように、対応する計器内の図形デ
ータと同時にこのデータ値に対するフラグを設定する。
【０１９４】ブロック３５０において決定されるよう
に、オペレータが構成ファイル内で定義されるコマンド
ストリングを実行するとされるボタンを選択した場合
は、GUIサブシステムはデータディスプレイサブシステ
ムを呼び出し、次いでこのデータディスプレイサブシス
テムはブロック３５２において構成ファイルからコマン
ドストリングを得るために構成サブシステムを呼び出
す。データディスプレイサブシステムは、ブロック３５
４においてユーザ提供パラメータを受け取り、次いでブ
ロック３５６においてコマンドストリングを実行するた
め、コマンドストリングをホストオペレーティングシス
テムへ渡す。
【０１９５】オペレータがブロック３５０において決定
されるように、再生コンソールを開くボタンを選択した
場合は、ブロック３５８において、再生ファイルが開か
れ、かつ前もって保管されているコンソール構成データ
が読み出される。次に、ブロック３６０において、この
コンソール構成データを用いてディスプレイ上に再生コ
ンソールが開かれる。この動作は、図１９のブロック２
５４において再生サブシステムによって開始され、次い
で本来データが記録されている同じコンテキスト内の前
もって記録されたデータをコンテキストのセットアップ
のために拡張されたオペレータ対話を要求せずに、自動
的にオペレータに提供するための能力を提供する。最後
に、データ記録送りは、ブロック３６２において開始さ
れ、ここで、データ送りを開始するための要求がデータ
提供者に送られる。この要求の結果として受け取られた
データ送りはブロック３０２において処理される。
【０１９６】構成サブシステムの実施 まず図３に関しては、構成サブシステム３０の主機能は
構成ファイル１１０からデータに対する要求を受け取
り、かつ発呼者（発呼者）に要求又はデータを戻すこと
である。これは、適切なデータ提供者へデータ要求を経
路化するためのネットワーク送信／受信インターフェー
ス７０への主要インターフェースでもある。
【０１９７】xmperfパフォーマンスツールが初めてスタ
ートする時、構成サブシステムが構成ファイルをパーズ
（解析）し、かつすべてのモニター及びメニューが作成
される時にどのように見えるかを決定する初期構成定義
制御ブロックを構築する。
【０１９８】図２１に関しては、ブロック３７０におい
て、データディスプレイサブシステムが、コンソールが
どのように見えるか（寸法、形状、計器、カラー、値、
その他）、又はオペレータからどの情報をスケルトンコ
ンソールが必要としているかを定義する構成データを要
求する場合、構成サブシステムは、ブロック３７２にお
いて、構成定義制御ブロックからこのデータを検索し、
次いでこのデータを発呼者へ戻す。
【０１９９】オペレータが“save configuration file
（構成ファイルを保管せよ）”オプションを選択した場
合、ブロック３６０（図２１）において、GUI サブシス
テムは、この要求を構成サブシステムへ渡し、次いで構
成サブシステムはタイムベースのネームによって現在構
成ファイルを再度ネーミングし、次いでブロック３６２
においてアクティブ構成ファイルである新たなファイル
へ現在構成制御ブロックデータを書込み、次いでブロッ
ク３９０において終了する。
【０２００】GUI がネットワークノードのリストをオペ
レータに提供する必要がある場合、ブロック３６６にお
いて、GUI はネットワーク送信／受信インターフェース
を介してこの要求をデータ提供者デーモンへ伝送するた
めに、ブロック３６４において構成サブシステムを呼び
出す。データ提供者がこの要求に応答する時、ブロック
３６８において、応答ノードリストが作成され、かつこ
のリストはGUI サブシステムへ戻される。
【０２０１】ブロック３７４及びブロック３８０によっ
て決定されるように、発呼者ルーチン（経路）が“Star
t （開始せよ）”、“stop（停止せよ）”、又は“chan
ge data feed rate （データ送り速度を変更せよ）”が
データ提供者へ伝送されるように要求した場合は、ブロ
ック３８６において、構成サブシステムはこの要求をネ
ットワーク送信／受信インターフェースを介してデータ
提供者へ送り、次いでブロック３９０において終了す
る。
【０２０２】ブロック３８０において決定されるよう
に、発呼者ルーチンがデータ値に対するデータ階層を走
査したい場合、ブロック３８２において、構成サブシス
テムはネットワーク送信／受信インターフェースを介し
てこの要求をデータ提供者へ伝送し、ブロック３８４に
おいて、受信されたデータを発呼者へ戻す。データコン
テキスト階層の例は以下に示される。
【０２０３】
【表１】
【０２０４】データコンテキスト階層を走査するため
に、プログラムは、コンテキストオブジェクトの全ての
サブコンテキストを作成（例示）するために、RSiInsta
ntiateを呼び出す。次に、プログラムは、パスネームと
一致するコンテキストに対するコンテキスト階層を検索
するためにRSiPathGetCxを呼び出す。次いで、コンテキ
ストの第１のサブコンテキストを戻すためにRSiFirstCx
を呼び出す。RSiNextCxがコンテキストの次のサブコン
テキストを得るために呼び出される。統計はコンテキス
ト階層の葉ノードにおいて配置されている。この統計は
コンテキストの第１の統計を得るためにRSiFirstStatを
呼び出すことによって検索されることができ、かつRSiN
extStat はコンテキストの次の統計を得る。
【０２０５】データ値受信者サブシステムの実施 図７のデータ値受信者サブシステム６０は、ネットワー
ク送信／受信インターフェース７０からインターフェー
ス１５０においてすべてのデータ送りを受け取る。この
データは、入力データがアクティブディスプレイコンソ
ールにおける指定計器と一致され得るように StatSetID
を含む。
【０２０６】図２２に関しては、データ送りパケット４
００を受信したら、データ値受信者は StatSetIDを受け
取り、かつブロック４０２において一致 StatSetIDを探
索するアクティブディスプレイコンソールのリストを捜
し出す。データ値受信者が一致を見つけなかった場合に
はブロック４０６においてこのデータを廃棄する。
【０２０７】ブロック４０４において決定されるよう
に、データ値受信者サブシステムが一致コンソールを見
つけた場合、ブロック４０８において、このサブシステ
ムが見つけたコンソール制御ブロックを指し示すポイン
タによって、データをデータディスプレイサブシステム
へ渡す。ブロック４１０において決定されるように、記
録がコンソール又は計器に対してアクティブである場
合、ブロック４１２において、データは、データが記録
ファイル内に保管されるようにコンソール制御ブロック
を指し示すポインタによって記録サブシステムへ渡され
る。
【０２０８】局所と遠隔統計の両方を有するネットワー
ク送信／受信インターフェースからの統計データの単方
向フローと、データ値受信者サブシステムによって要求
される最少の処理量のおかげで、リアルタイムのパフォ
ーマンス／統計データはディスプレイ及び記録サブシス
テムの両方へ同時に伝送され得る。
【０２０９】ネットワーク送信／受信インターフェース
の実施 図８のネットワーク送信／受信インターフェース７０の
主機能は、ネットワーク要求をデータ提供者デーモン２
１０へ送り、その応答を受け取り、次いでデータ送り情
報をデータ値受信者サブシステム６０へ渡すことであ
る。
【０２１０】図２３に関しては、ブロック４２０におい
て決定されるように、ネットワーク送信／受信インター
フェースが、全てのデータ提供者デーモンを識別するた
めに呼び出しを受け取った場合、ブロック４２２におい
て、ネットワーク送信／受信インターフェースは、局所
副区域ネットワーク送信／受信インターフェース内の全
てのホストと、ホストファイル内で指定されたいかなる
ホストへも“ are you there ”メッセージを同報通
信する。ブロック４２４において、ネットワーク送信／
受信インターフェースは、全ての応答を待機し、次いで
全ての応答ホストのリストを呼び出しルーチンへ戻す。
【０２１１】ネットワーク送信／受信インターフェース
が、ブロック４２６においてデータ階層を走査し、ブロ
ック４２８において計器データ値を交渉し、ブロック４
３０においてデータ送りの頻度を開始、停止、又は変更
するために呼び出しを受け取ったならば、ネットワーク
送信／受信インターフェースは、ブロック４３２、４３
４、又は４３６のそれぞれにおいて要求パケットをデー
タ提供者デーモンへ伝送し、次いでブロック４３８とブ
ロック４４０において、応答を待機し、かつ応答を構成
サブシステムへ戻して渡す。データ提供者デーモン２１
０は局所又は遠隔ノードのいづれかに配置される。基底
にあるTCP/IPソケット通信プロトコルはデータ要求者か
らデーモンの位置をマスキングする。データ要求者はノ
ードネームを指定するだけで、通信プロトコルはそれが
局所か又は遠隔かを決定する。
【０２１２】ブロック４４２において、ネットワーク送
信／受信インターフェースがデータ提供者デーモンから
データ送りを受け取った場合は、ブロック４４４におい
て、データをデータ値受信者サブシステムへ渡す。
【０２１３】図形ユーザインターフェースの実施 図２４に示されているように、図形ユーザインターフェ
ース（GUI ）８０は単にユーザとパフォーマンスツール
の間のインターフェースであり、ユーザ入力を受け取
り、情報を適切なパフォーマンスツールサブシステムへ
渡す。ブロック４２１において、インターフェースはユ
ーザ入力を受け取るのを待機する。ブロック４２３にお
いては、ユーザがパフォーマンスツールを終了させたい
かどうかがチェックされる。その場合、ツールはブロッ
ク４１９において終了する。
【０２１４】そうでない時は、ブロック４２５、４２
９、４３３、及び４３７においては、入力が、構成、デ
ータディスプレイ、記録、又は再生サブシステムのいづ
れかに宛先指定されているか否かを決定するためのチェ
ックが行なわれる処理が継続される。ブロック４２７、
４３１、４３５、又は４３９においては、適切なサブシ
ステムはユーザ入力の宛先に基づいて呼び出される。
【０２１５】GUI と他のサブシステムの間の特定のイン
ターフェースは、図２５においてさらに示されている。
記録システムへのGUI のインターフェースは、以下を備
える。ユーザは、ブロック４３３（図２４）において、
GUI が検出すると共に記録サブシステムへ伝送するコン
ソール又は計器記録を開始及び停止するための要求を開
始する。記録システムは、ユーザが現存記録ファイルの
追加／置換を望むかどうかをユーザに促すためにGUI へ
メッセージを伝送し、かつこの様な問い合わせに対する
ユーザによる応答が記録サブシステムへ戻される。
【０２１６】構成サブシステムへのGUI インターフェー
スは以下のメッセージを備える。第１に、コンソールを
作成／消去／複写するためのユーザ開始メッセージは構
成サブシステムへ送られる。コンソールを例示するため
の要求も（構成サブシステムへ）送られ、構成サブシス
テムからの応答は、可能なコンソール例示をリスト作成
するメッセージである。次いで、ユーザはGUI によって
このリストから選択し、メッセージがGUI から選択され
た例示を示す構成サブシステムへ送られる。ユーザは、
計器を追加するか、或いは値を追加／変更するように送
られるメッセージを開始することもでき、どちらもGUI
を使ってユーザに提供される、可能性のある値のリスト
を作成する。ユーザは構成サブシステムへ送られる値を
選択する。最後に、ユーザは構成ファイルを保管するた
めの要求を開始することができる。
【０２１７】データディスプレイサブシステムへのGUI
インターフェースは以下のメッセージを備える。ユーザ
は、コンソールを開／閉するための要求を開始すること
ができる。ユーザは、計器のスタイル又は特性を変更す
るか、又は値の特性を変更するためのメッセージを開始
することができる。データディスプレイサブシステム
は、ユーザへ提供するために、可能な選択のリストを含
むメッセージをGUI へ伝送し、それゆえユーザはデータ
ディスプレイサブシステムへ戻す選択を行なうことがで
きる。
【０２１８】最後に、再生サブシステムへのGUI インタ
ーフェースは以下のメッセージを備える。ユーザは、記
録を開／閉するように再生サブシステムに命令するため
のメッセージを開始し、再生サブシステムは記録のリス
ト作成によって応答し、このリストはユーザが選択する
ために提供される。この選択は再生サブシステムへ戻さ
れる。ユーザは、GUI によって再生サブシステムへ、記
録／再生ファイルを、再生／停止、巻戻し、シーキン
グ、減速／加速再生、及び消去するように種々のメッセ
ージを送らせる動作を呼び出すこともできる。
【０２１９】遠隔システムのモニタリング 図２６に関しては、実行可能データ収集２１０を実行可
能なデータディスプレイ９０から分離させる概念が、局
所ホスト２０８又は遠隔ホスト２１８上のデータ消費者
９０へ統計を供給することが可能な分離したデータ提供
者２２０を使用する概念へと移行した。パフォーマンス
ツール９０は、システムにおいて実行可能なプログラム
を削減することによって、真の遠隔モニタリングを、遠
隔的にモニタリングされるように完全なパフォーマンス
ツールの部分集合へ供給する。xmserved２１０と呼ばれ
る部分集合はデータ検索部分２０７とネットワークイン
ターフェース２０５からなる。これは、手動的に、かつ
システム開始ファイルのうちの一つから開始され、或い
はデータ消費者による要求が受け取られた時に開始され
た（inetd ）超（スーパー）デーモンによって開始され
る様に残されたデーモンとして実行される。
【０２２０】このアプローチの明確な利点は、モニタさ
れるシステムにおけるモニタリングソフトウェアの影響
を最小とする点にある。あるホストは多数の遠隔ホスト
をモニタすることができるので、より大規模のインスタ
レーション（設置）には、ネットワークにおける多数の
又は全ての他のホストをモニタするために専用のホスト
を使用することもある。
【０２２１】xmservedデーモンは、複数の（及び異な
る）プラットフォームと接続されることができるので、
デーモンが実行する各ホストの特徴に対してフレキシブ
ルな適合を可能とすることが示される。これはいくつか
の示唆を含んでいる。第１に、データ提供者デーモン２
１０は其自体に埋め込まれたいかなるシステム依存統計
をも所有していない。第２に、このような統計を抽出す
るために、システム依存統計及び関数が外部実行（エク
スキュータブル）２２０へ提供される。これらの外部実
行とxmservedの間のクロスアクセス統計のプロトコル及
び方法が定義される。第３に、アプリケーションプログ
ラミングインターフェースがプロトコルとアクセスメカ
ニズムを汎用化するために使用される。従って、本明細
書中に記述されているパフォーマンスツールと同様のカ
ストマイズ（個別化）されたツールが開発され、次いで
このツールは現存のxmservedデーモンとインターフェー
スする。
【０２２２】遠隔システムのモニタリングがどのように
して起こるかが以下に詳細に示されている。この説明に
関しては、データ提供者ホスト２１８という用語が他の
ホストへ統計を供給するホストについて説明している
が、統計を受け取り、処理し、かつディスプレイするホ
ストはデータ消費者２０８と呼ばれている。
【０２２３】遠隔モニタリングを開始するための主導権
は常にデータ消費者プログラム９０とともに存在してい
る。
【０２２４】パフォーマンスツールは、遠隔統計の潜在
的な提供者と以下の三つの状況において常に接触を試み
る。 １． ツールが実行を開始した時、ツールは常に潜在的
データ提供者ホストを識別しようと試みる。 ２． 潜在的データ提供者と接触するための最後の試み
から５分経過した時、ユーザはデータ提供者ホストを参
照する計器を作成する。 ３． 潜在的データ提供者ホストと接触するための最後
の試みから５分経過した時、ユーザは遠隔計器を含むコ
ンソールを起動させる。
【０２２５】５分間制限はデータ消費者ホスト２０８が
潜在的データ提供者ホスト２１８の更新されたリストを
有することを確認するために実行される。これは５分置
きに行なわれる無条件の同報通信ではない。むしろ、デ
ータ提供者ホストを識別しようとする試みは、ユーザが
遠隔モニタリングを開始したいと望み、この試行が最後
に行なわれてから５分を超えた時制限される。
【０２２６】５分間制限は最近開始した潜在的データ提
供者についての情報を得るだけでない。この制限はもは
や使用不可能なこのようなホストをデータ提供者のリス
トから除去する。
【０２２７】パフォーマンスツールが一旦潜在的データ
提供者ホストを識別する必要に気付くと、パフォーマン
スツールは送信勧誘的 are you there メッセージが
送られるネットワークアドレス（単数又は複数）を得る
ために以下の方法のうちの一つ以上を使用する。最後の
二つの方法はファイル/usr/lpp/xmservd/hostsの存在に
依存する。データ提供者ホストを勧誘するための三つの
方法は以下に示される。 １． ユーザによって禁じられないならば、以下に記述
されているように、パフォーマンスツールは、ホストの
ネットワークインターフェースの各々と対応する同報通
信アドレスを見つける。送信勧誘メッセージは対応する
同報通信アドレスを用いて各ネットワークインターフェ
ースへ送られる。同報通信は Localhost（局所ホスト）
（ループバック）インターフェース２０２やX.25又はSL
IP（シリアルラインインターフェースプロトコル）接続
のような二地点間インターフェースにおいては試行され
ない。 ２． インターネット同報通信アドレスのリストがファ
イル/usr/lpp/xmservd/hosts内に供給されるならば、送
信勧誘メッセージはこの様な同報通信アドレスの各々に
送られる。ファイル内に提供される全てのインターネッ
トアドレスは、その最後の構成要素が数字２５５である
場合、同報通信アドレスであると仮定される。 ３． ホストネーム又は非同報通信インターネットアド
レスのリストがファイル/usr/lpp/xmservd/hosts内に供
給されるならば、このリスト内の各ホストに対するホス
トインターネットアドレスが探索されかつメッセージが
各ホストへ送られる。探索はgethostbyname( )call（呼
び出し）を介して行なわれ、これによって、パフォーマ
ンスツールが実行するホストに対してどちらのネームサ
ービスがアクティブであるかということがホストアドレ
スを見つけるために使用される。ファイル/usr/lpp/xms
ervd/hostsは非常に単純なレイアウトを有する。行の１
列内に配置された場合にのみ一つだけのキーワードが認
識される。このキーワードは、 nobroadcast であり、かつ are you there メッセージが上記の方
法（１）を用いて同報通信されないことを意味する。こ
のオプションは、多数のホストがネットワーク上に存在
しており、好適に定義された部分集合だけが遠隔的にモ
ニタされる状況において有用である。同報通信が試行さ
れるべきであるが三つのホストへの直接的接触が必要と
されることを示すために、/usr/lpp/xmservd/hostsファ
イルはテーブル６に示されているように見られる。 ------------------------------------------------------------------------ nobroadcast birte.austin.ibm.com gatea.almaden.ibm.com umbra ------------------------------------------------------------------------ テーブル６ サンプル/usr/lpp/xmservd/hosts 特定ホストを勧誘するためのファイル
【０２２８】テーブル６はモニタするためのホストが必
ずしも同じドメイン内、又は局所ネットワーク上に配置
される必要がないことをさらに示している。
【０２２９】データ消費者ホストと同じ部分集合上には
ない遠隔ホストをモニタするときは常に他の部分集合の
同報通信アドレス又はこれらのホストの全てのホストネ
ームが、/usr/lpp/xmservd/hostsファイル内で指定され
なければならない。この理由はＩＰ同報通信はＩＰルー
タ又はゲートウェイを介して伝搬しないことによる。
【０２３０】テーブル７は、同報通信アドレス１２９．
４９．１４３．２５５によって識別される部分集合上に
同報通信するために、全ての局所インターフェース上で
同報通信されたいと所望される状態を示している。 ------------------------------------------------------------------------ １２９．４９．１４３．２５５ umbra ------------------------------------------------------------------------ テーブル７ 部分集合を勧誘するためのサンプル /usr/lpp/xmservd/hosts ファイル
【０２３１】xmservd デーモン２１０はinetd （開始さ
れた）“super daemon（超デーモン）”から開始される
ように設計される。以下のセクションは、xmservd がど
のようにしてスタートし、終了し、かつデータ消費者プ
ログラムのトラックを保持するかについて記述してい
る。
【０２３２】xmservd デーモン２１０は適切に実行する
ためにinetd デーモンとして構成されなければならな
い。デーモンが手動的に開始された場合、プログラムxm
peekを呼び出すことによってそれ自体を再スケジューリ
ングし、次いで終了するように試みる。これによってxm
servd がinetd を介して再スケジューリングされること
になる。/etc/ometd.conf 内にデーモンを定義する行
は、inetd が一度に一つ以上のデーモンの複写を開始す
るのを阻止するために“wait（待機せよ）”オプション
を指定しなければならない。
【０２３３】xmservd デーモンはＵＤＰデータグラムが
そのポートで受け取られた直後にinetd によって開始さ
れる。これは、これらのデータグラムが受け取られた時
に、xmservd デーモンが開始されることを指定するため
に予備のシステム構成の間、inetd がセットアップされ
ているからである。デーモンが局所SNMPエージェントか
らのＳＭＵＸインターフェース（このインターフェース
は後で説明される）を通った要求によってスケジュール
されないことに留意されたい。SNMPエージェントは異な
るポート数を使用する。xmservd が異常終了したり、殺
されたりしない場合は、いかなるデータ消費者もその入
力を必要とし、またSNMPエージェントへの接続が確立さ
れかつアクティブである限り、xmservd は実行を継続す
る。データ消費者がその入力を必要とせず、かつＳＭＵ
Ｘインターフェースを介する接続が全く確立されない
か、又はこのような接続のいづれもが終了するいずれか
である時には、デーモンはxmservd に対する−１（Ｌの
場合より低い）コマンドライン引き数によって指定され
た分（minutes ）数の間さまよっている。time to live
分（minutes ）のデフォルト数は１５である。
【０２３４】ＳＭＵＸインターフェースを介するSNMPエ
ージェントへの接続がアクティブである時は必ず、デー
モンは、たとえ供給するデータ消費者がない時でもタイ
ムアウト（時間切れ）したり、消滅することはない。次
いで、“time to live”限定は、xmservd におけるテ
ーブル（表）から削除され得る非活動状態の遠隔消費者
を探索する時を決定するためのみに使用される。
【０２３５】他の多くのデーモンと同様に、xmservd は
それ自体をリフレッシュするための要求としてシグナル
SIGHUP （kill−１（−１を消去））の受け取りを変換
する。xmservd は、inetd を介してxmservd 自体の他の
複写を生産し、かつそれ自体を殺すことによって上記の
動作を実行する。これが生じる時には、xmservd の生産
された複写は、その信号を受け取ったxmservd の複写を
使用していたかもしれないいかなるデータ消費者につい
ても最初は認識していない。これによって、全てのデー
タ消費者プログラムはそれらのモニタリングを継続する
ために、生産されたデーモンとの再同期化を要求しなけ
ればならない。
【０２３６】xmservd によって認識された他の信号は、
デーモンによってＭＩＢデータをダンプさせる SIGINT
（kill−２（−２を消去））である。
【０２３７】パフォーマンスツール９０のようなデータ
消費者プログラムがデータ提供者ホスト２１８と接触す
るために同報通信を使用する時、恐らく大部分のデータ
消費者プログラムが、応答するほんのわずかのデーモン
によって計器を定義する。これによって大部分のデーモ
ンが多数のデータ消費者によって接触されるだろうが、
ほんのわずかのデータ消費者だけに統計を提供する。こ
れがデーモンにおけるホストテーブルを膨張させ、かつ
大規模なインスタレーションの場合においては、デーモ
ンにおける不必要なロードを誘導し得る。これを阻止す
るために、デーモンはそのサービスに興味がないと思わ
れるデータ消費者を除外しようを試みる。
【０２３８】“time to live”パラメータは非活動状
態のパートナーをチェックするために使用される。デー
タ消費者は、以下の条件のいずれかが真である場合、デ
ーモンのテーブルから除去される。 １． time to live期間の２倍の期間においてパケッ
トがデータ消費者から受け取られないと共にこのデータ
消費者に対して計器が定義されなかった。 ２． time to live期間の８倍の期間においてデータ
消費者からパケットが受け取られなかった。
【０２３９】（以下に記載されている）except recmes
sages に予約されているデータ消費者はあたかもデーモ
ンによって定義された計器を有しているかのように扱わ
れる。
【０２４０】図２７に示されているように、xmservd が
その入力を実行しかつこの入力を一つ以上のデータ消費
者へ供給すると、xmservd はデータ消費者がまだ起動し
ており、かつxmservd の入力を必要としていることを確
認しなければならない。さもなければ、xmservd は、ネ
ットワークを介して統計を伝送し続けるために、システ
ム資源を消耗するであろう。デーモンは、何時がデータ
消費者ホストがまだ生きていることをチェックするため
の時を決定するために、“alive limit （作動限定）”
を使用する。作動限定は、ユーザが、データ消費者ホス
トからの遠隔モニタリング構成を変更する時は必ずリセ
ットされるが、データがデータ消費者へ送られる時はリ
セットされない。
【０２４１】一方、静止状態においては、xmservd デー
モンは、ブロック４５０において、メッセージを受取り
又は“alive limit ”の満了のいづれかを待機する。次
いでブロック４５２においては、要求された動作が、予
め送られたstill alive メッセージに応答したメッセ
ージの受取りであるかどうかを決定するためにチェック
される。そうである場合、作動限定（アライブリミッ
ト）タイマーがブロック４５４でリセットされる。
【０２４２】アライブリミットがブロック４５６に到る
と、xmservd はタイプstill alive のメッセージをブ
ロック４６０でデータ消費者へ送る。データ消費者プロ
グラムは、応答するために“alive limit ”秒を有して
いる。ブロック４５８において決定されるように、“al
ive limit ”秒後に応答が受け取られない場合は、デー
モンは、ブロック４６０において他のstill alive メ
ッセージを伝送し、かつブロック４５０において他の
“alive limit ”秒を待機する。まだ応答がない場合
は、ブロック４６２において、デーモンはデータ消費者
が死んだか、又はもはや対象外であると仮定し、統計を
消費者を送ることを停止する。このデフォルト“alive
limit ”は３００秒（５分）であり、作動限定は、xmse
rvd に対して−ｔのコマンドライン引き数によって設定
され得る。
【０２４３】（後述される）フィルタリングされたプロ
グラムを介して、取られるべき一つ以上の動作を生じ得
る例外的条件が定義され得る。一つのこの様な動作は、
デーモンが実行するホストにおけるコマンドの実行であ
る。他の動作は例外メッセージの伝送である。メッセー
ジタイプexcept rec は後者のために使用される。
【０２４４】各例外メッセージの内容は以下に示されて
いる。 １． 例外メッセージを伝送するホストのホストネー
ム。 ２． 例外が検出された時刻。 ３． ０乃至１０までの数の例外の重大度。 ４． 所与の例外定義から二つの例外メッセージの間の
分の最小数。 ５． 例外を記述するシンボルネーム。 ６． 例外のもっと冗長な記述。
【０２４５】xmservd デーモンは、このデーモンが認識
している全てのホストへ、それらが例外メッセージを受
け取りたいと宣言した例外を送る。（以下に記述され
る）ＡＰＩのRSiOpen 及びRSiInvite 関数の呼び出し
は、データ消費者アプリケーションが例外メッセージを
受け取りたいかどうかを宣言するためにデータ消費者ア
プリケーションによって使用される。
【０２４６】現在、パフォーマンスツールは常に例外メ
ッセージを要求する。一つの例外メッセージが受け取ら
れた時、この例外メッセージはそれがテキストメッセー
ジとして表示されるパフォーマンスツール主要ウィンド
ウへ伝送される。パフォーマンスツールによって他の動
作は行なわれない。
【０２４７】xmservd デーモンが死んだり殺されたりす
ると共に、一つ以上のデータ消費者がこのデーモンによ
って定義された計器を有している場合、デーモンは、フ
ァイル/usr/lpp/xmservd/xmservd. 状態において接続を
記録しようと試みる（xmservd コマンドライン引き数−
ｄが/usr/lppと異なるディレクトリを置き換えるために
使用され得る）。xmservd が後で再スタートされる時に
このファイルが存在する場合は、メッセージタイプ i
am back（戻ります）がファイルに記録されたデータ消
費者ホストの各々へ伝送される。次いでこのファイルは
消去される。
【０２４８】データ消費者として動作するプログラムが
再同期を行うことができる場合、割り込まれたモニタリ
ングは、手動による介入を必要とせずに、速やかに再開
することができる。パフォーマンスモニターは、スター
トアップダイアログとデータ提供者を再交渉させること
によって、 i am backメッセージがそのホストから受
け取られた時は必ず、ホストに対する全てのアクティブ
（活動状態）モニタを再同期させることができる。
【０２４９】データ提供者ホストとデータ消費者ホスト
の間を流れる三つのタイプのメッセージは既に記述され
ている。メッセージタイプはテーブル８に示されている
ように５つのグループに編成されている。 ------------------------------------------------------------------------ 構成メッセージ create stat set タイプ＝０１ del set stat タイプ＝０２ first cx タイプ＝０３ first stat タイプ＝０４ instantiate タイプ＝０５ next cx タイプ＝０６ next stat タイプ＝０７ path add set stat タイプ＝０８ path get cx タイプ＝０９ path get stat タイプ＝１０ stat get path タイプ＝１１ データ送り及び送り制御メッセージ begin feeding タイプ＝３１ change feeding タイプ＝３２ end feeding タイプ＝３３ data feed タイプ＝３４ going down タイプ＝３５ セッション制御メッセージ are you there タイプ＝５１ still alive タイプ＝５２ i am back タイプ＝５３ except rec タイプ＝５４ 状態メッセージ send status タイプ＝８１ host status タイプ＝８２ 動的データ提供者メッセージ get supply タイプ＝９１ ------------------------------------------------------------------------ テーブル８ 遠隔モニタリングのためのメッセージタイプ
【０２５０】全ての構成メッセージ（図２７のブロック
４６８）は、どの統計がデータ提供者によって送られる
べきかについてデータ消費者９０とデータ提供者２１８
の間で交渉されるように指定されている。全てのメッセ
ージは、ブロック４７０（図２７）において応答を要求
し、かつ全てがデータ消費者によって開始される。
【０２５１】一旦どのデータを供給すべきかについての
交渉が完了すると、ブロック４７０（図２７）におい
て、データ提供者ホストのxmservd ２１０は、供給する
ための統計についての情報のセットを保持する。分離セ
ットがデータ消費者プログラムごとに保持される。デー
タの送りは、ブロック４７２において、begin feedin
g メッセージがデータ消費者プログラムから受け取られ
るまで開始されない。begin feeding メッセージがデ
ータ送りの頻度についての情報を含み、かつxmservd デ
ーモン２１０はこの情報を５００ミリ秒の倍数へ丸め、
次いでデータ送りを開始する。
【０２５２】デーモンは、ブロック４７４において、何
時データを送るべきかを決定するためにタイムアウトル
ープを使用する。１セットを超える値が送られる場合
は、xmservd は必要とされる以上のメッセージが同時に
送られるのを阻止するために単純なアルゴリズムを使用
する。データを伝送するために使用されるメッセージタ
イプはdata feedである。
【０２５３】データ消費者へのデータ送りは、ブロック
４８０において、データ消費者がend feeding メッセ
ージを送るまで、又はデータ消費者がstill alive メ
ッセージにもはや応答しなくなるまで、継続される。そ
の時がきたら、ブロック４８２においてデータ送りは停
止する。
【０２５４】データ送りの頻度はブロック４７６におい
てchange feeding メッセージを送ることによってデー
タ消費者プログラムによって変更され得る。このメッセ
ージは、ユーザが計器の間隔特性を変更する時には必ず
伝送され、これにより、ブロック４７８において、デー
モンが、データ値の読み取り及び送りのために間隔を変
更する。
【０２５５】このグループにおける最後のメッセージタ
イプは、going downである。このメッセージは、デー
タ消費者が秩序正しく終了する時、及びＡＰＩ（以下参
照）に書き込まれたプログラムがRSiClose呼び出しを発
生する時にはいつでもデータ消費者によって伝送され
る。このメッセージは、データ消費者が認識している全
てのデータ提供者ホストへ送られ、かつブロック４８４
（図２７）において検出された時に、このメッセージ
は、データ提供者ホスト２０８及び２１８におけるデー
モン２１０をして、終了データ消費者プログラム（図２
７のブロック４８６）についてのすべての情報を消去さ
せる。
【０２５６】このセッション制御メッセージタイプのう
ちの二つは以前のセクションにおいて説明されてきた。
再度捕獲するために、ブロック４６６においてホスト自
体を識別するために、ブロック４６４において潜在的デ
ータ提供者ホストを引き出すように are you there
メッセージはデータ消費者から送られる。still aliv
e メッセージは、データ消費者から入力されずに、xmse
rvd によって開始されるexcept rec から離れた唯一の
メッセージタイプである。このメッセージは遠隔モニタ
に応答を促し、これによってモニタがまだ活動状態であ
ることを証明する。
【０２５７】第３のセッション制御メッセージは、常
に、xmservd がデータ消費者から受け取る第１のメッセ
ージに対する応答である i am backメッセージであ
る。i am backメッセージがデータ消費者ホストのパフ
ォーマンスツールによって受け取られた時、このメッセ
ージは、データ提供者ホストに対して構成テーブルをボ
イド（白抜き）としてマーキングすることによって応答
する。これは データ提供者ホストのデーモンが明らか
に再スタートされたためであり、どの統計を送るべきか
についての初期の交渉が今は無効となっていることを意
味する。
【０２５８】i am backメッセージが遠隔提供者から
受け取られ、その間、この提供者に対する遠隔計器が活
動状態である場合は、この計器に対する再交渉がすぐに
開始される。この提供者に対する他の遠隔計器がデータ
消費者ホストに対して定義される場合、これらの計器に
対する再交渉は各計器が起動される時刻まで遅延され
る。
【０２５９】再交渉は、データ消費者ホスト２０８上の
パフォーマンスツール９０が作動しないかぎりは開始さ
れない。データ提供者ホストが再び放逐され、これによ
ってそのxmservd デーモンが静かに消去することは極め
て可能である。データ消費者はもはやデータを受け取ら
ず、次いで遠隔計器は再生を停止する。現在、どの機能
もこの状態を検出しないが、メニューオプションは、ユ
ーザがデータ提供者によって“resynchronize （再同
期）”するのを可能とする。このオプションが選択され
た時には、are you there メッセージがパフォーマ
ンスツールから送られる。データ提供者デーモンが実行
中又はスタートされ得る場合にはこのデーモンは、i
am backメッセージによって応答し、次いで再交渉が開
始される。
【０２６０】通常は、xmservd はシステムにおいて有効
でないロードだけを誘導する。各々が一つの単一データ
提供者ホストからいくつかの統計をモニタする多数のデ
ータ消費者プログラムの場合は、処理されるべき要求の
絶対数は、データ提供者ホスト上に実行可能ではないロ
ードをデータ提供者ホストに生じ得る。
【０２６１】二つの特徴は、ユーザが、ホストが責任を
有するいかなるホストに対するデーモンをも制御するこ
とを可能とする。第１の特徴は、このセクションにおい
て記述されているように、デーモンの状態をディスプレ
イするための機能である。他の特徴はxmservd デーモン
へのアクセスを制御するための能力である。
【０２６２】xmservd デーモンが、背景において実行さ
れ、かつ必要に応じて開始されたり、停止されたりする
ので、デーモンの状態を決定するには特別の動作が必要
となる。このような動作は二つのメッセージタイプ、se
nd statusとhost statusを介して実行される。第１の
メッセージタイプは、任意のxmservd デーモンへ伝送さ
れ、次いであるxmservd デーモンは、デーモンの活動
（アクティビティ）を総合カウントしたメッセージを戻
すことによって応答し、次いでこのデーモンが認識して
いるデータごとにメッセージタイプhost statusが後に
続く。
【０２６３】xmpeekと呼ばれるユーティリティはパフォ
ーマンスツールの部分として供給される。このユーティ
リティは、ユーザが、そのxmservd デーモンの状態につ
いて任意のホストに問い合わせ、或いはこのホストノー
ドにおいて使用可能である全てのデータ統計のリストを
得ることを可能とする。コマンドラインは単純であり、
かつテーブル９に示されている。
【０２６４】 ------------------------------------------------------------------------ xmpeek ｛−ａ｜−１｝ ホストネーム ------------------------------------------------------------------------ テーブル９
【０２６５】コマンドのフラグは共にオプショナルであ
る。フラグ−ａが指定されるならば、１行がデーモンに
よって認識されているデータ消費者ごとにリストが作成
される。廃棄される場合は、現在、デーモンによって定
義された計器を有するデータ消費者のみがリスト作成さ
れる。
【０２６６】ホストネームが指定される場合、ネーミン
グされたホスト上のデーモンが照会される。ホストネー
ムが指定されない場合、局所ホスト上のデーモンが照会
される。xmpeekプログラムからの出力の例はテーブル１
０に示されている。
【０２６７】
【表２】
【０２６８】xmpeekからの出力は二つの形式をとること
ができる。この出力は、−ａフラグが使用されるか、又
はデータ消費者がデーモンによって定義された少なくと
も一つの計器を有しているかのいづれかの場合には、ホ
ストエキストラ上のデータ消費者に対する詳細単一行だ
けが示されることを除いては、少なくともテーブル１０
に示されているだけの出力を有することができる。xmpe
ekがデーモンと接触するためにＡＰＩを使用するので、
xmpeekそれ自体がデータ消費者として現れることに留意
されたい。これによって、出力は常に少なくとも一つの
認識されているモニタを示す。
【０２６９】固定出力においては、デーモンが実行して
いるホストのネームが最初に示される。次いで、３行が
後に続き、デーモンの現在状態に対する総計を供給す
る。上記の例においては、一つの計器だけが定義され、
しかもアクティブである。さらに、二つのデータ消費者
はデーモンによって認識されるが、データ消費者のうち
の一つだけがｂｉｒｔｅにおけるデーモンによって定義
された計器を有する。明らかに、この出力は−ａフラグ
を付けずに生成された。
【０２７０】より多くのアクティビティの例がテーブル
１１に示されている。この数字は、幾つかの詳細な定義
されたゼロ計器を示すように、コマンドxmpeek−ａ bi
rteによって生成される。この様な行は、are you t
here メッセージがデータ消費者によって受け取られ
が、計器が全く定義されなかったか、或いは前もって定
義されたどの計器も消去されたことを示す。
【０２７１】
【表３】
【０２７２】示されているように、同一ホストネームが
一度を超えて現れることもある。これは、xmperfと全て
の他のアクティブデータ消費者プログラムの全ての実行
複写が、各々がxmpeek出力において示されているように
ＵＤＰパケットに使用されるポート数によって識別され
る、分離したデータ消費者としてカウントされかつ処理
されるからである。
【０２７３】テーブル１１における詳細な第２行は、ho
stumbra 上の一つの特定のモニタが、定義されているが
六個の計器を有し、四つの計器だけがアクティブである
ことを示す。この状況は遠隔コンソールが閉じられた場
合に生じる。データ消費者が閉じられる時、コンソール
はパフォーマンスツールの主要ウィンドウの“monitor
（モニタ）”メニュー内にあり、かつこのコンソールの
計器の定義はデータ提供者デーモンのテーブル内に残留
したままであるが、計器はアクティブではない。
【０２７４】前述したように、xmpeekプログラムは、ユ
ーザが、データ提供者デーモンのアクティビティを見た
り、このホストノードにおいて使用可能な全てのデータ
統計のリストを得るのを可能とする。図２８に関して
は、'1' オプションが選択された場合、xmpeekプログラ
ムは、ブロック４９４において、局所又は遠隔であり得
るデータ提供者デーモンが使用可能な全てのデータ統計
のリストを要求するためにネットワーク送信／受信イン
ターフェースを呼び出す。“host（ホスト）”が指定さ
れない場合、これはデフォルトによる局所ホストであ
る。デーモンが統計のリストを受け取った後には、デー
モンは、ブロック４９６においてこのリストをシステム
の“standard output （標準出力）”へ送る。
【０２７５】−１オプションが選択されなかったなら
ば、xmpeekは、ブロック４９８においてデータ提供者デ
ーモンのアクティビティについてリポートを要求するた
めに、ネットワーク送信／受信インターフェースを呼び
出す。このリポートには、デーモンがデータを提供して
いる全てのアクティブモニタと、デーモンが伝送してい
る多数の計器とが含まれている。xmpeekがこの情報を受
け取った後、xmpeekは、やはりブロック４９８におい
て、テーブルにおいてこのデータをディスプレイする。
【０２７６】xmservd デーモンへのアクセスは、“/usr
/lpp/xmservd/xmservd.res”における構成ファイル内に
スタンザ（stanza）を供給することによって限定され得
る。三つのスタンザが以下に示されている。コロンがス
タンザの一部であることに留意されたい。スタンザは行
の１列において開始されなければならない。スタンザの
タイプごとに一つを超える行が存在し得るが、max:スタ
ンザ（ stanza ）の場合は、最終例がそれより先の例よ
り優先する。ONLY: このスタンザタイプが使用された時には、デーモ
ンへのアクセスはスタンザの後でネーミングされたホス
トに制限される。ホストネームは、ブランク、タブ又は
カンマによって分離されて指定される。only: 行におい
て指定されていない任意のホストからのアクセスは、ar
e you there メッセージが受け取られた時には拒絶
される。一つ以上のonly: 行が指定される場合は、この
ような行において指定されるホストのみがデーモンのデ
ータ検索機能へ到達する。ALWAYS: このスタンザタイプが使用される時、デーモン
へのアクセスはスタンザの後にネーミングされるホスト
へ常に容認される。ホストネームは、ブランク、タブ又
はカンマによって分離されて指定される。この考えは、
たとえアクティブデータ消費者の数が確立された限定数
を超えたとしても、データ消費者のホストから遠隔モニ
タリングを実行する必要があるユーザが実際にアクセス
達成し得ることを確認することである。しかしながら、
only: スタンザも指定されるが、ホストはこの様なスタ
ンザ行内でネーミングされない場合、always: スタンザ
がチェックされる前でもアクセスは拒絶される。alway
s: スタンザが使用される場合、only: スタンザを使用
することを抑制するか、又はalways: 行においてネーミ
ングされた全てのホストもonly: 行内でネーミングされ
るのを確認するかのいづれかである。MAX: このスタンザにはデーモンによっていかなる時でも
計器を定義することが可能とされる同時データ消費者の
数が後に続かなければならない。always: 行内でネーミ
ングされるホストから実行されるいかなるデータ消費者
も、最大数が超過されたかどうかがチェックされる時に
はカウントされない。遠隔コンソールがデータ消費者ホ
ストから開かれた時に通常はアクセスされるが、アクセ
スは計器が定義された時に拒絶される。max: 行が発見されない場合、データ消費者の最大数は省
略値として１６を取る。
【０２７７】テーブル１２はサンプルxmservd 構成ファ
イルを示す。二つのonly: 行は、xmservd デーモンへア
クセスできる合計９個のホストを定義する。他のホスト
は、この構成ファイルによってホスト上のデーモンから
統計量を要求することを許容されない。
【０２７８】二つのalways: 行は、遠隔モニタリングが
常に許容されるべき二つのホストをネーミングする。最
終的に、最大の三つのデータ消費者が一度に計器を定義
することが許容される。パフォーマンスツールがどのホ
ストを実行しようとも、パフォーマンスツールの各複写
は一つのデータ消費者（マルチプロセッシングデータ処
理システムにおいて、このツールの複数のコピーを呼び
出すことが可能なので）としてカウントすることに注目
されたい。 ------------------------------------------------------------------------ only: srv1 srv2 birte umbra xtra jones chris only: savanna rhumba always: birte always: chris max: 3 ------------------------------------------------------------------------ テーブル１２
【０２７９】図２６のネットワーク送信／受信インター
フェース７０とデータ提供者デーモン２１０の間のイン
ターフェース１６２及び２０２（遠隔及び局所インター
フェースは同一メッセージを備えている）が図２９にお
いてさらに示されている。ネットワーク送信／受信イン
ターフェースは、結果的にデーモンからi am back応
答を生じるare you there メッセージを送る。send
statusへの要求はデーモン２１０へ送られ、結果的に
host status応答を生じる。前もって記述されている多
数の構成はxmservd デーモンへ送られ、結果的に応答メ
ッセージを生じる。デーモンへの begin feeding メッ
セージは、ネットワーク送信／受信インターフェースへ
送られる複数のdata feedパケットを生じる。change
feeding及びend feeding メッセージもデーモンによ
って供給されるdata feedを変更したり、停止したりす
るためにデーモンへ送られる。ネットワーク送信／受信
インターフェースからのgoing downメッセージは応答
を要求しない単方向状態メッセージである。最後に、デ
ーモンはインターフェース７０に対して、データ消費者
がまだ活動状態にあることを確認するために応答を求め
るstill alive メッセージを開始することができる。
【０２８０】SNMP多重（SMUX）インターフェース SNMP（単純ネットワークマネージメントプロトコル）
は、インターネットプロトコルに基づくプロトコルであ
る。その名前が示唆するように、その主要目的はコンピ
ュータのネットワークのマネージメントを可能とするプ
ロトコルを提供することにある。SNMPに基づくプログラ
ムは、非ＳＮＡ（システム・ネットワーク・アーキテク
チュア）環境においてネットワークマネージメントアリ
ーナを現在支配している。SNMPベースのネットワークマ
ネージメントプログラムのうち最も広く使用されている
ものは、ヒューレットパッカード社（Hewlett Packard,
Inc. ）のオープンビューパッケージ（Openview packa
ge）におけるプログラムである。ヒューレットパッカー
ド製品のIBM の実践は、IBM ネットビュー（NetView）/
6000 として使用可能である。SNMPプロトコルは、（i）
1989年の４月、J.Case、M.Feder 、M.Schoffstall 、及
びJ.Davin による「コメント要求（Request for Commen
ts(RFC)1098 」と、（ii）1988年の８月、J.Case、M.Fe
der 、M.Schoffstall 、及びJ.Davin によって「単純ネ
ットワークマネージメントプロトコル（The Simple Net
work Management Protocol）」のＲＦＣ（コメント要
求）1067がテネシー大学（ノックスビル（knoxville
））のNYSERNet、Rensselaer Polytechnic、Proteon
において定義されており、どちらも本明細書中に背景的
資料として参照することによって組み込まれている。
【０２８１】ネットワークマネージメントは主としてネ
ットワークにおける資源の利用可能性に関している。SN
MPのトップにおいて実施されるように、ネットワークマ
ネージメントは、ネットワークにおける一つ又は幾つか
のホストが（SNMPマネージャーとして知られている）ク
ライアントプログラムを実行し、かつ（可能ならば）全
てのネットワークノードがサーバコードを実行するクラ
イアント／サーバモデルを使用する。大部分のホストタ
イプにおいては、サーバコードは、通常SNMPエージェン
トとして参照されるsnmpd 、デーモンとして実施され
る。
【０２８２】マネージャー（管理プログラム）とデーモ
ンの間の通信は、二つのプロトコルモデルを使用する。
第１のモデルは全体的に要求／応答タイプのプロトコル
である。他のモデルは、トラップに基づき、これらのト
ラップは、いくつかの事象をクライアントへ知らせるた
めに、サーバ（エージェント）からクライアント（マネ
ジャー）へ送られる非請求パケットである。
【０２８３】要求／応答プロトコルは以下のように木
（ツリー）要求タイプを支援する。 Get: マネージャーからエージェントへ出され、特定変
数の現在値を要求する。その値が使用可能である場合、
エージェントはその値を戻す。 Set: マネージャーからエージェントへ出され、特定変
数の変更を要求する。値の変更が実施されなければなら
ないことも意味するように「含意」によって、エージェ
ントにより値の変更が解釈される。例えば、メモリバッ
ファの数が変更された場合、エージェントはそれが実行
するシステムにおいてこの変更を実行することが予期さ
れる。多数のシステム変数は、セットできないが読み出
し専用変数である。 Get next: マネージャーからエージェントへ出され、エ
ージェントが変数の階層においてさらに１ステップ前進
し、かつ次の変数の値を戻すことを要求する。
【０２８４】“get next”要求タイプによって暗黙に定
義されているように、変数は、xmservd デーモンによっ
て提供された統計を保持するために使用される階層とほ
ぼ類似した階層において構成される。しかしながら、パ
フォーマンスツールコンテクスト階層とは違って、例
え、SNMPマネージャーが、どの変数が使用可能かを見る
ために変数の階層を走査することができたとしても、SN
MPマネージャーは１０進法の符号化（コーディング）シ
ステムによってこれらの変数を識別すると共にこのマネ
ジャー自体によってこれらのコードをテキスト記述へ変
換することはできない。SNMPマネージャーが１０進法の
符号化からテキストへ変換することを可能とさせるため
に、変数と階層を記述するファイルが提供されなければ
ならない。ファイルは、1987年12月の国際標準化8824に
おける国際標準化機構規格（ＩＳＯ）の抽象構文記法１
（ＡＳＮ．１）に対する仕様であるオープンシステム相
互接続（Open System Interconnect）においてＩＳＯに
よって定義され、かつ本明細書中に背景的資料として参
照することによって組み込まれているように、抽象構文
記法１（ＡＳＮ．１）の部分集合内の変数を記述しなけ
ればならない。SNMPによって使用される部分集合はＲＦ
Ｃ（コメント要求）1065において定義されている。変数
の（部分）集合とその階層を記述するファイルは、“Ma
nagement Information Base （マネージメント情報ベー
ス）”即ち“ＭＩＢ”を記述するように指定されるので
ＭＩＢファイルと呼ばれる。ＭＩＢは、1988年８月、K.
マクローリ(MCcloghrie)、及びM.ローズ(Rose)のＴＷ
Ｇ、ＲＦＣ（コメント要求）1066における“Management
Information Base for Network Management of TCP/IP
-basedInternets （TCP/IP−ベースインターネットのネ
ットワークマネージメントに対するマネージメント情報
ベース）”においてさらに述べられており、かつ本明細
書中に参照することによって組み込まれている。
【０２８５】通常は、SNMPエージェントは、どの変数を
SNMPエージェントが提供することとされているかを認識
し、かつ固定セットを使用する。他の状態においては、
SNMPエージェントの変数のセットは、特別なプログラム
又は特別なハードウェアが設置されるので拡張されるこ
とが必要である。これは、1991年５月、ローズ(Rose),
M.T. によって記述されたRFC1227 、“SNMP MUX Protoc
ol and MIB(SNMP多重プロトコル及びMIB ）”と呼ばれ
るインターフェースプログラミングインターフェースに
よって実行され、かつ本明細書中に背景的資料として参
照することによって組み込まれている。SNMPエージェン
トから使用可能な変数のセットを拡張するために、SMUX
がxmservd デーモンによってどのようにして使用され得
るかを以下に記述する。
【０２８６】パフォーマンスプログラムスイート（Suit
e ）の目標は、IBM NetView/6000プログラムの目標とは
非常に異なる。後者は、主として、ネットワーク資源を
使用可能かつアクセス可能であるように保持することを
目標とする監視及び補正動作に関している。一般に、資
源の使用可能性は資源のユーティライゼーション（利
用）よりも重要とされる。例えば、IBM NetView/6000は
ディスクの自由空間の量をトラックするが、本明細書中
に記述されているパフォーマンスツールは物理的ディス
クアクティビティに特に関する。
【０２８７】xmperfプログラムスイートは、主として以
下のことを目標とする資源ユーティライゼーションの連
続的モニタリングに関する。 ・パフォーマンス−重（ヘビー）アプリケーションを識
別し、かつできるだけ改善すること。 ・不十分なシステム資源を識別し、これらの資源のより
多くを提供するために前進すること。 ・将来の許容量計画に対する入力としてロードを予測す
ること。 ・深刻なパフォーマンス犯罪人を識別し、かつ彼らが引
き起こす問題を解決するように処理すること。
【０２８８】二つの製品間のどこかには両方が関連し合
うグレーエリアがある。これは、変数（又は統計）のう
ちのあるものが両方の環境において使用可能でなければ
ならないことを意味する。これは、二つの製品が情報を
共用しないならば、どちらも同じ情報にアクセスし、こ
れによってそれらが共通のアクセスメカニズムを有して
いる場合は除去し得るオーバーヘッドを誘導することを
意味する。
【０２８９】このような共通のアクセスメカニズムは、
xmservd/ＳＭＵＸインターフェースを介して使用可能で
ある。このアクセスメカニズムは、xmservd デーモンが
全てのその統計を読み出し専用（リードオンリー）変数
としてSNMPエージェントヘ提供することを可能とする。
xmservd デーモンインターフェースは、構成ファイル/u
ser/lpp/xmservd/xmservd.res 内に単純スタンザを置く
ことによって呼び出される。トークンはそれ自体の行の
１列で開始され、かつ次でなければならない。
【０２９０】dosmux
【０２９１】dosmuxスタンザが一旦実行されると、xmse
rvd デーモンが使用可能な全ての統計は、局所ホストに
おけるsnmpデーモンによって自動的にレジスタされる。
動的データ提供者（Dynamic Data Supplier ）は統計の
階層へ追加されたり、或いは統計の階層から削除された
りすることができる。動的データ提供者によって誘導さ
れた任意の不揮発性変更もsnmpd デーモンへすぐに連絡
されるが、揮発性変更は例示された時だけsnmpd デーモ
ンによって登録される。
【０２９２】xmservd デーモンは、snmpd へ現在搬送さ
れている全ての変数を記述するＭＩＢファイルを生成す
ることができる。これは、SIGINTが xmservdプロセスへ
送られた時は必ず実行される（−２消去）。MIB ファイ
ルは、ASN.1 表記法において作成され、かつ/usr/lpp/x
mservd/xmservd.mib. 内に置かれる。ファイルのいかな
る古い複写も上書きされる。発生されたMIB ファイルは
IBM NetView/6000によって要求される形式においてファ
イルを生成するためにmosyコマンドによって編集され得
る。次いで、このファイルは、変数に関するテキスト情
報を変換するためにSNMPマネジャーが読み出すいづれの
ファイルにも追加され得る。
【０２９３】SIGINTをxmservd デーモンへ送ることによ
って、MIB ファイルが必要とされる時、全ての関連する
動的データ提供者プログラムが実行され、かつデーモン
によって登録される。さらに、このデーモンによって登
録される少なくとも一つのデータ消費者も存在すべきで
ある。これによって、発生されたMIB ファイルがこのホ
スト内の全ての可能な統計を含むことが確認される。
【０２９４】xmperfコンテクスト階層の改善された特徴
のうちの一つは、複数レベルにおける例示を可能とする
ことである。一つのコンテクストはディスクを定義し、
かつディスクの実数はホストからホストへと変化する。
例示を介して、サブコンテクストが特定のホスト内に存
在するディスクごとに追加される。
【０２９５】SNMPデータ構造も同様の機能即ちテーブル
の定義を可能とする。上記のケースにおいて、テーブル
は“Disks(ディスク) ”であり、かつディスクドライブ
が存在するのと同じ位多くの要素を有し、かつ各要素は
ディスクに対して定義された全てのフィールドを含む。
【０２９６】パフォーマンスツールは、コンテクスト階
層における次レベルにおいて例示を継続することができ
る。例えば、各ディスクはそれらに割り当てられた論理
ボリュームの変数を有し、かつ各々は統計のその一致セ
ットを有する。次いで、論理ボリューム割当てが変化す
るにつれて、例示は、一つのディスクがコンテクスト階
層を調整するのを可能とする。
【０２９７】SNMPはこのようなことを許容しない。テー
ブルは例示され得る唯一のタイプの構造であり、かつテ
ーブルは常に階層内で最低レベルに置かれなければなら
ない。この点において、我々は、パフォーマンスツール
のコンテクスト階層が決して複数レベルで例示しないよ
うに調整した。さもなければ、コンテクスト階層は、複
数レベルで例示しないように調整した。さもなければ、
コンテクスト階層は、SNMPエージェントへエクスポート
（搬送）されない。
【０２９８】パフォーマンスツールと例示のためのＭＩ
Ｂ定義との差によって、この二つのケースにおいて例示
がどのように見えるかを図示することが認可されるよう
に思える。この二つのケースはディスクドライブ統計の
例示をみることによって図示される。
【０２９９】テーブル１３は，コマンドxmpeek−１の出
力からクリッピングされたディスク統計のリストを示
す。各ディスク（この場合、三つ）は定義された四つの
統計を有するのが見られる。対応するコンテクスト構造
はテーブル１４において図形的に示されている。 ------------------------------------------------------------------------ /nchris/Disk/hdisk0/ ディスクhdisk0に対する統計 /nchris/Disk/hdisk0/busy 時刻ディスク使用中（パーセント） /nchris/Disk/hdisk0/xfer ディスクから／ディスクへの転送 /nchris/Disk/hdisk0/rblk ディスクから読取られた512 バイトブロック /nchris/Disk/hdisk0/wblk ディスクへ書き込まれた512 バイトブロック /nchris/Disk/hdisk1/ ディスクhdisk1に対する統計 /nchris/Disk/hdisk1/busy 時刻ディスク使用中（パーセント） /nchris/Disk/hdisk1/xfer ディスクから／ディスクへの転送 /nchris/Disk/hdisk1/rblk ディスクから読取られた512 バイトブロック /nchris/Disk/hdisk1/wblk ディスクへ書き込まれた512 バイトブロック /nchris/Disk/hdisk2/ ディスクhdisk2に対する統計 /nchris/Disk/hdisk2/busy 時刻ディスク使用中（パーセント） /nchris/Disk/hdisk2/xfer ディスクから／ディスクへの転送 /nchris/Disk/hdisk2/rblk ディスクから読取られた512 バイトブロック /nchris/Disk/hdisk2/wblk ディスクへ書き込まれた512 バイトブロック ------------------------------------------------------------------------ テーブル１３ xmperfにおけるディスク例示
【０３００】
【表４】
【０３０１】このコンテクスト構造のＳＮＭＰ概念はい
くらか異なる。この構造がＳＭＵＸインターフェースを
介してxmservd から搬送される時、この構造はＭＩＢテ
ーブルへ変換される。ＭＩＢテーブルを印刷するため
に、以下のコマンド snmpinfo −md −v xmdDisk を用いて、その出力がテーブル１５に示されている。 ------------------------------------------------------------------------ xmdDiskEntryInstName.0＝“ hdisk0 ” xmdDiskEntryInstName.1＝“ hdisk1 ” xmdDiskEntryInstName.2＝“ hdisk2 ” xmdDiskEntryBusy.0＝20943 xmdDiskEntryBusy.1＝679 xmdDiskEntryBusy.2＝386 xmdDiskEntryXfer.0＝11832 xmdDiskEntryXfer.1＝444 xmdDiskEntryXfer.2＝89 xmdDiskEntryRblk.0＝73201 xmdDiskEntryRblk.1＝2967 xmdDiskEntryRblk.2＝6595 xmdDiskEntryWblk.0＝137449 xmdDiskEntryWblk.1＝1585 xmdDiskEntryWblk.2＝105 ------------------------------------------------------------------------ テーブル１５−ディスク例示
【０３０２】示されているように、検索シーケンスが反
転されている。xmperfが、次のディスクへ進む前に、一
つのディスクに対して全ての統計を検索する時、SMUX
は、次の統計へ進む前に、全てのディスクに対して一つ
の統計を読み取ることによって構造を走査する。
【０３０３】例のネーム（この場合はディスクドライブ
のネーム）が、“instance name （例名) ”を意味する
ネームInstNameを常に有する他の人工的タイプの統計と
して、どのように現れるかについても注目されたい。
【０３０４】最後に、パフォーマンスツールのコンテク
スト構造からＭＩＢテーブルへの変換において、人工的
エキストラレベルが挿入される。これは、ＭＩＢ定義シ
ンタックスル（構文）のためである。“path name （パ
スネーム）”におけるエキストラレベルはパフォーマン
スツールコンテクストからの変換への入力（Entry ）へ
常にセットされる。
【０３０５】ディクス統計に対するＭＩＢ定義はテーブ
ル１６に示されている。 ------------------------------------------------------------------------ xmdDisk オブジェクト−タイプ 構文 xmdDisk のシーケンス アクセス アクセスできない 状態 指定 記述 “Disk and CD ROM Statistics（ディスク及びCDROM 統計）” : : ＝｛ xmd 4 ｝ xmdDiskEntry オブジェクト−タイプ 構文 xmdDiskEntry アクセス アクセスできない 状態 指定 記述 “Element of above table（上記テーブルの要素）” : : ＝｛ xmdDisk 1 ｝ xmdDiskEntry : :＝ シーケンス ｛ xmdDiskEntryInstName ディスプレイストリング、 xmdDiskEntryBusy カウンタ、 xmdDiskEntryXfer カウンタ、 xmdDiskEntryRblk カウンタ、 xmdDiskEntryWblk カウンタ ｝ xmdDiskEntryInstName オブジェクト−タイプ 構文 ディスプレイストリング アクセス 読み出し専用 状態 指定 記述 “Instance Name （例名）” : : ＝｛ xmdDiskEntry 1 ｝ xmdDiskEntryBusy オブジェクト−タイプ 構文 カウンタ アクセス 読み出し専用 状態 指定 記述 “Time disk is busy (percent) （時刻ディスク使用中）” : : ＝｛ xmdDiskEntry 2 ｝ xmdDiskEntryXfer オブジェクト−タイプ 構文 カウンタ アクセス 読み出し専用 状態 指定 記述 “Transfer to/from disk （ディスクへの変換及び ディスクからの変換）” : : ＝｛ xmdDiskEntry 3 ｝ xmdDiskEntryRblk オブジェクト−タイプ 構文 カウンタ アクセス 読み出し専用 状態 指定 記述 “512 byte blocks read from disk（ディスクから読み出された 512 バイトブロック）” : : ＝｛ xmdDiskEntry 4 ｝ xmdDiskEntryWblk オブジェクト−タイプ 構文 カウンタ アクセス 読み出し専用 状態 指定 記述 “512 byte blocks written to disk （ディスクへ書き込まれた 512バイトブロック）” : : ＝｛ xmdDiskEntry 5 ｝ ------------------------------------------------------------------------ テーブル１６−ディスク例示に対するＭＩＢ記述
【０３０６】パフォーマンスツールにおいて、コンテク
ストは以下の例示タイプを有するものとして定義され得
る。 SiNoInst たとえ必要とされなくともコンテクス
トは決して例示されない。 SiCfgInst xmservd が開始された時、コンテクス
トが例示される。例示しようとするさらなる試みは明示
的に要求された時のみ実行される。大部分のデータ消費
者プログラムはこのコンテクストタイプ; xmperf does
not.によってコンテクストを例示しようとしない。この
例示タイプを有するコンテクストの例はディスク及びペ
ージ空間である。 SiContInst コンテクストはそれが作成され、かつ
例示が要求された時に例示される。大部分のデータ消費
者プログラムは、このコンテクストタイプ；xmperf doe
s.によってコンテクストを例示しようとする。この例示
タイプを有するコンテクストの分類例はプロセスを定義
するコンテクストである。
【０３０７】ＳＭＵＸを介してコンテクストを搬送する
時には、SiCfgInst 又はSiContInstの例示タイプを有す
るコンテクストはテーブルへ変換される。
【０３０８】動的データ提供者プログラムに関しては、
特別の制約がSiCfgInst 及びSiContInstの使用に適用す
る。但し、ＤＤＳによって定義される不揮発性コンテク
ストの階層のトップに位置するコンテクストに対しては
どちらも使用されない。さらに、揮発性拡張として追加
されるコンテクストに対してもどちらも使用されない。
【０３０９】一般に、例示に対する要求は動的データ提
供者プログラム（ＤＤＳ）へ渡されないので、SiNoInst
だけがＤＤＳプログラムにおいて使用される。SiContIn
stの使用が所望されるならば、SiContInstを有するコン
テクストのサブコンテクストの各々は同一タイプの揮発
性コンテクストである。テーブルとしてＳＭＵＸを介し
て搬送されるべきコンテクストに関しては、サブコンテ
クストの一つの例は、ＤＤＳプログラムの不揮発性コン
テクスト階層の一部として定義されなければならない。
【０３１０】遠隔デーモンへアクセスするためのアプリ
ケーションプログラミングインターフェース データ消費者プログラムは、アプリケーションプログラ
ミングインターフェースの使用によって任意ホストのxm
servd デーモンの統計に完全アクセスすることができ
る。遠隔統計インターフェース（即ちRSi インターフェ
ース）は以下のような機能呼び出しのいくつかのグルー
プからなる。 １． 初期化及び終了 RSiInit RSi 処理のテーブルを割当てるか、又は変更
する。 RSiOpen 遠隔ホストに対するRSi インターフェースを
初期化する。 RSiClose 遠隔ホストに対するRSi インターフェースを
終了し、かつ割り当てられた全てのメモリを解放する。 RSiInvite 各々を識別するためにネットワークにデータ
提供者を勧誘し、かつデータ提供者ホストネームのテー
ブルを戻す。 ２． 初期化及びコンテクスト階層の走査 RSiInstantiate コンテクストオブジェクトの全てのサ
ブコンテクストを作成（例示）する。 RSiPathGetCx コンテクストパスネームと一致するコ
ンテクストに対するコンテクスト階層を探索する。 RSiFirstCx コンテクストの第１のサブコンテクス
トを戻す。 RSiNextCx コンテクストの次のサブコンテクスト
を戻す。 RSiFirstStat コンテクストの第１の統計を戻す。 RSiNextStat コンテクストの次の統計を戻す。 ３． 受信統計のセットを定義する RSiCreateStatSet 空StatSet を作成する。 RSiPathAddSetStat 単一統計をStatSet へ追加す
る。 RSiAddAndInst 所与の統計のコンテクストを例
示し、かつその統計をStatSet へ追加する。 RSiDelSetStat StatSet から単一統計を消去す
る。 RSiStatGetPath StatValsポインタによって識別
された統計の完全なパスネームを見つける。 ４． データ送りの開始、変更、及び停止 RSiStartFeed StatSet に対するデータ送り伝
送を開始するようにxmservd へ告げる。 RSiChangeFeed StatSet に対するデータ送り伝
送間の時間間隔を変更するようにxmservd へ告げる。 RSiStopFeed StatSet に対するデータ送り伝
送を停止するようにxmservd へ告げる。 ５． データ送りパケットの受信及び復号化 RSiMainLoop アプリケーションが実行を延期
し、かつデータ送りが到着した時に目覚めるのを待機す
ることを可能とする。 RSiGetValue データ送りパケットからの抽出
するによって、所与のStatValsポインタに対するデータ
値を戻す。 RSiGetRawValue データ送りパケットからの抽出
によって、所与のStatValsポインタに対する有効StatVa
ls構造へポインタを戻す。
【０３１１】以下のセクションはインターフェースデー
タ構造を説明すると共に、ライブラリ関数といくつかの
重要なデザインコンセプトとの属性共有を導入する。
【０３１２】RSi インターフェースは、遠隔ホストの統
計の現在ビュー、及びデータ消費者プログラムと遠隔ホ
ストのxmservd デーモン２１０の間の対話の状態を記述
する制御ブロック（又はデータ構造）に基づく。要求デ
ータ構造は以下に示される。 RSi handle（ハンドル）− RSi ハンドルはタイプRSi
HandleStructのデータ構造へのポインタである。あらゆ
る他のRSi 呼び出しを使用する前に、データ消費者プロ
グラムは、RSi ハンドルのテーブルを割り当てるために
RSi Init呼び出しを使用しなければならない。テーブル
からのRSi ハンドルは、ホストへの論理接続が開かれる
時に初期化される。RSi ハンドルは、同一ホストへの全
ての順次機能呼び出しにおいて引き数として指定されな
ければならない。RSi ハンドルの内部フィールドの内の
一つだけがデータ消費者プログラムによって使用され
る。即ち、受け取られたネットワークパケット、ｐｉの
ポインタである。非常に特殊なケースにおいてのみ、こ
のポインタが使用する必要があるが、このポインタはRS
i Open（オープン）によって初期化され、かつ決してデ
ータ消費者プログラムによって変更されることはない。
RSi ハンドルは、/usr/lpp/xmservd/API/xmip.hにおい
て定義される。 StatVals− 単一データ値は、構造StatValsとして/usr
/lpp/xmservd/API/Sdidef.h において定義される構造に
よって示される。この構造において定義されているポイ
ンタのいづれもデータ消費者プログラムにおいて有効で
ないことが認識されるべきである。ポインタを使用する
時の試行は通常セグメントフォールトを生成する。最後
の三つのフィールドだけがデータ消費者プログラムによ
って安全に使用され得る。これらのフィールドは、 val 統計データフィールドの最新の実際の内容。 val change 統計データフィールドの最新の実際の内
容と、監視された先行値の差（デルタ値）。 error （エラー） enum Error in によって定義された
エラーコードは、ファイル/usr/lpp/xmservd/API/Sdide
f.h を含む。二つの値のフィールドは、実データフィー
ルドが対応するStat構造内のフラグによってロングか又
は浮動しているかを意味するユニオン値として定義され
ることに留意されたい。Stat構造はStatVals構造から直
接アクセスされない（ポインタはすでに述べたように無
効である。）従って、val 及びval changeフィールド
におけるデータタイプを決定するためには、RSiPathAdd
SetStat 関数呼び出しによって戻された時に、ユーザは
Stat構造を保管すべきであった。これはかなりぎこちな
いなので、関数呼び出しRSiGetValue がユーザの代わり
に全てを行なってくれる。従って、ユーザはStat構造を
トラックすることを心配する必要はない。 Stat− これは統計値を記述するためのデータ構造であ
る。これはタイプstructStatの/usr/lpp/xmservd/API/S
didef.h において定義される。このデータ構造から情報
が必要とされる（関数RSiStatGetPathによって戻された
情報とは無関係に）場合、データはRSiPathAddSetStat
関数呼び出しによって戻される時に保管されるべきであ
る。ポインタ get fun がデータ消費者プログラムにお
いて全く意味をもたないことに留意されたい。 RSiGetRawValue関数呼び出しは、Stat構造へのアクセス
を得る他の方法を提供するが、これはデータ送りパケッ
トが処理されている時のみに行なわれる。 StatSe− xmservd デーモンは、同時に抽出され、かつ
単一データパケット内のデータ消費者プログラムへ送ら
れる統計のセットの定義を受容する。このような統計の
セットを記述する構造は、タイプstructStatSet に関す
る/usr/lpp/xmservd/API/Sdidef.h において定義され
る。RSiCreateStatSet関数呼び出しによって戻される
時、StatSet ポインタは、唯一の目的がいくつかの他の
関数（機能）呼び出しにおける統計の正確なセットを識
別することであるハンドルとして取り扱われるべきであ
る。データ送りパケットにおいて戻される時は、StatSe
t 構造は、データ送りパッケージが作成された（遠隔ホ
ストのクロックによる）実時間と、同じStatSet に対す
る最新の先行データ送りパッケージが作成されてからの
経過時間とを保持する。両ケースにおいて、この構造に
おけるポインタはデータ消費者プログラムに対して無効
である。
【０３１３】RSi インターフェースAPI は二つの明確に
異なる操作方法を有する。このセクションは、xmservd
へ単一要求を伝送し、かつ応答を待機する「要求−応答
（request-response) 」プロトコルにおいて記述する。
指定された時間制限内に応答が受け取られなかった場合
はタイムアウトが生じ、この場合一つの単一再試行が行
なわれる。再試行もやはりタイムアウトを生じた場合に
は、それが、外部整数フィールドRSIErrnoに定数 RSiTi
meout を置くことによって発呼者へ連絡される。いかな
る他のエラーが生じた場合も、外部整数フィールドはい
くつかの他の非ゼロ値を有する。
【０３１４】通信エラーもタイムアウトも生じない場
合、パケットは、SDi ハンドルにおけるpiポインタによ
ってポイントされた受信バッファにおいて使用可能であ
る。パケットは関数呼び出しがxmservd サイドにおいて
成功したか否かを知らせる状態コードを含む。悪い状態
コードが受け取られたことをデータ消費者プログラムへ
示すため、定数RSiBadStatがRSiErrno内に配置されるの
で、パケットにおける状態コードのチェックは、コード
が正確にどれかを問題とする場合にのみ必要とされる。
【０３１５】各関数呼び出しに対して定義されるよう
に、エラー又は成功の表示は、関数呼び出しが成功した
か又は外部整数RSiErrnoがテストされ得るかどうかを決
定するために使用される。このフィールドがRSiOkay で
あるならば、関数呼び出しが成功したのであり、さもな
ければ、関数呼び出しは成功していない。RSiErrnoへ戻
されたエラーコードはenum RSiErroeType 内に定義され
る。 RSiErroeType 定義は以下のように定義される。
【０３１６】RSiOkay ＝０：首尾よく実行された関数呼
び出し。 RSiTimeout ：再試行後、データ提供者から応答なし。
【０３１７】RSiBusy ：オープン状態のRSi RSiSendErr ：ソケットアドレスへ送られた又は送られ
なかったショートパッケージ。
【０３１８】RSiPollErr ：ポール上のエラー又は呼び
出し選択。 RSiRecvErr ：ソケットアドレスからデータを受け取る
ための呼び出しにおけるエラー。
【０３１９】RSiSizeErr ：受け取られたショートパッ
ケージ RSiResync ：データが再同期要求を提供。
【０３２０】RSiBadStat ：エラー状態コードを有する
パケットの受け取り。 RSiBadArg ：RSi * 呼び出しに対して無効な引き数。
【０３２１】RSiBadHost ：ホストに対するインターネ
ットアドレスを変換又は発見できない。
【０３２２】RSiDupHost ：ホストネームを複製。 RSiSockErr ：ソケットのオープン又は準備におけるエ
ラー。
【０３２３】RSiNoPort ：getservbyname callにおけ
るエラー。 RSiNoMatch ：アクティブコンソールへStatval 又はSt
atset をマッピングできない。
【０３２４】RSiInstErr ：データ提供者によってオブ
ジェクトを例示できない。 RSiNoFeed ：データ送り記録なし。
【０３２５】RSiTooMany ：ネットワークパケットに対
する統計の最大数を超過した。 RSiNoMem ：RSiHandle テーブルに対するメモリ不
足。
【０３２６】RSiNotInit ：RSiInit を介して例示され
ないインターフェース。
【０３２７】全てのライブラリ関数（図８の参照数１６
１）は、（ネットワーク駆動インターフェースを使用す
る）RSiMainLoop 、並びに（ネットワークトラフィック
を組み込まない）RSiInit 、RSiGetValue 、及びRSiGet
RawValueを除いて、要求−応答インターフェースを使用
する。
【０３２８】xmquery プロトコルは、要求パケットによ
って請求されることなくデータ提供者サイド（xmservd
）から送られる三つのタイプのデータパケット定義す
る。これらのパケットタイプは、still alive 、data
feed 、except recパケットである。still aliv
e パケットはRSi インターフェース１６０において内部
的に処理され、かつデータ消費者プログラムにおいてプ
ログラミングを必要としない。
【０３２９】data feed パケットは、要求−応答タイ
プの関数呼び出しによって生成されるいかなるパケット
と非同期的に受け取られる。data feed （データ送
り）パケットが要求−応答関数を処理する時に受け取ら
れた場合には、制御は、RSiOpen 関数呼び出しによって
RSi ハンドルが作成される時にネーミングされなければ
ならないコールバック（呼び戻し）関数へ渡される。
【０３３０】データ消費者プログラムが要求−応答関数
を使用していない時には、このプログラムは、data f
eed パケットを受け取りかつ処理できることを必要とす
る。これは、パケットが受け取られた時は必ずコールバ
ック関数を呼び出すRSiMainLoop 関数によって達成され
る。
【０３３１】実際に、データ送りコールバック関数は、
このようなパケットが i am back、still alive
、又はexcept rec などのタイプである場合を除い
て、送られた最新の要求への応答として識別されること
ができない全ての受け取られたパケットに対して呼び出
される。タイムアウト後に到着する「要求−応答」パケ
ットに対する応答がコールバック関数へ送られることに
注目されたい。それは、受け取られたパッケージタイプ
をテストするためのコールバック関数の責務である。
【０３３２】except rec パケットは、要求−応答タイ
プ関数呼び出しによって生成されたいかなるパケットと
非同期的に受け取られる。except rec パケットが要求
−応答関数を処理する時に受け取られた場合は、制御
は、RSiOpen 関数呼び出しによって、RSi ハンドルが作
成される時にネーミングされなければならないコールバ
ック（呼び戻し）関数へ渡される。
【０３３３】データ消費者プログラムが要求−応答関数
を使用していない時、データ消費者プログラムはexcept
rec パケットを受け取りかつ処理できることも必要で
ある。これは、パケットが受け取られた時に必ず、呼び
出し関数を呼び出すRSiMainLoop 関数によって達成され
る。
【０３３４】メッセージタイプを処理するためのコール
バック関数が、RSiOpen 関数呼び出しにおいて指定され
なかった場合、データ消費者プログラムがexcept rec
メッセージを廃棄することに注目されたい。
【０３３５】ネットワーク接続が悪くなり、ホストが下
降し、インターフェースが壊され、かつプロセスが消去
される。この状態は、全てのネットワークベースのプロ
グラムにおいて余分な複雑性を誘導する。xmservd プロ
トコルにおいては、このような状態は、通常は以下のう
ち一つ以上の結果を生じる。
【０３３６】パケット紛失 未解決の要求に対する応答は受け取られず、従ってタイ
ムアウトを生じる。データ消費者プログラムがいずれに
しろ他のエラーリターンコードを処理しなければならな
いので、タイムアウトはかなり処理しやすい。さらに、
タイムアウトによって、予期されたデータ送りが受け取
られないことになる。この状態を処理するための適切な
方法は、消去されたホストに関連する全てのメモリを解
放し、かつRSihandle を解放するためにRSiClose関数を
使用することである。このRSihandle が解放された後、
データ消費者プログラムは遠隔システムに対して他のRS
iOpen を試みるか、又は単に遠隔システムを出る。
【０３３７】要求の再同期化 xmservd デーモンが、所与のホストにおいて所与のデー
タ消費者プログラムから最初に情報を得る時は必ず、xm
servd デーモンは、タイプ i am backのパケットによ
って応答し、これによってデーモンと再同期をとるため
にデータ消費者プログラムを効率的に促進する。さら
に、デーモンが削除又消滅した時にデーモンが対話した
データ消費者プログラムと再同期をとろうと試行する
時、デーモンは i am backパケットを送信する。いく
つかの他の状態が存在しており、すべてがxmservd デー
モンによって検出される内部エラーを含み、xmservd デ
ーモンはやはり i am backパケットを発生するが、こ
れらの状態は滅多に生じないので、確実に無視され得
る。
【０３３８】しかしながら、「最初に接触した」xmserv
d の概念を理解することは重要である。これは、デーモ
ンの内部のテーブルに基づく。これらのテーブルはデー
モンが知っている全てのデータ消費者を識別する。デー
タ消費者プログラムは、デーモンと対話するために使用
されるＩＰポート数によって後置され、データ消費者プ
ログラムが実行するホストのホストネームによって認識
されることを理解されたい。各データ消費者プログラム
の実行は、同じデータ消費者プログラムのいくつかの実
行複写を行なうように、独特に識別される。
【０３３９】データ消費者プログラムが規則正しく終了
する時は必ず、このデータ消費者プログラムは、このプ
ログラムが終了しようとする意思を伝え、かつデーモン
は内部テーブルから消費者を除去する。しかしながら、
データ消費者プログラムがある時、デーモンからデータ
送りを要求しないことを決定した場合は、デーモンはデ
ータ消費者が興味を失い、かつデータ消費者をそのテー
ブルから除去することを検出する。その後でデータ消費
者プログラムがxmservd と再び対話したいことを決定す
るならば、デーモンは i am backパケットによって応
答する。
【０３４０】i am backパケットはRSi インターフェ
ースによって特別な処理が提供される。一つのパケット
が受け取られる度に、コールバック関数が呼び出され
る。この関数は、RSiOpen 関数呼び出しにおいて定義さ
れなければならない。
【０３４１】遠隔xmservd がデータ消費者を認識してい
ないので、RSiOpen 関数呼び出しの実行中、全てのデー
タ消費者プログラムが一度はこのコールバックを呼び出
させることを期待することができることに注目された
い。これは正常であり、データ消費者プログラムをパニ
ック状態にはさせない。RSiOpen 関数の処理中、再同期
コールバックが二回呼び出される場合、オープン実行は
失敗し、かつ適している場合は再試行される。
【０３４２】API の使用は、遠隔ホストからの統計の継
続リストを生成するために小型のデータ消費者プログラ
ムを作成することによって図示されている。第１のバー
ジョンは、ＣＰＵ関連の統計のみをアクセスする。それ
は、ユーザがコマンドライン上でホストネームを指定し
ない場合、統計が局所ホストから送られるものと仮定す
る。このプログラムは、消去されるまで、継続して統計
をディスプレイする。サンプルプログラムに対する資源
コードは付録Ａに示されている。
【０３４３】xmservd デーモンとの関係を初期化しかつ
終了させるために使用される関数は、テーブル１７、１
８、及び１９に示されている。他の任意の呼び出しが実
行される前には、プログラムはRSiInit 呼び出しを出さ
なければならない。呼び出しの目的は以下に示されてい
る。 １． RSiHandleStruct 構造の配列を割当て、データ消
費者プログラムへこの配列のアドレスを戻すか、或い
は、 ２． RSiHandleStruct 構造の前もって割り当てられた
配列の寸法を大きくし、かつ前の一つの配列の内容によ
って新たな配列を初期化すること。 ------------------------------------------------------------------------ RSiHandle RSiInit（int count ） ------------------------------------------------------------------------ テーブル１７
【０３４４】達成された場合、関数は割り当てられた配
列のアドレスを戻す。エラーが生じた場合は、エラーテ
キストが、外部文字配列 RSiEMsg内に配置され、かつ関
数はヌル（空文字）を戻す。前に割り当てられた配列の
大きさを増すために使用された時には、この関数は、最
初に新しい配列を割当て、次いで古い配列全体を新しい
部分へ移動させる。アプリケーションプログラムは、そ
れらが配列を拡張することを期待する場合は、アドレス
によるよりむしろインデックスによって、 RSiハンドル
配列内の要素を参照する。データ消費者プログラムが対
話する遠隔ホストの数がプログラムの寿命を通して増加
し得るならば、この配列は拡張される必要がある。
【０３４５】RSiInitを繰り返し呼び出すアプリケーシ
ョンは、RSiInit 呼び出しが再実行されている間、RSiH
andle 配列の前のアドレスを保存する必要がある。この
呼び出しが首尾よく完了した後には、呼び出しプログラ
ムは、フリーサブルーチンを用いて前の配列をフリーに
する。
【０３４６】関数への引き数は、 count RSi ハンドルの配列における要素の数を
指定しなければならない。呼出しが前に割り当てられた
配列を拡張するために使用される場合は、この引き数は
配列要素の現在数よりも大きくなければならない。それ
は常にゼロより大きくなければならない。アレイ（配
列）の大きさは、いつの時点においてもデータ消費者プ
ログラムが対話できるホストの数と少なくとも同数であ
るように指定される。
【０３４７】テーブル１８に関しては、RSiOpen 関数と
呼ばれるライブラリ関数の目的は、以下に示されてい
る。 １． 特定のホストにおける認識されているデータ消費
者としてデータ消費者プログラムを確立すること。これ
は、ホストへare you there パケットを送ることに
よって実行される。 ２． データ消費者プログラムによる次の使用に対して
RSi ハンドルを初期化すること。 ------------------------------------------------------------------------ int RSiOpen (RSiHandle rhandle, int wait, int bufsize, char *hostname, int ( * feed callb)( ), int ( * resy callb)( ), int ( * excp callb)( )) ------------------------------------------------------------------------ テーブル１８−RSiOpen 関数呼び出し
【０３４８】達成された場合、関数はゼロを戻し、かつ
rhandle によって指し示されたタイプRSiHandle の領域
を初期化する。エラーが生じた場合、エラーテキストは
外部文字配列RSiEMsg 内に配置され、かつこの関数は負
の値を戻す。
【０３４９】この関数に対する引き数は、以下のように
示されている。 rhandle 前のRSiInit 呼び出しによって戻
されるRSiHandleStruct配列の要素を指し示さなくては
ならない。この関数が成功した場合、この構造は初期化
され、次のRSi インターフェース関数呼び出しのための
ハンドルとして使用する準備ができる。 wait RSi インターフェースが要求−応
答関数を使用した時の応答を待機するミリ秒におけるタ
イムアウトを指定しなければならない。ＬＡＮにおいて
は、この引き数に対するリーズナブルな値は１００ミリ
秒である。指定された待機時間以後に応答が受け取られ
ない場合は、ライブラリ関数１６１は、タイムアウト表
示を戻す前に待機時間の５倍が経過するまで受け取り動
作を再試行する。待機時間はゼロより上のミリ秒であ
る。 bufsize ネットワークパケットを構築する
ために使用される最大バッファサイズを指定する。この
サイズは一般的に少なくとも2,048 バイトである。バッ
ファサイズはデータ消費者プログラムによって受け取ら
れ得る最大パケット長さを決定し、次いで一つのdata
feedパケットにおいて受け取られ得るデータ値の数に対
して制限を設定する。両者はパケットを取り扱うことが
可能でなければならないので、xmservd デーモンのバッ
ファサイズよりも大きなバッファサイズを設定すること
にポイントはない。値のより大きなセットが必要とされ
るならば、コマンドラインのxmservd に対する引き数−
ｂは、そのバッファサイズを16,384バイトまで大きくす
るために使用され得る。data feedパケットの固定部分
は１０４バイトであり、かつ各値は３２バイトを取る。
従って、2,048 バイトのバッファサイズはパケット当た
り６０までの値を可能とする。 hostname xmservdデーモンが接触される遠
隔ホストの識別を含む文字配列でなくてはならない。
（第１の白の空間に到る迄の）ホスト識別の最初の「ワ
ード」はホストネームとして使用される。完全なホスト
識別はRSiHandle フィールドロングネームにおいて記憶
され、かつエンドユーザが、使用されているホストを識
別するのを補助するいかなる記述をも含み得る。ホスト
ネームはロングフォーマット（ドメインネームを含む）
又はショートフォーマットのいづれであってもよい。 feed callb xmservdデーモンからdata feed
パケットが受け取られた時、このdata feedパケットを
処理する関数のポインタでなくてはならない。このコー
ルバック関数が呼び出された時、以下に記述されるよう
に、この関数には三つの引き数が渡される。 resy callb xmservdデーモンから受け取られ
る時に、i am backパケットを処理する関数のポイン
タでなくてはならない。このコールバック関数が呼び出
された時、以下に記述されるように、この関数には三つ
の引き数が渡される。 excp callb except rec パケットがxmserv
d デーモンから受け取られた時、except rec パケット
を処理する関数のヌル（NULL）又はポインタでなければ
ならない。ヌルポインタが渡された場合、アプリケーシ
ョンはexcept rec メッセージを受け取らない。このコ
ールバック関数が呼び出された時、以下の示されている
ようにこの関数には三つの引き数が渡される。この引き
数は任意の前のRSiInvite 又はRSiOpen 呼び出しの対応
する引き数を常にオーバライドし、かつそれ自体が引き
続くいづれかの実行によってオーバライドされ得る。こ
のように、モニタリングアプリケーションは例外のモニ
タリングをターンオン及びターンオフすることができ
る。前のオープン呼び出しによって指定される例外処理
をオーバライドするためのRSiOpen 呼び出しに対して
は、接続は、最初にRSiClose呼び出しによって閉じられ
なければならない。
【０３５０】アプリケーションにおけるfeed callb 、
resy callb 、及びexcp callb 関数が以下の三つの引
き数によって呼び出される。 １． RSiHandle。 data feedパケットが受け取られ
た時、この構造はパケットを送るホストを示すように保
証される。全ての他の構造においては、RSiHandle 構造
はアプリケーションが対話するホストのいづれも表示し
得る。 ２． 受け取られたパケットを含む入力バッファに対す
るタイプパック* のポインタ。RSiHandle 構造のポイン
タではなくこのポインタが使用される。 ３． 親ホストのインターネットアドレスのタイプstru
ct sockaddr in* のポインタ。
【０３５１】テーブル１９に示されているようにライブ
ラリ関数RSiCloseは以下の責務を負う。
【０３５２】１． 特定のホストにおける認識されてい
るデータ消費者としてデータ消費者プログラムを除去す
ること。これはホストに対するgoing downパケットを
送ることによって行なわれる。
【０３５３】２． RSiHandle をアクティブでないとし
てマーキングすること。 ３． RSiHandle に関して割り当てられた全てのメモリ
を解放すること。 ------------------------------------------------------------------------ void RSiClose （RSHandle rhandle） ------------------------------------------------------------------------ テーブル１９ RSIClose 関数呼び出し
【０３５４】関数は戻し値を有さない。この関数に対す
る引き数は以下に示される。 rhandle RSiOpen 関数によって前もって
初期化されたRSiHandleでなければならない。
【０３５５】マクロRSiIsOpen が RSi handle がオープ
ンか否かをテストするために使用され得る。この関数は
引き数としてRSiHandle を取り、かつハンドルがオープ
ンである場合、TRUE(1) を戻し、そうでない場合はFALS
E(0)となる。
【０３５６】サンプルプログラムの主要機能はテーブル
２０に示されているように、上記の三つの関数を使用す
る。１２〜１５までの行はuname 関数によって得られた
デフォルトホストネームをオーバライドするために任意
のコマンドライン引き数を使用する。
【０３５７】
【表５】
【０３５８】行１７〜行２８はRSiInit 及びRSiOpen 関
数を用いてRSi インターフェースを初期化する。初期化
を失敗した場合はプログラムが終了することに留意され
たい。
【０３５９】以下の行（２９−３２）は、プログラム
が、プログラムを消去又は終了するためのいかなる試み
をも検出することを確認する。これが生じた場合、関数
must exitが呼び出される。この関数は、xmservd デーモ
ンとの協働が終了することを確認する単一目的を有す
る。終了は、テーブル２１に示されている関数を用いて
これを実行する。 ------------------------------------------------------------------------ void must exit（ ） ｛ RSiClose （rsh ）; exit （−９） ｛ ------------------------------------------------------------------------ テーブル２１−データ消費者信号処理
【０３６０】最終的に、テーブル２０の行３４〜行３６
はデータ消費者プログラムの主要処理ループのための初
期値パスネームを準備する。これは全ての値のパスネー
ムが準備される一つの方法である。次に、内部関数１st
stats における主要処理ループが呼び出される。奇数に
対して、この関数が戻る場合は、RSiClose呼び出しが出
され、プログラムが終了する。
【０３６１】このサンプルデータ消費者プログラムがデ
ータ送りをxmservd デーモンから受け取ることができる
ことを意図するので、StatSet は統計のセットを定義す
るために提供される。これはテーブル２２に示されてい
るRSiCreateStatSet関数によって実行されるべきであ
る。この関数は単純に以下のようになる。 １． StatSet構造を割り当てる。 ２．空の StatSetとして構造を初期化する。 ------------------------------------------------------------------------ struct StatSet * RSiCreateStatSet( RSiHandle rhandle) ------------------------------------------------------------------------ テーブル２２−RSiCreateStatSet関数呼び出し
【０３６２】達成されたならば、関数は作成された Sta
tSetへポインタを戻す。エラーが生じた場合は、関数は
ヌルを戻し、かつエラーテキストが外部文字配列RSiEMs
g 内に置かれる。
【０３６３】関数に対する引き数は、以下に示される。 rhandle RSiOpen関数によって先に初期化
されたRSiHandle でなければならない。
【０３６４】このサンプルプログラムにおいては、Stat
Set はテーブル２４に示されている主要処理関数におい
て作成される。
【０３６５】テーブル２４における行１２〜行１９は、
局所関数addstat を呼び出し、かつこの局所関数は、コ
ンテクスト階層内の全てのCPU に関する統計を見つけ、
かつこの情報を収集及びプリントするために配列を初期
化する。最初の２行は、CPUを追加することによって関
数へパスされた値のパスネームを拡張する。この結果生
じたストリングは、全てのCPU 関連統計が保持されるコ
ンテクストのパスネームである。パスネームは、引き数
として値のパスネームを取る関数呼び出しによって予期
されるものである終了スラッシュを用いずに、フォーマ
ットhosts/hostname/CPUを有する。関数addSetはテーブ
ル２７に示されている。この関数はCPU関連統計をアク
セスするための走査関数のうちの三つを使用する。第１
の関数呼び出しはRSiPathGetCx（テーブル１９）であ
り、その目的は以下に示されている。 １． コンテクストの所与のパスネームに対するコンテ
クスト階層を探索すること。 ２． このコンテクストを引続き参照する時に使用され
るためにハンドルを戻すこと。 ------------------------------------------------------------------------ cx handle * RSiPathGetCx( RSiHandle rhandle, char *path ) ------------------------------------------------------------------------ テーブル２３−RSiPathGetCx関数呼び出し
【０３６６】達成されたならば、関数は、タイプstruct
cx handleへポインタとして定義されたハンドルを戻
す。エラーが生じたならば、ヌルは戻され、かつエラー
テキストが外部文字配列RSiEMsg 内に置かれる。
【０３６７】関数に対する引き数は以下のように示され
る。 rhandle RSiOpen関数によって先に初期化さ
れたRSiHandle でなければならない。 path ハンドルが戻されるべきコンテク
ストのパスネーム。コンテクストパスネームは完全なパ
スネームでなければならず、終了スラッシュを含んでは
ならない。コンテクストパスネームが決してスラッシュ
から開始されないことに留意されたい。
【０３６８】サンプルプログラムによるRSiPathGetCxの
使用はテーブル２７における行８〜行１２において示さ
れている。次に、行１４〜行３０においては、二つの関
数呼び出しがCPU コンテクストに対して定義される統計
値を検索する。これはRSiFirstStatとRSiNextStat を用
いることによって実行される。これらの関数はテーブル
２５及びテーブル２６において記述されている。
【０３６９】
【表６】
【０３７０】RSiFirstStat関数（テーブル２５）の目的
は以下に示されている。 １． 第２の引き数によって識別されたコンテクストが
存在することを検査すること。 ２． このコンテクストに対して定義された統計のリス
トの最初の要素へハンドルを戻すこと。 ３． 統計のショートネーム及び記述を戻すこと。 ------------------------------------------------------------------------ struct StatLink *RSiFirstStat（RSiHandle rhandle, cx handle* context, char **name, char **descr ） ------------------------------------------------------------------------ テーブル２５−RSiFirstStat関数呼び出し
【０３７１】達成されたならば、関数はポインタをタイ
プstructStatLinkの構造へ戻す。エラーが生じたなら
ば、ヌルが戻され、かつエラーテキストが外部文字配列
RSiEMsg 内に置かれる。
【０３７２】関数に対する引き数は以下のように示され
る。 rhandle RSiOpen関数によって先に初期化さ
れたRSiHandle でなければならない。 context 成功したRSiPathGetCx関数呼び出し
によって前に戻されたタイプcx handleのハンドルでな
ければならない。 name 文字配列に対するポインタのポイン
タでなければならない。このポインタは文字配列ポイン
タにおけるポイントへ初期化されなければならない。関
数呼び出しが達成された時、統計値のショートネームが
文字配列ポインタに戻される。 descr 文字配列に対するポインタのポイン
タでなければならない。このポインタは文字配列ポイン
タにおけるポイントへ初期化されなければならない。関
数呼び出しが成功した場合、統計値の記述は文字配列ポ
インタに戻される。
【０３７３】RSiNextStat 関数（テーブル２６）の目的
は以下に示されている。 １． 第２の引き数によって識別されたコンテクストが
存在することを検査すること。 ２． このコンテクストに対して定義された統計のリス
トの次の要素のハンドルを戻すこと。 ３． 統計のショートネーム及び記述を戻すこと。 ------------------------------------------------------------------------ struct StatLink *RSiNextStat （RSiHandle rhandle, cx handle *context, struct StatLink *link, char **name char **descr ） ------------------------------------------------------------------------ テーブル２６−RSiNextStat 関数呼び出し
【０３７４】成功した場合、関数はポインタをタイプst
ruct StatLink の構造へポインタを戻す。エラーが生じ
たならば、ヌルは戻され、かつエラーテキストが外部文
字配列RSiEMsg 内に置かれる。
【０３７５】関数に対する引き数は以下のように示され
る。 rhandle RSiOpen関数によって先に初期化さ
れたRSiHandle でなければならない。 context 有効なRSiPathGetCx関数呼び出しに
よって先に戻されたタイプcx handleのハンドルでなけ
ればならない。 link 成功したRSiFirstStat又はRSiNextS
tat 関数呼び出しによって先に戻されたタイプstructSt
atLinkの構造のポインタ。 name 文字配列に対するポインタのポイン
タでなければならない。このポインタは文字配列ポイン
タにおけるポイントへ初期化されなければならない。関
数呼び出しが成功した場合、統計値のショートネームが
文字配列ポインタに戻される。 descr 文字配列に対するポインタのポイン
タでなければならない。このポインタは文字配列ポイン
タにおけるポイントへ初期化されなければならない。関
数呼び出しが達成された時、統計値の記述は文字配列ポ
インタに戻される。
【０３７６】テーブル２７における行２０〜２１におい
ては、コンテクスト（“CPU ”）のショートネームが保
管され、かつカラム見出しをプリントする時に使用する
ための二つの配列における統計のショートネームが保管
される。行２２〜２４は完全なコンテクストパスネーム
と値のショートネームを連結することによって統計値の
完全パスネームを構築する。これは、テーブル２８に記
述されている関数呼び出しRSiPathAddSetStat によって
StatSetに値を追加する処理を続けるために必要であ
る。この値はテーブル２７における行２５及び行２６に
よって追加される。
【０３７７】
【表７】
【０３７８】RSiPathAddSetStat 関数（テーブル２８）
の目的は以下に示されている。 １． 単一統計値を定義済みの StatSetへ追加するこ
と。 ------------------------------------------------------------------------ struct StatVals *RSiPathAddSetStat （RSiHandle rhandle, struct StatSet * StatSet, char * path） ------------------------------------------------------------------------ テーブル２８−RSiPathAddSetStat 関数呼び出し
【０３７９】成功した場合、関数はポインタをタイプst
ruct StatVals へ戻す。エラーが生じた場合、ヌルが戻
されかつエラーテキストが外部文字配列RSiEMsg 内に置
かれる。ユーザが現在局所バッファサイズが許容するよ
りも多くの値をStatSet ヘ追加しようとするならば、RS
iErrnoはRSiTooManyへセットされる。遠隔ホストのxmse
rvd デーモンのバッファサイズが許容するよりも多くの
値を追加しようと試みるならば、RSiErrnoはRSiBadStat
ヘセットされ、かつ戻されたパケット内の状態フィール
ドは too many hosts へセットされる。
【０３８０】外部整数RSiMaxValuesは、データ消費者の
バッファサイズによって受容可能である値の最大数を保
持する。
【０３８１】関数に対する引き数は以下に示されてい
る。 rhandle RSiOpen 関数によって先に初期化さ
れたRSiHandle 。 StatSet 先に成功したRSiCreateStatSet関数
呼び出しによって戻されたタイプstructStatSet の構造
のポインタ。 path StatSet へ追加するための統計値の
完全値パスネーム。値のパスネームは終了スラッシュを
含まない。値パスネームが決してスラッシュによって開
始されないことに留意されたい。
【０３８２】説明する為のテーブル２４における主要処
理関数の次の部分は、行２１〜行２３からなる。最初の
行は、単純に、StatSet に対する統計の監視を送ること
を開始するようにxmservd デーモンへ伝える。次の２行
は入力data feedパケットをチェックするために関数RS
iMainLoop を呼び出す無限ループを定義する。関連する
二つの関数呼出しはテーブル２９及び３０において記述
されている。
【０３８３】RSiStartFeed関数（テーブル２９）の目的
は以下に示される。 １． data feedパケットを送るのに必要とされる度数
をxmservd へ伝えること。 ２． data feedパケットを送るのを開始するようにxm
servd へ伝える。 ------------------------------------------------------------------------ int RSiStartFeed（RSiHandle rhandle, struct StatSet *statset, int msecs ） ------------------------------------------------------------------------ テーブル２９−RSiStartFeed関数呼び出し
【０３８４】達成されたならば、関数はゼロを戻すか、
そうでない場合は、−１を戻し、次いでエラーテキスト
が外部文字配列RSiEMsg 内に置かれる。
【０３８５】関数に対する引き数は以下のように示され
る。 rhandle RSiOpen関数によって先に初期化さ
れたRSiHandle 。 statset 成功したRSiCreateStatSet関数呼び
出しによって先に戻されたタイプstructStatSet の構造
のポインタ。 msecs data feedパケットの伝送間のミリ
秒数。この数は５００ミリ秒の倍数へ丸められる。
【０３８６】RSiMainLoop 関数の目的は以下に示されて
いる（テーブル３０）。 １． データ消費者インターフェースが処理を延期する
ことを許容すると共に、data feedパケットが一つ以上
のxmservd デーモンから到着するのを待機すること。 ２． データ送りを待機する関数へ制御をデータ消費者
プログラムへ戻すように伝えることであり、これによっ
て後者が他の事象をチェックし、かつ反応することがで
きる。 ３． このような受け取られたパケットごとに、data
feedパケットを処理するために関数を呼び出すこと。 ------------------------------------------------------------------------ void RSiMainLoop （int msecs ） ------------------------------------------------------------------------ テーブル３０−RSiMainLoop 関数呼び出し
【０３８７】関数呼出しはいかなる値も戻さない。エラ
ーテキストは外部文字配列RSiEMsg内に置かれる。
【０３８８】この関数に対する引き数は以下に示されて
いる。 msecs 発呼者へ戻す前に関数が受信の
試行を継続するミリ秒における最短経過時間。プログラ
ムが指定されたミリ秒の間だけ制御を解放するが、RSiO
pen 呼び出しにおいて定義されたコールバック関数はこ
の時間を通じて反復されて呼び出され得る。データ消費
者プログラムが主な事象コントローラである場合は、こ
の値は、本明細書中に記載されている実施例のプログラ
ムにおけるように常に非ゼロ値にセットされなければな
らない。このプログラムが、X Windows ツールキットの
内の一つのXtMainLoop事象ループにおけるように、他の
主要事象コントローラを有している場合は、ゼロ値を指
定することは好ましい。次いで、タイムアウト関数はRS
iMainLoop の実行をトリガする。RSiMainLoop が、ミリ
秒当たりゼロ値によって実行される度に、全ての使用可
能な入力パケットは読み取られかつ処理される。使用可
能な入力がこれ以上存在しなくなった途端に関数は戻
る。OSF/Motif アプリケーションにおけるRSiMainLoop
の使用方法の例がテーブル３１に示されている。 ------------------------------------------------------------------------ void xtimeout（void *something ） ｛ xiid ＝XtAppAddTimeOut(XtWidgetToApplicationContext(top), xdelay, xtimeout, NULL）; RSiMainLoop（０）; ｝ ------------------------------------------------------------------------ テーブル３１
【０３８９】xmservd からのデータ送りのフローの制御
に関する二つの残りの関数呼び出しはここで記述され
る。これはテーブル３２及び３３において実行される。
【０３９０】RSiChangeFeed 関数（テーブル３２）の目
的は以下に示されている。 １． xmservd デーモンがdata feedパケットを送って
いる頻度を変更すること。 ------------------------------------------------------------------------ int RSiChangeFeed （RSiHandle rhandle, struct StatSet *statset, int msecs ） ------------------------------------------------------------------------ テーブル３２−RSiChangeFeed 関数呼び出し
【０３９１】達成されたならば、関数はゼロ、そうでな
い場合は−１を戻す。ヌルエラーテキストは、関数の成
功又は失敗には関わらず、外部文字配列RSiEMsg 内に置
かれる。
【０３９２】関数に対する引き数は以下に示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたRSiHandle 。 statset 成功したRSiCreateStatSet関数呼び
出しによって前に戻されたタイプstructStatSet の構造
のポインタ。データ送りは前のRSiStartFeed関数呼び出
しを介してこのStatSet のためにスタートされるべきで
あった。 msecs data feedパケットの伝送間のミリ
秒数。この数は５００ミリ秒の倍数へ丸められる。
【０３９３】RSiStopFeed 関数の目的は以下に示されて
いる（テーブル３３）。 １． 所与のStatSet に対してdata feedパケットを送
るのを停止するように、xmservd デーモンへ伝える。デ
ーモンがStatSet を消去するように命令されなかた場
合、データの送りはStatSet に対するRSiStartFeed関数
呼び出しを発生することによって再開され得ること。 ２． StatSet に対する全てのそれらの情報を消去する
ように、選択的にデーモンとAPI ライブラリ関数へ告げ
る。消去されたStatSet に関しての引き続く参照は無効
であること。 ------------------------------------------------------------------------ int RSiStopFeed （RSiHandle rhandle, struct StatSet * statset, boolean erase） ------------------------------------------------------------------------ テーブル３３−RSiStopFeed 関数呼び出し
【０３９４】達成されたならば、関数はゼロ、そうでな
い場合は−１へ戻す。ヌルエラーテキストは、関数の成
功又は失敗に関わらず、外部文字配列RSiEMsg 内に置か
れる。
【０３９５】関数に対する引き数は以下に示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたタイプRSiHandle の構造に対して。 statset 成功したRSiCreateStatSet関数呼び
出しによって前に戻されたタイプstructStatSet の構造
のポインタ。データ送りは、前のRSiStartFeed関数呼び
出しを介してこのStatSet のためにスタートされるべき
であった。 erase この引き数がTRUEにセットされたな
らば、xmservd デーモンはネーミングされたStatSet に
ついての全ての情報を廃棄する。そうでない場合は、デ
ーモンは統計のセットのその定義を維持する。
【０３９６】data feedがRSi インターフェースによっ
て検出された時は必ず、RSiOpen 関数呼び出しによって
定義されたデータ送りコールバック関数が呼び出され、
引き数としてRSihandle をコールバック関数へ渡す。デ
ータ送りに対する我々のサンプルプログラムのコールバ
ック関数はテーブル３４において示されている。関数に
おける行の大部分は各２０詳細行がプリントされた後の
印刷ヘッディングに関連している。これは行数９から１
９行及び２６行内にある。
【０３９７】
【表８】
【０３９８】受け取られた統計値の実際の処理は行２２
−２４によって行なわれる。この処理は以下のようにラ
イブラリ関数RSiGetValue の使用を含む。 １． 関数呼び出しに対する第２の引き数に基づいて受
け取られたデータパケットにおいてStatVals構造を検索
する。これは、 RSiインターフェースによって内部に維
持されているテーブル内のルックアップ動作を有する。 ２． オプションではあるが、SiFloat 又はSiLongのい
づれかであるとしてデータフィールドの形式を決定し、
かつそのデータ形式に基づいたさらなる処理に対してデ
ータ値を抽出する。 ３． SiQuantity又はSiCounter のいづれかとして値を
決定する。前者の場合は、戻されたデータ値はStatVals
構造におけるval フィールドである。後者が検索された
場合は、関数によって戻された値は前のデータパケット
のタイムスタンプ以後経過した秒数によって分割された
val changeフィールドである。 ------------------------------------------------------------------------ float RSiGetValue（RSiHandle rhandle, struct StatVals * svp） ------------------------------------------------------------------------ テーブル３５−RSiGetValue 関数呼び出し
【０３９９】成功した場合、関数は非負値を戻す。さも
なければ、この関数は−1.0 以下の負値を戻す。ヌルエ
ラーテキストは、関数の成功又は失敗に関わらず、外部
文字配列RSiEMsg 内に置かれる。
【０４００】関数に対する引き数は、以下に示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたRSiHandle でなければならない。 svp 成功したRSiPathAddSetStat 関数呼
び出しによって前もって戻されたタイプstructStatVals
のハンドルである。
【０４０１】図３０は付録Ａのリストに記載されている
サンプルプログラムから発生された出力の例を示す。
【０４０２】データ送りパケット内で受け取られたデー
タに関してRSiGetValue が提供するよりも多く知る必要
がある場合は、ライブラリ関数RSiGetRawValue（テーブ
ル３２）が使用され得る。この関数は以下のことを提供
する。 １． 関数呼び出しに対する第２の引き数に基づいた受
信データパケット内のStatVals構造を検索する。これ
は、RSi インターフェースによって内部的に保持された
テーブル内のルックアップ動作を含む。 ２． 有効なStat構造において指し示すためにStatVals
構造内の構造Statポインタを更新する。 ３． ポインタをStatVals構造へ戻す。戻されたポイン
タは静的領域を指し示すと共にRSiGetRawValueの次の実
行までのみ有効である。 ４． 索引によって整変数を、呼び出しへの第２の引き
数と対応するデータ送りパケットのValsSet 配列へ更新
する。 ------------------------------------------------------------------------ struct StatVals RSiGetRawValue （RSiHandle rhandle, struct StatVals * svp, int *index ） ------------------------------------------------------------------------ テーブル３６− RSiGetRawValue 関数呼び出し
【０４０３】成功した場合、関数はポインタを戻す。そ
うでない場合は、ヌルは戻され、かつエラーテキスト
は、外部文字配列RSiEMsg 内に置かれる。
【０４０４】関数への引き数は、以下に示されている。 rhandle RSiOpen 関数によって前に初期化さ
れたRSiHandle でなければならない。 svp 成功したRSiPathAddSetStat 関数呼
び出しによって前もって戻されたタイプstructStatVals
のハンドルである。 index 整変数へのポインタ。関数呼び出し
が成功した場合、データ送りパケットのValsSet 配列へ
の索引は戻される。索引は関数に対するsvp 引き数と一
致する要素と対応している。
【０４０５】利用者がデーモンが実行しているシステム
内で検索された全てのディスクに対するショートネーム
xferを有する統計のリストを作成したい場合は、コンテ
クストを走査する追加の関数呼び出しが必要とされる。
【０４０６】RSiFirstCx関数の目的は以下に示されてい
る（テーブル３７）。 １． 第２の引き数によって識別されたコンテクストが
存在することを検査すること。 ２． コンテクストに対して定義されたサブコンテクス
トのリストの第１の要素へハンドルを戻すこと。 ３． サブコンテクストのショートネーム及び記述を戻
すこと。 ------------------------------------------------------------------------ struct CxLink *RSiFirstCx（RSiHandle rhandle, cx handle *context, char ** name, char ** descr ） ------------------------------------------------------------------------ テーブル３７− RSiFirstCx 関数呼び出し
【０４０７】成功した場合、関数はタイプstruct CxLin
k の構造へポインタを戻す。エラーが生じた場合、ヌル
は戻され、かつエラーテキストは、外部文字配列RSiEMs
g 内に置かれる。
【０４０８】関数への引き数は以下のように示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたRSiHandle でなければならない。 context 成功したRSiPathGetCx関数呼び出し
によって前もって戻されたタイプcx handleのハンドル
である。 name 文字配列へのポインタのポインタ。
ポインタは文字配列ポインタにおいて指すために初期化
される。関数呼び出しが成功した場合、サブコンテクス
トのショートネームが文字配列ポインタ内に戻される。 descr 文字配列へのポインタのポインタ。
ポインタは文字配列ポインタにおいて指すために初期化
される。関数呼び出しが成功した場合、サブコンテクス
トの記述は文字配列ポインタ内に戻される。
【０４０９】RSiNextCx 関数の目的は以下に示されてい
る。 １． 第２の引き数によって識別されたコンテクストが
存在することを検査すること。 ２． コンテクストのために定義されたサブコンテクス
トのリストの次の要素に対してハンドルを戻すこと。 ３． サブコンクストのショートネーム及び記述を戻す
こと。 ------------------------------------------------------------------------ struct CxLink *RSiNextCx （RSiHandle rhandle, cx handle *context, struct CxLink * link, char ** name, char ** descr ） ------------------------------------------------------------------------ テーブル３８− RSiNextCx関数呼び出し
【０４１０】成功した場合、関数はタイプstruct CxLin
k の構造へポインタを戻す。エラーが生じた場合、ヌル
は戻され、かつエラーテキストは、外部文字配列RSiEMs
g 内に置かれる。
【０４１１】関数への引き数は以下のように示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたRSiHandle でなければならない。 context 成功したRSiPathGetCx関数呼び出し
によって前もって戻されたタイプcx handleのハンドル
である。 link 成功したRSiFirstCx又はRSiNextCx
関数呼び出しによって以前に戻されたタイプstructCxLi
nkの構造へのポインタ。 name 文字配列へのポインタのポインタ。
ポインタは文字配列ポインタにおいて指すために初期化
される。関数呼び出しが成功した場合、サブコンテクス
トのショートネームが文字配列ポインタ内に戻される。 descr 文字配列へのポインタのポインタ。
ポインタは文字配列ポインタにおいて指すために初期化
される。関数呼び出しが成功した場合、サブコンテクス
トの記述は文字配列ポインタ内に戻される。
【０４１２】RSiInstantiate関数の目的は以下に示され
ている（テーブル３９）。 １． 第２の引き数によって識別されたコンテクストが
存在することを検査すること。 ２． このコンテクストの全てのサブコンテクストがコ
ンテクスト階層において作成されるようにコンテクスト
を例示する。xmservd デーモンが開始された時は常に全
ての他のコンテクストは例示されるので、この関数呼び
出しは、コンテクストのSiInstFreqが、SiContInst又は
SiCfgInst へセットされた場合、広く意味をなすことに
留意されたい。 ------------------------------------------------------------------------ int RSiInstantiate （RSiHandle rhandle, cx handle *context ） ----------------------------------------------------------------------- テーブル３９− RSiInstantiate 関数呼び出し
【０４１３】成功した場合は、関数はゼロ値を戻す。そ
うでない場合は、関数はSiError において定義されたよ
うなエラーコードを戻し、かつエラーテキストは外部文
字配列RSiEMsg 内に置かれる。
【０４１４】関数に対する引き数は以下に示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたタイプRSiHandle の構造を指す。 context 成功したRSiPathGetCx関数呼び出し
によって前もって戻されたタイプcx handleのハンドル
である。
【０４１５】テーブル４０は、全てのサブコンテクスト
がアクセスされることを確認するために、これら三つの
関数呼び出しがどのようにしてRSiPathGetCxと結合され
るがを示す。このサンプルプログラムの内部関数addsta
t （テーブル２７）は各サブコンテクストの統計を順に
StatSet へ追加するために使用される。スタートコンテ
クストの下の全てのレベルのサブコンテクストを走査し
たがったプログラムは再帰的関数を容易に作成すること
がきる。
【０４１６】
【表９】
【０４１７】三つのRSi 関数呼び出しは使用されなかっ
たか、又は上記に示されなかった。これらのうちの一つ
は後述される。他の二つは以下に示されている。
【０４１８】第１はRSiDelSetStat （テーブル４１）で
あり、その目的は以下に示されている。 １． 第２の引き数によって識別されたStatSet が存在
しており、かつ第３の引き数によって識別されたStatVa
ls統計を含むことを検査すること。 ２． 未来のdata feedパケットが削除された統計を含
まないように、StatSetからStatVals値を削除（デリー
ト）すること。 ------------------------------------------------------------------------ int RSiDelSetStat（RSiHandle rhandle, struct StatSet *ssp, struct StatVals * svp ） ----------------------------------------------------------------------- テーブル４１− RSiDelSetStat関数呼び出し
【０４１９】成功した場合は、関数はゼロ値を戻す。そ
うでない場合は、非ゼロ値を戻し、かつエラーテキスト
は外部文字配列RSiEMsg 内に置かれる。
【０４２０】関数に対する引き数は以下に示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたRSiHandle でなければならない。 ssp 成功したRSiCreateStatSet関数呼び
出しによって前に戻された構造タイプstruct StatSetの
ポインタ。 svp 成功したRSiPathAddSetStat 関数呼
び出しによって戻されたようなタイプstructStatValsの
ハンドル。
【０４２１】RSiStatGetPath関数呼び出しの目的は以下
に示されている（テーブル４２）。 １． 第２の引き数によって識別されたStatVals統計が
存在することを検査すること。 ２． 統計の完全な値パスネームを含む文字配列へポイ
ンタを戻すこと。 ------------------------------------------------------------------------ int RSiStatGetPath （RSiHandle rhandle, struct StatVals * svp ） ------------------------------------------------------------------------ テーブル４２− RSiStatGetPath 関数呼び出し
【０４２２】成功した場合は、関数はパスネームへポイ
ンタを戻し、そうでない場合は、この関数はヌルを戻
し、かつエラーテキストは外部文字配列RSiEMsg 内に配
置される。
【０４２３】関数に対する引き数は以下に示されてい
る。 rhandle RSiOpen 関数によって前に初期化さ
れたRSiHandle 。 svp 成功したRSiPathAddSetStat 関数呼
び出しによって戻されたようなタイプstruct StatVals
のハンドル。
【０４２４】ユーザにどのホストをモニタリングすべき
かを指定することを要求するよりも潜在的データ提供者
ホストのリストをエンドユーザに提供することができる
プログラムを設計することが時には所望される。RSiInv
ite 関数呼び出し（テーブル４３）はユーザがこのよう
なプログラムを作成するのを許容する。
【０４２５】関数呼出しの目的は、遠隔ホストにおいて
xmservd デーモンに応答させるようにネットワークへ a
re you there メッセージを同報通信することであ
る。 ------------------------------------------------------------------------ char ** RSiInvite（int(* resy callb)( )), （int(* excp callb)( )), ------------------------------------------------------------------------ テーブル４３− RSiInvite関数呼び出し
【０４２６】成功した場合、関数は、各々が送信勧誘に
応答するホストのホストネームを含む文字ポインタの配
列を戻す（各応答ホストのホストＩＤは are you th
ereメッセージに対するホストの応答に含まれてい
る）。さらに、外部整変数RSiInvTabActive が、検索さ
れたホストネームの数を含む。ホストネームの配列への
戻されたポインタは関数呼び出しによって解放されな
い。呼び出しプログラムはこの関数呼び出しによって戻
されたポインタが、RSiInvite に対する引き続く呼び出
し後も有効のままである。成功しなかった場合は、エラ
ーテキストは外部文字配列RSiEMsg 内に配置され、エラ
ー数はRSiErrno内に配置され、かつ関数はヌルを戻す。
【０４２７】関数に対する引き数は以下に示されてい
る。 resy callb これらのパケットがRSiInvite
関数呼び出しへの継続時間中、遠隔ホストにおけるxmse
rvd デーモンから受け取られる時、i am backパケッ
トを処理する関数に対する関数のヌル又はポインタであ
る。この呼び出し関数が呼び出された時、以下に記述さ
れている三つの引き数が渡される。
【０４２８】この引き数がヌルとして指定された場合、
RSiInvite 関数内部のコールバック関数はいづれの i
am backパケットをも受け取り、かつこの関数が戻すホ
ストネームのテーブルを組み立てるためにこれらのパケ
ットを使用する。 excp callb 遠隔ホストにおけるxmservd デ
ーモンから受け取られた時のexcept rec パケットを処
理する関数のポインタ又はヌルである。ヌルポインタが
渡されたならば、アプリケーションは except rec メ
ッセージを受け取らない。このコールバック関数が呼び
出された時、以下に記述されるように三つの引き数が渡
される。
【０４２９】この引き数は任意の前のRSiInvite 又はRS
iOpen 呼び出しの対応する引き数を好ましくは無効と
し、かつ引き数それ自体がいづれかの引き数の次の実行
によって無効とされ得る。このように、アプリケーショ
ンは例外モニタリングをターンオン及びターンオフする
ことができる。前のオープンコールによって指定された
例外処理を無視するためのRSiOpen に関しては、その接
続がRSiClose呼び出しによって最初に閉じられる。
【０４３０】アプリケーションにおけるresy callb 及
びexcp callb 関数は以下の三つの引き数によって呼び
出される。 １． RSiHandle 。data feedパケットが受け取られた
時、これによってポインタによって指し示された構造が
パケットを送るホストを表示することが保証される。こ
のようにして指し示されたRSi ハンドルが、パッケージ
を送ったホストを表示しないことはほぼ確実である。こ
の引き数は無視されかつ第２の引き数のみを使用するべ
きである。即ち入力バッファのポインタである。 ２． 受け取られたパケットを含む入力バッファに対す
るタイプpack* のポインタである。RSiHandle 構造にお
けるポインタではなく、常にこのポインタを使用する。 ３． タイプstruct sockaddr in* の発信ホストのイ
ンターネットアドレスへのポインタ。
【０４３１】RSiInvite 関数は、送信誘導的な are
you there メッセージが送られ得るインターネットア
ドレスを得るために、前述された一つ以上の方法を使用
する。
【０４３２】RSiInvite 関数が、ネームサーバが使用不
可であるか、又は異常に長い応答時間を有することを検
出したならば、この関数はホストネームではなくむしろ
ホストのインターネットアドレスを戻す。ホストのリス
トが部分的に組み立てられた後ネームサーバが失敗した
場合、同一ホストが２度現れる。一度はそのインターネ
ットアドレスと共に、もう一度はそのホストネームと共
にである。
【０４３３】RSiInvite 関数呼び出しの実行時間は、/u
sr/lpp/xmservd/hostsファイル内に置かれた同報通信ア
ドレスの数に主として依存する。このようなアドレスの
各々は、約５０ミリ秒＋応答を処理するために要求され
る時間によって実行時間を延長する。呼び出し関数の最
短の実行時間は約１．５秒であり、その間、コールバッ
ク関数が指定され、かつこれらのコールバック関数へ提
供されたパケットが到着した場合、アプリケーションは
制御され得る。
【０４３４】動的データ提供者 上記の説明は、API の実施だけでなくAPI の使用方法の
両方について記述しているが、やはりある程度のフレキ
シビリティに欠けている。ある未来の日付において、他
のタイプの資源統計（まだ知られてない）が将来のプロ
セス及び／又はアプリケーションに対して存在し得るこ
とが可能である。xmservd デーモンに対するパフォーマ
ンスツールのインターフェースは、局所及び遠隔プロセ
スのためのデータ統計を要求しかつ受け取るための基本
的なフレームワークを提供するので、xmservd デーモン
と、パフォーマンスツールのユーザにとっては興味深い
統計を有する他のアプリケーション／プロセスとのイン
ターフェースをさらに定義することは有用である。例え
ば、いくつかの未来のデータベース又はマルチメディア
アプリケーションプログラムは、データ処理システムに
おけるアプリケーションプログラムの実行を最適化しよ
うとする時にモニタリングするために有用であるいくつ
かのパラメータや統計を定義し得る。これらの統計が、
定義可能な形式においてxmservd デーモンへ供給される
ならば、xmservd に関わるパフォーマンスツールの現存
のユーティリティは、統計の範囲が、まだ開発の余地の
あるアプリケーションプログラムに対してこれらの統計
を含むために、捕獲され、記録され、ディスプレイさ
れ、かつ再生されるように、拡張するために使用され
る。
【０４３５】図２６は、「動的データ提供者」（モニタ
リングのために新しい統計を提供するアプリケーション
プログラム）とxmservd デーモンの間にこのインターフ
ェース２０４を表示する。
【０４３６】DDS インターフェースの実施は二つの部
分、UDP ベースプロトコルと共用メモリプロトコルから
なる。UDP ベースプロトコルは上記に説明されているUD
P ベースの“xmquery ”プロトコルの拡張である。この
拡張は、統計が使用可能であることをxmservd に知らせ
るために、各DDS によって使用される単一パケットタイ
プ（“get supply”）からなる。このパケットは、DD
S がアクティブであることをxmservd に最初に知らせる
ために、DDS ごとに一度だけ使用される。DDS とxmserv
d の間の残存するハンドシェーキングは共用されたメモ
リプロトコルを介して実行される。“get supply”パ
ケットは、データ統計が利用可能であることをデータ提
供者デーモンへ知らせるとともに、データ提供者デーモ
ンと連絡するために使用する共用メモリセグメントのネ
ーム及びＩＤキーを渡すために各データ提供者デーモン
によって使用される。
【０４３７】統計は、アドレスが、初期UDP パケットに
おいてDDS からxmservd へ渡される共用メモリセグメン
ト内で定義される。Xmservd は、統計がxmservd にとっ
て公知である一つ以上のサブツリーに新しい統計を追加
するためにこの情報を使用する。初期化の後では、統計
は、DDS によって収集され、かつxmservd がxmservd の
データ消費者を送るように要求された時にデータ値をそ
こから抽出することができる共用メモリ領域内に配置さ
れる（例：パフォーマンスツール）。
【０４３８】メモリを共用する二つのパーティ（xmserv
d とDDS ）は、共用メモリ領域内のフィールドに基づい
た単純プロトコルを介して互いに更新されたままであ
る。起こり得るハンドシェーキングのタイプは以下を含
む。 ・ xmservd が終了することをDDS に伝える。 ・ xmservd は、共用されたメモリセグメントが消去さ
れたことを検出する。 ・ DDS は追加の統計が使用可能になったことをxmserv
d に伝える。 ・ DDS は前に追加された統計がもはや使用可能でなな
いことをxmservd に伝える。
【０４３９】以下は、ホスト上のxmservd デーモンから
利用可能な統計のセットを拡張するための上記のインタ
ーフェースについて詳細に説明している。動的データ提
供者（DDS ）プログラムは、実行された時、xmservd デ
ーモンと接触し、かつその統計を搬送する。この拡張さ
れたデーモンからその統計を得るいかなるプログラムも
DDS によって提供される追加の統計をアクセスすること
ができる。DDS プログラムは、統計のセットが拡張され
ようとしているxmservd を実行しているプログラムと同
じホストにおいて実行しなければならない。
【０４４０】動的データ提供者プログラムは、データ消
費者がホストのxmservd デーモンから提供され得る統計
のセットを拡張するように意図されている。動的データ
提供者は、サブコンテクスト及び統計を有するパーマネ
ント（不揮発性）又は動的（揮発性）のコンテクストと
して統計を追加することができる。この概念を図示する
ために、xmservd デーモンがテーブル４４に図示されて
いるように、コンテクストと統計のセットを有すると仮
定する。
【０４４１】
【表１０】
【０４４２】ここで、他の統計へのアクセスが可能であ
り、かつ統計がこのセットへ追加されると仮定する。動
的データ提供者が作成される。例えば、いくつかの統計
がトップレベルで追加され得る。これが図４５に示され
ているように、コンテクストと統計のツリー構造を拡張
することができる。
【０４４３】
【表１１】
【０４４４】示されているように、トップレベルにおい
て二つのコンテクストTEST及びMORETESTが追加される。
これらのコンテクストの始めはガジェット（gadgets ）
及びウィジット（widgets ）と呼ばれる二つの統計を有
する。第２は直接の派生統計を有さないが、SubTest と
呼ばれるサブコンテクストを有しており、このサブテク
ストは次に二つの統計、レベル及びキュー（待ち行列）
を有する。
【０４４５】この最初のシナリオに対して、追加された
コンテクスト及び統計は不揮発性であり、従ってパーマ
ネント統計として追加され得る。これによって、一つだ
けのライブラリ関数の使用及び以下のプログラミングス
テップが要求されることになる。 １． 統計を記述するためにデータ構造を宣言せよ。 ２． コンテクストを記述するためにデータ構造を宣言
せよ。 ３． 必要に応じて他のデータ領域を宣言せよ。 ４． xmservd インターフェースを初期化せよ。 ５． 例外処理を初期化せよ。 ６． 統計フィールドを初期化せよ。 ７． 主要ループを作成せよ。
【０４４６】タイプstruct Stat の単純構造において統
計が記述される。統計のテーブルは統計を有するとして
定義される各コンテクストに対して作成されなければな
らない。統計、ガジェット、及びウィジットの定義はテ
ーブル４６に示されているように見える。 ------------------------------------------------------------------------ static const struct Stat PUStats ＝｛ ｛“gadgets ”, “Fake counter value”,0, 100, SiCounter SiLong, NULL, SZ OFF(dat, a, SiULong)｝ ｛“widgets ”, “Another fake counter value”,0, 100, SiCounter, SiLong, NULL, SZ OFF(dat, b, SiULong)｝ ｝; ------------------------------------------------------------------------ テーブル４６ DDS −二つの統計値に対する定義
【０４４７】構造におけるフィールドは以下に示されて
いる。 １． 統計のショートネーム、３２バイトの文字デー
タ。 ２． 統計の記述、６４バイトの文字データ。 ３． 上部値域より低い作表、数値のための下部値域。 ４． 下部値域より高い作表、数値のための上部値域。 ５． データ値が変換される方法を定義する記号定数。
現在、以下の定数だけが定義されている。
【０４４８】SiCounter 値は連続的に増分され
る。通常、データ消費者が監視の合間の値におけるデル
タ（変更）を示す。
【０４４９】SiQuantity 値は使用されるメモリ
又は使用可能なディスクスぺースのようなレベルを表わ
す。 ６． データ消費者へ分配されなければならない時にデ
ータの形式を記述する記号定数。データ形式は、組み込
みファイルSdidef.h. 内の“enum”DataTypeによって定
義されるタイプのうちの一つでなければならない。現
在、タイプSiLong及びSiFloat だけが有効である。他の
どれかのタイプが指定される場合は、SiFloat が割り当
てられる。 ７． このフィールドは内部データテーブルとの互換性
を提供する。それはNULLと指定される。 ８． マクロSZ OFF は以下のように三つの引き数を取
る。
【０４５０】ａ． この統計値に対してソースデータフ
ィールドを含む構造のネーム。 ｂ． 上記のようにネーミングされた構造におけるこの
統計値に対するソースデータフィールドのネーム。
【０４５１】ｃ． ソースデータフィールドのデータ形
式。
【０４５２】コンテクスト階層内の二つの異なる場所に
統計の二つのセットを実際に追加することが所望される
ので、第２のセットも宣言されなければならない。テー
ブル４７はそれがどのように行なわれるがを示す。 ------------------------------------------------------------------------ static CONST struct Stat FakeMemStat ＝｛ ｛“level ”, “Fake quantity value ”, 0, 100, SiQuantity, SiLong, NULL, SZ OFF(dat, c, SiULong)｝ ｛“queue ”, “Another fake quantity value ”, 0, 100, SiQuantity, SiLong,NULL, SZ OFF(dat, d, SiULong)｝, ｛; ------------------------------------------------------------------------ テーブル４７ DDS −他の二つの統計値の定義
【０４５３】この統計が宣言された後、これらの親コン
テクストにリンクされるべきである。これはデータ構造
のテーブルを定義することによっても行なわれる。構造
の単一テーブルはパーマネントコンテクストとして定義
するように所望される全てのコンテクストを保持するた
めに定義される。各コンテクストは、タイプcx create
の一つの要素を要求する。三つの追加されたコンテクス
トを作成するためには、コンテクストはテーブル４８内
に示されているように宣言される。 ------------------------------------------------------------------------ static CONST cx create cx table ＝｛ ｛“TEST”, “Bogus Context Number 1”,sizeof(struct context), “TOP ”,PUStats, STAT L(PUStats), NULL, 0, NULL, SiContInst ｝ ｛“MORETEST”, “Bogus Context Number 2”,sizeof(struct context), “TOP ”, NULL, 0, NULL, 0, NULL, SiContInst｝, ｛“SubTest ”, “Bogus Context Number 3”,sizeof(struct context), “MORETEST”, FakeMemStats, STAT L(FakeMemStats), NULL, 0, NULL, SiNoInst ｝, ｝; ------------------------------------------------------------------------ テーブル４８ DDS −不揮発性コンテクストの宣言
【０４５４】各コンテクスト要素は以下のフィールドを
有する。 １． コンテクストのショートネーム、３２バイトの文
字データ。 ２． コンテクストの記述、６４バイトの文字データ。 ３． このフィールドは内部データテーブルとの互換性
を提供する。それはsizeof（struct Context）と指定さ
れなければならない。 ４． 親コンテクストのショートネーム、３２バイトの
文字データ。このコンテクストがトップレベルにおいて
追加される場合は、このネームをTop として指定する。
そうでない場合は、この同一テーブルにおいて他のコン
テクストのショートネームを指定せよ。 ５． 何も定義されなかった場合はこのコンテクスト又
はヌルに対する統計のテーブルのポインタ。 ６． 何も定義されなかった場合はこのコンテクスト又
はゼロに対する統計のテーブルにおける要素のカウン
ト。統計が定義された場合は、テーブル要素の数を得る
ために、マクロSTAT L を使用せよ。 ７． このフィールドは内部データテーブルとの互換性
を提供する。それはNULLと指定されなければならない。 ８． このフィールドは内部データテーブルとの互換性
を提供する。それはゼロと指定されなければならない。 ９． このフィールドは内部データテーブルとの互換性
を提供する。それはNULLと指定されなければならない。 １０． このコンテクストのために使用可能な例示のタ
イプを記述する記号定数。定義されているコンテクスト
が動的にサブコンテキストを追加することによって決し
て拡張されない場合は、定数 SiNoInst を指定し、さも
なければ定数SiContInstを使用せよ。三つの例示タイプ
の最後は、&dds. 統計に対して意味をもたない。
【０４５５】動的データ提供者プログラムは必要に応じ
てその固有のデータ領域を定義しなければならない。例
の構造及びフィールドはテーブル４９に示されている。 ------------------------------------------------------------------------ strust dat ｛ u long a; u long b; u long c; u long d; ｝； static int CxCount ＝CX L(cx table); / * 定義されたコンテクストのカウ ント* / static SdiShare *dataarea＝ NULL; / *共用メモリポインタ */ static struct dat *d ＝ NULL; / *統計データ領域へのポインタ* / static struct timezone tzone; ------------------------------------------------------------------------ テーブル４９ 構造及びデータフィールドの宣言
【０４５６】最初の数行は、生統計がxmservd へ提供す
るために計算されるデータ構造を定義する。データ領域
は不揮発性統計によって参照される全てのデータフィー
ルドを保持する。
【０４５７】次いで、追加される静的コンテクストの数
だけ初期化するためにマクロ（CX L ）を使用するカウン
タが定義される。最後にポインタが定義され、このポイ
ンタはxmservd デーモンによって共用されるデータ領域
を指すために結局は初期化される。
【０４５８】上記に説明されているように、xmservd デ
ーモンとDDS は、互いの間で通信しあうために、共用メ
モリを使用する。共用されたメモリ領域に関して以下に
述べられるいくつかの重要な点がある。
【０４５９】共用メモリ構成フィールド： 共用メモリ
領域はライブラリ関数によって作成され、かつその制御
情報及び発生したデータ構造は、一般に（わずかの例外
はあるが）DDS プログラムによって直接使用されたり、
或いは操作されない。DDS プログラムによって使用され
るフィールドは以下に示されている。 SiShGoAway このフラグは、それが終了する
時、xmservd によってセットされる。通常、DDS がこの
フラグを見る時、DDS はその共用メモリを解放し、次い
でデーモンが再開する時にxmservd によってレジスタす
るためにフラグ自体を終了したり又は準備したりする。
共用メモリの解放に失敗することによって、再開された
xmservd によってレジスタすることは不可能となる。 SiShT 共用されたデータ領域が更新され
る度に、DDS プログラムによって更新されるタイムスタ
ンプ。xmservd デーモンは、DDS が最後に活動状態であ
った時を調べるためにこのフィールドをチェックする。
タイムスタンプが更新されずに１５秒以上が経過した場
合、xmservd は動的データ提供者が消滅したと仮定し、
SiShGoAwayフラグをセットし、かつ共用メモリ領域のそ
のアクセスを解放する。 SiShArea 共用メモリセグメント内のデータ
領域のアドレス。DDS プログラムはこのフィールドによ
ってポインタをロードし、かつ共用メモリデータ領域を
アクセスするためにこのポインタを使用しなければなら
ない。
【０４６０】共用メモリデータ領域： 共用メモリデー
タ領域は、 DDSが、統計値が計算された時のその統計値
を配置する場所である。計算は、共用メモリにおいて割
り当てられた領域内で直接行なわれるか、又は計算結果
を有する局所データフィールド内で実行され、次いで共
用メモリへ移動される。重要なことは、共用されたメモ
リ領域が、統計を定義するテーブルのうちのいづれか一
つにおいて参照されるデータ構造内のこれらのフィール
ドの最後のフィールドを含むほどの大きさであることが
保証されていることを認識することにある。
【０４６１】これによって、テーブル４９において定義
されているように、構造データが追加のデータフィール
ドを有していた場合、宣言された統計はこれらの領域を
参照しないので、共用メモリにおいてこれらのフィール
ドを利用することができない。このようなフィールドを
アクセスするための試行によって、セグメント化の欠点
を生じることになる。
【０４６２】必要とされる全ての宣言が適所にあるか
ら、xmservd デーモンは記録される必要がある。これ
は、SdiDInitと呼ばれる単一ライブラリ関数を介して行
なわれる。この関数はテーブル５０において示されてい
るように定義される。その目的は以下に示されている。 １． 必要とされる共用メモリ領域の大きさを決定し、
かつその大きさの共用メモリセグメントを作成するこ
と。 ２． 共用メモリへ全ての静的コンテクスト及び全ての
参照統計を移動すること。 ３． xmservd デーモンと接触し、かつ全ての静的コン
テクストをそのコンテクストツリーへ追加するようにデ
ーモンに依頼すること。 ------------------------------------------------------------------------ SdiShare * SdiDInit (cx create *cxtab, int cxcnt, cx create *ixtab, int ixcnt, char *name） ------------------------------------------------------------------------ テーブル５０−SdiDInit関数呼び出し
【０４６３】成功した場合、関数は共用メモリ制御領域
のアドレスを戻す。エラーが生じた場合は、エラーテキ
ストは外部文字配列SdiEMsg 内に配置され、かつこの関
数はヌルを戻す。
【０４６４】関数に対する引き数は以下に示されてい
る。 cxtab 追加するための不揮発性コンテクストの
テーブルのポインタ。 cxcnt 不揮発性コンテクストのテーブルにおけ
る要素のカウント。この値を検索するためにマクロCX
L を使用せよ。 ixtab 追加するための揮発性コンテクストのテ
ーブルのポインタ。何も定義されない場合はヌル指定せ
よ。 ixcnt 揮発性コンテクストのテーブルにおける
要素のカウント。この値を検索するためにマクロCX L
を使用せよ。
【０４６５】何も定義されない場合はゼロを指定せよ。 name 共用メモリセグメントを作成する時に使
用するファイルネームを指定する。実行時においては、
ファイルは存在し、かつ継続するためにライブラリ関数
に対してDDS を実行するプロセスによって書き込むこと
が可能である。ファイルが存在しない場合は作成され
る。作成に失敗した場合は、関数はエラーを戻す。
【０４６６】例を示す目的のために、関数はテーブル５
１に示されているステートメントによって呼び出され
る。 ------------------------------------------------------------------------ dataarea＝ SdiDInit (cx table Cxcount, NULL, 0,“ /mydir/mydds ”; if（!dataarea ） ｛ fprintf(“%s”,SdiEMsg) ； exit（−１） ｝ d ＝(struct dat * )&dataarea->SiShArea 0 ; ------------------------------------------------------------------------ テーブル５１−xmservd によって登録
【０４６７】xmservd と対話するために、DDS が共用メ
モリを使用するので、DDS プログラムが消滅する時に共
用メモリ領域が解放されることを確認することは非常に
重要である。これが起こることを保証するための最良の
方法は、DDS プログラムが消滅したことを示す信号をキ
ャッチすることにある。信号を処理するために使用され
る同一関数は通常のプログラム終了に対して有利に使用
され得る。これはテーブル５２に示されているように行
なわれる。 ------------------------------------------------------------------------ （Ｃ）著作権 IBM コーポレーション、未刊行、全権保有 void SdiStopMe( ) ｛ if(!dataarea) shmctl(dataarea->SiShMemId, IPC RMID, NULL); dataarea ＝NULL; exit(0); ｝ signal(SIGTERM, SdiStopMe); signal(SIGTERM, SdiStopMe); ------------------------------------------------------------------------ テーブル５２ DDS −例外処理及び正常終了
【０４６８】関数SdiStopMe は、共用されたメモリ領域
が解放され、次いで終了することを確認する。信号ハン
ドラーを定義する２行は、DDS プログラムがxmservd に
よって登録するDDS プログラム内の場所の周囲に配置さ
れる。
【０４６９】大部分のケースにおいて、統計値はタイプ
SiCounter とSiQuantityの組合せである。データ消費者
は前者に対するデルタ値に通常は関心をもつ。最初に、
第１の読み出しを行ない、次いで共用メモリにおいて統
計フィールドを初期化する。このように、たとえデータ
消費者によって読み取られた最初のデルタ値でも有効で
ある傾向を有する。
【０４７０】データフィールドを更新することによっ
て、タイムスタンプを更新することが常に要求されるこ
とになり、これにより、初期フィールド値を提供するた
めに使用された行はテーブル５３における方式に従う。 ------------------------------------------------------------------------ gettimeofday(&dataarea->SiShT, &tzone); d->a ＝・・・; d->b ＝・・・; d->c ＝・・・; d->d ＝・・・; ------------------------------------------------------------------------ テーブル５３ DDS −データ値例示
【０４７１】この例において、我々が共用メモリデータ
領域において直接作動することを仮定していることに留
意されたい。
【０４７２】主要ループは通常は非常に単純であり、か
つwhile ループとして好適に作成されている。while ル
ープ内に組み込まれる条件のうちの一つはSiShGoAwayフ
ラグに対するテストである。他の条件はアプリケーショ
ンによって必要とされるプログラムを終了するために他
の方法を示す。テーブル５４の実施例における主要ルー
プはフラグだけをテストする。 ------------------------------------------------------------------------ while(!dataarea->SiShGoAway) ｛ usleep(499000); gettimeofday(&dataarea->SiShT, &tzone); d->a ＝・・・; d->b ＝・・・; d->c ＝・・・; d->d ＝・・・; ｝ SdiStopMe( ); ------------------------------------------------------------------------ テーブル５４ 動的データ提供者の主要ループ
【０４７３】主要ループは上記に示されているのと同じ
位単純であるが、このような単純性がDDS プログラムに
よって共用メモリ領域内の値を要求以上の頻度で更新さ
せる。DDS が値を定義したがxmservd デーモンがこの値
のいづれも使用しない状態においては、データフィール
ドを更新することは恐らく不要である。
【０４７４】二つのフィールドが動的データ提供者プロ
グラムへもう少しの繊細さを追加することを許容する。
両フィールドとも共用メモリ構造フィールド（Shared M
emory Structured Field）であり、かつSdiDInitによっ
て戻されたポインタを介してアクセスされ得る。 SiShInterval xmservdからのデータ値に対する
要求の合間のミリ秒の数をもつ整数。値の異なる要求者
が異なるインターバルによって要求するので、この値
は、例えば、最も速く実行する計器に対して定義された
インターバルのように定義された最小のインターバルを
反映する。 SiShSubscrib xmservdから現在要求されている
データ値の数。
【０４７５】明らかに、SiShSubscribがゼロであるなら
ば、だれもデータ値の供給を要求しない。従ってDDS に
おける更新頻度は減少され得る。データフィールドの更
新を停止し、むしろ５乃至１０秒のインターバルによっ
て更新を減少させることを勧める。
【０４７６】SiShSubscribは非ゼロ値である場合は、あ
る利用者がデータ値の連続供給を要求しており、従っ
て、この更新頻度は、要求頻度がSiShIntervalにおいて
提供された頻度と一致するように調整される。
【０４７７】これらの原理を使用する主要ループはテー
ブル５５に示されているように見える。 ------------------------------------------------------------------------ （Ｃ）著作権 IBM コーポレーション、未刊行図書、全権保有。 while(!dataarea->SiShGoAway) ｛ if(! dataarea->SiShSubscrib) usleep(dataarea->SiShInterval * 1000) else sleep(5) gettimeofday(&dataarea->SiShT, &tzone); d->a ＝・・・; d->b ＝・・・; d->c ＝・・・; d->d ＝・・・; ｝ SdiStopMe( ); ------------------------------------------------------------------------ テーブル５５ DDS −動的データ提供者の主要ループ
【０４７８】SiShSubscribフィールドは、通常、共用メ
モリ領域内のデータ値に現在加入している全てのデータ
消費者プログラムのカウントを保持する。しかしなが
ら、データ消費者及びデータ提供者の両方として動作す
るプログラムを許容するためには、割り当てられたポー
トのポート番号が、他の共用メモリ構造フィールドであ
るフィールドSiShPortNoへのプログラムのデータ消費者
サイドへ移動され得る。データ消費者／データ提供者プ
ログラムはポート番号を挿入するために以下のようなス
テートメントを使用する。
【０４７９】dataarea->SiShPortNo ＝rsh->portno; ここで、rsh はホストに対するRSiHandle である。RSiH
andle 構造におけるフィールドportnoはライブラリ関数
RSiOpen によって更新される。ポート番号が共用メモリ
領域内に挿入される時、xmservd は、局所ホストのその
ポート番号において発信する共用メモリ領域内のデータ
値に対する加入をカウントしない。
【０４８０】上記のプログラムセグメントは、図３１及
び図３２において示されているように、作業用DDS プロ
グラムへ結合される。
【０４８１】揮発性統計 上記セクションにおいて、動的データ提供者プログラム
はパーマネントコンテクスト及び統計を有する統計のセ
ットを拡張するために作成された。次に、コンテクスト
及び統計が動的に追加されたり、削除されたりすること
を許容するために前もって記述されたサンプルプログラ
ムを拡張した。
【０４８２】環境が変化するにつれて、統計を追加した
り、削除するのが当然であるという状態は非常に少な
い。例えば、DDS がネットワークホストのペア間の応答
回数をモニタリングすることに関わると仮定されたい。
小規模ネットワークでさえ、あらゆる可能なホストペア
を定義しかつそれらのトラックを保持するにはあまりに
も大きすぎる。時間のいかなる点においても、限定され
た数のセッションはアクティブであるが、この数は関連
するホストペアが変化するように変化する。この揮発性
が提供された統計内に反映された場合、統計を動的に追
加したり、削除したりする能力が要求される。
【０４８３】コンテクストを動的に追加及び削除するた
めに使用される二つのライブラリ関数の使用を図示する
ために、テーブル４５に示されているコンテクスト階層
は、テーブル５６に示されている階層のように拡張され
る。
【０４８４】
【表１２】
【０４８５】示されているように、Bingo （ビンゴ）と
呼ばれるコンテクストが、新しいコンテクストの親とし
て前に追加されたコンテクストMORETESTと共にこの階層
へ追加されている。追加されるコンテクストは二つの統
計値、即ち問題と解を有する。コンテクストは、その時
刻によって決定されるように、動的に追加れたり、削除
されたりする。
【０４８６】前の実施例のプログラムに対しては以下の
追加ステップを進む。 １． 動的統計を記述するためにデータ構造を宣言せ
よ。 ２． 動的コンテクストを記述するためにデータ構造を
宣言せよ。 ３． 必要に応じて他のデータ領域を宣言せよ。 ４． xmservd パフォーマンスツールによって登録を変
更せよ。 ５． 動的コンテクストを追加及び削除するための主要
ループを変更せよ。
【０４８７】統計は、それらがパーマネントに追加され
るにせよ動的に追加されるにせよ、ほぼ同様に定義され
る。あるコンテクストに対して全ての統計が一つの配列
内で定義されなければならないことは正当である。適切
であるならば、その配列はより多くのコンテクストによ
って参照され得るが、大部分の場合はそうではない。唯
一の実質的な差は、動的に追加されようとする統計の各
セットが、そのデータフィールドのソースとして、分離
したデータ構造を参照しなければならないことである。
これは、全ての統計ソースフィールドが共通構造内に存
在しなければならないパーマネント統計とは全く異なっ
ている。
【０４８８】動的データ構造を必要するには明らかに理
由が存在する。静的データ値は一度しか生じない。これ
らの値は全て共用メモリ内の一つの隣接領域内にある。
これに対して動的データ値は複数の例において存在し、
かつ出たり入ったりし得る。これらの値が要求された
り、削除されたりする時、これらの値は共用メモリ内に
動的に割り当てられ、かつこれらの共用メモリ領域は自
由リストへ戻される。
【０４８９】テーブル５６における実施例に関して、
「問題」及び「解」の値を追加するための統計の定義が
テーブル５７に示されている。 ------------------------------------------------------------------------ static CONST struct Stat InstStat ＝｛ ｛“problems”，“Fake counter value”，0 ，100, SiCounter, SiLong, NULL, SZ OFF （inst, a, SiFloat）｝， ｛“solutions ”，“Another fake counter value”，0 ，100, SiCounter, SiLong, NULL, SZ OFF （inst, b, SiLong ）｝， ｝; ------------------------------------------------------------------------ テーブル５７ DDS −動的統計値に対する定義
【０４９０】前に使用された（テーブル４９において定
義された）構造“dat ”はここでは参照されないが、
“inst”と呼ばれる異なる構造はまだ定義されていない
ことに留意されたい。
【０４９１】この実施例においては、単一コンテクスト
だけが追加される。もっと多くのコンテクストが追加さ
れ得るが、DDS プログラムが追加したいとする各コンテ
クストごとに、一つの要素がコンテクストのテーブルに
おいて定義されなければならない。コンテクストがテー
ブル内で定義されず、かつDDS がxmservd によって登録
された時にコンテクストがSdiDInitへ渡されない限り
は、コンテクストは動的に追加されることはできない。
テーブルはパーマネントコンテクストのテーブルと全く
同じ形式を有するが、同一テーブルでなはい。テーブル
５８は単一コンテクストをどのように定義するかを示し
ている。 ------------------------------------------------------------------------ static CONST cx create inst table ＝｛ ｛“INST1", “Instantiable Context Number 1"sizeof(struct Context), “MORETEST",InstStats, STAT L(InstStats),NULL,0,NULL,SiNoInst ｝, ｝; ------------------------------------------------------------------------ テーブル５８ DDS −動的コンテクストに対する定義
【０４９２】宣言された統計によって参照される構造
と、割り当てられた共用データ領域へアクセスするため
に使用されるポインタとが定義されるべきである。便宜
上、整数も動的コンテクストの数を保持するために以下
のように定義される。 ------------------------------------------------------------------------ struct inst ｛ float a; u long b; ｝; int InstCount ＝CX L(inst table);/* 定義されたコンテクストのカウント* / struct inst ptl＝NULL; * / * 統計データ領域へのポインタ* / ------------------------------------------------------------------------ テーブル５９ DDS −動的拡張に対する他のデータ領域
【０４９３】xmservd デーモンによる登録はほとんど変
わらない。ライブラリ関数は動的コンテクストテーブル
が存在する場所とその関数がいくつ要素を所有している
かを知るべきである。これはテーブル６０に示されてい
る。
【０４９４】
【表１３】
【０４９５】テーブル６１は変更された主要ループを示
す。ループは三つのコードによって拡張される。第１の
コードはコンテクストを追加するためにライブラリ関数
SdiSAddCx を使用する。第２のコードセグメントは、コ
ンテクストを再度削除するためにSdiDDelCx を使用し、
かつ第３のコードはコンテクスト及びその統計がアクテ
ィブである時は必ず共用データ領域内でこの値を更新す
る。
【０４９６】
【表１４】
【０４９７】SdiDaddCx と呼ばれるライブラリ関数はテ
ーブル６２に示されているように定義される。その目的
は以下に示されている。 １． あるコンテクストがそのコンテクスト階層へ追加
されるために利用可能であることをxmservd へ伝えるた
めに共用メモリ領域を使用すること。 ２． 共用メモリへコンテクストの複写を移動させるこ
と。 ３． データ領域に対してメモリを割り当てること。 ------------------------------------------------------------------------ char * SdiDAddcx(ushort ix, char *parent, char *name, char *descr) ------------------------------------------------------------------------ テーブル６２ DDS −SDiDAddcx 関数呼び出し
【０４９８】達成した場合、関数は共用メモリ領域のア
ドレスを戻す。エラーが生じた場合、エラーテキストが
外部文字配列SdiEMsg 内に配置されかつこの関数はヌル
を戻す。
【０４９９】関数に対する引き数は以下に示されてい
る。 ix 動的コンテクストのテーブルにおいて追加
されるコンテクストの要素番号。動的コンテクストのテ
ーブルがSdiDInit関数呼び出しにおいて定義されなかっ
た場合、コンテクストは追加されない。テーブルの第１
の要素は要素番号ゼロである。 parent 追加されるコンテクストの親コンテクスト
となるべきコンテクストのショートネーム。このネーム
は、静的コンテクストのテーブル（テーブル４８）内の
現存コンテクストの“Top （トップ) ”かショートネー
ムかのいづれかである。 name 追加されるコンテクストへ提供されるべき
ショートネーム、このネームが親コンテクストにおいて
固有であることに留意されたい。同じコンテクストが同
じ親の下で複数回追加されるならば、各例示ごとにネー
ムを変更する。 descr xmperfのようなデータ消費者へ提供される
時に追加するためのコンテクストの記述。
【０５００】ライブラリ関数SdiDDelCx はテーブル６３
に示されているように定義される。その目的は以下に示
されている。 １． xmservd デーモンが削除用コンテクストが前もっ
て動的に追加されていたことを検出しなかったならば、
このコンテクストを“to-be-added ”リストから取り出
すか、或いはこの割り当てられた共用メモリを自由リス
トへ戻すこと。そうでない場合、 ２． コンテクストとその対応する統計値がコンテクス
ト階層から除去されなければならないことと、いかなる
割り当てられた共用メモリも自由リストへ戻されなけれ
ばならないこととをxmservd デーモンへ表示すること。 ------------------------------------------------------------------------ int SdiDDelCx(char * area) ------------------------------------------------------------------------ テーブル６３ DDS − SdiDDelCx関数呼び出し
【０５０１】成功した場合は、関数はゼロを戻す。エラ
ーが生じたならば、エラーテキストが外部文字配列SdiE
Msg 内に配置され、かつこの関数は非ゼロ値を戻す。
【０５０２】関数に対する引き数は以下のように示され
る。 area SdiDAddcx 関数呼び出しによって戻され
る予め割り当てられた共用メモリデータ領域のアドレ
ス。
【０５０３】揮発性拡張の認識 動的データ提供者プログラムが揮発性の拡張を追加又は
削除する時、これは共用メモリ領域内のフィールドを介
してxmservd へ表示される。UDP パケットはライブラリ
関数によって発生されない。xmservd デーモンは、共用
メモリ領域内で検索するために、いくつかの事象がそれ
を助長するまで、DDS 変更を認識するようにはならな
い。
【０５０４】コンテクスト構造の更新を最小限に保持す
るので、このアプローチは選択されたのである。これら
の変更は必要に応じて実施される。以下に示されている
のは、xmservd に揮発性拡張に対する変換のための共用
メモリ領域をチェックさせる事象のリストである。 １． RSiPathGetCx関数が、DDS によって定義されるコ
ンテクストのいづれにも使用される時はいつでも。即
ち、プログラムが値パスネームからコンテクストポイン
タを探索しようとする時はいつでも。この関数はコンテ
クスト階層のいかなる走査に対しても通常は要求され
る。 ２． RSiFirstCx関数が、DDS によって定義されるコン
テクストのいづれにも使用される時はいつでも。即ち、
プログラムが、DDS においてコンテクストのサブコンテ
クストの走査を開始する時はいつでも。 ３． RSiFirstStat関数が、DDS によって定義されるコ
ンテクストのいづれにも使用される時はいつでも。即
ち、プログラムが、DDS 内のコンテクストの統計の走査
を開始する時はいつでも。 ４． RSiInstantiate関数が、DDS によって定義される
コンテクストのいづれにも使用される時はいつでも。即
ち、プログラムが、動的データ提供者プログラムによっ
て定義されるいかなるコンテクストの例示をも明示的に
要求する時はいつでも。
【０５０５】注釈機能実施 このセクションは、記録されたパフォーマンスデータの
マーキング及び注釈を許容するパフォーマンスツールの
記録／再生メカニズムの拡張について記述する。この機
能は、ユーザが、その分野の科学者が、収集された被検
物のフィールドサンプルを収集し、マーキングし、かつ
注釈するように、プログラム「病理学」及びこれらが記
録されたコンテクストを科学的にカタログ化しかつ文書
化するのを許容する。
【０５０６】注釈された記録は様々な方法において有用
であり、これらは以下を含む。 １． 分析のため他の場所においてエキスパートへ伝送
され得るフィールドにおけるパフォーマンスデータの収
集。 ２． パフォーマンス問題の比較及び診断に使用される
プロトタイプの実施例のケースブックの構築。 ３． パフォーマンス分析クラスに関して使用される教
育的例の生成。
【０５０７】マーキング及び注釈機能は、図１において
前述されかつ図示された以下のサブシステムへの拡張を
含んでいる。 １． マーカートークンと注釈の記録を可能とする記録
サブシステム。 ２． マーカートークンを識別しかつ注釈を検索するの
を可能とする再生サブシステム。 ３． マーカートークンと注釈のディスプレイを可能と
するディスプレイサブシステム。 ４． マーカートークンの挿入、注釈記録の作成／編集
／ビューイング、再生中のマーカトークンの処理、及び
注釈に対するマルチメディア入力（オーディオ／ビジュ
アル図形及び画像）と出力の追加を支援するためのGUI
。
【０５０８】マーキング及び注釈機能は以下の要求を満
たす。 １． コンピュータシステムにおいて迅速に事象が起こ
るので、ユーザはリアルタイムで事象を迅速かつ正確に
マーキングできなければならない。 ２． 全ての関連する情報の捕獲を可能とするために、
事象マーク及び記録全体へ可能性のある長さの注釈を取
り付け可能であることが必要である。 ３． 注釈記録の作成及び編集はいつでも可能である。
これは事象のショートシーケンスの「迅速」なマーキン
グとこれらの事象に続く長さの注釈を許容する。 ４． 事象マーク（マーカートークン）は再生中容易に
見ることができるべきだが、グラフを不明瞭にしないよ
うにコンパクトでなければならない。 ５． 注釈記録はユーザがそれらを見たい時だけディス
プレイされる。これは、注釈記録を編集するか又は再生
中のマークで停止する時である。 ６． 事象のマーキング及び注釈は記録及び再生動作中
に可能である。 ７． 再生中、ユーザ特定の事象マーク又はその次のマ
ークを走査することができるべきである。
【０５０９】リアルタイムにおける事象の正確なマーキ
ングを許容するためには、マーキングは迅速な１ステッ
プ動作であるべきである。これは以下のように達成され
る。 １． ユーザは通常の方法で計器又はコンソールの記録
を開始する。 ２． 計器又はコンソール記録のサブメニューから、ユ
ーザはボタンでマーキングを選択する。これによって選
択された計器がマーキングモードになり、この際、マー
カートークンの挿入の要求に応じて計器のマウスクリッ
クが変換される。この動作は記録中のである計器に対し
てのみ許容される。 ３． ユーザがマーキングモードにある計器のマウスを
クリックする時はいつでも、マーカートークンはパフォ
ーマンスツールによって作成される。これは、マウスク
リックと対応する時間に指定された計器にディスプレイ
される矢印及びラベルとして表示される。ラベルはショ
ートマシン発生ユニークラベル（２桁のシンボルで一般
的に十分である）である。マーカートークンはタイムグ
ラフと共に移動する。グラフが記録している間、又は注
釈がこのトークンがそのポインタを有する分離ファイル
内に保持されるので後で、ユーザは注釈を提供すること
ができる。 ４． ユーザは適切な計器内でマウスポインタによって
マウスボタンを繰り返しクリックすることによってマー
カートークンのシーケンスを発生することができる。 ５． ユーザはマーキングモードを終了するために「マ
ーキングオフ」ボタンを選択する。
【０５１０】マーク終了の注釈は記録中はいつでも可能
である。それは以下のように達成される。 １． ユーザが計器又はコンソール記録サブメニューか
ら注釈ボタンを選択する。 ２． パフォーマンスツールは、現在記録内に存在する
マーカートークンのタイム分類された選択リストをユー
ザに提供する。リストへの各入力はマークの時間、ラベ
ル、マークが入力される計器のIDからなる。リストへの
最初の入力は記録全体に対する注釈である。 ３． ユーザがリストから入力を選択する時、パフォー
マンスツールは、Motif規定を使ってマーカートークン
と対応する注釈記録を編集するためにダイアログをディ
スプレイする。このダイアログは以下のフィールドを有
する。
【０５１１】ａ）ラベル−これは編集可能フィールドで
あり、特に計器にディスプレイされたラベルを変更する
のを編集する。
【０５１２】ｂ）時間−記録中の編集可能フィールドで
はない。 ｃ）ユーザがいかなる所望の本文の情報をも入力するこ
とができるスクロール可能なテキスト入力フィールド。 ４． ユーザはこの時点で指定マークを削除することも
選択する（これは他の一つのメニューボタンである）。 ５． ユーザが正規の方法においてコンソールの記録を
終了した時、ユーザはなんらかの注釈を追加したいか否
かを問われる。追加を望む場合、ユーザはユーザが再度
記録を終了するまで記録を注釈することをが許容され
る。この期間中、記録を行なわれないが、記録ファイル
はまだ開かれている。
【０５１３】再生中にリアルタイムのマーキング問題は
存在しないので、再生中のマーキング及び注釈は同時に
行なわれ得る。これは以下のように達成される。 １． ユーザは所望の時間に再生を停止する。 ２． 次いで、計器のマークメニューボタンを選択する
ことによってマークを追加することができる。 ３． ユーザがマークを挿入する時、パフォーマンスツ
ールは、記録中のように、注釈記録編集ダイアログを直
ちにディスプレイする。 ４． ダイアログは記録中にディスプレイされたダイア
ログと一致しているが、この場合、タイムフィールドを
編集することが可能であり、これによって記録の異なる
時間へ移動することが可能である。タイムフィールドを
編集した後では、統計に対してディスプレイされた値は
従って自動的に変化する。 ５． ユーザは記録においてと同様に注釈記録のテキス
トフィールドを編集することができる。 ６． 記録がマークの時間において停止した時、適切な
ボタンを選択することによって、ユーザは現存のマーク
に対する注釈を編集／ビューイングすることもでき、或
いはそれらを削除することもできる。 ７． ユーザは、リストから現存マークを選択するか、
又は次／前のマークをシーキングすることによって現存
マークをシーキングすることができる。 ８． 状態グラフに関しては、記録が実際の速度で再生
された時、マークは短時間（例えば、２秒間）見ること
ができる。他の実施例においては、マークはマークの正
確な時間以外の間隔においては時々不明瞭になる。
【０５１４】再生中のマーカートークンの迅速な位置付
け及び移動を円滑にするためには、再生及び記録中に、
メモリ内に“mark table（マークテーブル）”（マーカ
ートークン記録の要約）を保持し、かつそれをファイル
が書き込まれた時にファイルの終わりに格納することが
最良である。
【０５１５】注釈サポートを提供するための記録サブシ
ステムの内部動作が示されている図３３を参照された
い。GUI メッセージがブロック４９９において選択され
た注釈ボタンのうちの一つを有する記録サブシステムに
よって受け取られた時、ブロック５０１においてこのマ
ークボタンがオペレータによって選択されたか否かがチ
ェックされる。選択された場合、マークテーブルはブロ
ック５０３において初期化される。選択されない場合、
ユーザが「マークオフ」選択を選択することにより、ブ
ロック５０５において前のマーキングを不可能とするこ
とを選択したか否かを決定するためにチェックされる。
選択した場合、マークテーブルが完成され、かつブロッ
ク５０７において保管される。選択しなかった場合は、
ブロック５０９において、ユーザが、データ上で捕獲さ
れているｎが次の連続整数であるマーカートークンｎを
配置することを選択したか否かがチェックされる。選択
した場合には、ブロック５１１において、マーカートー
クンｎはデータ記録ファイル１００に配置される。選択
しない場合は、ブロック５１３においてユーザが現在又
は他の現存マーカートークンｎ（MTn)のいづれを注釈す
ることを選択したか否かがチェックされる。注釈を選択
した場合には、ブロック５１５においてこのMTN に対応
する注釈ファイルが開かれる。ユーザによって供給され
かつGUI を介して渡されたユーザ注釈情報が、ブロック
５１５においてこの注釈ファイルに書き込まれる。注釈
を選択しなかった場合には、ブロック５１７において
（これが唯一の他の注釈ボタン選択であるので）ユーザ
がマーカートークンMTn を削除することを所望しかつ選
択されたMTn が削除されるとが仮定される。
【０５１６】ブロック５３７において注釈ボタン選択を
アクティブにするGUI メッセージが受け取られた時、図
３４は、再生サブシステムの一部分に対するフローチャ
ートである。ブロック５１９においては、マークボタン
がオペレータによって選択されたか否かについてチェッ
クされる。選択された場合、マークテーブルはブロック
５２１において初期化される。選択されなかった場合、
ブロック５２３において、マークオフ選択を選択するこ
とによって、ユーザが前のマーキングを不可能とするこ
とを選択したか否かがチェックされる。選択した場合、
マークテーブルは完成され、ブロック５２５において保
管される。選択されなかった場合、ブロック５２７にお
いて、ユーザが、捕獲されているデータ上にマーカート
ークンｎを配置することを選択したか否かがチェックさ
れる。選択された場合、マーカートークンｎが、ブロッ
ク５２９においてデータ記録ファイル内に配置される。
再生中にリアルタイムマーキング問題が存在しないの
で、再生中にマーキング及び注釈は同時には実行できな
い。これによって、ブロック５３１においては、ユーザ
によって注釈情報を書き込むためにMTn に対する注釈フ
ァイルが開かれる。ユーザがマーカートークンｎを配置
することを選択しなかった場合、ブロック５３３におい
て、ユーザがマーカートークンｎを削除することを選択
したか否かがチェックされる。選択した場合、ブロック
５３５においてMTn は削除される。選択しなかった場
合、ルーチンは戻る。
【０５１７】図３８においては、マーカートークン記録
を有するデータ記録６００が示されている。記録ファイ
ル１００に保管されるデータ記録（レコード）はコンソ
ールヘッダデータ６０２によって開始される。データレ
コード１−ｉがブロック６０４において捕獲されている
のが示されている。ユーザは、ブロック６０４において
レコードｉの後で記録されたデータを注釈することを選
択し、是によってマーカートークン１レコード６０６
は、ｉ番目のデータレコードの後に記録される。データ
は、他の注釈がユーザから要求されるまで、ブロック６
０８においてｉ＋１番目以降から記録され続ける。ブロ
ック６１０において、第２のマーカートークン２レコー
ドは保管される。このように、ユーザによって引き続く
注釈に対するリアルタイムデータのデータ記録を中断さ
せることなく、マーカーは記録されたデータストリーム
内に速やかに配置され得る。
【０５１８】マーカートークン記録（ブロック６０６及
び６１０）は以下のフィールドを含む。 ・ マーカーID ０〜ｎまでの整数値 ・ ラベル ユーザによって編集され得るテキスト文字ストリング ・ タイムスタンプ マーカーが配置されたシステムタイム ・ 注釈ファイルネーム
【０５１９】病理学ライブラリ及び検索関数 コンピュータシステムパフォーマンスモニタリング及び
同調（チューニング）の科学はそれが依存する他の科学
フィールドに非常に類似している。 １． 正常及び異常現象の監視及び分析 ２． 仮説及び定理を有効にするための実験 ３． 偏差又は所望されない影響を終始一貫して補正す
るための手続き。
【０５２０】コンピュータパフォーマンスのモニタリン
グ、分析、及び同調動作と、医療の専門家には公知の病
気及び疾病の監視、診断、及び治療とが類比され得る。
それは、図形コンピュータシステムパフォーマンス病理
学ライブラリが、システムパフォーマンス病理学即ち
「疾病」の情報を集め、情報の操作特徴を識別し、それ
らをネーミングし、かつ「コンピュータパフォーマンス
医師」のコミュニティによってアクセスされ得るデータ
収納場所にこれらの情報を格納するためのプロセスのキ
ー部分であるそのコンテクスト内にある。この「科学的
方法論」に従って、多くのツール、モデル、理論、及び
実践が医学及び生物学の分野から利用され得る。病理学
は、何か異常なもの、又はあるものの仮定された正常な
状態からの逸脱を意味することで知られている。
【０５２１】一旦構築されれば、パフォーマンス病理学
ライブラリの目的は、コンピュータ知識の本体及びネッ
トワークパフォーマンス問題と解決への広範かつ容易な
アクセスを提供することにある。従って、この知識は、
当該マシンが「不良パフォーマンス」モードにある時を
認識し、補正行動を取り、閉フィードバックループ内の
対応する結果をモニタリングすることができる知的マシ
ンの開発における最新技術の向上の基本となることがで
きる。
【０５２２】以下の説明は、システムパフォーマンスの
ある記録を監視し、記録し、注釈し、かつ再生するため
に、上記の様に、パフォーマンスツールの存在を仮定し
ている。記録、注釈、及び再生機能は、テキスト、図
形、又は（音声及び画像を含む）マルチメディアデータ
記録を許容し、次いでコンピュータアクセス可能なメデ
ィアに記憶される。これらの記録は、ｎ次元（例えば、
追加情報を搬送するカラー、プレゼンテーションスタイ
ル、又は注釈などの他の属性を有する２Ｄ、３Ｄ、オー
バータイム）であり、かつ全ての次元のコンテクストを
保護する忠実度の高い再生メカニズムである。コンテク
ストは、２Ｄ又は３Ｄデータオーバータイム、カラー、
プレゼンテーションスタイル、記録度数、又はオーディ
オ／テキスト注釈のような記録のｎ次元属性を保護する
記録によって記憶されたヘッダ情報を有する各記録（フ
ァイル）に保持される。これらの属性に対して行なわれ
る変更も、追加特徴に応じて適切に行なわれた好適拡張
を有する記録ヘッダ記録のために予め記述されたデータ
構造を用いて記録ファイル内に組み込まれる。ライブラ
リのユーザは、ユーザが多くの異なる探索カテゴリによ
りデータをアクセスすることができるように、記録の多
くの編成されたビュー（視点）を必要とする。
【０５２３】この環境は、注釈ファシリティを介して提
供されたエンハンスメントによって上記に述べられてい
る記録／再生ファシリティによって好ましく提供されて
いる。図３５におけるフローチャートは、ネットワーク
及びコンピュータシステムのパフォーマンス問題を識別
し、診断し、処理するのを補助するように、システムパ
フォーマンス病理学ライブラリを確立しかつ使用するた
め、一般的な手続き５００を表現する。
【０５２４】病理学ライブラリは、大規模中央ライブラ
リ、サテライト（周辺）ライブラリ、及び特別コレクシ
ョン専用ライブラリなどのいくつかの有効範囲（スコー
プ）を有することができる。中央ライブラリのための
「ライブラリアン（Librarians）」は中央収納場所にお
けるユーザコミュニティに公知の記録、診断、及び治療
の最大のセットを収集するための責務を負う。それらは
現在に及ぶ最新の知識プールを保持し、かつ時代遅れの
資料を保存する責務を負う。許可された時、ライブラリ
アンは周辺ライブラリと「専用コレクション」への基準
アクセスを有する。周辺ライブラリは局所ユーザコミュ
ニティへの興味の一般的基準とトピックスを含む。専用
ライブラリは専用ユーザの個別化において保持され、か
つ維持される。
【０５２５】ライブラリ作成の第１の段階は、ブロック
５０２においてパフォーマンス記録、分析、及び「治
療」データを集めることにある。前提条件の記録／再生
ツールを使って、パフォーマンス「科学者」は彼らのシ
ステムの種々の構成を行なうことに努め、かつCPU 、メ
モリ、ディスク、ネットワークその他の生パフォーマン
スデータの利用法の記録を行なう。記録は、人工的に構
築された「イン・ビトロ（試験管）」実験か、又はパフ
ォーマンス問題の生きた「イン・ビボ（生体内）」フィ
ールド監視であった病理学のケースについて行なわれ
る。第１の段階５０２の期間は、殆ど全ての記録が新し
い監視である。記録データベース（DB）が成長するにつ
れて、公知の病理学によってグループ化され得る追加監
視が圧縮された形式で保管され、これによって統計プロ
ファイルがブロック５０６において捕獲されたデータか
ら発生し得る。独特の新しい監視が第２の段階５０４に
おいて処理される。
【０５２６】ライブラリ作成の第２の段階は、記録デー
タをライブラリに入力する前に、ブロック５０８におい
て、記録データをシステマチックに記述し、注釈し、分
析し、項類化し、ネーミングし、かつ操作することであ
る。二つの主要カテゴリは、「健康」データベースと
「疾病」データベースである。この第２の段階は、ブロ
ック５１０において、各記録への病理学的影響を検出
し、かつ関連付けることによって、記録を、これら二つ
の主要カテゴリへ分類する。例えば、記録は、アイドル
状態である時に100 ％の CPUユーティライゼーションに
おいて実行される「暴走(run away)」プロセスを示すこ
ともある。或いは、「スラッシング」記録が、メモリ制
約付きシステムにおいて大規模な常駐セットメモリ必要
条件を有するプロセスに対して過度のディスクページン
グを示すこともある。「健康」（ブロック５１２）又は
「疾病」（ブロック５１４）のデータベース内に配置さ
れる前に、これらのシナリオにおけるキー特徴因子は、
記述され、記録に注釈が付けられ、項類化され、恐らく
フィルタリングされ、圧縮され、基準化され、他の公知
の現象と相関する。
【０５２７】ライブラリ作成の第３の段階は、識別され
た「疾病」に対する公知の治療法の収集である。多くの
疾病は以下のような周知の治療法を有する。例えば、暴
走プロセスを「消去」又はキャンセル／停止し、CPU が
オーバーロードされた場合はより高速のプロセッサを追
加し、システムが常にスラッシングしている場合はより
多くのメモリを追加し、大幅に断片化したディスクを非
断片化させ、疾病データスループットをボトルネックし
た時にバッファの数と大きさを増加させる等。この段階
５１８は治療に対する疾病の相関と連係を含む。未知の
治療に関しては、さらなる研究と分析がブロック５２０
において推薦され、かつブロック５２２において新しい
監視がなされる。
【０５２８】病理学ライブラリが確立された後、このラ
イブラリは、ライブラリユーザにとって有用である有効
なアクセスメカニズムを必要とする。ユーザ自身による
生パフォーマンス記録は限定された利用性を有し、かつ
特定のグループの人々ためにのみ存在する。主要探索メ
カニズムは、本明細書中に背景資料として参照されるこ
とによって組み込まれている1991年の“Oracle for IBM
RISC System/6000 Installation and user's Guide ”
( パーツ番号 5687-v.0.31の6.0 バージョン)に記述さ
れている Oracle Relational Data Base Management Sy
stem(RDBMS) （オラクルカンレンデータベースマネージ
メントシステム）のような、この分野において一般的に
公知である従来のコンピュータベースの問い合わせデー
タベースである。データベースは各記録において全ての
キー情報を有する。記録それ自体はまだ元の観察者のマ
ーキング及び注釈を有しているが、この記録の目立った
特徴は探索データベースの一部であることを必要とす
る。
【０５２９】ユーザは以下のように記録索引を探索する
ことができる。 ・ 病理学のカテゴリ／クラスによって ・ＣＰＵ ・メモリ ・ディスク ・ページング ・ネットワーク ・文字Ｉ／Ｏ（入／出力） ・ 公知の「疾病」の「ネーム」によって ・ＣＰＵオーバーロード ・メモリリーク ・ディスク断片化 ・スラッシング ・ネットワークビーコニング ・超過エラー再試行 ・超過パスレングス ・不均衡資源ユーティライゼーション ・フォークループ ・ 兆候によって ・不良キーボード応答 ・低速ディスプレイ更新による低スループット ・Ｉ／Ｏバウンド ・ 「記録パターン」によって ・公知の事象に対応する図形又は算術的パターン
【０５３０】所望される記録を識別した後、ユーザは、
データの再生、試験、及び分析のための記録に容易にア
クセスすることができる。
【０５３１】これらのパフォーマンス「疾病」のための
「治療」が見つかった時、それらもデータベース内に記
憶され、かつ対応する疾病（単数又は複数）にリンクさ
れる。新しい「健全な」応答の記録も記憶され、これに
よってユーザは、「治療法」の適用後にこのシステムが
どのように見えるかを調べることができる。監視がより
正確になると、自動データフィルタは、データ分析プロ
セスを自動化するのを補助するようにデータパターンを
自動的に相関及び相互相関するために使用される。デー
タフィルタは、各サンプルポイントにおいて特定のシス
テムパフォーマンスデータをとり、かつこれらのデータ
値がいくつかの公知の病理学的パターンに相関し得るか
否かを調べるために相関手続きを介してそれを実行す
る。フィルタリングプロセスは、個々の抽出された値の
他に、データ傾向を照合させるように、ある時間にわた
るデータを抽出することを必要とする。フィルタリング
プロセスはデータ変数の算術的演算子とブール演算子の
結合を含む。データフィルタは警報又はいくつかの他の
ユーザ指定プロセスをセットオフする値を発生し得る。
例えば、データフィルタはホストマシンのページングス
ペースが１０％のフリースペースより小さい時、又はフ
リーページングスペースの１００ページより少ない時、
警報（alarm ）をセットし得る。このシナリオに対する
フィルタ手続きは以下の方法で表現される。
【０５３２】 alarm ＝(PagSp%free < 10) ｜｜(PagSp free < 100)
【０５３３】フィルタも、広範囲のロードの下で最適の
システムパフォーマンスに対して自動的に同調するフィ
ードバックシステムへワイヤリングされ得る。データフ
ィルタの出力は、システムパフォーマンスを変更し、か
つ改善するために、仕様パフォーマンスから検出し、か
つそのデータをパフォーマンス同調システムコンポーネ
ントへフィードバックするために使用され得る。このフ
ィードバックシステムの実施例は、データフィルタが、
通信バッファのオーバーランをモニタし、かつ検出し、
次いで以下に示されているようにシステムの新たなピー
クデマンドに合わせてバッファのサイズを大きくするた
めにそのデータを使用することである。
【０５３４】データ削減及び警報 追加ツールが、例えば、ある条件が満足された時のコマ
ンドなどの所望される統計及び開始動作を抜き出すとき
にさらなるフレキシビリティを許容するために提供され
る。以下に、ユーザが、データ削減によって現存統計か
ら新しい統計を定義し、かつユーザ定義条件によってト
リガされる警報を定義するのを許容する特別なユーティ
リティを記述しており、これによっていかなる所望のコ
マンドも実行され得る。
【０５３５】実行は、図３６に示されているように、fi
ltd （データフィルタ）５６０と呼ばれるユーティリテ
ィである。それは前述されているアプリケーションプロ
グラミングインターフェース１６０及び２４０を使用し
ており、動的データ提供者及びデータ消費者として振る
舞う。ユーティリティはブロック５６２において局所シ
ステムのxmservd デーモンから統計を読み取り、かつブ
ロック５６４において新しい統計をxmservd へ戻し定義
する。filtd ユーティリティも、ユーザが、コマンド５
７０の実行をトリガするために、ブロック５６８におい
て条件を定義するのを可能とする。条件は、xmservd か
らの生の統計５７２に依存するだけでなく、ユーティリ
ティのデータ削減部分５６６によって定義された新しい
統計５７４にも依存する。
【０５３６】フィルタリングされかつ警告された統計は
正規のシステム統計である。しかしながら、これらの統
計は、前述されたDDS インターフェースへxmservd を用
いて特定マシンにおいて実行されるアプリケーション、
即ちユーザ発生プログラムによって定義される統計でも
ある。これによって、アプリケーションプログラムは、
たとえモニタリングされるその特定の統計がフィルタリ
ングと警報ユーティリティにとって現在は未知であって
も、現存のフィルタリング及び警報システムに容易に追
加される。アプリケーションプログラムは、それ自体の
アプリケーション統計及び／又はシステム統計のための
それ自体のフィルタリング及び警報条件を追加するため
に、構成ファイル（以下に定義されている）を単に変更
するだけである。
【０５３７】filtd ユーティリティはデーモンとして実
行するように設計されている。それは三つのコマンドラ
イン引き数をとり、その全てがテーブル６４に示されて
いるようにオプショナルである。 ------------------------------------------------------------------------ filtd −f config file −1 log file −p trace level ------------------------------------------------------------------------ テーブル６４ filtdに対するコマンドライン引き数 −f デフォルト構成ファイルネームをオーバライ
ドする。このオプションが提供されていないならば、フ
ァイルネームは /usr/lpp/xmservd/filter.cf.であると
仮定される。構成ファイルとは、filtd がどのデータ削
減及びどの警報の定義が所望されるかが伝えられる場所
である。 −1 （より低いケースＬ）プログラムによって使
用されるlog （ログ）ファイルのネームをオーバーライ
ドする。デフォルトネームは、ロギングは交互にファイ
ル/usr/lpp/xmservd/filter.log1か/usr/lpp/xmservd/f
ilter.log2になる意味として理解される/usr/lpp/xmser
vd/filter.log である。指定されたいかなるファイルネ
ームも同様に処理される。 −p log （ログ）ファイルに書き込まれた詳細の
レベルを指定する。トレースレベルは１乃至９でなけれ
ばならない。トレースレベルが高くなればなる程、より
多くの詳細がログファイルに書き込まれる。このオプシ
ョンが指定されなかった場合、トレースレベルはゼロに
セットされる。
【０５３８】図３７に関しては、filtd （データフィル
タ）が開始された時、ブロック５８０において、filtd
は、局所xmservd デーモンによって登録するように、RS
iOpen( )呼び出しをすぐに出す。ブロック５８２におい
て、これが、filtd がまだ実行されてない場合xmservd
を開始させる。ブロック５８４においてxmservd への首
尾よい連結に従って、次いでfiltd はブロック５８６に
おいて構成ファイルを読み取り、かつブロック５８８に
おいてこのファイルに供給された情報をパーズする。
【０５３９】構成ファイル１１０は、現存のファイルか
ら新しい統計を定義するか、又は統計から警報を定義す
る表現を含む。ある表現をパーズしている間に統計のネ
ームと出会うたびに、ブロック５９０においてそのネー
ムが有効か否かがxmservd デーモンによってチェックさ
れる。有効でないならば、ブロック５９２において表現
全体が廃棄され、かつfiltd は、ブロック５８６におい
て、もしあれば、構成ファイル内で次の表現をパーズす
るために進行する。検出されたエラーはログファイルへ
報告される。
【０５４０】ブロック５８６において決定されるよう
に、全ての表現がパーズされた時、filtd はブロック５
９４において新しい統計を定義する全ての表現を処理す
る。第１に、filtd は、xmservd によって新しい統計を
組み立てることを必要とするその統計に対する加入を記
録する。次いでfiltd は動的データ提供者としてxmserv
d によって記録する。この時点で、filtd は統計の消費
者でありかつ提供者である。この初期化段階の終わりで
は、filtd は、ブロック５９６においてfiltd が加入し
た統計送りを開始するようxmservd に命令する。
【０５４１】ブロック５９８において、初期化段階の最
終段階は、（テーブル６６において定義されるように）
いかなる警報定義をもパーズする。新しい統計はこの時
点では定義されない。警報は前の段階即ち表現のパージ
ングによって定義される統計に関する。
【０５４２】新しい統計がfiltd 構成ファイルを介して
定義される時はいつも、生データ統計は、最初はxmserv
d から５秒おきに要求される。データ消費者プログラム
が新しい統計に加入していない間は、抽出インターバル
は５秒か、以下に示されている警報継続期間のための最
低の必要条件に一致するように要求される値より小さな
値のままである。
【０５４３】他のデータ消費者プログラムが一つ以上の
新しい統計に加入する時、抽出（サンプリング）間隔は
最も速い抽出を必要とするデータ消費者プログラムと一
致するように調整される。再び、警報の継続期間の必要
条件がより小さなインターバルを口述する場合、新しい
インターバルが選択される。
【０５４４】大部分の目的に関しては、抽出インターバ
ルは２秒又はそれ以上に安全にセットされ得る。もし３
０個の新しい統計が定義されたが、一つの統計だけが加
入した場合は、データ送りが加入された統計に対して伝
送される度に３０個全部が計算される。
【０５４５】filtd は動的データ提供者プログラムであ
るので、xmservd デーモンが実行する時は常にそれを実
行させることが好ましい。これは、一つの行をxmservd
構成ファイルに追加し、かつfiltd プログラム及び任意
のコマンドライン引き数の完全なパスネームを指定する
ことによって発生されることができる。例えば、 /usr/bin/filtd −p5
【０５４６】項データ削減が使用されたにもかかわら
ず、filtd のデータ削減機能５６６は実際に正反対のこ
とを実行するために使用され得る。所望されるだけの新
しい統計が定義され得る。しかしながら、データ削減機
能は、結合値の合理的なセットに対する統計の大きな数
を削減することが最も一般的に使用される。
【０５４７】多くの新しい統計を定義するにせよ、現存
の統計をもっと少ない新しい統計へ結合するにせよ、表
現は構成ファイルへ入力される。新しい統計を定義する
ための表現の一般的な形式はテーブル６５に示されてい
る。 ------------------------------------------------------------------------ target＝expression description（ターゲット＝表現記述） target（ターゲット）: 非現存変数の非修飾ネーム。アルファベットから開始されなければなら ず、英数字とパーセント符号だけを有する。 expression（表現）： ｛ variable ｜wildcard｜const ｝operator｛variable｜ wildcard｜const ｝... variable（変数）: 下線と置換されるスラッシュを有する完全修飾xmperf変数ネーム; 有効ネ ームは少なくとも一つの下線を有する。各ネームコンポーネントはアルフ ァベットから開始し、かつ英数字とパーセント符号だけを有する。参照さ れた変数はすでに存在している（この構成ファイル内では定義されること ができない）。 wildcard（ワイルドカード）： 下線と置換されるスラッシュを有する完全修飾xmperf変数ネーム; 有効ネ ームは少なくとも一つの下線を有する。各ネームコンポーネントはアルフ ァベットから開始し、かつ英数字とパーセント符号だけを有するか、又は ワイルドカードでなければならない。ワイルドカード文字はコンテクスト ネームの代わりに出現し、一度だけ出現し、かつ以下の文字 '＋' 、' * ' 、' # ' 、' > ' 、' < ' のうちの一つでなければならな い。 operator（オペレータ）: ｛* 、/ 、% 、＋、−｝の一つ const （定数）： digits .digits（桁） description(記述) ： 定義されたターゲット変数を記述するテキスト。ダブルクォーツに閉じら れる。 ------------------------------------------------------------------------ テーブル６５ filtd によるデータ削減に対する表現形式
【０５４８】この表現は、この表現を明確にするために
必要とされるだけの数の括弧を有する。「ワイルドカー
ド」の使用法に注目されたい。それは一つのネームを有
する所与の統計の複数の例を参照する方法であるが、さ
らに重要なことには、この方法は、この表現をそれが使
用されているシステムの実際の構成とは無関係にする。
例えば、以下の表現が示される。
【０５４９】allreads＝Disk ＋ rblk は異なるマシンの異なる表現の数値を以下のように求め
ることができる。
【０５５０】allreads＝((Disk/cd0/rblk ＋ Disk/hdis
kl/rblk) ＋Disk/hdisk0/rblk) allreads＝ Disk/hdisk0/rblk 表現において指定された全ての数の定数は浮動少数点と
して値が求められる。同様に、結果的に生じる新しい統
計（「ターゲット」）も常に浮動少数点として定義され
る。
【０５５１】全ての新しい統計は、“avgload ”と呼ば
れる新しい統計が“Filters/avgload ”としてデータ消
費者プログラムへ認識されるように、「フィルタ（Filt
ers）」と呼ばれるコンテクストへ追加される。
【０５５２】上記（テーブル４６及びその記述）のよう
に、xmservd によって提供される統計はタイプSiCounte
r 又はタイプSiQuantityのいづれかのものである。表現
におけるこの二つのタイプは新しい統計を定義するため
に結合され得るが、結果的に生じる統計は一般的にタイ
プSiQuantityのものとして定義される。
【０５５３】これは、新しい統計を定義しかつ変換する
ために理解されるべき結果を有する。それがどのように
動作するかを調べるために、カウンタとして定義される
生統計値があると仮定されたい。「ウィジット」と呼ば
れる生統計に対するデータ送りが２秒間隔で受け取られ
る場合、以下のテーブルが得られる。
【０５５４】 経過秒 カウンタ値 デルタ値 計算された 速度／秒 -------- ---------- --------- ---------------- 0 33,206 2 33,246 40 20 4 33,296 50 25 6 33,460 164 82 8 33,468 8 4 10 33,568 100 50 新しい統計が以下の表現によって定義される場合、 ガジェット＝ウィジット となり、パフォーマンスツールがこの新しい統計、即ち
最新のデータ送りが受け取られた時に計算された速度を
モニタするために使用される。以下のテーブルは異なる
ビューイングインターバルによって何が見られるかを示
す。
【０５５５】 １秒 ２秒 4 秒 ４秒 経過秒 インターバル インターバル インターバル 生速度 ------- --------- --------- --------- ------------- 1 ? 2 20 20 3 20 4 25 25 25 23 5 25 6 82 82 7 82 8 4 4 4 43 9 4 10 50 50
【０５５６】上記テーブルの最終コラムは、生カウンタ
値が平均速度で到着するために使用されなかった場合に
４秒インターバルで値がどうなるかを示している。これ
は、明らかに、新しい統計を定義する時に考慮に入れる
必要がある。最良の方法は、使用すべきインターバルを
標準化することである。
【０５５７】要するに、新しい値が定義された時、タイ
プSiQuantityの任意の生の値がそのまま使用されるとと
もに、毎秒当たりの最新の計算された速度がタイプSiCo
unter の生値に対して使用される。
【０５５８】filtd は、それが新しい統計の値５６４を
計算する前に生統計５６２を読み取らなければならない
ので、新しい統計は常に生統計よりも１「サイクル」後
退している。新しい値を計算するために使用された生の
統計と共に、定義された統計を作表するパフォーマンス
ツール計器は、新しい値と生の統計の間に時間のずれを
示す。
【０５５９】xmservd デーモンは、cpu 資源の使用を四
つのグループ、kernel、user、wait、及びidleへ分割す
る。もし二つだけのグループ、running 及びnotbusy と
して提供したいと所望される場合、これら二つの新しい
統計は以下の表現によって定義され得る。 running ＝CPU kern＋CPu user“CPU running ” notbusy ＝CPU wait＋CPu idle“CPU not running ”
【０５６０】LAN インターフェースに対する転送された
パケットあたりのバイトの平均数を調べたい場合、以下
のように表現される。
【０５６１】 packsize＝NetIf tr0 ooctet／Netif tr0 opacket ＼ “Average packet size ”
【０５６２】上記の実施例においては、除算子は頻繁に
ゼロであるのが好ましい。ゼロによる除算が試行された
時はいつでも、結果の値はゼロにセットされる。この実
施例は、表現が、バックスラッシュを有する最後の行を
除く各行を終了させることによって一つ以上の行に対し
て継続され得ることも示している。
【０５６３】ネットワークパケットのパーセンテージが
システムにおいてループバックインターフェースを使用
する場合は、以下のような定義が使用され得る。
【０５６４】 localpct＝(NetIf lo0 ipacket ＋NetIf lo0 opacket)* 100 ＼ ／(NetIf ＋ ipacket ＋NetIf ＋ opacket) “Percent of network packets on loopback i/f” 上記はワイルドカードの有用性を図示している。
【０５６５】警報５７１は、トリガすべき動作７０と警
報をトリガするための条件を定義する条件部分を記述し
ている動作部分からなる。警報定義に対する一般的な形
式はテーブル６６に示されている。 ------------------------------------------------------------------------ action＝condition description （動作＝条件記述） action（動作):
【０５６６】
【数１】
【０５６７】 alarm definition: command line , ｛TRAPxx｝, ｛EXCEPTION ｝のうちの 一つ又はそれ以上。
【０５６８】 condition （条件） : bool expression DURATION seconds FREQUENCY minutes SEVERITY xx bool expression: ｛ evariable｜wildcard｜const ｝bool operator｛ evariable｜ wildcard｜const ｝... evariable :下線と置換されるスラッシュを有する完全
修飾xmperf変数ネーム; 有効ネームは少なくとも一つの
下線を有する。各ネームコンポーネントはアルファベッ
トから開始し、かつ英数字とパーセント符号だけを有す
る。参照された変数はこの同じフィルタによって定義さ
れ、この場合、“target（目標）”が新しい統計のネー
ムであるFilters targetとして指定されなければなら
ない。
【０５６９】wildcard （ワイルドカード）：下線と置
換されるスラッシュを有する完全修飾xmperf変数ネー
ム; 有効ネームは少なくとも一つの下線を有する。各ネ
ームコンポーネントはアルファベットから開始し、かつ
英数字とパーセント符号だけを有するか、又はワイルド
カードでなければならない。ワイルドカード文字はコン
テクストネームの代わりに出現し、一度だけ出現し、か
つ以下の文字 '＋' 、' * ' 、' # ' 、' > ' 、' < ' のうちの一つでなければならない。
【０５７０】 bool operator: ｛* 、/ 、% 、＋、−、&&、｜｜、＝、！= 、> 、>=、< 、<=｝ const（定数）： digits . digits description（記述）：定義された警報又はターゲット
変数を記述するテキスト。
【０５７１】 ダブルクォーツ（“ ”）で閉じられる。 ------------------------------------------------------------------------ テーブル６６ filtdによって警報を定義するための形式
【０５７２】二つのキーワードDURATION（継続時間）と
FREQUENCY （度数）は、警報がトリガされる前にある条
件が真のままであるべき時間を決定し、かつ同じ警報の
各トリガリング間に要する分の数を指定するために使用
される。これらのキーワードが指定されなかった場合は
デフォルト値を適用し、キーワードが指定された場合
は、これらは定義された最小値より少なくてはならな
い。デフォルト値及び最小値は以下に示されている。
【０５７３】
【０５７４】トリガされるべき警報に関しては、同じ警
報がトリガされた最終時間から少なくともFREQUENCY 分
が経過しなければならない。この場合、条件は一定して
モニタリングされる。条件が偽から真へスイッチする度
に、タイムスタンプが取られる。条件が真のままである
限り、最終タイムスタンプからの経過時間がDURATIONと
比較され、かつその経過時間がDURATIONと同じか又は超
過した場合は警報がトリガされる。
【０５７５】データ送りインターバルを無理に１秒以下
にさせずに実行される時、filtd は少なくとも三つのデ
ータ送りがDURATION秒後に行なわれることを確認する。
これは必要ならばデータ送りインターバルを変更するこ
とによって行なわれる。たとえ、生統計が新しい統計か
警報のいづれかを定義するにせよ、或いは両方を定義す
るにせよ、filtd プログラムによって受け取られた全て
の生統計に対して使用されている一つだけのデータ送り
インターバルしか存在してないので、データ送り変更の
実行には定義された新しい統計のサイド効果が付随す
る。
【０５７６】警報は実際には警報ではなくともよい。警
報を正常にトリガする条件によって、人間の介入なしで
行なわれる補正動作が提供されればより好ましいことで
ある。このような補正動作の一つの実施例は、UDP オー
バーランの場合に、UDP 受信バッファを増加させること
である。次の「警報」定義は以下に示されている。
【０５７７】
【数２】
【０５７８】no command（コマンドなし）の実行に加え
て送られる特定数３１を有するSNMPトラップを有するこ
とが所望されるならば、警報は以下のように定義され
る。
【０５７９】
【数３】
【０５８０】ホストにおけるページングスペースが、１
０％以下のフリーを有している時、又は１００ページ未
満のフリーページングスペースがある時は必ず、以下の
ような警報定義が使用される。
【０５８１】
【数４】
【０５８２】ある最終的な実施例は、ディスクに対する
平均的最頻（ビジー）パーセントが５秒を超える５０％
を超えた時はいつでも対象となるデータ消費者プログラ
ムへexcept rec を送るように警報を以下のように定義
する。
【０５８３】
【数５】
【０５８４】上記及び実施例から理解されるように、こ
のフィルタリング能力は、フィルタ及び警報が定義され
るだけでなく、警報条件を検出した結果として呼び出さ
れ得る引き続く動作の両方において非常にフレキシブル
である。
【０５８５】プロセス制御 システム及びネットワークパフォーマンス同調（チュー
ニング）の重要なコンポーネントは、システムにおける
任意のノードから実行している間、プロセス実行のコー
スにアクセスしかつ変更するための能力である。実際、
多くのシステムに対して責任を有し、かつ資源だけでな
く問題補正に関わっているシステム管理者にとって、ネ
ットワークを介するプロセスの中心的なモニタリング及
び制御のために容易な機能を所有することは非常に重要
である。このシステム管理者は、システムのネットワー
クを介して仕事の円滑な流れを確実とするためだけでな
く、「病理学的に正気でない」又はむやみに実行されて
しまうプロセスを消去するためにプロセスの優先権を調
整できることが必要である。この制御機能は、システム
管理者が、今行なわれた動作に対するシステムの応答を
すぐに調べるのを許容するライブモニタリング機能に関
連するパフォーマンス管理の重要な構成要素である。
【０５８６】局所及びネットワークプロセスの簡単なシ
ステム管理制御のための方法は以下に示されている。そ
れは、ライブネットワークモニタリング機能と分析ツー
ルのセットが、最適な方法を決定するだけでなく、実行
された動作に対するシステムの応答を監視する際にユー
ザを助けるために利用可能であることが確実とする。ツ
ールのユーザは、局所又は遠隔マシンに対して選択され
たプロセスへ所望される操作を実行するために適切な安
全保護アクセス及び許可を有することも確実とする。好
ましい実施例においては、Motif 図形ユーザインターフ
ェースは、データ処理システムのディスプレイへの情報
を提供し、かつユーザに単一又は複数のメニュー項目を
選択するのを許容するために使用される。このインター
フェースは、異なるプログラムやプロセスから複数の出
力をディスプレイする重畳ウィンドウを有するユーザイ
ンターフェースを提供することで一般に公知である。さ
らに詳細な情報に関しては、ニュージャージー州、イン
グルウッドクリフ(Englewood Cliffs)、プレンティスホ
ール(Prentice Hall) から入手可能な1991年の改訂版1.
1 であり、本明細書中に参照されることによって組み込
まれている"OSF/Motif Style Guide" を参照されたい。
【０５８７】以下の各ステップは、データ処理システム
の局所又は遠隔ネットワークコンピュータのための基本
的プロセス制御の流れを記述している。 ・ ユーザはユーザインターフェースにおいて「プロセ
ス制御」メニューボタンを選択し、これによってプロセ
ス制御ルーチンを呼び出す。 ・ プロセス制御ルーチンは、局所ホストを含む「ホス
ト」ファイル内のリストに記載されているホスト及びサ
ブネットに対してUDP ネットワーク同報通信を行なう。 ・ プロセス処理ルーチンは、ネットワーク同報通信か
ら受け取られた応答に基づいてユーザに対して利用可能
なネットワークノードのメニューを提供する。 ・ ユーザはメニューから一つ以上のノードを選択す
る。 ・ プロセス制御ルーチンは選択された各ノードへプロ
セスデータに対する要求を送る。 ・ 選択されたノード（単数及び複数）は、この要求を
受け取り、かつ局所プロセステーブル入力を受け取る。
属性による順序又はプロセスが要求された場合、プロセ
スは分類されかつ要求された順序に従ってランキングさ
れる。 ・ 選択されたノード（単数及び複数）は、好ましい実
施例におけるランク順に、プロセス制御ルーチンを備え
る開始ノードに対して選択されたプロセスのスナップシ
ョットを送る。 ・ プロセス制御ルーチンは、ノードごとにプロセスス
ナップショットを受け取る。次いで、プロセス制御ルー
チンは、ユーザが、「オブジェクト」としてプロセスデ
ータにおいて選択しかつ操作するのを許容するため、GU
I （図形ユーザインターフェース）へプロセスデータを
送る。 ・ ユーザは、例えば、プロセスID(PID) 、プロセスネ
ーム、プロセス優先順位、プロセス所有者のユーザid、
プロセスメモリユーティライゼーション（利用）、CPU
ユーティライゼーション、ページフォルト（不在）、そ
の他のような特定カテゴリ又はプロセスパラメータによ
って、プロセスデータのメニューを再度順序付けるため
に、"sort(分類)"ボタンを選択することができる。 ・ GUI は、どのカテゴリに分類すべきかをユーザが選
択するために選択ボタンの第２のセットへ"sort(分類)"
ボタンを拡張する。ユーザが分類するためにカテゴリを
選択した後、ランキングは、そのカテゴリにおけるデー
タのタイプに応じて英数字で行なわれる。次いで、分類
されたデータはGUI によって再度ディスプレイされる。 ・ ユーザは、最新のデータ値を得るためにプロセスデ
ータの「リフレッシュ（復元）」スナップショットを要
求することができる。リフレッシュは、プロセスが連続
的にモニタリングされていない時、遠隔プロセス情報に
対して特に有用である。 ・ ユーザは、メニューから一つ以上のプロセスを選択
し、かつこれらのプロセスにおいて実行すべき、優先順
位を上下させたり、プロセスを消去したり、より詳細な
統計を得たりなどの動作を選択する。 ・ プロセスが局所である場合、プロセス制御ルーチン
は、ユーザが認証されており、かつ選択された各プロセ
スに対して選択された動作を実行するように許可されて
いることをチェックする。このテストが渡された場合、
選択された動作は選択されたプロセスごとに実行され
る。実行される動作はユーザによって選択され得るコマ
ンドバーオプションにおいて定義される。例えば、ユー
ザによって選択された複数のプロセスid(PIDs)を取る"k
ill process(消去プロセス)"を選択し、次いで選択され
たプロセスを「消去」するために、それらをシステム "
kill（消去）" コマンドへ渡す。GUI は選択されたコマ
ンドを変換し、次いでこの情報を構成サブシステムへ渡
し、これによって構成サブシステムは選択されたコマン
ドのシステムの呼び出す。プロセスが遠隔である場合、
プロセス制御ルーチンは、遠隔ホストのエージェント
（デーモン）へその要求を伝送し、これによってエージ
ェント（デーモン）は、要求者のID及び権限をチェック
し、要求を実行し、かつ結果を要求プロセス制御ルーチ
ンへ戻す。 ・ 遠隔ホストがユーザ指定要求を受け取る時、このホ
ストは開始ユーザによって指定されたパラメータ及びコ
マンドを取り、かつそれらを局所システムで実行される
ように当該局所システムへ渡す。上記の実施例における
ように、遠隔ホストは選択されたプロセスID(PID) に対
する消去要求を受け取り、次いで選択されたプロセスを
消去するために、遠隔システムの「消去」コマンドへ要
求を渡す。
【０５８８】データ処理システム 図３９は、すべてが共通経路であるバス６１２を介して
相互接続されている、CPU ６１０、ランダムアクセスメ
モリ（RAM ）及びリードオンリーメモリ（ ROM）６１
４、原型（プロトタイプ）アダプタ６１６、Ｉ／Ｏアダ
プタ６１８、ユーザインターフェースアダプタ６２２、
通信アダプタ６３４、並びにディスプレイアダプタ６３
６を備える本発明の好ましい実施例を示している。上記
の各構成要素は、当業者に公知の従来の技術を用いて共
通のバスにアクセスし、かつCPU をバスマスターとして
システムにおける各構成要素に対して特定の範囲を専用
とするような方法を含む。他の当業者に公知の従来の技
術は、DASD６２０又はネットワーク６３０のような外部
デバイスからデータ処理システムのRAM ６１４へデータ
を高速で転送するために使用される直接メモリアクセ
ス、DMA を含んでいる。図３９に詳細に示されているよ
うに、これらの外部デバイス６２０及び６３０はそれぞ
れのアダプタ６１８及び６３４を介して共通のバス６１
２へインターフェースする。ディスプレイ６３８のよう
な他の外部デバイスは、バス６１２とディスプレイ６３
８を介してデータフローを提供するためにアダプタ６３
６を同様に使用する。ユーザインターフェース手段は、
ジョイスティック６３２、マウス６２６、キーボード６
２４、及びスピーカ６２８のようなアイテム（品目）が
取り付けられているアダプタ６２２によって提供され
る。
【０５８９】好ましい実施例において、CPU ６１０はRI
SCマイクロプロセッサであり、それはバス６１２に沿っ
て延出する６３２ビットデータパスを備える。他のマイ
クロプロセッサやマイクロコントローラが本発明の範囲
や精神から逸脱することなく、このCPU の代わりに同様
に使用することができる。好ましい実施例における原型
アダプタ６１６は、NMI 信号を発生するためにウォッチ
ドッグタイマとして使用されるタイマーを含む。他の実
施例は、当業者に公知の多数のマイクロコントローラ
（例えば、インテル8051）によって実行されるように、
CPU ６１０の内部にタイマーを含んでいる。さらに他の
実施例では、CPU ６１０の外部にあるが、CPU ６１０を
保持する同一カード／母板上に含まれているタイマーを
含む。さらに、タイマー関数（機能）は、他のアダプタ
ーカード６１８、６２２、６３４、又は６３６上に存在
し得る他のシステムタイマーを用いて発生される。例え
ば、ユーザインターフェースアダプタは、スピーカ６２
８を駆動させるために矩形の波形を発生する際に使用さ
れるインテル8253のようなタイマーモジュールを有す
る。このタイプのタイマーモジュールは複数の内部モジ
ュールを有しており、これによってこのモジュール内の
未使用タイマーは CPU６１０の NMI信号を発生するため
に使用され得る。回路を発生タイマーの特定位置が、出
願人が請求した発明を達成し又は実行するためにクリテ
ィカル（臨界）ではないことがポイントである。
【０５９０】
【発明の効果】本発明は、データ処理システムに高度に
フレキシブルな解析ツールを提供する。
【図面の簡単な説明】
【図１】パフォーマンスツールを備えるサブシステム構
成素子を示す図である。
【図２】記録ファイルに対する再生及び記録システムイ
ンターフェースを示す図である。
【図３】システムと構成サブシステムとの対話を示す図
である。
【図４】システムとデータディスプレイサブシステムと
の対話を示す図である。
【図５】システムと記録サブシステムとの対話を示す図
である。
【図６】システムと再生サブシステムとの対話を示す図
である。
【図７】システムとデータ値受信者サブシステムとの対
話を示す図である。
【図８】システムとネットワーク送信／受信サブシステ
ムとの対話を示す図である。
【図９】記録サブシステムの動作のフローチャートであ
る。
【図１０】総合パフォーマンスツールシステムに対する
記録サブシステムインターフェースを示す図である。
【図１１】種々のメニュー選択からの許容動作を示す表
である。
【図１２】パフォーマンスツールによって発生される種
々のディスプレイを示す図である。
【図１３】パフォーマンスツールによって発生される種
々のディスプレイを示す図である。
【図１４】パフォーマンスツールによって発生される種
々のディスプレイを示す図である。
【図１５】パフォーマンスツールによって発生される種
々のディスプレイを示す図である。
【図１６】パフォーマンスツールによって発生される種
々のディスプレイを示す図である。
【図１７】総合パフォーマンスツールシステムに対する
再生サブシステムインターフェースを示す図である。
【図１８】複数のデータ処理システム同士間の並行動作
を示す図である。
【図１９】再生サブシステムの内部動作のフローチャー
トである。
【図２０】データディスプレイサブシステムの内部動作
のフローチャートである。
【図２１】構成サブシステムの内部動作のフローチャー
トである。
【図２２】データ値受信者サブシステムの内部動作のフ
ローチャートである。
【図２３】ネットワーク送信／受信インターフェースの
内部動作のフローチャートである。
【図２４】図形ユーザインターフェースの内部動作のフ
ローチャートである。
【図２５】総合パフォーマンスツールシステムに対する
図形ユーザインターフェースサブシステムのインターフ
ェースを示す図である。
【図２６】データ提供者デーモンと動的データ提供者の
インターフェースを示す図である。
【図２７】データ提供者デーモンの内部動作のフローチ
ャートである。
【図２８】xmpeekユーティリティの内部動作のフローチ
ャートである。
【図２９】総合パフォーマンスツールシステムに対する
データ提供者デーモンインターフェースを示す図であ
る。
【図３０】付録Ａの表（図３１及び図３２）に記載され
ているサンプルプログラムから発生される出力の例を示
す図である。
【図３１】追加タイプのデータを供給するように拡張を
提供するためにデーモンアプリケーションプログラミン
グインターフェースを使用する動的データ提供者プログ
ラムのＣ言語プログラムである。
【図３２】追加タイプのデータを供給するように拡張を
提供するためにデーモンアプリケーションプログラミン
グインターフェースを使用する動的データ提供者プログ
ラムのＣ言語プログラムである。
【図３３】データの注釈及びマーキングのための内部動
作のフローチャートである。
【図３４】データの注釈及びマーキングのための内部動
作のフローチャートである。
【図３５】病理学的ライブラリシステムに対する内部動
作のフローチャートである。
【図３６】パフォーマンスツールのフィルタリングと警
報の能力のブロック図である。
【図３７】フィルタリングとフィルタリングされた警報
ユーティリティの内部動作のフローチャートである。
【図３８】注釈を支持するためのマーカートークンを有
するデータ記録ファイルを示す図である。
【図３９】本発明の好ましい実施例のデータ処理システ
ムを示す図である。
【符号の説明】
６１０ CPU ６１４ RAM 及び ROM ６１６ 原型アダプタ ６１８ Ｉ／Ｏアダプタ ６２２ ユーザインターフェースアダプタ ６３４ 通信アダプタ ６３６ ディスプレイアダプタ
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ニールズ クリスチャンセン アメリカ合衆国78758、テキサス州オース ティン、クエイル パーク ドライヴ 1015 (72)発明者 ジョゼフ クリントン ロス アメリカ合衆国78628、テキサス州ジョー ジタウン、ウエスト エスパラダ 203 (72)発明者 アルバート テランス ロワン アメリカ合衆国78729、テキサス州オース ティン、ハムフリー ドライヴ 13100

Claims (8)

    【特許請求の範囲】
  1. 【請求項１】 データ処理システムの記録されたシステ
    ムパラメータデータを図形コンテクスト内にディスプレ
    イする方法であって、 前記データ処理システムから前記記録されたシステムパ
    ラメータデータを読み取るステップと、 情報をディスプレイするためのディスプレイ手段上に可
    変速度で前記システムパラメータデータをディスプレイ
    するステップと、 を備えるディスプレイ方法。
  2. 【請求項２】 データ処理システムの記録されたシステ
    ムパラメータデータを図形コンテクスト内にディスプレ
    イする方法であって、 前記データ処理システムから前記記録されたシステムパ
    ラメータデータを読み取るステップと、 情報をディスプレイするためのディスプレイ手段上に指
    定された可変速度で前記記録されたシステムパラメータ
    データのある部分をディスプレイするステップと、 を備えるディスプレイ方法。
  3. 【請求項３】 図形コンテクスト内にデータ処理システ
    ムのシステムパラメータデータをディスプレイする方法
    であって、 情報をディスプレイするためにディスプレイ手段上に前
    記システムパラメータデータのある部分をディスプレイ
    するステップと、 前記ディスプレイ手段上に前記システムパラメータデー
    タの第２の部分をディスプレイし、かつ新しいノードに
    対してオブジェクトを再マウントすることによって、前
    記第２の部分に対応するパラメータデータコンテクスト
    変更するステップと、 を備えるディスプレイ方法。
  4. 【請求項４】 データ処理システムの記録されたシステ
    ムパラメータデータを図形コンテクスト内にディスプレ
    イするためのシステムであって、 前記データ処理システムから前記記録されたシステムパ
    ラメータデータを読み取るための手段と、 情報をディスプレイするためのディスプレイ手段上に指
    定された可変速度で前記システムパラメータデータをデ
    ィスプレイするための手段と、 を備えるディスプレイシステム。
  5. 【請求項５】 データ処理システムの記録されたシステ
    ムパラメータデータを図形コンテクスト内にディスプレ
    イするためのシステムであって、 前記データ処理システムから前記記録されたシステムパ
    ラメータデータを読み取るための手段と、 情報をディスプレイするためのディスプレイ手段上に指
    定された可変速度で前記記録されたシステムパラメータ
    データのある部分をディスプレイするための手段と、 を備えるディスプレイシステム。
  6. 【請求項６】 データ処理システムのシステムパラメー
    タデータを図形コンテクスト内にディスプレイするため
    のシステムであって、 情報をディスプレイするためのディスプレイ手段上に、
    前記システムパラメータデータのある部分をディスプレ
    イするための手段と、 前記ディスプレイ手段上に前記システムパラメータデー
    タの第２の部分をディスプレイし、かつ新しいノードへ
    オブジェクトを再構築することによって、前記第２の部
    分と対応するパラメータデータコンテクストを変更する
    ための手段と、 を備えるディスプレイシステム。
  7. 【請求項７】 データ処理システムの同一パフォーマン
    ス統計の複数のビューを同時ディスプレイするための方
    法であって、 ある抽出インターバルにおいてシステム統計の第１のサ
    ンプル値を捕獲するステップと、 異なる抽出インターバルにおいて前記システム統計の第
    ２のサンプル値を捕獲するステップと、 データをディスプレイするためのディスプレイ手段上に
    前記第１のサンプル値と前記第２のサンプル値を同時に
    ディスプレイするステップと、 を備える同時ディスプレイ方法。
  8. 【請求項８】 データ処理システムの同一パフォーマン
    ス統計の複数のビューを同時ディスプレイするためのシ
    ステムであって、 ある抽出インターバルにおいてシステム統計の第１のサ
    ンプル値を捕獲するための手段と、 異なる抽出インターバルにおいて前記システム統計の第
    ２のサンプル値を捕獲するための手段と、 データをディスプレイするためのディスプレイ手段上に
    前記第１のサンプル値と前記第２のサンプル値を同時に
    ディスプレイするための手段と、 を備える同時ディスプレイシステム。
JP5238545A 1992-10-23 1993-09-24 ディスプレイ方法及びディスプレイシステム Pending JPH06208487A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US96595992A 1992-10-23 1992-10-23
US965959 1992-10-23

Publications (1)

Publication Number Publication Date
JPH06208487A true JPH06208487A (ja) 1994-07-26

Family

ID=25510731

Family Applications (1)

Application Number Title Priority Date Filing Date
JP5238545A Pending JPH06208487A (ja) 1992-10-23 1993-09-24 ディスプレイ方法及びディスプレイシステム

Country Status (2)

Country Link
JP (1) JPH06208487A (ja)
CA (1) CA2099414A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010016332A1 (ja) * 2008-08-07 2010-02-11 ソニー株式会社 通信装置、通信方法、及びプログラム

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5615323A (en) 1994-11-04 1997-03-25 Concord Communications, Inc. Displaying resource performance and utilization information
US6516348B1 (en) 1999-05-21 2003-02-04 Macfarlane Druce Ian Craig Rattray Collecting and predicting capacity information for composite network resource formed by combining ports of an access server and/or links of wide arear network
US6754704B1 (en) 2000-06-21 2004-06-22 International Business Machines Corporation Methods, systems, and computer program product for remote monitoring of a data processing system events
CN110057375B (zh) * 2012-06-05 2023-11-14 耐克创新有限合伙公司 用于提供路线信息和热图的活动监测系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01173139A (ja) * 1987-12-23 1989-07-07 Internatl Business Mach Corp <Ibm> 複数タスク状態表示方法
JPH02129979A (ja) * 1988-11-09 1990-05-18 Toshiba Corp マイクロ波レーザ装置
JPH0452753A (ja) * 1990-06-14 1992-02-20 Fujitsu Ltd 分散型監視制御システムの負荷状態表示方式
JPH04149740A (ja) * 1990-10-15 1992-05-22 Toshiba Corp ガイダンス表示方式
JPH04260137A (ja) * 1991-02-14 1992-09-16 Oki Electric Ind Co Ltd 情報処理装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01173139A (ja) * 1987-12-23 1989-07-07 Internatl Business Mach Corp <Ibm> 複数タスク状態表示方法
JPH02129979A (ja) * 1988-11-09 1990-05-18 Toshiba Corp マイクロ波レーザ装置
JPH0452753A (ja) * 1990-06-14 1992-02-20 Fujitsu Ltd 分散型監視制御システムの負荷状態表示方式
JPH04149740A (ja) * 1990-10-15 1992-05-22 Toshiba Corp ガイダンス表示方式
JPH04260137A (ja) * 1991-02-14 1992-09-16 Oki Electric Ind Co Ltd 情報処理装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010016332A1 (ja) * 2008-08-07 2010-02-11 ソニー株式会社 通信装置、通信方法、及びプログラム
JP2010039913A (ja) * 2008-08-07 2010-02-18 Sony Corp 通信装置、通信方法、及びプログラム

Also Published As

Publication number Publication date
CA2099414A1 (en) 1994-04-24

Similar Documents

Publication Publication Date Title
JP2553307B2 (ja) プロセス監視方法
US5483468A (en) System and method for concurrent recording and displaying of system performance data
US5553235A (en) System and method for maintaining performance data in a data processing system
US5506955A (en) System and method for monitoring and optimizing performance in a data processing system
US10908977B1 (en) Efficient message queuing service
US7434167B2 (en) Accessibility system and method
US7089561B2 (en) Methods and systems for creating and communicating with computer processes
US7941789B2 (en) Common performance trace mechanism
US6671829B2 (en) Method and apparatus for analyzing performance of data processing system
US5887167A (en) Synchronization mechanism for providing multiple readers and writers access to performance information of an extensible computer system
US8037458B2 (en) Method and system for providing a common structure for trace data
KR20060015705A (ko) 사용자 인터페이스 자동화 프레임워크 클래스 및 인터페이스
US5343409A (en) System and method for probing object resources in a window server environment
US7243046B1 (en) System and method for preparing trace data for analysis
CN112181764A (zh) Kubernetes资源数据的监视方法及装置
CN108139961A (zh) 遥测定义系统
CN109739619A (zh) 一种基于容器化应用的处理方法、装置及存储介质
US20040061714A1 (en) Logical element tree and method
JP2549251B2 (ja) ライブ・データ用の注釈記録の作成方法
JPH06208487A (ja) ディスプレイ方法及びディスプレイシステム
Pike 81⁄ 2, the Plan 9 Window System
EP3010194B1 (en) Method of tracing a transaction in a network
US7536376B2 (en) Task oriented log retrieval utilizing a self-learning search tool
JPH10333938A (ja) 計算機システムにおける実行ログの記録、表示方法、ならびに同方法を用いた計算機システム、及び同方法がプログラムされ記録される記録媒体
Scott Unifying Event Trace and Sampled Performance Data