(57)【特許請求の範囲】
【請求項１】
ホストプロセッサとのインタフェースを構成するチャネルアダプタと、回線を使用して他のファイル制御装置とのデータ転送を行うリモートアダプタと、前記チャネルアダプタ及びリモートアダプタを管理するリソースマネジャを具備し、転送されたデータをデバイスに格納するリモートファイル制御装置において、
前記リモートアダプタに処理中断を行う処理中断手段を設け、
回線上に転送されたパケットの途中パケットがロストしたとき、そのリモートアダプタの前記処理中断手段がリソースマネジャに対して処理中断通知を出力することを特徴とするリモートファイル制御装置。
【請求項２】
ホストプロセッサとのインタフェースを構成するチャネルアダプタと、回線を使用して他のファイル制御装置とのデータ転送を行うリモートアダプタと、前記チャネルアダプタ及びリモートアダプタを管理するリソースマネジャを具備し、転送されたデータをデバイスに格納するリモートファイル制御装置において、
前記リソースマネジャに、リモートアダプタから全パケットを受取ったことを通知される全パケット受取り通知監視手段を設け、
最初にスタート要求されたリモートアダプタから全パケット受取通知が到着しないときに後でスタート要求を出したリモートアダプタからの全パケット受取通知が到着したとき、最初にスタート要求したリモートアダプタにおいて最終パケットロストが発生したものと判断して、これにパケットロスト通知及び処理中断通知を送出することを特徴とするリモートファイル制御装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はリモートファイル制御装置に係り、特に正センタと副センタ間に伝送されるパケットロスト時のＬＴＤ（Ｌｏｏｋ  ａｓｉｄｅ  Ｔａｂｌｅ  Ｄｉｒｅｃｔｏｒｙ）に対する記入処理を高速化するものに関する。
【０００２】
【従来の技術】
データ処理装置においては、危機対策のため、正センタと副センタを設け、同一のデータを管理することが行われている。この場合、正センタと副センタは、一方が危機状態になっても他方は安全を期するため、互いに遠隔地にこれらを設置している。そして正センタのデバイスのデータが記入されたとき、このデータを副センタにリモート転送し、これに応じて副センタのデバイスも同じくデータが記入され、データの同一性を保持している。このため、正センタ、副センタにそれぞれリモートファイル制御装置が具備されている。デバイスは、例えば磁気ディスクにより構成される。
【０００３】
従来のリモートファイル制御装置を図１３に基づき説明する。
正センタにはホストプロセッサ５０、リモートファイル制御装置５１、デバイス５２が具備され、リモートファイル制御装置５１にはチャネルアダプタ５３、キャッシュ５４、リモートアダプタ５５、リソースマネジャ５６が設けられている。
【０００４】
副センタは、正センタと同様に、これまたホストプロセッサ６０、リモートファイル制御装置６１、デバイス６２が具備され、リモートファイル制御装置６１にはチャネルアダプタ６３、キャッシュ６４、リモートアダプタ６５、リソースマネジャ６６が設けられている。そして正センタのリモートアダプタ５５と副センタのリモートアダプタ６５間には回線７０が設けられている。
【０００５】
いま正センタのホストプロセッサ５０が、リモートファイル制御装置５１に対しデバイス５２へのデータの書込要求を行うと、チャネルアダプタ５３がこれを受信してリソースマネジャ５６に対しキャッシュ５４への書込み要求を行う。そしてリソースマネジャ５６が許可を与えるとチャネルアダプタ５３はキャッシュ５４にこの書込みデータを書込み、またリモートアダプタ５５に対して転送要求を行う。
【０００６】
リソースマネジャ５６は、キャッシュ５４に書込みされたデータをデバイス５２に書込む。またリモートアダプタ５５はこの書込みデータを回線７０により副センタのリモートファイル制御装置６１のリモートアダプタ６５に送出する。
【０００７】
副センタではリモートアダプタ６５がこの書込みデータを受信するとリソースマネジャ６６に対しキャッシュ６４への書込み要求を行う。そしてリソースマネジャ６６が許可を与えるとリモートアダプタ６５はキャッシュ６４にこの書込みデータを記入する。このキャッシュ６４に記入された書込みデータはリソースマネジャ６６によりデバイス６２に書込まれる。このようにして正センタのホストプロセッサ５０から転送された書込みデータは正センタのデバイス５２及び副センタのデバイス６２に書込まれ、これらデバイス５２、６２間の整合性が保持される。
【０００８】
ところで、図１４（Ａ）に示す如く、正センタ、副センタではリモートファイル制御装置８１、８５に共に複数のリモートアダプタ８３、８４及び８７、８８を搭載し、これらの間に回線７１、７２を設けることができる。
【０００９】
このような複数のリモートアダプタを搭載した環境下において、２トラック以上のデータ転送を行う際には、正センタのリモートファイル制御装置８１のチャネルアダプタ８２が各リモートアダプタ８３、８４にトラックを１つずつ割り当て、回線７１、７２による副センタのリモートファイル制御装置８５への転送を並列して行っている。
【００１０】
図１４（Ａ）により、リモート転送対象トラックが２トラックで、リモートアダプタ数が２である場合を想定して具体的にリモート転送状態を説明する。
【００１１】
図１４（Ａ）において、チャネルアダプタ８２は、ホストプロセッサ５０から受取ったデータトラック０〜トラック１をリモートアダプタ８３〜８４にそれぞれ１トラックずつ振り分けて転送を行う。このように、リモートアダプタ８３−８７間及びリモートアダプタ８４−８８間のリモート転送はトラック単位内で転送が行われ、複数のリモートアダプタによる並列転送が可能となっている。
【００１２】
なお、チャネルアダプタ８２はホストプロセッサ５０から１トラック分のデータを受取り次第そのリモートアダプタ８３または８４に転送依頼を行うものであり、あらかじめ定められた、順序で、例えばリモートアダプタ８３から先に転送依頼を行うので、図１４（Ａ）に示す如く、チャネルアダプタ８２が先に受取ったデータであるトラック０の方がトラック１よりも先に転送される。
【００１３】
また１つのトラックは、複数のパケット（通常は１２個）からなっており、図１４（Ａ）に示す如く、パケットが順番に転送される。この順番を示すため、各パケットの先頭には番号が付与されている。
【００１４】
このため、チャネルアダプタ８２は、ホストプロセッサ５０から受取ったデータをリモートファイル制御装置８１の図示省略したキャッシュに記入後リモートアダプタ８３、８４が順次これを読み出し、トラック毎にパケットを作成し、番号が記入されたヘッダを付加し、前記の如く転送する。
【００１５】
ところで副センタのリモートファイル制御装置８５では、リモートアダプタ８７又は８８がそれぞれ転送されたデータを一時バッファに保持し、デバイスの書込先アドレスのデータをキャッシュに読出し、これに転送されたデータを書込んだあとでデバイスの書込先アドレスに戻すことが行われていたが、これではデバイス９３からデータを読込むために時間がかかるので、処理がおそくなる。そのため図１４（Ｂ）に示す如く、キャッシュ８９内のＬＴＤ（Ｌｏｏｋ  ａｓｉｄｅ  Ｔａｂｌｅ  Ｄｉｒｅｃｔｏｒｙ）領域９１にトラック番毎にＬＴＤ９５を設け、これにそのトラックに記入されているレコード数Ｎｔと、各レコードのレコード長Ｌｔ等の各トラックフォーマットの情報を記入しておく。すなわちＬＴＤ９５は１つのトラック内に記入されている複数のレコードの長さが等しい場合に使用するものである。
【００１６】
これにより正センタから副センタにデータが送られてきたとき、そのトラック内の何番目の順位のレコードに対するものであるのかを、例えば先頭パケットのヘッダから読み出し、該当トラック番号のＬＴＤをアクセスすることによりそのトラック内のレコードのレコード長を認識し、このレコード長にレコード順位を乗じてデバイスの書込先アドレスを求める。そしてこのようにして得られたデバイスの書込先にデータを書き込むことができる。これは正センタのリモートファイル制御装置においても同様である。
【００１７】
このようにＬＴＤを用いてレコード数、データ長を認識し、これによりデバイス９３から書込先のデータを読み込まずにデータをデバイスに書き込むことができるので、データ処理の高速化をはかることができる。
【００１８】
ＬＴＤは、図１５（Ａ）に示す如く、キャッシュ上のＬＴＤ領域にトラック単位で存在しており、１つのＬＴＤは例えば４バイトの情報から成っている。
【００１９】
ところで現在のリモートファイル制御装置では、ハードの仕様により、ＬＴＤが格納されているキャッシュエリアつまりＬＴＤ領域へのアクセス、読み込み、書き込みは、例えば６４バイトの如き一定単位でしか行うことができない。
【００２０】
いま、正センタのホストプロセッサ５０からトラックフォーマットが変更されるＩ／Ｏ命令つまりデバイスに対する書込み命令が発行された場合、該当トラックのＬＴＤの情報を書き換える必要がある。
【００２１】
このときの問題として同一６４バイト内にあるＬＴＤを複数のリモートアダプタが更新する場合、同タイミングでこのＬＴＤの読み込み処理及び書き込み処理を実行すると、このＬＴＤの内容を破壊してしまうことがある。
【００２２】
例えば図１５（Ｂ）に示す如く、リモートアダプタＲＡ０が同一６４バイト内のＬＴＤ領域Ｄ0 に対するトラック０のデータを書き込み、リモートアダプタＲＡ１が同じくＬＴＤ領域Ｄ0 のトラック１のデータを書き込む場合について説明する。
【００２３】
▲１▼先ずリモートアダプタＲＡ０がＬＴＤ領域Ｄ0 の６４バイトのデータを読込む。
【００２４】
▲２▼次にリモートアダプタＲＡ１がＬＴＤ領域Ｄ0 の６４バイトのデータを読込む。
【００２５】
▲３▼リモートアダプタＲＡ０がトラック０のデータを書き換え、ＬＴＤ領域Ｄ0 に戻す。
【００２６】
▲４▼次にリモートアダプタＲＡ１がトラック１のデータを書き換えＬＴＤ領域Ｄ0 に戻せば、リモートアダプタＲＡ１が読み込んだ６４バイトのデータはトラック０のデータが前のままであり、前記▲３▼で書き換えたトラック０のデータは破壊されてしまうことになる。
【００２７】
このような問題を解決するため、同一６４バイト内のＬＴＤに対する更新がリモートアダプタＲＡ０とＲＡ１とで競合した場合、排他制御を行って初めにアクセスしたリモートアダプタＲＡ０を優先させ、リモートアダプタＲＡ０における書き換えが終わってからリモートアダプタＲＡ１に対する書き換えを行うように、すなわち１つのリモートアダプタしか動作することができないように制御している。
【００２８】
【発明が解決しようとする課題】
ところで副センタにおけるリモートファイル制御装置の問題として、主センタと副センタ間の回線上でパケット・ロストが発生した場合、パケット・ロストの発生しなかった回線に接続されたリモートアダプタの処理が長時間待たされてしまうということがある。
【００２９】
その理由は、副センタのリモートアダプタではパケット・ロストを検出したとき、正センタのリモートアダプタに対して、ロストしたパケットからのデータに対する再送要求を行うが、そのとき副センタのリモートファイル制御装置のリソースマネジャへの処理終了を通知せずに再送パケットが転送されてくるのを待っているからである。この際同一６４バイト内のＬＴＤを更新するＩ／Ｏ命令が競合した場合、前記の如く、排他制御が行われるため、当該リモートアダプタが再送パケットを待っている間、他のリモートアダプタが動作することができない。
【００３０】
このため、副センタにおける他のリモートアダプタでは処理を長時間待たされてしまい、その結果としてＩ／Ｏ命令に対するスループットつまり正センタにおけるホストプロセッサから出力されたＩ／Ｏ命令に対する単位時間に処理できる仕事量が低下するという現象が発生する。
【００３１】
従来の磁気ディスク制御装置により構成されるリモートファイル制御装置において、トラックの書き込みデータの転送途中にパケット・ロストが発生したときの副センタの、主としてリモートアダプタに関する動きを図１４に基づき更に説明する。
【００３２】
以下の説明におけるＲＡ０、ＲＡ１、ＲＭ等は図１４に示される記号に基づくものである。
【００３３】
（１）副センタのリモートアダプタＲＡ０が正センタのリモートアダプタＲＡ０（図１４参照、図１６では省略）よりトラック０に対するパケットを受け取る。
【００３４】
（２）これにより副センタのリモートアダプタＲＡ０はリソースマネジャＲＭに対し、トラック０に対するデータ更新のスタート要求を行う。
【００３５】
（３）リソースマネジャＲＭは、同一トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタが行っていないことにより、リモートアダプタＲＡ０に対し、データ更新処理の開始できることを示す処理開始通知を行う。
【００３６】
（４）副センタのリモートアダプタＲＡ１は、前記（１）と同様に、正センタのリモートアダプタＲＡ１よりトラック１に対するパケットを受け取る。
【００３７】
（５）これにより副センタのリモートアダプタＲＡ１はリソースマネジャＲＭに対し、トラック１に対するデータ更新のスタート要求を行う。
【００３８】
（６）リソースマネジャＲＭは、同一トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタが行っている場合は排他制御を行い、同時期に複数のリモートアダプタを動作させないようにする。この場合、リソースマネジャＲＭは、リモートアダプタＲＡ１に対して、リモートアダプタＲＡ０がすでに更新処理動作を行っているので、処理ビジーを通知する。
【００３９】
（７）リモートアダプタＲＡ０が、回線上でトラック０に対するデータの途中パケットが、そのパケットについている番号のチェックにもとづきロストしたことを検出すると、リモートアダプタＲＡ０は正センタのリモートアダプタＲＡ０に対してロストしたパケット以降のパケットの再送要求を行う。その後リソースマネジャＲＭに処理終了を通知せず、正センタからロストしたパケット以降のパケットが再送されてくるのを待つ。
【００４０】
（８）副センタのリモートアダプタＲＡ０が正センタのリモートアダプタＲＡ０から前記ロストしたパケット以降の転送データであるトラック０の再送パケットを受け取る。
【００４１】
（９）副センタのリモートアダプタＲＡ０は、この再送パケットを受け取ったならば、キャッシュ上のＬＴＤ領域からトラック０のＬＴＤを含む６４バイトのＬＴＤデータ（トラック０、トラック１・・・トラックＥを含む、図１４（Ａ）参照）をリモートアダプタＲＡ０自身のメモリ上に読み込み、トラック０のＬＴＤデータの更新を行う。
【００４２】
（１０）副センタのリモートアダプタＲＡ０は、前記（９）で更新したトラック０のデータを含む６４バイトのＬＴＤデータをキャッシュ上のＬＴＤ領域に上書きする。このようにしてキャッシュ上のＬＴＤを更新する。
【００４３】
（１１）それから副センタのリモートアダプタＲＡ０は、正センタのリモートアダプタＲＡ０から受け取ったトラック０のデータをキャッシュ上のトラックデータ領域に記入する。
【００４４】
（１２）副センタのリモートアダプタＲＡ０は、リソースマネジャＲＭに対し、トラック０のデータ更新処理が全て終了したことを通知する処理終了通知を出力する。
【００４５】
（１３）副センタのリモートアダプタＲＡ１は、リソースマネジャＲＭに対し、再度データ更新のスタート要求を行う。このリモートアダプタＲＡ１が再度スタート要求を出すタイミングは任意である。その際に、前記（６）における処理ビジー状態が解除されていない場合は、リモートアダプタＲＡ１は再度スタート要求を出力する処理を繰り返す。
【００４６】
（１４）副センタのリソースマネジャＲＭは、前記（３）と同様に、同一トラック又は同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡ０が行っていなければ、リモートアダプタＲＡ１に対してデータ更新処理を開始できる旨を示す処理開始通知を出力する。
【００４７】
（１５）リモートアダプタＲＡ１は、リソースマネジャＲＭから前記処理開始通知を受け取ったならば、前記（９）〜（１２）と同様に、前記（４）にもとづき、処理ビジー状態中で受け取ったトラック１に対するデータ更新処理のために、キャッシュ上のＬＴＤ領域からトラック１のＬＴＤを含む６４バイトのＬＴＤデータをリモートアダプタＲＡ１自身のメモリ上に読み込み、トラック１のＬＴＤデータの更新を行ったのち、この更新したトラック１のデータを含む６４バイトのＬＴＤデータをキャッシュ上のＬＴＤ領域に上書きすることによりキャッシュ上のＬＴＤを更新する。それからリモートアダプタＲＡ１は、前記（４）において正センタのリモートアダプタＲＡ１から受け取ったトラック１のデータをキャッシュ上のトラックデータ領域に記入する。そしてリモートアダプタＲＡ１はリソースマネジャＲＭに対し、トラック１のデータ更新処理終了を示す処理終了通知を出力する。
【００４８】
なお前記（１１）及び（１５）においてキャッシュ上のトラックデータ領域に記入されたデータ（上記の例ではトラック０、トラック１に対するデータ）は、その後リソースマネジャＲＭによりデバイスに格納される。
【００４９】
このように前記（７）において、パケット・ロストが発生したとき、（８）〜（１２）に示す如く、ロストしたパケット以下のパケットの再送による処理が終わるまで他のリモートアダプタが動作することができないという問題が存在する。
【００５０】
第２の問題点を次に説明する。
前記の説明では、回線上でパケット・ロストが発生した場合の処理遅延問題について記述したが、第２の問題点としてパケット・ロストの検出時に関する問題点を以下に説明する。
【００５１】
現在の磁気ディスク制御装置により構成されるリモートファイル制御装置において、副センタのリモートアダプタＲＡ０、ＲＡ１は、回線上でトラックの途中のパケットがロストした場合、受信したパケットのパケット番号をチェックしてその順序性が崩れることにより検出することができる。例えば、図１７（Ａ）に示す如く、パケット１〜パケット１０を受信したものの、次にパケット１１ではなくパケット１２を受信すればパケット１１がロストしたことを検出できる。
【００５２】
しかし副センタのリモートアダプタＲＡ０、ＲＡ１は、回線上で最終パケットがロストした場合、次に受け取るパケットがないため、その順序性の検出ではこれを検知することができず、最終パケットが転送されてくるのを回線監視時間の間待ち続ける。例えば図１７（Ｂ）に示す如く、パケット１〜パケット１１は受信したものの、パケット１２が来ないとき、パケット１２が転送されてくるのを回線監視時間だけ待つことになる。なお図１７はパケット１２が最終パケットの例である。
【００５３】
したがって最終パケットのロストは、回線監視時間を超えたことでしか検出することができず、その結果パケットの再送要求の発行が、途中パケットのロストの場合よりも遅れることになる。なお回線監視時間とは、副センタのリモートアダプタが受け取るべきパケットを待つ時間のことである。副センタのリモートアダプタでは、この回線監視時間を過ぎても全パケットが揃わない場合、パケット・ロストが発生したものと認識して正センタのリモートアダプタに対する再送要求を行う。
【００５４】
従来の磁気ディスク制御装置により構成されるリモートファイル制御装置において、トラックの最終パケットのロストが発生した場合の副センタの、主としてリモートアダプタに関する動きを図１８にもとづき更に説明する。なお送信データのパケット数はホストプロセッサからの指示より決めらる。
【００５５】
（１）副センタのリモートアダプタＲＡ０が正センタのリモートアダプタＲＡ０（図１４参照、図１８では省略）よりトラック０に対するパケットを受け取る。
【００５６】
（２）これにより副センタのリモートアダプタＲＡ０はリソースマネジャＲＭに対し、トラック０に対するデータ更新のスタート要求を行う。
【００５７】
（３）リソースマネジャＲＭは、同一トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタが行っていないことにより、リモートアダプタＲＡ０に対し、データ更新処理の開始できることを示す処理開始通知を行う。
【００５８】
（４）副センタのリモートアダプタＲＡ１は、前記（１）と同様に、正センタのリモートアダプタＲＡ１よりトラック１に対するパケットを受け取る。
【００５９】
（５）これにより副センタのリモートアダプタＲＡ１はリソースマネジャＲＭに対し、トラック１に対するデータ更新のスタート要求を行う。
【００６０】
（６）リソースマネジャＲＭは、同一トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタが行っている場合は排他制御を行い、同時期に複数のリモートアダプタを動作させないようにする。この場合、リソースマネジャＲＭは、リモートアダプタＲＡ１に対して、リモートアダプタＲＡ０がすでに更新処理動作を行っているので、処理ビジーを通知する。
【００６１】
（７）回線上で、トラック０の最終パケットのロストを、パケットの順序性のチェックでは検出できないため、リモートアダプタＲＡ０はこの最終パケットのロストを回線監視時間（通常２秒）を超えてもこの最終パケットが受信できなかったことでしか検出できない。したがってリモートアダプタＲＡ０は、回線監視時間の間、最終パケットの転送を待ち続けた後に正センタのリモートアダプタＲＡ０に対してロストしたパケット以降のパケット（この場合はロストしたパケットが最終パケットであるので最終パケットになる）の再送要求を行う。その後、リモートアダプタＲＡ０はリソースマネジャＲＭに処理終了を通知せず、ロストしたパケット以降のパケット（この場合は最終パケット）が正センタから再送されてくるのを待つ。
【００６２】
（８）副センタのリモートアダプタＲＡ０は正センタのリモートアダプタＲＡ０から前記ロストしたパケット以降の転送データであるトラック０の再送パケットつまり最終パケットを受け取る。
【００６３】
（９）副センタのリモートアダプタＲＡ０は、この再送パケットを受け取ったならば、キャッシュ上のＬＴＤ領域からトラック０のＬＴＤを含む６４バイトのＬＴＤデータ（トラック０、トラック１・・・トラックＥを含む、図１３（Ａ）参照）をリモートアダプタＲＡ０自身のメモリ上に読み込み、トラック０のＬＴＤデータの更新を行う。
【００６４】
（１０）副センタのリモートアダプタＲＡ０は、前記（９）で更新したトラック０のデータを含む６４バイトのＬＴＤデータをキャッシュ上のＬＴＤ領域に上書きする。このようにしてキャッシュ上のＬＴＤを更新する。
【００６５】
（１１）それから副センタのリモートアダプタＲＡ０は、正センタのリモートアダプタＲＡ０から受け取ったトラック０のデータをキャッシュ上のトラックデータ領域に記入する。
【００６６】
（１２）副センタのリモートアダプタＲＡ０は、リソースマネジャＲＭに対し、トラック０のデータ更新処理が全て終了したことを通知する処理終了通知を出力する。
【００６７】
（１３）副センタのリモートアダプタＲＡ１は、リソースマネジャＲＭに対し、再度データ更新のスタート要求を行う。このリモートアダプタＲＡ１が再度スタート要求を出すタイミングは任意である。その際に、前記（６）における処理ビジー状態が解除されていない場合は、リモートアダプタＲＡ１は再度スタート要求を出力する処理を繰り返す。
【００６８】
（１４）副センタのリソースマネジャＲＭは、前記（３）と同様に、同一トラック又は同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡ０が行っていなければ、リモートアダプタＲＡ１に対してデータ更新処理を開始できる旨を示す処理開始通知を出力する。
【００６９】
（１５）リモートアダプタＲＡ１は、リソースマネジャＲＭから前記処理開始通知を受け取ったならば、前記（９）〜（１２）と同様に、前記（４）にもとづき、処理ビジー状態中で受け取ったトラック１に対するデータ更新処理のために、キャッシュ上のＬＴＤ領域からトラック１のＬＴＤを含む６４バイトのＬＴＤデータをリモートアダプタＲＡ１自身のメモリ上に読み込み、トラック１のＬＴＤデータの更新を行ったのち、この更新したトラック１のデータを含む６４バイトのＬＴＤデータをキャッシュ上のＬＴＤ領域に上書きすることによりキャッシュ上のＬＴＤを更新する。それからリモートアダプタＲＡ１は、前記（４）において正センタのリモートアダプタＲＡ１から受け取ったトラック１のデータをキャッシュ上のトラックデータ領域に記入する。そしてリモートアダプタＲＡ１はリソースマネジャＲＭに対し、トラック１のデータ更新処理終了を示す処理終了通知を出力する。
【００７０】
なお前記（１１）及び（１５）においてキャッシュ上のトラックデータ領域に記入されたデータ（上記の例ではトラック０、トラック１に対するデータ）は、その後リソースマネジャＲＭによりデバイスに格納される。
【００７１】
このように、従来の装置では、パケット・ロストを検出した副センタのリモートアダプタがロストしたパケット以降の転送データを受取って処理終了通知をリソースマネジャが受取るまで副センタの他のリモートアダプタの処理が長時間待たされるため、Ｉ／Ｏのスループットが低下するという問題点が存在した。
【００７２】
従って本発明の目的は、副センタのリモートアダプタの受信パケットがトラックの途中パケットのロストが発生した場合でも、トラックの最終パケットのロストが発生した場合でも、他のリモートアダプタが長時間処理を待たされることなく書き込み処理が可能なリモートファイル制御装置を提供することである。
【００７３】
【課題を解決するための手段】
前記目的を達成するためのリモートファイル制御装置の原理図を図１により説明する。
【００７４】
図１において、１は正センタ側のホストプロセッサ、２はリモートファイル制御装置、３はチャネルアダプタ、４、５はそれぞれリモートアダプタ、６はデバイス、８、９はそれぞれ回線、１０は副センタ側のホストプロセッサ、１１はリモートファイル制御装置、１２はチャネルアダプタ、１３、１４はそれぞれリモートアダプタ、１５はリソースマネジャ、１６はリモートアダプタ１３に設けた中断手段、１７はリモートアダプタ１４に設けた中断手段、１８は全パケット受取通知監視手段、２０はデバイスである。
【００７５】
本発明における前記目的は下記の構成により達成される。
（１）ホストプロセッサとのインタフェースを構成するチャネルアダプタ１２と、回線８、９を使用して他のファイル制御装置２とのデータ転送を行うリモートアダプタ１３、１４と、前記チャネルアダプタ１２及びリモートアダプタ１３、１４を管理するリソースマネジャ１５を具備し、転送されたデータをデバイス２０に格納するリモートファイル制御装置１１において、前記リモートアダプタ１３、１４に処理中断を行う処理中断手段１６、１７を設け、回線８、９上に転送されたパケットの途中パケットがロストしたとき、そのリモートアダプタの前記処理中断手段がリソースマネジャ１５に対して処理中断通知を出力すること。
【００７６】
（２）ホストプロセッサとのインタフェースを構成するチャネルアダプタ１２と、回線８、９を使用して他のファイル制御装置２とのデータ転送を行うリモートアダプタ１３、１４と、前記チャネルアダプタ１２及びリモートアダプタ１３、１４を管理するリソースマネジャ１５を具備し、転送されたデータをデバイス２０に格納するリモートファイル制御装置１１において、前記リソースマネジャ１５に、リモートアダプタから全パケットを受取ったことを通知される全パケット受取り信号通知監視手段１８を設け、最初にスタート要求されたリモートアダプタから全パケット受取通知が到着しないときに後でスタート要求を出したリモートアダプタからの全パケット受取通知が到着したとき、最初にスタート要求したリモートアダプタにおいて最終パケットロストが発生したものと判断して、これにパケットロスト通知及び処理中断通知を送出すること。
【００７７】
これにより下記の効果を奏することができる。
（１）途中パケットのロストを検出したリモートアダプタが、その時点でリソースマネジャに対して処理中断を通知し、リソースマネジャはそのリモートアダプタに対する同一６４バイト内のＬＴＤ領域に対するロックつまりアクセス禁止状態を解除するので、処理ビジーで待たされていたリモートアダプタがすぐにＬＴＤ領域に対して動作を行うことができ、その結果従来技術より処理時間を早くすることができる。
【００７８】
（２）最初にスタート要求したリモートアダプタからリソースマネジャに全パケット受取通知が到着しないときに後からスタート要求を出したリモートアダプタからの全パケット受取通知が到着したとき、リソースマネジャが最終パケットロストが発生したものと判断して全パケット受取通知の到着しないリモートアダプタにパケットロスト通知＋処理中断通知を出力することにより、処理ビジーで待たされていた全パケットを受取った方のリモートアダプタがすぐにＬＴＤ領域に対して動作を行うことができ、また最終パケットのロストを早く検出することができ、その結果従来技術より処理時間を早くすることができる。
【００７９】
【発明の実施の形態】
本発明の一実施の形態を図２〜図１０にもとづき詳述する。図２は本発明の一実施の形態を副センタのリモートファイル制御装置について代表的に示したものであり、正センタのリモートファイル制御装置も同様に構成されている。図３は途中パケットロスト時の副センタにおけるタイムチャートを示し、図４は途中パケットロスト時の副センタのリモートアダプタＲＡの動作説明図（その１）、図５は途中パケットロスト時の副センタのリモートアダプタＲＡの動作説明図（その２）、図６は途中パケットロスト時の副センタのリソースマネジャＲＭの動作説明図、図７は最終パケットロスト時の副センタのタイムチャート、図８は最終パケットロスト時の副センタのリモートアダプタＲＡの動作説明図（その１）、図９は最終パケットロスト時の副センタのリモートアダプタＲＡの動作説明図（その２）、図１０は最終パケットロスト時の副センタのリソースマネジャＲＭの動作説明図である。
【００８０】
図２において他図と同記号は同一部分を示し、８、９はそれぞれ回線、１０はホストプロセッサ、１１はリモートファイル制御装置、１２はチャネルアダプタ、１３、１４はそれぞれリモートアダプタ、１５はリソースマネジャ、１６はリモートアダプタに設けられた中断手段、１７はリモートアダプタ１４に設けられた中断手段、１８はリソースマネジャ１５に設けた全パケット受取り通知監視手段、１９はリソースマネジャ１５に設けられた中断手段、２０はデバイス、２１はキャッシュである。
【００８１】
回線８、９は、図１に示す如く、主センタのリモートファイル制御装置２から副センタのリモートファイル制御装置１１に対してデータを転送するものであり、回線８には例えばトラック０のパケット１、２・・・が転送され、回線９には例えばトラック１のパケット１、２・・・が転送される。
【００８２】
ホストプロセッサ１０は副センタを総合制御するものであり、例えばリモートファイル制御装置１１やデバイス２０の動作状態を監視するものである。
【００８３】
リモートファイル制御装置１１は、リモートファイル制御装置２と同様に、例えば磁気デスク制御装置で構成され、正センタのデバイス６と副センタのデバイス２０に保持されたデータの整合性を保つために正センタから転送されたデータをデバイス２０に格納するものであり、チャネルアダプタ１２、リモートアダプタ１３、１４、リソースマネジャ１５、キャッシュ２１等を具備するものである。
【００８４】
チャネルアダプタ１２はホストプロセッサ１０とリモートファイル制御装置１１との外部インタフェースを構成し、制御するモジュールであり、例えばプロセッサとファームウェアで構成・制御される。
【００８５】
リモートアダプタ１３は、回線８を使用して正センタのリモートファイル制御装置２とデータ転送を行うモジュールであり、例えばプロセッサとファームウェアで構成・制御される。そしてトラックを構成するパケットの順序性をチェックし、最初のパケットあるいは途中のパケットがロストしたとき、処理中断を通知する処理中断通知を出力する中断手段１６を備えている。
【００８６】
リモートアダプタ１４は、回線９を使用して正センタのリモートファイル制御装置２とデータ転送を行うモジュールであり、例えばプロセッサとファームウェアで構成・制御される。そしてトラックを構成するパケットの順序性をチェックし、最初のパケットあるいは途中のパケットがロストしたとき、処理中断を通知する処理中断通知を出力する中断手段１７を備えている。
【００８７】
リソースマネジャ１５はチャネルアダプタ１２、リモートアダプタ１３、１４を含むリモートファイル制御装置１１を管理・制御するモジュールであってプロセッサとファームウェアで構成され、多数のテーブルを有し、処理に必要なデータがこれらに記入されている。またリソースマネジャ１５には、リモートアダプタ１３、１４がトラックを構成している全パケットを受信したときこれを示す全パケット受取り通知を受信監視する全パケット受取り通知監視手段１８と、この全パケット受取り通知監視手段１８により、処理開始通知を送出したリモートアダプタよりも、あとでスタート要求したリモートアダプタから全パケット受取り通知を受取ったとき、処理開始通知を送出したリモートアダプタに最終パケットがロストしたものと認識して、パケットロスト通知＋処理中断通知を出力する中断手段１９を備えている。
【００８８】
デバイス２０は、主センタに設けられたデバイス６と同じデータが格納されるものであって、例えば磁気ディスク装置で構成されている。
【００８９】
キャッシュ２１は、前記の如く、デバイス２０に格納すべきデータが一時保持されるデータ領域と、デバイス２０の各トラックフォーマットの情報が記入されるテーブルであるＬＴＤが記入されるＬＴＤ領域を有している。そして各ＬＴＤにはレコード数、レコードのデータ長等のトラックフォーマットの情報が記入されている。
【００９０】
Ａ．途中パケットがロストした場合
先ず図３〜図６にもとづき副センタのリモートアダプタ１３で途中パケットのロストを検出した場合の本発明の動作について説明する。以下の説明においてリモートアダプタ１３、１４をそれぞれリモートアダプタＲＡ０、ＲＡ１と表現し、リソースマネジャ１５をリソースマネジャＲＭと表現する。
【００９１】
最初にわかり易く説明するため図３のタイムチャートにもとづき説明する。
（１）副センタのリモートアダプタＲＡ０が正センタのリモートアダプタ４（ＲＡ０、図１参照）より、トラック０に対するパケットを受け取る。
【００９２】
（２）これにより副センタのリモートアダプタＲＡ０はリソースマネジャＲＭに対しトラック０に対するデータ更新のスタート要求を行う。
【００９３】
（３）リソースマネジャＲＭは、同一トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡ１が行っていなければ、リモートアダプタＲＡ０に対し、データ更新処理の開始できることを示す処理開始通知を行う。
【００９４】
（４）副センタのリモートアダプタＲＡ１は、前記（１）と同様に、正センタのリモートアダプタ５（ＲＡ１、図１参照）よりトラック１に対するパケットを受け取る。
【００９５】
（５）これにより副センタのリモートアダプタＲＡ１はリソースマネジャＲＭに対し、トラック１に対するデータ更新のスタート要求を行う。
【００９６】
（６）リソースマネジャＲＭは同一トラック又は同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタが行っている場合は排他制御を行い、同時期に複数のリモートアダプタを動作させないようにする。この場合、リソースマネジャＲＭは、リモートアダプタＲＡ１に対して、リモートアダプタＲＡ０がすでに更新処理動作を行っているので、処理ビジーを通知する。
【００９７】
（７）リモートアダプタＲＡ０が、回線８上でトラック０の途中のパケットが、そのパケットについている番号のチェックにもとづきロストしたことを検出すると、リモートアダプタＲＡ０の中断手段１６が当該トラック０の更新処理中断を通知する処理中断通知をリソースマネジャＲＭに対して出力する。
【００９８】
（８）副センタのリモートアダプタＲＡ０は正センタのリモートアダプタＲＡ０に対してロストしたパケット以降のパケットの再送要求を行う。この際に、それまでに受け取ったパケットの内容は保持しておき、ロストしたパケット以降のパケットが正センタから再送されてくるのを待つ。
【００９９】
（９）ところで、この間に副センタのリモートアダプタＲＡ１はトラック１の全パケットを受信したことにより、再度データ更新のスタート要求を行う。
【０１００】
（１０）このとき、前記（７）において、処理中断となっているため、リソースマネジャＲＭは、同一トラック又は同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡ０が行っていないので、リモートアダプタＲＡ１に対してデータ更新処理を開始できる旨を通知する。
【０１０１】
（１１）これによりリモートアダプタＲＡ１は、パケットを受け取ったならば、キャッシュ２１上のＬＴＤ領域からトラック１のＬＴＤを含む６４バイトのＬＴＤデータ（トラック０、トラック１・・・トラックＥを含む）を、リモートアダプタＲＡ１自身のメモリ上に読み込み、トラック１のＬＴＤを更新する。
【０１０２】
（１２）リモートアダプタＲＡ１は、前記（１１）で更新したトラック１のデータを含む６４バイトのＬＴＤデータをキャッシュ２１上のＬＴＤ領域に上書きする。このようにしてキャッシュ２１上のＬＴＤを更新する。
【０１０３】
（１３）それからリモートアダプタＲＡ１は、正センタのリモートアダプタＲＡ１から受け取ったトラック１のデータをキャッシュ２１上のトラックデータ領域に書き込む。
【０１０４】
（１４）リモートアダプタＲＡ１は、リソースマネジャＲＭに対し、トラック１のデータ更新処理が全て終了したことを通知する処理終了通知を出力する。
【０１０５】
（１５）副センタのリモートアダプタＲＡ０は、正センタのリモートアダプタＲＡ０よりトラック０のロストしたパケット以降のデータである再送パケットを受け取る。
【０１０６】
（１６）副センタのリモートアダプタＲＡ０は再送パケットを受け取り、全パケットが揃ったならばリソースマネジャＲＭに対し、データ更新処理のスタート要求を行う。
【０１０７】
（１７）リソースマネジャＲＭは、同一トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡ１が行っていなければ、リモートアダプタＲＡ０に対しデータ更新処理を開始できる旨を通知する。但し同一トラック又は同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡ１が行っている場合は排他制御を行い、同時期に複数のリモートアダプタを動作させないようにする。すなわちリソースマネジャＲＭは、リモートアダプタＲＡ０に対し、リモートアダプタＲＡ１が動作している場合には処理ビジーを通知することになり、その場合リモートアダプタＲＡ０はリソースマネジャＲＭに対するデータ更新処理の再開要求を繰り返すことになる。
【０１０８】
（１８）そしてリモートアダプタＲＡ０がリソースマネジャＲＭから処理開始通知を受け取ったならば、以降、前記（１１）〜（１４）と同様に、キャッシュ２１上のトラック０のＬＴＤを含む６４バイトのＬＴＤデータを読み込み、トラック０のＬＴＤを更新してトラック０のデータを含む６４バイトのＬＴＤデータをキャッシュ２１上のＬＴＤ領域に上書きしてＬＴＤの更新を行い、それからリモートアダプタＲＡ０は正センタのリモートアダプタＲＡ０から受け取ったトラック０のデータをキャッシュ２１上のトラックデータ領域に書き込み、リソースマネジャＲＭに対し、トラック０のデータ更新処理が全て終了したことを通知する処理終了通知を出力する。
【０１０９】
このようにして先ず副センタのリモートアダプタＲＡ０に伝達されたパケットに途中パケットロストが発生しても、副センタのリモートアダプタＲＡ０が処理中断となるので、他のリモートアダプタＲＡ１は処理を待たされることなく処理を行うことができる。
【０１１０】
このように、途中パケットロストの発生したときの副センタのリモートアダプタＲＡ０、ＲＡ１の動作を図４、図５に示すフローチャートにもとづき更に説明する。図４、図５は先ずリモートアダプタＲＡ０が正センタからパケットを受け取った例を示し、また図４のＡは図５のＡと連続することを示す。
【０１１１】
Ｓ１．副センタのリモートアダプタＲＡ０が正センタからパケッを受け取る。
Ｓ２．このリモートアダプタＲＡ０は受信したパケットが当該トラックのパケット１か否かを判断する。
【０１１２】
Ｓ３．パケット１であれば、リモートアダプタＲＡ０は副センタのリソースマネジャＲＭに対し、データ更新処理のスタート要求を行う。
【０１１３】
Ｓ４．リモートアダプタＲＡ０は、このデータ更新処理要求に対しリソースマネジャＲＭからのレスポンスがビジーか否かを判断する。
【０１１４】
Ｓ５．このリソースマネジャＲＭからのレスポンスが処理ビジーでなければ、リモートアダプタＲＡ０は、処理可能であることを示すフラグＦ１をオンにする。そしてＳ９に移り全パケットを受け取っていなければＳ１に戻り、次のパケットを受け取る。
【０１１５】
Ｓ６．しかしレスポンスが処理ビジーであれば、リモートアダプタＲＡ０は、処理ビジーであることを示すフラグＦ２をオンにする。そしてＳ９に移り、全パケットを受け取っていなければＳ１に戻り次のパケットを受け取る。
【０１１６】
Ｓ７．受信したパケットが当該トラックのパケット１でなければ、リモートアダプタＲＡ０はこの正センタから受け取ったパケットの順序性をチェックする。
【０１１７】
Ｓ８．この順序性をチェックして、途中パケットのパケットロストを検出したか否かを判断する。
【０１１８】
Ｓ９．途中パケットのパケットロストを検出せず、また全てのパケットを受け取っていない場合には、フローチャートのＳ１に戻る。
【０１１９】
Ｓ１０．しかし前記Ｓ８において、途中パケットのパケットロストを検出すると、副センタのリモートアダプタＲＡ０は正センタのリモートアダプタＲＡ０に対し、ロストしたパケットの再送要求を行う。
【０１２０】
Ｓ１１．副センタのリモートアダプタＲＡ０は、このとき処理可能を示すフラグＦ１がオフか否かをチェックする。
【０１２１】
Ｓ１２．この処理可能を示すフラグＦ１がオフでなければ、すなわちフラグＦ１がオンであればリソースマネジャＲＭに対し、当該トラックの処理中断通知を行い、他のリモートアダプタＲＡ１が処理可能な状態にする。そして処理可能を示すフラグＦ１をオフにする。
【０１２２】
Ｓ１３．ところで前記Ｓ９において全てのパケットを受け取ったとき、リモートアダプタＲＡ０が自己の、処理可能を示すフラグＦ１がオンかオフかをみる。
【０１２３】
Ｓ１４．この処理可能を示すフラグＦ１がオフでなければ、すなわち処理可能を示すフラグＦ１がオンであれば、リモートアダプタＲＡ０は、キャッシュ２１上のＬＴＤ領域をリモートアダプタＲＡ０自身のメモリ上に読み込む。
【０１２４】
Ｓ１５．リモートアダプタＲＡ０は、このリモートアダプタＲＡ０自身のメモリ上で、キャッシュから読み込んできたＬＴＤに対し、当該トラックのＬＴＤデータを更新する。
【０１２５】
Ｓ１６．それからリモートアダプタＲＡ０はキャッシュ上のＬＴＤ領域に、更新したＬＴＤデータを上書きする。
【０１２６】
Ｓ１７．そしてリモートアダプタＲＡ０は、正センタのリモートアダプタＲＡ０から送られてきたトラックをキャッシュ２１上のトラックデータ領域に書き込む。
【０１２７】
Ｓ１８．それからリモートアダプタＲＡ０は、当該トラックのデータ更新処理が終了したことをリソースマネジャＲＭに対して通知する。
【０１２８】
Ｓ１９．前記Ｓ１３において、リモートアダプタＲＡ０が自己の処理可能を示すフラグＦ１がオフであれば、リソースマネジャＲＭからのレスポンスは処理可能でないことを示すものあるので、リソースマネジャＲＭに対してデータ更新処理のスタート要求を行う。
【０１２９】
Ｓ２０．しかし、この要求に対してリソースマネジャＲＭからのレスポンスが処理ビジーであれば、このフローチャートの「３」に移り、再びリソースマネジャＲＭに対し、データ更新処理のスタート要求を行う。しかしこの要求に対しリソースマネジャＲＭからのレスポンスが処理ビジーでなければ前記Ｓ１４〜Ｓ１８に移行し、データ更新処理の終了がリソースマネジャに通知される。
【０１３０】
なお、図４、図５の説明は、リモートアダプタＲＡ０が正センタからデータを受け取った場合について説明したが、リモートアダプタＲＡ１についても全く同様である。
【０１３１】
次に副センタのリソースマネジャＲＭの動作を、図６により更に説明する。
Ｓ３１．副センタのリソースマネジャＲＭは、リモートアダプタＲＡ０からコマンドを受け取ったとき、そのコマンドがデータ更新処理のスタート要求か否かを判断する。
【０１３２】
Ｓ３２．受け取ったコマンドがデータ更新処理のスタート要求であれば、リソースマネジャＲＭはその更新要求先のＬＴＤが同一６４バイト内のＬＴＤ領域がロック中か否かを判断する。
【０１３３】
Ｓ３３．ロック中であれば、このデータ更新処理のスタート要求に対して許可を与えることができないため、リソースマネジャＲＭはこのスタート要求を行ったリモートアダプタＲＡ０に対して処理ビジーを返す。
【０１３４】
Ｓ３４．しかし前記Ｓ３２においてロック中でなければ、このスタート要求を行ったリモートアダプタＲＡ０に対して処理開始通知を返す。そして同一６４バイト内のＬＴＤ領域を他のリモートアダプタからの更新処理を禁止するためにロックする。このようにしてこのデータ更新処理のスタート要求に対する処理を終了し、次のコマンドを待つ。
【０１３５】
Ｓ３５．リモートアダプタＲＡ０から受け取ったコマンドがデータ更新処理のスタート要求でなければ、処理中断通知を受け取ったか否かを判断する。
【０１３６】
Ｓ３６．受け取ったコマンドが処理中断通知であれば、リソースマネジャＲＭはその処理中断通知先のＬＴＤと同一６４バイト内のＬＴＤ領域に対するロックを解除する。このようにしてこの処理中断通知に対する処理を終了し次のコマンドを待つ。
【０１３７】
Ｓ３７．リモートアダプタＲＡ０から受け取ったコマンドがデータ更新処理のスタート要求でもなく、処理中断通知でもなければ、データ更新処理終了通知を受け取ったか否かを判断する。
【０１３８】
Ｓ３８．受け取ったコマンドがデータ更新処理通知であれば、リソースマネジャＲＭはそのデータ更新処理先のＬＴＤと同一６４バイト内のＬＴＤ領域に対するロックを解除する。このようにしてデータ更新処理終了通知に対する処理を終了し次のコマンドを待つ。
【０１３９】
またリモートアダプタＲＡ０から受け取ったコマンドがデータ更新処理のスタート要求でもなく、処理中断通知でもなく、データ更新処理終了通知でもなければ、リソースマネジャＲＭは、リモートアダプタＲＡ０からの次のコマンドを待つ。
【０１４０】
なお図６の説明は、リモートアダプタＲＡ０からリソースマネジャが何らかのコマンドを受け取った場合について説明したが、他のリモートアダプタＲＡ１から何らかのコマンドを受け取った場合も同様である。
【０１４１】
Ｂ．最終パケットがロストした場合
次に図７〜図１０にもとづき副センタのリモートアダプタＲＡ０で最終パケットのパケットロストを検出した場合の、本発明の動作について説明する。なお最終パケットにはエンドマークが付加されているので、例えばこれを検知することにより最終パケットを検出できる。
【０１４２】
最初にわかり易く説明するため図７のタイムチャートにもとづき、正センタ及び副センタのリモートファイル制御装置にはそれぞれリモートアダプタＲＡ０、ＲＡ１が搭載されていること、入出力命令Ｉ／ＯはこれらリモートアダプタＲＡ０、ＲＡ１の両方が同時に使用される処理命令であるものとし、リモートアダプタＲＡ０の回線パスにおいて最終パケットがロストし、リモートアダプタＲＡ１では正常にパケットの転送が行えた場合について説明する。
【０１４３】
（１）副センタのリモートアダプタＲＡ０が正センタのリモートアダプタＲＡ０より、トラック０に対するパケットを受け取る。
【０１４４】
（２）これにより副センタのリモートアダプタＲＡ０は、リソースマネジャＲＭに対しトラック０に対するデータ更新のスタート要求を行う。
【０１４５】
（３）リソースマネジャＲＭは、同一トラック又は同一６４バイト内のＬＴＤに対する更新処理要求を他のリモートアダプタＲＡ１が行っていなければ、リモートアダプタＲＡ０に対し、データ更新処理の開始できることを示す処理開始通知を行う。
【０１４６】
（４）このあとで副センタのリモートアダプタＲＡ１は正センタのリモートアダプタＲＡ１よりトラック１に対するパケットを受け取る。
【０１４７】
（５）これにより副センタのリモートアダプタＲＡ１はリソースマネジャＲＭに対し、トラック１に対するデータ更新のスタート要求を行う。これによりリソースマネジャＲＭは、リモートアダプタＲＡ１よりＲＡ０からのスタート要求が早く通知されたことを覚えておく。
【０１４８】
（６）リソースマネジャＲＭは同トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタが行っている場合は排他制御を行い、同時期に複数のリモートアダプタを動作させないようにする。この場合リソースマネジャＲＭは、リモートアダプタＲＡ１に対して、リモートアダプタＲＡ０がすでに更新処理動作を行っているので、処理ビジーを通知する。
【０１４９】
（７）正センタのリモートアダプタＲＡ０から出力されたトラック０のパケット２が副センタのリモートアダプタＲＡ０に受け取られる。
【０１５０】
（８）正センタのリモートアダプタＲＡ１から出力されたトラック１のパケット２が副センタのリモートアダプタＲＡ１に受け取られる。
【０１５１】
（９）続いて正センタのリモートアダプタＲＡ０から転送されたトラック０のパケット３、４・・・１１が副センタのリモートアダプタＲＡ０に受け取られるが最後のパケット１２が受け取られない状態となる。
【０１５２】
（１０）しかし正センタのリモートアダプタＲＡ１から転送されたトラック１のパケット３、４・・・１２が副センタのリモートアダプタＲＡ１に受け取られる。
【０１５３】
（１１）副センタのリモートアダプタＲＡ１は、このトラック１の最終パケット１２を受け取ることにより正センタから受け取るべきパケットを全部受け取るので、リソースマネジャＲＭに対して全パケット受け取り通知を発行し、再度トラック１に対するデータ更新のスタート要求を行う。これによりリソースマネジャＲＭは、リモートアダプタＲＡ０よりも早くリモートアダプタＲＡ１から全パケット受け取り通知がきたことにより、リモートアダプタＲＡ０におけるパケットロストが発生したと認識する。
【０１５４】
（１２）これにもとづきリソースマネジャＲＭは、リモートアダプタＲＡ０に対しパケットロストの発生したこと及び処理中断を通知する（パケットロスト通知＋処理中断通知）を送出する。
【０１５５】
（１３）これにより、副センタのリモートアダプタＲＡ０は、パケットロストが発生したことを認識し、正センタのリモートアダプタＲＡ０に対し、また受け取っていないパケットつまりロストしたトラック０のパケット１２の再送要求を行う。その際それまでに受け取ったパケットの内容を保持しておき、まだ受け取っていないパケットすなわちロストしたパケットが正センタから再送されてくるのを待つ。
【０１５６】
（１４）リソースマネジャＲＭは、前記（１１）においてリモートアダプタＲＡ１からデータ更新のスタート要求を受け取ったので、リモートアダプタＲＡ１に対して処理開始通知を行ってデータ更新処理を開始できることを通知する。すなわち前記（１２）においてリモートアダプタＲＡ０に対し処理中断を行っているので、トラック１のＬＴＤと同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡ０が行っていないので、リモートアダプタＲＡ１への処理開始通知が可能となる。
【０１５７】
（１５）以降の処理は前記図３の（１１）〜（１８）の処理と同様であるので、説明の簡略化のため省略する。
【０１５８】
このようにして、従来は最終パケットのロストの場合については次に送られてくるパケットがないため検出できなかったものが、本発明では副センタのリモートアダプタＲＡとリソースマネジャＲＭとの間に、以下に示すコマンドを通知することにより最終パケットのロストを検出することができる。
【０１５９】
イ、リモートアダプタＲＡはリソースマネジャＲＭに対し、従来と同様にパケット１を受け取った際に「処理開始通知」を発行する。
【０１６０】
ロ、リモートアダプタＲＡは、リソースマネジャＲＭに対し、全パケットを受け取った際に「全パケット受け取り通知」を発行する。
【０１６１】
ハ、リソースマネジャＲＭは、リモートアダプタに対し、パケットロストが発生したと認識した際に「パケットロスト通知＋処理中断通知」を発生する。
【０１６２】
このように最終パケットロストの発生したときの副センタのリモートアダプタＲＡ０、ＲＡ１の動作を図８、図９に示すフローチャートにもとづき更に説明する。但し、このフローチャートには途中パケットをロストした場合の考慮も含んでいる。図８、図９は先ずリモートアダプタＲＡ０が正センタからパケッを受け取った例を示し、また図８のＢは図９のＢと連続することを示す。
【０１６３】
Ｓ１．副センタのリモートアダプタＲＡ０が正センタからパケッを受け取る。
Ｓ２．このリモートアダプタＲＡ０は受信したパケットが当該トラックのパケット１か否かを判断する。
【０１６４】
Ｓ３．パケット１であれば、リモートアダプタＲＡ０は副センタのリソースマネジャＲＭに対し、データ更新処理のスタート要求を行う。
【０１６５】
Ｓ４．リモートアダプタＲＡ０は、このデータ更新処理要求に対してリソースマネジャＲＭからのレスポンスがビジーか否かを判断する。
【０１６６】
Ｓ５．このリソースマネジャＲＭからのレスポンスが処理ビジーでなければ、リモートアダプタＲＡ０は、処理可能であることを示すフラグＦ１をオンにする。
【０１６７】
Ｓ６．しかしレスポンスが処理ビジーであれば、リモートアダプタＲＡ０は、処理ビジーであることを示すフラグＦ２をオンにする。
【０１６８】
Ｓ７．前記Ｓ２において、受信したパケットが当該トラックのパケット１でなければ、リモートアダプタＲＡ０はこの正センタから受け取ったパケットの順序性をチェックする。
【０１６９】
Ｓ８．この順序性をチェックして、途中パケットのパケットロストを検出したか否かを判断する。
【０１７０】
Ｓ９．これにより途中パケットのパケットロストを検出すると、副センタのリモートアダプタＲＡ０は正センタのリモートアダプタＲＡ０に対し、ロストしたパケットの再送要求を行う。
【０１７１】
Ｓ１０．副センタのリモートアダプタＲＡ０は、このとき処理可能を示すフラグＦ１がオフか否かをチェックする。
【０１７２】
Ｓ１１．この処理可能を示すフラグＦ１がオフでなければ、すなわちフラグＦ１がオンであれば、リソースマネジャＲＭに対し、当該トラックの処理中断通知を行い、他のリモートアダプタＲＡ１が処理可能な状態にする。そして処理可能を示すフラグＦ１をオフにする。
【０１７３】
Ｓ１２．前記Ｓ８において途中パケットのロストパケットを検出しないか、あるいは前記Ｓ１０において処理可能を示すフラグＦ１がオフの場合、あるいは前記Ｓ１１の処理可能を示すフラグＦ１がオフにしたあとで、リモートアダプタＲＡ０はリソースマネジャＲＭから（パケットロスト通知＋処理中断通知）を受け取ったか否かを判断する。
【０１７４】
Ｓ１３．リモートアダプタＲＡ０は、リソースマネジャＲＭから前記（パケットロスト通知＋処理中断通知）を受け取っていなければ、当該トラックの全てのパケットを受け取ったか否かを判断し、受け取っていなければ、図８に示すフローチャートの前記Ｓ１に戻る。
【０１７５】
Ｓ１４．しかし前記Ｓ１３において当該トラックの全てのパケットを受け取っていれば、リソースマネジャＲＭに対して、全パケット受け取り通知を行う。
【０１７６】
Ｓ１５．それからリモートアダプタＲＡ０は自己の処理可能を示すフラグＦ１がオフか否かをみる。
【０１７７】
Ｓ１６．この処理可能を示すフラグＦ１がオフでなければ、すなわち処理可能を示すフラグＦ１がオンであれば、リモートアダプタＲＡ０はキャッシュ２１上のＬＴＤ領域をリモートアダプタＲＡ０自身のメモリ上に読み込む。
【０１７８】
Ｓ１７．リモートアダプタＲＡ０は、このリモートアダプタＲＡ０自身のメモリ上で、キャッシュから読み込んできたＬＴＤに対し、当該トラックのＬＴＤデータを更新する。
【０１７９】
Ｓ１８．それからリモートアダプタＲＡ０はキャッシュ上のＬＴＤ領域に、更新したＬＴＤデータを上書きする。
【０１８０】
Ｓ１９．そしてリモートアダプタＲＡ０は、正センタのリモートアダプタＲＡ０から送られてきたトラックをキャッシュ２１上のトラックデータ領域に書き込む。
【０１８１】
Ｓ２０．それからリモートアダプタＲＡ０は、当該トラックのデータ更新処理が終了したことをリソースマネジャＲＭに対して通知する。
【０１８２】
Ｓ２１．前記Ｓ１２において、リモートアダプタＲＡ０がリソースマネジャＲＭから（パケットロスト通知＋処理中断通知）を受け取っていれば、リモートアダプタＲＡ０は正センタのリモートアダプタＲＡ０に対し、ロストした可能性のあるパケットの再送要求を行い、処理可能を示すフラグＦ１をオフにする。そして前記Ｓ１３に移る。
【０１８３】
Ｓ２２．前記Ｓ１５において、リモートアダプタＲＡ０が自己の処理可能を示すフラグＦ１がオフであれば、リソースマネジャＲＭからのレスポンスは処理可能でないことを示すものであるので、リソースマネジャＲＭに対してデータ更新処理のスタート要求を行う。
【０１８４】
Ｓ２３．しかしこの要求に対してリソースマネジャＲＭからのレスポンスが処理ビジーであればこのフローチャートの「３」に移り、再びリソースマネジャＲＭに対し、データ更新処理のスタート要求を行う。またこの要求に対しリソースマネジャＲＭからのレスポンスが処理ビジーでなければ前記Ｓ１６〜Ｓ２０に移行し、データ更新処理の終了がリソースマネジャＲＭに通知される。
【０１８５】
なお図８、図９の説明は、リモートアダプタＲＡ０が正センタからデータを受け取った場合について説明したが、リモートアダプタＲＡ１についても全く同様である。
【０１８６】
次に副センタのリソースマネジャＲＭの動作を、図１０により更に説明する。
Ｓ４１．副センタのリソースマネジャＲＭは、リモートアダプタＲＡ０又はＲＡ１からコマンドを受け取ったとき、そのコマンドがデータ更新処理のスタート要求か否かを判断する。
【０１８７】
Ｓ４２．受け取ったコマンドがデータ更新処理のスタート要求であれば、リソースマネジャＲＭはその更新要求先のＬＴＤが同一６４バイト内のＬＴＤ領域がロック中か否かを判断する。
【０１８８】
Ｓ４３．ロック中であれば、このデータ更新処理のスタート要求に対して許可を与えることができないため、リソースマネジャＲＭはこのスタート要求を行ったリモートアダプタＲＡ０又はＲＡ１に対して処理ビジーを返す。
【０１８９】
Ｓ４４．しかし前記Ｓ４２においてロック中でなければ、このスタート要求を行ったリモートアダプタＲＡ０又はＲＡ１に対して処理開始通知を返す。そして同一６４バイト内のＬＴＤ領域を他のリモートアダプタからの更新処理を禁止するためにロックする。このようにしてデータ更新処理のスタート要求に対する処理を終了し、次のコマンドを待つ。
【０１９０】
Ｓ４５．リモートアダプタＲＡ０又はＲＡ１から受け取ったコマンドがデータ更新処理のスタート要求でなければ、処理中断通知を受け取ったか否かを判断する。
【０１９１】
Ｓ４６．受け取ったコマンドが処理中断通知であれば、リソースマネジャＲＭはその処理中断通知先のＬＴＤと同一６４バイト内のＬＴＤ領域に対するロックを解除する。このようにしてこの処理中断通知に対する処理を終了し次のコマンドを待つ。
【０１９２】
Ｓ４７．リモートアダプタＲＡ０又はＲＡ１から受け取ったコマンドがデータ更新処理のスタート要求でもなく、処理中断通知でもなければ、全パケット受け取り通知を受け取ったか否かを判断する。
【０１９３】
Ｓ４８．受け取ったコマンドが全パケット受け取り通知であれば、リソースマネジャＲＭはリモートアダプタＲＡ０又はＲＡ１からスタート要求を受け取った順番と、リモートアダプタＲＡ０又はＲＡ１からの全パケット受け取り通知を受け取った順番が一致しているかチェックする。
【０１９４】
Ｓ４９．順番が一致していれば、そのまま処理を終了し、次のコマンドを待つ。
【０１９５】
Ｓ５０．しかし順番が一致していなければ、リソースマネジャＲＭは全パケット受け取り通知が発行されていないリモートアダプタＲＡ０又はＲＡ１に対し、（パケットロスト通知＋処理中断通知）を行う。そして処理中断通知先のＬＴＤと同一６４バイト内のＬＴＤ領域に対するロックを解除する。このようにしてこの順番が一致しない場合の処理を終了し次のコマンドを待つ。
【０１９６】
Ｓ５１．リモートアダプタＲＡ０又はＲＡ１から受け取ったコマンドがデータ更新処理のスタート要求でもなく、処理中断通知でもなく、全パケット受け取り通知でもなければ、データ更新処理終了通知を受け取ったか否かを判断する。
【０１９７】
Ｓ５２．受け取ったコマンドがデータ更新処理終了通知であれば、リソースマネジャＲＭはそのデータ更新処理先のＬＴＤと同一６４バイト内のＬＴＤ領域に対するロックを解除する。このようにしてデータ更新処理終了通知に対する処理を終了し、次のコマンドを待つ。
【０１９８】
またリモートアダプタＲＡ０又はＲＡ１から受け取ったコマンドがデータ更新処理のスタート要求でもなく、処理中断通知でもなく、全パケット受け取り通知でもなく、データ更新処理終了通知でもなければ、リソースマネジャＲＭはリモートアダプタＲＡ０又はＲＡ１からの次のコマンドを待つ。
【０１９９】
Ｃ．途中パケットがロストした場合と最終パケットがロストした場合とを総合したもの。
【０２００】
前記Ａ．Ｂを総合した場合を図１１〜図１２にもとづき説明する。図１１は途中パケットがロストした場合と最終パケットがロストした場合とを総合した場合の副センタにおけるタイムチャート（その１）を示し、図１２は同じタイムチャート（その２）を示す。なお図１１、１２はリモートアダプタＲＡ０、ＲＡ１の他にＲＡ２が設けられた例について説明する。
【０２０１】
（１）副センタのリモートアダプタＲＡ０が正センタのリモートアダプタＲＡよりトラック０に対するパケット１を受け取る。
【０２０２】
（２）これにより副センタのリモートアダプタＲＡ０は、リソースマネジャＲＭに対し、トラック０に対するデータ更新のスタート要求を行う。
【０２０３】
（３）リソースマネジャＲＭは、同一トラック又は同一６４バイト内のＬＴＤに対する更新処理要求を他のリモートアダプタＲＡすなわちＲＡ１、ＲＡ２が行っていなければ、リモートアダプタＲＡ０に対し、データ更新処理の開始できることを示す処理開始通知を行う。
【０２０４】
（４）このあとで副センタのリモートアダプタＲＡ１は、前記（１）と同様に、正センタのリモートアダプタＲＡよりトラック１に対するパケット１を受け取る。この際、リソースマネジャＲＭはリモートアダプタＲＡ１よりもＲＡ０からの処理開始通知が早く通知されたことを覚えておく。
【０２０５】
（５）リモートアダプタＲＡ１は、前記（２）と同様に、リソースマネジャＲＭに対し、トラック１のデータ更新のスタート要求を行う。
【０２０６】
（６）リソースマネジャＲＭは同一トラックまたは同一６４バイト内のＬＴＤに対する更新処理を、他のリモートアダプタが行っている場合は排他制御を行い、同時期に複数のリモートアダプタＲＡを動作させないようにする。つまりリソースマネジャＲＭはリモートアダプタＲＡ１に対して、リモートアダプタＲＡ０が既に動作しているので、処理ビジーを通知する。
【０２０７】
（７）リモートアダプタＲＡ２は、前記（１）と同様に、正センタのリモートアダプタＲＡよりトラック２に対するパケット１を受け取る。
【０２０８】
（８）リモートアダプタＲＡ２は、前記（２）と同様に、リソースマネジャＲＭに対し、トラック２に対するデータ更新のスタート要求を行う。この際、リソースマネジャＲＭは、リモートアダプタＲＡ２よりもリモートアダプタＲＡ０、ＲＡ１からの処理開始通知が早く通知されたことを覚えておく。
【０２０９】
（９）リソースマネジャＲＭは同トラックまたは同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡが行っている場合は排他制御を行い、同時期に複数のリモートアダプタＲＡを動作させないようにする。つまりリソースマネジャＲＭはリモートアダプタＲＡ２に対し、リモートアダプタＲＡ０が既に動作しているので、処理ビジーを通知する。
【０２１０】
（１０）リモートアダプタＲＡ０は正センタのリモートアダプタＲＡより、トラック０のパケット２を受け取る。
【０２１１】
（１１）リモートアダプタＲＡ１は、前記（１０）と同様に、正センタのリモートアダプタＲＡより、トラック１のパケット２を受け取る。
【０２１２】
（１２）リモートアダプタＲＡ２は、前記（１０）と同様に、正センタのリモートアダプタＲＡより、トラック２のパケット２を受け取る。
【０２１３】
（１３）回線上でトラック０の途中パケットがロストしてしまった場合、リモートアダプタＲＡ０はパケットの順序性が崩れることにより、当該処理トラック０に関してパケットロストを検出する。リモートアダプタＲＡ０は、パケットロストを検出したなら、リソースマネジャＲＭに対し、当該トラック０の更新処理を中断する旨を通知する。
【０２１４】
（１４）リモートアダプタＲＡ０は正センタのリモートアダプタＲＡに対してロストしたパケット以降のパケットの再送要求を行う。その際それまでに受け取ったパケットの内容は保持しておき、ロストしたパケット以降のパケットが正センタから再送されてくるのを待つ。
【０２１５】
（１５）リモートアダプタＲＡ０は正センタのリモートアダプタＲＡよりトラック０のパケット１２を受け取る。ただしリモートアダプタＲＡ０は途中パケットのロストを以前に検出しているので、ロストしたパケットより後のパケットを受け取った際は内部的に捨てる。
【０２１６】
（１６）リモートアダプタＲＡ１の回線上でトラック１のパケット１２のロストが発生するが、リモートアダプタＲＡ１はこのパケット１２のロストを検出できないので、ロストの発生を認識していない。
【０２１７】
（１７）リモートアダプタＲＡ２は正センタのリモートアダプタＲＡよりトラック２のパケット１２を受け取る。
【０２１８】
（１８）リモートアダプタＲＡ２は、正センタから受け取るべきパケットを全て受け取ったならば、リソースマネジャＲＭに対し、全パケットを受け取った旨を通知する。また同時に再度データ更新のスタート要求を行う。リソースマネジャＲＭは、リモートアダプタＲＡ１よりも早くリモートアダプタＲＡ２より全パケット受け取り通知が来たことから、リモートアダプタＲＡ１に関してパケットロストが発生したと認識する。
【０２１９】
（１９）リソースマネジャＲＭは、前記（１８）においてパケットロストを検出したならば、リモートアダプタＲＡ１に対して「パケットロスト通知＋処理中断通知」を行う。
【０２２０】
（２０）リモートアダプタＲＡ１はリソースマネジャＲＭからの前記「パケットロスト通知＋処理中断通知」により、パケットロストが発生したことを認識し、正センタのリモートアダプタＲＡに対して、まだ受け取っていない、ロストしたパケットの再送要求を行う。その際、それまでに受け取ったパケットの内容は保持しておき、まだ受け取っていないロストしたパケットが正センタから再送されてくるのを待つ。
【０２２１】
（２１）リソースマネジャＲＭは、前記（１８）にてリモートアダプタＲＡ２よりデータ更新のスタート要求を受け取ったので、リモートアダプタＲＡ２に対し、データ更新処理を開始できる旨を通知する。即ち、リモートアダプタＲＡ０、ＲＡ１は処理中断のため、同一６４バイト内のＬＴＤに対する更新処理を他のリモートアダプタＲＡが行っていないので、このようなデータ更新処理開始ができる。
【０２２２】
（２２）以降の処理は、前記図３の（１１）〜（１８）と同様の処理をトラック２とトラック０に関して行う。
【０２２３】
（２３）またトラック１の再送パケットが届いたならば、前記図３の（１５）〜（１８）と同様の処理をトラック１に関して行う。
【０２２４】
前記説明は、正センタ及び副センタにリモートアダプタが２個又は３個設けられた例について説明したが本発明はこれに限定されるものではなく、４個以上の場合でも同様に適用することができる。
【０２２５】
またキャッシュ領域へのアクセスが６４バイト単位の例について説明したが、本発明は勿論これに限定されるものではない。
【０２２６】
なお図３に示すα１は図１６に示すα１と同じ時間経過に相当し、図７に示すα２は図１８に示すα２と同じ時間経過に相当する。これによっても本発明における処理の高速化が理解できる。
【０２２７】
【発明の効果】
本発明によれば下記の効果を奏するものである。
（１）途中パケットのロストを検出したリモートアダプタが、その時点でリソースマネジャに対して処理中断を通知し、リソースマネジャはそのリモートアダプタに対する同一６４バイト内のＬＴＤ領域に対するロックつまりアクセス禁止状態を解除するので、処理ビジーで待たされていたリモートアダプタがすぐにＬＴＤ領域に対して動作を行うことができ、その結果従来技術より処理時間を早くすることができる。
【０２２８】
（２）最初にスタート要求したリモートアダプタからリソースマネジャに全パケット受取通知が到着しないときに後からスタート要求を出したリモートアダプタからの全パケットン受取通知が到着したとき、リソースマネジャが最終パケットロストが発生したものと判断して全パケット受取通知の到着しないリモートアダプタにパケットロスト通知＋処理中断通知を出力することにより、処理ビジーで待たされていた全パケットを受取った方のリモートアダプタがすぐにＬＴＤ領域に対して動作を行うことができ、また最終パケットのロストを早く検出することができ、その結果従来技術より処理時間を早くすることができる。
【図面の簡単な説明】
【図１】本発明の原理図である。
【図２】本発明の一実施の形態である。
【図３】途中パケットをロストしたときの副センタにおけるタイムチャートである。
【図４】途中パケットをロストしたときの副センタのリモートアダプタＲＡの動作説明図（その１）である。
【図５】途中パケットをロストしたときの副センタのリモートアダプタＲＡの動作説明図（その２）である。
【図６】途中パケットをロストしたときの副センタのリソースマネジャＲＭの動作説明図である。
【図７】最終パケットをロストしたときの副センタにおけるタイムチャートである。
【図８】最終パケットをロストしたときの副センタのリモートアダプタＲＡの動作説明図（その１）である（但し途中パケットをロストした場合の考慮も含む）。
【図９】最終パケットをロストしたときの副センタのリモートアダプタＲＡの動作説明図（その２）である（但し途中パケットをロストした場合の考慮も含む）。
【図１０】最終パケットをロストしたときの副センタのリソースマネジャＲＭの動作説明図である（但し途中パケットをロストした場合の考慮も含む）。
【図１１】途中パケットがロストした場合と最終パケットがロストした場合とを総合した場合の本発明の副センタにおけるタイムチャート（その１）である。
【図１２】途中パケットがロストした場合と最終パケットがロストした場合とを総合した場合の本発明の副センタにおけるタイムチャート（その２）である。
【図１３】従来のリモートファイル制御装置説明図である。
【図１４】従来のリモート転送説明図である。
【図１５】リモートファイル制御装置のＬＴＤ説明図である。
【図１６】従来の途中パケットをロストしたときの副センタにおけるタイムチャートである。
【図１７】パケットロスト説明図である。
【図１８】従来の最終パケットをロストしたときの副センタにおけるタイムチャートである。
【符号の説明】
１  ホストプロセッサ
２  リモートファイル制御装置
３  チャネルアダプタ
４、５  リモートアダプタ
６  デバイス
８、９  回線
１５  リソースマネジャ
１６、１７  中断手段
１８  全パケット受取り通知監視手段
２１  キャッシュ
【図１】
0003756690.tif 000002
【図２】
0003756690.tif 000003
【図３】
0003756690.tif 000004
【図４】
0003756690.tif 000005
【図５】
0003756690.tif 000006
【図６】
0003756690.tif 000007
【図７】
0003756690.tif 000008
【図８】
0003756690.tif 000009
【図９】
0003756690.tif 000010
【図１０】
0003756690.tif 000011
【図１１】
0003756690.tif 000012
【図１２】
0003756690.tif 000013
【図１３】
0003756690.tif 000014
【図１４】
0003756690.tif 000015
【図１５】
0003756690.tif 000016
【図１６】
0003756690.tif 000017
【図１７】
0003756690.tif 000018
【図１８】
0003756690.tif 000019