JP3327306B2

JP3327306B2 - シスプレックスおよびデータを報告する方法

Info

Publication number: JP3327306B2
Application number: JP29356594A
Authority: JP
Inventors: ディーテル・コーニグ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1994-02-22
Filing date: 1994-11-28
Publication date: 2002-09-24
Anticipated expiration: 2017-09-24
Also published as: EP0668564A1; JPH07239793A; US5923874A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、接続を通して接続する
複数のオペレーティング・システム・イメージを持ち、
データを報告するためのレポータ機構を含むシスプレッ
クス（sysplex）に関する。レポータ機構は、報告可能
なデータを含むオペレーティング・システム・イメージ
中に、記憶装置内バッファおよびデータ・セットを持
つ。

【０００２】

【従来の技術】多大な処理能力が必要とされるにつれ、
一般に、大きいモノリシック単一プロセッサ・コンピュ
ータを離れ、多数のより小さいプロセッサが一緒に接続
し互いに協力してジョブを処理するシステムに向かう傾
向がある。これらのいわゆる「シスプレックス」環境
は、環境内の各プロセッサがそれ自身のオペレーティン
グ・システムを実行する、すなわち、各プロセッサが、
それ自身のオペレーティング・システム・イメージを持
つ、という特徴を持つ。中央サーバ・プロセッサは、全
オペレーティング・システムにわたって１つの同期タイ
ミング信号を提供する。

【０００３】IBM社は現在、最大８つのMVSイメージがMV
Sクロス・システム接続機構を使用して接続しているシ
スプレックスを、提供している。これは、「Use of XCF
tofacilitate Communication among Independent Proc
esses」、IBM Technical Disclosure Bulletin、vol.
3、no.11、1991年4月、357〜359ページに記述されてい
る。将来的には、オペレーティング・システム・イメー
ジの数を実質的に増やすことが望ましい。オペレーティ
ング・システム・イメージの数を増すことによって、シ
スプレックスが連続的に使用可能であることを保証する
ことができる。というのは、計画されたシステム停止の
影響あるいはシステム故障を、排除するかあるいはエン
ド・ユーザの小さいグループに制限することができるか
らである。より多くのオペレーティング・システム・イ
メージを持つシスプレックスの性能を改善し、さらに拡
張することができる。つまり、ユーザは、より大きい処
理能力を必要とする時、設備全体を改良しなくても、さ
らにイメージを追加するだけでよい。

【０００４】イメージの数が増加すると、イメージ動作
のシステム管理を増やす必要性がでてくる。特に、各オ
ペレーティング・システム・イメージの性能を監視し、
シスプレックスに接続する周辺装置の負荷を測定する必
要がある。シスプレックス中の各イメージのワークロー
ドを監視することによって、システム全体が最適な方法
で機能していることを保証することができる。

【０００５】コンピュータ・システムの性能を監視する
ための様々な装置が、従来技術において知られている。
IBM社は、MVSに基づくシステムに対して、顧客システム
の性能および可用性を測定し報告する、いわゆる資源測
定機構（RMF）を提供している。RMFは、性能問題が起こ
ると、それが重大な問題になる前にインストレーション
・エンジニアが問題を解決できるように報告する。さら
にRMFは、ユーザがシステムを調整し必要な場合より大
きい容量を提供できるように、長期的なシステム測定に
ついての情報を提供することができる。RMFについての
概要は、IBMマニュアルNo. GC28-1028に記述されてい
る。RMFのためのユーザーズ・ガイド No.GC28-1058も市
販されている。必要によりこれらの出版物を参照された
い。

【０００６】同様のプログラムが、Candle、Legent、La
ndmarkおよび他の会社によって提供されている。

【０００７】IBM Technical Disclosure Bulletin、vo
l. 33、no. 4、1990年9月、79〜83ページ、「Computer
System Performance Monitor」には、それ自身の性能を
監視するためにコンピュータ・システムの能力を改善す
る、コンピュータ・システム性能モニタが記述されてい
る。モニタは、システムの性能を分析する、一組の性能
に関する定義された機能を提供する。これは、システム
・ソフトウェアによって直接的に、あるいは、定義され
たインタフェースを通してプロセッサを監視するオプシ
ョンのハードウェアによって、達成される。

【０００８】これらのプログラムは単一イメージ・シス
テムの性能を監視するのには適したツールであるが、上
記のシスプレックスのような複数イメージ・システムを
監視する、より複雑な要求には対処することができな
い。

【０００９】従来技術において、分散データ・システム
環境におけるプロセッサの性能を監視する数多くの方法
が知られている。例えば、IBM Technical Disclosure B
ulletin、vol. 34、no. 6、1991年11月、387〜389ペー
ジ、「Method for Workload Performance Measuremen
t」と題する論文は、ワークロードを測定することがで
きる基礎的なシステム能力を提供する、様々なユーザお
よびシステム・ワーク・アクティビティの組合せからな
る方法を開示している。

【００１０】IBM Technical Disclosure Bulletin、vo
l. 24、no. 3、1991年8月、1416〜1419ページ、「Large
System Performance Monitor」と題する論文は、利用
率を決定し知るためにシステム資源のアクティビティを
分析するモニタを教示している。ここに記述されるモニ
タは、監視されているシステムの性能を妨げないあるい
は劣化させないで、システム資源のアクティビティを分
析することができる。

【００１１】米国特許5/119,493号（US-A-5 119 493）
（Janis その他による）は、システム内の複数のユーザ
からアクセス可能な複数の資源オブジェクトを持つデー
タ処理システム内で、選択的なドキュメント履歴ログを
維持する方法を教示している。履歴ログは生成され、選
択されたアクティビティのドキュメンテーションが必要
な各資源オブジェクトに関連付けられる。アクティビテ
ィのリストは生成され、特定の資源オブジェクトに関し
て起こる全アクティビティをろ過するのに使用される。
この方法を使用すると、重要なアクティビティだけを記
録することができ、メモリ空間を能率的に使用すること
ができる。

【００１２】米国特許5/109,486号（US-A-5 109 486）
（Seymourによる）は、そのローカルな構成プロセッサ
に、全般的なあるいは特定の資源あるいはノードにおい
て変化した状態の通告を要求するメッセージを送信す
る、マネージャを教示している。構成マネージャは、処
理要求メッセージからの情報を含む状態監視ファイル
に、レコードを確立する。この情報から、システムの性
能を分析することができる。

【００１３】WO-A-93/00632（ICL Data AB）は、ローカ
ル・エリア・ネットワークの形で接続する複数のコンピ
ュータからなるコンピュータ・システムの動作を監視し
変化させる方法およびシステムを教示している。システ
ムは、実行が監視されなければならない各実行可能プロ
グラム中に少なくとも１つの事象レポート作成プログラ
ムを含み、事象レポート作成プログラムによって報告さ
れる事象を処理するための事象処理装置を含む。インタ
フェースは、事象レポート作成プログラムによって報告
された事象を事象処理装置に転送するために提供され
る。この装置から、システムの性能に関する情報を得る
ことができる。

【００１４】

【発明が解決しようとする課題】これらの従来技術のシ
ステムはすべて、監視されている資源あるいはプログラ
ムに事象が起こる度に中央監視プログラムに事象を報告
するという不利益がある。このことは、ネットワークに
わたる多量のメッセージ通信量を発生させ、能率を悪く
し、さらに悪いことには、コンピュータ・ジョブの実行
を妨害することがある。

【００１５】

【課題を解決するための手段】これらの不利益は、本発
明による、第１のオペレーティング・システム・イメー
ジにおける第１のデータ・サーバ、報告可能なデータを
含む記憶装置内バッファあるいはデータ・セットを持つ
オペレーティング・システム・イメージにおける、１つ
以上の第２のデータ・サーバによって、解決される。本
発明において、シスプレックスが動作中である時、第２
のデータ・サーバは要求を受け取ると、データ・セット
から報告可能なデータを収集し、それを接続を通して第
１のデータ・サーバへ渡し、第１のデータ・サーバはそ
れをレポータ機構に渡す。

【００１６】本発明においては、報告可能なデータは、
要求された時に第１のオペレーティング・システム・イ
メージにのみ渡されるので、従来技術を上回る利益があ
る。つまり、連続的なデータ通信量が避けられ、シスプ
レックス上の負荷、特にオペレーティング・システム・
イメージ間の接続上の負荷が少ない時に、データを要求
することができる。データ通信量が減少すると、オペレ
ーティング・システム・イメージ間の接続をより効率的
に利用することができる。

【００１７】レポータ機構は、各オペレーティング・シ
ステム・イメージ中に２つの型のデータ・セットを持つ
ことができ、報告可能なデータを収集する要求は、どち
らのデータ・セットに報告可能なデータがあるかを指示
する。

【００１８】本発明の他の実施例において、レポータ機
構は、報告可能なデータが記憶される、第１のデータ・
サーバによって生成される応答領域を含む。応答領域に
より、報告可能なデータを処理する時、効率的にデータ
を返還することができる。例えば外部媒体にデータを記
憶すると、レポータ・プロセッサによるデータの処理が
遅くなる。

【００１９】レポータ機構は、シスプレックス内の資源
を監視するための監視機構中に、特定のアプリケーショ
ンを持つ。シスプレックスにおいて、データ・セットは
シスプレックス内の資源の使用および負荷に関連するデ
ータを含む。

【００２０】シスプレックスの資源を監視することによ
って、資源の使用および資源上の負荷を決定することが
でき、その結果、各資源によって実行される作業を調整
することができる。このことは、複数のオペレーティン
グ・システム・イメージを持つシスプレックスにおいて
特に重要である。というのは、プログラムの処理は、そ
れがオペレーティング・システム・イメージの１つで実
行されている間ホールドされ、他のイメージは使用され
ないままであるからである。

【００２１】

【００２２】本発明の他の実施例において、本方法は以
下のステップを含む。第１のオペレーティング・システ
ム・イメージから、どのオペレーティング・システム・
イメージ中に報告可能なデータがあるかを示す検索基準
を持つ要求を送信する第１のステップ、検索基準とオペ
レーティング・システム・イメージ中の報告可能なデー
タを突き合わせる第２のステップ、報告可能なデータが
あるオペレーティング・システム・イメージのイメージ
・リストを第１のオペレーティング・システム・イメー
ジに返す第３のステップ、イメージ・リストを使用し
て、オペレーティング・システム・イメージに報告可能
なデータを収集する要求を送信する第４のステップ、報
告可能なデータを第１のオペレーティング・システム・
イメージに返す第５のステップ、報告可能なデータを第
１のオペレーティング・システム・イメージ中に生成さ
れた応答領域に記憶する第６のステップ。

【００２３】レポータ機構の使用は、資源監視機構内の
アプリケーションに制限されない。１つのオペレーティ
ング・システム・イメージにより他のオペレーティング
・システム・イメージからデータを収集し照合しなけれ
ばいけない任意のシスプレックス中のアプリケーション
も、レポータ機構を使用することができる。

【００２４】

【実施例】図１は、測定機構を含むシスプレックス10の
概要図である。シスプレックス10は、複数のオペレーテ
ィング・システム・イメージ20a、20b、20c、20dを持
つ。見やすくするために、図１においては４つのオペレ
ーティング・システム・イメージのみが示される。より
多くのイメージを加えることができ、好ましい実施例に
おいては32のイメージが存在する。図１における参照符
号は、イメージ20aに対してのみ示される。これも簡略
化のためであり、他のイメージ20b、20cおよび20dにお
ける対応する要素は、イメージ20aにおける要素と同じ
機能を実行する。

【００２５】オペレーティング・システム・イメージ20
の各々は、アプリケーション・プログラム（図示されな
い）あるいはアプリケーション・プログラムの一部が置
かれたアドレス空間、RMFアドレス空間と呼ばれる第１
の測定機構アドレス空間30および、RMFGATアドレス空間
と呼ばれる第２の測定機構アドレス空間50を持つ。本発
明の好ましい実施例は、２つの測定機構アドレス空間3
0、50を持つ。第１の測定機構アドレス空間30および第
２の測定機構アドレス空間50における機能を、１つの測
定機構アドレス空間に取り入れることも可能である。

【００２６】第１の測定機構アドレス空間30において、
SMFデータと呼ばれる第１の複数の記憶装置内バッファ4
0が提供される。この記憶装置内バッファ40の機能は、
以下により詳細に記述される。

【００２７】第２の測定機構アドレス空間50において、
モニタIIIデータと呼ばれる第２の複数の記憶装置内バ
ッファ60が提供される。第２の複数の記憶装置内バッフ
ァ60は、システム・データの連続した監視を可能にし一
時的な性能問題を解決する、いわゆるモニタIIIレコー
ドを記憶する。第２の複数の記憶装置内バッファ60の役
割は、以下により詳細に記述される。

【００２８】第１の複数の記憶装置内バッファ40および
第２の複数の記憶装置内バッファ60をメモリに記憶し、
以下に説明するように、そこから他のイメージにおける
測定機構アドレス空間に渡すことができる。第１のデー
タ・セット70は第１の測定機構アドレス空間30に接続
し、第２のデータ・セット80は第２の測定機構アドレス
空間50に接続する。SMFデータは、第１の記憶装置内バ
ッファ40および第１のデータ・セット70が共に存在する
場合、双方に同時に渡される。同様に、モニタIIIデー
タは、第２の記憶装置内バッファ60および第２のデータ
・セット80が共に存在する場合、双方に同時に渡され
る。データ・セット70、80および記憶装置内バッファ4
0、60は、データ・グループとして集合的に呼ばれる。

【００２９】シスプレックス10は、第１の記憶装置内バ
ッファ40あるいは第２の記憶装置内バッファ60のいずれ
かに記憶されているデータを評価するための、２つの分
析プログラムを持つ。測定機構プロセッサ（RMFポスト
・プロセッサ）110は、直接アクセス記憶装置70からデ
ータを収集し、１つの記憶装置90上へマージし、必要に
応じてソートする。ソートされたデータはまた、記憶装
置100上に記憶される。図１において、記憶装置90およ
び100が２つの単一記憶装置として示されているが、実
際は同じ記憶装置の２つの異なる領域である。測定機構
プロセッサ110は、マージされソートされたデータを使
用して、シスプレックス10の性能についての情報を表示
する。

【００３０】測定機構レポータ（RMFモニタIIIレポー
タ）120は、直接アクセス記憶装置80からデータを収集
し、シスプレックス10の性能のリアルタイムの分析を可
能にする。

【００３１】図２は、第１の複数の記憶装置内バッファ
40を持つ、第１の測定機構アドレス空間30の概要図であ
る。

【００３２】第１の複数の記憶装置内バッファ40は、長
期のシステム・ワークロードおよび資源利用率の分析を
可能にする、いわゆるシステム管理機構（SMF）レコー
ドを記憶する。SMFデータ収集ルーチン32は、システム
についての情報を獲得し、この情報を第１の記憶装置内
バッファ40および第１のデータ・セット70に渡す。

【００３３】どの情報を記憶し、どのレコードを収集す
るかは、シスプレックス10の所有者が決定することがで
きる。この決定をする時に考慮に入れなければいけない
要素は、以下の通りである。 ○SMFデータ収集ルーチン32は、必要な情報をシスプレ
ックス所有者に与えるためにどんなレコードを生成しな
ければならないか？ ○例えばデータベース・プログラムのような、多量のSM
Fレコードを生成するプログラムが実行しているか？ ○シスプレックス10の動作に影響を与えるシステム構成
は何か？ ○SMFデータ収集ルーチン32が必要とする資源に対し
て、各オペレーティング・システム・イメージ20上でど
のくらいのコンテンションがあるか。

【００３４】図４は、第１の複数のデータ・バッファ40
に記憶されたSMFデータ・レコード310の形式の例を示
す。SMFデータ・レコード310は、この場合18あるいは24
バイト長であるSMFレコード・ヘッダ320および、最大3
2,756バイト長の情報330からなる。SMFデータ・レコー
ド310の正確な長さは、以下に詳述されるように、SMFレ
コード・ヘッダ320内に示される。情報330の構成は可変
であり、SMFデータ・レコード310のユーザによって指定
される。

【００３５】SMFレコード・ヘッダ320の固定的な構成
は、図５に示される。SMFレコード・ヘッダ320の第１の
フィールドはSMFxLENと呼ばれ、2バイト長である。これ
は、SMFレコード・ヘッダ320および情報330を含む、SMF
データ・レコード310全体の長さを示す。次のフィール
ドはSMFxSEGと呼ばれ、SMFデータが２つ以上のSMFデー
タ・レコード310にわたる場合、つまり記録されるデー
タが32,756バイト以上の長さである時使用される。SMF
データが２つ以上のSMFデータ・レコード310にわたらな
い場合、SMFxSEGフィールドの2バイトは共に16進のゼロ
にセットされる。SMFxLENおよびSMFxSEGフィールドは共
に、レコード記述語（RDW）と呼ばれる4バイトのレコー
ド記述子を形成する。

【００３６】SMFデータ・レコード310の次のフィールド
は、SMFレコードが生成されたオペレーティング・シス
テムを示すSMFxFLGである。これは、1バイト長である。
例えばこのバイトが3にセットされている場合、MVS/SP
バージョン4のオペレーティング・システムを示す。こ
れが4にセットされている場合オペレーティング・シス
テムがMVS/ESAであることを示し、5にセットされている
場合オペレーティング・システムがMVS/XAであることを
示す。0、1および2の値は、他の目的のために予約され
る。

【００３７】SMFxRTYフィールドは、1バイト長であり、
0からFF（16進）の値をとることができる。これは、生
成されたSMFデータ・レコード310の形式を示す。本発明
の好ましい実施例において、レコード形式0から127（10
進）は、IBMオペレーティング・システム・イメージが
使用するように予約される。特にレコード形式70〜79は
ここに記述されるように、資源測定機構によって使用さ
れる。レコード形式128〜255は、アプリケーション・プ
ログラムが自由に使用することができる。

【００３８】SMFxTMEフィールドは4バイト長であり、真
夜中から経過した、SMFデータ・レコード310が生成され
てからの時間を100秒単位で示す。SMFxDTEフィールドも
4バイト長であり、SMFデータ・レコード310が生成され
た日付けを示す。

【００３９】最後にSMFxSIDフィールドは、SMFデータ・
レコード310が生成された、システムあるいはオペレー
ティング・システム・イメージ20の識別番号を示す。

【００４０】SMFデータ・レコード310の他のバージョン
において、SMFレコードが生成されたサブシステムのサ
ブシステム識別名（SMFxSSI−4バイト長）および、レコ
ードのサブ形式（SMFxSTY）を記録するフィールドがさ
らに提供される。これは、24バイト長のSMFレコード・
ヘッダ320において与えられる。

【００４１】すべてのフィールドが４番目の位置に小さ
いxを持つことが観察される。xの値は、SMFレコードの
形式を示す。xは、0から255の値をとることができる。
本発明の好ましい実施例において、xは70から79の値を
持つ。

【００４２】上記のように、SMFデータ収集ルーチン32
は各オペレーティング・システム・イメージ20上に提供
される。これらのSMFデータ収集ルーチン32は、システ
ムの所有者がレコード形式で指定した情報をデータ・バ
ッファ40へ渡し、バッファ40内の各データ・セットを１
つずつ満たす。データ・セットの１つが満たされると、
SMFデータ収集ルーチン32は第１の測定機構アドレス空
間30内の空のデータ・セットを検索する。１つのデータ
・セットがSMFレコードで満たされている間、SMFダンプ
・ルーチンが、データを第１の複数のデータ・セットの
満杯になったデータ・セットから、直接アクセス記憶装
置70上の予約された記憶空間に書き出すのに使用され
る。

【００４３】第２の測定機構アドレス空間50の構成は、
図３に示される。これは、上記の第２の複数の記憶装置
内バッファ60だけでなく、システム・データを収集しそ
のサンプルを取り、記憶装置内バッファ60あるいはデー
タ・セット80にデータを記憶する、データ収集ルーチン
55を含む。

【００４４】データ収集ルーチン55は、以下のオプショ
ンを持つコマンドによって開始される。

【００４５】CYCLE(nnnn) これは、システム・データのサイクル時間を千分の１秒
で指定する。

【００４６】DATASET (サブオプション) これは、VSAMデータ・セットへの記録を制御する。サブ
オプションは、MINTIME(nnn)からのデータの保存を制御
する。

【００４７】MINTIME (nnn) これは、時間間隔の長さを秒で指定する。この時間間隔
の終わりに、データ収集ルーチン55は、収集された全て
のサンプルを結合してサンプル・セットにする。これは
要約され測定機構レポータ120により報告される。サン
プル・セットの正確な構成は、収集されたデータの形式
に依存する。

【００４８】図６は、シスプレックス・データ・サーバ
170を持つシスプレックス10の概要を示す。識別に関し
ては、図６で使用される参照符号は、図１で使用される
のと同じシスプレックス10の要素を示している。第１の
測定機構アドレス空間30において、図１に示されるモジ
ュールに加えてシスプレックス・データ・サーバ170が
提供される。

【００４９】シスプレックス・データ・サーバ170は、
図６に示されるように、図２に示されるバッファ40に記
憶されたSMFレコード・データへのアクセス、および、
図３に示される第２の測定機構アドレス空間50に提供さ
れた記憶装置内バッファ60へのアクセスを持つ。シスプ
レックス・データ・サーバ170は、各オペレーティング
・システム・イメージ20a〜dにおいて全く同一であり、
図６に示される接続410を通して、他のオペレーティン
グ・システム・イメージ20a〜d中の全ての他のシスプレ
ックス・データ・サーバ170に接続する。シスプレック
ス・データ・サーバ170は、資源測定機構がオペレーテ
ィング・システム・イメージ20で実行している場合、第
１の測定機構アドレス空間30において常に能動である。

【００５０】シスプレックス・データ・サーバ170は資
源測定機構によって使用される全ての形式のデータを処
理することができ、特に、SMFデータおよびモニタIIIデ
ータを使用することができる。シスプレックス・データ
・サーバ170は、RMFレポータ・セッション自身例えば測
定機構レポータ120によって、あるいは、許可アプリケ
ーション・プログラムよって起動することができる、一
連の汎用プログラミング・インタフェース（GUPI）サー
ビスを提供する。

【００５１】図６はまた、オペレーティング・システム
・イメージの第１の測定機構アドレス空間におけるシス
プレックス・データ・サーバ170に接続する、オペレー
ティング・システム・イメージ20b中のユーザ・アドレ
ス空間150を示している。ユーザ・アドレス空間150は、
シスプレックス・データ・サーバ170により提供されるG
UPIサービスを使用する許可を与えられたアプリケーシ
ョン・プログラム160を持つ。

【００５２】アプリケーション・プログラム160は、シ
スプレックス10からデータを報告するレポータ機構を構
成する。

【００５３】シスプレックス・データ・サーバ170は以
下のGUPIを提供する。 ERBDSQRY−RMF使用可能シスプレックスSMFデータ照会サ
ービス。 ERBDSREC−RMFシスプレックスSMFレコード・データ要求
サービス。 ERB3XDRS−RMFシスプレックス・モニタIII・データ検索
サービス。

【００５４】ERBDSQRY GUPIは、データ・セット40中の
使用可能なSMFレコード・データのディレクトリを要求
するために、あるいは、シスプレックス10における各オ
ペレーティング・システム・イメージ上のデータ・セッ
ト60におけるサンプルのセットを要求するために、使用
される。ERBDSQRYに対する呼出し命令は、図７に示され
る。

【００５５】ERBDSQRYに与えられるパラメータは、以下
の値を持つ。

【００５６】ANSWER_AREA_ADDR シスプレックス・データ・サーバ170が要求された情報
を返す、メモリ中のアドレスを指定する。領域は、ユー
ザ・アドレス空間150あるいは、パブリック・アドレス
およびデータ空間であってもよい。パラメータanswer_a
rea_addrは、長さ4のポインタ変数として定義される。

【００５７】ANSWER_AREA_ALET answer_area_addrパラメータによって指定された応答領
域のアクセス・リスト・エントリ・テーブル（ALET）を
指定する。応答領域がユーザ・アドレス空間150にある
場合、answer_area_aletの値は0でなければならない。
パラメータanswer_area_aletは、長さ4の符号なし整数
変数として定義される。

【００５８】ANSWER_AREA_LENGTH アドレスがanswer_area_addrパラメータで与えられる応
答領域の長さを指定する。十分な空き領域が提供されな
い場合、answer_area_addrパラメータによってアドレス
指定されたメモリ空間は、完全なデータのために必要な
長さでなければならないので、シスプレックス・データ
・サーバ170は呼出しアプリケーション・プログラム160
に、どのくらいの空き領域を提供しなければならないか
を知らせる。answer_area_lengthは、長さ4の符号なし
整数変数として定義される。

【００５９】REQUEST_TYPE ERBDSQRY機能コードを指定し、以下の値のうちの1つを
とる。 ○SMF 任意の形式およびサブ形式のSMFデータ・レコー
ド310についての情報を要求する。全てのSMFデータ・レ
コード310についての情報が返され、SMF時間情報（SMF
レコード・ヘッダ320の日付および時間フィールドに指
定される時間ポイント）は、start_timeおよびend_time
パラメータ（下記参照）に指定される時間間隔に含まれ
る。 ○RMF 任意のRMF形式およびサブ形式のSMFデータ・レ
コード310についての情報を要求する。全てのSMFデータ
・レコード310についての情報が返され、（RMF生成セク
ションに指定される）計画されたRMF測定間隔終了時間
は、start_timeおよびend_timeパラメータ（下記参照）
に指定される時間間隔に含まれる。 request_typeパラメータは、長さ3の文字変数として定
義される。

【００６０】START_TIME 情報が要求される時間間隔が始まる日付および時間を指
定する。start_timeパラメータは、長さ14の文字変数と
して定義され、いわゆる「ソートされた」形式、「yyy
y,mm,dd,hh,mn,ss」で提示される。これらはそれぞれ、
開始時間の、yyyyは年、mmは月、ddは日、hhは時間、mn
は分、そしてssは秒の値である。この情報を省略したい
場合、14の空白値を渡すことができる。この場合パラメ
ータは、ERBDSQRY GUPIが呼出された時点における、デ
ータ・セット40の「最も古い」SMF時間の値に設定され
る。

【００６１】END_TIME 情報が要求される時間間隔が終了する日付および時間を
指定する。end_timeパラメータは、長さ14の文字変数と
して定義され、start_timeパラメータと同じ「ソートさ
れた」形式で記述される。同様に、情報は14の空白値を
渡すことによって省略することができる。この場合パラ
メータの値は、ERBDSQRY GUPIサービスが呼出された時
点における、データ・セット40の「最も新しい」SMF時
間に設定される。

【００６２】SMF_RECORD_TYPE_INFO smf_record_type_listパラメータで提供されたSMFレコ
ード形式のリストの型を指定する。これは、以下の値の
うち１つを持つ。 ○INCLUDE smf_record_type_listパラメータで提供さ
れたSMFレコード形式のリストは内包リストである、つ
まり、情報はリストされたSMFレコード形式に対して要
求される。 ○EXCLUDE smf_record_type_listパラメータで提供さ
れたSMFレコード形式のリストは排他リストである、つ
まり、情報はリストされたSMFレコード形式を除く全て
のSMFレコード形式に対して要求される。 ○ALL smf_record_type_listパラメータで提供されたS
MFレコード形式のリストは無視される、つまり、情報は
すべてのSMFレコード形式に対して要求される。 smf_record_type_infoパラメータは、長さ7の文字変数
として定義される。

【００６３】SMF_RECORD_TYPE_LIST 情報が要求されるSMFレコード形式のリストを指定す
る。図８に示されるように、これは長さ4の符号なし整
数変数として定義され、配列中の要素の数を指定する。
これに一対の長さ2の符号なし整数の配列が続き、各対
の第１の数はレコード形式を指定し、各対の第２の数は
レコード・サブ形式を指定する。サブ形式なしのレコー
ド形式に対しては、0のサブ形式が指定される。

【００６４】SMF_SYSTEM_NAME_INFO smf_system_name_listパラメータで提供される、SMFデ
ータ・セット40が存在するオペレーティング・システム
・イメージ20のリストの型を指定する。パラメータは、
以下の値の１つをとる。 ○INCLUDE smf_system_name_listパラメータで提供さ
れたオペレーティング・システム・イメージ20のリスト
は内包リストである、つまり、情報はリストされたオペ
レーティング・システム・イメージ20名を持つシステム
に対して要求される。 ○EXCLUDE smf_system_name_listパラメータで提供さ
れたSMFシステム名のリストは排他リストである、つま
り、情報はリストされた名を持つオペレーティング・シ
ステム・イメージ20を除く、シスプレックス内のすべて
のシステムに対して要求される。 ○ALL smf_system_name_listパラメータで提供された
オペレーティング・システム・イメージ名のリストは無
視される、つまり、情報はシスプレックス10内のすべて
のシステムに対して要求される。 smf_system_name_infoパラメータは、長さ7の文字変数
として定義される。

【００６５】SMF_SYSTEM_NAME_LIST 情報が要求されるオペレーティング・システム・イメー
ジ20名のリストを指定する。smf_system_name_listは、
長さ4の符号なし整数変数として定義される。これは配
列要素の数を指定し、長さ4の文字配列が後に続く。各
配列要素は、イメージ名を持つ。

【００６６】RETURN_CODE ERBDSQRY GUPIが完了すると、return_codeパラメータは
GUPIに対する戻りコードを含む。これは、長さ4の符号
なし整数変数として定義される。

【００６７】REASON_CODE ERBDSQRY GUPIが完了すると、reason_codeは動作が成功
しなかった理由を表す理由コードを含む。これは、長さ
4の符号なし整数変数として定義される。

【００６８】ERBDSQRYがアプリケーション・プログラム
160に制御を戻し、サービスが成功すると、応答領域
（図示されない）がメモリ中のanswer_area_addrパラメ
ータによって指定されたアドレスに生成される。この応
答領域の構成は、ヘッダ領域601およびデータ領域603に
分けられる。ヘッダ領域601は図１０に示され、３つのG
UPIすべてに共通である。データ領域は呼出されたGUPI
の型によって異なり、ERBDSQRY GUPIの場合request_typ
eパラメータの値による。図１１は、request_typeパラ
メータが値SMFを持つときの応答領域のデータ領域603を
示す。図１２は、request_typeパラメータが値RMFを持
つ時の応答領域のデータ領域603を示す。データ領域603
は、各オペレーティング・システム・イメージ20から収
集されたデータに対するシステム・リスト・エントリを
含む。

【００６９】図１０のブロックは、以下の値を持つ。 NAM 605 以下に示す、共通ヘッダ601の4文字頭字語
である。 ○ 「DSQA」ERBDSQRY GUPI共通ヘッダ ○ 「DSRA」ERBDSREC GUPI共通ヘッダ ○ 「XDRH」ERB3XDRS GUPI共通ヘッダ VER 608 共通ヘッダ601のバージョン（最初は1にセ
ット）。 LEN 610 返されたデータ全体の長さ。 TLN 612 要求された全データを含むために必要な、
応答領域全体の長さ。 PLX 615 GUPIを使用して呼出しを行っているアプリ
ケーション・プログラム160が実行している、オペレー
ティング・システム・イメージ20名。 SOF 618 ヘッダから第１のシステム・リスト・エン
トリSNMへのオフセット。 SLM 620 １つのシステム・リスト・エントリの長さ
（すなわちSNM、SID、RMFフィールドの長さ）。 SNO 622 システム・リスト・エントリ（SNM、SID、R
MF）の数。 DOF 625 ヘッダ601から第１のデータ・セクションへ
のオフセット。詳細なレイアウトは、以下の個々のデー
タ・セクションの説明を参照されたい。 DLN 628 １つのデータ・セクションの長さ。可変長
データ・セクションに対しては、このフィールドはゼロ
である。この場合、長さは個々のデータ・セクション・
ヘッダに記憶される。 DNO 630 返されたデータ・セクションの数。

【００７０】system list これは、シスプレックス10内のオペレーティング・シス
テム・イメージ20につき１つのエントリを含む。 SNMn オペレーティング・システム・イメージ20に対
する8文字のシステム名。 SIDn 4文字のSMFシステムID。RMFがこのシステム上
で能動でない場合、このフィールドは16進の0を含む。 RMFn 32ビットのRMF状態表示。 ○ビット1は、このシステムのRMFアドレス空間30の状態
を示す（「1」Bは能動）。○ビット2は、このシステム
のSMFデータのためのRMFデータ・バッファ40の状態を示
す（「1」Bは能動）。○ビット3は、このシステムのRMF
モニタIIIアドレス空間50の状態を示す（「1」Bは能
動）。○ビット4から32は予約領域である。

【００７１】ERBDSQRY GUPIが完了した時返されるデー
タ領域603は、request_typeパラメータの値がSMFである
時、図１１に示されるレイアウトをとる。図１１のブロ
ックは、以下の情報を含む。

【００７２】RECTOKn 650 ERBDSQRY GUPIによって提供され、次のERBDSREC GUPIへ
の呼出しによって使用されるレコード・トークン。

【００７３】SMFHDRn 320、652 図５に示されるSMFレコード・ヘッダ（24バイト）。

【００７４】図１２には、request_typeパラメータが値
RMFを持つ時の、応答領域のデータ領域603が示される。
フィールドRECTOKn 650およびSMFHDRn 320、652は、図
１１と同じ情報を含む。RMFINFOフィールド655は、SMF
データ・レコード310のRMF生成セクションからの32バイ
トの付加情報を含む。

【００７５】図１３は、SMFデータ・レコード310のRMF
生成セクションに含まれる付加情報を示す。これは、以
下のフィールドを含む。 SMFxxDAT 4バイト長で、RMF間隔の実際の開始日付を
与える。 SMFxxIST 4バイト長で、RMF間隔の実際の開始時間を
与える。 SMFxxINT 4バイト長で、RMF間隔の実際の長さを与え
る。 SMFxxOIL 2バイト長で、計画された間隔長を秒単位
で与える。 SMFxxSYN 2バイト長で、RMF同期値を秒単位で与え
る。 SMFxxLGO 8バイト長で、グリニッジ標準時（GMT）と
地域時間のオフセット時間を与える。 SMFxxGIE 8バイト長で、RMF間隔の計画された終了を
GMTで与える。

【００７６】ERBDSREC GUPIは、シスプレックス10内の
各オペレーティング・システム・イメージ20上のデータ
・セット40からSMFレコード・データを要求するために
使用される。各要求されたSMFレコードに対して、以前
のERBDSQRY GUPI呼出しによって得られた応答領域に含
まれるレコード・トークン650は、ERBDSREC GUPIにパラ
メータとして渡されるレコード・トークン650のリスト
に含まれる。

【００７７】ERBDSREC GUPIに対する呼出しは、図１４
に示される。

【００７８】ANSWER_AREA_ADDR RMF呼出しルーチンが要求された情報を返す、応答領域8
00のアドレスを指定する。領域は、ユーザ・アドレス空
間150あるいは、パブリック・アドレスおよびデータ空
間にあってもよい。パラメータは、長さ4のポインタ変
数として定義される。

【００７９】ANSWER_AREA_ALET answer_area_addrパラメータによって指定される応答領
域のアクセス・リスト・エントリ・テーブル（ALET）を
指定する。領域がユーザ・アドレス空間150にある場
合、answer_area_aletの値は0でなければならない。パ
ラメータanswer_area_aletは、長さ4の符号なし整数変
数として定義される。

【００８０】ANSWER_AREA_LENGTH アドレスがanswer_area_addrパラメータによって与えら
れる応答領域800の長さを指定する。十分な空き領域が
提供されていない場合、answer_area_addrパラメータに
よってアドレス指定されたメモリ空間は完全なデータの
ために必要な長さでなければならないので、シスプレッ
クス・データ・サーバ170は呼出しプログラムに、どの
くらいの空間を提供しなければならないかを知らせる。
answer_area_lengthは、長さ4の符号なし整数変数とし
て定義される。

【００８１】RMF_RECORD_TOKEN_LIST ERBDSQRY GUPIを使用して要求されたSMFレコードに対す
る、レコード・トークン650のリストを指定する。図１
５に示されるように、これは長さ4の符号なし整数変数
として定義され、配列要素の数を指定する。この配列要
素は文字列からなり、各要素は長さ8である。

【００８２】RETURN_CODE ERBDSQRY GUPIが完了すると、return_codeパラメータは
GUPIに対する戻りコードを含む。これは、長さ4の符号
なし整数変数として定義される。

【００８３】REASON_CODE ERBDSQRY GUPIが完了すると、return_codeは動作が成功
しなかった理由を示す理由コードを含む。これは、長さ
4の符号なし整数変数として定義される。

【００８４】ERBDSRECがアプリケーション・プログラム
160に制御を返し、サービスが成功すると、応答領域が
メモリのanswer_area_addrパラメータによって指定され
たアドレスに生成される。応答領域は、図１０に示され
る共通ヘッダ601およびデータ・セクション800からな
る。データ・セクション800の構成は、図１６に示され
る。応答領域800は、各要求されたSMFレコードに対し
て、データ・セクション・ヘッダ810およびデータ・セ
クション・エントリ850を含む。データ・セクション・
エントリ850は、要求された順序にある、つまり、rmf_r
ecord_token_listパラメータに指定されたトークンの順
にある。各SMFデータ・レコード310に対するデータ・セ
クション・エントリ850は、ERBDSREC GUPIにより提供さ
れたデータ・セクション・ヘッダ810およびSMFレコード
（SMFRECORDn）850自身を含む。データ・セクション800
の様々なフィールドは、以下の値を持つ。

【００８５】RLn このSMFデータ・レコード310のデータ・エントリの長さ
（データ・ヘッダ810を含む）。

【００８６】RCn このSMFレコードの要求に対する戻りコードは以下の通
りである。 0 データが返された。SMFレコード850は、データ・
ヘッダ810に続く。 4 データが返されなかった。SMFレコードが遠隔オペ
レーティング・システム・イメージ20から受け取られる
前に、時間切れになった。 8 データが返されなかった。レコード・トークンRMF
TOKn 880が、シスプレックス10内のオペレーティング・
システム・イメージ20に存在するSMFレコードに対応し
ない。

【００８７】RECTOKn このSMFレコード850に対するレコード・トークン。この
トークンは、入力パラメータrmf_record_token_listか
らコピーされた。

【００８８】SMFRECORDn SMFレコード850である。

【００８９】ERB3XDRS GUPIは、指定された日付けおよ
び時間範囲に従ってモニタIIIデータのサンプル・セッ
トを要求するために使用される。

【００９０】ERB3XDRS GUPIの呼出しは、図１７に示さ
れる。

【００９１】ERB3XDRSに与えられるパラメータは、以下
の値を持つ。

【００９２】ANSWER_AREA_ADDRシスプレックス・データ
・サーバ170が要求された情報を返す、メモリ中の応答
領域のアドレスを指定する。領域は、ユーザ・アドレス
空間150あるいは、パブリック・アドレスおよびデータ
空間であってもよい。パラメータanswer_area_addrは、
長さ4のポインタ変数として定義される。

【００９３】ANSWER_AREA_ALET answer_area_addrパラメータによって指定された応答領
域のアクセス・リスト・エントリ・テーブル（ALET）を
指定する。領域がユーザ・アドレス空間150にある場
合、answer_area_aletの値は0でなければならない。パ
ラメータanswer_area_aletは、長さ4の符号なし整数変
数として定義される。

【００９４】ANSWER_AREA_LENGTH アドレスがanswer_area_addrパラメータによって与えら
れる応答領域の長さを指定する。空き領域が提供されな
い場合、answer_area_addrパラメータは完全なデータの
ために必要な長さを含まなければならないので、シスプ
レックス・データ・サーバ170は呼出しプログラムに、
どのくらいの空間を提供しなければならないかを知らせ
る。answer_area_lengthは、長さ4の符号なし整数変数
として定義される。

【００９５】START_TIME このパラメータは、要求された時間範囲情報の開始日付
けおよび時間を指定する。start_timeパラメータは、上
記の「ソートされた」形式の長さ14の文字変数として定
義される。

【００９６】END_TIME このパラメータは、要求されている範囲情報の終了日付
けおよび時間を指定する。start_timeパラメータと同様
に、end_timeパラメータは、「ソートされた」形式の長
さ14の文字変数として定義される。

【００９７】SYSTEM_NAME 情報を要求するオペレーティング・システム・イメージ
20名を指定する。これは、4文字のSMFシステム識別名
（SID）である。request_typeパラメータが値「SCP」を
持つ場合、system_nameは4つの空白（ヌル値）として指
定することができ、この結果、情報はシスプレックス10
内のすべてのオペレーティング・システム・イメージ20
から収集される。system_nameパラメータは、長さ4の文
字変数として定義される。

【００９８】RETURN_CODE ERB3XDRS GUPI呼出しが完了すると、return_codeパラメ
ータは、長さ4の符号なし整数変数として定義される戻
りコードを含む。

【００９９】REASON_CODE ERB3XDRS GUPI呼出しが完了すると、reason_codeパラメ
ータは、長さ4の符号なし整数変数として定義される理
由コードを含む。

【０１００】ERB3XDRS応答領域レイアウト：ERB3XDRS G
UPI呼出しが呼出しプログラムに制御を返し、サービス
が成功すると、ANSWER_AREA_ADDRパラメータによって指
定されたアドレスにおける応答領域は、図１０に示され
る共通ヘッダ601および、その構成が図１８に示される
要求されたモニタIIIデータ・セクションを含む。

【０１０１】モニタIIIデータ・セクションは、データ
・セクション・ヘッダ1000および実際のモニタIIIデー
タを含む。データ・セクションは、１つ以上のサンプル
・セットからなる。圧縮されていないサンプル・セット
のレイアウトは、RMF ユーザーズ・ガイド（IBM マニュ
アル No. GC28-1058）に記述されており、参照によりこ
こに取り入れられる。データ・セクション・ヘッダ1000
内のフィールドは、以下の情報を含む。 DEL 1002 このデータ・セクションの長さ。 RTN 1003 データ検索戻りコード。 RSN 1004 データ検索RSN。 DGV 1005 「VRM」形式のデータ収集ルーチンのバー
ジョン。 DGS 1008 データ収集ルーチンが実行しているオペレ
ーティング・システム・イメージ20のシステム名。 MNT 1010 データ収集ルーチンのMINTIMEオプショ
ン。 SAM 1012 返されたデータに対するサンプルの実際の
数。 RNG 1015 実際の範囲長（秒単位）。 BEG 実際の範囲開始時間（ソートされた時刻表
示形式YYYYMMDDHHMMSS）。 END 実際の範囲終了時間（ソートされた時刻表
示形式YYYYMMDDHHMMSS）。 DRC 1031 データ圧縮出口完了コード。

【０１０２】「*」がつけられたフィールドは、予約領
域である。

【０１０３】GUPIの使用に対する本発明の典型的な実施
例を、図１９を参照して記述する。以下のシナリオを、
説明のために仮定する。しかし、他のシナリオも可能で
あることが理解されるであろう。ユーザ・アドレス空間
150で実行しているアプリケーション・プログラム160
は、シスプレックス10の資源に関するデータを生成しよ
うとする。従来技術において、アプリケーション・プロ
グラム160は、SMFデータ・セット40あるいは、同じオペ
レーティング・システムで実行しているモニタIIIデー
タ・セット60に問い合わせる。本発明のシステムにおい
ては、複数のオペレーティング・システム・イメージ20
があり、アプリケーション・プログラム160はオペレー
ティング・システム・イメージの１つの上でだけで実行
しているが（図６の実施例においてはオペレーティング
・システム・イメージ20bだけ）、他のオペレーティン
グ・システム・イメージ上でも実行することができる。
したがって、アプリケーション・プログラム160はシス
プレックス・データ・サーバ170を使用しなければなら
ない。

【０１０４】上記のように、シスプレックス・データ・
サーバ170は、資源測定機構がオペレーティング・シス
テム・イメージ20で実行している時は常に第１の測定機
構アドレス空間30で実行している。特に、シスプレック
ス・データ・サーバ170は、アプリケーション・プログ
ラム160が実行しているオペレーティング・システム・
イメージ20上で実行しなければならない。

【０１０５】図１９のステップ1100において、アプリケ
ーション・プログラム160は、シスプレックス・データ
・サーバ170によりGUPIとして供給されるERBDSQRYサー
ビスを呼出す。アプリケーション・プログラム160は、G
UPIに必要なパラメータ値を与えなければならない（上
記参照）。アプリケーション・プログラム160は、ユー
ザ・アドレス空間150あるいはパブリック・アドレスお
よびデータ空間に、ERBDSQRYサービスから返されるデー
タに対する応答領域を生成する。生成された応答領域の
アドレスおよび長さは、ANSWER_AREA_ADDR、ANSWER_ARE
A_ALETおよびANSWER_AREA_LENGTHパラメータで与えられ
る（ステップ1110）。アプリケーション・プログラム16
0はまた、データを要求するオペレーティング・システ
ム・イメージ20名のリストを提供しなければならない。
このリストは、SMF_SYSTEM_NAME_LISTおよびSMF_SYSTEM
_NAME_INFOパラメータで与えられる。シスプレックス・
データ・サーバ170は、名をあげられたすべてのオペレ
ーティング・システム・イメージ20上で動作していなけ
ればならない。そうでなければ、呼出しからの戻りにお
いて、RETURN_CODEおよびREASON_CODEパラメータによっ
てエラーメッセージが示される。アプリケーション・プ
ログラム160はまた、収集するデータの形式を指定しな
ければならない。これは、上記のREQUEST_TYPE、START_
TIME、END_TIMEおよびSMF_RECORD_TYPE_INFOパラメータ
によって与えられる。

【０１０６】ステップ1120において、ERBDSQRYサービス
を呼出したシスプレックス・データ・サーバ170は、接
続410を通して、SMF_SYSTEM_NAME_LISTおよびSMF_SYSTE
M_NAME_INFOパラメータによって指定されたオペレーテ
ィング・システム・イメージ20上で実行しているシスプ
レックス・データ・サーバ170に、データに対する要求
を送る。ステップ1130において、シスプレックス・デー
タ・サーバ170は、SMFデータ・セット40や同じオペレー
ティング・システム・イメージ20で実行しているモニタ
IIIデータ・セット60に問い合わせる。検索基準との一
致が見つかったオペレーティング・システム・イメージ
20において、シスプレックス・データ・サーバ170は、
開始シスプレックス・データ・サーバ170に、SMFデータ
・レコード310からSMFレコード・ヘッダ652および要求
される場合RMF生成セクション655を返す（ステップ114
0）。

【０１０７】ステップ1150において、開始シスプレック
ス・データ・サーバ170は情報を統合し、レコード・ト
ークン650を返された各SMFレコード・ヘッダ652に割り
当てる。共通ヘッダ601（図１０）が、返された情報お
よびヘッダに対して生成され、返されたSMFレコード・
ヘッダ652、RMF生成セクション655、レコード・トーク
ン650と共に、ステップ1110で生成された応答領域に記
憶される（ステップ1160）。データ・セクションの構造
は、図１１、１２に示される。

【０１０８】ERBDSQRY GUPIからのRETURN_CODEおよびRE
ASON_CODEパラメータは、ERBDSQRYGUPIから起こってい
るエラーあるいは問題を示すために使用される。例え
ば、ANSWER_AREA_LENGTHパラメータによって割り当てら
れた応答領域の長さが、要求された長さおよび、図１０
に示される共通ヘッダのLENブロック610により指定され
る長さより短い時、エラーが示される。

【０１０９】アプリケーション・プログラム160はここ
で、生成された応答領域に記憶された情報を処理するこ
とができる。情報の典型的な使用は、各オペレーティン
グ・システム・イメージ20上の各データ・バッファ40か
らSMFレコード・データを要求することである。この目
的のために、シスプレックス・データ・サーバ170は、E
RBDSREC GUPIを提供するERBDSRECサービスを備える。ア
プリケーション・プログラム160によるこのサービスの
呼出しを、図２０を参照して記述する。

【０１１０】ステップ1200において、アプリケーション
・プログラム160はシスプレックス・データ・サーバ170
のERBDSRECサービスを呼出す。ERBDSREC呼出しの形式
は、図１４に示される。これは、ユーザ・アドレス空間
150あるいはパブリック・アドレスおよびデータ空間内
に生成された、ERBDSREC応答領域800の位置および長さ
を記述するために、ANSWER_AREA_ADDR、ANSWER_AREA_AL
ET、ANSWER_AREA_LENGTHパラメータを含む。これらのパ
ラメータは、ERBDSREC応答領域800を生成するためにス
テップ1210において使用される。ERBDSREC呼出しに伴
い、ERBDSQRY呼出しにより生成されERBDSQRY応答領域に
記録された、レコード・トークン650のリストが渡され
る。これらのレコード・トークン650は、アプリケーシ
ョン・プログラム160によって要求されたSMFレコードを
示す。

【０１１１】ステップ1220において、シスプレックス・
データ・サーバ170は、レコード・トークン650によって
指定されたオペレーティング・システム・イメージ20の
シスプレックス・データ・サーバ170にデータ収集に対
する要求を渡し、この要求はステップ1230において実行
される。データ収集ステップ1230は、オペレーティング
・システム・イメージ20中のシスプレックス・データ・
サーバ170によって実行される。SMFデータは、第１の複
数のデータ・セット40から得られる。収集されたSMFデ
ータは、要求しているシスプレックス・データ・サーバ
170に返されヘッダ（図１０）が生成され、データは統
合されて（ステップ1250）、応答領域800（図１６）に
記憶される（ステップ1260）。データはそれから、アプ
リケーション・プログラム160あるいは他のプログラム
によって、応答領域800から処理される。

【０１１２】ERB3XDRS GUPIは、モニタIIIデータが要求
され図１８に示される応答領域1000に記憶されることを
除いて、ERBDSREC GUPIと同様の方法で使用することが
できる。本発明の他の実施例において、図１に示される
測定機構プロセッサ110は、ERBDSQRY呼出しからの応答
領域800およびERB3XDRS呼出しからの応答領域1000が存
在するアドレス空間があるのと同じオペレーティング・
システム・イメージ20上で、実行することができる。測
定機構プロセッサ110は使用可能なデータを取り、報告
し、データに基づき判断するので、システム管理者はシ
ステムの問題を識別することができる。測定機構プロセ
ッサ110は、以下の事項について報告する。

【０１１３】クロス・システム接続機構遅延：遅延レポ
ートは、他のオペレーティング・システム・イメージ20
からのサービスを待っている、１つのオペレーティング
・システム・イメージ20中のジョブに関する情報を提示
する。レポートの表形式はまた、遅延の説明もリストす
る。

【０１１４】遅延レポート：（すべてのジョブに対す
る）遅延レポートは、システム内の各ジョブのアクティ
ビティおよび、各ジョブを遅らせているハードウェアお
よびソフトウェア資源を示す。レポートの表形式はま
た、すべての遅延に対する主要な理由をリストする。

【０１１５】装置遅延：装置遅延レポートは、例えば、
直接アクセス記憶装置（DASD）、テープ、あるいは大容
量記憶装置コントローラ（MSC）ボリュームのような装
置ボリュームを求めて争っているジョブについての情報
を提示する。

【０１１６】装置資源遅延：資源向け装置遅延レポート
は、ジョブを遅らせている入出力装置のアクティビティ
についての情報を提示する。

【０１１７】エンキュー遅延：エンキュー遅延レポート
は、逐次再使用可能資源の使用を待っている（エンキュ
ーされている）ジョブについての情報を提示する。表形
式はまた、エンキュー・コンテンションがレポート間隔
以上にジョブを遅らせた時間の割合および、遅れたジョ
ブが待っている間資源をホールドしていたジョブを、リ
ストする。

【０１１８】エンキュー資源遅延：資源向け遅延レポー
トは、システム中にコンテンションを起こしている逐次
再使用可能資源についての情報を提示する。レポートの
表形式はまた、これらの資源に対する遅れた（エンキュ
ーされた）ジョブ名および、これらの資源をホールドし
ているジョブ名をリストする。

【０１１９】階層記憶管理プログラム（HSM）遅延：HSM
遅延レポートは、HSMからのサービスを待っているジョ
ブについての情報を提示する。レポートの表形式はま
た、遅延の説明をリストする。

【０１２０】JES遅延：JES遅延レポートは、JES2または
JES3からのサービスを待っているジョブについての情報
を提示する。レポートの表形式はまた、遅延の説明をリ
ストする。

【０１２１】ジョブ・レポート：ジョブ・レポートは、
ジョブが遅れた理由についての情報を提示する。レポー
ト中の情報は、主要なあるいは要求された遅延理由を記
述し、ジョブ遅延を起こす可能性のある要因を提示す
る。

【０１２２】プロセッサ遅延：プロセッサ遅延レポート
は、レポート間隔の間、プロセッサのために遅れたジョ
ブ、あるいはプロセッサを使用しているすべてのジョブ
についての情報を提示する。

【０１２３】記憶装置遅延：記憶装置遅延レポートは、
フレームを使用したすべてのジョブおよび、ジョブがレ
ポート間隔の間に使用した中央記憶装置および拡張記憶
装置のワーキング・セットの大きさ、についての情報を
提示する。ジョブがページングまたはスワッピング・ア
クティビティのために遅れた場合、レポートは遅延の理
由も識別する。

【０１２４】記憶装置遅延要約：記憶装置要約レポート
は、各領域および性能グループに対する記憶装置の使用
に関する情報を提供する。

【０１２５】記憶装置フレーム：記憶装置フレーム・レ
ポートは、各アドレス空間に対するフレーム・カウント
に関する情報を提供する。レポートはまた、補助スロッ
ト・カウントおよび、拡張記憶装置からのページ・イン
率を含むページ・イン率、に関する情報を提供する。

【０１２６】記憶装置資源遅延：資源向け記憶装置遅延
レポートは、システム記憶装置の使用および、直列ボリ
ュームによるページング空間遅延、についての情報を提
示する。

【０１２７】システム情報レポート：システム情報レポ
ートは、シスプレックス10の概要、そのワークロードお
よび、資源を使用しているあるいは資源のために遅れた
ジョブの合計数、を提供する。システム情報レポート
は、シスプレックス10全体に対する測定および、TSO、
バッチ、開始タスク、領域、および性能グループのよう
な、ジョブ・グループに対する測定を報告することがで
きる。

【０１２８】ワーク・フロー／例外レポート：ワーク・
フロー／例外レポートは、システム・アクティビティお
よびシステム資源についての情報を提示する。レポート
の第１の部分は、ジョブがシスプレックスを通って動く
速度を示す。レポートの第２の部分は、指定された例外
基準に合うジョブを示す。ワーク・フローを速度計で表
示するグラフィック・レポートを生成することができ
る。

【０１２９】

【０１３０】

【発明の効果】本発明によれば、より効率的に利用しう
るように改善されたオペレーティング・システム・イメ
ージ間の接続を提供できる。

【図面の簡単な説明】

【図１】RMFシスプレックス・データ・サーバを持たな
いシスプレックスの概要図である。

【図２】第１の測定機構アドレス空間（RMFアドレス空
間）の概要図である。

【図３】第２の測定機構アドレス空間（RMFGATアドレス
空間）の概要図である。

【図４】SMFデータ・レコードの形式の例を示す図であ
る。

【図５】SMFデータ・レコードのためのヘッダ構成の例
を示す図である。

【図６】本発明のシスプレックス・データ・サーバを持
つシスプレックスの概要図である。

【図７】ERBDSQRY GUPI呼出しの形式を示す図である。

【図８】smf_record_type_listパラメータの形式を示す
図である。

【図９】smf_system_name_listパラメータの形式を示す
図である。

【図１０】GUPIから返された共通ヘッダの形式を示す図
である。

【図１１】request_typeパラメータが値SMFを持つ時、E
RBDSQRY GUPIによって生成される応答領域を示す図であ
る。

【図１２】request_typeパラメータが値RMFを持つ時、E
RBDSQRY GUPIによって生成される応答領域を示す図であ
る。

【図１３】SMFレコードのRMF生成セクションの形式を示
す図である。

【図１４】ERBDSREC GUPI呼出しの形式を示す図であ
る。

【図１５】rmf_record_token_listパラメータの形式を
示す図である。

【図１６】ERBDSREC GUPIから返される時に生成される
応答領域のデータ・セクション・ヘッダを示す図であ
る。

【図１７】ERB3XDRS GUPI呼出しの形式を示す図であ
る。

【図１８】ERB3XDRS GUPIから返される時に生成される
応答領域のデータ・セクション・ヘッダの形式を示す図
である。

【図１９】ERBDSQRY GUPI呼出しのフローチャートであ
る。

【図２０】ERBDSREC GUPI呼出しのフローチャートであ
る。

【符号の説明】

１０シスプレックス２０オペレーティング・システム・イメージ３０、５０測定機構アドレス空間３２、５５データ収集ルーチン４０、６０記憶装置内バッファ７０、８０データ・セット１１０測定機構プロセッサ（RMFポスト・プロセッサ) １２０測定機構レポータ（RMFモニタIIIレポータ）１５０ユーザ・アドレス空間１６０アプリケーション・プログラム１７０シスプレックス・データ・サーバ３１０ SMFデータ・レコード４１０接続６００、８００、１０００応答領域

───────────────────────────────────────────────────── フロントページの続き (72)発明者ディーテル・コーニグドイツ連邦共和国ディー−71083ヘレンバーグ、シュワリナー・ストラベ 31 (56)参考文献特開平６−12288（ＪＰ，Ａ) 特開平３−131157（ＪＰ，Ａ) 特開平３−25560（ＪＰ，Ａ) 特開平３−176755（ＪＰ，Ａ) 特開平３−257639（ＪＰ，Ａ) 特開昭62−24377（ＪＰ，Ａ) 特開昭59−208661（ＪＰ，Ａ) 特開平５−334137（ＪＰ，Ａ) ＩＥＥＥＴＲＡＮＳＡＣＴＩＯＮＳＯＮＳＯＦＴＷＡＲＥＥＮＧＩＮＥＥＲＩＮＧＶｏｌ．15，Ｎｏ．12 （1989），Ｐ1615〜Ｐ1629

Claims

(57)【特許請求の範囲】

【請求項１】接続手段（410）を通して接続された複
数のオペレーティング・システム・イメージ（20）を持
ち、シスプレックス（10）からの動作中のデータを報告
するために第１の上記オペレーティング・システム・イ
メージ（20）上で稼働する一のレポータ機構（160）を
持つシスプレックス（10）であって、各上記オペレーティング・システム・イメージ（20）内
に、報告可能なデータを含むデータ・グループ（40、6
0）を持ち、上記第１のオペレーティング・システム・イメージ（2
0）における第１のデータ・サーバ（170）と、報告可能なデータを含む上記データ・グループ（40、6
0）を持ち且つ上記第１のオペレーティング・システム
・イメージ（20）とは異なる上記オペレーティング・シ
ステム・イメージ（20）における第２のデータ・サーバ
（170）と、を有し、上記第２のデータ・サーバ（170）が、上記第１のデー
タ・サーバ（170）から上記報告可能なデータを収集す
るための一の要求を受け取ると、上記異なるオペレーテ
ィング・システム・イメージ（20）における上記データ
・グループ（40、60）から上記報告可能なデータを収集
し、上記接続手段（410）を通して上記第１のデータ・
サーバ（170）へ上記報告可能なデータを渡し、上記第
１のデータ・サーバ（170）が上記報告可能なデータを
上記レポータ機構（160）に渡す、上記シスプレック
ス。
【請求項２】各上記オペレーティング・システム・イ
メージ（20）が２つの上記データ・グループ（40、60）
を有し、上記要求が、上記データ・グループ（40、60）のどちら
に上記報告可能なデータがあるかを指示する、請求項１に記載のシスプレックス（10）。
【請求項３】上記第１のデータ・サーバ（170）によ
って生成され、上記報告可能なデータが記憶される応答
領域（800、1000）を有する、請求項１または２に記載
のシスプレックス（10）。
【請求項４】上記レポータ機構（160）を含む上記シ
スプレックス（10）内の資源を監視するための監視機構
を有し、上記データ・グループ（40、60）が、上記シスプレック
ス（10）内の資源の使用およびロードに関するデータを
含む、請求項１乃至３のいずれか１項に記載のシスプレックス
（10）。
【請求項５】複数のオペレーティング・システム・イ
メージを持つシスプレックスにおけるデータを報告する
方法であって、第１のオペレーティング・システム・イメージから、ど
のオペレーティング・システム・イメージ内に報告可能
なデータが存在するかを示す検索基準を持つ一の要求を
送る、第１のステップ（1120）と、上記検索基準と、上記要求を受け取った各オペレーティ
ング・システム・イメージ内の上記報告可能なデータを
突き合わせる、第２のステップ（1130）と、上記報告可能なデータがその内部に存在するオペレーテ
ィング・システム・イメージの一のイメージ・リスト
を、上記第１のオペレーティング・システム・イメージ
に返す、第３のステップ（1140）と、上記イメージ・リスト内にリストされたオペレーティン
グ・システム・イメージに、当該オペレーティング・シ
ステム・イメージ内の上記報告可能なデータを収集する
ための一の要求を送る、第４のステップ（1220）と、上記リストされたオペレーティング・システム・イメー
ジから上記第１のオペレーティング・システム・イメー
ジに上記報告可能なデータを返す、第５のステップ（12
40）と、上記報告可能なデータを、上記第１のオペレーティング
・システム・イメージ内の応答領域に記憶する、第６の
ステップ（1260）と、を含む上記方法。