(57)【要約】【課題】  同じ故障要因で故障し、その故障要因が復旧された複数のジョブに対して一括して動作を再開させることができる。【解決手段】  故障情報受信手段１ａは、故障が発生した際にジョブ２ａ，２ｂ，３ａ，３ｂが出力するジョブ自身の情報と故障要因とを含む故障情報を受信する。データベース格納手段１ｂは、故障情報を故障要因ごとに分類して、故障管理データベース１ｆに格納する。故障要因受信手段１ｃは、故障要因が復旧されたことによってオペレータより入力される故障要因を受信する。ジョブ検索手段１ｄは、故障管理データベース１ｆを参照して、故障要因に対応するジョブ２ａ，２ｂ，３ａ，３ｂを検索する。ジョブ動作再開手段１ｅは、検索されたジョブ２ａ，２ｂ，３ａ，３ｂの動作を再開させる。【選択図】  図１
2005222105.tif 000002
【特許請求の範囲】
【請求項１】
複数のバッチコンピュータによって実行される複数のジョブを復旧するジョブ復旧プログラムにおいて、
コンピュータを、
故障が発生した際に前記ジョブが出力する前記ジョブの情報と故障要因とを含む故障情報を受信する故障情報受信手段、
前記故障情報を前記故障要因ごとに分類して、故障管理データベースに格納するデータベース格納手段、
前記故障要因が復旧されたことによってオペレータより入力される前記故障要因を受信する故障要因受信手段、
前記故障管理データベースを参照して、前記故障要因に対応する前記ジョブを検索するジョブ検索手段、
前記ジョブの動作を再開させるジョブ動作再開手段、
として機能させることを特徴とするジョブ復旧プログラム。
【請求項２】
前記オペレータの要求に応じて、前記故障管理データベースに格納されている前記故障情報を表示装置に表示することを特徴とする請求項１記載のジョブ復旧プログラム。
【請求項３】
動作が再開された前記ジョブの前記故障情報を前記故障管理データベースから削除することを特徴とする請求項１記載のジョブ復旧プログラム。
【請求項４】
前記故障情報の前記故障管理データベースへの格納に関する履歴情報を登録履歴データベースに格納する登録履歴データベース格納手段をさらに有することを特徴とする請求項１記載のジョブ復旧プログラム。
【請求項５】
複数のバッチコンピュータによって実行される複数のジョブを復旧するジョブ復旧装置において、
故障が発生した際に前記ジョブが出力する前記ジョブの情報と故障要因とを含む故障情報を受信する故障情報受信手段と、
前記故障情報を前記故障要因ごとに分類して、故障管理データベースに格納するデータベース格納手段と、
前記故障要因が復旧されたことによってオペレータより入力される前記故障要因を受信する故障要因受信手段と、
前記故障管理データベースを参照して、前記故障要因に対応する前記ジョブを検索するジョブ検索手段と、
前記ジョブの動作を再開させるジョブ動作再開手段と、
を有することを特徴とするジョブ復旧装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はジョブ復旧プログラムおよびジョブ復旧装置に関し、特に複数のバッチコンピュータによって実行される複数のジョブを復旧するジョブ復旧プログラムおよびジョブ復旧装置に関する。
【背景技術】
【０００２】
一般にバッチ処理は、複数のジョブを組み合わせてジョブネットを構成し、処理が実行される。また、バッチ処理は、大量のデータ処理のため地域毎等に分割され、並列処理を行うことが一般的である。また、バッチ処理では、故障したジョブを見つけ出し、故障回復の支援を行えるようになっている。
【０００３】
従来、コンピュータの有効活用を促進するために、無駄な待ち時間を排除したジョブの並列処理を可能としたバッチジョブ処理方法があった（例えば、特許文献１参照）。また、計算機システムでジョブ群を複数回実行する場合、該ジョブ群を実行するジョブ群に含まれるジョブ毎の実行履歴を蓄積し、該ジョブ群のジョブ実行において異常が発生した際に、該ジョブ群の異常発生時の実行履歴と正常終了時の実行履歴を比較し、該比較結果に基づき異常の原因を検出する計算機システムの異常回復支援方法があった（例えば、特許文献２参照）。
【特許文献１】特開平８−２７２６２６号公報（段落番号〔００１３〕〜〔００４８〕、図１）
【特許文献２】特開平１０−７８８９４号公報（段落番号〔０００５〕〜〔００２３〕、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら従来の方法では、複数のジョブが同じ故障要因によって故障し、その故障要因が復旧された場合、ジョブを１つずつ指定して、動作を再開しなければならないという問題点があった。
【０００５】
本発明はこのような点に鑑みてなされたものであり、同じ故障要因で故障し、その故障要因が復旧された複数のジョブに対して一括して動作を再開させることができるジョブ復旧プログラムおよびジョブ復旧装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明では上記問題を解決するために、複数のバッチコンピュータ２，３によって実行される複数のジョブ２ａ，２ｂ，３ａ，３ｂを復旧するジョブ復旧プログラムにおいて、コンピュータ１を、故障が発生した際にジョブ２ａ，２ｂ，３ａ，３ｂが出力するジョブ２ａ，２ｂ，３ａ，３ｂの情報と故障要因とを含む故障情報を受信する故障情報受信手段１ａ、故障情報を故障要因ごとに分類して、故障管理データベース１ｆに格納するデータベース格納手段１ｂ、故障要因が復旧されたことによってオペレータより入力される故障要因を受信する故障要因受信手段１ｃ、故障管理データベース１ｆを参照して、故障要因に対応するジョブ２ａ，２ｂ，３ａ，３ｂを検索するジョブ検索手段１ｄ、ジョブ２ａ，２ｂ，３ａ，３ｂの動作を再開させるジョブ動作再開手段１ｅ、として機能させることを特徴とするジョブ復旧プログラムが提供される。
【０００７】
このようなジョブ復旧プログラムによれば、ジョブ２ａ，２ｂ，３ａ，３ｂの情報と故障要因を含む故障情報は故障要因ごとに分類されて、故障管理データベース１ｆに格納される。ジョブの故障要因が復旧されたことによって入力される故障要因に対するジョブ２ａ，２ｂ，３ａ，３ｂは、故障管理データベース１ｆを参照して検索される。そして、検索されたジョブ２ａ，２ｂ，３ａ，３ｂの動作を再開する。これにより、故障要因が復旧されたジョブは、復旧された故障要因をコンピュータ１に入力することによって検索され、動作が再開される。
【発明の効果】
【０００８】
本発明のジョブ復旧プログラムでは、故障が発生した際にジョブが出力するジョブの情報と故障要因とを含む故障情報を、故障要因ごとに分類して故障管理データベースに格納する。そして、故障要因が復旧されたことによってオペレータから入力される故障要因を受信し、復旧された故障要因に対応するジョブを、故障管理データベースを参照して検索、動作を再開するようにした。これにより、同じ故障要因で故障し、その故障要因が復旧された複数のジョブに対して一括して動作を再開させることができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の原理を図面を参照して詳細に説明する。
図１は、本発明の原理を説明する原理図である。
図に示すようにコンピュータ１は、故障情報受信手段１ａ、データベース格納手段１ｂ、故障要因受信手段１ｃ、ジョブ検索手段１ｄ、およびジョブ動作再開手段１ｅを有している。バッチコンピュータ２は、ジョブ２ａ，２ｂを実行している。バッチコンピュータ３は、ジョブ３ａ，３ｂを実行している。
【００１０】
ジョブ２ａ，２ｂ，３ａ，３ｂは、自身に故障が発生した際、またはジョブ２ａ，２ｂ，３ａ，３ｂが利用する資源に故障が発生した際、故障情報を出力する。故障情報には、故障情報を出力するジョブ自身の情報と故障要因とが含まれる。
【００１１】
故障情報受信手段１ａは、故障が発生した際にジョブ２ａ，２ｂ，３ａ，３ｂが出力する、故障情報を受信する。
データベース格納手段１ｂは、故障情報受信手段１ａによって受信された故障情報を、故障情報に含まれる故障要因ごとに分類して、故障管理データベース１ｆに格納する。
【００１２】
故障管理データベース１ｆには、例えば、図に示すように、故障情報Ａ，Ｂ，…，Ｘが故障要因Ｙ１，Ｙ２，…ごとに分類されて格納される。
故障要因受信手段１ｃは、オペレータより入力される故障要因を受信する。故障要因は、例えば、故障したジョブの故障が回復されたことによってオペレータより入力される。
【００１３】
ジョブ検索手段１ｄは、故障要因受信手段１ｃによって受信された故障要因に対応するジョブを、故障管理データベース１ｆを参照して検索する。例えば、オペレータから故障要因Ｙ１が入力された場合、ジョブ検索手段１ｄは、故障要因Ｙ１に属する故障情報Ａ，Ｂ，…に含まれるジョブの情報よって、故障要因Ｙ１に対応するジョブを検索できる。
【００１４】
ジョブ動作再開手段１ｅは、ジョブ検索手段１ｄより検索されたジョブの動作を再開する。すなわち、ジョブ動作再開手段１ｅは、故障によって動作が停止していたジョブを再起動する。
【００１５】
以下、図１の動作について説明する。
図に示すように、ジョブ２ｂ，３ａに故障が発生したとする。そして、ジョブ２ｂ，３ａは、故障要因Ｙ１を有する故障情報Ａ，Ｂを出力したとする。
【００１６】
故障情報受信手段１ａは、ジョブ２ｂ，３ａから故障情報Ａ，Ｂを受信する。データベース格納手段１ｂは、故障情報受信手段１ａより受信された故障情報Ａ，Ｂを、故障要因Ｙ１に分類して故障管理データベース１ｆに格納する。
【００１７】
故障要因Ｙ１が復旧されたとする。この場合、オペレータは、復旧した故障要因Ｙ１をコンピュータ１に入力する。
故障要因受信手段１ｃは、オペレータより入力された故障要因Ｙ１を受信する。ジョブ検索手段１ｄは、故障管理データベース１ｆを参照して、故障要因Ｙ１に対応するジョブ２ｂ，３ａを検索する。ジョブ動作再開手段１ｅは、ジョブ検索手段１ｄより検索されたジョブ２ｂ，３ａの動作を再開させる。
【００１８】
このように、故障が発生した際にジョブ２ａ，２ｂ，３ａ，３ｂが出力するジョブの情報と故障要因とを含む故障情報を、故障要因ごとに分類して故障管理データベース１ｆに格納する。そして、故障要因が復旧されたことによってオペレータから入力される故障要因を受信し、復旧された故障要因に対応するジョブを、故障管理データベース１ｆを参照して検索、動作を再開するようにした。これにより、同じ故障要因で故障し、その故障要因が復旧された複数のジョブに対して一括して動作を再開させることができる。
【００１９】
次に、本発明の実施の形態を図面を参照して詳細に説明する。
図２は、本発明の実施の形態のシステム構成例を示した図である。
図に示すシステム構成例は、例えば、社会保険納付処理のシステムに適用される。図に示すシステム構成例では、例えば、年金等の支払いが、ＡＴＭ（Automated Teller Machine）から２４時間できるようになっている。
【００２０】
納付処理システム１０は、ネットワーク３０を介してＡＴＭ２０と接続されている。また、納付処理システム１０は、ホスト４０と接続されている。
ＡＴＭ２０は、ユーザ５０から、例えば、年金の支払いおよびユーザ５０に関する情報を受け付ける。図において、ＡＴＭ２０は１つしか示してないが、各地に複数設置されている。ＡＴＭ２０は、受け付けた年金の金額およびユーザ５０に関する情報を、ネットワーク３０を介し、納付処理システム１０に送信する。納付処理システム１０は、ＡＴＭ２０から送信される情報を処理、集計等をし、ホスト４０へ送信する。ホスト４０は、納付処理システム１０から送られてきた情報を管理、保持する。
【００２１】
次に、納付処理システム１０のシステム構成例を詳細に説明する。
図３は、図２の納付処理システムのシステム構成例を示した図である。
図に示すように、納付処理システム１０は、監視サーバ１１、バッチサーバ１２，１３、データベース（ＤＢ）サーバ１４、業務サーバ１５，１６、および連携サーバ１７から構成される。各サーバは、各地に分散されており、ネットワーク１８によって接続されている。
【００２２】
監視サーバ１１は、バッチサーバ１２，１３、ＤＢサーバ１４を管理、監視している。例えば、バッチサーバ１２，１３、ＤＢサーバ１４が故障していないか監視し、また、バッチサーバ１２，１３、ＤＢサーバ１４が故障から復帰したとき、再起動するようにする。
【００２３】
バッチサーバ１２，１３は、複数のジョブを実行してジョブネットを構成し、例えば、年金等の社会保険納付処理を行っている。なお、バッチサーバ１２，１３は２つしか示してないが、２つ以上存在して複数のジョブを実行し、ジョブネットを構成するようにしてもよい。
【００２４】
ＤＢサーバ１４は、バッチサーバ１２，１３がジョブを実行するのに必要なデータ、ジョブを実行することによって得たデータが格納される。ＤＢサーバ１４は１つか示してないが、もちろん２つ以上存在していてもよい。
【００２５】
業務サーバ１５，１６は、社会保険に関する業務を行うオペレータが使用するサーバである。業務サーバ１５，１６からバッチサーバ１２，１３、ＤＢサーバ１４にアクセスすることによって、社会保険に関する情報を受信することができる。また、業務サーバ１５，１６は、監視サーバ１１にアクセスすることによって、バッチサーバ１２，１３、ＤＢサーバ１４の状態を受信し、また制御することができる。
【００２６】
連携サーバ１７は、納付処理システム１０の外部と通信をする。例えば、ＡＴＭ２０、ホスト４０と通信する。これによって、納付処理システム１０を構成している監視サーバ１１、バッチサーバ１２，１３、ＤＢサーバ１４、および業務サーバ１５，１６は、ＡＴＭ２０、ホスト４０とデータのやり取りをすることができる。
【００２７】
次に、監視サーバ１１のハードウェア構成について説明する。
図４は、監視サーバのハードウェア構成を示すブロック図である。
図に示す監視サーバ１１は、ＣＰＵ(Central Processing Unit)１１ａによって装置全体が制御されている。ＣＰＵ１１ａには、バス１１ｇを介してＲＡＭ(Random Access Memory)１１ｂ、ハードディスクドライブ(ＨＤＤ:Hard Disk Drive)１１ｃ、グラフィック処理装置１１ｄ、入力インターフェース１１ｅ、および通信インターフェース１１ｆが接続されている。
【００２８】
ＲＡＭ１１ｂには、ＣＰＵ１１ａに実行させるＯＳ(Operating System)のプログラムやアプリケーションプログラム、ジョブの少なくとも一部が一時的に格納される。また、ＲＡＭ１１ｂには、ＣＰＵ１１ａによる処理に必要な各種データが保存される。ＨＤＤ１０ｃには、ＯＳやアプリケーションプログラムなどが格納される。
【００２９】
グラフィック処理装置１１ｄには、モニタ１１ｈが接続されている。グラフィック処理装置１１ｄは、ＣＰＵ１１ａからの命令に従って、画像をモニタ１１ｈの表示画面に表示させる。入力インターフェース１１ｅには、キーボード１１ｉと、マウス１１ｊとが接続されている。入力インターフェース１１ｅは、キーボード１１ｉやマウス１１ｊから送られてくる信号を、バス１１ｇを介してＣＰＵ１１ａに送信する。
【００３０】
通信インターフェース１１ｆは、ネットワーク１８に接続されている。通信インターフェース１１ｆは、ＣＰＵ１１ａからの命令に従い、ネットワーク１８を介して他のサーバと通信を行う。
【００３１】
なお、バッチサーバ１２，１３、ＤＢサーバ１４、業務サーバ１５，１６、および連携サーバ１７も図４と同様のハードウェア構成を有する。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。
【００３２】
次に、図３に示した納付処理システム１０全体の機能の概略について説明する。
図５は、納付処理システム全体の機能の概略を説明する図である。
図５において、図３と同じものには同じ符号を付し、その詳細な説明を省略する。
【００３３】
図に示すように、バッチサーバ１２は、ジョブ１２ａを実行している。バッチサーバ１２および図に示してないその他の複数のバッチサーバは、連携してジョブを実行し、図に示すようなジョブネット６１を構成している。
【００３４】
ジョブ１２ａは、故障（異常）が発生した場合、その故障に関する故障要因と、ジョブ１２ａ自身に関する情報とを含む通知データを監視サーバ１１に送信する。例えば、ＤＢサーバ１４にアクセスできないなどの故障が発生した場合、その内容を示す故障要因と、アクセスできなかったジョブ自身の情報とを含む通知データを監視サーバ１１に送信する。なお、図示していないが、その他のバッチサーバで実行されるジョブも、故障が発生すると通知データを監視サーバ１１に送信する。
【００３５】
監視サーバ１１は、バッチサーバから送信される通知データを元に、ジョブの故障に関する故障情報を、例えば、ＨＤＤ１１ｃに構築されるデータベースに記憶する。故障情報は、図示するように故障区分、事象と階層的に分類され格納される。
【００３６】
監視サーバ１１は、故障情報を、受信した通知データに含まれる故障要因により故障区分、事象に分類し、データベースに記憶する。故障情報は、故障要因によって、まず、大きく故障区分ごとに分けられ、さらに、その故障区分の中で、事象ごとに分けられる。例えば、あるジョブにおいて、ファイルＡ１，Ｂ１にファイルアクセスできないという故障が発生したとする。この場合、ファイルＡ１にアクセスできないジョブの故障情報は、例えば、図５において、ファイルアクセスの事象Ａに分類されて格納される。ファイルＢ１にアクセスできないジョブの故障情報は、例えば、ファイルアクセスの事象Ｂに分類されて格納される。
【００３７】
業務サーバ１５は、ジョブ１５ａを実行している。業務サーバ１５は、ジョブ１５ａの実行によって、監視サーバ１１にアクセスし、故障によって動作停止しているジョブの故障情報をモニタに表示する。これによって、オペレータは、どのジョブにどのような故障が発生しているのかを知ることができる。また、一つの故障事象によりどのジョブが停止しているか把握することができる。
【００３８】
業務サーバ１６は、ジョブ１６ａを実行している。業務サーバ１６は、ジョブ１６ａの実行によって、故障要因が取り除かれたジョブを再動作するよう、監視サーバ１１に指示を出力する。このとき、復旧した故障要因のみを監視サーバ１１に送信することによって、その故障要因によって動作停止していたジョブが一括して再動作される。
【００３９】
例えば、上記例において、ファイルＡ１へのアクセスエラーのみが復旧されたとする。この場合、事象Ａを指定してやれば、ファイルＡ１にアクセスできなかったジョブが再動作する。また、ファイルＢ１へのアクセスエラーのみが復旧されたとする。この場合、事象Ｂを指定してやれば、ファイルＢ１にアクセスできなかったジョブが再動作する。また、ファイルＡ１，Ｂ１へのアクセスエラーが復旧されたとする。この場合、故障区分のファイルアクセスを指定してやれば、ファイルＡ１，Ｂ１にアクセスできなかったジョブが再動作する。
【００４０】
なお、業務サーバ１５からジョブの再動作の指示を出力することもできる。また、業務サーバ１６のモニタに故障しているジョブの故障情報を表示することもできる。このようにするには、業務サーバ１５でジョブ１６ａを実行し、業務サーバ１６でジョブ１５ａを実行するようにすればよい。
【００４１】
また、ジョブ１５ａ，１６ａを監視サーバ１１で実行することにより、監視サーバ１１からでも、ジョブの再動作の指示をすることができ、故障情報をモニタ１１ｈに表示することができる。
【００４２】
次に、バッチサーバで実行されるジョブについて詳細に説明する。
図６は、バッチサーバで実行されるジョブを説明する図である。
図に示すようにバッチサーバで実行されるジョブ７１は、フレームワーク７２、ＡＰＬ（application）７３から構成される。
【００４３】
フレームワーク７２は、他のジョブとデータのやり取りをするためのプログラムである。フレームワーク７２は、ＡＰＬ７３において故障が発生した場合、通知データを監視サーバ１１に送信するためのプログラムが記述された異常出口部を有している。
【００４４】
ＡＰＬ７３は、社会保険納付のための処理を行うプログラムである。ＡＰＬ７３は、ファイルにアクセスするためのファイルアクセス部、ＤＢサーバ１４にアクセスするためのＤＢアクセス部、社会保険納付の情報を処理するためのＡＰＬロジック部、ＯＳに割り込みをするためのＯＳ割り込み部、バッチサーバのハードウェアをチェックするハードウェアチェック部、および業務サーバ１５，１６から処理規制の指示を受け付けるコマンド規制部から構成されている。
【００４５】
ＡＰＬ７３のファイルアクセス部、ＤＢアクセス部、ＡＰＬロジック部、およびＯＳ割り込み部の各々は、バッチサーバによって実行されているときに故障が発生した場合、各部で故障が発生したことを示すコードをフレームワーク７２に出力する。また、ハードウェアチェック部は、バッチサーバのハードウェアチェックにより故障を検出した場合、ハードウェアに故障があることを示すコードをフレームワーク７２に出力する。コマンド規制部は、業務サーバから処理規制の指示があった場合、処理規制がされていることを示すコードをフレームワーク７２に出力する。
【００４６】
次にコードが示す故障内容の例について説明する。
図７は、コードと故障内容の関係を示した図である。
図のコード表７４に示すように、ファイルアクセス部から出力されるコードは０００１である。すなわち、ファイルアクセスによって異常が発生した場合、ファイルアクセス部はフレームワーク７２に０００１のコードを出力する。ＤＢアクセス部から出力されるコードは０００２である。すなわち、ＤＢサーバ１４のアクセスによって異常が発生した場合、ＤＢアクセス部はフレームワーク７２に０００２のコードを出力する。ＡＰＬロジック部から出力されるコードは０００３である。すなわち、社会保険納付の情報処理によって異常が発生した場合、ＡＰＬロジック部はフレームワーク７２に０００３のコードを出力する。ＯＳ割り込み部から出力されるコードは０００４である。すなわち、ＯＳの割り込みによって異常が発生した場合、ＯＳ割り込み部はフレームワーク７２に０００４のコードを出力する。ハードウェアチェック部から出力されるコードは０００５である。すなわち、ハードウェアチェックにより異常が検出された場合、ハードウェアチェック部はフレームワーク７２に０００５のコードを出力する。コマンド規制部から出力されるコードは０００６である。すなわち、業務サーバより処理規制があるときは、コマンド規制部はフレームワーク７２に０００６のコードを出力する。
【００４７】
フレームワーク７２の異常出口部は、ＡＰＬ７３から出力されるコードに基づいて通知データを生成する。通知データには、例えば、ジョブ７１を実行しているバッチサーバのマシン名、ジョブ７１のジョブ名、故障の種類、故障の詳細情報、発生日時が含まれる。
【００４８】
図８は、通知データのデータ構成例である。
図に示すように通知データ７５は、マシン、ジョブ名、故障区分、詳細情報、詳細エラー、および発生日時の欄を有している。
【００４９】
マシンの欄には、例えば、ジョブを実行しているバッチサーバのＩＰアドレスが格納される。ジョブ名の欄には、バッチサーバが実行しているジョブのジョブ名が格納される。ジョブ名は、ジョブごとに付与されている識別子（ＩＤ）で表される。故障区分の欄には、ジョブのＡＰＬから出力されるコードが格納される。詳細情報の欄には、故障原因の元となった資源名が格納される。詳細エラーの欄には、故障原因の情報が格納される。発生日時の欄には、故障を検出し、ジョブが停止したときの日時が格納される。
【００５０】
マシンの欄、ジョブ名の欄、および発生日時の欄は、フレームワークの異常出口部より情報が格納される。故障区分の欄は、フレームワークの異常出口部がＡＰＬから受け取ったコードが格納される。詳細情報の欄は、フレームワークの異常出口部より、ＡＰＬの各部がアクセスしていた資源名、例えば、ＤＢ名、ファイル名が格納される。詳細エラーの欄は、フレームワーク７２の異常出口部より、ＡＰＬ７３が異常を発生した理由が格納される。
【００５１】
図８の例では、故障したバッチサーバのＩＰアドレスはｘｘ．ｘｘ．ｘｘ．ｘｘである。故障したジョブ名はＪＯＢ１である。故障区分は０００２より、ＤＢアクセスによって異常が発生したことを示している。詳細情報はＤＢ１より、データベース名がＤＢ１のデータベースにアクセスしたことにより故障が発生したことを示している。詳細エラーは例外データより、ジョブがＤＢアクセスして適正なデータが返ってこなかったために故障が発生したことを示している。発生日時は２００３．１２．１２．１２：１３：３０より、この時間に故障でジョブが停止したことを示している。
【００５２】
ところで、ジョブは、故障によって実行が中断されて、再開される場合、中断されたところから実行が再開されるようになっている。
図９は、ジョブの再開処理について説明する図である。
【００５３】
図には、図６に示したジョブ７１、フレームワーク７２、およびＡＰＬ７３が示してある。また、ジョブ７１を実行するバッチサーバの、例えば、ＨＤＤに構築されるリスタートＤＢ７６および中間ファイル７７が示してある。
【００５４】
フレームワーク７２は、ＡＰＬ７３で実行されたプログラムポイントの３０レコード分をリスタートＤＢ７６に格納する。また、フレームワーク７２は、中間ファイルアクセスＡＰＩ（Application Programming Interface）を有し、ＡＰＬ７３の実行によって生成されたデータを数レコード分中間ファイル７７に格納する。
【００５５】
リスタートＤＢ７６には、実行が中断されるまでの３０レコード分のスタートポイントが格納され、中間ファイル７７には、中断されるまでのデータが数レコード分格納されている。従って、故障により実行が中断され、再開される場合、フレームワーク７２は、リスタートＤＢ７６を参照して、リスタートポイントを設定する。そして、設定されたリスタートポイントに対応するデータを中間ファイル７７より参照し、実行を再開する。これによって、ジョブ７１は中断されたところから実行を再開することができる。
【００５６】
次に、監視サーバ１１の有する機能について説明する。
図１０は、監視サーバの機能ブロック図である。
図に示すように監視サーバ１１は、通知データ受信部８１、事象格納部８２、事前チェック部８３、照会処理部８４、故障事象検索部８５、再起動部８６、故障管理ＤＢ８７、事象管理履歴ＤＢ８８、および登録削除履歴部８９を有している。
【００５７】
故障管理ＤＢ８７には、バッチサーバから送信される通知データを元にした故障情報が、通知データに含まれる故障要因によって分類され格納される。
図１１は、故障管理ＤＢの構造例を示した図である。
【００５８】
図に示すように、故障管理ＤＢ８７に格納される故障情報は、まず、故障区分によって大きく分類される。そして、故障原因の下位の事象において、さらに詳細に分類される。
故障区分は、図に示すように、例えば、ファイルアクセスの異常による故障、ＤＢアクセスによる故障、…のように区分される。なお、故障区分にない新たな故障原因が生じると、新たな故障区分が追加される。故障区分の下位では、故障情報は、さらに詳細に故障要因によって分類される。
【００５９】
図１２は、故障情報のデータ構成例を示した図である。
図に示すように故障情報９１は、故障区分、詳細情報、ジョブ識別情報の欄から構成される。ジョブ識別情報は、マシン名、ジョブ名、発生日時の欄から構成される。
【００６０】
故障区分の欄には、故障情報９１が属する故障区分の区分番号が格納される。詳細情報の欄には、故障原因の具体的な情報が格納される。例えば、ＤＢへのアクセス故障である場合、どのＤＢへのアクセスが故障なのかの情報が格納される。ジョブ識別情報のマシン名の欄には、故障したジョブを実行しているバッチサーバのマシン名が格納される。ジョブ識別情報のジョブ名の欄には、故障したジョブのジョブ名が格納される。ジョブ識別情報の発生日時の欄には、故障が発生した日時が格納される。
【００６１】
故障情報９１は、バッチサーバから受信した通知データを元に生成される。故障区分の欄には、受信した通知データに含まれる故障区分が格納される。詳細情報の欄には、受信した通知データに含まれる詳細情報が格納される。また、マシン名の欄には、受信した通知データに含まれるマシンのＩＰアドレスを元にマシン名が格納される。監視サーバ１１には、予めＩＰアドレスに対応するマシン名が記憶されており、受信した通知データのＩＰアドレスに対応するマシン名を取得し格納する。また、ジョブ名の欄には、受信した通知データに含まれるジョブ名が格納される。また、発生日時の欄には、通知データに含まれる発生日時が格納される。
【００６２】
事象管理履歴ＤＢ８８には、故障管理ＤＢに格納された故障情報の内容が、格納された時間とともに格納される。また、故障管理ＤＢに登録してある故障情報が削除されたとき、削除された故障情報の内容が、削除された時間とともに格納される。
【００６３】
通知データ受信部８１は、バッチサーバが実行するジョブから通知データを受信する。
事象格納部８２は、通知データ受信部８１より受信された通知データを元に、故障情報を生成し故障管理ＤＢ８７に格納する。このとき、事象格納部８２は、故障情報を故障情報に含まれる故障区分ごとに分類し、さらに詳細情報ごとに分類して格納する。なお、故障情報が、故障管理ＤＢ８７の故障区分にない故障原因を含んでいる場合、事象格納部８２は、新たな故障区分を故障管理ＤＢ８７に登録する。
【００６４】
また、事象格納部８２は、オペレータによって選択されたジョブの情報を故障管理ＤＢ８７に格納する。これによって、オペレータは、運用を中止したいジョブの実行を停止することができる。
【００６５】
事前チェック部８３は、バッチサーバを起動する前に、ジョブが使用するデータベース、アプリケーション、ファイルなどの資源に故障が生じているかのチェックを行う。事前チェック部８３は、資源に故障が生じている場合、その故障情報を故障管理ＤＢ８７に格納する。事前チェック部８３は、故障情報をその内容に応じて故障区分ごとに、さらに事象ごとに分類して格納する。
【００６６】
照会処理部８４は、オペレータからの要求に応じて、故障管理ＤＢ８７、事象管理履歴ＤＢ８８に格納されている情報を、オペレータが使用している業務サーバ１５，１６のモニタに表示する。また、照会処理部８４は、オペレータからの要求に応じて、監視サーバ１１のモニタ１１ｈに、故障管理ＤＢ８７、事象管理履歴ＤＢ８８に格納されている情報を表示する。
【００６７】
故障事象検索部８５は、故障管理ＤＢ８７を参照し、オペレータから指示される故障区分、事象（詳細情報）に属するジョブを全て検索する。例えば、オペレータより、故障区分のＤＢアクセスを検索する旨の指示があった場合、故障事象検索部８５は、故障管理ＤＢ８７を参照して、故障区分のＤＢアクセスに属するジョブを全て検索する。また、オペレータより、故障区分のＤＢアクセスの事象Ａを検索する旨の指示があった場合、故障事象検索部８５は、故障管理ＤＢ８７を参照して、故障区分がＤＢアクセスの事象Ａに属するジョブを全て検索する。
【００６８】
再起動部８６は、故障事象検索部８５によって検索されたジョブ、すなわち故障によって実行が中断されていたジョブを再起動する。これによって、事象に属しているジョブが一括して再起動される。再起動部８６は、再起動したジョブの故障情報を故障管理ＤＢ８７から削除する。
【００６９】
登録削除履歴部８９は、故障管理ＤＢ８７において、故障情報が登録および削除されたときの履歴情報を、登録および削除が行われた日時とともに事象管理履歴ＤＢ８８に格納する。
【００７０】
次に、故障発生とその復旧例について説明する。ジョブのＡＰＬロジック部より故障が発生した例について説明する。
図１３は、ＡＰＬロジック部の故障発生例を説明する図である。
【００７１】
図に示すように、バッチサーバ１２は、ジョブ１０１〜１０３を実行しているとする。ジョブ１０１の処理名を東地区１、ジョブ名をＪＯＢ１、アプリケーション名を集計とする。ジョブ１０２の処理名を東地区２、ジョブ名をＪＯＢ２、アプリケーション名を集計とする。ジョブ１０３の処理名を東地区３、ジョブ名をＪＯＢ３、アプリケーション名を集計とする。
【００７２】
バッチサーバ１３は、ジョブ１０４〜１０６を実行しているとする。ジョブ１０４の処理名を西地区１、ジョブ名をＪＯＢ４、アプリケーション名を集計とする。ジョブ１０５の処理名を西地区２、ジョブ名をＪＯＢ５、アプリケーション名を集計とする。ジョブ１０６の処理名を西印刷、ジョブ名をＪＯＢ６、アプリケーション名を印刷とする。
【００７３】
この状態において、ジョブ１０１，１０２，１０４〜１０６に故障が発生したとする。各ジョブは、通知データを生成し、監視サーバ１１に送信する。
図１４は、図１３のバッチサーバから出力される通知データを示した図である。
【００７４】
図に示す通知データ１１１は、図１３のバッチサーバ１２のジョブ１０１，１０２から出力される通知データを示している。通知データ１１２は、図１３のバッチサーバ１３のジョブ１０４〜１０６から出力される通知データを示している。
【００７５】
例えば、通知データ１１１においてマシンの欄には、バッチサーバ１２のＩＰアドレスが格納されている。ジョブ名の欄には、ジョブ１０１のジョブ名ＪＯＢ１、ジョブ１０２のジョブ名ＪＯＢ２が格納されている。故障区分の欄には、ジョブ１０１，１０２のＡＰＬロジック部で異常が発生したことを示す０００３が格納されている。詳細情報の欄には、ジョブ１０１，１０２のアプリケーション名の集計が格納されている。詳細エラーの欄には、故障原因の情報である例外データが格納されている。発生日時の欄には、故障を検出し、ジョブが停止した日時が格納されている。
【００７６】
通知データ１１２においてマシンの欄には、バッチサーバ１３のＩＰアドレスが格納されている。ジョブ名の欄には、ジョブ１０４のジョブ名ＪＯＢ４、ジョブ１０５のジョブ名ＪＯＢ５、ジョブ１０６のジョブ名ＪＯＢ６が格納されている。故障区分の欄には、ジョブ１０４〜１０６のＡＰＬロジック部で異常が発生したことを示す０００３が格納されている。詳細情報の欄には、ジョブ１０４，１０５のアプリケーション名の集計、ジョブ１０６のアプリケーション名の印刷が格納されている。詳細エラーの欄には、故障原因の情報である例外データ、プリントエラーが格納されている。発生日時の欄には、故障を検出し、ジョブが停止した日時が格納されている。
【００７７】
通知データ１１１，１１２は、監視サーバ１１の通知データ受信部８１に受信される。事象格納部８２は、受信された通知データ１１１，１１２を元に故障情報を生成し、故障要因ごとに分類して故障管理ＤＢ８７に格納する。また、登録削除履歴部８９は、故障管理ＤＢ８７に情報が格納されたことにより、その履歴情報を事象管理履歴ＤＢ８８に格納する。
【００７８】
監視サーバ１１の照会処理部８４は、オペレータからの要求により、オペレータが使用する業務サーバのモニタに現在のジョブの状況を表示する。
図１５は、モニタに表示されるジョブ照会画面を示した図で、（ａ）は画面その１、（ｂ）は画面その２、（ｃ）は画面その３である。
【００７９】
図１５（ａ）〜図１５（ｃ）に示す画面１２１〜１２３は、オペレータが使用する業務サーバのモニタに表示される画面である。画面１２１〜１２３は、オペレータによって切り替えることができる。監視サーバ１１の照会処理部８４は、オペレータの要求に応じて、故障管理ＤＢ８７、事象管理履歴ＤＢ８８に格納されているジョブの状況を表示する。
【００８０】
画面１２１には、故障区分ごとのジョブの件数が表示されている。オペレータによって、例えば、故障区分の何れかの項目にポインタが合わせられ、クリックされると、その項目が選択、確定され、その項目に対する詳細な情報を示した画面１２２が表示される。なお、画面１２１の例では、アプリ故障が選択されている。
【００８１】
画面１２２は、故障区分、詳細情報、ジョブ件数および登録ボタン１２２ａ，１２２ｃ、復旧ボタン１２２ｂ，１２２ｄが表示されている。登録ボタン１２２ａ，１２２ｃ、復旧ボタン１２２ｂ，１２２ｄは、例えば、ポインタが合わせられクリックされると選択される。登録ボタン１２２ａ，１２２ｃが選択された場合、ジョブの動作を停止する画面に進む。例えば、オペレータがあるジョブの運用を中止したい場合に、登録ボタン１２２ａ，１２２ｃをクリックするようにする。オペレータによって選択、確定されたジョブの情報は、故障管理ＤＢ８７に登録される。復旧ボタン１２２ｂ，１２２ｄが選択、確定された場合、故障によって処理が中断していたジョブが再起動される。
【００８２】
詳細情報の何れかの項目が選択、確定されると、その項目に対する詳細な情報を示した画面１２３が表示される。なお、画面１２２の例では、詳細情報の集計が選択されている。
【００８３】
画面１２３には、マシン名、ジョブ情報、発生日時、詳細エラーが表示される。なお、画面１２１〜１２３に示してないが、例えば、画面１２１〜１２３に表示される、戻るボタンをクリックすることにより、前画面に戻ることができる。
【００８４】
図１６は、ジョブの復旧を説明する図である。
図１５において、復旧ボタン１２２ｂが選択されると、監視サーバ１１は図１６に示すように、アプリ故障の集計に属するバッチサーバ１２のジョブ１０１，１０２と、バッチサーバ１３のジョブ１０４，１０５を一括して再起動する。なお、復旧ボタン１２２ｄが選択されると、監視サーバ１１の再起動部８６は、アプリ故障の印刷に属するジョブ１０６を再起動する。
【００８５】
次に、ジョブのＤＢアクセス部より故障が発生した例について説明する。
図１７は、ＤＢロジック部の故障発生例を説明する図である。
図に示すようにＤＢサーバ１４は、データベース１４ａを有し、このデータベース１４ａに故障が発生したとする。すると、バッチサーバ１２，１３が実行しているジョブのＤＢアクセス部に異常が発生する。バッチサーバ１２，１３は、ＤＢアクセス部の故障発生により、通知データを監視サーバ１１に送信する。
【００８６】
図１８は、図１７のバッチサーバから出力される通知データを示した図である。
図に示す通知データ１３１は、図１７のバッチサーバ１２から出力される通知データを示している。通知データ１３２は、バッチサーバ１３から出力される通知データを示している。
【００８７】
例えば、通知データ１３１においてマシンの欄には、バッチサーバ１２のＩＰアドレス１９２．１６８．ｘｘ．ｘｘが格納されている。ジョブ名の欄には、異常発生したジョブのジョブ名ＪＯＢ１が格納されている。故障区分の欄には、ＤＢアクセス部で異常が発生したことを示す０００２が格納されている。詳細情報の欄には、故障したデータベースの名前のＤＢ１が格納されている。詳細エラーの欄には、故障原因の詳細情報であるＩＯエラーが格納されている。発生日時の欄には、故障を検出し、ジョブが停止した日時が格納されている。
【００８８】
通知データ１３２においてマシンの欄には、バッチサーバ１３のＩＰアドレス１９２．１６８．ｙｙ．ｙｙが格納されている。ジョブ名の欄には、異常発生したジョブのジョブ名ＪＯＢ２が格納されている。故障区分の欄には、ＤＢアクセス部で異常が発生したことを示す０００２が格納されている。詳細情報の欄には、故障したデータベースの名前のＤＢ１が格納されている。詳細エラーの欄には、故障原因の詳細情報であるＩＯエラーが格納されている。発生日時の欄には、故障を検出し、ジョブが停止した日時が格納されている。
【００８９】
通知データ１３１，１３２は、監視サーバ１１の通知データ受信部８１に受信される。事象格納部８２は、受信された通知データ１３１，１３２を元に故障情報を生成し、故障要因ごとに分類して故障管理ＤＢ８７に格納する。また、登録削除履歴部８９は、故障管理ＤＢ８７に情報が格納されたことにより、その履歴情報を事象管理履歴ＤＢ８８に格納する。
【００９０】
監視サーバ１１の照会処理部８４は、オペレータからの要求により、オペレータが使用する業務サーバのモニタに現在のジョブの状況を表示する。
図１９は、モニタに表示されるジョブ照会画面を示した図で、（ａ）は画面その１、（ｂ）は画面その２、（ｃ）は画面その３である。
【００９１】
図１９（ａ）〜図１９（ｃ）に示す画面１４１〜１４３は、オペレータが使用する業務サーバのモニタに表示される画面である。画面１４１〜１４３は、オペレータによって切り替えることができる。監視サーバ１１の照会処理部８４は、オペレータの要求に応じて、故障管理ＤＢ８７、事象管理履歴ＤＢ８８に格納されているジョブの状況を表示する。
【００９２】
画面１４１には、故障区分ごとのジョブの件数が表示されている。オペレータによって、例えば、故障区分の何れか項目にポインタが合わせられ、クリックされると、その項目が選択、確定され、その項目に対する詳細な情報を示した画面１４２が表示される。なお、画面１４１の例では、故障区分の欄のＤＢ故障が選択されている。
【００９３】
画面１４２は、故障区分、詳細情報、ジョブ件数および登録ボタン１４２ａ、復旧ボタン１４２ｂが表示されている。登録ボタン１４２ａ、復旧ボタン１４２ｂは、例えば、ポインタが合わせられクリックされると選択、確定される。登録ボタン１４２ａが選択、確定された場合、ジョブの動作を停止する画面に進む。例えば、オペレータがあるジョブの運用を中止したい場合に、登録ボタン１４２ａをクリックするようにする。オペレータによって、選択されたジョブは、故障管理ＤＢ８７に登録される。復旧ボタン１４２ｂが選択、確定された場合、故障によって処理が中断していたジョブが再起動される。
【００９４】
詳細情報の何れかの項目が選択、確定されると、その項目に対する詳細な情報を示した画面１４３が表示される。なお、画面１４２の例では、詳細情報のＤＢ１が選択されている。
【００９５】
画面１４３には、マシン名、ジョブ情報、発生日時、詳細エラーが表示される。なお、画面１４１〜１４３に示してないが、例えば、画面１４１〜１４３に表示される、戻るボタンをクリックすることにより、前画面に戻ることができる。
【００９６】
図２０は、ジョブの復旧を説明する図である。
図１９において、復旧ボタン１４２ｂが選択されると、監視サーバ１１は図２０に示すように、バッチサーバ１２，１３のデータベースアクセスに関するジョブを再起動する。すなわち、復旧ボタン１４２ｂが選択されると、ＤＢ故障のＤＢ１に属するジョブが一括して再起動される。
【００９７】
以下、各装置の処理の流れについてフローチャートを用いて説明する。
まず、監視サーバ１１全体の処理の流れについて説明する。
図２１は、監視サーバ全体の処理の流れを示したフローチャートである。
【００９８】
ステップＳ１において、監視サーバ１１は、ジョブに故障が発生したことを示す通知データをバッチサーバから受信する。
ステップＳ２において、監視サーバ１１は、受信した通知データより、故障の生じたジョブの故障情報を故障要因によって分類し、故障管理ＤＢ８７に格納する。
【００９９】
ステップＳ３において、監視サーバ１１は、ジョブの修正、ハードウェアの交換等により復旧された故障要因をオペレータから受け付ける。そして、監視サーバ１１は、ジョブの再開処理を行う。
【０１００】
ステップＳ４において、監視サーバ１１は、故障復旧されたジョブの故障情報を故障管理ＤＢ８７から削除する。
なお、図２１に示してないが、オペレータからの要求によって、監視サーバ１１はオペレータが使用する業務サーバのモニタに故障情報の照会をすることができる。
【０１０１】
次に、バッチサーバの故障検出について説明する。
図２２は、バッチサーバでの故障検出の処理の流れを示したフローチャートである。
ステップＳ１１において、バッチサーバで実行されるジョブのＡＰＬは、異常が発生した場合、異常が発生したことを示すコードをフレームワークに出力する。
【０１０２】
ステップＳ１２において、バッチサーバで実行されるジョブのフレームワークは、ＡＰＬから出力されるコードに基づいて通知データを生成する。
ステップＳ１３において、バッチサーバで実行されるジョブのフレームワークは、通知データを監視サーバ１１に送信する。
【０１０３】
次に、監視サーバ１１の事前チェック処理について説明する。
図２３は、監視サーバの事前チェックの処理の流れを示したフローチャートである。
ステップＳ２１において、監視サーバ１１の事前チェック部８３は、バッチサーバを起動する前に、ジョブが使用するデータベース、アプリケーション、ファイルなどの資源に故障が生じているか否かのチェックを行う。故障が生じていた場合、ステップＳ２２に進む。故障が生じていない場合、ステップＳ２３へ進む。
【０１０４】
ステップＳ２２において、監視サーバ１１の事前チェック部８３は、故障情報が属する故障区分に、故障情報を格納する。
ステップＳ２３において、監視サーバ１１の事前チェック部８３は、故障が生じてないバッチジョブの起動命令を出す。
【０１０５】
次に、監視サーバ１１の故障情報の格納について説明する。
図２４は、監視サーバの故障情報の格納処理の流れを示したフローチャートである。
ステップＳ３１において、監視サーバ１１の通知データ受信部８１は、通知データをバッチサーバから受信する。また、オペレータから停止させたいジョブの情報を受信する。
【０１０６】
ステップＳ３２において、監視サーバ１１の事象格納部８２は、通知データ受信部８１より受信された通知データを元にした故障情報を生成する。また、オペレータから通知されたジョブの情報より、停止させたいジョブの情報を生成する。事象格納部８２は、故障情報およびオペレータから通知されたジョブの情報が属する故障区分が故障管理ＤＢ８７にすでに登録されているか否かを判断する。すでに故障区分が故障管理ＤＢ８７に登録されている場合は、ステップＳ３４へ進む。登録されていない場合は、ステップＳ３３へ進む。
【０１０７】
ステップＳ３３において、監視サーバ１１の事象格納部８２は、故障管理ＤＢ８７に新規の故障区分を登録する。
ステップＳ３４において、監視サーバ１１の事象格納部８２は、故障情報を、故障要因ごとに故障区分、事象に分類して格納する。
【０１０８】
ステップＳ３５において、監視サーバ１１の登録削除履歴部８９は、故障管理ＤＢ８７に格納された情報（故障情報）を、格納日とともに事象管理履歴ＤＢ８８に格納する。
次に、監視サーバ１１の復旧処理について説明する。
【０１０９】
図２５は、監視サーバの復旧処理の流れを示したフローチャートである。
ステップＳ４１において、監視サーバ１１の故障事象検索部８５は、オペレータから復旧指示を受け付ける。すなわち、オペレータが動作再開させようとするジョブの故障区分、詳細情報を、オペレータが使用している業務サーバから受け付ける。
【０１１０】
ステップＳ４２において、監視サーバ１１の故障事象検索部８５は、受け付けた故障区分、詳細情報に属する故障情報のジョブを故障管理ＤＢ８７から全て検索する。
ステップＳ４３において、監視サーバ１１の再起動部８６は、検索されたジョブより、そのジョブを実行するバッチサーバに、故障していたジョブを再起動するよう指示を出す。
【０１１１】
ステップＳ４４において、監視サーバ１１の再起動部８６は、再起動指示を出したジョブの故障情報を故障管理ＤＢ８７から削除する。
ステップＳ４５において、監視サーバ１１の登録削除履歴部８９は、削除された故障情報を削除した時間とともに事象管理履歴ＤＢ８８に登録する。
【０１１２】
次に、故障に関する情報をオペレータが使用する業務サーバのモニタに表示する監視サーバ１１の照会処理について説明する。
図２６は、監視サーバの照会処理の流れを示したフローチャートである。
【０１１３】
ステップＳ５１において、監視サーバ１１の照会処理部８４は、オペレータから故障に関する照会の指示を受け付ける。このとき、照会を受けたい故障区分、詳細情報をオペレータから受け付ける。
【０１１４】
ステップＳ５２において、監視サーバ１１の照会処理部８４は、オペレータから指定された故障区分、詳細情報に属する故障情報を故障管理ＤＢ８７から検索する。
ステップＳ５３において、監視サーバ１１の照会処理部８４は、オペレータが使用している業務サーバのモニタに検索した故障情報を表示する。なお、モニタに表示した故障情報はプリンタ装置に出力することができる。
【０１１５】
次に、故障履歴に関する情報をオペレータが使用する業務サーバのモニタに表示する監視サーバの履歴照会処理について説明する。
図２７は、監視サーバの履歴照会処理の流れを示したフローチャートである。
【０１１６】
ステップＳ６１において、監視サーバ１１の照会処理部８４は、オペレータから履歴に関する照会の指示を受け付ける。このとき、履歴照会を受けたい日時をオペレータから受け付ける。
【０１１７】
ステップＳ６２において、監視サーバ１１の照会処理部８４は、オペレータから指定された日時の履歴情報を事象管理履歴ＤＢ８８から検索する。
ステップＳ６３において、監視サーバ１１の照会処理部８４は、オペレータが使用している業務サーバのモニタに検索した履歴情報を表示する。なお、モニタに表示した履歴情報はプリンタ装置に出力することができる。
【０１１８】
このように、ジョブの故障情報を、故障要因ごとに分類して故障管理ＤＢ８７に格納する。そして、故障要因が復旧されたことによってオペレータから入力される故障要因（故障区分、詳細情報）を受信し、復旧された故障要因に対応するジョブを、故障管理ＤＢ８７を参照して検索、動作を再開するようにした。これにより、同じ故障要因で故障し、その故障要因が復旧された複数のジョブに対して一括して動作を再開させることができる。
【０１１９】
また、故障情報、故障情報の履歴情報をモニタに表示するようにしたので、オペレータは容易にどのジョブがどのような故障をし、復旧されたのかを知ることができる。また、オペレータの復旧させたいジョブの故障要因の入力が容易となる。
【０１２０】
なお、コンピュータが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０１２１】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１２２】
（付記１）  複数のバッチコンピュータによって実行される複数のジョブを復旧するジョブ復旧プログラムにおいて、
コンピュータを、
故障が発生した際に前記ジョブが出力する前記ジョブの情報と故障要因とを含む故障情報を受信する故障情報受信手段、
前記故障情報を前記故障要因ごとに分類して、故障管理データベースに格納するデータベース格納手段、
前記故障要因が復旧されたことによってオペレータより入力される前記故障要因を受信する故障要因受信手段、
前記故障管理データベースを参照して、前記故障要因に対応する前記ジョブを検索するジョブ検索手段、
前記ジョブの動作を再開させるジョブ動作再開手段、
として機能させることを特徴とするジョブ復旧プログラム。
【０１２３】
（付記２）  前記オペレータの要求に応じて、前記故障管理データベースに格納されている前記故障情報を表示装置に表示することを特徴とする付記１記載のジョブ復旧プログラム。
【０１２４】
（付記３）  動作が再開された前記ジョブの前記故障情報を前記故障管理データベースから削除することを特徴とする付記１記載のジョブ復旧プログラム。
（付記４）  前記故障情報の前記故障管理データベースへの格納に関する履歴情報を登録履歴データベースに格納する登録履歴データベース格納手段をさらに有することを特徴とする付記１記載のジョブ復旧プログラム。
【０１２５】
（付記５）  前記故障情報の前記故障管理データベースからの削除に関する履歴情報を削除履歴データベースに格納する削除履歴データベース格納手段をさらに有することを特徴とする付記３記載のジョブ復旧プログラム。
【０１２６】
（付記６）  前記オペレータの要求に応じて、前記登録履歴データベースに格納されている前記履歴情報を表示装置に表示することを特徴とする付記４記載のジョブ復旧プログラム。
【０１２７】
（付記７）  前記オペレータの要求に応じて、前記削除履歴データベースに格納されている前記履歴情報を表示装置に表示することを特徴とする付記５記載のジョブ復旧プログラム。
【０１２８】
（付記８）  前記オペレータの指示によって前記ジョブが利用する資源を検査する検査手段、
前記資源が故障していた場合、前記資源の情報と前記ジョブの情報とを含む資源故障情報を故障要因ごとに分類して、前記故障管理データベースに格納する資源データベース格納手段、
をさらに有することを特徴とする付記１記載のジョブ復旧プログラム。
【０１２９】
（付記９）  複数のバッチコンピュータによって実行される複数のジョブを復旧するジョブ復旧装置において、
故障が発生した際に前記ジョブが出力する前記ジョブの情報と故障要因とを含む故障情報を受信する故障情報受信手段と、
前記故障情報を前記故障要因ごとに分類して、故障管理データベースに格納するデータベース格納手段と、
前記故障要因が復旧されたことによってオペレータより入力される前記故障要因を受信する故障要因受信手段と、
前記故障管理データベースを参照して、前記故障要因に対応する前記ジョブを検索するジョブ検索手段と、
前記ジョブの動作を再開させるジョブ動作再開手段と、
を有することを特徴とするジョブ復旧装置。
【０１３０】
（付記１０）  複数のバッチコンピュータによって実行される複数のジョブを復旧するジョブ復旧方法において、
故障が発生した際に前記ジョブが出力する前記ジョブの情報と故障要因とを含む故障情報を故障情報受信手段によって受信し、
前記故障情報を前記故障要因ごとに分類して、故障管理データベースにデータベース格納手段で格納し、
前記故障要因が復旧されたことによってオペレータより入力される前記故障要因を故障要因受信手段で受信し、
前記故障管理データベースを参照して、前記故障要因に対応する前記ジョブをジョブ検索手段で検索し、
前記ジョブの動作をジョブ動作再開手段で再開させる、
ことを特徴とするジョブ復旧方法。
【図面の簡単な説明】
【０１３１】
【図１】本発明の原理を説明する原理図である。
【図２】本発明の実施の形態のシステム構成例を示した図である。
【図３】図２の納付処理システムのシステム構成例を示した図である。
【図４】監視サーバのハードウェア構成を示すブロック図である。
【図５】納付処理システム全体の機能の概略を説明する図である。
【図６】バッチサーバで実行されるジョブを説明する図である。
【図７】コードと故障内容の関係を示した図である。
【図８】通知データのデータ構成例である。
【図９】ジョブの再開処理について説明する図である。
【図１０】監視サーバの機能ブロック図である。
【図１１】故障管理ＤＢの構造例を示した図である。
【図１２】故障情報のデータ構成例を示した図である。
【図１３】ＡＰＬロジック部の故障発生例を説明する図である。
【図１４】図１３のバッチサーバから出力される通知データを示した図である。
【図１５】モニタに表示されるジョブ照会画面を示した図で、（ａ）は画面その１、（ｂ）は画面その２、（ｃ）は画面その３である。
【図１６】ジョブの復旧を説明する図である。
【図１７】ＤＢロジック部の故障発生例を説明する図である。
【図１８】図１７のバッチサーバから出力される通知データを示した図である。
【図１９】モニタに表示されるジョブ照会画面を示した図で、（ａ）は画面その１、（ｂ）は画面その２、（ｃ）は画面その３である。
【図２０】ジョブの復旧を説明する図である。
【図２１】監視サーバ全体の処理の流れを示したフローチャートである。
【図２２】バッチサーバでの故障検出の処理の流れを示したフローチャートである。
【図２３】監視サーバの事前チェックの処理の流れを示したフローチャートである。
【図２４】監視サーバの故障情報の格納処理の流れを示したフローチャートである。
【図２５】監視サーバの復旧処理の流れを示したフローチャートである。
【図２６】監視サーバの照会処理の流れを示したフローチャートである。
【図２７】監視サーバの履歴照会処理の流れを示したフローチャートである。
【符号の説明】
【０１３２】
１  コンピュータ
２，３  バッチコンピュータ
１ａ  故障情報受信手段
１ｂ  データベース格納手段
１ｃ  故障要因受信手段
１ｄ  ジョブ検索手段
１ｅ  ジョブ動作再開手段
１ｆ  故障管理データベース
２ａ，２ｂ，３ａ，３ｂ，１２ａ，１５ａ，１６ａ，７１  ジョブ
１０  納付処理システム
１１  監視サーバ
１２，１３  バッチサーバ
１４  ＤＢサーバ
１５，１６  業務サーバ
１７  連携サーバ
７２  フレームワーク
７３  ＡＰＬ
７５  通知データ
８１  通知データ受信部
８２  事象格納部
８３  事前チェック部
８４  照会処理部
８５  故障事象検索部
８６  再起動部
８７  故障管理ＤＢ
８８  事象管理履歴ＤＢ
８９  登録削除履歴部
【図１】
2005222105.tif 000003
【図２】
2005222105.tif 000004
【図３】
2005222105.tif 000005
【図４】
2005222105.tif 000006
【図５】
2005222105.tif 000007
【図６】
2005222105.tif 000008
【図７】
2005222105.tif 000009
【図８】
2005222105.tif 000010
【図９】
2005222105.tif 000011
【図１０】
2005222105.tif 000012
【図１１】
2005222105.tif 000013
【図１２】
2005222105.tif 000014
【図１３】
2005222105.tif 000015
【図１４】
2005222105.tif 000016
【図１５】
2005222105.tif 000017
【図１６】
2005222105.tif 000018
【図１７】
2005222105.tif 000019
【図１８】
2005222105.tif 000020
【図１９】
2005222105.tif 000021
【図２０】
2005222105.tif 000022
【図２１】
2005222105.tif 000023
【図２２】
2005222105.tif 000024
【図２３】
2005222105.tif 000025
【図２４】
2005222105.tif 000026
【図２５】
2005222105.tif 000027
【図２６】
2005222105.tif 000028
【図２７】
2005222105.tif 000029