JPH06295290A - データ処理システム及びデータ処理方法 - Google Patents

Abstract

(57)【要約】 【目的】本発明は、複数コンピユータシステムで走る多
重プロセス間に通信サービスを提供する方法及びシステ
ムを提案する。 【構成】分散環境内に論理プロセス階層を作成する機構
が提供される。同様に論理プロセス階層を越える拡張子
が提供される。通信機構は個々のプロセスが使用するこ
とのできる機能のライブラリとして実施される。文脈の
任意の定義を用いるので、名前又は他の一切の属性によ
つてオペレーテイングシステムプロセス空間内にプロセ
スを関連させる必要はない。このようなプロセスがロー
カルコンピユータ上に存在しようが又は遠隔コンピユー
タ上に存在しようが、単一システムの意味規則を用いて
プロセスにアクセスすることができる。プロセスが分散
文脈の一部として登録することができる機構が提供され
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はデータ処理システム及び
データ処理方法に関し、特に複数コンピユータデータ処
理システムにおける多重プロセス通信に適用して好適な
ものである。

【０００２】

【従来の技術】今日の状況においてはコンピユータの試
験及びネツトワークの試験はますます重要になりつつあ
る。これらのシステムの利用者は高水準の信頼性を要求
する。システム障害が生ずるとデータの保全性が損なわ
れる。単一のコンピユータを試験すること自体も複雑な
ことではあるが、単一のコンピユータを試験する方法が
存在することは一般に良く知られている。システムを最
初に起動させるときに、種々の形式のパワーオンコード
又はブートコードによりコンピユータを試験する。

【０００３】

【発明が解決しようとする課題】システムが誤動作した
ことに気づいたときには、コンピユータ又はネツトワー
クに診断プログラムを走らせることができる。これらの
診断プログラムは試験されるべきハードウエアに対する
特定のプログラムであり、極めて特殊化されている。こ
の試験手続きを呼び出し及び又は動作させるための情報
は診断プログラム自身の中にハードコード化されている
のが普通である。所与の診断プログラムを部分的に変更
して本来意図した使用目的以外の要求に適合させること
はできないので、所与のタスクを単独又は共同で遂行す
るように相互接続された複数のコンピユータを有する複
数コンピユータネツトワークにおけるその使用可能性が
極めて制限されていた。

【０００４】スクリプトフアイルを書くことによりアプ
リケーシヨンプログラムを制御し得ることも当分野にお
いて知られている。スクリプトはユニツクス（Ｕｎｉ
ｘ）又はこれと互換性のあるオペレーテイングシステム
内の準プログラムであり、実行すべき手続きのセツトを
定義する。これらの手続きは、アプリケーシヨンプログ
ラムを呼び出し、コンピユータユーザからＩ／Ｏを受け
取り、パラメータに基づいて論理的に判断することがで
きる。しかしながらこれらのスクリプトプログラムは正
規のアプリケーシヨンプログラムと同様に柔軟性に欠け
るなどの多くの欠陥に悩まされる。付加的なステツプ又
はプロセスを追加するにはプログラム自身を変更するこ
と必要があり、これは単に複雑になるばかりでなく、プ
ログラミングの状態次第ではプログラムの他の領域に望
ましくない結果を生じさせる可能性がある。

【０００５】複数コンピユータネツトワークにおけるプ
ロセス間通信を支援するために、幾つかの技術ではプロ
セス名に基づくプロセス文脈作成の概念を使用する。こ
の文脈がプロセス名に基づく継承のプロセスを通じて得
られるならば、このプロセス文脈はプロセス始動の順序
に基づいて固定されたものとなる。分散環境にプロセス
全体の意味規則を拡張するか又は全体的に変化させる概
念は存在しない。

【０００６】階層的にネツトワーク化されたコンピユー
タ環境を支援することができる、高度にモジユール化さ
れた柔軟な試験機構を提供する必要がある。また、こう
した環境における実時間動作をシミユレートできるよう
にすることにより、アーキテクチヤの性能や動作間の問
題点を検出できるようにする必要もある。

【０００７】本発明の目的はデータ処理システム用に階
層的試験フレームワークを提供することである。

【０００８】本発明の他の目的はモジユール化された試
験環境を提供することである。

【０００９】本発明のさらに他の目的は複数コンピユー
タのデータ処理システムに、モジユール化された試験環
境を提供することである。

【００１０】本発明のさらに他の目的はデータ処理シス
テム内の複数のコンピユータを試験する共通ユーザイン
タフエースを提供することである。

【００１１】本発明のさらに他の目的は多重処理環境に
ホスト間通信機構を提供することである。

【００１２】

【課題を解決するための手段】かかる課題を解決するた
め本発明においては、複数コンピユータデータ処理シス
テムにおける多重プロセスを呼び出す方法において、複
数コンピユータデータ処理システムによつて単一のシス
テム意味規則を作成するステツプと、単一のシステム意
味規則を用いることによりローカルデータプロセツサ及
び遠隔データプロセツサの双方に多重プロセスを呼び出
すステツプとを含むようにする。

【００１３】また本発明においては、複数コンピユータ
データ処理システムにおける多重プロセスを管理する方
法において、コンピユータ上で実行するプロセスのため
にコンピユータの機械名を固有のプロセス識別コード
（ＩＤ）と結び付けることにより複数コンピユータの固
有のプロセス識別コード（ＩＤ）を作成するステツプ
と、複数コンピユータの固有のプロセス識別コード（Ｉ
Ｄ）を用いることにより複数コンピユータデータ処理シ
ステムにおける多重プロセスを制御するステツプとを含
むようにする。

【００１４】また本発明においては、分散データ処理シ
ステムにおけるプロセス間通信に透過性を提供する方法
において、ローカルプロセツサにおいて、遠隔プロセツ
サ上に存在する遠隔プロセスの実行を初期化するステツ
プと、遠隔プロセスを登録することによりアクセス情報
を動的に提供するステツプとを含むようにする。

【００１５】また本発明においては、複数コンピユータ
データ処理システムにおける多重プロセスを呼び出すシ
ステムにおいて、ローカルデータプロセツサと、遠隔デ
ータプロセツサと、単一のシステム意味規則を用いるこ
とによりローカルデータプロセツサ及び遠隔データプロ
セツサの双方における多重プロセスを呼び出す手段とを
設けるようにする。

【００１６】また本発明においては、複数コンピユータ
データ処理システムにおける多重プロセスを管理するシ
ステムにおいて、コンピユータ上で実行するプロセスの
ためにコンピユータの機械名を固有のプロセス識別コー
ド（ＩＤ）と結び付けることにより複数コンピユータの
固有のプロセス識別コード（ＩＤ）を作成する手段と、
複数コンピユータの固有のプロセス識別コード（ＩＤ）
を用いることにより複数コンピユータデータ処理システ
ムにおける多重プロセスを制御する手段とを設けるよう
にする。

【００１７】さらに本発明においては、分散データ処理
システムにおけるプロセス間通信に透過性を提供するシ
ステムにおいて、ローカルプロセツサにおいて、遠隔プ
ロセツサ上に存在する遠隔プロセスの実行を初期化する
手段と、遠隔プロセスを登録することによりアクセス情
報を動的に提供する手段とを設けるようにする。

【００１８】

【作用】多重試験用のフレームワーク／足場を提供する
方法及びシステムを開示する。またこの中には試験プロ
セスを自動化し単純化する試験ツールも含まれている。
本発明のデザインはネツトワーク化及びタスク同時実行
を処理する。この試験用足場の狙いは多数のホストコン
ピユータを含む大規模ネツトワークシステムレベルの統
合試験又は単一のホストコンピユータレベルの試験にお
ける機能検証試験を遂行する際に使用し得る柔軟な試験
ケースドライバにある。この試験用足場は大規模試験環
境の必要性に応えるために設計したものである。デフオ
ルトによつてこれらの環境を実行できる能力は一段と小
規模な環境を操作することができる。

【００１９】この文脈においては、「複雑な試験環境」
は多数のホスト上で長時間に亘つて数千の試験を逐語的
に実行する環境として定義される。通常、こうした形式
の試験はシステムレベル統合の問題点の発見を目標とし
ており、しばしばソフトウエア試験サイクルの終点付近
に置かれる。複雑な試験環境を支援するこの足場機能の
うちのほんの幾つかをあげれば、ループ制御と、保管及
び圧縮のオプシヨンと、分散フアイルシステムの支援
と、同じ機械上での同じ試験ケースの多重同時実行の支
援とがある。

【００２０】この試験用足場の他の強みは完全に自動化
されていながらも、実世界の機構を厳密に模倣すること
ができるその能力である。含まれている幾つかの主な機
能エリアには、分散実行管理、顧客シミユレーシヨンの
ための足場作り、同名のスペース内での衝突回避、自動
化状態収集機構、試験ケース独立、多重形式試験用の共
通テスタインタフエース等がある。

【００２１】さらに本発明による方法及びシステムは多
重シナリオドライバレベルを提供し、これは、密にクラ
スタ化されたネツトワーク環境内の機械のシミユレーシ
ヨンと、同じ機械上で同時に実行している多数の人々の
シミユレーシヨンと、人々が実行している実際のタスク
のシミユレーシヨンとができるようにする。例えばこの
中には、ユーザが複数の機械にログインしたりログアウ
トしたりしてタスクを実行し、分散フアイルスペース内
のフアイルを共用し、その正確な状態を示す試験シナリ
オの終端において自動的に作成される報告書を有するよ
うな大企業の、週の就業日を実際にシミユレーシヨンす
る40時間試験シナリオを開始する単一コマンドを実行で
きる能力が準備される。この試験用足場はこの形式のプ
ロセスを自動化するように設計された。

【００２２】この試験用足場の全機能を得るためには、
複数のホスト間で通信するための媒体が存在しなければ
ならない。通信媒体が無ければ、機械シナリオ及び以下
に示すものだけが走行できる。分散環境内に論理処理階
層を作成する機構が提供される。同様に論理処理階層を
越えた拡張も提供される。

【００２３】本発明においては、文脈を任意に定義する
ことができるので、名前又は他の何らかの属性によつて
プロセスをオペレーテイングシステム処理空間内に関係
付ける必要がない。プロセスが構内のコンピユータ上に
存在しようとも、遠隔のコンピユータ上に存在しようと
も、単一のシステム意味規則を使用してこのようなプロ
セスにアクセスすることができる。プロセスに分散文脈
の一部として登録することを許容する機構が提供され
る。登録は階層内のその親を指名していずれかの子プロ
セスによつて明示的に実行されてもよく、また子を生む
ときに親プロセスによつて自動的に実行されてもよい。
この機構により柔軟性が付加され、これにより、実行し
ているプロセスの一部についての知識を必要とせずに実
行時に分散環境内の宛先ノードを選択することができ
る。これは、機械形式に基づいてプロセスを分散させる
能力と、特定のノード又は負荷平衡の考慮のもとに利用
し得る機能とを与える。

【００２４】この方法を使用することにより、この論理
階層に関与することを選択するプロセスが登録しなけれ
ばならないときに幾つかの方法でプロセスが登録し得る
柔軟性を獲得する。以下に例をあげる。

【００２５】プロセスは制御されたプロセスであること
を登録することができる。すなわちプロセスは正規のプ
ロセスとして同一の意味規則で走行することを選択する
ことができる。プロセスはこのモードでは分散環境を有
する。これは、論理処理ツリーの他のプロセスから正規
信号を受け取り、プロセスが出る場合には、期待する結
果をその論理親上に生じさせることができる。

【００２６】プロセスは論理処理ツリーの現在の部分で
あるプロセスに関係があるパーテイとして登録できる。
このモードにおいて同じ通信機構を使用することによ
り、プロセスは特定の事象のための通知専用リスト上に
それ自身を置くことができる。またこのモードにおい
て、論理親は子の死又は他の出口事象について通知され
ることはない。しかしながら、このプロセスは分散環境
空間及びメツセージサービス等の、他の論理処理グルー
プ属性にあやかる。

【００２７】分散環境における汎用サーバで実行できる
ようにこの登録機構を拡張することができ、これによ
り、分散環境内の制御用のシステム透過機能をユーザに
提供する。

【００２８】

【実施例】以下図面について、本発明の一実施例を詳述
する。

【００２９】図１は試験用フレームワークを示し、完全
な試験用足場を具体化したものを包含している。このフ
レームワークは複数の試験シナリオレベル１６、１８、
２０及び２２のためのシナリオドライバ１２を含む。ま
た図２に示すように、シナリオ構築ツール５２と、報告
書フイルタ６４と、標準ジヤーナルプログラミングイン
タフエース７０及び７４を含む試験シナリオ開発のため
のインタフエース定義と、完全なデイレクトリ構造とを
含んでいる。この足場が制御できる範囲は単一の試験プ
ログラムからなる極めて小さな試験シナリオから多数の
ホストと数千の試験プログラムとを包含する極めて大き
くて複雑な試験シナリオに及ぶ。この目的のために４つ
の異なる階層レベルをもつシナリオドライバを提供す
る。

【００３０】本発明が試験用環境を提供することに照準
を合わせている点を認識することが重要である。実際の
試験プログラムを提供するものではない。この足場は良
好に定義されたインタフエースを有し、このインタフエ
ースは試験プログラムを書き込むための構造を最小限要
求するにすぎない。この足場は個々のテストプログラム
のサイズ及び又は複雑性に制約を課すことはない。この
足場の下で実行する試験プログラムはオペレーテイング
システムコマンドを実行してそのリターンコードを検査
することができるか又は１ダースの機械からなる環境シ
ナリオを開始することができる。

【００３１】（アーキテクチヤの概観）

【００３２】（１）用語、（２）モデル、（３）システ
ム要求の３つの観点からアーキテクチヤに関して詳細に
説明する。

【００３３】用語の部門は当該明細書を通じて用いる用
語についての小辞典である。アーキテクチヤのモデルは
２つ存在し、このモデル部門においては構成要素につい
て説明する。システム要求部門では現在のアーキテクチ
ヤによつて課される要求について詳述する。

【００３４】（１）用語

【００３５】「アプリケーシヨンプログラミングインタ
フエース（ＡＰＩ）」はアプリケーシヨンに対するイン
タフエース又は機能のセツトである。

【００３６】「開始フツク」はその下にある試験シナリ
オを実行する前にシナリオドライバによつて実行される
ユーザコードである。シナリオ実行ステージの間試験シ
ナリオのカストマイズを支援することを意図するもので
ある。

【００３７】「分散フアイルスペース」は複数のホスト
によつて共用されるデイレクトリ構造である。ネツトワ
ークフアイルシステムＮＦＳ（サン・マイクロシステム
社の商標）はこの概念の最も一般的なＵＮＩＸによる具
体化である。

【００３８】「終了フツク」はその下にある試験シナリ
オを実行した後にシナリオドライバによつて実行される
ユーザコードである。シナリオ実行ステージの間試験シ
ナリオのカストマイズを支援することを意図するもので
ある。

【００３９】「環境シナリオ」は試験シナリオレベルで
あり、関連する機械と、個人と、タスクシナリオとをネ
ツトワーク環境内でまとめてグループ化する際に使用さ
れる。

【００４０】「環境シナリオドライバ」は自動化された
プログラムであり、環境シナリオの実行を制御する。

【００４１】「機械シナリオ」は試験シナリオレベルで
あり、関連する個人及びタスクシナリオを単一のホスト
上でまとめてグループ化する際に使用される。

【００４２】「機械シナリオドライバ」は自動化された
プログラムであり、機械シナリオの実行を制御する。

【００４３】「個人シナリオ」は試験シナリオレベルで
あり、関連するタスクシナリオをまとめてグループ化
し、顧客をシミユレートする際に使用する。

【００４４】「個人シナリオドライバ」は自動化したプ
ログラムであり、個人シナリオの実行を制御する。

【００４５】「報告書フイルタ」はシナリオジヤーナル
及び又はタスクジヤーナルを読み取つて読み易い報告書
を作成するプログラムに与えられる総称名である。

【００４６】「シナリオ構築ツール」はメニユー方式プ
ログラムであり、シナリオ定義フアイル及びシナリオイ
ンスタンスフアイルを管理できるようにする。

【００４７】「シナリオ定義フアイル」はユーザ定義属
性と試験シナリオを定義するシナリオドライバ属性との
双方を収容する。定義フアイルは各ユーザ定義属性の形
式と、制限と、デフオルト値と、記述とを表わすユーザ
定義属性に関するテンプレートデータ及びシナリオドラ
イバ属性についての実際のテンプレート値を収容する。
定義フアイルはシナリオインスタンスフアイルを作成す
るためのテンプレートを形成する。

【００４８】「シナリオ開発ステージ」はその中ですべ
てのユーザタスクコード及びシナリオ構成情報を開発し
デバツグするステージである。

【００４９】「シナリオドライバ」は他の下位レベルシ
ナリオドライバ又はユーザタスクコードの実行を駆動又
は制御するプログラムに与えられる総称的な用語であ
る。

【００５０】「シナリオドライバ属性」は主要なシナリ
オドライバ構成方式である。これらを使用して、シナリ
オドライバの機能を定義及び又は変更する。

【００５１】「シナリオ実行ステージ」はその中で試験
シナリオを実行するステージである。

【００５２】「シナリオインスタンスフアイル」はシナ
リオドライバ属性と、試験シナリオを定義するユーザ定
義属性との双方を収容する。シナリオインスタンスフア
イルはシナリオドライバ属性及びユーザ定義属性の双方
についての実際の値を収容する。

【００５３】「シナリオジヤーナル」は標準ジヤーナル
であり、これはシナリオ実行に関する高レベルデータを
収容する。

【００５４】「タスク支援フアイル」はタスクを文書化
するデータを収容する。

【００５５】「タスクジヤーナル」はユーザタスクコー
ドによつて利用される標準ジヤーナルである。試験シナ
リオで実行するタスクのすべてのインスタンスについて
１つのタスクジヤーナルが存在する。

【００５６】「タスクシナリオ」はユーザコードからな
る試験シナリオレベルである。これはテストケースの等
価物と考えることができる。

【００５７】「タスクシナリオドライバ」は自動化され
たプログラムであり、タスクシナリオの実行を制御す
る。

【００５８】「タスク設定コード」はユーザコードであ
り、シナリオ実行ステージの間試験原始コードをコンパ
イルする際に使用される。

【００５９】「試験シナリオ」は試験の選択されたグル
ープ化に与えられる総称名である。

【００６０】「ユーザ定義属性」はユーザタスクコード
にデータを運ぶ際に使用される変数である。

【００６１】「ユーザタスクコード」は試験目的のため
のタスクシナリオ開発者によつて書き込まれるコードで
あり、通常テストケースと呼ばれるものと同義である。

【００６２】（２）モデル

【００６３】本発明の主要構成要素のアーキテクチヤレ
ベルでのすべての対話を記述するために、以下に示す２
つのモデル（Ａ）及び（Ｂ）を使用する。第１のモデル
は各シナリオドライバの対話と、シナリオドライバが実
行するオブジエクトと、試験シナリオに対するシナリオ
ドライバの関係とを記述する。第２のモデルは本発明を
構成する構成要素同士の対話を記述する。

【００６４】（Ａ）シナリオドライバ対話アーキテクチ
ヤモデル

【００６５】図１に示すように、シナリオドライバ対話
アーキテクチヤモデル１０は各シナリオドライバ１２の
対話と、シナリオドライバが符号１４において実行する
オブジエクトと、試験シナリオに対するシナリオドライ
バの関係とを記述する。このモデルの構成要素の外郭を
略記した長方形１６、１８、２０及び２２は試験シナリ
オを表し、デイスクアイコンはデータ記憶場所７２、２
６、２８、３０及び３２を表し、ブロツク１２はプログ
ラムを表し、陰影を付した四角のブロツク６８はシナリ
オ開発者によつて開発されるコードを表す。

【００６６】このモデルは試験シナリオ１６、１８、２
０及び２２とこれらに対応するシナリオドライバ１２と
の間の関係を示す。定義された試験シナリオはいずれ
も、その実行を制御する１つのシナリオドライバ１２
と、その特定の試験シナリオを定義するのに必要な構成
情報を提供する１つのシナリオインスタンスフアイル
（例えば２６、２８、３０及び３２）とを有する。

【００６７】シナリオドライバ対話アーキテクチヤモデ
ル１０は、タスクシナリオレベル１６を介して環境シナ
リオレベル２２から受け取る各試験シナリオレベルにお
いてはシナリオドライバ要素１２は同じであるが、シナ
リオインスタンスフアイルは異なることを示している。
好適な実施例には、各シナリオドライバと関連付けた１
つのシナリオインスタンスフアイルが存在し、１つのシ
ナリオドライバ要素が存在するが、その動作はシナリオ
インスタンスフアイルの内容に極めて大きく左右され
る。

【００６８】このモデルが示すように、他のシナリオド
ライバを制御するシナリオドライバはこれらのドライバ
を同時に１つ又は２つ以上制御することができる。これ
は階層的試験の一式を実現させ、これにより、他の試験
シナリオからなる試験シナリオを定義することができ
る。ユーザタスクコードを実行するタスクシナリオドラ
イバはユーザタスクコードの一片だけを制御する。従つ
て試験シナリオで実行されるユーザタスクコードの個々
の各構成要素には単一のタスクシナリオドライバが存在
する。

【００６９】このモデルから認識すべき最も重要な事項
の１つは、シナリオドライバ１２はユーザコードのただ
一片の実行を制御する以上のことを行うということであ
る。このような機能に加えて、シナリオドライバ１２は
ネツトワーク化した環境内のホストのセツト全体を制御
する能力をも有する。

【００７０】また機械シナリオドライバによつて複数の
個人シナリオドライバを実行することができるので、シ
ナリオドライバは１つのホスト上で実行している複数の
人々をエミユレートする機能をも有する。これらの各個
人ドライバは一組のタスクシナリオドライバを実行する
能力を有し、次に個人ドライバはシナリオ開発者の試験
コードを実際に実行する。この階層的モデルは凝集性ネ
ツトワーク環境における実個人エミユレーシヨンと非並
行柔軟性とを実現し、すべてを１つの環境シナリオドラ
イバから中央制御して自動化する。

【００７１】（Ｂ）構成要素対話アーキテクチヤモデル

【００７２】図２は構成要素対話アーキテクチヤモデル
５０を示し、本発明のすべての主要なアーキテクチヤ構
成要素の対話を示す。デイスクアイコン５４、５６及び
６２はデータ記憶場所を表し、ブロツク５２、５８、６
０及び６４はプログラムを表す。陰影を付したプログラ
ムブロツク６８はシナリオ開発者が開発したユーザコー
ドを表す。

【００７３】このモデルは、シナリオ定義フアイル５６
及びシナリオインスタンスフアイル５４の主要な対話が
シナリオ構築ツール５２を通じて遂行されることを示し
ている。シナリオ構築ツール５２を用いてシナリオ定義
及びインスタンスを管理し、シナリオ開発者を用いてシ
ナリオ構築ツール５２にアクセスする。

【００７４】シナリオ定義フアイル５６はシナリオにつ
いての構成情報を定義し、シナリオインスタンスフアイ
ル５４を作成するテンプレートとして使用される。シナ
リオインスタンスフアイル５４はシナリオドライバの入
力であり、シナリオ実行ステージの間シナリオドライバ
構成情報を供給する。

【００７５】シナリオドライバ５８はその入力としてイ
ンスタンスデータを読み取り、シナリオドライバ６０及
び又はユーザコード６８の他のセツトを実行する。各シ
ナリオドライバレベル間にはインタフエースが存在し
（図１の符号１４）、またシナリオドライバ及びユーザ
コード間にもインタフエースが存在する（図２の符号７
０）。これらのインタフエースはシナリオドライバ及び
実行できるオブジエクトの組み合わせによつて変わる。

【００７６】シナリオドライバによつて実行されるシナ
リオドライバをモデルの上辺に単一プログラムとして示
す。しかしながらシナリオドライバは同時に複数のシナ
リオドライバを実行することができる。次にこれらの各
シナリオドライバは主シナリオドライバプログラムが配
置されている、このモデルの中央部に入る。主シナリオ
ドライバプログラムはこれらを実行したシナリオドライ
バと同一の考え得る対話のセツトを有する。

【００７７】いずれかのシナリオドライバからのジヤー
ナルへの記入はシナリオジヤーナルドライバプログラミ
ングインタフエース７８を経由してシナリオジヤーナル
に対してなされる。好適な実施例において、同じシナリ
オ内で実行する機械上のすべてのシナリオドライバは同
じシナリオジヤーナル６２に記入する。

【００７８】試験用足場の各ユーザコード構成要素はこ
のモデル内の単一のユーザコードプログラムボツクス６
８にグループ化される。ユーザコードはタスクジヤーナ
ル７２に記録を記入し、開始フツク及び終了フツクユー
ザコードの実行はシナリオジヤーナル６２に記入する。
同じシナリオ内で実行しているユーザタスクコードの各
インスタンスは自身の固有のタスクジヤーナルに記入す
る。

【００７９】シナリオジヤーナル６２及びタスクジヤー
ナル７２のフオーマツトは首尾一貫しているので、報告
書フイルタ６４はジヤーナルを読んで、明瞭な報告書６
６を作成することができる。

【００８０】（３）システム要求

【００８１】上述のアーキテクチヤ及びデザインによつ
て課される一組のアーキテクチヤ要求を以下に示す。

【００８２】（階層的フアイルシステム）

【００８３】オペレーテイングシステムのフアイルシス
テムはデイレクトリ内にデイレクトリを有し、いかなる
点においてもこれらのデイレクトリ内にフアイルする能
力を組み込んでいなければならない。標準的なＵｎｉｘ
オペレーテイングシステムはこの機能を提供する。

【００８４】（子プロセス）

【００８５】オペレーテイングシステムは同時に実行で
きる複数の子プロセスを作成し得る実行プロセスを有す
ることができなければならない。また親プロセスは子プ
ロセスを上回る幾つかの制御を有していなければならな
い。標準的なＵｎｉｘオペレーテイングシステムはこの
機能を提供する。

【００８６】（ホスト間通信）

【００８７】ホスト間通信は特定のシステム上でユーザ
実行レベルで実行する。これにより、下にあるオペレー
テイングシステムを変更する必要なく上述の機能を実行
することができ、またその通信チヤネルのための基本的
システムサービスだけに依拠するので「オープンシステ
ム」解決であるという付加的利益をも得ることができ
る。このように通信機構は通信プロトコルから完全に独
立している。それはメツセージ受渡しサービスであるの
で、メツセージ受渡しに使用する実際のプロトコルはメ
ツセージ受渡しの実際のプロセスから独立している。メ
ツセージ受渡しのためのＡＰＩはsend packet()であ
る。パケツトをいかにして引き渡すかの詳細は、与えら
れた機械／オペレーテイングシステム実行のためのsend
packetのインプレメンタに似ている。ソケツトを用い
ることによつて通信機構の実現を例示する。この特性に
よつて与えられる付加的な柔軟性はメツセージシステム
で複数のプロトコルを使用することができ、これにより
システムが所与の状況の中で最高性能の通信を動的に選
択できるようになることである。例えば、ソケツトを使
用してシステム境界を越えて通信し、ボツクス内通信用
の共用メモリ又はメツセージキユーを使用することを望
むことがある。アーキテクチヤにより、send packetに
同じ呼出しを行うことにより呼出しプロセスには見えな
い両方のタスクを実行することができる。

【００８８】論理プロセススペースを動的に再配置して
プロセスを論理プロセススペースに任意に挿入すること
ができるので、分散プロセス制御に新しい次元が開け
る。これにより、このレベルの制御において、現在は実
行できない幾つかの機能を実行することができる。

【００８９】通常は関係のないプロセスを中央制御する
ことができるだけでなく、トツプノードからの論理プロ
セスフアミリの完全なビユーを保存することができる。 − 親との通信（反復的） − 即時論理処理フアミリとの通信 − 現在のフアミリの対等者との通信 − 論理処理ツリーの一切の構成要素との任意の通信 − − プロセスを始動し文脈を動的に指定する − − 論理的階層の実行時操作 − 故障中のプロセツサからの操作プロセス − サーバ障害 − 通知経路の変更 − グローバルな基礎の上に立つた環境データの動的変
更 − プロセス通知 − 負荷平衡

【００９０】この論理フアミリの表示に付加される要素
は拡張ＰＩＤである。１つの多重処理システム上で種々
の機構を使用することにより各プロセスは固有のプロセ
スＩＤを伴つて確実に走る。これらの機構は２つ以上の
オペレーテイングシステムインスタンスが環境内に存在
するときには機能を継続しない。分散形論理処理ツリー
の場合には、機械名と機械固有のプロセスＩＤとの組合
わせを使用してこの文脈内のプロセスを識別する。いず
れか１つのオペレーテイングシステムインスタンス上の
固有のプロセスＩＤの保証と固有の機械ＩＤの技法とが
与えられた場合、分散環境内の処理についての固有のＩ
Ｄを保証することができる。

【００９１】論理処理階層の構造が与えられた場合、通
常利用できない付加的機能を利用することができる。こ
のシステムの柔軟性によつてリカバリシナリオをもつこ
とができ、これにより、被制御プロセスの場合の新しい
親にプロセスを動的に再割り当てすることができる。こ
れは、既存の多重処理システムと同様の意味規則を許容
するので、プロセスの親が死んだ場合にプロセスの継承
を生じさせる。この場合を除けば、リカバリシナリオは
バツクアツププロセス及び冗長プロセスに死んだ親の子
を継承させるよう真先に指定されてよい。これにより、
論理処理階層はサーバ又は制御処理の障害に耐えて予測
しうる制御された手法を継続することができる。

【００９２】上述の通信アーキテクチヤの付加的利益に
は、（１）論理フアミリ階層に加わる以外の目的で登録
プロセスを使用する能力及び（２）ノード障害が生じた
場合にプロセスを動的に再割り当てする能力を含む。

【００９３】以下に、メツセージ受渡しのために選択さ
れる制御プロセスを実行する際に用いられる機構及び分
散形試験環境ドライバによつて使用されるプロセス間通
信を説明する。

【００９４】環境全体をシミユレーシヨンする、単一シ
ステム上にある制御点をもつた多数のシステム上で、何
らかの利用しうる試験を駆動し追尾し制御できるように
することが試験ドライバの目的である。この目標を達成
するには、単一の機械上で試験環境を駆動することから
予想される手法と全く同じ手法で環境内のドライバが通
信することができるような通信機構を確立する必要があ
る。

【００９５】ドライバ自身の実施を簡単にするため、試
験ドライバに対して使用しうる機能のライブラリとして
この通信機構が実施され、各機械上に制御デーモンを設
けて分散形ｉｐｃを提供する。この実施技術を使用する
ことによつてライブラリ内への通信機能及び制御デーモ
ン内への制御機能を分離したので、ドライバは、分散環
境内でメツセージを受け渡す際に使用されるネツトワー
ク形式又はプロトコル形式を知つている必要はない。

【００９６】ここで制御デーモンについて概略的に説明
する。

【００９７】図３２に示すように、この分散形試験に加
入することを期待される各機械３４２上で制御デーモン
（サーバ）３４０が走る。分散環境３３８の制御の下に
ある試験ドライバ１２はこれらが実行されている機械３
４２上のサーバ３４０に登録されることを期待される。
他のプロセス及び他のプロセツサとの通信はすべて試験
ドライバ１２が実行している機械のためのサーバを経由
してなされる。これにより、遠隔の機械上で子プロセス
を生むことができると共に、処理が完了したならば子の
死を親機械で受け取ることができる。同じプロセツサ上
又は遠隔プロセツサ上であつても、登録技術を用いるこ
とにより、親プロセスの直接の子孫ではない子をサポー
トすることもできる。ドライバタスクの実行及び終了を
中央点を介して制御することによつて、この分散環境３
３８の下で走つている一切のタスクドライバ１２からリ
ターンコード情報を得ることができる。

【００９８】また制御デーモン３４０は登録された各プ
ロセスについての個別のメツセージキユー用の機能３４
４だけでなく、試験環境３３８全体に亘る環境変数の保
守及び検索の機能をも有する。

【００９９】この環境に加わるためには、プロセスはサ
ーバ３４０に登録しなければならない。これはライブラ
リ内のレジスタ関数呼出しを送出することによつて達成
される。プロセスが登録を選択をすると、サーバにクラ
イアントレコードが作成され、サーバ使用のためのその
クライアントにハンドルが割り当てられる。ハンドルを
登録プロセスに戻して、サーバとのその後の通信に使用
する。

【０１００】制御されたこのプロセスが処理を終了する
と、終了コマンドをサーバに送出することによりその処
理が完了したことを表示しなければならない。終了コマ
ンドは現在のプロセスのリターンコードの受渡しを要求
する。プロセスが終了コマンドを送出すると、終了プロ
セスが妨害し、サーバは、子が終了していて親プロセス
がその子を終了させることを待ち受けている親メツセー
ジキユーにメツセージをエンキユーする。親は release
child 関数呼出しを送出し、子はそのメツセージの受
信を扱う。サーバが release child コマンドを受け取
ると、子は終了準備ができている旨の信号を受け取り、
クライアントデータ構造がサーバ内で解除される。

【０１０１】ここでＩＰＣライブラリ関数について概略
的に説明する。

【０１０２】分散されたｉｐｃ層へのアクセスはＩＰＣ
ライブラリ関数(ipclib.a)を経由してアクセスされる。
これらの関数はコミユニケーシヨン３４８にアクセスす
るためのユーザレベルＡＰＩ３４６（図３２）を提供
し、サーバによつて提供される機能に役に立つ。

【０１０３】下記のことはipclibから利用することがで
き、試験ドライバ内の制御フローに従つてブレークダウ
ンされる。

【０１０４】ここで初期化について説明する。

【０１０５】set signals()

【０１０６】set signals コマンドは信号ハンドラの
初期化に使用される。信号ハンドラはライブラリに構築
され、サーバからクライアントに送られるメツセージを
処理する機能と、子の死及びプロセスの終了を処理する
機能とを有する。この技法を使用すれば、ドライバ開発
者はこの呼出しをドライバコードに含んでいることだけ
が必要となり、すべての信号処理はipclib信号ベクトル
を用いて自動的になされる。

【０１０７】ここで登録及び終了について説明する。

【０１０８】register client(int handle)

【０１０９】これは正規の登録コマンドであり、プロセ
スが始動するとこれをローカル制御デーモン（サーバ）
に登録してｉｐｃ通信チヤネルに加わらなければならな
い。このコマンドの送出はハンドルの値に基づいて異な
る結果を発生させることがある。

【０１１０】図３４を参照する。プロセスはブロツク３
９０において start process 関数呼出しによつて始動
するとき、環境変数は、そのプロセスが使用すべきハン
ドルの値を含む(AUS PHANDLE)をセツトされる。ブロツ
ク３９２で登録されると、プロセスは環境変数に与えら
れるハンドルを使用する（ブロツク３９６）。このハン
ドルは子をサーバに予め登録することによつて作成され
たものであり、既に親に知られている。これを実行した
とき、サーバ内のクライアントレコードが更新され、こ
れを子に通知した親が始動する。正しいハンドルがこの
インスタンスに渡されると、register clientルーチン
が渡されたハンドルと同一のハンドルを戻す。

【０１１１】ブロツク３９４で判定されたように、プロ
セスがトツプレベルプロセスとして始動すると、ハンド
ルの値はゼロになる。このことは、ブロツク３９８に示
すように、これがトツプレベルプロセスであり、サーバ
がこのプロセスの親として振る舞うことを示している。
この場合、register clientルーチンは新しいハンドル
値を戻し、このハンドルが将来このクライアントのため
に使用されることを示している。

【０１１２】ブロツク４００から開始し、クライアント
プロセスは登録パケツトを準備してこのパケツトをサー
バに送り、ブロツク４０２でこれを受け取る。登録パケ
ツトを受け取ると、ブロツク４０４においてサーバはこ
のパケツトに格納されているハンドルが既にサーバクラ
イアントテーブルに存在するか否かを確認する。ハンド
ルが存在しないとき、ブロツク４０６においてサーバは
新しいハンドルを構成し、サーバクライアントテーブル
内の新しいクライアントレコードを初期化し、ブロツク
４０８において登録パケツト内のハンドルをクライアン
トに戻す。ブロツク４０４においてクライアントテーブ
ルにハンドルが存在することをサーバが確認すると、サ
ーバはサーバクライアントテーブルを更新する。ハンド
ルによつて示されるプロセスの現在の状態次第では、更
新プロセスは２つの形式をとり得る。ハンドルと一致す
るテーブルエントリがペンデイング状態にあるとき、そ
のエントリは有効とマークされ処理を継続する。テーブ
ルエントリが有効とマークされたとき、このクライアン
トのために新しいハンドルが作成され、サーバクライア
ントテーブルに新しいテーブルエントリが作成される。
この場合ハンドルに割り当てられる値は新しいテーブル
エントリの値である。ローカルサーバクライアントテー
ブルが更新されると、ブロツク４１２においてサーバは
プロセスの親ホストを検査し、このプロセスの親がロー
カルであるか遠隔であるかを判定する。親がローカルシ
ステム上にあるとき、ブロツク４２２においてサーバは
親のハンドルを検査する。親がサーバでないとき、ブロ
ツク４２４において親プロセスが通知される。この通知
は親のメツセージキユーにメツセージをエンキユーし、
メツセージがペンデイングであるという、親プロセスへ
の信号を処理することによつて達成される。親はメツセ
ージを検索してローカル子状態レコードを作成する。次
にブロツク４０８において、このプロセスのためのハン
ドルをもつ登録パケツトが登録プロセスに戻される。ブ
ロツク４２２において親がサーバであると判定される
と、親プロセスの通知は必要ないので、ブロツク４２６
においてハンドルは登録プロセスに戻される。

【０１１３】図３４のブロツク４１２に戻り、ここで親
が遠隔であると判定されると、ブロツク４１４において
ローカルサーバクライアントテーブルを更新することに
よりこのプロセスが登録されたことを表示する。ブロツ
ク４１６において、登録パケツトはローカルサーバによ
つて準備されて遠隔サーバに送られる。次にローカルサ
ーバは遠隔処理が完了するまで待機する。パケツトを受
け取ると、ブロツク４１８において遠隔サーバは遠隔サ
ーバクライアントテーブルを更新することによりこのプ
ロセスが登録されたことを表示する。親プロセスは遠隔
コンピユータ上に存在するので、ブロツク４２０におい
て親プロセスの通知が遠隔サーバによつて実行される。
この通知がエンキユーされると、遠隔サーバは登録パケ
ツトをローカルサーバに戻す。次に、ブロツク４０８に
おいてローカルサーバはローカルシステムに関する最終
情報をもつパケツトを更新すると共に、登録プロセスの
ハンドルをもつパケツトを戻し、かくしてブロツク４２
８において登録を完了する。

【０１１４】これ以外の２つの状況も考えられる。
（１）ハンドルが無効である。この場合プロセスはサー
バによつて採用され新しいハンドルが戻される。（２）
ハンドルが既に使用されている。この場合、受け渡され
るハンドルは親ハンドルであると解釈され、子は受け渡
されるハンドルの子として登録され、新しいハンドルが
戻される。

【０１１５】xx terminate(int handle, int rc)

【０１１６】プロセスが出るに前にこの終了（terminat
e ）を使用する。終了するプロセスのハンドル及び親に
戻されるべきリターンコードがパラメータとして使用さ
れる。終了コマンドの意図はリターンコードが親プロセ
スに戻れるようにすることである。子が死んだとの通知
を親が確実に受け取るようにするため、終了プロセスは
信号に従うことを妨害する。サーバは、親メツセージキ
ユーにメツセージをエンキユーすることによつて親プロ
セスに通知し、メツセージがペンデイングであることを
信号で親に知らせる。親信号ハンドラーはこの信号を捕
捉してメツセージを入手し、親子データテーブルを更新
して release child コマンドを送出する。このコマン
ドを使用することにより、サーバは終了プロセスのため
のクライアントテーブルエントリを一掃し、SIGUSR2 信
号を子に送る。

【０１１７】この信号を受け取ると、子プロセスはその
退出を完了する。またこの信号の捕捉に使用される信号
ハンドラーはipclibの一部であり、これを操作するのに
ユーザによるコード化は必要ない。

【０１１８】ここで注意することは、メツセージ受渡
し、通知、登録又はクライアントに代わつてサーバによ
つて処理される一切の機能について述べたが、動作が常
に適切な機械上で生ずることを想定して述べたというこ
とである。サーバはプロセスがどこを走つているかを知
ることに注意し、適切なサーバインスタンスについての
要求を送ることによりコマンドの完了を確実にする。次
に説明するものは、サーバで使用される通知コマンドで
ある。通知コマンドは通知（handle、sigval）の構文を
有する。クライアントデータ構造については後に詳述す
るが、サーバが各クライアントレコードに組み合わせら
れているクライアントホスト及び親ホストを有すること
を今知つておく必要がある。このコマンドが送出される
と、サーバはハンドルによつて指示されるクライアント
ホスト名を探し、この名前がサーバのホスト名と同じで
あるとき、キル<sigval> pidを送出してクライアントに
通知する。ホスト名が一致しないとき、クライアントデ
ータ構造のクライアントホスト名によつて指示されるホ
スト名にコマンドパケツトが送られる。このコマンドパ
ケツトはそのホストとこのプロセスに関わる機械上に出
されるキルとによつて受け取られる。

【０１１９】（標本プロセスの流れ）

【０１２０】図３５及び図３６は標本プロセスの流れ及
びその結果としての状態を示す。図３５はサーバ及びク
ライアントプロセス間に存在する相互関係を示す。図３
５は分散形通信機能を用いて幾つかのプロセスを始動さ
せた後のシステム状態のスナツプシヨツトを示す。符号
４３０のシステム１及び符号４５０のシステム２はその
上で走つているサーバのインスタンスを有する。システ
ム１（Ｓ１）に関わるサーバは符号４３２で示し、シス
テム２（Ｓ２）に関わるサーバは符号４５２で示す。下
記のシナリオに従うことにより図３５に示すシステム状
態に到達する。

【０１２１】システム１（Ｓ１）におけるシナリオ。
（０）サーバはクライアントテーブルを初期化し、それ
自身をハンドル「０」として加算する。（１）プロセス
１０１がＳ１上で始動した（４３４）。（２）プロセス
１０１が登録する。（３）プロセス１０１がプロセス１
０２を始動させる（４３８）。（４）プロセス１０２が
登録する。（５）プロセス１０２がプロセス１０３を始
動させる（４４０）。（６）プロセス１０３がプロセス
１０４を始動させる（４４２）。（７）プロセス１０４
が登録する。

【０１２２】システム２（Ｓ２）におけるシナリオ。
（０）サーバはクライアントテーブルを初期化し、それ
自身をハンドル「０」として加算する。（１）プロセス
２０１がＳ２の上で始動した。（２）プロセス２０１が
登録する。（３）プロセス２０１がプロセス２０２を始
動させる（４５６）。（４）プロセス２０２が登録す
る。（５）プロセス２０２がＳ１上でプロセスを始動さ
せる。（６）Ｓ２サーバはプロセスを始動させるように
Ｓ１サーバに要求する。（７）Ｓ１がプロセス１０５を
始動させる（４３６）。（８）プロセス１０５が登録す
る。

【０１２３】この図を示した理由は、分散環境に単一シ
ステム意味規則を提供するのに必要な機構を説明するた
めの基準点を与えるためである。通信する情報にかかわ
らず、基本的な通信経路は同じである。これによつて、
メツセージ、環境データ、信号又はこれら以外の必要と
されるもののサービスに同じモデルを使用することがで
きる。通信モデルの重要な要素は論理的親子関係であ
り、このモデルにはこの論理的親子関係が保持されてい
る。このモデルが克服する主たる制限は、親プロセスか
ら２世代以上も離れているプロセスから状態情報を入手
するという問題である。この問題点を解決するため、こ
の論理的フアミリツリーに関わりのあるプロセスはロー
カルサーバに登録しなければならない。サーバに登録す
るプロセスにはハンドルが割り当てられ、サーバのクラ
イアントテーブルに挿入される。この登録プロセスから
作成されるサーバテーブルと、その反映である図３５の
システムスナツプシヨツトとについて次に説明する。

【０１２４】Ｓ１すなわち符号４３０上にあるサーバ４
３２用のクライアントプロセステーブルを図３６の４６
０に示す。ハンドル「０」はサーバデーモンプロセス
（図３５の４３２）のために使用するものであつたが、
このサーバのための情報をクライアントプロセステーブ
ル４６０の行４６２に示す。ここで、サーバ４３２は登
録済であり、現在のプロセスハンドルとして「０」を有
し、（親が無いため）親プロセスハンドルは「０」、
（遠隔プロセスによつて初期化されていないため）遠隔
プロセスハンドルは「０」、プロセスＩＤは「23」、
（親が無いため）親プロセスＩＤは「０」、このプロセ
スを走らせているシステム名はＳ１、（サーバプロセス
なので）親が走つているシステム名はＳ１、（環境が定
義されていないため）環境へのポインタは「０」である
ことが判る。環境又はメツセージキユーに値が定義され
ていた場合、このフイールドは現在のメツセージキユー
の頭へのポインタ、メツセージキユーへのポインタ及び
時刻表示を格納する。

【０１２５】図３６のクライアントプロセステーブル４
６０のハンドル１（符号４６４）を参照してみると、こ
の登録エントリはプロセス１０１（図３５の４３４）に
関するものであることが判る。関連するＰＩＤの列を調
べればこれを確認することができる。このテーブルから
判るこれ以外の、プロセス１０１についての興味深い情
報は、親プロセスのハンドル（Ｐｈａｎｄ）は「０」、
親プロセスのＩＤ（ＰＰＩＤ）は「23」、この両者がサ
ーバプロセス４３２に関連していることである。行４６
６（図３５のプロセス１０２に関する）及び行４６８
（図３５のプロセス１０４に関する）の情報は同じＰｈ
ａｎｄ情報及びＰＰＩＤ情報に基づいて同様の形式の親
プロセス関係を示す。

【０１２６】Ｓ１サーバに関するクライアントプロセス
テーブル４６０の最後のエントリを分析する前にまず、
Ｓ２サーバに関するクライアントプロセステーブル４８
０を見る。（図３５の）Ｓ２サーバ４５２はＳ１サーバ
が行４６２に有するエントリと類似のエントリを行４７
２に有することが判る。これら両者の間の違いは、この
場合にはプロセスＩＤ（ＰＩＤ）が「99」であり、シス
テム名がＳ２であることである。

【０１２７】エントリ４７４及びエントリ４７６はシス
テム２上のローカルプロセスを示し、システム１に関し
て既述したテーブルエントリと類似している。エントリ
４７８は遠隔プロセスを記述しているエントリである。
ハンドルは「３」となつており、これが指示しているハ
ンドルによつてプロセスがこのサーバに知られる。親ハ
ンドルは「２」となつており、これは論理親であるＳ２
上のプロセス２０２（図３１の４５６）を示す。遠隔ハ
ンドルは「４」であり、これは遠隔システム上のこのプ
ロセスを記述しているハンドルを示す。プロセスｉｄは
「105 」であり、これはＳ１クライアントプロセステー
ブル４６０の行４７０に示したプロセスｉｄと同じであ
る。親プロセスｉｄは２０２である。プロセスホストは
Ｓ１であり、これが遠隔プロセスであることを示す。親
ホスト又は親プロセスのホストはＳ２である。Ｓ２はプ
ロセス２０２についてのプロセスホストである。

【０１２８】図３６のサーバＳ１についてのクライアン
トプロセステーブル４６０の行４７０を参照すると、ハ
ンドルが「４」のプロセスはプロセスＩＤ１０５（図３
５の項目４３６）に対応することが判る。このプロセス
１０５に関して、親プロセスハンドルは「０」（サーバ
プロセスを示している）、遠隔プロセスハンドルは
「３」（このプロセスはハンドル「３」の遠隔プロセス
と同じであることを示している）、親プロセスＩＤは
「23」（これはローカルサーバであり、すべてのプロセ
スはこのローカルサーバを通じて遠隔機械フアンネルか
ら始動される）、ローカルシステム名はＳ１、親が走つ
ているシステムはＳ２（すなわち、これは遠隔プロセス
から始動された）であることが判る。言い換えれば、行
４７０に示される情報はプロセス１０５にアクセス／管
理するときにＳ１サーバ４３２によつて使用され、この
同じプロセス１０５に使用される情報は行４７８に格納
され、こうしたプロセスにアクセス／管理するときにＳ
２サーバ４５２によつて使用される。このように、単一
のシステム意味規則は分散環境のプロセスにアクセスす
るローカルシステム及び遠隔システムの双方によつて使
用される。

【０１２９】ここまでホスト間通信機構について説明し
てきたが、再びこの試験環境内部の説明に戻る。

【０１３０】環境変数について説明する。

【０１３１】ライブラリは分散環境内に環境変数を有す
るための能力を与える。これらの変数は分散環境によつ
て見られるように親子関係に保持される。この機能は、
変更がなされたレベルよりも下のすべてのレベルにおい
て見られる試験環境内のレベルにおける環境変数を変更
できるようにする。環境変数機能へのアクセスは次の通
りである。

【０１３２】xx putenv(name, value, handle)

【０１３３】このルーチンはローカルサーバ上のハンド
ルが指示するクライアントのための環境を更新する。

【０１３４】xx getenv(name,handle)

【０１３５】このルーチンは受け渡される環境変数名に
関連する値を保持している文字ポインタを戻す。getenv
関数はハンドルが指示する環境を見て情報を得る。それ
が見つからなければ、そのフアミリツリーに従つて、環
境変数を探しているサーバレベルに戻る。環境変数が見
つからなければ、この関数はNULLを戻す。

【０１３６】ここで注意することは、プロセスが遠隔の
親の子であるとき、子が変数名の解明に失敗すれば遠く
から探索を継続することである。getenv要求を伴うサー
バはこの要求を遠隔の親ホストに送り、遠隔ホスト上の
環境ツリーを歩くことを終了する。

【０１３７】xx freenv(name,handle)

【０１３８】このルーチンはローカルホスト上のハンド
ルが示すクライアントについての名前によつて指示され
る環境変数を削除する。

【０１３９】ここで子プロセスの始動について説明す
る。

【０１４０】ライブラリで利用できる他の機能は start
process 機能である。プロセスレベルにおいて、プロ
セスによつて始動するいかなる子の進行をも追跡する能
力を有する。その制御のために使用されるデータ構造を
表（１）に示す。

【０１４１】

【表１】

【０１４２】ここで表中に現れる英文字の列は記号であ
つて、翻訳できない（以下の表においても同様であ
る）。

【０１４３】ドライバプロセスのユーザにとつて重要な
情報は子データ構造の状態フイールド及びリターンコー
ドである。この情報はドライバに、どの子プロセスが未
決であるかを理解させ、これらのプロセスの現在の状態
を理解させることができる。子が完了すると、そのプロ
セスからのリターンコードはそのプロセスに関する chi
ld data構造で利用できるようになる。

【０１４４】表（２）はフイールドの説明である。

【０１４５】

【表２】

【０１４６】関数について説明する。

【０１４７】reserve slot(handle)。親プロセスはこ
の reserve slotルーチンを使用して、サーバで始動さ
せられる子のクライアントスロツトを予約する。親のハ
ンドルを用いて reserve slot関数は呼び出される。こ
の関数からのリターンには子のための新しいハンドルが
使用される。

【０１４８】reserve slotルーチンはプロセス始動ル
ーチンによつて呼び出され、通常はユーザプログラムに
よつて使用されることはない。また reserve slotルー
チンは、呼出されたときに child dataレコードを親の
中に設定し、このレコードはドライバ子データとサーバ
クライアント情報とを関連付けるために使用される。

【０１４９】start process(hostname,command,handl
e)。このプロセス始動コマンドを使用してすべての子プ
ロセスを始動させなければならない。 start process
コマンドは次の３つのパラメータを有する。

【０１５０】（１）hostname−子プロセスの実行を希望
するホスト名を指示する。（２）command −子プロセス
の始動を実行すべくパラメータを伴うコマンドを与え
る。（３）handle−これは親プロセスハンドルである。

【０１５１】図３３に示すように、ブロツク３５０にお
いて start process コマンドを出すと、以下に示す
（１）〜（７）又は（１）〜（９）のシーケンスが生ず
る。

【０１５２】（１）ブロツク３５２においてホスト名を
検査し、ローカルホスト上でのプロセス始動を望むか又
は遠隔ホスト上でのプロセス始動を望むかを決定する。

【０１５３】プロセスがローカルホスト上で走ると判定
されると、以下の（２）〜（７）のシーケンスが生ず
る。

【０１５４】（２）ブロツク３５４において reserve
slotを呼び出して子ハンドルを得る。

【０１５５】（３）ブロツク３５６においてローカルプ
ロセスを始動し、ブロツク３５８において子レコードを
作成する。

【０１５６】（４）ブロツク３６０においてputenvを用
いて新しいハンドルをシエル環境に入れる。

【０１５７】（５）ブロツク３６２において新しいプロ
セスを分岐させ、プロセスｉｄを入手する。

【０１５８】（６）ブロツク３６３において start pr
ocess に渡されたコマンドを実行する。

【０１５９】（７）ブロツク３６４において親の child
dataテーブルをハンドル及び分岐プロセスｉｄで更新
し、ブロツク３６６においてペンデイング状態にする。

【０１６０】ブロツク３６３において子が始動すると、
これをサーバに登録し（上記を参照）、 child dataテ
ーブルエントリは有効状態となる。

【０１６１】ブロツク３５２においてプロセスが遠隔ホ
スト上で走ると判定されると、以下の（２）〜（９）の
シーケンスが生ずる。

【０１６２】（２）ブロツク３７０においてremote co
mmand 関数を呼び出し、遠隔プロセス始動の要求をサー
バに送る。

【０１６３】（３）ブロツク３７２においてローカルサ
ーバは遠隔プロセスに関するクライアントレコードを構
築し、ブロツク３７４においてコマンドパケツトをホス
ト名によつて指示されるサーバに送る。

【０１６４】（４）ブロツク３７６において遠隔ホスト
はコマンドパケツトを受け取り、サーバ上で遠隔実行関
数を処理する。

【０１６５】（５）ブロツク３７８において遠隔ホスト
はプロセスのクライアントテーブル内にスロツトを作成
する。

【０１６６】（６）ブロツク３７８においてputenvを使
用して新しいハンドルをシエル環境に置く。

【０１６７】（７）ブロツク３８０において新しいプロ
セスを分岐させ、プロセスｉｄを入手する。

【０１６８】（８）ブロツク３８１においてコマンドパ
ケツトに渡されるコマンドを実行する。

【０１６９】（９）ブロツク３８２においてクライアン
トデータテーブル内の親のｐｉｄスロツトに分岐プロセ
スｉｄを格納し、ブロツク３８４においてテーブルエン
トリをペンデイング状態に変更する。

【０１７０】ローカルプロセス又は遠隔プロセスのいず
れにおいても、良好なリターンコードによりコマンドパ
ケツトは親ホストサーバに戻される（ローカルプロセス
ではブロツク３６８、遠隔プロセスではブロツク３８
６）。ブロツク３８８において、遠隔ハンドルを指示す
るようにクライアント情報を更新し、親ホスト上のクラ
イアント情報に有効とマークする。

【０１７１】この時点で親プロセスは分岐したプロセス
の状態についての知識はもつていない。プロセスが遠隔
システム上に登録するまで、すべての状態情報はサーバ
に保持される。次に、遠隔プロセスが登録してピクチヤ
を完成するときに何が起きるかを説明する。

【０１７２】（未定の遠隔プロセスの登録）

【０１７３】遠隔機械上で実行されたプロセスは登録す
る。これが生じたとき、遠隔サーバ上のクライアントレ
コードは実際の登録しているプロセスのｐｉｄを反映す
るよう更新され、クライアントレコードの状態が有効に
なる。次に遠隔サーバは、子が始動した親ホストサーバ
にコマンドパケツトを送る。親ホスト上のサーバは、子
が始動したとのメツセージをエンキユーし、親プロセス
に信号を送る。この信号は信号ハンドラによつて捕捉さ
れ、有効状態の親のために child dataレコードが作成
される。

【０１７４】この時、ローカルの場合又は遠隔の場合の
いずれであつても、 start process コマンドは、始動
した子のハンドルを戻す。このハンドルは常に、そのプ
ロセスのローカルサーバビユーに関連するハンドルにな
る。

【０１７５】ここで図３４を参照する。上の記述は多重
コンピユータ複合体の複数のプロセツサにプロセツサ間
通信サポートを提供する。

【０１７６】（デイレクトリ構造）

【０１７７】この試験環境はすべてを包含している幾分
か複雑なデイレクトリ構造の指定を含む。このデイレク
トリ構造はすべてのユーザタスクコード、シナリオツー
ル（足場作りツールを含む）及びシナリオ実行ステージ
の間にデータを累算する構造を含む。

【０１７８】（トツプレベルデイレクトリ構造）

【０１７９】図３を参照してデイレクトリ構造の好適な
実施例について説明する。当業者は、ここに説明するも
のと同様の階層的構造を、違う構造を用いて実施するこ
とができることを理解する。

【０１８０】デフオルトによつて、試験用足場のための
親レベルデイレクトリ構造は /austin８０である。 /au
stinデイレクトリに５つのデイレクトリ構造が配置され
る。これらの構造の名は、 /austin/.def ８２、 /aust
in/.inst８４、 /austin/tools８６、 /austin/tasks８
８及び /austin/runtime９０である。以下に述べるよう
に、デフオルトロケーシヨン及び又はこれらのデイレク
トリのうちのどれかの名前を変更することができる。次
に、これら５つのデイレクトリ構造をどのように使用す
るかについて説明する。

【０１８１】（１）.defデイレクトリ

【０１８２】この定義デイレクトリ８２はシナリオ定義
フアイルを格納する。定義デイレクトリに関するデフオ
ルトロケーシヨンは /austin/.def である。

【０１８３】（２）.inst デイレクトリ

【０１８４】このインスタンスデイレクトリ８４はシナ
リオを記述するフアイルであるシナリオインスタンスフ
アイルを格納する。インスタンスデイレクトリに関する
デフオルトロケーシヨンは /austin/.instである。

【０１８５】（３）tools デイレクトリ

【０１８６】このツールデイレクトリ８６はすべての標
準化された足場ツールとシナリオ実行に必要な他の何ら
かのツールとのリポジトリである。この構造は /austin
/toolsという名前で表される。図４に示すように、この
/austin/toolsデイレクトリ８６には次のような５つの
デイレクトリが存在する。これらは、ソースコードのた
めの src９２と、エクスキユータブルズ（executables
）及びシエルスクリプトのための*bin９４と、データ
フアイルのための dat９８と、文書のための doc１００
と、ライブラリのための*lib９６とである。 /austin/t
oolsデイレクトリは導入時に設置され、めつたに変化し
ない。タスクコードに必要な一切のツールを標準化し、
このデイレクトリ構造に配置することができる。

【０１８７】*bin及び*libの表示を使用して複数のbin
デイレクトリ及び複数のlib デイレクトリを表現する。
「＊」の代わりに一組の文字を用いて、デイレクトリに
どのような形式のエクスキユータブルズ又はライブラリ
が有るかを表示する。例えば現在、tools デイレクトリ
構造はrsbin 及びrslib と名付けられた２つのデイレク
トリを有し、ここに、ＲＩＳＣシステム／6000（ＩＢＭ
社のＲＩＳＣベースのコンピユータシステム）エクスキ
ユータブルズ及びライブラリが配置されている。試験用
足場がSUN SparcStation上でコンパイルされるとき、SU
N エクスキユータブルズ及びライブラリ用に他の２つの
デイレクトリすなわちsunbin及びsunlibを使用すること
ができる。

【０１８８】複数のバイナリ及びライブラリデイレクト
リを有することの利点は、ネツトワーク内の単一のホス
トからエクスキユータブルズ及びライブラリを扱うこと
ができ、また情報を備えているクライアントがこれらの
ローカル環境変数又はＰＡＴＨ環境変数を設定すること
ができるので、これらがクライアントのオペレーテイン
グシステム及びハードウエアプラツトフオームに基づい
て適切なデイレクトリにアクセスすることができること
である。

【０１８９】（４）tasks デイレクトリ構造

【０１９０】タスクデイレクトリ８８は図５に示すよう
に、すべてのシナリオ開発者のユーザコード（タスク）
用のリポジトリである。好適な実施例においては、 /au
stin/tasksデイレクトリに26個のデイレクトリ１０２を
見つけることができる。これらのデイレクトリ１０２に
は「ａ」から「ｚ」までの名前が付されており、タスク
のそれぞれの名前の最初の文字によつてタスクを区分す
る。タスクは、タスクの名前の第１の文字と同一の文字
デイレクトリ１０２の下にあるタスクデイレクトリ構造
にそれ自身の個別のデイレクトリ１０４を持たなければ
ならない。ここで、mtask1、mtask2及びmtask3と名付け
た個別のデイレクトリ１０４を有するタスクｍを示す。
タスクが作成するデイレクトリはその名前と同一でなけ
ればならない。タスクを組立てるフアイル１０６はタス
ク名デイレクトリ内の以下に示すような４つのデイレク
トリに区分される。すなわちこれらのデイレクトリは、
ソースコードに関する src１０４と、実行可能なモジユ
ール及びシエルスクリプトに関する*bin１０８と、デー
タフアイルに関する dat１１０と、文書に関する doc１
１２とである。

【０１９１】タスクデイレクトリ構造全体がタスク開発
ステージを通じて頻繁に変化する。しかしながらタスク
シナリオドライバは、シナリオ実行ステージの間、全く
異なるデイレクトリ構造に書き込むことを許すインタフ
エースを提供するので、タスクデイレクトリ構造に書き
込むことは全く必要ない。このことは、シナリオ実行ス
テージの間に生じがちなタスク構造の破壊の回避に役に
立つ。シナリオ実行ステージの間にタスクデイレクトリ
に待機が生じないことを一段と確実にするため、その許
可を変更することによつてデイレクトリ構造を読出し専
用にすることができる。すなわち、シナリオが分散環境
で実行されている場合、タスクデイレクトリ構造を環境
サーバからの読出し専用にしてよい。注意すべきは、シ
ナリオドライバはシナリオ実行ステージの間、このタス
クデイレクトリ構造が読出し専用であることを明示的に
保証するものではないということである。以下にその例
を示す。

【０１９２】図６に示すようにデイレクトリ /austin/t
asks/r１２２にはrcp の名をもつタスク１２０を見い出
すことができ、デイレクトリ /austin/tasks/f１２６に
は floatの名をもつタスク１２２及び ftp１２４を見い
出すことができる。タスク構造１０４のすべてのタスク
は適切な文字デイレクトリ１０２の下にあるデイレクト
リ名となる。例えば、 rcpの名をもつタスクに対しては
/austin/tasks/r/rcpと名付けられたデイレクトリ１２
０があり、これは、 rcpタスクに関するすべての情報１
０６を格納している。このデイレクトリをＡＵＳＣＯＤ
ＥＤＩＲデイレクトリ（後に説明する）と呼ぶ。

【０１９３】（５） runtimeデイレクトリ構造

【０１９４】図７に示す実行時デイレクトリ構造９０は
シナリオ実行ステージの間に広範囲に使用される。トツ
プレベルのシナリオドライバが実行を開始するとき、 /
austin/runtimeデイレクトリ９０にデイレクトリ１３０
を作成する。デイレクトリ１３０はシナリオインスタン
スの名前１３２と、それに続く日付１３４と時間１３６
とから構成される。このデイレクトリ１３０をシナリオ
デイレクトリと呼び、その全ツリーをシナリオデイレク
トリ構造と呼ぶ。時刻表示をしたシナリオデイレクトリ
は、（システム資源に制約がなければ）ｎ個のシナリオ
実行からシナリオデータを擁護することを保証する。

【０１９５】シナリオデイレクトリ１３０には、pass１
４０、 working１４２及びfail１４４の名前をもつ３つ
のデイレクトリ１３８とscen.journal.<hostname> （す
なわちシナリオ内の機械あたりの１つのジヤーナルフア
イル）の名前をもつフアイル１４６とが存在する。 wor
kingデイレクトリ１４２はすべての実行時タスクアクテ
イビテイが生ずるところである。タスクの完了に続い
て、タスクに関連するフアイルが workingデイレクトリ
１４２からpassデイレクトリ１４０又はfailデイレクト
リ１４４のいずれかに移る。そのどちらに移るかは、以
下に説明するように、構成保管属性及びこれらの成功率
に左右される。フアイルscen.journal.<hostname> １４
６はシナリオジヤーナル情報が記録される場所である。
このデイレクトリ構造１３８は後述するように、シナリ
オ実行時にトツプレベルシナリオドライバによつて作成
される。

【０１９６】（runtime taskデイレクトリ構造）

【０１９７】図８に示すように、タスクが根ユーザとし
て走つている場合には、タスクシナリオドライバが実行
する時に、タスクシナリオドライバはシナリオデイレク
トリの workingデイレクトリ１４２に固有のデイレクト
リ１５０を作成する。図９に示すように、タスクが根ユ
ーザではないユーザとして走つている場合、ユーザのホ
ームデイレクトリ１５４（環境変数ＨＯＭＥによつて示
す）に固有のタスクデイレクトリ構造１５２が作成され
る。このデイレクトリ１５０又は１５２をタスクデイレ
クトリと呼び、そのそれぞれのデイレクトリツリー１５
６又は１５８を実行時タスクデイレクトリ構造（上述の
タスクデイレクトリ構造と混同してはならない）と呼
ぶ。タスクインスタンスの名前１５８と、タスクがその
上で実行しているホストの名前１６０と、タスクのプロ
セス識別番号（ＰＩＤ）１６２と、タスクの反復１６４
とを組み合わせることによつて固有のタスクデイレクト
リ名が作成される。

【０１９８】このタスクデイレクトリの固有性によつ
て、同じホスト上で同じタスクを同時に実行することが
できるか又は同じシナリオデイレクトリフアイルスペー
スを同時に使用することができる。固有のタスクデイレ
クトリ構造がpassデイレクトリ又はfailデイレクトリに
移されると、反復実行が固有性を提供する。分散形実行
時フアイルスペース内でシナリオが実行しており、かつ
タスクデイレクトリ構造の名前を作成する際に使用され
るフイールドのうちの１つが使用されていなかつた場
合、タスクを互いに「進めさせる」ことができる。この
固有の workingデイレクトリフアイルスペースは本発明
の試験用足場の強力な特徴のうちの１つである。

【０１９９】固有のタスクデイレクトリの下に、３つの
デイレクトリをもつデイレクトリ１５６がある。すなわ
ち、 binデイレクトリ１６６、workデイレクトリ１６８
及びjourデイレクトリ１７０である。 binデイレクトリ
１６６は、後に説明するようにコンパイルされたエクス
キユータブルズを出力するタスク準備コードが使用する
ために作成される。workデイレクトリ１６８は、ユーザ
のコードが実行を開始するときにユーザが配置される場
所である。ユーザは、是認されている場合以外は、work
デイレクトリから出ているデイレクトリを変更してはな
らない。jourデイレクトリ１７０は、標準タスクジヤー
ナル（task.journal）１７２が配置される場所（図１の
７２）であるばかりでなく、後述するようにタスクシナ
リオドライバが ausjournals構成属性を用いてすべての
ジヤーナルを作成する場所である。

【０２００】この実行時タスクデイレクトリ構造全体は
タスクシナリオドライバによつて作成される。タスクシ
ナリオの実行が完了すると、そのタスクのための固有の
デイレクトリ構造は、タスクの成功及びシナリオドライ
バ保管属性の値次第で、シナリオデイレクトリのpass又
はfailデイレクトリに移される。次にこれはシナリオド
ライバ圧縮属性の値次第で圧縮される。属性が何であろ
うとも、タスクデイレクトリ構造は常にシナリオの wor
kingデイレクトリ（根ユーザの場合）又は＄ＨＯＭＥデ
イレクトリ（根ユーザではない場合）から除去される。
またpass又はfailデイレクトリへの情報の移動もタスク
シナリオドライバによつて実行される機能である。

【０２０１】（複数の runtimeシナリオデイレクトリ構
造）

【０２０２】図１０において、２つの異なるシナリオ１
８０及び１８２は実行したか又は実行している。これら
のシナリオはエンジニアリング環境シナリオに関する同
じシナリオ定義フアイルから発信されるが、シナリオイ
ンスタンスフアイルは異なる。上述したようにこのこと
は、デイレクトリ名の最初のフイールドが同じであり同
一のシナリオ定義を示しているが、第３のフイールドは
違つていて異なるインスタンスを示している（engineer
ing.e.1 対engineering.e.2 ）ことから明らかである。
デイレクトリ名から、シナリオengineering.e.1 は1991
年３月11日の午前11時５分に開始し（日付・時刻表示が
910311．110500である）、第２のシナリオは1991年３月
12日の午前11時５分に開始した（日付・時刻表示が9103
12．110500である）ということも判る。従つて、これら
のシナリオは正確に２４時間離れて実行を開始したもの
である。

【０２０３】これら２つのデイレクトリ構造１８０及び
１８２を使用している２つのシナリオが共に終了すると
き、これらの構造は実行時フアイルスペース９０に残
る。シナリオドライバはタスクシナリオクリーンアツプ
（後述する）にオプシヨンを提供するが、シナリオドラ
イバ構造を自動的に取り去ることはしない。

【０２０４】次に図１０の環境シナリオ１８０（engine
ering.e.1 910311.110500 ）で実行しているタスクデイ
レクトリ構造に見い出される幾つかのタスクの実行につ
いて説明する。

【０２０５】（シナリオデイレクトリworking デイレク
トリ構造）

【０２０６】図１１を見ると、 engineering環境シナリ
オ１３０で３つのタスク１８４、１８６及び１８８が実
行していることが判る。上述したしように実行中のタス
クは、タスクが根ユーザとして実行する場合常にシナリ
オデイレクトリ内の workingと名付けられたデイレクト
リの下に配置され、そうでなければ、ユーザの＄ＨＯＭ
Ｅデイレクトリにデイレクトリをもつことになる。これ
については後述する。

【０２０７】図１１の engineeringシナリオは、固有の
タスクデイレクトリ名に異なるホスト名を含んでいるだ
けではなく実行時デイレクトリに複数のシナリオジヤー
ナルフアイルを含んでいるので、分散形実行時フアイル
スペースを用いて実行していることが判る。シナリオが
分散されていなかつた場合、タスクデイレクトリは同じ
ホスト名を含む。図示した例において、２つのタスクす
なわちタスク１８４及びタスク１８６はホストclaussen
上で実行しており、１つのタスクすなわちタスク１８８
はホストthelake 上で実行している。

【０２０８】（標本実行時 pass/failデイレクトリ構
造）

【０２０９】上述した固有のタスクデイレクトリの実行
後ロケーシヨンを図１２に示す。図１２から幾つかの項
目を推論することができる。第１に、前に実行していた
２つのタスク（符号１８４のrcp.t.1.claussen.999.1及
び符号１８６のrcp.t.2.claussen.888.1）が渡され、１
つ（fp.t.2.thelake.1122.1 ）は失敗した。第２に、シ
ナリオドライバ属性aussave はタスク rcp.t.1（１８
４）及びタスク rcp.t.2（１８６）に対しては値 all又
はpassを有し、タスク ftp.t.1（１８８）に対しては値
all又はfailを有した。図１２から判る第３の事柄は、
シナリオドライバ属性auscompress オプシヨンがタスク
rcp.t.1（１８４）に関してはpass又はall にセツトさ
れ、タスク rcp.t.2（１８６）に関してはnone又はfail
にセツトされ、 ftp.t.1（１８８）に関してはnone又は
passにセツトされたことである。シナリオドライバ属性
の保管及び圧縮に関するこれ以上の情報は下記を参照さ
れたい。

【０２１０】デイレクトリ構造環境変数について説明す
る。

【０２１１】再度図３を参照する。親デイレクトリ構造
/austin８０及びその下にある各５つのデイレクトリ構
造をすべて、異なるロケーシヨンに移動させること及び
又は必要が有れば名前を付けなおすことができる。これ
らの移動及び又は再度の命名をさせると、６つの環境変
数を準備してデイレクトリ構造の新しいロケーシヨンに
セツトする必要がある。環境変数は次の通りである。

【０２１２】（１）「ＡＵＳＲＯＯＴ」。値は /austin
デイレクトリ８０の新しいロケーシヨンである。

【０２１３】（２）「ＡＵＳＤＥＦ」。値は /austin
/.defデイレクトリ８２の新しいロケーシヨンである。

【０２１４】（３）「ＡＵＳＩＮＳＴ」。値は /austin
/.instデイレクトリ８４の新しいロケーシヨンである。

【０２１５】（４）「ＡＵＳＴＯＯＬＳ」。値は /aust
in/toolsデイレクトリ８６の新しいロケーシヨンであ
る。

【０２１６】（５）「ＡＵＳＴＡＳＫＳ」。値は /aust
in/tasksデイレクトリ８８の新しいロケーシヨンであ
る。

【０２１７】（６）「ＡＵＳＲＵＮＴＩＭＥ」。値は /
austin/runtimeデイレクトリ９０の新しいロケーシヨン
である。

【０２１８】デフオルトロケーシヨンを使用すると、環
境変数をセツトする必要はない。

【０２１９】シナリオドライバ及びシナリオ構築ツール
を使用することにより /austinデイレクトリの下の５つ
のデイレクトリ構造のロケーシヨンを決定する手続きは
次の通りである。

【０２２０】（１）検査をして、その構造のための環境
変数が定義されているか否かを知る。定義されていれ
ば、それはデイレクトリ構造の値である。定義されてい
なければ（２）に進む。（２）検査をして、環境変数Ａ
ＵＳＲＯＯＴが定義されているか否かを知る。定義され
ていれば、ＡＵＳＲＯＯＴ環境変数によつて指定される
デイレクトリの末尾に適切なデフオルトデイレクトリ名
を追加するが、これはデイレクトリ構造の値である。Ａ
ＵＳＲＯＯＴが定義されていなければ（３）に進む。
（３）探索されているデイレクトリ構造の値はデフオル
トである。

【０２２１】上述のことは、次のようなことを意味して
いる。シナリオ構築ツールがインスタンスを探索してい
るとき、最初に、ＡＵＳＩＮＳＴ環境変数が定義されて
いるか否かを知るための検査をする。ＡＵＳＩＮＳＴが
定義されていればシナリオ構築ツールはインスタンスフ
アイルが＄ＡＵＳＩＮＳＴデイレクトリに配置されるこ
とを期待する。ＡＵＳＩＮＳＴが定義されていないと
き、シナリオ構築ツールはＡＵＳＲＯＯＴ環境変数が定
義されているか否かを知るための検査をする。定義され
ているならば、＄ＡＵＳＲＯＯＴ/.instデイレクトリに
インスタンスを探索する。ＡＵＳＲＯＯＴ環境変数が定
義されていなければ /austin/.instデイレクトリにイン
スタンスを探索する。

【０２２２】（シナリオ定義フアイル及びシナリオイン
スタンスフアイル）

【０２２３】（定義フアイル及びインスタンスフアイル
の対話）

【０２２４】図１５はシナリオ定義フアイル５６及びシ
ナリオインスタンスフアイル５４と試験用足場内の他の
要素との対話を示す。定義フアイル及びインスタンスフ
アイルはシナリオ構築ツール５２を用いて作成され変更
され削除される。これらのインスタンスフアイルはシナ
リオドライバ５８への構成入力として使用される。

【０２２５】シナリオ開発ステージの間に定義を作成す
る必要がある。これらの定義をテンプレートとして用い
てシナリオインスタンスを作成する。またシナリオイン
スタンスフアイルを作成するステツプもシナリオ開発ス
テージの間に必要なステツプである。シナリオインスタ
ンスフアイルが無ければシナリオドライバは実行に失敗
するであろうし、シナリオ定義が無ければ（シナリオ構
築ツールを迂回しない限り）シナリオインスタンスを作
成することはできない。

【０２２６】定義からインスタンスが例示されたなら
ば、これらをシナリオドライバ用の構成情報として使用
する。各シナリオドライバが実行されると、そのシナリ
オドライバの動作を定義する１つのインスタンスを渡さ
れる。

【０２２７】各定義及びインスタンスは（定義用の） /
austin/.def デイレクトリ又は（インスタンス用の） /
austin/.instデイレクトリ内の別個のフアイルである。
フアイルの名前は定義又はインスタンスの名前である。
フアイル内に、/etc/filesystems内のスタンザと性質の
似ているスタンザを見出すことができる（注意すべき
は、これは、ＵＮＩＸコンパチブルオペレーテイングシ
ステムによつて一般に知られ使用されている標準スタン
ザである）。スタンザの名前はフアイル名、すなわちイ
ンスタンス／定義名と同じである。次にスタンザは幾つ
かの属性名／値ペアをラインあたり１つ格納する。

【０２２８】ausで始まる属性はシナリオドライバ属性
又はシナリオドライバ構成属性と呼ばれる。 ausという
接頭部はシナリオドライバ属性に割り付けられたもので
ある。定義フアイル又はインスタンスフアイルに見い出
されるこれ以外の属性はいずれもユーザ定義属性と呼ば
れる。ユーザ定義属性及びシナリオドライバ属性の双方
の目的については詳しく後述する。

【０２２９】上記の最初の段落において述べたように定
義フアイルはインスタンスフアイルとは僅かに異なる。
定義フアイル内のユーザ定義属性についての値は実際に
は、その定義の例示インスタンスフアイルに見い出され
る値ではない。定義フアイル内のユーザ定義属性の各値
がその代わりに表現するものは、ユーザ定義属性の型を
記述する構文法と、その制限と、そのデフオルト値と、
ユーザ定義属性を何のために使用するかについての短い
記述とである。この情報はすべて、例示化時にその変数
が実際の値を与えられるとき、シナリオ構築ツールが使
用する。シナリオ構築ツールは、例示化する時にタスク
開発者によつて入れられるユーザ定義属性の実際の値
が、そのユーザ定義属性の定義が定義されたときに設定
された基準に合致することを確実にする。

【０２３０】（フアイル名構文法）

【０２３１】与えられた任意の名前（文字で始まり、ゼ
ロ又は１つ以上の英数字、下線又はピリオドが続かなけ
ればならない）からなる定義フアイルには、ピリオド及
び拡張子「ｅ」、「ｍ」、「ｐ」又は「ｔ」が続く。定
義フアイル上に配置される拡張子は、その定義が定義す
るものの如何により、環境シナリオならば「ｅ」、機械
シナリオならば「ｍ」、個人シナリオならば「ｐ」、タ
スクシナリオならば「ｔ」である。

【０２３２】上述の定義フアイル名からなるインスタン
スフアイルには、ピリオド及び現在の定義に関する固有
の整数値である拡張子が続く。例えば、 foo.eと名付け
られた定義が２回例示化されたとき、インスタンス fo
o.e.1及びインスタンスfoo.e.2 が存在する。３回例示
化されたとき、 foo.e.3の名前をもつ新しいインスタン
スが作成される。

【０２３３】

【表３】

【０２３４】

【表４】

【０２３５】次表（５）は一般的なスタンザ構文法を用
いてのタスク定義フアイルの例である。

【０２３６】

【表５】

【０２３７】この定義フアイルの例から判るように、タ
スクは割り付けられた３つの定義済み属性と、３つのユ
ーザ定義属性（SERVER、CLIENTS 及びFILESIZE）とを有
する。文字列型であることを要求されるユーザ定義属性
SERVERは制限及びデフオルト値を有してない。また文字
列型であることを要求されるユーザ定義属性 CLIENTSも
制限及びデフオルト値を有していない。オプシヨンであ
り整数型である第３のユーザ定義属性FILESIZEは「 51
2」、「1024」、「2048」又は「4096」に制限され、デ
フオルト値として「 512」を有する。これら３つの属性
についての記述も幾らかの情報をもたらす。

【０２３８】この定義フアイルの名前はsample.t. であ
る。デフオルトによつて、これは /austin/.def に配置
され、シナリオ構築ツールによつて操作され得る。通
常、この定義の作成及び操作はシナリオ構築ツールを通
じて完全になされる。

【０２３９】上述したタスク定義フアイルの例を次表
（６）に示す。

【０２４０】

【表６】

【０２４１】すべての割り付けられた属性の正確な意味
とこのインタンスフアイルをドライバが使用する方法と
について以下に詳述する。この例によつて示すようにシ
ナリオ開発者は例示化ステージの間にSERVERとしてホス
ト「arsenio 」を指定し、CLIENTとしてホスト「carso
n」、ホスト「leno」及びホスト「oprah 」を指定し、F
ILESIZEは「 512」である。シナリオ開発者はFILESIZE
変数を変更する必要はなかつた。これはデフオルトによ
つて値「 512」を伴つて作成された。

【０２４２】（シナリオ構築ツール）

【０２４３】シナリオ構築ツールはシナリオ定義フアイ
ル及びシナリオインスタンスフアイルを管理するため
の、自然言語のタスク指向インタフエースを提供する。
シナリオ構築ツールは階層構造を使用する。この階層構
造はメニユーパネルと対話パネルとからなる。メニユー
は実行すべきタスクを連続的に詳しく述べる。対話パネ
ルは定義属性及びインスタンス属性のためにデータを入
れる。インスタンス及び定義の双方の上で遂行できる基
本的機能は付加すること、変更すること、取り去ること
及びリストに列挙することである。

【０２４４】シナリオ構築ツールはデータ処理システム
の指示メツセージにコマンド名（例えばaussbt）を入れ
る従来の手法で呼び出される。呼び出されると、図１６
に示すようにシナリオ構築ツールのトツプライン２００
に現在のメニユーパネル又は対話パネルのタイトルが表
示される。メニユーパネル又は対話パネルの下部２０２
には現在のメニユー又は対話のための使用可能な機能キ
ーが表示される。メニユーパネルの２０４にはタスク指
向項目のリストが表示される。図１７は図１６において
タスク項目を選択した後の、結果としてのメニユーパネ
ルを示す。対話パネルにおいては、図１８に示すような
属性名が左側に表示され、エントリフイールドは右側に
表示される。

【０２４５】対話パネルには属性の値を入れることがで
きる。シンボルを使用して種々の形式のフイールドを表
示する。シンボルは対話パネル内の種々の場所に表示す
ることができる。

【０２４６】

【表７】

【０２４７】以下に例を述べる。図１６はシナリオ構築
ツールの最初のメニユーパネルがどのように見えるかを
例示している。画面底部の機能キー２０２はパネルから
パネルに変化する。しかしながら、このメインメニユー
上の５つの機能キーの定義は好適な実施例におけるパネ
ル全体を通じて首尾一貫している。パネルごとの文脈感
知支援はＦ１キー２１３でいつでも使用できる。Ｆ２キ
ー２１５は画面をリフレツシユするために使用される。
Ｆ３キー２１７及びＥＳＣキー（図示せず）はいつでも
前のパネルに戻す。Ｆ９キー２１９は一時的にシエルに
出（「exit」をタイプすることによつて戻る）、Ｆ１０
キー２２１はどのパネルにおいてもシナリオ構築ツール
を抜ける。

【０２４８】図１７は他のメニユーパネルである。この
特定のメニユーパネルにアクセスするには、最初のメニ
ユーからタスクを選択し、第２のメニユーからインスタ
ンス管理を選択する。このメニユーパネルから、下線を
付した文字を各メニユー項目が含んでいることが認めら
れる。この文字をキーボード上で選択すれば、自動的に
その項目が選択される。

【０２４９】図１８は対話パネルのサンプルである。こ
の特定の対話パネルは上述のタスクインスタンスフアイ
ルに関するシナリオ構築ツールによつて表示されるもの
である。sample.tと呼ばれるタスク定義の新しいインス
タンスにシナリオ開発者がaussbtとタイプして構築ツー
ルに入り、次にタスク（Task）、インスタンス管理（Ma
nage Instace）、インスタンスの加算（Add an Instanc
e ）及びサンプルｔ定義を選択する。次にサンプルｔ１
インスタンスと図１８の対話パネルが表示される。タス
クインスタンス管理ステージの間、属性austype ２０６
及び属性austaskcode ２０８はすべて読出し専用であ
る。このことは、ずつと左方の列に「＠」の記号２１２
で表す。読出し専用とした理由は、これらがシナリオを
定義する属性であり、これらを変更することは異なるシ
ナリオ定義を作成することを意味し、そうする代わりに
タスク／定義／作成オプシヨンを選択することができる
からである。このパネルは予め定義したシナリオ（すな
わち、存在するシナリオ定義フアイルを既にもつている
シナリオ）の例示のためだけに示すものである。属性au
scompress ２１４、属性aussave ２１６及び属性ausver
bose２２４はトグルリングを有し、このことをずつと右
方の列に「＊」の記号２１８で表示する。これは、利用
者がタブキーを用いて異なる値を選択することができる
か又はＦ４キーを使用して可能な値のリストを入手でき
ることを意味する。シナリオドライバ属性ausloops２２
０、austime ２２２及びausverbose２２４はすべて数値
を要求する。このことを、ずつと右方の列に「＃」の記
号２２６によつて表示する。１つのユーザ定義属性ＦＩ
ＬＥＮＡＭＥ２２８があるが、好適な実施例においては
これが必要である。これを、ずつと左方の列に「＊」の
記号で表示する。また注意すべきは、ＦＩＬＥＮＡＭＥ
２２８もずつと右方の列にトグルリング（「＊」）２１
８を有し、これにより、ユーザがタブキーを用いて異な
る値を選択するか又はＦ４キーを使用して可能な値のリ
ストを入手できることを表示する。

【０２５０】この例示化のための情報が完了すると、エ
ンター（ Enter）キーを押して実際にインスタンスフア
イルを作成し、タスクシナリオドライバを制御する際に
使用することができる。

【０２５１】（シナリオドライバ）

【０２５２】図１９を参照する。シナリオドライバ５８
は試験用足場の主要な構成要素である。シナリオドライ
バはアーキテクチヤの概観において既に述べた４つの異
なるシナリオレベルの実行を制御することができる。

【０２５３】シナリオドライバは単独で実行可能であ
り、その動作はシナリオインスタンスフアイル５４によ
つて決定される。インスタンスフアイルはシナリオドラ
イバに識別のセンスを与える。例えば、１つのインスタ
ンスはオペレーテイングシステム全体を試験するタスク
を実行する、50ものホストをネツトワーク化した環境シ
ナリオの実行をこのシナリオドライバに制御させること
ができ、他のインスタンスはオペレーテイングシステム
の特定の一片を機能的に検証するただ10行のシエルスク
リプトの実行をこのシナリオドライバに制御させること
ができる。

【０２５４】シナリオドライバの利点は多種多様であ
る。まず第１にこれは、多数のホストに亘つて環境シナ
リオ全体を自動化する足場作りシステムを設定する。こ
の足場作りシステムは複数のホストからなる構成におい
て日常のタスクを実行している人々をシミユレートす
る。

【０２５５】第２に、シナリオドライバは、同じタスク
が同じホスト上又は同じネツトワーク内のユーザとして
同時に実行されているシステム試験類似環境で生ずる問
題を処理する。シナリオドライバは最善を尽くして環境
を設定し、そこではこれらのタスクが互いに干渉するこ
とはない。シナリオドライバの第３の利点は、前にタス
クに見い出された多くのコードが今やこのシナリオドラ
イバに移送されることである。例えば、各タスクが反復
目的のコードを必要とする代わりに、このコードがシナ
リオドライバに移され、そのインタフエースが標準化さ
れている。作業用デイレクトリの作成と実行時領域のク
リーンアツプとはもはやユーザタスクコードがアドレス
しなければならない問題ではない。これは、シナリオド
ライバレベルにおいて完全かつ首尾一貫して制御され、
シナリオの必要性に従つて変化する。

【０２５６】またシナリオドライバは一組の標準化した
ジヤーナル６２を提供する。ジヤーナルは標準的なフオ
ーマツトを有するので、標準的な報告書フイルタを通し
てこれらを走らせて実行結果を検査することができる。

【０２５７】試験シナリオドライバの実行は現在の試験
用環境において必要な制御に従い、タスクレベルを通じ
て環境レベルからいずれかのレベルにおいて開始するこ
とができる。好適な実施例においては試験シナリオドラ
イバは依存性を有し、そのロケーシヨンはＰＡＴＨ環境
変数内に提供される。シナリオドライバは、デフオルト
によつて /austin/tools/rsbinデイレクトリに配置され
る。このデイレクトリを以下のコマンドを用いてＰＡＴ
Ｈ環境変数に付加することができる。

【０２５８】 PATH=/austin/tools/rsbin:$PATH ;export PATH

【０２５９】シナリオドライバは２つの使用文を準備す
る。第１の使用文はコマンドライン上にエラーが検出さ
れたときに生ずる。この使用からの情報は標準エラー
（stderr）にプリントされる。第２の使用文は支援使用
文であり、これは「ｈ」フラグがシナリオドライバに渡
されるときに生ずる。この支援使用からの情報は標準出
力（stdout）にプリントされる。有効なタスクシナリオ
インスタンス名を伴う「ｈ」フラグが指定されると、後
述するように、そのインスタンスのための支援が標準出
力（stdout）に表示される。エラー使用文を次表（８）
に示す。

【０２６０】

【表８】

【０２６１】ドライバ支援の場合、ユーザはausdriver
-hに入る。タスク支援の場合、ユーザはausdriver -h <
task instance> に入る。 <task instance> を伴わ
ないシナリオドライバに「ｈ」フラグが渡されるときに
提供される情報を次表（９）に示す。

【０２６２】

【表９】

【０２６３】次に、構成に使用し得るシナリオドライバ
オプシヨンのセツトについて定義する。構成オプシヨン
はシナリオドライバ５８に、それが制御している試験シ
ナリオレベルと、それが実行すべきものと、いかにして
実行を遂行すべきかとを伝達する。各シナリオドライバ
と関連しているシナリオインスタンスフアイル５４内で
すべての構成オプシヨンを指定することによつて、これ
らをシナリオドライバに伝達することができる。またこ
れらの構成オプシヨンの幾つかはコマンドラインからシ
ナリオドライバを直接呼ぶときにコマンドラインフラグ
によつて指定することができる。しかしながら多くの場
合、タスクドライバが独立して実行しているか又は実行
しているシナリオドライバがシナリオ内のトツプレベル
のシナリオドライバでない限り、シナリオドライバは一
段と高いレベルのシナリオドライバによつて呼び出さ
れ、これらの構成情報の大部分をこれらの関連インスタ
ンスから受け取る。しかしながら、一段と高レベルのシ
ナリオドライバに渡されたコマンドラインフラグが適切
である場合、このシナリオドライバはコマンドラインフ
ラグを、これを実行するシナリオドライバに自動的に渡
す。コマンドラインフラグ構成属性は矛盾がある場合に
はインスタンスフアイル構成属性のいずれかを無効にす
る。同じフラグが複数回コマンドライン上に指定される
か又は同じ属性が複数回インスタンス内に指定される
と、警告メツセージを出して最後のフラグ又は属性を使
用する。

【０２６４】属性に関連付けた英語の句によつて下位の
各属性が最初に記述される。括弧内の構成属性名と同じ
ライン上に、対応するシナリオインスタンスフアイル属
性名と、存在するならばコマンドラインフラグとを見い
出すことができる。構成属性名に続いて表があり、この
表が示しているのは、どのシナリオドライバレベルにこ
の属性が関わつているか、どのシナリオドライバレベル
がこれを必要としているか及び各レベルにおけるそのデ
フオルト値である。次にインスタンス属性についての構
文法が与えられ、その属性に関連したものがあるならば
コマンドラインフラグの構文法が与えられる。次に属性
の記述があり、多くの場合いかにして属性を使用するか
を示す例がある。このセクシヨン（５）を通じて使用さ
れる構文法を次表（１０）に示す。

【０２６５】

【表１０】

【０２６６】

【表１１】

【０２６７】インスタンス属性構文法は、≪ausbeghook
≫＝“＜『 begin hook』＞”であり、コマンドライン
構文法はない。

【０２６８】（説明）。開始フツクは、シナリオドライ
バが次のレベルのシナリオドライバ又はユーザコードを
実行するに前にユーザコードをシナリオドライバによつ
て自動的に実行する道を提供する。通常、開始フツクを
使用することにより、実行している試験シナリオに独特
の幾つかの形式の自動的セツトアツプを行う。これは試
験シナリオをカストマイズできるようにする。開始フツ
クを実行させるには、上述した構文法ダイアグラム内の
＜『 begin hook』＞で示される２重引用符付き文字列
の情報を評価のためのシステムに渡す。零以外のリター
ンコードを開始フツクから受け取ると、シナリオドライ
バは実行を終了して制御をその親シナリオドライバに戻
す（又はそれがトツプレベルのシナリオドライバの場合
にはＡＩＸシエルに戻す）。

【０２６９】 （例１）ausbeghook =“/austin/tools/rsbin/setup ”

【０２７０】この例では、開始フツク/austin/tools/rs
bin/setup を実行する。プログラムが零以外のリターン
コードを戻すと、シナリオドライバは上述したように実
行を停止する。/austin/tools/rsbin が（ＰＡＴＨ環境
変数を経由して）既にシステム経路にあると、開始フツ
クはausbeghook =“setup ”のように特定され得る。

【０２７１】 （例２）ausbeghook =“check tcpip; check nfs”

【０２７２】この例は幾らか複雑である。この文字列を
システムに送り、１つのプログラムを実行する代わりに
２つのプログラムを順次実行する。この２つのプログラ
ムは実際に同じプログラム（検査）であるけれども、常
に異なるパラメータを渡される。これらのプログラムの
第２のものからのリターンコードは開始フツク実行から
戻される。これら２つのプログラムのいずれかが失敗し
た場合、シナリオドライバが停止することが重要なら
ば、開発者は、これらの各プログラムを呼び出すシエル
スクリプトを作成し、これらのリターンコードを検査
し、そのリターンコードを出ることができる。次に、そ
のシエルスクリプトの名前をausbeghookに置く。

【０２７３】

【表１２】

【０２７４】インスタンスフアイル構文法は、≪auscod
edir≫＝“＜『directory 』＞”であり、コマンドライ
ン構文法はない。

【０２７５】（説明）。ユーザのベースコードデイレク
トリは、タスク開発者のために、デフオルトロケーシヨ
ン内にそれが存在しない場合にタスクコードのロケーシ
ヨンを指示する道を提供する。文字列はベースレベルデ
イレクトリの値を格納し、そこに、現在のタスクに対す
る開発者のタスクデイレクトリ構造が存在する。このシ
ナリオドライバ属性のためのデフオルト値は、タスクシ
ナリオドライバがそのシナリオのタスクデイレクトリ構
造のロケーシヨン及び現在のインスタンスの名前を使用
して実行時に計算される。デイレクトリは次のようにセ
ツトされる。

【０２７６】<scenario ´s task directory stru
cture>/<first letter of the instance>/<instance
base>

【０２７７】ここで<instance base> は´.t.<int>´
拡張子を伴わないインスタンス名である。

【０２７８】（例１）。例えばタスクシナリオドライバ
がインスタンスサンプルタスク.t.1で実行され、かつデ
フオルトＡＵＳＴＩＮデイレクトリ構造が環境変数によ
つて修正されていなかつた場合、このサンプルタスク.
t.1インスタンスのためのデフオルトタスクコードデイ
レクトリ構造は /austin/tasks/s/sampletask である。
このデイレクトリ構造の下にはbin 、dat 、doc 及びsr
c の各デイレクトリがあり、これらは各タスクコードデ
イレクトリ構造を形成する。

【０２７９】（例２）。タスクがタスク開発者ステージ
にあるのでタスク開発者が異なるロケーシヨンに配置さ
れているタスクを有することを望む場合、auscodedir属
性を変更することによつてこれを実行することができ
る。例えば、タスク開発者が、tasksと名付けたホーム
デイレクトリ内のデイレクトリにすべてのタスクを格納
していた場合、sampletaskの名をもつタスクに対するベ
ースコードデイレクトリは/u/username/tasks/ samplet
ask である。このデイレクトリの下にデイレクトリbin
、dat 、doc 及びsrc がある。この変更が生じたこと
をシナリオドライバに知らせるため、属性auscodedirは
次のようにシナリオインスタンスフアイルを覗く。

【０２８０】 auscodedir =“/u/username/tasks/sampletask” Compression (auscompress, -c)

【０２８１】

【表１３】

【０２８２】インスタンスフアイル構文法は、≪auscom
press ≫＝< ≪none≫｜≪pass≫｜≪fail≫｜≪all ≫
> であり、コマンドライン構文法は、≪-c≫ <≪ｎ≫｜
≪ｐ≫｜≪ｆ≫｜≪ａ≫> である。

【０２８３】（説明）。シナリオドライバ圧縮構成属性
は、保管したタスク情報がタスクの実行に従つて圧縮さ
れているか否かを確認する。シナリオドライバ保管オプ
シヨンの値が、ユーザタスクコードの実行後にタスク情
報を保管するというようなものであれば、それが圧縮さ
れるか否かを圧縮オプシヨンが決定する。この圧縮の決
定はユーザのタスクが渡されたか失敗したか及び圧縮属
性の値に基づいて行われる。圧縮は、 auscompressイン
スタンス属性若しくは「ｃ」コマンドラインフラグに基
づいて、圧縮を実行せず（無し(none)又はｎ）にセツト
するか、渡されたタスクだけに圧縮を行う（パス(pass)
又はｐ）にセツトするか、失敗したタスクだけに圧縮を
行う（失敗(fail)又はｆ）にセツトするか又は常に圧縮
を実行する（全部(all) 又はａ）にセツトすることがで
きる。圧縮アルゴリズムは AIX tarコマンドを使用する
ことにより単一の固有フアイルに固有のタスク作業デイ
レクトリ構造の全体を作り、次に、 AIX圧縮コマンドを
使用してそのフアイルを圧縮する。これは、情報を保管
する必要がある環境に対しては有益なオプシヨンである
が、シナリオ実行ステージの間に作り出される情報の量
は、拡張した時間期間走行した後に莫大なものとなる。

【０２８４】圧縮された情報を非圧縮状態にして再圧縮
することのできる２つのユーテイリテイが存在する。

【０２８５】（例１）。数千のタスクが何日もの間そこ
で実行しているシナリオは、その環境全体に対するすべ
てのタスク実行時情報が圧縮されるよう圧縮属性をセツ
トすることを望むことがある。これを行うには各機械イ
ンスタンスフアイル内のすべてに対してauscompress 属
性をセツトする。機械インスタンスフアイル内の情報
は、機械シナリオ内にある各タスクシナリオに自動的に
漏れる。以下の行は、機械シナリオインスタンスフアイ
ル内においてこの効果を有する。

【０２８６】auscompress = all

【０２８７】（例２）。他の状況において、異なるハー
ドデイスク資源を有する複数のホストを有する環境シナ
リオが実行しているものとする。こうした状況では、多
量のデイスクスペースを有するホストは何も圧縮せず
（無し(none)又はｎ）、少量のデイスクスペースを有す
る機械はあらゆるものを圧縮する（全部( all)又はａ）
ように圧縮オプシヨンをセツトすることができる。これ
を達成するため、僅かなデイスク資源を有するホストの
インスタンスフアイルに次の属性を置く。

【０２８８】auscompress = all

【０２８９】また多くのデイスク資源を有する機械のイ
ンスタンスフアイルには次のような属性を置く。

【０２９０】auscompress = none

【０２９１】（例３）。この例においては、極めて稀に
実行している機械シナリオが、渡されたタスク情報を見
るので、機械シナリオインスタンスフアイルに次のよう
な属性を置くことによつて情報を圧縮することができ
る。

【０２９２】auscompress = pass

【０２９３】（例４）。１つの環境内で実行している同
じタスクが異なる圧縮オプシヨンを有することができる
ことに注意することが重要である。これは、タスクが異
なるインスタンスフアイルに関連付けられているからで
ある。例えば、２つの異なる機械上で実行するタスク r
cpは完全に別々の圧縮属性を有することができる。これ
は、２つのタスクインスタンスのうちの第１のものは圧
縮属性をパスにセツトするインスタンスに関連付けられ
ているからであり、これにより、それはタスクが渡され
るときだけにタスクフアイルを圧縮する。次のようなシ
ナリオインスタンス属性でこれを行う。

【０２９４】auscompress = pass

【０２９５】タスクの第２のインスタンスは圧縮アルゴ
リズムを全部（all ）に対してセツトするインスタンス
フアイルに関連付けられているので、全部のタスクフア
イルが成功に関係なく圧縮される。次のようなシナリオ
インスタンス属性でこれを行う。

【０２９６】auscompress = all

【０２９７】

【表１４】

【０２９８】インスタンスフアイル構文法は≪ ausdesc
≫＝“＜『description 』＞”であり、コマンドライン
構文法はない。

【０２９９】（説明）。 ausdesc属性は各定義済シナリ
オを記述している、シナリオインスタンスフアイル作成
時にシナリオ構築ツールに入つた情報がインスタンスフ
アイル内に保存されるようにする。このデータは情報だ
けを目的とする。それはインスタンス間の違いを記述す
る「テキスト」である。

【０３００】（例）。以下は、シナリオインスタンスフ
アイルのサンプルを記述したテキストである。

【０３０１】ausdesc ＝「このインスタンスは圧縮属性
をpassに対してセツトし保管を allに対してセツトす
る」。

【０３０２】以下は、同じシナリオ定義フアイルから出
た異なるシナリオインスタンスフアイルからの他のサン
プルを記述したテキストである。

【０３０３】ausdesc ＝「このインスタンスは圧縮属性
を allに対してセツトし保管を allに対してセツトす
る」。

【０３０４】

【表１５】

【０３０５】インスタンスフアイル構文法は≪ausdistr
ibuted≫＝ <≪ true ≫｜≪ false≫> であり、コマン
ドライン構文法は≪-d≫ <≪ｔ≫｜≪ｆ≫> である。

【０３０６】（説明）。分散実行時フアイルスペース属
性は分散した /austin/ runtime フアイルスペースで環
境シナリオを実行することが意図であるか又は /austin
/ runtime フアイルスペースがネツトワーク内の各機械
に存在するか否かを環境シナリオドライバに通知する。

【０３０７】注意すべきは、分散属性が真であつても偽
であつても、シナリオドライバによつてマウントが実際
に行われることはないことである。この値は単にシナリ
オ実行ステージの間のフアイルスペースの分散に関する
ユーザの意図が何であるかをシナリオドライバに通知す
る。 /austin/runtimeフアイルスペースの実際の分散は
良好な開始フツクのアプリケーシヨンである。

【０３０８】（例１）。以下は、シナリオ実行ステージ
の間に /austin/runtimeフアイルスペースを分散してい
ない環境シナリオインスタンスフアイルからの抜粋であ
る。

【０３０９】ausdistributed = false

【０３１０】（例２）。以下は、シナリオ実行ステージ
の間に /austin/runtimeフアイルスペースを分散してい
る環境シナリオインスタンスフアイルからの抜粋であ
る。

【０３１１】ausdistributed = true

【０３１２】

【表１６】

【０３１３】インスタンスフアイル構文法は≪ausendho
ok≫＝“＜『end hook』＞”であり、コマンドライン
構文法はない。

【０３１４】（説明）。終了フツクは次のレベルのシナ
リオドライバ又はユーザタスクコードを実行した後にシ
ナリオドライバによつてユーザコードを自動的に実行し
得る道を提供する。終了フツクが実行する時間を除い
て、開始フツク及び終了フツクの双方に同じ情報を適用
する。

【０３１５】

【表１７】

【０３１６】インスタンスフアイル構文法は≪ ausjour
nals≫＝“［＜『 env va:journalna』｜『 jourl na
me』＞... ］”であり、コマンドライン構文法はない。

【０３１７】（説明）。この ausjournals属性を用い
て、ジヤーナルコマンドが書き込むデフオルト標準ジヤ
ーナルフアイルとは異なる、ユーザのタスクコードが使
用を望む何らかのジヤーナルを定義する。ユーザのタス
クコードを実行する前に、タスクシナリオドライバは a
usjournals予約属性の値に基づいて環境変数をセツトす
る。これらの環境変数はユーザ定義ジヤーナルの経路を
含む。この経路は固有のタスク実行時デイレクトリ構造
のjourデイレクトリ内にある。このデイレクトリは（ t
askjournalの名を有する）標準タスクジヤーナル及び a
usjournalsコマンドと共に定義される各ユーザ定義ジヤ
ーナルを格納する。これらのフアイルの実際のロケーシ
ヨンはユーザのタスクコードとは関係がない。これは、
ユーザは環境変数を使用してジヤーナルを参照するから
である。

【０３１８】ausjournalsコマンドに関する構文法は一
見したところ幾らか複雑であるが、以下の説明及び実例
がその意味を理解する助けとなる。 ausjournalsコマン
ドの値は１つ又は２つ以上の項目のリストを含んでい
る、２重引用符き文字列である。これらの項目はフオー
マツト『 env var ： journal name』又は単なる『 j
ournal name』を有することができる。シナリオドライ
バはこれらの項目からなるリスト全体を分析し、第１の
形式を見い出した場合、現在のjourデイレクトリの経路
に等しい『 env var 』にフアイル名『 journal nam
e』が続く名前を有する環境変数をセツトする。項目の
第２形式を見い出した場合、シナリオドライバは現在の
jourデイレクトリの経路に等しい『 journal name』の
大文字版に『journal name』と名付けたフアイルが続
く環境変数をセツトする。この場合『env var 』を大
文字にして「正規」ＵＮＩＸ環境変数命名規定に従う。

【０３１９】（例１）。この例においてタスク開発者は
デフオルトジヤーナルフアイル以外の彼／彼女のタスク
のために３つのジヤーナルを使用することを要求する。
ausjournals に彼／彼女が与える値は以下の通りであ
る。

【０３２０】ausjournals ＝“Spooljour:spooljour cm
djour DiffResults:diff- jour”

【０３２１】この値は上述の形式の双方を含む。シナリ
オドライバはこのインスタンス属性を読み、以下の３つ
の環境変数をそこに示す値にセツトする。

【０３２２】Spooljour=“/austin/runtime/<scenariod
ir>/working/<taskdir>/jour/spooljour”

【０３２３】CMDJOUR=“/austin/runtime/<scenariodir
>/working/<taskdir>/jour/cmdjour”

【０３２４】DiffResults=“/austin/runtime/<scenari
odir>/working/<taskdir>/jour/diffjour ”

【０３２５】（例２）。この例では、シナリオ開発者は
elog及びklogと名付けた２つのジヤーナルを必要とす
る。タスクシナリオインスタンスフアイルに次のように
指定する。

【０３２６】ausjournals=“elog klog ”

【０３２７】これにより、以下の環境変数は次のような
値をもつ結果となる。

【０３２８】ELOG＝“austin/runtime/<scenariodir>/w
orking/<taskdir>/jour/elog”

【０３２９】KLOG＝“/austin/runtime/<scenariodir>/
working/<taskdir>/jour/klog ”

【０３３０】これによりユーザはこれらのフアイルに書
込むことができる。以下は、上述のフアイルを使用する
シエルスクリプトからの抜粋である。

【０３３１】ls-alt foofile＞＄ELOG diff ＄ELOG

【０３３２】＄AUSCODEDAT/expected.results ＞＞＄KL
OG if ［“＄？”！＝“０”］；then auserror “The
ls -all foofile command failed. ”eles auslog “Th
e ls-alt foofile command was succesful.”fi

【０３３３】

【表１８】

【０３３４】インスタンスフアイル構文法は≪ ausloop
s ≫＝＜『integer 』＞であり、コマンドライン構文法
は-1<integer> である。

【０３３５】（説明）。属性を実行するためのループは
シナリオ属性ausobjlist内のインスタンスを何回実行す
べきか又はシナリオ属性 austaskcode内のユーザのタス
クコードを何回実行すべきかをシナリオドライバに通知
する。注意すべきは、『 time to execute』属性が存在
することである。同じインスタンスフアイル内又はコマ
ンドライン上に双方が指定されたとき、『 time to exe
cute』属性が優先順位をとる。どちらかがコマンドライ
ン上に指定されるとき、これらは、シナリオインスタン
スフアイルにあるこのいずれかを上回る優先順位をと
る。ausloopsのための整数値は正でなければならない。

【０３３６】（例）。 loops to execute 属性が次のよ
うな値をタスクシナリオインスタンスフアイルに有する
とき、それは個人シナリオドライバによつて実行された
ものである。

【０３３７】ausloops＝20

【０３３８】ユーザタスクコードは個人ドライバへの制
御を復帰させる前に20回実行する。動作の順序として
は、個人ドライバがその開始フツクを実行し、次にタス
クドライバが実行する。タスクドライバはその開始フツ
クを実行し、次にそのユーザタスクコードを20回実行
し、その終了フツクを実行し、次に個人シナリオドライ
バへの制御に復帰する。個人シナリオドライバが「１」
よりも大きいループ値を有しているとき、タスクシナリ
オドライバは再び実行して同一の２回目のプロセスを進
み、その開始フツクを実行し、そのユーザタスクコード
を20回実行し、その終了フツクを実行し、次に個人シナ
リオドライバに実行制御を戻す。

【０３３９】

【表１９】

【０３４０】インスタンスフアイル構文法は≪ ausmode
≫＝< ≪concurrent≫｜≪sequential≫ >であり、、コ
マンドライン構文法は-m < c｜s > である。

【０３４１】（説明）。実行モード属性は一段と低いレ
ベルのシナリオドライバを順次又は同時に実行させるこ
とができる。「同時」が指定されると、シナリオドライ
バはそのausobjlist内のすべてのインスタンスの実行を
同時に開始して、これらすべての終了を待機する。「順
次」が指定されると、シナリオドライバはausobjlist内
のインスタンスを順次実行する。リスト内のすべてのオ
ブジエクトが実行し、かつ終了すると、同時であるか順
次であるかにかかわらずそれはシナリオドライバの１つ
のループを作る。

【０３４２】（例１）。個人シナリオが５つのタスクシ
ナリオからなり、かつ個人シナリオインスタンスフアイ
ルに次の値、すなわち ausmode＝concurrentを有してい
るとき、これは５つのタスクシナリオの実行を同時に開
始する。個人シナリオフアイルに以下の属性、すなわち
ausloops＝２を伴うloop twiceがセツトされると、個人
シナリオフアイルは、５つの各タスクが実行を完了する
のを待つて同じプロセスの２回目を開始する。第２の反
復実行の終了によつて、５つのタスクは各２回づつ実行
したことになる。いつ同時実行が使用されるかに留意す
ることが重要であり、一段と低レベルのすべてのドライ
バは、これらのドライバの前の各実行が完了するまで第
２の反復実行を開始しない。従つてこの例における５つ
のタスクシナリオのうちの４つはたつた10分で完了し、
５番目のものが30分かかるならば、個人シナリオの２回
の反復実行には正味１時間かかる。実行開始後、最初の
４つは10分後に終了するが５番目のタスクは実行を継続
しており、これら５つのタスクが揃つて２回目を実行す
るまでにはまだ20分もかかる。

【０３４３】（例２）。４つのタスクを実行するのに10
分かかり１つのタスクを実行するのに30分かかるような
５つのタスクを有する個人シナリオの上述の例を用い
て、この例は個人シナリオが順次モードで２つのループ
を実行するのに必要な時間の長さを示す。ドライバに順
次モードで実行させるには個人シナリオインスタンスフ
アイルに以下の属性を使用する。

【０３４４】ausmode = sequential

【０３４５】これら５つのタスクを背中合わせに実行す
れば、個人シナリオの各反復実行はほぼ70分を要する。
従つて、個人シナリオの２回の反復にはほぼ 140分かか
り、同時実行の場合に要する時間の２倍以上もかかるこ
とになる。

【０３４６】

【表２０】

【０３４７】インスタンスフアイル構文法は≪ausobjli
st≫ =“< 『instance』> ... ”であり、コマンドライ
ン構文法はない。

【０３４８】（説明）。オブジエクトリスト属性は他の
シナリオドライバ（環境、機械及び個人）を実行するシ
ナリオドライバにとつて極めて重要である。ausobjlist
と名付けられたオブジエクトリストインスタンス属性は
１つ又は２つ以上の項目のリストを含む。これらの項目
は現在のシナリオドライバが制御するシナリオを記述す
るインスタンスの名前である。シナリオドライバは一段
と低レベルのシナリオを走らせる他のシナリオドライバ
の実行を開始できる状態のとき、ausobjlistを抜けて、
現在のインスタンスの名前をこれに渡しているシナリオ
ドライバを実行する。オブジエクトリストはトツプの３
つの試験シナリオレベルにシナリオを定義するものであ
る。これは、オブジエクトリストが、試験シナリオが実
行しているものの核心を格納するからである。

【０３４９】（例）。この例では機械シナリオが実行し
ており、そのオブジエクトリストは次のようなものであ
る。

【０３５０】ausobjlist =「person1.p.1 person1.p.2
person2.p.1 」

【０３５１】機械シナリオドライバはシナリオドライバ
ステツプを実行した後、一段と低レベルのシナリオドラ
イバを実行できる点に達する。これを行うため、機械シ
ナリオドライバは上述のリストを検査し、同時又は順次
に３つのシナリオドライバを開始する。これらはインス
タンスperson1.p.1 、インスタンスperson1.p.2 、イン
スタンス2.p.1 を渡される。これにより３つの個人シナ
リオドライバが実行され、これらのシナリオドライバは
現在の機械シナリオドライバによつて制御される。注意
すべきは、person1.p.1 及びperson1.p.2 は同じ個人の
２つのインスタンスであることである。

【０３５２】

【表２１】

【０３５３】インスタンスフアイル構文法は≪ausobjnu
mlist ≫＝“＜『integer 』＞...”である。

【０３５４】コマンドライン構文法は、-r＜『integer
』＞｜≪-r≫『“＜『integer 』＞＜『integer 』
＞... ”』と、≪-e≫＜『integer 』＞｜≪-e≫“＜
『 integer』＞＜『integer 』＞... ”である。

【０３５５】（説明）。オブジエクトナンバーリストは
ausobjlist属性のメンバーを実行させるか又は現在のシ
ナリオ実行から除外させる。これは、ausobjlist内の項
目に写像するインテジヤのリストを指定することによつ
て実行される。デフオルトによつて、オブジエクトナン
バーリスト属性はausobjlist属性内のすべてのインスタ
ンスに対応するインテジヤのリストにセツトされるの
で、実行によつてこれらはすべて実行を完遂する。オブ
ジエクトナンバーリスト構成属性が準備され、これによ
り構成オブジエクトリストはインスタンス作成／変更ス
テージの間ausobjlist内のインスタンスのテンプレート
をなおも不変に維持することができる。これは、そのリ
ストは現在のシナリオを「定義する」ものであり、シナ
リオ構築ツールのインスタンス管理部分の間に変更され
ることはないからである。

【０３５６】（例１）。個人インスタンスが次のような
ausobjlist及びausobjnumlist を含んでいる場合、

【０３５７】ausobjlist＝“task1.t.1 task2.t.1 task
3.t.1 task4.t.1 task5.t.1 task6.t.1 ”、ausobjnuml
ist ＝“1 2 3 6 ”である。

【０３５８】個人シナリオドライバが実行するとき、そ
の個人のためのausobjlist内には６つのタスクインスタ
ンスが存在するが４つのタスクシナリオドライバだけを
開始する。これは、ausobjnumlist がその中に４つのイ
ンテジヤしか有していないからである。実行される４つ
のタスクとはtask1.t.1 、task2.t.1 、task3.t.1 及び
task6.t.1 であり、ausobjlistの４及び５のメンバーは
除外される。

【０３５９】（例２）。上述した個人シナリオドライバ
がコマンドライン上の-r“1 2 3 45 6 ”で実行する場
合、コマンドラインフラグは ausobjnumlistインスタン
ス属性を無効にして６つのタスクシナリオドライバ全部
を実行する。

【０３６０】（例３）。上述した個人シナリオドライバ
がコマンドライン上の-e「1 6」で実行された場合、コ
マンドラインフラグは ausobjnumlistインスタンス属性
を再び無効にし、ausobjlistの第１のメンバー及び第６
のメンバーを実行から除外してリスト内の残りのタスク
を実行する。

【０３６１】

【表２２】

【０３６２】インスタンスフアイル構文法は≪aussave
≫＝< ≪none≫｜≪pass≫｜≪fail≫｜≪all ≫> であ
り、コマンドライン構文法は-s < n｜ｐ｜ｆ｜ａ> であ
る。

【０３６３】（説明）。保管オプシヨンを使用して、タ
スク実行のために作成された固有の実行時デイレクトリ
構造を保管すべきか否かをタスクレベルシナリオドライ
バに通知する。タスク実行時情報を保管すべきか否かの
決定はユーザのタスクが渡されたか失敗したかというこ
とと保管属性の値とに基づいて行われる。 aussaveイン
スタンス属性又は「ｓ」コマンドラインフラグでこの保
管属性をセツトすることができる。セツトの種類は、全
く保管せず（無し(none)又はｎ）、渡されたタスクにお
いてだけ保管する（パス(pass)又はｐ）、失敗したタス
クにおいてだけ保管する（失敗(faile) 又はｆ）又は常
に保管する（全部(all) 又はａ）である。この保管機能
は圧縮機能と一緒に協力して作用することにより、タス
ク実行時にどの情報を保管し、保管するどの情報を圧縮
するかを決定する。

【０３６４】（例）。機械シナリオは失敗するタスクか
らの機械シナリオのタスク情報だけを保存することを望
むことがある。この状況においては機械インスタンス属
性aussave を次のようにセツトする。

【０３６５】aussave = fail

【０３６６】注意すべきは、この属性は機械シナリオド
ライバレベルにおいては実際に何も行つていないが、タ
スクシナリオドライバレベルへと下方に渡されて、そこ
で、この属性を使用することにより、タスク実行時デイ
レクトリ構造を除去又は保管すべきか否かを決定する。

【０３６７】

【表２３】

【０３６８】インスタンスフアイル構文法は≪ austask
code≫＝“＜『task file name』＞”であり、コマン
ドライン構文法はない。

【０３６９】（説明）。タスクコードパラメータはタス
クシナリオドライバの実行にとつて極めて重要である。
これは、何を実行すべきかを詳述している情報を含む他
の３つのシナリオドライバレベルのために指定されたオ
ブジエクトリストパラメータに類似している。オブジエ
クトリスト構成属性及びタスクコードパラメータ間の違
いは、タスクコードパラメータが実行すべきユーザのコ
ードの実際のフアイル名を含むことである。

【０３７０】タスクフアイル名への実際の経路は指定さ
れない。これは、このフアイルのロケーシヨンは次のよ
うにして決定されるからである。$AUSBIN によつて示さ
れる実行時タスクbin デイレクトリ構造が最初に検査さ
れ、次に、$AUSCODEBIN によつて示されるタスクコード
デイレクトリ構造の binデイレクトリが検査される。

【０３７１】（例）。そのロケーシヨンが /austin/tas
ks/r/rcp/bin/foobar であるシエルスクリプトfoobarを
走らせることによつて rcpタスクを実行すると、タスク
シナリオインスタンスフアイル内のaustaskcode 属性の
ために以下のように指定される。

【０３７２】austaskcode = 「foobar」

【０３７３】

【表２４】

【０３７４】インスタンスフアイル構文法は≪austaskp
arams ≫＝“＜『parameters』＞”であり、コマンドラ
イン構文法はない。

【０３７５】（説明）。主に試験用足場は環境変数に写
像されるユーザ定義属性を経由してユーザタスクコード
に渡つている情報の周囲に準備されるが、シナリオドラ
イバ及びシナリオ構築ツールもコマンドラインパラメー
タを経由してユーザタスクコードにパラメータを渡す能
力を支援する。これを行うには、タスクパラメータ構成
属性を使用する。ユーザタスクコードを実行するとき、
このシナリオドライバインスタンス属性の値を直接的に
コマンドライン上に渡す。

【０３７６】（例）。タスクについてのユーザタスクコ
ードがfoobarであり、コマンドラインを経由して渡され
る絶対値パラメータをそれが必要とする場合、インスタ
ンスフアイルからの以下の属性がこの状況を処理する。

【０３７７】 austaskcode = “foobar”austaskparams = “-m 20 ”

【０３７８】コマンドfoobarが実行したとき、これはコ
マンドラインに追加された“ -m 20”を伴つて実行す
る。

【０３７９】

【表２５】

【０３８０】インスタンスフアイル構文法は≪austim≫
＝＜『real』｜『integer 』＞であり、コマンドライン
構文法は-t＜『real』｜『integer 』＞である。

【０３８１】（説明）。 austime属性はユーザが望むシ
ナリオドライバ実行継続時間の長さを指定する。 austi
meを指定したとき、シナリオドライバはそのausobjlist
又はaustaskcode 内の項目を実行してこれらの完了を待
つ。すべてのインスタンスが完了すると、シナリオドラ
イバはシナリオドライバの開始時間が時間属性によつて
指定される時間よりも少ないために、検査をして時間が
経過したか否かを知る。肯定結果が得られると、シナリ
オドライバはausobjlist内のすべての項目を再び実行す
る。注意すべきは、この時間属性のための値は正でなけ
ればならないことである。

【０３８２】（例）。タスクを実行するための時間とし
てタスク開発者が２時間を指定し、かつユーザのタスク
コードの実行にほぼ45分必要であるとき、タスク全体が
３回の反復実行すなわち、ほぼ２時間15分の実行を行
う。「説明」で述べたように、これが生ずるのは、第２
の反復実行後時間がまだ残り、それゆえ次の反復が始め
られて、その反復に従つて実行のための時間を使い尽く
し、これにより実行が停止されるからである。

【０３８３】

【表２６】

【０３８４】インスタンスフアイル構文法は≪austype
≫= < ≪environment ≫｜≪machine ≫｜≪person≫｜
≪task≫ >であり、コマンドライン構文法はない。

【０３８５】（説明）。シナリオドライバ型属性は最も
重要なインスタンス属性である。それは、シナリオレベ
ルが実行しているシナリオドライバを教えるものであ
る。このことは極めて重要である。なぜならば、シナリ
オドライバの動作は、それがどのシナリオレベルを実行
しているかに大きく左右されるからである。

【０３８６】

【表２７】

【０３８７】インスタンスフアイル構文法は≪ aususer
≫＝“＜『user name』＞”であり、コマンドライン構
文法は-u＜『user name』＞である。

【０３８８】（説明）。ユーザ属性は一群のタスクをユ
ーザuser nameとして実行できるようにする。この属性
が個人レベルで使用されるとき、シナリオドライバはau
sobjlistのタスクインスタンスを実行する前にユーザus
er nameを変更しようと試みる。このユーザ変更が成功
しない場合、シナリオドライバはエラーを出して制御を
機械ドライバに戻す（又はＡＩＸシエルがトツプレベル
のシナリオドライバの場合ＡＩＸシエルに戻す）。

【０３８９】

【表２８】

【０３９０】インスタンスフアイル構文法は≪ausverbo
se≫＝＜『integer 』＞であり、コマンドライン構文法
は-v＜『integer 』＞である。

【０３９１】（説明）。冗長オプシヨンは情報の変化度
を、ジヤーナル内に載置できるようにすると共に標準出
力（stdout）及び標準エラー（stderr）に送ることがで
きるようにする。この冗長の変化レベルはジヤーナル記
入コマンドの操作を通じて達成される。冗長の度合いは
合計８つある。

【０３９２】

【表２９】

【０３９３】インスタンスフアイル構文法は≪auswindo
ws≫＝ <≪ true ≫｜≪false ≫>であり、コマンドラ
イン構文法は≪-w≫ <≪ｔ≫｜≪ｆ≫> である。

【０３９４】（説明）。ウインドウ構成属性は、これが
存在するならばウインドウ環境の利益を得るようにシナ
リオドライバが試みるべきであるか否かを決定する。値
が真であり、ＤＩＳＰＬＡＹ環境変数がセツトされる
と、シナリオドライバがそのausobjlistのメンバーを実
行し、これにより新しいシナリオドライバを開始するご
とに、異なるウインドウの新しいシナリオドライバを開
始しようと試みる。

【０３９５】（ユーザ定義属性）

【０３９６】ユーザ定義属性をこの試験用足場内のいず
れのレベルにおいても指定することができる。これらの
属性は一段と低レベルによつて機械レベルから下方に受
け継がれる。これらの属性はシナリオドライバ属性では
ないシナリオインスタンスフアイル内に識別子を配置
し、次にこれに１つの値を与えることによつて指定され
る。ドライバの１つが構成フアイル内でユーザ定義属性
に遭遇すると、このドライバはユーザ定義属性を単に環
境に置き、従つてこれは実行されたいずれかの子プロセ
スに継承される。

【０３９７】ユーザ定義属性の概念は情報をユーザタス
クコードに送る場合にタスクインスタンスシナリオフア
イルレベルで特に有用である。上述したように、ユーザ
定義属性の内容はシナリオ構築ツールによつて厳密に制
御することができるが、これは、このユーザ定義属性が
シナリオを定義するステージの間に定義され、形式及び
オプシヨン又は要求されたフラグを与えられなければな
らないからである。またユーザ定義属性は制限及びデフ
オルト値を有するように定義することができる。タスク
レベルでユーザ定義属性を使用する以外に、これらの属
性はすべての他のレベルで完全に有効である。この能力
によつてユーザ定義属性を個人シナリオレベルで１回だ
け指定することができ、次に個人シナリオを構築する各
タスクシナリオによつて使用することができる。

【０３９８】機械シナリオ全体はスケ−ルフアクタ（SC
ALEFACTOR ）のような環境変数を使用してこの機械シナ
リオを構築しているすべてのタスクシナリオが実行され
ている場合のストレスのレベルを判定することができ
る。

【０３９９】（属性の概要）

【０４００】次表（３０）はドライバ属性の完全なセツ
トとこれらの属性が有効であるレベルとを示す。灰色は
特定の属性が所定のシナリオレベルで有効であることを
表し、一方黒色はこれが有効でないことを表す。また有
効な属性はREQUIREDされることができ、従つて所与のレ
ベルで特定されなければならない。幾つかの属性は所与
のドライバレベルで有効であるが、これらの属性の値を
次のシナリオに引き渡す以外は何も行わない（これらの
属性を矢印で表す）。

【０４０１】（予約済属性の概要情報）

【０４０２】

【表３０】

【０４０３】以下は、シナリオドライバがそのシナリオ
レベルとは関係なく実行するシーケンスである。

【０４０４】（１）必要な内部初期化をすべて実行す
る。（２）必要であれば一時的ジヤーナルフアイルを作
成する。（３）コマンドラインを分析する。（４）
「ｈ」フラグが見つかり、インスタンスフアイルが存在
しない場合、シナリオドライバに詳細な援助を与える。
（５）インスタンスの属性を読み取る。（６）インスタ
ンスの予約済属性の有効性を検査する。（７）インスタ
ンスフアイル内で見つけたすべてのユーザ定義属性を環
境内に配置する。（８）現在のレベルについてシナリオ
ドライバ構成属性を決定する。（９）要求されればタス
クに対する援助を示す。（１０）存在すれば開始フック
を実行する。（１１）これがトツプレベルのシナリオド
ライバであれば、シナリオセツトアツプ機能を実行す
る。（１２）必要があれば、ausobjlistに対して必要な
変更を行う。（１３）次のレベルを実行する（これはル
ーピングの発生するステツプである）。（１４）存在す
れば終了フツクを実行する。（１５）実行状態を示すリ
ターンコードによつてこのプロセスを抜ける。

【０４０５】（環境シナリオドライバ）

【０４０６】図２０を参照する。ホストのクラスタにつ
いて、自動化したテストの制御が必要である場合、環境
シナリオドライバ２３０（及び図１のブロツク２２内の
符号１２）を使用する。環境内のこれらのホストの１つ
は環境サーバとして指定されなければならず、この環境
内の他のホストは環境クライアントとして指定されなけ
ればならない。環境サーバは環境シナリオドライバがこ
れに基づいて実行されるホストであり、環境クライアン
トは機械シナリオドライバがこれに基づいて実行される
ホストである（また注意すべきは、環境サーバは環境ク
ライアントであることができることである）。

【０４０７】環境シナリオドライバは通信１４用の環境
クライアントについて、上述したように、インターネツ
トソケツト及びausdriverdという名前のデーモンに依存
している。この通信方法は、環境クライアントについて
機械シナリオドライバ２３２の実行を開始し、これらの
機械シナリオドライバが実行を終了すると、これらの機
械ドライバからリターンコードを受け取ることができる
ようにする必要がある。デフオルトデイレクトリ構造及
びRISC System/6000プラツトフオームを仮定すると、以
下のコマンドを使用することによりネツトワーク内の環
境クライアントについてシナリオドライバデーモンを開
始することができる。

【０４０８】# /austin/tools/rsbin/ausdriverd &

【０４０９】環境シナリオの意図が、同時に行われるxt
ermsの利点を十分活用してＸ‐Windows でその機械シナ
リオのすべてを実行する場合、ausdriverdデーモンはこ
の環境内に既に設定されているＸ‐Windows の DISPLAY
環境変数で開始されなければならない。これは幾つかの
方法で行うことができる。

【０４１０】まず、Ｘ‐Windows を開始すると、 ausdr
iverコマンドをxterm の１つで実行することによつて、
この効果を得ることができるが、これは、Ｘ‐Windows
を初期化することによつて DISPLAY環境変数がＸ‐serv
erに設定されるからである。これは、 ausdriverデーモ
ンがその環境内に DISPLAY環境を有し、変数が正しい値
を有することを保証するのに最も安全な方法である。し
かしながら、自動化することも一段と困難である。

【０４１１】Ｘ‐serve が常に同じ、例えば、unix:0で
あることが分かつていれば、他の方法を推薦することが
できる。/ etc /rc./ aus という名前のフアイルを作成
してこれに以下のコマンドを置く。

【０４１２】# DISPLAY=unix:0 ausdriverd ＆then、/e
tc/inittabフアイル端部に以下のコマンドを加える。

【０４１３】rcaus:2:wait:sh /etc/rc.aus

【０４１４】この結果、 DISPLAY環境変数を所定のＸ‐
server、unix:0に設定して、ブート時間でausdriverdデ
ーモンが実行される。

【０４１５】環境シナリオドライバのオブジエクトリス
ト(ausobjlist)のインスタンス２３４は特別の意味を有
する。このインスタンスの名前（上述したように、.m.<
int>の前の）は、このインスタンスがそれに基づいて実
行されようとしている機械のホスト名でなければならな
い。従つて、foobarという名前の機械に基づいて、環境
シナリオドライバ２３０が機械シナリオ２３２の実行を
開始するためには、環境シナリオドライバのオブジエク
トリスト(ausobjlist)内のインスタンス２３４の１つの
名前が「foobar.m.<int>」でなければならない。ここで
<int> は特定のfoobar機械シナリオインスタンス番号で
ある。foobarはfoobar.m.<int>機械シナリオが実行され
るべきホストの名前であると、環境シナリオドライバは
仮定する。

【０４１６】実行時にフアイルシステムをクラスタ内で
分散することのできる方法は多くある。例えば、１つの
可能性は、フアイルシステム全体をネツトワーク内の各
ホストに配置させることである。他の可能性は、フアイ
ルシステムをネツトワーク内の１つのホストに物理的に
配置させ、次に当分野では周知のように、このフアイル
システムをネツトワークフアイルシステム（ＮＦＳ）
（又はこれと同等の物）を介してネツトワーク内のすべ
てのホストに分配することである。しかしながらこの分
散を行うと、すべての情報がネツトワーク内のすべての
ホストの同じ位置に存在することが要求される。

【０４１７】環境シナリオドライバは環境シナリオの実
行中に /austin/runtimeデイレクトリ構造が分配される
か否かによつて異なつた動作を実行する。このデイレク
トリ構造が（ＮＦＳ又はＮＦＳと類似の何か）を介して
分散される場合、シナリオジヤーナルフアイルに環境全
体を書き込む際にいずれかのホスト上でいずれかのシナ
リオドライバが実行されているときは常に、物理的な書
き込みが、/austin/runtime デイレクトリ構造のサーバ
に配置されるフアイルと同じフアイルで発生する。

【０４１８】環境シナリオがＮＦＳのような何かによつ
て/austin/runtime デイレクトリ構造を分散する場合、
環境シナリオインスタンスフアイル内の ausdistribute
された予約済属性は真に設定すべきではない。

【０４１９】環境シナリオドライバレベルの開始フツク
及び終了フツクを環境シナリオの実行に対する非常に総
合的なピースとして使用することにより、特定の環境に
対してシナリオドライバの実行をカストマイズする。例
えば、開始フツクはタスクの取得、ネツトワークの実
装、ネツトワークの準備の検証、すべてのクライアント
に対するＸ‐Windows の開始、すべてのクライアントに
対する ausdriverの存在の検証等のような環境設定全体
を自動的に行うスクリプトを走らせることができる。終
了フツクは状態フアイルを集め、報告書を自動的に走ら
せ、ネツトワークの実装を外すことによつて環境をクリ
ーンアツプする等を行うことができる。

【０４２０】環境シナリオドライバ２３０は機械シナリ
オが走つているホストが壊れるか又はネツトワークイン
タフエースが故障する等の何らかの理由で、機械シナリ
オドライバ２３２と接触ができなくなると、環境シナリ
オドライバは決して終了しない。これは、現在、環境シ
ナリオドライバが待機実行の状態にないからである。環
境シナリオドライバは、機械シナリオドライバが実行を
終了したという言葉をインターネツトソケツト通信媒体
を介して機械シナリオドライバから受け取るまで待機し
続ける。

【０４２１】（機械シナリオドライバ）

【０４２２】図２１を参照する。ホスト上で自動的に複
数の個人シナリオの実行を制御することが適当である場
合には、機械シナリオドライバ（また図１のブロツク２
０の符号１２）が使用される。この機械シナリオドライ
バによつて、情報を機械シナリオにグループ化すること
ができ、従つて状態はそのレベルで追跡することがで
き、「機械シナリオ」の成功率について判定することが
できる。

【０４２３】（個人シナリオドライバ）

【０４２４】図２２を参照する。機械上で自動的に複数
のタスクシナリオの実行を制御することが適当である場
合は、個人シナリオドライバ２５０が使用される。個人
シナリオドライバによつて、タスクをパーソンのような
シナリオにグループ化することができ、従つて状態をこ
のレベルで追跡することができ、「個人シナリオ」の成
功率について判定することができる。

【０４２５】ユーザ構成属性が１つの値を有していれ
ば、個人シナリオドライバは別のステツプを実行する。
このような状況では、個人シナリオドライバはユーザ構
成属性の値によつて特定されたユーザアカウントに対し
て「ログイン」をシユミレートする。これによつて、個
人シナリオドライバのレベル以下で走るすべてのタスク
は個人のレベルでユーザが指定したように実際に走るこ
とができる。ユーザ構成属性を変更すれば、ドライバは
ルートの特権を実行することを要求する。ユーザが個人
インスタンス内に割り付けられた属性の aususerによつ
て指定されると、そのユーザのｉｄはシステム上に存在
しなければならない。個人シナリオドライバはそのユー
ザをシステムに自動的に加えることはない。

【０４２６】（タスクシナリオドライバ）

【０４２７】図２３に示すように、タスクシナリオドラ
イバ２６０を使用することによりユーザタスクコード６
８を実行する。これによつて、ユーザタスクコード内で
一般的にシナリオ開発者が実行する多くの機能を自動的
に処理することができる。例えば、ループに対する他の
方法、ジヤーナルに記入する他の方法又は独自の作業空
間を作成する他の方法を見つける意味がないので、タス
クシナリオドライバはこれらの設計の詳細すべてを独自
に処理し、従つてユーザのコードを「testing」だけに
集中させることができる。

【０４２８】タスクドライバがユーザのタスクコードの
実行を開始するとき、図２４に示すように、タスクドラ
イバは他のシナリオドライバとは異なる幾つかのステツ
プを実行する。主な相違点の１つは、タスクが独自のデ
イレクトリ構造２７０を作成し、この構造に基づいてこ
のタスクはその作業のすべてを実行することである。こ
のデイレクトリ構造はタスク名、このタスクが実行され
ているホスト名、このタスクのプロセスのｉｄ番号及び
このタスクの反復を用いて作成される。シナリオデイレ
クトリの下に作業中という名前の構造のデイレクトリが
見つかる。このタスクデイレクトリの下には、さらに３
つのデイレクトリ、bin 、jour及びworkが作成される
（例えば、図８を参照）。

【０４２９】タスクコードを実行する前に、タスクドラ
イバはブロツク２７２でユーザの binデイレクトリにセ
ツトアツプフアイルが存在するか否かを検査する。セツ
トアツプフアイルが存在する場合、タスクシナリオドラ
イバはこれをブロツク２７４で実行する。このプログラ
ムは実行を継続するためにゼロのリターンコードをタス
クドライバに戻さなければならない。

【０４３０】ブロツク２７６においてユーザのタスクコ
ードを呼び出すとき、最初にAUSBINデイレクトリ内を探
す。ユーザのタスクコードがAUSBINデイレクトリにある
場合、これはそのロケーシヨンから実行され、タスクコ
ードがAUSBINデイレクトリにない場合にはAUSCODEBINデ
イレクトリを探索する。ユーザのタスクコードがAUSCOD
EBINデイレクトリにある場合、これを実行し、ユーザの
タスクコードがAUSCODEBINデイレクトリにない場合は、
エラーが発生される。

【０４３１】ブロツク２７９においてユーザのタスクコ
ードを実行する前に、タスクシナリオドライバは、ブロ
ツク２７８においてデイレクトリを実行時タスクデイレ
クトリ構造の作業デイレクトリに変更する。

【０４３２】ユーザのタスクコードが完了すると、ユー
ザのタスクコードがパスしたか又は失敗したか否か及び
aussaveシナリオドライバ属性の値によつて、タスクド
ライバはブロツク２８０において実行時タスクデイレク
トリ構造を実行時シナリオデイレクトリのパス又は失敗
デイレクトリに移動させる。またタスクシナリオドライ
バはブロツク２８２において auscompressの値によつて
作業及びパスデイレクトリ内で情報を圧縮する。

【０４３３】（ジヤーナル記入）

【０４３４】図２５を参照する。シナリオドライバ５８
は６つのジヤーナルコマンドのセツトを使用することに
よりシナリオジヤーナル６２に対して記入を行う。これ
らのコマンドはbegin 、log 、warning 、error 、seve
re及びfinishである。分散環境において、すべてのシナ
リオドライバは同じシナリオジヤーナルフアイル６２に
対して同じシナリオログで実行するが、これ以外の場合
には、各機械に対して１つのシナリオジヤーナルフアイ
ルが存在し、この機械上のすべてのシナリオドライバは
各機械に対して記入する。

【０４３５】（Ｘ‐Windows 資源のカストマイズ）

【０４３６】ausdriver＿machine 、 ausdriver＿perso
n及び ausdriver＿taskによつてxtermsを事前保留する
ことによつて、すべての有効な xterm資源を使用してシ
ナリオドライバがこれらのxtermsを実行する方法を変更
することができる。これらの資源を使用しない場合、こ
れらの３つのレベルに対してシナリオドライバが使用す
る xtermは、.Xdefaultsフアイル内のデフオルト xterm
資源である。

【０４３７】（例）。次表３１は、ウインドウズの構成
属性を真に設定して x‐Windows で走らせたときに、機
械、個人及びタスクシナリオドライバのxtermsを制御す
るために使用する資源のサンプルのセツトである。

【０４３８】

【表３１】

【０４３９】（シナリオジヤーナル）

【０４４０】図２６のシナリオジヤーナルフアイル６２
は ASCIIテキストフアイルである。分散形実行時フアイ
ル空間で実行される環境においては、このフアイルは環
境サーバに存在するだけであり、すべてのシナリオドラ
イバはこれに対して記入する。非分散環境においては、
この環境内の各機械に対して１つのシナリオジヤーナル
が存在し、１つの機械上で実行しているすべてのドライ
バはこれらのそれぞれのシナリオジヤーナルに記入す
る。

【０４４１】（フオーマツト）

【０４４２】シナリオジヤーナルフアイルには２つの異
なるレコード形式が存在する。（１）ジヤーナル記入機
能（begin 、log 、warning 、error 及びsevereによつ
て作成されるレコード形式及び（２）シナリオドライバ
終了機能によつて作成されるレコード形式が存在する。

【０４４３】

【表３２】

【０４４４】終了機能のレコードとの唯一の相違点はフ
イールド１３及び１４間に他のフイールドが存在し、そ
の上に、終了したオブジエクトのリターンコードが存在
することである。

【０４４５】各フイールドは文字「｜」（パイプ文字）
によつて分離される。第１のフイールドの前又は最後の
フイールドの次にはパイプ文字は存在しない。

【０４４６】（例）。図２７はフアイルclaussen.m.1３
００が指示する機械シナリオを走らせることによつて作
成されたシナリオの例を示す。次にこの機械シナリオは
１つの個人シナリオ、shane.p.1 ３０２を実行し、この
個人シナリオは２つのタスクシナリオ、shane.t.1 ３０
４及びshane2.t.1３０８を実行し、これらはいずれも符
号３０６及び３１０においてそれぞれ失敗した。かくし
て、個人シナリオ及び機械シナリオはそれぞれ符号３１
２及び３１４においてまた失敗した。この特定の例に対
する唯一のジヤーナルのエントリは冗長レベルに起因す
る開始及び終了である。

【０４４７】この標準フオーマツトに基づいて、動作中
の実際のテストとは関係なく、汎用の報告書ジエネレー
タ６４（図２６）を使用して報告書６６（図２６）を作
成することができる。

【０４４８】（ユーザコードインタフエース）

【０４４９】図２のＡＰＩ７０によつて、シナリオドラ
イバ５８及びユーザコード６８間にインタフエースが設
けられる。このインタフエースは伝統的なＡＰＩすなわ
ちアプリケーシヨンプログラミングインタフエースでは
なく、１組のシステム変数である。これらのシステム変
数はユーザタスクコードを呼び出す前にシナリオドライ
バによつて設定される。ユーザタスクコードはこれらの
変数にアクセスすることによりこのシステムの状態又は
環境を判定することができる。ユーザコードが使用する
ために下記の環境変数を設ける。

【０４５０】（１）AUSCODEDIR

【０４５１】AUSCODEDIRデイレクトリ構造は、この構造
にユーザのタスクコードを配置する最高レベルの構造で
ある。例えば、タスクadminlの場合、デフオルトによる
このデイレクトリ構造は/austin/tasks/adminlである。
この構造のデフオルトのロケーションはインスタンス属
性auscodedirによつて変更することができる。

【０４５２】（２）AUSCODESRC

【０４５３】AUSCODESRCデイレクトリはAUSCODEDIRデイ
レクトリの下にあるユーザのタスクsrcデイレクトリの
ロケーシヨンである。これを使用して実行時間中にこの
構造内のフアイルを参照することができる。

【０４５４】（３）AUSCODEBIN

【０４５５】AUSCODEBINデイレクトリはAUSCODEDIRデイ
レクトリの下にあるユーザのタスクbinデイレクトリの
ロケーシヨンである。これを使用して実行時間中にこの
構造内のフアイルを参照することができる。

【０４５６】（４）AUSCODEDAT

【０４５７】AUSCODEDATデイレクトリはAUSCODEDIRデイ
レクトリの下にあるユーザのタスクdatデイレクトリの
ロケーシヨンである。これを使用して実行時間中にこの
構造内のフアイルを参照することができる。

【０４５８】（５）AUSCODEDOC

【０４５９】AUSCODEDOCデイレクトリはAUSCODEDIRデイ
レクトリの下にあるユーザのタスクdocデイレクトリの
ロケーシヨンである。これを使用して実行時間中にこの
構造内のフアイルを参照することができる。

【０４６０】（６）AUSBIN

【０４６１】AUSBINデイレクトリ構造は実行時にドライ
バが自動的に作成する構造である。このデイレクトリの
目的は、実行時間中に行う必要があるすべてのソースコ
ードのコンパイルのロケーシヨンを可能にすることであ
るが、これは、 /austin/tasksデイレクトリ構造が実行
時間中だけに読み取られるからである。通常この環境変
数はタスクセツトアツププログラムで使用される。

【０４６２】（７）AUSLIB

【０４６３】AUSLIBデイレクトリはＣプログラムにリン
クする際に使用されるlibaus.aライブラリのロケーシヨ
ンである。これは、タスクセツトアツプコード又はタス
クコード自身で使用することができる。

【０４６４】（８）AUSPASS

【０４６５】AUSPASS変数は、パスしたタスクに対す
る、シナリオの保存デイレクトリ構造を示す。

【０４６６】（８）AUSFAIL

【０４６７】AUSFAILは、失敗したタスクに対する、シ
ナリオの保存デイレクトリ構造を示す。

【０４６８】（９）AUSWORKING

【０４６９】AUSWORKING変数は、進行中のすべてのタス
クを含む、シナリオの作業デイレクトリ構造を示す。

【０４７０】（１０）AUSSCENARIO

【０４７１】AUSSCENARIO変数は、シナリオジヤーナル
フアイル（複数）を含む、シナリオの最高レベルのデイ
レクトリ構造を示す。

【０４７２】（１１）AUSTASK

【０４７３】AUSTASK変数は実行中の現在のタスクシナ
リオの名前を保持する。

【０４７４】（１２）AUSPERSON

【０４７５】AUSPERSON変数は実行中の現在の個人シナ
リオの名前を保持する。

【０４７６】（１３）AUSMACHINE

【０４７７】AUSMACHINE変数は実行中の現在の機械シナ
リオの名前を保持する。

【０４７８】（１４）AUSENVIRONMENT

【０４７９】AUSENVIRONMENT変数は実行中の現在の環境
シナリオの名前を保持する。

【０４８０】（１５）AUSTPHIDIR

【０４８１】AUSTPHIDIR変数はタスクドライバが実行時
間に作成するタスク実行時のデイレクトリ構造のトツプ
を示す。

【０４８２】（１６）AUSWORK

【０４８３】AUSWORK変数は、タスク実行時デイレクト
リ（AUSTPHIDIR）内の作業デイレクトリを示す。これ
は、タスクが実行時間に置かれるデイレクトリである。

【０４８４】（１７）AUSJOURNAL AUSJOURNAL変数はシナリオジヤーナルフアイルの名前を
保持する。この変数は変更すべきでない。

【０４８５】（ジヤーナルプログラミングインタフエー
ス）

【０４８６】標準的なジヤーナル記入プログラミングイ
ンタフエース７４（図２）はタスク開発者のために存在
する。このジヤーナル記入インタフエースはＣバインデ
イング及びシエルバインデイングの双方を有する４つの
コマンドから構成される。これらのジヤーナル記入コマ
ンドは標準化したジヤーナル７２を作成する。標準化ジ
ヤーナルの利点は、その内容を分析することができる１
組の強化した報告書フイルタを有することができる能力
である。注意すべきは、シナリオジヤーナル６２はタス
クジヤーナル７２と同じ内部フオーマツトを有すること
である。またこのシナリオジヤーナルはタスクジヤーナ
ル７２に設けられているのと同じＡＰＩを有している
が、これはユーザタスクと違つてシナリオドライバ５８
だけが使用する。

【０４８７】標準ジヤーナル記入プログラミングインタ
フエースは、auslog、auswarning、auserror及びaussev
ere のコマンドから構成される。

【０４８８】（Ｃ言語のバインデイング）

【０４８９】以下は、Ｃ言語のジヤーナル機能の構文法
である。

【０４９０】void auslog( char *Format [,Value,
...] ) 、void auswarning( char *Format [,Value,
...] ) 、void auserror( char *Format [,Value,
...] ) 、voidaussevere( char *Format [,Value,
...] )

【０４９１】これらのコマンドの構文法は、printf()シ
ステム呼出しのコマンドと同じである。これらの各ルー
チンに可変数の引数を通過させることができ、これらの
引数はこのルーチン内で評価される。例えば、下記の方
法でauslog()を呼び出すことができる。

【０４９２】auslog( “Calling function %s at %
d.”, function＿name,time)

【０４９３】タスクコードがＣ言語で書かれると、これ
は、ライブラリ /austin/tools/rslib/libaus.a.とリン
クすることによつてこれらのジヤーナル記入機能にアク
セスすることができる。

【０４９４】（シエル言語のバインデイング）

【０４９５】auslog <string>、 auswarning <string
>、 auserror <string>及び aussevere <string> は、
ジヤーナル記入コマンド用のシエル言語のバインデイン
グである。

【０４９６】これらの機能を使用するには、 tools bin
デイレクトリがＰＡＴＨ環境変数（すなわち、PATH=$PA
TH:austin/tools/rsbin ）を使用するシステム経路内に
なければならない。

【０４９７】（説明）。以下は、４つの各ジヤーナル記
入コマンドの意図した用途の簡単な説明である。

【０４９８】（１）auslog

【０４９９】auslogコマンドはエラー条件を示さないジ
ヤーナルエントリをタスクコードに行わせるために設け
られる。基本的にauslogコマンドはデバツグの支援に使
用され、タスクの実行中に実行される動作の追跡に使用
することができる。

【０５００】（２）auswarning

【０５０１】auswarningコマンドは、全体のタスクを失
敗させる程には厳しくないエラー条件を示すジヤーナル
エントリをタスクコードに行わせるために設けられる。
基本的にこのauswarningコマンドは予期しない結果を示
すために使用されるが、失敗を是認するのに十分な程重
要ではない。

【０５０２】（３）auserror

【０５０３】auserrorコマンドは、実行中のタスクコー
ドを失敗させるすべてのエラー条件を示すジヤーナルエ
ントリをタスクコードに行わせるために設けられる。こ
のauserrorコマンドを使用して予期しない結果を指示
し、この予期しない結果の大きさがタスクを失敗させる
べきであるが、このタスクの連続した実行を中断すべき
ではない。

【０５０４】（４）aussevere

【０５０５】aussevereコマンドは、実行中のタスクコ
ードを失敗させるエラー条件を示すジヤーナルエントリ
をタスクコードに行わせるために設けられる。この aus
severeコマンドを使用して予期しない結果を指示し、こ
の予期しない結果の大きさがタスクを失敗させるべきで
あり、かつタスクの実行を中断すべきである。一般的に
終了コマンド又はリターンコマンドはタスクコード内の
aussevereコマンドに従う。

【０５０６】（開始フツク及び終了フツク）

【０５０７】開始フツク及び終了フツクはドライバによ
つて実行される。これらは、図１のユーザコードジヤー
ナルプログラミングインタフエース７４にアクセスす
る。開始及び終了フツクのためのジヤーナルエントリ
は、タスクジヤーナルフアイルの代わりにシナリオジヤ
ーナルフアイルにログされる。これは、タスクジヤーナ
ル７２の代わりにシナリオジヤーナル６２に記入を行う
唯一のユーザコードである。注意すべきは、冗長レベル
は、これがタスクジヤーナルのエントリに影響を及ぼす
のとは異なる方法でシナリオジヤーナルエントリに影響
を及ぼす。

【０５０８】ドライバは開始フツク及び終了フツクのス
クリプトによつて戻された値を使用することにより前進
すべきか否かを判定する。この値がゼロ以外であると
き、ドライバは実行を中断する。

【０５０９】機械シナリオドライバレベルで開始フツク
及び終了フツクを使用することにより、機械シナリオの
実行中に特定のホストのシステム資源を監視し、かつ特
定の機械シナリオに特有の他の特定のセツトアツプ項目
及びクリーンアツプ項目を監視することができるスクリ
プトの実行を開始及び中断することができる。また機械
シナリオレベルでの開始フツク及び終了フツクはいずれ
かのユーザとして実行することができる特定のタスクの
セツトアツプステツプを実行する優れた位置であるが、
あるセツトアツプとクリーンアツプとを実行するにはあ
る最小のルートのユーザ権限を必要とする。これは、通
常機械シナリオドライバがルートの権限によつて走り、
タスクシナリオドライバは恐らくこれによつて動作して
いないからである。

【０５１０】（タスク）

【０５１１】ユーザのタスクコードは、上述したよう
に、４つのユーザコードジヤーナルプログラミングコマ
ンドを使用して標準のタスクジヤーナルにログすること
ができる。前に述べた環境変数は、タスクコードが処理
する必要があるすべてのフアイルを配置させるために使
用することができる。タスクコードがタスクドライバに
リターンコードを戻してこれがパスしたか失敗かを指示
することが義務づけられている。値がゼロであると成功
を示し、これ以外のすべての値は失敗を示す。次にタス
クドライバはこのパス又は失敗の値をシナリオジヤーナ
ルに対して記入する。

【０５１２】タスクセツトアツプコードはそのインタフ
エースに対して実際のタスクコードと非常に類似した動
作を行う。このタスクコードは上述したジヤーナルプロ
グラミングインタフエースにアクセスする。タスクセツ
トアツプコードに対するジヤーナルのエントリはタスク
ジヤーナルにログされる。

【０５１３】タスクコードが実行時間中にソースフオー
マツト内にあるとき、タスクセツトアツプコードの目的
は、そのソースコードをコンパイルし、環境変数AUSBIN
によつて表される２進のコンパイルされたソースコード
用の実行時デイレクトリコードにこのソースコードを置
くことである。

【０５１４】セツトアツプフアイルの構文法はストリン
グ「.setup」が後に続くタスクの名前である。これは、
このタスクの binデイレクトリ（環境変数AUSCODEBINで
示す）内になければならない。タスクドライバが走ると
きこのフアイルが存在すれば、このフアイルはタスクコ
ードの実行の前に自動的に実行される。

【０５１５】ドライバはタスクセツトアツプコードによ
つて戻された値を使用することにより前進すべきか否か
を判定する。この値がゼロ以外のいずれかの値であれ
ば、ドライバはタスクコードを実行しない。

【０５１６】タスクヘルプフアイルインタフエースはド
ライバを介するオンライン、ソフトコピー、タスクヘル
プを可能にするために存在する。この形式のヘルプを受
け取るために、 ausdriverコマンドは「ｈ」コマンドラ
インフラグ及びタスクインスタンスフアイルによつて実
行される。このインスタンスフアイルを使用することに
よりタスクヘルプフアイルの予期されるロケーシヨンを
判定し、次にこれをstdoutに送る。

【０５１７】ヘルプフアイルの構文法は、ストリン
グ「.help 」が後に続くタスクの名前である。これはタ
スクの docデイレクトリ（環境変数AUASCODEDOC によつ
て示す）内になければならない。このフアイルは簡単な
ASCIIフアイルである。特定のヘルプフアイルのフオー
マツトを有することは優れたアイデアであるがこの種の
ヘルプフアイル内の情報はテストを行つている組織によ
つて決まる。

【０５１８】（タスクジヤーナル）

【０５１９】タスクジヤーナルフアイルは ASCIIテキス
トフアイルである。シナリオ実行ステージの間にテスト
シナリオで実行されるタスクの各インスタンスと関連す
るタスクジヤーナルフアイルは１つある。

【０５２０】タスクジヤーナルフアイルのすべてのエン
トリは同じレコードフオーマツトを有し、４つのタスク
ジヤーナル記入コマンド、auslog、auswarning、auserr
or、及びaussevere によつて作成される。

【０５２１】タスクジヤーナルのフイールドのフオーマ
ツトは次表（３３）の通りである。

【０５２２】

【表３３】

【０５２３】各フイールドは文字「｜」（パイプ文字）
によつて分離されている。第１のフイールドの前又は最
後のフイールドの次にはパイプ文字は存在しない。

【０５２４】図２８はタスクジヤーナルフアイルがどの
ようなものであるかを示す１例である。これは、シナリ
オジヤーナルフアイルの例で走つたタスクshane.t.1 か
らの出力である。タスクが走ると、冗長レベルは「７」
に設定された。

【０５２５】（報告書フイルタ）

【０５２６】報告書フイルタ６４によつて、異なるレベ
ルでシナリオの簡単な概要が与えられる。ユーザはどの
レベルで報告書ジエネレータが要約を行うかを指定する
ことができる。符号６６で報告される情報は、指定され
たレベルの各特定の項目がパスした回数と失敗した回数
と成功の重み付けしないパーセントとである。報告書ジ
エネレータ６４は異なる個人シナリオの下で走る同一の
２つのタスクを別のタスクとして報告する。この考え方
は各レベルで行われる。このような報告書ジエネレータ
の実行はシナリオがどのよう実行されているかについて
の高レベルの感触を得るのに有用であるが、実行回数に
基づくパーセントに重み付けしない。例えば、個人シナ
リオが１つのタスクを99回実行し、これが99回の試行す
べてでパスし、他のタスクは１回だけ実行されて失敗す
れば、この個人シナリオは成功率が99〔％〕ではなくて
０〔％〕としてマークされる。現在行われている報告書
では重み付けがないので、この報告書ジエネレータは重
み付けの必要がないタスクレベルだけで使用することを
推奨する。

【０５２７】

【表３４】

【０５２８】Ausreportの例を次表（３５）に示す。

【０５２９】

【表３５】

【０５３０】この報告書は個人シナリオを走らせた後に
発生された。この特定の個人シナリオ、pers.p.1は２つ
のタスクインスタンス、try 1.t.2 及びtry2.t.1から構
成される。try.2.t.1 は３回ループしたと報告され、tr
y1.t.2は１回だけループしたと報告された。シナリオジ
ヤーナルフアイルのサイズを小さくするため、冗長度は
０に設定された。図２９はこのシナリオの実行時間に作
成されたシナリオジヤーナルフアイルを示す。

【０５３１】（ユーテイリテイ）

【０５３２】（ｐｋユーテイリテイ）

【０５３３】AIXユーテイリテイpkを使用してデイレク
トリ構造を１つのフアイルに圧縮する。この使用法の構
文は PK <directory> である。

【０５３４】図３０に示すように、PKコマンドを使用す
る結果、<directory> で示すデイレクトリ構造３２０が
得られ、これは AIX tarコマンド３２２及び AIX圧縮コ
マンド３２４によつて処理される。このプロセスの結
果、このデイレクトリ構造内のすべてのフアイルは１つ
のフアイルに結合され、次にこのフアイルは圧縮され
る。このフアイルがpkコマンドによつて作成されたこと
を示すため、拡張子 .tar.Z ３２６を与える。

【０５３５】pkコマンドの主な目的は、シナリオデイレ
クトリ構造のパス及びフアイルのデイレクトリ内のタス
クシナリオデイレクトリ構造の圧縮を可能にすることで
ある。pkユーテイリテイを使用する結果、システムデイ
スクの資源に対して一段と最適な記憶構造が得られる。

【０５３６】（実行後のシナリオデイレクトリ構造の
例）

【０５３７】図１２はengineering.e .1という名前の環
境シナリオの実行によつて作成されるデイレクトリ構造
の１例を示す。この例は、シナリオのパスデイレクトリ
内でどのにようにrcp.t.2 タスクシナリオデイレクトリ
構造を圧縮するかを示す。

【０５３８】

【表３６】

【０５３９】pkコマンドはデイレクトリ構造rcp.t.2.cl
aussen.888.1の圧縮をもたらす。古いデイレクトリ名
は、これらがpkコマンドと共にパツクされたことを示し
ているtar.Z フアイル名拡張子を伴うフアイル名に変更
される。この図１２について留意すべき１つの事柄は、
パスデイレクトリ内のrcp.t.1.claussen.999.1.tar.Zフ
アイルが既にpkプロセスを通過していることである。こ
れは、このフアイルがパスすれば、これを実行し、引き
続いてこのフアイルを自動的に圧縮するようにrcp.t.1
t.t.1インスタンスフアイルがタスクドライバに命令す
る。新しいデイレクトリ構造を図１３に符号１８７で示
す。

【０５４０】（unpkユーテイリテイ）

【０５４１】ユーテイリテイunpkを使用することにより
pkプロセスを通過したフアイルの圧縮を解除する。この
使用法の構文はunpk< packed＿file＿name> である。

【０５４２】図３１に示すように、unpkコマンドを使用
すると、< packed＿file＿name> で示すフアイル名３２
８が得られ、これはAIX uncompressコマンド３３０及び
tarコマンド３３２を介して走る。このプロセスの結
果、フアイルは圧縮されず、次に untarされてデイレク
トリ構造３３４を作成する。デイレクトリ構造３３４の
名前は、.tar.Z拡張の付いていない< packed＿file＿na
me> によつて示される名前である。

【０５４３】unpkコマンドの主な目的は、図１３に示す
ような以前にパツクされた情報のパツクを外し、これを
検討できるようにすることである。例えば、ドライバが
自動的に検討する必要があるタスクデイレクトリ構造を
自動的にパツクすれば、unpkコマンドを使用することに
よりこれのパツクを外し、その通常のサイズ及び構造に
戻すことができる。

【０５４４】（実行後のシナリオデイレクトリ構造の
例）

【０５４５】この例は、シナリオ構造のパスデイレクト
リ内のパツクされたフアイルのうち１つのパツクの取り
外しを示す。

【０５４６】

【表３７】

【０５４７】このunpkコマンドによつて、図１３のrcp.
t.1.claussen.999.1デイレクトリ構造１８４が復元す
る。図１４はunpkコマンドの終了後の構造１８５を示
す。

【０５４８】（ ausstatユーテイリテイ）

【０５４９】ausstatユーテイリテイは、これが標準タ
スクジヤーナルで見つけたauserror及び aussevereのジ
ヤーナルレコードの数を戻す。このユーテイリテイの主
な目的はタスク開発者の失敗率を判定する場合にこれら
のタスク開発者を支援することである。

【０５５０】ユーザタスクコードがリターンコードをタ
スクドライバに渡すことは義務であるので、この目的の
ためにユーザタスクコードの終端において ausstatコマ
ンドを使用することができる。

【０５５１】ausstatをこの目的のために使用すると
き、これはすべてのauserror及び aussevereレコードを
ジヤーナルフアイル内でカウントするので、予防策を使
用しなければならない。見いだした実際のエラーの数を
表すために ausstatが見つけた数を希望するなら、２つ
のauserrorコマンドを使用して１つのエラーを記述して
はいけない。１つのエラーを記述するために２本以上の
ラインが必要であれば、１つ又は２つ以上の auslogsの
前にあるauserror又は aussevereを使用する。

【０５５２】（Ｃ言語のインタフエース）

【０５５３】以下は ausstat機能に対するＣ言語のイン
タフエースのためのANSI Cプロトタイプの定義である。

【０５５４】int ausstat( void );

【０５５５】ユーザタスクコードはライブラリ/austin/
tools/lib/libaus.a. とリンクすることによつて ausat
at機能にアクセスすることができる。

【０５５６】（例）。以下の例は、Ｃ言語で書かれたサ
ンプルタスクで ausstatコマンドをどのように使用する
ことができるかを示す。以下のコードはユーザのタスク
コードの１セクシヨンであり、これは標準のジヤーナル
コマンドを使用し、次に ausstatを使用してジヤーナル
記入されたエラー及び重大エラーの数をタスクシナリオ
ドライバに戻す。

【０５５７】

【表３８】

【０５５８】次表（３９）は上述のソースコード内の３
つのテスト機能(test1()、test2()及びtest3())に対す
る成功又は失敗の可能な組合わせを表すマトリツクスで
ある。第４番目のフイールドの値は ausstatが計算した
タスク全体のリターンコードである。

【０５５９】以前の失敗のためにテストケースが中止さ
れたため、実行しなかつた。

【０５６０】（シエル言語インタフエース）

【０５６１】ausstatコマンドを出すことによつて簡単
に ausstatコマンドのシエルスクリプトインタフエース
を使用する。 ausstatシエルインタフエースはauserror
又はaussevereのジヤーナルエントリの数を２つの方
法、すなわちこの値をstdoutに反映させる方法及びその
リターンコードを適正な値に設定する方法によつて戻
す。

【０５６２】次表（４０）は上述の例のコードに対応す
るシエル言語である。

【０５６３】

【表４０】

【０５６４】aussevereに続くラインはauslogであり、
他の aussevereではないことに留意する。これが他の a
ussevereであるとき、タスクは値「１」の代わりに値
「２」を有して存在するが（test1 がパスしたと仮定し
て）、これは、 ausstatが実際の問題ではなく正にジヤ
ーナルレコードを考慮するからである。

【０５６５】最後に、図３７はこの多重コンピユータデ
ータ処理システムで使用されるデータ処理システム３４
２の好適な実施例を示す。中央処理装置（ＣＰＵ）５１
０はバス５１２を介して読出し専用メモリ（ＲＯＭ）５
１６、ランダムアクセスメモリ（ＲＡＭ）５１４、入出
力（Ｉ／Ｏ）アダプタ５１８、通信アダプタ５３４、ユ
ーザインタフエースアダプタ５２２及びデイスプレイア
ダプタ５３６に接続される。Ｉ／Ｏアダプタ５１８によ
り、データを記憶する不揮発性マス記憶装置５２０のよ
うな種々の入力／出力装置（例えば、直接アクセス記憶
装置（ＤＡＳＤ）、テープ、ホログラフ記憶装置、カー
トリツジ等）にバス５１２をインタフエースすることが
できる。通信アダプタ５３４により、バス５１２と組み
合わせてＣＰＵ５１０から通信ネツトワーク３４８への
データフローを形成することができる。表示アダプタ５
３６により、データ又は他の情報をデイスプレイ装置５
３８に表示することができる。ユーザインタフエースア
ダプタ５２２により、キーボード５２４、マウス又は指
示装置５３２、キーパツド５２６又はスピーカ５２８の
ような種々のユーザ（個人）入力／出力装置を制御する
ことができる。

【０５６６】このデータ処理システム３４２は上述した
ようにプロセス間通信を行い、さらに図３２に示すよう
な多重コンピユータデータ処理システムで使用すること
ができる。

【０５６７】上述のように本発明をその最適な実施例に
ついて図示、説明したが、本発明の精神及び範囲から脱
することなく形式及び詳細構成について種々の変更を加
えても良い。

【０５６８】

【発明の効果】上述のように本発明によれば、複数コン
ピユータデータ処理システムによつて単一のシステム意
味規則を作成し、このシステム意味規則を用いてローカ
ルデータプロセツサ及び遠隔データプロセツサの双方に
おける多重プロセツサを呼び出すようにすることによ
り、多数のホストコンピユータシステムを含む大規模な
ネツトワークシステムレベルの統合試験に必要な大規模
試験環境用のフレームワークを提供することができる。

【図面の簡単な説明】

【図１】図１は階層的試験環境のフレームワークを示す
略線図である。

【図２】図２は階層的試験環境のためのアーキテクチヤ
モデルを示すブロツク図である。

【図３】図３は直接アクセス記憶装置（ＤＡＳＤ）上に
記憶された試験用足場データ構造のトツプレベルのデイ
レクトリを示す略線図である。

【図４】図４は標準化した足場ツールを保持する tools
デイレクトリ構造を示す略線図である。

【図５】図５はユーザタスクコードを保持するtaskデイ
レクトリ構造を示す略線図である。

【図６】図６は特定のユーザタスクの下にあるデイレク
トリ構造を示す略線図である。

【図７】図７はシナリオデイレクトリの保持に使用する
runtimeデイレクトリ構造の略線図である。

【図８】図８はタスク情報の保持に使用するtaskデイレ
クトリの略線図である。

【図９】図９はタスク情報の保持に使用するtaskデイレ
クトリの略線図である。

【図１０】図１０は複数のシナリオインスタンスに対す
る結果を示す runtimeデイレクトリ構造の略線図であ
る。

【図１１】図１１は複数のタスクに対する結果を示すta
skデイレクトリ構造の略線図である。

【図１２】図１２は複数のタスクに対する結果を示すta
skデイレクトリ構造の略線図である。

【図１３】図１３は複数のタスクに対する結果を示すta
skデイレクトリ構造の略線図である。

【図１４】図１４は複数のタスクに対する結果を示すta
skデイレクトリ構造の略線図である。

【図１５】図１５はシナリオドライバへの入力のための
フアイルの作成に使用されるシナリオ構築ツールの略線
図である。

【図１６】図１６はシナリオ構築ツールに関するユーザ
対話パネルのサンプルを示す略線図である。

【図１７】図１７はタスク管理のためシナリオ構築ツー
ルによつて使用される対話パネルのサンプルを示す略線
図である。

【図１８】図１８はインスタンス付加のためシナリオ構
築ツールによつて使用される対話パネルのサンプルを示
す略線図である。

【図１９】図１９はシナリオドライバとの対話を示す略
線図である。

【図２０】図２０は試験用足場のトツプ階層レベルの環
境シナリオを示す略線図である。

【図２１】図２１は試験用足場の中間階層レベルの機械
シナリオを示す略線図である。

【図２２】図２２は試験用足場の、第２の中間レベルの
個人シナリオを示す略線図である。

【図２３】図２３は試験用足場の下層レベルのタスクシ
ナリオを示す略線図である。

【図２４】図２４はタスクドライバの動作の流れを示す
フローチヤートである。

【図２５】図２５はシナリオジヤーナルを作成するため
の、シナリオドライバの対話を示す略線図である。

【図２６】図２６は報告書を作成するための、シナリオ
ジヤーナルの対話を示す略線図である。

【図２７】図２７はシナリオジヤーナルフアイルのサン
プルを示す略線図である。

【図２８】図２８はタスクジヤーナルフアイルのサンプ
ルを示す略線図である。

【図２９】図２９は表３３に示す報告書を作成する際に
使用されるシナリオジヤーナルフアイルを示す略線図で
ある。

【図３０】図３０はpack(pk)コマンドに対する制御の流
れを示すフローチヤートである。

【図３１】図３１はunpack(unpk)コマンドに対する制御
の流れを示すフローチヤートである。

【図３２】図３２は複数コンピユータデータ処理システ
ムを示す略線図である。

【図３３】図３３は子プロセスを始動する制御の流れを
示すフローチヤートである。

【図３４】図３４はプロセスを登録する制御の流れを示
すフローチヤートである。

【図３５】図３５は多重プロセスデータ処理システム内
の２つのシステムの内部状態を示すブロツク図である。

【図３６】図３６は図３５に示す２つのシステムの内部
状態に関するクライアントプロセステーブルを示す図表
である。

【図３７】図３７は一般的なデータ処理用コンピユータ
のブロツク図である。

【符号の説明】

１０……シナリオドライバの対話アーキテクチヤモデ
ル、１２、２３０、２３２、２４０、２４４、２５０、
２５２、２６０……ドライバ、１６……タスクシナリ
オ、１８……個人シナリオ、２０……機械シナリオ、２
２……環境シナリオ、２６……タスクインスタンス、２
８……個人インスタンス、３０……機械インスタンス、
３２、２３４……環境インスタンス、５０……構成要素
の対話アーキテクチヤモデル、５２……シナリオ構築ツ
ール、５４……シナリオインスタンスフアイル、５６…
…シナリオ定義フアイル、５８……シナリオ、６０……
シナリオドライバ、６２……シナリオジヤーナル、６４
……報告書ジエネレータ、６６……報告書、６８……ユ
ーザタスクコード、７０、７４……アプリケーシヨンプ
ログラムインタフエース（ＡＰＩ）、７２……タスクジ
ヤーナル、３４２……データ処理システム、３４８……
ネツトワーク、５１０……中央処理装置（ＣＰＵ）、５
１４……ＲＡＭ、５１６……ＲＯＭ、５１８……Ｉ／Ｏ
アダプタ、５２０……非揮発性マス記憶装置、５２２…
…ユーザインタフエースアダプタ、５２４……キーボー
ド、５２６……キーパツド、５２８……スピーカ、５３
２……指示装置、５３４……通信アダプタ、５３６……
表示アダプタ、５３８……デイスプレイ装置。

【表３９】

───────────────────────────────────────────────────── フロントページの続き (72)発明者 クリストフア・シエーン・クラウゼン アメリカ合衆国、テキサス州78758、オー ステイン、＃2322、ウエルズ・ブランチ・ パークウエイ 1801番地 (72)発明者 ジエームズ・オテイス・コツクス アメリカ合衆国、テキサス州78750、オー ステイン、スプリツト・レール・パークウ エイ 12526番地

Claims (6)

【特許請求の範囲】
1. 【請求項１】複数コンピユータデータ処理システムにお
   ける多重プロセスを呼び出す方法において、 上記複数コンピユータデータ処理システムによつて単一
   のシステム意味規則を作成するステツプと、 上記単一のシステム意味規則を用いることによりローカ
   ルデータプロセツサ及び遠隔データプロセツサの双方に
   上記多重プロセスを呼び出すステツプとを含むことを特
   徴とするデータ処理方法。
2. 【請求項２】複数コンピユータデータ処理システムにお
   ける多重プロセスを管理する方法において、 コンピユータ上で実行するプロセスのために上記コンピ
   ユータの機械名を固有のプロセス識別コード（ＩＤ）と
   結び付けることにより複数コンピユータの固有のプロセ
   ス識別コード（ＩＤ）を作成するステツプと、 上記複数コンピユータの固有のプロセス識別コード（Ｉ
   Ｄ）を用いることにより上記複数コンピユータデータ処
   理システムにおける多重プロセスを制御するステツプと
   を含むことを特徴とするデータ処理方法。
3. 【請求項３】分散データ処理システムにおけるプロセス
   間通信に透過性を提供する方法において、 ローカルプロセツサにおいて、遠隔プロセツサ上に存在
   する遠隔プロセスの実行を初期化するステツプと、 上記遠隔プロセスを登録することによりアクセス情報を
   動的に提供するステツプとを含むことを特徴とするデー
   タ処理方法。
4. 【請求項４】複数コンピユータデータ処理システムにお
   ける多重プロセスを呼び出すシステムにおいて、 ローカルデータプロセツサと、 遠隔データプロセツサと、 単一のシステム意味規則を用いることによりローカルデ
   ータプロセツサ及び遠隔データプロセツサの双方におけ
   る上記多重プロセスを呼び出す手段とを具えることを特
   徴とするデータ処理システム。
5. 【請求項５】複数コンピユータデータ処理システムにお
   ける多重プロセスを管理するシステムにおいて、 コンピユータ上で実行するプロセスのために上記コンピ
   ユータの機械名を固有のプロセス識別コード（ＩＤ）と
   結び付けることにより複数コンピユータの固有のプロセ
   ス識別コード（ＩＤ）を作成する手段と、 上記複数コンピユータの固有のプロセス識別コード（Ｉ
   Ｄ）を用いることにより上記複数コンピユータデータ処
   理システムにおける多重プロセスを制御する手段とを具
   えることを特徴とするデータ処理システム。
6. 【請求項６】分散データ処理システムにおけるプロセス
   間通信に透過性を提供するシステムにおいて、 ローカルプロセツサにおいて、遠隔プロセツサ上に存在
   する遠隔プロセスの実行を初期化する手段と、 上記遠隔プロセスを登録することによりアクセス情報を
   動的に提供する手段とを具えることを特徴とするデータ
   処理システム。