(57)【要約】【課題】ジョブ実行中にそのジョブを実行しているリソースマネージャホストでリソースエラーが発生した場合に、業務停止を回避すること。【解決手段】ジョブの実行を行うリソースマネージャホストＡ〜Ｘのそれぞれは、ＣＰＵ、メモリ、ディスク等リソースを管理してジョブの実行を行い、ＣＰＵ効率が悪くなったり、メモリやディスクが不足した場合に、統合マネージャホスト１０にリソースエラーを報告する。統合マネージャホスト１０は、エラーを報告したリソースマネージャホストで行っていたジョブを実行可能な他のリソースマネージャホストを探し、あるいは、ジョブスケジュールを変更して、エラーを報告したリソースマネージャホストで行っていたジョブをたのリソースマネージャホストに実行させる。【選択図】      図１
2005031892.tif 000002
【特許請求の範囲】
【請求項１】
スケジューリングされているジョブ群を実行するジョブ実行システムにおいて、複数種のリソースを備えてジョブの実行を行う複数のリソースマネージャホストと、ジョブ実行の管理を行う統合マネージャホストとを備え、前記リソースマネージャホストは、ジョブ実行中のリソースの状況を監視してリソースエラーを検知するリソースエラー検知手段と、リソースエラーを前記統合マネージャホストに報告するリソースエラー通知手段とを有し、前記統合マネージャホストは、リソースエラーを報告してきたリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定する手段を有することを特徴とするジョブ実行システム。
【請求項２】
スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において、複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け、リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することを特徴とするジョブ実行制御方法。
【請求項３】
前記移行先のリソースマネージャホストで不足するアプリケーションを移行先のリソースマネージャホストに送信してインストールさせることを特徴とする請求項２記載のジョブ実行制御方法。
【請求項４】
前記リソースの状況から移行先のリソースマネージャホストを決定することができない場合、ジョブスケジュールの変更を行って移行先のリソースマネージャホストを決定することを特徴とする請求項２または３記載のジョブ実行制御方法。
【請求項５】
前記移行先のリソースマネージャホストのリソースに不要な情報がある場合、それらを削除させることを特徴とする請求項２、３または４記載のジョブ実行制御方法。
【請求項６】
スケジューリングされているジョブ群の実行を制御するジョブ実行制御プログラムにおいて、複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け付ける処理ステップと、リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定する処理ステップとを有し、前記各処理ステップを実行することによりジョブの実行を制御することを特徴とするジョブ実行制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ジョブ実行システム及び実行制御方法に係り、特に、情報処理システムにおけるスケジューリングされたジョブの実行システム及び実行制御方法に関する。
【０００２】
【従来の技術】
近年の情報処理システムは、無人で業務ジョブを処理するために、時刻予約によるジョブの自動起動、先行ジョブの終了による次に予約した接続ジョブの自動起動等のジョブスケジューリングが行われている。
【０００３】
また、情報処理システムとして、１台のマネージャホストを用意し、そのマネージャホストで定義したジョブを、他の複数の実行ホストで実行することができるようにし、さらに、実行結果をマネージャホストで集中管理することができるシステムが知られている。
【０００４】
前述のようなジョブ実行システムは、特許文献１等に記載されているように、あるホストで実行していたジョブが、そのホストで実行することができなくなっとき、他のホストで再実行することができる。
【０００５】
【特許文献１】
特開平１１−３５３２８４号公報
【０００６】
【発明が解決しようとする課題】
ジョブのスケジュールを行ってジョブの実行を制御する前述した従来技術は、ジョブスケジュールの構築時に、マシン情報、実行ジョブ情報、ジョブ実行条件等を考慮して、スケジューリングを決定するが、その後のシステム運用により、業務データ容量が変更され、各ジョブの実行時間がスケジュール構築時の予想と大きく異なった場合等に、各ホストマシンのＣＰＵに割り当てられているジョブの実行が非効率的なものとなり、システムにスケジューリングされているジョブの処理時間が増大するという問題点を生じさせていた。
【０００７】
また、前述した従来技術は、システム運用中に、実行中のホスト内で、メモリやディスクの容量不足等のリソースエラー等、マシントラブルが生じた場合、エラー時に行うジョブを定義しておくことにより、トラブルを回避することができるが、正常なケースのジョブ実行が停止してしまうという問題点を有している。
【０００８】
本発明の目的は、前述した従来技術の問題点を解決し、ジョブ実行中のリソースエラーによる業務自体の停止を回避することができるようにしたジョブの実行システム及び実行制御方法を提供することにある。
【０００９】
【課題を解決するための手段】
本発明によれば前記目的は、スケジューリングされているジョブ群を実行するジョブ実行システムにおいて、複数種のリソースを備えてジョブの実行を行う複数のリソースマネージャホストと、ジョブ実行の管理を行う統合マネージャホストとを備え、前記リソースマネージャホストが、ジョブ実行中のリソースの状況を監視してリソースエラーを検知するリソースエラー検知手段と、リソースエラーを前記統合マネージャホストに報告するリソースエラー通知手段とを有し、前記統合マネージャホストが、リソースエラーを報告してきたリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定する手段を有することにより達成される。
【００１０】
また、前記目的は、スケジューリングされているジョブ群の実行を制御するジョブ実行制御方法において、複数種のリソースを備えてジョブを実行するリソースマネージャホストからのリソースエラーの報告を受け、リソースエラーの報告を行ったリソースマネージャホスト以外の他のリソースマネージャホストのリソースの状況からリソースエラーの報告を行ったリソースマネージャホストで行っていたジョブを実行することが可能な移行先のリソースマネージャホストを決定することにより達成される。
【００１１】
【発明の実施の形態】
以下、本発明によるジョブ実行システム及び実行制御方法の実施形態を図面により詳細に説明する。
【００１２】
図１は本発明の一実施形態によるジョブ実行システムの構成を示すブロック図、図２は統合マネージャホストの内部構成を示すブロック図、図３はリソースマネージャホストの内部構成を示すブロック図である。図１〜図３において、１０は統合マネージャホスト、２０〜４０はリソースマネージャホスト、５０〜９０はリソース、１００はＰＰ情報データベース、１１０はジョブスケジュール実行部、１２０はジョブ実行部、１３０はリソースエラー情報受信部、１４０はリソースエラー情報解読部、１５０は各リソース使用状況判定部、１６０はリソース調査部、１７０はリソース削除依頼部、１８０はインストール指示部、１９０はインストール情報送信部、２００はジョブスケジュール定義変更部、２１０はリソースエラー検知部、２２０はリソースエラー通知部、２３０はリソース情報通知部、２４０は命令受け付け部、２５０はリソース削除部、２６０はインストール情報受信部、２７０はインストール実行部である。
【００１３】
本発明の実施形態によるジョブ実行システムは、図１に示すように、統合マネージャホスト１０と複数のリソースマネージャホスト２０〜４０とがネットワークを介して接続されて構成されている。リソースマネージャホスト２０〜４０は、管理対象となるＣＰＵ、メモリ、ディスク等の多種のリソース５０〜９０を含んで、あるいは、接続されて構成され、ジョブの実行を行う。また、統合マネージャホスト１０は、リソースマネージャホストで使用するアプリケーション（ＰＰ）情報を格納して管理するＰＰ情報データベース１００が接続されており、実行すべきジョブのスケジュール管理、ジョブを実行するリソースマネージャホストの管理を行う。
【００１４】
統合マネージャホスト１０は、図２に示すような各種の機能部を備えて構成されており、次に、これらの機能部のそれぞれについて説明する。
【００１５】
ジョブスケジュール実行部１１０は、すでに定義されているジョブスケジュールを元にそのジョブスケジュールを制御する。
【００１６】
ジョブ実行部１２０は、ジョブスケジュールにより定義されている１つ１つのジョブを実行する。
【００１７】
リソースエラー情報受信部１３０は、リソースマネージャホストから送信されてきたエラー通知を受信する。
【００１８】
リソースエラー情報解読部１４０は、リソースエラー情報受信部１３０で受け取ったエラー通知を解読する。
【００１９】
リソース使用状況判定部１５０は、ネットワークを介して接続されている全てのリソースマネージャホストのリソース群がどの程度使用されているかを調査し、リソースエラーにより停止しているジョブを行うことのできる移動先のリソースマネージャホストを決定する。
【００２０】
リソース調査部１６０は、ジョブを実行することができる移動先のリソースマネージャホストが決定したら、そのリソースマネージャホストにインストールしなくてはならないＰＰ等の情報や、そのリソースマネージャホストに存在する不要な情報を洗い出す。
【００２１】
リソース削除依頼部１７０は、リソース使用状況判定部１５０の判定で、どのリソースマネージャホストも、移動先としてジョブの実行を行うことができるだけの余裕がない場合に、各リソースマネージャホストが持つリソースの使用率をみて、解放できそうなリソースを持つリソースマネージャに不要情報の削除の依頼を行う。
【００２２】
インストール指示部１８０は、移動先のリソースマネージャホストにＰＰ情報等のジョブの実行に必要な情報のインストールを依頼する。
【００２３】
インストール情報送信部１９０は、実際にマシンにインストールする情報を、リソースマネージャホストに送信する。
【００２４】
ジョブスケジュール定義部２００は、ジョブをどのような順番で、どのリソースマネージャホストを使用するか、どの時間帯で実行するかを決定し、ジョブスケジュールテーブルの書き換えを行う。
【００２５】
リソースマネージャホストのそれぞれは、図２に示すような各種の機能部を備えて構成されており、次に、これらの機能部のそれぞれについて説明する。
【００２６】
リソースエラー検知部２１０は、自リソースマネージャホスト内でのリソースエラーを検知し、リソースエラー通知部２２０は、取得したリソースエラーの情報を統合マネージャホスト１０に対して通知する。
【００２７】
リソース情報通知部２３０は、自リソースマネージャホスト内でどんなリソースがどれだけ不足しているかの情報、及び、ジョブの実行に必要なＰＰ等の情報を統合マネージャホスト１０に対し通知する。
【００２８】
命令受け付け部２４０は、統合マネージャホスト１０から送信されてきた命令を受け付けて解読する。
【００２９】
リソース削除部２５０は、リソース削除依頼部１７０から通知された不要と判断された情報によりリソースを解放する。
【００３０】
インストール情報受信部２６０は、ジョブ実行に必要なインストール情報を統合マネージャホスト１０から受信し、インストール実行部２７０は、ジョブ実行に必要な情報をインストールする。
【００３１】
次に、前述したように構成されるジョブ実行システムにおけるジョブ実行中のリソースエラーによる業務の停止を回避する処理動作を説明するが、その処理動作を説明する前に、処理の中で必要とするリソースマネージャホストのリソース監視画面、各種データの通信プロトコル、各種データテーブルの構成について図面により説明する。
【００３２】
図４はリソースマネージャホストで自ホストのリソースを監視するために用いるリソース監視画面の例を示す図である。この表示画面は、リソースマネージャホストに登録されているそのホストのリソースの使用状況を表示するものであり、図示例は、この画面を表示しているリソースマネージャホストが、リソースＡ〜Ｄとして、ＣＰＵ、メモリ、ディスク、その他を有し、リソースＡ〜Ｃがジョブ▲１▼により使用されており、リソースＡ（ＣＰＵ）の使用率が３０％、リソースＢ（メモリ）、Ｃ（ディスク）をそれぞれ２０ＭＢ、８０ＭＢ使用していることを表示している。
【００３３】
図５はエラー情報データの通信プロトコルの例を示す図である。このプロトコルは、リソースマネージャホストのリソースエラー通知部２２０から統合マネージャホスト１０にエラー情報を通知するために使用されるもので、データの先頭にこのデータがエラー情報データであることを示すエラーデータ開始のフラグを設定し、それに続いて、エラーが発生したリソースマネージャホスト名、エラー要因となった容量不足等のリソースの種別、どのようなエラーが発生したのかを示すエラー種別、エラーが発生した日時が設定されて構成される。
【００３４】
図６はエラー情報データテーブルの構成例を示す図である。エラー情報データテーブルは、統合マネージャホストがリソースマネージャホストから送信されてきた図５に示すエラー情報を切り分けて格納管理するためのものである。どのリソースマネージャホストのどのリソースで、どのようなエラーが起きたのかを切り分けて示し、エラーが発生したリソースマネージャホスト名、エラー要因となった容量不足等のリソースの種別、どのようなエラーが発生したのかを示すエラー種別、エラーが発生した日時が管理される。図示の第１行のレコードの例の場合、リソースマネージャホストＡにおいて、Ｍｅｍｏｒｙ１で、Ｅｍｐｔｙ  となるエラーが日時ＹＹＹ／ＭＭ／ＤＤ  ｈｈ／ｍｍ／ｄｄに発生したことを示している。
【００３５】
図７はリソース情報データの通信プロトコルの例を示す図である。このリソース情報１０００は、リソースエラーを生じたリソースマネージャホストが統合マネージャホストに送信する移動したい（実行中だった）ジョブの情報やジョブ実行に必要なＰＰ情報等のリソース情報である。
【００３６】
このリソース情報１０００は、データの先頭にこのデータがリソース情報データであることを示すリソースデータ開始のフラグを設定し、それに続いて、送信元リソースマネージャホスト名、実行中であったジョブのＩＤ、送信日時が設定され、その後ろに、ジョブ実行に必要なメモリ容量、ディスク容量、推奨ＣＰＵ性能、ＰＰ数、ＰＰ名とそのバージョンを付け、最後に、このリソース情報データの後に送信するＰＰのインストールに必要なレジストリファイルのファイル数、ＰＰの緩急設定に必要な情報のファイル数を付与して構成されている。図示例では、２つのＰＰのＰＰ名１、２があり、それぞれに、バージョン、レジストリファイルのファイル数、情報のファイル数が設定されている。
【００３７】
図８はリソース情報データテーブルの構成例を示す図である。このリソース情報データテーブル１０１０は、リソースマネージャホストから送信されてきた図７に示すリソース情報を、統合マネージャホスト側で切り分けて、リソース情報データテーブルに格納したものである。
【００３８】
図９はパフォーマンス情報データテーブルの構成例を示す図である。このパフォーマンス情報データテーブル１０１１は、統合マネージャホストが、他に利用可能なリソースマネージャホストのリソースの使用状況を調べ、その結果を格納するものであり、管理対象のリソースマネージャホスト名、リソース数、日時、リソース名、使用率が格納される。図示例では、管理対象のリソースマネージャホスト名ＨｏｓｔＡが３つのリソースを持ち、日時  ２００３／０２／２１  １０：３０：００の状態で、リソースとしてＣＰＵ、ＭＥＭＯＲＹ、ＤＩＳＫを持ち、それぞれ、５０％、３０％、６０％の使用率であることを示している。なお、使用状況を調査する方法は、公知の方法を使用することができる。
【００３９】
図１０は統合マネージャホスト１０に接続されているＰＰ情報データベース１００の構成を説明する図である。このＰＰ情報データベース１００には、統合マネージャホストが管理しているリソースマネージャホストにインストールしてあるＰＰ名とバージョンとが、各リソースマネージャホスト毎に区別して登録されている。管理対象のリソースマネージャホストに新しくＰＰがインストールされると、このデータベースに、ＰＰ名とバージョンとが逐次登録される。
【００４０】
図１１はインストール指示の通信プロトコル例を示す図である。インストール指示は、ジョブ実行に必要な情報が足りなくて、そのリソースマネージャホストがジョブ実行可能状態になかった場合に、インストール指示部１８０が、リソースマネージャホストに送信する指示である。
【００４１】
このインストール指示の通信プロトコル１１００は、データの先頭にこのデータがインストール指示のデータであることを示すインストール指示データ開始フラグを設定し、それに続いて、インストールするＰＰ名、バージョンＮｏ、このデータの後に送信するインストールに必要なインストール設定ファイルのファイル数、レジストリの設定に必要なレジストリ情報ファイルのファイル数、インストールするＰＰの環境設定に必要な情報ファイルのファイル数を付加して送信される。
【００４２】
図１２はインストール情報について説明する図である。このインストール情報１１１０は、図１１により説明したプロトコルによるインストール指示の後に送信する、実際にインストールに必要な情報ファイル群である。これらのファイル群は、インストールを行うインストーラファイルとそのインストーラに必要な情報を記載したインストーラ設定ファイル群、レジストリの設定に必要なレジストリファイル群、インストールＰＰの環境設定に必要なＰＰ環境設定ファイル群により構成される。
【００４３】
図１３はリソースの削除依頼の通信プロトコルの例を示す図である。このリソースの削除依頼は、ジョブスケジューリングを再定義して実行可能なリソースマネージャホストを決定した場合に、リソースの不要な情報の削除の削除をリソースマネージャホストに依頼するときに、統合マネージャホストからリソースマネージャホストに送信するものである。そして、このプロトコルは、その先頭に、このデータが削除依頼のデータであることを示す削除依頼開始のフラグが設定され、それに続いて、削除するＰＰ名称、バージョンＮｏを付与して送信される。
【００４４】
図１４はリソースマネージャホストでリソースエラーが生じた場合の統合マネージャホストにおけるリソースエラー回避の処理動作を説明するフローチャートであり、次に、これについて説明する。
【００４５】
（１）統合マネージャホストは、ジョブの全てが正常に実行されている場合、リソースエラー情報がリソースマネージャホストから送信されてくるのを待ち受ける待機状態にある。リソースエラー情報がリソースマネージャホストから図５により説明した通信データプロトコル９００の形で送信されてくると、このエラー情報は、統合マネージャホストのリソースエラー情報受信部１３０で受け取られる（ステップ３００）。
【００４６】
（２）リソースエラー情報受信部１３０は、受信したリソースエラー情報をリソースエラー情報解読部１４０に渡す。リソースエラー情報解読部１４０は、どのリソースマネージャホストのどのリソースで、どのようなエラーが起きたのかを切り分け、図６により説明したエラー情報データテーブル９１０に格納する（ステップ３１０）。
【００４７】
（３）統合マネージャホストは、ステップ３１０の情報の解読後、再びリソースマネージャホストから送信されてくる移動したい（実行中だった）ジョブの情報やジョブ実行に必要なＰＰ情報等のリソース情報の待ち受け状態になる。そして、統合マネージャホストは、図７により説明したようなリソース情報１０００をリソースマネージャホストから受け取ると、リソース情報を切り分けて、図８により説明したリソース情報テーブル１０１０に格納する。統合マネージャホストは、さらに、リソースマネージャホストから送信されてくるレジストリ情報ファイル、設定情報ファイルを受け取り、それらのファイルをユーザ指定のディレクトリへ一時保存する（ステップ３２０）。
【００４８】
（４）次に、統合マネージャホストは、リソース使用状況判定部１５０で、各リソースマネージャホストのリソースのパフォーマンス情報を取得（公知の機能を使用）し、図９により説明したようなパーフォーマンステーブルを作成する（ステップ３３０）。
【００４９】
（５）次に、統合マネージャホストは、他に利用することができるリソースマネージャホストを検索する。この検索は、前述したステップ３３０の処理で作成した図９に示すパフォーマンス情報データテーブル内のリソースとステップ３２０の処理で内容を格納した図８に示すリソース情報テーブルに格納されている移動したいジョブが必要とするリソースと比較することにより行われる。
【００５０】
例えば、リソースマネージャホストＡで実行されていたジョブ▲１▼をリソースマネージャホストＢに移すことが可能かを調べるものとする。ジョブ▲１▼が必要とするリソースとしてのメモリの最大容量は、図８に示しているように７１ＭＢであり、リソースマネージャホストＢのリソース使用率におけるメモリの使用率は、図９に示しているように５０％である。このため、リソースマネージャホストＢが備えているメモリの容量の残量、この場合５０％の残容量が７１ＭＢ以上あるか否かを調べる。同様に、ジョブ▲１▼が必要とするリソースとしてのディスク容量は、図８に示しているように１ＧＢであり、２つのディスクを持つリソースマネージャホストＢのリソース使用率におけるディスクの使用率は、図９に示しているように、それぞれ４０％、７０％である。このため、リソースマネージャホストＢが備えている２つのディスクの容量の残量、この場合６０％、３０％の残容量の何れか一方の残容量が１ＧＢ以上あるか否かを調べる。
【００５１】
全てのリソースについて前述したような比較を行い、この比較の結果、移動したいジョブが必要とするリソースより使用可能容量が大きいリソースを有する他のリソースマネージャホストを発見した場合、使用可能リソースマネージャホスト発見とし、発見できなかった場合、使用可能リソースマネージャホストなしと判定する（ステップ３４０）。
【００５２】
（６）ステップ３４０の判定で、他に利用できるリソースマネージャホストを発見できなかった場合、統合マネージャホストは、ジョブスケジュールを組み直して、組み直した結果、実行順序が遅いジョブの実行を行うリソースマネージャホストを実行可能なリソースマネージャホストとして決定する。なお、ジョブスケジュールの組み直しは、公知の手段を使用して行うことができる（ステップ３５０、３６０）。
【００５３】
（７）ステップ３６０の処理後、または、ステップ３４０の判定で、他に利用できるリソースマネージャホストを発見できた場合、リソース調査部１６０は、ジョブを実行する対象リソースマネージャホストに、ジョブ実行に必要なＰＰ情報等が存在するか、その対象リソースマネージャホストに不要な情報はないか等、そのリソースマネージャホストがジョブ実行可能状態であるか否かを調査する。必要なＰＰ等の調査は、図１０により説明した統合マネージャホストに接続されているＰＰ情報データベース１００に登録されている管理対象のリソースマネージャホストのＰＰ情報１０１を元に、図８に示したリソース情報の必要ＰＰ名を比較することにより行う（ステップ３７０）。
【００５４】
（８）ステップ３７０の調査での管理対象リソースマネージャホストのＰＰ情報に必要ＰＰが登録されているか等の結果により、そのリソースマネージャホストがジョブ実行可能状態か否かを判定する。すなわち、管理対象リソースマネージャホストのＰＰ情報に必要ＰＰが登録されていた場合、そのリソースマネージャホストがジョブ実行可能状態であると判定し、登録れていなかった場合、ジョブ実行可能状態にないと判定する。そして、そのリソースマネージャホストが実行可能状態になかった場合、ジョブ実行に必要な情報が足りないのか、後回しになったジョブが使用していたリソースがあり、その結果として必要なリソースが足りないのかを判定する（ステップ３８０）。
【００５５】
（９）ステップ３８０の判定で、ジョブ実行に必要な情報が足りないで、そのリソースマネージャホストがジョブ実行可能状態になかった場合、インストール指示部１８０は、図１１により説明したようなインストール指示通信プロトコル１１００を作成し、リソースマネージャホストに送信する（ステップ３９０）。
【００５６】
（１０）続いて、インストール情報送信部１９０は、ユーザ指定のディレクトリに保存してある図１２により説明したような必要ＰＰのインストーラや設定ファイル群であるインストール情報１１１０をリソースマネージャに送信する。その後、ステップ３７０からの処理に戻って、再びリソース調査からの処理を続ける（ステップ４００）。
【００５７】
（１１）ステップ３８０の判定で、後回しになったジョブが使用していたリソースがあり、その結果として必要なリソースが足りないで、そのリソースマネージャホストがジョブ実行可能状態になかった場合、すなわち、ステップ３４０の判定で、実行可能なリソースマネージャホストを発見することができずに、ジョブスケジューリングを再定義することにより、実行可能なリソースマネージャホストを決定した場合、リソース削除依頼部１７０は、そのリソースマネージャホストにリソース削除の依頼を行う。ここでは、図１３に示したようなリソースの不要な情報の削除依頼プロトコル１２００を作成して、リソースマネージャホストに送信する。削除して欲しいＰＰ情報の決定は、ステップ３５０、ステップ３６０の処理で決定された後回しになったジョブのＰＰ情報を削除対象ＰＰとする。その後、ステップ３７０からの処理に戻って、再びリソース調査からの処理を続ける（ステップ４１０）。
【００５８】
（１２）ステップ３８０の判定で、そのリソースマネージャホストがジョブ実行可能状態にあると判断された場合、ジョブスケジュール定義変更部２００は、ジョブスケジュールを組み直し、ジョブ実行部１２０は、ジョブの実行を再開する。ジョブスケジュールの組み直し、及び、ジョブ実行は、公知の手段により行うことができる（ステップ４２０、４３０）。
【００５９】
図１５は前述したステップ３５０の処理で行われるジョブスケジュールの組み直しの例について説明する図であり、次に、これについて説明する。
【００６０】
図１５（ａ）に６００として示すように、ジョブ▲１▼、▲２▼が同一のあるいは異なるリソースマネージャホストで実行され、いま、ジョブ▲３▼、▲４▼、▲５▼が異なるリソースマネージャホスト上で実行中であるとし、この状態で、ジョブ▲３▼を実行中のリソースマネージャホストでリソースエラーが生じたとする。そして、このときに、ステップ３５０のジョブスケジュールの組直しの処理に移行して、ジョブスケジュールの組み直しを行うと、実行順序が遅くてもかまわないジョブ▲５▼を実行しているリソースマネージャホストにジョブ▲３▼を移動して実行させる。すなわち、ジョブ▲５▼を実行しているリソースマネージャホストは、ジョブ▲５▼の実行に必要であったリソースが不要となり、このジョブ▲５▼に実行に必要であったリソースを使用することにより、ジョブ▲３▼の処理を実行することが可能となる。ジョブ▲５▼は、ジョブ▲３▼か、ジョブ▲４▼の実行後に実行するようにスケジュールすることになるが、ジョブ▲４▼がすでに実行中であるため、ジョブ▲４▼はジョブ▲３▼より先にその処理が終了することになる。このため、ジョブ▲５▼は、ジョブ▲４▼の実行中であるリソースマネージャホストに移動する。このような、ジョブスケジュールの組み直しにより、ジョブスケジュール変更後のスケジュールは、図１５（ｂ）に６０１として示すようなものとなる。なお、図１５（ａ）で最後に実行されればよいとされていたジョブ▲６▼は、図１５（ｂ）に示す組み直しの場合にも最後に行われるようにされる。
【００６１】
図１６はリソースマネージャホストでリソースエラーが生じた場合のリソースマネージャホストにおけるリソースエラー回避の処理動作を説明するフローチャートであり、次に、これについて説明する。ここでの処理は、自リソースマネージャホストでリソースエラーを生じた場合、及び、他のリソースマネージャホストでリソースエラーを生じた場合の両者の処理を含むものである。
【００６２】
（１）各リソースマネージャホストは、自ホスト内のリソースを監視している。いま、図１に示すリソースマネージャホストＡ２０において、リソースＡ−１でリソース不足が発生したものとする。この場合、リソースマネージャホストのリソースエラー検知部２１０（図４により説明したリソース監視画面）は、そのリソース不足エラーを検知する。このエラー検知は、公知の手段により行うことができ、各リソースに使用率のしきい値（ユーザ設定）を設け、それを越えた場合にエラーとみなすこととして行う（ステップ５００）。
【００６３】
（２）リソースエラー検知部２１０がリソースエラーを検知すると、リソースマネージャホストのリソースエラー情報通知部２２０は、統合マネージャホストにリソースエラーが起きたことを通知する。この通知は、図５により説明したエラー情報データ通信プロトコル９００を作成し、これを統合マネージャホストに送信することにより行われる（ステップ５１０）。
【００６４】
（３）次に、リソースマネージャホストは、実行することができなくなったジョブの情報や、ジョブ実行に必要なＰＰ情報等のリソース情報を、リソース情報通知部２３０から統合マネージャホストに通知する。この通知は、図７により説明したように、リソース情報通信プロトコルを作成して送信し、その後、必要ＰＰのレジストリ情報からレジストリ情報ファイルを作成し、さらに、ＰＰの設定が定義してあるファイルをコピーし、これらのファイル群を、リソース情報通知後に、続けて統合マネージャホストに転送することにより行われる（ステップ５２０）。
【００６５】
ステップ５２０の処理の後、リソースエラーを発生したリソースマネージャホストは、統合マネージャホスト側からの命令を待ち受ける状態となる。また、リソースエラーを発生しなかったリソースマネージャホストは、リソースの監視を行いながら統合マネージャホスト側からの命令を待ち受ける状態となっている。
【００６６】
（４）リソースマネージャホストの命令受け付け部２４０は、統合マネージャホストから送信された命令を受信すると、その命令が「リソース削除依頼」であるか、「インストール指示」であるか、「ジョブ実行」であるかに切り分ける（ステップ５３０）。
【００６７】
（５）ステップ５３０で受信した命令がインストール指示であった場合、インストール情報受信部２６０は、次に送られてくるインストール情報を受信し、インストール実行部２７０が、そのインストール情報をマシン内にインストールする。その後、再び、命令待ち受け状態となる（ステップ５５０、５６０）。
【００６８】
（６）ステップ５３０で受信した命令がリソース削除依頼であった場合、リソース削除部２５０は、送られてきた削除依頼データで指定してある不要な情報を削除し、その後、再び、命令待ち受け状態となる（ステップ５４０）。
【００６９】
（７）ステップ５３０で受信した命令がジョブ実行であった場合、そのリソースマネージャホストは、ジョブの実行を開始し、また、実行中に使用する各リソースの監視を開始する（ステップ５７０）。
【００７０】
前述した本発明の実施形態における各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。
【００７１】
前述した本発明の実施形態によれば、ジョブ実行中にリソースエラーを発生させたリソースマネージャホストは、統合マネージャホストに対して、リソースエラーの発生を報告し、他のリソースマネージャホスト実行中のジョブを移すことができるので、リソースエラーによる業務停止を回避することができる。
【００７２】
前述した本発明の実施形態は、リソースマネージャホストでリソースエラーが発生した場合を例として説明したが、本発明は、リソースマネージャホストのリソース以外の他の機能に障害が発生して、そのリソースマネージャホストでジョブの実行を行うことができなくなった場合にも適用することができる。この場合、統合マネージャホストが、リソースマネージャホストとの間で通信を行うことができなくなったことを検出して対応すればよい。
【００７３】
【発明の効果】
以上説明したように本発明によれば、ジョブ実行中にそのジョブを実行しているリソースマネージャホストでリソースエラーが発生した場合にも、業務停止を回避することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態によるジョブ実行システムの構成を示すブロック図である。
【図２】統合マネージャホストの内部構成を示すブロック図である。
【図３】リソースマネージャホストの内部構成を示すブロック図である。
【図４】リソースマネージャホストで自ホストのリソースを監視するために用いるリソース監視画面の例を示す図である。
【図５】エラー情報データの通信プロトコルの例を示す図である。
【図６】エラー情報データテーブルの構成例を示す図である。
【図７】リソース情報データの通信プロトコルの例を示す図である。
【図８】リソース情報データテーブルの構成例を示す図である。
【図９】パフォーマンス情報データテーブルの構成例を示す図である。
【図１０】統合マネージャホストに接続されているＰＰ情報データベースの構成を説明する図である。
【図１１】インストール指示の通信プロトコル例を示す図である。
【図１２】インストール情報について説明する図である。
【図１３】リソースの削除依頼の通信プロトコルの例を示す図である。
【図１４】リソースマネージャホストでリソースエラーが生じた場合の統合マネージャホストにおけるリソースエラー回避の処理動作を説明するフローチャートである。
【図１５】ジョブスケジュールの組み直しの例について説明する図である。
【図１６】リソースマネージャホストでリソースエラーが生じた場合のリソースマネージャホストにおけるリソースエラー回避の処理動作を説明するフローチャートである。
【符号の説明】
１０  統合マネージャホスト
２０〜４０  リソースマネージャホスト
５０〜９０  リソース
１００  ＰＰ情報データベース
１１０  ジョブスケジュール実行部
１２０  ジョブ実行部
１３０  リソースエラー情報受信部
１４０  リソースエラー情報解読部
１５０  各リソース使用状況判定部
１６０  リソース調査部
１７０  リソース削除依頼部
１８０  インストール指示部
１９０  インストール情報送信部
２００  ジョブスケジュール定義変更部
２１０  リソースエラー検知部
２２０  リソースエラー通知部
２３０  リソース情報通知部
２４０  命令受け付け部
２５０  リソース削除部
２６０  インストール情報受信部
２７０  インストール実行部
【図１】
2005031892.tif 000003
【図２】
2005031892.tif 000004
【図３】
2005031892.tif 000005
【図４】
2005031892.tif 000006
【図５】
2005031892.tif 000007
【図６】
2005031892.tif 000008
【図７】
2005031892.tif 000009
【図８】
2005031892.tif 000010
【図９】
2005031892.tif 000011
【図１０】
2005031892.tif 000012
【図１１】
2005031892.tif 000013
【図１２】
2005031892.tif 000014
【図１３】
2005031892.tif 000015
【図１４】
2005031892.tif 000016
【図１５】
2005031892.tif 000017
【図１６】
2005031892.tif 000018