JPH0793272A - 資源の同期点管理を実行する装置および方法 - Google Patents

Abstract

(57)【要約】 【目的】本発明の目的は、分散式で独立なアプリケーシ
ョン環境用の、効率的で調整された資源保護／回復シス
テムおよび方法を提供することである。 【構成】コンピュータ・システムまたは処理において、
複数の実行環境用の各実計算機の全体に同期点マネジャ
が分散されているが、１実計算機内のすべての実行環境
および同期点マネジャが、共通の回復ファシリティおよ
び回復ログを共用する。共通の回復ログが、システム内
のすべての実行環境のために、回復ファシリティによっ
て使用される。異なるシステムは、通信ファシリティに
よって相互接続され、そのそれぞれが、それ自体の回復
ファシリティと回復ログを有する。同じ実計算機内の第
１実行環境と第２実行環境の間で保護された会話が開始
でき、それぞれの実行環境内の同期点マネジャが、この
保護された会話に関連する２段階のコミット手順を調整
する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

【０００３】このようなシステムは、それぞれが１台の
実計算機であると見なされる。２台以上のこのような実
計算機をネットワーク内で相互接続し、異なる実計算機
の仮想計算機の間での会話を介してデータを転送するこ
とが一般に行われている。このような転送は、ＡＶＳゲ
ートウェイやＶＴＡＭファシリティ（“ＡＶＳゲートウ
ェイ”および“ＶＴＡＭ”は、ＩＢＭコーポレーション
の登録商標）などの通信ファシリティを介して行われ
る。

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

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

【０００６】ＩＢＭシステム・ネットワーク・アーキテ
クチャＳＮＡ ＬＵ６．２アーキテクチャ（解説書ＳＣ
３１−６８０８、第５．３章、“Presentation Service
s -Sync Point Verbs”、ＩＢＭコーポレーション刊）
は、２つ以上の保護された資源間でコミットを調整する
ことが以前から知られていた。このアーキテクチャは、
すでに、単一のアプリケーション環境内で実行される同
期点処理とそれに関連する回復処理の両方を実行する、
同期点マネジャからなる同期点ファシリティに対処して
いた。複数のアプリケーションがこの環境内で同時に実
行できた。ＬＵ６．２アーキテクチャは、資源の調整、
同期点のロギングおよび回復の責任を負う同期点マネジ
ャ（ＳＰＭ）をサポートする。従来技術のＣＩＣＳ／Ｖ
Ｓ（ＩＢＭコーポレーションの登録商標）環境は、この
ようなアーキテクチャをサポートする。

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

【０００８】前述のＬＵ６．２同期点アーキテクチャ
は、１つのアプリケーション実行環境として定義され
る。あらゆるＬＵ６．２同期点環境は、その環境用のア
プリケーションを実行する。データは、通常はその環境
に所有され、その環境から特に抜き出されない限り、そ
の環境の外部では共用されない。ＬＵ６．２同期点アー
キテクチャは、単一の環境内での資源の調整、回復およ
び同期点マネジャのロギングのための同期点マネジャ
（ＳＰＭ）モデルを定義する。異なる環境には、たとえ
物理的に同一のプロセッサ上にあっても、別々の同期点
動作および回復動作と別々のログを含む、別々の同期点
マネジャが必要となる。同様に、もう１つの従来技術の
システム制御プログラムである、ＩＢＭコーポレーショ
ンから販売されているＣＩＣＳ／ＶＳ制御プログラムで
は、すべてのプロセスとほとんどの資源は、システムで
はなく環境が所有する。

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

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

【００１１】

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

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

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

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

【００１５】

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

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

【００１７】

【実施例】図面で、複数の図を通じて同じ要素は同じ参
照番号で示す。図１には、従来技術によるＬＵ６．２同
期点タワー・モデルまたはアーキテクチャが示されてい
る。このアーキテクチャは、１つの実行環境として定義
されている。この例では、３つのアプリケーション・プ
ログラム１４、１６および１８が、実行環境１２内で時
分割式に実行される。資源マネジャ２６および２７は、
ＤＢ／２またはＣＩＣＳファイル制御装置（ＤＢ／２お
よびＣＩＣＳはＩＢＭコーポレーションの登録商標）で
あり、それぞれ資源２２および２４へのアクセスを制御
する。ＤＢ／２（ＣＣＩＳ／ＭＶＳオペレーティング・
システム）またはＳＱＬ／ＤＳ（ＣＣＩＳ／ＶＳＥオペ
レーティング・システム）資源マネジャが実行環境１２
の外部にある場合、実行環境１２は、従来技術によって
資源マネジャへインタフェースする資源アダプタを含む
ことになる。この従来技術のアーキテクチャでは、アプ
リケーション・プログラム１４は、同期点マネジャ２０
に対して資源２２および２４を呼び出す作業要求を行っ
た後で、その作業要求に含まれる資源のコミットを要求
する。

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

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

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

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

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

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

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

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

【００２６】その２段階コミット手順を実行する間に、
同期点マネジャ６０Ａは、回復ファシリティ７０Ａに要
求を発行して、段階１の同期点マネジャ情報をログ７２
Ａに強制ロギング（「強制ロギング」とは、同期点マネ
ジャ６０Ａに戻る前に、確実に情報が実際の物理装置に
書き込まれるようにすることを意味する）させる（ステ
ップ５０８）。この情報には、作業論理ユニット識別
子、同期点マネジャの状態および、このコミット要求に
参加する登録された各保護資源アダプタに関する名前そ
の他の関連情報が含まれる。この情報は、保護ファイル
・アダプタ６２Ａおよび６２Ｂが登録された時に、同期
点マネジャ６０Ａに与えられたものである。同期点マネ
ジャ６０Ａの状態は、準拠する２段階コミット・パラダ
イムの規則によって決定される。たとえば、この２段階
コミット・パラダイムは、ＩＢＭコーポレーションの刊
行物“System Network Architecture LU 6.2 Referenc
e: PeerProtocols, SC31-6808, Chapter 5.3 Presentat
ion Services - Sync Point verbs”に記載されている
タイプのものである。この同期点処理の間に障害が発生
した場合、同期点マネジャの状態を使用して、作業論理
ユニットの結果（コミットまたはバックアウト）を決定
する。この実施例で使用する２段階コミット・パラダイ
ムの規則によれば、同期点マネジャの段階１の状態は、
「開始側（Ｉｎｉｔｉａｔｏｒ）」、「同期点マネジャ
保留中（Ｓｙｎｃｐｏｉｎｔ Ｍａｎａｇｅｒ Ｐｅｎ
ｄｉｎｇ）」である。２段階コミット手順の第１段階が
中断されずに完了した場合（判断ブロック５１２）、同
期点マネジャ６０Ａは、回復ファシリティ７０Ａに第２
の要求を発行して、ログ７２Ａにその段階２の状態を強
制ロギングさせる。保護ファイル・アダプタと資源マネ
ジャからの回答と、使用している２段階コミット・パラ
ダイムの規則とに基づいて、同期点マネジャ６０Ａは、
その第２段階の決定を知る。この実施例では、このパラ
ダイムは以下のようなものである。１つまたは複数の保
護資源アダプタが、段階１の要求に対して「バックアウ
ト」と回答した場合、段階２の決定は「バックアウト」
である。すべてが「要求コミット」と回答した場合、決
定は「コミット」である。図３に示した例では、保護フ
ァイル・アダプタ６２Ａおよび６２Ｂは、「要求コミッ
ト」と回答し（ステップ５１０）、段階２の状態は、同
期点マネジャ６０Ａによって、「開始側コミット済み
（Ｉｎｉｔｉａｔｏｒ Ｃｏｍｍｉｔｔｅｄ）」として
ロギングされる。この例では、ファイル・マネジャ６３
Ａおよび６３Ｂは、段階１の要求に対してそれぞれの保
護ファイル・アダプタ６２Ａおよび６２Ｂを介して「要
求コミット」と回答した後、「不確定（ｉｎｄｏｕｂ
ｔ）」の状態になる、すなわち、それらのファイル・マ
ネジャは、同期点マネジャ６０Ａからの段階２の決定に
基づいて、ファイル更新をコミットまたはバックアウト
できることに留意されたい。

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

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

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

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

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

【００３２】ここでアプリケーション５６Ａは、同期点
マネジャ６０Ａにコミット５８Ａを発行する（ステップ
５３４）。上述したように、同期点マネジャ６０Ａは、
回復ファシリティ７０Ａにコンタクトしてその段階１の
ロギングを求め、登録された各資源に対して段階１の
「準備」コールを発行する（ステップ５３４Ａおよび５
３５Ａ）。保護ファイル・アダプタ６２Ａおよび６２Ｂ
は、上述したように振る舞う。保護会話アダプタ６４Ａ
は、段階１の「準備」コールを受け取った時、それが代
理する保護された会話、すなわち最初にアプリケーショ
ン５６Ａによってアプリケーション５６Ｄに対して確立
された会話を介して、体系的システム間「準備」コール
を送る（ステップ５３５）。保護会話アダプタ６４Ｄ
は、この「準備」コールを認識して、会話メッセージ受
取コールを発行したアプリケーション５６Ｄに、コミッ
トの発行を要求する戻りコードを与える（ステップ５３
６）。次に、アプリケーション５６Ｄは、同期点マネジ
ャ６０Ｄに対してコミット５８Ｄを発行する（ステップ
５３７）。上述したように、同期点マネジャ６０Ｄはそ
の回復ファシリティにコンタクトするが、この場合は、
回復ファシリティ７０Ｄにコンタクトして、段階１情報
をログ７２Ｄに強制ロギングさせる（ステップ５３
８）。アプリケーション５６Ａが元のコミット要求を発
行し、その要求に応じてアプリケーション５６Ｄが後で
コミットを発行したので、この実施例で使用する２段階
コミット・パラダイムに基づくと、同期点マネジャ６０
Ｄの段階１の状態は「開始側カスケード、同期点マネジ
ャ保留中（Ｉｎｉｔｉａｔｏｒ Ｃａｓｃａｄｅ，Ｓｙ
ｎｃｐｏｉｎｔ Ｍａｎａｇｅｒ Ｐｅｎｄｉｎｇ）」
である（ステップ５３８）。同期点マネジャ６０Ｄは、
段階１の「準備」コールを用いて保護ファイル・アダプ
タ６２Ｄにコンタクトする（ステップ５３８）。保護フ
ァイル・アダプタ６２Ｄとそれに関連する資源マネジャ
６３Ｄは、上述したように段階１の処理を実行し、「コ
ミット要求」の回答を戻す。

【００３３】この例では、中断がなかったので、判断ブ
ロック５３９からステップ５４０に進み、同期点マネジ
ャ６０Ｄが、回復ファシリティ７０Ｄにコンタクトし
て、ログ７２Ｄを「代理、不確定（Ａｇｅｎｔ，Ｉｎｄ
ｏｕｂｔ）」の状態に強制ロギングさせる。この状態
は、その後に中断が起こり、その結果、同期点マネジャ
６０Ｄが、同期点マネジャ６０Ａから段階２の決定を受
け取らなくなる場合、回復ファシリティ７０Ａからの回
復処理がその同期点処理を完了するのを待たなければな
らないことを意味する。次に、同期点マネジャ６０Ｄ
は、保護会話アダプタ６４Ｄにコンタクトして「コミッ
ト要求」の回答を与える。次に、保護会話アダプタ６４
Ｄは、体系的システム間フォーマットの「コミット要
求」を保護会話アダプタ６４Ａに送り（ステップ５４
１）、保護会話アダプタ６４Ａは、同期点マネジャ６０
Ａに「コミット要求」と回答する（ステップ５４２）。
上述したように、同期点マネジャ６０Ａは保護ファイル
・アダプタ６２Ａおよび６２Ｂから「コミット要求」を
受け取った（ステップ５３５Ａ）。この例では中断がな
いので、判断ブロック５４３からステップ５４４に進
み、同期点マネジャ６０Ａが回復ファシリティ７０Ａに
コンタクトして、ログ７２Ａを段階２の「開始側、コミ
ット済み（Ｉｎｉｔｉａｔｏｒ，ｃｏｍｍｉｔｔｅ
ｄ）」の状態に強制ロギングさせる（ステップ５４
４）。次に、同期点マネジャ６０Ａは、段階２の「コミ
ット済み」の決定で、登録された各保護資源アダプタを
呼び出す（図５Ｂ、ステップ５４５）。保護ファイル・
アダプタ６２Ａおよび６２Ｂは、上述したようにこのコ
ミットの決定を処理する（ステップ５４５Ａ）。保護会
話アダプタ６４Ａは、このコミット決定を受け取った
時、それが代理する保護会話、すなわち最初にアプリケ
ーション５６Ａによってアプリケーション５６Ｄに対し
て確立された会話を介して、体系的システム間フォーマ
ットの「コミット済み」コールを送る（ステップ５４
６）。保護会話アダプタ６４Ｄは、この「コミット」コ
ールを受け取り、同期点マネジャ６０Ｄに段階２の「コ
ミット」の決定を回答する（ステップ５４７）。

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

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

【００３６】図５５は、図２の実施例の代替実施例であ
り、図２と比較して説明するのが最適である。図２およ
び図５５では共に、アプリケーション環境、システム・
ファシリティおよび資源マネジャが分散されている。し
かし、図２では、１つの物理装置、システム５０Ａが、
複数のアプリケーション環境５２Ａ、５２Ｂ、５２Ｃ、
２つの資源マネジャ６３Ａ、６３Ｂ、回復ファシリティ
７０Ａおよび通信ファシリティ５７Ａを含んでいる。図
２では、システム制御プログラム５５Ａは、会話マネジ
ャ５３Ａおよび同期点マネジャ６０Ａ、６０Ｂ、６０Ｃ
を含んでいる。図２のシステム５０Ａは、メインフレー
ム・コンピュータであってよく、このタイプの構成は、
しばしば集中コンピュータ処理と呼ばれる。また、図２
では、システム５０Ａ内のアプリケーション環境が、通
信ネットワークを介してシステム５０Ｄ内のアプリケー
ション環境に接続されている。これとは対照的に、図５
５では、アプリケーション環境、システム・ファシリテ
ィおよび資源マネジャが、それぞれ別々の実計算機内に
ある。この構成は、分散コンピュータ処理と呼ばれる。
この環境では、システム９０Ａ、９０Ｂ、９０Ｃ、１１
０Ｅ、１１４Ｆ、１２０Ｇは、プログラム式ワークステ
ーションであって、図２のシステム５０Ａおよび５０Ｄ
に機能は類似しているが、サイズや性能は必ずしも類似
していない。図５５のシステムは、たとえばローカル・
エリア・ネットワーク（ＬＡＮ）などの通信ネットワー
クによって接続される。図５５のアプリケーション環境
９２Ａ、９２Ｂ、９２Ｃは、図２のアプリケーション環
境５２Ａ、５２Ｂ、５２Ｃと機能は同等である。しか
し、アプリケーション環境９２Ａ、９２Ｂ、９２Ｃはそ
れぞれ、別々のプログラム式ワークステーションに含ま
れている。図５５のシステム制御プログラム９５Ａ、９
５Ｂ、９５Ｃはそれぞれ、図２のシステム制御プログラ
ム５５Ａと機能的に同等である。システム制御プログラ
ム９５Ａ、９５Ｂ、９５Ｃはそれぞれ、（ａ）同期点マ
ネジャ６０Ａ、６０Ｂ、６０Ｃと機能的に同等な同期点
マネジャ１００Ａ、１００Ｂ、１００Ｃ、（ｂ）実行環
境制御プログラム６１Ａ、６１Ｂ、６１Ｃと機能的に同
等な実行環境制御プログラム９１Ａ、９１Ｂ、９１Ｃ、
（ｃ）保護会話アダプタ（ＰＣＡ）６４Ａ、６４Ｂ、６
４Ｃと機能的に同等な保護会話アダプタ１０４Ａ、１０
４Ｂ、１０４Ｃ、（ｄ）資源アダプタ（ＲＡ）６２Ａお
よび６２Ｂと機能的に同等な資源アダプタ１０２Ａ、１
０２Ｂ、１０２Ｃ、および１０３Ａ、１０３Ｂ、１０３
Ｃ、（ｅ）会話マネジャ５３Ａ、５３Ｂ、５３Ｃと機能
的に同等な会話マネジャ９３Ａ、９３Ｂ、９３Ｃ、およ
び通信ファシリティ５７Ａと機能的に同等な通信ファシ
リティ９７Ａ、９７Ｂ、９７Ｃを含む。しかし、図５５
の例では、通信ファシリティは各システム制御プログラ
ム９５Ａ、９５Ｂ、９５Ｃの一部であって、それ自体の
実行環境に含まれてはいない。また、図５５では、資源
マネジャ１１２Ｅおよび１１３Ｆは、図２の資源マネジ
ャ６３Ａおよび６３Ｂと機能的に同等であり、それらの
ファイル１１５Ｅ、１１７Ｆおよびログ１１６Ｅ、１１
８Ｆは、図２のファイル７８Ａ、７８Ｂおよびログ８０
０Ａ、８００Ｂと機能的に同等である。しかし、資源マ
ネジャ１１２Ｅおよび１１３Ｆは、それぞれ別々のプロ
グラム式ワークステーション上にある。図５５の回復フ
ァシリティ１２１Ｇおよびそのログ１２２Ｇは、図２の
回復ファシリティ７０Ａおよびそのログ７２Ａと機能的
に同等である。しかし、回復ファシリティ１２１Ｇは１
つのプログラム式ワークステーション内にある。図５５
のシステム５０Ｄは、図２のシステム５０Ｄと同一であ
り、このネットワークの融通性を示すために含めてあ
る。この環境での同期点処理の説明は、上記の同期点処
理の説明で、図２の番号を対応する図５５の番号に置き
換えることによって得られる。したがって、本発明は広
範囲なコンピュータ・システムおよびネットワークで実
施できる。

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

【００３８】具体的に言うと、図２８では、システム５
０Ａ内に、それぞれ資源マネジャ（プログラム）２６０
Ａ、２６０Ｂ、２６０Ｃを含む３つの同等な実行環境５
２Ｅ、５２Ｆ、５２Ｇがある。資源マネジャ２６０Ａ、
２６０Ｂ、２６０Ｃはそれぞれ、ＶＭ／ＳＰリリース６
オペレーティング・システムの共用ファイル・システム
（ＳＦＳ）資源マネジャ（“ＶＭ”はＩＢＭコーポレー
ションの登録商標）の拡張バージョンとそれに関連する
資源２６２Ａ、２６２Ｂ、２６２Ｃであることが好まし
い。さらに、各実行環境５２Ｅ、５２Ｆ、５２Ｇはま
た、図２３に示した回復ファシリティ７０Ａの機能を実
現するため、プログラム７０Ａ、７０Ｂ、７０Ｃをも含
む。共用ファイル・システムを含む実行環境内に各回復
ファシリティを置くことの利点は、その共用ファイル・
システムに、回復ファシリティが使用できるサービス、
すなわち通信サービスおよびタスク処理サービスが含ま
れることである。通信サービスは、通信プロトコル、割
込み処理、メッセージ管理を処理する。図２８のシステ
ム５０Ａでは、回復ファシリティ７０Ａは、当初、実行
環境５２Ｅが初期設定される際に回復ファシリティ・ロ
グ７２Ａに関連づけられる回復ファシリティとして、シ
ステム制御プログラムに識別される。これは、実行環境
５２Ｅの初期設定処理への入力としてあるパラメータを
指定することによって達成される。実行環境５２Ｅは、
システム制御プログラムに対してそれ自体を、回復ファ
シリティとして、かつシステム５０Ａ内での資源識別子
sync_point_logに対するすべての通信のターゲットとし
て識別する（資源識別子sync_point_logの説明について
は、「保護された資源を回復するためのログ名の交換」
を参照されたい。）。この資源識別子sync_point_log
は、システム５０Ａ内で一義的でなければならず、常に
１つの実行環境にしか関連づけることができない。この
実施例では、実行環境５２Ｅが回復ファシリティ・ログ
７２Ａを含む持久記憶域を定義し、その結果、実行環境
５２Ｅを指定すると、別の記憶域を指定するそれに勝る
指定がない場合、自動的にログ７２Ａが資源回復ログと
して暗示されることになる。

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

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

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

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

【００４３】上述したように、「作業ユニット」とは、
１つのアプリケーションから直接アクセス可能であり、
共通の同期点に参加する、資源の範囲である。たとえば
（図２において）、資源アダプタ６２Ａ、６２Ｂおよび
保護会話アダプタ６４Ａに結合された資源は、すべてア
プリケーション５６Ａから直接アクセス可能であり、し
たがって、すべて同一の作業ユニットを有することがで
きる。これらがすべてアプリケーション５６Ａによって
行われる関連する作業要求に用いられる場合、これらは
すべて同一の作業ユニットを有する。作業ユニット識別
子は、システム制御プログラム５５によって選択され、
それぞれの実行環境内で一義的である。この実施例で
は、システム制御プログラム５５Ａは、会話マネジャ５
３Ａと、各実行環境５２用の実行環境制御プログラム６
１を含む。限定ではなく例として示すと、実行環境制御
プログラム６１Ａは、ＶＭ／ＳＰリリース６オペレーテ
ィング・システム（“ＶＭ”はＩＢＭコーポレーショ
ン．の登録商標）の拡張ＣＭＳ構成要素でよい。この実
行環境制御プログラムは、アプリケーション５６Ａの実
行を制御し、上述したように、作業ユニット識別子を割
り当てる。したがって、作業ユニット識別子は、各実行
環境内で一義的である。アプリケーションは、複数の関
連する作業要求に対して同一の作業ユニットを使用し、
関連しない作業要求に対しては異なる作業ユニットを使
用する。「作業論理ユニット」識別子とは、関連する作
業要求に使用されるすべての資源に対するグローバルに
一義的な（ネットワーク全体を通じての）識別子であ
り、関連する作業要求をすべてカバーする。作業論理ユ
ニット識別子は、その作業要求を生成したシステムの回
復ファシリティ７０によって割り当てられ、この実施例
では、下記のものを含む。 （１）相互接続された１群のシステムを識別する、ネッ
トワーク識別子、（２）そのネットワーク内の１つの通
信ファシリティを識別する、システム識別子、（３）ロ
ーカルに一義的な要素をＬＵＷＩＤに与える、インスタ
ンス番号（たとえば、タイムスタンプを使用してよ
い）、（４）特定の同期点インスタンスを識別する、シ
ーケンス番号。たとえば、これは、“System Network A
rchitecture LU6.2 Reference: Peer Protocols, SC31-
6808 Chapter 5.3 Presentation Services - Sync Poin
t verbs”によって定義されるタイプのものである。同
期点マネジャ６０は、保護会話が作業ユニット内で使用
される場合、または作業要求が保護会話を必要としなく
とも、２段階コミット手順が必要な場合に、回復ファシ
リティから作業論理ユニット識別子（ＬＵＷＩＤ）を要
求する。ＬＵＷＩＤは、資源アダプタが同期点マネジャ
を呼び出すことによって要求することができ、またＬＵ
ＷＩＤがまだ獲得されていないがコミットのために必要
な場合には、コミット処理の始めに同期点マネジャがＬ
ＵＷＩＤを要求することができる。以下で詳細に説明す
るように、保護された会話や多数の保護された資源など
の保護された資源が作業ユニットで使用される時に、作
業ユニットがＬＵＷＩＤと関連づけられる。作業ユニッ
トは、複数のファイルと複数のファイル記憶場所の混合
物、他の保護された資源と他の参加する資源マネジャ、
およびある分散アプリケーションの異なる部分間での保
護された会話を含むことができる。保護された会話の場
合は、各アプリケーション・パートナが、この同一の保
護された会話とこのアプリケーションによって直接アク
セスされる他の資源とに（それぞれの実行環境内で）異
なる作業ユニットを割り当てる場合であっても、単一の
作業論理ユニットが、２つ以上のアプリケーション・パ
ートナの間に拡がる。したがって、ある保護された会話
に関連する各アプリケーション・パートナはそれぞれ、
それ自体の作業ユニットをローカルに割り当てて使用す
るが、２つ以上のアプリケーション・パートナの作業ユ
ニットは、同一の分散された作業論理ユニットを参照す
る。各実行環境は、他の実行環境で割り当てられた作業
ユニットの識別を知らず、異なる実行環境内の作業ユニ
ットが同一の識別子を有することは、偶然の一致によっ
てしか起こり得ないことに留意されたい。ＬＵＷＩＤで
はなく、上述の拡張された範囲をもつ作業ユニットを使
用して、ローカルなコミット範囲が定義される。という
のは、既存のアプリケーションが、最小限の変更で拡張
された機能の利益を享受できるからである。作業ユニッ
トからＬＵＷＩＤへの変更は面倒であり、既存のアプリ
ケーションを変更する必要がある。

【００４４】図６ないし図９は、同一のアプリケーショ
ン５６Ａ用の異なる作業ユニットおよび作業論理ユニッ
トと、それぞれ異なるシステム５０Ａおよび５０Ｄ内で
実行される複数のアプリケーション・パートナ５６Ａお
よび５６Ｄに関連づけられた複数の資源に拡がる別の作
業論理ユニットとを確立する処理を、実例によって示し
た図である。図７に示した例で、アプリケーション５６
Ａが開始され、実行環境制御プログラム６１Ａから作業
ユニット識別子Ｘを得る（ステップ９２８）。実行環境
制御プログラムは、各実行環境内で一義的な作業ユニッ
ト識別子を選択する責任を負う。次に、アプリケーショ
ン５６Ａは、実行環境５２Ａ内の資源アダプタ６２Ａに
対して作業要求を行って、資源７８Ａ内にある１ファイ
ルを更新してこの作業要求を作業ユニットＸの下で行う
ように、あるいはデフォルトにより、アプリケーション
５６Ａによって指定された「現作業ユニット」の下に割
り当てられるように指定する（ステップ９３０）。資源
アダプタが作業ユニットＸ用のＬＵＷＩＤを要求する場
合（判断ブロック９３５）、同期点マネジャ６０Ａは、
ＬＵＷＩＤがまだ割り当てられていなければ、回復ファ
シリティ７０Ａから作業ユニットＸをカバーするＬＵＷ
ＩＤを要求し、そのＬＵＷＩＤを作業ユニットＸと関連
づける。その後、同期点マネジャは、資源アダプタにこ
のＬＵＷＩＤを戻す（ステップ９３６）。図６に示した
例では、（資源アダプタ６２Ａを介してアクセスされ
た）資源７８Ａは、保護された会話ではないので、判断
ブロック９３７（図７）からステップ９３９に進み、資
源が更新される。資源アダプタ６２Ａが、まだ作業ユニ
ットＸのために登録されていない場合（判断ブロック９
３３）、資源アダプタ６２Ａを同期点マネジャ６０Ａに
登録する（ステップ９３４）。前述の例では、アプリケ
ーション５６Ａは、同一の作業ユニットの下でさらに別
の作業を行うことは望まず（判断ブロック９４０）、関
連しない新規の作業を行うことも望まない（判断ブロッ
ク９４１）ので、次のステップでは、アプリケーション
５６Ａがコミットを発行する（ステップ９４２）。これ
に応答して、同期点マネジャ６０Ａは、１段階コミット
手順を開始する（ステップ９４４）。ところで、アプリ
ケーション５６Ａは、他の関連しない作業要求を開始す
る前に作業ユニットＸのためにコミットを発行する必要
がないことに留意されたい（判断ブロック９４１）。こ
の特定の場合には、同期点マネジャは、１段階のコミッ
ト手順を実行するので、ＬＵＷＩＤは不要である。

【００４５】この例では、アプリケーション５６Ａは、
次に作業ユニットＸとは独立な作業を行うために、下記
の処理を開始する。アプリケーション５６Ａは、実行環
境制御プログラム６１Ａから新規の作業ユニットを要求
し、実行環境制御プログラム６１Ａは、作業ユニットＹ
を戻す（ステップ９２８）。次に、アプリケーション５
６Ａは、資源アダプタ６２Ｂを介して、作業ユニットＹ
の下で資源７８Ｂを更新する要求を行う（ステップ９３
０）。資源アダプタが作業ユニットＹ用のＬＵＷＩＤを
要求する場合（判断ブロック９３５）、同期点マネジャ
６０Ａは、回復ファシリティ７０ＡからＬＵＷＩＤを得
て、それを作業ユニットＹと関連づける（ステップ９３
６）。この時、作業ユニットＹ用の作業論理ユニット
は、資源マネジャ６３Ｂのみに拡がる。次に、資源７８
Ｂに対する更新を実施する（ステップ９３９）。資源ア
ダプタ６２Ｂは、まだ作業ユニットＹのために登録され
ていないので、同期点マネジャ６０Ａに登録される（ス
テップ９３４）。

【００４６】次に、アプリケーション５６Ａは、同一の
作業ユニットＹの下で、さらに別の作業たとえば他の資
源中のデータの変更を行うことを望む（判断ブロック９
４０）。図６に示した例では、この別の作業は保護され
た会話であり、この保護された会話が、分散アプリケー
ション・パートナ５６Ｄを介してシステム５０Ｄ内の資
源にアクセスするのに使用される。この例では、これが
新規の保護された会話の始まりである。すなわち、アプ
リケーション５６Ａは、作業ユニットＹの下で、アプリ
ケーション５６Ｄとの新規の保護された会話を開始する
（ステップ９３０）。保護会話アダプタ６４Ａは作業ユ
ニットＹ用のＬＵＷＩＤを要求するので、ＬＵＷＩＤが
まだ割り当てられておらず、作業ユニットに関連づけら
れていない場合、同期点マネジャは、回復ファシリティ
を呼び出し、保護会話アダプタにＬＵＷＩＤを戻す（ス
テップ９３６）（保護会話アダプタは、この会話を開始
する時にＬＵＷＩＤを必要とする（ステップ９４
７）。）。次に、判断ブロック９３７から判断ブロック
９４６に進む。これは新規の保護された会話であるの
で、会話マネジャ５３Ａは、保護された会話を開始し、
作業ユニットＹに関連するＬＵＷＩＤを通信ファシリテ
ィに送る（ステップ９４７）。この例では、アプリケー
ション・パートナ５６Ｄが異なるシステム内に常駐して
いるので、通信ファシリティ５７Ａを使用する。しか
し、アプリケーション・パートナが同一のシステム５０
Ａ内の別の実行環境、たとえば５２Ｂ内に常駐している
場合は、この通信機能は、システム制御プログラム５５
Ａの会話マネジャ５３Ａによって提供され、通信ファシ
リティ５７Ａは使用されないことに留意されたい。保護
会話アダプタ６４Ａが会話マネジャ５３Ａから制御を返
され、保護会話開始要求が成功したことが示された時、
保護会話アダプタ６４Ａは、同期点マネジャ６０Ａに登
録され（ステップ９４８）、アプリケーション５６Ａに
制御を返す。この時、アプリケーション５６Ａは、アプ
リケーション５６Ｄにメッセージを送って、資源７８Ｄ
の更新を要求する（ステップ９４９）。ただし、このメ
ッセージは、アプリケーション５６Ｄが開始されるま
で、システム５０Ｄ内にバッファされる。メッセージを
送った後、アプリケーション５６Ａはこれ以上行うべき
作業がない（判断ブロック９４０および９４１）ので、
作業ユニットＹに対するコミットを発行する（ステップ
９４２）。同期点マネジャ６０Ａが、２段階コミット手
順を開始する（ステップ９４４）。

【００４７】システム制御プログラム５５Ｄが、通信フ
ァシリティ５７Ｄを介して通信ファシリティ５７Ａから
会話開始要求を受け取った時（図８のステップ９６
０）、システム制御プログラム５５Ｄは、実行環境５２
Ｄを開始する（ステップ９６２）。保護会話アダプタ６
４Ｄは、実行環境５２Ｄ用の新規の作業ユニットＺを獲
得し、この実行環境５２Ｄ内で、アプリケーション５６
Ｄが実行環境制御プログラム６１Ｄから実行されること
になる。この作業ユニットは、実行環境５２Ｄ内で一義
的である。また、保護会話アダプタ６４Ｄは、開始され
た会話で受け取ったＬＵＷＩＤをこの新規の作業ユニッ
トに関連づけるよう同期点マネジャに指令し、その後、
この新規の作業ユニットの下で同期点マネジャ６０Ｄに
登録される（ステップ９６６）。（ステップ９４７での
会話開始要求の流れは、保護会話アダプタ６４Ａから、
会話マネジャ５３Ａ、通信ファシリティ５７Ａ、通信フ
ァシリティ５７Ｄ、会話マネジャ５３Ｄを経て、保護会
話アダプタ６４Ｄへと向かう。）その後、アプリケーシ
ョン５６Ｄが開始される。

【００４８】次に、アプリケーション５６Ｄは、ステッ
プ９３０Ｄで作業要求を行う。この例では、この最初の
作業要求は、会話上でメッセージを受け取ることであ
る。この保護された会話はすでにＬＵＷＩＤを有してい
るので、判断ブロック９３５Ｄから判断ブロック９３７
Ｄに進む。これは、保護された会話であるが、新規のア
ウトバウンドな保護された会話ではない（すなわち、新
規の保護された会話の開始ではない）ので、判断ブロッ
ク９３７Ｄおよび９４６Ｄからステップ９４９Ｄに進
み、メッセージをアプリケーション５６Ｄが受け取る。

【００４９】図６以降に示した例では、保護された会話
は、アプリケーション５６Ｄに、追加の作業、たとえば
（資源アダプタ６２Ｄを介して）資源７８Ｄ内のファイ
ルの更新を行わせ、したがって判断ブロック９４０Ｄか
らステップ９３０Ｄに進み、アプリケーション５６Ｄ
が、作業ユニットＺを使用して資源７８Ｄを更新するよ
うにとの作業要求を行う。資源アダプタがＬＵＷＩＤを
要求する場合（判断ブロック９３５Ｄ）、同期点マネジ
ャは資源アダプタにＬＵＷＩＤを戻す（ステップ９３６
Ｄ）。ステップ９６６ですでにＬＵＷＩＤが割り当てら
れ、作業ユニットに関連づけられているので、回復ファ
シリティを呼び出してＬＵＷＩＤを割り当てる必要はな
い。この作業要求は、保護された会話資源を使用しない
ので、判断ブロック９３７Ｄからステップ９３９Ｄに進
み、作業要求に従って資源７８Ｄを更新する。資源アダ
プタ６２Ｄはまだ登録されていないので、判断ブロック
９３３Ｄからステップ９３４Ｄに進み、資源アダプタ６
２Ｄが同期点マネジャ６０Ｄに登録される。この時点で
アプリケーション５６Ｄは、アプリケーション５６Ａが
いつこの作業のコミットを要求するかを決定する必要が
ある。これは、アプリケーション５６Ｄにより、保護さ
れた会話上で（作業要求を）受け取ることによって、達
成される。アプリケーション５６Ａがコミットを発行済
みの時には、アプリケーション５６Ｄは、戻りコードTa
ke_Syncpointを得る。したがって、判断ブロック９４０
Ｄからステップ９３０Ｄに進み、アプリケーション５６
Ｄが、作業ユニットＺの下で保護された会話上で受取り
を発行する。保護会話アダプタ６４ＤにはＬＵＷＩＤが
不要であり（判断ブロック９３５Ｄ）、この作業要求は
保護された会話を使用し（判断ブロック９３７Ｄ）、こ
の保護された会話は新規のアウトバウンドな会話ではな
い（判断ブロック９４６Ｄ）ので、受取りが行われる
（ステップ９４９Ｄ）。アプリケーション５６Ｄには、
作業ユニットＺ上で行うべき追加の作業がないので、判
断ブロック９４０Ｄから判断ブロック９４１Ｄに進む。
アプリケーション５６Ａがコミットを発行済みの時は
（判断ブロック９４１Ｄ）、アプリケーション５６Ｄ
は、受取り時に戻りコードTake_Syncpointを得て、コミ
ットを発行する（ステップ９４２Ｄ）。次に、同期点マ
ネジャ６０Ｄが、コミット手順を開始する（ステップ９
４４Ｄ）。この例では、これで作業ユニットＺに関連す
る作業要求は完了し、判断ブロック９５０Ｄからアプリ
ケーション５６Ｄの終わりに進む。この時、アプリケー
ション５６Ａは、同期点マネジャ６０Ａから制御を返さ
れ、終了する。

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

【００５１】コミット手順のための資源の登録 図１０は、資源の自動的かつ総称的な登録を示す図であ
る。この登録は、保護された資源を同期点マネジャ（Ｓ
ＰＭ）６０に対して識別するファシリティである。それ
ぞれのアプリケーション実行環境５２で、資源アダプタ
６２／６４および同期点マネジャ６０は、アプリケーシ
ョン５６のために登録に参加する。この実施例では、資
源マネジャ６３と資源７８は、この環境の外部にある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００６６】図１２に示した例では、アプリケーション
５６Ａが複数の作業要求を行う。これらの要求は、シス
テム５０Ａによって並列に処理され、複数の資源マネジ
ャと資源を必要とする。この例について具体的に言う
と、アプリケーション５６Ａは、２つの作業ユニットＣ
およびＤに対して８つの作業要求を行い、これらの要求
がシステム５０Ａによって並列に処理される。コミット
点が図１３に示されているが、作業ユニットＣのコミッ
ト点は時刻１９と４４にあり、作業ユニットＤのコミッ
ト点は時刻３３にある。図１３の時間単位は、シーケン
スを表す論理的クロック単位である（物理的クロック単
位ではない）。図１３において、同一の時刻に発生する
事象は、互いの順序がどうでもよいことを暗示してい
る。

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

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

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

【００７０】アプリケーション５６Ａが作業ユニットＣ
を使用してその最初のレコードであるメッセージ“star
t security event（安全保護事象開始）”を書き込む時
（図１４のステップ６１２）、資源マネジャ６３Ａは、
その資源アダプタ６２Ａを介してアプリケーション実行
環境５２Ａ内に登録される。同期点マネジャ６０Ａは、
図１２の表１２６内で作業ユニットＣの下に、資源マネ
ジャ６３Ａ用の登録エントリを作成する（ステップ６１
４）。このエントリは、出口ルーチン名と、資源アダプ
タ６２Ａが登録の際に渡した特別なプライベート値とを
含む、資源アダプタ６２Ａの出口に渡すべきパラメータ
のリストを含む。資源アダプタの出口は、この特別な値
を使用して、会話１用の制御ブロックを探し出すことが
できる。

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

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

【００７３】アプリケーション５６Ａが、作業ユニット
Ｄの下で、時刻１と時刻７に作業要求を行う時、資源ア
ダプタ６２Ａおよび６２Ｂの両方が、同期点マネジャ６
０Ａに登録され、同期点マネジャ６０Ａは、表１２７に
登録エントリ６３Ａおよび６３Ｂを追加する。

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

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

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

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

【００７８】この登録変更の例は、図１１の流れ図に詳
細に示されている。ステップ５８０の作業要求が、その
保護された資源に関する最初の要求であり、この要求が
読取り専用である場合、判断ブロック５８１から判断ブ
ロック５８２に進む。資源アダプタ６２Ａは、それが登
録されている各作業ユニットの下で各資源用の内部標識
を保存していることに留意されたい。この標識が、判断
ブロック５８１で検査される。この資源は、保護された
会話ではないので、判断ブロック５８２から判断ブロッ
ク５８３に進む。この作業は読取り専用なので、判断ブ
ロック５８３からステップ５８５に進む。ステップ５８
５で、対応する資源アダプタ６２Ａが、読取り専用資源
として登録される。ステップ５８０の次の作業要求が、
同一の作業ユニットの下での同一の資源への書込みまた
は更新である場合、資源アダプタ６２Ａは、読取りモー
ドとしてであるとはいえ、ステップ５８５ですでに登録
されているので、判断ブロック５８１から判断ブロック
５８４に進む。この資源は保護された会話ではないの
で、判断ブロック５８４から判断ブロック５８６に進
み、この要求は更新モード用なので、判断ブロック５８
６から判断ブロック５８８に進む。次に、判断ブロック
５８８からステップ５９０に進み、資源アダプタ６２Ａ
（ステップ５８５ですでに読取りモードとして登録済
み）は、同期点マネジャ６０Ａにおけるその登録を書込
みモードに変更する。図１１によれば、この資源に対す
るある作業ユニットの下での最初の作業要求が書込みモ
ードである場合には、資源アダプタ６２Ａが、ステップ
５９２で書込みモードとして登録されることに留意され
たい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１０７】Ｂ側の同期点マネジャは、保護会話アダプ
タを介してＣ側の同期点マネジャからのメッセージ“re
quest commit”を受け取る。メッセージ“request comm
it”だけが受け取られたので、次のステップで、回復フ
ァシリティに状態レコードを送って、同期点の状態を
「代理、不確定」Ｂ８（図１８）に更新する。状態レコ
ードが回復ファシリティのログに成功裡に書き込まれる
と、Ｂ側の同期点マネジャは、Ａからのメッセージ“pr
epare”に応答して、保護会話アダプタを介してＡ側の
同期点マネジャにメッセージ“request commit”を送
る。

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

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

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

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

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

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

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

【０１１５】作業要求に応答して（図２９のステップ６
５１）、アダプタ６２Ａ、６２Ｇおよび６４Ａが、同期
点マネジャ６０に登録される（ステップ６５３）。同期
点マネジャ６０は、登録オブジェクト１６２Ａ、１６２
Ｂおよび１６２Ｃを生成し、参加する資源（共用ファイ
ル資源マネジャ６３Ａ、ＳＱＬ資源マネジャ６３Ｇおよ
びシステム５０Ｂ内の保護された会話のパートナ）の識
別子を入れる。また、この登録情報は、資源アダプタ出
口ルーチン名、資源および保護された会話の製品識別
子、および各資源のエラー・ブロックの必要な長さを含
む。資源アダプタ出口ルーチン名は、この例のシステム
５０Ａ内のシステム制御プログラムなどの製品が、２タ
イプの資源を所有する時に必要である。製品識別子と資
源アダプタ出口ルーチン名は共に、参加する資源のタイ
プ、たとえば共用ファイル資源マネジャ、ＳＱＬ資源マ
ネジャ、または保護会話マネジャを識別する。１実行環
境内の同一タイプの資源の資源アダプタはすべて、シス
テム５０Ａのページング・セットを縮小するために、同
一のプールからのエラー・ブロックを使用する（図解は
図３１を参照されたい）。ある資源がステップ６５３
（図２９）で、他のタイプの資源と同一のサイズのエラ
ー・ブロックを要求する場合、そのエラー・ブロック・
プールがこれら２つの資源によって共用される。

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

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

【０１１８】ステップ６５５（図２９）で、同期点マネ
ジャ６０は、各資源アダプタ（図３２の６２Ａ、６２Ｇ
および６４Ａ）に、登録オブジェクト１６２Ａないし１
６２Ｃにセーブされたそのエラー・ブロック（オブジェ
クト６６Ａないし６６Ｃ）のアドレスを渡す。登録オブ
ジェクト１６２Ａないし１６２Ｃは、資源アダプタが登
録された時、各資源アダプタごとに作成されている（ス
テップ６５３）。障害がない場合、ステップ６５４から
のコミットが完了し、その後同期点マネジャ６０は、更
新がコミット済みであることをアプリケーション５６Ａ
に報告する（ステップ６５７）。

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

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

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

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

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

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

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

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

【０１２７】既知の同期点参加者のログ名に関する情報
は、その他の同期点情報とは分離または区分してロギン
グされる。このログ名情報は、ログ名ログ７２Ａ２（図
１９）に記録され、残りの情報は、同期点ログ７２Ａ１
に記録される。

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

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

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

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

【０１３２】３つの同期点の範囲が、図３３に含まれて
いる。第１の範囲は、単一のアプリケーション環境５２
Ａ（および同期点マネジャ）を含み、２つの資源マネジ
ャ６３Ａおよび６３Ｅを使用する。第２の同期点の範囲
は、３つのアプリケーション環境５２Ｂ、５２Ｄおよび
５２Ｆを含み、これらはそれぞれ、様々な参加する資源
マネジャ（５２Ｂには６３Ｂ、５２Ｄには６３Ｄと６３
Ｅ、５２Ｆには６３Ｆと６３Ｇ）を含む。これを図３４
の同期点ツリーに示す。

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

【０１３４】この会話開始を受け取ると、通信ファシリ
ティ５７Ａは、その交換ログ名状況テーブル（ＥＬＳ
Ｔ）２０８Ａを探索して、現経路である経路Ｂ用のエン
トリを求める（図２０のステップ８３３）。交換ログ名
状態テーブルの経路Ｂ用のエントリは、状況０によっ
て、システム５０Ａが最後に開始されて以降にこの経路
上には保護された会話が発生していないことを示す。し
たがって（図２０の判断ステップ８３４）、交換ログ名
状態テーブルの経路Ｂ用のエントリ２０８Ａが、状況１
に変更され（図２０のステップ８３６）、会話開始メッ
セージ５０５（図１９）が代行受信され、この会話は、
通信ファシリティ５７Ａによって中断される（図２０の
ステップ８３７）。次に、通信ファシリティ５７Ａ（図
１９）は、ローカルの回復ファシリティ７０Ａへの制御
経路上にメッセージ２００（図１９）を送って、この会
話開始が通信ファシリティ５７Ａに受諾されないうち
に、経路Ｂに対してログ名交換を初期設定すべきである
と指示する（図２０のステップ８３８）。

【０１３５】回復ファシリティ７０Ａは、このメッセー
ジを受け取り（図２１のステップ８５０）、その後、Ｅ
ＬＳＴ２０７Ａの経路Ｂ用のエントリを状況１にセット
して、経路Ｂ用のログ名交換が進行中であることを示す
（図２１のステップ８５１）。次に、回復ファシリティ
７０Ａ（図１９）は、通信経路Ｂ上で保護されない会話
を開始する（図１９のメッセージ２０２）。この会話は
「保護されていない」ので、通信ファシリティによる代
行受信の可能性はない。というのは、保護された会話だ
けが、ログ名交換手順を強制するために代行受信がある
かどうか監視されるからである。システム５０Ａからシ
ステム５０Ｄへの通信ファシリティを介する経路指定
は、上記と同様である。

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

【０１３７】回復ファシリティ７０Ｄは、通信線２０２
に沿って回復ファシリティ７０Ａから送られたログ名情
報を受け取った後に（図２２のステップ８７０）、経路
Ｂに関するＥＬＳＴ２０７Ｄを状況１にセットし、ロー
カル通信ファシリティ５７Ｄは、メッセージ２０３（図
１９）を介して、やはり経路Ｂに関するＥＬＳＴ２０８
Ｄを状況１に変更するよう通知される（図２２のステッ
プ８７１）。図２０のステップ８４１、図２０のステッ
プ８４２、図２０のステップ８４３および図２０のステ
ップ８４６は、通信ファシリティ内のＥＬＳＴを変更す
るステップを示す。回復ファシリティ７０Ｄは、メッセ
ージ２０２（図１９）から、回復ファシリティ７０Ａの
ログ名が新規でなく（図２２の判断ステップ８７２）、
それ自体のログも新規ではない（図２２の判断ステップ
８７６）と判定し、最後に、メッセージ２０２（図１
９）内のログ名が、回復ファシリティ７０Ｄのログ名ロ
グ７２Ｄ２の経路Ｂに関するエントリに記憶されたログ
名と一致すると判定する。したがって、ＥＬＳＴ２０７
Ｄは、経路Ｂに関して状況２にセットされ、ローカル通
信ファシリティ５７Ｄは、メッセージ２０３（図１９）
を介して、やはり経路Ｂに関するＥＬＳＴ２０８Ｄを状
況２にセットするよう通知される（図２２のステップ８
７９、図２０のステップ８４１および図２０のステップ
８４２）。その後、回復ファシリティ７０Ｄは、回復フ
ァシリティ７０Ａに正常に応答して（図１９のメッセー
ジ２０６）、そのログ７２Ｄのログ名とそれが新規であ
るか否かの標識を送る（図２２のステップ８８２）。

【０１３８】回復ファシリティ７０Ａは、この正常な応
答を受け取り（図２１の判断ステップ８５３）、回復フ
ァシリティ７０Ａのログ７２Ａが新規ではなく（図２１
の判断ステップ８５７）、メッセージ２０６（図１９）
によれば回復ファシリティ７０Ｄのログ７２Ｄが新規で
はないので（図２１の判断ステップ８５８）、回復ファ
シリティ７０Ａは、回復ファシリティ７０Ｄからメッセ
ージ２０６（図１９）中で送られたログ７２Ｄの名前
と、ログ７２Ａ２の経路Ｂに関するエントリに記憶され
たログ名の突合せに成功し（図２１の判断ステップ８５
９）、したがって、ＥＬＳＴ２０７Ａの経路Ｂに関する
エントリを状況２にセットし、メッセージ２０４（図１
９）を介して、ローカル通信ファシリティ５７Ａに、Ｅ
ＬＳＴ２０８Ａを状況２にセットするよう通知する（図
２１のステップ８６２）。その後、回復ファシリティ７
０Ａは、経路Ｂ上の回復ファシリティ７０Ｄとの会話の
正常終了を行って（図２１のステップ８６３）、回復フ
ァシリティ７０Ｄが、正常に完了できるようにする（図
２２の判断ステップ８８３と図２２のステップ８８
６）。通信ファシリティ５７Ａが、経路Ｂの状況をＥＬ
ＳＴ２０８Ａに記入するよう伝えるメッセージ２０４
（図１９）を受け取ると（図２０のステップ８４１と図
２０のステップ８４２）、代行受信され中断された経路
Ｂ上の会話５０５は、その初期設定を完了できるように
なる（図２０の判断ステップ８４３、図２０のステップ
８４５および図２０のステップ８４６）。この完了によ
って、この会話の中断状態が解消され、この会話は、そ
の宛先である通信ファシリティ５７Ｄに向かって流れる
ことができるようになる。目的の通信ファシリティ５７
Ｄで保護会話到着事象（図２０のステップ８３２）があ
り、その後、ＥＬＳＴ２０８Ｄ内の経路エントリを検索
して、状況が２であることが示され（図２０の判断ステ
ップ８３４）、この会話開始が、アプリケーション５６
Ｄに正常に流れることができるようになる（図２０のス
テップ８３９）。

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

【０１４０】目的の回復ファシリティ７０Ｄが、メッセ
ージ２０２（図１９）中で送られたログ名と経路Ｂに関
してログ７２Ｄ２に記憶されたログ名が一致しないこと
を見つけた場合（図２２の判断ステップ８７７）、メッ
セージ２０６（図１９）中でエラーが戻され（図２２の
ステップ８８０）、ＥＬＳＴ２０７Ｄは、経路Ｂに関し
て状況０にセットされ、通信ファシリティ５７Ｄは、メ
ッセージ２０３（図１９）を介して、同様にそのＥＬＳ
Ｔ２０８Ｄを変更するよう通知される（図２０のステッ
プ８４１、図２０のステップ８４２および図２２のステ
ップ８８１）。

【０１４１】原始ログ７２Ａが新規であり（図２２の判
断ステップ８７２）、ログ７２Ｄも新規である（図２２
の判断ステップ８７３）ことを示すメッセージ２０２
（図１９）を、回復ファシリティ７０Ｄが受け取った場
合、ログ７２Ａの新規のログ名が、経路Ｂに関するログ
７２Ｄ２に記憶され（図２２のステップ８７８）、前記
と同様に正常な完了が継続する（図２２のステップ８７
９、図２２のステップ８８２など）。

【０１４２】原始ログ７２Ａは新規であるが（図２２の
判断ステップ８７２）、ログ７２Ｄは新規でない（図２
２の判断ステップ８７３）ことを示すメッセージ２０２
（図１９）を、回復ファシリティ７０Ｄが受け取り、か
つ同期点ログ７２Ｄ１から、経路Ｂに関して未解決の同
期点回復（未処理の再同期化）が存在すると判定された
（図２２の判断ステップ８７４）場合には、システム５
０Ｄの操作員に対してエラー・メッセージが生成され
（図２２のステップ８７５）、メッセージ２０６（図１
９）中で、回復ファシリティ７０Ａにエラーが戻され
（図２２のステップ８８０）、ＥＬＳＴ２０７Ｄは状況
０に変更され、ローカル通信ファシリティは、メッセー
ジ２０３（図１９）を介して、ＥＬＳＴ２０８Ｄを状況
０に変更するよう通知され（図２２のステップ８８１、
図２０のステップ８４１、図２０のステップ８４２）、
その後、リターンする（図２２のステップ８８２）。

【０１４３】回復ファシリティ７０Ａが、回復ファシリ
ティ７０Ｄからのメッセージ２０６（図１９）中でエラ
ー応答を検出し（図２１の判断ステップ８５３）、かつ
未処理の再同期化が存在するとログ７２Ａ１で示される
（図２１の判断ステップ８５４）場合には、システム５
０Ａの操作員にメッセージが送られ（図２１のステップ
８５５）、ＥＬＳＴ２０７Ａおよび２０８Ａは、状況０
に変更される（図２１のステップ８５６）。ＥＬＳＴ２
０８Ａは、通信ファシリティ５７Ａに対するメッセージ
２０４（図１９）を介して状況０に変更される（図２０
のステップ８４１と図２０のステップ８４２）。この結
果、代行受信された会話を開始したアプリケーション５
６Ａにエラーが戻され、会話は拒絶される（図２０のス
テップ８４４）。未処理の再同期化がない場合は（図２
１の判断ステップ８５４）、操作員にメッセージは送ら
れない（図２１の判断ステップ８５４）。

【０１４４】回復ファシリティ７０Ｄからのメッセージ
２０６（図１９）中で、新規のログ名が回復ファシリテ
ィ７０Ａに戻されると（図２１の判断ステップ８５
７）、このログ名はログ７２Ａ２の経路Ｂに関するエン
トリに記憶され（図２１のステップ８６１）、２のＥＬ
ＳＴ状況が経路Ｂに関してセットされ（図２１のステッ
プ８６２）、通信ファシリティ５７Ａは、この会話を中
断から解放する（図２０のステップ８４１、図２０の判
断ステップ８４３および図２０のステップ８４５）。

【０１４５】回復ファシリティ７０Ｄからメッセージ２
０６（図１９）中で戻されたログ名が、経路Ｂに関して
ログ７２Ａ２に記憶された名前と一致しないことを回復
ファシリティ７０Ａが検出するか（図２１の判断ステッ
プ８５８および８５９）、あるいはログ７２Ｄ２に対し
て新規のログ名が戻され（図２１の判断ステップ８５
８）、経路Ｂに関して必要な未処理の再同期化が存在す
るとログ７２Ａ１から回復ファシリティ７０Ａが決定し
た（図２１の判断ステップ８６０）場合は、回復ファシ
リティ７０Ａは、メッセージ２０２および２０６（図１
９）をサポートした会話を異常終了させることによっ
て、回復ファシリティ７０Ｄに重大なエラーが存在する
ことを知らせ（図２１のステップ８６４）、システム５
０Ａの操作員に対するメッセージを生成し（図２１のス
テップ８６５）、ＥＬＳＴ２０７Ａの状況をリセット
し、通信ファシリティ５７Ａに対するメッセージ２０４
（図１９）を介して、ＥＬＳＴ２０８Ａの状況をもリセ
ットする（図２１のステップ８６６）。この結果、代行
受信された会話を開始したアプリケーション５６Ａにエ
ラーが戻され、会話は拒絶される（図２０のステップ８
４４）。

【０１４６】すべての場合において、回復ファシリティ
７０Ｄは、回復ファシリティ７０Ａに応答（図２２のス
テップ８８２）した後であっても、会話の異常終了を通
じて回復ファシリティ７０Ａから送られるエラー（図２
１のステップ８６４）を検出することができる（図２２
の判断ステップ８８３）。それが発生した時、ＥＬＳＴ
２０７Ｄの経路Ｂのエントリと、通信ファシリティ５７
Ｄへのメッセージ２０３（図１９）（および図２０のス
テップ８４１と図２０のステップ８４２）を介してＥＬ
ＳＴ２０８Ｄの経路Ｂのエントリとが、状況０にリセッ
トされ（図２２のステップ８８４）、ログ７２Ｄ２の経
路Ｂに関するログ名エントリが消去され（図２２のステ
ップ８８５）、以前のステップ８７８（図２２）を否定
する。

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

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

【０１４９】さらに、通信ファシリティ５７Ａ、回復フ
ァシリティ７０Ａまたはそれらの間の制御経路の障害の
後に、アプリケーション５６Ｄが、アプリケーション環
境５２Ａ内のアプリケーション５６Ａに対する経路Ｂに
沿った会話を開始するものと仮定する。通信ファシリテ
ィ５７Ｄ内の交換ログ名状況テーブルは、経路Ｂの状況
が２であり、通信ファシリティ５７Ｄ内のテーブルが、
システム５０Ａに障害が発生した際にはリセットされな
かったことを示しているので、この会話は、通信ファシ
リティ５７Ｄによって代行受信されない。ところが、こ
の会話が通信ファシリティ５７Ａまで達すると、保護会
話到着事象があり（図２０のステップ８３２）、ＥＬＳ
Ｔ２０８Ａを検索すると、状況が０であることが示され
（図２０の判断ステップ８３４）、通信ファシリティ５
７Ａはこの会話の経路指定を代行受信し（図２０のステ
ップ８３６と図２０のステップ８３７）、したがって通
信ファシリティ５７Ａは、回復ファシリティ７０Ａに対
するメッセージ２００（図１９）によって、ログ名交換
を要求する（図２０のステップ８３８）。これによっ
て、前述のログ名交換処理が繰り返される。このログ名
交換がその交換処理中に回復ファシリティ７０Ｄ中で受
け取られた時、回復ファシリティ７０Ｄ内の交換ログ名
状況テーブルは、経路Ｂのエントリの状況が２であるこ
とを示す。したがって、回復ファシリティ７０Ｄは、通
信ファシリティ５７Ｄに、経路Ｂに関して交換ログ名状
況テーブルを変更するよう通知することはしない。この
ような交換は不要である。この点が、このログ名交換処
理における、上述の障害発生前の処理との唯一の相違点
である。ログ名交換処理が完了した後に、回復ファシリ
ティ７０Ａは、メッセージ２０４（図１９）を介して通
信ファシリティ５７Ａに、経路Ｂの状況を０から２に変
更するよう通知する。その後、通信ファシリティ５７Ａ
は、経路Ｂに沿った会話を解放し、この会話がアプリケ
ーション５２Ａに流れるようになる。

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

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

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

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

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

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

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

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

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

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

【０１６０】図２６の残りの部分には、ログ名交換を開
始する時を決定するために、資源マネジャ６３Ａ（図２
３）が実行するアルゴリズムが示されている。資源識別
子objectを最初に受け取った時（ステップ２２６）、資
源マネジャ６３Ａは、ログ名ログ８００Ａ２を検索し
て、資源アダプタ６２Ａ（図２３）から渡された回復情
報に含まれる資源識別子log_name_logによって識別され
る回復ファシリティ７０Ａ用のエントリがあるか否かを
判定する（図２６のステップ２３０）。この資源マネジ
ャは、ログ名ログ８００Ａ２（図２３）を検索するの
に、資源アダプタから受け取った資源識別子log_name_l
ogを使用する。エントリがない場合、資源マネジャ６３
Ａはログ名交換を開始する（図２６のステップ２３
２）。ステップ２３０で、回復ファシリティ７０Ａ（図
２３）用のエントリが見つかった場合、資源マネジャ６
３Ａは、フラグexchange_doneがセットされているか否
かを判定する（図２６のステップ２３４）。フラグexch
ange_doneは、ログ名交換が成功した時にセットされ、
資源マネジャが異常終了するかまたは正常に遮断される
まで、セットされたままである。回復ファシリティとの
会話を開始するのに失敗したために、資源マネジャがロ
グ名を交換できない場合には、資源マネジャは、その資
源アダプタによって開始された会話を打ち切る。フラグ
exchange_doneがセットされていない場合、資源マネジ
ャ６３Ａ（図２３）は、ステップ２３２（図２６）でロ
グ名交換を開始する。しかし、フラグexchange_doneが
セットされている場合には、資源マネジャ６３Ａ（図２
３）は、資源アダプタ６２Ａから送られたログ名を、前
記のエントリ内のログ名と比較する（図２６のステップ
２３６）。これら２つのログ名が同一である場合には、
資源マネジャはログ名交換を開始しないが（図２６のス
テップ２４２）、異なる場合には、資源マネジャ６３Ａ
（図２３）は、ステップ２３２（図２６）でログ名交換
を開始する。前述のアルゴリズムは、資源マネジャがい
ずれかの回復ファシリティに関連する資源アダプタと初
めて通信する際に、その回復ファシリティに関してログ
名が交換されることを保証する。また、このアルゴリズ
ムは、その後に回復ファシリティ７０Ａ（図２３）用の
ログ名が変更される時、ログ名が交換されることを保証
する。後者の場合、資源マネジャ６３Ａが資源アダプタ
から回復ファシリティのログ７２Ａの新しい名前を得る
場合であってもこのログ名交換は必要である。というの
は、回復ファシリティ７０Ａのログ名ログを資源マネジ
ャ６３Ａのログ名ログと同期させなければならず、回復
ファシリティ７０Ａに資源マネジャのログ８００Ａのロ
グ名を与えることが必要だからである。

【０１６１】ステップ２３２（図２６）の、資源マネジ
ャ６３Ａ（図２３）と回復ファシリティ７０Ａの間での
ログ名交換は、図２７にさらに詳しく示されており、以
下のステップを含む（ログ７２Ａがそのログであると仮
定する） １．図２７のステップ２４３。資源マネジャ６３Ａ（図
２３）が、資源アダプタ６２Ａから得た資源識別子log_
name_logを使用して、回復ファシリティ７０Ａとの会話
２５０を開始する。 ２．図２７のステップ２４３。資源マネジャ６３Ａ（図
２３）が、回復ファシリティ７０Ａに資源マネジャ６３
Ａを一義的に識別するobject資源識別子を送る。 ３．図２７のステップ２４４。資源マネジャ６３Ａ（図
２３）が、回復ファシリティ７０Ａにログ８００Ａのロ
グ名を送る。 ４．図２７のステップ２４５。回復ファシリティ７０Ａ
（図２３）が、資源マネジャ８００Ａのログ名で、ログ
名ログ７２Ａ２を更新する。 ５．図２７のステップ２４６。回復ファシリティ７０Ａ
（図２３）が、資源マネジャ６３Ａに応答を戻して、ロ
グ７２Ａのログ名を与える。 ６．図２７のステップ２４７。資源マネジャ６３Ａ（図
２３）が、ログ７２Ａの名前でログ名ログ８００Ａ２を
更新する。 ７．図２７のステップ２４８。資源マネジャ６３Ａ（図
２３）が、ログ名ログ８００Ａ２内のフラグexchange_d
oneをセットする。

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

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

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

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

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

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

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

【０１６９】図３３は、システム５０Ａ、５０Ｄおよび
５０Ｆに関係する、様々な回復状況を示す図である。各
アプリケーション実行環境５２Ａ、５２Ｂ、５２Ｄ、５
２Ｆ、５２Ｇは、資源回復を調整するためにそれぞれ同
期点マネジャ６０Ａ、６０Ｂ、６０Ｄ、６０Ｆ、６０Ｇ
（図示せず）を使用するアプリケーション５６Ａ、５６
Ｂ、５６Ｄ、５６Ｆ、５６Ｇ（図示せず）を実行する。
各同期点マネジャは、そのシステム内の回復ファシリテ
ィを使用して、同期点と、障害を発生している同期点か
らの回復に必要なログ名ログとを管理する。たとえば、
アプリケーション環境５２Ａおよび５２Ｂ内の同期点マ
ネジャは、回復ファシリティ７０Ａを使用して、同期点
回復情報を回復ファシリティ・ログ７２Ａに書き込む。
資源マネジャ６３Ａ、６３Ｂ、６３Ｄ、６３Ｅ、６３
Ｆ、６３Ｇは、それぞれ、それ自体の同期点と、ログ名
ログ８００Ａ、８００Ｂ、８００Ｄ、８００Ｅ、８００
Ｆ、８００Ｇとを管理する。この例では、同期点の範囲
が矢印付きの実線で示されている。同期点はいずれの参
加者によって開始されることもでき、同期点の範囲は動
的であるが、図を簡単にするためにこの図は静的なもの
である。図の静的な場合では、同期点は、アプリケーシ
ョン環境５２Ｂから５２Ｄへさらに５２Ｆへと、関連す
る同期点マネジャおよび保護会話アダプタ（図示せず）
を介し、実線の通信経路８０１および８０２を経て流
れ、またアプリケーション環境５２Ａ、５２Ｂ、５２
Ｄ、５２Ｆ、５２Ｇから、関連する同期点マネジャおよ
び保護会話アダプタを介し、それぞれ実線の通信経路８
０３Ａ−１、８０３Ａ−２、８０３Ｂ、８０３Ｄ、８０
３Ｅ、８０３Ｆ、８０３Ｇを経て、資源マネジャ６３
Ａ、６３Ｂ、６３Ｄ、６３Ｅ、６３Ｆ、６３Ｇへと流れ
る。

【０１７０】３つの同期点の範囲が、図３３に含まれて
いる。第１の範囲には、同期点マネジャ６０Ａを含む単
一のアプリケーション環境５２Ａが含まれ、２つの資源
マネジャ６３Ａおよび６３Ｅを使用する。第２の同期点
の範囲には、３つのアプリケーション環境５２Ｂ、５２
Ｄおよび５２Ｆが含まれ、これらはそれぞれ、様々な参
加資源マネジャ（５２Ｂには６３Ｂ、５２Ｄには６３Ｄ
と６３Ｅ、５２Ｆには６３Ｆと６３Ｇ）を含む。これを
図３４の同期点ツリーに示す。第３の同期点の範囲に
は、アプリケーション環境５２Ｇと資源マネジャ６３Ｇ
が含まれる。

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

【０１７２】同期点は、その同期点の参加者中をカスケ
ード式に伝播して、図３４に示された同期点ツリーを形
成する。アプリケーション５６Ｂ、５６Ｄおよび５６Ｆ
は、それぞれ保護会話アダプタ６４Ｂ、６４Ｄおよび６
４Ｆ（図示せず）によって管理される保護された会話８
０１および８０２を介して、互いに通信する。アプリケ
ーション５６Ｂ、５６Ｄおよび５６Ｆは、それぞれ資源
アダプタ６２Ｂ、６２Ｄ、６２Ｆ（図示せず）を使用
し、これらの資源アダプタは、それぞれ保護されない会
話８０３Ｂ、８０３Ｄ、８０３Ｅ、８０３Ｇ、８０３Ｆ
を使用して、資源マネジャ６３Ｂ、６３Ｄ、６３Ｅ、６
３Ｇ、６３Ｆと通信する。このツリーには、同期点開始
側のアプリケーション５６Ｂとそれに参加する資源マネ
ジャ６３Ｂおよび分散アプリケーション５６Ｄ、分散ア
プリケーション５６Ｄに参加する資源マネジャ６３Ｅ、
６３Ｄおよび分散アプリケーション５６Ｆ、分散アプリ
ケーション５６Ｆに参加する資源マネジャ６３Ｇおよび
６３Ｆが含まれる。

【０１７３】同期点回復のために、１つの同期点ログ、
たとえば７２Ｄが、同期点マネジャ６０Ｄによって（図
示されない回復ファシリティ７０Ｄを介して）、同期点
ツリー内でその直前にある環境５２Ｂ内のアプリケーシ
ョン５６Ｂと、直接参加者であることが同期点マネジャ
６０Ｄにわかっている、資源マネジャ６３Ｅ、６３Ｄお
よびアプリケーション環境５２Ｆ内のアプリケーション
５６Ｆとに関する情報と共に維持されるが、その他の同
期点参加者６３Ｂ、６３Ｇまたは６３Ｆに関しては、同
期点ログ７２Ｄ内に何も維持されない。

【０１７４】図３５は、同期点回復の主要要素の高水準
流れ図２９８である。この図は、回復ファシリティ７０
の２つの部分、同期点以前の回復同意（ステップ２９
９、３００、３０１および３０２）と同期点障害からの
回復（ステップ３０３ないし３０６）を表している。

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

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

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

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

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

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

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

【０１８２】“State”（状態）フィールド SPL_SYNCPOINT_STATEは、同期点の全体的な状態であ
る。同期点が段階２に達すると、この状態によって、下
流側の参加者を駆動してその同期点を解決することが可
能になる。同期点が、障害を発生した時点で段階１であ
った場合には、回復要求事象の処理で、開始側回復ファ
シリティの指示に従って、この状態を変更することがで
きる。

【０１８３】SPL_PARTICIPANT_STATEは、応答処理ドラ
イバ３１８によって、参加者からの応答状態を用いて更
新される。

【０１８４】RCS_PARTICIPANTS_STATEは、影響を受ける
下流側の同期点参加者を駆動する目的で、様々な回復事
象処理によってセットされる。

【０１８５】RCS_INITIATOR_RESPONSE_STATEは、様々な
回復事象処理３１１ないし３１５によってRCS_PARTICIP
ANTS_STATEと共に初期設定されるが、ある状況の下で
は、すなわち、開始側への応答が、ヒューリスティック
応答として知られる単方向性の決定から生じた、参加者
からの異常かつ予期されない応答を反映するためのもの
である場合には、応答処理ドライバ３１８によっても更
新される。このフィールドは、開始側に戻される状態を
形成するために開始側応答ドライバ３１９が使用する。

【０１８６】“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は、回復手順の各参加者との会
話の状況を記録するのに使用される。これがとり得る値
は４つあり、RESTART（再始動）、CONNECTED（接続済
み）、RETRY（再試行）およびRESPONDED（応答済み）で
ある。

【０１９５】LL_LOGNAMEは、同期点参加者のログ名であ
る。潜在的な同期点通信に関係する各経路ごとに１つず
つ記録される。

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

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

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

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

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

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

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

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

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

【０２０５】図４３は、回復ファシリティ７２の障害が
発生した（ステップ３１４）場合に行われる処理（ステ
ップ４０８）を示す流れ図である。回復ファシリティ７
０が再始動される（ステップ４０７）時、ログ７２を検
索して（ステップ４１１）、下記の条件を満足するすべ
てのエントリを探す。SPL_SYNCPOINT_STATEが、この同
期点を完了するために、同期点の直接参加者を駆動でき
ることを示していること。これは、以下のいずれかによ
って示される。SPL_SYNCPOINT_STATEが同期点段階１を
示し、開始側の“prepare”に対する応答がなかった場
合、あるいはSPL_SYNCPOINT_STATEが同期点段階２を示
す場合。

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

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

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

【０２０９】開始側の場合、このサポートが開始された
（ステップ４０８）後に、回復制御構造を作成し（ステ
ップ４１４）、渡された指示に合わせてRCS_INITIATOR_
RESPONSE_STATEとRCS_PARTICIPANTS_STATEを設定して、
回復処理が開始した回復要求と等価な要求を形成する。
さらに、RCS_RESPOND_TO_INITIATORをオフにセットし
て、応答の生成を抑止し、RCS_RETURN_TO_CALLERをオフ
にセットして、処理の完了時に回復初期設定から戻るの
を抑止する。回復初期設定を呼び出して（ステップ４１
５）、処理を開始させる。

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

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

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

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

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

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

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

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

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

【０２１９】図４８は、開始側応答ドライバ（ステップ
３１９）を示す流れ図である。まず、開始側応答ドライ
バが開始される（ステップ４６０）。RCS_RESPONSE_TO_
INITIATORがセットされていない場合（判断ブロック４
６１）、応答する必要はない。したがって、同期点ログ
のエントリを消去するだけでよい（ステップ４６８）。
応答すべき開始側がない時（ステップ４６２）、すなわ
ち、回復ファシリティが同期点ツリーの最初のノードを
表している時も、応答は行わない。

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

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

【０２２２】RCS_PATH_IDが設定されていない（判断ブ
ロック４６５）時は、開始側への応答（ステップ４６６
および４６７）は行われない。そうでない場合は、RCS_
INITIATOR_RESPONSE_STATE（ステップ４６６）と応答サ
ービス（ステップ４６７）を使用して、開始側への正常
な応答が行われる。RCS_RESPOND_TO_INITIATORまたはRC
S_ERASE_LOGがオンである場合（判断ブロック４７
７）、完了の前に、回復終了機能が呼び出される（ステ
ップ４６８）。

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

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

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

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

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

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

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

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

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

【０２３２】図５では、アプリケーション５６Ａ（した
がって、同期点マネジャ６０Ａも）が、コミット要求の
開始側であった。ところが、図５１は、アプリケーショ
ン５６Ａではなく、システム５０Ｈにある別のアプリケ
ーション５６Ｈがコミットを開始した（ステップ７０
０）別の例を示す図である。アプリケーション５６Ｈが
実行されるアプリケーション環境は、アプリケーション
５６Ａが実行される環境と類似していても異なっていて
もよい。ただし、両方のシステムおよびアプリケーショ
ン環境は、どちらも前述の通信と２段階コミット手順を
サポートする。システム５０Ａとシステム５０Ｄは、図
２のそれと同一である。図５１（およびそれに続く図５
２と図５３）に示す例では、アプリケーション５６Ｈ
は、システム５０Ｈ内の同期点マネジャ６０Ｈに対し
て、システム５０Ｈ、システム５０Ａおよびシステム５
０Ｄ内の資源を使用するコミット要求（SYNCPT）を発行
した。このコミット要求に応答して、同期点マネジャ６
０Ｈは、段階１の“prepare”コールを用いて、その登
録された資源である保護会話アダプタ６４Ｈを呼び出
す。次に、保護会話アダプタ６４Ｈが、システム５０Ａ
内の保護会話アダプタ６４Ｂに体系的システム間“prep
are”コールを送る（ステップ７０１）。前述したよう
に、この“prepare”信号は、２段階コミット手順の第
１段階の一部である。次に、保護会話アダプタ６４Ｂが
アプリケーション５６Ａに“Take Syncpoint”の通知を
与え（ステップ７０４）、これに応答して、アプリケー
ション５６Ａが同期点マネジャ６０Ａに対してコミット
要求（SYNCPT）を発行する（ステップ７０６）。次に、
同期点マネジャ６０Ａが、段階１の“prepare”コール
を用いて保護会話アダプタ６４Ａを呼び出す。保護会話
アダプタ６４Ａは、システム５０Ｄ内の保護会話アダプ
タ６４Ｄに体系的システム間prepareコールを送る（ス
テップ７０８）。これに応答して、保護会話アダプタ６
４Ｄがアプリケーション５６Ｄに“Take Syncpoint”通
知を与える（ステップ７１０）。これに応答して、アプ
リケーション５６Ｄが同期点マネジャ６０Ｄにコミット
（SYNCPT）要求を発行する（ステップ７１２）。同期点
マネジャ６０Ｄは、その登録されたすべての資源に段階
１の“prepare”コールを発行する。同期点マネジャ６
０Ｄによってアクセスされるすべての資源がコミットの
準備ができた時、同期点マネジャ６０Ｄは、“request
commit”の回答を用いて保護会話アダプタ６４Ｄを呼び
出す。保護会話アダプタ６４Ｄは、体系的システム間
“request commit”コールをこのコミット要求の開始
側、この場合には保護会話アダプタ６４Ａに送り、保護
会話アダプタ６４Ａは同期点マネジャ６０Ａに“reques
t commit”と回答する（ステップ７１４）。同期点マネ
ジャ６０Ａは、この要求と、その資源がすべて作動可能
である旨の通知とを受け取った後に、保護会話アダプタ
６４Ｂに“request commit”と回答する。保護会話アダ
プタ６４Ｂは、体系的システム間“request commit”コ
ールを、このコミット要求の開始側、この場合には開始
側の保護会話アダプタ６４Ｈと同期点マネジャ６０Ｈに
送る（ステップ７１６）。同期点マネジャ６０Ａの代理
として保護会話アダプタ６４Ｈからのこの回答と、同期
点マネジャ６０Ｈの資源がすべて作動可能である旨の通
知とを受け取った後に、同期点マネジャ６０Ｈの段階２
の決定がコミットされる。同期点マネジャ６０Ｈは、段
階２の決定“commit”を用いてすべての資源を呼び出
す。保護会話アダプタ６４Ｈは、呼び出されると、体系
的システム間“commit”コールを保護会話アダプタ６４
Ｂに送り、保護会話アダプタ６４Ｂは同期点マネジャ６
０Ａに“committed”と回答し、これがその段階２の決
定になる（ステップ７１８）。

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

【０２３４】次に、同期点マネジャ６０Ａが、段階２の
“commit”決定を用いて、その登録されたすべての資源
を呼び出す。同期点マネジャ６０Ａが、“commit”コー
ルで保護会話アダプタ６４Ａを呼び出すと、保護会話ア
ダプタ６４Ａは、体系的システム間“commit”コールを
保護会話アダプタ６４Ｄに送ることを試み、保護会話ア
ダプタ６４Ｄは、同期点マネジャ６０Ｄに“committe
d”と回答しなければならない。ところが、この例では
この送信は会話経路の障害のために成功しない（ステッ
プ７２０）。この障害に応答して、同期点マネジャ６０
Ａは、このＬＵＷＩＤと保護された会話とのための回復
処理を求めて回復ファシリティ７０Ａにコンタクトす
る。上述したように、回復ファシリティ７０Ａは、回復
ファシリティ７０Ｄを用いた回復の実行を１回試みる
（ステップ７２２）。この例では、通信経路の障害が持
続しているので、この試みも成功しない。次に、回復フ
ァシリティ７０Ａは、ログ・エントリを読み取って、非
同期的再同期化が必要なことを知る。そこで回復ファシ
リティ７０Ａは、同期点マネジャ７０Ａに、この失敗し
た回復の試みと、回復が非同期的に継続されることを通
知する。その後、同期点マネジャ６０Ａは、“forget,
resynchronization-in-progress(RIP)（忘却、進行中の
再同期化）”を用いて、保護会話アダプタ６４Ｂを呼び
出す。保護会話アダプタ６４Ｂは、体系的システム間
“forget, RIP”コールを保護会話アダプタ６４Ｈに送
り、保護会話アダプタ６４Ｈは同期点マネジャ６０Ｈに
“forget, RIP”と回答する（ステップ７２６）。その
後、同期点マネジャ６０Ａは、アプリケーション５６Ａ
に戻りコード“RC = OK. LUW_OUTCOME_PENDING”を与え
て、commitの意図と、このコミット処理が非同期的に完
了されることを知らせる（ステップ７２４）。ステップ
７２６の“Forget, RIP”通知は、ステップ７１８に対
する肯定応答として働き、それによって同期点マネジャ
６０Ｈは、ステップ７００の同期点に関係する同期点情
報用のその回復ファシリティ・ログに“forget”の状態
を書き込む。というのは、この時、２段階コミット処理
がアプリケーション５６Ｈの要求したコミットに関して
完了しているからである。同期点マネジャ６０Ｈは、そ
の保護会話アダプタ６４Ｈから“Forget, RIP”の指示
を受け取ると（このコミットに関係する他のすべての資
源からメッセージを受け取っていると仮定して）、アプ
リケーション５６Ｈに戻りコード“RC = OK. LUW_OUTCO
ME_PENDING”を戻して、コミットの意図と、このコミッ
ト処理が非同期的に完了されることを知らせることがで
きる（ステップ７２８）。

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

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

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

【０２３８】図５２は、同期点マネジャ６０Ｈが、以下
で詳細に示すようにバックアウトを発行する場合の進行
中の再同期化の機能を示す図である。ステップ７００〜
７１４は、図５１と同一である。ただし、同期点マネジ
ャ６０Ｈは、ステップ７１６で同期点マネジャ６０Ａか
ら保護会話アダプタ６４Ｈを介して回答“request comm
it”を受け取った後に、その保護された資源のうちの１
つまたは複数が動作不能であるために、バックアウトす
ることを決定する。そこで、同期点マネジャ６０Ｈは、
段階２の決定“backout”を用いてその登録された資源
を呼び出す。この決定“backout”が、同期点マネジャ
６０Ａに与えられる（保護会話アダプタ６４Ｈが、体系
的システム間backoutコールを保護会話アダプタ６４Ｂ
に送り、保護会話アダプタ６４Ｂが、同期点マネジャ６
０Ａに“backout”と回答する）（ステップ７４０）。
同期点マネジャ６０Ａは、段階２の決定“backout”で
その登録された資源を呼び出す。保護会話アダプタ６４
Ａは、ステップ７４２で、保護会話アダプタ６４Ｄを介
して同期点マネジャ６０Ｄにシステム間backoutコール
を送ろうと試みる。ところがこの例では、通信経路障害
またはその他のタイプの障害のために、ステップ７４２
は失敗する。これに応答して、同期点マネジャ６０Ａ
は、ステップ７４４で、ＬＵＷＩＤと障害を発生した資
源の識別子とを用いて回復ファシリティ７０Ａを呼び出
し、システム５０Ｄ上の回復ファシリティ７０Ｄを用い
た回復処理を実行させる。しかし、この例では、この回
復の試みも失敗する。回復ファシリティ７０Ａは、同期
点マネジャ６０Ａに、この回復の試みに失敗したが、非
同期的に回復処理を完了すると回答する。他の保護され
た資源からの通知を受けた後に、同期点マネジャ６０Ａ
は、その回復ファシリティのログ７２Ａに、“backout,
rip”の状態を書き込む。その後、同期点マネジャ６０
Ａは、“backout, rip”の回答を用いて保護会話アダプ
タ６４Ｂを呼び出す。体系的システム間backoutコール
に基づいて、保護会話アダプタ６４Ｂは、保護会話アダ
プタ６４Ｈからの元の段階２の“backout”コールに対
してエラー回答を送る（ステップ７４８）。その後、保
護会話アダプタ６４Ｂは、保護会話アダプタ６４Ｈに、
体系的システム間“backout, rip”コールを送る（ステ
ップ７５０）。保護会話アダプタ６４Ｈは、この“back
out, rip”の指示を受け取った後に、体系的システム間
肯定応答を送り（ステップ７５２）、同期点マネジャ６
０Ｈに“backout, rip”と回答する（ステップ７５
２）。同期点マネジャ６０Ｈは、他の資源からの回答を
得た後に、アプリケーション５６Ｈに、バックアウトが
保留中であることを通知する戻りコード“RC = Backou
t, LUW_OUTCOME_PENDING”を戻して、アプリケーション
５６Ｈが他の有用な作業を行ってもよいと知らせる（ス
テップ７５４）。保護会話アダプタ６４Ｂは、保護会話
アダプタ６４Ｈから“backout, rip”コールに対する肯
定応答（ステップ７４８および７５０に対する応答）を
得ると、同期点マネジャ６０Ａに“ok”と回答する。そ
の後同期点マネジャ６０Ａは、回復ファシリティのログ
７２Ａ内のこのＬＵＷＩＤ用のログエントリに“forge
t”の状態を書き込み、アプリケーション５６Ａに戻り
コード“RC = Backout, LUW_OUTCOME_PENDING”を戻す
（ステップ７４６）。この戻りコードは、このコミット
要求の意図された結果がバックアウトであるが、すべて
の資源がバックアウトしたわけではないことを意味す
る。ここでアプリケーション５６Ａは、その処理を続行
できる。回復ファシリティのログ７２Ａ内のＬＵＷＩＤ
エントリは、上述の“implied forget”としてシステム
５０Ａによって忘却される。この“forget”が書き込ま
れる時、このＬＵＷＩＤ内の障害を発生した資源がまだ
回復されていない場合は、回復が行われるまでそのＬＵ
ＷＩＤエントリは実際には忘却されない。その間に、回
復ファシリティ７０Ａは、システム５０Ｄ内の回復ファ
シリティ７０Ｄを用いて非同期的に回復の試みを続ける
（ステップ７５６）。回復が完了した時、同期点マネジ
ャ６０Ｄは、バックアウトの通知を受け、その段階２の
処理を完了する。その後同期点マネジャ６０Ｄはアプリ
ケーション５６Ｄに、すべての資源がバックアウトされ
たことを意味する戻りコード“RC = BACK OUT. ALL_AGR
EED”を戻す（ステップ７５８）。アプリケーション５
６Ｈ、５６Ａおよび５６Ｄは、いずれも他の処理を続行
できる。回復ファシリティ７０Ａと回復ファシリティ７
０Ｄの間で回復処理が行われる際に、回復の開始とその
処理の結果を示すメッセージが操作員コンソールに送ら
れることに留意されたい。

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

【０２４０】図５４は、以下で詳細に示すように異なる
障害のために、同期点マネジャ６０Ａがバックアウトを
発行する場合の進行中の再同期化の機能を示す図であ
る。ステップ７００〜７０６は、図５２と同一である。
ただし、同期点マネジャ６０Ａは、ステップ７０６でコ
ミット要求を受け取った後に、段階１の“prepare”コ
ールを用いてその登録された資源を呼び出す。保護会話
アダプタ６４Ａは、保護会話アダプタ６４Ｄに体系的シ
ステム間“prepare”コールを送ろうと試みる（ステッ
プ７０８Ａ）。ところが、ステップ７０８Ａに示される
ように、通信経路の障害またはその他の障害のために、
この“prepare”コールを保護会話アダプタ６４Ｄは受
け取らない。同期点マネジャ６０Ａは、段階２のbackou
tコールを用いてそのローカルな登録された資源を呼び
出す（ステップ７６３）。その後同期点マネジャ６０Ａ
は、ＬＵＷＩＤと障害を発生した資源の識別子とを用い
て回復ファシリティ７０Ａを呼び出し、回復処理を実行
するよう求める。回復ファシリティ７０Ａは、システム
５０Ｄ内の回復ファシリティ７０Ｄを用いて回復処理を
実行しようと試みる（ステップ７４４）。通信経路の障
害が持続しているので、ステップ７４４も失敗し、その
結果、同期点マネジャ６０Ａは、図５２を参照して上述
したステップ７４６の信号を送る。ステップ７５０〜７
５６は、図５２と同一である。同期点マネジャ６０Ａに
よって行われる処理とは非同期的に、アプリケーション
５６Ｄが、以前（アプリケーション５６Ａがアプリケー
ション５６Ｄを開始した時）に確立されたアプリケーシ
ョン５６Ａとの保護された会話上で経路障害の指示を受
け取る（ステップ７６１）。この経路障害のため、保護
会話アダプタ６４Ｄは保護会話アダプタ６４Ａからprep
areコールを受け取れなかった。この経路障害は、保護
された会話に対して発生したので、アプリケーション５
６Ｄはバックアウト要求を発行しなければならない。ア
プリケーション５６Ｄは、バックアウト要求を発行し
（ステップ７６２）、最終的に、すべての資源がバック
アウトされたことを示す戻りコードを受け取る（ステッ
プ７６４）。この時点で、アプリケーション５６Ｈ、５
６Ａおよび５６Ｄは、いずれも他の処理を続行できる。
その間に、回復ファシリティ７０Ａは、システム５０Ｄ
内の回復ファシリティ７０Ｄを用いて非同期的に回復の
試みを続ける（ステップ７５６）。回復処理が回復ファ
シリティ７０Ａと回復ファシリティ７０Ｄの間で行われ
る際に、回復の開始とその処理の結果を示すメッセージ
が操作員コンソールに送られることに留意されたい。

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

【０２４２】以下は、部分的な用語集である。

【０２４３】アプリケーション ある実行環境内で実行され、コミット、バックアウトま
たは作業要求のうちの１つまたは複数を発行できる、ユ
ーザ・プログラムまたはサービス・プログラムまたは資
源マネジャと統合された作業分散機能。

【０２４４】実行環境 仮想計算機、パーソナル・コンピュータ、ワーク・ステ
ーション、ミニ・コンピュータ、メインフレーム・コン
ピュータまたはその他のタイプのコンピュータあるいは
それらの任意の組合せにおいて、アプリケーション、シ
ステム・ファシリティ（回復ファシリティ、通信ファシ
リティなど）、資源マネジャまたはその他のプログラム
あるいはそれらの任意の組合せを実行するための、何ら
かの計算手段。

【０２４５】保護された会話 何らかの形の同期点処理または保護的コミットもしくは
バックアウト手順の対象となる会話。

【０２４６】保護された資源 何らかの形の同期点処理または他の保護的コミットもし
くはバックアウト手順の対象となる資源。

【０２４７】回復ファシリティ 障害を発生した同期点またはその他のコミットもしくは
バックアウト手順の回復の責任を負うファシリティ。

【０２４８】２段階コミット手順 更新または保護会話あるいはその両方の、コミットまた
はバックアウトを調整または同期あるいはその両方を行
うための手順。通常、２段階コミット手順は、保護され
た会話を介して、複数の資源または単一の資源を原子的
にコミットまたはバックアウトするのに使用される。た
とえば、２段階コミット手順には、ポーリングまたは準
備段階と、バックアウトまたはコミット段階を含めるこ
とができる。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図３７】図２のログ７２の内容と、図３５で表される
手順を制御するのに必要な制御構造とを示す、ブロック
図である。

【図３８】図３５のステップ２９９および３００の詳細
を示す流れ図である。

【図３９】図３５のステップ３０１および３０２の詳細
を示す流れ図である。

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

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

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

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

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

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

【図４６Ａ】図３６のステップ３１７の詳細を示す流れ
図である。

【図４６Ｂ】図３６のステップ３１７の詳細を示す流れ
図である。

【図４７】図３６のステップ３１８の詳細を示す流れ図
である。

【図４８Ａ】図３６のステップ３１９の詳細を示す流れ
図である。

【図４８Ｂ】図３６のステップ３１９の詳細を示す流れ
図である。

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

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

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

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

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

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

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

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

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

【符号の説明】

５０ システム ５２ アプリケーション実行環境 ５３ 会話マネジャ ５５ システム制御プログラム ５６ アプリケーション ６０ 同期点マネジャ（ＳＰＭ） ６２ 資源アダプタ ６３ 資源マネジャ ６４ 保護会話アダプタ ７０ 回復ファシリティ ７２ ログ

───────────────────────────────────────────────────── フロントページの続き (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（番 地なし)

Claims (36)

【特許請求の範囲】
1. 【請求項１】第１の実行環境と、 前記第１の実行環境のために第１のコミット手順を調整
   する第１の同期点マネジャ手段と、 第２の実行環境と前記第２の実行環境のために第２のコ
   ミット手順を調整する第２の同期点マネジャ手段と、 前記第１および第２の同期点マネジャ手段に結合され
   た、前記第１のコミット手順および前記第２のコミット
   手順を回復するための回復ファシリティ手段とを備え
   る、コンピュータ・システム。
2. 【請求項２】前記第１の同期点マネジャが前記第１の実
   行環境内に常駐し、 前記第２の同期点マネジャが前記第２の実行環境内に常
   駐する、 請求項１に記載のコンピュータ・システム。
3. 【請求項３】さらに、前記第１の実行環境を前記第２の
   実行環境に結合するためのホスト手段を備える、請求項
   １に記載のコンピュータ・システム。
4. 【請求項４】前記第１の実行環境が第１の仮想計算機で
   あり、前記第２の実行環境が第２の仮想計算機である、
   請求項３に記載のコンピュータ・システム。
5. 【請求項５】前記回復ファシリティ手段が、前記ホスト
   手段に結合された第２の仮想計算機内に常駐する、請求
   項４に記載のコンピュータ・システム。
6. 【請求項６】さらに、前記回復ファシリティ手段に結合
   された、前記第１の実行環境および前記第２の実行環境
   のための前記回復ファシリティにサービスする回復ファ
   シリティ・ログ手段を備える、請求項１に記載のコンピ
   ュータ・システム。
7. 【請求項７】さらに、前記第１の実行環境と前記第２の
   実行環境の間で、前記第１および第２の実行環境に関係
   し、前記第１および第２のコミット手順に関連する、保
   護された会話を成立させる手段を備える、請求項１に記
   載のコンピュータ・システム。
8. 【請求項８】前記第１の同期点マネジャ手段が、前記第
   １の実行環境に関する同期点段階情報を、前記回復ファ
   シリティ手段を介して前記回復ファシリティ・ログ手段
   にロギングする手段を含み、前記第２の同期点マネジャ
   手段が、前記第２の実行環境に関する同期点段階情報
   を、前記回復ファシリティ手段を介して前記回復ファシ
   リティ・ログ手段にロギングする手段を含む、請求項６
   に記載のコンピュータ・システム。
9. 【請求項９】前記第１のコミット手順が２段階である、
   請求項１に記載のコンピュータ・システム。
10. 【請求項１０】さらに、第３の実行環境と、 前記第３の実行環境のために第３のコミット手順を調整
    する第３の同期点マネジャ手段と、 前記第３の同期点マネジャ手段に結合された、前記第３
    のコミット手順を回復するための第２の回復ファシリテ
    ィ手段と、 前記第１および第２実行環境がその中に常駐する第１の
    実計算機を、前記第３実行環境がその中に常駐する第２
    の実計算機に結合するための通信ファシリティ手段と、 前記第１の実行環境と前記第３の実行環境の間で、前記
    通信ファシリティ手段を介して保護された会話を成立さ
    せる手段とを備える、 請求項１に記載のコンピュータ・システム。
11. 【請求項１１】第１の実行環境内で第１のアプリケーシ
    ョンを実行するステップと、 前記第１のアプリケーションのために第１の２段階コミ
    ット手順を調整するステップと、 第２の実行環境内で第２のアプリケーションを実行する
    ステップと、 前記第２のアプリケーションのために第２の２段階コミ
    ット手順を調整するステップと、 前記第１および第２の実行環境に結合された共通回復フ
    ァシリティを用いて、前記第１および第２の２段階コミ
    ット手順を回復するステップとを含む、保護された資源
    の同期点管理を行う方法。
12. 【請求項１２】前記第１の２段階コミット手順の調整
    が、前記第１の実行環境内で実行され、 前記第２の２段階コミット手順の調整が、前記第２の実
    行環境内で実行される、 請求項１１に記載の方法。
13. 【請求項１３】さらに、前記第１および第２の実行環境
    を共通ホストとホスト接続するステップを含む、請求項
    １１に記載の方法。
14. 【請求項１４】前記第１の実行環境が第１の仮想計算機
    によって提供され、前記第２の実行環境が第２の仮想計
    算機によって提供され、さらに、前記第１および第２の
    仮想計算機を単一の実計算機内に設けるステップを含
    む、請求項１３に記載の方法。
15. 【請求項１５】さらに、前記回復ファシリティを、前記
    実計算機内の第２の仮想計算機内に設けるステップを含
    む、請求項１４に記載の方法。
16. 【請求項１６】さらに、前記第１の２段階コミット手順
    および前記第２の２段階コミット手順用の同期点情報
    を、共通回復ログにロギングするステップを含む、請求
    項１１に記載の方法。
17. 【請求項１７】さらに、前記第１のアプリケーションと
    前記第２のアプリケーションの間で保護された会話を開
    始するステップを含み、前記第１および第２のコミット
    手順が、前記の保護された会話をサポートする、請求項
    １１に記載の方法。
18. 【請求項１８】前記第１および第２のアプリケーション
    が、関係する作業要求を共通のコミット範囲内で行う、
    請求項１１に記載の方法。
19. 【請求項１９】第１の実行環境内で第１のアプリケーシ
    ョンの実行を制御する第１の手段と、 前記第１のアプリケーションに応答して、前記第１のア
    プリケーションのために第１のコミット手順を調整する
    第１の手段と、 第２の実行環境内で第２のアプリケーションの実行を制
    御する第２の手段と、 前記第２のアプリケーションに応答して、前記第２のア
    プリケーションのために第２のコミット手順を調整する
    第２の手段と、 前記第１および第２の調整手段に動作可能的に結合され
    た、前記第１および第２のコミット手順を回復するため
    の回復ファシリティ手段とを含む、コンピュータ制御装
    置。
20. 【請求項２０】前記の両方の制御手段と前記の両方の調
    整手段が、１つのオペレーティング・システムの部分で
    ある、請求項１９に記載のコンピュータ制御装置。
21. 【請求項２１】前記第１の実行環境が第１の仮想計算機
    であり、前記第２の実行環境が第２の仮想計算機であ
    り、 さらに、前記第１の実行環境と前記第２の実行環境の間
    での会話を管理するためのホスト・オペレーティング・
    システム手段を含む、 請求項１９に記載のコンピュータ制御装置。
22. 【請求項２２】前記回復ファシリティ手段が、第２の仮
    想計算機によって提供される、請求項２１に記載のコン
    ピュータ制御装置。
23. 【請求項２３】前記第１の実行環境と前記第２の実行環
    境の間で保護された会話を開始する手段を含み、 前記第１および第２のコミット手順が、前記の保護され
    た会話に関係する、 請求項１９に記載のコンピュータ制御装置。
24. 【請求項２４】さらに、前記第１の実行環境および前記
    第２の実行環境用の同期点段階情報を、前記回復ファシ
    リティ手段を介して共通回復ログにロギングする手段を
    含む、請求項１９に記載のコンピュータ制御装置。
25. 【請求項２５】さらに、前記回復ファシリティ手段に結
    合された、前記第１の実行環境および前記第２の実行環
    境用の同期点情報を記憶するための回復ログを指定する
    手段と、 前記第１および第２のコミット手順を回復するための第
    ２の回復ファシリティ手段と、 前記第１の回復ファシリティ手段が非活動状態である時
    に、前記第２の回復ファシリティ手段を活動化し、前記
    第２の回復ファシリティ手段を前記回復ログに結合し、
    これによって前記第２の回復ファシリティ手段が第１の
    前記回復ファシリティにバックアップを提供するように
    する手段とを含む、請求項１９に記載のコンピュータ制
    御装置。
26. 【請求項２６】さらに、前記回復ファシリティ手段に結
    合された、前記第１の実行環境および前記第２の実行環
    境用の同期点情報を記憶するための、回復ログ手段と、 前記回復ファシリティ手段を含む第３の実行環境と、 前記第１のコミット手順と前記第２のコミット手順を回
    復するための第２の回復ファシリティ手段と、 前記第２の回復ファシリティ手段を含む第４の実行環境
    と、 前記第１の回復ファシリティ手段が非活動状態である時
    に、前記第２の回復ファシリティ手段を活動化し、前記
    第２の回復ファシリティ手段を前記同期点ログに結合す
    る手段とを備える、請求項１に記載のコンピュータ・シ
    ステム。
27. 【請求項２７】さらに、前記第３の実行環境内に常駐す
    る第１の共用ファイル・システム・マネジャと、 前記第４の実行環境内に常駐する第２の共用ファイル・
    システム・マネジャとを備える、請求項２６に記載のコ
    ンピュータ・システム。
28. 【請求項２８】第１のアプリケーションを実行するため
    の第１の実行環境と、前記第１の実行環境に結合され
    た、前記第１の実行環境によって開始された第１のコミ
    ット手順を回復するための第１の回復ファシリティ手段
    とを備えた、第１の実計算機と、 第２のアプリケーションを実行するための第２の実行環
    境と、前記第２の実行環境に結合された、前記第２の実
    行環境によって開始されたコミット手順を回復するため
    の第２の回復ファシリティ手段とを備える、第２の実計
    算機と、 前記第１の実行環境が、資源マネジャ手段によって管理
    される資源にアクセスできるように、資源マネジャ手段
    を前記第１の実行環境に結合する手段と、 前記第２の実行環境が、前記資源マネジャ手段によって
    管理される前記資源にアクセスできるように、前記資源
    マネジャ手段を前記第２の実行環境に結合する手段と、 前記第１の実行環境が前記資源にアクセスする時に、前
    記第１の回復ファシリティ手段を使用して前記資源を回
    復する手段と、 前記第２の実行環境が前記資源にアクセスする時に、前
    記第２の回復ファシリティ手段を使用して前記資源を回
    復する手段とを備える、コンピュータ・ネットワーク。
29. 【請求項２９】さらに、前記第１回復ファシリティ手段
    に結合された、前記第１のコミット手順に関係する同期
    点段階情報を記憶するための、第１の同期点ログ手段
    と、 前記第２の回復ファシリティ手段に結合された、前記第
    ２のコミット手順に関係する同期点段階情報を記憶する
    ための、第２の同期点ログ手段と、 前記資源マネジャに結合された、前記資源マネジャに関
    係する同期点段階情報を記憶するための、第３の同期点
    ログ手段とを備える、請求項２８に記載のコンピュータ
    ・ネットワーク。
30. 【請求項３０】第１の実計算機内の第１の実行環境内で
    実行されるアプリケーションの実行を制御し、前記第１
    の実行環境による、前記第１の実計算機内の第１の資源
    マネジャの使用、および第２の実計算機内の第２の資源
    マネジャの使用をサポートする、第１のオペレーティン
    グ・システム手段と、 前記第１および第２の資源マネジャに関するコミット手
    順をそれぞれ少なくとも１つ回復するための第１の回復
    ファシリティ手段と、 前記アプリケーションが、前記第１の資源マネジャに関
    係する第１の資源のユーザである時に、前記第１回復フ
    ァシリティ手段を使用して前記第１の資源を回復する手
    段と、 前記アプリケーションが前記第２の資源マネジャに関係
    する第２の資源のユーザである時に、前記第１の回復フ
    ァシリティ手段を使用して前記第２の資源を回復する手
    段とを含む、コンピュータ可読媒体を含むコンピュータ
    制御装置。
31. 【請求項３１】さらに、前記第１の回復ファシリティ手
    段にサービスする、前記第１の実行環境に関する同期点
    段階情報を記憶するための第１の同期点ログを定義する
    手段と、 前記第２の資源マネジャにサービスする、前記第２の資
    源マネジャに関する同期点段階情報を記憶するための第
    ２の同期点ログを定義する手段とを備える、請求項３０
    に記載のコンピュータ制御装置。
32. 【請求項３２】第１のアプリケーションを実行するため
    の第１のコンピュータと、 前記第１のコンピュータにサービスする、前記第１のア
    プリケーションに関係するコミット手順を回復するため
    の、第１の回復ファシリティ手段と、 前記第１の回復ファシリティ手段にサービスする、回復
    情報を記憶するための、第１の回復ログ手段と、 第２のアプリケーションを実行するための第２のコンピ
    ュータと、 前記第２のコンピュータにサービスする、前記第２のア
    プリケーションに関係するコミット手順を回復するため
    の、第２の回復ファシリティ手段と、 前記第２回復ファシリティ手段にサービスする、回復情
    報を記憶するための、第２の回復ログ手段と、 第３のアプリケーションを実行するための第３のコンピ
    ュータと、 前記第３のコンピュータにサービスする、前記第３のア
    プリケーションに関係するコミット手順を回復するため
    の、第３の回復ファシリティ手段と、 前記第３の回復ファシリティ手段にサービスする、回復
    情報を記憶するための、第３の回復ログ手段と、 前記第１および第２のコンピュータを関係する作業用の
    共通コミット範囲に含めるために、前記第１のコンピュ
    ータと前記第２のコンピュータの間の会話を成立させる
    手段と、 前記第２および第３のコンピュータを関係する作業用の
    共通コミット範囲に含めるために、前記第２のコンピュ
    ータと前記第３のコンピュータの間の会話を成立させる
    手段を備え、 前記第１の回復ログ手段が、前記第１および第２のコン
    ピュータ用の回復情報を記憶するが、前記第３のコンピ
    ュータ用の情報は記憶せず、前記第２の回復ログ手段
    が、前記第１、第２および第３のコンピュータ用の回復
    情報を記憶し、前記第３の回復ログ手段が、前記第２お
    よび第３のコンピュータ用の回復情報を記憶するが、前
    記第１のコンピュータ用の情報は記憶しない、 コンピュータ・ネットワーク。
33. 【請求項３３】前記回復情報が、回復ログ手段の名前情
    報を含む、請求項３２に記載のコンピュータ・ネットワ
    ーク。
34. 【請求項３４】前記回復情報が、同期点状態情報を含
    む、請求項３２に記載のコンピュータ・ネットワーク。
35. 【請求項３５】前記第１の実行環境が、第１のパーソナ
    ル・コンピュータまたは第１のワーク・ステーション内
    に常駐し、 前記第２の実行環境が、第２のパーソナル・コンピュー
    タまたは第２のワーク・ステーション内に常駐する、請
    求項１に記載のコンピュータ・システム。
36. 【請求項３６】前記回復ファシリティ手段が、第３のパ
    ーソナル・コンピュータまたは第３のワーク・ステーシ
    ョン内に常駐する、請求項３５に記載のコンピュータ・
    システム。