JP2000010937A

JP2000010937A - リソース管理方法

Info

Publication number: JP2000010937A
Application number: JP10177839A
Authority: JP
Inventors: Kenji Yamauchi; 健司山内
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1998-06-24
Filing date: 1998-06-24
Publication date: 2000-01-14

Abstract

(57)【要約】【課題】ネットワーク内に分散配置された計算機間で
共用されるリソースの追加／削除等の変更した場合、こ
のリソースを管理する計算機から他の計算機へリソース
変更メッセージを送信するが、従来は１つのリソースの
変更に対し１回の送信を行うので、複数個のリソースの
変更をした場合、複数回の送信を必要とした。【解決手段】リソースの追加・削除があると、リソー
ス変更メッセージ１０のフォーマットのように、複数個
のリソースの変更であっても、リソース名（ＮＡＭＥ）
とネットワーク内アドレス（ＡＤＤＲ）との複数組の指
定を行う。このメッセージ１０を送信することにより、
複数個のリソースの変更内容が一括送信でき、ネットワ
ークの通信負荷を軽減する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータネッ
トワークシステム内に分散配置され、ネットワーク内の
各計算機間にて共用されるリソースの管理方法に関す
る。

【０００２】

【従来の技術】従来の技術として、例えば特開昭６２−
１８２８６３号公報に示されたリソースの管理方法を説
明する。図１９は従来例および本発明が適用されるコン
ピュータネットワークシステムの構成図で計算機Ａ〜
Ｆ、ファイルＦＩＬＥＣは通信制御装置２を介して通信
媒体１で接続されており、計算機Ａ，ＢにはプリンタＰ
ＲＩＮＴＡ、ファイルＦＩＬＥＢが設置されている。

【０００３】ここで通信媒体および通信プロトコルは任
意であり、例えばリング型ローカルエリアネットワーク
（例えばトークンリング）、バス型ローカルエリアネッ
トワーク（例えば、イーサネット）、ポイントツーポイ
ントネットワーク（例えばＲＳ−２３２Ｃ）等を統合し
たものなどである。ネットワーク制御は、各計算機に接
続された通信制御装置２によって行われる。また、各通
信制御装置間メッセージ交信方法も任意である。よっ
て、割り込み駆動型（メッセージ受信時、計算機に割り
込みを発生しデータを受け渡す方法）、ビジーウエイテ
ィング型（常時、計算機側でデータを受信したか監視す
る方法）など、どちらの方法でもよい。

【０００４】ネットワーク内の計算機Ａ〜Ｆは、ネット
ワーク内のリソースのアクセス管理を行うために、ネッ
トワーク内の全てのリソース制御情報を格納する図２０
のようなリソース管理テーブルと、自計算機内のリソー
スの追加／削除の来歴を格納する図２１のような自計算
機内リソース来歴管理テーブルを持つ。ただし、図２０
のテーブルは、図１９の計算機Ａ（ＮＯＤＥＡ）のもの
を例示しており、ネットワーク内の各計算機（ＮＯＤＥ
Ａ〜Ｆ）で定義されたリソース全てのリソース名称とそ
れらのネットワーク内アドレス、属性情報により構成さ
れる。

【０００５】各計算機がこれらのリソースにアクセスす
る時は、本テーブルを参照することによりリソース名称
に対応したリソースのアドレス、属性情報を得てアクセ
スする。図２１の自計算機内リソース来歴管理テーブル
は、図１９の計算機Ａ（ＮＯＤＥＡ）のものを例示して
おり、自計算機で定義したネットワークに追加（登録）
／削除したリソースの名称、追加／削除の時刻が格納さ
れている。このテーブルは、各計算機が自計算機内リソ
ースの追記（登録）、削除を行う時に作成される。

【０００６】各計算機は、このリソースの追加／削除お
よび来歴管理テーブルの作成後にネットワーク内で稼働
中の全計算機へリソース追加／削除を報告するため、図
２３（ｂ）で示すリソース変更メッセージをブロードキ
ャストする。本メッセージは、図２３（ｂ）で示す様に
名称（ＮＡＭＥ）、ネットワーク内アドレス（ＡＤＤ
Ｒ）、属性情報（ＣＯＮＴＲＯＬ）、追加／削除ビット
（Ｃ）、送信先アドレス（ＤＡ）、及び送信元アドレス
（ＳＡ）などより成っている。

【０００７】このリソース変更メッセージを受けたネッ
トワーク内の各計算機は、この内容をリソース管理テー
ブルへ格納して必要な時にアクセスする。しかし、リソ
ース変更メッセージのブロードキャスト時に停止（削
除）していた計算機は、リソース情報の更新をブロード
キャスト時には行えないから、これを従来例および、本
発明では図１８に示す処理を行うことによって解決して
おり、これを以下で説明する。

【０００８】次に動作について説明する。（１）まず、図２２に示すように、ＮＯＤＥＡの計算機
停止中に、ＮＯＤＥＢが時刻ｔ０に新規リソースの登録
（追加）を行い、これをブロードキャストした場合、Ｎ
ＯＤＥＡはこの時のリソース変更メッセージを受信でき
ない。そこで、ｓｔｅｐ１００では、計算機Ａは図２３
（ａ）で示す立ち上げ報告メッセージを立ち上がり時点
ｔ２にブロードキャストする。この立ち上げ報告メッセ
ージは、その計算機が前回停止（削除）した時刻ｔ１
（ＩＮＡＣＴ）と、今回立ち上がった時刻ｔ２（ＡＣ
Ｔ）、及び、計算機名（ＮＮＡＭＥ）等より成ってお
り、図２２の場合は、ＮＮＡＭＥ＝ＮＯＤＥＡ、ＩＮＡ
ＣＴ＝ｔ１、ＡＣＴ＝ｔ２である。

【０００９】（２）この立ち上げ報告メッセージを受信
した計算機Ｂは、報告元計算機Ａの停止時間中ｔ１〜ｔ
２にリソースの追加／削除を行ったか否かを自計算機内
リソース来歴管理テーブルをサーチして調べ（ｓｔｅｐ
２００）、（３）もしあれば、図２３（ｂ）に示したリソース変更
メッセージを報告元計算機Ａへ送信する。（ｓｔｅｐ２
０１）。（４）このメッセージを受信した計算機Ａは、その内容
を自計算機内のリソース管理テーブルへ登録し、（ｓｔ
ｅｐ１０１）、当該リソースの利用可能状態となる。

【００１０】（５）図２２の時刻ｔ２にもし計算機Ｂが
停止していれば、上記の計算機Ａからの立ち上げ報告メ
ッセージを計算機Ｂは受信できず、リソース追加を計算
機Ａへ知らせられない。図２４はこのような状況を示し
ていて（図２２とは計算機Ａ，Ｂの役割が逆になってい
る。）、この場合は、計算機Ｂが時刻ｔ４に立ち上がっ
て、立ち上げ報告メッセージをブロードキャストして
も、計算機Ａは停止中のため時刻ｔ０におけるリソース
の登録を計算機Ｂは知ることができない。この場合は、
時刻ｔ２に計算機Ａから立ち上げ報告メッセージがブロ
ードキャストされるが（ｓｔｅｐ１００）、これを受信
した計算機Ｂは、ｓｔｅｐ２００，２０１の処理は終わ
った後、自計算機が計算機Ａ停止中のｔ１〜ｔ２の間に
立ちあがったか否かを調べ（ｓｔｅｐ２０２）、

【００１１】（６）もしこの間に立ち上がっていれば、
計算機Ａへ送信する（ｓｔｅｐ２０３）。（７）この立ち上げ報告メッセージを受信した計算機Ａ
は、計算機Ｂの停止期間ｔ３〜ｔ４にリソースの追加／
削除を行っているかどうかを自計算機内リソース管理テ
ーブルをサーチして調べ（ｓｔｅｐ１０２）、（８）もしあれば、該リソースのリソース変更メッセー
ジを計算機Ｂに送信し（ｓｔｅｐ１０３）、（９）これを受信した計算機Ｂはその情報をリソース管
理テーブルへ設定し（ｓｔｅｐ２０４）、処理を終わ
る。

【００１２】

【発明が解決しようとする課題】従来のリソース管理方
法は以上のように構成されており、各計算機は、自計算
機内のリソースが更新される度にリソース更新報告をブ
ロードキャスト送信するが、一度の送信につき、一つの
リソース変更しか報告しないため、複数のリソースが更
新された場合にリソースの数だけ複数回に渡りリソース
更新報告をブロードキャスト送信する必要があり、ネッ
トワークの負荷が高くなりやすく、リアルタイムシステ
ムなど、迅速な通信が要求されるシステムでは、大きな
問題となる。

【００１３】また、従来のリソース管理方法は、リソー
ス更新時に以前との差分のみを報告するため、通信や、
計算機内の障害などにより、一度でも報告を喪失してし
まうと、他の計算機とリソース管理テーブルの内容が相
違し、整合性が取れなくなるという問題もあった。

【００１４】本発明は、上記のような課題を解決するた
めになされたもので、ネットワーク内の各計算機間のリ
ソース管理に関する通信を少なくすることによりネット
ワークの通信負荷を下げ、リアルタイムシステムに要求
される計算機間の通信性能を確保することと、各計算機
間でのリソース管理テーブルの不整合をなくすことを目
的にしている。

【００１５】

【課題を解決するための手段】（１）この発明に係るリ
ソース管理方法は、ネットワーク内の計算機がそのネッ
トワーク内で共有されるリソースの追加、削除等のリソ
ース更新を行った時には、当該計算機がネットワーク内
の他計算機に対して上記更新したリソースの定義情報を
送信し、上記他計算機は受信した上記定義情報により自
計算機内のリソース定義情報を更新することにより、更
新されたリソースへのアクセスを可能とし、計算機の立
ち上げ時に、その立ち上げ計算機が前回停止（削除）し
た時刻と今回立ち上がった時刻とからなる立ち上げ報告
メッセージをネットワーク内の他計算機へ報告し、上記
メッセージの報告先計算機は、上記メッセージの報告元
計算機の停止中に自計算機のリソースの更新を行ってい
た場合には、その更新したリソースの定義情報を上記報
告元計算機へ送信してリソース定義情報を更新させ、上
記報告先計算機が報告元計算機の停止中に立ち上がって
いた場合には、その立ち上げ時に送信したのと同じ立ち
上げ報告メッセージを上記報告元計算機へ送信し、上記
報告元計算機は上記報告先計算機が停止中に自計算機の
リソースの更新を行っていた場合には、その更新したリ
ソースの定義情報を上記報告先計算機へ送信してリソー
ス定義情報を更新させるようにしたリソース管理方法に
おいて、上記定義情報を送信する場合に、リソースの追
加／削除等の変更があった全てのリソースの定義情報を
一括送信するようにしたものである。

【００１６】（２）また、ネットワーク内の計算機がそ
のネットワーク内で共有されるリソースの追加、削除等
のリソース更新を行った時には、当該計算機がネットワ
ーク内の他計算機に対して自計算機が管理するリソース
の内少なくとも動作しているリソースの定義情報を一括
送信し、上記他計算機は受信した上記定義情報により自
計算機内のリソース定義情報を更新することにより、更
新されたリソースへのアクセスを可能とし、計算機の立
ち上げ時に、その立ち上げ計算機が前回停止（削除）し
た時刻と今回立ち上がった時刻とからなる立ち上げ報告
メッセージをネットワーク内の他計算機へ報告し、上記
メッセージの報告先計算機は、上記メッセージの報告元
計算機の停止中に自計算機のリソースの更新を行ってい
た場合には、自計算機が管理するリソースの内少なくと
も動作しているリソースの定義情報を上記報告元計算機
へ一括送信してリソース定義情報を更新させ、上記報告
先計算機が報告元計算機の停止中に立ち上がっていた場
合には、その立ち上げ時に送信したのと同じ立ち上げ報
告メッセージを上記報告元計算機へ送信し、上記報告元
計算機は上記報告先計算機が停止中に自計算機のリソー
スの更新を行っていた場合には、自計算機が管理するリ
ソースの内少なくとも動作しているリソースの定義情報
を上記報告先計算機へ一括送信してリソース定義情報を
更新させるようにしたものである。

【００１７】（３）また、ネットワーク内の計算機がそ
のネットワーク内で共有されるリソースの追加、削除等
のリソース更新を行った時には、当該計算機がネットワ
ーク内の他計算機に対して上記更新したリソースの定義
情報を送信し、他計算機は受信した上記定義情報により
自計算機内のリソース定義情報を更新することにより、
更新されたリソースへのアクセスを可能とし、且つ、上
記定義情報を送信する場合に、リソースの追加／削除等
の変更があった全てのリソースの定義情報を一括送信
し、計算機の立ち上げ時に、その立ち上げ計算機は、自
計算機が管理しているリソースの内少なくとも動作して
いるリソースの定義情報を他計算機へ一括送信し、他計
算機は受信したリソースの定義情報により自計算機内の
リソース定義情報を更新すると共に、自計算機が管理し
ているリソースの内少なくとも動作しているリソース定
義情報を一括返信して立ち上げ計算機のリソースの定義
情報を更新させるようにしたものである。

【００１８】（４）また、ネットワーク内の計算機がそ
のネットワーク内で共有されるリソースの追加、削除等
のリソース更新を行った時には、当該計算機がネットワ
ーク内の他計算機に対して自計算機が管理するリソース
の内少なくとも動作しているリソースの定義情報を一括
送信し、他計算機は受信した上記定義情報により自計算
機内のリソース定義情報を更新することにより、更新さ
れたリソースへのアクセスを可能とし、計算機の立ち上
げ時に、その立ち上げ計算機は、自計算機が管理してい
るリソースの内少なくとも動作しているリソースの定義
情報を他計算機へ一括送信し、他計算機は受信したリソ
ースの定義情報により自計算機内のリソース定義情報を
更新すると共に、自計算機が管理しているリソースの内
少なくとも動作しているリソース定義情報を一括返信し
て立ち上げ計算機のリソースの定義情報を更新させるよ
うにしたものである。

【００１９】（５）また、上記（１）〜（４）のいずれ
か１項において、定義情報は、ネットワーク内で共有さ
れるリソース毎に付与したネットワークアドレスを設定
した定義情報としておき、定義情報を授受する場合に
は、上記ネットワークアドレスによりリソースを判別す
るようにしたものである。

【００２０】（６）また、上記（１）〜（４）のいずれ
か１項において、定義情報は、計算機とこの計算機が管
理しているリソースとを同一アドレスとする計算機アド
レスを設定すると共に、上記リソースを区別するための
リソースＩＤを設定した定義情報としておき、定義情報
を授受する場合には、上記計算機アドレスおよびリソー
スＩＤによりリソースを管理している計算機とリソース
とを判別するようにしたものである。

【００２１】（７）また、上記（１）〜（６）のいずれ
か１項において、計算機が停止する際には、その停止計
算機が停止に関わる定義情報を送信する代わりに、計算
機停止通知を他計算機へ送信し、停止通知を受けた他計
算機は、その停止通知に応じて自計算機内のリソース定
義情報を更新するようにしたものである。

【００２２】（８）また、上記（１）〜（７）のいずれ
か１項において、計算機が停止情報を送信できずに異常
終了した場合、その異常計算機の管理するリソースにア
クセスした計算機は、アクセスの失敗により上記リソー
スが停止状態であると判断し、その判断に応じて自計算
機内のリソース定義情報を更新するものである。

【００２３】（９）また、上記（１）〜（７）のいずれ
か１項において、計算機が停止情報を送信できずに異常
終了した場合、その異常計算機の管理するリソースにア
クセスした計算機は、アクセスの失敗により上記リソー
スが停止状態であると判断し、その判断に応じて自計算
機内のリソース定義情報を更新すると共に、他計算機に
上記判断結果を通知し、通知を受けた他計算機において
も、上記リソースにアクセスした計算機と同様に自計算
機内のリソース定義情報を更新するものである。

【００２４】（１０）また、上記（１）〜（７）のいず
れか１項において、計算機が停止情報を送信できずに異
常終了した場合、その異常計算機の管理するリソースに
アクセスした計算機は、アクセスの失敗により上記異常
計算機が管理する全てリソースが停止状態であると判断
し、その判断に応じて自計算機内のリソース定義情報を
更新するものである。

【００２５】（１１）また、上記（１）〜（７）のいず
れか１項において、計算機が停止情報を送信できずに異
常終了した場合、その異常計算機の管理するリソースに
アクセスした計算機は、アクセスの失敗により上記異常
計算機が管理する全てのリソースが停止状態であると判
断し、その判断に応じて自計算機内のリソース定義情報
を更新すると共に、他計算機に上記判断結果を通知し、
通知を受けた他計算機においても、上記リソースにアク
セスした計算機と同様に自計算機内のリソース定義情報
を更新するものである。

【００２６】（１２）また、上記（１）〜（１１）のい
ずれか１項において、任意の計算機から他計算機にリソ
ース定義情報の通知要求を送信すると、上記他計算機
は、上記受信した通知要求に応じて自計算機の管理する
リソースの定義情報を返信し、上記任意の計算機は上記
返信内容に応じて自計算機内のリソース定義情報を更新
するものである。

【００２７】

【発明の実施の形態】実施の形態１．図１は、この発明
の実施の形態１のリソース管理方法のリソース変更メッ
セージのフォーマット説明図である。図２は、新規リソ
ース登録（追加）時のリソース更新処理のフローチャー
トである。また、本発明におけるシステム構成図は、従
来例の図１９と同様である。

【００２８】次に図１、図２を用いて動作について説明
する。（１）図２のｓｔｅｐ３００において、計算機Ａが管理
する複数のリソースについて、新規登録（追加）または
削除が発生する。（２）この時、計算機Ａはｓｔｅｐ３０１において、図
１に示すリソース変更メッセージ１０を一回だけブロー
ドキャスト送信する。図１のリソース変更メッセージ１
０では、追加／削除するリソースを一つのメッセージ内
に複数組み込むことができる。この時、メッセージ内に
組み込んだリソースの数をＲＮＵＭに記録して送信す
る。

【００２９】（３）ｓｔｅｐ３０１において計算機Ａが
送信したリソース変更メッセージ１０はブロードキャス
ト送信により、ネットワーク内の全計算機に受信され
る。（４）ｓｔｅｐ３１０において、該送信を受信した計算
機は、該リソース変更メッセージに組み込まれている複
数のリソースについて、自計算機内のリソース管理テー
ブルを更新する。ここでリソース管理テーブルとは、従
来例の図２０と同じものである。なお、図２では、計算
機Ｂの場合を例示している。

【００３０】以上説明したようにこの実施の形態１によ
れば、１つのリソース変更メッセージ内に複数のリソー
スの更新情報を組み込めるようにしたので、複数のリソ
ースの変更があった場合にも、１度のリソース変更メッ
セージの送信により通知することができる。従って、本
発明は、従来例のようなリソースの変更数分のリソース
変更メッセージを送信する必要がなく、ネットワークの
通信負荷を下げ、計算機間の通信性能を確保できるとい
う効果がある。

【００３１】実施の形態２．前記実施の形態１では、各
計算機は、図２０のリソース管理テーブルにおいて、各
リソースのネットワーク内アドレスを保有していたた
め、リソースのアドレスが変更になっただけでも、リソ
ース変更メッセージをブロードキャスト送信する必要が
あった。実施の形態２はこの問題を解決するために考え
られたもので、リソースのアドレス変更の場合には、リ
ソース変更メッセージを送信する必要をなくすことによ
り、通信負荷を軽減することを目的としている。

【００３２】この実施の形態２では、ネットワーク内の
各計算機は、図４に示すネットワークリソース管理テー
ブル１２と、図５に示すローカルリソース管理テーブル
１３を有する。ネットワークリソース管理テーブル１２
は、ネットワーク内で共有されるリソースの定義情報を
保有するが、リソースのネットワーク内アドレスではな
く、各リソースを管理している計算機のアドレスを保有
する。また、ローカルリソース管理テーブル１３は、自
計算機が管理するリソースの情報を保有するものであ
り、各リソースの名称とアドレスを有する。

【００３３】これに伴い、リソース変更メッセージにお
いても図３に示すとおり、リソースのネットワーク内ア
ドレス（図１のリソース変更メッセージ１０におけるＡ
ＤＤＲ）をメッセージ内に組込む必要はなくなった。図
６に実施の形態２におけるリソースの追加／削除と、リ
ソースへのアクセスのフローチャートを示す。

【００３４】次に実施の形態２のリソース管理方法の動
作について図６を用いて説明する。（１）ネットワーク内の各計算機は、ｓｔｅｐ４０１に
おいて、自計算機でリソースの追加／削除が起こった場
合、（２）ｓｔｅｐ４０２において、ローカルリソース管理
テーブルを更新する。（３）次にｓｔｅｐ４０３において、該計算機から他計
算機に対してリソース変更メッセージをブロードキャス
ト送信する。これは実施の形態１と同様である。このと
き、実施の形態２では、リソース変更メッセージの中に
リソースアドレスを組込む必要はない。（４）ｓｔｅｐ４１０において、リソース変更メッセー
ジを受けた計算機Ｂは自計算機内のネットワークリソー
ス管理テーブルを更新する。この時のネットワークリソ
ース管理テーブルは図４に示すとおり、計算機アドレス
を保有する。この計算機アドレスは、図３に示すリリー
ス変更メッセージ１１の送信元アドレスに対応する。

【００３５】次に、ネットワーク上のリソースにアクセ
スする場合を考える。ここでは、計算機Ｂから計算機Ａ
のリソースＰＲＩＮＴＡにアクセスする場合を例示す
る。（１）ｓｔｅｐ４１１において、計算機Ｂは自計算機内
のネットワークリソース管理テーブルからＰＲＩＮＴＡ
を管理する計算機（この場合は、計算機Ａ）のアドレス
を得て、計算機Ａにアクセス要求を送信する。（２）ｓｔｅｐ４０４において、計算機Ａはアクセス要
求を受けて、ローカルリソース管理テーブルからリソー
スのアドレスを取得し、アクセス要求に応答する。

【００３６】以上説明したように、この実施の形態２に
よれば、各計算機は、ネットワーク上のリソースのアド
レスを保有する代わりに各リソースを管理する計算機の
アドレスを保有するようにしたので、リソースのアドレ
ス変更によるリソース変更メッセージを送信する必要が
ない。これにより、通信メッセージが少なくなり、通信
負荷の軽減による計算機間通信の性能確保を行えるとい
う効果がある。なお、上記説明では計算機間で定義情報
を送信する場合は、計算機アドレスと共にリソース名称
を送信しているが、リソースを区別するリソースＩＤで
あればよい。例えばＩＤ番号を用いてもよい。

【００３７】実施の形態３．前記実施の形態１、２のリ
ソース管理方法では、計算機が停止する場合、該計算機
が管理する全リソースについて、リソース削除のリソー
ス変更メッセージをブロードキャスト送信する必要があ
った。実施の形態３は、この問題を解決するために考え
られたもので、計算機停止時には、よりデータ長の短い
停止報告メッセージを送信することにより、該計算機が
保有するリソースのリソース変更メッセージを送信する
必要をなくし、ネットワークの通信負荷を軽減すること
を目的としている。

【００３８】図７は実施の形態３における停止報告メッ
セージを示し、図８は、実施の形態３における計算機停
止時の処理のフローチャートである。

【００３９】次に実施の形態３において、計算機が停止
するときの処理を図８を用いて説明する。図８では、計
算機Ａが停止する場合を例示している。（１）まず、ｓｔｅｐ５００において、計算機Ａは、図
７に示す停止報告メッセージ１４をブロードキャスト送
信し、（２）ｓｔｅｐ５０１にて停止する。（３）ｓｔｅｐ５１０において、該メッセージを受信し
た計算機Ｂは、自計算機内のネットワークリソース管理
テーブルから、該計算機Ａが管理するリソースを削除す
る。

【００４０】以上説明したように実施の形態３によれ
ば、計算機が停止する場合に、該計算機が管理するリソ
ースのリソース変更メッセージを送信する代わりに、よ
りデータ長の短い停止報告メッセージを送信するだけな
ので、通信負荷の軽減により、計算機間の通信性能が確
保できるという効果がある。

【００４１】実施の形態４．前記実施の形態３では、計
算機が、停止報告メッセージを送信できずに異常終了し
た場合には対応できなかった。本実施の形態４では、異
常終了した計算機のリソースにアクセスし、アクセスが
エラーになった場合は、該リソースが削除されたものと
判断し、ネットワークリソース管理テーブルから該リソ
ースを削除するようにした。これにより、存在しないリ
ソースに再度アクセスすることを防ぎ、通信負荷を軽減
することができる。図９は実施の形態４の計算機異常終
了時の処理を示すフロー図である。

【００４２】次に実施の形態４における計算機異常終了
時の処理を図９を用いて説明する。（１）ｓｔｅｐ６００において、計算機Ａが停止報告メ
ッセージを送信できずに異常終了した後に、（２）計算機Ｂがｓｔｅｐ６１０において、計算機Ａ上
のリソースにアクセスした場合、（３）該アクセスは、ｓｔｅｐ６１１においてエラー終
了する。

【００４３】（４）このアクセス失敗により、ｓｔｅｐ
６１２において、計算機Ｂは該リソースが削除されたも
のと判断し、自計算機内のネットワークリソース管理テ
ーブルから該リソースを削除する。（５）これ以降、計算機Ｂは該リソースにアクセスしな
くなる。

【００４４】以上説明したように、この実施の形態４に
よれば、停止報告メッセージを送信できずに計算機が異
常終了した場合、該計算機が管理するリソースへのアク
セスが失敗した時に、ネットワークリソース管理テーブ
ルから該リソースを削除するので、以降、再度該リソー
スにアクセスすることがなくなり、通信負荷が軽減でき
るという効果がある。

【００４５】実施の形態５．実施の形態４では、停止報
告メッセージを送信できずに計算機が異常終了した場
合、該計算機が管理するリソースへのアクセスが失敗し
た計算機は、自計算機内のネットワークリソース管理テ
ーブルから該リソースを削除するので、以降、該計算機
から再度該リソースにアクセスすることがなくなるが、
他の計算機からも１度はアクセスが行われるという問題
があった。

【００４６】実施の形態５では、リソースへのアクセス
が失敗し、自計算機内のネットワークリソース管理テー
ブルを削除した後、リソース削除のリソース変更メッセ
ージをブロードキャスト送信することにより、他計算機
にも当該リソースの削除を知らせるので、以降、どの計
算機からも当該リソースへアクセスしなくなる。図１０
は実施の形態５の処理を示すフロー図である。

【００４７】次に動作について説明する。（１）ｓｔｅｐ７００において、計算機Ａが停止報告メ
ッセージを送信できずに異常終了した後に、（２）計算機Ｂがｓｔｅｐ７１０において、計算機Ａ上
のリソースにアクセスした場合、（３）該アクセスは、ｓｔｅｐ７１１において、エラー
終了する。

【００４８】（４）このアクセス失敗により、ｓｔｅｐ
７１２において、計算機Ｂは該リソースが削除されたも
のと判断し、自計算機内のネットワークリソース管理テ
ーブルから該リソースを削除する。（５）次にｓｔｅｐ７１３において、リソース変更メッ
セージをブロードキャスト送信することにより、ネット
ワーク内の全計算機に該リソースの削除を知らせる。（６）これ以降、計算機Ｂだけでなく、ネットワーク内
の全計算機は該リソースにアクセスしなくなる。

【００４９】以上説明したように実施の形態５によれ
ば、ある計算機が停止報告メッセージを送信できずに異
常終了した後、該計算機のリソースにアクセスした計算
機が該リソースの削除を検知すると、それをネットワー
ク内の全計算機に通知するので、以降該リソースへのア
クセスがなくなり、通信負荷を軽減し、通信性能を確保
できるという効果がある。

【００５０】実施の形態６．前記実施の形態４では、計
算機が停止報告メッセージを送信できずに異常終了した
場合、該計算機のリソースにアクセスした計算機は、ア
クセスのエラーにより該リソースの削除を検知し、自計
算機内のネットワークリソース管理テーブルから、該リ
ソースを削除することにより、該リソースへの再度のア
クセスを防いでいたが、該異常停止計算機が管理する他
リソースへのアクセスは行われていた。（同様の処理に
より、２回目以降のアクセスは防がれる。）

【００５１】実施の形態６は、この問題を解決するため
に考えられたもので、異常終了計算機が管理するリソー
スへのアクセスが失敗した場合には、該リソースだけで
なく、該計算機が管理する全リソースをネットワークリ
ソース管理テーブルから削除することにより、該計算機
が管理するどのリソースへも再度のアクセスをしない様
にしたものである。図１１は実施の形態６の処理フロー
図である。

【００５２】次に実施の形態６の動作について説明す
る。（１）ｓｔｅｐ８００において、計算機Ａが停止報告メ
ッセージを送信できずに異常終了した後に、（２）計算機Ｂがｓｔｅｐ８１０において、計算機Ａ上
のリソースにアクセスした場合、（３）該アクセスは、ｓｔｅｐ８１１においてエラー終
了する。

【００５３】（４）このアクセス失敗により、ｓｔｅｐ
８１２において、計算機Ｂは該リソースが削除されたも
のと判断し、自計算機内のネットワークリソース管理テ
ーブルから該リソースのみでなく、計算機Ａが管理する
全リソースを削除する。（５）これ以降、計算機Ｂは該リソースのみでなく、計
算機Ａが管理する全リソースにアクセスしなくなる。

【００５４】以上説明したように、この実施の形態６に
よれば、異常終了計算機が管理するリソースへのアクセ
スが失敗した場合には、該リソースだけでなく、該計算
機が管理する全リソースをネットワークリソース管理テ
ーブルから削除することにより、該計算機が管理するど
のリソースへも再度のアクセスをしない様にしたことに
より、さらに通信負荷を軽減できる効果がある。

【００５５】実施の形態７．実施の形態５では、停止報
告メッセージを送信できずに計算機が異常終了した場
合、該計算機が管理するリソースへのアクセスが失敗し
た計算機は、自計算機内のネットワークリソース管理テ
ーブルから該計算機が管理する全リソースを削除するの
で、以降、該計算機から再度該計算機が管理する全リソ
ースにアクセスすることがなくなるが、他の計算機から
も１度はアクセスが行われるという問題があった。

【００５６】実施の形態７では、リソースへのアクセス
が失敗し、自計算機内のネットワークリソース管理テー
ブルから該計算機が管理する全リソースを削除した後、
該計算機の停止報告メッセージをブロードキャスト送信
することにより、以降、どの計算機からも当該計算機が
管理する全リソースへアクセスしなくなる。図１２は実
施の形態７の処理を示すフロー図である。

【００５７】次に動作について説明する。（１）ｓｔｅｐ９００において、計算機Ａが停止報告メ
ッセージを送信できずに異常終了した後に、（２）計算機Ｂがｓｔｅｐ９１０において、計算機Ａ上
のリソースにアクセスした場合、（３）該アクセスは、ｓｔｅｐ９１１においてエラー終
了する。

【００５８】（４）このアクセス失敗により、ｓｔｅｐ
９１２において、計算機Ｂは該リソースおよび、計算機
Ａが管理する全リソースが削除されたものと判断し、自
計算機内のネットワークリソース管理テーブルから計算
機Ａが管理する全リソースを削除する。（５）次にｓｔｅｐ９１３において、計算機Ａの停止報
告メッセージをブロードキャスト送信することにより、
ネットワーク内の全計算機に該リソースの削除を知らせ
る。（６）これ以降、計算機Ｂだけでなく、ネットワーク内
の全計算機は計算機Ａの全リソースにアクセスしなくな
る。

【００５９】以上説明したように実施の形態７によれ
ば、ある計算機が停止報告メッセージを送信できずに異
常終了した後、該計算機のリソースにアクセスした計算
機が該リソースの削除を検知すると、該計算機の停止報
告メッセージをネットワーク内の全計算機に通知するの
で、以降ネットワーク上の全計算機から該計算機が管理
する全リソースへのアクセスがなくなり、通信負荷を軽
減し、通信性能を確保できるという効果がある。

【００６０】実施の形態８．実施の形態１，２のリソー
ス管理方法では、リソースの追加／削除があった時に、
更新したリソースについてのみ更新情報をリソース変更
メッセージにて通知していた。しかし、リソースの追加
／削除が多数あった場合には、更新情報が長くなるた
め、通信データ長が大きくなる上、リソース管理テーブ
ルの更新処理が煩雑になるので、現在有効なリソース
（動作しているリソース）のみを通知してもらったほう
が通信データ長が小さく、処理が簡単に済む場合があ
る。

【００６１】実施の形態８はこういう場合のために考え
られたもので、追加／削除の更新情報ではなく、現在有
効なリソースの一覧情報を現状報告メッセージで通知す
るものである。図１３は現状報告メッセージのフォーマ
ットであり、図１４は現状報告メッセージの送信／受信
処理を示すフロー図である。

【００６２】次に実施の形態８の動作を図１３，図１４
を用いて説明する。（１）ｓｔｅｐ１００１において、計算機Ａがリソース
更新を行う。なお、このリソース更新はリソースの追加
／削除が多数あり、リソース変更メッセージを送るに
は、データ長が長くなり、受信側の処理が煩雑になるも
のとする。（２）この場合、計算機Ａはｓｔｅｐ１００２におい
て、図１３に示す現状報告メッセージ１５をブロードキ
ャスト送信する。

【００６３】（３）該メッセージを受信した計算機Ｂ
は、ｓｔｅｐ１０１１において、ネットワークリソース
管理テーブルの計算機Ａが管理するリソース情報を上書
きする。ここで、計算機Ｂが受信したのがリソース変更
メッセージである場合は、該メッセージに含まれる１つ
１つのリソースの追加／削除をメッセージ内容から判定
し、自計算機内のネットワークリソース管理テーブルか
ら当該リソースを検索し、内容をメッセージ通りに更新
する必要があったが、現状報告メッセージを受信した場
合には、計算機Ａの管理するリソースを一旦全部ネット
ワークリソース管理テーブルから削除し、現状報告メッ
セージ内のリソースを一括してネットワークリソース管
理テーブルに追加するだけでよい。

【００６４】以上説明したように実施の形態８によれ
ば、リソースの追加／削除の更新情報ではなく、現在有
効なリソースの一覧情報を現状報告メッセージで通知す
るようにしたので、特に更新するリソースが多数あるよ
うな場合に、メッセージ長を小さくして通信負荷を軽減
すると共に、メッセージ受信側計算機のネットワークリ
ソース管理テーブルの更新処理を迅速に行うことができ
るという効果がある。

【００６５】なお、現状報告メッセージは、自計算機が
管理しているリソースの内、現在有効なリソース（動作
しているリソース）のみを通知するようにしたが、自計
算機が管理している全てのリソースを通知するようにし
てもよい。全てのリソースを通知することは、動作して
いるリソースを通知することと発明としては等価であ
り、この発明では有効リソース（動作しているリソー
ス）の通知は全てのリソースの通知も含むものとする。
なお、全リソースを送信する場合は、有効リソースの検
索をせずに送信することができる。

【００６６】実施の形態９．実施の形態１，２のリソー
ス管理方法では、リソースの更新があった時に、以前と
の差分のみを更新情報として送信するため、ネットワー
クや、計算機の一時的な障害などにより一度でも更新メ
ッセージを喪失してしまうと、他の計算機とリソース管
理テーブルの内容が相違し、整合性をとるためには、全
計算機を再立ち上げする必要があった。

【００６７】実施の形態９はこの問題を解決するために
考えれらたもので、他の計算機に対してリソース情報通
知要求メッセージを送信すると、該メッセージを受信し
た計算機は、現状報告メッセージにより現在有効なリソ
ースを通知するようにしたものである。図１５はリソー
ス情報通知要求メッセージのフォーマットを示す。現状
報告メッセージのフォーマットは、図１３と同じもので
ある。図１６は実施の形態９の処理を示すフロー図であ
る。

【００６８】次に動作について、図１６を用いて説明す
る。（１）リソースアクセスのエラーなどにより、リソース
管理テーブルの不整合の可能性があると判断した時、計
算機Ａはｓｔｅｐ１１０１において、図１５に示すリソ
ース情報通知要求をブロードキャスト送信する。（２）該メッセージを受け取った計算機Ｂは、ｓｔｅｐ
１１１０において、計算機Ｂが管理し、現在有効なリソ
ースの情報を図１３に示す現状報告メッセージにて計算
機Ａに通知する。（３）ｓｔｅｐ１１０２において計算機Ａは該現状報告
メッセージをもとにネットワークリソース管理テーブル
を更新する。

【００６９】以上説明したように実施の形態９によれ
ば、リソース管理テーブルの不整合が起こった場合で
も、リソース情報通知要求メッセージと現状報告メッセ
ージにより整合性をとることができ、リソース管理テー
ブルの信頼性を確保することができるという効果があ
る。

【００７０】実施の形態１０．実施の形態１，２では、
立ち上げ報告メッセージや、自計算機内リソース来歴管
理テーブルにより、計算機が停止している間に他の計算
機のリソースが変更された場合も、計算機立ち上げ後に
把握できるしくみになっていたが、この方法では、時刻
管理の処理が煩雑であり、また、ネットワークや、計算
機の一時的な障害により立ち上げ報告メッセージが喪失
した場合には、リソース管理テーブルの整合性がとれな
くなるという問題があった。

【００７１】実施の形態１０はこの問題を解決するため
に考えられたもので、実施の形態８，９で考えた現状報
告メッセージとリソース情報通知要求メッセージによ
り、自計算機内リソース来歴管理テーブルを不要にし、
リソース管理テーブルの信頼性を確保できるようにした
ものである。図１７は実施の形態９の処理を示すフロー
図である。

【００７２】次に動作について説明する。（１）ｓｔｅｐ１２０１において、計算機Ａが起動した
ものとする。（２）次にｓｔｅｐ１２０２において、計算機Ａは自計
算機が管理するリソースの内、有効なものを現状報告メ
ッセージのブロードキャスト送信にてネットワーク内の
全計算機に通知する。（３）ｓｔｅｐ１２１１において、該メッセージを受信
した計算機Ｂは自計算機内のネットワークリソース管理
テーブルを更新する。

【００７３】（４）次に計算機Ａは、ｓｔｅｐ１２０３
において、リソース情報通知要求メッセージをブロード
キャスト送信する。（５）ｓｔｅｐ１２１２において、該メッセージを受信
した計算機Ｂは現状報告メッセージを計算機Ａに送信す
る。ｓｔｅｐ１２０４において該メッセージを受信した
計算機Ａは自計算機内のネットワークリソース管理テー
ブルを更新する。

【００７４】以上説明したように実施の形態１０によれ
ば、自計算機内リソース来歴管理テーブルは不要とな
り、リソースの来歴時刻管理をしなくても、立ち上げ時
にネットワーク上のリソースの最新情報を取得できるの
で、リソース管理テーブルの信頼性を確保できる効果が
ある。

【００７５】実施の形態１１．実施の形態８では、リソ
ースの更新時に現状報告メッセージを授受するように
し、実施の形態１０では、計算機の立ち上げ時のみに、
現状報告メッセージを授受するようにしたが、実施の形
態８と実施の形態１０とを併せて、リソース更新時と計
算機立ち上げ時共、現状報告メッセージを授受するよう
にしてもよい。

【００７６】

【発明の効果】以上のようにこの発明によれば、リソー
スを更新した定義情報を一括送信したり、自計算機の管
理するリソースの内少なくとも動作しているリソースを
送信したり、また、計算機間のリソース定義情報の授受
には計算機アドレスを用いたりすることにより通信負荷
を軽減することができる。

【図面の簡単な説明】

【図１】この発明の実施の形態１によるリソース管理
方法のリソース変更メッセージのフォーマット図であ
る。

【図２】この発明の実施の形態１によるリソース管理
方法の動作のフローチャートである。

【図３】この発明の実施の形態２によるリソース管理
方法のリソース変更メッセージのフォーマット図であ
る。

【図４】この発明の実施の形態２によるリソース管理
方法のネットワークリソース管理テーブルの図である。

【図５】この発明の実施の形態２によるリソース管理
方法のローカルリソース管理テーブルの図である。

【図６】この発明の実施の形態２によるリソース管理
方法の動作のフローチャートである。

【図７】この発明の実施の形態３によるリソース管理
方法の停止報告メッセージのフォーマット図である。

【図８】この発明の実施の形態３によるリソース管理
方法の動作のフローチャートである。

【図９】この発明の実施の形態４によるリソース管理
方法の動作のフローチャートである。

【図１０】この発明の実施の形態５によるリソース管
理方法の動作のフローチャートである。

【図１１】この発明の実施の形態６によるリソース管
理方法の動作のフローチャートである。

【図１２】この発明の実施の形態７によるリソース管
理方法の動作のフローチャートである。

【図１３】この発明の実施の形態８によるリソース管
理方法の現状報告メッセージのフォーマット図である。

【図１４】この発明の実施の形態８によるリソース管
理方法の動作のフローチャートである。

【図１５】この発明の実施の形態９によるリソース管
理方法のリソース情報通知要求メッセージのフォーマッ
ト図である。

【図１６】この発明の実施の形態９によるリソース管
理方法の動作のフローチャートである。

【図１７】この発明の実施の形態１０によるリソース
管理方法の動作のフローチャートである。

【図１８】従来の計算機立ち上げ時のリソース更新処
理のフローチャートである。

【図１９】従来の計算機のネットワークシステムの構
成図である。

【図２０】従来のリソース管理テーブルを示す図であ
る。

【図２１】従来の計算機内のリソース来歴管理テーブ
ルを示す図である。

【図２２】従来の新規リソース登録時の計算機の状態
を示すタイムチャートである。

【図２３】従来の立ち上げ報告メッセージおよびリソ
ース変更メッセージのフォーマット図である。

【図２４】従来の新規リソース登録時の計算機の状態
を示すタイムチャートである。

【符号の説明】

１通信媒体２通信制御装置１０，１１リソース変更メッセージ１２ネットワークリソース管理テーブル１３ローカルリソース管理テーブル１４停止報告
メッセージ１５現状報告メッセージ１６リソース情
報通知要求メッセージＡ〜Ｆ計算機ＦＩＬＥＢ，ＦＩ
ＬＥＣファイルＰＲＩＮＴＡプリンタ

Claims

【特許請求の範囲】

【請求項１】ネットワーク内の計算機がそのネットワ
ーク内で共有されるリソースの追加、削除等のリソース
更新を行った時には、当該計算機がネットワーク内の他
計算機に対して上記更新したリソースの定義情報を送信
し、上記他計算機は受信した上記定義情報により自計算
機内のリソース定義情報を更新することにより、更新さ
れたリソースへのアクセスを可能とし、計算機の立ち上
げ時に、その立ち上げ計算機が前回停止した時刻と今回
立ち上がった時刻とからなる立ち上げ報告メッセージを
ネットワーク内の他計算機へ報告し、上記メッセージの
報告先計算機は、上記メッセージの報告元計算機の停止
中に自計算機のリソースの更新を行っていた場合には、
その更新したリソースの定義情報を上記報告元計算機へ
送信してリソース定義情報を更新させ、上記報告先計算
機が報告元計算機の停止中に立ち上がっていた場合に
は、その立ち上げ時に送信したのと同じ立ち上げ報告メ
ッセージを上記報告元計算機へ送信し、上記報告元計算
機は上記報告先計算機が停止中に自計算機のリソースの
更新を行っていた場合には、その更新したリソースの定
義情報を上記報告先計算機へ送信してリソース定義情報
を更新させるようにしたリソース管理方法において、上
記定義情報を送信する場合に、リソースの追加／削除等
の変更があった全てのリソースの定義情報を一括送信す
るようにしたことを特徴とするリソース管理方法。
【請求項２】ネットワーク内の計算機がそのネットワ
ーク内で共有されるリソースの追加、削除等のリソース
更新を行った時には、当該計算機がネットワーク内の他
計算機に対して自計算機が管理するリソースの内少なく
とも動作しているリソースの定義情報を一括送信し、上
記他計算機は受信した上記定義情報により自計算機内の
リソース定義情報を更新することにより、更新されたリ
ソースへのアクセスを可能とし、計算機の立ち上げ時
に、その立ち上げ計算機が前回停止した時刻と今回立ち
上がった時刻とからなる立ち上げ報告メッセージをネッ
トワーク内の他計算機へ報告し、上記メッセージの報告
先計算機は、上記メッセージの報告元計算機の停止中に
自計算機のリソースの更新を行っていた場合には、自計
算機が管理するリソースの内少なくとも動作しているリ
ソースの定義情報を上記報告元計算機へ一括送信してリ
ソース定義情報を更新させ、上記報告先計算機が報告元
計算機の停止中に立ち上がっていた場合には、その立ち
上げ時に送信したのと同じ立ち上げ報告メッセージを上
記報告元計算機へ送信し、上記報告元計算機は上記報告
先計算機が停止中に自計算機のリソースの更新を行って
いた場合には、自計算機が管理するリソースの内少なく
とも動作しているリソースの定義情報を上記報告先計算
機へ一括送信してリソース定義情報を更新させるように
したことを特徴とするリソース管理方法。
【請求項３】ネットワーク内の計算機がそのネットワ
ーク内で共有されるリソースの追加、削除等のリソース
更新を行った時には、当該計算機がネットワーク内の他
計算機に対して上記更新したリソースの定義情報を送信
し、他計算機は受信した上記定義情報により自計算機内
のリソース定義情報を更新することにより、更新された
リソースへのアクセスを可能とし、且つ、上記定義情報
を送信する場合に、リソースの追加／削除等の変更があ
った全てのリソースの定義情報を一括送信し、計算機の
立ち上げ時に、その立ち上げ計算機は、自計算機が管理
しているリソースの内少なくとも動作しているリソース
の定義情報を他計算機へ一括送信し、他計算機は受信し
たリソースの定義情報により自計算機内のリソース定義
情報を更新すると共に、自計算機が管理しているリソー
スの内少なくとも動作しているリソース定義情報を一括
返信して立ち上げ計算機のリソースの定義情報を更新さ
せるようにしたことを特徴とするリソース管理方法。
【請求項４】ネットワーク内の計算機がそのネットワ
ーク内で共有されるリソースの追加、削除等のリソース
更新を行った時には、当該計算機がネットワーク内の他
計算機に対して自計算機が管理するリソースの内少なく
とも動作しているリソースの定義情報を一括送信し、他
計算機は受信した上記定義情報により自計算機内のリソ
ース定義情報を更新することにより、更新されたリソー
スへのアクセスを可能とし、計算機の立ち上げ時に、そ
の立ち上げ計算機は、自計算機が管理しているリソース
の内少なくとも動作しているリソースの定義情報を他計
算機へ一括送信し、他計算機は受信したリソースの定義
情報により自計算機内のリソース定義情報を更新すると
共に、自計算機が管理しているリソースの内少なくとも
動作しているリソース定義情報を一括返信して立ち上げ
計算機のリソースの定義情報を更新させるようにしたこ
とを特徴とするリソース管理方法。
【請求項５】請求項１〜４のいずれか１項のリソース
管理方法において、定義情報は、ネットワーク内で共有
されるリソース毎に付与したネットワークアドレスを設
定した定義情報としておき、定義情報を授受する場合に
は、上記ネットワークアドレスによりリソースを判別す
るようにしたことを特徴とするリソース管理方法。
【請求項６】請求項１〜４のいずれか１項のリソース
管理方法において、定義情報は、計算機とこの計算機が
管理しているリソースとを同一アドレスとする計算機ア
ドレスを設定すると共に、上記リソースを区別するため
のリソースＩＤを設定した定義情報としておき、定義情
報を授受する場合には、上記計算機アドレスおよびリソ
ースＩＤによりリソースを管理している計算機とリソー
スとを判別するようにしたことを特徴とするリソース管
理方法。
【請求項７】請求項１〜６のいずれか１項のリソース
管理方法において、計算機が停止する際には、その停止
計算機が停止に関わる定義情報を送信する代わりに、計
算機停止通知を他計算機へ送信し、停止通知を受けた他
計算機は、その停止通知に応じて自計算機内のリソース
定義情報を更新するようにしたことを特徴とするリソー
ス管理方法。
【請求項８】請求項１〜７のいずれか１項のリソース
管理方法において、計算機が停止情報を送信できずに異
常終了した場合、その異常計算機の管理するリソースに
アクセスした計算機は、アクセスの失敗により上記リソ
ースが停止状態であると判断し、その判断に応じて自計
算機内のリソース定義情報を更新することを特徴とする
リソース管理方法。
【請求項９】請求項１〜７のいずれか１項のリソース
管理方法において、計算機が停止情報を送信できずに異
常終了した場合、その異常計算機の管理するリソースに
アクセスした計算機は、アクセスの失敗により上記リソ
ースが停止状態であると判断し、その判断に応じて自計
算機内のリソース定義情報を更新すると共に、他計算機
に上記判断結果を通知し、通知を受けた他計算機におい
ても、上記リソースにアクセスした計算機と同様に自計
算機内のリソース定義情報を更新することを特徴とする
リソース管理方法。
【請求項１０】請求項１〜７のいずれか１項のリソー
ス管理方法において、計算機が停止情報を送信できずに
異常終了した場合、その異常計算機の管理するリソース
にアクセスした計算機は、アクセスの失敗により上記異
常計算機が管理する全てリソースが停止状態であると判
断し、その判断に応じて自計算機内のリソース定義情報
を更新することを特徴とするリソース管理方法。
【請求項１１】請求項１〜７のいずれか１項のリソー
ス管理方法において、計算機が停止情報を送信できずに
異常終了した場合、その異常計算機の管理するリソース
にアクセスした計算機は、アクセスの失敗により上記異
常計算機が管理する全てのリソースが停止状態であると
判断し、その判断に応じて自計算機内のリソース定義情
報を更新すると共に、他計算機に上記判断結果を通知
し、通知を受けた他計算機においても、上記リソースに
アクセスした計算機と同様に自計算機内のリソース定義
情報を更新することを特徴とするリソース管理方法。
【請求項１２】請求項１〜１１のいずれか１項のリソ
ース管理方法において、任意の計算機から他計算機にリ
ソース定義情報の通知要求を送信すると、上記他計算機
は、上記受信した通知要求に応じて自計算機の管理する
のリソース内少なくとも動作しているリソースの定義情
報を返信し、上記任意の計算機は上記返信内容に応じて
自計算機内のリソース定義情報を更新することを特徴と
するリソース管理方法。