OpenVMS
システム管理者マニュアル


前へ 次へ 目次 索引


19.8.2 装置テスト・フェーズ

装置テスト・フェーズには,ディスク,磁気テープ,ライン・プリンタ,およびターミナルなどの装置のタイプ別のテストが含まれます。 この項では,装置テスト・フェーズについて説明し,単一の装置をテストするための指示を示します。装置テスト・フェーズ全体を独立させて実行するための情報については, 第 19.4.1 項 を参照してください。

19.8.2.1 装置フェーズの動作

UETP 装置テスト・フェーズは,実行可能イメージであるフェーズ・コントローラ UETPHAS00 を起動します。 このイメージは,テストを行う装置コントローラごとに,独立プロセスを 1 つずつ作成します。たとえば,システムに 3 つのターミナル・コントローラ, 1 つのライン・プリンタ,および 2 つのディスク・コントローラが存在する場合,このイメージは 6 つの独立プロセスを作成します。同時に,独立プロセスは,さまざまなタイプの装置をテストするイメージを実行します。

UETP の初期化フェーズでは,UETINIDEV.DAT と呼ばれるファイルと UETCONT00.DAT と呼ばれるファイルが作成されます。 UETINIDEV.DAT には,OpenVMS がサポートするシステム中のコントローラおよび関連装置に関するデータが入っています。 UETCONT00.DAT は,装置テスト・イメージをテスト可能な各コントローラに関連付けます。

UETPHAS00 は UETCONT00.DAT 中の情報を使って,作成した各装置プロセスに渡す装置コントローラ名を見つけます。 UETPHAS00 は,個々のテストへの SYS$INPUT であるメールボックスにコントローラ名を書き込みます。各独立プロセスはそのデータを使って,テストを行うコントローラを決定します。次に,テスト・イメージは UETINIDEV.DAT から装置コントローラおよびそのコントローラ上でテスト可能なすべてのユニットを探します。すべてのコントローラ上のすべての装置のテストが完了すると,フェーズ・コントローラは終了します。

UETCONT00.DAT は UETP の実行終了時に自動的に削除されるので, UETP.COM を起動しなければ装置フェーズは実行できません。しかし,個々のテスト・イメージだけなら実行できます。 UETINIDEV.DAT は,ユーザが削除するまでSYS$TEST に存在します。

19.8.2.2 単一装置テストの実行

この項で述べる個々のテストを実行するには,まず, SYSTEST アカウントにログインしなければなりません。また,UETINIDEV.DAT のコピーが存在しなければなりません。前回の実行によるこのファイルのコピーが存在しなければ,このファイルを作成してください (UETINIDEV.DAT は,完全な UETP の実行または装置テスト・フェーズの実行によって作成されます)。単一装置テストを実行するときには,ログ・ファイルは作成されないので注意してください。このテストはすべての出力をユーザのターミナルに送ります。

特定の装置タイプに対してだけテストを行う場合は, 表 19-1 (VAX システムの場合) または 表 19-2 (Alpha システムの場合) からテスト・イメージ名を選択し,そのイメージを実行することによって,特定のコントローラだけをテストすることができます。次に例を示します。


$ RUN UETTTYS00
Controller designation?: TTB

UETP は,コントローラ指示子および装置コードの入力を求めます。ユーザ自身のターミナルをテストするのでなければ,コントローラ名を明示的に示さなければなりません。ターミナル・テストを実行する場合, Return を押せば,ユーザ自身のターミナルだけをテストできます。

何回も実行を繰り返す場合は,論理名 CTRLNAME を定義する方が便利です。


$ DEFINE CTRLNAME TTB
$ RUN UETTTYS00

このようにコントローラ名を定義すると,テスト完了後も論理名 CTRLNAME は割り当てられたままになります。 論理名の割り当てを解除するには,次のように,DCL の DEASSIGN コマンドを使用します。


$ DEASSIGN CTRLNAME

19.8.2.3 UETINIDEV.DAT の形式

UETINIDEV.DAT ファイルは ASCII 順編成ファイルなので,必要に応じて入力したり編集したりすることができます。このファイルの内容は,次のコマンドを入力することによって表示することができます。


$ TYPE UETINIDEV.DAT
 
DDB x ddd
UCB y uuuuu nnnnnnnnn.nnn
END OF UETINIDEV.DAT

この例では,次のようにシンボルが定義されています。

シンボル
x 当該コントローラにテスト可能なユニットがある場合は T。当該コントローラでテストを行わない場合は N。
y ユニットがテスト可能な場合は T。ユニットがテスト可能でない場合は N。
ddd 装置コントローラ名。たとえば,DUA。
uuuuu 装置ユニット番号。たとえば,25。
nnnnnnnnn.nnn ユニットに対する UETP 装置テスト名。たとえば,UETDISK00.EXE。

UETINIDEV.DAT には,ユーザのシステムに接続されている,またはユーザのシステムから見ることができる各コントローラに対する DDB (装置データ・ブロック) 行が入っています。 DDB 行の後には,当該コントローラに接続された各ユニットに対する UCB (ユニット制御ブロック) 行があります。 DDB 行と UCB 行の両方がその装置がテスト可能であることを示すときに限り,装置テストは特定の装置をテストできます。

19.8.2.4 ループ・モードによるテストの実行

ある装置に対して特に負荷をかけてテストしたい場合は,ループ・モードで装置テストを実行します。このモードでは,テストが無限に実行されます。次に例を示します。


$ DEFINE MODE LOOP
$ RUN UETDISK00
Controller designation?: DRA
%UETP-I-TEXT, End of pass 1 with 980 iterations at 22-JUN-2000 16:18:51:03
 
^C

ループ・モードのテストを終了するには,Ctrl/C を使用しなければなりません。 Ctrl/Y を使用すると,UETP はクリーンアップ処理を行いません。

19.8.2.5 個々の装置テストの機能

ディスク・テストは,システム中のディスクごとにファイルを 2 つずつ割り当て,そのファイルにランダムなデータ・ブロックを書き込みます。 次に,テストはそのデータをチェックし,エラーがあれば SYS$OUTPUT に報告し,最後に,そのディスク・ファイルを削除します。

クラスタ環境でディスク・テスト・フェーズを実行する場合,テストを行うシステムにマウントされているすべてのディスクがアクセスされます。このとき,テストされるディスクのユーザにとってディスク領域の不足という問題が発生するかもしれません。したがって,遠隔ノード上のユーザ (ローカル・システムのユーザとディスクを共有しているユーザ) には,使用中のディスクが UETP によってテストされるということを警告しておくべきです。

磁気テープ・テストは,システム中のすべての磁気テープ・ドライブをテストします。 このテストは,マウントされているすべての磁気テープ上に大きなファイルを作成し,その中にさまざまなサイズの順次レコードを複数書き込みます。さらに,レコードの書き込み後,磁気テープを巻き取り,書き込んだレコードを検査し,最後に,磁気テープを再初期化します。

ターミナルおよびライン・プリンタ・テストでは,数ページまたは数画面かの出力が作成され,各ページまたは画面にヘッダ行および ASCII 文字によるテスト・パターンが出力されます。ヘッダ行には,テスト名,装置名,データ,および時間が出力されます。

実験周辺機器アクセラレータ (LPA11--K) の場合,テスト・イメージによって LPA11--K の I/O バスの構成が決定されます。テスト・イメージはすべてのタイプのマイクロコードを LPA11--K にロードし,LPA--K の I/O バス上のすべての装置に対してデータの読み込みまたは書き込みを行います。

通信装置テストは,転送メッセージ・バッファをランダムなデータでいっぱいします。次に,ループバック・モードを使って,メッセージを何度か転送および受信します。ループ・バックされたデータが正しいかどうかをチェックするために, AST ルーチンが $QIO 読み込みと関連付けられ,受信したメッセージと転送したメッセージが比較されます。この手順は,異なる長さのメッセージを使って繰り返されます。

インタフェース装置テストは,装置を保守モードでテストし,ランダムなデータを書き込み,最後にそのデータを検査します。

イーサネット・アダプタ・テストは,装置に対して自己テスト診断を行います。また,このテストは,さまざまなアダプタ・モード (内部ループバックおよび外部ループバックなど) を使用するテスト・データを使って,読み込みおよび書き込み作業を行います。

ベクタ・プロセッサ装置テストは,単純なベクタ・スカラ算術演算およびベクタ・ベクタ算術演算を行い,その結果と予期された値を比較します。このテストは,また,ベクタ関連拡張システム・サービスを使って,強制的に算術例外条件およびメモリ管理例外条件をシステムに発生させます。

表 19-1 に,装置テスト・イメージおよび VAX システム上でテストされる装置のリストを示します。

表 19-1 装置テスト (VAX のみ)
テスト・イメージ名 テストされる装置
UETDISK00.EXE ディスク
UETTAPE00.EXE 磁気テープ・ドライブおよびテープ・カートリッジ・ドライブ
UETTTYS00.EXE ターミナルおよびライン・プリンタ
UETLPAK00.EXE LPA11--K
UETCOMS00.EXE DMC11, DMR11
UETDMPF00.EXE DMF32, DMP11
UETDR1W00.EXE DR11--W
UETDR7800.EXE DR780, DR750
UETCDRO00.EXE RRD40, RRD42, RRD50
UETUNAS00.EXE イーサネット・アダプタ
UETVECTOR.EXE ベクタ・プロセッサ,VVIEF

表 19-2 に,装置テスト・イメージおよび Alpha 上でテストされる装置のリストを示します。

表 19-2 装置テスト (Alpha のみ)
テスト・イメージ名 テストされる装置
UETDISK00.EXE ディスク
UETTAPE00.EXE 磁気テープ・ドライブおよびテープ・カートリッジ・ドライブ
UETTTYS00.EXE ターミナルおよびライン・プリンタ
UETCDRO00.EXE RRD42
UETUNAS00.EXE イーサネット・アダプタ

19.8.3 システム・ロード・テスト・フェーズ

システム・ロード・テストの目的は,システム資源を同時に要求する複数のターミナル・ユーザをシミュレートすることです。 システム・ロード・テストは,さまざまなコマンド・プロシージャを実行する独立プロセスを複数作成します。この結果は,ファイル UETLOAD00.DAT に出力されます。各プロセスは,ターミナルにログインしたユーザをシミュレートします。つまり,各プロシージャ内のコマンドは,ターミナルからユーザが入力したコマンドと同じタイプのコマンドです。ロード・テストは連続して複数の独立プロセスを作成し,各独立プロセスがそれぞれのコマンド・プロシージャを同時に実行します。つまり,独立プロセスと同じ数のユーザが同時にターミナルからコマンドを入力するのと同じような影響をシステムに与えます。このようにして,ロード・テストは,通常のシステムにおける使用と同じような環境を作り出します。

ロード・テストは,論理名 LOADS を使って,作成する独立プロセスの数を決定します。 UETP コマンド・プロシージャを起動すると,シミュレートするユーザの人数,つまり,作成する独立プロセスの数を尋ねてきます ( 第 19.4.3 項 を参照)。この数は,使用しているシステムのメモリ量,スワップ領域,およびページング領域を考慮して決める必要があります。このときのユーザの応答によって,グループ論理名 LOADS が定義されます。

UETP マスタ・コマンド・プロシージャは,終了フェーズにおいて,テストによって行われたグループ論理名の割り当てを解除します。 UETP パッケージが正常終了しなかった場合のみ,グループ論理名 LOADS の割り当ては解除されません。

作成する独立プロセスの数にもよりますが,ロード・テストによって実行されるコマンド・プロシージャは大量の出力を生成します。各独立プロセス (すなわちユーザ) に対して,テストは UETLOnnnn.LOG と呼ばれる出力ファイルのバージョンを作成します (nnnn は数値文字列)。コンソールには,ロード・テストの進行を表す状態情報だけ表示されます。

ロード・テストが完全な UETP の一部として実行される場合も,独立したフェーズとして実行される場合も, UETP は UETLOnnnn.LOG ファイルを結合し,出力をファイル UETP.LOG に書き込み,最後に,個々の出力ファイルを削除します。

システム・ロード・テストを独立したフェーズとして実行するには,スタートアップ・ダイアログの中から LOAD を選択します ( 第 19.4.1 項 を参照)。

19.8.4 DECnet for OpenVMS テスト・フェーズ

DECnet for OpenVMS ソフトウェアがユーザの OpenVMS システムに組み込まれている場合,完全な UETP の実行によって, DECnet ハードウェアおよびソフトウェアが自動的にテストされます。通信装置は DECnet に割り当てられ, DECnet 装置は UETP 装置テストでテストできないので, DECnet for OpenVMS または他のアプリケーションがその装置を割り当てている場合, UETP はイーサネット・アダプタをテストしません。 DECnet テストの開始時,DECnet ノードおよびサーキット・カウンタはゼロにされ,実行時の障害監視が可能になります。

他の UETP フェーズと同様に, DECnet for OpenVMS フェーズを独立させて実行することもできます。 第 19.4.1 項 を参照してください。

19.8.4.1 環境

DECnet for OpenVMS テストは,DECnet がサポートするすべてのノード・タイプ (ルーティング・ノードおよび非ルーティング・ノードを含む) に接続された OpenVMS システム,および若干異なるタイプのオペレーティング・システム (RSTS,RSX,TOPS,RT など) 上で正常に動作します。遠隔システムには,システム間でファイルをコピーするための省略時のアクセス権が必要です。DECnet フェーズでは,次のテストを行います。

テストがサポートする通信回線の数には制限はありません。ある隣接ノードにおけるテストを,通常の通信転送率で 2 分以上継続してはなりません。

注意

UETP は,ユーザのシステムが FAL オブジェクトに対して省略時のアクセス権を持っていることを想定しています。しかし,ネットワーク構成コマンド・プロシージャ NETCONFIG.COM は,省略時の設定で,FAL オブジェクトに対するアクセス権を提供しません。 NETCONFIG.COM が提供する省略時の設定で DECnet ソフトウェアをインストールする場合,UETP DECnet フェーズでエラー・メッセージが表示されることがあります。このエラー・メッセージは無視してかまいません。詳細は 第 19.7.13 項 を参照してください。

19.8.4.2 DECnet フェーズの動作

UETP (UETPHAS00.EXE の制御下において) は,ファイル UETDNET00.DAT を読み込み, DECnet for OpenVMS フェーズ中に次の手順を行います。

  1. ネットワーク制御プログラム (NCP) の LOOP EXECUTOR コマンドを複数回実行し,UETP が動作しているノードをテストする。

  2. NCP を使って,コマンド SHOW ACTIVE CIRCUITS を実行する。この結果は,UETININET.TMP に書き込まれ,そこから UETP はデータ・ファイル UETININET.DAT を作成する。UETININET.TMP ファイルには,ON 状態であるが遷移状態でないサーキットについての次の情報が入っている。


    UETININET.TMP ファイルは,テストする装置を決定するために, DECnet フェーズ全体で使用される。

  3. UETININET.TMP ファイルを使って,テスト可能なサーキットごとに NCP コマンド・プロシージャを 1 つ作成する。各コマンド・プロシージャには,サーキット・カウンタおよびノード・カウンタをゼロにし,ファイルのコピーによってサーキットおよび隣接ノードをテストする複数の NCP コマンドが入っている。

    注意

    カウンタをゼロにしたくない場合は, DECnet for OpenVMS ソフトウェアをテストしないでください。

  4. 手順 3 のコマンド・プロシージャを並行して実行し,ユーザ負荷が高い状態をシミュレートする。シミュレートされるユーザ負荷は,以下の値のうち少ない方である。

  5. プログラム UETNETS00.EXE を実行する。このプログラムは UETININET.DAT ファイルを使って,テスト可能な各サーキットに対するサーキット・カウンタおよびノード・カウンタをチェックする。カウンタが劣化を示している場合 (つまり,ゼロではない場合),その名前と値がコンソールに報告される。ログ・ファイルには,すべてのカウンタが報告されるが,劣化を示すカウンタだけはコンソールにも報告される。次に,UETNETS00 出力の例を示す。


    %UETP-S-BEGIN, UETNETS00 beginning at  22-JUN-2000 13:45:33.18 
    %UETP-W-TEXT, Circuit DMC-0 to (NODENAME1) OK. 
    %UETP-I-TEXT, Node  (NODENAME2) over DMC-1 response timeouts = 1. 
    %UETP-I-TEXT, Circuit DMC-1 to (NODENAME2) local buffer errors = 34. 
    %UETP-I-TEXT, Node  (NODENAME3) over DMP-0 response timeouts = 3. 
    %UETP-S-ENDED, UETNETS00 ended at 22-JUN-2000 13:45:36.34 
    


    カウンタの劣化が必ずしもエラーの原因となるわけではないので,テストが成功したかどうかは,システムではなく,ユーザが判断することである。次のカウンタは劣化を示す。
    サーキットの場合


    ノードの場合


前へ 次へ 目次 索引