(57)【特許請求の範囲】
【請求項１】
バッチ実行サーバにおけるバッチ処理を運用管理サーバで管理するためのバッチ処理の実行管理方法において、
前記運用管理サーバは、前記バッチ処理を実行するバッチ実行サーバに、当該運用管理サーバでの、前記バッチ実行サーバにおけるバッチプログラムを識別するバッチ識別記号を送信し、
前記バッチ実行サーバは、
前記バッチ識別記号が、データベースに格納されたバッチ識別記号、実行日および実行時刻から構成されるバッチ実行状態管理情報に対応するレコードがないかを検索し、
当該検索結果が該当するレコードがなかった場合、所定処理を終了後、同期点取得でデータ更新を確定していればコミット完了情報にレコードが追加された状態になり、データ更新が完了していると判断し、
検索結果が該当するレコードがあった場合、前記所定処理を実行せず、処理を終了させることを特徴とするバッチ処理の実行管理方法。
【請求項２】
請求項１に記載のバッチ処理の実行管理方法において、
前記判断では、同期点取得でデータ更新を戻していればデータ更新されていないと判断することを特徴とするバッチ処理の実行管理方法。
【請求項３】
請求項１または２のいずれかに記載のバッチ処理の実行管理方法において、
さらに、予め定められた期間において、同一バッチ処理を複数回起動すると実行結果が不正になるバッチ処理において、上記の判断結果に応じて複数回起動を防止することを特徴とするバッチ処理の実行管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、いわゆるバッチ処理の実行を管理するための技術に関する。その中でも特に、バッチ処理の実行に伴うエラーを監視ないし管理するための技術に関する。
【背景技術】
【０００２】
企業の業務システムなどで、データを一定期間ないし一定量などでまとめて処理することがなされている。このようなバッチ処理においてもデータの更新(書き込み)のエラーなどで異常終了が発生することがある。この異常終了に対応、つまり、リカバリする技術として、特許文献１が提案されている。
【０００３】
特許文献１では、前回のバッチ処理時に発生したエラーが解消しておらずリカバリに失敗した場合、それ以降のトランザクションが集積してしまうとの問題を解決することを目的にしている。この目的を達成するために、特許文献１では、リカバリ回数を記録しておき、リトライ(リカバリ)回数が予め定められた回数以下のバッチ処理を対象として、リカバリ処理を開始することが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１７６３０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、情報システムにおけるバッチ処理については、決められた時刻に正確に動作させたり、複雑な条件を全て満たした場合に速やかに動作させる必要があり、かつその実行状況を運用者が把握する必要がある。高信頼性を要求される情報システムにおいては、運用者の負荷を軽減することと人為的ミスをなくすために、このようなバッチ処理の実行制御及び実行状況の監視を行えるよう運用管理ソフトを導入しているのが一般的である。
【０００６】
運用管理ソフトは例えば図２に示すような方法で使用される。図２において、運用管理ソフト２１は起動条件が揃ったバッチプログラム４１を起動しバッチプログラムを実行する。データベースへの追加更新を伴うバッチプログラム４１は業務処理を行った後、業務処理が正常に終了した場合は処理４１６でデータベースの追加更新を確定し正常終了する。業務処理中に何らかの異常を検知した場合は、処理４１７でデータベースの追加更新内容をバッチプログラム４１実行前の状態に戻しエラー終了する。正常終了またはエラー終了した結果は、運用管理ソフト２１に応答される。情報システムの運用者はバッチプログラム４１の実行結果を、運用管理ソフト２１がバッチプログラム４１より応答された結果より認識する。
【０００７】
図２に示すような方法でバッチプログラムの実行が行われる場合で、バッチプログラム４１が処理４１６によりデータベースの追加更新が確定し正常終了した直後に何らかの要因で障害が発生しバッチプログラム４１の実行結果を運用管理ソフト２１に応答できなかった場合、バッチプログラム４１では正常に処理が終了しているにも関わらず、運用管理ソフト２１ではバッチプログラム４１の実行結果を受け取れないため、運用者はバッチプログラム２１の実行状態を把握できない、もしくは、バッチプログラム２１がエラー終了したと誤認識する場合がある。
【０００８】
高信頼性かつ公共性が極めて高い情報システムにおいては、速やかにシステムを復旧することが要求される。
【０００９】
前記障害要因を調査する場合、バッチプログラム４１の実行状態を確認するため実行ログなどを調査し確認する必要がある。障害要因を排除し回復する場合、バッチプログラム４１がエラー終了したと誤認識されていると回復運用の中で再度バッチプログラム４１を実行しデータベースの格納値を不正な値に更新する可能性がある。バッチプログラムの実行状況を把握する手段が必要となる。
この点については、特許文献１でも考慮されていない。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明では、バッチ処理の実行において、バッチプログラムのデータ更新結果(commit完了しているか、rollbackしているか）と、バッチ処理を監視する運用管理ソフトが認識する処理結果が不整合となっても、バッチプログラムのデータ更新結果を認識するものである。より具体的には、運用管理ソフトから起動されたバッチプログラムは、コミット完了情報（データベース）に対して、バッチプログラムを特定できる情報を付加して情報を追加（insert）する。そして、各種データベースへのアクセスを伴った処理終了後、同期点取得でデータ更新を確定（commit）していればコミット完了情報にレコードが追加された状態になり、データ更新が完了していると判断するものである。また、同期点取得でデータ更新を戻し（rollback）ていればデータ更新されていないと判断する。
【００１１】
また、本発明では、上記の判断に基づいて、予め定められた期間において、同一バッチ処理を複数回起動すると実行結果が不正になるバッチ処理において、複数回起動を防止することも、その一態様に含まれる。これは、既に情報が登録されていれば１度動作していることを示すため、処理開始時にチェックすることで複数回起動を抑止できる
【発明の効果】
【００１２】
本発明によれば、バッチ処理の実行において、バッチプログラムのデータ更新結果と、バッチ処理を監視する運用管理ソフトが認識する処理結果が不整合となっても、バッチプログラムのデータ更新結果を認識できる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態のシステム構成図。
【図２】本発明の一実施形態の処理の内容を示すフローチャート(概要)。
【図３】本発明の一実施形態で用いられるバッチ実行状態管理情報を示す図。
【図４】本発明の一実施形態の処理の内容を示すフローチャート(詳細)。
【発明を実施するための形態】
【００１４】
以下、図面を用いて、本発明の一実施形態について説明する。本実施形態では、図３に一構成例を示すバッチ実行状態管理情報をデータベースとして作成し、図４に示す方法で使用する。また、その概要を図２に示すとおりである。また、この処理は、図１に示す各装置（いわゆるコンピュータで、プログラムに従ってＣＰＵがそのための演算を実行する）で、その処理が実行される。
【００１５】
図４において、運用管理ソフト２１は処理２１１で起動条件がそろったバッチプログラム４１を起動しバッチプログラムを実行する。データベースの追加更新を行うバッチプログラム４１は、運用管理ソフト上でのバッチプログラム４１を識別する値を取得するために、処理４１１で運用管理ソフト２１に対して取得用のコマンドを発行する。運用管理ソフト２１は処理２１３で、バッチプログラム４１を識別する値をバッチプログラム４１にリターンする。
【００１６】
バッチプログラム４１は、バッチ実行状態管理情報に対して、運用管理ソフトより取得したバッチプログラム４１を識別する値をバッチ識別記号として保持するレコードがないか、処理４１２にて検索する。
【００１７】
処理４１３の判定において、バッチプログラム４１を識別する値をバッチ識別記号として保持するレコードがない場合、処理４１４でバッチ実行状態管理情報に対してバッチプログラム４１を識別する値をバッチ識別記号として保持するレコードを追加した後、処理４１５の業務処理を実行する。
【００１８】
処理４１４によるレコードの追加及び処理４１５による業務処理が正常に終了した場合、処理４１６でデータベースへの追加更新の確定を行い、バッチ状態管理情報へのバッチプログラム４１を識別する記号をバッチ識別記号に持つレコードの追加も確定する。処理４１２でバッチ状態管理情報を検索した結果、バッチプログラム４１を識別する値をバッチ識別記号に持つレコードがなしの場合、運用管理ソフトが正常に応答を受け取ったか否かに関わらずバッチプログラム４１は既に正常終了済みであるため、業務処理を行わずに終了する。
【００１９】
バッチプログラム４１の実行結果を運用管理ソフト２１に応答するときに何らかの要因による障害が発生し、運用管理ソフト２１がバッチプログラム４１の実行結果を受け取れないで運用管理ソフト２１でバッチプログラム４１の実行状態が把握できない場合においても、バッチ状態管理情報にバッチプログラム４１を識別する値をバッチ識別記号に持つレコードが存在するかしないかにより、正常終了しデータベースの追加更新が正常に完了しているか否かを把握することが可能となる。
【００２０】
また、バッチプログラム４１が正常終了しているにも関わらず、運用管理ソフト２１が実行結果を受け取れていないためにバッチプログラム４１がエラー終了したと誤認識してバッチプログラム４１を再度実行しても、既にバッチ状態管理情報にバッチプログラム４１を識別する値をバッチ識別記号に持つレコードが存在するため、バッチプログラム４１の処理内で業務処理を行わないで終了することが可能となる。
【符号の説明】
【００２１】
１…ディスプレイ装置、２…運用管理サーバ、３…ネットワーク、４…バッチ実行サーバ
【図１】
0005746878.tif 000002
【図２】
0005746878.tif 000003
【図３】
0005746878.tif 000004
【図４】
0005746878.tif 000005