JP3109054B2 - エラー回復サブシステムおよびエラー回復方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はデータ処理システムにお
けるソフトウェア・エラーまたはハードウェア・エラー
からの回復に関するものである。さらに具体的には、本
発明は、再構成が容易なエラー回復サブシステム、およ
びエラーから回復するための方法、およびそのためのプ
ログラム装置に関するものである。

【０００２】

【従来の技術】コンピュータまたはデータ処理システム
は、一般にプロセッサ、記憶装置、入出力装置、通信装
置等の複数のハードウェア構成要素を含む。さらに、そ
のようなシステムは、オペレーティング・システム、ア
プリケーション・サポート・システム、アプリケーショ
ン、処理、データ構造等の複数のソフトウェア構成要素
をも含む。これらのハードウェアまたはソフトウェア構
成要素のいずれか１つに障害またはエラーがあった場
合、コンピュータ・システム動作の結果が無効になる可
能性がある。したがって、そのようなエラーの発見およ
び訂正に多大な努力が投入されてきた。

【０００３】データ処理システムでエラーが発見される
と、システムを作業状態に復元するため、特定の回復動
作または一連の動作が生成される。これらの動作には、
ソフトウェア処理の再始動、データ域の再初期設定、中
央演算処理装置の再ブート、個々のハードウェアのリセ
ット等が含まれる。複雑なシステムでは、システムのど
の基本ハードウェアまたはソフトウェア構成要素が故障
していて、回復動作の手当てを必要としているかを実時
間で判定することが困難な場合が多い。データ処理シス
テム全体の使用可能性は、完全な作業状況が急速に再回
復できるかどうかに依存するので、システム回復時間を
最小にするための効率的な戦略が必要である。

【０００４】検出されたエラーから回復するための１つ
の既知の方法は、全ての既知のシステム変数を調べて、
データ処理システムの状態を正確に決定することであ
る。次に、実際のシステム状態を、一連の回復動作が知
られている全ての可能なシステム状態と比較する。これ
らの可能なシステム状態は「エラー状態」と呼ばれ、シ
ステム・メモリに保持される。実際のシステム状態がエ
ラー状態と一致した場合は、そのようなエラー状態に関
連する一連の回復動作が呼び出される。

【０００５】エラー回復サブシステムを実施するために
必要な詳細論理は複雑であり、しばしば多大な開発努力
を必要とする。データ処理システムには多数のシステム
変数があるので、検出可能でなければならないシステム
状態と、メモリに保持しなければならないエラー状態は
莫大な数にのぼる。さらに、データ処理システムの耐用
期間中に新たなエラー状態がしばしば識別されるが、エ
ラー回復サブシステムの論理に対する追加および変更は
非常に困難であり、高価である。例えば、システムをプ
ログラミングするために使用される論理は、新たなエラ
ー状態が発見されたとき、およびそれらに関連する一連
の回復動作を保持し、使用するように再設計しなければ
ならない。さらに、データ処理システムの構成要素の老
化により、あるエラー状態に対する適当な一連のエラー
回復動作が変化するとき、再設計が必要である。したが
ってエラー回復サブシステムの設計および保守は費用が
かかり、かつデータ処理システムの耐用期間中に得られ
る経験に対する反応が鈍い傾向がある。

【０００６】データ処理システムの回復時間を最小にす
るために使用されるもう１つの戦略は、検出されたエラ
ー状態を引き起こした可能性がある最も単純、かつ最も
初歩的な構成要素のレベルで回復を試みることである。
この最低レベルの構成要素の再初期設定でエラー状態が
なくならなかった場合は、次に高いレベルの（より大き
く、より包括的な機能を有する）構成要素を再初期設定
する。エラーが依然としてなくならない場合は、エラー
状態がなくなるまで、さらに高いレベルの構成要素を再
初期設定する。所定のタイムアウト期間の後、またはエ
ラーに関係する可能性がある最高レベルの構成要素を再
初期設定した後もエラー状態が残っている場合は、エラ
ー回復サブシステムが故障したものと見なし、警報を使
って、担当者に訂正処置を取るよう警告する。エラーか
ら回復するためのこの種の多段手順戦略は、多段エラー
回復システムと呼ばれる。

【０００７】米国特許第４８６６７１２号は、幾分変更
可能なエラー回復サブシステムを開示している。このエ
ラー回復サブシステムは、ユーザによる編集が可能なテ
ーブルおよびユーザによる編集が可能なアクション・テ
ーブルを含む。エラー・テーブルは可能な各エラー状態
毎に１つの項目を有し、そのエラー状態を訂正するため
に取られる可能性がある各回復動作シーケンス毎に１つ
のカウント増分を含む。アクション・テーブルは、各回
復動作シーケンスを一義的に識別する動作コードと、可
能な各回復動作シーケンスに関するエラー・カウントし
きい値を含む。このサブシステムは、可能な各回復動作
シーケンス毎のエラー・カウント増分を累計し、対応す
るしきい値を越えたとき、関連する回復動作シーケンス
を開始させる。このエラー・テーブルおよびアクション
・テーブルは、ユーザによる編集が可能なので、新たな
エラー状態を考慮し、既知の別の回復動作シーケンスを
特定のエラー状態と関連づけ、エラー・カウントしきい
値を調節するために、サブシステムを容易に変更するこ
とができる。しかし、システム状態を決定する際に非常
に多数のサブシステム変数をどのように処理するかはは
っきりしない。さらに、動作コードを変更することによ
り、あるエラー状態に関連する回復動作シーケンスを
（ある指定されたシーケンスから別の指定されたシーケ
ンスに）変更することはできるが、システムが老化した
とき新たな回復動作シーケンスを作り出すための簡単な
方法はなく、その代りに、論理を再設計しなければなら
ない。エラー回復システムがソフトウェア／マイクロコ
ード・プログラミングとして実施されている場合でも、
そのようなプログラムを導入前に変更し、次いで新しい
コード・ロードとしてコンパイルし直さなければなら
ず、したがってシステム維持が遅くなる。さらに、上記
特許に開示されているエラー回復サブシステムは、多段
エラー回復システムに限定される。

【０００８】

【発明が解決しようとする課題】本発明の主目的は、デ
ータ処理システム用の改良されたエラー回復サブシステ
ム、およびエラーから回復するための改良された方法、
およびそのためのプログラム装置である。

【０００９】本発明の他の目的は、システム状態の数を
定義する際の複雑さを低減するエラー回復サブシステ
ム、およびエラーから回復するための方法、およびその
ためのプログラム装置である。

【００１０】本発明の他の目的は、データ処理システム
の構成の変化、システム状態の新たな定義、新たなエラ
ー状態、およびエラー状態に応じて必要とされる新たな
回復動作シーケンスを考慮するために容易に変更するこ
とができるエラー回復サブシステムである。

【００１１】

【課題を解決するための手段】本発明の上記その他の目
的は、汎用エラー回復サブシステムによって達成され
る。このエラー回復サブシステムは、監視されるどのハ
ードウェアにでも使用できるように容易に変更できる点
で汎用である。このエラー回復サブシステムは、システ
ム状態、エラー状態、およびシステム状態とエラー状態
の比較に応じて取られる回復動作シーケンスを定義する
ための規則を含む、ユーザによる編集が可能なファイル
を使用する。エラー状態は、システム状態とエラー状態
の不必要なビット比較をなくすため、ドントケア変数を
含む。回復動作シーケンスは、一組の基本的回復動作に
対するインデックスを使って指定され、したがって新た
な回復動作シーケンスの追加が単純になる。システム状
態、エラー状態、および回復動作シーケンスがユーザに
よる編集が可能なファイル内で定義されるので、エラー
回復方式の変更が、エラー回復サブシステムのプログラ
ム・コードをコンパイルし直さずに行なうことができ
る。したがってエラー回復サブシステムに対するそのよ
うな変更を実時間で行なうことができる。エラーから回
復するための方法およびそのためのプログラム装置も開
示される。

【００１２】

【実施例】図面において、様々な図で同じ参照番号は同
じ特徴および構成要素を示す。ここでは包括的エラー回
復サブシステムを光ディスク・ライブラリ中で実施され
たものとして説明するが、どんなデータ処理システムで
実施することもできる。自動記憶ライブラリは、磁気テ
ープ、磁気ディスク、光ディスク等の取外し可能なデー
タ記憶媒体を保持するための複数の記憶セル、ロボット
式ピッカ機構、および１つまたは複数の内部周辺記憶装
置を含む。各データ記憶媒体は、ピッカによる操作が容
易なように、カセットまたはカートリッジ・ハウジング
に収容することが可能である。ピッカは、コマンドに基
づいて動作し、人手を借りずに、記憶セルと内部周辺記
憶装置の間でデータ記憶媒体を移動させる。データ記憶
媒体が内部周辺記憶装置にマウントされると、システム
が要求する間、データをその媒体に書き込み、またはそ
の媒体から読み出すことができる。データは１つまたは
複数のファイルの形で媒体上に記憶され、各ファイルは
論理データ・セットである。光ディスク・ライブラリは
一種の自動記憶ライブラリである。

【００１３】図２ないし図５において、様々な図で同じ
番号は同じ特徴および構造要素を示す。本発明の自動記
憶ライブラリを、光ディスク・ライブラリ中で実施され
たものとして説明する。図１ないし図４に、こうした光
ディスク・ライブラリの様々な図を示す。ライブラリ１
は、ライブラリの作動部分のほとんどを囲むハウジング
２を含み、ハウジング２は内部にアクセスするための前
後のドア板（図示せず）を有する。ライブラリ１はさら
に、複数の光ディスク記憶セル３と、複数の内部光ディ
スク・ドライブ４を含む。各記憶セル３は、片面または
両面にデータを記録した光ディスク１枚を格納すること
ができる。ディスクの片面に記憶されたデータを「ボリ
ューム」と称する。好ましい実施例では、ライブラリ１
は、７２個の記憶セルからなる列２列に配列された１４
４個の記憶セル３と、最大４台の光ディスク・ドライブ
４を含む。光ディスクは、アブレーティブ型、位相変化
型、光磁気式、その他の方式の光記録層を含み、光ディ
スク・ドライブ４との整合性をもつ限りで、読取り専
用、追記形、または書込み可能型のいずれでもよい。そ
の上、光ディスクは、ラセン形または同心円状のトラッ
ク・パターンに記録することができる。記録フォーマッ
トの詳細は本発明の一部ではなく、当技術分野で既知の
どんなものでもよい。ロボット式ピッカ５は、１個のグ
リッパ６を含み、グリッパ６は、記憶セル３またはドラ
イブ４のいずれにある光ディスクにもアクセスでき、そ
れらの光ディスクをそれらの間で移動することができ
る。好ましい実施例では、光ディスクは、グリッパ６で
扱いやすいようにカートリッジに入れてあり、その形状
因子が１３．３ｃｍ（５ １／４インチ）であるが、他
の実施例では、ドライブ４およびグリッパ６に整合する
ものならどんな寸法でもよい。

【００１４】図２にはハウジング２の正面は示してない
が、ライブラリ１のいくつかの部分が、オペレータがア
クセスできるようにハウジング２の正面を置いて突き出
している。それらの部分は、コンソール・ドア７の一部
であり、電力インジケータ／スイッチ８、入口／出口ス
ロット９、外部光ディスク・ドライブ１０、コンソール
１１、キーボード１２のすべてまたは一部を含む。コン
ソール・ドア７は、図３に示すように、必要なときその
背後にアクセスできるように、外へ開くことができる。
スロット９は、光ディスクをライブラリ１に差し込み、
またはライブラリ１から外すために使用する。オペレー
タからキーボード１２を介してライブラリ１にコマンド
を送って、ピッカ５に、スロット９に差し込んだ光ディ
スクを受け取ってそれを記憶セル３または記憶機構４に
移送させ、あるいは記憶セル３または記憶機構４から光
ディスクを回収してそれをスロット９に渡させ、ライブ
ラリ１から外すことができる。コンソール１１を用い
て、オペレータは、ハウジング２の内部を見ずに、ライ
ブラリ１のある種の動作を監視し制御することができ
る。外部光ディスク・ドライブ１０は、ドライブ４とは
違って、グリッパ６でアクセスできず、手動でロードし
アンロードしなければならない。ライブラリ１はまた、
光ディスク・ドライブ排気ファン１４、外部ディスク・
ドライブ排気ファン１５、および電源１６を含む。

【００１５】ライブラリ１の電源を入れると、キーボー
ド１２で受け取ったコマンドがシステム制御装置１７に
転送される。好ましい実施例では、システム制御装置１
７は、ＯＳ／２オペレーティング・システムを用いるＩ
ＢＭ ＰＳ／２ ８０型パーソナル・コンピュータであ
る。このＩＢＭ ＰＳ／２ ８０型パーソナル・コンピ
ュータは、主記憶装置と、固定ディスクやフロッピー・
ディスク・ドライブに見られるような１つまたは複数の
記憶媒体を含む。システム制御装置１７は、後述のよう
に、ドライブ４、外部ディスク・ドライブ１０、ピッカ
５に命令を発行する。ドライブ制御カード１３とピッカ
制御カード１８は、システム制御装置１７から発行され
た既知の小型コンピュータ・システム・インタフェース
（ＳＣＳＩ）コマンド・パケットを、ドライブ４、外部
ディスク・ドライブ１０、ピッカ５の電気機械的動作に
変換する。ライブラリ１内でのピッカ５の移動は、Ｘ−
Ｙ方向である。垂直方向の移動は、垂直方向モータ１９
で駆動され、水平方向の移動は水平方向モータ２０で駆
動される。モータ１９は親ねじ２１を回転させてピッカ
５を垂直に移動させ、モータ２０はベルト２２と２３を
回転させてピッカ５を水平に移動させる。さらに、ピッ
カ５を回転させて、グリッパ６の届く範囲内にある光デ
ィスクのいずれかの面を直立位置にすることもできる。
ライブラリ１のその他の物理的特徴は、図を簡単にする
ため図面に示してなく、示してあっても番号をつけてな
いが、いずれも周知のものである。

【００１６】次に図６に関して、ライブラリ１のシステ
ム接続について説明する。システム制御装置１７は、１
台または複数のホスト／システム・プロセッサ３０に、
そこから入力を受け取り、そこに出力を送るように接続
されている。システム・プロセッサ３０は、ホスト中央
演算処理装置（ＣＰＵ）、たとえばＭＶＳまたはＶＭオ
ペレーティング・システムを使用するＩＢＭ３０９０メ
インフレーム・プロセッサ、ＯＳ／４００またはＡＩＸ
オペレーティング・システムを使用するＩＢＭＡＳ／４
００中規模コンピュータ、あるいはＯＳ／２またはＤＯ
Ｓオペレーティング・システムを使用し、ローカル・エ
リア・ネットワーク（ＬＡＮ）中に配置されたＩＢＭ
ＰＳ／２パーソナル・コンピュータなどのプロセッサの
ネットワークでよい。システム・プロセッサ３０への接
続は示してないが、周知のものである。システム・プロ
セッサ３０がＩＢＭ ３０９０メインフレーム・プロセ
ッサである場合、ＩＢＭ文書“ＩＢＭ Ｃｈａｎｎｅｌ
−ｔｏ−ＣｈａｎｎｅｌＡｄａｐｔｅｒ”（資料番号Ｓ
Ａ２２−７０９１−００）、１９８３年６月、ＩＢＭ文
書“ＩＢＭ Ｓｙｓｔｅｍ／３６０ ａｎｄ Ｓｙｓｔ
ｅｍ／３７０ Ｉ／Ｏ Ｉｎｔｅｒｆａｃｅ Ｃｈａｎ
ｎｅｌ ｔｏ Ｃｏｎｔｒｏｌ Ｕｎｉｔ，Ｏｒｉｇｉ
ｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅ
ｒｓ Ｉｎｆｏｒｍａｔｉｏｎ”（資料番号ＧＡ２２−
６９７４−０９）、１９８８年２月、およびＩＢＭ文書
“ＩＢＭ Ｓｙｓｔｅｍ／３７０ Ｅｘｔｅｎｄｅｄ
Ａｒｃｈｉｔｅｃｔｕｒｅ Ｐｒｉｎｃｉｐｌｅｓ ｏ
ｆ Ｏｐｅｒａｔｉｏｎ”（資料番号ＳＡ２２−７０８
５−０１）、１９８７年１月に記載されているインタフ
ェースに基づくＩＢＭシステム／３７０チャネル接続機
構を用いて接続を行うことができる。上記の各ＩＢＭ文
書を、引用により本明細書に合体する。システム・プロ
セッサ３０がＩＢＭ ＡＳ／４００中規模コンピュータ
である場合は、ＳＣＳＩインタフェース接続機構を用い
て直接接続を行うことができる。その場合、ライブラリ
１は、ＡＮＳＩ標準Ｘ３Ｔ９．２／８６−１０９ ｒｅ
ｖ．５に従ってホスト・システムによって直接制御され
る。上記のＡＮＳＩ標準を引用により本明細書に合体す
る。システム・プロセッサ３０がＬＡＮ中に配置された
複数のＩＢＭ ＰＳ／２ パーソナル・コンピュータで
ある場合は、ＩＢＭ文書“Ｄｉｓｔｒｉｂｕｔｅｄ Ｄ
ａｔａ Ｍａｎａｇｅｍｅｎｔ Ｌｅｖｅｌ２．０Ａｒ
ｃｈｉｔｅｃｔｕｒｅ Ｒｅｆｅｒｅｎｃｅ”（資料番
号ＳＣ２１−９５２６）、１９８９年３月に記載されて
いるプロトコルに従って、ＩＢＭトークン・リング・ネ
ットワークＬＡＮ接続機構のＮＥＴＢＩＯＳ制御プログ
ラム・インタフェースを用いて接続を行うことができ
る。上記のＩＢＭ文書を引用により本明細書に合体す
る。以下では、ライブラリ１の好ましい実施例を、シス
テムにとってライブラリ１が共用の汎用記憶装置に見え
る、ＬＡＮ環境におけるファイル・サーバとして使用さ
れるものとして説明を行う。

【００１７】システム制御装置１７は、ＳＣＳＩバス３
１を含む既知の単端ＳＣＳＩ接続を介して、ドライブ
４、ピッカ５、外部光ディスク・ドライブ１０に接続さ
れる。別の実施例では、システム制御装置１７を同様に
して、別の物理的ボックス（図示せず）に、そのボック
スの動作を指示するように接続することもできる。その
ボックスは、システム制御装置をその中に物理的に含ま
ず、その代りＳＣＳＩバス３２を介してシステム制御装
置１７から制御される点を除き、図２ないし５に示した
ものと基本的に同じである。システム制御装置を含むボ
ックスと含まないボックスを１個ずつ含む論理サブシス
テムは、１個のライブラリと見なされる。さらに、ある
種の環境で使用するために、ＲＳ−２３２インタフェー
ス（図示せず）を介して２台のシステム制御装置を接続
して、システム制御装置を含むボックスと含まないボッ
クスを２個ずつ含むライブラリを作成することもでき、
以下同様である。

【００１８】次に図７を参照して、システム制御装置１
７の機能的構成要素レベルでの説明を行う。一般に、シ
ステム制御装置１７は、ファイルの作成と削除、ファイ
ルへの書込みとファイルからの読取り、記憶セル３とド
ライブ４とスロット９の間での光ディスクの移動、使用
度およびエラーに関する統計の提供など、主なライブラ
リ機能をサポートするように設計されている。ライブラ
リ内のボリュームは、単一のドライブのルート・ディレ
クトリ内のサブディレクトリとして現れる。各ボリュー
ムに割り当てられるラベルは、サブディレクトリ名を表
す。システム・プロセッサ３０は、ルート・ディレクト
リを読み取ることができるが、ルート・ディレクトリに
ファイルを記憶することはできない。ボリューム上でア
クセスされるどの経路も、そのボリューム・ラベルを表
すサブディレクトリ要素の下にある経路として現れる。

【００１９】ライブラリ１はシステム制御装置３０には
単一の周辺記憶装置に見える。ライブラリ１は、ライブ
ラリ１内のそのボリューム、そのボリュームを載せるべ
きドライブ４などの物理位置に関して命令を必要としな
いが、その代りにシステム制御装置１７がそのような決
定をすべて行い、適当な処置を指令する。したがって、
ライブラリの管理はユーザにとってトランスペアレント
である。

【００２０】汎用ライブラリ・ファイル・サーバ（ＧＬ
ＦＳ）５０は、正式に定義されたインタフェースを介し
て１組の汎用中間ハードウェア・コマンドを用いてライ
ブラリを制御する。このインタフェースについては後で
説明する。データはＧＬＦＳ５０によって論理レコード
・レベルで扱われ、単一バイトから可変長データ・オブ
ジェクト全体までに及ぶ量のデータ・アクセスが可能に
なる。オペレーティング・システム５１は、制御の流れ
を調停し、入りオペレーティング・システム・コマンド
を外部インタフェースからライブラリ・サブシステムに
送る。オペレーティング・システム５１は、既知のいく
つかのオペレーティング・システムのいずれでもよく、
好ましい実施例ではＯＳ／２オペレーティング・システ
ムである。ＯＳ／２オペレーティング・システムを使用
すると、一般に標準の固定ディスク・オペレーティング
・システム・コマンドによるライブラリ１の制御が可能
となる。ライブラリの制御は、独自のコマンドＤｏｓＦ
ｓＣｔｌによって指令される。このコマンドを使用する
と、初期設定、ライブラリ１への光ディスクの装入／取
出し、ライブラリ・マップ・ファイルの読取り／書込
み、ドライブ１０への光ディスクのマウント／デマウン
ト、仮想ドライブ・オプションのエネーブル／ディスエ
ーブルなどがサポートされる。ドライブの制御は、独自
のコマンドＤｏｓＤｅｖＩＯＣｔｌによって指令され
る。ライブラリ１に対するプログラム式制御の残りの部
分は、初期設定時に記憶媒体からシステム制御装置１７
の主記憶装置にアップロードされる、マイクロコード内
に保持される。他の実施例では、マイクロプログラム式
制御をサポートするために必要な一部の機能も、システ
ム・プロセッサ３０内で走行するオペレーティング・シ
ステムに対するユーティリティとして提供されることが
ある。

【００２１】ＯＳ／２オペレーティング・システムは、
システム制御装置１７に組み込まれたいくつかの進んだ
オペレーティング・システム概念を含んでいる。この進
んだ概念には、動的リンク・ライブラリ、導入可能ファ
イル・システム、多重タスク処理がある。動的リンク・
ライブラリ（ＤＬＬ）は、それぞれ必要に応じて動的に
ロードできる１組の機能を内蔵するファイルである。通
常は、プログラムをコンパイルし、そのプログラムが呼
び出す可能性のあるすべての機能のコンパイル済みプロ
グラム・コードとリンクさせてからでないと、そのプロ
グラムは実行できない。ＤＬＬを用いると、プログラム
が、コンパイル済みで、プログラム・コードの独立した
モジュールにリンク済みの機能を呼び出すことができる
ようになる。ＯＳ／２は、必要に応じて呼び出すことの
できる１組のＤＬＬモジュールを含む。カスタムＤＬＬ
モジュールを使用すると、ＯＳ／２に非標準型の記憶装
置を制御させることができる。カスタムＤＬＬモジュー
ルは、導入可能ファイル・システム（ＩＦＳ）と呼ばれ
る。ＩＦＳによってサポートされる各機能は、入口点と
呼ばれる。導入可能ファイル・システムに関する詳細に
ついては、ＩＢＭ文書“ＩＢＭ Ｐｅｒｓｏｎａｌ Ｓ
ｙｓｔｅｍｓ Ｄｅｖｅｌｏｐｅｒ”（資料番号Ｇ３６
２−０００１−０３）、１９８９年秋、を参照のこと。
上記文書を引用により本明細書に合体する。好ましい実
施例では、ＧＬＦＳ５０は、規定された入口点を有す
る、ＯＳ／２オペレーティング・システムへのＩＦＳと
して実施される。

【００２２】ＯＳ／２オペレーティング・システムのも
う１つの重要な態様は、多重タスク処理である。多重タ
スク処理とは、システムが多数のプログラムを同時に実
行できる能力である。システム・プロセッサの時間が、
タスク間で分配され、各タスクは、他のタスクが存在し
ない場合と同様に実行されているように見える。各タス
クごとに別々の環境が維持される。各タスク用のメモリ
およびレジスタの内容は、相互の干渉を避けるため分離
されている。タスクとその関連する環境を「スレッド」
と呼ぶ。プログラムは、ＩＢＭ ＰＳ／２ ８０型パー
ソナル・コンピュータの主記憶装置内にコード域とデー
タ域を含むことができる。コード域とは、所与の任意の
スレッドに関して実行中の命令を含む、メモリのセクシ
ョンをいう。データ域とは、命令の実行中に操作される
メモリ（またはレジスタ）のセクションをいう。複数の
スレッドに同じコード域が使用されることがあるので、
各スレッドが同じ実行すべきコード域を指すことはあり
得るが、それぞれ分離したデータ域を含む。

【００２３】上側のインタフェース・トランスレータ８
０は、上側インタフェース・コマンドとＧＬＦＳ５０の
コマンドの間の変換を司る。下側インタフェース・トラ
ンスレータ９０は、ＧＬＦＳ５０が発行したコマンドと
下側インタフェース・コマンドの間の変換を司る。トラ
ンスレータ８０および９０は、それぞれ明確なインタフ
ェースをもつ別々のリンク可能モジュールとして実施さ
れ、ライブラリ１を新しい上側および下側インタフェー
スに容易に接続できるようにする。新しいインタフェー
スに対する接続の唯一の影響は、トランスレータ８０お
よび９０の新しい部分が作成されることである。ＧＬＦ
Ｓ５０は総称的なものであるため、それは変更されない
ままとなる。

【００２４】ライブラリ１の上側インタフェースは、ラ
イブラリ編成ファイル、ライブラリ・マップ・ファイ
ル、システム性能ファイル、コンソール１１（およびキ
ーボード１２）、ネットワーク・インタフェースを含
む。ライブラリ構成ファイル、ライブラリ・マップ・フ
ァイル、システム性能ファイルは図面には示してない
が、システム制御装置１７の固定ディスク・ドライブに
記憶される。これらのファイルは、ライブラリ・オペレ
ータまたは保守要員の手で維持される。ライブラリ構成
ファイルは、ライブラリ１のハードウェア構成の様々な
特性、例えばライブラリ１内の物理ボックスの数、各物
理的ボックス内のドライブ４と１０の数、ドライブが内
部ドライブ４か外部ドライブ１０かの別、各物理ボック
ス内の記憶セルの数、ピッカ５およびドライブ４と１０
のＳＣＳＩアドレスなどをリストする。ライブラリ・マ
ップ・ファイルは、ライブラリ１内の光ディスクの様々
な特性、例えばライブラリ１内の各光ディスクのボリュ
ーム・ラベル、ライブラリ１内の各光ディスクに関する
自由空間情報、および各光ディスクに関するある種の使
用統計、例えばマウント数、最後のアクセスの目的など
をリストする。システム制御装置１７は、ライブラリ構
成ファイルおよびライブラリ・マップ・ファイルを使用
して、ライブラリ内の資源の数と配列を識別し、ライブ
ラリ１内の資源の状況が変化するとき、ファイルをそれ
に合わせて調整する。システム性能ファイルは、仮想ド
ライブ・オプション・パラメータＵ、最小仮想ドライブ
有資格時間Ｖ、最小デマウント有資格時間Ｗ、事前デマ
ウント有資格時間Ｘ、遊休デマウント時間Ｙなどのオペ
レータ指定のパラメータをリストする。これらのパラメ
ータについては後で定義する。コンソル１１は、ライブ
ラリ構成要素の進行状況を示し、エラー報告などのコマ
ンドおよびユーティリティ機能をオペレータが利用でき
るようにするのに使用する。キーボード１２は、オペレ
ータが、例えばコンソール１１を介して受け取った情報
に応答して、ライブラリ１に手動入力を行うために使用
する。コンソール１１とキーボード１２は、コンソール
・ドライバ８１およびコンソール・ディジタル・マネジ
ャ８３によってＧＬＦＳ５０にリンクされる。ネットワ
ークは、ＬＡＮアダプタ・ドライバ８２およびＮＥＴＢ
ＩＯＳネットワーク制御プログラム８４にリンクされ
る。このネットワーク・インタフェースは、ネットワー
ク上のプロセッサが、そのファイル・サーバとして働く
ライブラリ１に対する遠隔アクセスを得られるようにす
る。

【００２５】ＧＬＦＳ要求マネジャ５２は、オペレーテ
ィング・システム５１へのインタフェースであり、ＯＳ
／２オペレーティング・システムがＩＦＳと通信するの
に使用するのと同じ１組の入口点に応答する。ＧＬＦＳ
要求マネジャ５２は、ライブラリ機能を実行するために
オペレーティング・システム・コマンドを分割すること
を司り、プロセス制御マネジャ（ＰＣＭ）５３ａ内にあ
るルーチンを呼び出して各ステップを実行することによ
りそれを行う。ＰＣＭ５３ａは、要求ブロックの生成を
必要とするものも含めて、コマンドを分解し処理する際
にシステムを助ける１組のユーティリティ・ルーチンで
ある。これらのルーチンは、ディレクトリ経路ストリン
グを解析し、光ディスクをライブラリに入れ、ボリュー
ムの位置を探し出し、ボリュームにドライブを割り振
り、光ディスクを反転させて反対面にあるボリュームを
マウントすべく提示し、ボリュームをマウントし、デマ
ウントし、光ディスクをライブラリから出すなどする。
これらのルーチンについては後で当該の個所で説明す
る。ディレクトリ管理方式（ＤＭＳ）５３ｂは、周知の
ようにライブラリ１内のユーザ・ファイルの開閉状況を
監視するためのＩＦＳファイル指定を満足するコード・
モジュールであり、そのようなユーザ・ファイルを操作
するために使用する。このような内部モジュール内のＩ
ＦＳインタフェースを使用すると、外部ＩＦＳスタイル
によるディレクトリ管理方式の実施態様を容易に適合さ
せることが可能になる。

【００２６】電力投入初期設定（ＰＯＩ）モジュール５
４は、制御装置の電力投入およびリセット機能を管理す
るもので、初期設定時にオペレーティング・システム５
１によって呼び出される。ＰＯＩモジュール５４は、構
成要素の自己検査の結果の判定と報告、ライブラリ構成
ファイルおよび現況ファイルの読取りなどの機能を司
る。エラーは、エラー回復モジュール５６およびエラー
記録モジュール５７によって処理される。エラー回復モ
ジュール５６は、動的装置再割振りや装置コマンドの再
試行を含めてすべてのエラーを処理する。エラー記録モ
ジュール５７は、エラー情報の保管およびコンソール１
１を介してオペレータにそれを報告することを司る。

【００２７】資源マネジャ６０は、要求ブロック、ドラ
イブ制御ブロック、エラー情報ブロックを含めて、シス
テム制御装置１７のデータ域内の制御ブロックの動的割
振りと割振り解除を行う。要求ブロックは、ドライブ４
またはピッカ５に関するハードウェア事象を要求するの
に使用される。ドライブ制御ブロックは、後で説明する
ように、ドライブ４に関する状況情報を記憶するのに使
用される。エラー情報ブロックは、エラーの報告、分
離、および恐らくは再試行を行うのに必要な情報を記憶
するのに使用される。制御ブロックの割振りおよび割振
り解除は、資源マネジャ６０によって維持されている、
ＩＢＭ ＰＳ／２ ８０型パーソナル・コンピュータの
主記憶装置内の利用可能な自由空間のリストを使って実
行される。エラー回復モジュール５６と資源マネジャ６
０は、共に図７に示すシステム制御装置の大部分の構成
要素に接続されている。図が簡単になるようにこれらの
接続は図示していない。

【００２８】スケジューラ６１と６２は、要求ブロック
の内容の一部を検証し、それを、その要求を処理するハ
ードウェア装置のパイプに入れることを司る。パイプと
は、あるスレッドから別のスレッドに通じる待機データ
経路であり、そのパイプに割当てられた識別子を知って
いるどのスレッドからもそれにアクセスできる。ディス
パッチャ６３と６４は、要求ブロックの妥当性検査を行
い、要求がすぐ実行できる状態にあることを確認し、そ
の要求を適宜、ドライブ論理マネジャ９１およびライブ
ラリ論理マネジャ９２に指名することを司る。コーディ
ネータ６５は、ディスパッチャ６３および６４に対する
要求実行の調整を司る。コーディネータ６５は、ＰＣＭ
５３ａから受け取った各要求ブロックに対する記入項目
を有するテーブルを用いてそれを行う。各記入項目は、
特定の要求ブロックに関連する支援要求ブロックをリス
トする。別の要求が既に完了していることを必要とする
要求は「従属」要求と呼び、最初に完了しなければなら
ない要求は「支援」要求と呼ぶ。コーディネータ６５
は、関連する支援要求が実行されるまで、従属要求の実
行を抑える。支援要求が実行されない場合、コーディネ
ータ６５はそれに従属する要求を拒絶する。

【００２９】論理マネジャ９１および９２は、要求ブロ
ックの形の総称ライブラリ・コマンドを、ＳＣＳＩデー
タ・パケットの形の相当する装置レベルのコマンドに変
換することを司る。論理マネジャ９１および９２はま
た、それぞれドライブ・ドライバ９３とライブラリ・ド
ライバ９４からハードウェア状況情報を受け取ることを
司る。ドライバ９３と９４は、ハードウェアおよび物理
メモリを直接操作する。ドライバ９３と９４はまた、当
該の各ハードウェアとの間のあらゆる通信を実行し、か
つ割込みに応答する。論理マネジャ９１とドライブ・ド
ライバ９３はドライブ４を制御し、論理マネジャ９２と
ライブラリ・マネジャ９４はピッカ５を制御する。図を
簡単にするため図６には図示してないが、実際には、多
数のドライブ・ディスパッチャ６３、ドライブ論理マネ
ジャ９１、ドライブ・ドライバ９３が、ライブラリ内の
各ドライブ４または１０ごとに１組ずつある。各組はそ
れぞれ異なるデータ・パイプに接続されている。

【００３０】第１図を参照すると、エラーの検出時にエ
ラー回復モジュール５６に渡される内部データ・ブロッ
クが示されている。ライブラリ１内で、エラー回復のた
めに使用される内部データ・ブロックは、機能コードの
エラーに出会ったセクションによって作成されるエラー
情報ブロックと、そのようなコードの動作を開始した要
求ブロックである。図面で、ブロックの左側の欄は、ブ
ロック内の特定のフィールドの始めのブロックの頭から
のオフセットをバイトで示す。ブロックの右側の欄はフ
ィールドのサイズを示す。以下に説明するように、サイ
ズが１バイトよりも小さいフィールドはすべて、システ
ム状態に挿入されるとき０ビットを埋め込まれる。他の
実施例では、データ処理システムの必要に応じて、任意
の数およびサイズのデータ構造を使用することができ
る。フィールド内のデータの意味およびタイプは本発明
にとっては重要ではなく、図面に示したフィールドの概
要は一例として挙げたものにすぎない。

【００３１】１２バイトのエラー情報ブロック内に６つ
のフィールドがある。最初のフィールドは、エラー情報
ブロック識別子である。エラー情報ブロック識別子は、
エラー情報ブロックの第１バイトから始まり、その３バ
イトを占める。第２のフィールドは機能フィールドであ
り、エラー状態に出会ったシステム制御装置１７内のコ
ード・ルーチンを識別する。機能フィールドは、（エラ
ー情報ブロック識別子が最初の３バイトを占めるので）
エラー情報ブロックの第４バイトから始まり、１バイト
を占める。第３のフィールドは位置フィールドであり、
エラーに出会ったルーチン内の、エラーが発生した位置
を識別する。エラー情報ブロックの第４のフィールドは
戻りコード・フィールドであり、エラー回復モジュール
５６にエラーを直ちに報告することができないコード・
ルーチンから要求が受け取る結果を識別する。戻りコー
ド・フィールドは、エラー情報ブロックの第６バイトか
ら始まり、２バイトを占める。第５のフィールドはタイ
プ・フィールドであり、エラー・タイプを示す。エラー
・タイプは５つのタイプのいずれかである。資源エラー
は、その機能が使用するメモリが割り振られていない
等、特定の機能をサポートするための資源を求める要求
をオペレーティング・システムが拒絶したことを示す。
論理エラーはシステム・コードの実施における障害を示
す。残りの３種のエラーは、ライブラリ・エラー、ドラ
イブ・エラーおよびカード・エラーであり、それぞれラ
イブラリ１、ドライブ４および１０、カード１３および
１８のエラーに対応する。タイプ・フィールドは、エラ
ー情報ブロックの第８バイトから始まり、４ビットの長
さである。最後のフィールドは要求ブロック・ポインタ
・フィールドであり、それと関連する要求ブロックがあ
る場合に、それを指すポインタにすぎない。

【００３２】１５バイトの要求ブロックは、８つのフィ
ールドを含む。要求ブロックの第１のフィールドは要求
ブロック名である。要求ブロックの第２のフィールド
は、エラー状態が発生した装置のアドレスまたは論理装
置番号であり、装置タイプも含むことができる。たとえ
ば、装置タイプは、ライブラリ内の特定の光ディスク・
ドライブが追記型かそれとも書込み可能型かを示すこと
ができる。第３のフィールドはコマンド・フィールドで
あり、エラーが発生したとき試みられていたコマンドを
示す。戻りコード・フィールドは、エラー情報ブロック
のそれと類似している。第５および第６のフィールド
は、センス・キー・フィールドおよび追加センス修飾子
（ＡＳＱ）フィールドであり、前述のＳＣＳＩ標準で定
義されるように、ドライブ４または１０またはライブラ
リ１のみに関係するエラーに関する特定のＳＣＳＩパケ
ット情報を提供する。最後の２つのフィールドはＳＣＳ
Ｉ状況フィールドおよびＣＭＤ状況フィールドであり、
カード１３および１８に関係するエラーに関する特定の
情報を提供する。要求ブロックの各フィールドは、バイ
ト０、３、７、９、１１、１１、１２、１３で開始し、
それぞれ３、４、２、２、１／２、１／２、１、２バイ
トにわたっている。

【００３３】ユーザ編集可能データ・ファイルは、ユー
ザによって指定される、エラー回復のために必要な情報
の多くを含む。このデータ・ファイルは図８に示してあ
り、システム状態を決定し、かつエラー状態、およびそ
れに関連する個々の回復動作のシーケンスを提供するた
めに使用される。図面は、ユーザが構造参照言語で指定
したデータ・ファイルの内容を示す。この言語を使用す
るのは、データ入力を簡単にするためである。実際にデ
ータ・ファイルにあるデータの量は全体を示すには大き
すぎるので、便宜上小さなサンプル・データ・ファイル
を示してある。データ・ファイルは２種類の基本的な情
報、すなわち、システム状態に関係する情報と、エラー
状態および関連する回復動作シーケンスに関係する情報
を含む。

【００３４】システム状態に関係する情報は一組の変換
規則であり、エラー回復で使用される前述のブロックか
ら関連フィールドを抽出するために使用される。エラー
回復の際には無価値であると（システムの開発または使
用中に）判定されたフィールドは、その内容が何であ
れ、単に抽出のために指定されない。さらに、規則はユ
ーザ編集可能データ・ファイルに入っているので、シス
テム状態の定義の変更は簡単である。システム状態の定
義の変更により、システム状態変数を定義するために使
用される関連フィールドを変更することが可能になる。
コードを変更することなく単にテーブルを変更すること
により、追加のまたは異なるエラー情報を、エラー回復
コードが使用するために集めることができ、それによ
り、プロダクト・コードの変更または再コンパイルなし
に容易なフィールド更新が可能になる。

【００３５】システム状態における各データ・フィール
ドは、１つの規則を使って得られる。ＮＵＭＲＵＬＥＳ
は、規則の数、したがってシステム状態におけるフィー
ルドの数を指定するために使用される。この例では４つ
の規則が１行当り１つずつ示されている。“Ｄ”の後の
数字は、ブロックの頭からの変位をバイトで示す。
“Ｂ”の後の数字は、指定されたバイトの頭からの変位
をビットで示す。“Ｌ”の後の数字は、指定されたビッ
トから始まる、抽出すべきビットの数を示す。抽出され
たデータは、完全なバイトを作成するため、常に埋め込
まれる。これらの規則を適用すると、図８の最初の規則
は、システム状態の第１バイトとしてエラー情報ブロッ
クの機能フィールド全体を指定することが理解できる。
第２の規則はエラー情報ブロックのタイプ・フィールド
をシステム状態の第２バイトとして指定する。第３およ
び第４の規則でハイフンとその後の数字“８”は、エラ
ー情報ブロックの最後のフィールド内の要求ブロックを
指すポインタを指定する。すなわち、第３の規則は、要
求ブロックのコマンド・フィールドをシステム状態の第
３バイトとして指定し、第４の規則は、要求ブロックの
ＡＳＱフィールドをシステム状態の最後の第４バイトと
して指定する。各ブロックへの飛越しは「ステップ」と
見なされる。最初の２つの規則はそれぞれ１つの（エラ
ー情報ブロックへの）ステップを指定し、最後の規則は
それぞれ２つの（エラー情報ブロックおよび要求ブロッ
クへの）ステップを指定する。ステップの数は、使用さ
れるブロックの数を越えることができない。

【００３６】エラー状態および関連する個々の回復動作
シーケンスに関係する情報は、基本的に、そのようなエ
ラー状態、および関連する個々の回復動作へのインデッ
クスを指定するテーブルである。ＮＵＭＥＲＲＯＲＳ
は、エラー状態の数（図では１７）を指定するために使
用される。ＲＳＳＩＺＥは、任意のエラー状態と関連す
る個々の回復動作の最大数を指定するために使用され
る。この数は後述するように終了標識を含む。このテー
ブルは、あるエラー状態とその関連インデックスを１行
ごとにリストする。エラー状態は矢印の前に指定され、
インデックスはその後で順に指定される。エラー状態の
各項目は、システム状態のバイト値に対応するバイト値
である。エラー状態の第１バイトは、システム状態の第
１バイトに対応し、エラー状態の第２バイトはシステム
状態の第２バイトに対応し、以下同様である。バイト値
の代りの“Ｘ”は、「ドントケア（どうでもよい）」変
数であり、エラー状態をシステム状態と比較する際にそ
のようなバイトは考慮されないことを意味する。すなわ
ち、図８の第１のエラー状態は、システム状態の第２お
よび第３バイトの値にかかわらず、システム状態の第１
バイトが１であり、かつシステム状態の最後の第４バイ
トが７であれば、システム状態に一致する。同様に、シ
ステム状態の最後の第４バイトの値は、第２のエラー状
態をシステム状態と突き合わせする際に全く意味を持た
ない。ドントケア変数を使用すると、表現しなければな
らないエラー状態の数が大幅に減り、エラー状態テーブ
ルの柔軟性が大幅に向上する。一実施例では、システム
状態が少なくとも１つのエラー状態に一致することを保
証するため、指定された最後のエラー状態はｃａｔｃｈ
−ａｌｌ（どんな状況にも対応できる）状態（すなわ
ち、すべてドントケア変数）である。

【００３７】回復動作インデックスは、個々の回復動作
を指定する。ライブラリ１に対する可能な個々の各回復
動作は、後で説明するように、インデックスによって回
復動作アレイ中にリストされる。個々の回復動作は、回
復動作を指定することが可能な最も基本的なレベルにあ
る。個々の回復動作が組み合わさって、関連するエラー
状態から回復するために使用される回復動作シーケンス
を形成する。すなわち、図面に示した例は、システム状
態が最初のエラー状態に一致した場合、回復のために最
初の５つの回復動作が呼び出される。終了標識は回復動
作シーケンスの終りを示す。システム状態が第２のエラ
ー状態に一致した場合は、回復のために、第２、第３お
よび第４の回復動作が呼び出される。システム状態が第
３のエラー状態に一致した場合は、回復のために、第１
および第３の回復動作が呼び出され、以下同様である。
回復動作シーケンスはユーザ編集可能データ・ファイル
で指定されるので、ライブラリ１が老化したとき所与の
エラー状態に関する新しい回復動作シーケンスの作成が
簡単になり、ユーザは単にエラー状態に関連するインデ
ックスを変更するだけでよい。便宜上図面には示してな
いが、注釈も構造化参照言語で同様に行なわれる。

【００３８】動作方法ライブラリ１の初期設定は、オペ
レーティング・システム５１、ＧＬＦＳ要求マネジャ５
２、資源マネジャ６０、ＰＯＩモジュール５４を使って
実行される。ライブラリ・ハードウェアの自己検査によ
ってそれが正しく機能することを確認した後、オペレー
ティング・システム５１がロードされ、ＯＳ／２ ＣＯ
ＮＦＩＧ．ＳＹＳ（システム構成）ファイルを使って、
オペレーティング・システム・パラメータを設定し、ド
ライバをロードする。次いでオペレーティング・システ
ム５１は初期設定コマンドを生成し、このコマンドがＧ
ＬＦＳ要求マネジャ５２に、次いでＰＯＩモジュール５
４に渡される。ＰＯＩモジュール５４は、ライブラリ構
成ファイル、ライブラリ・マップ・ファイル、システム
性能ファイルを読み取り、ＩＢＭ ＰＳ／２ ８０型パ
ーソナル・コンピュータの主記憶装置内で必要な内部デ
ータ構造を作成し、ライブラリ構成ファイル内で指定さ
れたライブラリ１の各ハードウェア構成要素ごとに別々
のスレッドを初期設定する。資源マネジャ６０は、メモ
リの管理に使用される内部テーブルを初期設定する。次
いでＰＯＩモジュール５４は、システム制御装置１７お
よび制御カード１３と１８に、電力投入自己検査の結果
について照会し、問題があればエラー回復モジュール５
６に報告する。初期設定中に検出されたエラーはエラー
記憶モジュール５７によって記録され、可能なものはエ
ラー回復モジュール５６によって回復される。システム
制御装置１７が準備完了状態にあるとき、システムはコ
ンソール１１またはネットワーク・インタフェースの活
動状態に感応する。

【００３９】エラー回復のために必要な内部データ構造
も初期設定中に作成される。これらのデータ構造は、ユ
ーザ編集可能データ・ファイルから解析され、図９およ
び１０に示してある。実際にはそのようなデータ構造自
体はユーザによる編集が可能ではないが、初期設定時に
それらのデータ構造を解析するのに使用するデータ・フ
ァイルは実際にユーザ編集可能なので、本発明の目的に
とってはユーザ編集可能と考えられる。図９は、その共
通域１３０を含めて、エラー回復のためのマスタ制御ブ
ロックを示す。共通域１３０は、変換規則の数、状態変
数のサイズ、エラー状態の数、個々の回復動作のサイ
ズ、および規則構造１３１を指すポインタのアレイを含
む。１つの変換規則ごとに１つのポインタがある。各規
則構造１３１は、要求ブロックへのバイト変位、ビット
変位、ビット長、および当該の変換規則のステップ数を
含む。各規則構造１３１はまた、ステップ構造（変換規
則内の１ステップ当り１つのステップ構造）のアレイを
含む。各ステップ構造は、フィールドのタイプ（ポイン
タ対終了標識）およびエラー情報ブロックへのバイト変
位を含む。

【００４０】マスター制御ブロックの共通域１３０はま
た、エラー・テーブル１３２、ケア・テーブル１３３お
よび回復テーブル１３４を指すポインタを含む。図１０
に、これらのテーブルをシステム状態および回復動作ア
レイと共に示す。エラー・テーブルおよびケア・テーブ
ルは、基本的に、データ・ファイルからのエラー状態情
報を２つのテーブルに分配する。エラー・テーブルは、
システム状態と比較する際に好ましい順序でエラー状態
をリストするにすぎない。ケア・テーブルは、システム
状態との比較中にエラー・テーブルをオーバレイするド
ントケア変数のマスクをリストするにすぎない。ケア・
テーブルは１６進形式で示し、“０”バイトはドントケ
ア変数を示す。システム状態は、エラー・テーブルおよ
びケア・テーブル内の対応する行を使ってエラー状態と
比較される。最初の比較では、システム状態の４バイト
（０、２、６、７）が第１のエラー状態の４バイト
（１、２、６、７）と比較される。ケア・テーブルは、
第２および第３のバイトがドントケア・バイトであるこ
とを示しているので、最初および最後のバイトについて
のみ一致するかどうか判定する。ここでは、システム状
態の第１バイトとエラー状態の第１バイトは異なるの
で、一致しない。実際には、テーブルを下方に進んで、
システム状態は最初に第３のエラー状態と一致する。便
宜上システム状態およびエラー・テーブルには数値が示
されているが、これらの値は実際には２進形式で表され
（そのためにバイトが使用される）、比較は実際にはビ
ットごとの比較である。

【００４１】回復テーブルは、実際にデータ・ファイル
からの回復動作インデックス情報をリストする。各エラ
ー状態に回復シーケンスが割り当てられる。回復シーケ
ンスは、必要に応じて終りに０が埋め込まれた一連の回
復動作インデックスから成る。回復動作インデックス
は、回復活動アレイへのインデックスであり、動作やは
りユーザによって提供され、初期設定時にリンクされ
る。各インデックスは、エラー回復のために（そのよう
な活動シーケンスの一部として）呼び出される実際の基
本的回復動作に対応する。このようなインデックス付け
により、ライブラリ１内の活動リストでどのように指定
されたかにかかわらず、ユーザが基本的回復動作を所望
の任意の順序で指定することが可能になる。ユーザは、
これらの動作が所望の順序に並ぶように、特定の機能に
対して各インデックスを選ぶだけである。

【００４２】次に図１１を参照して、システム制御装置
１７の動作について述べる。ネットワーク・インタフェ
ースから要求を受け取ると、ネットワーク制御コード
は、ステップ１００で、その要求を１組の標準のＯＳ／
２ オペレーティング・システム・コマンドに変換す
る。次にオペレーティング・システム５１は、ステップ
１０１で、それらのオペレーティング・システム・コマ
ンドを処理するため、適当なオペレーティング・システ
ム・コールを発行する。ＧＬＦＳ要求マネジャ５２がこ
れらのシステム・コールを受け取って、より簡単な機能
に分解する。各機能について、ＧＬＦＳ要求マネジャ５
２は、ステップ１０２でＰＣＭ５３ａまたはＤＭＳ５３
ｂあるいはその両者内のルーチンを呼び出し、そのルー
チンに必要な適切なデータのサブセットをパラメータと
して渡す。ハードウェアの活動を必要とする各ルーチン
の場合は、ＰＣＭ５３ａまたはＤＭＳ５３ｂあるいはそ
の両者が、ステップ１０３で、ハードウェア・レベル要
求ブロックを生成するために資源マネジャ６０を呼び出
し、そのブロックをスケジューラ６１と６２に発行し、
ハードウェア従属関係があればコーディネータ６５に知
らせて、それらの要求が適当に順序付けできるようにす
る。ＰＣＭ５３ａはまた、各ルーチンが完了したとき、
制御および状況情報をＧＬＦＳ要求マネジャ５２に戻
す。

【００４３】ＩＢＭ ＰＳ／２ ８０型パーソナル・コ
ンピュータの主記憶装置内で利用可能な自由空間のリス
トを検査した後、資源マネジャ６０は、その要求ブロッ
クに必要なメモリ空間を割り振る。資源マネジャ６０を
呼び出すルーチンが、ある制御ブロックに対する大部分
の情報を提供し、資源マネジャ６０は、制御ブロック識
別子や要求ブロック識別子などある種の追加情報を記入
する。ドライブ・スケジューラ６１とライブラリ・スケ
ジューラ６２は、すべてのハードウェア事象要求を要求
ブロック識別子として受け取り、それをそれぞれドライ
ブ・ディスパッチャ６３とライブラリ・ディスパッチャ
６４に接続されたデータ・パイプに転送する。ディスパ
ッチャ６３と６４は、要求ブロック識別子が存在するか
どうか、それぞれのデータ・パイプを連続して検査す
る。要求ブロック識別子を受け取った後、ディスパッチ
ャ６３と６４は、要求ブロックがすぐ実行できる状態に
あるかどうか判定するためにコーディネータ６５を呼び
出す。コーディネータ６５は、要求ブロック従属関係テ
ーブルを検査し、すべての支援要求ブロックが完了する
まで、ディスパッチャ６３と６４が要求ブロック識別子
を発行するのを妨げる。すべての要求ブロック従属関係
が満たされたとき、要求ブロック識別子が当該の論理マ
ネジャ９１または９２に発行される。

【００４４】ステップ１０４で、論理マネジャ９１と９
２は、要求ブロック識別子を受け取り、それらの要求を
実施するのに必要なＳＣＳＩハードウェア・コマンド・
パケットを作成し、それらのパケットをドライバ９３お
よび９４に発行する。次いでハードウェアがそれらの要
求を物理的に実行する。各要求が完了したとき、論理マ
ネジャ９１と９２はその完了を通知する。次いでディス
パッチャ６３または６４は次の要求ブロックの識別子を
当該の論理マネジャ９１または９２に発行する。

【００４５】上記動作中のどの時点でエラー状態に出会
っても、エラー回復モジュール５６が呼び出される。図
１２を参照すると、ステップ２２０でエラーが見つかっ
たとき、エラー回復モジュール５６が呼び出される。ス
テップ２２１でＴＲＡＮＳＬＡＴＥ（変換）ルーチンが
呼び出され、エラー回復モジュール５６が、オペレーテ
ィング・システム５１からエラー情報ブロックと要求ブ
ロックを受け取り、変換規則を使ってその中の情報をシ
ステム状態に変換する。ステップ２２２でＣＯＭＰＡＲ
Ｅ（変換）ルーチンが呼び出され、一致が見つかるまで
システム状態が各エラー状態と順に比較される。最初の
一致で比較が終了する。複数のエラー状態がシステム状
態に一致する場合は、最初の一致のみが検出される。関
連する回復動作シーケンスの制限の程度の順にエラー状
態を（すなわち、ドントケア変数が最も少ないエラー状
態からドントケア変数が最も多いエラー状態へと）リス
トすることにより、最も制限された回復動作シーケンス
が最初に回復のために試みられる。ステップ２２３でＲ
ＥＣＯＶＥＲ（回復）ルーチンが呼び出され、エラー回
復モジュール５６が、比較状態の一致に基づいて、エラ
ー回復のために回復動作シーケンスを呼び出す。ステッ
プ２２４で、エラー回復モジュール５６は、呼出し側機
能に制御を戻す。ＴＲＡＮＳＬＡＴＥルーチン２２１、
ＣＯＭＰＡＲＥルーチン２２２およびＲＥＣＯＶＥＲル
ーチン２２３は、図１３ないし図１５にさらに詳細に示
されている。

【００４６】図１３を参照すると、ステップ２３０でＴ
ＲＡＮＳＬＡＴＥルーチンの呼出しが開始する。ステッ
プ２３１で、第１の規則の最初のステップが考慮され
る。ステップ２３２でステップ構造が検索され、ステッ
プ２３３でそのステップが最後のステップであるかどう
かに応じて分岐する。最後のステップでない場合は、ス
テップ２３４で要求ブロックを指すポインタが抽出され
る。ステップ２３６で、ポインタがセットされているか
どうかに応じて分岐する。セットされている場合は、次
のステップに進み、ステップ２３２に戻って新しいステ
ップ構造を得る。このループは、ステップ２３３で規則
の最後のステップが見つかるか、またはステップ２３６
でポインタ中にデータが見つからなくなるまで続行す
る。ステップ２３３で規則中の最後のステップが見つか
った場合は、ステップ２３９で当該のブロックからフィ
ールドの値が抽出され、システム状態の現バイトに置か
れる。ステップ２３６でポインタがセットされていなか
った場合は、システム状態の現バイトに０が挿入され
る。ポインタがセットされていないときは、そのポイン
タと関連するデータが現在のシステム状態には必要でな
いことを暗示する（それらのフィールドに対してドント
ケア変数が表現される）。どちらの場合も、次にステッ
プ２４１で最後の規則まで進んだかどうかに応じて分岐
する。最後の規則でない場合は、ステップ２４２で次の
規則の最初のステップに進み、ステップ２３２に戻って
次の規則を使ってシステム状態の次のバイトを得る。最
後の規則に達した場合は、ステップ２４３でＴＲＡＮＳ
ＬＡＴＥルーチンから戻る。

【００４７】図１４を参照すると、ステップ２７０でＣ
ＯＭＰＡＲＥルーチンの呼出しが開始する。ステップ２
７１で、システム状態の第１バイト、エラー・テーブル
内のエラー状態の第１バイト、および管理テーブル内の
第１バイトが検索される。ステップ２７２で、システム
状態バイトとエラー・テーブル・バイトに対する第１の
ビットごとの排他的ＯＲ（ＸＯＲ）演算、およびそれに
続いてＸＯＲの結果と管理テーブル・バイトに対するビ
ットごとのＡＮＤ演算により、これらのバイトが比較さ
れる。結果がすべてゼロのバイトでない場合は、一致が
なく、ステップ２７３からステップ２７４に分岐する。
次にステップ２７４で、今比較したエラー状態に応じて
分岐する。今比較した（かつシステム状態に一致しなか
った）エラー状態が最後のエラー状態でない場合は、エ
ラー・テーブル内の次のエラー状態の第１バイトおよび
管理テーブル内の次のエラー状態の第１バイトに進み、
ステップ２７２に戻って新たな比較を行なう。このルー
プは、ステップ２７２でバイトが一致するが、またはス
テップ２７４で最後のエラー状態に達するまで続行す
る。ステップ２７３でバイトが一致すると、ステップ２
７７でシステム状態およびエラー状態の最後のバイトに
達したかどうかに応じて分岐する。達していない場合
は、同じシステム状態バイトおよびエラー状態バイトの
次のバイトに進む。最後のバイトに達した場合は、以前
のバイトは全て一致したはずであり、システム状態とエ
ラー状態の全体が一致する。次にステップ２７９に進
む。ステップ２７４で最後のエラー状態に達すると、際
限なくステップ２７２にループして戻ることを回避する
ため、再びステップ２７９に進む。ステップ２７９で、
一致したエラー状態に関連する回復シーケンス・インデ
ックスが保管され、ステップ２８０でＣＯＭＰＡＲＥル
ーチンから戻る。指定された最後のエラー状態がｃａｔ
ｃｈ−ａｌｌ状態であって、システム状態が少なくとも
１つのエラー状態と一致することが保証されている実施
例では、ステップ２７３でシステム状態とエラー状態が
一致していなければ最後のエラー状態に達することは不
可能なので、ステップ２７４は省略することができる。

【００４８】図１５を参照すると、ステップ２９０でＲ
ＥＣＯＶＥＲルーチンの呼出しが開始する。ステップ２
９１で、ステップ２７９からの保管された回復シーケン
ス・インデックスを使って、回復動作シーケンス・イン
デックスのコピーが作成される。ステップ２９２で、シ
ーケンス内の最初の回復動作インデックス（すなわち、
第１バイト）が抽出される。次にステップ２９３で、最
後の回復動作に達した（すなわち、回復動作インデック
スが終了標識０である）かどうかに応じて分岐する。達
していない場合は、ステップ２９４で、回復動作インデ
ックスを使って個々の回復動作が呼び出される。次にシ
ーケンス内の次の回復動作インデックスに進み、ステッ
プ２９３に戻る。このループは、ステップ２９３で最後
の回復動作に達するまで続行し、最後の回復動作に達し
た時点でステップ２９７でＲＥＣＯＶＥＲルーチンから
戻る。

【００４９】以上本発明を好ましい実施例に関連して説
明してきたが、当業者なら理解するように、本発明の趣
旨、範囲および教示から逸脱することなく、細部に様々
な変更を加えることができる。例えば、本発明を光ディ
スク・ライブラリの文脈で開示したが、同様の考慮によ
り、他のタイプのライブラリまたはデータ処理システム
全体またはそれらのシステムの他の構成要素に適用可能
にすることができる。さらに、ドライブと記憶セルの数
などライブラリ内で多数の変形を行なうことができる。
例えば、代替実施例では、ライブラリ１は３２個の記憶
セル３と２台のドライブ４を含む。システム制御装置１
７がハウジング２の外部に配置され、ハウジングの寸法
が縮小される。さらに、ステップ２９３は、上記の条件
に追加された条件下でステップ２９７に分岐するように
することができる。例えば、そのような回復動作のシー
ケンス内の個々の回復動作がエラーからの完全な回復を
もたらすことがステップ２９４でわかった場合は、残り
の回復動作を引き続きループすることは必要でなく、し
たがって非効率的である。同様に、特定の回復動作の反
復が望ましいときなど、特定の条件下でステップ２９３
をステップ２９７に分岐しないようにすることもでき
る。さらに、回復動作で、処理中の現回復動作シーケン
スの内容を変更することができる。ライブラリ１の残り
の特徴は基本的に変わらない。従って、本明細書に開示
した本発明は、頭記の請求項の記載によってのみ限定さ
れるものである。

【００５０】

【発明の効果】本発明によれば、データ処理システム用
の改良されたエラー回復サブシステム、およびエラーか
ら回復するための改良された方法、およびそのためのプ
ログラム装置が提供される。また、システム状態の数を
定義する際の複雑さを低減するエラー回復サブシステ
ム、およびエラーから回復するための方法、およびその
ためのプログラム装置が提供される。さらに、データ処
理システムの構成の変化、システム状態の新たな定義、
新たなエラー状態、およびエラー状態に応じて必要とさ
れる新たな回復動作シーケンスを考慮するために容易に
変更することができるエラー回復サブシステムが提供さ
れる。

【図面の簡単な説明】

【図１】本発明に従って使用されるエラー情報ブロック
および要求ブロックの概略構成図である。

【図２】本発明を実施するための光ディスク・ライブラ
リの正面切開透視図である。

【図３】コンソール・パネルを前に回転させ、ファンを
取り除いた以外は図２と同じ図である。

【図４】図２および図３の光ディスク・ライブラリの背
面切開透視図である。

【図５】図４のロボット式ピッカおよびグリッパの拡大
図である。

【図６】図２ないし５の光ディスク・ライブラリ・ハー
ドウェアの概略図である。

【図７】図２ないし６の光ディスク・ライブラリのシス
テム制御装置の概略構成図である。

【図８】構造化参照言語を使用したユーザ編集可能デー
タ・ファイルの一例を示す図である。

【図９】初期設定中に作成されるエラー回復サブシステ
ムの内部データ構造の概略図である。

【図１０】初期設定中に作成されるエラー回復サブシス
テムの内部データ構造の概略図である。

【図１１】その上側インターフェースで受け取ったネッ
トワーク要求をその下側インターフェースでＳＣＳＩコ
マンド・パケットに変換する際の、光ディスク・ライブ
ラリのシステム制御装置の動作の流れ図である。

【図１２】本発明のエラー回復サブシステムの動作の高
レベル流れ図である。

【図１３】図１２で呼び出される変換ルーチンの流れ図
である。

【図１４】図１２で呼び出される比較ルーチンの流れ図
である。

【図１５】図１２で呼び出される回復ルーチンの流れ図
である。

【符号の説明】

１ 光ディスク・ライブラリ ２ ハウジング ３ 光ディスク記憶セル ４ 内部光ディスク・ドライブ ５ ロボット式ピッカ ６ グリッパ １０ 外部光ディスク・ドライブ １１ コンソール １２ キーボード １７ システム制御装置 ３０ システム・プロセッサ ５０ 汎用ライブラリ・ファイル・サーバ（ＧＬＦＳ） ５１ オペレーティング・システム ６０ 資源管理プログラム ６５ コーディネータ ８０ インタフェース変換プログラム ９０ インタフェース変換プログラム

───────────────────────────────────────────────────── フロントページの続き (72)発明者 クリストファー・ジョン・モナハン アメリカ合衆国 85748、アリゾナ州、 ツーソン、サウス・ソールジャー・トレ ール 1668番地 (72)発明者 メアリー・リンダ・モナハン アメリカ合衆国 85748、アリゾナ州、 ツーソン、サウス・ソールジャー・トレ ール 1668番地 (72)発明者 デニス・リー・ウィルソン アメリカ合衆国 85715、アリゾナ州、 ツーソン、イースト・ピノン・サークル 7855番地 (56)参考文献 特開 昭63−279329（ＪＰ，Ａ)

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】データ処理システムのシステム状態のフィ
   ールドを定義する規則、およびデータ処理システムのエ
   ラー状態を含み、上記規則および上記エラ−状態をユー
   ザが編集することのできるユーザ編集可能ファイルと、 システム状態とエラー状態を比較し、どのエラー状態が
   システム状態と一致するかに応じて回復動作シーケンス
   を呼び出すよう上記ユーザ編集可能ファイルに結合され
   た手段とを含み、これによってエラ−回復サブシステム
   のプログラム・コ−ドをコンパイルしなくてもエラ−回
   復方式を変更することができる、データ処理システムで
   使用するためのエラー回復サブシステム。
2. 【請求項２】上記ユーザ編集可能ファイルには、同じ回
   復動作シ−ケンスを有する異なるシステム状態を１つの
   エラ−状態で表せるようなドントケア変数が含まれる、
   請求項１に記載のエラー回復サブシステム。
3. 【請求項３】上記ユーザ編集可能ファイルが、データ処
   理システムに対する個々の回復動作のリストへのインデ
   ックスである一連の回復動作インデックスを含む、請求
   項１または２に記載のエラー回復サブシステム。
4. 【請求項４】自動化記憶ライブラリのシステム状態のフ
   ィールドを定義する規則を含み、少なくとも１つのドン
   トケア変数を使用する自動化記憶ライブラリのエラー状
   態を含み、さらに自動化記憶ライブラリに対する個々の
   回復動作のリストへのインデックスである一連の回復動
   作インデックスを含み、少なくとも上記規則をユーザが
   編集することのできるユーザ編集可能ファイルと、 システム状態とエラー状態を比較し、どのエラー状態が
   システム状態に一致するかに応じて回復動作シーケンス
   を呼び出すよう上記ユーザ編集可能ファイルに結合され
   た手段とを含み、これによってエラ−回復サブシステム
   のプログラム・コ−ドをコンパイルしなくてもエラ−回
   復方式を変更することができる、自動化記憶ライブラリ
   で使用するためのエラー回復サブシステム。
5. 【請求項５】データ処理システムのシステム状態を決定
   する機械実行ステップと、 システム状態をエラー状態と比較する機械実行ステップ
   と、 どのエラー状態がシステム状態に一致するかに応じて決
   定される、データ処理システムに対する個々の回復動作
   のリストへのインデックスである一連の回復動作インデ
   ックスを使って、どのエラー状態がシステム状態に一致
   するかに応じて回復動作シーケンスを呼び出す機械実行
   ステップとを含む、 データ処理システムでエラーから回復するための方法。
6. 【請求項６】回復動作シーケンスを回復動作によって変
   更することができる、請求項５に記載の方法。