(57)【特許請求の範囲】
【請求項１】
第１のプログラムが第１のデータ記憶装置(31)のデータと相互作用し、第２のデータ記憶装置(33)及び第３のデータ記憶装置(35)の各々が前記第１のデータ記憶装置のデータをミラーするように動作したり、又は第２及び第３のプログラムと各々相互作用するために前記第１のデータ記憶装置から分離されることが可能であり、且つ前記プログラムの各々がそれぞれのデータ記憶装置のデータを変更することができる、複数のプログラム(22,23,24)と共に使用するためのデータ記憶機構（ファシリティ）であって、
Ａ）前記第２のデータ記憶装置を前記第１データ記憶装置のミラーとして設定するため、及び当該設定とは異なる時期に前記第３のデータ記憶装置を前記第１のデータ記憶装置との間で独立して相互作用する前記第１のデータ記憶装置のミラーとして設定するための、前記データ記憶装置に作動可能に接続されたミラー設定手段と、
Ｂ）前記第１のデータ記憶装置から前記第２のデータ記憶装置を分割するための、且つ当該分割とは異なる時期に前記第１のデータ記憶装置から前記第３のデータ記憶装置を分割するための、前記第１のプログラムと前記第１のデータ記憶装置との間の相互作用と同時に作動可能なミラー分割手段であって、前記ミラー分割手段の動作後、前記第２のプログラム及び前記第３のプログラムが、前記第２及び第３のデータ記憶装置のそれぞれで前記データを相互作用することが可能である前記ミラー分割手段と、
Ｃ）前記第２及び第３のデータ記憶装置の１つを任意のタイミングで選択して、当該選択された一方の装置を前記第１データ記憶装置のミラーとして周期的に再設定するための、これらのデータ記憶装置に接続された再設定手段であって、前記第１のデータ記憶装置から前記第２及び第３のデータ記憶装置のうちで選択された一方の装置に対して、前に分割された時点を境にそれ以降、前記第１のデータ記憶装置及び前記選択された一方の装置において変更されたデータに対応するデータのみを、前記第１のデータ記憶装置から前記選択された一方の装置に転送する手段を含む前記再設定手段とを、
備えていることを特徴とするデータ記憶機構。
【請求項２】
各データ記憶装置がブロック内のデータを転送するとともに、前記第１のデータ記憶装置が前記第２及び第３のデータ記憶装置のための第１表を含み、そして前記第２及び第３のデータ記憶装置が、前記第２及び第３のデータ記憶装置のうち対応する一方の装置用並びに前記第１のデータ記憶装置用の個々のデータ記憶装置内のデータブロックに一致し、且つデータのコピー処理を制御するための前記ミラー設定手段、前記ミラー分割手段、及び前記再設定手段により使用されるためのエントリを備えた表を含むように構成され、
更にデータブロックとして前記データ記憶装置の各々にデータを書き込む手段を含み、
前記第１のデータ記憶装置内の書き込み手段は、前記第１表内における前記第２及び第３のデータ記憶装置に対する各エントリを変更し、そして前記第２及び第３のデータ記憶装置の各々における書き込み手段は、個々の表のうち対応した表内のエントリを変更し、これによって前記変更されたエントリが各データブロックのデータに対する変更を識別することを特徴とする請求項１に記載のデータ記憶機構。
【請求項３】
前記第２及び第３のデータ記憶装置のうち選択された一方から、前記第１データ記憶装置にデータを復元するための完全復元手段を更に備えており、前記完全復元手段は、前記第２及び第３のデータ記憶装置のうち選択された一方から前記第１データ記憶装置へと次のデータ全てのコピーを行わせることができ、前記第１記憶装置から選択されなかったもう一方のデータ記憶装置に復元されたデータをコピーすることができることを特徴とする請求項１に記載のデータ記憶機構。
【請求項４】
前記各データ記憶装置がデータブロックによって特徴付けられ、前記第１データ記憶装置が、前記第１のデータ記憶装置用のエントリ（56）、第２及び第３のデータ記憶装置用のエントリ（セッションDDF(1),DDF(2)のPBビット）を備えた第１表を含んでおり、前記第２及び第３のデータ記憶装置はそれぞれ、前記第２及び第３のデータ記憶装置の内の対応する一方の装置に対するエントリを備えた表（63,71）を含んでおり、表内のエントリはデータブロックに対応し、更に、前記データ記憶機構は、前記データ記憶装置それぞれの各データブロックに対してデータを書き込むための手段（30,32,34）を含んでおり、前記完全復元手段は、前記第１データ記憶装置に対する第１表中のエントリを無効（180）に変更し、前記選択されたデータ記憶装置内のエントリを前記選択された記憶装置内のデータは変更されていない（182）と表示するように変更し、前記第２および第３のデータ記憶装置の内の選択されなかったもう一方に対するエントリを選択されなかった各データ記憶装置内のデータは変更された（183）と表示するように変更することを特徴とする請求項３に記載のデータ記憶機構。
【請求項５】
前記第２及び第３のデータ記憶装置の内の選択された一方から前記第１データ記憶装置にデータを復元するための増分復元手段を更に備えており、前記増分復元手段は、前記第２及び第３のデータ記憶装置のうち選択された一方から前記第１記憶装置へと変更後のデータをコピーをさせることができ、前記第１記憶装置から選択されなかったデータ記憶装置に、復元されたデータをコピーすることができることを特徴とする請求項１に記載のデータ記憶機構。
【請求項６】
前記第１データ記憶装置は、前記第１、第２、第３のデータ記憶装置それぞれに対するエントリを備えた第１の表を含んでおり、前記第２及び第３のデータ記憶装置はそれぞれ、前記第２及び第３のデータ記憶装置の内の対応する一方に対する、データのコピー処理を制御するための前記ミラー設定手段、前記ミラー分割手段、及び前記再設定手段により使用されるためのエントリを備えた表を含んでいることを特徴とする請求項５に記載のデータ記憶機構。
【請求項７】
第１のアプリケーションプログラムが第１物理ディスク記憶装置ユニット上に配置された第１記憶装置デバイス内のデータと対話するようになっているデータ処理システムで、前記第１記憶装置デバイス内に記憶されたデータのコピーと同時的且つ独立的に対話するために少なくとも２つの追加的プログラム(23,24)を使用可能にするための方法において、
Ａ）各追加的プログラム用に追加的記憶装置デバイスを識別する段階であって、前記追加的記憶装置のそれぞれはデータトラック内にデータを記憶し、
Ｂ）前記追加的記憶装置デバイス各々に対し、前記第１記憶装置デバイス上のデータトラックに対して加えられた各変更を記録するためのエントリ（PB）を有するセッションリファレンスを、それぞれに定義づける段階と、
Ｃ）前記第１記憶装置デバイス上のデータトラックへの各変更を、前記セッションリファレンスの対応するエントリ内に記録する段階と、
Ｄ）各プログラムがデータトラック中に加える各変更を記録するためのエントリを備えた前記第１及び追加的記憶装置デバイスそれぞれのためのデバイスリファレンスを定義する段階と、
Ｅ）各追加的プログラムとの対話のために、他の記憶装置デバイス上へ前記第１記憶装置デバイス内のデータの独立したコピーを生成する段階と、
Ｆ）各追加的プログラムがそのそれぞれの記憶装置デバイス内に記憶されたデータトラック内に対して加える各変更をデバイス変更リファレンスに記録する段階と、
Ｇ）前記追加的記憶装置デバイスのうちの選択された１つのデバイス上のデータトラックの選択を更新しながら、対応するセッション内のエントリとデバイス変更リファレンスとを論理的に組み合わせ処理(161)して変更されたデータトラックを識別する段階と、
Ｈ）第１記憶装置デバイスの変更されたデータトラックから、選択された記憶装置デバイスの対応するトラックへとコピーする段階とから成ることを特徴とする方法。
【請求項８】
前記独立したコピーを生成する段階が、
i）前記選択された記憶装置デバイス上のデータを前記第１記憶装置デバイス上のデータと同期させる段階と、
ii）同期が達成された後、前記１つの追加的記憶装置デバイスを前記第１記憶装置デバイスから分割し、それにより前記選択された記憶装置デバイスとその対応するプログラムの間の対話を可能にする段階とを含んでいることを特徴とする請求項７に記載の方法。
【請求項９】
前記分割する段階が、前記選択された記憶装置デバイスに対するセッションリファレンス内の各エントリを変更されていないとマークする段階と、対応するデバイス変更リファレンス内の各エントリを有効とマークする段階とを含んでいることを特徴とする請求項８に記載の方法。
【請求項１０】
前記デバイス変更リファレンスの各々が、異なる記憶装置デバイスに対する多数のエントリセットを有しており、前記分割する段階が、
ｉ）前記セッションリファレンス内の対応するエントリが変更されたとマークされた場合には、前記選択された記憶装置デバイスに対するミラーである別の記憶装置デバイス用のデバイス変更リファレンスのあるエントリセット内のエントリを無効とマークする段階と、
ii）前記第１記憶装置デバイスに対応する前記選択された記憶装置デバイスに対する１つのエントリセット内のエントリを有効とマークする段階と、
iii）前記セッションリファレンス内の全てのエントリを変更されていないとマークする段階を含んでいることを特徴とする請求項８に記載の方法。
【請求項１１】
前記第１記憶装置デバイス内のデータは、選択された記憶装置デバイスから復元することができ、この復元する方法が、
ｉ）前記第１記憶装置デバイスに対応する前記第１記憶装置デバイス内の１つのエントリセットの中の全てのエントリを無効とマークする段階と、
ii）前記選択された記憶装置デバイスに対応する前記第１記憶装置デバイスに対するデバイス変更リファレンス内の１つのエントリセットの中の全てのエントリを有効とマークする段階と、
iii）前記選択された記憶装置デバイスに対するセッションリファレンス内の全てのエントリを変更されていないとマークする段階と、
iv）他のセッションリファレンス内の全てのエントリを変更されたとマークして、それにより前記選択された記憶装置デバイス内のデータが前記第１記憶装置デバイス内のデータを復元することが可能で、何れの選択されていない記憶装置デバイスに対しても次のデータ転送が可能になる段階を含んでいることを特徴とする請求項１０に記載の方法。
【請求項１２】
復元すべき前記第１記憶装置デバイス内のデータが、前記第１及び選択された記憶装置デバイスの最前の分割以降に起きた前記第１記憶装置デバイス内のデータ変更に限定され、この復元する方法が、
ｉ）前記選択された記憶装置デバイスに対応する前記第１記憶装置デバイスに対するデバイス変更リファレンス内の１つのエントリセットの中の全てのエントリを有効とマークする段階と、
ii）前記選択された記憶装置デバイスに対するデバイス変更リファレンス内の対応するエントリが有効である場合、又は前記選択された記憶装置デバイスに対するセッションリファレンス内のエントリが変更された場合は、前記第１記憶装置デバイスに対応する前記第１記憶装置デバイス内の１つのエントリセットの中の全てのエントリを無効とマークする段階と、
iii）前記選択された記憶装置デバイスに対するセッションリファレンス内の全てのエントリを変更されていないとマークする段階と、
iv）他のセッションリファレンス内の全てのエントリを変更されたとマークして、それにより前記第１及び選択された記憶装置デバイス内の変更されたエントリに対応するデータ部分だけが前記第１記憶装置デバイスに転送され、それにより、システムは復元されたデータを何れの選択されていない記憶装置デバイスにも転送できるようになる段階を含んでいることを特徴とする請求項７に記載の方法。
【請求項１３】
前記セッションリファレンスを定義する段階が、前記第１記憶装置デバイスと選択された記憶装置デバイスを識別し、且つ前記第１及び追加的記憶装置デバイスそれぞれが各データ部分をデータトラックに記憶し、そして前記デバイスリファレンスを定義する段階が、自身に対応する第１のエントリセットと、前記選択された記憶装置デバイスに対応する第２のエントリセットを定義する段階を含んでおり、前記セッションリファレンス及びデバイスリファレンスを定義する段階それぞれが、対応するエントリとトラックの間に対応を設定することを特徴とする請求項７に記載の方法。
【請求項１４】
独立したコピーを生成する前記段階が、
i）前記選択された記憶装置デバイス上のデータを前記第１記憶装置デバイス上のデータと同期させる段階と、
ii）同期が達成された後、前記選択された記憶装置デバイスを前記第１記憶装置デバイスから分割し、それにより前記選択された記憶装置デバイスとその対応するプログラムの間の対話を可能にする分割段階を含んでいることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記分割する段階が、前記選択された記憶装置デバイスに対するセッションリファレンス内の各トラックエントリを変更されていないとマークする段階と、対応するデバイス変更リファレンス内の各トラックエントリを有効とマークする段階を含んでいることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記分割する段階が、
ｉ）前記選択された記憶装置デバイスに対するセッションリファレンス内の対応するトラックエントリが変更された場合は、何れの鏡映記憶装置デバイスに対するエントリセット内のトラックエントリをも、前記選択された記憶装置デバイスに対するデバイス変更リファレンス内で無効とマークする段階と、
ii）前記第１記憶装置デバイスに対するエントリセット内のトラックエントリを、前記選択された記憶装置デバイスに対するデバイス変更リファレンス内で有効とマークする段階と、
iii）前記選択された記憶装置デバイスに対するセッションリファレンス内の全てのトラックエントリを変更されていないとマークする段階を含んでいることを特徴とする請求項１４に記載の方法。
【請求項１７】
前記第１記憶装置デバイス内のデータが他の記憶装置デバイスの内の選択されたデバイスから復元でき、この復元する方法が、
ｉ）前記第１記憶装置デバイスに対応する前記第１記憶装置デバイス内のエントリセットの中の全てのトラックエントリを無効とマークする段階と、
ii）前記選択された他の記憶装置デバイスに対応する前記第１記憶装置デバイスに対するデバイス変更リファレンス内のエントリセットの中の全てのトラックエントリを有効とマークする段階と、
iii）前記選択された記憶装置デバイスに対するセッションリファレンス内の全てのトラックエントリを変更されていないとマークする段階と、
iv）他のセッションリファレンス内の全てのトラックエントリを変更されたとマークし、それにより追加的記憶装置デバイスのうちの選択された記憶装置デバイス内のデータが前記第一記憶装置デバイス内のデータを復元することが可能な段階を含んでいることを特徴とする請求項１３に記載の方法。
【請求項１８】
復元すべき前記第１記憶装置デバイス内のデータが、前記第１及び選択された記憶装置デバイスの最前の分割以降に起きた前記第１及び選択された記憶装置デバイス内のデータ変更に限定され、この復元する方法が、
ｉ）前記選択された記憶装置デバイスに対応する前記第１記憶装置デバイスに関するデバイス変更リファレンスに対するエントリセット内の全てのトラックエントリを有効とマークする段階と、
ii）前記選択された記憶装置デバイスに対するデバイス変更リファレンス内の対応するトラックエントリが有効である場合、又は前記選択された記憶装置デバイスに対するセッションリファレンス内のトラックエントリが変更された場合には、自身に対応する前記第１記憶装置デバイス内のエントリセットの中の全てのトラックエントリを無効とマークする段階と、
iii）前記選択された記憶装置デバイスに対するセッションリファレンス内の全てのトラックエントリを変更されていないとマークする段階と、
iv）他のセッションリファレンス内の全てのトラックエントリを変更されたとマークし、それにより前記第１及び選択された記憶装置デバイス内の変更されたエントリに対応するデータ部分だけが第１記憶装置デバイス内にデータを復元する段階を含んでいることを特徴とする請求項１３に記載の方法。
【発明の詳細な説明】
【０００１】
（関連特許出願の説明）
ユワル・オフェックの名において「共通データセットへの独立的且つ同期的アクセスのための方法及び装置」に対して付与（１９９７年４月２５日出願）された、本発明と同じ譲受人に対して譲渡されている米国特許証（出願番号第０８／８４２，９５３号）。
【０００２】
マシュー・ギャグニー他による１９９９年２月１７日出願の「冗長なデータ記憶装置を介したデータをカスケードするための方法及び装置」に対する米国特許証、出願番号第０９／２５１，８１２号。但し、この出願は本発明と同じ譲受人に対して譲渡されている。
【０００３】
（発明の技術的分野）
本発明は、概括的にはデータ処理システムに、より厳密には、そのようなデータ処理システムにおいて使用される、独立したアクセスに対してデータを複製するための、そして標準からデータを周期的に更新するための容量を有するデータ記憶機構に関する。
【０００４】
（発明の背景）
上記米国特許証（出願番号第０８／８４２，９５３号）には、通常のデータ処理活動への割込を最小限に抑えた、様々な目的に沿ってデータを複製するための方法及び装置が開示されている。ある特定のインプリメンテーションでは、データ記憶機構はビジネス・コンティヌエーション・ボリューム（ＢＣＶ）コンセプトを使用する。このコンセプトの下では、ホストからＢＣＶ能力を備えたディスク記憶機構への設定コマンドは、第１論理ボリューム（以後「標準ボリューム」と称す）と第２論理ボリューム（以後「ＢＣＶボリューム」と称す）の間の関係を作り出す。記憶機構は、データを標準ボリュームからＢＣＶボリュームへ、順序付けられた様式で、何れのホストアプリケーションにも見えないようにコピーする。つまりは、ホストアプリケーション又はプログラムは、データが標準ボリュームからＢＣＶボリュームにコピーされている時でも、従来のＩ／Ｏリクエストを使って標準ボリュームと通常どおり通信を継続することができる。
【０００５】
ＢＣＶボリュームが標準ボリュームからのデータの正確なコピーを有している場合、ＢＣＶボリュームは「同期した」状態であり、データは複製されている。一旦同期すると、分割コマンドは、標準ボリュームとそのホストアプリケーションの間の活動とは無関係に、他の用途のためＢＣＶボリュームを分離することができる。特に、ＢＣＶボリュームは、標準ボリューム上の何れのデータも壊す恐れ無しに、テスト中の開発プログラム又はバックアッププログラムのような他のアプリケーションプログラムと対話することができる。これらの独立したオペレーションの間、標準ボリュームに関連するアプリケーションは、当該データを変更することができ、その間他のアプリケーションはＢＣＶボリューム上の複製されたデータを変更することができる。各変更はトラック又は他のデータブロックに関して生じる。これらのオペレーションの間に、各変更の位置、又はトラックも識別される。
【０００６】
ＢＣＶボリューム上のデータを標準デバイス上のデータで更新することが求められる場合は、２つの方法のうち一方が使用される。１つ目として、設定コマンドは標準デバイス内の全データがＢＣＶボリュームに対してコピーされるようにする。２番目の方法はより効率的である。再設定コマンドは、標準及びＢＣＶボリューム内で、先の分割コマンド以降データに変更があった位置又はトラック全てを識別する。再設定コマンドは、ここで、標準又はＢＣＶボリュームの何れかで変更になったデータだけが、標準デバイスからＢＣＶデバイスに転送されるようにする。明らかなように、変更されたのが全トラックの１００％よりも少なければ、再設定方式は、ＢＣＶボリュームを標準ボリュームと同期させる時間を省くことができる。
【０００７】
上記特許に開示されている様々なコマンドを使ってＢＣＶボリュームを使用すれば、データ処理にとって非常に強力なツールになることが証明されている。それは各人にデータを取り扱う際の柔軟性を提供し、通常のオペレーションへの干渉を最小に抑えながらデータを複製できる能力のおかげで、データ処理システム全体の信頼性を高める。しかしながら最近では、データを多数のＢＣＶボリュームへ複製し、複製されたデータを反復的に更新することが強く望まれるという、新しい必要条件が浮上してきている。
【０００８】
現在利用可能なシステムには制約がある。２つのＢＣＶボリュームが設定され分割される場合、最も新しく定義された標準−ＢＣＶデバイスペアをつなぐためには再設定コマンドしか使えない。この制約は、標準デバイス内の変更が各ＢＣＶデバイスに対して別々には保守されないことから課せられるものである。そうでなければ、再設定コマンドは拒否される。例えば、第１ＢＣＶボリュームに対して標準−ＢＣＶペア（即ち、標準ＳＴＤ−ＢＣＶ（１）ペア）を設定し、当該ペアを分割し、ＳＴＤ−ＢＣＶ（２）ペアを設定し、当該ペアを分割し、そしてＢＣＶ（１）ボリュームを更新するという場合を想定しよう。先行技術によるシステムでは、ＢＣＶ（１）ボリュームを更新するには設定コマンドを処理することが必要であった。
【０００９】
このような設定コマンドに応じて全てのデータを転送するのに必要な時間は、再設定コマンドに応じてデータを転送する時間をはるかに上回ると考えられる。従って、先行するコマンドシーケンスとは無関係に、多数の標準ＳＴＤ−ＢＣＶペアで再設定コマンドの使用が許される方法及び装置を提供することが強く望まれている。
【００１０】
（発明の概要）
従って、本発明の目的は、標準デバイス上のデータを多数の記憶装置デバイスに複製できるようにするデータ記憶機構を提供し、それにより各コピー内のデータを効率的な方法で周期的に更新できるようにすることである。
【００１１】
本発明の別の目的は、標準デバイス上のデータを多数の記憶装置デバイスに複製できるようにし、且つ標準デバイス内のデータに生じ他の記憶装置デバイスにコピーされた変更を反映するのに必要なデータだけを標準デバイスから転送することにより、コピーを更新できるようにするデータ記憶機構を提供することである。
【００１２】
本発明の更に別の目的は、標準デバイスからの多数のデータのコピーを可能にし、ホストデバイスと標準デバイス内のデータとの間の如何なる対話に関しても効率的に且つ見えないようにそれらのコピーを更新することを可能にするデータ記憶機構を提供することである。
【００１３】
本発明のある態様によれば、データ記憶機構は、第１、第２、及び第３のプログラムそれぞれと個別に対話する第１、第２、及び第３のデータ記憶装置を備えている。第２及び第３データ記憶装置はそれぞれ、異なる時期に、第１データ記憶装置のミラーとして選択的に接続することができる。第２及び第３のデータ記憶装置はそれぞれ、異なる時期に、第１データ記憶装置から取り外し又は分割することもでき、それによりそれらは第２及び第３のプログラムそれぞれと対話することが可能になる。第２及び第３データ記憶装置の一方でデータの更新が求められる場合は、それはミラーとして再設定されるが、対応する第２又は第３のデータ記憶装置において変更されたデータと第１記憶装置において変更されたデータだけが転送される。
【００１４】
本発明の別の態様によれば、データ処理システムは、第１物理ディスク記憶装置ユニット上に位置する第１記憶装置デバイス内のデータと対話できるようになっている第１アプリケーションプログラムを有している。当該同一データのコピーと同時に且つ独立して対話するために、少なくとも２つの追加的なプログラムが使用可能となる。厳密には、システムは、追加プログラムそれぞれに対し、異なる物理ディスク記憶装置ユニット上の追加的記憶装置デバイスを識別する。追加的記憶装置デバイスの各々に対するセッションリファレンスは、第１記憶装置デバイス上のデータの対応する部分に対してなされた各変更を記録するためのエントリを有している。デバイスリファレンスは、それぞれのプログラムが対応する記憶装置デバイス上のデータ部分に対して行なう各変更を記録するためのエントリを備えた第１及び各追加的記憶装置デバイスに対しても設定される。他の記憶装置デバイスへの転送のため、及びそれぞれの各追加的プログラムにより使用するため、独立したコピーが生成される。プログラムがデータ部に変更を行なう都度、そのイベントは、当該プログラムとデータ記憶装置デバイスに関連付けられたデバイス変更リファレンス内に記録され、一方その間もシステムは独立して作動している。要求があり次第、対応するセッション内のエントリとデバイス変更リファレンスを組み合わせて、変更されたデータ部を識別し、第１記憶装置デバイスから選択された記憶装置デバイスへと転送されるデータを制御することにより、選択された記憶装置デバイスにでコピーの更新が行われる。
【００１５】
本発明の別の態様によれば、マルチプロセッサ・データ処理システムは、１つのプログラムが１つのデータ記憶装置デバイス内のデータで作動するデータ記憶機構と、他のプログラムそれぞれが別のデータ記憶装置デバイスと対話する複数の他のプログラムを含んでいる。この１つのデータ記憶装置デバイスからのデータの多数のコピーは、対応するプログラムを使ったオペレーションのため追加的データ記憶装置デバイスそれぞれに作成される。これらのデバイス間の対話は、コピーが作成されることになる追加的記憶装置デバイスそれぞれのための第１バッファと、各追加的記憶装置デバイスと１つの記憶装置デバイスとのための第２バッファとを定義することを含んでいる。１つの記憶装置デバイスからのデータは、追加的データ記憶装置デバイスの１つにコピーされ、それにより別のプログラムが、その１つのデータ記憶装置デバイスで使用されているデータ及びプログラムとは無関係に、追加的データ記憶装置デバイス上のデータコピーと対話できるようになる。この１つのプログラムによりこの１つの記憶装置デバイス上のデータに対して行なわれた各変更、及び他のプログラムにより対応する追加的記憶装置デバイスに対して行われた各変更は、第１及び第２バッファにそれぞれ記録される。独立したオペレーションが完了すると、対応する第１及び第２バッファ内の情報は組み合わせられ、この１つのデータ記憶装置デバイスからある追加的記憶装置デバイスへとコピーされるべきデータを識別し、それによりコピーされるべきデータが使用可能になるので、追加的記憶装置デバイス内のデータはその１つのデータ記憶装置デバイス内のデータを複製する。
【００１６】
(好適な実施例の詳細な説明)
各請求項は、本発明の主題を厳密に指摘し明確に請求している。本発明の様々な目的、利点、及び新しい特徴は、添付図面を参照しながら以下の詳細な説明を読むことによりより深く理解されるであろう。なお、図面では、類似の部分を類似の符号で表している。
【００１７】
図１は、１つ又はそれ以上のホストデバイスを備えたマイクロプロセッサ・ホストアレイ２１がオペレーションを制御する、データ処理システム２０を示している。各ホストデバイスはプログラムを処理するが、以下の説明にある「ホストアプリケーション」とは、ホストで処理されている特定のアプリケーションプログラム、手続き、プロセス、モジュール等を指す。図１は、このようなアプリケーション、即ち、ＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２、ＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３、ＨＯＳＴ  ＡＰＰ  Ｃアプリケーション２４、の３つを示している。
【００１８】
各ホストアプリケーションは、システムバス２６上で、データ記憶機構２５に記憶されているデータにアクセスして処理するが、前記システムバス２６は、シングル及びパラレル・バス構造を含む既知の形態のうち何れの形態であってもよい。説明上、データ記憶機構２５は、ＨＯＳＴ  ＡＰＰ  Ａアプリケーション、ＨＯＳＴ  ＡＰＰ  Ｂアプリケーション、又はＨＯＳＴ  ＡＰＰ  Ｃアプリケーション、２２、２３、２４の何れかで処理されるデータ全てを記憶するものと考えることにする。
【００１９】
本発明は、様々なタイプ及び構成の数多くのディスク記憶機構で実現することができる。以下の説明は、特定のデータ記憶機構２５、即ち、シンメトリクス・ディスク・アレイ記憶装置（ＤＡＳＤ）に関連付けて記述する。しかしながら、このように特定的に説明した実施例を他のデバイスに適用できるということは、当業者には容易に理解されるであろう。
【００２０】
データ記憶機構２５であるシンメトリクス・ディスク・アレイ記憶装置は、相互間で、且つ一連のディスクアダプタ及び物理的ディスクと通信する、ホストアダプタ２７とキャッシュメモリ２８とを含んでいる。図１は、例として、論理ボリューム３１を含む１つ又はそれ以上の論理ボリュームを記憶する物理ディスクのアレイを備えた第１ディスクアダプタ（ＤＡ）３０、論理ボリューム３３を備えたディスクアダプタ３２、論理ボリューム３５を備えたディスクアダプタ３４を示している。本発明を説明する上で、物理デバイスは論理ボリュームを記憶するものとする。図１では、各ディスクアダプタには記憶装置デバイスが１つしか付いていないが、各ディスクアダプタは多数の物理ディスク記憶装置ユニットのオペレーションを制御でき、多数の論理ボリュームにアクセスできることは言うまでもない。
【００２１】
しかしながら、よく知られているように、論理ボリュームは、１つの物理デバイスの一部分、物理デバイス一式、多数の物理デバイスの各部分を備えていてもよいし、又更には物理デバイス一式を多数個具備していてもよい。本説明では以下の語が使用されている。図１に関して「標準デバイス」とは論理ボリューム３１を意味し「ＢＣＶ（１）デバイス」及び「ＢＣＶ（２）デバイス」はそれぞれに論理ボリューム３３及び３５を意味する。
【００２２】
バス３６は、ホストアダプタ２７、キャッシュメモリ２８、及びディスクアダプタ３０、３２、３４を含むディスクアダプタと相互接続している。アダプタ２７、３０、３２、３４それぞれは、コマンドに応じて様々なオペレーションを実行するためのプログラム可能な制御を含んでいる。加えて、各ディスクアダプタは、コピープログラム３７、３８、３９のようなコピープログラムをディスクアダプタ３０、３２、３４それぞれに含んでいる。
【００２３】
図２は、本発明に関連するキャッシュメモリ２８の部分、厳密には図１に示している書き込みペンディングスロット４２及びデバイスヘッダ４３について詳しく示している。キャッシュメモリ内のデータ構造を書き込みペンディングスロットとデバイスヘッダとして使用することは、当技術では一般的によく知られている。図２の書き込みペンディングスロット４４のような個々の書き込みペンディングスロットは、ヘッダ４５を含んでおり、そのヘッダの後にデータブロック４６のデータがついている。普通は、このデータブロックは１物理トラック分のデータを保有している。各ヘッダ４５は、書き込みオペレーションが必要か、それとも書き込みペンディングスロット４２の１つから物理ディスクデバイス内のある位置へデータをデステージする必要があるかを指示するＷＰフラグ４７を含んでいる。一旦、データがキャッシュメモリ２８から対応するデータ記憶装置デバイスに転送されると、システムはそのスロットに対するＷＰビット４７をクリアする。各ヘッダには、本発明とは関係のない他のデータも含まれているが、ここには図示しない。
【００２４】
デバイスヘッダ４３は、シンメトリクスＤＡＳＤ内の各記憶装置デバイス毎にエントリを１つずつ含んでいる。このようなエントリである３つのエントリ、即ち、標準デバイス３１用のエントリ４８、ＢＶＣ（１）デバイス３３用のエントリ４９、ＢＣＶ（２）デバイス３５用のエントリ５０を示している。これらエントリの各々は同じ編成である。つまり、デバイスエントリ４８は、ヘッダ５１とデバイス３１内の各シリンダ毎の複数のエントリを含んでいる。３つの特定のエントリ、即ちシリンダ０エントリ５２、シリンダ１エントリ５３、及びシリンダｎエントリ５４を示している。
【００２５】
シリンダ０エントリ５２のような各シリンダエントリは、トラックＩＤ表５５のようなトラックＩＤ表を定義する位置のブロックを指し、各位置はシリンダ内の特定のトラックに割当てられている。トラックＩＤ表５５には、２つのトラックエントリ、即ち、個々の物理デバイスに対するトラック０エントリ５６とトラックＥエントリ５７が示されているが、シリンダ毎に１５のデータトラックがある。
【００２６】
デバイスエントリ４９は、ヘッダ６１とシリンダエントリを含んでいるブロック６０を備えている。図２では、トラックＩＤ表６３を識別するシリンダ０エントリ６２を含む３つの特定のシリンダエントリを示している。トラックＩＤ表６３は、この特定の実施例では、２つのエントリ、即ちトラック０エントリ６４とトラックＥエントリ６６を含んでいる。ブロック６０の追加的シリンダのエントリも含まれることになる。図２では、このようなエントリを２つ、即ちシリンダ１エントリ６７とシリンダｍエントリ６８を示している。デバイスエントリ５０は同じデータ構造になっており、ヘッダとシリンダエントリを備えたブロック７０を含んでいる。各シリンダエントリはトラック表７１を指すことになる。
【００２７】
各トラックＩＤ表に対応して、データブロック若しくは、ＰＢ表とも呼ばれる「保護ビット」を含んでいる表がある。このようなＰＢ表の１つ７２は、ＰＢヘッダ７３によりトラックＩＤ表５５に対応付けられている。このＰＢ表７２は、シリンダ内のトラック毎に１行、セッション毎に１列の２次元アレイと捉えることができる。集合的に、標準デバイス内の全シリンダに対するＰＢ表は、標準デバイス内の多数のセッションと各トラックを規定している。以下の論において、「ＰＢ表７２」とは、図２に示す個々の表、又は標準デバイス内の全シリンダに対するこのような特定の表の集合体のことを言う。
【００２８】
シンメトリクス・ディスク・アレイ記憶装置システムにおいて、各行は２バイト幅で１６セッションまでを規定する。以下の論において、特定のＰＢビット位置は、ＰＢ（ｘ，ｙ）の形で識別され、ｘはシリンダ内のトラックを示し、ｙはセッション番号を示す。図２は、ＤＤＦ（１）及びＤＤＦ（２）セッション等のようなセッションを示しており、ＤＤＦ（ｎ）は本発明のプリセスを取り入れたセッション用の名称である。１６ビット幅の表では、１６のセッションを定義することができる。しかしながら、ＰＢ表は本発明以外のアプリケーションにも使用することができるので、ＤＤＦセッションの数は制限してもよい。より厳密に言えば、ＤＤＦセッション生成中は、他のセッションの生成と同様に、標準デバイスに対応付けられたコントローラが、何れの「ｙ」桁が利用できるかを判定する。ある桁が利用できるのであれば、コントローラは、選択されたＰＢビット桁に相関付けられたセッション・アイデンティフィケーションを設定する。
【００２９】
米国特許証出願番号第０８／８４２，９５３号に記述されている先行技術によるデータ記憶機構では、データをトラックに書き込むためのＩ／Ｏリクエスト、即ち書き込みリクエストは、トラックＩＤ表のＭ１からＭ４ビット位置により表される様々なトラックＩＤ表を変更する。この発明は、標準デバイスに関連付けられたＰＢ表と、標準及びＢＣＶデバイスに関連付けられたトラック表との組み合わせを用いて、１つの標準デバイスに関して多数のＢＣＶセッションを使用可能にする。図１に示すように、これは標準デバイス３１上のデータが、異なる時期に、ＢＣＶ（１）デバイス３３及びＢＣＶ（２）デバイス３５に複製できるようにする。ＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２は、標準デバイス３１と継続して作動する。分割後、ＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３は、ＢＣＶ（１）デバイス３３と作動可能になり、ＨＯＳＴ  ＡＰＰ  Ｃアプリケーション２４は、ＢＣＶ（２）デバイス３５と作動可能になる。明らかになっていくであろうが、ＰＢ表とトラック表を組み合わせることにより、ＢＣＶデバイス３３又は３５のどちらもが、どんな順序ででも標準デバイス３１から更新できるようになる。
【００３０】
図３は、書き込みリクエストへ応答する時のデータ記憶機構２５の作動に対する修正を示している。先行技術によるデバイスでは、ステップ８０は、ホストアダプタ内のホストアプリケーションの１つからの書き込みリクエストの受信を表す。ステップ８１はこのリクエストをステージする。次に、ディスクアダプタはステップ８２で書き込みリクエストを受信し、変更すべきトラックを識別する。
【００３１】
書き込みリクエストに対する正確な応答は、標準デバイス又はＢＣＶデバイスとしての論理ボリュームの状態によって決まる。ステップ８４が、書き込みリクエストが標準デバイスに向けたものであると判定すると、ステップ８４は制御をステップ８５に送る。ステップ８５は、識別されたトラックに対するＰＢ表内のあるビットを各セッション毎の変更値にセットする。つまり、これらが２つのＤＤＦセッション、即ちＤＤＦ（１）及びＤＤＦ（２）であり、書き込みリクエストが標準デバイス３１のトラック１を識別している場合、ＰＢ表７２のＤＤＦ（１）とＤＤＦ（２）列内のトラック１ビット（即ちＰＢ（ＤＤＦ（１）、１）ビットとＰＢ（ＤＤＦ（２）、１）ビット）が「変更された」値を引き継ぐことになる。以下の議論では「Ｃ」は「変更された」値を示し「Ｕ」は「変更されていない」値を示す。この「変更された」値を表すのに「１」ビットか「０」ビットのどちらを使うかは好みの問題であるが、本発明のある特定の実施例では「変更された」値を「０」としている。ステップ８５はここで、ステップ９０においてトラック（図示せず）に対する書き込みペンディングフラグがクリアできるという承認を返す前に、制御を、完了状態を通知するステップ８６及び書き込みオペレーションを実行するステップ８７に転送する。
【００３２】
識別されたトラックが、ＢＣＶ（１）デバイス３３又はＢＣＶ（２）デバイス３５のようなＢＣＶデバイス内にあれば、ステップ８４は、制御をステップ９１に転送するす。ステップ９１は、対応するＢＣＶトラック表の「Ｍ４」ビットを無効に設定する。ＢＣＶオペレーションでは、このビットは「Ｍ４ｂ」ビットという名称で指定される。図１のＨＯＳＴ  Ｂアプリケーション２３が、書き込みリクエストを、デバイス３３のシリンダ０トラック０に対して生成したものと想定する。ステップ９１は、トラックＩＤ表６３の行６４のＭ４ｂの状態に無効状態を表示させる。以下の議論において「Ｖ」及び「Ｉ」はそれぞれ有効及び無効を表す。シンメトリクス・インプリメンテーションでは、Ｖ及びＩ値はそれぞれ「０」及び「１」である。
【００３３】
以下の議論では、「〜としてマークされた」という語句を用いるが、これはビット位置に関して起こされるアクションのことである。明らかになることだが、ほとんどの状況において、特定のビット位置の状態は予測不可能である。我々は、先行状態とは関係ない最優先オペレーションを表すために「〜としてマークされた」という語句を用いる。
【００３４】
設定コマンド
このような背景が理解された上で、これより、ＢＣＶデバイスに記憶された標準デバイスからの多数のデータのコピーを使用する、多数の独立して作動するセッションを使用可能にする様々なコマンドについて説明する。このようなセッションは何れも、ホストアプリケーション又は他のソースが設定コマンドを発行すると開始される。設定コマンドは、標準デバイス３１のような標準デバイスと、ＢＣＶデバイス３３又は３５の内の１つのようなＢＶＣデバイスを識別する。図１のホストアダプタ２７のようなホストアダプタがステップ１００でコマンドを受信すると、エラーが存在する場合には打ち切るために、ステップ１０１でエラーについて検査する。エラーがなければ、ホストアダプタはステップ１０２で設定リクエストを発行する。
【００３５】
ディスクアダプタがステップ１０３で設定リクエストを受信すると、ディスクアダプタコントローラはそのリクエストがあるセッションを識別しているかどうかを判断する。標準デバイスとＢＣＶデバイス間に関係を確立させるという初期の試みの場合に当てはまるように、セッションが含まれていないのであれば、ステップ１０４は、ＤＤＦセッション番号の割り付け及び標準デバイスに関係付けられたＰＢ表内の対応するビット位置の選択を含む、多数のテスト及び機能を実行するステップ１０５に制御を転送する。加えて、他の機能も実行できる。ステップ１０５は又、必要なリソースが利用可能なことを保証する。図１及び２のシステムに関連して、ステップ１０５は、標準デバイス３１とデバイス３３ＢＣＶ（１）をペアにしたＤＤＦ（１）セッションを確立することができる。条件が適合しない場合は、エラーメッセージが送信される。全てのテストにパスすると、ステップ１０５は制御をステップ１０６に転送し、設定機能は、米国特許証出願番号第０８／８４２，９５３号に開示されているのと同じやり方で続ける。セッションが設定リクエスト用に定義されているのであれば、ステップ１０４はステップ１０５を迂回して制御を１０６に転送する。
【００３６】
以降のステップは、選択されたＢＣＶボリュームを何れの対応するアプリケーションからも隔離し、選択されたＢＣＶデバイスをミラーとして標準デバイス３１に接続する。知られているように、これが起きると、トラック表又はミラー位置のある特定の列が、他のミラーデバイスのトラックの状態を表すものとして指定される。これは、いつも未使用のミラー位置として選択される。これが起きると、正確な位置が変更されることになり「ＭＭ」という名前で移動ミラーと呼ばれる。設定コマンドは、標準デバイスに関係付けられた全ての移動ミラービットを無効状態にする。これにより、標準デバイス上のコピープログラムが、選択されたＢＣＶデバイスにデータをコピーできるようになる。ＢＣＶデバイスが標準デバイスと同期しているときは、通常の鏡映オペレーションが継続される。
【００３７】
厳密には、ステップ１０６は、対応するＢＣＶデバイスをＢＣＶミラーとして選択し、先に説明したように、次に利用可能な標準デバイスミラーを加える。本発明の構成には入っていないが、当技術ではよく知られている種々のブックキーピングオペレーションも実行される。ＢＣＶデバイスと、それと共に作動するプログラムとの間のこれ以上の通信は不可能なので、ステップ１０７は、選択されたＢＣＶデバイスに対する全ての書き込みペンディング・オペレーションを捨てる。ステップ１０８は、選択されたＢＣＶデバイスをその機能において、対応するアプリケーション用の記憶機構として、ノット・レディ（ＮＲ）にセットすることにより隔離を完遂する。
【００３８】
次にステップ１１０は、標準デバイストラックＩＤ表の全移動ミラー（ＭＭ）トラック状態ビットを無効状態にセットする。標準デバイス内の割り当てられていないＭ１からＭ４ビット位置の内の何れか１つは、ミラーデバイスの状態を表すために割当てることができる。割当てられたビット位置はＭＭビット位置と呼ばれる。全ＭＭビットを無効とマークすることにより、標準デバイスからの全データが選択されたＢＣＶデバイスに確実にコピーされることになる。従来の設定コマンドが発行された場合には、ステップ１１１は、制御をステップ１１２に転送し、そこで、ステップ１１３でホストアダプタに送り戻すため、そして設定コマンドを発行しているアプリケーションに更に転送するため、完了状態を通知する。しかしながら、本発明により、あるセッションが含まれている場合は、ステップ１１１はプロセス中にステップ１１４を挿入する。ステップ１１４は、対応するＰＢ表内のセッションと関係付けられた全てのトラックエントリを「変更された」セットとしてマークする。こうして、設定コマンドがＤＤＦ（０）セッションとして生成される場合は、ＰＢ表７２を含む全てのＰＢ表内の全てのＰＢビットが「変更された」値を反映することになる。その後、完了状態はステップ１１２で通知され、ステップ１１３で転送されることになる。一旦、このプロセスが完了すると、デバイスアダプタ３０内のコピープログラム３７は、標準デバイス３１からの全てのデータを、ミラーとして機能する選択されたデバイスへとコピーする。
【００３９】
分割コマンド
一旦、設定コマンドが発行されると、標準デバイスと選択されたＢＣＶデバイスとの間の関係は、ＢＣＶボリュームの同調の後まで継続する。次に、分割コマンドは、ＢＣＶデバイスとその対応するアプリケーションとの間の経路を作り出すことができる。例えば、図１で、設定コマンドが、標準デバイス３１とＢＣＶ（１）デバイス３３との間にＢＣＶ関係を作り出す場合は、分割コマンドは標準デバイス３１とＢＣＶデバイス３３を隔離して、デバイス３３に、ＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３にセットされた複製データを再び接続する。図５で説明したように、手続きは、ホストアダプタがステップ１２１で分割コマンドを受信すると開始される。ホストアダプタはステップ１２２で様々な状況をテストする。例えば、ある特定のテストは、ＢＣＶデバイスが標準デバイスと実際に同期しているか否かを判定する。エラー状況が存在する場合は、ステップ１２２はステップ１２３に逸れ、応答を打ち切る。そうでなければ、ステップ１２４はデバイスアダプタに分割リクエストを発行し、他のホストから当該デバイスアダプタへの以降の通信を遮断する。
【００４０】
ステップ１２５で、選択されたＢＣＶデバイス用のデバイスコントローラは、分割コマンド又はリクエストを受信する。分割コマンドに対する応答の間、如何なる活動をも防止するために、何れのミラーデバイスもステップ１２６でロックされる。これにより、分割コマンドに対する応答が処理されている間は、何れの新規の書き込みリクエストも他のホストから当該デバイスに通知されないようになる。ステップ１２７では、選択されたＢＣＶデバイスに関係付けられたデバイスコントローラは、ＢＣＶミラーを標準デバイスから取り外し、ＢＣＶ（１）デバイス３３用のＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３のような、その元々のＢＣＶアプリケーションに再び割り当てる。構成変更を反映するため、あるデバイスの記録を更新するというような種々のブックキーピング手続きが実行される。次に、ＢＣＶデバイスのそのミラーオペレーションという意味での状態は、ミラーとして機能しているデバイスをノット・レディ（ＮＲ）状態にセットすることにより停止される。
【００４１】
ステップ１３０は、選択されたＢＣＶデバイスに対する何れの書き込みペンディング・オペレーションをも、当技術では知られているやり方で管理する。制御はここでステップ１３１へ移り、識別表を標準デバイスから選択されたＢＣＶデバイスへコピーする。
【００４２】
ステップ１３２は、分割コマンドが、米国特許証第０８／８４２，９５３号に開示されている完全分割コマンドであるのか、米国特許証出願番号第０９／２５１，８１２号に開示されている差分（ＤＩＦＦ）分割コマンドであるのかによって、次のオペレーションを制御する。完全分割コマンドが関係する場合は、ステップ１３２は、制御をステップ１３３に転送し、全てのＭ４ｂビット、即ち選択されたＢＣＶデバイス・トラックＩＤ表のＭ４ビットを有効とマークする。従って、ＢＣＶデバイスがデバイス３３であれば、トラックＩＤ表６３内の全てのＭ４ビットが「有効」とマークされる。これは、選択されたＢＣＶデバイスに対して、その対応するアプリケーションはデータに何の変更も行なわなかったことを示している。
【００４３】
ＤＩＦＦ分割リクエストが関係する場合は、トラック毎に解析が実行されねばならない。ステップ１３２は、トラックを選択することでループを始めるステップ１３５に制御を転送する。ステップ１３５は、ここで、対応するビットが「変更された」とマークされているかどうかを判定することにより、書き込みリクエストが割り込んできて標準デバイスのデータを変更したかどうかを判定する。ＤＤＦ（ｎ）ビットが「変更された」とマークされていれば、ステップ１３５は、制御をステップ１３５に転送する。ステップ１３６は対応するＢＦＭビットをどれも無効とマークする。ＢＣＶボリュームは独立して作動してもよいし、分割された後に他のミラーと一緒に作動してもよい。このようなミラーが存在するのであれば、それらはＢＣＶデバイス用のトラックＩＤ表中に識別される。例えば、ＢＣＶデバイス３３がＭ２ミラーと共に作動している場合は、トラックＩＤ表中のＭ２ビット位置は、ＢＦＭビットとして指定されることになり、トラック毎に１ビットが割当てられる。このようなミラーデバイスが存在しなければ、ステップ１３６は何れのビット値も変更しない。
【００４４】
ステップ１３７は、もっと多くのトラックをテストすることによりループを終了する。より多くのトラックが存在する場合、ステップ１３８は、制御をステップ１３５に戻す。そうでなければ、ステップ１３７は、制御をステップ１３８に転送し、選択されたＢＣＶデバイスに対するトラックＩＤ表中の全てのＭ４ｂビットを有効とマークする。
【００４５】
ステップ１３３がその機能を完了した後、制御はステップ１３４に移動し、そこでセッションに対する全てのＤＤＦ（ｎ）ビットが「変更されていない」とマークされる。つまり、分割コマンドが、標準デバイス３１をＢＣＶデバイス３３に関連付けているセッションを識別するのであれば、セッション識別子ＤＤＦ（１）により、図２のＰＢ表７２のＤＤＦ（１）列内の全てのビットは「変更された」とマークされることになる。これにより、ＰＢ表は確実に、選択されたＢＣＶデバイス上に複製データを正確に反映するものとなる。
【００４６】
次に、ステップ１４０は、その対応するアプリケーションに関して、選択されたＢＣＶデバイスをレディ状態にセットする。ステップ１４１は、ステップ１４２でホストアダプタに戻すため完了状態を通知する。これが起きると、ＢＣＶデバイス３３の場合はＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３のような、選択されたＢＣＶデバイスに対応するアプリケーションは、分割コマンドの時に存在したコンテキストの複製データと対話できるようになる。このデータの処理は、標準デバイスと対話しているアプリケーション、及びＢＣＶデバイス３５のＨＯＳＴ  Ｃ  ＡＰＰアプリケーション２４のような、他のＢＣＶデバイス上でデータを処理するための他のアプリケーションの処理と並行して又は同時に起きる。
【００４７】
先に指摘したように、図１のＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２のようなアプリケーションは、標準デバイス３１上のトラックを変更するので、図２のトラックＩＤ表５５内の対応するトラック位置をマークし、全てのセッションに対しＰＢ表７２中の対応するビットを「変更された」とマークする。つまり、ＤＤＦ（１）及びＤＤＦ（２）セッションがアクティブであれば、標準デバイス３１に対する書き込みリクエストは、ＰＢ表７２中のＤＤＦ（１）列及びＤＤＦ（２）列の双方について対応するトラック位置を変更する。
【００４８】
例えば、関係するＢＣＶデバイスがＢＣＶデバイス３３であると仮定すると、ＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３は、ＢＣＶデバイス３３上のデータを変更する。これにより、変更されたトラックに対するＭ１ビット位置は有効とマークされ、Ｍ４ｂビット位置は無効とマークされ、当該トラックは標準デバイス上の対応するトラックともはや同期していないことが表示される。
【００４９】
分割コマンドが処理された後、別のアプリケーションプログラムが、図３に従って取り扱われる書き込みリクエストを発行する。時間中、所与のセッションに関する全てのＰＢビット、並びに対応するＢＣＶデバイスに対するＭ４ｂビットは、ＢＣＶデバイス及び標準デバイスに対してなされた全ての変更を、トラック毎に（即ち、トラック単位で）まとめて表示することになる。
【００５０】
再設定コマンド
場合によっては、特定のＢＣＶデバイス上の複製データを更新することが望ましいこともある。その１つのアプローチは、別の設定コマンドを発行することである。しかしながら、再設定コマンドは、標準デバイスから選択されたＢＣＶデバイスまで、どちらかのデバイスにおいて変更されたトラックのデータを転送することしかしない。これにより、設定コマンドの処理にかかる時間のうち転送する時間をかなり削減できる。
【００５１】
図６は、再設定コマンドに応答して、ホストアダプタ及び選択されたデバイスコントローラが行う手続きを示している。先の事例のように、ホストアダプタはステップ１５０でホストから再設定コマンドを受信し、ステップ１５１でエラーをテストする。エラーが発見されると、ステップ１５２は処理を打ち切り、適当なエラーコードを出す。先行システムにおいては、指定されたＢＣＶデバイスが設定コマンドを初期化するデバイスでなかった場合に、このようなエラーが起きた。本発明によれば、再設定コマンドがセッション中のどんなＢＣＶデバイスでも識別できるので、そのようなエラーはもはや起きない。エラーが存在しないとすると、ステップ１５３はディスクアダプタに再設定リクエストを出し、他のコマンドに応答する際に行われる切断と同じやり方で切断を実行する。
【００５２】
ステップ１５４では、デバイスアダプタは再設定リクエストを受信する。ステップ１５５は、ローカルＢＣＶミラーとして選択されたＢＣＶデバイスに、次に利用可能なデバイスミラー指定を加える。ステップ１５６で、ＢＣＶデバイスは、図１のＢＣＶデバイス３３に対するＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３のような、対応するアプリケーションに対してノット・レディ（ＮＲ）にセットされる。ＢＣＶデバイスに対する全ての書き込みペンディングはステップ１５７で無効にセットされる。
【００５３】
ステップ１６０は、次に、記憶装置デバイスがトラック毎ベースに解析されるループ内の第１ステップとして、あるトラックを選択する。ステップ１６１は、選択されたＢＣＶデバイス用のトラックＩＤ表から選択されたトラックに対するトラックＭ４ｂビットを、ＤＤＦセッション用の選択されたトラックに対するＰＢビットと組み合わせる。例えば、ＤＤＦ（１）セッションが、標準デバイス３１とＢＣＶ（１）デバイス３３の間の関係を確立する場合、ステップ１６７は、図２のトラックＩＤ表６３からのＭ４ビットと、ＰＢ表７２のＤＤＦ（１）列からの対応するＰＢビットを、論理ＯＲ演算で組み合わせる。その結果により、標準デバイス３１又はＢＣＶデバイス３３の何れかで特定のトラックが変更されたか否かが識別される。
【００５４】
ステップ１６２は、対応するＭＭビットを、そのビットの組み合わせに基づいてマークする。組み合わせは通常、論理ＯＲ演算である。ステップ１６３は、ここで、全てのトラックを解析し終えたかどうかを判定する。解析が終わっていなければ、ステップ１６４は次のトラックを選択して、制御をステップ１６０に戻す。解析が完了していれば、システムはステップ１６５を用いて、完了状態を通知し、ステップ１６６で、その状態をホストアダプタを介して再設定コマンドのソースに転送して戻す。
【００５５】
ステップ１６０で開始したループが終了すると、標準デバイス内のＭＭビットは、標準デバイスから選択されたＢＣＶデバイスへ転送する必要のある各トラックを識別する。次に、コピープログラム、一般的には標準デバイスに関係付けられたコピープログラムは、ＭＭビットを使って転送を制御する。
【００５６】
このプロセスの間に、ＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２が標準デバイス３１に対して書き込みリクエストを生成すれば、対応するＰＢビットを変更することになる。しかしながら、再設定コマンドがアクティブである限り、ステップ１６０で開始されたループは作動するので、新規データは、次の分割で、選択されたＢＣＶデバイスに転送される。
【００５７】
復元コマンド
図７は、標準デバイスの全てのデータを選択されたＢＣＶデバイスから復元する復元コマンドを示している。この手続きは、ＢＣＶデバイスが有効コピーを持っている間に、標準デバイスに故障が起きた場合に役立つ。例えば、ＢＣＶデバイスの１つがバックアップ・オペレーションに使用中であれば、分割コマンド後にはデータは一切変更されない。ディスクの故障又はファイル破壊というイベントが起きた場合、復元コマンドは、特定のＤＤＦセッションに対する先の分割コマンドの時に存在していたバージョンで、標準デバイス内のデータを復元する。
【００５８】
図７に示すように、ホストアダプタはステップ１７０で復元コマンドを受信して、ステップ１７１でエラー状況をテストする。ＢＣＶデバイスが無効トラックを有する場合、標準デバイスに対して書き込みペンディング・オペレーションがある場合、又は標準デバイスがノット・レディ（ＮＲ）状態により特徴づけられている場合には、復元コマンドに固有のエラー状況が存在する。ステップ１７２は、このようなエラー状況が存在するのであれば、復元コマンドの何れのプロセッシングをも打ち切る。
【００５９】
エラー状況が存在しないならば、ステップ１７３は復元リクエストを発行し、次に切断する。デバイスアダプタがステップ１７４で復元コマンドに出会うと、ステップ１７５で、選択されたＢＣＶデバイスに対する次に利用可能な標準ミラーデバイス指定を選択する。ステップ１７６は、ＢＣＶデバイスを、当該デバイスが対応するアプリケーションに対してもはや使用可能状態にないか又は利用できないことを表示することにより、そのアプリケーションから隔離する。
【００６０】
様々なペンディングになっている書き込みオペレーションはステップ１７７で管理される。選択されたＢＣＶに対する書き込みペンディング・オペレーションが存在する場合には、同一の書き込みペンディング・キャッシュ・スロットが保守されるが、その属性は、ＢＣＶデバイスではなく標準デバイスのデバイス番号を反映するため、そしてミラーが、現在、ＢＣＶデバイス上の第１の利用可能なローカルミラーではなく、標準デバイスにミラーとして関係付けられていることを反映するために、変更される。先行技術で既知のように、種々の書き込みペンディング及びイン・キャッシュ・フラグがここでセットされる。
【００６１】
復元コマンドの実行例として、選択されたＢＣＶデバイスだけが有効なデータを保持していると仮定すれば、デバイスコントローラは、ステップ１８０を用いて、標準デバイス及びあらゆるローカルミラーに対するトラックＩＤ表内の全てのエントリを無効とマークする。ステップ１８１では、コントローラは、有効とされている選択されたＢＣＶデバイスに対する標準デバイス表内の全てのトラックを有効とマークする。標準デバイスに対するトラックＩＤ表内に常駐しているのはＭＭビットである。ステップ１８２では、現在のＤＤＦセッションに対する全てのトラックエントリは「変更されていない」とマークされる。つまり、関連セッションがＤＤＦ（１）セッションであれば、図２のＤＤＦ（１）ＰＢ表７２内の全てのトラックは「変更されていない」値にセットされる。ステップ１８３では、ＤＤＦ（２）セッションのような他の全てのＤＤＦセッションに対するＰＢビットは「変更された」とマークされる。ステップ１８４は、完了状態を通知し、ステップ１８５は、その状態を、ホストアダプタを介してリクエスト中のアプリケーションに戻す。これに伴い、標準デバイスに関係付けられたコピープログラムは、ここで、トラックＩＤ表５５のようなトラック表のＭＭビット内の信号の状態を使って、選択されたＢＣＶデバイスからデータをコピーし、当該データ全てを標準デバイスに復元する。
【００６２】
増分復元コマンド
増分復元コマンドは、先回の分割コマンド以降標準デバイス内で変更されたトラックに対応するＢＣＶデバイス内のトラックからのデータだけを転送することにより、標準デバイスを選択されたＢＣＶデバイスと同期状態にする。これにより、完全復元を実行する高価なオーバーヘッドを使わずに、デバイスとの同期が確立できる。図８は、ホストアダプタがステップ１９２で増分復元コマンドを受信して、ステップ１９１でエラーのテストを行い、エラーが存在すればステップ１９２で打ち切る、というプロセスを示している。エラーが存在しなければ、制御はステップ１９３に移り、増分復元コマンドをシステムバス上でデバイスアダプタに送る。
【００６３】
ステップ１９４は、デバイスアダプタでの、増分リクエストの受信を表している。ステップ１９５及び１８６は、図７のステップ１７５及び１７６と同じやり方で作動する。ステップ１９７は、標準デバイスに対するあらゆる書き込みペンディング・オペレーションを、それらを無効とマークすることにより処理する。ステップ２００は標準デバイス表内の全てのＭＭビットを有効とマークする。
【００６４】
次のステップ２０１は、トラック毎に解析するためのループを開始する。各トラック毎に、ステップ２０２は、選択されたＢＣＶデバイスに関するＭ４ｂビットが有効であるか否かを判定する。ステップ２０３は、ＤＤＦ（ｎ）セッションに関するＰＢビットが変更されているか否かを判定する。何れの場合にも、制御は２０４に移り、選択されたトラックに対する標準デバイス内のＭＭビットを無効とマークする。ステップ２０５は、選択されたトラックに対するＤＤＦ（ｎ）セッションに関する対応するＰＢビットを「変更されていない」とマークする。次に、ステップ２０６は、当該トラックに関する他の全てのＤＤＦセッションに対する全てのＰＢビットを「変更された」とマークする。
【００６５】
ステップ２０７はループ制御として機能し、ステップ２１０で次のトラックが識別され、制御はステップ２０２に戻る。全てのトラックが調べられると、ステップ２０７は制御をステップ２１１に転送し、ここで完了状態が通知され、ステップ２１２はこの状態を、ホストアダプタを介して、増分復元コマンドを発行しているアプリケーションに転送することができる。
【００６６】
特定の例
図３から図８はそれぞれ特定のオペレーションを定義している。本発明については、特定の構造コマンドシーケンスを使った特定の例を参照することにより、理解が一層深まるであろう。図９は、メインアプリケーションと２個のミラーを使って作動する標準デバイス３１を備えたデータ記憶機構２２０を示している。特定のミラー位置を特定の順序で識別するための要件がないので、図９では、標準デバイス３１は、ミラー２２２をＭ２ミラーとして、そしてミラー２２３をＭ４ミラーとして割当てている。その結果、トラックＩＤ表内のＭ１とＭ３ビット位置は未使用のままとなる。ＢＣＶ（１）と表示されている第１ＢＣＶデバイス３３は、バックアップ・オペレーションのためにデータを提供するよう構成されている。この場合、バックアップアプリケーション２３は、ＢＣＶ（１）デバイス３３から、テープバックアップまたは他の媒体のバックアップ機構に、データを周期的にコピーする。これは、そのトラックＩＤ表内にＭ１ミラーとして割当てられる。Ｍ２及びＭ３ビットは割り当てられていない。Ｍ４ビットはＭ４ｂビット位置である。第２ＢＣＶデバイス、即ちＢＣＶ（２）デバイス３５は、Ｍ２ミラー２２４、及びＭ３／ＲＩミラーと表示されたＭ３／ＲＤＦ（遠隔データ機構）ミラー２２５を含んでいる。ＲＤＦミラーは当技術では既知である。
【００６７】
この特定の配置を使うと、様々なトラックＩＤ表ビットに対して、代わりの指示が適用できる。標準デバイス３１はＭ２及びＭ４ビット位置を占めている。ＢＣＶデバイスが使用されるとき、次に利用可能な位置がそのＢＣＶデバイスに割当てられる。図９の標準デバイスの場合、次に利用可能な位置はＭ１位置であるので、標準デバイスが設定コマンド又は再設定コマンドの間にＢＣＶデバイス３３又は３５の何れかにつながると、それはＭＭビット位置になる。ＢＣＶ（１）デバイス３３はＭ１ミラーと定義され、Ｍ４ビット位置はＭ４ｂビット位置である。ＢＣＶデバイス３３が自身のプログラムで作動している場合、Ｍ１ビット位置はＭＭビット位置である。ＢＣＶデバイス３５は、ＢＣＶ（２）デバイスをＭ２ミラーとして含んでおり、一方その遠隔デバイスはＭ３／ＲＩミラーである。この場合は、Ｍ２ビット位置はＢＣＶデバイス３５に対するＭＭビット位置であり、Ｍ４ビット位置はＭ４ｂビット位置になる。ＲＤＦデバイス２２５は、固定ミラーを構成しているので、Ｍ３ビット位置はＢＦＭ（又はＢＣＶ固定ミラー）ビット位置とも呼ばれる。
【００６８】
図１０は、図９に示す構成内で起き得るイベントのシーケンスを示している。イベント２３０では、ＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２が、標準デバイス３１内の特定されたトラックに書き込みをする。これが起きると、リクエストは標準デバイスに対するものであり、図３のオペレーションはアクティブなセッションがなくても継続するので、そのトラックに対するＤＤＦ（１）ビットとＤＤＦ（２）ビットの両方が「変更された」とマークされる。当該トラックに対するトラックＩＤ表内のＭ１ビットは「無効」とマークされ、一方Ｍ２及びＭ４ビットは「有効」とマークされる。Ｍ３ビットは使用されないので、その値は、何れの未使用のビットも常に「無効」とマークされることを要件とする一般ルールに従って割当てられる。他の何れのトラックも変更されない。
【００６９】
イベント２３１は、あるオペレーションを示しており、それによってＨＯＳＴＡＰＰ  Ｂアプリケーション２３がＢＣＶ（１）デバイス３３内のあるトラックに書き込みをする。この場合、ＤＤＦ（１）値とＤＤＦ（２）値、又はトラックＩＤ表５５又は７１には如何なる変更も起きない。しかし、トラックＩＤ表６３には変更がある。厳密には、Ｍ１ビットは「有効」とマークされ、Ｍ４ビット若しくはＭ４ｂビットは「無効」とマークされる。Ｍ２及びＭ３ビット位置は、対応するデバイスがないので、イベントのシーケンスを通してずっと「無効」とマークされたままである。
【００７０】
イベント２３２は、アプリケーション２４からの書き込みリクエストがＢＣＶ（２）デバイス２４上のトラックを識別する場合の、同様のオペレーションを示している。この場合は、対応するトラックに関するトラックＩＤ表７１内のＭ２及びＭ３ビットが「有効」とマークされ、一方Ｍ４ビット若しくはＭ４ｂビットは無効とマークされる。
【００７１】
ここで、標準デバイス３１とＢＣＶデバイス３３の間に第１のセッションを確立することが求められていると仮定しよう。アプリケーションはこれらのデバイスを識別するための設定コマンドを生成する。図４に示す設定コマンド・プロセッシングが完了すると直ちに、ＰＢ表に対するＤＤＦ（１）エントリ内のトラックビット位置全てが「変更された」とマークされることになる。ＤＤＦ（２）セッションについての対応するトラックは影響を受けないままである。その結果、標準デバイス５５に関係付けられたコピープログラムは、標準デバイス３１からの全てのデータを、ＢＣＶ（１）デバイス３３に複製する。各トラックが転送されるので、標準デバイストラックＩＤ表５５内の対応するＭＭビット位置は「有効」とマークされることになる。データがＢＣＶ（１）デバイスの対応するトラックに転送されると、表６３内の全てのＭ１ビットは「有効」とマークされ、ＤＤＦ（１）セッションについての対応するＰＢビットは「変更された」とマークされる。
【００７２】
イベント２３４は、ＤＤＦ（１）セッションに関する完全分割コマンドに対する応答を表している。図５のステップ１３３及び１３４に示すように、トラックＩＤ表６３内の全てのＭ４ｂビットは「有効」とマークされ、ＤＤＦ１（１）セッションに対するＰＢビットは全て「変更されていない」とマークされる。
【００７３】
イベント２３５は、ＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２がデータを標準デバイス３１のトラックに書き込む状況を表している。図３に示すように、この書き込みリクエストは、対応するトラックに関するＤＤＦ（１）セッション及びＤＤＦ（２）セッションの両方を「変更された」とマークすることになる。他のトラックに関する他のＰＢビットには変更がない。
【００７４】
ステップ２３６は、標準デバイス３１とＢＣＶ（２）デバイス３５の間のＤＤＦ（２）セッションの確立を表している。ここで、トラックＩＤ表７２に対するＤＤＦ（２）部の全ての値は「変更された」とマークされている。この関係を使って、標準デバイストラックＩＤ表５５内の各Ｍ１ビットは、ＭＭビットとしてＢＣＶ（２）デバイス３５のトラックを指すので、全てのＭ１ビットの値は「無効」とマークされる。同期性が確立されると、ＢＣＶ（２）デバイス３５に対するトラックＩＤ表７１内のＭ２及びＭ３ビット位置は「有効」とマークされる。又、Ｍ４ビットは、このセッションに対するＭ４ｂビットとして「有効」とマークされる。トラックＩＤ表６３には如何なる変更も起きない。
【００７５】
データが同期化されると、標準デバイス３１に対するトラックＩＤ表５５内のＭ１ビットは「有効」とマークされる。システムが次に、イベント２３７でＤＤＦ（２）セッションに対する完全分割オペレーションを発行するときには、ＢＣＶ（２）デバイスのトラックＩＤ表７１内の全てのＭ４ｂビットは「有効」とマークされる。各トラックに対するＤＤＦ（２）ＰＢビット位置は「変更されていない」とマークされる。
【００７６】
ＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２が、イベント２４０で標準デバイス３１内のトラックにデータを書き込むと再度仮定しよう。標準デバイスは、両方のセッションに関する対応するトラック位置内のＰＢビットを「変更された」とマークすることにより応答する。他には変更はない。
【００７７】
ここで、ＢＣＶ（１）デバイス３３と標準デバイス３１の間に同期性を再確立することにより、ＤＤＦ（１）セッションを更新することが求められていると仮定しよう。本発明によれば、イベント２４１は再設定コマンドを処理する。図６に示すように、トラック毎に、システムは、選択されたＢＣＶデバイスに関するトラックＩＤ状態表に対するＭ４ビットと、ＤＤＦセッションに対するＰＢビットを組み合わせ、トラックＩＤ表５５内のＭＭビットを「無効」にセットする。イベント２３４でのＢＣＶデバイス３３の分割と、イベント２４１での再設定の間に、ＨＯＳＴ  ＡＰＰ  Ｂアプリケーション２３が何れかのトラックを変更していれば、トラックＩＤ表６３内のＭ４ｂビットは「無効」とマークされ、ＤＤＦセッションに対する対応するＰＢビットが「変更された」とマークされたか否かに拘わらず、トラックＩＤ表５５のＭ１ビットにも変更が生じることとなる。一旦ペアが再確立されると、コピープログラムはマークされた各トラック内のデータを転送し、対応するＤＤＦ（１）ビットは「変更されていない」とマークされ、トラックＩＤ表６３では、対応する各Ｍ４ｂビットが「有効」とマークされることになる。
【００７８】
イベント２４２は、ＢＣＶデバイス３５からデータを増分的に復元するための決定を表している。ＢＣＶデバイスは、例えば、標準デバイス３１上に情報の更新されたバージョンを有しているかもれない。増分復元オペレーションの終了時には、標準デバイスに対するトラックＩＤ表５５内の全Ｍ１ビットは「有効」とマークされる。ＰＢ表７２のＤＤＦ（２）ビットは「変更されていない」とマークされ、ＤＤＦ（１）ビットは「変更された」とマークされる。これは、ＢＣＶデバイス３３のような他のＢＣＶデバイス内のデータが、標準デバイス３１内のデータのレプリカをもはや保有していないことを意味する。しかしながら、ＤＤＦ（１）ビットを変更されたとマークしておけば、本例でのＢＣＶ（１）デバイスのような別のＢＣＶデバイスが関係する次の再設定又は設定コマンド手続きに応じて、正確なデータを確実に転送できる。
【００７９】
イベント２４３は、標準デバイス３１に対する別の書き込みオペレーションを表している。標準デバイス３１は、全てのＤＤＦセッション内の変更された１つ又は複数のトラックに対する全てのＰＢ位置を「変更された」とマークすることにより応答する。
【００８０】
イベント２４４は、標準デバイス３１からＢＣＶ（２）デバイス３５を切り離すための、ＤＩＦＦ分割コマンドの受信を表している。これが起きると、図５のステップ１３７は、図９のＭ３／Ｒ１ミラー２２５に対するＢＦＭビットに対応するトラックＩＤ表７１内のビット位置を「無効」とマークすることになる。ＢＦＭビットは、トラックＩＤ表７１内のＭ２ビットである。これは、変更がＭ３／Ｒ１ミラー２２５に及ぶことを保証している。
【００８１】
先の例は、１つのトラックに関連して起き得るイベントの多くのシーケンスの内の１つを表している。しかしながら、他のトラックのデータも変更され、より複雑なシーケンスが展開し得ることは明らかである。しかしながら、図９及び１０は、１つの標準デバイスと異なったＢＣＶデバイスとを含んでいる多くのセッションを確立するための能力を実証している。これは、種々のコマンドに応答する転送が、全て、ＨＯＳＴ  ＡＰＰ  Ａアプリケーション２２及び標準デバイス３１のような、基本的ホストアプリケーションと標準デバイスとの間の対話に対して独立的し、且つ見えないように起きることから、強力なツールを提供すると言える。差分分割、再設定、及び増分復元の間に生成される転送は、必要とされる変更のみに限定される。更に、標準デバイス３１上の何れのデータも破壊する恐れなしに、データは複製され使用される。
【００８２】
以上、本発明を、基本的記憶装置ユニットとしてトラックを用い且つトラック毎の解析と状態を保守する特定のデータ記憶機構に関わる特定の実施例に関連して説明してきた。本発明は、ファイル、レコード、又はセクターを含む他の細分化のレベルにも容易に適用できる。特定のコマンド及びシーケンスを開示してきた。それらシーケンスの多くは変更可能であり、同様の結果を得るために異なるステップが取り入れられてもよいことは明らかであろう。従って、請求の範囲に述べる意図は、本発明の真の精神と範囲内にあるこのような変更及び修正を全て網羅することである。
【００８３】
新規なものとして請求され、特許証によって保証されることを求めているものは、特許請求の範囲に述べる通りである。
【図面の簡単な説明】
【図１】本発明により構成されたデータ処理システムのブロック図である。
【図２】図１のデータ処理システムにおいて使用されるデータ編成を示す図である。
【図３】図１のシステムのオペレーションの間の、書き込みリクエストに応答するフロー線図である。
【図４】本発明により接続を確立するための手続きを示す図である。
【図５】図１のシステムによって達成される分割オペレーションのための手続きを示す図である。
【図６】図１のシステムにより達成される再設定のための手続きを示す図である。
【図７】図１のシステムにより達成される復元のための手続きを示す図である。
【図８】図１のシステムにより達成される増分的復元のための手続きを示す図である。
【図９】本発明の詳細なオペレーションを理解する上で役立つ特定の構成における記憶装置を幾つか示す概略図である。
【図１０】オペレーションの典型的なシーケンスに存在する様々なオペレーティング状態を示す表である。
【図１】
0003741609.tif 000002
【図２】
0003741609.tif 000003
【図３】
0003741609.tif 000004
【図４】
0003741609.tif 000005
【図５】
0003741609.tif 000006
【図６】
0003741609.tif 000007
【図７】
0003741609.tif 000008
【図８】
0003741609.tif 000009
【図９】
0003741609.tif 000010
【図１０】
0003741609.tif 000011