JPH06332876A - 系間排他制御方式 - Google Patents

Abstract

(57)【要約】 【目的】 多重計算機システムにおいて、排他制御サー
ビスを行なう。 【構成】 ネットワークで結合された計算機群により構
成された多重計算機システムにおいて排他情報管理用テ
ーブル、排他サービスマネージャ、排他要求を排他サー
ビスマネージャに送信する排他要求マネージャを各々２
重化している。 【効果】 この発明は、ネットワークで結合された多重
計算機システムを構築し、システム内の計算機に障害が
発生しても排他制御サービスが損なわれることなく続行
できる点で、信頼性の高い排他制御サービスを提供でき
る効果がある。また、従来、計算機障害発生時にアプリ
ケーションシステム独自のエラー処理を排他を解除する
前に行なうことができなかったが、排他を解除する前
に、任意のエラー処理手段を実行できる効果がある。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、相互に接続された多重
計算機システムにおける排他制御に関するものであり、
更に詳しくは計算機システムにおける障害発生時におい
て、系内共有資源に対する排他サービス処理の継続性、
及び一貫性の保証を目的とした排他制御方式に関するも
のである。

【０００２】

【従来の技術】従来の多重計算機システムにおけるファ
イルロックサービスについて以下に、説明する。図１７
は、多重計算機のシステム構成図を示したもので、５０
１は計算機１、５０２は計算機２であり、５１０は上記
計算機を接続しているネットワークである。計算機１上
において、５０３は、ロックマネージャ１＜ＬＭ１＞、
５０５はステータスモニタ１＜ＳＭ１＞、５０７はロッ
ク管理テーブルＴである。また、計算機２上において、
５０９はアプリケーションプロセス＜ＡＰ＞、５０４は
ロックマネージャ２＜ＬＭ２＞、５０６はステータスモ
ニタ２＜ＳＭ２＞、５０８はローカルロック管理テーブ
ルである。

【０００３】次に動作について、図１７及び図１８のフ
ローチャートに基づいて、正常系処理及び、異常系処理
に分けてそれぞれ説明する。 Ａ．正常系処理 まづ、正常系処理の動作について、図１８（ａ）につい
て説明する。 （１）アプリケーションプロセス＜ＡＰ＞（５０９）
は、ロックマネージャ２＜ＬＭ２＞（５０４）に対し排
他要求を行なう。（ｓｔｅｐ５２１） （２）ロックマネージャ２＜ＬＭ２＞（５０４）は、上
記排他要求を受け付け（ｓｔｅｐ５２４）て、排他要求
か排他解除かをチェック（ｓｔｅｐ５２５）する。 （３）排他要求であれば、ローカルロック管理テーブル
＜ＬＴ＞（５０８）に登録（ｓｔｅｐ５２６）し、ロッ
クマネージャ１＜ＬＭ１＞（５０３）に要求を送信（ｓ
ｔｅｐ５２７）する。 （４）ロックマネージャ＜ＬＭ１＞（５０３）は、上記
要求を受信する（ｓｔｅｐ５３２）と、排他要求か、解
除要求かをチェック（ｓｔｅｐ５３３）する。 （５）排他要求であれば、ロック管理テーブル＜Ｔ＞
（５０７）を排他可能かどうか検索（ｓｔｅｐ５３４）
する。 （６）排他可能（ｓｔｅｐ５３５）であればメッセージ
にＯＫを設定（ｓｔｅｐ５３６）し、排他不可能であれ
ばメッセージにＮＧを設定（ｓｔｅｐ５３８）する。 （７）ｓｔｅｐ５３３において、排他解除要求の場合
は、解除要求のあったリソースをロック管理テーブル＜
Ｔ＞（５０７）上で検索（ｓｔｅｐ５３９）し、その排
他情報を削除（ｓｔｅｐ５４０）し、メッセージに解除
ＯＫを設定（ｓｔｅｐ５４１）する。 （８）メッセージの設定が完了（ｓｔｅｐ５３６、又は
ｓｔｅｐ５３８、又はｓｔｅｐ５４１）したら、これを
ロックマネージャ２＜ＬＭ２＞（５０４）に送信（ｓｔ
ｅｐ５３７）する。 （９）ロックマネージャ＜ＬＭ２＞（５０４）は、これ
を受信（ｓｔｅｐ５２８）し、メッセージをチェック
（ｓｔｅｐ５２９）する。 （１０）受信メッセージ内容を調べ、排他要求結果が不
可（ＮＧ）、若しくは排他解除要求がＯＫの場合には、
ローカルロック管理テーブル＜ＬＴ＞（５０８）から削
除（ｓｔｅｐ５３０）し、アプリケーションプロセス＜
ＡＰ＞（５０９）に結果を通知（ｓｔｅｐ５３１）す
る。 （１１）アプリケーションプロセス＜ＡＰ＞（５０９）
は、排他要求が成功した場合には、一連のアプリケーシ
ョン個有の処理（ｓｔｅｐ５２２）を行ない、該処理終
了後、排他解除要求を、ロックマネージャ２＜ＬＭ２＞
に送信（ｓｔｅｐ５２３）する。

【０００４】Ｂ．異常系処理 次に、障害発生時の処理について図１８（ｂ）について
説明する。ここで、アプリケーションプロセス＜ＡＰ＞
（５０９）が、排他要求を出力（図１８（ａ）のｓｔｅ
ｐ５２１）した時点から、排他解除要求（ｓｔｅｐ５２
３）を出すまでの期間において、異常を起こした場合を
想定する。 （１）ステータスモニタ２＜ＳＭ２＞（５０６）が、ア
プリケーションプロセス＜ＡＰ＞（５０９）の異常を検
知（ｓｔｅｐ５４２）すると、ローカルロック管理テー
ブル＜ＬＴ＞（５０８）の内容を順次読み出す。（ｓｔ
ｅｐ５４３） （２）アプリケーションプロセス＜ＡＰ＞（５０９）が
ロックしている情報が、含まれているかどうかをチェッ
ク（ｓｔｅｐ５４４）し、該アプリケーションがロック
している情報が存在すれは、ロックマネージャ２＜ＬＭ
２＞（５０４）に対して排他解除要求を出す。（ｓｔｅ
ｐ５４５） これをローカルロック管理テーブル＜ＬＴ＞（５０８）
に該当情報がなくなるまで繰り返す。（ｓｔｅｐ５４
６）

【０００５】

【発明が解決しようとする課題】上記従来例のような構
成をとる排他制御システムにおいては、ファイルロック
サービスを提供してはいるものの、特に排他要求を獲得
しているアプリケーションプロセスに異常が発生した場
合において、直ちに該アプリケーションが獲得していた
排他要求が全て解除されてしまい、アプリケーションの
処理内容によっては、回復処理手順として、排他要求が
解除される前に実行しておかなければならない処理を、
排他要求解除に先立って実行しておくことができないと
いう問題点があった。さらに、排他を獲得しているアプ
リケーションプロセスが搭載されている計算機に異常が
発生した場合には、エラー回復処理が一切行われないと
いう問題点があった。加えて、ロックマネージャが存在
する計算機に異常が発生した場合には、排他サービス処
理が一切継続できないという問題点があった。

【０００６】この発明は、上記のような問題点を解消す
るためになされたもので、排他要求を獲得中のアプリケ
ーションプロセスに障害が発生した場合において、前記
排他要求を解除するに先立ってアプリケーションプロセ
スの処理内容に応じたエラー回復処理を実行できるよう
にすることによって、システム全体としての排他サービ
ス処理の継続性確保を目的としたものである。また、排
他制御実現手段が搭載された主計算機において障害が発
生した場合においても、従計算機が前記処理を代行でき
るようにすることで、システム内における排他サービス
制御の一貫性、並びに信頼性の維持向上を目的としたも
のである。

【０００７】

【課題を解決するための手段】本発明に係る系間排他制
御方式は、排他サービス機能を提供する第１の計算機
と、排他サービスを要求するアプリケーションプロセス
が搭載された第２の計算機群から構成された多重計算機
システムにおいて、前記第１の計算機には共有リソース
に対する排他要求、排他解除要求を実行する排他制御処
理実行部と、排他情報管理テーブルを具備し、前記第２
のグループを構成する計算機には、共有リソースに対す
る排他要求、排他解除のサービスを要求するアプリケー
ションプロセスに発生した障害を検知するためのプロセ
ス状態監視部と、上記障害検知時におけるエラー処理手
続きの登録部と、前記エラー処理手続きの実行部より構
成されたプロセス監視モニター手段を備えるようにした
ものである。また、排他サービス機能を提供する第１の
計算機と、排他サービスを要求するアプリケーションプ
ロセスが搭載された第２の計算機群から構成された多重
計算機システムにおいて、前記第１の計算機は共有リソ
ースに対する排他要求、排他解除要求を実行する排他制
御処理実行部と、他計算機の障害発生を検知するための
他計算機状態監視部と、上記計算機障害検知時における
エラー処理手続きの登録部及び並びに前記エラー処理手
続きの実行部より構成されたエラー処理部と、から構成
された排他サービスマネージャ手段を具備し、前記第２
のグループを構成する計算機は、共有リソースに対する
排他要求、排他解除のサービスを要求するアプリケーシ
ョンプロセスに発生した障害を検知するためのプロセス
状態監視部と上記障害検知時におけるエラー処理手続き
の登録部と、前記エラー処理手続きの実行部より構成さ
れたプロセス監視モニター手段を具備するようにしたも
のである。さらに、上記多重計算機システムが、特に２
台より構成された対向システムにおいては、対向する２
台の計算機双方に、共有リソースに対する排他要求、排
他解除要求を実行する排他制御処理実行部と、他計算機
の障害発生を検知するための他計算機状態監視部と、上
記計算機障害検知時におけるエラー処理手続きの登録部
及び前記エラー処理手続きの実行部より構成されたエラ
ー処理部と、から構成された排他サービスマネージャ手
段と、共有リソースに対する排他要求、排他解除に係わ
るサービスを要求するアプリケーションプロセスに発生
した障害を検知するためのプロセス状態監視部と上記障
害検知時におけるエラー処理手続きの登録部と、前記エ
ラー処理手続きの実行部より構成されたプロセス監視モ
ニタ手段を備えるようにしたものである。加えて、排他
制御処理を実行する第１の計算機群と、排他制御要求処
理を実行する第２の計算機群と、排他サービスを要求す
るアプリケーションプロセスが搭載された第３の計算機
群より構成された多重計算機システムにおいて、前記第
１の計算機群を構成する計算機は、共有リソースに対す
る排他要求、排他解除要求を実行する排他制御処理実行
部と、障害発生時におけるエラー処理手続きの登録部及
び前記エラー処理手続きの実行部より構成されたエラー
処理部と、から構成された排他サービスマネージャ手段
を具備し、前記第２の計算機群を構成する計算機は、前
記第１の計算機群に対する排他要求、排他解除要求を実
行する排他要求処理実行部と、多重計算機システムを構
成する計算機群の障害発生を検知するための他計算機状
態監視部と、前記計算機障害検知時におけるエラー処理
手続きの登録部及び前記エラー処理手続きの実行部より
成るエラー処理部と、から構成された排他要求マネージ
ャ手段を具備し、前記第３の計算機群を構成する計算機
は、前記アプリケーションプロセスに発生した障害を検
知するためのプロセス状態監視部と、上記障害検知時に
おけるエラー処理手続きの登録部及び前記エラー処理手
続きの実行部より構成されたエラー処理部と、から構成
されたプロセス監視モニタ手段を具備するようにしたも
のである。

【０００８】

【作用】この発明による系間排他制御方式においては、
アプリケーションプロセスの処理内容に応じたきめの細
いエラー回復処理を実行することができるので、アプリ
ケーションプロセスに障害が発生した場合においても、
処理全体の継続性を維持することができる。また、他計
算機状態監視部を設けて、アプリケーションプロセスが
搭載された計算機の障害発生を検知し、エラー処理を行
うようにすることで、ネットワークを構成している計算
機全体に係る障害発生に対してもエラー回復処理を可能
としたものである。加えて、排他制御サービス実現に必
要な諸機能を主計算機及び従計算機に分散して配置する
ことにより、一方の計算機に障害が発生した場合におい
ても、他の計算機が該処理を代行するようにしたこと
で、システム内における排他サービス制御の一貫性及び
信頼性を維持できる。

【０００９】

【実施例】

実施例１．本発明の実施例１について、図１〜図３に基
づいて説明する。図１（ａ）において、計算機１（１０
１）、計算機２（１０２）、計算機３（１０３）は多重
計算機システムを構築する計算機群であり、回線ＬＡＮ
（１１０）により各計算機は結合されている。計算機１
（１０１）には、排他サービスマネージャ＜ＳＭ＞（１
０４）と、排他情報管理テーブル＜Ｔ＞（１０５）が搭
載され、ここで排他サービスマネージャ＜ＳＭ＞は、図
１（ｂ）に示すように排他制御部（１１１）、他計算機
状態監視部（１１２）、及び障害発生時におけるエラー
処理部（１１３）より構成され、他計算機状態監視部
は、他計算機異常検知手段（１１４）を介して他計算機
の異常状態を検出する。一方、計算機２（１０２）、計
算機３（１０３）内には、各々排他サービスを受けるア
プリケーションプロセス１＜ＡＰ１＞（１０８）と、ア
プリケーションプロセス２＜ＡＰ２＞（１０９）及び、
これらを監視するためのプロセス監視モニター１＜ＷＰ
１＞（１０６）、監視モニター２＜ＷＰ２＞（１０７）
が搭載されている。ここで、プロセス監視モニター＜Ｗ
Ｐ＞は、図１（ｂ）で示すようにプロセス状態監視部
（１１５）と、アプリケーションプロセス異常時のエラ
ー処理部（１１６）より構成され、プロセス状態監視部
は、プロセス異常検知手段（１１７）を介してプロセス
の障害を検出する。

【００１０】次に動作について、正常系処理及び障害発
生時の異常系処理に分けて、それぞれ説明する。 Ａ．正常系処理 正常処理動作について、図２のフローチャート及び図１
に基づいて説明する。 （１）アプリケーションプロセス１＜ＡＰ１＞（１０
８）が共有リソースの排他要求を行なう場合には、回線
ＬＡＮ（１１０）を介して排他サービスマネージャ＜Ｓ
Ｍ＞（１０４）に排他要求を送信（ｓｔｅｐ１２１）す
る。 （２）排他サービスマネージャ＜ＳＭ＞（１０４）は、
排他要求を受信（ｓｔｅｐ１３０）する。 （３）排他サービスマネージャの排他制御部（１１１）
は、排他要求か解除要求かを判別（ｓｔｅｐ１３１）
し、排他要求であれば排他情報管理テーブル＜Ｔ＞（１
０５）を検索（ｓｔｅｐ１３２）し、要求のあった共有
リソースが排他可能かをチェック（ｓｔｅｐ１３３）す
る。 （４）チェックの結果、排他可能であれば排他情報管理
テーブル＜Ｔ＞（１０５）に共有リソース情報、要求元
の計算機情報、要求元のプロセス情報等からなる排他情
報を登録（ｓｔｅｐ１３４−１）しメッセージにＯＫを
設定（ｓｔｅｐ１３４−２）する。排他不可能であれ
ば、メッセージにＮＧを設定（ｓｔｅｐ１３６）する。 （５）ｓｔｅｐ１３１において、排他解除要求であれ
ば、排他情報管理テーブル＜Ｔ＞（１０５）を検索（ｓ
ｔｅｐ１３７）し、解除対象の排他情報を削除（ｓｔｅ
ｐ１３８）し、メッセージに解除完了を設定（ｓｔｅｐ
１３９）する。 （６）メッセージが設定されたら、アプリケーションプ
ロセス１＜ＡＰ１＞（１０８）に対し、メッセージを送
信（ｓｔｅｐ１３５）する。 （７）アプリケーションプロセス１＜ＡＰ１＞（１０
８）は、排他が成功したら、該アプリケーションプロセ
スに対応したエラー処理手段（１１６）をプロセス監視
モニター１＜ＷＰ１＞（１０６）に対して登録（ｓｔｅ
ｐ１２２）する。 （８）プロセス監視モニター１＜ＷＰ１＞（１０６）
は、上記エラー処理手段の登録を受け付け（ｓｔｅｐ１
２６）て、登録を行なう（ｓｔｅｐ１２７）。 （９）アプリケーションプロセス１＜ＡＰ１＞（１０
８）は、登録が完了するとアプリケーション処理を行な
う（ｓｔｅｐ１２３）。 （１０）アプリケーションプロセスの処理が終了する
と、エラー処理手段（１１６）の登録削除をプロセス監
視モニター１＜ＷＰ１＞（１０６）に対して行なう（ｓ
ｔｅｐ１２４）。 （１１）プロセス監視モニター１＜ＷＰ１＞（１０６）
は、登録削除を受け付け（ｓｔｅｐ１２８）て、エラー
処理手段の登録削除を行なう（ｓｔｅｐ１２９）。 （１２）アプリケーションプロセス１＜ＡＰ１＞（１０
８）は、エラー処理手段の登録削除が終ると、排他サー
ビスマネージャ＜ＳＭ＞（１０４）に対し排他解除要求
を行なう（ｓｔｅｐ１２５）。

【００１１】Ｂ．障害発生時の処理 Ｂ．１ 図２のアプリケーション処理実行中（ｓｔｅｐ
１２３）において、アプリケーションプロセス＜ＡＰ１
＞（１０８）に障害が発生した場合の処理について、図
３（ａ）のフローチャート、及び図１に基づいて説明す
る。 （１）プロセス監視モニター１＜ＷＰ１＞（１０６）の
プロセス状態監視部（１１５）が、プロセス異常検知手
段（１１７）によりアプリケーションプロセス＜ＡＰ１
＞に障害が発生したことを検知（ｓｔｅｐ１４０）し、
アプリケーションプロセスの障害発生時の回復処理の為
にエラー処理部（１１６）に対し、エラー処理要求を行
なう（ｓｔｅｐ１４１）。 （２）アプリケーションプロセス障害発生時のエラー処
理部（１１６）は、エラー処理要求を受け付ける（ｓｔ
ｅｐ１４３）と、エラー処理手段が登録されているかを
チェック（ｓｔｅｐ１４４）し、登録されていればエラ
ー処理手段を実行する（ｓｔｅｐ１４５）。 （３）エラー処理手段の実行が終ると、プロセス状態監
視部（１１５）に終了を通知（ｓｔｅｐ１４６）する。 （４）プロセス状態監視部（１１５）は、アプリケーシ
ョンプロセスの障害発生時のエラー処理要求を、障害発
生時の処理内容を記述した排他サービスマネージャ＜Ｓ
Ｍ＞（１０４）のエラー処理部（１１３）に送信（ｓｔ
ｅｐ１４２）する。 （５）排他サービスマネージャ＜ＳＭ＞（１０４）のエ
ラー処理部（１１３）は、これを受信（ｓｔｅｐ１４
７）し、排他情報管理テーブル＜Ｔ＞（１０５）を検索
（ｓｔｅｐ１４８）し、対象アプリケーションプロセス
が保持している排他に対して、排他解除要求を排他制御
部（１１１）に対して行なう（ｓｔｅｐ１４９）。 （６）全ての排他解除が行なわれたら、プロセス状態監
視部（１１５）に完了メッセージを送信（ｓｔｅｐ１５
０）する。

【００１２】Ｂ．２ 排他サービス中に、アプリケーシ
ョンプロセスが搭載された計算機２（１０２）又は計算
機３（１０３）が障害を起こした場合のエラー処理につ
いて、図３（ｂ）のフローチャート、及び図１について
説明する。 （１）排他サービスマネージャ＜ＳＭ＞（１０４）の他
計算機状態監視部（１１２）が、他計算機異常検知手段
（１１４）により障害の発生を検知（ｓｔｅｐ１５１）
し、障害検出時のエラー処理部（１１３）に対し、エラ
ー処理要求を行なう（ｓｔｅｐ１５２）。 （２）排他サービスマネージャ＜ＳＭ＞（１０４）のエ
ラー処理部（１１３）は、他計算機障害検出時のエラー
処理要求を受け付け（ｓｔｅｐ１５５）て、エラー処理
手段が登録されているかをチェック（ｓｔｅｐ１５６）
し、処理手段が予め登録されていれば、エラー処理手段
を実行（ｓｔｅｐ１５７）する。 （３）エラー処理手段の実行が終了すると、終了通知を
他計算機状態監視部（１１２）に対して行なう（ｓｔｅ
ｐ１５８）。 （４）エラー処理要求（ｓｔｅｐ１５２）が完了した
ら、排他情報管理テーブル＜Ｔ＞（１０５）を検索（ｓ
ｔｅｐ１５３）し、対象計算機上のアプリケーションプ
ロセスが保持している排他要求に対して、排他解除要求
を排他制御部（１１１）に対して行なう（ｓｔｅｐ１５
４）。尚、ｓｔｅｐ１５７で実行するエラー処理手段の
排他サービスマネージャ＜ＳＭ＞への登録は、多重計算
機システム運転開始時等の任意の時点で行なわれる。

【００１３】ここでプロセス監視モニタ＜ＷＰ＞（１０
６）のエラー処理部（１１６）と、排他サービスマネー
ジャ＜ＳＭ＞（１０４）のエラー処理部（１１３）に登
録されて実行されるエラー処理内容について詳しく説明
する。エラー処理部（１１６）に登録されて実行される
（例えばｓｔｅｐ１４５）エラー処理手段の例として、
アプリケーションプロセス１＜ＡＰ１＞（１０８）が共
有ファイルをリソースとして排他を行ない、アプリケー
ション処理（ｓｔｅｐ１２３）で共有ファイルの論理的
に関連する複数のレコード操作を行なっている途中で、
アプリケーションプロセス１＜ＡＰ１＞（１０８）が障
害を起こし、途中で処理が中断してしまいレコード間の
一貫性がとれなくなった場合に、アプリケーションのロ
グ情報によりレコードを操作する以前の状態に復元する
処理をエラー処理手段として登録することが考えられ
る。このようにして、エラー処理を行なわずに直ちに排
他解除を行なうとレコード間の一貫性が保てなくなって
しまうという不都合を回避することができる。エラー処
理部（１１３）に登録され実行される（例えば、ｓｔｅ
ｐ１５７）エラー処理手段の例も、（ｓｔｅｐ１４５）
で行なわれるエラー処理手段と基本的に同様であり、例
えばアプリケーションプロセス１＜ＡＰ１＞（１０８）
で前記と同様のアプリケーション処理が行なわれていた
場合に、アプリケーションプロセスが搭載されている計
算機２（１０２）で障害が発生した時は、アプリケーシ
ョンのログ情報によりレコードを操作する以前の状態に
復元する処理を行なった後に、アプリケーションプロセ
ス１＜ＡＰ１＞（１０８）を計算機３（１０３）上で再
起動させる処理をエラー処理手段として登録すること等
が考えられる。

【００１４】実施例２．本発明における実施例２につい
て、図４〜図６に基づいて説明する。図４において、計
算機１（２０１）と計算機２（２０２）は回線（２１
１）により結合された２重計算機システムである。計算
機１（２０１）内には、排他サービスマネージャ１＜Ｓ
Ｍ１＞（２０３）、排他情報管理テーブル１＜Ｔ１＞
（２０５）、プロセス監視モニター１＜ＷＰ１＞（２０
７）、アプリケーションプロセス１＜ＡＰ１＞（２０
９）が搭載されている。一方、計算機２（２０２）内に
は、排他サービスマネージャ２＜ＳＭ２＞（２０４）、
排他情報管理テーブル２＜Ｔ２＞（２０６）、プロセス
監視モニター２＜ＷＰ２＞（２０８）、アプリケーショ
ンプロセス２＜ＡＰ２＞（２１０）が搭載されている。
排他サービスマネージャ１＜ＳＭ１＞（２０３）、排他
サービスマネージャ２＜ＳＭ２＞（２０４）は、図１
（ｂ）で示した排他サービスマネージャ＜ＳＭ＞（１０
４）と同一の構成であり、プロセス監視モニター１＜Ｗ
Ｐ１＞（２０７）、プロセス監視モニター２＜ＷＰ２＞
（２０８）も、図１（ｂ）のプロセス監視モニター１＜
ＷＰ１＞（１０６）と同一の構成である。

【００１５】次に動作について、正常系処理及び障害発
生時の異常系処理に分けてそれぞれ説明する。尚、ここ
では計算機１（２０１）を主計算機、計算機２（２０
２）を従計算機と仮定している。 Ａ．正常系処理 Ａ．１ まず、アプリケーションプロセスが主計算機
（２０１）上に搭載されている場合の動作について、図
５のフローチャート、及び図４について説明する。 （１）アプリケーションプロセス１＜ＡＰ１＞（２０
９）が、共有リソースの排他を行なう場合には、排他サ
ービスマネージャ１＜ＳＭ１＞（２０３）の排他制御部
（１１１）に対して排他要求を出す（ｓｔｅｐ２２
０）。 （２）排他サービスマネージャ１＜ＳＭ１＞（２０３）
は、これを受け付け（ｓｔｅｐ２２３）て、自機が主計
算機か従計算機かをチェック（ｓｔｅｐ２２５）する。 （３）この場合は主計算機なので、次に排他要求か解除
要求かをチェックする（ｓｔｅｐ２２６）。 （４）排他要求の場合には、自機内のテーブル（排他情
報管理テーブル１＜Ｔ１＞（２０５））を検索（ｓｔｅ
ｐ２２７）し、排他可能かをチェックする（ｓｔｅｐ２
２８）。 （５）排他可能であれば、自機内のテーブル（排他情報
管理テーブル１＜Ｔ１＞（２０５））に排他情報を登録
（ｓｔｅｐ２３２）し、次に自機内からの要求かをチェ
ック（ｓｔｅｐ２３３）する。 （６）自機内からの要求であれば、排他サービスマネー
ジャ２＜ＳＭ２＞（２０４）の排他制御部（１１１）に
対して、排他登録要求を送信（ｓｔｅｐ２３６）し、他
機からの要求であれば、単にメッセージにＯＫを設定
（ｓｔｅｐ２３４）する。 （７）ｓｔｅｐ２２８において、排他不可能であればメ
ッセージにＮＧを設定（ｓｔｅｐ２２９）する。 （８）一方、ｓｔｅｐ２２６において、排他解除要求の
場合には、自機内のテーブル（排他情報管理テーブル１
＜Ｔ１＞（２０５））を検索（ｓｔｅｐ２３７）し、排
他情報を削除（ｓｔｅｐ２３８）し、自機内からの要求
かをチェック（ｓｔｅｐ２３９）する。 （９）自機内からの要求であれば、排他サービスマネー
ジャ２＜ＳＭ２＞（２０４）の排他制御部（１１１）に
対して削除要求を送信（ｓｔｅｐ２４１）し、他機から
の要求であれば、単にメッセージに解除完了を設定（ｓ
ｔｅｐ２４０）する。 （１０）メッセージの設定が行なわれたら自機内からの
要求かをチェック（ｓｔｅｐ２３０）し、自機内からの
要求であればアプリケーションプロセス１＜ＡＰ１＞
（２０９）に対しメッセージを通知（ｓｔｅｐ２３１）
し、他機からの要求であれば、排他サービスマネージャ
２＜ＳＭ２＞（２０４）に対し、メッセージを送信（ｓ
ｔｅｐ２３５）する。 （１１）アプリケーションプロセス１＜ＡＰ１＞（２０
９）は排他要求が成功したら、アプリケーション処理を
実行（ｓｔｅｐ２２１）し、一連のアプリケーション処
理終了後、最後に排他解除要求（ｓｔｅｐ２２２）を行
なう。

【００１６】Ａ．１ 次にアプリケーションプロセス
が、従計算機（２０２）上に搭載されている場合の動作
について、図６のフローチャート、及び図４について説
明する。 （１）アプリケーションプロセス２＜ＡＰ２＞（２１
０）が、共有リソースの排他を行なう場合には、排他サ
ービスマネージャ２＜ＳＭ２＞（２０４）の排他制御部
（１１１）に対して排他要求を出す（ｓｔｅｐ２４
２）。 （２）排他サービスマネージャ２＜ＳＭ２＞（２０４）
は、これを受け付け（ｓｔｅｐ２４５）て、自機が主計
算機か、従計算機かをチェック（ｓｔｅｐ２４７）す
る。 （３）この場合は従計算機なので、登録又は削除要求か
をチェック（ｓｔｅｐ２４８）し、登録又は削除要求の
場合、すなわち排他サービスマネージャ１＜ＳＭ１＞
（２０３）からの要求時には（これは、図５のｓｔｅｐ
２４１、又はｓｔｅｐ２３６に対する要求であり、ｓｔ
ｅｐ２４６経由で受信されたものに相当する。）、登録
要求か削除要求かをチェック（ｓｔｅｐ２６４）する。 （４）登録要求であれば、自機内のテーブル（排他情報
管理テーブル２＜Ｔ２＞（２０６））に、排他情報を登
録（ｓｔｅｐ２６５）し、削除要求であれば、自機内の
テーブル（排他情報管理テーブル２＜Ｔ２＞（２０
６））から排他情報を削除（ｓｔｅｐ２６６）する。 （５）ｓｔｅｐ２４８において、排他又は解除要求の場
合（これは、従計算機上のアプリケーションプロセスか
らの要求でありｓｔｅｐ２４５で受付けたものに相当す
る。）には、排他要求か削除要求かをチェック（ｓｔｅ
ｐ２４９）し、排他要求であれば、自機内のテーブル
（排他情報管理テーブル２＜Ｔ２＞（２０６））を検索
（ｓｔｅｐ２５０）し、排他可能かどうかをチェック
（ｓｔｅｐ２５１）する。 （６）排他可能であれば、自機内のテーブル（排他情報
管理テーブル２＜Ｔ２＞（２０６））に排他情報の仮登
録を行ない（ｓｔｅｐ２５４）、主計算機上の排他サー
ビスマネージャ１＜ＳＭ１＞（２０３）の排他制御部
（１１１）に対して、排他要求を送信（ｓｔｅｐ２５
５）する。（上記主サービスマネージャ＜ＳＭ１＞に対
する要求は、図５のｓｔｅｐ２２４で受信され、既に
Ａ．１で説明したようにして処理される。） （７）排他要求送信に対する返答メッセージをチェック
（ｓｔｅｐ２５６）し、ＯＫであれば、自機内のテーブ
ル（排他情報管理テーブル２＜Ｔ２＞（２０６））に仮
登録していた排他情報を本登録（ｓｔｅｐ２５８）し、
メッセージにＯＫを設定（ｓｔｅｐ２５９）する。 （８）ＮＧであれば、自機内のテーブル（排他情報テー
ブル２＜Ｔ２＞（２０６））に仮登録していた排他情報
を削除（ｓｔｅｐ２５７）し、メッセージにＮＧを設定
（ｓｔｅｐ２５２）する。 （９）ｓｔｅｐ２５１で、自機内のテーブル（排他情報
管理テーブル２＜Ｔ２＞（２０６））を検索した時点
で、排他不可能であればメッセージにＮＧを設定（ｓｔ
ｅｐ２５２）する。 （１０）ｓｔｅｐ２４９で解除要求であれば、主計算機
上の排他サービスマネージャ１＜ＳＭ１＞（２０３）の
排他制御部（１１１）に対して、排他解除要求を送信
（ｓｔｅｐ２６０）し、（該要求は、図５のｓｔｅｐ２
２４で受信される。）次に自機内のテーブル（排他情報
管理テーブル２＜Ｔ２＞（２０６））を検索（ｓｔｅｐ
２６１）し、排他情報を削除（ｓｔｅｐ２６２）し、メ
ッセージに”削除”を設定（ｓｔｅｐ２６３）する。 （１１）メッセージが設定されたら、アプリケーション
プロセス２＜ＡＰ２＞（２１０）に対してメッセージを
通知（ｓｔｅｐ２５３）する。 （１２）アプリケーションプロセス２＜ＡＰ２＞（２１
０）は、排他要求が成功した場合にアプリケーション処
理を実行（ｓｔｅｐ２４３）し、アプリケーションの一
連の処理が終了後、最後に排他解除要求を出す（ｓｔｅ
ｐ２４４）。

【００１７】Ｂ．障害発生時の動作 アプリケーションプロセスに対するサービス実行中に、
計算機１（２０１）に障害が発生した場合のエラー処理
について図７のフローチャート、及び図４について説明
する。 （１）排他サービスマネージャ２＜ＳＭ２＞（２０４）
の他計算機状態監視部（１１２）が、他計算機異常検知
手段（１１４）により異常を検知（ｓｔｅｐ２６６）
し、排他サービスマネージャ２＜ＳＭ２＞（２０４）の
障害発生時のエラー処理部（１１３）に対して、エラー
処理要求を行なう（ｓｔｅｐ２６７）。 （２）エラー処理部（１１３）は、エラー処理要求を受
け付け（ｓｔｅｐ２７４）ると、エラー処理手段が登録
されているかをチェック（ｓｔｅｐ２７５）し、エラー
処理手段が登録されていれば、エラー処理手段を実行
（ｓｔｅｐ２７６）し、エラー処理の終了を通知（ｓｔ
ｅｐ２７７）する。 （３）排他サービスマネージャ２＜ＳＭ２＞（２０４）
の他計算機状態監視部（１１２）は、エラー処理終了の
通知を受けたら自機が主計算機か従計算機かをチェック
（ｓｔｅｐ２６８）し、この場合には従計算機であるの
で、自機内のテーブル（排他情報管理テーブル２＜Ｔ２
＞（２０６））を検索（ｓｔｅｐ２７１）し、仮登録の
排他情報を、本登録に変更（ｓｔｅｐ２７２）し、自機
の設定を主計算機に変更（ｓｔｅｐ２７３）する。 （４）次に、自機内のテーブル（排他情報管理テーブル
２＜Ｔ２＞（２０６））を検索（ｓｔｅｐ２６９）し、
相手側計算機、即ちこの場合は計算機１（２０１）が保
持している全ての排他に関して、排他サービスマネージ
ャ２＜ＳＭ２＞（２０４）の排他制御部（１１１）に対
して、排他解除要求を出す（ｓｔｅｐ２７０）。

【００１８】上記、障害発生時における障害回復処理の
動作説明としては、主計算機たる計算機１（２０１）に
障害が発生したと仮定して説明をしてきたが、計算機２
（２０２）に障害が発生した場合も、図７のフローチャ
ートで対応が可能である。また、正常処理動作の実施例
における排他要求処理（図５のｓｔｅｐ２２０、若しく
は、図６のｓｔｅｐ２４２）の後で、エラー処理手段の
登録を実施すれば、実施例１で説明した如く同様の手順
によってアプリケーションプロセスの障害発生に対して
も対処することが可能となる。このようにして、排他情
報管理テーブル１＜Ｔ１＞（２０５）と排他情報管理テ
ーブル２＜Ｔ２＞（２０６）にシステム全体の排他情報
を保持するので、どちらの計算機に障害が発生しても排
他情報が失われることなく、又、排他要求情報も失われ
ることなくサービスを続行できる。

【００１９】実施例３．本発明の実施例３について、図
８〜図１１について説明する。図８（ａ）において、計
算機１（３０１）、計算機２（３０２）、計算機３（３
０３）、計算機４（３０４）、計算機５（３０５）は回
線ＬＡＮ（３１５）によって結合された多重計算機シス
テムであり、計算機１（３０１）は、排他サービスマネ
ージャ１＜ＳＭ１＞（３０６）及び排他情報管理テーブ
ル１＜Ｔ１＞（３０８）より構成されている。一方、計
算機２（３０２）は、排他サービスマネージャ２＜ＳＭ
２＞（３０７）と排他情報管理テーブル２＜Ｔ２＞（３
０９）より構成されており、上記排他サービスマネージ
ャは図８（ｂ）に示すように排他制御部（３１６）とエ
ラー処理部（３１７）より構成されている。計算機３
（３０３）内には図８（ｂ）に示すように排他要求キュ
ー（３２１）、排他要求処理部（３１８）、他計算機状
態監視部（３１９）、異常時のエラー処理部（３２０）
により構成された排他要求マネージャ＜ＲＭ＞（３１
０）が搭載されている。計算機４（３０４）、及び計算
機５（３０５）内には、アプリケーションプロセス１＜
ＡＰ１＞（３１３）及びアプリケーションプロセス２＜
ＡＰ２＞（３１４）と、プロセス監視モニター１＜ＷＰ
１＞（３１１）、及びプロセス監視モニター２＜ＷＰ２
＞（３１２）がある。ここでプロセス監視モニター１＜
ＷＰ１＞（３１１）と、プロセス監視モニター２＜ＷＰ
２＞（３１２）は、図１（ｂ）のプロセス監視モニター
１＜ＷＰ１＞（１０６）と同じ構成である。

【００２０】前記のように構成された多重計算機システ
ムにおいて、詳細動作の説明に入る前に、まづ図９に基
づいて実施例３の概念について説明する。アプリケーシ
ョンプロセス１＜ＡＰ１＞（３１３）が共有リソースの
排他を行なう際には、排他要求マネージャ＜ＲＭ＞（３
１０）の排他要求処理部（３１８）に排他要求を送信し
（６０１）、排他要求処理部（３１８）は要求をキュー
に保存して、排他サービスマネージャ１＜ＳＭ１＞（３
０６）と排他サービスマネージャ２＜ＳＭ２＞（３０
７）の両方に排他要求を送信する（６０２，６０３）。
排他サービスマネージャ１＜ＳＭ１＞（３０６）と排他
サービスマネージャ２＜ＳＭ２＞（３０７）は、各々排
他制御処理を行なった後に、排他要求マネージャ＜ＲＭ
＞（３１０）の排他要求処理部（３１８）に回答を返信
する（６０４，６０５）。この際、排他要求マネージャ
＜ＲＭ＞は、主側（排他サービスマネージャ１＜ＳＭ１
＞（３０６））から返信を受けた時点で、アプリケーシ
ョンプロセス１＜ＡＰ１＞（３１３）に回答を返信する
（６０６）。尚、排他要求処理部（３１８）における要
求をキューに入れる目的は、排他サービスマネージャ１
＜ＳＭ１＞（３０６）と排他サービスマネージャ２＜Ｓ
Ｍ２＞（３０７）の、どちらから返信が来たかをチェッ
クすることにより、排他サービスマネージャ＜ＳＭ＞の
搭載されている計算機１（３０１）、又は計算機２（３
０２）に障害が発生した際に、アプリケーションプロセ
スに対して回答を送信したか否かをチェックし、適切な
エラー処理を行なうためである。その概念を図９（ｂ）
で示す。図に示すように、排他サービスマネージャ＜Ｓ
Ｍ＞が搭載された計算機が障害を起こした場合のキュー
の状態には、Ｓ（１）〜Ｓ（６）のいずれかが対応して
いる。ここで、状態がＳ（３）、及びＳ（６）は、排他
要求マネージャ＜ＲＭ＞が主計算機、従計算機どちらの
排他サービスマネージャ＜ＳＭ＞からも回答を受信して
いないことを示す。状態Ｓ（１）の場合は、主側排他サ
ービスマネージャ＜ＳＭ＞からは、もはや回答が来るこ
とがないので従側排他サービスマネージャの情報を元に
アプリケーションプロセスに回答を送信する。状態Ｓ
（２）の場合は、従側排他サービスマネージャ＜ＳＭ＞
からは回答が来てないが、主側排他サービスマネージャ
＜ＳＭ＞からは回答を既に受けとっている。すなわちア
プリケーションプロセスへの回答は送信済みなので、こ
れまでの従計算機を主計算機に切り換えた後で（新）主
計算機からの回答受信によって、アプリケーションプロ
セスへ再度回答を送信するのを防止するため、“回答送
信済み”のマークを付ける。状態Ｓ（４）は、既に回答
を受信済みの従側排他サービスマネージャ＜ＳＭ＞に障
害が発生し、主側排他サービスマネージャ＜ＳＭ＞から
の回答を待っている状態である。状態Ｓ（５）は、既に
主側排他サービスマネージャ＜ＳＭ＞からは回答を受信
してアプリケーションプロセスへ回答を送信済みであ
り、従側排他サービスマネージャ＜ＳＭ＞からは、もは
や回答を受信することはないので、キューから削除す
る。以上が実施例３の概念説明である。

【００２１】次に動作について、正常系処理及び障害発
生時の異常系処理に分けてそれぞれ説明する。尚、ここ
では、図８のように構成された多重計算機システムにお
いて、排他サービスマネージャ１＜ＳＭ１＞（３０６）
を主、排他サービスマネージャ２＜ＳＭ２＞（３０７）
を従の排他サービスマネージャと仮定している。 Ａ．正常系処理 図１０のフローチャート、及び図８について説明する。 （１）アプリケーションプロセス１＜ＡＰ１＞（３１
３）が、共有リソースの排他を行なう際には、回線ＬＡ
Ｎ（３１５）を介して排他要求マネージャ＜ＲＭ＞（３
１０）の排他要求処理部（３１８）に排他要求を送信
（ｓｔｅｐ３３０）する。 （２）排他要求処理部（３１８）は、排他要求を受信
（ｓｔｅｐ３３３）すると排他要求キュー（３２１）に
要求キュー登録（ｓｔｅｐ３３４）し、主側排他サービ
スマネージャ１＜ＳＭ１＞（３０６）と、従側排他サー
ビスマネージャ２＜ＳＭ２＞（３０７）の両方共に要求
を送信（ｓｔｅｐ３３５）する。 （３）排他サービスマネージャ１＜ＳＭ１＞（３０６）
の排他制御部（３１６）は、要求を受信（ｓｔｅｐ３４
７）すると、要求が、排他か解除かをチェック（ｓｔｅ
ｐ３４８）する。 （４）排他要求の場合には、自機内のテーブル（排他情
報管理テーブル１＜Ｔ１＞（３０８））を検索（ｓｔｅ
ｐ３４９）し、排他可能かチェック（ｓｔｅｐ３５０）
する。 （５）排他可能であれば、自機内のテーブル（排他情報
管理テーブル１＜Ｔ１＞（３０８））に排他情報を登録
（ｓｔｅｐ３５１）し、メッセージにＯＫを設定（ｓｔ
ｅｐ３５２）する。排他が不可能であれば、メッセージ
にＮＧを設定（ｓｔｅｐ３５４）する。 （６）ｓｔｅｐ３４８で排他解除要求の場合には、自機
内のテーブル（排他情報管理テーブル＜Ｔ１＞（３０
８）を検索（ｓｔｅｐ３５５）し、対象の排他情報を削
除（ｓｔｅｐ３５６）し、メッセージに、解除完了を設
定（ｓｔｅｐ３５７）する。 （７）メッセージが設定されたら、排他要求マネージャ
＜ＲＭ＞（３１０）の排他要求処理部（３１８）にメッ
セージを送信（ｓｔｅｐ３５３）する。従排他サービス
マネージャ２＜ＳＭ２＞（３０７）も、同様の動作をす
る。 （８）排他要求マネージャ＜ＲＭ＞（３１０）の排他要
求処理部（３１８）は、回答メッセージを受信（ｓｔｅ
ｐ３３６）したら、主従、どちらの排他サービスマネー
ジャ＜ＳＭ＞からの回答かをチェック（ｓｔｅｐ３３
７）する。 （９）主側排他サービスマネージャ＜ＳＭ１＞（３０
６）からの回答メッセージであれば、排他要求キュー
（３２１）上の回答に対する要求情報を検索（ｓｔｅｐ
３３８）し、従側から回答受信済みのマークが記入され
ているかをチェック（ｓｔｅｐ３３９）し、回答受信が
記入されていれば、その要求情報をキューから削除（ｓ
ｔｅｐ３４０）し、記入されていなければ、主から回答
受信済みのマークを記入（ｓｔｅｐ３４２）した後に、
回答送信済みかをチェック（ｓｔｅｐ３４１−１）し、
未送信であれば、アプリケーションプロセス１＜ＡＰ１
＞（３１３）に対して回答を送信し（ｓｔｅｐ３４１−
３）、回答済みであれば何もしない（ｓｔｅｐ３４１−
２）。 （１０）回答が主側からでなければ、排他要求キュー
（３２１）上の回答に対する要求情報を検索（ｓｔｅｐ
３４３）し、主側から回答受信済みのマークが記入され
ているかをチェック（ｓｔｅｐ３４４）し、記入されて
いれば、その要求情報をキューから削除（ｓｔｅｐ３４
５）し、記入されていなければ、従側から回答受信済み
のマークを記入（ｓｔｅｐ３４６）する。 （１１）アプリケーションプロセス１＜ＡＰ１＞（３１
３）は、排他が成功すると一連のアプリケーション処理
を実行（ｓｔｅｐ３３１）した後、排他要求マネージャ
＜ＲＭ＞（３１０）の排他要求処理部（３１８）に、排
他解除要求を出す（ｓｔｅｐ３３２）。

【００２２】Ｂ．障害発生時の動作 アプリケーションプロセスに対するサービス実行中に、
計算機１（３０１）、計算機２（３０２）、計算機４
（３０４）、計算機５（３０５）に障害が発生した場合
の処理について、図１１のフローチャート、及び図８に
ついて説明する。 （１）排他要求マネージャ＜ＲＭ＞（３１０）の他計算
機状態監視部（３１９）が、他計算機異常検知手段（２
０６）により障害発生を検知（ｓｔｅｐ３６０）し、障
害発生時のエラー処理部（３２０）に対し、エラー処理
要求（ｓｔｅｐ３６１）を行なう。 （２）エラー処理部（３２０）は、エラー処理要求を受
け付け（ｓｔｅｐ３９５）ると、障害発生時におけるエ
ラー処理手段が登録されているか否かををチェック（ｓ
ｔｅｐ３９６）し、処理手段が登録されていれば、エラ
ー処理手段を実行（ｓｔｅｐ３９７）し、他計算機状態
監視部（３１９）に対し、終了通知（ｓｔｅｐ３９８）
を行なう。 （３）排他要求マネージャ＜ＲＭ＞（３１０）の他計算
機状態監視部（３１９）は、エラー処理要求が終了した
ら、障害を起こしたのが排他サービスマネージャ１＜Ｓ
Ｍ１＞（３０６）、又は排他サービスマネージャ２＜Ｓ
Ｍ２＞（３０７）が搭載されているサービス計算機か否
かをチェック（ｓｔｅｐ３６２）する。 （４）サービス計算機であれば、異常を起こしたのが主
側、従側計算機のいずれかをチェック（ｓｔｅｐ３６
４）する。主側計算機が異常を起こしたのであれば、排
他要求キュー（３２１）を検索（ｓｔｅｐ３６８）し、
全ての要求キューに対して従側排他サービスマネージャ
＜ＳＭ２＞から回答受信済みかをチェック（ｓｔｅｐ３
６９）する。 （５）従側排他サービスマネージャ＜ＳＭ２＞からの回
答受信済みのマークが記入されていれば、主側排他サー
ビスマネージャ＜ＳＭ１＞からは、もはや回答を受信す
ることはないので、その情報からアプリケーションプロ
セスに対して要求の回答を送信（ｓｔｅｐ３７３）し、
排他要求キュー（３２１）よりキューを削除（ｓｔｅｐ
３７４）する。従側排他サービスマネージャ＜ＳＭ２＞
から回答受信済みでなければ、主側から回答受信済みか
をチェック（ｓｔｅｐ３７０）し、主側から回答受信済
みであれば、アプリケーションプロセスに対しては既に
回答送信済みなので回答送信済みのマークを記入（ｓｔ
ｅｐ３７２）し、従計算機を主計算機に設定を変更（ｓ
ｔｅｐ３７１）する。（ここで、主側、従側いずれの計
算機からも未だ回答を受信していなかった場合について
は、ｓｔｅｐ３７１でそれまでの従計算機がここで主計
算機に設定変更されたので、この主計算機（設定変更後
の）から、いずれ回答が来て、アプリケーションプロセ
スに回答が送信されるというプロセスをとる。） （６）ｓｔｅｐ３６４で従側計算機が障害を起こしたの
であれば、排他要求キュー（３２１）を検索（ｓｔｅｐ
３６５）し、主側排他サービスマネージャ＜ＳＭ１＞か
ら回答受信済みかをチェック（ｓｔｅｐ３６６）し、回
答受信済みであれば、既にアプリケーションプロセスに
対しては回答送信済みであるので排他要求キュー（３２
１）よりその要求キューを削除する（ｓｔｅｐ３６７）
だけである。 （７）次いで、サービス計算機が障害を起こしたのでな
ければ（アプリケーションプロセス搭載機に障害発
生）、排他サービスマネージャ１＜ＳＭ１＞（３０
６）、及び排他サービスマネージャ２＜ＳＭ２＞（３０
７）の両方のエラー処理部（３１７）に対して、障害を
起こした計算機に関する排他を全て解除するための要求
を送信（ｓｔｅｐ３６３）する。サービス計算機が異常
を起こした場合においても、排他サービスマネージャ１
＜ＳＭ１＞（３０６）、又は排他サービスマネージャ２
＜ＳＭ２＞（３０７）の健在な方のエラー処理部（３１
７）に対して障害を起こした計算機に関する排他を全て
解除する要求を送信（ｓｔｅｐ３６３）する。 （８）排他サービスマネージャ１＜ＳＭ１＞（３０
６）、又は排他サービスマネージャ２＜ＳＭ２＞（３０
７）のエラー処理部（３１７）は要求を受信（ｓｔｅｐ
３７５）し、排他情報管理テーブル１＜Ｔ１＞（３０
８）又は排他情報管理テーブル２＜Ｔ２＞（３０９）を
検索（ｓｔｅｐ３７６）し、障害を起こした計算機上の
アプリケーションが保持する排他の解除要求を、排他制
御部（３１６）に対して行なう（ｓｔｅｐ３７７）。上
記の例では、排他サービスマネージャを主／従に分けて
主側を優先する例になっているが、排他サービスマネー
ジャを３重化し、多数決方式で排他の可否を決定するこ
とも可能である。このようにして排他サービスを行なう
計算機のどれかに異常が発生しても排他情報、及び排他
要求情報は失われることなくサービスが続行できる。

【００２３】実施例４．本発明の実施例４について、図
１２〜図１６について説明する。図１２において、計算
機１（４０１）、計算機２（４０２）、計算機３（４０
３）、計算機４（４０４）、計算機５（４０５）、計算
機６（４０６）は、回線ＬＡＮ（４１７）により結合さ
れた多重計算機システムである。計算機１（４０１）、
及び計算機２（４０２）内には排他サービスマネージャ
１＜ＳＭ１＞（４０７）及び排他サービスマネージャ２
＜ＳＭ２＞（４０８）と、排他情報管理テーブル１＜Ｔ
１＞（４０９）及び排他情報管理テーブル２＜Ｔ２＞
（４１０）が搭載されている。計算機３（４０３）及び
計算機６（４０６）内には、排他要求マネージャ１＜Ｒ
Ｍ１＞（４１１）及び排他要求マネージャ２＜ＲＭ２＞
（４１２）が搭載されている。計算機４（４０４）及び
計算機５（４０５）内には、プロセス監視モニター１＜
ＷＰ１＞（４１３）及びプロセス監視モニター２＜ＷＰ
２＞（４１４）と、アプリケーションプロセス１＜ＡＰ
１＞（４１５）及びアプリケーションプロセス２＜ＡＰ
２＞（４１６）が存在している。ここで、排他サービス
マネージャ１＜ＳＭ１＞（４０７）及び排他サービスマ
ネージャ２＜ＳＭ２＞（４０８）は、図８（ｂ）の排他
サービスマネージャ１＜ＳＭ１＞（３０６）と同様の構
成であり、排他要求マネージャ１＜ＲＭ１＞（４１１）
及び排他要求マネージャ２＜ＲＭ２＞（４１２）も同じ
く図８（ｂ）の排他要求マネージャ＜ＲＭ＞（３１０）
と同様の構成であり、プロセス監視モニター１＜ＷＰ１
＞（４１３）及びプロセス監視モニター２＜ＷＰ２＞
（４１４）は、図１（ｂ）のプロセス監視モニター１＜
ＷＰ１＞（１０６）と同様の構成である。

【００２４】以上のように構成された多重計算機システ
ムにおいて、詳細動作の説明に入る前に、まづ図１３に
基づいて実施例４の概念について説明する。尚、ここで
は、＜ＲＭ１＞（４１１）を主排他要求マネージャ、＜
ＲＭ２＞（４１２）を従排他要求マネージャとし、また
＜ＳＭ１＞（４０７）を主排他サービスマネージャ、＜
ＳＭ２＞（４０８）を従排他サービスマネージャとして
説明を進める。アプリケーションプロセス１＜ＡＰ１＞
（４１５）が、共有リソースの排他を行なう際には、排
他要求マネージャ１＜ＲＭ１＞（４１１）及び排他要求
マネージャ２＜ＲＭ２＞（４１２）の双方に排他要求を
送信する（７０１，７０２）。排他要求マネージャ１＜
ＲＭ１＞（４１１）及び排他要求マネージャ２＜ＲＭ２
＞（４１２）は、各々要求をキューに保存する。排他要
求マネージャ１＜ＲＭ１＞（４１１）は、排他サービス
マネージャ１＜ＳＭ１＞（４０７）及び排他サービスマ
ネージャ２＜ＳＭ２＞（４０８）に要求を送信する（７
０３，７０４）。排他サービスマネージャ１＜ＳＭ１＞
（４０７）と排他サービスマネージャ２＜ＳＭ２＞（４
０８）は、各々排他制御処理を行なった後に、排他要求
マネージャ１＜ＲＭ１＞（４１１）に回答を送信する
（７０５，７０６）。排他要求マネージャ１＜ＲＭ１＞
（４１１）は、その回答をアプリケーションプロセス１
＜ＡＰ１＞（４１５）に送信する（７０７）と共に排他
要求マネージャ２＜ＲＭ２＞（４１２）に転送する。
（７０８）尚、主側排他要求マネージャ＜ＲＭ＞の存在
する計算機に障害が発生した場合には、従側排他要求マ
ネージャ＜ＲＭ＞の保持するキュー情報と排他サービス
マネージャ＜ＳＭ＞が最後に処理した要求（ＬＲ）を元
にエラー処理を行なう。その概念を図１９（ｂ）で示
す。主側＜ＲＭ＞が障害を起こした時の従側＜ＲＭ＞の
キューの状態と、主側＜ＳＭ＞が最後に処理した要求Ｌ
Ｒ１と、従側＜ＳＭ＞が最後に処理した要求ＬＲ２の組
合せは状態Ｓ（１）〜Ｓ（６）の様になる。図中の○は
主側、従側それぞれの排他サービスマネージャ＜ＳＭ＞
からの回答受信済みのマークを、×は回答未受信のマー
クを、また？印は排他サービスマネージャ＜ＳＭ＞側か
らは回答を送出しているにも拘らず、従側排他要求マネ
ージャ＜ＲＭ＞側では、その受信を確認していないこと
を示し、破線で囲まれた部分（７１０）は、既に削除さ
れたキューを示している。Ｓ（１）は、主側＜ＳＭ＞か
らの回答受信が、従側＜ＳＭ＞からの回答受信よりも先
行している状態で主側＜ＲＭ＞に障害が発生し、この為
に、主側＜ＳＭ＞、及び従側＜ＳＭ＞から主側＜ＲＭ＞
へ既に送出された回答が途中で消失したことを示してい
る。Ｓ（２）は、Ｓ（１）とは逆のケースで、従側＜Ｓ
Ｍ＞からの回答受信が先行している状態で、主側＜ＲＭ
＞に障害が発生した為に、既に主従＜ＳＭ＞から主側＜
ＲＭ＞へ送出されていた回答が途中で消失し、従側＜Ｒ
Ｍ＞に到着しなかったことを示す。Ｓ（３）は、主側＜
ＳＭ＞、及び従側＜ＲＭ＞からの回答受信が同じペース
で進行し、主側＜ＳＭ＞、従側＜ＳＭ＞が主側＜ＲＭ＞
に回答を送出した後で、主側＜ＲＭ＞に障害が発生した
ため、従側＜ＲＭ＞に届かなかった事を示している。Ｓ
（６）は、主側、及び従側＜ＳＭ＞からの回答が両方と
も従側＜ＲＭ＞へ到着して、キューから削除されたこと
を示している。Ｓ（４）は、主側＜ＳＭ＞の処理が先行
しており、従側＜ＳＭ＞処理終了相当分までの回答は、
従側＜ＲＭ＞へ到着し、キューから削除されたが、主側
＜ＳＭ＞の先行処理分の回答が主側＜ＲＭ＞障害のた
め、途中で消失したことを示す。Ｓ（５）は、Ｓ（４）
とは逆のケースで、従側＜ＳＭ＞の先行処理分の回答が
途中で消失したことを示す。従って、考え方としては、
ＬＲ１の情報をアプリケーションプロセスに回答として
送信し、ＬＲ２の情報は従側＜ＳＭ＞から回答受信済み
マーク記入に使用して、必要ならキューを削除する。Ｌ
Ｒより後方のキュー（７０９）は、主側＜ＲＭ＞が排他
サービスマネージャ＜ＳＭ＞に要求を出せなかった部分
なので、＜ＳＭ＞に要求を送信するのに使用する。この
ようにして要求と回答が消失するのを防いでいる。

【００２５】次に動作について、正常系処理及び障害発
生時の異常系処理に分けてそれぞれ説明する。尚、ここ
では図のように構成された多重計算機システムにおい
て、排他サービスマネージャ１＜ＳＭ１＞（４０７）を
排他サービスマネージャの主側、排他サービスマネージ
ャ２＜ＳＭ２＞（４０８）を排他サービスマネージャの
従側とし、排他要求マネージャ１＜ＲＭ１＞（４１１）
を排他要求マネージャの主側、排他要求マネージャ２＜
ＲＭ２＞（４１２）を排他要求マネージャの従側と仮定
している。 Ａ．正常系処理 図１４のフローチャート、及び図１２について説明す
る。 （１）アプリケーションプロセス１＜ＡＰ１＞（４１
５）が共有リソースの排他を行なう際には、回線ＬＡＮ
（４１７）を介して排他要求マネージャ１＜ＲＭ１＞
（４１１）、及び排他要求マネージャ２＜ＲＭ２＞（４
１２）の双方に排他要求を送信（ｓｔｅｐ４２１）す
る。 （２）排他要求マネージャ１＜ＲＭ１＞（４１１）の排
他要求処理部（３１８）は、要求を受信（ｓｔｅｐ４２
４）し、自機が主側か否かをチェック（ｓｔｅｐ４２
５）する。 （３）主側でなければ（すなわち従側であれば）、排他
要求キュー（３２１）に要求を登録（ｓｔｅｐ４２６）
する。主側であれば、排他要求キュー（３２１）に要求
を登録（ｓｔｅｐ４２７）し、排他サービスマネージャ
１＜ＳＭ１＞（４０７）、及び排他サービスマネージャ
２＜ＳＭ２＞（４０８）の両方に要求を送信（ｓｔｅｐ
４２８）する。 （４）排他サービスマネージャ１＜ＳＭ１＞（４０７）
の排他制御部（３１６）は、要求を受信（ｓｔｅｐ４３
９）し、その要求をＬＲ（ラスト・リクエスト）として
記憶（ｓｔｅｐ４４０）する。 （５）次に要求が、排他か解除かをチェック（ｓｔｅｐ
４４１）し、排他要求であれば、排他情報管理テーブル
１＜Ｔ１＞（４０９）を検索（ｓｔｅｐ４４２）し、排
他可能かどうかをチェック（ｓｔｅｐ４４３）し、排他
可能であれば、排他情報管理テーブル１＜Ｔ１＞（４０
９）に排他情報を登録（ｓｔｅｐ４４４）し、メッセー
ジにＯＫを設定（ｓｔｅｐ４４５）する。ｓｔｅｐ４４
３で、排他不可能であればメッセージにＮＧを設定（ｓ
ｔｅｐ４４７）する。 （６）ｓｔｅｐ４４１で解除要求であれば、排他情報管
理テーブル１＜Ｔ１＞（４０９）を検索（ｓｔｅｐ４４
８）し、対象の排他情報を削除（ｓｔｅｐ４４９）し、
メッセージに、解除完了を設定（ｓｔｅｐ４５０）す
る。 （７）メッセージが設定されたら、メッセージ内容をＬ
Ｒに追記（ｓｔｅｐ４４６−１）し、主側の排他要求マ
ネージャである排他要求マネージャ１＜ＲＭ１＞（４１
１）に対してのみメッセージを送信する（ｓｔｅｐ４４
６−２）。 （８）排他要求マネージャ１＜ＲＭ１＞（４１１）は回
答メッセージを受信（ｓｔｅｐ４２９）すると、排他サ
ービスマネージャの主側からの回答かをチェック（ｓｔ
ｅｐ４３０）する。 （９）主側からの回答であれば、排他要求キュー（３２
１）を検索（ｓｔｅｐ４３１）し、従側からの回答受信
済みのマークが記入されているかをチェック（ｓｔｅｐ
４３２）し、回答受信済みであれば排他要求キュー（３
２１）から要求キューを削除（ｓｔｅｐ４３３）する。
従側から未回答であれば、主側からの回答受信済みのマ
ークを記入（ｓｔｅｐ４３７）する。 （１０）自機が、排他要求マネージャの主側であるかを
チェック（ｓｔｅｐ４３４）し、従側であればなにもせ
ず（ｓｔｅｐ４３８）に、主側であれば、回答送信済み
かをチェック（ｓｔｅｐ４３５−１）し、未送信であれ
ば、回答をアプリケーションプロセス１＜ＡＰ１＞（４
１５）に送信（ｓｔｅｐ４３５−２）する。 （１１）従側の排他要求マネージャに回答を転送（ｓｔ
ｅｐ４３６）する。 （１２）ｓｔｅｐ４３０で回答メッセージが、従側の排
他サービスマネージャからのものであれば、排他要求キ
ュー（３２１）を検索（ｓｔｅｐ４５１）し、主側から
の回答受信済みかをチェック（ｓｔｅｐ４５２）し、主
側からの回答受信済みであれば、排他要求キュー（３２
１）より対象要求キューを削除（ｓｔｅｐ４５３）し、
主側から未回答であれば、従側から回答受信済みのマー
クを記入（ｓｔｅｐ４５６）する。 （１３）自機が、主側か従側かをチェック（ｓｔｅｐ４
５４）し、主側であれば、回答を従側の排他要求マネー
ジャに回答を転送（ｓｔｅｐ４５５）し、自機が従側で
あれば何もしない（ｓｔｅｐ４５７）。 （１４）排他要求が成功すると、アプリケーションプロ
セス１＜ＡＰ１＞（４１５）は、一連のアプリケーショ
ン処理を実行（ｓｔｅｐ４２２）した後、排他解除要求
を出す（ｓｔｅｐ４２３）。

【００２６】Ｂ．障害発生時の動作 アプリケーションプロセスに対するサービス実行中に障
害が発生した計算機を主側排他要求マネージャ１＜ＲＭ
１＞（４１１）が検知した場合を図１５について、又従
側排他要求マネージャ２＜ＲＭ２＞（４１２）が検知し
た場合を図１６について各々説明する。 Ｂ．１ 主側排他要求マネージャが検知した場合 （１）サービス中に計算機に異常が発生し、排他要求マ
ネージャ１＜ＲＭ１＞（４１１）の他計算機異常検知手
段（１１４）により他計算機状態監視部（３１９）が、
障害を検知（ｓｔｅｐ４５８）すると、自機が主側か否
かをチェック（ｓｔｅｐ４５９）し、主側であれば、異
常時のエラー処理部（３２０）にエラー処理要求を送る
（ｓｔｅｐ４６０）。異常時のエラー処理部（３２０）
は、実施例３の（ｓｔｅｐ３７５）から（ｓｔｅｐ３７
８）と同じ手順で処理を行なう。 （２）エラー処理が終ると、障害を起こした計算機が排
他サービスマネージャ１＜ＳＭ１＞（４０７）か、排他
サービスマネージャ２＜ＳＭ２＞（４０８）か、排他要
求マネージャ１＜ＲＭ１＞（４１１）か、あるいは排他
要求マネージャ２＜ＲＭ２＞（４１２）が搭載されたサ
ービス計算機であるか否かをチェック（ｓｔｅｐ４６
１）し、サービス計算機であれば、排他サービスマネー
ジャの存在する計算機か、排他要求マネージャの存在す
る計算機かをチェック（ｓｔｅｐ４６４）する。 （３）障害発生計算機が、排他サービスマネージャの存
在する計算機であれば、主側の排他サービスマネージャ
が搭載された計算機かをチェック（ｓｔｅｐ４６５）
し、主側＜ＳＭ＞に障害が発生したのであれば、排他要
求キュー（３２１）を検索（ｓｔｅｐ４６９）し、従側
＜ＳＭ＞から回答受信済みかをチェック（ｓｔｅｐ４７
０）し、従側から回答受信済みであれば（主側＜ＳＭ＞
からの回答待ちの状態で、主側＜ＳＭ＞に障害が発生し
てしまった状態なので）、アプリケーションプロセスに
対し回答を送信（ｓｔｅｐ４７４）して、排他要求キュ
ー（３２１）より対象要求キューを削除する（ｓｔｅｐ
４７５）。 （４）ｓｔｅｐ４７０において、従側＜ＳＭ＞から未回
答であれば、主側＜ＳＭ＞から回答受信済みかをチェッ
ク（ｓｔｅｐ４７１）し、主側＜ＳＭ＞から回答受信済
みであれば、（既にアプリケーションプロセスには回答
を送信済みであり、現時点で従側＜ＳＭ＞から回答が届
いていないという事は、この後のｓｔｅｐ４７２で従側
＜ＳＭ＞を”主”に変更する。すると、＜ＲＭ＞の排他
要求処理部は旧の従側＜ＳＭ＞からの回答を、主＜ＳＭ
＞からの回答として受信することとなり、再びアプリケ
ーションプロセスに回答を送信することになるので、こ
れを抑止する為に）回答送信済みマークを記入（ｓｔｅ
ｐ４７３）する。主側＜ＳＭ＞から未回答であった場合
には、なにもせずに排他サービスマネージャの従側の設
定を主側に変更する（ｓｔｅｐ４７２）。（この場合に
は、＜ＲＭ＞の排他要求処理部は、設定変更された新主
側＜ＳＭ＞から回答を受信することになる。） （５）ｓｔｅｐ４６５で、障害を起こしたのが従側の排
他サービスマネージャであれば、排他要求キュー（３２
１）を検索（ｓｔｅｐ４６６）し、主側＜ＳＭ＞から回
答送信済みであれば（単に従側＜ＳＭ＞からの回答待ち
の状態であったので）その要求キューを排他要求キュー
（３２１）より削除する（ｓｔｅｐ４６８）。（主側＜
ＳＭ＞からの回答を未受信の場合は、＜ＲＭ＞排他要求
処理部が、やがてこれを受信するので、ここではＮＯＰ
でよい。） （６）ｓｔｅｐ４６１でサービス計算機以外（アプリケ
ーションプロセス搭載機）に障害が発生したのであれ
ば、排他サービスマネージャ１＜ＳＭ１＞（４０７）、
及び排他サービスマネージャ２＜ＳＭ２＞（４０８）の
エラー処理部（３１７）に対し、異常を起こした計算機
内のアプリケーションが保持している排他を全て解除す
るように要求する（ｓｔｅｐ４６２）。排他サービスマ
ネージャ１＜ＳＭ１＞（４０７）、及び排他サービスマ
ネージャ２＜ＳＭ２＞（４０８）のエラー処理部（３１
７）は、これを実施例３の（ｓｔｅｐ３７５）から（ｓ
ｔｅｐ３７７）と同様の手順で処理する。

【００２７】Ｂ．２ 従側排他要求マネージャが検知し
た場合 （１）排他要求マネージャ２＜ＲＭ２＞（４１２）の他
計算機異常検知手段（１１４）により他計算機状態監視
部（３１９）が、障害を検知（ｓｔｅｐ４５８）する
と、自機が従側なので、まず、排他要求マネージャの主
側に障害が発生したのかをチェック（ｓｔｅｐ８００）
する。 （２）排他要求マネージャの主側が障害を起こしたので
なければ、何もしない（ｓｔｅｐ８０１）。（これは主
側の排他要求マネージャが、同様に障害を検知し処理を
行なう為である。） （３）排他要求マネージャの主側に障害が発生したので
あれば、障害発生時の処理を記述したエラー処理部（３
２０）に対しエラー処理要求を行なう（ｓｔｅｐ８０
２）。 （４）エラー処理が終了すると、排他サービスマネージ
ャ１＜ＳＭ１＞（４０７）の排他制御部（３１６）に対
して、最後に処理した要求の情報を送るように問い合わ
せを送信（ｓｔｅｐ８０３）する。 （５）問い合わせを受信（ｓｔｅｐ８１５）した排他制
御部（３１６）は、（ｓｔｅｐ４４０）で記憶したＬＲ
を返信（ｓｔｅｐ８１６）する。 （６）ＬＲを受けた排他要求マネージャ２＜ＲＭ２＞
（４１２）は、これをＬＲ１に入れる（ｓｔｅｐ８０
３）。 （７）次に排他サービスマネージャ２＜ＳＭ２＞（４０
８）の排他制御部（３１６）に対して、最後に処理した
要求の情報を送るように問い合わせを送信（ｓｔｅｐ８
０４）し、（ｓｔｅｐ８１５，８１６）と同様の手順で
ＬＲを得ると、これをＬＲ２に入れる（ｓｔｅｐ８０
４）。 （８）従側＜ＲＭ＞上の要求キューを検索し、ＬＲ１に
対応するキューがあるかをチェック（ｓｔｅｐ８０５）
する。 （９）ＬＲ１に対応したキューがあれば、次にＬＲ２に
対応するキューがあるかをチェック（ｓｔｅｐ８０６）
する。ＬＲ１、ＬＲ２に対応するキューが両方とも存在
していた場合（図１３（ｂ）のＳ（１）、Ｓ（２）、Ｓ
（３）が相当）には、次にＬＲ１がＬＲ２よりキューの
後方にあるかをチェック（ｓｔｅｐ８０７）する。 （１０）ＬＲ１がＬＲ２より後方にあれば、（この状態
は図１３（ｂ）のＳ（１）に対応し、主側＜ＳＭ＞から
の受信が先行していて、アプリケーションプロセスに対
しては回答送信済みの状態であり、従側＜ＳＭ＞も既に
回答送信はしていたが、従側＜ＲＭ＞に到着しなかった
状況に相当するので）まずＬＲ２に対応するキューを削
除（ｓｔｅｐ８０８）する。 （１１）次に、ＬＲ１に対応するキューが主側＜ＳＭ＞
から回答受信済みであるかをチェック（ｓｔｅｐ８０
９）し、回答が確認できなければ（？印の状態で途中で
回答が消失した場合に相当。）ＬＲ１の情報を元に、ア
プリケーションプロセスに対して回答を送信（ｓｔｅｐ
８１０）し、ＬＲ１に対応するキューに、主側回答受信
済みのマークを記入（ｓｔｅｐ８１１）する。そして、
ＬＲ１の一つ後ろのキューを、Ｍ（７０９）とする。
（ｓｔｅｐ８１２）Ｍ（７０９）に相当するキュー内容
は、主側＜ＲＭ＞が排他サービスマネージャ＜ＳＭ＞に
対して、要求を出せなかったものである。 （１２）ｓｔｅｐ８０７でＬＲ１がＬＲ２より後方でな
ければ、（図１３（ｂ）のＳ（２）、Ｓ（３）が相当）
主側＜ＳＭ＞からの回答が途中で消失しているので、ま
ずＬＲ１の情報を元にアプリケーションプロセスに回答
を送信（ｓｔｅｐ８１７）し、次にＬＲ１に対応するキ
ューを削除（ｓｔｅｐ８１８）する。 （１３）次に、ＬＲ２に対応するキューに、従側回答受
信済みのマークを記入（ｓｔｅｐ８１９）し、（図１３
（ｂ）のＳ（２）、Ｓ（５）が対応）ＬＲ２の一つ後ろ
のキューを、Ｍ（７０９）とする（ｓｔｅｐ８２０）。 （１４）ｓｔｅｐ８０５で、ＬＲ１に対応するキューが
なければ（図１３（ｂ）のＳ（５）、Ｓ（６）に相
当）、ＬＲ２に対応するキューがあるかをチェック（ｓ
ｔｅｐ８２１）し、対応するキューがあれば（図１３
（ｂ）のＳ（５）に相当）、ｓｔｅｐ８１９に処理を移
し、対応するキューが存在しなければ（図１３（ｂ）の
Ｓ（６）に相当）、先頭のキューをＭ（７０９）とする
（ｓｔｅｐ８２２）。 （１５）Ｍ（７０９）が設定されたら、Ｍを含めて以降
のキューに関して排他サービスマネージャ１＜ＳＭ１＞
（４０７）と、排他サービスマネージャ２＜ＳＭ２＞
（４０８）にキューの要求を送信（ｓｔｅｐ８１３）す
る。 （１６）最後に自機の設定を、排他要求マネージャの主
側に変更する（ｓｔｅｐ８１４）。このようにして、排
他サービスを行なう計算機のどれかに異常が発生しても
排他情報、及び排他要求情報が失われることなくサービ
スを続行することができる。

【００２８】

【発明の効果】この発明によれば、以上説明したように
構成されているので、以下に示すような効果を奏する。
アプリケーションプロセスの処理内容に対応したエラー
処理手続きを登録し、アプリケーションプロセスでの障
害発生時において前記エラー処理手続きを実行するよう
にしたので、アプリケーションプロセスの実行状況に則
したきめの細いエラー回復処理が可能となり、排他制御
サービスを滞らせることなく続行できるという効果があ
る。また、他計算機状態監視部を設けて、排他サービス
を要求するアプリケーションプロセスが搭載された計算
機の障害発生を検知し、該計算機障害発生時におけるエ
ラー処理手続きを登録し、実行するようにしたので、ネ
ットワークを構成している計算機全体に係る障害発生に
対してもエラー回復処理が可能となり、システム全体と
しての一貫性維持を計ることができるという効果があ
る。さらに、ネットワークが２台の計算機から構成され
た対向システムにおいては排他サービスマネージャと、
プロセス監視モニタを双方の計算機に搭載し、一方を主
計算機、他方を従計算機として構成したので、システム
動作中に、主側、従側のどちらの計算機に障害が発生し
ても、他方が主計算機となることによって排他サービス
を継続することができるという効果がある。加えて、排
他サービスマネージャ搭載計算機を多重化構成可能と
し、排他要求マネージャ搭載計算機をも多重化構成可能
としたので、各々、多重化を構成している計算機群にお
いて、一方の計算機に障害が発生しても、他の計算機が
サービスを代行できるようになり、システム全体として
の排他サービス処理の信頼性を向上させることができる
という効果がある。

【図面の簡単な説明】

【図１】図１は、この発明の実施例１による多重計算機
システムの構成図である。

【図２】図２は、この発明の実施例１による排他サービ
ス処理の動作（正常系）を示すフローチャートである。

【図３】図３は、この発明の実施例１による障害発生時
におけるエラー処理を示すフローチャートである。

【図４】図４は、この発明の実施例２による２重計算機
システムの構成図である。

【図５】図５は、この発明の実施例２による排他サービ
ス処理の動作（正常系）を示すフローチャートである。

【図６】図６は、この発明の実施例２による排他サービ
ス処理の動作（正常系）を示すフローチャートである。

【図７】図７は、この発明の実施例２による計算機障害
発生時のエラー処理を示すフローチャートである。

【図８】図８は、この発明の実施例３による多重計算機
システムの構成図である。

【図９】図９は、この発明の実施例３による排他制御処
理の概念図である。

【図１０】図１０は、この発明の実施例３による排他サ
ービス処理の動作（正常系）を示すフローチャートであ
る。

【図１１】図１１は、この発明の実施例３による計算機
障害発生時のエラー処理を示すフローチャートである。

【図１２】図１２は、この発明の実施例４による多重計
算機システムの構成図である。

【図１３】図１３は、この発明の実施例４による排他制
御処理の概念図である。

【図１４】図１４は、この発明の実施例４による排他サ
ービス処理の動作（正常系）を示すフローチャートであ
る。

【図１５】図１５は、この発明の実施例４による計算機
障害発生時のエラー処理を示すフローチャート１であ
る。

【図１６】図１６は、この発明の実施例４による計算機
障害発生時のエラー処理を示すフローチャート２であ
る。

【図１７】図１７は、従来例による多重計算機システム
の構成図である。

【図１８】図１８は、従来例による排他サービス処理の
動作を示すフローチャートである。

【符号の説明】

１０１ 排他サービスマネージャ搭載計算機 １０２，１０３ アプリケーションプロセス搭載計算機 １０４，２０３，２０４ 排他サービスマネージャ ３０６，３０７，４０７，４０８ 排他サービスマネー
ジャ １０５，２０５，２０６，３０８，３０９，４０９，４
１０ 排他情報管理テーブル １０６，１０７，２０７，２０８，３１１，３１２，４
１３，４１４ プロセス監視モニタ １１１，３１６ 排他制御部 １１２，３１９ 他計算機状態監視部 １１３，１１６，３１７，３２０ エラー処理部 １１４，２０６ 他計算機異常検知手段 １１５ プロセス状態監視部 １１７ プロセス異常検知手段 １０８，１０９，２０９，２１０，３１３，３１４，４
１５，４１６ アプリケーションプロセス ３１０，４１１，４１２ 排他要求マネージャ ３１８ 排他要求処理部 ３０３，４０３，４０６ 排他要求マネージャ搭載計算
機

Claims (5)

【特許請求の範囲】
1. 【請求項１】 系内システムにおける排他制御方式であ
   って、前記系内システムには、 単一系、又は多重系構成を成し、少くとも共有リソース
   に対する排他サービス機能を提供する排他サービス実現
   手段と、 上記排他サービス実現手段に対するサービス要求手続部
   とを構成要素として含み、 前記排他サービス実現手段は、 共有リソースに対する排他要求及び排他解除要求を実行
   する排他制御処理実行部と、 障害発生を検知するための障害発生検知部と、 上記障害発生時におけるエラー回復処理部を具備したこ
   とを特徴とする系間排他制御方式。
2. 【請求項２】 排他サービス機能を提供する第１の計算
   機と、排他サービスを要求するアプリケーションプロセ
   スが搭載された第２の計算機群から構成された多重計算
   機システムの排他制御方式において、 前記第１の計算機は共有リソースに対する排他要求及び
   排他解除要求を実行する排他制御処理実行部と、 前記排他制御処理実行に係わる排他情報管理テーブルを
   具備し、 前記第２のグループを構成する計算機は、 プロセス監視モニター手段を具備し、 前記プロセス監視モニター手段は、 共有リソースに対する排他要求及び排他解除に係わるサ
   ービスを要求するアプリケーションプロセスに発生した
   障害を検知するためのプロセス状態監視部と、 上記障害検知時におけるエラー処理手続きの登録部と、 前記エラー処理手続きの実行部、より構成されたことを
   特徴とする系間排他制御方式。
3. 【請求項３】 排他サービス機能を提供する第１の計算
   機と、排他サービスを要求するアプリケーションプロセ
   スが搭載された第２の計算機群から構成された多重計算
   機システムの排他制御方式において、 前記第１の計算機は、 排他サービスマネージャ手段と、排他サービス処理実行
   に係わる排他情報管理テーブルを具備し、 前記排他サービスマネージャ手段は、 共有リソースに対する排他要求及び排他解除要求を実行
   する排他制御処理実行部と、 他計算機の障害発生を検知するための他計算機状態監視
   部と、 上記計算機障害検知時におけるエラー処理手続きの登録
   部及び前記エラー処理手続きの実行部より構成されたエ
   ラー処理部と、を備え、 前記第２のグループを構成する計算機は、 プロセス監視モニター手段を具備し、 前記プロセス監視モニター手段は、 共有リソースに対する排他要求及び排他解除に係わるサ
   ービスを要求するアプリケーションプロセスに発生した
   障害を検知するためのプロセス状態監視部と、 上記障害検知時におけるエラー処理手続きの登録部と、 前記エラー処理手続きの実行部を備えたことを特徴とす
   る系間排他制御方式。
4. 【請求項４】 ネットワークで構成された多重計算機シ
   ステムにおける排他制御方式であって、 上記多重計算機システムが、特に２台より構成された対
   向システムにおいて、対向する２台の計算機双方に、排
   他サービスマネージャ手段と、プロセス監視モニタ手段
   と、排他サービス処理実行に係わる排他情報管理テーブ
   ルを搭載し、 前記排他サービスマネージャ手段は、 共有リソースに対する排他要求及び排他解除要求を実行
   する排他制御処理実行部と、 他計算機の障害発生を検知するための他計算機状態監視
   部と、 上記計算機障害検知時におけるエラー処理手続きの登録
   部及び前記エラー処理手続きの実行部より構成されたエ
   ラー処理部と、を備え、 前記プロセス監視モニタ手段は、 共有リソースに対する排他要求及び排他解除に係わるサ
   ービスを要求するアプリケーションプロセスに発生した
   障害を検知するためのプロセス状態監視部と、 上記障害検知時におけるエラー処理手続きの登録部と、
   前記エラー処理手続きの実行部を備えたことを特徴とす
   る系間排他制御方式。
5. 【請求項５】 排他制御処理を実行する第１の計算機群
   と、排他制御要求処理を実行する第２の計算機群と、排
   他サービスを要求するアプリケーションプロセスが搭載
   された第３の計算機群より構成された多重計算機システ
   ムにおける排他制御方式において、 前記第１の計算機群を構成する計算機は、 排他サービスマネージャ手段と、 排他サービス処理実行に係わる排他情報管理テーブルを
   具備し、 前記排他サービスマネージャ手段は、 共有リソースに対する排他要求及び排他解除要求を実行
   する排他制御処理実行部と、 障害発生時におけるエラー処理手続きの登録部及び前記
   エラー処理手続きの実行部より構成されたエラー処理部
   と、を備え、 前記第２の計算機群を構成する計算機は排他要求マネー
   ジャ手段を具備し、 前記排他要求マネージャ手段は、 前記第１の計算機群に対する排他要求及び排他解除要求
   を実行する排他要求処理実行部と、 多重計算機システムを構成する計算機群の障害発生を検
   知するための他計算機状態監視部と、 前記計算機障害検知時におけるエラー処理手続きの登録
   部及び前記エラー処理手続きの実行部より成るエラー処
   理部と、を備え、 前記第３の計算機群を構成する計算機においては、 プロセス監視モニタ手段が搭載され、 前記プロセス監視モニタ手段は、 アプリケーションプロセスに発生した障害を検知するた
   めのプロセス状態監視部と、 上記障害検知時におけるエラー処理手続きの登録部及び
   前記エラー処理手続きの実行部より構成されたエラー処
   理部と、を具備したことを特徴とする系間排他制御方
   式。