JP3268534B2 - 保護された資源の同期点管理を行うコンピュータ・システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般にコンピュータ・
オペレーティグ・システムに関するものであり、具体的
には、コンピュータ・システムまたはネットワーク内で
の保護された資源の調整式同期点管理に関するものであ
る。

【０００２】

【従来の技術】本発明のオペレーティング・システム
は、コンピュータ・システムのネットワーク内で使用で
きる。こうした各コンピュータ・システムは、1台の中
央ホスト・コンピュータと、複数の仮想計算機またはそ
の他の形式の実行環境を含むことができる。仮想計算機
用のホスト・コンピュータには、システム制御プログラ
ムが含まれ、このシステム制御プログラムは、ホストの
データ・プロセッサに対する各仮想計算機のアクセスを
スケジューリングし、大容量メモリを含むホストの資源
の管理を助けて、各仮想計算機が別々のコンピュータで
あるように見えるようにする。各仮想計算機はまた、ホ
ストを介してメッセージまたはファイルを送るために、
他の仮想計算機と会話することができる。各仮想計算機
は、その仮想計算機のユーザと会話する(すなわち、ユ
ーザから命令を受け取り、ユーザにプロンプトを提示す
る)ための、それ自体のシステム制御プログラムを有し
ている。共用ファイル・システム(SFS)や共用SQL関係デ
ータベースなど、任意のユーザ仮想計算機およびホスト
からアクセス可能な資源が存在してもよい。

【０００３】このようなシステムは、それぞれが1台の
実計算機であると見なされる。2台以上のこのような実
計算機をネットワーク内で相互接続し、異なる実計算機
の仮想計算機の間での会話を介してデータを転送するこ
とが一般に行われている。このような転送は、AVSゲー
トウェイやVTAMファシリティなどの通信ファシリティを
介して行われる。

【０００４】アプリケーションが、データベースまたは
ファイルを変更するには、まずそれらの変更を定義する
作業要求を行う。これに応答して、元のデータベースま
たはファイルは変更しないままで、その作業要求に基づ
く仮の変更がシャドウ・ファイル内で行われる。この
時、シャドウ・ファイルは有効でない。ここで、アプリ
ケーションは、シャドウ・ファイルの変更を有効にし、
それによってシャドウ・ファイルの変更で元のファイル
を置換するために、その変更をコミットするよう要求す
ることができる。1段階のコミット手順が使用できる。
この1段階コミット手順は、シャドウ・ファイルに含ま
れる資源の変更を1個のコマンドでコミットするもので
ある。SFS資源やSQL資源などの資源が変更される時、そ
の資源に対するコミットは、別々の1段階コミット手順
で完了できる。大多数の場合、すべての資源が別々の手
順でエラーや中断なしにコミットされる。しかしなが
ら、いずれかの1段階コミット手順の最中に問題が発生
した場合、完了したコミットもあれば完了しないコミッ
トもあり、整合性が失われる。問題が生じた後にクリテ
ィカルでない資源を再構築するコストは、1段階コミッ
ト手順の効率を考慮すれば、許容できるものである。

【０００５】しかし、クリティカルな資源およびクリテ
ィカルな会話を保護するには、2段階のコミット手順が
必要である。たとえば、第1の人物の当座預金口座が第1
のデータベース内で表され、第2の人物の普通預金口座
が第2のデータベース内で表されていると仮定する。第1
の人物が第2の人物に対して小切手を振り出し、第2の人
物がその小切手を自分の普通預金口座に預金する場合、
2段階コミット手順を用いれば、第1の人物の当座預金口
座が借方記入されるなら第2の人物の普通預金口座が貸
方記入され、そうでないならばどちらの口座も変更しな
いことが保証される。これらの当座預金口座と普通預金
口座は、保護されたクリティカルな資源と見なされる。
というのは、これらの当座預金口座と普通預金口座にか
かわるデータの転送が、信頼のおける取扱いを受けるこ
とが非常に重要であるからである。アプリケーション・
プログラムは、1個のコマンドで2段階コミット手順を開
始できる。この手順は、以下のステップまたは段階から
なる。 (1)準備段階の間、各関係者(借方と貸方)の資源が、そ
の資源がすべての変更をコミットする用意ができている
かどうか判定するために、同期点マネジャ手段によって
ポーリングされる。各資源は、すべての資源がこの準備
段階を首尾よく完了する、すなわち更新される用意がで
きている場合に、資源更新を完了すると約束する。 (2)コミット段階の間、同期点マネジャ手段は、すべて
の資源に更新を最終的なものにするよう指示し、いずれ
かの資源が準備段階を首尾よく完了できなかった場合に
は、それらを撤回する。

【０００６】IBMシステム・ネットワーク・アーキテク
チャSNA LU6.2アーキテクチャ(解説書SC31−6808、第5.
3章、“Presentation Services - Sync Point Verb
s”、IBMコーポレーション刊)は、2つ以上の保護された
資源間でコミットを調整することが以前から知られてい
た。このアーキテクチャは、すでに、単一のアプリケー
ション環境内で実行される同期点処理とそれに関連する
回復処理の両方を実行する、同期点マネジャからなる同
期点ファシリティに対処していた。複数のアプリケーシ
ョンがこの環境内で同時に実行できた。LU6.2アーキテ
クチャは、資源の調整、同期点のロギングおよび回復の
責任を負う同期点マネジャ(SPM)をサポートする。従来
技術のCICS/VS(IBMコーポレーションの商品)環境は、こ
のようなアーキテクチャをサポートする。

【０００７】従来技術のIBM SNA LU6.2によれば、段階
1および段階2で、コミット手順が実行され、同期点マネ
ジャがその段階を同期点ログに記録する。また、同期点
マネジャは、現在処理中の論理ユニットまたは作業の識
別番号を記録する。このようなロギングは、2段階コミ
ット手順中に問題が生じた場合に、同期点マネジャによ
る資源回復または再同期を助ける。2段階のコミット手
順に入った後にこのような問題が発生する場合、ログを
読み取り、資源回復処理を行って、それにかかわる資源
を整合性のある状態にする。この問題には、通信経路の
障害や資源マネジャの障害が含まれる。

【０００８】前述のＬＵ6．2同期点アーキテクチャは、
1つのアプリケーション実行環境として定義される。あ
らゆるＬＵ6．2同期点環境は、その環境用のアプリケー
ションを実行する。データは、通常はその環境に所有さ
れ、その環境から特に抜き出されない限り、その環境の
外部では共用されない。ＬＵ6．2同期点アーキテクチャ
は、単一の環境内での資源の調整、回復および同期点マ
ネジャのロギングのための同期点マネジャ（ＳＰＭ）モ
デルを定義する。異なる環境には、たとえ物理的に同一
のプロセッサ上にあっても、別々の同期点動作および回
復動作と別々のログを含む、別々の同期点マネジャが必
要となる。

【０００９】もう1つの従来技術のシステム制御プログ
ラムである、ＩＢＭコーポレーションから販売されてい
るＣＩＣＳ／ＶＳ制御プログラムでは、すべてのプロセ
スとほとんどの資源は、システムではなく環境が所有す
る。

【００１０】

【００１１】もう1つの従来技術のシステム制御プログ
ラムである、IBMコーポレーションから販売されてい
る、多重(仮想計算機)実行環境をサポートするためのVM
/SPリリース5制御プログラムでは、2つのアプリケーシ
ョン・プログラムが同一の(仮想計算機)実行環境内で実
行できた。しかし、被呼側アプリケーション・プログラ
ムがファイル更新をコミットした場合、たとえ呼出側ア
プリケーション・プログラムがまだ整合性のある状態に
なっていない場合であっても、呼出側アプリケーション
・プログラムのファイル更新がコミットされてしまう。
この従来技術のシステム制御プログラムには、呼出側ア
プリケーション・プログラムの作業を、被呼側アプリケ
ーション・プログラムの作業から分離する機能はなかっ
た。さらに、コミットは、ファイルに対するコミット
と、それとは別の手順を介したデータベースに対するコ
ミットだけに限定されていた。

【００１２】その後の従来技術のシステム制御プログラ
ムである、やはりIBMコーポレーションから販売されて
いる仮想計算機環境用のVM/SPリリース6制御プログラム
では、同一の仮想計算機(実行環境)上で実行される2つ
のアプリケーション・プログラムが、それらのファイル
用の異なる作業ユニットを定義できた。その結果、一方
のアプリケーションがアクセスするファイルが、他方の
アプリケーションがアクセスするファイルとは独立にコ
ミットでき、一方のアプリケーションの作業が、他方の
アプリケーションの作業とは独立に行えた。また、この
その後の従来技術のシステム制御プログラムでは、ある
アプリケーション(たとえば、サーバ)が、同時に複数の
作業ユニットを有することができた。それにもかかわら
ず、この従来技術のシステム制御プログラムは、複数の
資源が同じ作業ユニットを有することができるにもかか
わらず、資源の更新を独立にコミットしなければならな
かったという点で、制限されていた。さらに、各作業ユ
ニットは、1つの実行環境(仮想計算機)に制限されてい
た。

【００１３】

【発明が解決しようとする課題】本発明の全般的な目的
は、独立な分散アプリケーション環境用の、効率的で調
整された資源保護/回復システムおよび方法を提供する
ことである。

【００１４】本発明の具体的目的は、1実計算機内の多
重実行環境をサポートする、前述のタイプの方法および
システムを提供することである。

【００１５】本発明の他の具体的目的は、ローカル・エ
リア・ネットワークまたはその他のネットワーク内のワ
ークステーションやパーソナル・コンピュータなどの複
数のプロセッサをサポートする、前述のタイプの方法お
よびシステムを提供することである。

【００１６】本発明の他の具体的目的は、資源回復ファ
シリティをバックアップするための、効率的な技法を提
供することである。

【００１７】

【課題を解決するための手段】本発明は、複数の実行環
境用の各実計算機の全体に同期点マネジャが分散されて
いるが、1実計算機内のすべての実行環境および同期点
マネジャが、共通の回復ファシリティおよび回復ログを
共用する、コンピュータ・システムまたは方法に関す
る。したがって、各コンピュータ・システムごとに、第
1の実行環境と、第1の実行環境のために第1のコミット
手順を調整する第1の同期点マネジャと、第2の実行環境
と、第2の実行環境のために第2のコミット手順を調整す
る第2の同期点マネジャがある。共通の回復ファシリテ
ィが、第1および第2のコミット手順を回復するため、第
1および第2の同期点マネジャに結合されている。共通の
回復ログが、システム内のすべての実行環境のために、
回復ファシリティによって使用される。異なるシステム
は、通信ファシリティによって相互接続され、そのそれ
ぞれが、それ自体の回復ファシリティと回復ログを有す
る。同じ実計算機内の第1実行環境と第2実行環境の間で
保護された会話が開始でき、それぞれの実行環境内の同
期点マネジャが、この保護された会話に関連する2段階
のコミット手順を調整する。各実計算機内の会話マネジ
ャが、第1実行環境と第2実行環境の間での会話の経路選
択を助ける。

【００１８】各資源マネジャは、この実計算機の内部に
あろうと外部にあろうと、それ自体の回復ログを有する
が、その資源にアクセスする実計算機の回復ファシリテ
ィを使用する。

【００１９】

【実施例】図面で、複数の図を通じて同じ要素は同じ参
照番号で示す。図1には、従来技術によるLU6.2同期点タ
ワー・モデルまたはアーキテクチャが示されている。こ
のアーキテクチャは、1つの実行環境として定義されて
いる。この例では、3つのアプリケーション・プログラ
ム14、16および18が、実行環境12内で時分割式に実行さ
れる。資源マネジャ26および27は、DB/2またはCICSファ
イル制御装置(DB/2およびCICSはIBMコーポレーションの
商品)であり、それぞれ資源22および24へのアクセスを
制御する。DB/2(CCIS/MVSオペレーティング・システム)
またはSQL/DS(CCIS/VSEオペレーティング・システム)資
源マネジャが実行環境12の外部にある場合、実行環境12
は、従来技術によって資源マネジャへインタフェースす
る資源アダプタを含むことになる。この従来技術のアー
キテクチャでは、アプリケーション・プログラム14は、
同期点マネジャ20に対して資源22および24を呼び出す作
業要求を行った後で、その作業要求に含まれる資源のコ
ミットを要求する。

【００２０】次に、アプリケーション・プログラム14
は、以前の作業要求のデータ更新をコミットするため、
同期点マネジャ20からのコミットを要求する。これに応
答して、同期点マネジャ20は、資源マネジャ26および27
をポーリングして、それらが資源をコミットする準備が
できているか否かを判定し、準備ができている場合は続
いてそのコミットを指令することによって、2段階のコ
ミット手順を実施する。この2段階コミット手順の各段
階(および各段階の各ステップ)で、同期点マネジャ20
は、2段階コミット手順の状態を示す同期点情報をログ3
0に転送する。この2段階コミット手順中に障害が発生し
た場合、同期点マネジャは、資源を整合性のある状態に
するために、同期点回復手順を実施する。同期点マネジ
ャは、ログ30内の同期点情報を用いて、中断以前に2段
階コミット手順がどこまで進行したかを決定する。

【００２１】アプリケーション・プログラム14、16また
は18のうちのいずれかが、保護会話マネジャ40を介して
保護された会話を使用して、同一システム内の別の環境
内にあるパートナ・アプリケーション(図示せず)、また
は通信ファシリティを介して相互接続された別のシステ
ム内にあるパートナ・アプリケーション(図示せず)の通
信を試みるときにも、同期点マネジャ20と2段階コミッ
ト手順が使用される。この従来技術の同期点アーキテク
チャによれば、この別のシステムまたは別の環境は、実
行環境12と機能的に同等であり、20と機能的に同等な別
の同期点マネジャ、30と機能的に同等な別の同期点ロ
グ、40と機能的に同等な別の保護会話マネジャ、ならび
に26および27と機能的に同等な別の資源マネジャを含
む。この別の環境は、実行環境12のそれとは独立した、
調整機能および回復機能を提供する。

【００２２】 保護された資源の調整式同期点管理 図2には、本発明による同期点アーキテクチャが示され
ている。本発明は、UNIX環境、OS/2環境、OS/2オペレー
ティング・システム内のDOS環境、仮想計算機オペレー
ティング・システム内のCMS環境、仮想計算機オペレー
ティング・システム内のAIX環境、仮想計算機オペレー
ティング・システム内のCICS環境、仮想計算機オペレー
ティング・システム内のMUSIC環境など、それ自体の実
行環境内で実行される分散式および非分散式のアプリケ
ーションをサポートする、分散コンピュータ・オペレー
ティング・システムを含む。分散アプリケーションは、
別の実行環境内の資源を使用するか、あるいは別の実行
環境内のパートナ・アプリケーションとの通信会話(特
別なタイプの資源)を有することを特徴とする。資源マ
ネジャまたはパートナ・アプリケーションの実行環境
は、同一のシステム内にあっても、異なるシステム内に
あってもよく、同一形式の環境であっても、異なる環境
であってもよい。分散アプリケーション実行環境は、ア
プリケーションをそれ自体の環境内でサポートする1つ
または複数のシステムを含む。前記の環境が必要な資源
をすべて含む必要はない。これらの資源は、他所に分散
されており、通信ファシリティを使って獲得される。分
散アプリケーションの完全な環境は、すべての機能を備
えるように見える。というのは、分散アプリケーション
は、他の環境にある資源、特に回復ファシリティと通信
ファシリティを必要とするからである。

【００２３】本発明は、1つまたは複数のシステム(実計
算機または中央電子処理装置群(CEC))50Aおよび50Dを含
む。この実施例では、システム50Aは、複数の同等な分
散アプリケーション環境52A、52B、52C、システム制御
プログラム55Aの一部である会話マネジャ53Aと実行環境
制御プログラム61A、61B、61C、および回復ファシリテ
ィ70Aを含む。限定ではなく例として示すと、分散アプ
リケーション環境52A、52B、52Cはそれぞれ、拡張バー
ジョンの仮想計算機であってよく、回復ファシリティ70
Aは、別の拡張バージョンの仮想計算機に常駐でき、シ
ステム制御プログラム55Aは、仮想計算機である分散ア
プリケーション環境52A、52B、52C用の拡張バージョン
の仮想計算機オペレーティング・システムであってよ
い。実計算機であるシステム50A内の分散アプリケーシ
ョン環境52Aないし52C内で実行されるアプリケーション
は、実計算機であるシステム50D内または他のシステム
(図示せず)内で実行される同様の分散アプリケーション
環境内で実行されるパートナ・アプリケーションと、通
信ファシリティ57Aおよび57Dを介して通信できる。たと
えば、通信ファシリティ57Aは、仮想記憶通信アクセス
方式(“VTAM”)ファシリティと、APPC/VM VTAMサポー
ト(AVS)ゲートウェイ・ファシリティを含む。各分散ア
プリケーション環境52は、単一の同期点マネジャ(SPM)6
0Aと、複数の保護資源アダプタ62A、62Bおよび64Aを含
む。同期点マネジャを用いると、変更がアトミックにみ
える形で、関連する1群の更新をコミットまたはバック
アウト(取消し)できるようになる。同期点間で実行され
る更新(すなわち、コミットまたはバックアウト)は、作
業論理ユニットと称し、関連する更新は、回復ファシリ
ティを介して同期点マネジャによって割り当てられた、
作業論理ユニット識別子と称する一義的な名前で識別さ
れる。作業論理ユニットは、同一の分散アプリケーショ
ン環境内のアプリケーションからアクセスされる複数の
保護された資源を含むことができ、また他のアプリケー
ション環境内のパートナ・アプリケーションから保護さ
れた資源の1タイプである会話を介してアクセスされる
保護された資源を含むこともできる。

【００２４】会話とは、2つのパートナ・アプリケーシ
ョンの間で体系的に確立された経路である。各アプリケ
ーションによる会話の使用は、そのアプリケーションの
設計と、使用される会話のパラダイムによって決定され
る。会話が同期点処理に含まれる場合、これを保護され
た会話と称する。保護された資源は、下記「コミット手
順のための資源の登録」で説明する登録と称する処理を
介して同期点マネジャとコンタクトすることによって、
作業論理ユニットの一部になる。各保護資源アダプタ
は、アプリケーションならびに同期点マネジャに資源マ
ネジャへのインタフェースを提供する。(資源マネジャ
がアプリケーションと同一の実行環境内に常駐する場合
には、その代わりに、保護資源アダプタを資源マネジャ
と組み合わせることができる）。

【００２５】この実施例では、保護された資源は、ファ
イルと会話である。本発明の他の実施例では、保護され
た資源は、データベース・テーブル、待ち行列、遠隔手
順コールその他であってよい。保護資源アダプタ62Aお
よび62Bは、それぞれ、アプリケーション56Aのために、
ファイル78Aおよび78Bを管理する資源マネジャ63Aおよ
び63Bへのインタフェースを取り扱う。資源マネジャ63A
および63Bは、同一のシステム内にある。また、これら
が通信ネットワーク内の異なるシステム内に常駐するこ
ともできる。この実施例で、会話は会話マネジャによっ
て管理される。会話マネジャは、あるアプリケーション
から、同一システム内の異なる分散アプリケーション環
境内、または通信ネットワーク内の異なるシステム内の
異なる分散アプリケーション環境内で実行される他のパ
ートナ・アプリケーションへの会話または経路を管理す
る。保護された会話が、同一システム内の異なるアプリ
ケーション環境内で実行される2つのアプリケーション
・パートナの間、たとえばアプリケーション環境52Aお
よび52Bで実行されるアプリケーションの間で行われる
場合、会話マネジャは、システム50Aのシステム制御プ
ログラム55Aに含まれ、各保護会話アダプタ64Aおよび64
B(図示せず)を介してアプリケーション・パートナの間
で通信が行われる。保護された会話が、異なるシステム
内の異なるアプリケーション環境の間、たとえばアプリ
ケーション環境52Aおよび52Dで実行される2つのアプリ
ケーション・パートナの間で行われる場合、通信ファシ
リティ57Aおよび57Dを介してシステム50A内の会話マネ
ジャ53Aとシステム50D内の会話マネジャ53Dの間で通信
が行われる。この実施例では、このような通信は、対等
通信フォーマットを使用する。会話マネジャ53Aおよび5
3Dは、通信ファシリティ57Aおよび57Dと通信するのに、
環境内フォーマットを使用する。通信ファシリティ57A
および57Dは、環境内フォーマットから体系的システム
間通信標準フォーマットに、またその逆に変換する。た
とえば、この体系的システム間通信標準フォーマット
は、IBMのシステム・ネットワーク体系、LU6.2プロトコ
ルによって定義されるタイプのものでよい。

【００２６】回復ファシリティ70Aは、実計算機である
システム50A内の分散アプリケーション環境52A、52B、5
2Cのすべてにサービスする。回復ファシリティ70Aはロ
グ72Aを含み、その処理は、同期点マネジャ60A、60B、6
0Cに対するロギングを取り扱い、すべての分散アプリケ
ーション環境52A、52B、52Cのために、障害が発生した
同期点の回復を行う。システム50D上の回復ファシリテ
ィ70Dとそのログ72Dおよび同期点マネジャ60Dについて
も同様である。

【００２７】分散アプリケーション環境52A内のアプリ
ケーション56Aが、ファイル78Aおよび78Bを更新したい
場合、アプリケーション56Aは、アプリケーション56A内
のファイル・アプリケーション・プログラム・インタフ
ェースを介して、別々の2つの更新要求を行う。これら
の要求は、それぞれファイル78Aおよび78Bのための保護
資源アダプタ(以下、このタイプの資源に関しては保護
ファイル・アダプタＰFAと呼ぶ)62Aおよび62Bを呼び出
す(図3のステップ500)。資源マネジャ特有の実施様態に
基づいて、保護ファイル・アダプタは、このファイルが
保護されていることを知る。まだこの作業ユニットに関
して同期点マネジャに登録されていない場合、保護ファ
イル・アダプタ62Aおよび62Bは、この作業ユニットに関
するすべてのコミット要求およびバックアウト要求に関
わりたいと、同期点マネジャ60Aに登録する(ステップ50
2)。「作業ユニット」とは、ある同期点に参加する、そ
のアプリケーションから直接アクセス可能であり可視で
ある、すべての資源をグループにまとめたものであり、
通常、作業論理ユニット識別子と関連づけられている。
作業ユニットに関するさらに詳しい説明は、下記の「作
業ユニットに合わせて調整されたローカルおよびグロー
バルなコミット範囲」を参照されたい。次に、保護ファ
イル・アダプタ62Aおよび62Bは、それぞれ当該の資源マ
ネジャ63Aおよび63Bにコンタクトして、それぞれファイ
ル78Aおよび78Bを更新し(ステップ504)、アプリケーシ
ョン56Aに戻る。次に、アプリケーション56Aは、同期点
マネジャ60Aに、同期点58Aを要求する、すなわち、この
場合はコミットを要求する(ステップ506)。これに応答
して、同期点マネジャ60Aは、保護ファイル・アダプタ6
2Aおよび62Bとそのそれぞれの資源マネジャ63Aおよび63
Bによって表されるその登録された資源である、ファイ
ル78Aおよび78Bのために実行すべき、2段階コミット手
順を開始する。ステップ508で、同期点マネジャ60Aは、
段階1の「準備」コールで、登録されたその各資源を、
登録中に各資源アダプタから同期点マネジャに与えられ
たアダプタ同期点出口入口点で呼び出す。

【００２８】その2段階コミット手順を実行する間に、
同期点マネジャ60Aは、回復ファシリティ70Aに要求を発
行して、段階1の同期点マネジャ情報をログ72Aに強制ロ
ギング(「強制ロギング」とは、同期点マネジャ60Aに戻
る前に、確実に情報が実際の物理装置に書き込まれるよ
うにすることを意味する)させる(ステップ508)。この情
報には、作業論理ユニット識別子、同期点マネジャの状
態および、このコミット要求に参加する登録された各保
護資源アダプタに関する名前その他の関連情報が含まれ
る。この情報は、保護ファイル・アダプタ62Aおよび62B
が登録された時に、同期点マネジャ60Aに与えられたも
のである。同期点マネジャ60Aの状態は、準拠する2段階
コミット・パラダイムの規則によって決定される。たと
えば、この2段階コミット・パラダイムは、IBMコーポレ
ーションの刊行物“System Network Architecture LU
6.2 Reference: PeerProtocols, SC31-6808, Chapter
5.3Presentation Services - Sync Point verbs”に記
載されているタイプのものである。この同期点処理の間
に障害が発生した場合、同期点マネジャの状態を使用し
て、作業論理ユニットの結果(コミットまたはバックア
ウト)を決定する。この実施例で使用する2段階コミット
・パラダイムの規則によれば、同期点マネジャの段階1
の状態は、「開始側(Initiator)」、「同期点マネジャ
保留中(SyncpointManager Pending)」である。2段階コ
ミット手順の第1段階が中断されずに完了した場合(判断
ブロック512)、同期点マネジャ60Aは、回復ファシリテ
ィ70Aに第2の要求を発行して、ログ72Aにその段階2の状
態を強制ロギングさせる。保護ファイル・アダプタと資
源マネジャからの回答と、使用している2段階コミット
・パラダイムの規則とに基づいて、同期点マネジャ60A
は、その第2段階の決定を知る。この実施例では、この
パラダイムは以下のようなものである。1つまたは複数
の保護資源アダプタが、段階1の要求に対して「バック
アウト」と回答した場合、段階2の決定は「バックアウ
ト」である。すべてが「要求コミット」と回答した場
合、決定は「コミット」である。図3に示した例では、
保護ファイル・アダプタ62Aおよび62Bは、「要求コミッ
ト」と回答し(ステップ510)、段階2の状態は、同期点マ
ネジャ60Aによって、「開始側コミット済み(Initiator
Committed)」としてロギングされる。この例では、ファ
イル・マネジャ63Aおよび63Bは、段階1の要求に対して
それぞれの保護ファイル・アダプタ62Aおよび62Bを介し
て「要求コミット」と回答した後、「不確定(indoub
t)」の状態になる、すなわち、それらのファイル・マネ
ジャは、同期点マネジャ60Aからの段階2の決定に基づい
て、ファイル更新をコミットまたはバックアウトできる
ことに留意されたい。

【００２９】ロギングの後、同期点マネジャ60Aは、保
護ファイル・アダプタ62Aおよび62Bに対して、コミット
の決定と共に段階2のコールを発行する(ステップ513)。
ファイル・マネジャ63Aおよび63Bは段階2のコミットの
決定を受け取った時、それぞれ先に進んで、データをコ
ミットするのに、すなわち更新を恒久的にするのに必要
なことを何でも行う(ステップ516)。成功の回答が、当
該のファイル・マネジャに代わって保護ファイル・アダ
プタ62Aおよび62Bから送られ、同期点処理に中断がなか
った場合(判断ブロック514)、同期点マネジャ60Aは、回
復ファシリティ70Aを呼び出して、この作業論理ユニッ
トに関してログ72Aに「忘却(forget)」の状態を書き込
む(ステップ515)。これは強制ログ書込みである必要は
ない。すなわち、ログ・レコードをデータ・バッファに
書込んだ後、同期点マネジャ60Aに戻ることができる。
このバッファは、後の時点で物理媒体に書き込むことが
できる。この実施例で使用する2段階コミット・パラダ
イムに基づいて、同期点マネジャ60Aは、作業論理ユニ
ット識別子を更新し(1つだけ増分する)、これによっ
て、アプリケーション56Aの行う次の作業論理ユニット
が一義的であることを保証する。次に同期点マネジャ
は、アプリケーション56Aに戻る(ステップ515A)。

【００３０】この2段階コミット・パラダイムは、回復
処理用の規則をもち、したがって、回復ファシリティ70
Aは、中断された同期点を完了する方法(ステップ517お
よび図4)を知っている。同期点マネジャ60Aの処理が中
断された場合、判断ブロック514からステップ517に進
み、同期点マネジャ60Aが回復ファシリティ70Aにコンタ
クトする。ステップ517で、回復ファシリティ70Aは、同
期点マネジャ60Aから、作業論理ユニット識別子と、障
害を発生した1つまたは複数の関連する資源に関する情
報を受け取る。次に回復ファシリティ70Aは、正しいロ
グ・エントリを見つける(図4のステップ518)。このログ
情報を使用される2段階コミット・パラダイムと組み合
わせて用いると、回復ファシリティ70Aの手順で、中断
された同期点処理が完了できるようになる(ステップ51
9)。この例で使用される2段階コミット・パラダイムに
基づくと、ログ72A上の作業論理ユニット識別子に対す
る同期点状態エントリが「開始側、同期点マネジャ保留
中」である場合、障害を発生した資源マネジャ63Aまた
は63Bはそれぞれ、バックアウトするよう命じられる。
そうでない場合は、各資源マネジャは、ログ上にある同
期点マネジャの段階2の状態、すなわちコミットまたは
バックアウトを命じられる(ステップ520)。回復状態が
決定された後、回復ファシリティ70Aは、下記「保護さ
れた資源を回復するためのログ名の交換」および「分散
アプリケーション用の未完了の同期点のための回復ファ
シリティ」に記載するように、障害を発生した各保護資
源マネジャで回復処理を開始する。この処理は、ログ名
の交換と状態の比較からなり、これによって回復ファシ
リティ70Aの回復処理は、障害を発生した資源マネジャ6
3Aまたは63Bに、行うべきこと、すなわちコミットまた
はバックアウトを命じ、資源マネジャ63Aまたは63Bは、
それが行ったことを回復処理に伝える。回復ファシリテ
ィ70Aの回復処理は、同期点マネジャ60Aがその段階1の
ロギング活動中に書き込んだ情報に基づいて、障害を発
生した資源にコンタクトする方法を知る。障害を発生し
た資源マネジャがコンタクト可能である場合は(判断ブ
ロック521)、即座に回復が行われる(ステップ522)。障
害を発生した各資源で回復が行われた後(判断ブロック5
23)、同期点マネジャ60Aに戻ることができる(ステップ5
23A)。その後、同期点マネジャ60Aは、アプリケーショ
ン56Aに戻る(ステップ515A)。障害を発生した資源マネ
ジャがコンタクト不能である場合は、判断ブロック521
から判断ブロック524へ進み、回復ファシリティ70Aは、
アプリケーション56Aに戻る前に回復処理を完了しなけ
ればならないか否かを検査する。この判定は、段階1の
ロギング中に同期点マネジャが書き込んだ、作業論理ユ
ニットに対するログ・レコードに含まれる情報に基づい
て行われる。回復を完了させなければならない場合、回
復処理は、障害を発生した資源とコンタクトしようと試
み続ける(ステップ525)。回復を後の時点で完了してよ
い場合、すなわち回復を待つことが以前に選択されてい
る場合、回復ファシリティ70Aは、下記「コミット手順
の非同期的再同期化」に記載のように、同期点マネジャ
60Aに戻って、回復処理(すなわち、コミットまたはバッ
クアウト)の意図と、回復が後で完了されるとの指示と
を戻す(ステップ526)。すべての資源が回復された時(ス
テップ525A)、同期点マネジャ60Aは、アプリケーション
56Aにこの情報を戻す(ステップ515)。

【００３１】図2はまた、アプリケーション56Aが分散ア
プリケーションの一部であり得ることを示している。こ
れは、アプリケーション56Aと共同してその処理を完了
することのできるパートナ・アプリケーションが、少な
くとも1つ存在することを意味する。分散アプリケーシ
ョンを確立するために、アプリケーション56Aは、保護
された会話を開始する。この保護された会話は、アプリ
ケーション・プログラム会話開始インタフェースを呼び
出すことによってシステム50D内のパートナ・アプリケ
ーション56Dを起動し、この会話が保護すべきものであ
ることを示す(図5、ステップ530)。この要求は、保護会
話アダプタ64Aによって処理される。保護会話アダプタ6
4Aは、同期点マネジャ60Aに作業論理ユニット識別子を
求め、これを一義的な会話識別子と一緒に、遠隔システ
ム50Dに送る情報に含める。次に、保護会話アダプタ64A
は、この要求を会話マネジャ53Aに送り、会話マネジャ5
3Aは、これを通信ファシリティ57Aに送る。保護会話ア
ダプタ64Aは、会話開始要求が通信ファシリティ57Aから
通信ファシリティ57Dに送られた(またはこれから送られ
る)旨の指示を得る。この時、保護会話アダプタ64Aは、
同期点マネジャ60Aに登録する(ステップ532)。会話開始
要求は、この登録処理とは非同期に、通信ファシリティ
57Dに送られ、次に会話マネジャ53Dに送られ、次に保護
会話アダプタ64Dに送られる(図5のステップ532)。保護
会話アダプタ64Dは、作業論理ユニット識別子と一義的
な会話識別子を検索し、会話マネジャのために同期点マ
ネジャに登録する(ステップ532)。また、この時、保護
会話アダプタ64Dは、会話開始要求時に受け取った作業
論理ユニット識別子を同期点マネジャ60Dに与える。ア
プリケーション56Dによって行われた保護された作業
が、最初にアプリケーション56Aによって開始されたこ
の作業論理ユニット識別子と関連づけられる(ステップ5
32)。また、この作業論理ユニット識別子が、アプリケ
ーション56D用の新しい作業ユニットに割り当てられ、
その後アプリケーション56Dが開始される。

【００３２】したがって、アプリケーション56Aと56D
は、パートナ・アプリケーションであり、これらをまと
めて分散アプリケーションと称する。保護された会話を
用いると、アプリケーション56Aと56Dが、対等にデータ
を送受できるようになる。これは、アプリケーション56
Aまたはアプリケーション56Dのどちら側からも送信また
は受信を開始でき、それが、アプリケーションの製作者
と、通信マネジャが使用するパラダイムとによって決定
されることを意味する。上述したように、保護された会
話は、それぞれ保護会話アダプタ64Aおよび64Dによっ
て、両方の同期点マネジャに登録される。最初のコミッ
トを発行したアプリケーションに対する同期点処理の
間、保護会話アダプタは、同期点マネジャに対して資源
を代理し、要求された作業をコミットできるか否か(第1
段階)、およびそれを成功裡に達成したか否か(第2段階)
を応答しなければならない。パートナの保護会話アダプ
タから第1段階のコールを受け取るもう一方の保護会話
アダプタにとって、保護された会話はパートナの同期点
マネジャであり、それを介して段階1と段階2の指令を受
け取る。そのローカル同期点マネジャは、資源マネジャ
のように振る舞う。すなわち、保護会話アダプタは、同
期点マネジャの資源が行ったことの結果を受け取る(段
階1および段階2)。使用される同期点パラダイムは、ア
プリケーション・パートナが第1のコミットを発行する
規則を提供することに留意されたい。この例では、どの
アプリケーション・パートナも、最初にコミットを発行
することができ、このことは分散アプリケーションの設
計によって決まる。

【００３３】アプリケーション56Aは、開始要求が通信
ファシリティ57Aから成功裡に送られた旨の指示と共に
制御を得る。この時点で、アプリケーション56Aは、ア
プリケーション56Dに要求を送ることができ、アプリケ
ーション56Aは、確立された会話を介してアプリケーシ
ョン56Dに要求を送る。この例では、最終的にこの要求
は、アプリケーション56Dにファイル・アプリケーショ
ン・プログラム・インタフェースを呼び出させて、ファ
イル78Dを更新させる。上述したように、この更新要求
は、保護ファイル・アダプタ62Dに、(アプリケーション
56Dが開始された時にアプリケーション56Dに割り当てら
れた(ステップ532))同一の作業ユニットの下で、同期点
マネジャ60Dに登録させる(ステップ533)。また、ステッ
プ533で、アプリケーション56Dは、会話を介してアプリ
ケーション56Aに、作業を完了したことを示す応答を送
る。次に、アプリケーション56Aは、ファイル78Aおよび
78Bに関する更新要求を発行する。上述したように、保
護ファイル・アダプタ62Aおよび62Bは、すでに同期点マ
ネジャ60Aに登録済みであり、それぞれ資源マネジャ63A
および63Bにコンタクトしてこの更新を実行する(ステッ
プ533および533A)。

【００３４】ここでアプリケーション56Aは、同期点マ
ネジャ60Aにコミット58Aを発行する(ステップ534)。上
述したように、同期点マネジャ60Aは、回復ファシリテ
ィ70Aにコンタクトしてその段階1のロギングを求め、登
録された各資源に対して段階1の「準備」コールを発行
する(ステップ534Aおよび535A)。保護ファイル・アダプ
タ62Aおよび62Bは、上述したように振る舞う。保護会話
アダプタ64Aは、段階1の「準備」コールを受け取った
時、それが代理する保護された会話、すなわち最初にア
プリケーション56Aによってアプリケーション56Dに対し
て確立された会話を介して、体系的システム間「準備」
コールを送る(ステップ535)。保護会話アダプタ64Dは、
この「準備」コールを認識して、会話メッセージ受取コ
ールを発行したアプリケーション56Dに、コミットの発
行を要求する戻りコードを与える(ステップ536)。次
に、アプリケーション56Dは、同期点マネジャ60Dに対し
てコミット58Dを発行する(ステップ537)。上述したよう
に、同期点マネジャ60Dはその回復ファシリティにコン
タクトするが、この場合は、回復ファシリティ70Dにコ
ンタクトして、段階1情報をログ72Dに強制ロギングさせ
る(ステップ538)。アプリケーション56Aが元のコミット
要求を発行し、その要求に応じてアプリケーション56D
が後でコミットを発行したので、この実施例で使用する
2段階コミット・パラダイムに基づくと、同期点マネジ
ャ60Dの段階1の状態は「開始側カスケード、同期点マネ
ジャ保留中(Initiator Cascade,Syncpoint Manager Pen
ding)」である(ステップ538)。同期点マネジャ60Dは、
段階1の「準備」コールを用いて保護ファイル・アダプ
タ62Dにコンタクトする(ステップ538)。保護ファイル・
アダプタ62Dとそれに関連する資源マネジャ63Dは、上述
したように段階1の処理を実行し、「コミット要求」の
回答を戻す。

【００３５】この例では、中断がなかったので、判断ブ
ロック539からステップ540に進み、同期点マネジャ60D
が、回復ファシリティ70Dにコンタクトして、ログ72Dを
「代理、不確定(Agent,Indoubt)」の状態に強制ロギン
グさせる。この状態は、その後に中断が起こり、その結
果、同期点マネジャ60Dが、同期点マネジャ60Aから段階
2の決定を受け取らなくなる場合、回復ファシリティ70A
からの回復処理がその同期点処理を完了するのを待たな
ければならないことを意味する。次に、同期点マネジャ
60Dは、保護会話アダプタ64Dにコンタクトして「コミッ
ト要求」の回答を与える。次に、保護会話アダプタ64D
は、体系的システム間フォーマットの「コミット要求」
を保護会話アダプタ64Aに送り(ステップ541)、保護会話
アダプタ64Aは、同期点マネジャ60Aに「コミット要求」
と回答する(ステップ542)。上述したように、同期点マ
ネジャ60Aは保護ファイル・アダプタ62Aおよび62Bから
「コミット要求」を受け取った(ステップ535A)。この例
では中断がないので、判断ブロック543からステップ544
に進み、同期点マネジャ60Aが回復ファシリティ70Aにコ
ンタクトして、ログ72Aを段階2の「開始側、コミット済
み(Initiator,committed)」の状態に強制ロギングさせ
る(ステップ544)。次に、同期点マネジャ60Aは、段階2
の「コミット済み」の決定で、登録された各保護資源ア
ダプタを呼び出す(図6、ステップ545)。保護ファイル・
アダプタ62Aおよび62Bは、上述したようにこのコミット
の決定を処理する(ステップ545A)。保護会話アダプタ64
Aは、このコミット決定を受け取った時、それが代理す
る保護会話、すなわち最初にアプリケーション56Aによ
ってアプリケーション56Dに対して確立された会話を介
して、体系的システム間フォーマットの「コミット済
み」コールを送る(ステップ546)。保護会話アダプタ64D
は、この「コミット」コールを受け取り、同期点マネジ
ャ60Dに段階2の「コミット」の決定を回答する(ステッ
プ547)。

【００３６】上述したように、同期点マネジャ60Dは、
回復ファシリティ70Dにコンタクトして、ログ72Dを段階
2の状態に強制ロギングさせる。アプリケーション56A
が、元のコミット要求を発行し、それに応じてアプリケ
ーション56Dが後でコミットを発行したので、この実施
例で使用する2段階コミット・パラダイムに基づいて、
同期点マネジャ60Dの段階2の状態は「開始側カスケー
ド、コミット済み」である(ステップ548)。同期点マネ
ジャ60Dは、保護ファイル・アダプタ62Dにコンタクトし
てこの段階2のコミットの決定を与える(ステップ549)。
保護ファイル・アダプタ62Dとそれに関連する資源マネ
ジャ63Dは、上述のコミット処理を行い、「忘却」の回
答を戻す。中断がなかった(判断ブロック550)ので、同
期点マネジャ60Dは回復ファシリティ70Dにコンタクトし
て、この作業論理ユニットに対する同期点ログ・レコー
ドに対して、状態「忘却」をログ72Dにロギングさせる
(ステップ551)。「忘却」は、同期点処理が完了し、そ
のログ・レコードが消去可能であることを意味する。次
に、同期点マネジャ60Dは、保護会話アダプタ64Dとコン
タクトして、「忘却」の回答を与える。この実施例で使
用する2段階コミット・パラダイムに基づいて、同期点
マネジャ60Dは、作業論理ユニット識別子を1だけ増分
し、アプリケーション56Dに、コミットが成功裡に完了
したとの指示を戻す(ステップ552)。作業論理ユニット
識別子を更新することによって、分散アプリケーション
が行う次の作業論理ユニットが一義的であることが保証
される。

【００３７】次に、保護会話アダプタ64Dは、体系的シ
ステム間フォーマットの「忘却」の回答を保護会話アダ
プタ64Aに送り、保護会話アダプタ64Aは、同期点マネジ
ャ60Aに「忘却」を回答する(ステップ553)。上述したよ
うに、同期点マネジャ60Aは、保護ファイル・アダプタ6
2Aおよび62Bからも「忘却」の回答を受け取る(ステップ
545A)。中断がないと仮定すると、判断ブロック554から
ステップ555に進んで、同期点マネジャ60Aは、回復ファ
シリティ70Aにコンタクトして、この作業論理ユニット
に対して、状態「忘却」をログ72Aにロギングさせる。
やはり、使用する2段階コミット・パラダイムに基づい
て、次に同期点マネジャ60Aは作業論理ユニット識別子
を1だけ増分する(ステップ556)。この変更によって、分
散アプリケーションに対する次の作業論理ユニット識別
子が一義的であることが保証される。次に、同期点マネ
ジャ60Aは、このコミット要求が成功裡に完了した旨を
アプリケーション56Aに通知する。2段階コミット手順中
に、同期点マネジャ60Aまたは同期点マネジャ60Dまたは
その両方内で同期点処理が中断された場合、回復ファシ
リティ70Aおよび回復ファシリティ70Dは、論理流れの中
でステップ557と558およびステップ559と560で表される
回復動作を実施することになる。この回復動作は、下記
「保護された資源を回復するためのログ名の交換」、
「分散アプリケーション用の未完了の同期点のための回
復ファシリティ」および「コミット手順の非同期的再同
期化」にさらに詳しく説明されている。

【００３８】図61および図62は、図2の実施例の代替実
施例であり、図2と比較して説明するのが最適である。
図2ならびに図61および図62では共に、アプリケーショ
ン環境、システム・ファシリティおよび資源マネジャが
分散されている。しかし、図2では、1つの物理装置、シ
ステム50Aが、複数のアプリケーション環境52A、52B、5
2C、2つの資源マネジャ63A、63B、回復ファシリティ70A
および通信ファシリティ57Aを含んでいる。図2では、シ
ステム制御プログラム55Aは、会話マネジャ53Aおよび同
期点マネジャ60A、60B、60Cを含んでいる。図2のシステ
ム50Aは、メインフレーム・コンピュータであってよ
く、このタイプの構成は、しばしば集中コンピュータ処
理と呼ばれる。また、図2では、システム50A内のアプリ
ケーション環境が、通信ネットワークを介してシステム
50D内のアプリケーション環境に接続されている。これ
とは対照的に、図61および図62では、アプリケーション
環境、システム・ファシリティおよび資源マネジャが、
それぞれ別々の実計算機内にある。この構成は、分散コ
ンピュータ処理と呼ばれる。この環境では、システム90
A、90B、90C、110E、114F、120Gは、プログラム式ワー
クステーションであって、図2のシステム50Aおよび50D
に機能は類似しているが、サイズや性能は必ずしも類似
していない。図61および図62のシステムは、たとえばロ
ーカル・エリア・ネットワーク(ＬAＮ)などの通信ネッ
トワークによって接続される。図61のアプリケーション
環境92A、92B、92Cは、図2のアプリケーション環境52
A、52B、52Cと機能は同等である。しかし、アプリケー
ション環境92A、92B、92Cはそれぞれ、別々のプログラ
ム式ワークステーションに含まれている。図61のシステ
ム制御プログラム95A、95B、95Cはそれぞれ、図2のシス
テム制御プログラム55Aと機能的に同等である。システ
ム制御プログラム95A、95B、95Cはそれぞれ、(ａ)同期
点マネジャ60A、60B、60Cと機能的に同等な同期点マネ
ジャ100A、100B、100C、(ｂ)実行環境制御プログラム61
A、61B、61Cと機能的に同等な実行環境制御プログラム9
1A、91B、91C、(ｃ)保護会話アダプタ(ＰCA)64A、64B、
64Cと機能的に同等な保護会話アダプタ104A、104B、104
C、(ｄ)資源アダプタ(ＲA)62Aおよび62Bと機能的に同等
な資源アダプタ102A、102B、102C、および103A、103B、
103C、(ｅ)会話マネジャ53A、53B、53Cと機能的に同等
な会話マネジャ93A、93B、93C、および通信ファシリテ
ィ57Aと機能的に同等な通信ファシリティ97A、97B、97C
を含む。しかし、図61の例では、通信ファシリティは各
システム制御プログラム95A、95B、95Cの一部であっ
て、それ自体の実行環境に含まれてはいない。また、図
62では、資源マネジャ112Eおよび113Fは、図2の資源マ
ネジャ63Aおよび63Bと機能的に同等であり、それらのフ
ァイル115E、117Fおよびログ116E、118Fは、図2のファ
イル78A、78Bおよびログ800A、800Bと機能的に同等であ
る。しかし、資源マネジャ112Eおよび113Fは、それぞれ
別々のプログラム式ワークステーション上にある。図62
の回復ファシリティ121Gおよびそのログ122Gは、図2の
回復ファシリティ70Aおよびそのログ72Aと機能的に同等
である。しかし、回復ファシリティ121Gは1つのプログ
ラム式ワークステーション内にある。図62のシステム50
Dは、図2のシステム50Dと同一であり、このネットワー
クの融通性を示すために含めてある。この環境での同期
点処理の説明は、上記の同期点処理の説明で、図2の番
号を対応する図61および図62の番号に置き換えることに
よって得られる。したがって、本発明は広範囲なコンピ
ュータ・システムおよびネットワークで実施できる。

【００３９】図2のシステム50A内で、様々な理由から回
復ファシリティ70Aが利用不能になる可能性がある。し
たがって、システム50Aはバックアップを提供する。た
とえば、回復ファシリティ70Aが、資源マネジャをも制
御する実行環境の一部であり、この資源マネジャが動作
不能になる障害に出会った場合、回復ファシリティ70A
も動作不能になる。図31に示した例では、システム50A
は1つの資源マネジャ専用の複数の実行環境を含み、そ
の資源マネジャを含む各実行環境が回復ファシリティ・
プログラムをも含んでいるが、システム内で同時に活動
状態になれる回復ファシリティは1つだけである。

【００４０】具体的に言うと、図31では、システム50A
内に、それぞれ資源マネジャ(プログラム)260A、260B、
260Cを含む3つの同等な実行環境52E、52F、52Gがある。
資源マネジャ260A、260B、260Cはそれぞれ、VM/SPリリ
ース6オペレーティング・システムの共用ファイル・シ
ステム(SFS)資源マネジャの拡張バージョンとそれに関
連する資源262A、262B、262Cであることが好ましい。さ
らに、各実行環境52E、52F、52Gはまた、図26に示した
回復ファシリティ70Aの機能を実現するため、プログラ
ム70A、70B、70Cをも含む。共用ファイル・システムを
含む実行環境内に各回復ファシリティを置くことの利点
は、その共用ファイル・システムに、回復ファシリティ
が使用できるサービス、すなわち通信サービスおよびタ
スク処理サービスが含まれることである。通信サービス
は、通信プロトコル、割込み処理、メッセージ管理を処
理する。図31のシステム50Aでは、回復ファシリティ70A
は、当初、実行環境52Eが初期設定される際に回復ファ
シリティ・ログ72Aに関連づけられる回復ファシリティ
として、システム制御プログラムに識別される。これ
は、実行環境52Eの初期設定処理への入力としてあるパ
ラメータを指定することによって達成される。実行環境
52Eは、システム制御プログラムに対してそれ自体を、
回復ファシリティとして、かつシステム50A内での資源
識別子sync_point_logに対するすべての通信のターゲッ
トとして識別する(資源識別子sync_point_logの説明に
ついては、「保護された資源を回復するためのログ名の
交換」を参照されたい。)。この資源識別子sync_point_
logは、システム50A内で一義的でなければならず、常に
1つの実行環境にしか関連づけることができない。この
実施例では、実行環境52Eが回復ファシリティ・ログ72A
を含む持久記憶域を定義し、その結果、実行環境52Eを
指定すると、別の記憶域を指定するそれに勝る指定がな
い場合、自動的にログ72Aが資源回復ログとして暗示さ
れることになる。

【００４１】ところが、実行環境52Eが利用不能である
場合、ユーザはバックアップとして回復ファシリティ70
Bまたは70Cを活動化し、ログ72Aを実行環境52Fまたは52
Gに移動することができる。これは、実行環境52Fまたは
52Gの初期設定時に前述のパラメータを指定し、この実
行環境に対して回復ファシリティ・ログ72Aの位置を指
定することによって行われる。ユーザがログ72Aの位置
を指定するには、回復ファシリティ・ログ72Aを含む持
久記憶域の位置を識別するのに必要な、選択された実行
環境52Fまたは52Gからのコマンドを、システム制御プロ
グラムに与える。

【００４２】同期点障害の後に再同期化を完了するため
に回復ファシリティが必要とする情報は、すべて回復フ
ァシリティ・ログ72Aに含まれており、同期点回復に必
要な情報は、実行環境、資源マネジャまたは関連する持
久記憶域には含まれていない。したがって、回復ファシ
リティ・プログラムを含む資源マネジャを有するどんな
実行環境も、活動状態の回復ファシリティがログ72Aに
アクセスできる限り、回復ファシリティ70Aとして動作
することができる。回復ファシリティ機能の、実行環境
52Fへのバックアップ転送は、通信経路272Bで示され、
回復ファシリティ機能の、実行環境52Gへのバックアッ
プ転送は、通信経路272Cで示されている。

【００４３】回復ファシリティ70を備えたアプリケーシ
ョン環境内の同期点マネジャ60A、60Bまたは60Cのいず
れかの間で通信を行うには、システム制御プログラムを
介して回復ファシリティに対する会話を開始する際に、
資源識別子sync_point_logを使用する。

【００４４】作業ユニットに合わせて調整されたローカ
ルおよびグローバルなコミット範囲前述の図5および図6
の流れ図には、単一の作業論理ユニットまたはコミット
範囲が、たとえば異なるシステム内の複数の実行環境内
の資源とアプリケーションなど、異なるシステム内の2
つのアプリケーション・パートナに拡がり、コミット手
順がこの2つのアプリケーション・パートナの間で調整
される場合の例が示されている。以下に、この処理、な
らびにシステム50Aが、同一の実行環境内にある同一の
アプリケーションに別々の作業ユニットまたはコミット
範囲を提供できることについて、詳細に説明する。すべ
てのシステム50は、このように1つまたは複数の関連す
る作業ユニットに用いられる資源に合わせてコミット範
囲を正確に調整することができる。

【００４５】上述したように、「作業ユニット」とは、
1つのアプリケーションから直接アクセス可能であり、
共通の同期点に参加する、資源の範囲である。たとえば
(図2において)、資源アダプタ62A、62Bおよび保護会話
アダプタ64Aに結合された資源は、すべてアプリケーシ
ョン56Aから直接アクセス可能であり、したがって、す
べて同一の作業ユニットを有することができる。これら
がすべてアプリケーション56Aによって行われる関連す
る作業要求に用いられる場合、これらはすべて同一の作
業ユニットを有する。作業ユニット識別子は、システム
制御プログラム55によって選択され、それぞれの実行環
境内で一義的である。この実施例では、システム制御プ
ログラム55Aは、会話マネジャ53Aと、各実行環境52用の
実行環境制御プログラム61を含む。限定ではなく例とし
て示すと、実行環境制御プログラム61Aは、VM/SPリリー
ス6オペレーティング・システムの拡張CMS構成要素でよ
い。この実行環境制御プログラムは、アプリケーション
56Aの実行を制御し、上述したように、作業ユニット識
別子を割り当てる。したがって、作業ユニット識別子
は、各実行環境内で一義的である。アプリケーション
は、複数の関連する作業要求に対して同一の作業ユニッ
トを使用し、関連しない作業要求に対しては異なる作業
ユニットを使用する。「作業論理ユニット」識別子と
は、関連する作業要求に使用されるすべての資源に対す
るグローバルに一義的な(ネットワーク全体を通じての)
識別子であり、関連する作業要求をすべてカバーする。
作業論理ユニット識別子は、その作業要求を生成したシ
ステムの回復ファシリティ70によって割り当てられ、こ
の実施例では、下記のものを含む。

【００４６】 (1)相互接続された1群のシステムを識別する、ネットワ
ーク識別子、 (2)そのネットワーク内の1つの通信ファシリティを識別
する、システム識別子、 (3)ローカルに一義的な要素をLUWIDに与える、インスタ
ンス番号(たとえば、タイムスタンプを使用してよい)、 (4)特定の同期点インスタンスを識別する、シーケンス
番号。

【００４７】たとえば、これは、“System Network Arc
hitecture LU6.2 Reference: Peer Protocols, SC31-68
08 Chapter 5.3 Presentation Services - Sync Point
verbs”によって定義されるタイプのものである。同期
点マネジャ60は、保護会話が作業ユニット内で使用され
る場合、または作業要求が保護会話を必要としなくと
も、2段階コミット手順が必要な場合に、回復ファシリ
ティから作業論理ユニット識別子(LUWID)を要求する。L
UWIDは、資源アダプタが同期点マネジャを呼び出すこと
によって要求することができ、またLUWIDがまだ獲得さ
れていないがコミットのために必要な場合には、コミッ
ト処理の始めに同期点マネジャがLUWIDを要求すること
ができる。以下で詳細に説明するように、保護された会
話や多数の保護された資源などの保護された資源が作業
ユニットで使用される時に、作業ユニットがLUWIDと関
連づけられる。作業ユニットは、複数のファイルと複数
のファイル記憶場所の混合物、他の保護された資源と他
の参加する資源マネジャ、およびある分散アプリケーシ
ョンの異なる部分間での保護された会話を含むことがで
きる。保護された会話の場合は、各アプリケーション・
パートナが、この同一の保護された会話とこのアプリケ
ーションによって直接アクセスされる他の資源とに(そ
れぞれの実行環境内で)異なる作業ユニットを割り当て
る場合であっても、単一の作業論理ユニットが、2つ以
上のアプリケーション・パートナの間に拡がる。したが
って、ある保護された会話に関連する各アプリケーショ
ン・パートナはそれぞれ、それ自体の作業ユニットをロ
ーカルに割り当てて使用するが、2つ以上のアプリケー
ション・パートナの作業ユニットは、同一の分散された
作業論理ユニットを参照する。各実行環境は、他の実行
環境で割り当てられた作業ユニットの識別を知らず、異
なる実行環境内の作業ユニットが同一の識別子を有する
ことは、偶然の一致によってしか起こり得ないことに留
意されたい。LUWIDではなく、上述の拡張された範囲を
もつ作業ユニットを使用して、ローカルなコミット範囲
が定義される。というのは、既存のアプリケーション
が、最小限の変更で拡張された機能の利益を享受できる
からである。作業ユニットからLUWIDへの変更は面倒で
あり、既存のアプリケーションを変更する必要がある。

【００４８】図7ないし図11は、同一のアプリケーショ
ン56A用の異なる作業ユニットおよび作業論理ユニット
と、それぞれ異なるシステム50Aおよび50D内で実行され
る複数のアプリケーション・パートナ56Aおよび56Dに関
連づけられた複数の資源に拡がる別の作業論理ユニット
とを確立する処理を、実例によって示した図である。図
8に示した例で、アプリケーション56Aが開始され、実行
環境制御プログラム61Aから作業ユニット識別子Xを得る
(ステップ928)。実行環境制御プログラムは、各実行環
境内で一義的な作業ユニット識別子を選択する責任を負
う。次に、アプリケーション56Aは、実行環境52A内の資
源アダプタ62Aに対して作業要求を行って、資源78A内に
ある1ファイルを更新してこの作業要求を作業ユニットX
の下で行うように、あるいはデフォルトにより、アプリ
ケーション56Aによって指定された「現作業ユニット」
の下に割り当てられるように指定する(ステップ930)。
資源アダプタが作業ユニットX用のLUWIDを要求する場合
(判断ブロック935)、同期点マネジャ60Aは、LUWIDがま
だ割り当てられていなければ、回復ファシリティ70Aか
ら作業ユニットXをカバーするLUWIDを要求し、そのLUWI
Dを作業ユニットXと関連づける。その後、同期点マネジ
ャは、資源アダプタにこのLUWIDを戻す(ステップ936)。
図7に示した例では、(資源アダプタ62Aを介してアクセ
スされた)資源78Aは、保護された会話ではないので、判
断ブロック937(図8)からステップ939に進み、資源が更
新される。資源アダプタ62Aが、まだ作業ユニットXのた
めに登録されていない場合(判断ブロック933)、資源ア
ダプタ62Aを同期点マネジャ60Aに登録する(ステップ93
4)。前述の例では、アプリケーション56Aは、同一の作
業ユニットの下でさらに別の作業を行うことは望まず
(判断ブロック940)、関連しない新規の作業を行うこと
も望まない(判断ブロック941)ので、次のステップで
は、アプリケーション56Aがコミットを発行する(ステッ
プ942)。これに応答して、同期点マネジャ60Aは、1段階
コミット手順を開始する(ステップ944)。ところで、ア
プリケーション56Aは、他の関連しない作業要求を開始
する前に作業ユニットXのためにコミットを発行する必
要がないことに留意されたい(判断ブロック941)。この
特定の場合には、同期点マネジャは、1段階のコミット
手順を実行するので、LUWIDは不要である。

【００４９】この例では、アプリケーション56Aは、次
に作業ユニットXとは独立な作業を行うために、下記の
処理を開始する。アプリケーション56Aは、実行環境制
御プログラム61Aから新規の作業ユニットを要求し、実
行環境制御プログラム61Aは、作業ユニットYを戻す(ス
テップ928)。次に、アプリケーション56Aは、資源アダ
プタ62Bを介して、作業ユニットYの下で資源78Bを更新
する要求を行う(ステップ930)。資源アダプタが作業ユ
ニットY用のLUWIDを要求する場合(判断ブロック935)、
同期点マネジャ60Aは、回復ファシリティ70AからLUWID
を得て、それを作業ユニットYと関連づける(ステップ93
6)。この時、作業ユニットY用の作業論理ユニットは、
資源マネジャ63Bのみに拡がる。次に、資源78Bに対する
更新を実施する(ステップ939)。資源アダプタ62Bは、ま
だ作業ユニットYのために登録されていないので、同期
点マネジャ60Aに登録される(ステップ934)。

【００５０】次に、アプリケーション56Aは、同一の作
業ユニットYの下で、さらに別の作業たとえば他の資源
中のデータの変更を行うことを望む(判断ブロック94
0)。図7に示した例では、この別の作業は保護された会
話であり、この保護された会話が、分散アプリケーショ
ン・パートナ56Dを介してシステム50D内の資源にアクセ
スするのに使用される。この例では、これが新規の保護
された会話の始まりである。すなわち、アプリケーショ
ン56Aは、作業ユニットYの下で、アプリケーション56D
との新規の保護された会話を開始する(ステップ930)。
保護会話アダプタ64Aは作業ユニットY用のLUWIDを要求
するので、LUWIDがまだ割り当てられておらず、作業ユ
ニットに関連づけられていない場合、同期点マネジャ
は、回復ファシリティを呼び出し、保護会話アダプタに
LUWIDを戻す(ステップ936)(保護会話アダプタは、この
会話を開始する時にLUWIDを必要とする(ステップ94
7)。)。次に、判断ブロック937から判断ブロック946に
進む。これは新規の保護された会話であるので、会話マ
ネジャ53Aは、保護された会話を開始し、作業ユニットY
に関連するLUWIDを通信ファシリティに送る(ステップ94
7)。この例では、アプリケーション・パートナ56Dが異
なるシステム内に常駐しているので、通信ファシリティ
57Aを使用する。しかし、アプリケーション・パートナ
が同一のシステム50A内の別の実行環境、たとえば52B内
に常駐している場合は、この通信機能は、システム制御
プログラム55Aの会話マネジャ53Aによって提供され、通
信ファシリティ57Aは使用されないことに留意された
い。保護会話アダプタ64Aが会話マネジャ53Aから制御を
返され、保護会話開始要求が成功したことが示された
時、保護会話アダプタ64Aは、同期点マネジャ60Aに登録
され(ステップ948)、アプリケーション56Aに制御を返
す。この時、アプリケーション56Aは、アプリケーショ
ン56Dにメッセージを送って、資源78Dの更新を要求する
(ステップ949)。ただし、このメッセージは、アプリケ
ーション56Dが開始されるまで、システム50D内にバッフ
ァされる。メッセージを送った後、アプリケーション56
Aはこれ以上行うべき作業がない(判断ブロック940およ
び941)ので、作業ユニットYに対するコミットを発行す
る(ステップ942)。同期点マネジャ60Aが、2段階コミッ
ト手順を開始する(ステップ944)。

【００５１】システム制御プログラム55Dが、通信ファ
シリティ57Dを介して通信ファシリティ57Aから会話開始
要求を受け取った時(図9のステップ960)、システム制御
プログラム55Dは、実行環境52Dを開始する(ステップ96
2)。保護会話アダプタ64Dは、実行環境52D用の新規の作
業ユニットＺを獲得し、この実行環境52D内で、アプリ
ケーション56Dが実行環境制御プログラム61Dから実行さ
れることになる。この作業ユニットは、実行環境52D内
で一義的である。また、保護会話アダプタ64Dは、開始
された会話で受け取ったLUWIDをこの新規の作業ユニッ
トに関連づけるよう同期点マネジャに指令し、その後、
この新規の作業ユニットの下で同期点マネジャ60Dに登
録される(ステップ966)。(ステップ947での会話開始要
求の流れは、保護会話アダプタ64Aから、会話マネジャ5
3A、通信ファシリティ57A、通信ファシリティ57D、会話
マネジャ53Dを経て、保護会話アダプタ64Dへと向か
う。)その後、アプリケーション56Dが開始される。

【００５２】次に、アプリケーション56Dは、ステップ9
30Dで作業要求を行う。この例では、この最初の作業要
求は、会話上でメッセージを受け取ることである。この
保護された会話はすでにLUWIDを有しているので、判断
ブロック935Dから判断ブロック937Dに進む。これは、保
護された会話であるが、新規のアウトバウンドな保護さ
れた会話ではない(すなわち、新規の保護された会話の
開始ではない)ので、判断ブロック937Dおよび946Dから
ステップ949Dに進み、メッセージをアプリケーション56
Dが受け取る。

【００５３】図7以降に示した例では、保護された会話
は、アプリケーション56Dに、追加の作業、たとえば(資
源アダプタ62Dを介して)資源78D内のファイルの更新を
行わせ、したがって判断ブロック940Dからステップ930D
に進み、アプリケーション56Dが、作業ユニットＺを使
用して資源78Dを更新するようにとの作業要求を行う。
資源アダプタがLUWIDを要求する場合(判断ブロック935
D)、同期点マネジャは資源アダプタにLUWIDを戻す(ステ
ップ936D)。ステップ966ですでにLUWIDが割り当てら
れ、作業ユニットに関連づけられているので、回復ファ
シリティを呼び出してLUWIDを割り当てる必要はない。
この作業要求は、保護された会話資源を使用しないの
で、判断ブロック937Dからステップ939Dに進み、作業要
求に従って資源78Dを更新する。資源アダプタ62Dはまだ
登録されていないので、判断ブロック933Dからステップ
934Dに進み、資源アダプタ62Dが同期点マネジャ60Dに登
録される。この時点でアプリケーション56Dは、アプリ
ケーション56Aがいつこの作業のコミットを要求するか
を決定する必要がある。これは、アプリケーション56D
により、保護された会話上で(作業要求を)受け取ること
によって、達成される。アプリケーション56Aがコミッ
トを発行済みの時には、アプリケーション56Dは、戻り
コードTake_Syncpointを得る。したがって、判断ブロッ
ク940Dからステップ930Dに進み、アプリケーション56D
が、作業ユニットＺの下で保護された会話上で受取りを
発行する。保護会話アダプタ64DにはLUWIDが不要であり
(判断ブロック935D)、この作業要求は保護された会話を
使用し(判断ブロック937D)、この保護された会話は新規
のアウトバウンドな会話ではない(判断ブロック946D)の
で、受取りが行われる(ステップ949D)。アプリケーショ
ン56Dには、作業ユニットＺ上で行うべき追加の作業が
ないので、判断ブロック940Dから判断ブロック941Dに進
む。アプリケーション56Aがコミットを発行済みの時は
(判断ブロック941D)、アプリケーション56Dは、受取り
時に戻りコードTake_Syncpointを得て、コミットを発行
する(ステップ942D)。次に、同期点マネジャ60Dが、コ
ミット手順を開始する(ステップ944D)。この例では、こ
れで作業ユニットＺに関連する作業要求は完了し、判断
ブロック950Dからアプリケーション56Dの終わりに進
む。この時、アプリケーション56Aは、同期点マネジャ6
0Aから制御を返され、終了する。

【００５４】図11(および上記の図3ないし図5)には、本
発明で使用する例による、実行環境52Aおよび52D内での
コミットのタイミングが示されている。保護された会話
が、実行環境52Aに対して送られる状態の時、アプリケ
ーション56Aは、ステップ942(図9)に関して前述したよ
うに、作業ユニットYに関するコミットを発行する。実
行環境52Dが、保護された会話に対して受け取る状態に
ある時は、実行環境52Dは、実行環境52Aから戻りコード
Take_Syncpointと共にメッセージを受け取る。戻りコー
ドTake_Syncpointを受け取った後、アプリケーション56
Dはできるだけ早くコミットを発行すべきであることに
留意されたい。というのは、この戻りコードは、アプリ
ケーション56Aがコミットを発行済みであり、実行環境5
2Dがそれに対応するコミットを発行するのを待っている
ことを示しているからである。したがって、保護された
会話上でメッセージと戻りコードを受け取った後、アプ
リケーション56Dは、システム50D内の作業ユニットに関
連する他の保護された資源に関する作業を完了して、そ
れら他の資源を整合性のある状態にする。これを行った
結果、作業ユニットＺに関連するシステム50D内のすべ
ての資源が整合性のある状態になった後に、アプリケー
ション56Dは前記のコミットを発行する。次に、同期点
マネジャ60Aおよび60Dは、それぞれアプリケーション56
Aおよび56Dから直接アクセスされる資源に対して2段階
コミット手順を実施する。それぞれのアプリケーション
からアクセスされる資源をコミットするために、別々の
コミットが呼び出されるにもかかわらず、この2段階コ
ミット処理の間に、各同期点マネジャは、同期点状況の
情報をもう一方の同期点マネジャに報告する。同期点処
理のさらに詳しい説明については、「保護された資源の
調整式同期点管理」を参照されたい。

【００５５】 コミット手順のための資源の登録 図12は、資源の自動的かつ総称的な登録を示す図であ
る。この登録は、保護された資源を同期点マネジャ(SP
M)60に対して識別するファシリティである。それぞれの
アプリケーション実行環境52で、資源アダプタ62/64お
よび同期点マネジャ60は、アプリケーション56のために
登録に参加する。この実施例では、資源マネジャ63と資
源78は、この環境の外部にある。

【００５６】図12で、アプリケーション56は2つの部
分、作業要求とコミット要求を有するものとして示され
ている。これらの部分は共に、通常は同一のアプリケー
ション実行環境内で実行される。しかし、図中でこれら
2つの部分の間にある破線が示すように、このアプリケ
ーションは分散していてもよく、またこれら2種類の要
求が異なる環境から出されてもよい。

【００５７】あるエンド・ユーザが、システム制御プロ
グラムの開始ファシリティを呼び出して、アプリケーシ
ョン56を開始すると仮定する。この開始ファシリティ
は、アプリケーション実行環境52を構築し、アプリケー
ション56をロードし、それに制御を移す。アプリケーシ
ョン56が実行を開始する時、まだ同期点マネジャ60に登
録されている資源78はない。

【００５８】図2のアプリケーション56が、資源78を使
用するために作業要求を行う時(図3のステップ500およ
び図5のステップ530)、この要求は、資源78に関連する
特定の資源アダプタ62または64を呼び出す。資源アダプ
タ62または64の一般的な機能は、アプリケーション56を
資源マネジャ63に接続することである。システム50にお
いて、資源アダプタ62または64は、同期点マネジャ60に
自動的に登録を行う登録サブルーチンと、2段階コミッ
ト手順をサポートするアダプタ同期点出口入口点とを含
むように拡張されている。

【００５９】作業要求の入口点は、アプリケーション56
から資源マネジャ63へ作業要求(たとえば、ファイルの
オープン、データベースへのレコード挿入、会話の開始
など)をパスする、資源アダプタ62または64内のコード
行を示す。また、これらのコード行は、資源アダプタ62
または64内の登録サブルーチンと相互作用して、自動的
に登録を行う。この登録で、同期点マネジャ60に、資源
78がある作業ユニットの一部であることが知らされる。
また、この登録で、資源マネジャ63が同期点マネジャ60
に対して識別される。これは、具体的には、同期点マネ
ジャ60に、アダプタ同期点出口入口点と、資源マネジャ
の資源識別子object_recoveryを知らせることからな
る。

【００６０】アダプタ同期点出口入口点は、コミット要
求が行われる時に(図3のステップ506および図5のステッ
プ534)同期点マネジャ60の2段階コミット・ファシリテ
ィが使用する、資源アダプタ62または64内のコード行を
示す。資源識別子object_recoveryは、下記「保護され
た資源を回復するためのログ名の交換」(図29のステッ
プ225)で説明するように、同期点マネジャ60の2段階コ
ミット手順中に障害が発生した場合に、回復ファシリテ
ィ70が資源マネジャ63との会話を開始するために使用す
る識別子である。

【００６１】アプリケーション56のために自動的登録を
処理するために、資源アダプタ62または64のいずれかに
対する作業要求によって開始される処理は、資源に応じ
て異なる。使用される資源78は、本来作業要求の性質と
は無関係に保護されることができ、それがまだ登録され
ていない場合には、資源アダプタ62または64が、その登
録サブルーチンを使用して、アプリケーション56のため
にこの資源を同期点マネジャ60に自動的に登録する。ま
た、アダプタ62または64は、資源78が保護されるか否か
を知らず、資源マネジャ63がこれを知っていてもよい。
この場合、資源アダプタ62または64は、資源マネジャ63
に登録して、作業要求を資源マネジャ63に渡すことがで
きる。資源マネジャ63は、この作業要求を行った後、ア
ダプタ62または64に資源78が保護を必要とするか否かの
指示を戻すことができる。保護が不要な場合、資源アダ
プタ62または64は、その登録サブルーチンを使用して、
同期点マネジャ60から登録を取り消すことができる。あ
るいは、資源アダプタ62または64は、その資源がアプリ
ケーション56によって変更されるか否か、すなわちその
資源が読取りだけに使用されるか否かを、作業要求また
は資源マネジャ63から独自に決定することができる。読
取りのみの場合、資源アダプタ62または64は、同期点マ
ネジャ60の登録ファシリティを使用して、登録を読取り
専用に変更することができる。最後に、資源アダプタ62
または64は、資源78が読取り専用の資源か、それともで
きるだけ早く他のアプリケーションに利用可能にしなけ
ればならない、保護されない資源かを決定することがで
きる。この場合、資源アダプタは、2段階コミット手順
中に「準備」指令を得るために、登録されたままでいて
よい。その後、資源アダプタ62または64は、資源78をロ
ック解除する合図としてこの指令を使用することができ
る。この場合、アダプタ62または64は、同期点マネジャ
60からの指令に対して「準備済み」および「コミット」
と回答することができる。

【００６２】以下でさらに詳細に説明するように、登録
の取消しと変更をサポートすることによって、資源アダ
プタ62または64は、2段階コミット手順の最適化を可能
にする情報を同期点マネジャ60に与えることができる
(これも以下で説明する)。アプリケーション56がコミッ
ト要求を発行する時、同期点マネジャ60は、1つの資源
だけが変更済みとして登録されている(他の資源が登録
されていないか、あるいは他のすべての資源が読取り専
用として登録されている)と認識することができる。こ
の場合、同期点マネジャ60は、より効率的な1段階コミ
ット手順を使用することができる。

【００６３】次に、図2のアプリケーション56Aが実行中
であって、パートナ・アプリケーション56Dとの保護さ
れた会話を求める作業要求を行う(図5のステップ530)と
いう特定の例に対して適用した場合の、前述の一般的な
制御の流れについて考察する。この要求は、資源アダプ
タの1タイプである保護会話アダプタ64Aによって処理さ
れる。アダプタ64Aは、その登録サブルーチンを使用し
て、同期点マネジャ60Aの登録ファシリティを呼び出す
(ステップ532)。次に、アダプタ64Aは、資源マネジャと
して働く通信ファシリティ57Aを使用して、パートナ・
アプリケーション56Dを初期設定する。図2に示すよう
に、会話マネジャ53Aは、同一のシステム50A上のパート
ナ・アプリケーションを始動することができ、あるいは
通信ファシリティ57Aを介して別のシステム50D上の対応
する通信ファシリティ57Dと通信して、システム50D内の
アプリケーションを始動することもできる。後者の場
合、パートナ・アプリケーションはシステム50D上で実
行され、通信ファシリティ57Dが、システム制御プログ
ラム55Dの開始ファシリティを呼び出すことによって、
パートナ・アプリケーション56Dを開始する。このファ
シリティは、パートナ・アプリケーション56D用の新規
のアプリケーション実行環境52Dを構築する。開始ファ
シリティは、それがパートナ・アプリケーション56Dを
構築中であることを知っているので、起点側アプリケー
ション56Aとの保護された会話で通信ファシリティ57Dが
使用されることも知っている。したがって、開始ファシ
リティは、一時的にパートナ・アプリケーション56Dと
して働き、保護された会話のために保護会話アダプタ64
Dを呼び出す。次に、資源アダプタ64Dは、この保護され
た会話を同期点マネジャ60Dに登録する。したがって、
パートナ・アプリケーション56Dと起点側アプリケーシ
ョン56Aとの保護された会話が、パートナを呼び出す前
に登録される(その代わりに、パートナ・アプリケーシ
ョン56Dがアプリケーション56Aとの会話を使用するま
で、登録を遅延させることもできる)。したがって、図2
において、アプリケーション56Aの実行環境52A内の同期
点マネジャ60Aと、パートナ・アプリケーション56Dの実
行環境52D内の同期点マネジャ60Dは、それぞれ、この保
護された会話資源について知らされる。

【００６４】図2の議論において、この時点で、アプリ
ケーション56Aおよびパートナ・アプリケーション56D
は、それぞれの作業ユニットの下でそれぞれの実行環境
52Aおよび52D内で実行中であり、それぞれ1つまたは複
数の保護された資源78Aまたは78Dを使用することができ
る。たとえば、保護されたファイルを使用することがで
きる。アプリケーション56Aが、ファイル資源78Aを使用
するようにとの要求を行う時、資源アダプタ62Aが呼び
出される。アダプタ62Aは、その登録サブルーチンを使
用して、同期点マネジャ60Aの登録ファシリティを呼び
出す。次に、アダプタ62Aは、ファイル資源マネジャ63A
を呼び出す。したがって、アプリケーション56Aによる
保護された資源78Aの使用が、やはり自動的に登録され
る。同様にして、実行環境52D内で、資源78Dなど1つま
たは複数の資源に対する登録を行うことができる。

【００６５】上記の例から、登録が資源のタイプによら
ないので、この登録の実施例が総称的であることがわか
る。図12では、保護された資源78をサポートしようとす
る資源マネジャ63は、その資源アダプタ62または64に登
録サブルーチンを追加することができる。システム50の
同期点サポートを変更する必要はない。

【００６６】図12で、アプリケーション56が、保護され
ない資源を使用することもできる。たとえば、アプリケ
ーション56は、実行中の作業に関するメッセージを定期
的に表示する保護されないパートナ・アプリケーション
を生成したいが、この表示を実際の作業の完了と同期さ
せる必要はないことがある。この場合、アプリケーショ
ン56は、保護されない会話をもつようにとの作業要求を
行う。この制御の流れは、上述の例の保護された会話の
場合とほぼ同じである。唯一の相違は、資源アダプタ64
が作業要求内の情報から、この会話が保護されず、この
実施例では同期点マネジャ60に登録されないことを知っ
ている点である。したがって、保護されない会話は、同
期点マネジャ60の同期点処理には参加しない。

【００６７】図12において、上述の登録処理を仮定する
と、アプリケーション56がコミット要求を発行する時、
同期点マネジャ60は、同期させる必要のある保護された
資源の完全なリストをもっている。同期点マネジャ60内
での2段階コミット手順について説明した、前述の「保
護された資源の調整式同期点管理」を参照されたい。こ
の説明は、資源マネジャ63内で同期点サポートを使用す
るために、同期点マネジャ60が、資源アダプタ62または
64内のアダプタ同期点出口入口点をどのように使用する
かを示している。図12には示されていないが、アプリケ
ーション56はバックアウト要求を発行することもでき
る。この場合、同期点マネジャ60は、資源アダプタ62ま
たは64内のアダプタ同期点出口入口点にバックアウト指
令を与える。

【００６８】同期点処理の終りに、各同期点マネジャ60
は、アプリケーション56の登録リストを破壊しない。し
かし、各マネジャは、後同期処理のために、資源アダプ
タの出口をもう1度呼び出す。この呼出しに対して、ア
ダプタはその登録を修正するよう決定することができ
る。性能上の理由から、アダプタは、アプリケーション
56が終了するまで資源を登録状態に保つことができる。
一方、資源78がこれ以上使用されない(たとえば、アプ
リケーション56が終了する前に保護された会話が終わ
る)ことをアダプタが知っている場合、アダプタは、そ
の登録入口点を使用して、同期点マネジャ60から登録を
取り消すことができる。

【００６９】上記の制御の流れでは、分散式の資源マネ
ジャ63を仮定した。したがって、資源78を使用するとい
う要求は、必ず適当な資源アダプタ62または64に向か
い、このアダプタは、同期点マネジャ60内の登録ファシ
リティと、分散資源マネジャ63内の作業要求を呼び出し
た。ところが、資源マネジャ63が分散式ではない場合、
作業要求でアダプタを使用する必要はない。この場合、
資源マネジャ63と同期点マネジャ60が、同一のアプリケ
ーション実行環境52内にあるので、資源マネジャ63は、
同期点マネジャ60内の登録ファシリティを直接呼び出す
ことができる。

【００７０】図14に示した例では、アプリケーション56
Aが複数の作業要求を行う。これらの要求は、システム5
0Aによって並列に処理され、複数の資源マネジャと資源
を必要とする。この例について具体的に言うと、アプリ
ケーション56Aは、2つの作業ユニットCおよびDに対して
8つの作業要求を行い、これらの要求がシステム50Aによ
って並列に処理される。コミット点が図15に示されてい
るが、作業ユニットCのコミット点は時刻19と44にあ
り、作業ユニットDのコミット点は時刻33にある。図15
の時間単位は、シーケンスを表す論理的クロック単位で
ある(物理的クロック単位ではない)。図15において、同
一の時刻に発生する事象は、互いの順序がどうでもよい
ことを暗示している。

【００７１】作業ユニットとは、どの資源がある同期点
に参加するかについてのアプリケーション側の理解また
は範囲である。アプリケーションは、どの作業ユニット
に対して保護された資源の変更が行われるかを指定する
ことができる。また、アプリケーションは、保護された
会話をどの作業ユニットの下で開始するかも指定するこ
とができる。システム50Aは、アプリケーション実行環
境(図14の52A)内で複数の作業ユニットを許容する。具
体的に言うと、アプリケーション、同期点マネジャ60A
および保護されたアダプタ(たとえば、図14のSQL資源ア
ダプタ)は、複数の作業ユニットを並列してサポートす
ることができる。また、システム50Aは、保護された会
話を介して、2つのアプリケーション実行環境の作業ユ
ニットを結合することも許容する。各作業ユニットは、
一連の同期点を有することができる。ある作業ユニット
に対する同期点要求は、あるアプリケーションの実行環
境内の他の作業ユニットの活動には影響しない。

【００７２】図14および図15に示した次の例を考察す
る。ホームタウンにいるジョーンズ氏は、息子の信託預
金への振替を行いたいと思っている。ジョーンズ氏の銀
行の安全保護部門は、顧客も従業員も含めて、取引にか
かわるすべての人物を追跡する。安全保護記録と会計レ
コードは、互いに「すべてか無か」の包含関係にあるわ
けではないが、この2つの作業ユニットを並列して処理
する必要があるかもしれない。1つの理由としては、こ
の2つの作業ユニットを順に処理するのでは応答時間が
遅くなりすぎることが挙げられよう。

【００７３】この例では、時刻1の作業ユニットCに関す
る作業要求は、シカゴにあるこの銀行の本店の安全保護
記録を制御する資源マネジャ63Aを使用する。資源マネ
ジャ63Aと通信するために、資源アダプタ62Aによって保
護されない会話1が使用される。時刻1の作業ユニットD
に関する作業要求も、ジョーンズ氏の信託預金用にシカ
ゴにある資源マネジャ63Aを使用し、一方、時刻7の要求
は、ジョーンズ氏の他の会計レコードが保存されている
ホームタウンの資源マネジャ63Bに対するものである。
資源マネジャ63Aと通信するために、資源アダプタ62Aに
よって保護されない会話2が使用され、資源マネジャ63B
と通信するために、資源アダプタ62Bによって保護され
ない会話3が使用される。

【００７４】アプリケーション56Aが作業ユニットCを使
用してその最初のレコードであるメッセージ“start se
curity event(安全保護事象開始)”を書き込む時(図16
のステップ612)、資源マネジャ63Aは、その資源アダプ
タ62Aを介してアプリケーション実行環境52A内に登録さ
れる。同期点マネジャ60Aは、図14の表126内で作業ユニ
ットCの下に、資源マネジャ63A用の登録エントリを作成
する(ステップ614)。このエントリは、出口ルーチン名
と、資源アダプタ62Aが登録の際に渡した特別なプライ
ベート値とを含む、資源アダプタ62Aの出口に渡すべき
パラメータのリストを含む。資源アダプタの出口は、こ
の特別な値を使用して、会話1用の制御ブロックを探し
出すことができる。

【００７５】その結果、アプリケーション56Aが、時刻1
9に作業ユニットCに関するコミットを要求する時、同期
点マネジャ60Aは、表126を読み取って、どの資源アダプ
タ出口にこのコミット手順を開始するよう通知するべき
かを決定する。この例では、時刻19に作業ユニットCに
関するコミットが要求される時、同期点マネジャ60Aが
資源アダプタ62Aの出口を呼び出して、1段階コミット手
順を開始する。というのは、保護された資源が1つだけ
登録されているからである。資源アダプタ62Aの出口ル
ーチンは、同期点マネジャ60Aから、登録中に表126にセ
ーブされた特別な値を受け取るので、会話1を使用して
資源マネジャ63Aと通信すべきことを知る。

【００７６】この後、時刻26にジョーンズ氏の取引を扱
う銀行員の従業員IDをロギングする時には、登録は行わ
ない(ステップ613)。再登録が不要なのは、作業ユニッ
ト登録表126から、資源マネジャ63Aが作業ユニットCに
参加していることを、同期点マネジャ60Aがすでに知っ
ているからである。その結果、最初の作業要求の後の作
業ユニットCに関する各作業要求、およびその後の時刻4
4でのコミットの処理が、手早く行われる。また、作業
ユニットC用の各同期点にで、資源アダプタ62Aと資源マ
ネジャ63Aだけが通知を受ける。他の資源アダプタまた
は他の資源マネジャに通知することによる時間の浪費は
ない。

【００７７】アプリケーション56Aが、作業ユニットDの
下で、時刻1と時刻7に作業要求を行う時、資源アダプタ
62Aおよび62Bの両方が、同期点マネジャ60Aに登録さ
れ、同期点マネジャ60Aは、表127に登録エントリ63Aお
よび63Bを追加する。

【００７８】時刻19に最初の安全保護記録のコミットが
行われる時、時刻17の信託預金更新は、全く影響を受け
ない。時刻33に信託預金レコードと会計レコードがコミ
ットされる時、従業員IDメッセージはやはり影響を受け
ない。シカゴにある資源マネジャ63Aは、別々な2つの会
話1および2を介してアプリケーション56Aと通信してい
るので、混乱しないことに留意されたい。

【００７９】システム50Aが、資源マネジャに対してど
の作業ユニットが活動状態であるかを知っており、資源
アダプタをこのタスクから解放するので、資源アダプタ
の開発は簡単になる。設計が簡単なので、資源アダプタ
出口は良好に動作する。資源アダプタ出口は、必要なも
のをすべて有しており、同期点マネジャ60Aの行動をそ
の資源マネジャに送るだけである。もう1つの性能上の
展望は、同期点マネジャ60Aが、同期点手順を最適化で
きることである。というのは、同期点マネジャ60Aは、
どの作業ユニットのために資源マネジャが活動状態であ
るかを知っており、同期点に関係ない資源のために資源
アダプタおよび資源マネジャを呼び出すことによるオー
バヘッドを回避できるからである。

【００８０】システム50Aにおいて、共用ファイルやデ
ータベースなどの保護された資源に対して行われるタイ
プの作業要求が、その資源の状態を変更し、その結果、
登録情報を変更しなければならない場合があり得る。こ
れが重要であるのは、元の作業要求が、読取り専用の要
求であって、1段階コミット手順しか必要としないの
に、その後の同一の作業ユニットの下での関連する作業
要求が、書込み要求であって、使用される複数の保護さ
れた資源を調整するために、2段階コミット手順を必要
とすることがあるからである。

【００８１】図3に示したもう1つの例として、アプリケ
ーション56Aは、通常、更新すべきファイル内の特定の
レコードの位置を探すために、書込み要求を行う前にそ
のファイル上で1つまたは複数の読取り要求を行う。こ
のような読取り動作は、1段階コミット手順を用いて実
施できるが、この場合、資源アダプタ62Aは、この読取
り作業要求を受け取ると(ステップ500)、同期点マネジ
ャ60Aに読取りモードで登録される(ステップ502)。その
後の読取り動作中には、必要なコミット手順のタイプが
変化しないので、資源アダプタ62Aが同期点マネジャ60A
と相互作用する必要がないことに留意されたい。しか
し、その後、アプリケーション56Aが、同一の作業ユニ
ットの下で資源アダプタ62Aに対して書込み要求を行う
際には(ステップ504)、資源アダプタ62Aは、その同期点
マネジャ60Aにおける登録状況を書込みモードに変更す
る。以下でさらに詳細に説明するように、複数の保護さ
れた資源が、同一の作業ユニット上で書込みモードで登
録される場合には、幾分時間のかかる2段階コミット手
順が使用される。

【００８２】この登録変更の例は、図13の流れ図に詳細
に示されている。ステップ580の作業要求が、その保護
された資源に関する最初の要求であり、この要求が読取
り専用である場合、判断ブロック581から判断ブロック5
82に進む。資源アダプタ62Aは、それが登録されている
各作業ユニットの下で各資源用の内部標識を保存してい
ることに留意されたい。この標識が、判断ブロック581
で検査される。この資源は、保護された会話ではないの
で、判断ブロック582から判断ブロック583に進む。この
作業は読取り専用なので、判断ブロック583からステッ
プ585に進む。ステップ585で、対応する資源アダプタ62
Aが、読取り専用資源として登録される。ステップ580の
次の作業要求が、同一の作業ユニットの下での同一の資
源への書込みまたは更新である場合、資源アダプタ62A
は、読取りモードとしてであるとはいえ、ステップ585
ですでに登録されているので、判断ブロック581から判
断ブロック584に進む。この資源は保護された会話では
ないので、判断ブロック584から判断ブロック586に進
み、この要求は更新モード用なので、判断ブロック586
から判断ブロック588に進む。次に、判断ブロック588か
らステップ590に進み、資源アダプタ62A(ステップ585で
すでに読取りモードとして登録済み)は、同期点マネジ
ャ60Aにおけるその登録を書込みモードに変更する。図1
3によれば、この資源に対するある作業ユニットの下で
の最初の作業要求が書込みモードである場合には、資源
アダプタ62Aが、ステップ592で書込みモードとして登録
されることに留意されたい。

【００８３】資源マネジャ63が、ある同期点を完了し、
その同期点の完了以降に別の要求をもたないという状況
もある。その資源アダプタ62は、同期点手順が完了した
時点で、その登録状況を「中断」に変更することを許さ
れ、その結果、同期点マネジャ60は、現在、資源マネジ
ャ63が、その作業ユニットに関してどの同期点にも参加
していないことを知る。書込みモードの資源の中断によ
り、たとえばその作業ユニット内に書込みモードの資源
が他に1つしかないような時、同期点マネジャ60は、残
りの資源用のその後のコミット手順(1段階コミット)を
最適化できるようになる。中断された資源アダプタ62
は、その作業ユニットに関する新規の作業要求を受け取
る場合、同じ登録修正機能を用いてその登録を活動状態
に戻すことができる。

【００８４】ある種の資源マネジャの設計では、その資
源アダプタは、分散式の同期点活動について通知を受け
るために、アプリケーションとの対話の初期に登録され
る必要がある。ただし、その時点では、登録情報が完全
に揃っていなくてもよい。たとえば、保護会話アダプタ
64Aは、同期点が発生したか否かを知る必要があるの
で、パートナ・アプリケーション56Dとの保護された会
話を開始する時点で登録される必要があるが、保護会話
アダプタ64Aがすべての登録情報を得るのは、会話のパ
ートナがこの会話を受け入れた後であり、これはずっと
後になってから発生するかも知れない事象である。この
情報は、その後、ステップ590に示された前述の登録変
更処理の下で追加することができる。

【００８５】システム50は、時間を節約するための技法
をこの登録処理に追加して提供する。各資源アダプタ62
は、初めて同期点マネジャ60に登録される際に、資源マ
ネジャ63の識別と、その資源アダプタの同期点処理用の
出口ルーチン名の他にも、追加の情報を登録する。この
追加情報の多くは、通常、登録が変更される際に変更さ
れない。その結果、この追加情報は、ステップ590で資
源アダプタ62の登録が変更される際に再登録されない。
資源アダプタ62が同期点マネジャに一回だけ登録し、他
の登録情報が変化しても変化しない、前記の追加情報の
一部のリストを下記に示す。 1.資源マネジャと資源が、システムおよびネットワーク
内のどこに位置するかを記述する、資源識別子とネット
ワーク識別子、 2.製品を示す、すなわち、たとえば共用ファイル、デー
タベース、保護された会話など、資源のタイプを示す製
品識別子、 3.再同期化に必要なその他のデータ。これらの追加情報
は、毎回再登録されはしないので、登録処理が手早く行
われる。

【００８６】様々な場合に、アプリケーションがもはや
保護された資源を使用できない、または使用しないこと
がある。この例には、アプリケーション終了、資源マネ
ジャ終了、資源マネジャへの経路が利用不能などの事象
が含まれる。ある資源がもはや使用中ではないとアプリ
ケーションが宣言できるようにする、アプリケーション
または資源マネジャのプロトコルを設けることができ
る。アプリケーション実行環境が、アプリケーションの
終了以前に資源の登録を取り消すことができるようにす
るプロトコルをサポートすることもできる。また、保護
された会話が、アプリケーションの活動のために、また
は経路障害などのエラー状態のために、終了することも
ある。このような場合には、資源アダプタまたは保護会
話アダプタが、同期点マネジャから該当する資源のイン
スタンスすべての登録を取り消すことが好ましい(図16
のステップ618)。というのは、この登録取消しによっ
て、その後の同期点処理がより効率的になる(考慮すべ
き資源の数が減り、多分、消費されるメモリも少なくな
る)からである。さらに、この資源アダプタまたは保護
会話アダプタは、登録された資源に関する制御情報を削
除することができ、したがって、その後の処理をより効
率的にすることができる。

【００８７】図17は、資源アダプタ62または保護会話ア
ダプタ64が、資源78または保護された会話が利用不能で
あることを発見した(ステップ904)、あるいはアプリケ
ーションが終了したことを発見した(ステップ903)場合
の、登録解除活動の流れを示す図である。資源が利用不
能であることをアダプタが発見するのは、通常、アプリ
ケーションの作業要求の処理中であることに留意された
い(ステップ902)。アダプタは、それ自体の資源登録状
況の情報から、どの資源の登録を取り消さなければなら
ないかを決定する(ステップ906)。このような登録され
ている各資源について、アダプタは、同期点マネジャ60
を呼び出して、その資源の登録を取り消す(ステップ90
7)。アダプタは、同期点マネジャ60に対して、資源と作
業ユニットを識別しなければならないことに留意された
い。

【００８８】図17では、同期点マネジャ60を呼び出すご
とに(ステップ910)、同期点マネジャ60は、アダプタか
ら供給された作業ユニット識別子を使用して、その作業
ユニット資源表を探し出す(ステップ911)。この作業ユ
ニットの資源表から、同期点マネジャ60は、アダプタか
ら供給された作業ユニット識別子を使用して、所望の資
源エントリを探し出す(ステップ912)。次に、同期点マ
ネジャ60は、その資源エントリに登録を取り消された旨
のフラグを立て(ステップ913)、呼出し側アダプタに戻
る(ステップ914からステップ907に戻る)。しかし、論理
上、この登録を取り消された資源エントリは、次の同期
点まで保存しなければならないエラー情報を含んでいる
ので、同期点マネジャ60は、まだこの資源エントリを消
去することができない(「コミット手順におけるエラー
・コードおよびエラー記述情報の調整式処理」を参照さ
れたい)。

【００８９】ここでアダプタは、登録を取り消された資
源に関する制御情報を削除する(あるいは、登録を取り
消された旨のマークを付ける)ことができる(ステップ90
8)。登録取消しを引き起こした事象が、複数の資源登録
を削除させる場合があることに留意されたい(たとえ
ば、1つの資源が複数の作業ユニットのために登録され
ている場合がある)。したがって、ステップ906、907、9
08をプログラム・ループにして、以前に登録された該当
する各資源を処理することができる。その後、アダプタ
は呼出し側に戻ることができる(ステップ909)。資源が
利用不能であるために作業要求が失敗した場合、アダプ
タは、資源アダプタがアプリケーション・ユーザにエラ
ー情報を戻すために選択したどんな機構を用いてもアプ
リケーションにエラー状態を報告することができる。

【００９０】資源アダプタは、資源が利用不能である
か、またはアプリケーションが終了した結果として、他
の処理上の問題を生じることがある。たとえば、資源が
利用不能な状態であったため資源更新のバックアウトを
引き起こす場合、アダプタは、アプリケーションまたは
同期点マネジャ60あるいはその両方に、該当する作業ユ
ニット上の次の同期点がバックアウトでなければならな
いことを通知する必要がある。同期点処理中にこの状態
が発生すると、アダプタは、(バックアウト中の)資源の
状況を同期点マネジャ60に通知しなければならない。こ
の他にも、資源、環境または実施様態に依存する他の問
題が生じるかもしれない。

【００９１】ここで同期点マネジャ60は、フラグを立て
られた登録取消し済みの(ステップ913からの)資源の処
理に従事し、その結果、それらの資源は通常の処理では
無視されて、最終的に消去されることになる。同期点マ
ネジャ60は、フラグを立てられた登録取消し済みの資源
エントリを、その影響を受ける作業ユニットの次の同期
点の始めに消去することができる。図18に、同期点マネ
ジャ60内の同期点処理の流れが記述されている。次の同
期点処理で、登録された資源の表を読み取る時(ステッ
プ622)、その表中のフラグを立てられた登録取消し済み
の資源エントリをすべて消去することができる(この行
動は図18には図示せず)。ステップ622で、現在の同期点
処理の間のすべての同期点資源の参加リストを作成する
ので、アダプタによる資源登録エントリの資源登録の取
消しと変更は、現在の同期点処理には影響しない。この
時点で、登録取消し処理の全体が完了する。

【００９２】コミット手順の最適化 参加する各資源マネジャは、“System Network Archite
cture LU 6.2: Peer Protocols, sc31-6808, Chapter
5.3 Presentation Services - Sync Point Verbs”に記
載の2段階コミット手順などの2段階コミット手順を実行
する能力があり、1段階コミット手順を実行する能力は
あってもなくてもよい。2段階コミット手順は、資源を
保護するのに重要である。しかし、2段階コミット手順
は、1段階コミット手順と比べて、相対的に複雑で時間
のかかる処理である。たとえば、後で詳細に説明するよ
うに、2段階コミット手順では、同期点参加者に関する
情報を回復ファシリティのログ72(図2)にロギングする
という時間のかかるステップが必要であるが、1段階コ
ミット手順では、そのようなロギングの必要はない。ま
た、2段階コミット手順では、コミットを実行するの
に、資源アダプタ調整出口を2回呼び出す必要がある
が、1段階コミット手順でデータをコミットするには、
このような呼出しは1回だけでよい。「資源アダプタ調
整出口」とは、同期点マネジャ60(図2)が、関連する資
源マネジャに情報を提供するための機構である。同期点
マネジャは、システムをできるだけ手早く動作させるの
に必要な時に限り、2段階コミット手順を使用する。要
約すると、同期点マネジャは、保護された会話を使用す
るか、少なくとも2つの資源が更新モードであるか、あ
るいは1つまたは複数の参加する資源マネジャが1段階コ
ミット手順を実行できない時、2段階コミット手順を使
用する。すべての資源が1段階コミット手順を実行で
き、更新モードの資源がせいぜい1つである場合には、
同期点マネジャは、1段階コミット手順を使用する。ま
た、ある資源が読取り専用モードであり、したがってそ
の資源内のデータは読み取られるが更新されず、かつ資
源マネジャが1段階コミット手順を実行できる場合に
は、他の資源に使用されるコミット手順のタイプが何で
あれ、この資源には1段階コミット手順が使用される。
この最適化の最重要な構成要素は、資源マネジャおよび
資源アダプタが、作業要求によって定義される状態、す
なわち資源が読取り専用モードであるか更新モードであ
るかを、同期点以前に決定できることである。ある資源
が読取り専用モードである場合、それは、アプリケーシ
ョンがその資源からデータを読み取っただけであること
を意味する。ある資源が更新モードである場合、それ
は、アプリケーションがその資源内のデータを変更した
ことを意味する。

【００９３】この最適化処理は、下記のように始まる。
アプリケーション56(図2)が、ある資源に対する作業要
求を行う(図16のステップ612)。これが特定の作業ユニ
ットに対する最初の作業要求である場合(図16の判断ブ
ロック613)、その資源に関連する資源アダプタ62(図2)
は、それが現在、その作業ユニット用の活動状態の参加
する資源であることを、同期点マネジャに登録する(図1
6のステップ615)。登録時(図16のステップ616)に提供し
なければならない、この資源に関する情報の1つは、関
連する資源マネジャが1段階コミット手順を実行できる
か否かであり、たとえば、その資源が、特定の情況の下
で1段階コミット手順を実行できるデータベース・マネ
ジャであるかどうかである。やはり登録中に、資源アダ
プタは、このアプリケーションによって行われた作業要
求が、その資源を読取り専用モードにしたか、それとも
更新モードにしたかを同期点マネジャに記録する(図16
のステップ616)。

【００９４】資源の最初の登録の後、アプリケーション
がその資源に対して次の作業要求を行ったとき、資源の
状態が変化することがある。すなわち、資源が読取り専
用モードから更新モードに変化することがある。このよ
うな変化が発生した場合、資源アダプタは、この変化に
ついて同期点マネジャに知らせなければならず、登録情
報は新しい状態を反映するように更新される(図16のス
テップ619)。

【００９５】アプリケーションからの作業要求が、保護
された会話に対するものである場合、保護会話アダプタ
用の登録エントリは、その保護会話アダプタが更新モー
ドであって、1段階コミット手順を実行できないことを
必ず示す。保護会話アダプタは、複数の資源を使用する
可能性のある別のアプリケーション実行環境への通信経
路を表すので、読取り専用モードの資源への通信経路を
表しているのか、それとも更新モードの資源への通信経
路を表しているのかは、保護会話アダプタには決定でき
ない。したがって、別のアプリケーション実行環境への
通信経路が存在する場合には、クリティカルな資源に必
要な保護を提供するために、2段階コミット手順が必要
である。保護会話アダプタは、1段階コミット手順を実
行できない更新モードの資源として登録することによっ
て、2段階コミット手順が使用されることを保証する。

【００９６】アプリケーションは、その作業をすべて完
了した後に、資源上のデータのコミットまたはバックア
ウトを試みる。これを達成するために、アプリケーショ
ンは同期点マネジャに同期点要求を発行する。この同期
点要求の処理を開始するために(図18のステップ620)、
同期点マネジャは、作業ユニット表を読み取って、影響
を受ける作業ユニットのエントリを見つける(図18のス
テップ621)。作業ユニットの詳細については、「作業ユ
ニットに合わせて調整されたローカルおよびグローバル
なコミット範囲」を参照されたい。正しい作業ユニット
・エントリが見つかると、同期点マネジャは、その作業
ユニット用に登録された資源に関する情報をそのエント
リから読み取り、資源の3つのリストを生成する(図18の
ステップ622)。

【００９７】これらの表は、それぞれ異なる意味をも
つ。読取り専用リストは、アプリケーションがデータを
読み取っただけである資源を含む。更新リストは、アプ
リケーションによってそのデータが更新された資源と、
読取り専用の状態であるが、その資源マネジャが1段階
コミット手順を実行できない資源を含む。開始側リスト
は、更新を資源に同期させたい旨のメッセージを送った
通信パートナのリストを含む。各資源は、これらのリス
トのうちの1つだけにしか現れない。

【００９８】実際には、それぞれの資源の登録には、2
つのフラグが含まれる。これらのフラグは、同期点マネ
ジャに読み取られ、ある資源を更新リストに入れるべき
か、それとも読取り専用リストに入れるべきかを決定す
るのに使用される。第1のフラグは、その資源が読取り
専用モードの時オンとなり、更新モードの時オフとな
る。第2のフラグは、その資源が1段階コミット手順と2
段階コミット手順の両方をサポートする時オンとなり、
2段階コミット手順しか実行できない時オフとなる。実
際には、各資源の登録には、通信パートナが更新を資源
と同期させたい旨を示すメッセージをこの資源アダプタ
が通信パートナから受け取ったか否かに関する情報を含
むフィールドも含まれる。同期点マネジャは、このフィ
ールドを読み取り、そのデータを使用して、その資源を
開始側リストに入れるべきか否かを決定する。

【００９９】資源のリストを作成し終えると、同期点マ
ネジャは、同期点要求のタイプを検査する(図18の判断
ブロック623)。この同期点要求がバックアウトである場
合には、同期点マネジャは以下のバックアウト処理を実
行する。まず、更新リスト中に資源アダプタがあるなら
ば、それらのすべてに、その資源の変更をバックアウト
するように指令する(図18のステップ626)。次に、読取
り専用リスト中に資源アダプタがあるならば、それらの
すべてに、それらの資源に対する作用をバックアウトす
るよう指令する(図18のステップ627)。読取り専用の資
源に対する「バックアウト」の処理は、バックアウトす
べき資源内の実際のデータが変更されないので、その資
源の実施様態によって定義されることに留意されたい。
たとえば、共用ファイル資源マネジャ63(図2)内の読取
り専用ファイルをバックアウトするための処理は、その
ファイルをクローズし、そのアプリケーションの使用の
ために以前に維持されていたファイル位置情報を放棄す
ることを含むことができる。読取り専用の資源をバック
アウトするよう指令した後、開始側リスト中に資源アダ
プタがあれば、それらすべてに、このアプリケーション
実行環境がこの同期点に対する変更をバックアウトした
ことを伝える(図18のステップ628)。

【０１００】そうではなくて、この同期点要求がコミッ
トである場合(図18の判断ブロック623)、同期点マネジ
ャは、このコミットの最適化処理を開始する。この最適
化処理の第1ステップでは、開始側リストが空であるか
否か決定する(図18の判断ブロック624)。開始側リスト
が空でないならば、それは、このアプリケーション実行
環境が、その同期点ツリー内のカスケード式開始側であ
り、このコミットのために完全な2段階コミット手順を
使用しなければならないことを意味する。それが必要な
のは、この同期点ツリーの完全な範囲、すなわちこの同
期点に対して活動状態でありかつ更新モードである資源
がどれだけあるかを、どのアプリケーション実行環境も
知らないからである。この数が未知であるので、これら
のクリティカルな資源に必要な保護を提供するために、
2段階コミット手順を使用しなければならない。

【０１０１】開始側リストが空である場合(図18の判断
ブロック624)は、次のステップで、更新リスト中に複数
の資源があるか否かを決定する(図18の判断ブロック62
5)。そうである場合は、このコミットのために完全な2
段階コミット手順を使用しなければならない。すべての
資源がそれぞれの変更をコミットできると認めない限
り、どの資源もその変更をコミットしないので、この2
段階コミット手順は、更新モードの資源に対してより多
くの保護を提供する。

【０１０２】更新リスト中に2個未満の資源しかない場
合(図18の判断ブロック625)、次のステップで、更新リ
スト中に資源がないか、それとも1つあるか決定する(図
18の判断ブロック640)。更新リスト中に資源がない場
合、読取り専用の資源をコミットするために1段階コミ
ット手順を使用する。同様に、更新リスト中に資源が1
つだけあり、その資源マネジャが1段階コミット手順を
実行できる場合には、1段階コミット手順を使用する。

【０１０３】この1段階コミット手順は、更新リスト中
に資源アダプタがあるならば、それに対してその変化を
コミットするよう同期点マネジャが指令することから始
まる(図18のステップ641)。資源マネジャによるデータ
の1段階コミットは、2段階コミット中には2回の呼出し
が必要であるのとは対照的に、資源アダプタを1回呼び
出すだけで達成されることに留意されたい。この同期点
全体を通じて、更新モードの資源はせいぜい1つしか存
在し得ないので、異なる資源に対する異なる決定によっ
てデータの整合性が失われる可能性はない。また、この
1段階コミット手順中には、2段階コミット手順の一部と
してロギングが(図19のステップ644、648、651、658お
よび659)必要であるのとは対照的に、回復ファシリティ
のログ72(図2)への書込みが行われないことに留意され
たい。この1段階コミット手順は、読取り専用リスト中
に資源アダプタがあるならば、それに対してその変更を
コミットするよう同期点マネジャが指令することで終了
する(図18のステップ642)。読取り専用の資源の「コミ
ット」は、コミットすべきデータが実際には変化してい
ないので、資源の実施様態によって定義されることに留
意されたい。たとえば、一部の共用ファイル資源マネジ
ャ63(図2)は、読取りの整合性をもたらすので、あるア
プリケーションが共用ファイル資源マネジャ内のファイ
ルを読み取る時に、そのアプリケーションは、そのファ
イルの整合性のあるイメージを与えられる。すなわち、
他のアプリケーション環境がそのファイルに対して行っ
た変更は、ファイルの内容の読取りに干渉せず、ファイ
ルがオープンされた時の内容が読み取られる。アプリケ
ーションが読取りの目的でファイルをオープンする時、
読取り専用の資源であるとみなされる資源マネジャによ
ってこのイメージが生成される。アプリケーションは、
ファイルの読取りを終えた時、このファイルをクローズ
し、コミットを試みる。共用ファイル資源マネジャは、
読取り専用の資源としてこのコミットを実行する時、ア
プリケーションの使用のために維持されたイメージを破
棄することができる。これで、アプリケーションがこの
ファイルを再度オープンする場合、他のアプリケーショ
ンによって行われたコミット済みの変更をすべて含むフ
ァイルのイメージが見えることになる。

【０１０４】同期点要求の結果が、図18の判断ブロック
624、625または640の結論に従って、2段階コミット手順
となる場合、同期点マネジャ60(図2)は、やはり読取り
専用の資源のコミットを最適化する。読取り専用の資源
のこの最適化にはいくつかの部分がある。第1に、(図19
のステップ644)この読取り専用の資源に関する情報は、
回復ファシリティのログ72(図2)に書き込まれない。読
取り専用の資源が、それ自体のログに「不確定」の状態
をロギングすることは絶対にないので、読取り専用の資
源に関する情報を回復ファシリティ70(図2)にロギング
する必要はない。これは、資源マネジャが回復ファシリ
ティ70(図2)との再同期化を決して試みず、したがっ
て、回復ファシリティはこの資源に関する知識を必要と
しないことを意味する。第2に、この読取り専用の資源
は、コミットの第1段階、すなわち更新リスト中のすべ
ての資源アダプタへの“prepare(準備)”の送出には使
用されない(図19のステップ645)。データの整合性の点
で、読取り専用の資源にとってバックアウトはコミット
と同等なので、読取り専用の資源の行動が、資源の保護
に影響を与えることはありえない。

【０１０５】読取り専用の資源が2段階コミット手順に
使用されるのは、コミットの最終決定を伝えられる時、
すなわち、変更をコミットする(図19のステップ653)
か、または変更をバックアウトする(図19のステップ65
5)よう伝えられる時だけである。

【０１０６】下記に、システム50(図2)などのシステム
の一部である3つの異なるアプリケーション実行環境に
関わる、2段階コミット手順の例を示す。各アプリケー
ション実行環境は、異なるアプリケーションを実行中で
ある。アプリケーションAとアプリケーションBは、保護
された会話を介して通信中である。アプリケーションB
とアプリケーションCは、保護された会話を介して通信
中である。この2段階コミット手順は、アプリケーショ
ンAが、これと同一の実行環境内で現在実行中の同期点
マネジャにコミット要求B1(図20)を発行することによっ
て、コミットを試みる時に開始される。段階1は、この
同期点マネジャが、回復ファシリティのログB2(図20)に
ログ・レコード“SPM Pending (SPM保留)”を書き込む
時に始まる。ログ・レコード“SPM Pending”は、その
同期点用の作業論理ユニット識別子と、その同期点参加
者に関する情報を含み、この場合、ログ・レコード“SP
M Pending”は、1つの参加者としてアプリケーションB
を示す。

【０１０７】ログ・レコード“SPM Pending”が回復フ
ァシリティへ成功裡に書き込まれた後、同期点マネジャ
は、保護会話アダプタを介してアプリケーションBにメ
ッセージ“prepare”を送る。アプリケーションBは、そ
の会話パートナであるアプリケーションAが資源の同期
化を望んでいることを知らされ、その後アプリケーショ
ンBは、それと同一の実行環境内で現在実行中の同期点
マネジャにコミット要求B3(図20)を発行する。

【０１０８】B側の同期点マネジャについては、2段階コ
ミット手順の第1段階は、回復ファシリティのログB4(図
20)にレコード“SPM Pending”を書き込むことから始ま
る(図20)。レコード“SPM Pending”は、この同期点用
の作業論理ユニット識別子と、この同期点参加者に関す
る情報を含む。この場合、ログ・レコード“SPM Pendin
g”は、アプリケーションAに関する、それを同期点開始
側として示す情報とアプリケーションCに関する、それ
を同期点参加者として示す情報を含む。ログ・レコード
“SPM Pending”が回復ファシリティのログに成功裡に
書き込まれると、同期点マネジャは、保護会話アダプタ
を介してアプリケーションCにメッセージ“prepare”を
送る。アプリケーションCは、その会話パートナである
アプリケーションBが資源の同期化を望んでいることを
知らされ、その後アプリケーションCは、それと同一の
実行環境内で現在実行中の同期点マネジャに、コミット
要求B5(図20)を発行する。

【０１０９】同期点マネジャは、レコード“SPM Pendin
g”を回復ファシリティのログB6(図20)に書き込むこと
によって、2段階のコミット手順第1段階を開始する。こ
のレコード“SPM Pending”は、この同期点参加者に関
する情報と、この同期点用の作業論理ユニット識別子を
含む。この例では、レコード“SPM Pending”は、この
同期点の開始側であるアプリケーションBに関する情報
を含む。また、レコード“SPM Pending”は、アプリケ
ーションCに対する同期点参加者がないことを示してい
る。

【０１１０】参加者がないので、C側の同期点マネジャ
が、保護会話アダプタを介してメッセージ“prepare”
を送る必要はない。そこで、C側の同期点マネジャは、
回復ファシリティに状態レコードを送り、同期点の状態
を「代理、不確定」B7(図20)に更新する。この状態レコ
ードが回復ファシリティのログに成功裡に書き込まれる
と、C側の同期点マネジャは、このメッセージ“prepar
e”に応答して、保護会話アダプタを介してB側の同期点
マネジャにメッセージ“request commit(コミット要
求)”を送る。

【０１１１】B側の同期点マネジャは、保護会話アダプ
タを介してC側の同期点マネジャからのメッセージ“req
uest commit”を受け取る。メッセージ“request commi
t”だけが受け取られたので、次のステップで、回復フ
ァシリティに状態レコードを送って、同期点の状態を
「代理、不確定」B8(図20)に更新する。状態レコードが
回復ファシリティのログに成功裡に書き込まれると、B
側の同期点マネジャは、Aからのメッセージ“prepare”
に応答して、保護会話アダプタを介してA側の同期点マ
ネジャにメッセージ“request commit”を送る。

【０１１２】A側の同期点マネジャは、B側の同期点マネ
ジャからメッセージ“request commit”を受け取り、こ
れでこの同期点の第1段階が完了する。次に、この同期
点マネジャは、この同期点の開始側として、作業論理ユ
ニットをコミットするかそれともバックアウトするかを
決定しなければならない。メッセージ“request commi
t”だけがA側の同期点マネジャに受け取られたので、A
側の同期点マネジャは、この作業論理ユニットをコミッ
トすると決定する。この2段階コミット手順の第2段階
は、状態レコードを回復ファシリティに送ることによっ
てこの同期点マネジャがこの決定を記録することから始
まる。この状態レコードは、この同期点の状態を「開始
側、コミット済み」B9(図20)に変更する。この状態レコ
ードが回復ファシリティのログに成功裡に書き込まれる
と、この同期点マネジャは、保護会話アダプタを介して
B側の同期点マネジャにメッセージ“committed(コミッ
ト済み)”を送る。

【０１１３】B側の同期点マネジャは、このメッセージ
“committed”を受け取り、これで2段階コミット手順の
第1段階が完了する。第2段階は、この同期点マネジャが
回復ファシリティに状態レコードを送って、この同期点
の状態を「開始側カスケード、コミット済み」B10(図2
0)に更新する時に開始される。次に、B側の同期点マネ
ジャは、保護された会話を介してC側の同期点マネジャ
にメッセージ“committed”を送る。

【０１１４】C側の同期点マネジャは、このメッセージ
“committed”を受け取り、これで2段階コミット手順の
第1段階が完了する。C側の同期点マネジャは、回復ファ
シリティに状態レコードを送って、この同期点の状態を
「開始側カスケード、コミット済み」B11(図20)に更新
することによって、第2段階を開始する。メッセージ“c
ommitted”を受け取る参加者は他にはもう存在しないの
で、C側の同期点マネジャは、この同期点に関する作業
を完了している。このことを記録するために、C側の同
期点マネジャは、状態レコードを回復ファシリティに送
って、この同期点の状態を「忘却」B12(図20)に更新す
る。この状態を介して回復ファシリティは、この作業論
理ユニット識別子に関してC側の同期点マネジャが書き
込んだすべてのレコードが、もはや不要であり消去可能
であることを知る。この状態レコードが回復ファシリテ
ィのログに成功裡に書き込まれた後、C側の同期点マネ
ジャは、メッセージ“committed”に応答して、保護会
話アダプタを介してB側の同期点マネジャにメッセージ
“forget(忘却)”を送り、これでC側の同期点マネジャ
の2段階コミット手順の第2段階が終了する。このメッセ
ージ“forget”が送られた後、C側の同期点マネジャ
は、この同期点が成功裡に完了したとの指示と共に、制
御をアプリケーションCに返す。

【０１１５】B側の同期点マネジャは、C側の同期点マネ
ジャから保護会話アダプタを介して、メッセージ“forg
et”を受け取る。このメッセージ“forget”の受取り
は、B側の同期点マネジャがこの同期点を完了したこと
を示す。このことを記録するために、B側の同期点マネ
ジャは、回復ファシリティに状態レコードを送って、こ
の同期点の状態を「忘却」B13(図20)に更新する。この
状態から、回復ファシリティは、この作業論理ユニット
識別子に関してB側の同期点マネジャが書き込んだすべ
てのレコードが、もはや不要であり消去可能であること
を知る。この状態レコードが回復ファシリティに成功裡
に書き込まれた後、B側の同期点マネジャは、メッセー
ジ“committed”に応答して、保護会話アダプタを介し
てA側の同期点マネジャにメッセージ“forget”を送
り、これでB側の同期点マネジャの2段階コミット手順の
第2段階が終了する。メッセージ“forget”が送られた
後、B側の同期点マネジャは、この同期点が成功裡に完
了したとの指示と共に、制御をアプリケーションBに返
す。

【０１１６】A側の同期点マネジャは、このメッセージ
“forget”を受け取る。このメッセージ“forget”の受
取りは、A側の同期点マネジャがこの同期点を完了した
ことを示す。このことを記録するために、A側の同期点
マネジャは、回復ファシリティに状態レコードを送っ
て、この同期点の状態を「忘却」B14(図20)に更新す
る。この状態から、回復ファシリティは、この作業論理
ユニット識別子に関してA側の同期点マネジャが書き込
んだすべてのレコードがもはや不要であり消去可能であ
ることを知る。これでA側の同期点マネジャの2段階コミ
ット手順の第2段階が終了するが、このことは、この同
期点がそのすべての参加者について完了したことを意味
する。この状態レコードが回復ファシリティのログに成
功裡に書き込まれた後、A側の同期点マネジャは、この
同期点が成功裡に完了したとの指示と共に、制御をアプ
リケーションAに返す。

【０１１７】コミット手順におけるエラー・コードおよ
びエラー記述情報の処理の調整図32ないし35は、いずれ
かの資源または保護された会話がエラーまたは警告を報
告する場合に、アプリケーション56Aに戻りコードを与
える、システム50Aの構成要素を示す図である。また、
アプリケーション56Aは、それぞれの資源および保護さ
れた会話から、詳細なエラー情報を要求することができ
る。この詳細エラー情報は、報告元の資源を識別し、同
期点エラーの理由を記述し、同期点に関する警告のこと
もあり得る。

【０１１８】アプリケーション56Aは、システム50A内の
分散アプリケーション実行環境52A(図35参照)内で実行
中である。保護資源アダプタ62Aは、共用ファイル資源
マネジャ63A用のアダプタであり、資源アダプタ62Gは、
SQL資源マネジャ63G用のアダプタであり、保護会話アダ
プタ64Aは、保護会話アダプタ64Bを介するシステム50B
との保護された会話用のアダプタである。この例では、
アダプタ62Aおよび64Aは、システム50A内のシステム制
御プログラムに組み込まれた構成要素なので、同一の製
品識別子を有する。アダプタ62Gは、異なる製品の一部
なので、独自の製品識別子を有する。アダプタ62Aおよ
び64Aは、異なる資源アダプタ出口識別子を有する。こ
の例では、資源アダプタ62Gは、アプリケーション56Aに
は解読不能であって、アプリケーション56Aに詳細エラ
ー情報を返すための従来技術の機能を有する、エラー・
ブロックを生成する。

【０１１９】作業要求に応答して(図32のステップ65
1)、アダプタ62A、62Gおよび64Aが、同期点マネジャ60
に登録される(ステップ653)。同期点マネジャ60は、登
録オブジェクト162A、162Bおよび162Cを生成し、参加す
る資源(共用ファイル資源マネジャ63A、SQL資源マネジ
ャ63Gおよびシステム50B内の保護された会話のパート
ナ)の識別子を入れる。また、この登録情報は、資源ア
ダプタ出口ルーチン名、資源および保護された会話の製
品識別子、および各資源のエラー・ブロックの必要な長
さを含む。資源アダプタ出口ルーチン名は、この例のシ
ステム50A内のシステム制御プログラムなどの製品が、2
タイプの資源を所有する時に必要である。製品識別子と
資源アダプタ出口ルーチン名は共に、参加する資源のタ
イプ、たとえば共用ファイル資源マネジャ、SQL資源マ
ネジャ、または保護会話マネジャを識別する。1実行環
境内の同一タイプの資源の資源アダプタはすべて、シス
テム50Aのページング・セットを縮小するために、同一
のプールからのエラー・ブロックを使用する(図解は図3
4を参照されたい)。ある資源がステップ653(図32)で、
他のタイプの資源と同一のサイズのエラー・ブロックを
要求する場合、そのエラー・ブロック・プールがこれら
2つの資源によって共用される。

【０１２０】各登録物(62A、62Gおよび64A)について、
資源アダプタ出口ルーチンを呼び出すためのパラメータ
のリストが、同期点マネジャ60によって作成される。こ
のリストは、その資源のエラー・ブロックのアドレス
と、使用可能なエラー情報の長さを含む。登録エントリ
内に使用可能なエラー情報の長さを置いても、エラーが
発生しない場合には、システム50Aのページング・セッ
トは影響を受けない。

【０１２１】次に、アプリケーション56Aは、同期点マ
ネジャ60からのコミットを要求する(図32のステップ65
4)。アプリケーション56Aが、この同期点中にエラーが
発生する場合に共用ファイル資源マネジャ63Aからの詳
細な情報(システム50A内の共用ファイル資源マネジャの
従来技術の機能)を望む場合、アプリケーション56Aは、
詳細なエラー情報のコピーを記憶するための、その実行
環境内のデータ域のアドレスを、エラー・データ・アド
レスとしてこのCommit動詞と同時に送る(図32のステッ
プ654)。このデータは、資源マネジャ63Aがエラーまた
は警告を報告する場合に使用される。同期点マネジャ60
は、共用ファイル資源アダプタ62Aの代わりにこの動詞
を受け取り、エラー・データ・アドレスは、同期点マネ
ジャ60によってセーブされる。同期点の完了時に、すべ
てのエラーと警告(図32のエラー・ブロック66Aに記憶さ
れている)は、アプリケーション56Aのエラー・データ域
(図示せず)に移される。したがって、共用ファイル資源
マネジャの従来技術のエラー・パス・バック・アーキテ
クチャとの互換性が保たれている。

【０１２２】ステップ655(図32)で、同期点マネジャ60
は、各資源アダプタ(図35の62A、62Gおよび64A)に、登
録オブジェクト162Aないし162Cにセーブされたそのエラ
ー・ブロック(オブジェクト66Aないし66C)のアドレスを
渡す。登録オブジェクト162Aないし162Cは、資源アダプ
タが登録された時、各資源アダプタごとに作成されてい
る(ステップ653)。障害がない場合、ステップ654からの
コミットが完了し、その後同期点マネジャ60は、更新が
コミット済みであることをアプリケーション56Aに報告
する(ステップ657)。

【０１２３】ところが、ある資源がエラーまたは警告を
検出した場合には(図33のステップ670)、そのアダプタ6
2A、62Gまたは64Aは、エラー・ブロック66Aないし66C
(図32)を、設計上必要なものをすべて記憶するための場
所として使用して、詳細なエラー情報を入れ、入出力パ
ラメータである使用可能なエラーの長さを更新する。資
源アダプタ出口ルーチンは、2段階コミット手順中に何
回も呼び出すことができるので、必要に応じてエラー・
ブロックにエラー情報を付加できる。たとえば、3つの
警告と1つの重大なエラーがあってもよい。資源アダプ
タ出口ルーチンは、それ自体で使用可能なエラーの長さ
を管理する(ステップ672)。

【０１２４】同期点マネジャ60は、資源アダプタ出口ル
ーチンから、共通のフォーマットの単一の戻りコードを
受け取り、2段階コミット手順の論理を続行する(ステッ
プ673)。このとき、同期点マネジャ60は、エラー・ブロ
ック66Aないし66Cの内容を知らず、これに関心を持つこ
ともない。2段階コミット手順の論理がエラーまたは警
告を指摘した場合、同期点マネジャは、統合された戻り
コードをアプリケーション56Aに返す(図32のステップ65
7および図33のステップ674)。

【０１２５】この戻りコードを受け取ると、アプリケー
ション56Aは、同期点マネジャ60から提供されるルーチ
ンを呼び出すことによって、詳細なエラー・ブロックを
要求する(図33のステップ676)。これに応答して、同期
点マネジャ60内部のエラー・ブロック・マネジャ(図35
の機能690)が、空でないエラー・ブロックを探し、これ
をアプリケーション56Aのバッファに移動する。他の出
力パラメータは、このエラー・ブロックの所有者の製品
識別子と資源アダプタ出口ルーチン名である。次に、ア
プリケーション56Aは、この製品識別子を検査する。報
告を行った製品がシステム50A内のシステム制御プログ
ラムである場合(図33の判断ブロック678)、アプリケー
ション56Aは資源アダプタ出口ルーチン名を検査して、2
つのシステム制御プログラム・アダプタの区別を行う。
これで、エラー・ブロックでその資源名と障害の原因を
探すことができる(ステップ680Aまたは680B)。エラー・
ブロックの読取りを助けるためのシステム50A内のシス
テム制御プログラムから、共用ファイル資源マネジャと
保護された会話のための、マッピング・マクロが提供さ
れる。また、エラー・ブロックを都合の良い形であるパ
ラメータ・リストに再フォーマットするために、各アダ
プタからルーチン(図35の対話693)が提供される。共用
ファイル資源マネジャを使用する既存のアプリケーショ
ンは、エラー・パス・バック方法が変更されていないの
で、変更不要である。保護された会話は新規であるの
で、通信を使用する既存のアプリケーションに関する互
換性の目的には反しない。

【０１２６】製品がSQL資源マネジャである場合(図33の
判断ブロック681)、説明のため、エラー・ブロックが、
現在アプリケーション56Aが理解できる形ではないと仮
定すると、このエラー・ブロックを解読しなければなら
ない。したがって、アプリケーション56Aは、アプリケ
ーション56Aが理解できる形でエラーのタイプを識別す
るよう資源アダプタ62Gに要求する(ステップ682)。これ
に応答して(ステップ683)、SQL資源アダプタ62Gは、ア
プリケーション56Aの使用するルーチンに非常に類似し
てはいるが、資源アダプタ用に特殊化されたルーチンを
使って、同期点マネジャからエラー・ブロックを読み取
る。SQL資源アダプタ62Gとアプリケーション56Aは一義
的なトークンを与えられ、その結果、これらの双方が、
混乱することなく同一のエラー・ブロック内を巡回でき
ることに留意されたい。SQL資源アダプタ62Gは、エラー
・ブロック66C(図32)内のデータを再フォーマットし
て、アプリケーション56Aと互換性をもつ形に変換し(図
33のステップ684)、その後、この再フォーマットされた
詳細なエラー情報をアプリケーション56Aに送る(ステッ
プ685)。この例では、既存のSQL資源アダプタがエラー
情報の調整式処理に参加するには、些細な内部的な変更
しか必要でない、すなわち、同期点マネジャ60にエラー
・ブロックを要求しなければならないことに留意された
い。アプリケーション56Aが1つの資源しか更新しない場
合、既存のアプリケーションは変更を必要としないの
で、SQL資源アダプタのエラー・パス・バック・インタ
フェースの外見が保存される。アプリケーション56A
が、新しい機能である調整された同期点を使用している
ことを示す追加のエラー・コードは、非互換性とはみな
されない。

【０１２７】その後、アプリケーション56Aは、追加の
エラー・ブロックがあるか否かを決定するために、同期
点マネジャ60に照会を行う(図33のステップ676)。そう
である場合(判断ブロック677)、ステップ678ないし685
を繰り返して、同期点マネジャ60から1つまたは複数の
追加のエラー・ブロックを得る。これ以上エラー・ブロ
ックがない場合、判断ブロック677から図32のステップ6
88に進み、ここでアプリケーション56Aは処理を継続し
て、異なる機能を続行するか、あるいは障害の矯正を試
みる。

【０１２８】同期点マネジャ60は、前記「コミット手順
のための資源の登録」で述べたように、次の同期点まで
エラー・ブロックを保存する。

【０１２９】 保護された資源を回復するためのログ名の交換 アプリケーション56(図2)が同期点要求を発行する時、
すべての保護された資源に対する変更をコミットするた
めに、2段階コミット手順が開始される。保護された資
源には、資源マネジャによって管理されるデータベース
などの保護された資源、ならびに分散パートナ・アプリ
ケーションを表す保護された会話と称する特殊な分類の
資源が含まれる。「保護された資源の調整式同期点管
理」で述べたように、2段階コミット手順の第1段階は、
コミットのための資源の準備である。第1段階の間にす
べての資源マネジャがコミットに同意すると、第2段階
で実際のコミットを行う。第1段階の間に準備できない
資源がある場合、すべての資源は、第2段階の間にその
変更をコミットする代わりにバックアウトするよう命じ
られる。すべての資源データの変更は、それらが実際に
コミットされるまで、バックアウトの対象となる。

【０１３０】「分散アプリケーション用の未完了の同期
点のための回復ファシリティ」に記載するように、障害
のために同期点が完了できない時に同期点を完了させる
ための回復手順をサポートするには、その以前に同期点
情報が、持久記憶装置内にある回復ファシリティ・ログ
72および資源マネジャ・ログ800に記憶され、保持され
ていることが必要である。ロギングは、各同期点マネジ
ャ60ならびに参加する各資源マネジャ63によって行われ
る。ログに記録される情報には、ロギングを行う同期点
マネジャまたは資源マネジャからみた同期点の現在の状
態、既知の同期点参加者の同期点ログに関連する現在の
名前、および、同期点マネジャの場合には、同期点障害
からの回復の際に同期点参加者との会話を確立するのに
必要な情報が含まれる。

【０１３１】既知の同期点参加者のログ名に関する情報
は、その他の同期点情報とは分離または区分してロギン
グされる。このログ名情報は、ログ名ログ72A2(図21)に
記録され、残りの情報は、同期点ログ72A1に記録され
る。

【０１３２】いずれかの同期点ログに情報を記録する際
に障害が発生し、そのログを再初期設定する必要が生
じ、実際に新しいログを開始する時は、そのログに新し
い名前が割り当てられる。これが発生した時は、同期点
に参加する他の同期点マネジャおよび資源マネジャが、
新しいログの所有者および維持者と共に、そのログが再
初期設定されたこと、および新しい名前が有効であるこ
とを知らされることが重要である。

【０１３３】各同期点マネジャおよび参加者が、有効な
同期点ログを有することは、自動的再同期化のために不
可欠である。すなわち、再同期化の時点でのログは、同
期点中に使用されたものと同一のログでなければならな
い。いずれかのログが置換されまたは損傷を受けた場
合、再同期化は正常に進行できない。すべてのログが正
しいことを保証するために、各同期点マネジャおよび参
加する資源のログ名に関して同期点以前に同意が行われ
る。これはログ名交換と称する手順によって行われる。
再同期化の開始直前にもう1つのログ名交換があり、そ
の結果、すべての参加者のログ名が同期点開始時と同一
であると決定され、ログの再初期設定を行った参加者が
ないとわかるので、再同期を続行して、障害を発生した
同期点を回復することができる。この手順を省くと、無
効な同期点ログ情報のために、回復処理に障害が生じた
り、回復処理から誤った結果が生ずる可能性がある。

【０１３４】同一のシステム内のアプリケーション環境
(たとえば、システム50A内の分散アプリケーション環境
52Aおよび52B)間での保護された会話の最適化として
は、ログ名を交換する必要はない。というのは、同期点
マネジャ60Aおよび60Bが、それぞれ同一の回復ファシリ
ティ・ログ70Aおよび回復ファシリティ・ログ72Aを共用
しているからである。共通の回復ファシリティ・ログ72
Aが存在する時は、(ログ名交換による)ログ同期化のス
テップは、不要であり、省略してよい。同期点マネジャ
のロギングは、サポートされる同期点マネジャ60と同一
のシステム内に常駐する共通の回復ファシリティ70によ
って行われる。システム50A内の同期点マネジャ60A、60
B、60Cはすべて、共通の回復ファシリティ70Aを共用
し、回復ファシリティ・ログ72A内のログの、同一のサ
ポート対(同期点およびログ名)を共用している。

【０１３５】図36には、3つのシステム50A、50D、50F
と、そのそれぞれの中にある回復ファシリティと、これ
らのシステム間の通信が示されている。アプリケーショ
ン環境52A、52B、52D、52F、52Gは、それぞれ調整式の
資源回復のために同期点マネジャ60A、60B、60D、60F、
60Gを使用する、アプリケーション・プログラム56A、56
B、56D、56F、56G(図示せず)を含む。同期点マネジャ
は、そのシステム内の回復ファシリティを使用して、同
期点と、障害を発生した同期点からの回復に必要なログ
名ログとを管理する。たとえば、アプリケーション環境
52Aおよび52B内の同期点マネジャは、回復ファシリティ
70Aを使用してログ72Aに記録する。資源マネジャ63A、6
3B、63D、63E、63F、63Gは、それぞれそれ自体の同期点
と、ログ名ログ800A、800B、800D、800E、800F、800Gを
維持する。図示の同期点の範囲は、実線と矢印で示され
ている。同期点はいずれの参加者でも開始でき、かつ同
期点の範囲は動的であるが、図を簡単にするためにこの
図は静的なものである。この図の静的な場合では、同期
点は、アプリケーション環境の間で、52Bから52Dへ、さ
らに52Fへと、関連する同期点マネジャおよび保護会話
アダプタ(図示せず)を介し、通信の実線801および802を
経て流れ、またアプリケーション環境52A、52B、52D、5
2F、52Gから、関連する同期点マネジャおよび保護会話
アダプタを介し、それぞれ通信の実線803A−1、803A−
2、803B、803D、803E、803F、803Gを経て、資源マネジ
ャ63A、63B、63D、63E、63F、63Gへ流れる。点線は、同
期点以前の同意の際と、障害を発生した同期点を回復す
るための再同期化の際に使用される通信経路を示す。資
源マネジャにとって、この点線で示された通信は、起点
側アプリケーション環境のシステムの資源マネジャと回
復ファシリティの間に存在し、たとえば、資源マネジャ
63Eからは、70Dにではなく70Aに向かう。

【０１３６】3つの同期点の範囲が、図36に含まれてい
る。第1の範囲は、単一のアプリケーション環境52A(お
よび同期点マネジャ)を含み、2つの資源マネジャ63Aお
よび63Eを使用する。第2の同期点の範囲は、3つのアプ
リケーション環境52B、52Dおよび52Fを含み、これらは
それぞれ、様々な参加する資源マネジャ(52Bには63B、5
2Dには63Dと63E、52Fには63Fと63G)を含む。これを図37
の同期点ツリーに示す。

【０１３７】図21のブロック図および図22ないし図25の
流れ図は、システム50Aとシステム50Dの間の保護された
会話を使用するログ名交換の処理を実例によって示す図
である。アプリケーション56Aは、アプリケーション56D
との保護された会話を開始する(図22のステップ831)。
アプリケーション56Aはシステム50A内のアプリケーショ
ン環境52Aで実行中であり、アプリケーション56Dはシス
テム50D内のアプリケーション環境52Dで実行中である。
会話の開始には、経路(システム識別子、この例では
“B”)と、パートナ・アプリケーションの資源識別子を
指定することが含まれる。この経路はシステム50Dを識
別し、この資源識別子は目的のアプリケーション56Dを
識別する。資源識別子については、本節で後で詳しく説
明する。システム制御プログラムは、アプリケーション
の資源マネジャとして働くファシリティを含み、これは
アプリケーション用のアプリケーション資源識別子の確
立をサポートし、これらの識別子が会話開始に使用され
た際にこれを認識し、その後、実行環境内でアプリケー
ションを活動状態にし、またすでに活動状態である場合
には、新規の会話をその活動状態のアプリケーションに
経路指定する。したがって、アプリケーション用の会話
の経路指定には経路(システム識別子)と資源識別子を使
用する。その際に、経路は、それぞれシステムを代表す
る通信ファシリティの解釈に従ってシステム間の経路指
定を行い、資源識別子は、アプリケーション資源用の資
源マネジャとして働くシステム制御プログラムの解釈に
従って、システム内の実行環境内のアプリケーションへ
の経路指定またはそのアプリケーションの活動化を行
う。

【０１３８】この会話開始を受け取ると、通信ファシリ
ティ57Aは、その交換ログ名状況テーブル(EＬＳＴ)208A
を探索して、現経路である経路B用のエントリを求める
(図22のステップ833)。交換ログ名状態テーブルの経路B
用のエントリは、状況0によって、システム50Aが最後に
開始されて以降にこの経路上には保護された会話が発生
していないことを示す。したがって(図22の判断ステッ
プ834)、交換ログ名状態テーブルの経路B用のエントリ2
08Aが、状況1に変更され(図22のステップ836)、会話開
始メッセージ505(図21)が代行受信され、この会話は、
通信ファシリティ57Aによって中断される(図22のステッ
プ837)。次に、通信ファシリティ57A(図21)は、ローカ
ルの回復ファシリティ70Aへの制御経路上にメッセージ2
00(図21)を送って、この会話開始が通信ファシリティ57
Aに受諾されないうちに、経路Bに対してログ名交換を初
期設定すべきであると指示する(図22のステップ838)。

【０１３９】回復ファシリティ70Aは、このメッセージ
を受け取り(図23のステップ850)、その後、EＬＳＴ207A
の経路B用のエントリを状況1にセットして、経路B用の
ログ名交換が進行中であることを示す(図23のステップ8
51)。次に、回復ファシリティ70A(図21)は、通信経路B
上で保護されない会話を開始する(図21のメッセージ20
2)。この会話は「保護されていない」ので、通信ファシ
リティによる代行受信の可能性はない。というのは、保
護された会話だけが、ログ名交換手順を強制するために
代行受信があるかどうか監視されるからである。システ
ム50Aからシステム50Dへの通信ファシリティを介する経
路指定は、上記と同様である。

【０１４０】この会話開始は、資源識別子protected_co
nversation_recovery(保護会話回復)と称する、グロー
バルに予約された資源識別子も使用する。この資源識別
子を使用すると、識別された目的システム50Dの回復フ
ァシリティ70Dへの経路指定が可能になる。回復ファシ
リティ70Aおよび70Dはそれぞれ、初期設定の際に、シス
テム制御プログラムに対して、“protected_conversati
on_recovery”と称するグローバル資源に対するローカ
ル資源マネジャとしてそれ自体を識別する。この結果、
システム50D用のシステム制御プログラムは、protected
_conversation_recovery資源識別子を有する会話を、ロ
ーカルの回復ファシリティ70Dに経路指定し、また回復
ファシリティ70Dは、この会話を開始するのに使用され
たprotected_conversation_recovery資源識別子に基づ
いて、この会話の目的が、別の回復ファシリティ70Aと
のログ名交換であると判定する。この会話の初期メッセ
ージ202(図21)は、ログ72Aのログ名、ならびにそのログ
名が「新規」であるか否か、すなわち、「旧」ログに関
連する重大な障害または喪失の結果としてそのログ名が
新規のログを反映するように変更されたか否かの標識を
含む(図23のステップ852)。現在の例では、このログは
新規ではないと仮定する。回復ファシリティ70Aは、メ
ッセージ202(図21)に対する応答を待つ。

【０１４１】回復ファシリティ70Dは、通信線202に沿っ
て回復ファシリティ70Aから送られたログ名情報を受け
取った後に(図25のステップ870)、経路Bに関するEＬＳ
Ｔ207Dを状況1にセットし、ローカル通信ファシリティ5
7Dは、メッセージ203(図21)を介して、やはり経路Bに関
するEＬＳＴ208Dを状況1に変更するよう通知される(図2
5のステップ871)。図22のステップ841、図22のステップ
842、図22のステップ843および図22のステップ846は、
通信ファシリティ内のEＬＳＴを変更するステップを示
す。回復ファシリティ70Dは、メッセージ202(図21)か
ら、回復ファシリティ70Aのログ名が新規でなく(図25の
判断ステップ872)、それ自体のログも新規ではない(図2
5の判断ステップ876)と判定し、最後に、メッセージ202
(図21)内のログ名が、回復ファシリティ70Dのログ名ロ
グ72D2の経路Bに関するエントリに記憶されたログ名と
一致すると判定する。したがって、EＬＳＴ207Dは、経
路Bに関して状況2にセットされ、ローカル通信ファシリ
ティ57Dは、メッセージ203(図21)を介して、やはり経路
Bに関するEＬＳＴ208Dを状況2にセットするよう通知さ
れる(図25のステップ879、図22のステップ841および図2
2のステップ842)。その後、回復ファシリティ70Dは、回
復ファシリティ70Aに正常に応答して(図21のメッセージ
206)、そのログ72Dのログ名とそれが新規であるか否か
の標識を送る(図25のステップ882)。

【０１４２】回復ファシリティ70Aは、この正常な応答
を受け取り(図23の判断ステップ853)、回復ファシリテ
ィ70Aのログ72Aが新規ではなく(図23の判断ステップ85
7)、メッセージ206(図21)によれば回復ファシリティ70D
のログ72Dが新規ではないので(図23の判断ステップ85
8)、回復ファシリティ70Aは、回復ファシリティ70Dから
メッセージ206(図21)中で送られたログ72Dの名前と、ロ
グ72A2の経路Bに関するエントリに記憶されたログ名の
突合せに成功し(図23の判断ステップ859)、したがっ
て、EＬＳＴ207Aの経路Bに関するエントリを状況2にセ
ットし、メッセージ204(図21)を介して、ローカル通信
ファシリティ57Aに、EＬＳＴ208Aを状況2にセットする
よう通知する(図24のステップ862)。その後、回復ファ
シリティ70Aは、経路B上の回復ファシリティ70Dとの会
話の正常終了を行って(図24のステップ863)、回復ファ
シリティ70Dが、正常に完了できるようにする(図25の判
断ステップ883と図25のステップ886)。通信ファシリテ
ィ57Aが、経路Bの状況をEＬＳＴ208Aに記入するよう伝
えるメッセージ204(図21)を受け取ると(図22のステップ
841と図22のステップ842)、代行受信され中断された経
路B上の会話505は、その初期設定を完了できるようにな
る(図22の判断ステップ843、図22のステップ845および
図22のステップ846)。この完了によって、この会話の中
断状態が解消され、この会話は、その宛先である通信フ
ァシリティ57Dに向かって流れることができるようにな
る。目的の通信ファシリティ57Dで保護会話到着事象(図
22のステップ832)があり、その後、EＬＳＴ208D内の経
路エントリを検索して、状況が2であることが示され(図
22の判断ステップ834)、この会話開始が、アプリケーシ
ョン56Dに正常に流れることができるようになる(図22の
ステップ839)。

【０１４３】これで、会話の代行受信とログ名交換の正
常な場合の流れが完了する。いくつかの追加の場合も図
示されている。図22のステップ834と図22のステップ835
は、この経路用のログ名交換がすでに進行中であること
を示す1の状況が確立されると、同一の経路上の追加の
会話も中断されることを示している。

【０１４４】目的の回復ファシリティ70Dが、メッセー
ジ202(図21)中で送られたログ名と経路Bに関してログ72
D2に記憶されたログ名が一致しないことを見つけた場合
(図25の判断ステップ877)、メッセージ206(図21)中でエ
ラーが戻され(図25のステップ880)、EＬＳＴ207Dは、経
路Bに関して状況0にセットされ、通信ファシリティ57D
は、メッセージ203(図21)を介して、同様にそのEＬＳＴ
208Dを変更するよう通知される(図22のステップ841、図
22のステップ842および図25のステップ881)。

【０１４５】原始ログ72Aが新規であり(図25の判断ステ
ップ872)、ログ72Dも新規である(図25の判断ステップ87
3)ことを示すメッセージ202(図21)を、回復ファシリテ
ィ70Dが受け取った場合、ログ72Aの新規のログ名が、経
路Bに関するログ72D2に記憶され(図25のステップ878)、
前記と同様に正常な完了が継続する(図25のステップ87
9、図25のステップ882など)。

【０１４６】原始ログ72Aは新規であるが(図25の判断ス
テップ872)、ログ72Dは新規でない(図25の判断ステップ
873)ことを示すメッセージ202(図21)を、回復ファシリ
ティ70Dが受け取り、かつ同期点ログ72D1から、経路Bに
関して未解決の同期点回復(未処理の再同期化)が存在す
ると判定された(図25の判断ステップ874)場合には、シ
ステム50Dの操作員に対してエラー・メッセージが生成
され(図25のステップ875)、メッセージ206(図21)中で、
回復ファシリティ70Aにエラーが戻され(図25のステップ
880)、EＬＳＴ207Dは状況0に変更され、ローカル通信フ
ァシリティは、メッセージ203(図21)を介して、EＬＳＴ
208Dを状況0に変更するよう通知され(図25のステップ88
1、図22のステップ841、図22のステップ842)、その後、
リターンする(図25のステップ882)。

【０１４７】回復ファシリティ70Aが、回復ファシリテ
ィ70Dからのメッセージ206(図21)中でエラー応答を検出
し(図23の判断ステップ853)、かつ未処理の再同期化が
存在するとログ72A1で示される(図23の判断ステップ85
4)場合には、システム50Aの操作員にメッセージが送ら
れ(図23のステップ855)、EＬＳＴ207Aおよび208Aは、状
況0に変更される(図23のステップ856)。EＬＳＴ208A
は、通信ファシリティ57Aに対するメッセージ204(図21)
を介して状況0に変更される(図22のステップ841と図22
のステップ842)。この結果、代行受信された会話を開始
したアプリケーション56Aにエラーが戻され、会話は拒
絶される(図22のステップ844)。未処理の再同期化がな
い場合は(図23の判断ステップ854)、操作員にメッセー
ジは送られない(図23の判断ステップ854)。

【０１４８】回復ファシリティ70Dからのメッセージ206
(図21)中で、新規のログ名が回復ファシリティ70Aに戻
されると(図23の判断ステップ857)、このログ名はログ7
2A2の経路Bに関するエントリに記憶され(図24のステッ
プ861)、2のEＬＳＴ状況が経路Bに関してセットされ(図
24のステップ862)、通信ファシリティ57Aは、この会話
を中断から解放する(図22のステップ841、図22の判断ス
テップ843および図22のステップ845)。

【０１４９】回復ファシリティ70Dからメッセージ206
(図21)中で戻されたログ名が、経路Bに関してログ72A2
に記憶された名前と一致しないことを回復ファシリティ
70Aが検出するか(図23の判断ステップ858および859)、
あるいはログ72D2に対して新規のログ名が戻され(図23
の判断ステップ858)、経路Bに関して必要な未処理の再
同期化が存在するとログ72A1から回復ファシリティ70A
が決定した(図24の判断ステップ860)場合は、回復ファ
シリティ70Aは、メッセージ202および206(図21)をサポ
ートした会話を異常終了させることによって、回復ファ
シリティ70Dに重大なエラーが存在することを知らせ(図
24のステップ864)、システム50Aの操作員に対するメッ
セージを生成し(図24のステップ865)、EＬＳＴ207Aの状
況をリセットし、通信ファシリティ57Aに対するメッセ
ージ204(図21)を介して、EＬＳＴ208Aの状況をもリセッ
トする(図24のステップ866)。この結果、代行受信され
た会話を開始したアプリケーション56Aにエラーが戻さ
れ、会話は拒絶される(図22のステップ844)。

【０１５０】すべての場合において、回復ファシリティ
70Dは、回復ファシリティ70Aに応答(図25のステップ88
2)した後であっても、会話の異常終了を通じて回復ファ
シリティ70Aから送られるエラー(図24のステップ864)を
検出することができる(図25の判断ステップ883)。それ
が発生した時、EＬＳＴ207Dの経路Bのエントリと、通信
ファシリティ57Dへのメッセージ203(図21)(および図22
のステップ841と図22のステップ842)を介してEＬＳＴ20
8Dの経路Bのエントリとが、状況0にリセットされ(図25
のステップ884)、ログ72D2の経路Bに関するログ名エン
トリが消去され(図25のステップ885)、以前のステップ8
78(図25)を否定する。

【０１５１】図21のEＬＳＴ208Aおよび208Dに示される
ように、各通信ファシリティは、各経路に対する会話の
代行受信(状況2以外)、ログ名交換の開始(状況0)および
正常な会話の流れ(状況2)を制御する。各回復ファシリ
ティが維持するEＬＳＴ207Aおよび207Dも同様である
が、任意選択の最適化である。EＬＳＴ207Aおよび207D
を用いると、通信ファシリティのEＬＳＴの更新が実際
には不要である時に、ローカル通信ファシリティに対す
る更新要求のメッセージが回避できる。これについては
後でさらに説明する。

【０１５２】図21には、さらに、システムのうちの1つ
が障害を発生した時に必要な処理が示されている。通信
ファシリティ57A、回復ファシリティ70Aまたはそれらの
間の通信経路に障害があるものと仮定する。このような
障害は、通信ファシリティ57A内のEＬＳＴ208Aおよび回
復ファシリティ内70AのEＬＳＴ207Aを状況0にリセット
させる。このことが重要なのは、そうしないと、このよ
うな障害によって、ログ障害も発生していた可能性がマ
スクされ得るためである。この可能性のゆえに、交換ロ
グ名状況テーブルのエントリの状況を0にすることによ
って、すべての同期点同意がリセットされる。アプリケ
ーション環境52Aまたは52Dの障害は、これらのアプリケ
ーション環境がログ名交換処理に直接影響しないので、
ログ名交換状況テーブルのリセットを起こさないことに
留意されたい。アプリケーション環境はシステム・ファ
シリティよりも障害を発生しやすいので、このことは重
要である。同様に、共通の論理経路(図示せず)を共用す
る複数のアプリケーション環境のうちの1つの障害は、
その経路を使用する他のアプリケーションの処理には影
響を与えない。

【０１５３】さらに、通信ファシリティ57A、回復ファ
シリティ70Aまたはそれらの間の制御経路の障害の後
に、アプリケーション56Dが、アプリケーション環境52A
内のアプリケーション56Aに対する経路Bに沿った会話を
開始するものと仮定する。通信ファシリティ57D内の交
換ログ名状況テーブルは、経路Bの状況が2であり、通信
ファシリティ57D内のテーブルが、システム50Aに障害が
発生した際にはリセットされなかったことを示している
ので、この会話は、通信ファシリティ57Dによって代行
受信されない。ところが、この会話が通信ファシリティ
57Aまで達すると、保護会話到着事象があり(図22のステ
ップ832)、EＬＳＴ208Aを検索すると、状況が0であるこ
とが示され(図22の判断ステップ834)、通信ファシリテ
ィ57Aはこの会話の経路指定を代行受信し(図22のステッ
プ836と図22のステップ837)、したがって通信ファシリ
ティ57Aは、回復ファシリティ70Aに対するメッセージ20
0(図21)によって、ログ名交換を要求する(図22のステッ
プ838)。これによって、前述のログ名交換処理が繰り返
される。このログ名交換がその交換処理中に回復ファシ
リティ70D中で受け取られた時、回復ファシリティ70D内
の交換ログ名状況テーブルは、経路Bのエントリの状況
が2であることを示す。したがって、回復ファシリティ7
0Dは、通信ファシリティ57Dに、経路Bに関して交換ログ
名状況テーブルを変更するよう通知することはしない。
このような交換は不要である。この点が、このログ名交
換処理における、上述の障害発生前の処理との唯一の相
違点である。ログ名交換処理が完了した後に、回復ファ
シリティ70Aは、メッセージ204(図21)を介して通信ファ
シリティ57Aに、経路Bの状況を0から2に変更するよう通
知する。その後、通信ファシリティ57Aは、経路Bに沿っ
た会話を解放し、この会話がアプリケーション52Aに流
れるようになる。

【０１５４】前述の2つの例では、回復ファシリティ70A
が、メッセージ202(図21)を介して経路B上のログ名交換
を開始したことに留意されたい。しかし、その代わり
に、通信ファシリティ57Dが保護された会話を最初に代
行受信する通信ファシリティであった場合には、回復フ
ァシリティ70Dが、メッセージ206(図21)で示されるログ
名交換処理を開始する。保護された会話のために同一の
経路を使用する、同一のシステム50A内のすべてのアプ
リケーション環境に対して同期点以前の同意を満足する
には、単一のログ名交換で十分なことにも留意された
い。共通のログ名交換状況テーブル208Aに記録すること
によって、これが可能になる。さらに、同一のシステム
内にあるすべてのアプリケーション環境が同一のログ72
を共用するので、保護された会話に関係するシステム50
Aおよび50Dのそれぞれにアプリケーション環境が複数存
在する時でも、同期点以前の同意の要件を満足するに
は、上述の単一のログ名交換処理で十分であることに留
意されたい。また、保護された会話が、アプリケーショ
ン環境52Aからそれと同一のシステム50A内にあるアプリ
ケーション環境52Bに向けて開始される時は、アプリケ
ーション環境52Aおよび52Bが同一のログ72Aを共用し、
ログ名交換が不要であるので、通信ファシリティ57Aは
この会話を代行受信しない。

【０１５５】たとえば、この体系的システム間通信の標
準は、IBMコーポレーションの刊行物“System Network
Architecture LU 6.2 Reference: Peer Protocols, SC3
1-6808, Chapter 5.3 Presentation Services - Sync P
oint Verbs”に記載のタイプのものでよい。本節で述べ
たログ名交換は、交換の実行、制御および最適化のため
の処理を対象とするのであって、交換用の体系的プロト
コルを対象としてはいない。

【０１５６】ログ名交換は、回復ファシリティと、共用
ファイルやデータベースなどの保護された資源の資源マ
ネジャとの間でも必要である。同一のシステム内で会話
が行われる時(会話が共通の同期点ログを共用するので)
ログ名交換が不要である、保護された会話とは違って、
資源マネジャはそれ自体の同期点ログを維持するので、
参加する資源マネジャが開始側のアプリケーションと同
一のシステム内にある場合であっても、それらの資源マ
ネジャにはログ名交換が必要である。上記のSystem Net
work Architecture LU 6.2に記載の保護された会話とロ
グ名交換を確立するための通信プロトコルが使用でき
る、保護された会話とは違って、保護された資源は、こ
れらの機能のために、保護されない会話と専用のメッセ
ージ・プロトコルを使用する。また、保護された資源で
は、通信ファシリティを代行受信機能として用いること
によって資源マネジャに対する初期の通信を集中的に代
行受信することが、あらゆる場合に実用的なわけではな
い。これらの通信が必ずしも通信ファシリティを介して
進行するわけではないからである。この1例が、アプリ
ケーション環境52Aと同一のシステム50A内にある資源マ
ネジャ63A(図2)と、その資源を使用するアプリケーショ
ン56Aの場合である。この状況では、通信ファシリティ
を通過するのに資源との会話は不要であるが、その代わ
りに会話マネジャ53Aまたは他のローカルなファシリテ
ィを介した会話をサポートする。もう1つの理由は、資
源マネジャがその資源のユーザとの会話の方法を完全に
変更する必要なしにSystem Network Architecture LU
6.2の通信プロトコルに適合できるように、資源マネジ
ャのサポートに柔軟性を与えることである。同期点障害
からの自動的な回復処理には、上述の保護された会話の
場合と同様に、様々な参加者のログの名前がその同期点
が始まる前と同一であることが必要である。

【０１５７】図26は、保護された資源のマネジャに関す
るログ名交換を示す図である。この実施例では、システ
ム50Aは、アプリケーション環境52A、関連する資源アダ
プタ62A、回復ファシリティ70Aおよび共通の資源回復の
ログ72Aを含む。資源マネジャはローカルでもリモート
でもよいが、この図はローカルの場合である。以下で詳
細に説明するように、リモート資源マネジャの場合の処
理は、システム間通信の完了に通信ファシリティが使用
される点を除いて、基本的に同一である。ローカルであ
れリモートであれ、保護された会話は、通信には必ず通
信ファシリティを使用して、同期点以前の同意のための
ログ名交換を開始するための共通の代行受信点を提供す
るのに対して、資源マネジャは、図のように、ローカル
の場合には通信ファシリティの使用を回避することがで
き、同期点以前のログ名交換を開始するための上記の集
中的代行受信点はない。

【０１５８】ログ800A内のログ名ログ800A2は、資源マ
ネジャ63Aと関連づけられており、開始側の回復ファシ
リティ70Aのログ72Aの名前を記憶する。また、ログ800A
内の同期点ログ800A1は、資源マネジャ63Aと関連づけら
れており、同期点手順における、その保護された資源の
状態を記憶する。以下で詳細に説明するように、図26
は、同期点マネジャと参加する資源マネジャの間での適
時のログ名交換と、ログ72Aおよび800Aの一方または両
方の再初期設定を強制する障害によってもたらされたロ
グ名の変更を認識する能力とを保証するのに必要な、不
可欠の要素を示す図である。アプリケーション56Aが、
資源アダプタ62Aを介して資源マネジャ63Aに要求を送っ
た時(図29のステップ221)、資源アダプタ62Aは、同期点
マネジャ60Aを呼び出して、下記のものを要求する(ステ
ップ222)。1.回復ファシリティのログ72Aのログ名2.資
源マネジャ63Aによる初期のログ名交換のために回復フ
ァシリティ70Aとの会話を確立するのに必要な、回復フ
ァシリティ70Aの資源識別子log_name_log。この識別子
は、回復ファシリティ70Aを一義的に識別し、また回復
ファシリティ70Aが、入りログ名交換会話を、以下で説
明するように、接続のために資源識別子sync_point_log
を使用する同期点マネジャの会話などの他の会話から区
別できるようにする。その後、同期点マネジャ60Aは、
資源識別子sync_point_logを使用して、ローカル回復フ
ァシリティ70Aとの会話を確立する(図29のステップ22
3)。

【０１５９】資源識別子は、システム内の資源を識別す
るのに使用され、より具体的には、そのシステム内の現
在の実行環境内の資源のマネジャへの会話を完了するた
めに使用される。ある資源のマネジャは、その初期設定
時に、システム制御プログラム・ファシリティを使っ
て、資源をシステムに対して識別する。システム制御プ
ログラムは、強制的にこれらの資源識別子を一義的なも
のにする。図2の資源マネジャ63に加えて、他のファシ
リティも資源マネジャとして活動できる。その1例が回
復ファシリティ70であり、この回復ファシリティ70のロ
グは、回復ファシリティ70がその資源識別子を有する資
源であると見なされる。資源には4つのタイプがあり、
そのそれぞれが、資源識別子のタイプによって識別され
る。これらのうちの第1のものは、基本的に総称的であ
り、どんな資源も含むように拡張することができる。そ
の他のものは、明確に資源回復用に定義されている。1.
資源識別子objectによって識別される、object(オブジ
ェクト)資源。これは資源マネジャ63によって管理され
るオブジェクト78の集合である。これは、総称的資源マ
ネジャとその資源の場合であり、この資源は、データ・
ファイル、待ち行列、記憶装置またはアプリケーション
からなる集合を含むあらゆる資源に拡張することができ
る。このタイプの資源識別子は、その資源のマネジャ63
の所有する資源を、たとえばファイル・オープン、アプ
リケーションの起動など何らかの形で使用するために、
資源マネジャとの会話を確立するのに使用される。2.資
源識別子object_recoveryによって識別されるobject_re
covery(オブジェクト回復)資源。これは、資源マネジャ
のログ800であり、障害を発生した同期点手順から回復
する際の回復ファシリティ70との協力の手順をサポート
する。この識別子は、障害を発生した同期点から回復す
る時点で、その資源のマネジャ63との会話を確立して、
自動的回復の一部としてログ名を交換し、その同期点を
完了するために、回復ファシリティ70が使用する。3.資
源識別子sync_point_logによって識別されるsync_point
_log(同期点ログ)資源。これは回復ファシリティ70Aに
よって管理されるログ72A(図21および図26)と、ログ72A
の保守をサポートする1組の手順である。この識別子
は、同期点の状況に関するログ情報を提供するために、
同期点マネジャ60(図2)が、その回復ファシリティ70と
の会話を確立するのに使用する。4.資源識別子log_name
_logによって識別されるlog_name_log(ログ名ログ)資
源。これは、回復ファシリティ70Aによって管理される
ログ名ログ72A2(図26)と、ログ名ログ72A2の保守をサポ
ートする1組の手順である。この識別子は、適当な回復
ファシリティ70Aとの会話を確立して、その回復ファシ
リティ70Aとログ名を交換するために、資源マネジャ63A
が使用する。

【０１６０】回復ファシリティ70Aとの接続を確立した
後に、同期点マネジャ60Aは、資源アダプタ62Aが要求し
た回復情報を得る。この回復情報は、同期点マネジャ60
Aによって資源アダプタ62Aに戻され(図29のステップ22
4)、要求を行っている他の資源アダプタにを解放するた
めに、同期点マネジャ60Aがこれを保持する。次に、資
源アダプタ62A(図26)は、同期点マネジャ60A(図26)に、
下記の同期点回復情報をも提供する(図29のステップ22
5)。 1.同期点中に障害が発生した場合に、資源マネジャ63A
に接続するために回復ファシリティ70A(図26)が使用す
ることのできる、資源識別子object_recovery。この資
源識別子object_recoveryを使用すると、資源マネジャ
は、それぞれその処理に異なるプログラムを必要とす
る、資源アダプタ62Aからの入り会話と回復ファシリテ
ィ70Aからの入り会話を区別できるようになる。全資源
マネジャ用の標準のobject_recovery資源識別子を確立
するのではなくて、資源アダプタ62Aを介して資源マネ
ジャ63Aにそれ自体の資源識別子object_recoveryを提供
する能力を与えることによって、回復ファシリティ70A
は、この資源マネジャ63Aまたは他のいずれかの資源マ
ネジャの使用する他の資源識別子との衝突を回避して、
すべての資源マネジャが同期点処理に参加するための、
一般化された非破壊的なインタフェースを維持する。 2.同期点障害が存在する時、その同期点に参加する資源
マネジャ63Aを識別し、ログ名ログ72A2のそれ用のエン
トリを見つけるために、回復ファシリティ70Aが使用で
きる資源識別子object。この識別子は、同期点の管理、
同期点障害の場合の同期点のロギング、および障害を発
生した同期点からの回復のために、資源マネジャを一義
的に識別する。

【０１６１】上述の資源78Aの使用を求めるアプリケー
ション56Aの最初の要求に従って、資源アダプタ62Aは、
それ自体の資源識別子objectを使用して、資源マネジャ
63Aへの会話を初期設定し、回復ファシリティ70Aの資源
識別子log_name_logと、同期点マネジャから取得したロ
グ72Aの現在の名前とを含む、回復情報を渡す(図29のス
テップ226)。

【０１６２】図26では、資源回復に責任を負う回復ファ
シリティ70Aが1つだけ示されているが、複数のシステム
内にあるそれぞれそれ自体の回復ファシリティを備えた
複数のアプリケーションが資源を使用することがあるの
で、単一の資源マネジャで複数の回復ファシリティを扱
うことができる。これが図36に示されている。図36にお
いて、資源マネジャ63Eは、システム50A内のアプリケー
ション52Aとシステム50D内のアプリケーション52Dの両
方によって使用され、したがって2つの回復ファシリテ
ィ70Aおよび70Dからのログ名情報を必要とする。

【０１６３】障害を発生した同期点の回復をサポートす
るために、資源マネジャ63Aは、ログ名ログ800A2(図26)
に、各回復ファシリティのログ72の名前用のエントリを
必要とする。これらの各ログ名はそれぞれ、1つまたは
複数のアプリケーション56と同期点マネジャ60を介して
資源を使用するシステム50の1つを表す。参加する資源
マネジャ63A用のログ名ログ800A2(図26)は、関連する回
復ファシリティ70のそれぞれについて、下記の情報を含
む。 1.関連する各回復ファシリティ70(図26の場合は回復フ
ァシリティ70A)を識別する資源識別子log_name_log。 2.回復ファシリティ70のログ名(図26の場合、ログ72Aの
名前)。 3.ログ名が成功裡に交換済みであることを示すexchange
_done(交換終了)フラグ。exchange_doneフラグは、論理
的にはログ名ログ800A2(図26)の一部であるにもかかわ
らず、それに関連する資源マネジャが初期設定されるご
とに論理的にリセットされるので、これを持久記憶装置
に書き込む必要はない。このフラグの目的は、特定の回
復ファシリティ70Aのあるシステム50A内で動作中の資源
アダプタ62Aからの最初の会話を除き、その回復ファシ
リティ70Aに関するログ名交換を避けることである。1つ
のシステム内に、すべてが同一の回復ファシリティのサ
ービスを受け、それぞれが同一のまたは異なる資源マネ
ジャとの会話を有する資源アダプタを備える、多数のア
プリケーション環境が存在することがある。資源マネジ
ャがログ名交換を開始する必要があるのは、同一の回復
ファシリティに関連する資源アダプタの1つとの会話の
最初のインスタンスの際だけである。フラグexchange_d
oneがセットされると、それ以後の交換が防止される。

【０１６４】図29の残りの部分には、ログ名交換を開始
する時を決定するために、資源マネジャ63A(図26)が実
行するアルゴリズムが示されている。資源識別子object
を最初に受け取った時(ステップ226)、資源マネジャ63A
は、ログ名ログ800A2を検索して、資源アダプタ62A(図2
6)から渡された回復情報に含まれる資源識別子log_name
_logによって識別される回復ファシリティ70A用のエン
トリがあるか否かを判定する(図29のステップ230)。こ
の資源マネジャは、ログ名ログ800A2(図26)を検索する
のに、資源アダプタから受け取った資源識別子log_name
_logを使用する。エントリがない場合、資源マネジャ63
Aはログ名交換を開始する(図29のステップ232)。ステッ
プ230で、回復ファシリティ70A(図26)用のエントリが見
つかった場合、資源マネジャ63Aは、フラグexchange_do
neがセットされているか否かを判定する(図29のステッ
プ234)。フラグexchange_doneは、ログ名交換が成功し
た時にセットされ、資源マネジャが異常終了するかまた
は正常に遮断されるまで、セットされたままである。回
復ファシリティとの会話を開始するのに失敗したため
に、資源マネジャがログ名を交換できない場合には、資
源マネジャは、その資源アダプタによって開始された会
話を打ち切る。フラグexchange_doneがセットされてい
ない場合、資源マネジャ63A(図26)は、ステップ232(図2
9)でログ名交換を開始する。しかし、フラグexchange_d
oneがセットされている場合には、資源マネジャ63A(図2
6)は、資源アダプタ62Aから送られたログ名を、前記の
エントリ内のログ名と比較する(図29のステップ236)。
これら2つのログ名が同一である場合には、資源マネジ
ャはログ名交換を開始しないが(図29のステップ242)、
異なる場合には、資源マネジャ63A(図26)は、ステップ2
32(図29)でログ名交換を開始する。前述のアルゴリズム
は、資源マネジャがいずれかの回復ファシリティに関連
する資源アダプタと初めて通信する際に、その回復ファ
シリティに関してログ名が交換されることを保証する。
また、このアルゴリズムは、その後に回復ファシリティ
70A(図26)用のログ名が変更される時、ログ名が交換さ
れることを保証する。後者の場合、資源マネジャ63Aが
資源アダプタから回復ファシリティのログ72Aの新しい
名前を得る場合であってもこのログ名交換は必要であ
る。というのは、回復ファシリティ70Aのログ名ログを
資源マネジャ63Aのログ名ログと同期させなければなら
ず、回復ファシリティ70Aに資源マネジャのログ800Aの
ログ名を与えることが必要だからである。

【０１６５】ステップ232(図29)の、資源マネジャ63A
(図26)と回復ファシリティ70Aの間でのログ名交換は、
図30にさらに詳しく示されており、以下のステップを含
む(ログ72Aがそのログであると仮定する)。 1.図30のステップ243。資源マネジャ63A(図26)が、資源
アダプタ62Aから得た資源識別子log_name_log を使用し
て、回復ファシリティ70Aとの会話250を開始する。 2.図30のステップ243。資源マネジャ63A(図26)が、回復
ファシリティ70Aに資源マネジャ63Aを一義的に識別する
object資源識別子を送る。 3.図30のステップ244。資源マネジャ63A(図26)が、回復
ファシリティ70Aにログ800Aのログ名を送る。 4.図30のステップ245。回復ファシリティ70A(図26)が、
資源マネジャ800Aのログ名で、ログ名ログ72A2を更新す
る。 5.図30のステップ246。回復ファシリティ70A(図26)が、
資源マネジャ63Aに応答を戻して、ログ72Aのログ名を与
える。 6.図30のステップ247。資源マネジャ63A(図26)が、ログ
72Aの名前でログ名ログ800A2を更新する。 7.図30のステップ248。資源マネジャ63A(図26)が、ログ
名ログ800A2内のフラグexchange_doneをセットする。

【０１６６】アプリケーション56A(図26)が、同期点マ
ネジャ60Aから同期点を要求する時、同期点マネジャ60A
は、上記の資源識別子object_recoveryと資源識別子obj
ectを回復ファシリティ70Aに送り、そこではこれらの識
別子がその同期点処理の状態を記述する情報と共に同期
点ログ72A1に記憶される。同期点中に障害が発生した場
合、回復ファシリティ70Aが活動化されて、同期点手順
を完了するのに必要な動作を行う。障害を発生している
同期点に資源が参加していた場合、関連する回復ファシ
リティの同期点ログのエントリ内の回復情報を使用し
て、回復を達成するためにそれらの資源とコンタクトす
ることが可能になる。たとえば、アプリケーション56A
が2段階コミット動作中にダウンした場合、回復ファシ
リティ70Aが、活動化された後に、資源マネジャ63Aとロ
グ名を交換する。この第2の交換で、この同期点の開始
以降にログ名が変化していないことが示された場合に
は、回復ファシリティ70Aは、この同期点の回復を続行
できることを知る。この交換でログ名が一致しない場合
は、自動的回復に必要なログ情報が失われており、した
がって自動的回復を試みてはならないことを示してい
る。回復ファシリティ70Aは、第2のログ名交換を開始
し、資源マネジャ63Aに、この障害前の資源マネジャ63A
の状態または段階がどうであったかを尋ねる。上述した
ように、最初のログ名交換が資源マネジャによって開始
されるのに対して、障害発生後に必要なログ名交換は、
下記のように回復ファシリティ70Aによって開始され
る。 1.障害を発生している同期点に関連する同期点ログ72A1
内に回復情報がある各資源について、回復ファシリティ
70Aは、同期点ログ72A1のエントリ内で見つかった資源
識別子objectを、ログ名ログ72A2のエントリに適用する
検索の引数として使用し、その資源のログ名を得ること
によって、その資源のログ名ログのエントリを識別す
る。これを図28に示す。 2.回復ファシリティは、この同期点ログのエントリ内で
見つかった資源識別子object_recoveryを使用して、資
源マネジャ63Aへの会話252(図26)を確立する。 3.回復ファシリティ70Aは、それ自体のログ名、資源識
別子log_name_log(回復ファシリティ70Aの一義的識別
子)、およびこの資源のログ名を、会話252を使って資源
マネジャ63Aに送る。

【０１６７】これに応答して、資源マネジャ63Aは以下
のステップを実行する。 1.資源マネジャ63Aは、回復ファシリティ70Aからの会話
が、資源識別子object_recoveryを含んでいるので、そ
の会話が同期点回復の目的を意図したものであることを
認識する。 2.資源マネジャ63Aは、回復ファシリティ70Aから送られ
た資源識別子log_name_logを使用して、ログ名ログ800A
2内の、回復ファシリティ70Aに関連するエントリを検査
する。 3.資源マネジャ63Aは、回復ファシリティ70Aから送られ
た資源のログ名が、それ自体のログ800Aのログ名と対応
することを確認する。 4.資源マネジャ63Aは、ログ名ログ800A2内で回復ファシ
リティ70Aに関連するエントリを見つけられない場合、
会話252上で回復ファシリティ70Aにエラー信号を戻す。 5.資源マネジャ63Aは、上記の検査ステップのいずれか
が失敗した場合、会話252上で回復ファシリティ70Aにエ
ラー信号を送る。

【０１６８】回復の始めにログ名交換でエラー状態が検
出されると、回復ファシリティ70Aの自動的同期点障害
回復手順の継続が阻止される。このようなエラー状態
は、1つまたは複数の参加するログの障害が、この同期
点障害と同時に発生したことを示す。あるログの喪失
は、そのログ内のすべての情報が失われ、新規のログ名
が割り当てられることを意味する。このような障害に
は、障害を発生している同期点を解決するため、手動の
介入およびヒューリスティックな判断が必要である。こ
のようなエラー状態を検出することが、同期点障害の後
に実施されるログ名交換処理の主目的である。

【０１６９】図26に示されたローカル資源マネジャ63A
の場合と同様に、図27には、システム50Dの資源マネジ
ャ63Eが、資源マネジャ63Eによって管理される資源を使
用するシステム50Aのアプリケーション環境52Aおよびア
プリケーション56Aに対してリモートである場合の、ロ
グ名交換が示されている。リモート資源マネジャ63Eと
ローカルなアプリケーション56Aおよび回復ファシリテ
ィ70Aの間の通信は、システム制御プログラムによって
提供されるシステム間通信サポートではなくて、システ
ム間通信ファシリティ57Aおよび57Dを介して行われる。
同期点マネジャ60Aは、回復ファシリティ70Aを使用し
て、同期点と、障害を発生している同期点からの回復に
必要なログ名ログ72Aとを管理する。資源マネジャ63E
は、それ自体の資源マネジャ・ログ800Eを維持する。同
期点以前の同意の時点と、障害を発生している同期点を
回復するための再同期化の時点で使用される通信経路
は、資源マネジャ63Eとシステム50Aの回復ファシリティ
70Aの間にある。システム50Dの回復ファシリティ70D(図
示せず)は、この場合には使用されない。というのは、
起点側の同期点マネジャ、アプリケーションおよび関連
する回復ファシリティが、システム50Dに対してローカ
ルではなく、リモートなシステム50A内にあるからであ
る。資源マネジャがローカルの場合とリモートの場合で
のログ名交換処理の唯一の相違点は、リモート資源マネ
ジャ63Eと資源アダプタ62Aまたは回復ファシリティ70A
の間での通信が、ローカル・システム制御プログラムの
システム間通信サービスではなく、通信ファシリティ57
Aまたは57Dを介して行われる点である。それ以外は、こ
のログ名交換の処理は、図26を参照しながら説明した上
記の処理と同一である。通信ファシリティ57Aおよび57D
は、リモート・ログとログ名を交換する時期の決定には
参加しない。すなわち、これらの通信ファシリティは、
図21の保護された会話の場合のような、会話の代行受信
は行わない。

【０１７０】 分散式アプリケーション用の未完了の同期点のための回
復ファシリティ 図2に示した回復ファシリティ70Aは、障害に出会った同
期点を完了させるのに使用する。ほとんどの場合、回復
(再同期化)は、回復ファシリティ70Aによって自動的に
実行される。回復ファシリティ70Aは、障害を認識した
後に、ローカル同期点マネジャ60Aの代理として働い
て、その同期点の参加者への代替のまたは再取得された
通信を用いて、その同期点を正常に完了させる。障害に
は、障害を発生している同期点マネジャ60A、同期点マ
ネジャ60Aとその回復ファシリティ70Aの間の通信の障
害、アプリケーション・パートナ56Dまたは資源マネジ
ャ63の障害またはそれらとの通信の障害、および回復フ
ァシリティ70Aの障害が含まれる。

【０１７１】たとえば、この体系的システム間通信標準
は、IBMコーポレーション刊行物の“System Network Ar
chitecture LU 6.2 Reference: Peer Protocols, SC31-
6808, Chapter 5.3 Presentation Services - Sync Poi
nt verbs”に記載のタイプのものとすることができる。

【０１７２】回復ファシリティ70Aは、システム50内
の、アプリケーション実行環境52A、52Bおよび52Cと、
参加する同期点アプリケーションにサービスし、同期点
回復のために、共通の回復ファシリティ・ログ72Aを使
用する。通常、複数のシステムが通信ファシリティ57を
介して互いに相互接続されており、したがって、複数の
回復ファシリティ70を回復処理に使用することができ
る。

【０１７３】図36は、システム50A、50Dおよび50Fに関
係する、様々な回復状況を示す図である。各アプリケー
ション実行環境52A、52B、52D、52F、52Gは、資源回復
を調整するためにそれぞれ同期点マネジャ60A、60B、60
D、60F、60G(図示せず)を使用するアプリケーション56
A、56B、56D、56F、56G(図示せず)を実行する。各同期
点マネジャは、そのシステム内の回復ファシリティを使
用して、同期点と、障害を発生している同期点からの回
復に必要なログ名ログとを管理する。たとえば、アプリ
ケーション環境52Aおよび52B内の同期点マネジャは、回
復ファシリティ70Aを使用して、同期点回復情報を回復
ファシリティ・ログ72Aに書き込む。資源マネジャ63A、
63B、63D、63E、63F、63Gは、それぞれ、それ自体の同
期点と、ログ名ログ800A、800B、800D、800E、800F、80
0Gとを管理する。この例では、同期点の範囲が矢印付き
の実線で示されている。同期点はいずれの参加者によっ
て開始されることもでき、同期点の範囲は動的である
が、図を簡単にするためにこの図は静的なものである。
図の静的な場合では、同期点は、アプリケーション環境
52Bから52Dへさらに52Fへと、関連する同期点マネジャ
および保護会話アダプタ(図示せず)を介し、実線の通信
経路801および802を経て流れ、またアプリケーション環
境52A、52B、52D、52F、52Gから、関連する同期点マネ
ジャおよび保護会話アダプタを介し、それぞれ実線の通
信経路803A−1、803A−2、803B、803D、803E、803F、80
3Gを経て、資源マネジャ63A、63B、63D、63E、63F、63G
へと流れる。

【０１７４】3つの同期点の範囲が、図36に含まれてい
る。第1の範囲には、同期点マネジャ60Aを含む単一のア
プリケーション環境52Aが含まれ、2つの資源マネジャ63
Aおよび63Eを使用する。第2の同期点の範囲には、3つの
アプリケーション環境52B、52Dおよび52Fが含まれ、こ
れらはそれぞれ、様々な参加資源マネジャ(52Bには63
B、52Dには63Dと63E、52Fには63Fと63G)を含む。これを
図37の同期点ツリーに示す。第3の同期点の範囲には、
アプリケーション環境52Gと資源マネジャ63Gが含まれ
る。

【０１７５】図36中の破線は、同期点以前の同意の時点
と、障害を発生している同期点の回復のための再同期化
の時点で使用される通信経路を示す(前記の「保護され
た資源を回復するためのログ名の交換」を参照された
い)。資源マネジャでは、同期点以前の同意および再同
期化の経路は、その資源マネジャと、起点側アプリケー
ション環境(すなわち、その資源マネジャが管理する資
源を使用、たとえば更新する側)のシステムの回復ファ
シリティの間にあり、たとえば、アプリケーション環境
52Aが起点側である(資源マネジャ63Eの管理する資源を
使用する)時は、経路804A−2を介して資源マネジャ63E
と回復ファシリティ70Aの間にあり、アプリケーション
環境52Dが起点側である時は、経路804Dを介して資源マ
ネジャ63Eと回復ファシリティ70Dの間にある。

【０１７６】同期点は、その同期点の参加者中をカスケ
ード式に伝播して、図37に示された同期点ツリーを形成
する。アプリケーション56B、56Dおよび56Fは、それぞ
れ保護会話アダプタ64B、64Dおよび64F(図示せず)によ
って管理される保護された会話801および802を介して、
互いに通信する。アプリケーション56B、56Dおよび56F
は、それぞれ資源アダプタ62B、62D、62F(図示せず)を
使用し、これらの資源アダプタは、それぞれ保護されな
い会話803B、803D、803E、803G、803Fを使用して、資源
マネジャ63B、63D、63E、63G、63Fと通信する。このツ
リーには、同期点開始側のアプリケーション56Bとそれ
に参加する資源マネジャ63Bおよび分散アプリケーショ
ン56D、分散アプリケーション56Dに参加する資源マネジ
ャ63E、63Dおよび分散アプリケーション56F、分散アプ
リケーション56Fに参加する資源マネジャ63Gおよび63F
が含まれる。

【０１７７】同期点回復のために、1つの同期点ログ、
たとえば72Dが、同期点マネジャ60Dによって(図示され
ない回復ファシリティ70Dを介して)、同期点ツリー内で
その直前にある環境52B内のアプリケーション56Bと、直
接参加者であることが同期点マネジャ60Dにわかってい
る、資源マネジャ63E、63Dおよびアプリケーション環境
52F内のアプリケーション56Fとに関する情報と共に維持
されるが、その他の同期点参加者63B、63Gまたは63Fに
関しては、同期点ログ72D内に何も維持されない。

【０１７８】図38は、同期点回復の主要要素の高水準流
れ図298である。この図は、回復ファシリティ70の2つの
部分、同期点以前の回復同意(ステップ299、300、301お
よび302)と同期点障害からの回復(ステップ303ないし30
6)を表している。

【０１７９】同期点が発生する前に、その同期点の参加
者の間で、その同期点に関連するログの一致と、それら
のそれぞれのログ72の現在のレベルとに関する同意がな
ければならない(前述の「保護された資源を回復するた
めのログ名の交換」を参照されたい)。この同期点以前
の回復同意は、同期点障害の場合にその同期点障害から
回復するのに使用されるログが、その同期点が開始され
る前と同一のものであり、同一のレベルであることを保
証するのに重要である。同期点以前の回復同意の時点
(上述のログ名の交換)から同期点障害の発生までの間
に、1つまたは複数の参加者のログに障害があって、新
規のログを用いて開始しなければならない場合には、こ
の障害を発生したログに関連する自動的回復手順は失敗
する。

【０１８０】同期点の参加者の間でログ名を交換し、ロ
グ名をログ72に記録すると、同期点障害の場合に、この
情報を妥当性検査に使用できるようになる。これらの交
換は、特定の経路上で通信が初めて確立されるのを検出
した時に開始される。通信はローカルにもリモートにも
開始され得るので、回復ファシリティ70は、出ログ名交
換が必要なローカル検出(ステップ299および300)と、入
りログ名交換が必要なリモート検出(ステップ301および
302)の両方をサポートする。

【０１８１】回復ファシリティ70は、同期点障害からの
自動的回復を実現し、これには、回復手順を開始させる
様々な事象が発生するステップ303、回復手順の初期設
定ステップ304、回復ドライバ処理と称する実際の回復
ステップ305、および回復手順終了ステップ306が含まれ
る。回復ファシリティ70は、複数の同期点障害事象の非
同期的処理を含む。

【０１８２】図39は、この回復手順の「同期点障害から
の回復」の部分(ステップ303ないし306)をより詳細に示
す図である。下記の5種類の事象(ステップ303)が、この
回復手順を開始させる。 (1)同期点マネジャ60が、その1つまたは複数の同期点参
加者(たとえば、資源マネジャ63)との通信障害に出会っ
た時に同期点マネジャから要求を受け取った結果として
発生する、同期点要求事象311。この同期点マネジャ60
は、この同期点の活動をロギングするのに使用するのと
同一の経路を使って回復ファシリティ70に要求を送るこ
とによって、明示的に回復手順を開始する。この要求
は、対応する同期点識別子を使った、障害を発生してい
る参加者の記述を含む。指定された各同期点識別子ごと
に1つの事象が発生する。 (2)同期点開始側を表す回復処理が、その参加者の1つに
回復要求を送る時に、ターゲット回復ファシリティ70
(障害を発生している同期点の参加者を表す回復ファシ
リティ)で発生する、回復要求事象312。 (3)アプリケーション環境から回復ファシリティ70にロ
グ情報を送るのに使用される経路上の接続が断たれた時
に、その回復ファシリティ70内で発生する、通信障害事
象313。障害を発生した経路を使用していたアプリケー
ション環境に関して進行中の各同期点ごとに1つの事象
が発生する。 (4)回復ファシリティの終了に障害があり、その結果、
同期点のロギングを行えない時に発生する、回復ファシ
リティ障害事象314。障害の時点で完了していない各同
期点ごとに1つの事象が発生し、これらの事象は、回復
ファシリティが再始動される時に発生する。 (5)正常な自動的回復手順中に長い遅延または重大な障
害に出会った同期点障害を修復するのに用いられる管理
コマンドの結果として生じる、回復管理要求事象315。
この要求は、通常なら自動的回復プロトコルを介して入
手可能な応答状態情報を、手動で供給する。適当な応答
状態情報は、同期点のログ・レコードを手動で調べてオ
フラインで決定する。適当な応答データ(状態情報)は、
システム管理者が、同期点のログ・レコードを手動で調
べて決定する。

【０１８３】この回復手順が開始される際、ステップ30
4で、受け取った各回復事象に対する非同期的サブプロ
セスが開始される。参加ドライバ・サブプロセス(ステ
ップ317)が、一貫した解決策に関する同意を得るため
に、通信を開始し、障害を発生している同期点の下流側
の各参加者からの応答を受け入れる。この通信では、参
加ドライバを用いて、回復サーバのログ名と、commitや
back outなどの同期点状態とを含むメッセージを送り、
その後、送られた回復サーバのログ名に対する同意また
は不同意の指示、参加者のログ名、およびcommittedやb
acked outなどの同期点状態に対する応答を含む、参加
者からの応答を受け取る。参加ドライバは、このように
して受け取った各応答メッセージに対して、応答処理ド
ライバを呼び出す(ステップ318)。応答処理ドライバ
は、この応答を分析し、必要なすべての行動と記録を完
了する。これには、その参加者のログ名をログ72内に記
録されたその参加者のログ名と突き合わせて、その参加
者がこの同期点の開始以来ログ障害に出会っていないこ
とを検査することが必要である。さらに、この同期点応
答を回復ファシリティ・ログ72に記入することも必要で
ある。その後、応答処理ドライバは、参加ドライバにリ
ターンする。すべての応答を受け取って処理した後に、
開始側応答ドライバ(ステップ319)が呼び出されて、応
答を作成してこの同期点の開始側を代理する回復ファシ
リティにそれを送り、当該の場合には、この回復ファシ
リティがこの同期点をその同期点の開始側と共に解決で
きるようにする。開始側への応答は、現回復ファシリテ
ィがその参加者から受け取った応答に類似しており、現
回復ファシリティのログ名と、それ自体のすべての同期
点参加者からの結果に基づくcommittedやbacked outな
どの応答同期点状態を含む。最後に、回復終了サブプロ
セス(ステップ306)が、関係するすべての処理を終了す
る。

【０１８４】図40は、この回復手順に必要な制御構造を
示す図である。回復制御構造340は、特定の回復事象に
関する情報を保持し、その事象の現処理の間ずっと存在
する。制御構造340は、関連する同期点に対するすべて
の参加者の回復に共通する情報を保持する。また、ログ
72内の関連するエントリ342へのアンカと、参加者制御
構造344のチェーンへのアンカを保持し、各参加者制御
構造344は、現在の回復状況とこの回復参加者の経路識
別子を保持する。同期点ログのエントリ342は、ローカ
ルの同期点参加者に共通するヘッダ情報348、ならびに
直接開始側と各直接参加者とに関する本体情報350を有
する。最後に、この同期点ログに関連する回復ファシリ
ティに既知の、各同期点経路に関する初期ログ名交換情
報を保持する、ログ名ログ・エントリ354がある。

【０１８５】これらのフィールドの目的を、以下の構造
流れによってさらに示す。一部のフィールドは、あらか
じめ説明が必要である。"Chain"(チェーン)フィールド
は、同じタイプの構造を相互接続するのに使用される。

【０１８６】“State”(状態)フィールド SPL_SYNCPOINT_STATEは、同期点の全体的な状態であ
る。同期点が段階2に達すると、この状態によって、下
流側の参加者を駆動してその同期点を解決することが可
能になる。同期点が、障害を発生した時点で段階1であ
った場合には、回復要求事象の処理で、開始側回復ファ
シリティの指示に従って、この状態を変更することがで
きる。SPL_PARTICIPANT_STATEは、応答処理ドライバ318
によって、参加者からの応答状態を用いて更新される。
RCS_PARTICIPANTS_STATEは、影響を受ける下流側の同期
点参加者を駆動する目的で、様々な回復事象処理によっ
てセットされる。RCS_INITIATOR_RESPONSE_STATEは、様
々な回復事象処理311ないし315によってRCS_PARTICIPAN
TS_STATEと共に初期設定されるが、ある状況の下では、
すなわち、開始側への応答が、ヒューリスティック応答
として知られる単方向性の決定から生じた、参加者から
の異常かつ予期されない応答を反映するためのものであ
る場合には、応答処理ドライバ318によっても更新され
る。このフィールドは、開始側に戻される状態を形成す
るために開始側応答ドライバ319が使用する。 “Path ID”(経路識別子)フィールド RCS_PATH_IDは、入り事象に関連する経路であり、その
事象の起点側に応答するのに使用できる。PCS_PATH_ID
は、障害を発生した同期点の参加者に関連する経路であ
る。これは、参加者にとってSPL_RECOVERY_PATH_IDと同
一である。SPL_RECOVERY_PATH_IDは、同期点回復ファシ
リティに必要な、参加者または開始側に達する経路であ
る。SPL_SYNCPOINT_PATH_IDは、同期点ログ情報を、ロ
ーカル回復ファシリティの同期点ログに供給するため
に、アプリケーション実行環境内の同期点処理が使用す
る経路である。 “Flag”(フラグ) RCS_RESPOND_TO_INITIATORは、同期点回復ファシリティ
の直接開始側に対して、応答を生成すべきであることを
示す。RCS_RETURN_TO_CALLERは、待機標識(以下で説明
する)を使用する時、同期点回復要求からの同期リター
ンを制御するために使用する。RCS_ERASE_LOGは、回復
管理要求がPURGE(パージ)オプションを含んでおり、処
理の完了時に同期点ログのエントリを消去させることを
記録するために使用する。SPL_INITIATORは、同期点ロ
グのエントリの本体の特定のサブエントリ内の情報が、
この同期点の開始側または参加者に関するものであるこ
とを示す。 “Miscellaneous”(雑)フィールド RCS_FUNCTION_IDは、新しいプロセス内で実行するため
に呼び出すべき機能を決定するために、サブプロセス開
始サービスが使用する。SPL_SYNCPOINT_IDは、同期点の
一義的な識別子であり、同期点ツリー内のノードであ
る。同期点ログの各エントリは、独自の同期点識別子を
有する。SPL_SUSPENDED_PROCESS_IDは、中断された処理
を識別するためにタイマ待機サービスがセットするもの
で、この時限待機間隔が終了した時にリセットされる。
これは、特定のプロセスに対する時限待機を早めに終了
させるために、再開サービスを呼び出すのに使用され
る。PCS_STATUSは、回復手順の各参加者との会話の状況
を記録するのに使用される。これがとり得る値は4つあ
り、RESTART(再始動)、CONNECTED(接続済み)、RETRY(再
試行)およびRESPONDED(応答済み)である。LL_LOGNAME
は、同期点参加者のログ名である。潜在的な同期点通信
に関係する各経路ごとに1つずつ記録される。

【０１８７】図41は、ステップ299で事象(図38の同じス
テップに対応する)によってトリガされ、回復ファシリ
ティ70の活動化中に同期点通信が初めて開始される時に
回復ファシリティ70によって実行される、処理ステップ
300を示す流れ図である。この処理では、ローカル回復
ファシリティと、同期点通信のターゲットに関連する回
復ファシリティの間でログ名を交換するための処理を開
始する(ステップ359)。

【０１８８】受取サービスが、この処理のための入力デ
ータ(経路識別子)を提供する(ステップ361)。ログ名ロ
グは、ログ名の交換に使用される経路に関連するログ名
を検索するのに使用される(ステップ362)。このログ名
交換の際には、予期されるターゲット・ログ名が、ロー
カル回復ファシリティのログ名と共に送られる。このロ
グ名交換の要求が送られ(ステップ363ないし365)、その
応答が処理される(ステップ366)。この交換に成功する
と、ログ名ログは、新規のまたは変更されたターゲット
・ログ名で更新される。次に回復ファシリティは、この
経路から切断され(ステップ367)、最初の通信サービス
を呼び出して、この交換が成功であったことを記録し、
この処理された経路に対する将来の交換事象を抑止し、
あるいは交換が不成功であったことを記録して、通信の
中断の継続を保証し、ログ名交換の完了を試みる(ステ
ップ368)。

【０１８９】図42は、ステップ301(図38の同じステップ
に対応する)で事象によってトリガされ、入りログ名交
換要求の到着の結果として起こる、ステップ302の詳細
を示す流れ図である。開始(ステップ370)の後に、ログ
名と経路識別子を受け取り(ステップ371)、それに応じ
てログ名ログが更新される(ステップ371ないし373)。そ
の経路に関連する中断(タイマ待機)中の回復処理が存在
する場合(ステップ374)、回復ファシリティ70は、再開
サービスを呼び出して、各回復処理にその処理を再開さ
せる。ログ名交換応答(ステップ374A)は、ローカルのロ
グ名と、受け取った交換データに対する同意または不同
意の指示を含む。この応答は起点側に送られ(ステップ3
75)、交換に成功した場合には、最初の通信サービスを
呼び出して(ステップ376)、これ以降のその経路でのロ
グ名交換を抑止する。

【０１９０】図43は、同期点回復の実行を求める、活動
状態の同期点からの明示的要求事象(図39のステップ311
に対応するステップ311)に対する手順を示す流れ図であ
る。これは、アプリケーション環境52内で部分的な障害
が発生して、同期点からの回復が必要となるが、そのア
プリケーションまたは同期点は終了させる必要のない場
合に発生する。アプリケーション環境52内の同期点マネ
ジャからの要求は、この同期点識別子と、障害を発生し
ている同期点を完了するのに使用される指示(コミット
またはバックアウト)を提供する。これに加えて、障害
を発生した各同期点参加者について、回復経路識別子が
与えられる。必要な処置は、以下で詳細に説明するよう
に、同期的(待機標識が与えられる)または非同期的(待
機標識が与えられない)に完了することができる。

【０１９１】この要求の到着は、同期点ログを探索し
て、一致するSPL_SYNCPOINT_IDをもつエントリを探す
(ステップ381)ことを必要とする、手順(ステップ380)を
開始する事象(ステップ379)である。それが見つかる
と、その同期点ログのエントリへのアンカを備える回復
制御構造が作成され、この要求中で渡された指令に合わ
せてRCS_PARTICIPANTS_STATEが設定される(ステップ38
2)。これに加えて、フラグRCS_RESPOND_TO_INITIATORを
セットすると、この同期点の開始側を代理する回復ファ
シリティに応答を送ることが抑止され、待機標識が渡さ
れている場合には、フラグRCS_RETURN_TO_CALLERがセッ
トされ、回復処理が完了するまでこの要求に対する応答
を遅らせる。待機標識がない場合は、回復処理が開始し
た後に、開始側要求への応答がある。次に、与えられた
経路識別子で表される各参加者ごとに代理制御構造が作
成され(ステップ383)、PCS_STATUSがRESTARTに初期設定
される。代理制御構造のチェーンは、回復制御構造にア
ンカされる。次に、回復初期設定を呼び出して(ステッ
プ384)、回復制御構造を渡す。この初期設定から戻る
時、呼出し側への応答がある(ステップ385)。待機標識
が使用されていた時は、呼出し側は完了を知らされる。
そうでない場合は、この通知は、完了、または要求の処
理が開始された(後で完了する)との指示のいずれかであ
る。

【０１９２】図44は、障害を発生している同期点の直接
開始側を代理する回復ファシリティから回復要求を受け
取ったことによって開始された事象(ステップ312)から
生じる手順を示す流れ図である。これは、手順(ステッ
プ390)を開始して(ステップ388)、受取サービスを呼び
出し(ステップ391)、入り要求に関連する経路識別子、
障害を発生している同期点の同期点識別子(その同期点
内のローカル・ノードも識別する)、起点側の同期点ロ
グに関連するログ名、開始側の回復ファシリティが現回
復ファシリティの同期点ログの名前と一致すると予想し
ているログ名、およびこの障害を解決するのに使用され
る指示(状態)を得る。

【０１９３】経路識別子は、ローカルのログ名ログ内の
エントリを見つけるのに使用される(ステップ392)。次
に、起点側のログ名を用いてLL_LOGNAMEを検査し、渡さ
れた予期されるログ名を用いてローカルの同期点ログの
名前を検査する(ステップ393)。次に、同期点ログを探
索して、同期点識別子が一致するエントリを探す(ステ
ップ394)。それが見つかると、その同期点ログのエント
リへのアンカを備えた回復制御構造が作成され、この要
求中で渡された指示に合わせてRCS_PARTICIPANT_STATE
が設定される(ステップ395)。さらに、開始側への応答
が適当であることを示すフラグRCS_RESPOND_TO_INITIAT
ORをセットし、RCS_PATH_IDを開始側の入り経路の経路
識別子に設定する。アプリケーション環境52内の呼出し
側同期点マネジャ60へのリターンを抑止するため、フラ
グRCS_RETURN_TO_CALLERをセットする。最後に、回復初
期設定を呼び出して(ステップ396)、回復制御構造を渡
す。

【０１９４】図45は、アプリケーション環境52と回復フ
ァシリティ70の間の経路に障害があって、同期点のロギ
ングが動作不能になる(ステップ313)時に行われる処理
(ステップ400)を示す流れ図である。処理が開始された
(ステップ399)後、同期点ログを探索して、下記の両方
の条件を満足するエントリを探す(ステップ401)。 (1)SPL_SYNCPOINT_PATH_IDが障害を発生している経路と
一致する。 (2)SPL_SYNCPOINT_STATEが、この同期点を完了するため
に、同期点の直接参加者を駆動できることを示す。これ
は、以下のいずれかによって示される。SPL_SYNCPOINT_
STATEが同期点段階1を示し、開始側の“prepare”に対
する応答がなかった場合、あるいはSPL_SYNCPOINT_STAT
Eが同期点段階2を示す場合。

【０１９５】これらの条件が満たされる場合、その同期
点ログのエントリへのアンカを備えた回復制御構造が
(そのような各ログ・エントリごとに)作成される(ステ
ップ402)。その際に、TOR_RESPONSE_STATEとRCS_PARTIC
IPANTS_STATEは、共にSPL_SYNCPOINT_STATEから導かれ
る。SPL_PARTICIPANT_STATEが、RCS_INITIATOR_RESPONS
E_STATEの設定にも影響する場合がある。これは、たと
えば参加者からの応答が、単方向の(ヒューリスティッ
クな)行動を示していた時に起こる。さらに、フラグRCS
_RESPOND_TO_INITIATORをセットすると、この同期点の
開始側を代理する回復ファシリティに応答を送ることが
抑止され、フラグRCS_RETURN_TO_CALLERをセットする
と、戻るべき呼出し側の同期点マネジャが存在しないこ
とを示す。この結果得られる回復制御構造が、相互に連
鎖される。最後に、回復初期設定を呼び出して(ステッ
プ403)、回復制御構造のチェーンを渡す。

【０１９６】図46は、回復ファシリティ72の障害が発生
した(ステップ314)場合に行われる処理(ステップ408)を
示す流れ図である。回復ファシリティ70が再始動される
(ステップ407)時、ログ72を検索して(ステップ411)、下
記の条件を満足するすべてのエントリを探す。SPL_SYNC
POINT_STATEが、この同期点を完了するために、同期点
の直接参加者を駆動できることを示していること。これ
は、以下のいずれかによって示される。SPL_SYNCPOINT_
STATEが同期点段階1を示し、開始側の“prepare”に対
する応答がなかった場合、あるいはSPL_SYNCPOINT_STAT
Eが同期点段階2を示す場合。

【０１９７】この条件が満たされる場合、そのような各
ログ・エントリごとにその同期点ログへのアンカを備え
た回復制御構造が作成される(ステップ412)。その際
に、RCS_INITIATOR_RESPONSE_STATEとRCS_PARTICIPANTS
_STATEは、共にSPL_SYNCPOINT_STATEから導かれる。場
合によっては、SPL_PARTICIPANT_STATEが、RCS_INITIAT
OR_RESPONSE_STATEの設定にも影響を与える。これは、
参加者からの応答が、たとえば単方向の(ヒューリステ
ィックな)行動を示していた時に起こる。さらに、フラ
グRCS_RESPOND_TO_INITIATORをセットすると、この同期
点の開始側を代理する回復ファシリティに応答を送るこ
とが抑止でき、フラグRCS_RETURN_TO_CALLERをセットす
ると、戻るべき呼出し側の同期点マネジャが存在しない
ことを示す。この結果得られる回復制御構造が、相互に
連鎖される。最後に、回復初期設定を呼び出して(ステ
ップ403)、回復制御構造のチェーンを渡す。

【０１９８】図47は、回復管理要求(ステップ315)のサ
ポート(ステップ409)を示す図である。このサポート
は、下流側での解決のための同期点参加者との会話(参
加者の場合)、または、同期点完了のためにその参加者
を駆動する指示(状態)を与えるための同期点開始側との
会話(開始側の場合)を開始できなかったために動かなく
なった自動的同期点回復の修復を、手動で開始できるよ
うにするものである。

【０１９９】参加者の場合、この要求が参加者の応答の
代りをつとめ、その結果、下流側の参加者を駆動してい
る回復ファシリティ70は、実際にその参加者と通信する
ことなく回復を完了できるようになる。開始側の場合、
この要求は、開始側がローカルの回復ファシリティ70と
接続できないために発生し得ない、通常の回復処理によ
って開始される回復要求事象(図44参照)の代りをつとめ
る。後者の場合、この応答によって、ローカルの回復フ
ァシリティは、図44に示された事象なしに、その参加者
を駆動できるようになる。

【０２００】開始側の場合、このサポートが開始された
(ステップ408)後に、回復制御構造を作成し(ステップ41
4)、渡された指示に合わせてRCS_INITIATOR_RESPONSE_S
TATEとRCS_PARTICIPANTS_STATEを設定して、回復処理が
開始した回復要求と等価な要求を形成する。さらに、RC
S_RESPOND_TO_INITIATORをオフにセットして、応答の生
成を抑止し、RCS_RETURN_TO_CALLERをオフにセットし
て、処理の完了時に回復初期設定から戻るのを抑止す
る。回復初期設定を呼び出して(ステップ415)、処理を
開始させる。

【０２０１】参加者の場合、回復制御構造と中断された
回復処理がすでに存在していなければならない。この処
理は、タイマ待機中は中断され、各時間間隔の終わり
に、参加者との会話の初期設定が再試行される。これを
検査した後に(ステップ416)、渡された回復経路識別子
に関連する参加者の参加者制御構造を見つけ、この参加
者が実際に応答した場合と同様にPCS_STATUSをRESPONDE
Dに設定し(ステップ417)、渡された指示に合わせてSPL_
PARTICIPANT_STATEを設定する。その後、同期点ログの
エントリを更新する。次に、SPL_SUSPENDED_PROCESS_ID
を用いて再開サービスを呼び出し、中断されたプロセス
を再始動する(ステップ418)。いずれの場合にも、起点
側要求に対して、適当な置換が行われ、回復処理が再び
活動状態になっていることを示す応答が行われる(ステ
ップ419)。purgeオプションが渡された場合は、RCS_ERA
SE_LOGがオンになり、プロセスの終了時に同期点ログの
エントリが消去される。

【０２０２】図48は、回復初期設定機能(ステップ304)
に必要なステップを示す流れ図である。初期設定(ステ
ップ303)の後に、フラグRCS_RETURN_TO_CALLERに従っ
て、参加ドライバが現在のプロセス内で呼び出されたか
(オン)、それとも別の並行プロセス内で呼び出されたか
(オフ)を判定する(ステップ421)。RCS_RETURN_TO_CALLE
Rがセットされている場合、参加ドライバを呼び出して
(ステップ422)、回復制御構造を渡す。そうでない場合
は、「参加ドライバ」を示すようにRCS_FUNCTION_IDを
設定して、渡された各回復制御構造ごとに、サブプロセ
ス開始サービスを呼び出す(ステップ423)。

【０２０３】図49および図50は、参加ドライバのステッ
プ317の流れを示す流れ図である。参加ドライバの主な
機能は、関連する同期点ログが、その同期点の開始時と
同一レベルであることを保証し、その同期点を解決する
ための基礎となる同期点状態情報を提供するために、障
害を発生している同期点の参加者との通信を開始し、そ
れらの参加者から応答を得ることである。

【０２０４】参加ドライバの初期設定(ステップ430)の
後に、現在のRCS_PARTICIPANTS_STATEに従って、SPL_SY
NCPOINT_STATEを設定する(ステップ431)。この同期点の
参加者に対する参加者制御構造が、まだ作成されていな
い場合は、この時点でそれらの制御構造を作成し、互い
に連鎖し、現回復制御構造にアンカする。PCS_PATH_ID
は、各参加者のSPL_RECOVERY_PATH_IDから得られる。SP
L_PARTICIPANT_STATEがPCS_STATUSがRESPONDEDに設定さ
れて、その特定の参加者に対する同期点が解決されてい
ると示さない限り、PCS_STATUSはRESTARTに初期設定さ
れる。

【０２０５】ステップ432〜444の流れは、各参加者に対
するPCS_STATUSの値によって制御される。とり得る値は
以下の通りである。 (1)RESTART この参加者との会話が必要であることを
示す。 (2)CONNECTED この参加者との会話の初期設定に成功し
たことを示し、この参加者へ回復要求メッセージを送ら
せる。 (3)RESPONDED この参加者への回復要求メッセージの送
出が完了し、この参加者からの応答を得たことを示す。
応答処理ドライバを呼び出して(ステップ438ないし43
9)、この応答を処理する。 (4)RETRY 接続(すなわち、会話の確立)(ステップ4
36ないし437)またはメッセージの送出(ステップ440ない
し441)の試みに失敗したこと、あるいはログ名が一致し
なかったこと(ステップ440ないし441)を示す。参加者に
関するすべてのフラグPCS_STATUSが状況RESTARTおよびC
ONNECTEDよりも先に進んでいるが、通信障害に出会った
ものがある(他のものはRESPONDED)状態になった後に、
現同期点の参加ドライバは、時限間隔の間、実行を中断
する。この中断が完了した時、RETRYであったPCS_STATU
Sは、すべてRESTARTに変更され、再接続が試みられる。

【０２０６】多重事象待機サービス(ステップ433)は、
未処理の接続または送出のサービス要求のうちの最初の
ものが完了するのを待って、制御をその経路識別子およ
び成否の指示と共に参加ドライバに戻すのに使用する。
参加者に送られた回復要求(ステップ434ないし435)に
は、送出側の回復ファシリティ70のログ名と、参加者に
関連する予期されるログ名が含まれる。参加者の実際の
状態と比較して、適当な回復行動を定義できるようにす
るために、RCS_PARTICIPANTS_STATEが送られる。時限待
機サービス(ステップ442〜443)は、不成功であった会話
の開始を再試行する前に、システムで定義された時間間
隔の間プロセスを遅延させるのに使用する。この意図的
な遅延は、すべての参加経路を駆動し終えて、何らかの
障害に出会った後だけ試みられる。時限待機完了(ステ
ップ444)は、中断されたプロセスを再始動させて、参加
者との接続をもう1度試みさせる働きをする。すべての
参加者が状況RESPONDEDに達し、応答処理ドライバによ
る処理を完了した後、開始側応答ドライバを呼び出して
(ステップ445)、同期点開始側を代理する回復処理への
可能な応答を処理する。

【０２０７】図51は、障害を発生した同期点の参加者に
送られた回復要求に対する応答を処理するのに必要な処
理を示す示す流れ図である。応答処理ドライバ(ステッ
プ318)は、同期点識別子、経路識別子および参加者から
受け取った状態を渡される(ステップ450)。次に、ログ
名交換の応答が処理される(ステップ451)。ログ名が一
致しない場合、流れは参加ドライバに戻って(図39のス
テップ317)、時限待機の再試行を起こさせるエラーを戻
す。

【０２０８】同期点識別子は、同期点ログのエントリを
見つけるのに使用される。その後、経路識別子を使用し
て、その同期点ログのエントリの本体内で、SPL_RECOVE
RY_PATH_IDに一致する参加者を見つける。次に、前記の
状態を用いて、SPL_PARTICIPANT_STATEを更新する(ステ
ップ452)。

【０２０９】RCS_INITIATOR_RESPONSE_STATEは、たとえ
ば、単方向の(ヒューリスティックな)決定を反映するな
ど、参加者からの予期せぬ応答の結果として更新される
場合がある(ステップ453)。最後に、切断サービスを呼
び出して、現経路の接続を断つ(ステップ454)。

【０２１０】図52および図53は、開始側応答ドライバ
(ステップ319)を示す流れ図である。まず、開始側応答
ドライバが開始される(ステップ460)。RCS_RESPONSE_TO
_INITIATORがセットされていない場合(判断ブロック46
1)、応答する必要はない。したがって、同期点ログのエ
ントリを消去するだけでよい(ステップ468)。応答すべ
き開始側がない時(ステップ462)、すなわち、回復ファ
シリティが同期点ツリーの最初のノードを表している時
も、応答は行わない。

【０２１１】回復処理が開始し、中断されている、開始
側への応答の処理を求め、回復要求(図44に図示の事象)
がなく、その開始側に応答すべき既存の会話が存在しな
い(判断ステップ479)時は、現回復ファシリティ70が代
理する参加者が応答の準備ができていることを、その開
始側を代理する回復ファシリティに通知するために、そ
の回復ファシリティとの上流向きの通信を試みるのが適
当である(ステップ464)。これは、ローカル回復ファシ
リティ70との通信の試みに以前に失敗したために時限中
断の状態になっているその開始側の回復ファシリティが
ある時、すなわち、現在完了している回復がローカル回
復ファシリティ70の障害の結果生じた同期点障害から生
じたものである(図46に図示の事象)時に、最も効果的で
ある。この上流向けの通信は、時限中断を早めに打ち切
り、したがって、同期点の解決の遅延を最小にするとい
う効果があるはずである。図42のステップ374が、(開始
側を代理する)受信側回復ファシリティの行動を示して
いる。

【０２１２】SPL_SUSPENDED_PROCESS_IDが定義されてお
らず、RCS_PATH_IDが設定されていない場合(判断ブロッ
ク479)、回復中の同期点の同期点ログ・エントリの本体
中から開始側のエントリを見つけ、それに関連するSPL_
RECOVERY_PATH_IDを使って、SPL_RECOVERY_PATH_IDに対
する接続サービスを呼び出すことによって、上流向けの
通信が達成される。この会話を初期設定する試みに失敗
した時は、再試行は行われない(ステップ464Aの判断経
路“no”)。それは、この会話を完了し開始側に通知す
るための任意選択の最適化手段だからである。この会話
が開始される場合(ステップ464Aの判断経路“yes”)、
図41のステップ364〜367に従って、通常のログ名交換要
求が送られ(ステップ464B)、その後、判断ステップ477
を経て脱出する。接続が完了していない場合は、回復終
了を呼び出す(ステップ469)。

【０２１３】RCS_PATH_IDが設定されていない(判断ブロ
ック465)時は、開始側への応答(ステップ466および467)
は行われない。そうでない場合は、RCS_INITIATOR_RESP
ONSE_STATE(ステップ466)と応答サービス(ステップ467)
を使用して、開始側への正常な応答が行われる。RCS_RE
SPOND_TO_INITIATORまたはRCS_ERASE_LOGがオンである
場合(判断ブロック477)、完了の前に、回復終了機能が
呼び出される(ステップ468)。

【０２１４】図54は、回復終了論理(ステップ306)を示
す流れ図である。この論理は、ステップ470で開始した
後、記憶域と制御構造をきれいにして(ステップ471)、
呼出し側に戻る(終了)か、またはサブプロセス終了サー
ビスを呼び出して、現プロセスを完了する(ステップ47
2)。

【０２１５】 コミット手順の非同期的再同期化 システム50内での同期点処理中に障害が発生した時、参
加するアプリケーションの使用を最適化するために、下
記の非同期式再同期化の手順およびファシリティが提供
される。この手順に従えば、コミットを発行したアプリ
ケーションが、再同期化中に遊休状態で待機する必要が
なくなるので、そのアプリケーションの実行の際の長い
遅延が回避される。そのアプリケーションは、その代わ
りに、以下で詳細に説明するように、再同期化を待つ間
に他の有用な作業を行うことができる。同期点マネジャ
と回復ファシリティは、デフォルトのアプリケーション
またはシステムがそれを要求する場合、この手順を実行
する。回復ファシリティ70は、非同期的再同期化(進行
中の再同期化)をサポートし、この非同期的再同期化処
理をサポートする体系的システム間通信の流れの新規の
拡張版をサポートする。たとえば、システム間通信プロ
トコルは、“System Network Architecture LU6.2 Refe
rence: Peer Protocols, SC31-6808, Chapter 5.3 Pres
entation Services - Sync Point verbs”によって定義
されている。システム50内の体系的システム間通信の拡
張版には、Committed(最後の代理のみ)、Forget、Backo
utなどの流れに関して再同期化が進行中であることを示
す追加の指示が含まれている。2つの異なるシステムの
回復ファシリティの間での初期交換中または再同期化中
の交換ログ名のために定義されたデータ・フィールド中
に、この交換ログ名の送出側が進行中の再同期化をサポ
ートすることを示す標識がある。交換ログ名の処理は、
上記の「保護された資源を回復するためのログ名の交
換」に記述されている。このファシリティを使用するた
めには、両方の回復ファシリティが進行中の再同期化を
サポートしなければならない。最後に、状態比較データ
・フィールド中に、再同期化が進行中であることをパー
トナに伝える標識がある。

【０２１６】前述の「保護された資源の調整式同期点管
理」および図2、図60、図3、図4および図5では、2つの
パートナ・アプリケーション56Aおよび56D、それらのア
プリケーション環境、それらの処理および成功したコミ
ット処理について記述し図示した。本節では、非同期的
再同期化をもたらすコミット処理中の障害の説明を含む
ように上記の内容を拡張する。本明細書に記載の非同期
的再同期化処理は、保護された会話が同一のシステム上
にあるアプリケーション・パートナ間で行われ、両方の
アプリケーションが、たとえば仮想計算機オペレーティ
ング・システムの拡張バージョンの異なる仮想計算機な
ど、異なるアプリケーション環境内にある時にも適用可
能であることを理解されたい。また、他の実施例では、
アプリケーション56Aまたはアプリケーション56Dが、異
なるタイプの実行環境内で実行できることにも留意され
たい。

【０２１７】「保護された資源の調整式同期点管理」で
述べたように、アプリケーション56Aは、保護された会
話を介してアプリケーション56Dを開始する(図5のステ
ップ530)。保護会話アダプタ64Aおよび64Dが、当該の同
期点マネジャに登録される(図5のステップ532)。図55
は、アプリケーション56Aが次に行う処理(図5のステッ
プ533)を拡張したものである。図55に示されるように、
アプリケーション56Aは、同期点マネジャ60Aに対して、
“set syncpoint options wait = no(同期点オプション
待機をnoにセット)”コールを発行して、同期点処理中
に障害が生じた場合に、アプリケーション56Aが、同期
的再同期化をいつまでも待つつもりがないことを示し
(ステップ900)、同期点マネジャ60Aは、このオプション
を記録する(ステップ902)。アプリケーション56Aがアプ
リケーション56Dにコンタクトして何らかの作業を行う
よう伝えた後に(図5のステップ533)、アプリケーション
56Dによって同様の処理(図56のステップ904および906)
が行われる。この実施例では、体系化デフォルトは、WA
IT = yesであることに留意されたい。ただし、要望に応
じて、システム50Aおよびシステム50Dのデフォルト条件
をWAIT = noにすることも可能である。そのような場
合、アプリケーション56Aおよびアプリケーション56D
は、WAIT = noを望むならば、“set syncpoint options
(同期点オプション設定)”コールを発行する必要がな
い。“set syncpoint options”はローカル値である。
したがって、障害が検出された同期点マネジャ側で有効
な“syncpoint options”の値が、実際に使用される値
である。

【０２１８】処理は、「保護された資源の調整式同期点
管理」の記述と、図2および図5のステップ533A〜546に
従って進む。上記の詳細を要約すると、アプリケーショ
ン56Aは、保護された会話を介してアプリケーション56D
に要求を送って、アプリケーション56Dにファイル78Dを
更新させる。アプリケーション56Dは、アプリケーショ
ン56Aに回答して、アプリケーション56Aにファイル78A
および78Bを更新させる。アプリケーション56Aは、コミ
ットを発行して(図5のステップ534)、同期点マネジャ60
Aに保護会話アダプタ64Aを呼び出させて、保護会話アダ
プタ64Dへ段階1“prepare”コールを送らせる。これに
より、アプリケーション56Dは、コミット発行要求を受
け取る。アプリケーション56Dは、コミットを発行し(ス
テップ537)、同期点マネジャ60Dは、その段階1の処理を
行い、保護会話アダプタ64Aに“request commit”と回
答するために保護会話アダプタ64Dを呼び出す。この
時、同期点マネジャ64Dの状態は「不確定」である(その
旨がそのログ72Dに記入される)。保護会話アダプタ64A
は、同期点マネジャ60Aに“request commit”と回答す
る。同期点マネジャ60Aの他の資源も“request commi
t”と回答したので、同期点マネジャ60Aの状態は、現在
“committed”であり、この状態をそのログ72Aに書き込
む。次に同期点マネジャ60Aは、その登録された資源に
コンタクトして、段階2の決定“committed”を渡す(図6
のステップ545)。次に、保護会話アダプタ64Aが、この
段階2の決定“committed”を保護会話アダプタ64Dに送
る(図6のステップ546)。ところが、この処理中に保護会
話アダプタ64Aが、障害を発見し、その結果、アプリケ
ーション56Aとアプリケーション56Dの間の保護された会
話のための、システム50Aとシステム50Dの間の経路が使
用不能になる。保護会話アダプタ64Aは、同期点マネジ
ャ60Aに“resource failure(資源障害)”と回答する。
これは同期点マネジャ60Aの処理への割込みであり(図6
のステップ550)、同期点マネジャ60Aに回復処理を開始
させる(図6のステップ557)。

【０２１９】回復手順は、使用される2段階コミットの
例によって定義される。この実施例では、2段階コミッ
トの例は、「保護された資源の調整式同期点管理」で使
用したものである。回復処理は、同期点マネジャの段階
1または段階2の呼出しに対して、保護資源アダプタが異
常な回答をした場合に発生する。この異常な回答は、シ
ステム障害、経路障害、プログラム障害または資源マネ
ジャ障害によって引き起こされる資源障害の結果であ
る。回復は、それを必要とする、障害を発生した保護さ
れた各資源ごとに独立に行われる。回復の目的は下記の
通りである。 1.保護された資源を、可能なら整合性のある状態に置
く。不可能なら、そのシステムの操作員に通知し、保護
された会話に障害が発生した場合には、その損傷を検出
したシステムに通知する。 2.ロックされた資源を他の用途に自由に使用できるよう
に、ロック解除する。 3.回復ファシリティのログを更新して、そのLUWIDに関
して保護されたすべての資源に同期点作業がこれ以上は
不要であると示す。

【０２２０】回復すなわち再同期化に伴うステップに
は、下記のものが含まれる。 1.回復ファシリティが動作しているシステムが障害を発
生した場合に、同期点の動作状況を表す、回復ファシリ
ティのログ・レコードからのデータ構造が復元される。
これらのデータ構造から、回復ファシリティ(他の実施
例では、1つのファシリティが同期点処理と回復処理の
両方を実行するので、回復ファシリティが同期点マネジ
ャと呼ばれることもある)は、それが回復を開始する責
任を負う資源を決定する。この回復がシステム障害なし
に発生する場合には、この回復ファシリティによって使
用される同期点中に書かれたデータ構造がまだ無傷なの
で、ログから情報を復元する必要はない。 2.回復を開始する責任を負う回復ファシリティ内のプロ
グラムが起動される。この実施例で保護された会話に使
用される会話の例では、これは、下記のことを意味す
る。保護された会話に関して、最初にこの同期点に関係
した、確認を必要とするタイプのシステムの回復ファシ
リティ内で実行中のパートナ回復プログラムとの保護さ
れない会話を確立する。(これには、活動化すべき2つの
システムの間に新規の経路が必要になることがある。) パートナが、LUWIDの適当な記憶を有することを検査す
るためにログ名を交換する。両パートナのLUWIDの状態
(すなわち、commitまたはbackout)を比較し調節する。
回復完了時に回復ファシリティ・ログのエントリを消去
し、その結果を両パートナの操作員に通知する。 3.この2段階コミット手順に参加する他の資源マネジャ
に対して、同様の回復方法が定義される。一般に、非分
散式保護資源マネジャに対する回復処理は、同期点サポ
ートを実施するオペレーティング・システムによって定
義される。保護された会話に対する回復処理は、システ
ム間通信アーキテクチャによって定義される。たとえ
ば、前者は、仮想記憶オペレーティング・システムの拡
張バージョンによって定義されるタイプでよく、後者
は、“System Network Architecture LU6.2 Reference:
Peer Protocols, SC31-6808, Chapter 5.3 Presentati
on Services - Sync Point verbs”で部分的に定義され
るタイプのものでよい。

【０２２１】次に、同期点マネジャ60Aは、障害を発生
した資源の識別子(この例の場合、この資源は保護され
た会話64Aである)と処理中のLUWIDを用いて回復ファシ
リティ70Aを呼び出す。回復ファシリティ70Aは、そのLU
WIDのログ・エントリと保護された会話64Aのエントリを
見つける(図4のステップ518)。回復ファシリティ70A
は、このエントリ中の状態情報から、回復の判断を決定
する(ステップ519)。上述の処理に基づけば、この判断
は“Commit”である。回復ファシリティ70Aは、回復す
べき資源が保護された会話であることを知っており、回
復処理を開始する。この回復処理は、その会話のための
体系化された回復方法と使用される2段階コミット・パ
ラダイムとによってその処理が定義されるアプリケーシ
ョンである。この回復処理は、システム50D上の回復フ
ァシリティ70D内のパートナの回復処理のために、保護
されない会話を開始する(ステップ520)。この回復の試
みは、経路障害のために2つのシステム間で会話が開始
できない(判断ブロック521のNO分岐)ので、失敗する。
その後、回復ファシリティ70Aは、ログ・エントリを検
査して、アプリケーション56Aが、回復が完了しないう
ちに、回復ファシリティ70Aが同期点マネジャ60Aにリタ
ーンできることを意味する WAIT = Noを要求したか否か
を調べる。次いで、回復ファシリティ70Aは、後でアプ
リケーション56Aとは非同期的に回復を完了することが
できる(ステップ524)。この情報は、同期点マネジャ60A
が、その段階1のログ書込み中に書き込んだものであ
る。上述したように、アプリケーション56Aは、“set s
yncpoint options wait = no”コールを発行した。した
がって、回復ファシリティ70Aは、同期点マネジャ60Aに
回復の意図すなわちコミットと、再同期(回復)がまだ進
行中であるとの指示を戻す(ステップ526)。同期点マネ
ジャ60Aは、すでに他の保護された資源から“forget”
を伝えられているので(図6のステップ545A)、LUWIDの値
を1だけ更新し、アプリケーション56Aに、意図した結果
であるCommitと、すべての資源がコミットされてはいな
いこととを示す戻りコード“RC = OK.LUW_OUTCOME_PEND
ING”を戻す(図6のステップ558)。これは、このコミッ
ト処理がアプリケーション56Aとは非同期的に完了され
ることを意味する。したがって、アプリケーション56A
はその後に他の作業の処理を継続でき、再同期化を待っ
て時間を浪費することがない。

【０２２２】回復ファシリティ70Aは、システム50D上の
回復ファシリティ70Dを用いて、保護会話アダプタ64Aの
回復の完了を成功させようと繰り返し試みる(図4のステ
ップ527)。回復を開始して最終的に完了した時(判断ブ
ロック521のYES分岐)、回復ファシリティ70Aと回復ファ
シリティ70Dは共に、回復が開始されたこと、およびそ
れが成功裡に完了したことを示す操作員メッセージを書
く(ステップ522)。同期点マネジャ60Dも、その登録され
た資源である保護会話アダプタ64Dを介して、障害を発
生した会話について知らされている。同期点マネジャ60
Dは、障害を発生した資源、この場合は保護された会話6
4Dの識別子とLUWIDとを用いて、その回復ファシリティ7
0Dにもコンタクトしていた。回復ファシリティ70Dは、
同期点マネジャの「不確定」の状態に基づいて、回復フ
ァシリティ70Aによる回復のためにコンタクトされるの
を待たなければならなかったことを知っていた。この回
復が最終的に完了する時(判断ブロック523の分岐YES)、
回復ファシリティ70Dは同期点マネジャ60Dにコミットの
判断を戻す(ステップ523A)。その後、同期点マネジャ60
Dはその段階2の処理を実行する。保護された会話が中断
しているので、同期点マネジャ60Dは続いて新規の一義
的なLUWIDを得る。その後、同期点マネジャ60Dはアプリ
ケーション56Dにコミットの結果を戻す。これで、アプ
リケーション56Dはその処理を実行できるようになる。
以前の例では、同期点マネジャ60Aに対して保護会話ア
ダプタ64Aによって代理される保護された会話ではな
く、ステップ545Aでファイル・マネジャ63Aで障害が起
こり得たことに留意されたい。この代替例では、回復フ
ァシリティ70Aは、オペレーティング・システムによっ
て定義される保護されない会話用の回復方法に基づい
て、回復ファシリティ70Dの代わりにファイル・マネジ
ャ63Aを用いて回復を開始することになる。

【０２２３】図5では、アプリケーション56A(したがっ
て、同期点マネジャ60Aも)が、コミット要求の開始側で
あった。ところが、図57は、アプリケーション56Aでは
なく、システム50Hにある別のアプリケーション56Hがコ
ミットを開始した(ステップ700)別の例を示す図であ
る。アプリケーション56Hが実行されるアプリケーショ
ン環境は、アプリケーション56Aが実行される環境と類
似していても異なっていてもよい。ただし、両方のシス
テムおよびアプリケーション環境は、どちらも前述の通
信と2段階コミット手順をサポートする。システム50Aと
システム50Dは、図2のそれと同一である。図57(および
それに続く図58と図59)に示す例では、アプリケーショ
ン56Hは、システム50H内の同期点マネジャ60Hに対し
て、システム50H、システム50Aおよびシステム50D内の
資源を使用するコミット要求(SYNCPT)を発行した。この
コミット要求に応答して、同期点マネジャ60Hは、段階1
の“prepare”コールを用いて、その登録された資源で
ある保護会話アダプタ64Hを呼び出す。次に、保護会話
アダプタ64Hが、システム50A内の保護会話アダプタ64B
に体系的システム間“prepare”コールを送る(ステップ
701)。前述したように、この“prepare”信号は、2段階
コミット手順の第1段階の一部である。次に、保護会話
アダプタ64Bがアプリケーション56Aに“Take Syncpoin
t”の通知を与え(ステップ704)、これに応答して、アプ
リケーション56Aが同期点マネジャ60Aに対してコミット
要求(SYNCPT)を発行する(ステップ706)。次に、同期点
マネジャ60Aが、段階1の“prepare”コールを用いて保
護会話アダプタ64Aを呼び出す。保護会話アダプタ64A
は、システム50D内の保護会話アダプタ64Dに体系的シス
テム間prepareコールを送る(ステップ708)。これに応答
して、保護会話アダプタ64Dがアプリケーション56Dに
“Take Syncpoint”通知を与える(ステップ710)。これ
に応答して、アプリケーション56Dが同期点マネジャ60D
にコミット(SYNCPT)要求を発行する(ステップ712)。同
期点マネジャ60Dは、その登録されたすべての資源に段
階1の“prepare”コールを発行する。同期点マネジャ60
Dによってアクセスされるすべての資源がコミットの準
備ができた時、同期点マネジャ60Dは、“request commi
t”の回答を用いて保護会話アダプタ64Dを呼び出す。保
護会話アダプタ64Dは、体系的システム間“request com
mit”コールをこのコミット要求の開始側、この場合に
は保護会話アダプタ64Aに送り、保護会話アダプタ64Aは
同期点マネジャ60Aに“request commit”と回答する(ス
テップ714)。同期点マネジャ60Aは、この要求と、その
資源がすべて作動可能である旨の通知とを受け取った後
に、保護会話アダプタ64Bに“request commit”と回答
する。保護会話アダプタ64Bは、体系的システム間“req
uest commit”コールを、このコミット要求の開始側、
この場合には開始側の保護会話アダプタ64Hと同期点マ
ネジャ60Hに送る(ステップ716)。同期点マネジャ60Aの
代理として保護会話アダプタ64Hからのこの回答と、同
期点マネジャ60Hの資源がすべて作動可能である旨の通
知とを受け取った後に、同期点マネジャ60Hの段階2の決
定がコミットされる。同期点マネジャ60Hは、段階2の決
定“commit”を用いてすべての資源を呼び出す。保護会
話アダプタ64Hは、呼び出されると、体系的システム間
“commit”コールを保護会話アダプタ64Bに送り、保護
会話アダプタ64Bは同期点マネジャ60Aに“committed”
と回答し、これがその段階2の決定になる(ステップ71
8)。

【０２２４】ここまでは、2段階コミット手順の実施に
問題がなかった。また、各アプリケーションが、ステッ
プ700、706および712で当該の同期点マネジャにコミッ
ト要求を発行した後に、各同期点マネジャが、段階1の
情報と状態をそれぞれ当該の回復ファシリティ・ログに
ロギングすることに留意されたい。同様に、同期点マネ
ジャ60Aおよび60Dはそれぞれ、それに関連する資源から
すべての資源が作動可能である旨の通知を受け取ると、
それぞれ当該の回復ファシリティ・ログのエントリに
“in doubt”とロギングする。1つまたは複数の資源が
コミットできない場合、ログ・エントリは作成されない
が、上流側の開始側に“backout”と回答する前に、バ
ックアウト処理が完了している。同様に、同期点マネジ
ャ60Hは、その登録されたすべての資源から“request c
ommit”を受け取ると、その回復ファシリティ・ログに
“commit”の決定を書き込む。同期点マネジャ60Aおよ
び60Dは、それぞれこのコミット判断を受け取ると、そ
の登録された資源にコンタクトする前に、それぞれ当該
の回復ファシリティ・ログにこのコミット決定を書き込
む。

【０２２５】次に、同期点マネジャ60Aが、段階2の“co
mmit”決定を用いて、その登録されたすべての資源を呼
び出す。同期点マネジャ60Aが、“commit”コールで保
護会話アダプタ64Aを呼び出すと、保護会話アダプタ64A
は、体系的システム間“commit”コールを保護会話アダ
プタ64Dに送ることを試み、保護会話アダプタ64Dは、同
期点マネジャ60Dに“committed”と回答しなければなら
ない。ところが、この例ではこの送信は会話経路の障害
のために成功しない(ステップ720)。この障害に応答し
て、同期点マネジャ60Aは、このLUWIDと保護された会話
とのための回復処理を求めて回復ファシリティ70Aにコ
ンタクトする。上述したように、回復ファシリティ70A
は、回復ファシリティ70Dを用いた回復の実行を1回試み
る(ステップ722)。この例では、通信経路の障害が持続
しているので、この試みも成功しない。次に、回復ファ
シリティ70Aは、ログ・エントリを読み取って、非同期
的再同期化が必要なことを知る。そこで回復ファシリテ
ィ70Aは、同期点マネジャ70Aに、この失敗した回復の試
みと、回復が非同期的に継続されることを通知する。そ
の後、同期点マネジャ60Aは、“forget, resynchroniza
tion-in-progress(RIP)(忘却、進行中の再同期化)”を
用いて、保護会話アダプタ64Bを呼び出す。保護会話ア
ダプタ64Bは、体系的システム間“forget, RIP”コール
を保護会話アダプタ64Hに送り、保護会話アダプタ64Hは
同期点マネジャ60Hに“forget, RIP”と回答する(ステ
ップ726)。その後、同期点マネジャ60Aは、アプリケー
ション56Aに戻りコード“RC = OK. LUW_OUTCOME_PENDIN
G”を与えて、commitの意図と、このコミット処理が非
同期的に完了されることを知らせる(ステップ724)。ス
テップ726の“Forget, RIP”通知は、ステップ718に対
する肯定応答として働き、それによって同期点マネジャ
60Hは、ステップ700の同期点に関係する同期点情報用の
その回復ファシリティ・ログに“forget”の状態を書き
込む。というのは、この時、2段階コミット処理がアプ
リケーション56Hの要求したコミットに関して完了して
いるからである。同期点マネジャ60Hは、その保護会話
アダプタ64Hから“Forget, RIP”の指示を受け取ると
(このコミットに関係する他のすべての資源からメッセ
ージを受け取っていると仮定して)、アプリケーション5
6Hに戻りコード“RC= OK. LUW_OUTCOME_PENDING”を戻
して、コミットの意図と、このコミット処理が非同期的
に完了されることを知らせることができる(ステップ72
8)。

【０２２６】回復ファシリティ70Aは、システム50D上の
回復ファシリティ70Dを用いた回復処理の実行を定期的
に試み、同時にコミットの指令を試みる(ステップ73
0)。上述したように、回復が完了した時、回復ファシリ
ティ70Dは段階2の“commit”決定で同期点マネジャ60D
に回答する。同期点マネジャ60Dは、その段階2の処理を
完了し、アプリケーション56Dにこのコミット要求が成
功裡に完了したことを意味する戻りコード“RC = OK. A
LL_AGREED”を戻す(ステップ732)。アプリケーション56
H、56Aおよび56Dは、いずれも他の処理を続行できる。
回復ファシリティ70Aと回復ファシリティ70Dの間で回復
処理が行われる時は、回復の開始とその処理の結果を示
すメッセージが、操作員コンソールに送られることに留
意されたい。

【０２２７】また、同期点マネジャ60Aは、回復ファシ
リティ70Aから“FAILED ATTEMPT TORESYNC(再同期化の
試みに失敗した)”通知を受け取った時、ログ72A内のロ
グ・エントリ内のLUWIDの状態を“Forget, RIP”に更新
することにも留意されたい。システム50Aは、後で、こ
のLUWIDに含まれる保護された会話を搬送していたシス
テム50Aとシステム50Hの間の会話経路上に次の正常な流
れが到着した時に、このLUWIDに“forget”の状態を書
き込む。これが“implied forget(暗黙の忘却)”動作で
ある。同期点マネジャ60Aが“Forget, RIP”の状態を書
き込んだ後、“implied forget”を受け取る前に、シス
テム50Aとシステム50Hの間の会話経路(これを介して、
進行中の再同期化の通知を受け取ったコミット手順に関
係していた保護された会話が流れていた)が働かなくな
る障害が生じた場合、システム50AのLUWIDのログ・エン
トリが、使用される2段階コミット・パラダイムによっ
て定義される正常な回復手順によって消去される。ただ
し、これには、以前に定義した比較状態データ流れ中
で、新規の進行中の再同期化の標識が送られることが必
要となる。“implied forget”が受け取られ、それによ
ってシステム50Aが回復ファシリティ・ログ72Aに“forg
et”の状態を書き込む場合は、回復ファシリティ70Dで
の回復が完了しない限り、回復ファシリティ70Aはこの
回復レコードを実際に忘却させない。

【０２２８】同期点マネジャ間には移送経路があるの
で、前述の非同期的再同期化(進行中の再同期化)機能を
サポートする同期点マネジャは、これをサポートしない
他の同期点マネジャと通信できることにも留意された
い。同期点処理をサポートするシステムが最初に互いに
通信する時は、両方のシステムに使用される通信体系と
2段階コミット手順とによって定義される初期ケイパビ
リティ交換の際に、これらのシステムが前述の進行中の
再同期化機能をサポートするか否かが決定される。コミ
ット要求の開始側、図57の上記の例では同期点マネジャ
60Hが、進行中の再同期化をサポートしない場合には、
カスケード式の開始側(このコミット要求を受け取る同
期点マネジャ、上記の例では同期点マネジャ60A)は、こ
のコミット要求を開始した同期点マネジャ(上記の例で
は同期点マネジャ60H)に、同期点要求の意図(コミット
またはバックアウト)を送り返すが、再同期化が後で非
同期的に行われるとの指示は送り返さない。ローカル・
アプリケーションは、故障停止が発生し(上記の例では
アプリケーション56A)、同期点マネジャが進行中の再同
期化をサポートする(上記の例では同期点マネジャ60A)
場合、この進行中の再同期化通知を受け取る。

【０２２９】図58は、同期点マネジャ60Hが、以下で詳
細に示すようにバックアウトを発行する場合の進行中の
再同期化の機能を示す図である。ステップ700〜714は、
図57と同一である。ただし、同期点マネジャ60Hは、ス
テップ716で同期点マネジャ60Aから保護会話アダプタ64
Hを介して回答“request commit”を受け取った後に、
その保護された資源のうちの1つまたは複数が動作不能
であるために、バックアウトすることを決定する。そこ
で、同期点マネジャ60Hは、段階2の決定“backout”を
用いてその登録された資源を呼び出す。この決定“back
out”が、同期点マネジャ60Aに与えられる(保護会話ア
ダプタ64Hが、体系的システム間backoutコールを保護会
話アダプタ64Bに送り、保護会話アダプタ64Bが、同期点
マネジャ60Aに“backout”と回答する)(ステップ740)。
同期点マネジャ60Aは、段階2の決定“backout”でその
登録された資源を呼び出す。保護会話アダプタ64Aは、
ステップ742で、保護会話アダプタ64Dを介して同期点マ
ネジャ60Dにシステム間backoutコールを送ろうと試み
る。ところがこの例では、通信経路障害またはその他の
タイプの障害のために、ステップ742は失敗する。これ
に応答して、同期点マネジャ60Aは、ステップ744で、LU
WIDと障害を発生した資源の識別子とを用いて回復ファ
シリティ70Aを呼び出し、システム50D上の回復ファシリ
ティ70Dを用いた回復処理を実行させる。しかし、この
例では、この回復の試みも失敗する。回復ファシリティ
70Aは、同期点マネジャ60Aに、この回復の試みに失敗し
たが、非同期的に回復処理を完了すると回答する。他の
保護された資源からの通知を受けた後に、同期点マネジ
ャ60Aは、その回復ファシリティのログ72Aに、“backou
t, rip”の状態を書き込む。その後、同期点マネジャ60
Aは、“backout, rip”の回答を用いて保護会話アダプ
タ64Bを呼び出す。体系的システム間backoutコールに基
づいて、保護会話アダプタ64Bは、保護会話アダプタ64H
からの元の段階2の“backout”コールに対してエラー回
答を送る(ステップ748)。その後、保護会話アダプタ64B
は、保護会話アダプタ64Hに、体系的システム間“backo
ut, rip”コールを送る(ステップ750)。保護会話アダプ
タ64Hは、この“backout, rip”の指示を受け取った後
に、体系的システム間肯定応答を送り(ステップ752)、
同期点マネジャ60Hに“backout, rip”と回答する(ステ
ップ752)。同期点マネジャ60Hは、他の資源からの回答
を得た後に、アプリケーション56Hに、バックアウトが
保留中であることを通知する戻りコード“RC = Backou
t, LUW_OUTCOME_PENDING”を戻して、アプリケーション
56Hが他の有用な作業を行ってもよいと知らせる(ステッ
プ754)。保護会話アダプタ64Bは、保護会話アダプタ64H
から“backout, rip”コールに対する肯定応答(ステッ
プ748および750に対する応答)を得ると、同期点マネジ
ャ60Aに“ok”と回答する。その後同期点マネジャ60A
は、回復ファシリティのログ72A内のこのLUWID用のログ
エントリに“forget”の状態を書き込み、アプリケーシ
ョン56Aに戻りコード“RC = Backout, LUW_OUTCOME_PEN
DING”を戻す(ステップ746)。この戻りコードは、この
コミット要求の意図された結果がバックアウトである
が、すべての資源がバックアウトしたわけではないこと
を意味する。ここでアプリケーション56Aは、その処理
を続行できる。回復ファシリティのログ72A内のLUWIDエ
ントリは、上述の“implied forget”としてシステム50
Aによって忘却される。この“forget”が書き込まれる
時、このLUWID内の障害を発生した資源がまだ回復され
ていない場合は、回復が行われるまでそのLUWIDエント
リは実際には忘却されない。その間に、回復ファシリテ
ィ70Aは、システム50D内の回復ファシリティ70Dを用い
て非同期的に回復の試みを続ける(ステップ756)。回復
が完了した時、同期点マネジャ60Dは、バックアウトの
通知を受け、その段階2の処理を完了する。その後同期
点マネジャ60Dはアプリケーション56Dに、すべての資源
がバックアウトされたことを意味する戻りコード“RC =
BACK OUT. ALL_AGREED”を戻す(ステップ758)。アプリ
ケーション56H、56Aおよび56Dは、いずれも他の処理を
続行できる。回復ファシリティ70Aと回復ファシリティ7
0Dの間で回復処理が行われる際に、回復の開始とその処
理の結果を示すメッセージが操作員コンソールに送られ
ることに留意されたい。

【０２３０】図59は、同期点マネジャ60Aが、以下で詳
細に示すようにバックアウトを発行する場合の進行中の
再同期化の機能を示す図である。ステップ700〜714は、
図58と同一である。ただし、同期点マネジャ60Aは、ス
テップ714で回答“request commit”を受け取った後、
同期点マネジャ60Aに関連する資源のうちの1つまたは複
数がコミット不能であるため、段階2の“backout”コー
ルを用いてその登録された資源を呼び出す(ステップ75
9)。保護会話アダプタ64Aは、保護会話アダプタ64Dに体
系的システム間“backout”コールを送ろうと試みる(ス
テップ760)。ところが、ステップ760に示されるよう
に、通信経路障害またはその他の障害のため、この“ba
ckout”コールを保護会話アダプタ64Dは受け取らない。
同期点マネジャ60Aは、LUWIDと障害を発生した資源の識
別子とを用いて回復ファシリティ70Aを呼び出し、回復
処理を実行するよう求める。回復ファシリティ70Aは、
システム50D内の回復ファシリティ70Dを用いて、回復処
理を実行しようと試みる(ステップ744)。通信経路の障
害が持続しているので、ステップ744も失敗し、その結
果、同期点マネジャ60Aは、図58を参照して上述したス
テップ746の信号を送る。ステップ750〜758も、図58と
同一である。

【０２３１】図60は、以下で詳細に示すように異なる障
害のために、同期点マネジャ60Aがバックアウトを発行
する場合の進行中の再同期化の機能を示す図である。ス
テップ700〜706は、図58と同一である。ただし、同期点
マネジャ60Aは、ステップ706でコミット要求を受け取っ
た後に、段階1の“prepare”コールを用いてその登録さ
れた資源を呼び出す。保護会話アダプタ64Aは、保護会
話アダプタ64Dに体系的システム間“prepare”コールを
送ろうと試みる(ステップ708A)。ところが、ステップ70
8Aに示されるように、通信経路の障害またはその他の障
害のために、この“prepare”コールを保護会話アダプ
タ64Dは受け取らない。同期点マネジャ60Aは、段階2のb
ackoutコールを用いてそのローカルな登録された資源を
呼び出す(ステップ763)。その後同期点マネジャ60Aは、
LUWIDと障害を発生した資源の識別子とを用いて回復フ
ァシリティ70Aを呼び出し、回復処理を実行するよう求
める。回復ファシリティ70Aは、システム50D内の回復フ
ァシリティ70Dを用いて回復処理を実行しようと試みる
(ステップ744)。通信経路の障害が持続しているので、
ステップ744も失敗し、その結果、同期点マネジャ60A
は、図58を参照して上述したステップ746の信号を送
る。ステップ750〜756は、図58と同一である。同期点マ
ネジャ60Aによって行われる処理とは非同期的に、アプ
リケーション56Dが、以前(アプリケーション56Aがアプ
リケーション56Dを開始した時)に確立されたアプリケー
ション56Aとの保護された会話上で経路障害の指示を受
け取る(ステップ761)。この経路障害のため、保護会話
アダプタ64Dは保護会話アダプタ64Aからprepareコール
を受け取れなかった。この経路障害は、保護された会話
に対して発生したので、アプリケーション56Dはバック
アウト要求を発行しなければならない。アプリケーショ
ン56Dは、バックアウト要求を発行し(ステップ762)、最
終的に、すべての資源がバックアウトされたことを示す
戻りコードを受け取る(ステップ764)。この時点で、ア
プリケーション56H、56Aおよび56Dは、いずれも他の処
理を続行できる。その間に、回復ファシリティ70Aは、
システム50D内の回復ファシリティ70Dを用いて非同期的
に回復の試みを続ける(ステップ756)。回復処理が回復
ファシリティ70Aと回復ファシリティ70Dの間で行われる
際に、回復の開始とその処理の結果を示すメッセージが
操作員コンソールに送られることに留意されたい。

【０２３２】以上の説明により、本発明を実施する方法
およびシステムが開示された。ただし、本発明の範囲を
逸脱することなく、多数の変更および置換が可能であ
る。したがって、本発明の開示は、例示的なものであっ
て、限定的なものではなく、本発明の範囲を決定するに
は、頭記の特許請求の範囲を参照すべきである。

【０２３３】以下は、部分的な用語集である。 アプリケーション ある実行環境内で実行され、コミット、バックアウトま
たは作業要求のうちの1つまたは複数を発行できる、ユ
ーザ・プログラムまたはサービス・プログラムまたは資
源マネジャと統合された作業分散機能 実行環境 仮想計算機、パーソナル・コンピュータ、ワーク・ステ
ーション、ミニ・コンピュータ、メインフレーム・コン
ピュータまたはその他のタイプのコンピュータあるいは
それらの任意の組合せにおいて、アプリケーション、シ
ステム・ファシリティ(回復ファシリティ、通信ファシ
リティなど)、資源マネジャまたはその他のプログラム
あるいはそれらの任意の組合せを実行するための、何ら
かの計算手段 保護された会話 何らかの形の同期点処理または保護的コミットもしくは
バックアウト手順の対象となる会話 保護された資源 何らかの形の同期点処理または他の保護的コミットもし
くはバックアウト手順の対象となる資源 回復ファシリティ 障害を発生した同期点またはその他のコミットもしくは
バックアウト手順の回復の責任を負うファシリティ 2段階コミット手順 更新または保護会話あるいはその両方の、コミットまた
はバックアウトを調整または同期あるいはその両方を行
うための手順。通常、2段階コミット手順は、保護され
た会話を介して、複数の資源または単一の資源を原子的
にコミットまたはバックアウトするのに使用される。た
とえば、2段階コミット手順には、ポーリングまたは準
備段階と、バックアウトまたはコミット段階を含めるこ
とができる。

【図面の簡単な説明】

【図１】各実行環境内にすべてのコミット機能と回復機
能を組み込んだ、従来技術によるコンピュータ・システ
ムのブロック図である。

【図２】本発明による、2つの相互接続されたコンピュ
ータ・システムを含むコンピュータ・ネットワークのブ
ロック図である。各システムは、共通の回復ファシリテ
ィとログで複数の実行環境をサポートする。

【図３】図2の実行環境内で実行されるアプリケーショ
ンによって使用される資源に関する、2段階コミット手
順の流れ図である。

【図４】図3に示した2段階コミット手順中に割込みが発
生する時に実施される、回復処理の流れ図である。

【図５】図2の同期点ファシリティをサポートする保護
された会話によって接続された、2つの分散アプリケー
ション環境内で実行されるパートナ・アプリケーション
によって使用される資源に関する、2段階コミット手順
の流れ図である。

【図６】図2の同期点ファシリティをサポートする保護
された会話によって接続された、2つの分散アプリケー
ション環境内で実行されるパートナ・アプリケーション
によって使用される資源に関する、2段階コミット手順
の流れ図である。

【図７】単一の図2の実行環境内で異なるコミット範囲
を定義する複数の作業ユニットと、図2の複数のシステ
ムにまたがるコミット範囲とを示す、ブロック図であ
る。

【図８】コミット処理の範囲を定義し、コミット処理を
容易にするための、図2の1つのアプリケーション環境に
よる、ローカル作業ユニットとグローバルな作業論理ユ
ニットの使用を示す、流れ図である。

【図９】コミット処理の範囲を定義し、コミット処理を
容易にするための、図2のもう1つの関連するアプリケー
ション環境による、ローカル作業ユニットとグローバル
な作業論理ユニットの使用を示す、流れ図である。

【図１０】コミット処理の範囲を定義し、コミット処理
を容易にするための、図2のもう1つの関連するアプリケ
ーション環境による、ローカル作業ユニットとグローバ
ルな作業論理ユニットの使用を示す、流れ図である。

【図１１】図8および図8のグローバルな作業論理ユニッ
トにおける、保護された会話のタイミング図である。

【図１２】図2のシステム内での資源の自動的かつ総称
的な登録を示す、ブロック図である。

【図１３】図7の同期点マネジャ内に適当なタイプのコ
ミット手順用の資源を登録する手順と、そのコミット手
順のステップとを示す、流れ図である。

【図１４】図2のシステム内での作業ユニットに基づく
登録を示す、ブロック図である。

【図１５】作業ユニットに基づく登録を示す、銀行取引
の時間の流れを示す図である。

【図１６】同期点マネジャで、資源を登録し、資源の登
録情報を変更し、資源を登録解除する手順を示す、流れ
図である。

【図１７】資源アダプタ、保護会話アダプタおよび同期
点マネジャが、資源の登録を解除するのに使用する手順
を示す、流れ図である。

【図１８】同期点要求に応答して同期点マネジャが行う
処理と、1段階コミット処理か2段階コミット処理かを選
択する際に同期点マネジャが行う最適化とを示す、流れ
図である。

【図１９】2段階コミット手順を示す、流れ図である。

【図２０】2段階コミット手順に参加する3つの分散アプ
リケーション・プログラムを示す、流れ図である。

【図２１】図2のあるシステム内のアプリケーションと
別のシステム内のパートナ・アプリケーションの間で保
護された会話が行われる時に、障害を発生したコミット
手順の回復をサポートするためのログ名交換に用いる構
成要素と手順を示す、ブロック図である。

【図２２】通信ファシリティによる、初期の事象とその
後の会話事象のための図21に関連する処理の流れ図であ
る。

【図２３】ローカル通信ファシリティが回復ファシリテ
ィにある経路用のログ名を交換するよう要求した時に、
その結果として生じる、回復ファシリティによる、図21
に関連する処理の流れ図である。

【図２４】ローカル通信ファシリティが回復ファシリテ
ィにある経路用のログ名を交換するよう要求した時に、
その結果として生じる、回復ファシリティによる、図21
に関連する処理の流れ図である。

【図２５】別の回復ファシリティからログ名交換要求を
受け取った結果として生じる、回復ファシリティによ
る、図21に関連する処理の流れ図である。

【図２６】図2の一部における、ローカル資源マネジャ
を用いログ名交換のための構成要素と手順を示す、ブロ
ック図である。

【図２７】図2のシステムとリモート資源マネジャを使
用するログ名交換のための構成要素と手順を示す、ブロ
ック図である。

【図２８】図2の回復ファシリティの内容を示す、ブロ
ック図である。

【図２９】ログ名の交換を実施すべき時点を決定する処
理を示す、流れ図である。

【図３０】参加する資源マネジャと回復ファシリティの
間でログ名を交換するための処理を示す、流れ図であ
る。

【図３１】同期点ログの可搬性とバックアップ回復ファ
シリティを活動化する能力を示す、ブロック図である。

【図３２】コミット手順における問題を定義するエラー
・フラグおよび情報をアプリケーション・プログラムに
渡す際の、図2の資源アダプタと同期点マネジャの参加
を示す、ブロック図である。

【図３３】図32の構成要素を使ってアプリケーション・
プログラムにエラー情報を渡す手順を示す、流れ図であ
る。

【図３４】システムの作業用記憶域を減らすために、図
32に関連するエラー・ブロックが使用するページを共用
するための、制御ブロック構造を示す図である。

【図３５】図32のエラー・フラグおよび情報の生成と管
理に参加する、図2の構成要素のブロック図である。

【図３６】開始側アプリケーションと同一のシステムお
よび異なるシステムに常駐する資源マネジャと、コミッ
ト処理中に使用される通信経路ならびに同期点回復処理
のために使用される経路を組み込んだ、複数のシステム
・コミット範囲にわたるコミット・サイクルを含む、3
つのシステムを示す、ブロック図である。

【図３７】同期点参加者のツリーを形成する、図36の3
つの参加するアプリケーションおよびアプリケーション
環境とそれらが使用する資源マネジャとを示す、ブロッ
ク図である。

【図３８】回復ファシリティの、同期点以前の同意の手
順と同期点障害からの回復の手順を示す、高水準の流れ
図である。

【図３９】同期点障害からの回復のための回復ファシリ
ティの手順をより詳細に示す、流れ図である。

【図４０】図2のログ72の内容と、図38で表される手順
を制御するのに必要な制御構造とを示す、ブロック図で
ある。

【図４１】図38のステップ299および300の詳細を示す流
れ図である。

【図４２】図38のステップ301および302の詳細を示す流
れ図である。

【図４３】図39のステップ311の詳細を示す流れ図であ
る。

【図４４】図39のステップ312の詳細を示す流れ図であ
る。

【図４５】図39のステップ313の詳細を示す流れ図であ
る。

【図４６】図39のステップ314の詳細を示す流れ図であ
る。

【図４７】図39のステップ315の詳細を示す流れ図であ
る。

【図４８】図39のステップ304の詳細を示す流れ図であ
る。

【図４９】図39のステップ317の詳細を示す流れ図であ
る。

【図５０】図39のステップ317の詳細を示す流れ図であ
る。

【図５１】図39のステップ318の詳細を示す流れ図であ
る。

【図５２】図39のステップ319の詳細を示す流れ図であ
る。

【図５３】図39のステップ319の詳細を示す流れ図であ
る。

【図５４】図39のステップ306の詳細を示す流れ図であ
る。

【図５５】同期点処理中にエラーが発生した場合に、ア
プリケーション56Aおよびアプリケーション56Dが非同期
的再同期化を要求する様子を示すブロック図である。

【図５６】同期点処理中にエラーが発生した場合に、ア
プリケーション56Aおよびアプリケーション56Dが非同期
的再同期化を要求する様子を示すブロック図である。

【図５７】追加のシステム50Hを伴う、非同期的な進行
中の再同期化のステップを示す、流れ図である。

【図５８】システム50Hから発する障害を発生したバッ
クアウト指令に関係する、非同期的な進行中の再同期化
のステップを示す、流れ図である。

【図５９】システム50Aから発する障害を発生したバッ
クアウト指令に関係する、非同期的な進行中の再同期化
のステップを示す、流れ図である。

【図６０】システム50Aから発する障害を発生したprepa
reコールに関係する、非同期的な進行中の再同期化のス
テップを示す、流れ図である。

【図６１】図2の代替例としての、本発明のもう1つの実
施例のブロック図である。

【図６２】図2の代替例としての、本発明のもう1つの実
施例のブロック図である。

【符号の説明】

50 システム 52 アプリケーション実行環境 53 会話マネジャ 55 システム制御プログラム 56 アプリケーション 60 同期点マネジャ(SPM) 62 資源アダプタ 63 資源マネジャ 64 保護会話アダプタ 70 回復ファシリティ 72 ログ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 マイケル・ケヴィン・エインズワース アメリカ合衆国 13760、ニューヨーク 州、エンディコット、デイ・ホロウ・ロ ード、アール・ディーナンバー６、ボッ クス2443（番地なし) (72)発明者 シェリー・カーライル・バーンズ アメリカ合衆国 13734、ニューヨーク 州、バートン、エリス・クリーク・ロー ド、アール・ディーナンバー１、ボック ス358（番地なし) (72)発明者 ロバート、ブラッドリー・ベネット アメリカ合衆国 13760、ニューヨーク 州、エンドウェル、カントリー・クラ ブ・ロード 3718番地 (72)発明者 バーバラ・アン・マリー・マスラク アメリカ合衆国 13760、ニューヨーク 州、エンドウェル、バーナード・ブール バード 2008番地 (72)発明者 エドモンド・オーガスト・プルール アメリカ合衆国 13730、ニューヨーク 州、アフトン、アール・ディーナンバー １、ボックス632（番地なし) (72)発明者 ジェームズ、マイケル・ショワルター アメリカ合衆国 13760、ニューヨーク 州、エンディコット、ウェスト・メイ ン・ストリート 504番地 31号室 (72)発明者 トマス・ジョーゼフ・シチギエルスキ アメリカ合衆国 13760、ニューヨーク 州、エンディコット、パイン・ノール・ ロード 113番地 (72)発明者 アモス・スタンリー・タナー アメリカ合衆国 13850、ニューヨーク 州、ヴェスタル、コストリー・ロード、 アール・ディーナンバー３、ボックス 416（番地なし) (56)参考文献 特開 昭62−206645（ＪＰ，Ａ) 特開 平１−194040（ＪＰ，Ａ) 特開 平１−261746（ＪＰ，Ａ) 新田外３「大規模ＤＢ／ＤＣの高性 能・高信頼化方式の考察」情報処理学会 アドバンストデータベースシステムシン ポジウム論文集（昭和63年12月)

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】保護された資源の同期点管理を行うコンピ
   ュータ・システムであって、 第１実行環境と、 前記第１実行環境内に常駐し、前記第１実行環境に対す
   る第１コミット手順を調整する第１同期点マネジャ手段
   と、 前記第１同期点マネジャ手段を、前記第１コミット手順
   に関連する第１資源を管理する第１資源マネジャに結合
   する手段と、 第２実行環境と、 第２実行環境内に常駐し、前記第２実行環境に対する第
   ２コミット手順を調整する第２同期点マネジャ手段と、 前記第２同期点マネジャ手段を、前記第２コミット手順
   に関連する第２資源を管理する第２資源マネジャに結合
   する手段と、 前記第１および第２同期点マネジャ手段に結合され、前
   記第１および第２資源マネジャに対する同期点情報およ
   び該第１および第２資源マネジャの識別子を受け取り、
   前記第１および第２コミット手順を回復する、前記第１
   および第２実行環境に共通の回復ファシリティ手段と、前記回復ファシリティ手段に結合され、前記同期点情報
   および前記識別子を記憶する、前記第１および第２実行
   環境に共通の回復ファシリティ・ログ手段とを備え、 前記第１同期点マネジャ手段は、前記第１資源マネジャ
   に対する同期点情報を前記回復ファシリティ手段を介し
   て前記回復ファシリティ・ログ手段にロギングする手段
   を含み、前記第２同期点マネジャ手段は、前記資源マネ
   ジャに対する同期点情報を前記回復ファシリティ手段を
   介して前記回復ファシリティ・ログ手段にロギングする
   手段を含み、 前記回復ファシリティ手段を、前記第１および第２同期
   点マネジャ手段をバイパスして前記第１および第２資源
   マネジャに結合する手段を更に備え、 前記回復ファシリティ手段は、前記第１および第２同期
   点マネジャ手段をバイパスして前記第１資源マネジャに
   コミットまたはバックアウト・コマンドを伝えることに
   より前記第１コミット手順を回復し、前記第１および第
   ２同期点マネジャ手段をバイパスして前記第２資源マネ
   ジャにコミットまたはバックアウト・コマンドを伝える
   ことにより前記第２コミット手順を回復することを特徴
   とする、コンピュータ・システム。