JP2692775B2 - 試験環境を提供するシステム並びに試験ケースを駆動する方法及びシステム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はデータ処理システム及び
データ処理方法に関し、特に多重コンピュータネットワ
ークの機能を変更するためのシミュレーション及び試験
用のフレームワーク及び環境に適用して好適なものであ
る。

【０００２】

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

【０００３】

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

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

【０００５】多重コンピュータネットワークにおけるプ
ロセス間通信を支援するために、幾つかの技術ではプロ
セス名に基づくプロセスコンテキスト作成の概念を使用
する。このコンテキストがプロセス名に基づく遺伝(inh
eritance)プロセスを通じて得られるならば、このプロ
セスコンテキストはプロセス始動の順序に基づいて固定
されたものとなる。分散環境にプロセス全体の意味論(s
emantics)を拡張するか又は全体的に変化させる概念は
存在しない。

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

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

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

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

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

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

【００１２】

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

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

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

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

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

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

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

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

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

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

【００２２】

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

【００２３】図1は試験用フレームワークを示し、完全
な試験用足場を具体化したものを包含している。このフ
レームワークは多重試験シナリオレベル16、18、20及び
22のためのシナリオドライバ12を含む。また図2に示す
ように、シナリオ構築ツール52、報告書フイルタ64、標
準ジャーナルプログラミングインタフェース70及び74を
含む試験シナリオ開発のためのインタフェース定義並び
に完全なディレクトリ構造を含んでいる。この足場が制
御できる範囲は単一の試験プログラムからなる極めて小
さな試験シナリオから多数のホスト及び数千の試験プロ
グラムを包含する極めて大きくて複雑な試験シナリオに
及ぶ。この目的のために4つの異なる階層レベルをもつ
シナリオドライバを提供する。

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

【００２５】(アーキテクチャの概観) 用語、モデル及びシステム要求の3つの観点からアーキ
テクチャに関して詳細に説明する。用語の章は本明細書
を通じて用いる用語についての小辞典である。アーキテ
クチャのモデルは2つ存在し、モデルの章においては構
成要素について説明する。システム要求の章では現在の
アーキテクチャによって課される要求について詳述す
る。

【００２６】(1)用語 「アプリケーションプログラミングインタフェース(AP
I)」はアプリケーションに対するインタフェース又は機
能のセットである 「開始フック」はその下にある試験シナリオを実行する
前にシナリオドライバによって実行されるユーザコード
である。シナリオ実行ステージの間試験シナリオのカス
トマイズを支援することを意図するものである 「分散ファイルスペース」は複数のホストによって共用
されるディレクトリ構造である。ネットワークファイル
システムNFS(サン・マイクロシステム社の商標)はこの
概念の最も一般的なUNIXによる具体化である 「終了フック」はその下にある試験シナリオを実行した
後にシナリオドライバによって実行されるユーザコード
である。シナリオ実行ステージの間試験シナリオのカス
トマイズを支援することを意図するものである 「環境シナリオ」は試験シナリオレベルであり、関連す
る機械、個人及びタスクシナリオをネットワーク環境内
でまとめてグループ化する際に使用される 「環境シナリオドライバ」は自動化されたプログラムで
あり、環境シナリオの実行を制御する 「機械シナリオ」は試験シナリオレベルであり、関連す
る個人及びタスクシナリオを単一のホスト上でまとめて
グループ化する際に使用される 「機械シナリオドライバ」は自動化されたプログラムで
あり、機械シナリオの実行を制御する 「個人シナリオ」は試験シナリオレベルであり、関連す
るタスクシナリオをまとめてグループ化し、顧客をシミ
ュレートする際に使用する 「個人シナリオドライバ」は自動化したプログラムであ
り、個人シナリオの実行を制御する 「報告書フイルタ」はシナリオジャーナル及び又はタス
クジャーナルを読み取って読み易い報告書を作成するプ
ログラムに与えられる総称名である 「シナリオ構築ツール」はメニュー方式プログラムであ
り、シナリオ定義ファイル及びシナリオインスタンスフ
ァイルを管理できるようにする 「シナリオ定義ファイル」はユーザ定義属性と試験シナ
リオを定義するシナリオドライバ属性との双方を収容す
る。定義ファイルは各ユーザ定義属性の形式と、制限
と、デフォルト値と、記述とを表わすユーザ定義属性に
関するテンプレートデータ及びシナリオドライバ属性に
ついての実際のテンプレート値を収容する。定義ファイ
ルはシナリオインスタンスファイルを作成するためのテ
ンプレートを形成する 「シナリオ開発ステージ」はすべてのユーザタスクコー
ド及びシナリオ構成情報を開発しデバツグするステージ
である 「シナリオドライバ」は他の下位レベルシナリオドライ
バ又はユーザタスクコードの実行を駆動又は制御するプ
ログラムに与えられる総称的な用語である 「シナリオドライバ属性」は主要なシナリオドライバ構
成方式である。これらを使用してシナリオドライバの機
能を定義及び又は変更する 「シナリオ実行ステージ」はその中で試験シナリオを実
行するステージである 「シナリオインスタンスファイル」はシナリオドライバ
属性及び試験シナリオを定義するユーザ定義属性の双方
を収容する。シナリオインスタンスファイルはシナリオ
ドライバ属性及びユーザ定義属性の双方についての実際
の値を収容する 「シナリオジャーナル」は標準ジャーナルであり、これ
はシナリオ実行に関する高レベルデータを収容する 「タスク支援ファイル」はタスクを文書化するデータを
収容する 「タスクジャーナル」はユーザタスクコードによって利
用される標準ジャーナルである。試験シナリオで実行す
るタスクのすべてのインスタンスについて1つのタスク
ジャーナルが存在する 「タスクシナリオ」はユーザコードからなる試験シナリ
オレベルである。これは試験ケースの等価物と考えるこ
とができる 「タスクシナリオドライバ」は自動化されたプログラム
であり、タスクシナリオの実行を制御する 「タスク設定コード」はユーザコードであり、シナリオ
実行ステージの間試験原始コードをコンパイルする際に
使用される 「試験シナリオ」は試験の選択されたグループ化に与え
られる総称名である 「ユーザ定義属性」はユーザタスクコードにデータを運
ぶ際に使用される変数である 「ユーザタスクコード」は試験目的のためのタスクシナ
リオ開発者によって書き込まれるコードであり、通常試
験ケースと呼ばれるものと同義である。

【００２７】(2)モデル 本発明の主要構成要素のアーキテクチャレベルでのすべ
ての対話を記述するために、以下に示す2つのモデル(A)
及び(B)を使用する。第1のモデルは各シナリオドライバ
の対話、シナリオドライバが実行するオブジェクト及び
試験シナリオに対するシナリオドライバの関係を記述す
る。第2のモデルは本発明を構成する構成要素同士の対
話を記述する。

【００２８】(A)シナリオドライバ対話アーキテクチャ
モデル 図1に示すように、シナリオドライバ対話アーキテクチ
ャモデル10は各シナリオドライバ12の対話、シナリオド
ライバが符号14において実行するオブジェクト及び試験
シナリオに対するシナリオドライバの関係を記述する。
このモデルの構成要素の外郭を略記した長方形16、18、
20及び22は試験シナリオを表し、ディスクアイコンはデ
ータ記憶場所72、26、28、30及び32を表し、ブロック12
はプログラムを表し、陰影を付した四角のブロック68は
シナリオ開発者によって開発されるコードを表す。この
モデルは試験シナリオ16、18、20及び22並びにこれらに
対応するシナリオドライバ12の間の関係を示す。定義さ
れた試験シナリオはいずれも、その実行を制御する1つ
のシナリオドライバ12及びその特定の試験シナリオを定
義するのに必要な構成情報を提供する1つのシナリオイ
ンスタンスファイル(例えば26、28、30及び32)を有す
る。シナリオドライバ対話アーキテクチャモデル10は、
タスクシナリオレベル16を介して環境シナリオレベル22
から受け取る各試験シナリオレベルにおいてはシナリオ
ドライバ要素12は同じであるが、シナリオインスタンス
ファイルは異なることを示している。好適な実施例に
は、各シナリオドライバと関連付けた1つのシナリオイ
ンスタンスファイルが存在し、1つのシナリオドライバ
要素が存在するが、その動作はシナリオインスタンスフ
ァイルの内容に極めて大きく左右される。このモデルが
示すように、他のシナリオドライバを制御するシナリオ
ドライバはこれらのドライバを同時に1つ又は2つ以上制
御することができる。これは階層的試験環境を実現さ
せ、これにより、他の試験シナリオからなる試験シナリ
オを定義することができる。ユーザタスクコードを実行
するタスクシナリオドライバはユーザタスクコードの一
片だけを制御する。従って試験シナリオで実行されるユ
ーザタスクコードの個々の各構成要素には単一のタスク
シナリオドライバが存在する。このモデルから認識すべ
き最も重要な事項の1つは、シナリオドライバ12はユー
ザコードのただ一片の実行を制御する以上のことを行う
ということである。このような機能に加えて、シナリオ
ドライバ12はネットワーク化した環境内のホストのセッ
ト全体を制御する能力をも有する。また機械シナリオド
ライバによって複数の個人シナリオドライバを実行する
ことができるので、シナリオドライバは1つのホスト上
で実行している複数の人々をエミュレートする機能をも
有する。これらの各個人ドライバは一組のタスクシナリ
オドライバを実行する能力を有し、次に個人ドライバは
シナリオ開発者の試験コードを実際に実行する。この階
層的モデルは凝集性ネットワーク環境における実個人エ
ミュレーションと非並行柔軟性とを実現し、すべてを1
つの環境シナリオドライバから中央制御して自動化す
る。

【００２９】(B)構成要素対話アーキテクチャモデル 図2は構成要素対話アーキテクチャモデル50を示し、本
発明のすべての主要なアーキテクチャ構成要素の対話を
示す。ディスクアイコン54、56及び62はデータ記憶場所
を表し、ブロック52、58、60及び64はプログラムを表
す。陰影を付したプログラムブロック68はシナリオ開発
者が開発したユーザコードを表す。このモデルは、シナ
リオ定義ファイル56及びシナリオインスタンスファイル
54の主要な対話がシナリオ構築ツール52を通じて遂行さ
れることを示している。シナリオ構築ツール52を用いて
シナリオ定義及びインスタンスを管理し、シナリオ開発
者を用いてシナリオ構築ツール52にアクセスする。シナ
リオ定義ファイル56はシナリオについての構成情報を定
義し、シナリオインスタンスファイル54を作成するテン
プレートとして使用される。シナリオインスタンスファ
イル54はシナリオドライバの入力であり、シナリオ実行
ステージの間シナリオドライバ構成情報を供給する。シ
ナリオドライバ58はその入力としてインスタンスデータ
を読み取り、シナリオドライバ60及び又はユーザコード
68の他のセットを実行する。各シナリオドライバレベル
間にはインタフェースが存在し(図1の符号14)、またシ
ナリオドライバ及びユーザコード間にもインタフェース
が存在する(図2の符号70)。これらのインタフェースは
シナリオドライバ及び実行できるオブジェクトの組み合
わせによって変わる。シナリオドライバによって実行さ
れるシナリオドライバをモデルの上辺に単一プログラム
として示す。しかしながらシナリオドライバは同時に複
数のシナリオドライバを実行することができる。次にこ
れらの各シナリオドライバは主シナリオドライバプログ
ラムが配置されているこのモデルの中央部に入る。主シ
ナリオドライバプログラムはこれらを実行したシナリオ
ドライバと同一の考え得る対話のセットを有する。いず
れかのシナリオドライバからのジャーナルへの記入はシ
ナリオジャーナルドライバプログラミングインタフェー
ス78を経由してシナリオジャーナルに対してなされる。
好適な実施例において、同じシナリオ内で実行する機械
上のすべてのシナリオドライバは同じシナリオジャーナ
ル62に記入する。試験用足場の各ユーザコード構成要素
はこのモデル内の単一のユーザコードプログラムボック
ス68にグループ化される。ユーザコードはタスクジャー
ナル72に記録を記入し、開始フック及び終了フックユー
ザコードの実行はシナリオジャーナル62に記入する。同
じシナリオ内で実行しているユーザタスクコードの各イ
ンスタンスは自身の固有のタスクジャーナルに記入す
る。シナリオジャーナル62及びタスクジャーナル72のフ
オーマツトは首尾一貫しているので、報告書フイルタ64
はジャーナルを読んで、明瞭な報告書66を作成すること
ができる。

【００３０】(3)システム要求 上述のアーキテクチャ及びデザインによって課される一
組のアーキテクチャ要求を以下に示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４６】ここでIPCライブラリ関数について概略的
に説明する。分散されたIPC層へのアクセスはIPCライブ
ラリ関数(ipclib.a)を経由してアクセスされる。これら
の関数はコミュニケーション348にアクセスするための
ユーザレベルAPI346(図32)を提供し、サーバによって提
供される機能に役に立つ。

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

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

【００４９】ここで登録及び終了について説明する。 register client(int handle) これは正規の登録コマンドであり、プロセスが始動する
とこれをローカル制御デーモン(サーバ)に登録してIPC
通信チャネルに加わらなければならない。このコマンド
の送出はハンドルの値に基づいて異なる結果を発生させ
ることがある。

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

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

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

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

【００５４】これ以外の2つの状況も考えられる。 (1)ハンドルが無効である。この場合プロセスはサーバ
によって採用され新しいハンドルが戻される。 (2)ハンドルが既に使用されている。この場合、受け渡
されるハンドルは親ハンドルであると解釈され、子は受
け渡されるハンドルの子として登録され、新しいハンド
ルが戻される。 xx terminate(int handle, int rc) プロセスが出る前にこの終了(terminate )を使用する。
終了するプロセスのハンドル及び親に戻されるべきリタ
ーンコードがパラメータとして使用される。終了コマン
ドの意図はリターンコードが親プロセスに戻れるように
することである。子が死んだとの通知を親が確実に受け
取るようにするため、終了プロセスは信号に従うことを
妨害する。サーバは、親メッセージキューにメッセージ
をエンキューすることによって親プロセスに通知し、メ
ッセージがペンディングであることを信号で親に知らせ
る。親信号ハンドラーはこの信号を捕捉してメッセージ
を入手し、親子データテーブルを更新して release ch
ild コマンドを送出する。このコマンドを使用すること
により、サーバは終了プロセスのためのクライアントテ
ーブルエントリを一掃し、SIGUSR2 信号を子に送る。

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

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

【００５７】(標本プロセスの流れ) 図35及び図36は標本プロセスの流れ及びその結果として
の状態を示す。図35はサーバ及びクライアントプロセス
間に存在する相互関係を示す。図35は分散形通信機能を
用いて幾つかのプロセスを始動させた後のシステム状態
のスナップショットを示す。符号430のシステム1及び符
号450のシステム2はその上で走っているサーバのインス
タンスを有する。システム1(S1)に関わるサーバは符号4
32で示し、システム2(S2)に関わるサーバは符号452で示
す。下記のシナリオに従うことにより図35に示すシステ
ム状態に到達する。 システム1(S1)におけるシナリオ (0)サーバはクライアントテーブルを初期化し、それ自
身をハンドル「0」として加算する (1)プロセス101がS1上で始動した(434) (2)プロセス101が登録する (3)プロセス101がプロセス102を始動させる(438) (4)プロセス102が登録する (5)プロセス102がプロセス103を始動させる(440) (6)プロセス103がプロセス104を始動させる(442) (7)プロセス104が登録する システム2(S2)におけるシナリオ (0)サーバはクライアントテーブルを初期化し、それ自
身をハンドル「0」として加算する (1)プロセス201がS2の上で始動した (2)プロセス201が登録する (3)プロセス201がプロセス202を始動させる(456) (4)プロセス202が登録する (5)プロセス202がS1上でプロセスを始動させる (6)S2サーバはプロセスを始動させるようにS1サーバに
要求する (7)S1がプロセス105を始動させる(436) (8)プロセス105が登録する。

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

【００５９】S1すなわち符号430上にあるサーバ432用の
クライアントプロセステーブルを図36の460に示す。ハ
ンドル「0」はサーバデーモンプロセス(図35の432)のた
めに使用するものであったが、このサーバのための情報
をクライアントプロセステーブル460の行462に示す。こ
こで、サーバ432は登録済であり、現在のプロセスハン
ドルとして「0」を有し、(親が無いため)親プロセスハ
ンドルは「0」、(遠隔プロセスによって初期化されてい
ないため)遠隔プロセスハンドルは「0」、プロセスIDは
「23」、(親が無いため)親プロセスIDは「0」、このプ
ロセスを走らせているシステム名はS1、(サーバプロセ
スなので)親が走っているシステム名はS1、(環境が定義
されていないため)環境へのポインタは「0」であること
が判る。環境又はメッセージキューに値が定義されてい
た場合、このフィールドは現在のメッセージキューの頭
へのポインタ、メッセージキューへのポインタ及び時刻
表示を格納する。

【００６０】図36のクライアントプロセステーブル460
のハンドル1(符号464)を参照してみると、この登録エン
トリはプロセス101(図35の434)に関するものであること
が判る。関連するPIDの列を調べればこれを確認するこ
とができる。このテーブルから判るこれ以外のプロセス
101についての興味深い情報は、親プロセスのハンドル
(Phand)は「0」、親プロセスのID(PPID)は「23」、この
両者がサーバプロセス432に関連していることである。
行466(図35のプロセス102に関する)及び行468(図35のプ
ロセス104に関する)の情報は同じPhand情報及びPPID情
報に基づいて同様の形式の親プロセス関係を示す。

【００６１】S1サーバに関するクライアントプロセステ
ーブル460の最後のエントリを分析する前にまずS2サー
バに関するクライアントプロセステーブル480を見る。
(図35の)S2サーバ452はS1サーバが行462に有するエント
リと類似のエントリを行472に有することが判る。これ
ら両者の間の違いは、この場合にはプロセスID(PID)が
「99」であり、システム名がS2であることである。

【００６２】エントリ474及びエントリ476はシステム2
上のローカルプロセスを示し、システム1に関して既述
したテーブルエントリと類似している。エントリ478は
遠隔プロセスを記述しているエントリである。ハンドル
は「3」となっており、これが指示しているハンドルに
よってプロセスがこのサーバに知られる。親ハンドルは
「2」となっており、これは論理親であるS2上のプロセ
ス202(図31の456)を示す。遠隔ハンドルは「4」であ
り、これは遠隔システム上のこのプロセスを記述してい
るハンドルを示す。プロセスIDは「105 」であり、これ
はS1クライアントプロセステーブル460の行470に示した
プロセスIDと同じである。親プロセスIDは202である。
プロセスホストはS1であり、これが遠隔プロセスである
ことを示す。親ホスト又は親プロセスのホストはS2であ
る。S2はプロセス202についてのプロセスホストであ
る。

【００６３】図36のサーバS1についてのクライアントプ
ロセステーブル460の行470を参照すると、ハンドルが
「4」のプロセスはプロセスID105(図35の項目436)に対
応することが判る。このプロセス105に関して、親プロ
セスハンドルは「0」(サーバプロセスを示している)、
遠隔プロセスハンドルは「3」(このプロセスはハンドル
「3」の遠隔プロセスと同じであることを示している)、
親プロセスIDは「23」(これはローカルサーバであり、
すべてのプロセスはこのローカルサーバを通じて遠隔機
械フアンネルから始動される)、ローカルシステム名はS
1、親が走っているシステムはS2(すなわち、これは遠隔
プロセスから始動された)であることが判る。言い換え
れば、行470に示される情報はプロセス105にアクセス/
管理するときにS1サーバ432によって使用され、この同
じプロセス105に使用される情報は行478に格納され、こ
うしたプロセスにアクセス/管理するときにS2サーバ452
によって使用される。このように、単一のシステム意味
論は分散環境のプロセスにアクセスするローカルシステ
ム及び遠隔システムの双方によって使用される。

【００６４】ここまでホスト間通信機構について説明し
てきたが、再びこの試験環境内部の説明に戻る。環境変
数について説明する。ライブラリは分散環境内に環境変
数を有するための能力を与える。これらの変数は分散環
境によって見られるように親子関係に保持される。この
機能は、変更がなされたレベルよりも下のすべてのレベ
ルにおいて見られる試験環境内のレベルにおける環境変
数を変更できるようにする。環境変数機能へのアクセス
は次の通りである。 xx putenv(name, value, handle) このルーチンはローカルサーバ上のハンドルが指示する
クライアントのための環境を更新する。 xx getenv(name,handle) このルーチンは受け渡される環境変数名に関連する値を
保持している文字ポインタを戻す。getenv関数はハンド
ルが指示する環境を見て情報を得る。それが見つからな
ければ、そのファミリツリーに従って、環境変数を探し
ているサーバレベルに戻る。環境変数が見つからなけれ
ば、この関数はNULLを戻す。

【００６５】ここで注意することは、プロセスが遠隔の
親の子であるとき、子が変数名の解明に失敗すれば遠く
から探索を継続することである。getenv要求を伴うサー
バはこの要求を遠隔の親ホストに送り、遠隔ホスト上の
環境ツリーを歩くことを終了する。 xx freenv(name,handle) このルーチンはローカルホスト上のハンドルが示すクラ
イアントについての名前によって指示される環境変数を
削除する。

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

【００６７】

【表１】 struct child＿data /* 子データ追跡構造 */ ｛ short handle； char status； char plug； int rc； pid＿t pid； pid＿t fpid； ｝； 。

【００６８】ここで表中に現れる英文字の列は記号であ
って、翻訳できない(以下の表においても同様である)。

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

【００７０】表2はフィールドの説明である。

【００７１】

【表２】 フィールドの説明 handle - 子ハンドル status - 現在の子プロセス状態 s＿PEND - クライアントエントリに未決とマーク s＿VALID - クライアントエントリに有効とマーク（走行中） s＿TERM - クライアントに終了とマーク（有効退出） s＿SIGD - クライアントは子が死んだ信号を受取った（無効退出） s＿DONE - 子の処理は完了（有効退出） rc - 有効退出の場合の、子プロセスからの復帰コード pid - 登録した子プロセスのプロセスidであって、これは、正規の 動作において子と通信し子が終了したときに通知するために使 用するプロセスidである fpid - 分岐プロセスidのプロセスであって、これを通じて子を呼出 す。サーバに登録する前にプロセスが退出する場合および子プ ロセスが異常終了する場合にこの情報を保持し、子の死は、死 に行くプロセスとしてこのプロセスidを生じ、これを用いて 子プロセスをクリーンアップする。

【００７２】関数について説明する。reserve slot(ha
ndle)。親プロセスはこの reserve slotルーチンを使
用して、サーバで始動させられる子のクライアントスロ
ツトを予約する。親のハンドルを用いて reserve slot
関数は呼び出される。この関数からのリターンには子の
ための新しいハンドルが使用されるreserve slotルー
チンはプロセス始動ルーチンによって呼び出され、通常
はユーザプログラムによって使用されることはない。ま
た reserve slotルーチンは、呼出されたときに child
dataレコードを親の中に設定し、このレコードはドラ
イバ子データとサーバクライアント情報とを関連付ける
ために使用されるstart process(hostname,command,ha
ndle)。このプロセス始動コマンドを使用してすべての
子プロセスを始動させなければならない。 start proc
ess コマンドは次の3つのパラメータを有する。 (1) hostname−子プロセスの実行を希望するホスト名を
指示する (2) command −子プロセスの始動を実行すべくパラメー
タを伴うコマンドを与える (3) handle−これは親プロセスハンドルである。

【００７３】図33に示すように、ブロック350において
start process コマンドを出すと、以下に示す(1)〜
(7)又は(1)〜(9)のシーケンスが生ずる。 (1)ブロック352においてホスト名を検査し、ローカルホ
スト上でのプロセス始動を望むか又は遠隔ホスト上での
プロセス始動を望むかを決定する。プロセスがローカル
ホスト上で走ると判定されると、以下の(2)〜(7)のシー
ケンスが生ずる。 (2)ブロック354において reserve slotを呼び出して子
ハンドルを得る。 (3)ブロック356においてローカルプロセスを始動し、ブ
ロック358において子レコードを作成する。 (4)ブロック360においてputenvを用いて新しいハンドル
をシェル環境に入れる。 (5)ブロック362において新しいプロセスを分岐させ、プ
ロセスIDを入手する。 (6)ブロック363において start process に渡されたコ
マンドを実行する。 (7)ブロック364において親の child dataテーブルをハ
ンドル及び分岐プロセスIDで更新し、ブロック366にお
いてペンディング状態にする。ブロック363において子
が始動すると、これをサーバに登録し(上記を参照)、ch
ild dataテーブルエントリは有効状態となる。

【００７４】ブロック352においてプロセスが遠隔ホス
ト上で走ると判定されると、以下の(2)〜(9)のシーケン
スが生ずる。 (2)ブロック370においてremote command 関数を呼び出
し、遠隔プロセス始動の要求をサーバに送る。 (3)ブロック372においてローカルサーバは遠隔プロセス
に関するクライアントレコードを構築し、ブロック374
においてコマンドパケットをホスト名によって指示され
るサーバに送る。 (4)ブロック376において遠隔ホストはコマンドパケット
を受け取り、サーバ上で遠隔実行関数を処理する。 (5)ブロック378において遠隔ホストはプロセスのクライ
アントテーブル内にスロツトを作成する。 (6)ブロック378においてputenvを使用して新しいハンド
ルをシェル環境に置く。 (7)ブロック380において新しいプロセスを分岐させ、プ
ロセスIDを入手する。 (8)ブロック381においてコマンドパケットに渡されるコ
マンドを実行する。 (9)ブロック382においてクライアントデータテーブル内
の親のPIDスロツトに分岐プロセスIDを格納し、ブロッ
ク384においてテーブルエントリをペンディング状態に
変更する。

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

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

【００７７】(未定の遠隔プロセスの登録) 遠隔機械上で実行されたプロセスは登録する。これが生
じたとき、遠隔サーバ上のクライアントレコードは実際
の登録しているプロセスのPIDを反映するよう更新さ
れ、クライアントレコードの状態が有効になる。次に遠
隔サーバは、子が始動した親ホストサーバにコマンドパ
ケットを送る。親ホスト上のサーバは、子が始動したと
のメッセージをエンキューし、親プロセスに信号を送
る。この信号は信号ハンドラによって捕捉され、有効状
態の親のために child dataレコードが作成される。こ
の時、ローカルの場合又は遠隔の場合のいずれであって
も、 start process コマンドは、始動した子のハンド
ルを戻す。このハンドルは常に、そのプロセスのローカ
ルサーバビューに関連するハンドルになる。ここで図34
を参照する。上の記述は多重コンピュータ複合体の複数
のプロセッサにプロセッサ間通信サポートを提供する。

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

【００７９】(トップレベルディレクトリ構造) 図3を参照してディレクトリ構造の好適な実施例につい
て説明する。当業者は、ここに説明するものと同様の階
層的構造を、違う構造を用いて実施することができるこ
とを理解する。デフォルトによって、試験用足場のため
の親レベルディレクトリ構造は /austin80である。 /au
stinディレクトリに5つのディレクトリ構造が配置され
る。これらの構造の名は、 /austin/.def 82、 /austin
/.inst84、 /austin/tools86、/austin/tasks88及び /a
ustin/runtime90である。以下に述べるように、デフォ
ルトロケーション及び又はこれらのディレクトリのうち
のどれかの名前を変更することができる。次に、これら
5つのディレクトリ構造をどのように使用するかについ
て説明する。

【００８０】(1) .defディレクトリ この定義ディレクトリ82はシナリオ定義ファイルを格納
する。定義ディレクトリに関するデフォルトロケーショ
ンは /austin/.def である。 (2) .inst ディレクトリ このインスタンスディレクトリ84はシナリオを記述する
ファイルであるシナリオインスタンスファイルを格納す
る。インスタンスディレクトリに関するデフォルトロケ
ーションは /austin/.instである。 (3) tools ディレクトリ このツールディレクトリ86はすべての標準化された足場
ツールとシナリオ実行に必要な他の何らかのツールとの
リポジトリである。この構造は /austin/toolsという名
前で表される。図4に示すように、この /austin/tools
ディレクトリ86には次のような5つのディレクトリが存
在する。これらは、ソースコードのための src92、エク
ゼキュータブルズ(executables )及びシェルスクリプト
のための*bin94、データファイルのための dat98、文書
のための doc100及びライブラリのための*lib96であ
る。 /austin/toolsディレクトリは導入時に設置され、
めったに変化しない。タスクコードに必要な一切のツー
ルを標準化し、このディレクトリ構造に配置することが
できる。*bin及び*libの表示を使用して複数のbin ディ
レクトリ及び複数のlib ディレクトリを表現する。
「＊」の代わりに一組の文字を用いて、ディレクトリに
どのような形式のエクゼキュータブルズ又はライブラリ
が有るかを表示する。例えば現在、tools ディレクトリ
構造はrsbin 及びrslib と名付けられた2つのディレク
トリを有し、ここに、RISCシステム/6000(IBM社のRISC
ベースのコンピュータシステム)エクゼキュータブルズ
及びライブラリが配置されている。試験用足場がSUN Sp
arcStation上でコンパイルされるとき、SUN エクゼキュ
ータブルズ及びライブラリ用に他の2つのディレクトリ
すなわちsunbin及びsunlibを使用することができる。複
数のバイナリ及びライブラリディレクトリを有すること
の利点は、ネットワーク内の単一のホストからエクゼキ
ュータブルズ及びライブラリを扱うことができ、また情
報を備えているクライアントがこれらのローカル環境変
数又はPATH環境変数を設定することができるので、これ
らがクライアントのオペレーティングシステム及びハー
ドウェアプラットフォームに基づいて適切なディレクト
リにアクセスすることができることである。 (4) tasks ディレクトリ構造 タスクディレクトリ88は図5に示すように、すべてのシ
ナリオ開発者のユーザコード(タスク)用のリポジトリで
ある。好適な実施例においては、 /austin/tasksディレ
クトリに26個のディレクトリ102を見つけることができ
る。これらのディレクトリ102には「a」から「z」まで
の名前が付されており、タスクのそれぞれの名前の最初
の文字によってタスクを区分する。タスクは、タスクの
名前の第1の文字と同一の文字ディレクトリ102の下にあ
るタスクディレクトリ構造にそれ自身の個別のディレク
トリ104を持たなければならない。ここで、mtask1、mta
sk2及びmtask3と名付けた個別のディレクトリ104を有す
るタスクmを示す。タスクが作成するディレクトリはそ
の名前と同一でなければならない。タスクを組立てるフ
ァイル106はタスク名ディレクトリ内の以下に示すよう
な4つのディレクトリに区分される。すなわちこれらの
ディレクトリは、ソースコードに関する src104、実行
可能なモジュール及びシェルスクリプトに関する*bin10
8、データファイルに関する dat110並びに文書に関する
doc112である。タスクディレクトリ構造全体がタスク
開発ステージを通じて頻繁に変化する。しかしながらタ
スクシナリオドライバは、シナリオ実行ステージの間、
全く異なるディレクトリ構造に書き込むことを許すイン
タフェースを提供するので、タスクディレクトリ構造に
書き込むことは全く必要ない。このことは、シナリオ実
行ステージの間に生じがちなタスク構造の破壊の回避に
役に立つ。シナリオ実行ステージの間にタスクディレク
トリに待機が生じないことを一段と確実にするため、そ
の許可を変更することによってディレクトリ構造を読出
し専用にすることができる。すなわち、シナリオが分散
環境で実行されている場合、タスクディレクトリ構造を
環境サーバからの読出し専用にしてよい。注意すべき
は、シナリオドライバはシナリオ実行ステージの間、こ
のタスクディレクトリ構造が読出し専用であることを明
示的に保証するものではないということである。以下に
その例を示す。図6に示すようにディレクトリ /austin/
tasks/r122にはrcp の名をもつタスク120を見い出すこ
とができ、ディレクトリ /austin/tasks/f126には floa
tの名をもつタスク122及び ftp124を見い出すことがで
きる。タスク構造104のすべてのタスクは適切な文字デ
ィレクトリ102の下にあるディレクトリ名となる。例え
ば、 rcpの名をもつタスクに対しては /austin/tasks/r
/rcpと名付けられたディレクトリ120があり、これは、
rcpタスクに関するすべての情報106を格納している。こ
のディレクトリをAUSCODEDIRディレクトリ(後に説明す
る)と呼ぶ。 (5) runtimeディレクトリ構造 図7に示す実行時ディレクトリ構造90はシナリオ実行ス
テージの間に広範囲に使用される。トップレベルのシナ
リオドライバが実行を開始するとき、 /austin/runtime
ディレクトリ90にディレクトリ130を作成する。ディレ
クトリ130はシナリオインスタンスの名前132、それに続
く日付134及び時間136から構成される。このディレクト
リ130をシナリオディレクトリと呼び、その全ツリーを
シナリオディレクトリ構造と呼ぶ。時刻表示をしたシナ
リオディレクトリは、(システム資源に制約がなければ)
n個のシナリオ実行からシナリオデータを擁護すること
を保証する。シナリオディレクトリ130には、pass140、
working142及びfail144の名前をもつ3つのディレクト
リ138及びscen.journal.<hostname> (すなわちシナリオ
内の機械あたりの1つのジャーナルファイル)の名前をも
つファイル146が存在する。workingディレクトリ142は
すべての実行時タスクアクティビティが生ずるところで
ある。タスクの完了に続いて、タスクに関連するファイ
ルが workingディレクトリ142からpassディレクトリ140
又はfailディレクトリ144のいずれかに移る。そのどち
らに移るかは、以下に説明するように、構成保管属性及
びこれらの成功率に左右される。ファイルscen.journa
l.<hostname> 146はシナリオジャーナル情報が記録され
る場所である。このディレクトリ構造138は後述するよ
うに、シナリオ実行時にトップレベルシナリオドライバ
によって作成される。

【００８１】(runtime taskディレクトリ構造) 図8に示すように、タスクが根ユーザとして走っている
場合には、タスクシナリオドライバが実行する時に、タ
スクシナリオドライバはシナリオディレクトリの worki
ngディレクトリ142に固有のディレクトリ150を作成す
る。図9に示すように、タスクが根ユーザではないユー
ザとして走っている場合、ユーザのホームディレクトリ
154(環境変数HOMEによって示す)に固有のタスクディレ
クトリ構造152が作成される。このディレクトリ150又は
152をタスクディレクトリと呼び、そのそれぞれのディ
レクトリツリー156又は158を実行時タスクディレクトリ
構造(上述のタスクディレクトリ構造と混同してはなら
ない)と呼ぶ。タスクインスタンスの名前158、タスクが
その上で実行しているホストの名前160、タスクのプロ
セス識別番号(PID)162及びタスクの反復164を組み合わ
せることによって固有のタスクディレクトリ名が作成さ
れる。

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

【００８３】固有のタスクディレクトリの下に、3つの
ディレクトリをもつディレクトリ156がある。すなわ
ち、 binディレクトリ166、workディレクトリ168及びjo
urディレクトリ170である。 binディレクトリ166は、後
に説明するようにコンパイルされたエクゼキュータブル
ズを出力するタスク準備コードが使用するために作成さ
れる。workディレクトリ168は、ユーザのコードが実行
を開始するときにユーザが配置される場所である。ユー
ザは、是認されている場合以外は、workディレクトリか
ら出ているディレクトリを変更してはならない。jourデ
ィレクトリ170は、標準タスクジャーナル(task.journa
l)172が配置される場所(図1の72)であるばかりでなく、
後述するようにタスクシナリオドライバが ausjournals
構成属性を用いてすべてのジャーナルを作成する場所で
ある。

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

【００８５】(複数の runtimeシナリオディレクトリ構
造) 図10において、2つの異なるシナリオ180及び182は実行
したか又は実行している。これらのシナリオはエンジニ
アリング環境シナリオに関する同じシナリオ定義ファイ
ルから発信されるが、シナリオインスタンスファイルは
異なる。上述したようにこのことは、ディレクトリ名の
最初のフィールドが同じであり同一のシナリオ定義を示
しているが、第3のフィールドは違っていて異なるイン
スタンスを示している(engineering.e.1 対engineerin
g.e.2 )ことから明らかである。ディレクトリ名から、
シナリオengineering.e.1 は1991年3月11日の午前11時5
分に開始し(日付・時刻表示が910311.110500である)、
第2のシナリオは1991年3月12日の午前11時5分に開始し
た(日付・時刻表示が910312.110500である)ということ
も判る。従って、これらのシナリオは正確に24時間離れ
て実行を開始したものである。

【００８６】これら2つのディレクトリ構造180及び182
を使用している2つのシナリオが共に終了するとき、こ
れらの構造は実行時ファイルスペース90に残る。シナリ
オドライバはタスクシナリオクリーンアップ(後述する)
にオプションを提供するが、シナリオドライバ構造を自
動的に取り去ることはしない。

【００８７】次に図10の環境シナリオ180 (engineerin
g.e.1 910311.110500 )で実行しているタスクディレク
トリ構造に見い出される幾つかのタスクの実行について
説明する。

【００８８】(シナリオディレクトリworking ディレク
トリ構造) 図11を見ると、 engineering環境シナリオ130で3つのタ
スク184、186及び188が実行していることが判る。上述
したしように実行中のタスクは、タスクが根ユーザとし
て実行する場合常にシナリオディレクトリ内の working
と名付けられたディレクトリの下に配置され、そうでな
ければ、ユーザの＄HOMEディレクトリにディレクトリを
もつことになる。これについては後述する。図11の eng
ineeringシナリオは、固有のタスクディレクトリ名に異
なるホスト名を含んでいるだけではなく実行時ディレク
トリに複数のシナリオジャーナルファイルを含んでいる
ので、分散形実行時ファイルスペースを用いて実行して
いることが判る。シナリオが分散されていなかった場
合、タスクディレクトリは同じホスト名を含む。図示し
た例において、2つのタスクすなわちタスク184及びタス
ク186はホストclaussen上で実行しており、1つのタスク
すなわちタスク188はホストthelake 上で実行してい
る。

【００８９】(標本実行時 pass/failディレクトリ構造) 上述した固有のタスクディレクトリの実行後ロケーショ
ンを図12に示す。図12から幾つかの項目を推論すること
ができる。第1に、前に実行していた2つのタスク(符号1
84のrcp.t.1.claussen.999.1及び符号186のrcp.t.2.cla
ussen.888.1)が渡され、1つ(fp.t.2.thelake.1122.1 )
は失敗した。第2に、シナリオドライバ属性aussave は
タスク rcp.t.1(184)及びタスク rcp.t.2(186)に対して
は値 all又はpassを有し、タスク ftp.t.1(188)に対し
ては値 all又はfailを有した。図12から判る第3の事柄
は、シナリオドライバ属性auscompress オプションがタ
スクrcp.t.1(184)に関してはpass又はall にセットさ
れ、タスク rcp.t.2(186)に関してはnone又はfailにセ
ットされ、 ftp.t.1(188)に関してはnone又はpassにセ
ットされたことである。シナリオドライバ属性の保管及
び圧縮に関するこれ以上の情報は下記を参照されたい。

【００９０】ディレクトリ構造環境変数について説明す
る。再度図3を参照する。親ディレクトリ構造 /austin8
0及びその下にある各5つのディレクトリ構造をすべて、
異なるロケーションに移動させること及び又は必要が有
れば名前を付けなおすことができる。これらの移動及び
又は再度の命名をさせると、6つの環境変数を準備して
ディレクトリ構造の新しいロケーションにセットする必
要がある。環境変数は次の通りである。 (1)「AUSROOT」。値は /austinディレクトリ80の新しい
ロケーションである。 (2)「AUSDEF」。値は /austin/.defディレクトリ82の
新しいロケーションである。 (3)「AUSINST」。値は /austin/.instディレクトリ84の
新しいロケーションである。 (4)「AUSTOOLS」。値は /austin/toolsディレクトリ86
の新しいロケーションである。 (5)「AUSTASKS」。値は /austin/tasksディレクトリ88
の新しいロケーションである。 (6)「AUSRUNTIME」。値は /austin/runtimeディレクト
リ90の新しいロケーションである。デフォルトロケーシ
ョンを使用すると、環境変数をセットする必要はない。

【００９１】シナリオドライバ及びシナリオ構築ツール
を使用することにより /austinディレクトリの下の5つ
のディレクトリ構造のロケーションを決定する手続きは
次の通りである。 (1)検査をしてその構造のための環境変数が定義されて
いるか否かを知る。定義されていれば、それはディレク
トリ構造の値である。定義されていなければ(2)に進
む。 (2)検査をして環境変数AUSROOTが定義されているか否か
を知る。定義されていれば、AUSROOT環境変数によって
指定されるディレクトリの末尾に適切なデフォルトディ
レクトリ名を追加するが、これはディレクトリ構造の値
である。AUSROOTが定義されていなければ(3)に進む。 (3)探索されているディレクトリ構造の値はデフォルト
である。

【００９２】上述のことは、次のようなことを意味して
いる。シナリオ構築ツールがインスタンスを探索してい
るとき、最初に、AUSINST環境変数が定義されているか
否かを知るための検査をする。AUSINSTが定義されてい
ればシナリオ構築ツールはインスタンスファイルが＄AU
SINSTディレクトリに配置されることを期待する。AUSIN
STが定義されていないとき、シナリオ構築ツールはAUSR
OOT環境変数が定義されているか否かを知るための検査
をする。定義されているならば、＄AUSROOT/.instディ
レクトリにインスタンスを探索する。AUSROOT環境変数
が定義されていなければ /austin/.instディレクトリに
インスタンスを探索する。

【００９３】(シナリオ定義ファイル及びシナリオイン
スタンスファイル) (定義ファイル及びインスタンスファイルの対話) 図15はシナリオ定義ファイル56及びシナリオインスタン
スファイル54及び試験用足場内の他の要素の対話を示
す。定義ファイル及びインスタンスファイルはシナリオ
構築ツール52を用いて作成され変更され削除される。こ
れらのインスタンスファイルはシナリオドライバ58への
構成入力として使用される。シナリオ開発ステージの間
に定義を作成する必要がある。これらの定義をテンプレ
ートとして用いてシナリオインスタンスを作成する。ま
たシナリオインスタンスファイルを作成するステップも
シナリオ開発ステージの間に必要なステップである。シ
ナリオインスタンスファイルが無ければシナリオドライ
バは実行に失敗するであろうし、シナリオ定義が無けれ
ば(シナリオ構築ツールを迂回しない限り)シナリオイン
スタンスを作成することはできない。定義からインスタ
ンスが例示されたならば、これらをシナリオドライバ用
の構成情報として使用する。各シナリオドライバが実行
されると、そのシナリオドライバの動作を定義する1つ
のインスタンスを渡される。各定義及びインスタンスは
(定義用の) /austin/.def ディレクトリ又は(インスタ
ンス用の) /austin/.instディレクトリ内の別個のファ
イルである。ファイルの名前は定義又はインスタンスの
名前である。ファイル内に、/etc/filesystems内のスタ
ンザと性質の似ているスタンザを見出すことができる
(注意すべきは、これは、UNIXコンパチブルオペレーテ
ィングシステムによって一般に知られ使用されている標
準スタンザである)。スタンザの名前はファイル名、す
なわちインスタンス/定義名と同じである。次にスタン
ザは幾つかの属性名/値ペアをラインあたり1つ格納す
る。ausで始まる属性はシナリオドライバ属性又はシナ
リオドライバ構成属性と呼ばれる。 ausという接頭部は
シナリオドライバ属性に割り付けられたものである。定
義ファイル又はインスタンスファイルに見い出されるこ
れ以外の属性はいずれもユーザ定義属性と呼ばれる。ユ
ーザ定義属性及びシナリオドライバ属性の双方の目的に
ついては詳しく後述する。上記の最初の段落において述
べたように定義ファイルはインスタンスファイルとは僅
かに異なる。定義ファイル内のユーザ定義属性について
の値は実際には、その定義の例示インスタンスファイル
に見い出される値ではない。定義ファイル内のユーザ定
義属性の各値がその代わりに表現するものは、ユーザ定
義属性の型を記述するシンタックスと、その制限と、そ
のデフォルト値と、ユーザ定義属性を何のために使用す
るかについての短い記述とである。この情報はすべて、
例示化時にその変数が実際の値を与えられるとき、シナ
リオ構築ツールが使用する。シナリオ構築ツールは、例
示化する時にタスク開発者によって入れられるユーザ定
義属性の実際の値が、そのユーザ定義属性の定義が定義
されたときに設定された基準に合致することを確実にす
る。

【００９４】(ファイル名シンタックス) 与えられた任意の名前(文字で始まり、ゼロ又は1つ以上
の英数字、下線又はピリオドが続かなければならない)
からなる定義ファイルには、ピリオド及び拡張子
「e」、「m」、「p」又は「t」が続く。定義ファイル上
に配置される拡張子は、その定義が定義するものの如何
により、環境シナリオならば「e」、機械シナリオなら
ば「m」、個人シナリオならば「p」、タスクシナリオな
らば「t」である。上述の定義ファイル名からなるイン
スタンスファイルには、ピリオド及び現在の定義に関す
る固有の整数値である拡張子が続く。例えば、 foo.eと
名付けられた定義が2回例示化されたとき、インスタン
ス foo.e.1及びインスタンスfoo.e.2が存在する。3回例
示化されたとき、 foo.e.3の名前をもつ新しいインスタ
ンスが作成される。

【００９５】

【表３】

【００９６】

【表４】

【００９７】次表(5)は一般的なスタンザシンタックス
を用いてのタスク定義ファイルの例である。

【００９８】

【表５】 sample.t; austype = task ausdesc = "Tests NFS mounts from clients to a server." austaskcode = "nfstest" SERVER = req str @ NFS server, exports directories CLIENTS = req str @ list of NFS clients, mounts directories FILESIZE = opt int ｛ 512 1024 2048 4096 ｝512 @ File size in Bytes 。

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

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

【０１０１】上述したタスク定義ファイルの例を表6に
示す。

【０１０２】

【表６】 sample.t.1; austype = task ausdesc = "Tests NFS mounts from clients to a server." austaskcode = "nfstest" auscompress = none ausjournals = "klog elog SPOOL;spooljour" ausloops = 1 austaskparams = "-e 1 -f 16" aussave = all ausverbose = 7 SERVER = "arsenio" CLIENTS = "carson leno oprah" FILESIZE = "512" 。

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

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

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

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

【０１０７】

【表７】 記号 意味 [ ] タイプできるフィールドの始め及び終わりを指示する ＜ 見えているフィールドの左にさらにテキストがあることを示す ＞ 見えているフィールドの右にさらにテキストがあることを示す ＊ 値が要求されていることを示す ＋ 選択肢のリストまたはオプションリングを使用できることを 示す F4を押し、リストまたはタブを表示してオプションリングを 留める ＠ その属性は読出し専用であることを示す ＃ 実数または整数の値が要求されていることを示す。

【０１０８】以下に例を述べる。図16はシナリオ構築ツ
ールの最初のメニューパネルがどのように見えるかを例
示している。画面底部の機能キー202はパネルからパネ
ルに変化する。しかしながら、このメインメニュー上の
5つの機能キーの定義は好適な実施例におけるパネル全
体を通じて首尾一貫している。パネルごとのコンテキス
ト感知支援はF1キー213でいつでも使用できる。F2キー2
15は画面をリフレツシユするために使用される。F3キー
217及びＥSCキー(図示せず)はいつでも前のパネルに戻
す。F9キー219は一時的にシェルに出(「exit」をタイプ
することによって戻る)、F10キー221はどのパネルにお
いてもシナリオ構築ツールを抜ける。

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

【０１１０】図18は対話パネルのサンプルである。この
特定の対話パネルは上述のタスクインスタンスファイル
に関するシナリオ構築ツールによって表示されるもので
ある。sample.tと呼ばれるタスク定義の新しいインスタ
ンスにシナリオ開発者がaussbtとタイプして構築ツール
に入り、次にタスク(Task)、インスタンス管理(Manage
Instace)、インスタンスの加算(Add an Instance )及び
サンプルt定義を選択する。次にサンプルt1インスタン
スと図18の対話パネルが表示される。タスクインスタン
ス管理ステージの間、属性austype 206及び属性austask
code 208はすべて読出し専用である。このことは、ずっ
と左方の列に「＠」の記号212で表す。読出し専用とし
た理由は、これらがシナリオを定義する属性であり、こ
れらを変更することは異なるシナリオ定義を作成するこ
とを意味し、そうする代わりにタスク/定義/作成オプシ
ョンを選択することができるからである。このパネルは
予め定義したシナリオ(すなわち、存在するシナリオ定
義ファイルを既にもっているシナリオ)の例示のためだ
けに示すものである。属性auscompress 214、属性aussa
ve 216及び属性ausverbose224はトグルリングを有し、
このことをずっと右方の列に「＊」の記号218で表示す
る。これは、利用者がタブキーを用いて異なる値を選択
することができるか又はF4キーを使用して可能な値のリ
ストを入手できることを意味する。シナリオドライバ属
性ausloops220、austime 222及びausverbose224はすべ
て数値を要求する。このことを、ずっと右方の列に
「＃」の記号226によって表示する。1つのユーザ定義属
性FILENAME228があるが、好適な実施例においてはこれ
が必要である。これを、ずっと左方の列に「＊」の記号
で表示する。また注意すべきは、FILENAME228もずっと
右方の列にトグルリング(「＊」)218を有し、これによ
り、ユーザがタブキーを用いて異なる値を選択するか又
はF4キーを使用して可能な値のリストを入手できること
を表示する。

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

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

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

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

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

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

【０１１７】試験シナリオドライバの実行は現在の試験
用環境において必要な制御に従い、タスクレベルを通じ
て環境レベルからいずれかのレベルにおいて開始するこ
とができる。好適な実施例においては試験シナリオドラ
イバは依存性を有し、そのロケーションはPATH環境変数
内に提供される。シナリオドライバは、デフォルトによ
って /austin/tools/rsbinディレクトリに配置される。
このディレクトリを以下のコマンドを用いてPATH環境変
数に付加することができる。 PATH=/austin/tools/rsbin;$PATH ;export PATH シナリオドライバは2つの使用文を準備する。第1の使用
文はコマンドライン上にエラーが検出されたときに生ず
る。この使用からの情報は標準エラー(stderr)にプリン
トされる。第2の使用文は支援使用文であり、これは
「h」フラグがシナリオドライバに渡されるときに生ず
る。この支援使用からの情報は標準出力(stdout)にプリ
ントされる。有効なタスクシナリオインスタンス名を伴
う「h」フラグが指定されると、後述するように、その
インスタンスのための支援が標準出力(stdout)に表示さ
れる。エラー使用文を次表8に示す。

【０１１８】

【表８】 使用法; ausdriver [-c < n ｜f ｜p｜a >] [-d < t｜f> [-e ExcString] [-1 Loops] [-m <s ｜c >] [-r RunString] [-s <n｜f｜p｜a>] [-t Hours] [-u User ] [-v Level] [-w <t｜f>] <instance> 。

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

【０１２０】

【表９】 Project AUSTIN V1.00 Usage; ausdriver [command＿options ] <instance> The ausdriver command＿options are; -c <n ｜f｜p｜a> 圧縮オプション（n−無、f−失敗、 p−パス、a−全） -d <t｜f> 分散形環境（t−真、f−偽） -e ExcString ExcString 内のインテジャへマップされたイ ンスタンスを除外する -h もし、インスタンスがコマンドラインの上にあるならば タスクに支援を与え、そうでなければ、使用可能なオプ ションをすべて記述しているメッセージをプリントアウト する -1 Loops 実行のためのループ -m <s｜c> 実行のモード（s−逐次、c−同時） -r RunString RunString 内のインテジャへマップされたイ ンスタンスを実行する -s <n｜f｜p｜a> オプションを退避させる（n−無、f−失敗、 p−パス、a−全） -t Hours 実行するための時間 -u User 個人シナリオを実行する利用者 -v Level レベルの値（0-7)に冗長をセットする -w<t｜f> ウィンドウオプション（t−真、f−偽） ドライバ支援のためには、ausdriver -hに入る タスク支援のためには、ausdriver -h <task＿instance>に入る。

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

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

【０１２３】

【表１０】 <op1> op1が要求され、<op1>がユーザのデータによって置き換え られることを示す [op1] op1はオプションであり、[op1]がユーザのデータによって 置き換えられることを示す op1｜op2 op1とop2との論理和をとることを示す op1 ．．． 零またはそれ以上のop1を示す N/V その属性はデフォルト値を有していないことを示す 『 』 『 』で囲まれた語はユーザの値と置き換えられる 《 》 《 》で囲まれたテキストは、このテキストが逐語的に取ら れなければならないことを示す。

【０１２４】

【表１１】

【０１２５】インスタンス属性シンタックスは、≪ausb
eghook≫＝“＜『 begin hook』＞”であり、コマンド
ラインシンタックスはない。

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

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

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

【０１２９】

【表１２】

【０１３０】インスタンスファイルシンタックスは、≪
auscodedir≫＝“＜『directory 』＞”であり、コマン
ドラインシンタックスはない。 (説明) ユーザのベースコードディレクトリは、タスク開発者の
ために、デフォルトロケーション内にそれが存在しない
場合にタスクコードのロケーションを指示する道を提供
する。文字列はベースレベルディレクトリの値を格納
し、そこに、現在のタスクに対する開発者のタスクディ
レクトリ構造が存在する。このシナリオドライバ属性の
ためのデフォルト値は、タスクシナリオドライバがその
シナリオのタスクディレクトリ構造のロケーション及び
現在のインスタンスの名前を使用して実行時に計算され
る。ディレクトリは次のようにセットされる。

【０１３１】 <scenario's task directory structure>/<first letter of the instance>/<instance base> ここで＜instance base> は'.t.<int>'拡張子を伴わ
ないインスタンス名である。

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

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

【０１３４】

【表１３】

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

【０１３６】圧縮された情報を非圧縮状態にして再圧縮
することのできる2つのユーティリティが存在する。

【０１３７】(例1) 数千のタスクが何日もの間そこで実行しているシナリオ
は、その環境全体に対するすべてのタスク実行時情報が
圧縮されるよう圧縮属性をセットすることを望むことが
ある。これを行うには各機械インスタンスファイル内の
すべてに対してauscompress 属性をセットする。機械イ
ンスタンスファイル内の情報は、機械シナリオ内にある
各タスクシナリオに自動的に漏れる。以下の行は、機械
シナリオインスタンスファイル内においてこの効果を有
する。 auscompress = all (例2) 他の状況において、異なるハードディスク資源を有する
複数のホストを有する環境シナリオが実行しているもの
とする。こうした状況では、多量のディスクスペースを
有するホストは何も圧縮せず(無し(none)又はn)、少量
のディスクスペースを有する機械はあらゆるものを圧縮
する(全部( all)又はa)ように圧縮オプションをセット
することができる。これを達成するため、僅かなディス
ク資源を有するホストのインスタンスファイルに次の属
性を置く。 auscompress = all また多くのディスク資源を有する機械のインスタンスフ
ァイルには次のような属性を置く。 auscompress = none (例3) この例においては、極めて稀に実行している機械シナリ
オが、渡されたタスク情報を見るので、機械シナリオイ
ンスタンスファイルに次のような属性を置くことによっ
て情報を圧縮することができる。 auscompress = pass (例4) 1つの環境内で実行している同じタスクが異なる圧縮オ
プションを有することができることに注意することが重
要である。これは、タスクが異なるインスタンスファイ
ルに関連付けられているからである。例えば、2つの異
なる機械上で実行するタスク rcpは完全に別々の圧縮属
性を有することができる。これは、2つのタスクインス
タンスのうちの第1のものは圧縮属性をパスにセットす
るインスタンスに関連付けられているからであり、これ
により、それはタスクが渡されるときだけにタスクファ
イルを圧縮する。次のようなシナリオインスタンス属性
でこれを行う。 auscompress = pass タスクの第2のインスタンスは圧縮アルゴリズムを全部
(all )に対してセットするインスタンスファイルに関連
付けられているので、全部のタスクファイルが成功に関
係なく圧縮される。次のようなシナリオインスタンス属
性でこれを行う。 auscompress = all

【０１３８】

【表１４】

【０１３９】インスタンスファイルシンタックスは≪ a
usdesc≫＝“＜『description 』＞”であり、コマンド
ラインシンタックスはない。 (説明) ausdesc属性は各定義済シナリオを記述している、シナ
リオインスタンスファイル作成時にシナリオ構築ツール
に入った情報がインスタンスファイル内に保存されるよ
うにする。このデータは情報だけを目的とする。それは
インスタンス間の違いを記述する「テキスト」である。

【０１４０】(例) 以下はシナリオインスタンスファイルのサンプルを記述
したテキストである。ausdesc ＝「このインスタンスは
圧縮属性をpassに対してセットし保管を allに対してセ
ットする」。以下は、同じシナリオ定義ファイルから出
た異なるシナリオインスタンスファイルからの他のサン
プルを記述したテキストである。ausdesc ＝「このイン
スタンスは圧縮属性を allに対してセットし保管を all
に対してセットする」。

【０１４１】

【表１５】

【０１４２】インスタンスファイルシンタックスは≪au
sdistributed≫＝ ＜≪ true ≫｜≪false≫＞ であ
り、コマンドラインシンタックスは≪-d≫ ＜≪t≫｜
≪f≫＞ である。 (説明) 分散実行時ファイルスペース属性は分散した /austin/
runtime ファイルスペースで環境シナリオを実行するこ
とが意図であるか又は /austin/ runtime ファイルスペ
ースがネットワーク内の各機械に存在するか否かを環境
シナリオドライバに通知する。

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

【０１４４】(例1) 以下はシナリオ実行ステージの間に /austin/runtimeフ
ァイルスペースを分散していない環境シナリオインスタ
ンスファイルからの抜粋である。 ausdistributed = false (例2) 以下はシナリオ実行ステージの間に /austin/runtimeフ
ァイルスペースを分散している環境シナリオインスタン
スファイルからの抜粋である。 ausdistributed = true

【０１４５】

【表１６】

【０１４６】インスタンスファイルシンタックスは≪au
sendhook≫＝“＜『end hook』＞”であり、コマンド
ラインシンタックスはない。 (説明) 終了フックは次のレベルのシナリオドライバ又はユーザ
タスクコードを実行した後にシナリオドライバによって
ユーザコードを自動的に実行し得る道を提供する。終了
フックが実行する時間を除いて、開始フック及び終了フ
ックの双方に同じ情報を適用する。

【０１４７】

【表１７】

【０１４８】インスタンスファイルシンタックスは≪ a
usjournals≫＝“［＜『 env va;journalna』｜『 jou
rl name』＞... ］”であり、コマンドラインシンタッ
クスはない。 (説明) この ausjournals属性を用いて、ジャーナルコマンドが
書き込むデフォルト標準ジャーナルファイルとは異な
る、ユーザのタスクコードが使用を望む何らかのジャー
ナルを定義する。ユーザのタスクコードを実行する前
に、タスクシナリオドライバは ausjournals予約属性の
値に基づいて環境変数をセットする。これらの環境変数
はユーザ定義ジャーナルの経路を含む。この経路は固有
のタスク実行時ディレクトリ構造のjourディレクトリ内
にある。このディレクトリは( taskjournalの名を有す
る)標準タスクジャーナル及び ausjournalsコマンドと
共に定義される各ユーザ定義ジャーナルを格納する。こ
れらのファイルの実際のロケーションはユーザのタスク
コードとは関係がない。これは、ユーザは環境変数を使
用してジャーナルを参照するからである。

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

【０１５０】(例1) この例においてタスク開発者はデフォルトジャーナルフ
ァイル以外の彼/彼女のタスクのために3つのジャーナル
を使用することを要求する。ausjournals に彼/彼女が
与える値は以下の通りである。 ausjournals ＝“Spooljour;spooljour cmdjour DiffRe
sults;diff- jour” この値は上述の形式の双方を含む。シナリオドライバは
このインスタンス属性を読み、以下の3つの環境変数を
そこに示す値にセットする。 Spooljour=“/austin/runtime/<scenariodir>/working/
＜taskdir>/jour/spooljour” CMDJOUR=“/austin/runtime/<scenariodir>/working/<t
askdir>/jour/cmdjour” DiffResults=“/austin/runtime/<scenariodir>/workin
g/<taskdir>/jour/diffjour ” (例2) この例では、シナリオ開発者はelog及びklogと名付けた
2つのジャーナルを必要とする。タスクシナリオインス
タンスファイルに次のように指定する。 ausjournals=“elog klog ” これにより、以下の環境変数は次のような値をもつ結果
となる。 ELOG＝“austin/runtime/<scenariodir>/working/<task
dir>/jour/elog” KLOG＝“/austin/runtime/<scenariodir>/working/<tas
kdir>/jour/klog ” これによりユーザはこれらのファイルに書込むことがで
きる。以下は、上述のファイルを使用するシェルスクリ
プトからの抜粋である。 ls-alt foofile＞＄ELOG diff ＄ELOG ＄AUSCODEDAT/expected.results ＞＞＄KLOG if ［“＄
？”！＝“0”］；then auserror “The ls -all foofi
le command failed. ”eles auslog “The ls-alt foof
ile command was succesful.”fi

【０１５１】

【表１８】

【０１５２】インスタンスファイルシンタックスは≪ a
usloops ≫＝＜『integer 』＞であり、コマンドライン
シンタックスは-1<integer> である。 (説明) 属性を実行するためのループはシナリオ属性ausobjlist
内のインスタンスを何回実行すべきか又はシナリオ属性
austaskcode内のユーザのタスクコードを何回実行すべ
きかをシナリオドライバに通知する。注意すべきは、
『 time to execute』属性が存在することである。同じ
インスタンスファイル内又はコマンドライン上に双方が
指定されたとき、『 time to execute』属性が優先順位
をとる。どちらかがコマンドライン上に指定されると
き、これらは、シナリオインスタンスファイルにあるこ
のいずれかを上回る優先順位をとる。ausloopsのための
整数値は正でなければならない。

【０１５３】(例) loops to execute 属性が次のような値をタスクシナリ
オインスタンスファイルに有するとき、それは個人シナ
リオドライバによって実行されたものである。 ausloops＝20 ユーザタスクコードは個人ドライバへの制御を復帰させ
る前に20回実行する。動作の順序としては、個人ドライ
バがその開始フックを実行し、次にタスクドライバが実
行する。タスクドライバはその開始フックを実行し、次
にそのユーザタスクコードを20回実行し、その終了フッ
クを実行し、次に個人シナリオドライバへの制御に復帰
する。個人シナリオドライバが「1」よりも大きいルー
プ値を有しているとき、タスクシナリオドライバは再び
実行して同一の2回目のプロセスを進み、その開始フッ
クを実行し、そのユーザタスクコードを20回実行し、そ
の終了フックを実行し、次に個人シナリオドライバに実
行制御を戻す。

【０１５４】

【表１９】

【０１５５】インスタンスファイルシンタックスは≪ a
usmode≫＝＜ ≪concurrent≫｜≪sequential≫ >であ
り、コマンドラインシンタックスは-m < c｜s > であ
る。 (説明) 実行モード属性は低位レベルのシナリオドライバを順次
又は同時に実行させることができる。「同時」が指定さ
れると、シナリオドライバはそのausobjlist内のすべて
のインスタンスの実行を同時に開始して、これらすべて
の終了を待機する。「順次」が指定されると、シナリオ
ドライバはausobjlist内のインスタンスを順次実行す
る。リスト内のすべてのオブジェクトが実行し、かつ終
了すると、同時であるか順次であるかにかかわらずそれ
はシナリオドライバの1つのループを作る。

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

【０１５７】(例2) 4つのタスクを実行するのに10分かかり1つのタスクを実
行するのに30分かかるような5つのタスクを有する個人
シナリオの上述の例を用いて、この例は個人シナリオが
順次モードで2つのループを実行するのに必要な時間の
長さを示す。ドライバに順次モードで実行させるには個
人シナリオインスタンスファイルに以下の属性を使用す
る。 ausmode = sequential これら5つのタスクを背中合わせに実行すれば、個人シ
ナリオの各反復実行はほぼ70分を要する。従って、個人
シナリオの2回の反復にはほぼ 140分かかり、同時実行
の場合に要する時間の2倍以上もかかることになる。

【０１５８】

【表２０】

【０１５９】インスタンスファイルシンタックスは≪au
sobjlist≫ =“＜ 『instance』＞ ... ”であり、コマ
ンドラインシンタックスはない。 (説明) オブジェクトリスト属性は他のシナリオドライバ(環
境、機械及び個人)を実行するシナリオドライバにとっ
て極めて重要である。ausobjlistと名付けられたオブジ
ェクトリストインスタンス属性は1つ又は2つ以上の項目
のリストを含む。これらの項目は現在のシナリオドライ
バが制御するシナリオを記述するインスタンスの名前で
ある。シナリオドライバは一段と低レベルのシナリオを
走らせる他のシナリオドライバの実行を開始できる状態
のとき、ausobjlistを抜けて、現在のインスタンスの名
前をこれに渡しているシナリオドライバを実行する。オ
ブジェクトリストはトップの3つの試験シナリオレベル
にシナリオを定義するものである。これは、オブジェク
トリストが、試験シナリオが実行しているものの核心を
格納するからである。

【０１６０】(例) この例では機械シナリオが実行しており、そのオブジェ
クトリストは次のようなものである。 ausobjlist =「person1.p.1 person1.p.2 person2.p.1
」 機械シナリオドライバはシナリオドライバステップを実
行した後、一段と低レベルのシナリオドライバを実行で
きる点に達する。これを行うため、機械シナリオドライ
バは上述のリストを検査し、同時又は順次に3つのシナ
リオドライバを開始する。これらはインスタンスperson
1.p.1 、インスタンスperson1.p.2 、インスタンス2.p.
1 を渡される。これにより3つの個人シナリオドライバ
が実行され、これらのシナリオドライバは現在の機械シ
ナリオドライバによって制御される。注意すべきは、pe
rson1.p.1 及びperson1.p.2 は同じ個人の2つのインス
タンスであることである。

【０１６１】

【表２１】

【０１６２】インスタンスファイルシンタックスは≪au
sobjnumlist ≫＝“＜『integer 』＞... ”である。コ
マンドラインシンタックスは、-r＜『integer 』＞｜≪
-r≫『“＜『integer 』＞＜『integer 』＞... ”』
と、≪-e≫＜『integer 』＞｜≪-e≫“＜『 integer』
＞＜『integer 』＞... ”である。 (説明) オブジェクトナンバーリストはausobjlist属性のメンバ
ーを実行させるか又は現在のシナリオ実行から除外させ
る。これは、ausobjlist内の項目に写像するインテジヤ
のリストを指定することによって実行される。デフォル
トによって、オブジェクトナンバーリスト属性はausobj
list属性内のすべてのインスタンスに対応するインテジ
ヤのリストにセットされるので、実行によってこれらは
すべて実行を完遂する。オブジェクトナンバーリスト構
成属性が準備され、これにより構成オブジェクトリスト
はインスタンス作成/変更ステージの間ausobjlist内の
インスタンスのテンプレートをなおも不変に維持するこ
とができる。これは、そのリストは現在のシナリオを
「定義する」ものであり、シナリオ構築ツールのインス
タンス管理部分の間に変更されることはないからであ
る。

【０１６３】(例1) 個人インスタンスが次のようなausobjlist及びausobjnu
mlist を含んでいる場合、 ausobjlist＝“task1.t.1 task2.t.1 task3.t.1 task4.
t.1 task5.t.1 task6.t.1 ”、ausobjnumlist ＝“1 2
3 6 ”である。個人シナリオドライバが実行するとき、
その個人のためのausobjlist内には6つのタスクインス
タンスが存在するが4つのタスクシナリオドライバだけ
を開始する。これは、ausobjnumlist がその中に4つの
整数しか有していないからである。実行される4つのタ
スクとはtask1.t.1 、task2.t.1 、task3.t.1 及びtask
6.t.1 であり、ausobjlistの4及び5のメンバーは除外さ
れる。

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

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

【０１６６】

【表２２】

【０１６７】インスタンスファイルシンタックスは≪au
ssave ≫＝＜ ≪none≫｜≪pass≫｜≪fail≫｜≪all
≫＞ であり、コマンドラインシンタックスは-s < n｜p
｜f｜a>である。(説明) 保管オプションを使用して、タスク実行のために作成さ
れた固有の実行時ディレクトリ構造を保管すべきか否か
をタスクレベルシナリオドライバに通知する。タスク実
行時情報を保管すべきか否かの決定はユーザのタスクが
渡されたか失敗したかということと保管属性の値とに基
づいて行われる。 aussaveインスタンス属性又は「s」
コマンドラインフラグでこの保管属性をセットすること
ができる。セットの種類は、全く保管せず(無し(none)
又はn)、渡されたタスクにおいてだけ保管する(パス(pa
ss)又はp)、失敗したタスクにおいてだけ保管する(失敗
(faile) 又はf)又は常に保管する(全部(all) 又はa)で
ある。この保管機能は圧縮機能と一緒に協力して作用す
ることにより、タスク実行時にどの情報を保管し、保管
するどの情報を圧縮するかを決定する。

【０１６８】(例) 機械シナリオは失敗するタスクからの機械シナリオのタ
スク情報だけを保存することを望むことがある。この状
況においては機械インスタンス属性aussave を次のよう
にセットする。 aussave = fail 注意すべきは、この属性は機械シナリオドライバレベル
においては実際に何も行っていないが、タスクシナリオ
ドライバレベルへと下方に渡されて、そこで、この属性
を使用することにより、タスク実行時ディレクトリ構造
を除去又は保管すべきか否かを決定する。

【０１６９】

【表２３】

【０１７０】インスタンスファイルシンタックスは≪ a
ustaskcode≫＝“＜『task filename』＞”であり、コ
マンドラインシンタックスはない。 (説明) タスクコードパラメータはタスクシナリオドライバの実
行にとって極めて重要である。これは、何を実行すべき
かを詳述している情報を含む他の3つのシナリオドライ
バレベルのために指定されたオブジェクトリストパラメ
ータに類似している。オブジェクトリスト構成属性及び
タスクコードパラメータ間の違いは、タスクコードパラ
メータが実行すべきユーザのコードの実際のファイル名
を含むことである。タスクファイル名への実際の経路は
指定されない。これは、このファイルのロケーションは
次のようにして決定されるからである。$AUSBIN によっ
て示される実行時タスクbin ディレクトリ構造が最初に
検査され、次に、$AUSCODEBIN によって示されるタスク
コードディレクトリ構造の binディレクトリが検査され
る。

【０１７１】(例) そのロケーションが /austin/tasks/r/rcp/bin/foobar
であるシェルスクリプトfoobarを走らせることによって
rcpタスクを実行すると、タスクシナリオインスタンス
ファイル内のaustaskcode 属性のために以下のように指
定される。 austaskcode = 「foobar」

【０１７２】

【表２４】

【０１７３】インスタンスファイルシンタックスは≪au
staskparams ≫＝“＜『parameters』＞”であり、コマ
ンドラインシンタックスはない。 (説明) 主に試験用足場は環境変数に写像されるユーザ定義属性
を経由してユーザタスクコードに渡っている情報の周囲
に準備されるが、シナリオドライバ及びシナリオ構築ツ
ールもコマンドラインパラメータを経由してユーザタス
クコードにパラメータを渡す能力を支援する。これを行
うには、タスクパラメータ構成属性を使用する。ユーザ
タスクコードを実行するとき、このシナリオドライバイ
ンスタンス属性の値を直接的にコマンドライン上に渡
す。

【０１７４】(例) タスクについてのユーザタスクコードがfoobarであり、
コマンドラインを経由して渡される絶対値パラメータを
それが必要とする場合、インスタンスファイルからの以
下の属性がこの状況を処理する。 austaskcode = “foobar”austaskparams = “-m 20 ” コマンドfoobarが実行したとき、これはコマンドライン
に追加された“ -m 20”を伴って実行する。

【０１７５】

【表２５】

【０１７６】インスタンスファイルシンタックスは≪au
stim≫＝＜『real』｜『integer 』＞であり、コマンド
ラインシンタックスは-t＜『real』｜『integer 』＞で
ある。 (説明) austime属性はユーザが望むシナリオドライバ実行継続
時間の長さを指定する。 austimeを指定したとき、シナ
リオドライバはそのausobjlist又はaustaskcode 内の項
目を実行してこれらの完了を待つ。すべてのインスタン
スが完了すると、シナリオドライバはシナリオドライバ
の開始時間が時間属性によって指定される時間よりも少
ないために、検査をして時間が経過したか否かを知る。
肯定結果が得られると、シナリオドライバはausobjlist
内のすべての項目を再び実行する。注意すべきは、この
時間属性のための値は正でなければならないことであ
る。

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

【０１７８】

【表２６】

【０１７９】インスタンスファイルシンタックスは≪au
stype ≫= < ≪environment ≫｜≪machine ≫｜≪pers
on≫｜≪task≫ >であり、コマンドラインシンタックス
はない。 (説明) シナリオドライバ型属性は最も重要なインスタンス属性
である。それは、シナリオレベルが実行しているシナリ
オドライバを教えるものである。このことは極めて重要
である。なぜならば、シナリオドライバの動作は、それ
がどのシナリオレベルを実行しているかに大きく左右さ
れるからである。

【０１８０】

【表２７】

【０１８１】インスタンスファイルシンタックスは≪ a
ususer≫＝“＜『user name』＞”であり、コマンドラ
インシンタックスは-u＜『user name』＞である。 (説明) ユーザ属性は一群のタスクをユーザuser nameとして実
行できるようにする。この属性が個人レベルで使用され
るとき、シナリオドライバはausobjlistのタスクインス
タンスを実行する前にユーザuser nameを変更しようと
試みる。このユーザ変更が成功しない場合、シナリオド
ライバはエラーを出して制御を機械ドライバに戻す(又
はAIXシェルがトップレベルのシナリオドライバの場合A
IXシェルに戻す)。

【０１８２】

【表２８】

【０１８３】インスタンスファイルシンタックスは≪au
sverbose≫＝＜『integer 』＞であり、コマンドライン
シンタックスは-v＜『integer 』＞である。 (説明) 冗長オプションは情報の変化度を、ジャーナル内に載置
できるようにすると共に標準出力(stdout)及び標準エラ
ー(stderr)に送ることができるようにする。この冗長の
変化レベルはジャーナル記入コマンドの操作を通じて達
成される。冗長の度合いは合計8つある。

【０１８４】

【表２９】

【０１８５】インスタンスファイルシンタックスは≪au
swindows≫＝ ＜≪ true ≫｜≪false ≫＞ であり、
コマンドラインシンタックスは≪-w≫ ＜≪t≫｜≪f≫
＞ である。 (説明) ウインドウ構成属性は、これが存在するならばウインド
ウ環境の利益を得るようにシナリオドライバが試みるべ
きであるか否かを決定する。値が真であり、DISPLAY環
境変数がセットされると、シナリオドライバがそのauso
bjlistのメンバーを実行し、これにより新しいシナリオ
ドライバを開始するごとに、異なるウインドウの新しい
シナリオドライバを開始しようと試みる。

【０１８６】(ユーザ定義属性) ユーザ定義属性をこの試験用足場内のいずれのレベルに
おいても指定することができる。これらの属性は一段と
低レベルによって機械レベルから下方に受け継がれる。
これらの属性はシナリオドライバ属性ではないシナリオ
インスタンスファイル内に識別子を配置し、次にこれに
1つの値を与えることによって指定される。ドライバの1
つが構成ファイル内でユーザ定義属性に遭遇すると、こ
のドライバはユーザ定義属性を単に環境に置き、従って
これは実行されたいずれかの子プロセスに遺伝される。
ユーザ定義属性の概念は情報をユーザタスクコードに送
る場合にタスクインスタンスシナリオファイルレベルで
特に有用である。上述したように、ユーザ定義属性の内
容はシナリオ構築ツールによって厳密に制御することが
できるが、これは、このユーザ定義属性がシナリオを定
義するステージの間に定義され、形式及びオプション又
は要求されたフラグを与えられなければならないからで
ある。またユーザ定義属性は制限及びデフォルト値を有
するように定義することができる。タスクレベルでユー
ザ定義属性を使用する以外に、これらの属性はすべての
他のレベルで完全に有効である。この能力によってユー
ザ定義属性を個人シナリオレベルで1回だけ指定するこ
とができ、次に個人シナリオを構築する各タスクシナリ
オによって使用することができる。機械シナリオ全体は
スケールフアクタ(SCALEFACTOR )のような環境変数を使
用してこの機械シナリオを構築しているすべてのタスク
シナリオが実行されている場合のストレスのレベルを判
定することができる。

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

【０１８８】(予約済属性の概要情報)

【０１８９】

【表３０】

【０１９０】以下は、シナリオドライバがそのシナリオ
レベルとは関係なく実行するシーケンスである。(1)必
要な内部初期化をすべて実行する。(2)必要であれば一
時的ジャーナルファイルを作成する。(3)コマンドライ
ンを分析する。(4)「h」フラグが見つかり、インスタン
スファイルが存在しない場合、シナリオドライバに詳細
な援助を与える。(5)インスタンスの属性を読み取る。
(6)インスタンスの予約済属性の有効性を検査する。(7)
インスタンスファイル内で見つけたすべてのユーザ定義
属性を環境内に配置する。(8)現在のレベルについてシ
ナリオドライバ構成属性を決定する。(9)要求されれば
タスクに対する援助を示す。(10)存在すれば開始フック
を実行する。(11)これがトップレベルのシナリオドライ
バであれば、シナリオセットアップ機能を実行する。(1
2)必要があれば、ausobjlistに対して必要な変更を行
う。(13)次のレベルを実行する(これはルーピングの発
生するステップである)。(14)存在すれば終了フックを
実行する。(15)実行状態を示すリターンコードによって
このプロセスを抜ける。

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

【０１９２】環境シナリオドライバは通信14用の環境ク
ライアントについて、上述したように、インターネット
ソケット及びausdriverdという名前のデーモンに依存し
ている。この通信方法は、環境クライアントについて機
械シナリオドライバ232の実行を開始し、これらの機械
シナリオドライバが実行を終了すると、これらの機械ド
ライバからリターンコードを受け取ることができるよう
にする必要がある。デフォルトディレクトリ構造及びRI
SC System/6000プラットフォームを仮定すると、以下の
コマンドを使用することによりネットワーク内の環境ク
ライアントについてシナリオドライバデーモンを開始す
ることができる。 # /austin/tools/rsbin/ausdriverd & 環境シナリオの意図が、同時に行われるxtermsの利点を
十分活用してX‐Windows でその機械シナリオのすべて
を実行する場合、ausdriverdデーモンはこの環境内に既
に設定されているX‐Windows の DISPLAY環境変数で開
始されなければならない。これは幾つかの方法で行うこ
とができる。

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

【０１９４】X‐serve が常に同じ、例えば、unix;0で
あることが分かっていれば、他の方法を推薦することが
できる。/ etc /rc./ aus という名前のファイルを作成
してこれに以下のコマンドを置く。 # DISPLAY=unix;0 ausdriverd ＆then、/etc/inittabフ
ァイル端部に以下のコマンドを加える。 rcaus;2;wait;sh /etc/rc.aus この結果、 DISPLAY環境変数を所定のX‐server、unix;
0に設定して、ブート時間でausdriverdデーモンが実行
される。環境シナリオドライバのオブジェクトリスト(a
usobjlist)のインスタンス234は特別の意味を有する。
このインスタンスの名前(上述したように、.m.<int>の
前の)は、このインスタンスがそれに基づいて実行され
ようとしている機械のホスト名でなければならない。従
って、foobarという名前の機械に基づいて、環境シナリ
オドライバ230が機械シナリオ232の実行を開始するため
には、環境シナリオドライバのオブジェクトリスト(aus
objlist)内のインスタンス234の1つの名前が「foobar.
m.<int>」でなければならない。ここで<int> は特定のf
oobar機械シナリオインスタンス番号である。foobarはf
oobar.m.<int>機械シナリオが実行されるべきホストの
名前であると、環境シナリオドライバは仮定する。

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

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

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

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

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

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

【０２０１】(個人シナリオドライバ) 図22を参照する。機械上で自動的に複数のタスクシナリ
オの実行を制御することが適当である場合は、個人シナ
リオドライバ250が使用される。個人シナリオドライバ
によって、タスクをパーソンのようなシナリオにグルー
プ化することができ、従って状態をこのレベルで追跡す
ることができ、「個人シナリオ」の成功率について判定
することができる。ユーザ構成属性が1つの値を有して
いれば、個人シナリオドライバは別のステップを実行す
る。このような状況では、個人シナリオドライバはユー
ザ構成属性の値によって特定されたユーザアカウントに
対して「ログイン」をシユミレートする。これによっ
て、個人シナリオドライバのレベル以下で走るすべての
タスクは個人のレベルでユーザが指定したように実際に
走ることができる。ユーザ構成属性を変更すれば、ドラ
イバはルートの特権を実行することを要求する。ユーザ
が個人インスタンス内に割り付けられた属性の aususer
によって指定されると、そのユーザのIDはシステム上に
存在しなければならない。個人シナリオドライバはその
ユーザをシステムに自動的に加えることはない。

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

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

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

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

【０２０６】ブロック279においてユーザのタスクコー
ドを実行する前に、タスクシナリオドライバは、ブロッ
ク278においてディレクトリを実行時タスクディレクト
リ構造の作業ディレクトリに変更する。

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

【０２０８】(ジャーナル記入) 図25を参照する。シナリオドライバ58は6つのジャーナ
ルコマンドのセットを使用することによりシナリオジャ
ーナル62に対して記入を行う。これらのコマンドはbegi
n 、log 、warning 、error 、severe及びfinishであ
る。分散環境において、すべてのシナリオドライバは同
じシナリオジャーナルファイル62に対して同じシナリオ
ログで実行するが、これ以外の場合には、各機械に対し
て1つのシナリオジャーナルファイルが存在し、この機
械上のすべてのシナリオドライバは各機械に対して記入
する。 (X‐Windows 資源のカストマイズ) ausdriver＿machine 、 ausdriver＿person及び ausdri
ver＿taskによってxtermsを事前保留することによっ
て、すべての有効な xterm資源を使用してシナリオドラ
イバがこれらのxtermsを実行する方法を変更することが
できる。これらの資源を使用しない場合、これらの3つ
のレベルに対してシナリオドライバが使用する xterm
は、.Xdefaultsファイル内のデフォルト xterm資源であ
る。

【０２０９】(例) 表31は、ウインドウズの構成属性を真に設定して x‐Wi
ndows で走らせたときに、機械、個人及びタスクシナリ
オドライバのxtermsを制御するために使用する資源のサ
ンプルのセットである。

【０２１０】

【表３１】

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

【０２１２】(フオーマツト) シナリオジャーナルファイルには2つの異なるレコード
形式が存在する。(1)ジャーナル記入機能(begin 、log
、warning 、error 及びsevereによって作成されるレ
コード形式及び(2)シナリオドライバ終了機能によって
作成されるレコード形式が存在する。

【０２１３】

【表３２】 フィールド 説 明 １ ジャーナルコマンドの最初の文字(b、l、w、e、またはs) ２ フォーマットYYMMDDの現在の日付 ３ フォーマットHHMMSSの現在の時刻 ４ 現在のホスト名(hostnameコマンドと同じ) ５ 現在の利用者($LOGNAME環境変数から) ６ 環境シナリオインスタンス名 ７ 環境シナリオの反復のカウント ８ 機械シナリオインスタンス名 ９ 機械シナリオの反復のカウント １０ 個人シナリオインスタンス名 １１ 個人シナリオの反復のカウント １２ タスクシナリオインスタンス名 １３ タスクシナリオの反復のカウント １４ ジャーナルコマンドからのテキスト例。

【０２１４】終了機能のレコードとの唯一の相違点はフ
ィールド13及び14間に他のフィールドが存在し、その上
に、終了したオブジェクトのリターンコードが存在する
ことである。各フィールドは文字「｜」(パイプ文字)に
よって分離される。第1のフィールドの前又は最後のフ
ィールドの次にはパイプ文字は存在しない。

【０２１５】(例) 図27はファイルclaussen.m.1300が指示する機械シナリ
オを走らせることによって作成されたシナリオの例を示
す。次にこの機械シナリオは1つの個人シナリオ、shan
e.p.1 302を実行し、この個人シナリオは2つのタスクシ
ナリオ、shane.t.1 304及びshane2.t.1308を実行し、こ
れらはいずれも符号306及び310においてそれぞれ失敗し
た。かくして、個人シナリオ及び機械シナリオはそれぞ
れ符号312及び314においてまた失敗した。この特定の例
に対する唯一のジャーナルのエントリは冗長レベルに起
因する開始及び終了である。この標準フオーマツトに基
づいて、動作中の実際の試験とは関係なく、汎用の報告
書ジェネレータ64(図26)を使用して報告書66(図26)を作
成することができる。

【０２１６】(ユーザコードインタフェース) 図2のAPI70によって、シナリオドライバ58及びユーザコ
ード68間にインタフェースが設けられる。このインタフ
ェースは伝統的なAPIすなわちアプリケーションプログ
ラミングインタフェースではなく、1組のシステム変数
である。これらのシステム変数はユーザタスクコードを
呼び出す前にシナリオドライバによって設定される。ユ
ーザタスクコードはこれらの変数にアクセスすることに
よりこのシステムの状態又は環境を判定することができ
る。ユーザコードが使用するために下記の環境変数を設
ける。 (1) AUSCODEDIR AUSCODEDIRディレクトリ構造は、この構造にユーザのタ
スクコードを配置する最高レベルの構造である。例え
ば、タスクadminlの場合、デフォルトによるこのディレ
クトリ構造は/austin/tasks/adminlである。この構造の
デフォルトのロケーションはインスタンス属性auscoded
irによって変更することができる。 (2) AUSCODESRC AUSCODESRCディレクトリはAUSCODEDIRディレクトリの下
にあるユーザのタスクsrcディレクトリのロケーション
である。これを使用して実行時間中にこの構造内のファ
イルを参照することができる。 (3) AUSCODEBIN AUSCODEBINディレクトリはAUSCODEDIRディレクトリの下
にあるユーザのタスクbinディレクトリのロケーション
である。これを使用して実行時間中にこの構造内のファ
イルを参照することができる。 (4) AUSCODEDAT AUSCODEDATディレクトリはAUSCODEDIRディレクトリの下
にあるユーザのタスクdatディレクトリのロケーション
である。これを使用して実行時間中にこの構造内のファ
イルを参照することができる。 (5) AUSCODEDOC AUSCODEDOCディレクトリはAUSCODEDIRディレクトリの下
にあるユーザのタスクdocディレクトリのロケーション
である。これを使用して実行時間中にこの構造内のファ
イルを参照することができる。 (6) AUSBIN AUSBINディレクトリ構造は実行時にドライバが自動的に
作成する構造である。このディレクトリの目的は、実行
時間中に行う必要があるすべてのソースコードのコンパ
イルのロケーションを可能にすることであるが、これ
は、 /austin/tasksディレクトリ構造が実行時間中だけ
に読み取られるからである。通常この環境変数はタスク
セットアッププログラムで使用される。 (7) AUSLIB AUSLIBディレクトリはCプログラムにリンクする際に使
用されるlibaus.aライブラリのロケーションである。こ
れは、タスクセットアップコード又はタスクコード自身
で使用することができる。 (8) AUSPASS AUSPASS変数は、パスしたタスクに対する、シナリオの
保存ディレクトリ構造を示す。 (9) AUSFAIL AUSFAILは、失敗したタスクに対する、シナリオの保存
ディレクトリ構造を示す。 (10) AUSWORKING AUSWORKING変数は、進行中のすべてのタスクを含む、シ
ナリオの作業デイレクトリ構造を示す。 (11) AUSSCENARIO AUSSCENARIO変数は、シナリオジャーナルファイル(複
数)を含む、シナリオの最高レベルのディレクトリ構造
を示す。 (12) AUSTASK AUSTASK変数は実行中の現在のタスクシナリオの名前を
保持する。 (13) AUSPERSON AUSPERSON変数は実行中の現在の個人シナリオの名前を
保持する。 (14) AUSMACHINE AUSMACHINE変数は実行中の現在の機械シナリオの名前を
保持する。 (15) AUSENVIRONMENT AUSENVIRONMENT変数は実行中の現在の環境シナリオの名
前を保持する。 (16) AUSTPHIDIR AUSTPHIDIR変数はタスクドライバが実行時間に作成する
タスク実行時のディレクトリ構造のトップを示す。 (17) AUSWORK AUSWORK変数は、タスク実行時ディレクトリ(AUSTPHIDI
R)内の作業ディレクトリを示す。これは、タスクが実行
時間に置かれるディレクトリである。 (18) AUSJOURNAL AUSJOURNAL変数はシナリオジャーナルファイルの名前を
保持する。この変数は変更すべきでない。

【０２１７】(ジャーナルプログラミングインタフェー
ス) 標準的なジャーナル記入プログラミングインタフェース
74(図2)はタスク開発者のために存在する。このジャー
ナル記入インタフェースはCバインディング及びシェル
バインディングの双方を有する4つのコマンドから構成
される。これらのジャーナル記入コマンドは標準化した
ジャーナル72を作成する。標準化ジャーナルの利点は、
その内容を分析することができる1組の強化した報告書
フイルタを有することができる能力である。注意すべき
は、シナリオジャーナル62はタスクジャーナル72と同じ
内部フオーマツトを有することである。またこのシナリ
オジャーナルはタスクジャーナル72に設けられているの
と同じAPIを有しているが、これはユーザタスクと違っ
てシナリオドライバ58だけが使用する。

【０２１８】標準ジャーナル記入プログラミングインタ
フェースは、auslog、auswarning、auserror及びaussev
ere のコマンドから構成される。 (C言語のバインディング) 以下は、C言語のジャーナル機能のシンタックスであ
る。 void auslog( char *Format [,Value, ...] ) 、void a
uswarning( char *Format [,Value, ...] ) 、void aus
error( char *Format [,Value, ...] ) 、voidaussever
e( char *Format [,Value, ...] ) これらのコマンドのシンタックスは、printf()システム
呼出しのコマンドと同じである。これらの各ルーチンに
可変数の引数を通過させることができ、これらの引数は
このルーチン内で評価される。例えば、下記の方法でau
slog()を呼び出すことができる。 auslog( “Calling function %s at %d.”, function＿
name,time) タスクコードがC言語で書かれると、これは、ライブラ
リ /austin/tools/rslib/libaus.a.とリンクすることに
よってこれらのジャーナル記入機能にアクセスすること
ができる。

【０２１９】(シェル言語のバインディング) auslog <string>、 auswarning <string>、 auserror <
string>及び aussevere <string> は、ジャーナル記入
コマンド用のシェル言語のバインディングである。

【０２２０】これらの機能を使用するには、 tools bin
ディレクトリがPATH環境変数(すなわち、PATH=$PATH;au
stin/tools/rsbin )を使用するシステム経路内になけれ
ばならない。 (説明) 以下は、4つの各ジャーナル記入コマンドの意図した用
途の簡単な説明である。 (1) auslog auslogコマンドはエラー条件を示さないジャーナルエン
トリをタスクコードに行わせるために設けられる。基本
的にauslogコマンドはデバツグの支援に使用され、タス
クの実行中に実行される動作の追跡に使用することがで
きる。 (2) auswarning auswarningコマンドは、全体のタスクを失敗させる程に
は厳しくないエラー条件を示すジャーナルエントリをタ
スクコードに行わせるために設けられる。基本的にこの
auswarningコマンドは予期しない結果を示すために使用
されるが、失敗を是認するのに十分な程重要ではない。 (3) auserror auserrorコマンドは、実行中のタスクコードを失敗させ
るすべてのエラー条件を示すジャーナルエントリをタス
クコードに行わせるために設けられる。このauserrorコ
マンドを使用して予期しない結果を指示し、この予期し
ない結果の大きさがタスクを失敗させるべきであるが、
このタスクの連続した実行を中断すべきではない。 (4) aussevere aussevereコマンドは、実行中のタスクコードを失敗さ
せるエラー条件を示すジャーナルエントリをタスクコー
ドに行わせるために設けられる。この aussevereコマン
ドを使用して予期しない結果を指示し、この予期しない
結果の大きさがタスクを失敗させるべきであり、かつタ
スクの実行を中断すべきである。一般的に終了コマンド
又はリターンコマンドはタスクコード内の aussevereコ
マンドに従う。

【０２２１】(開始フック及び終了フック) 開始フック及び終了フックはドライバによって実行され
る。これらは、図1のユーザコードジャーナルプログラ
ミングインタフェース74にアクセスする。開始及び終了
フックのためのジャーナルエントリは、タスクジャーナ
ルファイルの代わりにシナリオジャーナルファイルにロ
グされる。これは、タスクジャーナル72の代わりにシナ
リオジャーナル62に記入を行う唯一のユーザコードであ
る。注意すべきは、冗長レベルは、これがタスクジャー
ナルのエントリに影響を及ぼすのとは異なる方法でシナ
リオジャーナルエントリに影響を及ぼす。ドライバは開
始フック及び終了フックのスクリプトによって戻された
値を使用することにより前進すべきか否かを判定する。
この値がゼロ以外であるとき、ドライバは実行を中断す
る。機械シナリオドライバレベルで開始フック及び終了
フックを使用することにより、機械シナリオの実行中に
特定のホストのシステム資源を監視し、かつ特定の機械
シナリオに特有の他の特定のセットアップ項目及びクリ
ーンアップ項目を監視することができるスクリプトの実
行を開始及び中断することができる。また機械シナリオ
レベルでの開始フック及び終了フックはいずれかのユー
ザとして実行することができる特定のタスクのセットア
ップステップを実行する優れた位置であるが、あるセッ
トアップとクリーンアップとを実行するにはある最小の
ルートのユーザ権限を必要とする。これは、通常機械シ
ナリオドライバがルートの権限によって走り、タスクシ
ナリオドライバは恐らくこれによって動作していないか
らである。

【０２２２】(タスク) ユーザのタスクコードは、上述したように、4つのユー
ザコードジャーナルプログラミングコマンドを使用して
標準のタスクジャーナルにログすることができる。前に
述べた環境変数は、タスクコードが処理する必要がある
すべてのファイルを配置させるために使用することがで
きる。タスクコードがタスクドライバにリターンコード
を戻してこれがパスしたか失敗かを指示することが義務
づけられている。値がゼロであると成功を示し、これ以
外のすべての値は失敗を示す。次にタスクドライバはこ
のパス又は失敗の値をシナリオジャーナルに対して記入
する。タスクセットアップコードはそのインタフェース
に対して実際のタスクコードと非常に類似した動作を行
う。このタスクコードは上述したジャーナルプログラミ
ングインタフェースにアクセスする。タスクセットアッ
プコードに対するジャーナルのエントリはタスクジャー
ナルにログされる。タスクコードが実行時間中にソース
フオーマツト内にあるとき、タスクセットアップコード
の目的は、そのソースコードをコンパイルし、環境変数
AUSBINによって表される2進のコンパイルされたソース
コード用の実行時ディレクトリコードにこのソースコー
ドを置くことである。セットアップファイルのシンタッ
クスはストリング「.setup」が後に続くタスクの名前で
ある。これは、このタスクの binディレクトリ(環境変
数AUSCODEBINで示す)内になければならない。タスクド
ライバが走るときこのファイルが存在すれば、このファ
イルはタスクコードの実行の前に自動的に実行される。
ドライバはタスクセットアップコードによって戻された
値を使用することにより前進すべきか否かを判定する。
この値がゼロ以外のいずれかの値であれば、ドライバは
タスクコードを実行しない。タスクヘルプファイルイン
タフェースはドライバを介するオンライン、ソフトコピ
ー、タスクヘルプを可能にするために存在する。この形
式のヘルプを受け取るために、 ausdriverコマンドは
「h」コマンドラインフラグ及びタスクインスタンスフ
ァイルによって実行される。このインスタンスファイル
を使用することによりタスクヘルプファイルの予期され
るロケーションを判定し、次にこれをstdoutに送る。ヘ
ルプファイルのシンタックスは、ストリング「.help 」
が後に続くタスクの名前である。これはタスクの docデ
ィレクトリ(環境変数AUASCODEDOC によって示す)内にな
ければならない。このファイルは簡単な ASCIIファイル
である。特定のヘルプファイルのフオーマツトを有する
ことは優れたアイデアであるがこの種のヘルプファイル
内の情報は試験を行っている組織によって決まる。

【０２２３】(タスクジャーナル) タスクジャーナルファイルは ASCIIテキストファイルで
ある。シナリオ実行ステージの間に試験シナリオで実行
されるタスクの各インスタンスと関連するタスクジャー
ナルファイルは1つある。タスクジャーナルファイルの
すべてのエントリは同じレコードフオーマツトを有し、
4つのタスクジャーナル記入コマンド、auslog、auswarn
ing、auserror、及びaussevere によって作成される。
タスクジャーナルのフィールドのフオーマツトは表33の
通りである。

【０２２４】

【表３３】 フィールド 説 明 １ ジャーナルコマンドの最初の文字(b、l、w、e、またはs) ２ フォーマットYYMMDDの現在の日付 ３ フォーマットHHMMSSの現在の時刻 ４ 現在のホスト名(hostnameコマンドと同じ) ５ 現在の利用者($LOGNAME環境変数から) ６ 環境シナリオインスタンス名 ７ 環境シナリオの反復のカウント ８ 機械シナリオインスタンス名 ９ 機械シナリオの反復のカウント １０ 個人シナリオインスタンス名 １１ 個人シナリオの反復のカウント １２ タスクシナリオインスタンス名 １３ タスクシナリオの反復のカウント １４ ジャーナルコマンドからのテキスト例。

【０２２５】各フィールドは文字「｜」(パイプ文字)に
よって分離されている。第1のフィールドの前又は最後
のフィールドの次にはパイプ文字は存在しない。図28は
タスクジャーナルファイルがどのようなものであるかを
示す1例である。これは、シナリオジャーナルファイル
の例で走ったタスクshane.t.1 からの出力である。タス
クが走ると、冗長レベルは「7」に設定された。

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

【０２２７】

【表３４】 使用法; ausreport [ -t ｜-p｜-m｜-e ] journal＿file -t , タスクレベルで報告書を走らせる。これはデフォルトである -p, 個人レベルで報告書を走らせる -m, 機械レベルで報告書を走らせる。

【０２２８】Ausreportの例を表35に示す。

【０２２９】

【表３５】 $ ausreport -t scen.journal タスク 個 人 機 械 環 境 合否の％ try1.t.2 pers.p.1 1 0 100％ try2.t.1 pers.p.1 2 1 67％。

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

【０２３１】(ユーティリティ) (pkユーティリティ) AIXユーティリティpkを使用してディレクトリ構造を1つ
のファイルに圧縮する。この使用法の構文は PK <direc
tory> である。図30に示すように、PKコマンドを使用す
る結果、＜directory> で示すディレクトリ構造320が得
られ、これは AIX tarコマンド322及び AIX圧縮コマン
ド324によって処理される。このプロセスの結果、この
ディレクトリ構造内のすべてのファイルは1つのファイ
ルに結合され、次にこのファイルは圧縮される。このフ
ァイルがpkコマンドによって作成されたことを示すた
め、拡張子 .tar.Z 326を与える。pkコマンドの主な目
的は、シナリオディレクトリ構造のパス及びファイルの
ディレクトリ内のタスクシナリオディレクトリ構造の圧
縮を可能にすることである。pkユーティリティを使用す
る結果、システムディスクの資源に対して一段と最適な
記憶構造が得られる。

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

【０２３３】

【表３６】 $ cd/austin/runtime/engineering.e.1.910311.11055/pass $ pk rcp.t.2.*。

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

【０２３５】(unpkユーティリティ) ユーティリティunpkを使用することによりpkプロセスを
通過したファイルの圧縮を解除する。この使用法の構文
はunpk< packed＿file＿name> である。図31に示すよう
に、unpkコマンドを使用すると、＜ packed＿file＿nam
e＞ で示すファイル名328が得られ、これはAIX uncompr
essコマンド330及び tarコマンド332を介して走る。こ
のプロセスの結果、ファイルは圧縮されず、次に untar
されてディレクトリ構造334を作成する。ディレクトリ
構造334の名前は、.tar.Z拡張の付いていない＜ packed
＿file＿name> によって示される名前である。unpkコマ
ンドの主な目的は、図13に示すような以前にパックされ
た情報のパックを外し、これを検討できるようにするこ
とである。例えば、ドライバが自動的に検討する必要が
あるタスクディレクトリ構造を自動的にパックすれば、
unpkコマンドを使用することによりこれのパックを外
し、その通常のサイズ及び構造に戻すことができる。

【０２３６】(実行後のシナリオディレクトリ構造の例) この例は、シナリオ構造のパスディレクトリ内のパック
されたファイルのうち1つのパックの取り外しを示す。

【０２３７】

【表３７】 $ cd /austin/runtime/engineering.e.1.910311.110500/pass $ unpk *999*。

【０２３８】このunpkコマンドによって、図13のrcp.t.
1.claussen.999.1ディレクトリ構造184が復元する。図1
4はunpkコマンドの終了後の構造185を示す。

【０２３９】( ausstatユーティリティ) ausstatユーティリティは、これが標準タスクジャーナ
ルで見つけたauserror及び aussevereのジャーナルレコ
ードの数を戻す。このユーティリティの主な目的はタス
ク開発者の失敗率を判定する場合にこれらのタスク開発
者を支援することである。ユーザタスクコードがリター
ンコードをタスクドライバに渡すことは義務であるの
で、この目的のためにユーザタスクコードの終端におい
て ausstatコマンドを使用することができる。ausstat
をこの目的のために使用するとき、これはすべてのause
rror及び aussevereレコードをジャーナルファイル内で
カウントするので、予防策を使用しなければならない。
見いだした実際のエラーの数を表すために ausstatが見
つけた数を希望するなら、2つのauserrorコマンドを使
用して1つのエラーを記述してはいけない。1つのエラー
を記述するために2本以上のラインが必要であれば、1つ
又は2つ以上の auslogsの前にあるauserror又は aussev
ereを使用する。

【０２４０】(C言語のインタフェース) 以下は ausstat機能に対するC言語のインタフェースの
ためのANSI Cプロトタイプの定義である。 int ausstat( void ); ユーザタスクコードはライブラリ/austin/tools/lib/li
baus.a. とリンクすることによって ausatat機能にアク
セスすることができる。

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

【０２４２】

【表３８】 main() { auslog( "Doing test 1." ); if ( test1() == SUCCESS ) auslog( "Test 1 successful. " ); else auserror( "Test 1 failed." ); auslog( "Doing test 2." ); if ( test2() == SUCCESS ) auslog( "Test 2 successful." ); else { aussevere( "Test 2 failed, rest of tests are dependent." ); auslog( "Test was a total of %d error(s)," , ausstat() ); exit(ausstat() ); } auslog( "Doing test 3." ); if ( test3() == SUCCESS ) auslog( "Test 3 successful." ); else auserror( "Test 3 failed." ); auslog( "Exiting user task code." ); auslog( "There was a total of %d error(s).", ausstat() ); exit( ausstat() ); } 。

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

【０２４４】

【表３９】

【０２４５】以前の失敗のために試験ケースが中止され
たため、実行しなかった。

【０２４６】(シェル言語インタフェース) ausstatコマンドを出すことによって簡単に ausstatコ
マンドのシェルスクリプトインタフェースを使用する。
ausstatシェルインタフェースはauserror又はaussever
eのジャーナルエントリの数を2つの方法、すなわちこの
値をstdoutに反映させる方法及びそのリターンコードを
適正な値に設定する方法によって戻す。表40は上述の例
のコードに対応するシェル言語である。

【０２４７】

【表４０】 auslog "Doing test 1." test1 if [ "$? = "0" ] ; then auslog "Test 1 successful. " else auserror "Test 1 failed." fi auslog "Doing test 2." test2 if [ "$? = "0" ]; then aulog "Test 2 successful. " else aussevere "Test 2 failed, rest of tests are dependent." auslog "There was a total of 'ausstat' error(s). " exit 'ausstat' fi auslog "Doing test 3." test2 if [ "$? = "0" ]; then auslog "Test 3 successful. " else auserror "Test 3 failed. " fi auslog "Exiting user task code." auslog "There was a total of 'ausstat' error(s)." exit 'ausstat' 。

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

【０２４９】最後に、図37はこの多重コンピュータデー
タ処理システムで使用されるデータ処理システム342の
好適な実施例を示す。中央処理装置(CPU)510はバス512
を介して読出し専用メモリ(ROM)516、ランダムアクセス
メモリ(RAM)514、入出力(I/O)アダプタ518、通信アダプ
タ534、ユーザインタフェースアダプタ522及びディスプ
レイアダプタ536に接続される。I/Oアダプタ518によ
り、データを記憶する不揮発性マス記憶装置520のよう
な種々の入力/出力装置(例えば、直接アクセス記憶装置
(DASD)、テープ、ホログラフ記憶装置、カートリツジ
等)にバス512をインタフェースすることができる。通信
アダプタ534により、バス512と組み合わせてCPU510から
通信ネットワーク348へのデータフローを形成すること
ができる。表示アダプタ536により、データ又は他の情
報をディスプレイ装置538に表示することができる。ユ
ーザインタフェースアダプタ522により、キーボード52
4、マウス又は指示装置532、キーパッド526又はスピー
カ528のような種々のユーザ(個人)入力/出力装置を制御
することができる。このデータ処理システム342は上述
したようにプロセス間通信を行い、さらに図32に示すよ
うな多重コンピュータデータ処理システムで使用するこ
とができる。

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

【０２５１】

【発明の効果】上述のように本発明によれば、連続的に
統合しかつ少なくとも1つのシナリオを有するレベル
と、シナリオを表す少なくとも1つのデータファイル
と、データファイル内に格納されているデータに基づい
て一段と高いレベルから一段と低いレベルを呼び出す手
段とを設けることにより、多数のホストコンピュータシ
ステムを含む大規模なネットワークシステムレベルの統
合試験に必要な大規模試験環境用のフレームワークを提
供することができる。

【図面の簡単な説明】

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

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

【図３】図3は直接アクセス記憶装置(DASD)上に記憶さ
れた試験用足場データ構造のトップレベルのディレクト
リを示す略線図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図３２】図32は多重コンピュータデータ処理システム
を示す略線図である。

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

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

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

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

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

【符号の説明】

10……シナリオドライバの対話アーキテクチャモデル、
12、230、232、240、244、250、252、260……ドライ
バ、16……タスクシナリオ、18……個人シナリオ、20…
…機械シナリオ、22……環境シナリオ、26……タスクイ
ンスタンス、28……個人インスタンス、30……機械イン
スタンス、32、234……環境インスタンス、50……構成
要素の対話アーキテクチャモデル、52……シナリオ構築
ツール、54……シナリオインスタンスファイル、56……
シナリオ定義ファイル、58……シナリオ、60……シナリ
オドライバ、62……シナリオジャーナル、64……報告書
ジェネレータ、66……報告書、68……ユーザタスクコー
ド、70、74……アプリケーションプログラムインタフェ
ース(API)、72……タスクジャーナル、342……データ処
理システム、348……ネットワーク、510……中央処理装
置(CPU)、514……RAM、516……ROM、518……I/Oアダプ
タ、520……非揮発性マス記憶装置、522……ユーザイン
タフェースアダプタ、524……キーボード、526……キー
パッド、528……スピーカ、532……指示装置、534……
通信アダプタ、536……表示アダプタ、538……ディスプ
レイ装置

───────────────────────────────────────────────────── フロントページの続き (72)発明者 クリストフア・シエーン・クラウゼン アメリカ合衆国、テキサス州78758、オ ーステイン、＃2322、ウエルズ・ブラン チ・パークウエイ 1801番地 (72)発明者 ジエームズ・オテイス・コツクス アメリカ合衆国、テキサス州78750、オ ーステイン、スプリツト・レール・パー クウエイ 12526番地 (56)参考文献 特開 平２−44421（ＪＰ，Ａ) 特開 昭62−276635（ＪＰ，Ａ) インターフェース，13［１］ （昭62 −１−１） ＣＱ出版社，Ｐ．181−185

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】複数のレベルを有する階層的試験環境を提
   供するシステムにおいて、 タスクファイル内の格納データに基づいてユーザタスク
   を呼び出す手段を有するタスクレベルドライバと、 上記タスクレベルドライバに結合され、中間ファイル内
   の格納データに基づいて上記タスクレベルドライバを呼
   び出す手段を有する中間ドライバと、 上記中間ドライバに結合され、トップレベルファイル内
   の格納データに基づいて上記中間ドライバを呼び出す手
   段を有するトップレベルドライバとを具えることを特徴
   とするシステム。
2. 【請求項２】上記トップレベルドライバは上記中間ファ
   イルの呼び出しの結果に基づいてジャーナルファイルを
   生成する、請求項１記載のシステム。
3. 【請求項３】複数のレベルを有する階層的試験環境を提
   供するシステムにおいて、 タスクファイル内の格納データに基づいてユーザタスク
   を呼び出す手段を有するタスクレベルドライバと、 上記タスクレベルドライバに結合され、第１の中間ファ
   イル内の格納データに基づいて上記タスクレベルドライ
   バを呼び出す手段を有する第１の中間ドライバと、 上記第１の中間ドライバに結合され、第２の中間ファイ
   ル内の格納データに基づいて上記第１の中間ドライバを
   呼び出す手段を有する第２の中間ドライバと、 上記第２の中間ドライバに結合され、トップレベルドラ
   イバファイル内の格納データに基づいて上記第２の中間
   ドライバを呼び出す手段を有するトップレベルドライバ
   とを具えることを特徴とするシステム。
4. 【請求項４】上記トップレベルドライバは上記第２の中
   間ファイルの呼び出しの結果に基づいてジャーナルファ
   イルを生成する、請求項３記載のシステム。
5. 【請求項５】試験ケースを駆動する方法において、 インスタンス属性をファイルから読み出すステップと、 上記ファイル内で見い出された一切のユーザ定義属性を
   システム環境変数に置くステップと、 現在のレベルのためのシナリオドライバ構成属性を決定
   するステップと、 開始フックコードを実行するステップと、 上記インスタンス属性及び上記シナリオドライバ構成属
   性に基づいて次のレベルのドライバを実行するステップ
   と、 終了フックコードを実行するステップとを含むことを特
   徴とする方法。
6. 【請求項６】試験ケースを駆動するシステムにおいて、 インスタンス属性をファイルから読み出す手段と、 上記ファイル内で見い出された一切のユーザ定義属性を
   システム環境変数に置く手段と、 現在のレベルのためのシナリオドライバ構成属性を決定
   する手段と、 開始フックコードを実行する手段と、 上記インスタンス属性及び上記シナリオドライバ構成属
   性に基づいて次のレベルのドライバを実行する手段と、 終了フックコードを実行する手段とを具えることを特徴
   とするシステム。