JPH06342396A - 共有データのアクセスを直列化する方法及び装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】データの整合性を維持しながら複数のシステム
間でデータを共有する。 【構成】ユーザ・データ４０２Ａ，Ｂはプライマリ・デ
ータ・ストアとオプションの代替データ・ストアに維持
される。各データ・ストアは１組のロック・ブロック４
０１Ａ〜Ｎを含み、各ロック・ブロックが、データを共
有する各システムに対応する。ロック・ブロックの内容
は通常は時刻値ＴＯＤであり、関連データのシステム所
有権の状態を示す。データの整合性を保証するためにサ
フィクス・レコード４０４Ａ，Ｂとチェック・レコード
４０３が用いられる。矛盾するサフィクス・レコードや
チェック・レコードから導かれたエラー指示を用いて、
データ復旧メカニズムがトリガされる。復旧メカニズム
は、同期化プロセスの間にプライマリへのアクセスを保
留する必要なくプライマリとセカンダリのデータ・スト
アの同期をとることができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、コンピュータ及びコ
ンピュータ・コンプレクスのオペレーティング・システ
ムに関し、特に、コンピュータまたはコンピュータ・コ
ンプレクスの各ユーザ間でデータを共有するメカニズム
とプロセスに関する。

【０００２】

【従来の技術】マルチプロセサ・コンプレクスまたはシ
スプレクス(sysplex)におけるデータの共有は、共有す
べきデータのロケーション（メイン・ストレージまたは
ＤＡＳＤなど）、可能なアクセスの性質（読み出し専
用、読み出し・書き込みなど）、及び共有の粒度（デバ
イス・レベルの共有、データ・セット・レベルの共有、
レコード・レベルの共有など）に応じて様々な方法で行
われる。実質上すべての共有メカニズムに共通するのは
ロッキング・メカニズムである。ロッキング・メカニズ
ムは、あるユーザによって変更されたデータが、変更が
完全になるまでは別のユーザによって参照されないよう
にする。ロッキング・メカニズムの例として、ＩＢＭ
ＭＶＳシステムでは、ＤＡＳＤデータ・セットへのアク
セスを直列化するためにＲＥＳＥＲＶＥメカニズムが用
いられる。MVS/ESA SPL: ApplicationDevelopment Macr
o Reference (GC28-1857-1) に述べられているように、
ＲＥＳＥＲＶＥでは、特定のシステム上の特定のタスク
で使用するデバイスを予約することができる。このメカ
ニズムを使えば、予約（ＲＥＳＥＲＶＥ）されたデバイ
ス上のすべてのデータ・セットを、それを所有するタス
クがデバイスを開放するまで、他のシステム上の他のタ
スクが使用できる。データの整合性は保証されるが、こ
のメカニズムの粒度が細かいものでないことは明らかで
ある。ＥＮＱ／ＤＥＱ（上記と同じ出版物に説明されて
いる）というメカニズムでは、ユーザが、順次に使用で
きるリソース（すなわちユーザ間で共有できるが、一度
に１ユーザしかアクセスできないリソース）を定義して
同じように制御することができる。また、IBM Technica
l Disclosure Bulletin、Vol. 22、No. 6（1979年11月
号） の pp. 2571-2573に説明されているメカニズムで
は、ユーザ固有キーを、時刻インディケータとともに、
アクセス・レコードに格納することによって、異なるシ
ステム間でデータ・セットをレコード・レベルで共有す
ることができる。アクセス・レコードは、後続のアクセ
ス側に対するロック・インディケータとなる。

【０００３】

【発明が解決しようとする課題】上述のメカニズムやそ
れらと同様の機構では、ロックをかけるユーザのシステ
ムがかなりの時間使用できなくなった場合に、ユーザに
よってロックされたリソースが他のユーザから見えなく
なってしまう。また、データに障害があった場合のファ
シリティやアシスタンスが提供されておらず、可用性の
ためにバックアップのデータ・セットを維持すべき状況
には言及されていない。

【０００４】この発明の目的は、システムまたはシステ
ム・コンプレクスの各ユーザ間でデータを効率よく共有
できるようにすることにある。

【０００５】この発明の目的には、停止したシステムに
よってロックされた共有データを、シスプレクスの他の
システムが使用できるようにすることも含まれる。

【０００６】この発明の目的には、一時的に停止したシ
ステムが、停止前にロックしていたデータを他のシステ
ムがアクセスしても、不都合を生じないように操作を再
開できるようにすることも含まれる。

【０００７】この発明の目的には、障害のあったデータ
を、代替またはバックアップのデータ・ストアに切り替
えることなく復旧することも含まれる。

【０００８】この発明の目的には、同期化プロセスの間
にプライマリ・データ・ストアへのアクセスを一時的に
保留することなく、新しい代替データ・ストアとの同期
をとることも含まれる。

【０００９】

【課題を解決するための手段】この発明によれば、共有
されたユーザ・データは、プライマリ・データ・ストア
に格納される。プライマリ・データ・ストアは、ロック
・ブロック（各々データを共有する各システムに関連す
る）の形の制御情報、サフィクス・レコード、及びチェ
ック・レコードを含む。サフィクス・レコードとチェッ
ク・レコードは、ユーザ・データの整合性を保証するの
に用いられ、ロック・ブロックは、共有するシステムの
１つが、必要に応じてデータを“ロックする”ために用
いられる。

【００１０】この発明はまた、制御情報を含み、最初は
プライマリ・データ・ストアと同一の（２重化された）
代替データ・ストアを与える。代替データ・ストアは、
存在するときには、障害のあったデータの再生を可能に
することによって、データの可用性を高める。代替デー
タ・ストアは“ロック・スティーリング”にも用いられ
る。ロック・スティーリングでは、共有する第２システ
ム（第１システムによってロックされたリソースを必要
とする）が、第１システムによって保持されていたロッ
クを“奪い”、プライマリ・データ・ストアと代替デー
タ・ストアの制御情報を操作することによって、ロック
が“奪われた”ことを指示できるので、第１システムは
後で、不都合が生じないように処理を再開することがで
きる。

【００１１】

【実施例】図１は、「共有データ・アクセス直列化」の
ハイレベル・ビューである。「共有データ・アクセス直
列化」は、共有ＤＡＳＤ上に維持されたユーザ・データ
の更新を直列化するためのものである。直列化は、レベ
ルの低い粒度（ユーザ・レコードまたはリソースが１
つ）で行われ、公正なアクセスが保証され、障害が克服
される。

【００１２】ユーザ・リソースを維持するのに用いられ
るデータ・ストアはＤＡＳＤデバイスに格納されるのが
普通である。「共有データ・アクセス直列化」は、グロ
ーバル制御情報をデータ・ストアに維持する（図３の３
０２）。プライマリ・データ・ストア（図１の１０３）
はユーザ・データを格納する。ユーザ・データは任意に
代替データ・ストア（図１の１０４）で２重化すること
ができる。データ・ストアは各々、自身の制御情報を格
納する。したがってプライマリ・データ・ストア、代替
データ・ストアのいずれも、そのデータ・ストアのデー
タをアクセスするための制御情報を格納する（プライマ
リ／代替データ・ストアについて詳しくはデータ２重化
の説明を参照のこと）。制御情報には、リソースの論理
名から物理ロケーション及びデータ属性へのマップが含
まれ、ユーザ要求で与えられたデータの名前を、対象リ
ソースを支える物理データへマッピングするのに用いら
れる。従来からのこのマッピングは、実際の直列化プロ
トコルには関係がなく、ここでは詳述しない。

【００１３】データ・ストアに格納された各リソース
は、これに関連するリソース・レベルの制御情報がいく
つかのタイプに分けられる。この制御情報は、リソース
へのアクセスの制御に用いられ、ユーザ・データの復旧
と信頼性を管理するために用いられる（図３の３０３参
照）。

【００１４】アクセス制御情報は１組のロック・ブロッ
クから成る。ロック・ブロックは、リソースの共有に関
与し得る各システムに１つである。図４は、ロック・ブ
ロック４０１とリソースのユーザ・データ４０２の関係
を示す。この図には、リソースを共有し得る各システム
にロック・ブロックが１つあることも示した。この例の
場合、リソースを共有できるシステムは“ｎ”個であ
る。各システムに、ロック・ブロックの所有権が割り当
てられ、与えられたロック・ブロックは１システムしか
所有できない。ロック・ブロックの所有権は、システム
の初期化時に、データ・ストアのグローバル制御情報の
なかの情報を使って割り当てられる。ロック・ブロック
３が割り当てられたシステムはロック・ブロック３を所
有する。ロック・ブロックの位置の所有権と特定のリソ
ースの所有権は同じではない。ロック・ブロック位置の
所有権はリソースの所有権を意味しない。

【００１５】ロック・ブロックはカウント／キー／デー
タ・レコードである。レコードのキー部は、直列化プロ
セスでは重視されない。レコードのデータ部も重要では
なく、直列化プロセスでは必要ない。図５に示すとお
り、キー５０１は、システム・シーケンス・ナンバ（グ
ローバル制御情報のなかの情報を使ってシステム初期化
時に一意に割り当てられる）と、時刻（ＴＯＤ）値（リ
ソースのアクセス要求の順序を定めるのに用いられる）
から成る。ロック・ブロックは、通常はアンロック状態
またはオール・ゼロである。ロック状態（リソース更新
の意図を示す）は、少なくとも１つのロック・ブロック
のゼロでないキー・フィールドによって反映される。

【００１６】リソースは、アクセス制御情報のほか、デ
ータの整合性を保証するための制御情報を含む。サフィ
クス・レコードは、関連する物理データ・レコードに格
納されたユーザ・データが完全かつ矛盾のないようにす
るために用いられる。図４の４０４Ａ、４０４Ｂに示し
たとおり、サフィクス・レコードは、データのユーザに
は見えないが、ユーザ・データ・レコードの物理的な部
分である。サフィクス・レコードに維持されるシングル
・レコード・ライトの時刻（ＴＯＤ）値（図６の６０
４）は、１つの物理レコードの完全性または無矛盾性を
判定するのに用いられる。

【００１７】サフィクス・レコードのほかに、マルチ・
レコード・ライト操作に対してデータの整合性を保証す
るためにチェック・レコード（図４の４０３）が用いら
れる。サフィクス・レコードだけでは、要求に対して物
理ブロックが２つ以上書き込まれた場合にデータの整合
性を保証するのに充分ではない。実際に書き込まれる物
理レコードはすべて正常に書き込まれるかもしれない
が、マルチ・レコード・ライト操作を成す、意図された
物理レコードがすべて書き込まれていなければ、リソー
スは、全体として一貫性のないものになる。チェック・
レコードと各サフィクス・レコードに維持されるマルチ
・レコード・ライト時刻（ＴＯＤ）値は、リソースを構
成するすべての物理ブロックが論理的に矛盾のないこと
を保証するために用いられる。

【００１８】シーケンス・ナンバは、サフィクス・レコ
ード、チェック・レコードのいずれにも維持される。シ
ーケンス・ナンバ・フィールドは、データ・ストアを共
有する各システムについて１つである。シーケンス・ナ
ンバは、システムがプライマリ・データ・ストアに書き
込んだデータが、あるエラー条件下で代替データ・スト
アに伝播したかどうかを判定するためにシステムによっ
て用いられる。このようなエラー条件の復旧時に、シー
ケンス・ナンバが用いられ、「共有データ・アクセス直
列化」が、ユーザの変更結果がデータ・ストアに正常に
書き込まれたか、または変更は行われず、ユーザがリー
ド直列化／データ変更／ライト直列化の更新シーケンス
を再起動しなければならないかどうかを、シーケンス・
ナンバのユーザに通知する。

【００１９】「共有データ・アクセス直列化」データを
維持するのに用いられるデータ・ストアには一定の性質
がなければならない。データ・ストア・デバイス（ＤＡ
ＳＤデバイス）は、あるシステムから要求を開始すれ
ば、そのシステムからの要求を完全にするか、または別
のシステムから要求を開始する前に、エラーをもって要
求を中止しなければならない。すなわち、要求はデータ
・ストア・デバイスによってインタレースすることはで
きない。要求の操作は、いつでも中断できるが、その割
り込みは、「共有データ・アクセス直列化」の例外とし
てレポートしなければならない。データ・ストアに書き
込まれたデータは、データ・ストアに存在する順序で処
理しなければならない。すなわち、データ・ストアに存
在するデータは、ランダムな順序あるいはインタリーブ
した順序でプロセサからデータ・ストア上のレコードに
転送することはできない。これはサフィクス・レコード
（物理的にデータ・ストア・レコードの最期の部分）が
一貫性チェックに用いられるからである。一貫性チェッ
クが正しく機能するためには、サフィクス・レコード
は、ユーザ・データがすべて書き込まれた後で書き込ま
なければならない。データ・ストアへのデータ転送が、
データ転送の完了前に中止されなければならない場合
は、転送されなかったデータは、データ・ストア上でゼ
ロにセットしなければならない。チェック・レコードの
この矛盾したデータにより、データの一貫性チェックが
可能になる（図６の６０４のシングル・レコード・ライ
ト時刻はゼロにできない）。データ・ストア・デバイス
は条件つき要求を可能にしなければならない。すなわち
要求は、ロックの値（レコードのキーの値）をテストで
き、次の要求操作（データの他のレコードへの書き込み
など）を条件に応じて実行できなければならない。

【００２０】データの２重化では、「共有データ・アク
セス直列化」により、エラーの訂正と復旧が可能にな
る。データの２重化は、「共有データ・アクセス直列
化」のオプションであり、データ・アクセスの直列化を
実現するためには必要ではない。データの２重化を行わ
ないようにした場合は、「共有データ・アクセス直列
化」の多くのエラー復旧機能が失われ、システムの可用
性が脅かされる。

【００２１】「共有データ・アクセス直列化」では、２
重化を実現するためにプライマリ（図１の１０３）と代
替（１０４）の２つのデータ・ストアが用いられる。プ
ライマリ／代替データ・ストアは、データ・ストアを最
初に使用するシステムの初期化時に同期がとられる。同
期化により、プライマリ・データ・ストア上のすべての
データが代替データ・ストアにコピーされる。プライマ
リ・データ・ストアにおいて訂正不可能なエラーが発生
した場合には、代替データ・ストアはここで、プライマ
リとして使用できる。通常処理の間、プライマリ・デー
タ・ストアに書き込まれたデータは代替データ・ストア
にも書き込まれる。これにより代替データ・ストアは、
プライマリのための信頼できる代替手段、バックアップ
となる。

【００２２】代替データ・ストアは、「共有データ・ア
クセス直列化」が最初に初期化されるかまたはその後に
初期化されたときに、「共有データ・アクセス直列化」
に使用できる。代替データ・ストアを使用できるように
しても、リソースを直列化するユーザ要求の通常の処理
には不都合が生じない。すなわちユーザ要求は、「共有
データ・アクセス直列化」によって代替データ・ストア
とプライマリ・データ・ストアの同期がとられていると
きに、大きな遅れなく処理される。

【００２３】代替データ・ストアは、プライマリ側で生
じたエラーの訂正と復旧の両方を実現するために用いら
れる。この復旧は、ローカル・レベルかグローバル・レ
ベルで行われる。

【００２４】グローバルなエラー復旧は、訂正できない
エラーがプライマリ・データ・ストアにおいて発生した
場合に必要である。訂正できないエラーには、データ・
ストア全体がアクセスできないエラー（データ・ストア
へのパスがすべて失われるなど）、レコードまたは１組
のレコードのローカル復旧が失敗したときのエラー（ス
トレージ媒体に欠陥がある − バッド・データ・レコ
ード − ときに発生し得る）などがある。グローバル
復旧では、障害のあったプライマリ・データ・ストアを
共有するすべてのシステムがその使用を停止する必要が
ある。これらのシステムはそこでプライマリの使用を止
めてデータ要求を満たし、機能的に完全な代替データ・
ストアを使用し始める。別のデータ・ストアを代替とし
て活動化し、この新しい代替ストアとプライマリとの同
期をとるための手段も提供される。

【００２５】エラーのローカル復旧は、エラーがプライ
マリ・データ・ストアの特定のレコードまたは１組のレ
コードに限定されるとみなされるときに試みられる。た
とえば、あるレコードが正常に読み出されているが（す
なわちデータ・ストアからプロセサへのデータ転送が正
常に終了）、サフィクス・レコードは、ユーザ・データ
が論理的に矛盾していることを示している場合、これ
は、データ・ストアを共有する別のシステムに、データ
・ストアへのデータ転送の間に障害が発生し、完全な矛
盾のないレコードを転送しなかった場合に発生する。こ
のケースのサフィクス・レコードは期待値を格納せず、
したがってデータが無効である可能性のあることを示
す。ローカル障害のもう１つのケースは、マルチ・レコ
ード・ライトが起動されても、あるシステムによって終
了しない場合である（マルチ・レコード・ライトは、ユ
ーザ・データが２つ以上の物理レコードにまたがるとき
に必要である）。このケースでは、論理レコードを成す
各物理レコードは完全である。これらのどの物理レコー
ドのサフィクス・レコードも、物理レコードは有効であ
ることを示す。しかし物理レコードの組は一貫性がな
い。これは、サフィクス・レコードに格納されたマルチ
ライト時刻値のいくつかが、チェック・レコードに格納
されたマルチライト時刻値と一致しないという事実によ
って検出される。（図４の４０３と図６の６０３を参
照。）

【００２６】上記のローカル問題は通常は、バッド・デ
ータ・ストア情報を引き起こした問題のあったシステム
によって検出され、そのシステムが復旧を試みることに
注意されたい。サフィクス・レコードとチェック・レコ
ードでは、どのシステムもエラーを検出して復旧を試み
ることができる。これは重要な属性である。エラーの発
生元となったシステムには、エラーを訂正できず、おそ
らくはデータ・ストアを共有する他のシステムにエラー
をレポートできないという問題が発生し得るからであ
る。サフィクス／チェック・レコードの処理がなけれ
ば、データ・ストア上のユーザ・データは信頼性がなく
なる。

【００２７】「共有データ・アクセス直列化」は、リソ
ースへのアクセスを可能にするサービス（ＲＥＡＤ、Ｒ
ＥＡＤ ＳＥＲＩＡＬＩＺＥＤ、ＷＲＩＴＥ ＳＥＲＩ
ＡＬＩＺＥＤ、及びＵＮＬＯＣＫ）をユーザに提供す
る。

【００２８】ＲＥＡＤは、名前つきリソースへの非直列
化アクセスである。これは、他のシステムからの同じリ
ソースへのアクセスを防げない。ＲＥＡＤサービスは、
リソースのロック状態を変えることもなければ、リソー
スのロック状態を調べることもない。したがってＲＥＡ
Ｄは、現在他のシステムによってロックされているリソ
ースに対して発行でき、他のシステムによるリソースの
アンロック前に終了する。

【００２９】ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤは、制御
された名前つきリソース・アクセスであり、リソースの
更新意図を含む。リソースは変更できるので、直列化は
データをアクセスする前に実現しなければならない。リ
ソースのロック（図４の４０１及び図５）を最初に取得
しなければならない。リソースは、ロックが取得される
までは読み出すことができない。すなわち当該システム
は、リソースに関連するデータを読み出す前にロックを
所有し（したがってリソースを所有し）なければならな
い。

【００３０】ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤは、制
御された名前つきリソース更新である。リソースは、先
行するＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求によってア
クセスされていなければならない。リソースは、先行す
るＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求によって取得さ
れたロックがまだ当該システムによって保持されている
場合にのみ更新される。データが正常に書き込まれる
と、当該システムのロックが解除される。リソースのロ
ックは当該システムに開放される。他に待機中のシステ
ムがある場合は、次にロックを待っているシステムに、
自身がリソースの所有者になったことが通知される。ロ
ックが保持されなくなると、ＷＲＩＴＥＳＥＲＩＡＬＩ
ＺＥＤ要求は失敗し、要求側にはこのアクションが通知
される。リソースは、ロックが保持されなくなったとき
には更新されない。

【００３１】ＵＮＬＯＣＫは、ＲＥＡＤ ＳＥＲＩＡＬ
ＩＺＥＤを通して当該システムによって名前つきリソー
スについて取得されたロックを、ユーザ・データの内容
を変えずに解除する手段である。「共有データ・アクセ
ス直列化」によって維持されたリソースのユーザ・デー
タ部は変更されない。リソースは、当該システムに対し
て開放またはアンロックされる。待機中のシステムが他
にある場合は、ロックを待っている次のシステムに、自
身がリソースの所有者になったことが通知される。

【００３２】システムがユーザ・データをロックできる
ということは、２つ以上のシステム間でデータを共有す
る機能の面から非常に重要な機能である。「共有データ
・アクセス直列化」は、この機能を低レベルの粒度で提
供する。しかし、オペレータの介入なくデータの連続使
用を可能にするためには、ユーザ・データがアクセス不
能とならないように何らかの手段を設ける必要がある。
データがアクセス不能になるのは、機能しなくなったシ
ステムによってデータがロックされていて、ロックを解
除できない場合、あるいはシステムが長い時間遅れ、お
そらくは停止した場合である。

【００３３】「共有データ・アクセス直列化」は、リソ
ースをかなり長く待っているシステムが、そのリソース
の所有権を他のシステムから奪うためのメカニズムを、
データのユーザまたはシステム・オペレータに対してト
ランスペアレントに提供する。これをロック・スティー
リングという。ロック・スティーリングは、ロックに関
係するデータの整合性を損なわないように実現しなけれ
ばならない。ロックが奪われたシステムは、実行を継続
でき、自身がロックを所有しているとみなしてデータを
リソースに書き込めなければならない。すなわちロック
・スティーリングは、機能しなくなったシステムに対す
る場合と同じように、一時停止したシステムに対しても
機能するものでなければならない。また、一時停止した
システムは、ロックが奪われた状態から回復できなけれ
ばならない。

【００３４】ロック・スティールでは、新しい所有者へ
のリソースの割当を可能にしながらリソースのデータ整
合性を保証するために、リソースに関連するアクセス制
御情報を使用する。（図４の４０１Ａ、４０１Ｂなど、
及び図５を参照。）新しい所有者はまた、アクセス制御
情報を使うことによって選択される。

【００３５】ロックを奪う機能は、ＲＥＡＤ ＳＥＲＩ
ＡＬＩＺＥＤとＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤの操
作によるアクセス制御情報の使用に依存する。（各操作
の詳細については以下の該当する節を参照されたい。）
ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ操作は、リソースに関
連するロック・ブロックに情報を記録し、リソース・デ
ータを読み出す前にリソースの所有権を得る。データは
データ・ストアから読み込まれ、ユーザに提示される。
ユーザはデータを更新し、ＷＲＩＴＥ ＳＥＲＩＡＬＩ
ＺＥＤを起動してデータの書き込みを要求する。ＷＲＩ
ＴＥ ＳＥＲＩＡＬＩＺＥＤは次に、データをデータ・
ストアに書き込み、対応するＲＥＡＤＳＥＲＩＡＬＩＺ
ＥＤ操作によってセットされたものと同じ値がロックに
含まれるようにする。ロックに正しい情報が含まれてい
ない場合、更新試行は失敗する。ロック・スティールは
ロックの内容を変えるので、ロック・スティールが発生
したときは、ロックに正しい情報は含まれていない。

【００３６】ユーザ要求処理

【００３７】ＲＥＡＤ操作 ＲＥＡＤ操作（図７及び以下で詳述）では、ユーザが、
データ・ストアに格納されたリソースをアクセスでき
る。ここでユーザは、ＲＥＡＤ操作を使い、読み出され
た情報を更新する意図のないこと、したがって他のシス
テムによるデータのアクセスを防げる理由のないことを
指示している。

【００３８】従来の「共有データ・アクセス直列化」
は、リード要求からのリソース名または識別子と、デー
タ・ストアからのグローバル制御情報（３０２）を使
い、データ・ストア内の特定のリソースを検出し、リソ
ースの属性（レコードのフォーマットやサイズなど）を
判定する。

【００３９】データ・ストアは、ＲＥＡＤ処理の各段階
で参照される。ＲＥＡＤは、データ・ストアをアクセス
している間に、データ・ストア上でエラー復旧を開始し
なければならない場合がある。ＲＥＡＤ操作は、データ
・ストア上のロック・ブロック情報をアクセスする問題
あるいはリソース・データを参照する問題にぶつかるこ
とがある。リソース・データの復旧についてはＲＥＡＤ
ＳＥＲＩＡＬＩＺＥＤの節の説明とその終わりの部分
を参照されたい。

【００４０】ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ操作 ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ操作（詳しくは図１０
と下記の説明を参照）とＷＲＩＴＥ ＳＥＲＩＡＬＩＺ
ＥＤサービス（ここで概要を述べる）では、ユーザが、
直列化を制御した形で共有リソースをアクセスし更新で
きる。ユーザは、データ・ストア上の共有リソースを更
新するためには、最初にリソースをロックし、リソース
をデータ・ストアから読み込む必要がある。これは特定
の名前のリソースに対するＲＥＡＤ ＳＥＲＩＡＬＩＺ
ＥＤ要求を「共有データ・アクセス直列化」に要求する
ことによって行われる。「共有データ・アクセス直列
化」がＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求を完了する
と、リソースはロックされ、データ・ストアの他のユー
ザはこのリソースの更新と、データ・ストアからの読み
込みができなくなる。当該ユーザはこのリソースを処理
のために使用できる。

【００４１】ユーザがリソースの処理を終えると、リソ
ースに加えられた変更は、「共有データ・アクセス直列
化」がリソースを更新するようにＷＲＩＴＥ ＳＥＲＩ
ＡＬＩＺＥＤ要求を通して要求することによって、デー
タ・ストアにコミットすることができる。ＷＲＩＴＥ
ＳＥＲＩＡＬＩＺＥＤサービスの詳細については次の節
を参照されたい。

【００４２】リソースが処理されたとき、ユーザは、デ
ータ・ストア上のリソースに変更を加えないことを決定
できる。ユーザは、「共有データ・アクセス直列化」の
ＵＮＬＯＣＫサービスを起動して、データ・ストアに対
する変更をコミットすることなく、リソースの直列化を
解除することができる。以下の節でＵＬＯＣＫサービス
の詳細に触れる。

【００４３】従来の「共有データ・アクセス直列化」
は、ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求からのリソー
ス名または識別子と、データ・ストアからのグローバル
制御情報３０２を使用してデータ・ストアのなかの特定
のリソースを検出し、リソースの属性（レコードのフォ
ーマットやサイズなど）を判定する。

【００４４】リードは直列化されるので、リソース・ロ
ック（図４の４０１Ａ、４０１Ｂなど）はデータをアク
セスする前に取得しなければならない。ロックの取得は
マルチステップ操作である。リソースを取得する最初の
ステップは、当該システムのロック・キーを生成し、こ
のロック・キーをリソースのアクセス制御情報のなかの
該当するロック・ブロックに記録する。当該システムが
使用するのに適したロック・ブロックは、システムの初
期化時に決定されたロック・ブロックである。各システ
ムは、リソースに関連するロック・ブロック（４０１
Ａ、４０１Ｂなど）のうち１つを所有する。所有権は、
データ・ストアのグローバル制御情報に格納された情報
から決定される。あるリソースの１組のロック・ブロッ
クなかの同じロック・ブロック（たとえば４０１Ｃ）
は、どのリソースについても、あるシステムによって所
有される。

【００４５】ロック・キーは、システム・シーケンス・
ナンバと時刻値から成る（図５の５０１参照）。システ
ム・シーケンス・ナンバはシステムの初期化時に取得さ
れ、データ・ストアを共有する各システムに対して一意
である。データ・ストアに格納されるグローバル制御情
報は、システムの初期化によってインクリメントされ、
次の一意のシステム・シーケンス・ナンバが生成され
る。システムは、その処理の間中、同じシーケンス・シ
ーケンス・ナンバを使う（図３の３０２参照）。時刻値
は、プロセサから取得された時間である。新しい時間値
は、ロック・キーが「共有データ・アクセス直列化」に
よってあるユーザのために取得されるごとに取得され
る。

【００４６】キーが生成されると、データ・ストアのな
かの該当するロック・ブロックに書き込まれる。これが
ロックを取得する第１ステップで、ロック・ブロックの
この組に関連するリソースを使用する当該システムの意
図がデータ・ストアに記録される。

【００４７】実行された「共有データ・アクセス」は、
これまでのところはリソースを使用する意図を示す。当
該システムはここで、だれがリソースの所有者かを判定
する必要がある。これをロック・ルール処理という。所
有権を判定するロック・ルールは３つある。リソースに
関連するロック・ブロックはすべてデータ・ストアから
読み出される。第１のロック・ルールでは、あるシステ
ムは、そのシステムのロック・ブロックを除くすべての
ロック・ブロックがゼロならばリソースの所有者であ
る。他のシステムはこのリソースに関心がない。

【００４８】第２のロック・ルールでは、あるシステム
は、そのシステムのロック・ブロック以外の少なくとも
１つのロック・ブロックがゼロでなく（他の少なくとも
１つのシステムはリソースに関心がある）、ゼロ以外の
すべてのロック・ブロックの時刻値が、当該システムの
時刻値よりも古い場合は、明らかに所有者ではない。当
該システムはリソースの使用を待つ必要がある。ロック
所有権は、別のシステムがそのロック・ブロックのロッ
ク・キーをゼロにリセットして、どのシステムが次にリ
ソースを使用するかを判定したときに、別のシステムに
よって当該システムに引き渡される。すなわち当該シス
テムは、時刻値の古いすべてのシステムが各々順に処理
を終えるまで待っていなければならない。

【００４９】第３のロック・ルールは、他の少なくとも
１つのシステムの時刻値が第１のシステムの時刻値より
も新しいケースを扱う。この状態は、時刻スタンプを取
得することと、リソースに対する関心を記録することが
アトミックではないために生じる。すなわち２つの要求
がインタリーブされることがある。システムＡが時刻ス
タンプを得、続いてシステムＢが時刻スタンプを得て、
その時刻スタンプをデータ・ストアに記録する。後にシ
ステムＡがその時刻スタンプを記録し、システムＢの新
しい時刻スタンプを検出する。

【００５０】このケースでは所有権の状態は不定であ
る。これを解決するため、第１のシステムが新しい時刻
値を生成し、この新しい時刻値を使って更新されたロッ
ク・キーをつくり、そのロック・ブロックをこの更新さ
れたロック・キーで書き込む。ロック・ブロックの更新
が完了すると、第１システムは、すべてのシステムのロ
ック・ブロックを読み出し、時刻値が最も古いシステム
を検出する。時刻値が最も古いシステムには、自身が所
有者であることが通知される。それが所有者であること
を、自身がすでに知っているときにシステムに通知する
ことは許容される。第１システムはそこで、所有者にな
ったという通知を待つ。

【００５１】システムが、それが所有者であることを判
定する（ロック・ルール１）か、またはそれが所有者で
あることを別のシステムから通知される（ロック・ルー
ル２または３）と、当該システムは、データ・ストアか
らユーザ・データを読み出して、ユーザ要求を満たすこ
とができる。ユーザにはデータが使用できることが通知
される。

【００５２】先に述べたとおり、データ・ストアは、Ｒ
ＥＡＤ ＳＥＲＩＡＬＩＺＥＤ処理の各段階で参照され
る。データ・ストアをアクセスしているとき、ＲＥＡＤ
ＳＥＲＩＡＬＩＺＥＤは、データ・ストア上でエラー
復旧を開始する必要があるかもしれない。行われるエラ
ー復旧は、データ・ストアのどの部分に障害があったか
によって決まる。ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ操作
は、データ・ストア上のロック・ブロック情報をアクセ
スする問題、またはリソース・データを参照する問題に
ぶつかることがある。

【００５３】ロック・ブロックに障害があると（ロック
・ブロックのライトやリードを試してみた結果が永続的
なリード／ライト・エラーあればそう判定される）、ロ
ック・ブロックのリフォーマットが試みられる。リフォ
ーマットは物理的に、データ・ストア上の当該ロック・
ブロック情報を含むトラックを再生成する。通常のライ
ト操作の代わりにフォーマット・ライトが用いられる。
ロック・ブロックはリソースへのアクセスを制御するの
で、ロック・ブロックの修復は、ロック・ブロックに障
害のあったリソースへのアクセスを一時停止するように
行う必要がある。修復の結果、すべての制御情報が失わ
れるので、現在のリソース所有者は所有権を失う。待機
側は列のなかのその位置を失う。所有者とすべての待機
側は所有権の再取得を試みる必要がある。実際に、ロッ
ク・ブロックの修復は、当該リソースに関心のあるすべ
てのシステムからのロックのマス・スティールになる。
ロック・ブロックの修復は事実上のスティール操作であ
るので、ロック・ブロックは、どのデータ・ストアで障
害が検出されたかどうかにかかわらず、代替とプライマ
リの両方のデータ・ストアでリフォーマットされる。こ
れは、リソースの使用を安全に停止するために必要であ
る。（スティール処理については図１８を、ロック・ブ
ロック処理と修復については図１１、１２、１３を参照
のこと。）

【００５４】プライマリ・データ・ストアからリソース
のデータを読み出すときにエラーが発生すると、代替デ
ータ・ストアからデータが読み出されようとする。代替
データ・ストアは、プライマリ・データ・ストアの２重
化イメージを含む。発生したエラーは、プライマリ・デ
ータ・ストアからデータを読み出そうとする永続的なエ
ラーであるか、またはサフィクス・レコードかチェック
・レコードに格納された情報が、物理レコードが不完全
であるかあるいは、いくつかの物理レコードのうちの１
つが、リソースを成す他の物理レコードと論理的に矛盾
することを示すかのいずれかである。ＲＥＡＤ ＤＡＴ
Ａ操作について試みられる復旧については図８Ａを参照
されたい。

【００５５】ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ操作 ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ操作（図１５と下記
の説明で詳述）では、ユーザは、データ・ストアに格納
されたリソースを制御性を保って更新できる。ユーザ
は、ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ操作を通してデー
タを読み出し、データを更新してからＷＲＩＴＥ ＳＥ
ＲＩＡＬＩＺＥＤ操作を起動して、変更されたデータを
データ・ストアにコピーバックする必要がある。「共有
データ・アクセス直列化」は更新されたデータをプライ
マリと代替の両方のデータ・ストアに書き込む。

【００５６】「共有データ・アクセス直列化」は、特定
のタイプのエラーを処理するために、各リソースのデー
タ・シーケンス・ナンバを維持する。データ・シーケン
ス・ナンバは、与えられたシステムについてデータのレ
ベルを反映する。システムがデータをデータ・ストアに
書き込むたびに新しいデータ・シーケンス・ナンバが生
成される。データ・シーケンス・ナンバはチェック・レ
コードに維持される。（図４の４０３、図６の６０２
Ａ、６０２Ｂなどを参照のこと。）データ・ストアを共
有する各システムに１つのデータ・シーケンス・ナンバ
がある。各システムは、そのデータ・シーケンス・ナン
バを使って、エラー復旧操作の間のデータ更新の結果を
判定する。

【００５７】システムは、復旧に備えて、（ＲＥＡＤ
ＳＥＲＩＡＬＩＺＥＤ操作によって読み込まれる）チェ
ック・レコードのローカル・コピーのそのデータ・シー
ケンス・ナンバをインクリメントする。

【００５８】新しいデータ・シーケンス・ナンバが生成
されると、プライマリ・データ・ストアを更新すること
ができる。ＵＰＤＡＴＥ操作は、次のアクション・シー
ケンスから成る。これらのアクションは、データ・スト
アに対する１つのアトミック操作を通して実行しなけれ
ばならない。第１に、システムのロック・ブロックがチ
ェックされ、リソースがまだ当該システムによって所有
されているかどうかが判定される。ロック・ブロックに
は、ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求によって書き
込まれたものと同じゼロでない値が格納されていなけれ
ばならない。ロック・ブロック値の状態の変化は、別の
システムがシステムからロックを、したがってリソース
を奪ったことを示す。ロックが奪われると、当該操作の
データ更新の部分が実行されない。ＷＲＩＴＥ ＳＥＲ
ＩＡＬＩＺＥＤ操作は終了し、ユーザには、そのＵＰＤ
ＡＴＥ操作が、ロックが奪われたために失敗したことが
通知される。ユーザは、ＲＥＡＤ ＳＥＲＩＡＬＩＺＥ
Ｄ操作から操作をリドゥできる。第２に、ロックがまだ
保持されているとすると、ユーザ・データ・レコード
が、対応するサフィクス・レコードとともにデータ・ス
トアに書き込まれる。そして最後に、チェック・レコー
ドが書き込まれる。チェック・レコードは、他のものの
なかで特に、当該システムの更新されたデータ・シーケ
ンス・ナンバを含む（他のシステムのデータ・シーケン
ス・ナンバは不変）。

【００５９】プライマリ・データ・ストアが更新されれ
ば代替データ・ストアを更新できる。代替データ・スト
アの更新は、次のアクション・シーケンスから成り、す
べてデータ・ストアに対する１回のアトミック操作で実
行される。第１に、当該システムのロック・ブロックが
チェックされ、リソースがまだ当該システムによって所
有されているかどうかが判定される。ロック・ブロック
はすべてゼロでなければならない（代替データ・ストア
上のロック・ブロックの通常状態）。ロック・ブロック
の非ゼロ値は、別のシステムが当該システムからロック
を、したがってリソースを奪ったことを示す。ロックが
奪われると当該操作のデータ更新の部分が実行されな
い。第２に、ロックがまだ保持されているとすると、ユ
ーザ・データ・レコードが、対応するサフィクス・レコ
ードとともに代替データ・ストアに書き込まれる。そし
て最後にチェック・レコードが書き込まれる。

【００６０】プライマリ・データ・ストアに障害が発生
してこれが除外され、代替データ・ストアがプライマリ
・データ・ストアになったときに、当該プロセスが代替
データ・ストア上（その時点ではプライマリ・データ・
ストア）のデータを更新しようとしている場合、ＷＲＩ
ＴＥ ＳＥＲＩＡＬＩＺＥＤ操作は終了する。ＷＲＩＴ
Ｅ ＳＥＲＩＡＬＩＺＥＤ操作のユーザにレポートされ
る内容は、代替データ・ストアの更新の完了状態によっ
て決まる。このＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ操作
がプライマリ・データ・ストアの障害のために中断され
たときに、代替操作が開始されなかった場合、新しいプ
ライマリ・データ・ストア（前身は代替データ・スト
ア）はユーザの変更を反映しない。これは事実上のロッ
ク奪取である。代替データ・ストアのすべてのゼロのロ
ック・ブロックがプライマリになっているからである。
ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤの発行側には、ロッ
クが奪われたことが通知され、発行側は、ＲＥＡＤ Ｓ
ＥＲＩＡＬＩＺＥＤから操作を再開できる（ロックをま
た取得する必要がある）。代替ＷＲＩＴＥ操作が、代替
データ・ストアがプライマリ・データ・ストアになる前
に正常に終了した場合、ユーザの変更はプライマリ・デ
ータ・ストアに反映される。ユーザには、ＷＲＩＴＥ
ＳＥＲＩＡＬＩＺＥＤ操作が成功したことが通知され
る。リソースをアンロックする必要はない。ロック・ブ
ロックがゼロのプライマリは事実上ロックされていない
リソースだからである。

【００６１】代替データ・ストアへのＷＲＩＴＥが成功
するか、または代替データ・ストアに完全な障害が発生
し、使用できないようになった場合（「共有データ・ア
クセス直列化」は代替データ・ストアなく継続でき
る）、あるいは代替データ・ストアが使用されていない
場合（代替データ・ストアはオプション）、ユーザ・デ
ータの更新は正常に処理されている。ＷＲＩＴＥ ＳＥ
ＲＩＡＬＩＺＥＤ操作は、当該システムのリソースのロ
ックを解除することによって完了する。これは、当該シ
ステムのリソースをアンロックし、ＷＲＩＴＥ ＳＥＲ
ＩＡＬＩＺＥＤ操作の成功をユーザに知らせるアンロッ
ク操作を起動することによって行われる。

【００６２】代替データ・ストアへのＷＲＩＴＥが、ロ
ック・チェックのために成功しなかった場合（代替デー
タ・ストア上のロックがゼロでなかった場合）、ロック
は当該システムから奪われている。ロックは、当該シス
テム上のこのＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ操作か
ら奪われたか、それとも前のＷＲＩＴＥ ＳＥＲＩＡＬ
ＩＺＥＤ操作から奪われたかどうかを判定する必要があ
る。

【００６３】スティール処理（ロックを所有するシステ
ム以外の他のシステム上で実行される）により、１つの
システムによるロックの保持が長すぎることが判定さ
れ、プライマリと代替の両方のデータ・ストア上の当該
システムのロック・ブロックの内容を変えることによっ
てそのシステムからリソース所有権が奪われる。代替デ
ータ・ストア上のロック・ブロックの内容が最初に変更
され、続いてプライマリ・データ・ストア上のロック・
ブロックの内容または値が変更される。具体的には、代
替データ・ストアのロック・ブロック値がゼロから、プ
ライマリ・データ・ストアのロック・ブロックのなかの
スティールによって検出された値（ＲＥＡＤ ＳＥＲＩ
ＡＬＩＺＥＤによって生成されたシステム・シーケンス
・ナンバと時刻値）に変更される。プライマリ・データ
・ストアのロック・ブロック値はゼロにセットされる。
ロックが奪われたシステムは、スティールによってだれ
からロックを奪うかが判定された時間と実際にロックが
奪われた時間との間にその操作を完了させることも可能
である。これはロック・スティールにとってもターゲッ
ト・システムにとっても問題ない。ただし、ターゲット
・システムからリソースに対する次の操作は、スティー
ルがその操作を対象としたものか前の要求を対象にした
ものかを判定しなければならない。

【００６４】ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤは、ス
ティールがこの操作を対象にしたものか前の操作を対象
にしたものかを判定しなければならない。これを行うた
めには、ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤは、その代
替ロック・ブロックのなかの値を調べなければならな
い。ロックの値（ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤによ
ってプライマリ・データ・ストアのロック・ブロックに
置かれたもののコピー）が、ＲＥＡＤ ＳＥＲＩＡＬＩ
ＺＥＤが書き込んだものと一致しない場合は、ロック・
スティールは前の要求に向けられたものである。ＷＲＩ
ＴＥ ＳＥＲＩＡＬＩＺＥＤは、上述のようにデータの
書き込みをまた試みる。このときは通常のゼロ値ではな
くこの新しい値の代替ロックをチェックする。そのとき
書き込みが成功すれば、後の余分な繰り返し処理を避け
るために、代替データ・ストア上のロック・ブロックは
すべてゼロにリセットされる。

【００６５】代替データ・ストア上のロック・ブロック
の値が一致しない場合、現在のＷＲＩＴＥ ＳＥＲＩＡ
ＬＩＺＥＤ操作のロックは当該システムから奪われてい
る。当該システム上のＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥ
Ｄサービスの呼び出し側は、プライマリの変更はコミッ
トしているが、代替データ・ストアの変更はコミットし
ていない。しかし変更が２重化されなかったことも考え
られる。変更が２重化されたかどうかが確認されるまで
は、ユーザに対して、ユーザの操作が完了したことを通
知できない。スティーリング・システムが２重化を実行
すると仮定することはできない。スティーリング・シス
テムが、このシステムの変更の２重化を保証するＲＥＡ
Ｄ ＳＥＲＩＡＬＩＺＥＤ、ＵＰＤＡＴＥ、及びＷＲＩ
ＴＥ ＳＥＲＩＡＬＩＺＥＤのプロセスを完了していな
いことが考えられるからである。そこで「共有データ・
アクセス直列化」は、ロックを奪ったシステムに依存す
ることなく２重化を保証する。ＷＲＩＴＥ ＳＥＲＩＡ
ＬＩＺＥＤはそのために、内部でＲＥＡＤ ＳＥＲＩＡ
ＬＩＺＥＤを起動する。これによりロックが通常の方法
で再取得されデータが再び読み出される。データは、他
のシステム上のアクティビティによって、当該操作が開
始されてから数回変更された可能性もあり変更されなか
った可能性もあることに注意されたい。ここでの唯一の
目標は、現在存在するどのレベルでも２重化されるよう
にすることにある。ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤが
完了すると、プライマリと代替の両方のデータ・ストア
に対して再びＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤが試み
られる。

【００６６】先に述べたとおり、データ・ストアはＷＲ
ＩＴＥ ＳＥＲＩＡＬＩＺＥＤ処理の各段階で参照され
る。ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤは、データ・ス
トアをアクセスするときに、データ・ストア上でエラー
復旧を開始しなければならないかもしれない。どのよう
なエラー復旧が行われるかは、データ・ストアのどの部
分に障害があったかによって決まる。ＷＲＩＴＥ ＳＥ
ＲＩＡＬＩＺＥＤ操作では、データ・ストア上のロック
・ブロック情報のアクセス問題またはリソース・データ
の参照問題が生じることがある。

【００６７】ロック・ブロックの復旧についてはＲＥＡ
Ｄ ＳＥＲＩＡＬＩＺＥＤの節の説明とその終わりの部
分を参照されたい。

【００６８】リソースのデータをプライマリまたは代替
データ・ストアへ書き込むときにエラーが発生すると、
障害のあったデータ・ストアのデータが再生されようと
する。リフォーマット（再生）は、データ・ストア上の
当該リソースのデータを含むトラックを物理的に再構成
する。通常のＷＲＩＴＥ操作の代わりにフォーマット・
ライトが用いられる。ＷＲＩＴＥ ＤＡＴＡと修復処理
については図１６を参照されたい。

【００６９】ＵＮＬＯＣＫ操作 ＵＮＬＯＣＫ操作（詳細は図１７及び下記の説明を参
照）では、ユーザは、データ・ストア上のデータを更新
することなく、前のＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要
求を取り消すことができる。この操作は、ＷＲＩＴＥ
ＳＥＲＩＡＬＩＺＥＤ操作がその処理を完了するために
も用いられる。

【００７０】ＵＮＬＯＣＫは、リソースのアクセス制御
情報を変えて、当該システムがリソースに関心のあるこ
との指示をこの情報から取り除く。（詳細は下記参
照。）次に、アクセス制御情報を調べて、他のどのシス
テムが（もしあれば）、リソースを次に所有すべきかを
判定する。次の所有者が見つかると、ＵＮＬＯＣＫは、
そのシステムに自身が所有者になったことを通知する。

【００７１】データ・ストアは、ＵＮＬＯＣＫ処理の各
段階で参照される。ＵＮＬＯＣＫは、データ・ストアを
アクセスしているときに、データ・ストア上でエラー処
理を開始する必要があるかもしれない。ＵＮＬＯＣＫ操
作は、データ・ストア上のロック・ブロックをアクセス
する問題にぶつかることがある。ロック・ブロックの復
旧についてはＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤの説明と
その終わりの部分を参照されたい。

【００７２】ＲＥＡＤ 図７の７０１では、データ・ストアが存在するかどうか
が調べられる。（すなわちプライマリ・データ・ストア
が存在するかどうか − これは図２５のプライマリ・
ストア・ディスクリプタ２５０１の“機能”インディケ
ータ２５０２で示される。）７０１の判定が、プライマ
リが存在しないことを示した場合は、呼び出す側に処理
が戻る。判定が、プライマリが存在することを示した場
合は、ＲＥＡＤ ＤＡＴＡルーチンが起動され（７０
２）、プライマリまたは代替データ・ストアからリソー
スが読み出される。ＲＥＡＤ ＤＡＴＡは図８Ａ、図８
Ｂに示した。ＲＥＡＤ ＤＡＴＡから処理が戻ると、プ
ライマリ・データ・ストアに訂正できない障害があるか
どうかが判定される（７０３）。あった場合、７０１の
判定が再び上述のように実行される。データがプライマ
リまたは代替データ・ストアから正常に読み出されてい
れば、処理は呼び出し側に戻る。

【００７３】ＲＥＡＤ ＤＡＴＡ 図８Ａ、図８ＢにＲＥＡＤ ＤＡＴＡ処理の制御の流れ
を示す。８０１で、プライマリ・データ・ストアからリ
ソースを読み出すためにチャネル・プログラムが生成さ
れる。次に８０２でチャネル・プログラムが起動されそ
の完了が待たれる。８０３では、チャネル・プログラム
によってデータが正常に読み出されたかどうかが判定さ
れる。そのとおりであれば、８０４でサフィクス・レコ
ードとチェック・レコードを調べることによってデータ
の信頼性が判定される。この一貫性チェックは、各サフ
ィクス・レコード及びチェック・レコード内のマルチ・
レコード・ライト時刻値（図６の６０３）が、他のすべ
てのサフィクス・レコード及びチェック・レコードと等
しいかどうか、また、各サフィクス・レコード及びチェ
ック・レコードのシングル・レコード・ライト時刻値
（図６の６０４）が、「共有データ・アクセス直列化」
のグローバル制御情報内の時刻値（図３の３０２Ａ）と
等しいかどうかを検査することによって行われる。次に
（８０５）、データが実際に信頼できるものであったか
どうかが判定される。信頼できるものであった場合、処
理は呼び出し側に戻る。信頼できるものでなかった場
合、処理は図８の８０７に示したように継続する。８０
３の判定が、データがプライマリ・データ・ストアから
正常に読み出されなかったことを示す場合は、８０６に
おいてエラーが訂正可能な永続的エラーかどうかが判定
される。エラーが訂正可能とみなせるかどうかは、デー
タ・ストア全体がアクセス可能とみなせるかどうか、ま
たは単に１つのレコードがエラーとみなせるかどうかを
示す。たとえばチャネル・プログラムのチェックがあっ
たことを示すリターン・コードは、訂正できない永続的
エラーとみなされる。レコード長が正当でないことを示
すリターン・コードは、訂正可能な永続的エラーとみな
される。永続的なエラーが訂正可能とみなされる場合、
永続的エラー処理が起動され（８０８）、使用不可能な
プライマリ・データ・ストアが除外される。この処理は
図９の説明の後に示した。そこで処理は呼び出し側に戻
る。８０７では、同期のとられた代替が存在するかどう
かが判定される。（図２５のインディケータ２５０６で
示される。）８０７の判定が、同期のとられた代替が存
在しないことを示す場合、８０８のように永続的エラー
処理が起動され、呼び出し側に処理が戻る。同期のとら
れた代替が存在する場合、チャネル・プログラムが生成
されて（８０９）、代替データ・ストアからリソースが
読み出され、当該チャネル・プログラムが起動される
（８１０）。そこでチャネル・プログラムの実行完了が
待たれる。

【００７４】８１１ではチャネル・プログラムがデータ
を正常に読み出したかどうかが判定される。そのとおり
であれば、読み出されたばかりのデータが信頼できるも
のかどうかが判定される（８１２）。この判定は８０４
の場合と同様に行われる。次に、データが信頼できるも
のであったかどうかが判定される（８１３）。そのとお
りであれば、処理は呼び出し側に戻る。信頼できるもの
でなかった場合、永続的エラー処理が起動され（８１
４）、使用不可能なプライマリ・ストアが除外され、ま
た起動されて（８１５）、使用不可能な代替データ・ス
トアが除外される。処理はここで呼び出し側に戻る。８
１１の判定が、データが代替データ・ストアから正常に
読み出されなかったことを示す場合、永続的エラー処理
が８１４、８１５のように起動され、呼び出し側に処理
が戻る。

【００７５】永続的エラー処理 図９Ａ、９Ｂは永続的エラー処理の制御の流れを示す。
９０１では、永続的エラーにぶつかったシステムのＩＤ
がローカルにセーブされる。次に（９０２）、システム
上の直列化された要求が、直列化要求を処理するタスク
を停止させることによって停止される。次に９０３にお
いて、障害が代替データ・ストアの障害だったかどうか
が判定される。そのとおりであれば９０４において代替
に障害が発生したことの指示がセットされて（２５１
０）オペレータに通知され、代替は、機能インディケー
タ（図２５の２５０５）をオフにすることによって除外
され使用できなくなる。次に、９０５において障害がプ
ライマリの障害だったかどうかが判定される。（この判
定は、代替データ・ストアの障害がなかった場合はステ
ップ９０３の直後に行われる。）プライマリに障害があ
った場合、９０６においてオペレータに通知され、プラ
イマリ・データ・ストアに障害のあったことの指示がセ
ットされ、機能インディケータ（図２５の２５０２）を
オフにすることによってプライマリが除外され使用不可
にされる。次に９０７で（プライマリ障害がなかった場
合はステップ９０５）、このエラーが（障害のあったデ
ータ・ストアのデータ・ストア名とボリューム・シリア
ル・ナンバで）他のシステムに（たとえばチャネル間通
信によって）通知される。次に（９０８）、代替データ
・ストアが存在し、プライマリに障害があったかどうか
が判定される。そのとおりなら、代替に障害があったと
いう指示がセットされ（９０９）、機能インディケータ
（図２５の２５０５）をオフにすることによって代替が
除外され使用不可にされる。代替は後に − 代替スト
ア・ディスクリプタの情報（２５０４）をプライマリ
（２５０１）に移すことによって − プライマリとし
て用いられる（９１０）。９０８の判定が、プライマリ
に障害がなかったか、または代替が存在しないことを示
す場合は、９１１で、代替が存在するかどうかが判定さ
れる。存在しない場合システムは終了する（９１２）。
代替が存在する場合（そしてステップ９１０について説
明した処理の後）、９１３において、すべてのシステム
がこのエラーを検出しかどうかが（ローカルにセーブさ
れたシステム識別子をデータ・ストアのグローバル制御
情報３０２のなかの参加しているシステムのリストと比
較することによって）判定される。検出していない場合
は９１４で、エラーを検出していない他のシステムに永
続的エラーが通知され、これらのシステムからの次の信
号が待たれる（９１５）。すべてのシステムがエラーを
検出した場合、当該システムの直列化された要求が（直
列化要求を処理するタスクを再起動することによって）
再起動され（９１６）、ルーチンは終了する。他のシス
テムからの信号が入ったとき、またはタイマが時間切れ
になった結果、当該システムのＩＤがローカル・エリア
９１７にセーブされ、処理は９１３に示したように継続
する。

【００７６】ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求 図１０（１０Ａ〜１０Ｃ）は、ＲＥＡＤ ＳＥＲＩＡＬ
ＩＺＥＤ要求の制御の流れを示す。１００１でデータ・
ストアが存在するかどうかが判定される（２５０１）。
プライマリ・データ・ストアが存在しない場合は要求側
に処理が戻る。プライマリが存在すれば、ロック所有権
の要求ＴＯＤが生成され（１００２）、要求がそのリソ
ースのロック・アンカ（図２５の２５０３）に配置され
る。次に（１００３）、ロック・ブロック・ライト処理
が起動され、要求ＴＯＤがプライマリ・データ・ストア
のなかの当該システムのロック・ブロックに書き込まれ
る。この処理については図１３とあわせて詳述する。ロ
ック・ブロック・ライト処理で書き込まれたロック・ブ
ロックは、当該システムに関連するシステム・シーケン
ス・ナンバと現在のＴＯＤ値を含む。このロック・ブロ
ックは図５の５０１に示した。ロック・ブロック・ライ
ト処理から戻った後、１００４で、プライマリ・データ
・ストアに訂正できない障害があったかどうかが判定さ
れる。なかった場合、ロック・ブロック・リード処理が
起動され、プライマリ・データ・ストアからすべてのロ
ック・ブロックが読み出され、よってリソース所有権が
判定される（１００５）。ロック・ブロック・リード処
理の詳細は図１１に示した。ロック・ブロック・リード
処理から戻ると、１００６において、プライマリ・デー
タ・ストアに訂正できない障害があったかどうかが判定
される。なかった場合、他のすべてのロック・ブロック
がゼロに等しいかどうかが判定される（１００７）。１
００７の答えがＹＥＳであれば、これは、ロック・ルー
ル１により、当該システムがリソースを所有し、処理は
以下に示すように１０１９から継続することを示す。１
００７の判定が、他のすべてのロック・ブロックがゼロ
に等しくないことを示す場合は、リソースのコンテンシ
ョンがある。１００８では他のすべてのＴＯＤが当該Ｔ
ＯＤよりも古いかどうかが判定される。他のすべてのＴ
ＯＤが当該ＴＯＤよりも古い場合、ロック・ルール２に
より、当該システムはリソースの所有者ではない。１０
０９では、リドライブＴＯＤが要求ＴＯＤに等しいかど
うかが判定される。この判定が必要なのは、１００５に
おいてＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求処理でロッ
ク・ブロックが読み出されたときに当該システムが所有
者ではなかった場合でも、ロック所有者信号処理がＲＥ
ＡＤ ＳＥＲＩＡＬＩＺＥＤ要求処理の間に非同期に実
行され、当該システムがそれ以降リソースの所有者にな
る可能性があるからである。したがって、１００９の判
定が、リドライブＴＯＤが当該要求ＴＯＤに等しいこと
を示す場合、ユーザはここでリソースの所有者になり、
処理は以下に示すように１０１９から継続する。リドラ
イブ要求ＴＯＤが当該要求ＴＯＤに等しくない場合、当
該システムはリソースの所有者になっておらず、ルーチ
ンは終了する。この後、ロック所有者信号が必要にな
る。１００８の判定が、他のすべてのＴＯＤが当該ＴＯ
Ｄよりも古くないことを示す場合、ロック・ルール３に
より、リソース所有権は不定であり、ロック所有権の新
しい要求ＴＯＤが生成される（１０１０）。次に、ロッ
ク・ブロック・ライト処理が起動され、新しい要求ＴＯ
Ｄがプライマリ・データ・ストアのなかの当該システム
のロック・ブロックに書き込まれる（１０１１）。ロッ
ク・ブロック・ライト処理については図１３とあわせて
詳述する。ロック・ブロック・ライト処理から戻ると、
１０１２において、プライマリ・データ・ストアに訂正
できない障害があったかどうかが判定される。なかった
場合、ロック・ブロック・リード処理が起動され（１０
１３）、プライマリ・データ・ストアからすべてのロッ
ク・ブロックが読み出されて所有権が判定される（図１
１参照）。ロック・ブロック・リード処理から戻ると、
プライマリ・データ・ストアに訂正できないエラーがあ
ったかどうかが判定される。なかった場合、１０１５に
おいて、１００９で説明したのと同じ理由から、リドラ
イブＴＯＤが要求ＴＯＤに等しいかどうかが判定され
る。これらの値が等しければ、当該システムはリソース
の所有者になっており、処理は以下に説明するとおり１
０１９から継続する。これらの値が等しくなければ、ロ
ック所有者信号がＴＯＤの最も古いシステムに送られる
（１０１６）。ルーチンはここで終了し、ロック所有者
信号を待つ。

【００７７】１０１９では、リード・データ処理が起動
され、データ・ストアからリソースが読み出される。
（リード・データ処理は図８に示した。）リード・デー
タ処理から戻ると、１０２０において、プライマリ・デ
ータ・ストアに訂正できない障害があったかどうかが判
定される。なかった場合は処理は要求呼び出し側に戻
る。ロック所有者信号処理（図１４ − 以下で詳述）
では、ロック所有者信号が受信され、当該システムでこ
の信号が有効かどうかが判定されるときに、ＲＥＡＤ
ＳＥＲＩＡＬＩＺＥＤ処理がブロック１０１７で起動さ
れる。１０１７では、データ・ストアが存在するかどう
かが判定される。存在しない場合、処理は要求呼び出し
側に戻る。プライマリ・データ・ストアが存在しない場
合、１０１８において、プライマリ・データ・ストアに
訂正できない障害が発生したかどうかが判定される。発
生しなかった場合、処理は先に示したようにブロック１
０１９から継続する。

【００７８】上記の判定（１００４、１００６、１０１
２、１０１４、１０１８、１０２０）のいずれかが、プ
ライマリ・データ・ストアに訂正できない障害のあるこ
とを示した場合、上述のように１００１においてＲＥＡ
Ｄ ＳＥＲＩＡＬＩＺＥＤ処理が再起動される。

【００７９】ロック・ブロック・リード 図１１はロック・ブロック・リード処理の制御の流れを
示す。１１０１ではチャネル・プログラムが生成され
て、プライマリまたは代替のデータ・ストアからロック
・ブロックが読み出される。１１０２ではチャネル・プ
ログラムが起動されてその終了が待たれる。次に、ロッ
ク・ブロックが正常に読み出されたかどうかが判定され
る（１１０３）。正常なら処理は呼び出し側に戻る。正
常でなければ１１０４において、訂正可能な永続的エラ
ーが発生したかどうかが判定される。発生していなけれ
ば、永続的エラー処理が起動され（１１０５）、使用で
きないプライマリまたは代替データ・ストアが除外され
る。永続的エラー処理は図９に示した。処理は呼び出し
側に戻る。訂正可能な永続的エラーがあれば、ロック・
ブロック修復処理が起動され（１１０６）、ロック・ブ
ロックが修復される。ロック・ブロック修復処理は図１
２に示した。処理は呼び出し側に戻る。

【００８０】ロック・ブロック修復処理 図１２はロック・ブロック修復処理の制御の流れを示
す。１２０１では代替データ・ストアが存在するかどう
かが判定される（２５０５）。１つ存在すれば、当該リ
ソースのロック・ブロックが代替データ・ストアでリフ
ォーマットされる（１２０２）。ロック・ブロックのリ
フォーマットが、プライマリ・データ・ストア上のロッ
ク・ブロックの前に代替データ・ストアで行われるの
は、ロック・ブロックを修復するのが、論理的にマス・
ロック・スティール操作であり、ロック・スティール処
理のところで述べているように、ロック・スティーリン
グは最初に代替データ・ストアに対して、次にプライマ
リ・データ・ストアに対して書き込みを行うからである
（図１８参照）。図４にロック・ブロックとリソースの
関係を示した。ロック・ブロックはリフォーマットされ
ているので、ロック・ブロックのなかの前のＴＯＤ値は
失われている。ロック・ブロック数は、リソースを共有
できるシステムの数（すなわち当該データ・ストアを共
有できるシステムの数）を示す。１２０３では、リフォ
ーマットが成功したかどうかが判定される。成功しなか
った場合、永続的エラー処理が起動され（１２０４）、
使用不可能な代替データ・ストアが除外される。永続的
エラー処理は図９に示した。処理は呼び出し側に戻る。
リフォーマットが成功した場合、プライマリ・データ・
ストア上のリソースのロック・ブロックがリフォーマッ
トされる（１２０５）。１２０５におけるこの処理は、
１２０１の判定が、代替データ・ストアが存在しないこ
とを示した場合も実行される。次に１２０６で、プライ
マリ・データ・ストアでのロック・ブロックのこのリフ
ォーマットが成功したかどうかが判定される。成功しな
かった場合、永続的エラー処理が起動され（１２０
７）、使用できないプライマリ・データ・ストアが除外
される。永続的エラー処理は図９に示した。処理はそこ
で呼び出し側に戻る。ロック・ブロックのリフォーマッ
トが成功した場合は、データ・ストアが要求に応答でき
なかったことの指示がセットされる（１２０８）。この
インディケータは、ロック・ブロック・リード処理に入
ってロック・ブロックがプライマリから読み出されたか
代替データ・ストアから読み出されたかに応じて、プラ
イマリまたは代替データ・ストアを反映する。処理はそ
こで呼び出し側に戻る。

【００８１】ＷＲＩＴＥ ＬＯＣＫ ＢＬＯＣＫ処理 図１３はＷＲＩＴＥ ＬＯＣＫ ＢＬＯＣＫ処理の制御
の流れを示す。１３０１ではチャネル・プログラムが生
成されてプライマリまたは代替データ・ストアへロック
・ブロックが書き込まれる。１３０２ではチャネル・プ
ログラムが起動されてその終了が待たれる。次に１３０
３ではロック・ブロックが正常に書き込まれたかどうか
が判定される。そのとおりなら処理は呼び出し側に戻
る。正常に書き込まれなかった場合は１３０４で訂正可
能な永続的エラーがあったかどうかが判定される。なか
った場合、永続的エラー処理が起動され（１３０５）、
使用できないプライマリまたは代替データ・ストアが除
外される。永続的エラー処理は図９に示した。そこで処
理は呼び出し側に戻る。訂正可能な永続的エラーがあっ
た場合は、ロック・ブロック修復処理が起動され（１３
０６）、ロック・ブロックが修復される。ロック・ブロ
ック修復処理は図１２に示した。ここで処理は呼び出し
側に戻る。

【００８２】ロック所有者信号受信処理 図１４（１４Ａ、１４Ｂ）はロック所有者信号の受信の
制御の流れを示す。この信号が受信されると、１４０１
において、データ・ストアが、信号が送信されたときと
同じかどうかが判定される。（プライマリ・データ・ス
トアのＩＤが信号で送信され、当該システム上で使用さ
れる現在のプライマリ・データ・ストアと照合され
る。）同じでなければ、ルーチンは終了してロック所有
者信号が無効なことが指示され、信号は棄却される。同
じであれば、与えられたリソースに対する要求が保留さ
れているかどうかが判定される（１４０２）。（当該リ
ソースのロック・アンカ（図２５の２５０３）がチェッ
クされる。）１４０２の判定が、リソース要求があるこ
とを示す場合は、当該信号が“最新の”信号であるかど
うかが判定される（１４０３）。この判定は、入力信号
の要求ＴＯＤを要求要素のリドライブＴＯＤ（２５１
１）と比較することによって行われる（“古い”信号が
棄却される）。要求ＴＯＤが新しい場合は、信号の要求
ＴＯＤが、ロック要求要素のリドライブＴＯＤフィール
ド（２５１１）にセーブされる（１４０４）。（リソー
ス所有者になったかどうかをＲＥＡＤ ＳＥＲＩＡＬＩ
ＺＥＤをもって検出できるように行われる − 図１０
の１００９、１０１５）。最新信号でなければこのセー
ブ操作はバイパスされる。次に（１４０５）、ＲＥＡＤ
ＳＥＲＩＡＬＩＺＥＤ処理がロック所有者信号を想定
しているかどうか（すなわちＲＥＡＤ ＳＥＲＩＡＬＩ
ＺＥＤが、図１０の判定１００９または１０１５に対す
るＮＯの応答を受信した後に存在したかどうか）が判定
される。ロック所有者信号を想定していなかった場合ル
ーチンは終了する。その信号が想定されていた場合、処
理はＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤのロック所有者信
号処理（図１０の１０１７）に戻る。１４０２の判定
が、当該システム上に与えられたリソースに対して要求
がないことを示す場合（適用されなくなった冗長信号が
受信されたなど）、ロック・ブロック・リード処理が起
動され（１４０６）、プライマリ・データ・ストアから
すべてのロック・ブロックが読み出される。次に、１４
０７で、ロック・ブロックを読み出すときにプライマリ
・データ・ストアで障害があったかどうかが判定され
る。あった場合ルーチンは終了する。なければ１４０８
で、いずれかのシステムが当該リソースを待っているか
どうかが判定される。待っていなければ（すなわちすべ
てのロック・ブロックがゼロに等しい場合）ルーチンは
終了する。あるシステムがロック所有者信号を待ってい
る場合は、当該システムが待っているシステムであるか
どうかが判定される（１４０９） − 各システムがそ
のロック・ブロック・ナンバを知っているので判定され
る。そうでない場合、ロック所有者信号は最も古い待機
側に送られ（１４１０）、ルーチンは終了する。ロック
所有者信号には、所有者の要求ＴＯＤ（所有者のロック
・ブロックから取得される）と、プライマリ・データ・
ストアのＩＤ（データ・セット名とボリューム・シリア
ル・ナンバ）が含まれる。当該システムが待っているシ
ステムであれば、ロック・ブロック・ライト処理が起動
され（１４１１）、当該システムのロック・ブロックが
クリアされる。（実際には待っていない。）（つまりデ
ータ・ストアと当該システムの同期がくずれたエラー状
態を意味する。）次に処理は１４０６から継続する。

【００８３】ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求処
理 図１５（１５Ａ〜１５Ｃ）はＷＲＩＴＥ ＳＥＲＩＡＬ
ＩＺＥＤ要求処理の制御の流れを示す。１５０１ではプ
ライマリ・データ・ストアに訂正できないエラーがある
かどうかが判定される。ある場合、処理は要求側に戻
り、エラーが指示される。ライトは発行されない。エラ
ーがない場合、データ書き込み処理が起動され（１５０
２）、プライマリ・データ・ストアにデータが書き込ま
れる。データ書き込み処理は図１６に詳しく示した。
（要求ＴＯＤはＷＲＩＴＥ ＤＡＴＡに引き渡されロッ
ク検証チェックが行われる。）次に１５０３では、デー
タの書き込み時にプライマリ・データ・ストアに訂正で
きない障害が発生したかどうかが判定される。発生した
場合、処理はまた要求側に戻り、書き込みが行われなか
ったというエラーが指示される。発生しなかった場合、
データがプライマリに書き込まれる前にプライマリのロ
ックが奪われたかどうかが判定される（１５０４）。そ
のとおりなら、エラーが呼び出し側に返され、書き込み
が完了しなかったことが示される。ロックが奪われなか
った場合、代替データ・ストアが存在するかどうかが判
定される（１５０５）。存在しない場合、ＵＮＬＯＣＫ
処理が起動され（１５０６）、制御がアンロックに渡
り、ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求が完了す
る。ＵＮＬＯＣＫ処理は図１７に詳しく示した。代替デ
ータ・ストアが存在する場合、ＷＲＩＴＥ ＤＡＴＡ処
理が起動され（１５０７）、データが代替データ・スト
アに書き込まれる。（ゼロ値がＷＲＩＴＥ ＤＡＴＡに
引き渡されてロック検証チェックが行われる。）ＷＲＩ
ＴＥ ＤＡＴＡ処理は図１６に詳しく示した。次に（１
５０８）、プライマリ・データ・ストアに訂正できない
障害があったかどうかが判定される。このような障害が
なかった場合、１５０９で、代替データ・ストアに訂正
できない障害が発生したかどうかが判定される。このよ
うな障害が発生しなかった場合、１５１０で、代替ロッ
クが奪われたかどうかが判定される。奪われた場合、ロ
ック・ブロック・リード処理が起動され（１５１１）、
当該システムのロック・ブロックが代替データ・ストア
から読み出される。ロック・ブロック・リード処理の詳
細は図１１に示した。次に（１５１２）、プライマリ・
データ・ストアに訂正できない障害があったかどうかが
判定される。なかった場合、代替ロック・ブロックにリ
セットの必要なことが指示される（１５１３）。次に
（１５１４）、代替データ・ストアに障害があったかど
うかが判定される。なかった場合、当該要求からロック
が奪われたかどうかが判定される（１５１５）。奪われ
なかった場合、ＷＲＩＴＥ ＤＡＴＡ処理が起動され
（１５１６）、データが代替データ・ストアに書き込ま
れる。（読み出されたばかりのロックのＴＯＤがＷＲＩ
ＴＥ ＤＡＴＡに引き渡されてロック検証チェックが行
われる。）ＷＲＩＴＥ ＤＡＴＡ処理の詳細は図１６に
示した。次に１５０８の判定が行われ、処理はここから
上述のように継続する。１５０８の判定が、プライマリ
・データ・ストアに訂正できない障害のあったことを示
す場合、１５１７で、代替データ・ストアが正常に更新
されたかどうかが判定される。そのとおりなら、処理は
要求側に戻り、書き込みが正常に完了したことが示され
る。更新されなかった場合、処理は要求側に戻り、書き
込みが行われなかったというエラーが示される。これと
同じエラーは、１５１２の判定が、プライマリ・データ
・ストアに訂正できない障害のあったことを示す場合も
返される。

【００８４】１５１０の判定が、代替ロックが奪われた
ことを示す場合、１５１８で、代替ロック・ブロックに
リセットが必要かどうかが判定される。必要なら１５１
９において、その指示がリセットされ、１５２０におい
て、ロック・ブロック書き込み処理が起動されて、ゼロ
が相対データ・ストアのロック・ブロックに書き込まれ
る。次に（または、１５１８の判定でＮＯの指示が受け
取られた場合）、ＵＮＬＯＣＫ処理が起動され（１５２
１）、制御がアンロックに渡り、ＷＲＩＴＥＳＥＲＩＡ
ＬＩＺＥＤ要求が完了する。ＵＮＬＯＣＫ処理の詳細は
図１７に示した。１５１５の判定が、当該要求からロッ
クが奪われたことを示す場合、ロック・ブロック書き込
み処理が起動され（１５２２）、ゼロが代替ロック・ブ
ロックに書き込まれる。次に（１５２３）、プライマリ
・データ・ストアに訂正できない障害があったかどうか
が判定される。このような障害が発生した場合、処理は
要求側に戻り、エラーと、書き込みが行われなかったこ
とが示される。障害がなかった場合、ＲＥＡＤ ＳＥＲ
ＩＡＬＩＺＥＤ処理が起動され（１５２４）、リソース
がまた取得されてユーザの変更が２重化される。ＲＥＡ
Ｄ ＳＥＲＩＡＬＩＺＥＤ処理の詳細は図１０に示し
た。処理は次に、上述のように１５０１の判定から継続
する。１５０９（または１５１４）の判定でＹＥＳが返
った場合も、１５２１の場合のようにＵＮＬＯＣＫ処理
が起動される。

【００８５】ＷＲＩＴＥ ＤＡＴＡ 図１６はＷＲＩＴＥ ＤＡＴＡ処理の制御の流れを示
す。１６０１でチャネル・プログラムが生成されて、リ
ソースがプライマリまたは代替データ・ストアに書き込
まれる（チャネル・プログラムの最初の部分では、当該
システムのロック・ブロックに、呼び出し側によって与
えられたキー値がまだ含まれるかどうかが検証される。
照合結果が“イコール”であれば、ロックはまだ所有さ
れており、チャネル・プログラムはまだ動作を継続でき
る。）１６０２でチャネル・プログラムが起動されその
完了が待たれる。次に１６０３で、データが正常に書き
込まれたかどうかが判定される。そのとおりなら処理は
呼び出し側に戻る。そうでないなら１６０４で、ロック
が奪われているかどうかが判定される。奪われている場
合、ロック要求要素（２５１３）に“ロック奪取”イン
ディケータがセットされ（１６０５）、処理は呼び出し
側に戻る。ロックが奪われていなければ、１６０６で、
訂正可能な永続的エラーがあったかどうかが判定され
る。なかった場合、永続的エラー処理が起動され（１６
０７）、使用できないプライマリまたは代替データ・ス
トアが除外される。永続的エラー処理の詳細は図９に示
した。エラーが訂正可能だった場合は、エラーが、ロッ
ク・ブロックの問題によるものか、データ書き込み障害
によるものかどうかが判定される。データ書き込み障害
なら、チャネル・プログラムが生成され（１６１０）、
データ・ストアのトラックがリフォーマットされ、チャ
ネル・プログラムが起動されて（１６１１）、その実行
完了が待たれる。次に１６１２で、リフォーマットが成
功したかどうかが判定される。そのとおりなら処理は呼
び出し側に戻る。そのとおりでなければ永続的エラー処
理が起動され（１６１３）、使用できないプライマリま
たは代替データ・ストアが除外される。１６０８の判定
が、ロック・ブロックの問題を示す場合、ロック・ブロ
ック修復処理が起動され（１６０９）、ロック・ブロッ
クが修復されて、処理は呼び出し側に戻る。ロック・ブ
ロック修復処理の詳細は図１２に示した。

【００８６】ＵＮＬＯＣＫ ＲＥＱＵＥＳＴ 図１７は、ＵＮＬＯＣＫ要求処理の制御の流れを示す。
１７０１において、プライマリ・データ・ストアに訂正
できない障害があったかどうかが判定される。あった場
合、処理は要求の呼び出し側に戻る。なかった場合、ロ
ック・ブロック書き込み処理が起動され（１７０２）、
プライマリ・データ・ストア上の当該システムのロック
・ブロックがゼロにされる。これは、リソースが当該シ
ステムに必要でなくなったことを示す。ロック・ブロッ
ク書き込み処理は図１３に詳しく示した。次に、１７０
３において、プライマリ・データ・ストアに訂正できな
い障害が発生したかどうかが判定される。そのような障
害が発生した場合、処理は要求の呼び出し側に戻る。発
生しなかった場合、ロック・ブロック読み出し処理が起
動され（１７０４）、プライマリ・データ・ストアから
すべてのロック・ブロックが読み出され、よってリソー
ス所有権が判定される。ロック・ブロック読み出し処理
の詳細は図１１に示した。次に、１７０５においてまた
プライマリ・データ・ストアに訂正できない障害があっ
たかどうかが判定される。そのとおりなら、処理は要求
の呼び出し側に戻る。そうでなければ、１７０６におい
て、最も古い待機側（最も古いＴＯＤ）がロック・ブロ
ックから検出される。次に１７０７で、かかる待機側が
検出されたかどうかが判定される。検出されなかった場
合、処理は要求呼び出し側に戻る。検出された場合、ロ
ック所有者信号がこの最も古い待機側に送られる（１７
０８）。この信号には最も古い待機側の要求ＴＯＤ（そ
のロック・ブロックから取得される）とデータ・ストア
のＩＤ（データ・セット名とボリューム・シリアル・ナ
ンバ）が含まれる。

【００８７】ＬＯＣＫ ＳＴＥＡＬ処理 図１８（１８Ａ、１８Ｂ）はＬＯＣＫスティール処理の
制御の流れを示す。ロック・スティール処理は、当該シ
ステムのすべてのロック要求要素を調べてリソース待機
時間が長すぎる要素を判定するタイマ駆動処理の結果と
して起動される。（起動の間隔と“長すぎる”の定義
は、不要な奪取が生じるほど短くてもいけないし、障害
のあったシステムが動作可能なシステムの性能を落とす
ほど長くてもいけない。実施例では起動間隔６秒、“長
すぎる’の定義は１２秒である。）１８０１では、ロッ
ク・ブロック読み出し処理が起動され、プライマリ・デ
ータ・ストアからすべてのロック・ブロックが読み出さ
れる。ロック・ブロック読み出し処理は図１１に詳しく
示した。１８０２では、現在のシステムのロック・ブロ
ックがゼロに等しいかどうかが判定される。（これはた
とえば次の場合に生じる。システムＡがリソースＸのロ
ックを取得し、次にシステムＢがＸをアクセスしようと
して、システムＡのロック・ブロックがセットされてい
るのを検出し、ロック所有者信号を待つ。そこでシステ
ムＡは何らかの原因で停止する。システムＣがＸをアク
セスしようとして、ＡとＢのロック・ブロックがセット
されているのを検出し、ロック所有者信号を待つ。次に
システムＡがＸを解除し（ここでロック・ブロックＴＯ
Ｄはゼロになる）、ロック所有者信号をＢに送る前に何
らかの原因で停止する。次にシステムＣがロック・ステ
ィールをかけ、Ｂが“所有者”であること（最も古い非
ゼロＴＯＤ）を検出し、ロックをＢから奪う（ＢのＴＯ
Ｄはここでゼロになる）。最後にＢが再起動され、ロッ
ク・スティールがかけられ、（Ｂは長く待ってたので）
そのＴＯＤがゼロになっているのを発見する！）。その
とおりであれば、ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤがま
た最初から駆動され、ルーチンは終了する。そうでなけ
れば、現在の所有者が検出される（１８０４）。（ロッ
ク・ブロックからのＴＯＤは最も古い。）次に、１８０
５で現在の所有者が当該システムであるかどうかが判定
される。そのとおりならロック所有者信号が当該システ
ムに送られ（１８０６）、ルーチンは終了する。そうで
なければ、所有者が最後の時点と同じかどうかが判定さ
れる（１８０７）。（先の所有者は１８０８で２５１４
にセーブされている。）所有者が最後の時点とは異なる
場合、１８０８で現在の所有者の情報が要求要素（２５
１４）にセーブされ、ルーチンが終了する。所有者が同
じなら、代替データ・ストアが存在するかどうかが判定
される。存在すればロック・ブロックＷＲＩＴＥ処理が
起動され（１８１０）、プライマリ・データ・ストアか
ら得られた現在の所有者の要求ＴＯＤが、代替データ・
ストア上の現在の所有者のロック・ブロックに書き込ま
れる。次にロック・ブロックＷＲＩＴＥ処理が起動され
（１８１１）、ゼロＴＯＤがプライマリ・データ・スト
ア上の現在の所有者のロック・ブロックに書き込まれ
る。新しい所有者は（プライマリのロック・ブロックか
ら最も古いＴＯＤを検出することによって）ここで（１
８１２）検出され、ロック所有者信号が新しい所有者に
送られる（１８１３）。そこでルーチンは終了する。

【００８８】新代替処理 図２６（２６Ａ〜２６Ｅ）は、新代替処理の制御の流れ
を示す。新代替処理は、新しい代替データ・ストアを初
期化してサービスを提供できるようにするときに必要で
ある。この処理は、オペレータ・コマンドで起動される
か、またはオペレータ・コマンドを受信したシステム・
コンプレクス内の別のシステムからの信号によって起動
される。２６０１において、この処理の要求が初期要求
信号であるかどうかが判定される。そうであれば２６０
２において、オペレータ要求が当該システムのシステム
・オペレータからのものかどうかが判定される。そのと
おりであれば２６０３において、当該システムが新しい
代替データ・ストアの同期をとる責任のあることが示さ
れる。（同期をとるとは、代替データ・ストアがプライ
マリ・データ・ストアの複製であることを意味する。）
要求が当該システムからのものでなければ、２６０４に
おいて、システムは現在の代替データ・ストアの使用を
中止する必要がある。オペレータ・コマンドを受け取っ
たシステムがすでに現在の代替データ・ストアをサービ
スができないようにしているからである。次に２６０５
において、新しい代替データ・ストアが使用可能かどう
かが判定される。（すなわちオペレータ・コマンドに指
示された新しい代替のボリュームとデータ・セットを検
出可能かどうか。）そうでなければ、２６０６におい
て、要求が当該システムからのものかが判定される。そ
うでなければ、“代替障害”信号が、参加している他の
すべてのシステムに送られ、ルーチンが終了する。要求
が当該システムからのものであれば、ルーチンが終了す
るだけである。２６０５の判定が、新しい代替が使用可
能であることを示す場合は、２６０８において、要求が
当該システムからのものかどうかが判定される。そうで
あれば、２６０９において、システムは現在の代替の使
用を中止する必要がある。次に２６１０で、システムは
新しい代替の使用を開始し、それに非同期状態とマーク
をつける（プライマリ・データ・ストアとして使用する
準備ができていないことを示す）。同期状態インディケ
ータは図２５の２５０６に示した。次に２６１１で、要
求が当該システムからのものかどうかが判定される。そ
うでなければ、“代替受理”信号が送られ（２６１
２）、タイマがセットされる（２６１３）。タイマをセ
ットする目的は、システムが、他のシステムが代替デー
タ・ストアの同期をとるのを長く待たずにすむようにす
ることにある。２６１１の判定が、要求が当該システム
からのものであることを示す場合、２６１４において、
当該システムが、データ・ストアを使用する唯一のシス
テムかどうかが判定される。（これはプライマリ・デー
タ・ストアのグローバル制御情報から判定できる。図３
の３０２を参照。）データ・ストアを使用する唯一のシ
ステムであれば、代替同期化処理が起動され（２６１
５）、代替データ・ストアとプライマリ・データ・スト
アとの同期がとられ、ルーチンは終了する。他のシステ
ムがデータ・ストアを使用している場合は、２６１６に
おいて、初期要求信号が他のすべてのシステムに送られ
る。次にタイマがセットされ（２６１７）、ルーチンは
終了する。

【００８９】代替同期化処理は図２６Ｂの下に示した。
最初に、２６１８において、ＲＥＡＤ ＳＥＲＩＡＬＩ
ＺＥＤとＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤがプライマ
リ・データ・ストアの各リソースに対して発行される。
（図３の３０２のグローバル制御情報は、どのリソース
が起動されているかを示す。）次に２６１９で、読み出
しまたは書き込みにエラーが発生したかどうかが判定さ
れる。エラーがあった場合、“代替障害”信号が、参加
している他の各システムに送られ、ルーチンは終了す
る。エラーがなければ、２６２１において、“代替動作
可能”信号が、参加している他の各システムに送られ
る。同期状態インディケータがここでセットされ（２６
２２、図２５の２５０６参照）、ルーチンは終了する。

【００９０】２６０１の判定が、新代替処理の初期要求
ではないことを示す場合、２６２３において、受信され
た信号が“代替受理”信号であるかどうかが判定され
る。そうなら、信号を送ったシステムの識別子がセーブ
され（２６２４）、２６２５において、現在のシステム
が、代替データ・ストアの同期をとるべきシステムかど
うかが判定される。（この責任を持つシステムが２６０
３で識別されセーブされている。）現在のシステムが、
同期をとるべきシステムではない場合、ルーチンは終了
する。現在のシステムが同期をとるべきシステムであれ
ば、参加しているすべてのシステムがもう応答したかど
うかが判定される（２６２６）。応答していなければル
ーチンは終了する。応答していれば２６２７で、代替同
期化処理が起動され、代替データ・ストアとプライマリ
・データ・ストアの同期がとられる。２６２３の判定
が、“代替受理”信号ではないことを示す場合、２６２
８において、“代替障害”信号かどうかが判定される。
そのとおりなら、当該システムは新しい代替データ・ス
トアを使用できなくなり（２６２９）、ルーチンは終了
する。“代替障害”信号でない場合、２６３０におい
て、“代替動作可能”信号かどうかが判定される。そう
であれば、代替同期化インディケータがセットされ（２
６３１、図２５の２５０６参照）、ルーチンは終了す
る。代替動作可能信号でなければ、２６３２において、
タイマ時間切れ信号かどうかが判定される。そうであれ
ば、２６３２．５において、当該システムが代替データ
・ストアの同期化に責任を持つべきかどうかが判定され
る。当該システムは、現在責任を持つシステムが活動状
態ではなくなっていれば責任を持つ（図３の３０２のグ
ローバル制御情報は、データ・ストアを使用しているシ
ステムのアレイを含み、システムが活動状態かどうかを
示す）。当該システムが新代替の同期化に責任を持つべ
きではない場合、ルーチンは終了する。責任を持つべき
なら、これが２６３３で示される。次に２６３４におい
て、すべてのシステムが応答したかどうかが判定され
る。（図３の３０２のグローバル制御情報は参加してい
る全システムを示すことに注意されたい。）参加してい
る全システムの状態は非同期タスクでモニタし、いずれ
か１つのシステムがサービスの対象外になっているかど
うかを、たとえば参加している各システムが共通にアク
セスできるデータ・フィールドの“脈拍”フィールドを
一定間隔で更新するようにすることによって判定でき
る。このような脈拍がなければ、非同期タスクは、グロ
ーバル制御情報を更新して、当該システムを参加システ
ムのリストから除外する必要がある。

【００９１】参加している全システムが応答していれ
ば、２６３５において代替同期化処理が起動され、代替
データ・ストアとプライマリ・データ・ストアの同期が
とられ、ルーチンは終了する。全システムがまだ応答し
ていなければ、２６３６において、フォローアップ信号
が参加している全システムに送られ、タイマがセットさ
れる（２６３７）。（この例では、タイマ値は２０秒後
に時間切れになるようにセットされる。）２６３２の判
定が、タイマ・ポップ信号を示さない場合、２６３８に
おいて、当該信号がフォローアップ信号かどうかが判定
される。（たとえば２６３６で示される。）そうでない
場合ルーチンは終了する。フォローアップ信号であれ
ば、２６３９において、信号が、現在の要求よりも古い
ＴＯＤを持つ信号かどうかが判定される。そうなら、２
６４０で、信号が現在の代替データ・ストアに対するも
のかどうかが判定される。そのとおりなら“代替受理”
信号が送られ（２６４１）、ルーチンは終了する。現在
の代替に対するものでなければ、“代替障害”信号が送
られ（２６４２）、ルーチンは終了する。２６３９の判
定が、信号が古い要求に対するものではないことを示す
場合、２６４３において、当該信号のＴＯＤが現在の要
求よりも新しい要求に対するものかどうかが判定され
る。（内部状態インディケータによって示される。）そ
うなら２６４５において、“代替障害”信号が送られて
当該要求が失敗し（これはたとえば、２つのシステムが
異なる代替データ・ストアを持ってくる必要のあるとき
に生じる）、ルーチンは終了する。要求が現在途中であ
れば、これは現在のシステムが初期要求信号をなくした
ことを示し、“新代替”処理がまた起動される（２６０
２）。その場合“代替受理”信号が送られ（２６４
６）、タイマがセットされて、ルーチンは終了する。
“代替受理”信号を送る理由は、先に送られた信号が失
われている可能性があるからである。

【００９２】タイマが時間切れになれば、タイマ・ポッ
プ信号を送る必要がある（２６４８）。

【００９３】例 この発明は、マルチシステム環境における使用例から最
も容易に理解される。

【００９４】ＲＥＡＤ／ＷＲＩＴＥ ＳＥＲＩＡＬＩＺ
ＥＤの例 図１９（１９Ａ、１９Ｂ）は、同じリソースに対する複
数のシステムからのＲＥＡＤ／ＷＲＩＴＥ ＳＥＲＩＡ
ＬＩＺＥＤ処理の一例である。システムＡ、システムＢ
の２つのシステムの各々の制御の流れを示す。１９０１
でユーザはリソースＸのＲＥＡＤ ＳＥＲＩＡＬＩＺＥ
Ｄ要求を出す。図２０の２００１、２００２、２００
３、及び２００４は、このＲＥＡＤ ＳＥＲＩＡＬＩＺ
ＥＤ要求の初めのロック・ブロックの状態を示す。ロッ
ク・ブロックのフィールドはすべて初めはゼロである。
ユーザの要求に応答して、リソースＸに対するシステム
Ａのロック・ブロックが書き込まれる（１９０２）。図
２０の２００５は、このステップが完了した後のシステ
ムＡのロック・ブロックの内容を示す。システムＡを示
すシーケンス・ナンバ（ＳＥＱ）１０がブロックに追加
されており、この要求の時刻値ＴＯＤ１はここで時刻フ
ィールドに入力される。リソースＸに関連する他のロッ
ク・ブロック２００６、２００７、２００８は不変であ
る。次に、リソースＸの全ロック・ブロックが読み出さ
れる（１９０３）。先に述べたとおり、システムＡに関
連するブロックを除くすべてのロック・ブロックはゼロ
なので、ロック・ルール１により、システムＡはリソー
スＸを所有する（１９０４）。次に１９０５では、リソ
ースＸのデータがストレージに読み込まれる。次に処理
はＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求側に戻り（１９
０６）、リソースＸが正常に読み出されたことが示され
る。

【００９５】次に１９０７で、ユーザは、システムＢか
らリソースＸのＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求を
出す。リソースＸに対するシステムＢのロック・ブロッ
クはプライマリ・データ・ストアに書き込まれる（１９
０８）。図２０の２０１０は、このロック・ブロックの
内容を示す。シーケンス・ナンバ１５はシステムＢに関
連し、時刻ＴＯＤ２は、システムＢのロック・ブロック
を書き込む要求に関連する時刻値である。プライマリと
代替データ・ストア上の他のすべてのロック・ブロック
２００９、２０１１、２０１２は不変である。システム
Ｂは次に、リソースＸのすべてのロック・ブロックを読
み出す（１９０９）。ロック・ルール２により、システ
ムＢは１９１０において、リソースＸを待つ必要があ
る。ゼロ以外のロック・ブロック値がシステムＢのロッ
ク・ブロック値よりも古いからである。すなわちＴＯＤ
１（２００９）はＴＯＤ２（２０１０）よりも古い。シ
ステムＢはそこで、システムＢがリソースＸの所有者に
なったことの指示を待つ（１９１１）。この待機期間
に、他のリソースまたはレコードの要求が遅れることは
ない。

【００９６】次に１９１２でシステムＡのユーザは、リ
ソースＸのＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求を出
す。リソースがまだシステムＡによって所有されている
ことが確認されると、１９１３において、リソースＸに
対する更新されたユーザ・データがプライマリ・データ
・ストアに書き込まれる。ロック・ブロックＡ（２００
９）にはまだシーケンス・ナンバ１０とＴＯＤ値ＴＯＤ
１があるので、リソースはまだ所有されており、データ
の更新は成功する。次に１９１４において、リソースＸ
の更新されたユーザ・データが代替データ・ストアに書
き込まれ、リソースがまだシステムＡに所有されている
かどうかチェックされる。所有権は、ロック・ブロック
Ａにシーケンス・ナンバ０、ＴＯＤ値０がなければなら
ないことを意味する。この場合はそれに当たるので（図
２０の２０１１）、リソースはまだ所有されており、デ
ータの更新は成功する。次に、１９１５でリソースＸの
システムＡのロック・ブロックがプライマリ・データ・
ストアに書き込まれ、リソースＸがアンロックされる。
すなわちロック・ブロックＡはすべてゼロにセットされ
る（図２０の２０１３）。次にリソースＸのすべてのロ
ック・ブロックが読み出される（１９１６）。これによ
りシステムＡは次の所有者を検出することができる（１
９１７）。次の所有者は、最も古い時刻フィールドに関
連するシステムである。例の場合はシーケンスが１５
（図２０の２０１４）のシステムＢである。システムＡ
はここで、システムＢに、それが所有者であることを通
知する。最後に１９１８で、システムＡはＷＲＩＴＥ
ＳＥＲＩＡＬＩＺＥＤ要求側に戻り、リソースが書き込
まれたことを示す。システムＢは、システムＡから自身
がリソースＸの所有者になったことの通知を受けて、リ
ソースＸのデータを読み出す（１９１９）。この後シス
テムＢはＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求側に戻
り、リソースＸが読み出されたことを示す（１９２
０）。

【００９７】ロック・スティール処理例１ 図２１（２１Ａ〜２１Ｅ）は、システムがデータをプラ
イマリ・データ・ストアに正常に書き込む前にロックが
奪われるロック・スティール処理の一例である。この例
は、相互に関連した３つのシステム（システムＡ、シス
テムＢ、システムＣ）上の制御の流れを示す。

【００９８】２１０１でユーザは、リソースＸのＲＥＡ
Ｄ ＳＥＲＩＡＬＩＺＥＤ要求を出す。図２２の２２０
１、２２０２、２２０３、２２０４、２２０５、及び２
２０６は、このＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求の
初めのロック・ブロックの状態を示す。ロック・ブロッ
クのフィールドはすべて最初はゼロである。ユーザ要求
に応答して、システムＡのリソースＸのロック・ブロッ
クが書き込まれる（２１０２）。図２２の２２０７に、
このステップが完了した後のシステムＡのロック・ブロ
ックの内容を示す。システムＡを示すシーケンス・ナン
バ１０がブロックに追加されており、当該要求の時刻値
ＴＯＤ１がここで時刻フィールドに入力される。リソー
スＸに関連する他のロック・ブロック２２０８、２２０
９、２２１０、２２１１、及び２２１２は不変である。
次に、リソースＸのすべてのロック・ブロックが読み出
される（２１０３）。先に触れたとおり、システムＡに
関連するブロックを除くふべてのロック・ブロックはゼ
ロなので、ロック・ルール１により、システムＡはリソ
ースＸを所有する（２１０４）。次に、リソースＸのデ
ータがストレージに読み込まれる（２１０５）。そこで
処理はＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求側に戻り
（２１０６）、リソースＸが正常に読み出されたことが
示される。次に、システムＢのユーザはリソースＸのＲ
ＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求を出す（２１０
７）。これより少し早く、システムＣのユーザがリソー
スＸのＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求を出す（２
１０８）。システムＣはリソースＸのそのロック・ブロ
ックをプライマリ・データ・ストアに書き込む。このロ
ック・ブロックは図２２の２２１５に示した。システム
Ｂのリソースｘのロック・ブロックもプライマリ・デー
タ・ストアに書き込まれる（図２１の２１１０）。図２
２の２２２０はこのロック・ブロックの内容を示す。次
にシステムＣはリソースＸのすべてのロック・ブロック
を読み出し（図２１の２１１１）、システムＢもリソー
スＸのすべてのロック・ブロックを読み出す（２１１
２）。システムＢは、ゼロではないロック・ブロック値
がすべて、そのロック・ブロック値よりも古いことを検
出する。すなわちＴＯＤ１（図２２の２２１９）とＴＯ
Ｄ２（２２２１）はＴＯＤ３（２２２０）よりも古い。
ロック・ルール２により、システムＢは、自身がこのリ
ソースの所有者であるという信号を受け取るまでは、リ
ソースＸを待っていなければならない。この間、他のリ
ソースまたはレコードの要求が遅れることはない。一方
（２１１４）システムＣは、少なくとも１つのシステム
のＴＯＤがそのＴＯＤよりも新しいことを検出するので
（図２２の２２２０のＴＯＤ３は２２２１のＴＯＤ２よ
りも新しい）、ロック・ルール３により、リソースＸの
所有状態は不定である。次にシステムＣはそのロック・
ブロックをリソースＸの新しいＴＯＤ値で更新する（図
２１の２１１５）。図２２の２２２７にこのロック・ブ
ロックの新しい状態を示す（ＴＯＤ４が新しいＴＯＤ
値）。システムＣは次に、リソースＸのすべてのロック
・ブロックを読み出す（図２１の２１１６）。システム
Ｃは次に（２１１７）、ロック・ブロックのなかで最も
古いＴＯＤを持つシステムを探し、システムＡ（図２２
の２２２５のＴＯＤ１）がこの時点で３つのＴＯＤのう
ち最も古いＴＯＤであると判定する。システムＣはこの
所有権をシステムＡに通知する。システムＡはこの所有
権の信号を受け取るが（２１１８）、自身がリソースＸ
の所有者であることをすでに知っているのでこの信号を
無視する。

【００９９】システムＡは、何らかの原因により、シス
テム・オペレータによって停止モードにされる（図２１
の２１２０）。これにより待機中のすべてのシステム
（システムＣ、システムＢ）は、リソースＸの待機時間
が長すぎることを検出する。２１２１でシステムＣは、
リソースＸの待機時間が長すぎることを検出するので、
リソースＸの全ロック・ブロックを読み出して現在の所
有者を判定する。同様に（２１２２）システムＢも、リ
ソースＸの待機時間が長すぎることを検出するので、こ
のリソースの全ロック・ブロックを読み出して現在の所
有者を判定する。２１２３、２１２４でシステムＣとシ
ステムＢは、システムＡがリソースＸの所有者であると
判定し（システムＡが最も古いＴＯＤを持つ）、待ち続
ける。２１２５ではシステムＣがまた、リソースＸの待
機時間が長すぎることを検出するので、このリソースの
全ロック・ブロックを読み出して現在の所有者を判定す
る。システムＣは、システムＡが現在の所有者であると
判定し（システムＡが最も古いＴＯＤを持っている）、
待機時間が長すぎることを最後に確認したときにシステ
ムＡが所有者として記録されたことを認識すると、シス
テムＡからのリソースＸのロック・スティールを開始す
る（２１２６）。この奪取を達成するために、２１２７
で、システムＡに関連したプライマリ・データ・ストア
からのリソースＸから読み出されたシーケンス・ナンバ
とＴＯＤが、ここでシステムＣによって、代替データ・
ストアのシステムＡのリソースＸのロック・ブロックに
書き込まれる。図２２の２２３４に代替データ・ストア
内のこのロック・ブロックの値を示す。プライマリ・デ
ータ・ストアのロック・ブロック２２３１、２２３２、
及び２２３３は不変であり、システムＢ、Ｃに対する代
替データ・ストアのロック・ブロック２２３５、２２３
６も同様であることに注意されたい。次に、システムＣ
によって、ゼロ値がシステムＡに対するリソースＸのプ
ライマリ・データ・ストアのロック・ブロックに書き込
まれる（図２１の２１２８）。システムＡに関連するプ
ライマリ・データ・ストアのこの新しいロック・ブロッ
クは図２２の２２３７に示した。

【０１００】次にシステムＢは、リソースＸの待機時間
が長すぎることを検出し、このリソースの全ロック・ブ
ロックを読み出して現在の所有者を判定する（図２１の
２１２９）。システムＢは、自身がリソースＸの所有者
であると判定するが（ロック・ブロックから読み出され
たそのＴＯＤが最も古い）、システムＢが待機時間が長
すぎることを最後に検出したときは所有者ではなかっ
た。システムＢは、自身がいくらか所有者になったと認
識して、この所有権を自分に通知する（図２１の２１３
０）。一方（２１３１）、システムＣはリソースＸのす
べてのロック・ブロックを読み出す。システムＣは次
に、どのシステムがリソースＸの所有者になるかを判定
する（図２１の２１３２）。次の所有者はシステムＢに
なる（ＴＯＤが最も古い）。システムＣは、システムＢ
に、それがリソースＸの所有者になったことを通知す
る。２１３３において、システムＢがリソースＸの所有
者になったという信号がシステムＢによって受信される
（システムＢは“ロック所有者”信号を受け取る −
図１４参照）。２１３５において、リソースＸに対する
第２のロック所有者信号がシステムＢによって受信され
る。システムＢは自身が所有者であることをすでに知っ
ているので、この信号を棄却する。（すなわちロック所
有者信号処理が起動されるが、ロック所有者信号が入力
されたときにＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤは起動さ
れない。）２１３４ではシステムＡのオペレータがシス
テムを再スタートさせ、停止されていたタスクをすべて
実行させる。２１３６ではシステムＢが（リソースＸの
新所有者）、リソースＸに置こうとするデータを読み出
す。処理はここでＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求
側に戻り、リソースＸが正常に読み出されたことが示さ
れる（２１３８）。２１３７では、システムＡのユーザ
がリソースＸのＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求
を出す。リソースＸに対する更新されたシステムＡのユ
ーザ・データは、プライマリ・データ・ストアに書き込
まれようとし、リソースＸがまだシステムＡによって所
有されているかどうかをチェックするためにそのロック
・ブロックが調べられる（２１３９）。そのロック・ブ
ロックの値はそのシーケンス・ナンバ１０にセットされ
なくなっているので − 先に述べたようにゼロに変え
られている（図２２の２２３７参照） − システムＡ
は、リソースＸを所有しなくなったと判定する。そのた
めＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求は成功せず
（図２１の２１４０）、処理はＷＲＩＴＥ ＳＥＲＩＡ
ＬＩＺＥＤ要求側に戻り、リソースＸが正常に書き込ま
れなかったことが示される。

【０１０１】ロック・スティール処理例２ 図２３（２３Ａ〜２３Ｆ）は、システムがデータをプラ
イマリ・データ・ストアに正常に書き込んだ後で、代替
データ・ストアに対するＷＲＩＴＥの前にロックが奪わ
れるときのロック・スティール処理の一例である。

【０１０２】２３０１でユーザはリソースＸのＲＥＡＤ
ＳＥＲＩＡＬＩＺＥＤ要求を出す。図２４の２４０
１、２４０２、２４０３、及び２４０４に、このＲＥＡ
Ｄ ＳＥＲＩＡＬＩＺＥＤ要求の初めのロック・ブロッ
クの状態を示す。ロック・ブロックのフィールドはすべ
て最初はゼロである。ユーザ要求に応答して、システム
ＡのリソースＸのロック・ブロックが書き込まれる（２
３０２）。図２４の２４０５にこのステップが完了した
後のシステムＡのロック・ブロックの内容を示す。シス
テムＡを示すシーケンス・ナンバ１０がブロックに追加
されており、この要求の時刻値ＴＯＤ１がここで時刻フ
ィールドに入力される。リソースＸに関連する他のロッ
ク・ブロック２４０６、２４０７、及び２４０８は不変
である。次にリソースＸのすべてのロック・ブロックが
読み出される（２３０３）。先に触れたとおり、システ
ムＡに関連するブロックを除くすべてのロック・ブロッ
クはゼロなので、ロック・ルール１により、システムＡ
はリソースＸを所有する（２３０４）。次に（２３０
５）、リソースＸのデータがストレージに読み込まれ
る。そこで処理はＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求
側に戻り、リソースＸが正常に読み出されたことが示さ
れる。次に（２３０７）システムＢのユーザがリソース
ＸのＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求を出す。シス
テムＢのリソースＸのロック・ブロックはプライマリ・
データ・ストアに書き込まれる（図２３の２３０８）。
図２４の２４１０にこのロック・ブロックの内容を示
す。システムＢは次に、リソースＸのすべてのロック・
ブロックを読み出す（図２３の２３０９）。システムＢ
は、ゼロでないロック・ブロック値がすべてそのロック
・ブロック値よりも古いことを検出する。すなわちＴＯ
Ｄ１（図２４の２４０９）がＴＯＤ２（２４１０）より
も古いことを知る。ロック・ルール２により、システム
Ｂは、自身がこのリソースの所有者であるという信号を
受け取るまではリソースＸを待っていなければならな
い。この間、他のリソースまたはレコードの要求が遅れ
ることはない。

【０１０３】ここでシステムＡは、何らかの原因によ
り、システム・オペレータによって停止モードにされる
（図２３の２３１１）。これにより待機中のすべてのシ
ステムは（この場合はシステムＢ）、結果的に、リソー
スＸの待機時間が長すぎることを認識する（図１８「ロ
ック・スティール処理」の説明を参照）。２３１２では
システムＢは、リソースＸの待機時間が長すぎることを
検出するので、リソースＸの全ロック・ブロックを読み
出して現在の所有者を判定する。２３１３ではシステム
ＢはシステムＡがリソースＸの所有者であると判定し
（ＴＯＤが最も古い）、待ち続ける。２３１４では再び
システムＢが、リソースＸの待機時間が長すぎることを
検出するので、このリソースのすべてのロック・ブロッ
クを読み出して現在の所有者を判定する。システムＢ
は、２３１５でシステムＡが現在の所有者であると判定
し（ＴＯＤが最も古い）、システムＢが待機時間の長す
ぎることを最後に確認したときにシステムＡが所有者と
して記録されたことを認識して、システムＡからのリソ
ースＸのロックのスティールを開始する。これを達成す
るために（２３１６）、システムＡに関連したプライマ
リ・データ・ストアからのリソースＸから読み出された
シーケンス・ナンバとＴＯＤ（図２４の２４０９）がこ
こでシステムＢによって代替データ・ストアのシステム
ＡのリソースＸのロック・ブロックに書き込まれる。図
２４の２４１５に代替データ・ストアのこのロック・ブ
ロックの値を示す。プライマリ・データ・ストアのロッ
ク・ブロック２４１３、２４１４は、システムＢの代替
データ・ストアのロック・ブロック（２４１６）と同様
に変わらないことに注意されたい。

【０１０４】２３１７ではシステムＡのオペレータがシ
ステムを再スタートさせ、停止されていたタスクをすべ
て完了させる。２３１８ではシステムＡのユーザがリソ
ースＸのＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求を出
す。リソースＸのシステムＡの更新されたユーザ・デー
タはプライマリ・データ・ストアに書き込まれ、リソー
スＸがまだシステムＡによって所有されているかどうか
をみるためにそのロック・ブロックがチェックされる
（２３１９）。システムＢはまだ、リソースＸのシステ
ムＡのロック・ブロックをゼロに変えてはいないので、
システムＡは自身がまだリソースＸを所有しているとみ
なす。次に（２３２０）システムＢはプライマリ・デー
タ・ストアのシステムＡのリソースＸのロック・ブロッ
クにゼロを書き込む。図２４の２４１７にこの新しいロ
ック・ブロックを示す。次に（２３２１）システムＢは
リソースＸのすべてのロック・ブロックを読み出す。次
に（２３２２）システムＡはリソースＸの更新されたユ
ーザ・データを代替データ・ストアに書き込もうとし、
リソースがまだシステムＡによって所有されているかど
うかをチェックする（チャネル・プログラムによって実
行される検証については図１６「ＷＲＩＴＥ ＤＡＴ
Ａ」の説明を参照）。しかしこの書き込みは成功しない
（２３２３）。ロックがシステムＡに所有されなくなっ
ているからである。

【０１０５】リソースＸの代替データ・ストアへの更新
は成功しなかったが、更新されたデータは先にプライマ
リ・データ・ストアに書き込まれている（２３１９）。
更新されたデータはこのリソースの他のユーザに開放さ
れている。したがって、システムＡのユーザに、書き込
みが不成功に終わったと通知するのは正しくない。そう
ではなくデータが２重化されるようにする必要がある
（２３２３）。そのためには最初に、ロックが当該シス
テムで現在処理されている要求から奪われたか、当該シ
ステムの前の要求から奪われたかどうかを判定する必要
がある（２３２４）。当該システムのロック・ブロック
はリソースＸについて読み込まれ、代替ロック・ブロッ
クはクリアされる（図１５の１５１１以降を参照）。一
方（２３２５）リソースＸの所有者はシステムＢと判定
されている（ＴＯＤが最も古い）。システムＢは所有者
と判定され、それがリソースＸの所有者であることが通
知される。２３２６ではシステムＢは自身がリソースＸ
の所有者であるというそれ自身の信号を受け取る。シス
テムＡでは（２３２７）、代替データ・ストア上のユー
ザの変更をバックアップする最初のステップとしてＲＥ
ＡＤ ＳＥＲＩＡＬＩＺＥＤが内部で起動される。２３
２８ではシステムＢがリソースＸのデータを読み込む。
２３２９では、内部で起動されたＲＥＡＤ ＳＥＲＩＡ
ＬＩＺＥＤ処理の第１ステップとして、システムＡのリ
ソースＸのロック・ブロックがプライマリ・データ・ス
トアに書き込まれる。このロック・ブロックの内容は図
２４の２４２５に示した（ＴＯＤ３は現在の要求の時刻
値）。２３３０では処理がＲＥＡＤ ＳＥＲＩＡＬＩＺ
ＥＤ要求側に戻り、リソースＸがシステムＢによって正
常に読み出されたことが示される。２３３１では再び、
２３２７において内部で起動されたＲＥＡＤ ＳＥＲＩ
ＡＬＩＺＥＤプロセスの一部として、リソースＸの全ロ
ック・ブロックが読み出される。ゼロでないロック・ブ
ロック値はすべて、システムＡのロック・ブロック値よ
りも古いので（ＴＯＤ２はＴＯＤ３よりも古い）、シス
テムＡは、ロック・ルール２により、リソースＸを待っ
ていなければならない（図２３の２３３２）。２３３３
ではシステムＢのユーザがリソースＸのＷＲＩＴＥ Ｓ
ＥＲＩＡＬＩＺＥＤ要求を出す。リソースＸの更新され
たユーザ・データがそこでプライマリ・データ・ストア
に書き込まれ、リソースＸがまだシステムＢによって所
有されているかどうかがチェックされる（２３３４）
（図１６のチャネル・プログラム検証の説明を参照）。
次に２３３５で、リソースＸの更新されたユーザ・デー
タが代替データ・ストアに書き込まれ、リソースがまだ
システムＢによって所有されているかどうかがチェック
される。次に（２３３６）システムＢのリソースＸのロ
ック・ブロックが書き込まれてリソースＸがアンロック
される（図２４の２４３０）。

【０１０６】リソースＸのロック・ブロックはすべて２
３３７で読み出され、次の所有者が判定される（２３３
８）。ロック所有者信号がシステムＡに送られる。そこ
で処理はＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求側に戻
り（２３３９）、リソースＸが正常に書き込まれたこと
が示される。２３４０ではシステムＡが、自身がリソー
スＸの所有者になったという信号を受け取る。そこでシ
ステムＡはリソースＸのデータを読み出す。このデータ
は、システムＡが最初に加えた変更と、システムＢの変
更から成る。２３４１で処理はＲＥＡＤ ＳＥＲＩＡＬ
ＩＺＥＤ要求側に戻り、リソースが正常に読み出された
ことが示される。この場合、要求側はＷＲＩＴＥ ＳＥ
ＲＩＡＬＩＺＥＤ処理である（内部のＲＥＡＤ ＳＥＲ
ＩＡＬＩＺＥＤ要求であるため）。２３４２で（読み出
されたばかりの）リソースＸのデータがプライマリ・デ
ータ・ストアに書き込まれ、リソースがまだシステムＡ
に所有されているかどうかがチェックされる。次に（２
３４３）、リソースＸのデータが代替データ・ストアに
書き込まれ、再び、リソースがまだ当該システムによっ
て所有されているかどうかがチェックされる（チャネル
・プログラム検証− 図１６参照）。システムＡのロッ
ク・ブロックがそこですべてゼロとしてプライマリ・デ
ータ・ストアに書き込まれてリソースＸがアンロックさ
れる（２３４４）。図２４の２４３３にこれを示す。次
にリソースＸのロック・ブロックはすべて読み出され
（２３４５）、次の所有者が判定される（２３４６）。
この時点ではリソースＸを待っているものがないのでロ
ック所有者信号は送られないことに注意されたい。そこ
で処理はＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求側に戻
り、リソースＸが正常に書き込まれたことが示される
（２３４７）。ここでプライマリ、代替の両データ・ス
トアが、システムＡとシステムＢの変更内容の組み合わ
せを含む。

【０１０７】

【発明の効果】この発明により、システムまたはシステ
ム・コンプレクスの各ユーザ間でデータを効率よく共有
することができる。

【図面の簡単な説明】

【図１】「共有データ・アクセス直列化」ユーザ・プロ
グラム、ＤＡＳＤ上のユーザ・データ、及び各システム
上の「共有データ・アクセス直列化」のインスタンスの
関係を示すブロック図である。

【図２】「共有データ・アクセス直列化」のユーザが使
用できるサービスを示すブロック図である。

【図３】ユーザ・データの管理において「共有データ・
アクセス直列化」に用いられる共有データ・ストアの内
容を示すブロック図である。

【図４】各ユーザ・データ項目に関係する制御構造を示
すブロック図である。

【図５】リソースへのアクセスを制御するのに用いられ
る構造を示すブロック図である。

【図６】リソースのデータの整合性を保証するのに用い
られる構造を示すブロックである。サフィクス・レコー
ドとチェック・レコードの構造は同じである。

【図７】ＲＥＡＤ要求処理の制御の流れを示す図であ
る。

【図８Ａ】ＲＥＡＤ ＤＡＴＡ処理の制御の流れを示す
図である。

【図８Ｂ】ＲＥＡＤ ＤＡＴＡ処理の制御の流れを示す
図である。

【図９Ａ】永続的エラー処理の制御の流れを示す図であ
る。

【図９Ｂ】永続的エラー処理の制御の流れを示す図であ
る。

【図１０Ａ】ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求処理
の制御の流れを示す図である。

【図１０Ｂ】ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求処理
の制御の流れを示す図である。

【図１０Ｃ】ＲＥＡＤ ＳＥＲＩＡＬＩＺＥＤ要求処理
の制御の流れを示す図である。

【図１１】ロック・ブロック・リード処理の制御の流れ
を示す図である。

【図１２】ロック・ブロック修復処理の制御の流れを示
す図である。

【図１３】ロック・ブロック・ライト処理の制御の流れ
を示す図である。

【図１４Ａ】ロック所有者信号処理の制御の流れを示す
図である。

【図１４Ｂ】ロック所有者信号処理の制御の流れを示す
図である。

【図１５Ａ】ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求処
理の制御の流れを示す図である。

【図１５Ｂ】ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求処
理の制御の流れを示す図である。

【図１５Ｃ】ＷＲＩＴＥ ＳＥＲＩＡＬＩＺＥＤ要求処
理の制御の流れを示す図である。

【図１６】データ・ライト処理の制御の流れを示す図で
ある。

【図１７】ＵＮＬＯＣＫ要求処理の制御の流れを示す図
である。

【図１８Ａ】ロック・スティール処理の制御の流れを示
す図である。

【図１８Ｂ】ロック・スティール処理の制御の流れを示
す図である。

【図１９Ａ】同じリソースに対する複数のシステムにつ
いてのリード直列化の例の制御の流れを示すテーブルで
ある。

【図１９Ｂ】同じリソースに対する複数のシステムにつ
いてのリード直列化の例の制御の流れを示すテーブルで
ある。

【図２０】図１９の例のロック・ブロックの状態変化を
示すテーブルである。

【図２１Ａ】第１ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２１Ｂ】第１ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２１Ｃ】第１ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２１Ｄ】第１ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２１Ｅ】第１ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２２】図２１の例のロック・ブロックの状態変化を
示すテーブルである。

【図２３Ａ】第２ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２３Ｂ】第２ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２３Ｃ】第２ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２３Ｄ】第２ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２３Ｅ】第２ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２３Ｆ】第２ロック・スティール処理の例の制御の
流れを示すテーブルである。

【図２４】図２３の例のロック・ブロックの状態変化を
示すテーブルである。

【図２５】プライマリ・ストア・ディスクリプタ、代替
ストア・ディスクリプタ、及びロック要求要素の制御ブ
ロック構造を示すブロック図である。

【図２６Ａ】“新代替”処理の制御の流れを示す図であ
る。

【図２６Ｂ】“新代替”処理の制御の流れを示す図であ
る。

【図２６Ｃ】“新代替”処理の制御の流れを示す図であ
る。

【図２６Ｄ】“新代替”処理の制御の流れを示す図であ
る。

【図２６Ｅ】“新代替”処理の制御の流れを示す図であ
る。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 マイケル・ダスティン・スワンソン アメリカ合衆国ニューヨーク州、パキプ シ、カレッジ・アヴェニュー 95番地

Claims (14)

【特許請求の範囲】
1. 【請求項１】各システムがメイン・ストレージ、システ
   ム・リソース、該システム・リソースを管理するオペレ
   ーティング・システム、及び外部媒体に存在する共有デ
   ータより成る、マルチシステムのセントラル・エレクト
   ロニック・コンプレクス（ＣＥＣ）において、該共有デ
   ータへのアクセスを制御する方法であって、 Ａ）上記共有データの共有リソース要素を外部媒体上の
   プライマリ・データ・ストアに配置するステップと、 Ｂ）各ブロックがシステムの１つに一意に関連づけられ
   たロック・ブロックより成るアクセス制御情報を、上記
   共有リソース要素に関連づけるステップと、 Ｃ）上記アクセス制御情報を用いた排他的アクセス制御
   方法によって、上記プライマリ・データ・ストアの上記
   共有リソース要素への排他的アクセスを第１システム上
   の第１プログラムに許可するステップと、 Ｄ）上記第１プログラムによって、上記共有リソース要
   素を上記メイン・ストレージに読み込むステップと、 Ｅ）上記第１プログラムによって、上記メイン・ストレ
   ージの上記共有リソース要素に変更を加えるステップ
   と、 Ｆ）上記第１プログラムによって、変更を加えられた上
   記リソース要素を上記プライマリ・データ・ストアに書
   き戻すステップと、 Ｇ）上記プライマリ・データ・ストア上の上記リソース
   要素への上記第１プログラムの排他的アクセス権を解除
   するステップとを含む、 アクセス制御方法。
2. 【請求項２】ロック・ブロックより成るアクセス制御情
   報を持つ代替データ・ストアに、該データ・ストアと実
   質上同様なプライマリ・データ・ストアのコピーを作成
   するステップを含む、請求項１に記載のアクセス制御方
   法。
3. 【請求項３】上記排他的アクセス制御方法が、 Ａ）上記第１システムに関連するロック・キーを生成す
   るステップと、 Ｂ）上記共有リソース要素及び上記第１システムに関連
   する、上記プライマリ・データ・ストア上のロック・ブ
   ロックの１つに上記ロック・キーを書き込むステップ
   と、 Ｃ）上記リソースに関連するすべてのロック・ブロック
   を上記プライマリ・データ・ストアから読み出すステッ
   プと、 Ｄ）上記リソースの所有者を判定するためにロック・ル
   ールの方法を適用するステップとを含む、 請求項１または２に記載のアクセス制御方法。
4. 【請求項４】上記排他的アクセス制御方法が、 Ａ）システムが上記共有リソース要素を待っている時間
   が長すぎることを待機時間超過検出方法によって判定す
   るステップと、 Ｂ）ロック・スティーリング方法によって、上記リソー
   スの排他的制御権を上記待機中のシステムに引き渡すス
   テップとを含む、 請求項３に記載のアクセス制御方法。
5. 【請求項５】上記ロック・ルールの方法が、 Ａ）上記プライマリ・データ・ストア上の上記共有リソ
   ース要素に関連するロック・ブロックが上記第１システ
   ムに関連するロック・ブロックを除いてすべてゼロのと
   きに、該第１システムを該リソースの所有者と判定する
   ステップと、 Ｂ）上記共有リソース要素に関連し、上記第１システム
   には関連しない少なくとも１つのロック・ブロックがゼ
   ロではなく、ゼロではないかかる各ロック・ブロックの
   時刻値が該第１システムの時刻値よりも古いときに、該
   第１システムを該共有リソース要素の所有者ではないと
   判定し、該第１システムに、該共有リソース要素の所有
   権の通知を待機させるステップと、 Ｃ）ロック・ルール（Ａ）及び（Ｂ）が適用されないと
   きに、所有権が確定しない状況を識別し、上記第１シス
   テムによって、新しい時刻値を生成し、該新時刻値をも
   って、上記共有リソース要素及び上記第１システムに関
   連するすべてのロック・ブロックを更新し、読み出され
   た上記のどのリソース要素が最も古い時刻値を持つかを
   判定し、かつ時刻値が最も古い上記読み出されたロック
   ・ブロックの１つに関連する第２システムに、該第２シ
   ステムが上記共有リソース要素の所有者となったことを
   通知するステップとを含む、 請求項４に記載のアクセス制御方法。
6. 【請求項６】上記ロック・スティーリング方法が、 Ａ）前のリソース所有者に関連する上記プライマリ・デ
   ータ・ストアに関連したロック・ブロックを第２データ
   ・ストアに書き込むステップと、 Ｂ）上記プライマリ・データ・ストア内の、上記前のリ
   ソース所有者に関連するロック・ブロックをゼロにする
   ステップと、 Ｃ）リソース待機時間が最長のシステムを判定し、待機
   中のかかるシステムが上記共有リソース要素の排他的制
   御権を持つことを該システムに通知するステップとを含
   む、 請求項５に記載のアクセス制御方法。
7. 【請求項７】Ａ）上記プライマリ・データ・ストアに欠
   陥レコードがあることを、ローカルエラー検出手段によ
   って判定するステップと、 Ｂ）上記プライマリ・データ・ストア上でローカル・エ
   ラーを訂正するステップとを含む、 請求項１に記載のアクセス制御方法。
8. 【請求項８】Ａ）上記プライマリ・データ・ストアに訂
   正できないエラーが発生したことをグローバルエラー検
   出手段によって判定するステップと、 Ｂ）上記プライマリ・データ・ストアを上記代替データ
   ・ストアと取り替えるステップと、 Ｃ）新しい代替データ・ストアを動的に生成するステッ
   プとを含む、 請求項２に記載のアクセス制御方法。
9. 【請求項９】各システムが、メイン・ストレージ、シス
   テム・リソース、該システム・リソースを管理するオペ
   レーティング・システム、及び外部媒体に存在する共有
   データより成る、マルチシステムのセントラル・エレク
   トロニック・コンプレクス（ＣＥＣ）において、該共有
   データへのアクセスを制御する直列化メカニズムであっ
   て、 Ａ）共有データを持つ共有リソース要素より成るプライ
   マリ・データ・ストアと、 Ｂ）上記プライマリ・データ・ストア上の上記共有リソ
   ース要素への排他的アクセス権を取得する上記コンプレ
   クスの第１システムのための、該プライマリ・データ・
   ストア内の排他的アクセス手段と、 Ｃ）上記プライマリ・データ・ストア内のグローバル制
   御要素とを含む、 直列化メカニズム。
10. 【請求項１０】上記プライマリ・データ・ストアと実質
    上同様な代替データ・ストアより成る、請求項９に記載
    のマルチシステムＣＥＣ。
11. 【請求項１１】上記排他的アクセス手段が、あるシステ
    ムに関連し、該システムが共有リソース要素を必要とす
    るときに上記プライマリ・データ・ストア上にゼロ値を
    持ち、かつ該システムが該共有リソース要素の排他的制
    御権を取得するときに該プライマリ・データ・ストア上
    に非ゼロ値を持つ、システム・シーケンス・ナンバ・フ
    ィールドと時刻値フィールドとを持ち、該プライマリ・
    データ・ストア上の各共有リソース要素に関連する、シ
    ステム関連ロック・キーを持ったロック・ブロックより
    成る、請求項９または１０に記載のマルチシステムＣＥ
    Ｃ。
12. 【請求項１２】Ａ）上記第１システムが故障するかまた
    は一時的に停止したことを判定する検出手段と、 Ｂ）上記第１システムに割り込みをかけ、該第１システ
    ムが故障するかまたは一時的に停止したときに上記共有
    データのリソースへの排他的アクセス権を待機中のシス
    テムに引き渡す、第２システムのための割り込み(preem
    ption)手段とを含む、 請求項１１に記載のマルチシステムＣＥＣ。
13. 【請求項１３】上記検出手段が、上記待機中のシステム
    の待機時間と“待機時間超過”間隔を比較するタイマ駆
    動ルーチンより成る、 請求項１２に記載のマルチシステムＣＥＣ。
14. 【請求項１４】上記割り込み手段がスティーリング・メ
    カニズムより成り、該メカニズムによって、上記第２シ
    ステムが、上記リソースの排他的制御権を付与される新
    しい制御システムを識別し、上記第１システムのプライ
    マリ・ロック・キーをゼロにセットして前のプライマリ
    ・ロック・キーをそのセカンダリ・ロック・キー位置に
    格納することによって、該リソースの排他的制御権を取
    り除き、かつ新しい制御メカニズムが該リソースの排他
    的制御権を得たことを該メカニズムに通知する、 請求項１３に記載のマルチシステムＣＥＣ。