(57)【特許請求の範囲】
【請求項１】
バッチ処理を構成する第１のジョブおよび第２のジョブを並列して実行可能なジョブ実行装置であって、
前記第１のジョブを実行する第１のジョブ実行部と、
前記第１のジョブ実行部によって前記第１のジョブが実行された結果出力された第１のデータを記憶するデータ記憶部と、
前記データ記憶部によって記憶されている前記第１のデータを処理する前記第２のジョブを実行する第２のジョブ実行部と、
前記第２のジョブで処理されている前記第１のデータを特定するためのデータ特定情報を含むデータ情報を記憶するデータ情報記憶部と、
障害が発生した場合に、前記データ記憶部によって記憶されている前記第１のデータ、および前記データ情報記憶部によって記憶されている前記データ情報をダンプするダンプ部と、
を備えることを特徴とするジョブ実行装置。
【請求項２】
前記第２のジョブ実行部によって前記第２のジョブを実行した結果出力される第２のデータがコミットされた場合に、前記データ記憶部によって記憶されている前記第１のデータから、前記コミットされた前記第２のデータに対応する前記第１のデータを削除するデータ削除部をさらに備えることを特徴とする請求項１記載のジョブ実行装置。
【請求項３】
前記データ情報には、前記データ記憶部によって記憶されている複数の前記第１のデータからなるデータ群を特定するためのデータ群特定情報がさらに含まれ、
前記第２のジョブ実行部は、前記データ群ごとに前記第２のデータをコミットし、
前記データ削除部は、前記第２のデータがコミットされた場合に、前記データ記憶部によって記憶されている前記第１のデータから、前記コミットされた前記第２のデータに対応する前記データ群に含まれる前記第１のデータを削除することを特徴とする請求項２記載のジョブ実行装置。
【請求項４】
前記ダンプ部によってダンプされた前記第１のデータおよび前記データ情報を、ダンプ時の記憶領域に記憶させるデータ復旧部をさらに備えることを特徴とする請求項１〜３のいずれか１項に記載のジョブ実行装置。
【請求項５】
バッチ処理を構成する第１のジョブおよび第２のジョブを並列して実行可能な装置において実行されるジョブ実行方法であって、
前記第１のジョブを実行する第１のジョブ実行ステップと、
前記第１のジョブ実行ステップにおいて前記第１のジョブが実行された結果出力された第１のデータを記憶するデータ記憶ステップと、
前記データ記憶ステップにおいて記憶された前記第１のデータを処理する前記第２のジョブを実行する第２のジョブ実行ステップと、
前記第２のジョブで処理されている前記第１のデータを特定するためのデータ特定情報を含むデータ情報を記憶するデータ情報記憶ステップと、
障害が発生した場合に、前記データ記憶ステップにおいて記憶された前記第１のデータ、および前記データ情報記憶ステップにおいて記憶された前記データ情報をダンプするダンプステップと、
を含むことを特徴とするジョブ実行方法。
【請求項６】
請求項５に記載の各ステップをコンピュータに実行させるためのジョブ実行プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ジョブ実行装置、ジョブ実行方法およびジョブ実行プログラムに関する。
【背景技術】
【０００２】
一般に、バッチ処理システムでは、ジョブに従って入力ファイルから順次データを読み込み、読み込んだデータを処理して出力ファイルに書き出す処理を実行する。このようなシステムで処理中に障害が発生した場合には、出力データを処理前の状態に戻し、再度処理を実行してデータを復旧する。下記特許文献１では、障害が発生した場合であっても、出力データを処理前の初期状態に戻すことなく、処理を再開する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平６−１２２６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記特許文献１に記載の技術では、バッチ処理中に出力されたデータの件数を記憶している。そして、障害が発生した場合には、入力データを再度先頭から読み込み、上記記憶した出力データ件数分の入力データを読み飛ばし、その次に入力されるデータから処理を再開して出力ファイルを更新させている。
【０００５】
ところが、バッチ処理システムの中には、複数のジョブを並列して実行可能なバッチ処理高速化方式（ＰＲＥＳＴ）を採用するものがある。このようなバッチ処理システムでは、先行するジョブでデータの一部が出力されると、その出力データを用いて後続ジョブが並列して実行される。したがって、バッチ処理中は、並列に実行されるジョブごとにデータの処理状態や処理件数が異なることになる。このようなバッチ処理システムで障害が発生すると、単に全体の処理件数を記憶しているだけでは、ジョブごとに異なるデータの処理状態や処理件数までは把握することができないため、障害発生時に処理が確定していないデータを全て初期状態に戻す必要がある。つまり、初期状態に戻したデータについては再度最初のジョブからバッチ処理を開始することになるため、障害回復後のデータ復旧に時間を要してしまう。
【０００６】
本発明は、上述した課題を解決するためになされたものであり、複数のジョブを並列して実行する場合であっても障害回復後のデータ復旧時間を短縮することができるジョブ実行装置、ジョブ実行方法およびジョブ実行プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明のジョブ実行装置は、バッチ処理を構成する第１のジョブおよび第２のジョブを並列して実行可能なジョブ実行装置であって、第１のジョブを実行する第１のジョブ実行部と、第１のジョブ実行部によって第１のジョブが実行された結果出力された第１のデータを記憶するデータ記憶部と、データ記憶部によって記憶されている第１のデータを処理する第２のジョブを実行する第２のジョブ実行部と、第２のジョブで処理されている第１のデータを特定するためのデータ特定情報を含むデータ情報を記憶するデータ情報記憶部と、障害が発生した場合に、データ記憶部によって記憶されている第１のデータ、およびデータ情報記憶部によって記憶されているデータ情報をダンプするダンプ部と、を備える。
【０００８】
本発明のジョブ実行方法は、バッチ処理を構成する第１のジョブおよび第２のジョブを並列して実行可能な装置において実行される方法であって、第１のジョブを実行する第１のジョブ実行ステップと、第１のジョブ実行ステップにおいて第１のジョブが実行された結果出力された第１のデータを記憶するデータ記憶ステップと、データ記憶ステップにおいて記憶された第１のデータを処理する第２のジョブを実行する第２のジョブ実行ステップと、第２のジョブで処理されている第１のデータを特定するためのデータ特定情報を含むデータ情報を記憶するデータ情報記憶ステップと、障害が発生した場合に、データ記憶ステップにおいて記憶された第１のデータ、およびデータ情報記憶ステップにおいて記憶されたデータ情報をダンプするダンプステップと、を含む。
【０００９】
本発明のジョブ実行プログラムは、上記ジョブ実行方法に含まれる各ステップをコンピュータに実行させる。
【発明の効果】
【００１０】
本発明によれば、障害回復後のデータ復旧時間を短縮することができる。
【図面の簡単な説明】
【００１１】
【図１】実施形態におけるジョブ実行装置の機能構成を示すブロック図である。
【図２】ジョブ実行装置におけるデータの流れを模式的に示す図である。
【図３】エージェント部が後続ジョブ実行部に処理データを送信する際の動作を説明するためのフローチャートである。
【図４】エージェント部が先行ジョブ実行部から処理結果データを受信する際の動作を説明するためのフローチャートである。
【図５】障害が発生した際の動作を説明するためのフローチャートである。
【図６】エージェント部が後続ジョブ実行部からコミット通知を受信した際の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００１２】
以下、添付図面を参照して、本発明に係るジョブ実行装置、ジョブ実行方法およびジョブ実行プログラムの好適な実施形態について説明する。
【００１３】
まず、図１および図２を参照して、実施形態におけるジョブ実行装置の構成について説明する。図１は、ジョブ実行装置の機能構成を示すブロック図である。図２は、ジョブ実行装置におけるデータの流れを模式的に示す図である。なお、ジョブ実行装置は、複数のジョブを並列して実行可能なバッチ処理高速化方式（ＰＲＥＳＴ）を採用する。
【００１４】
図１に示すように、ジョブ実行装置１は、複数のエージェント部１０と、複数のジョブ実行部２０と、エージェント管理部３０と、メモリ４０と、ダンプ情報ファイル５０とを有する。
【００１５】
ジョブ実行部２０は、一つのジョブごとに設けられ、割り当てられたジョブを実行する。本実施形態では、説明の便宜のために、ジョブが二つである場合について説明する。最初に実行するジョブを先行ジョブ（第１のジョブ）といい、この先行ジョブの実行によって出力されたデータを用いて処理を実行するジョブを後続ジョブ（第２のジョブ）という。また、先行ジョブを実行するジョブ実行部２０を先行ジョブ実行部２０（第１のジョブ実行部）といい、後続ジョブを実行するジョブ実行部２０を後続ジョブ実行部２０（第２のジョブ実行部）ということにする。なお、ジョブが二つであるため、エージェント部１０は一つとなる。
【００１６】
エージェント部１０は、ジョブ実行部２０間に設けられ、先行ジョブから後続ジョブへのデータの引き継ぎ処理等を制御する。エージェント管理部３０は、全てのエージェント部１０を管理する機能を有し、障害発生時には各エージェント部１０に障害が発生した旨を示す障害発生通知を送信する。エージェント部１０の詳細については後述する。
【００１７】
メモリ４０は、処理データ格納領域４１（データ記憶部）と、処理データ情報格納領域４２（データ情報記憶部）とを有する。図２に示すように、処理データ格納領域４１には、先行ジョブ実行部２０から出力された処理データ（第１のデータ）が格納される。処理データはチャンク（データ群）単位に特定可能に格納される。チャンクとは、複数のデータをまとめたものであり、トランザクションの単位となる。本実施形態では、三つのデータでチャンクを形成する。データにはデータを特定するための番号（データ特定情報）が入力順にカウントアップして付与され、チャンクにはチャンクを特定するための番号（データ群特定情報）が入力順にカウントアップして付与される。処理データ格納領域４１に格納される処理データは、先行ジョブ実行部２０から出力されたときに登録され、後続ジョブ実行部２０からコミットを受信したときに削除される。
【００１８】
処理データ情報格納領域４２には、処理データ管理テーブル４２１と、後続処理中データ番号４２２とが格納される。処理データ管理テーブル４２１は、データ項目として、例えば、チャンク番号、チャンク先頭データ番号、チャンク最後尾データ番号を有する。チャンク番号の項目には、先行ジョブ実行部２０から出力された処理データが属するチャンク番号が格納される。チャンク先頭データ番号の項目には、チャンクを構成する先頭の処理データに付与された番号（データ特定情報）が格納される。チャンク最後尾データ番号の項目には、チャンクを構成する最後尾の処理データに付与された番号（データ特定情報）が格納される。
【００１９】
処理データ管理テーブル４２１では、上記各データ項目からなる処理データ管理レコード（データ情報）単位に登録や削除が行われる。処理データ管理レコードは、チャンクを構成する先頭の処理データが先行ジョブ実行部２０から出力されたときに登録される。登録時の処理データ管理レコードのチャンク最後尾データ番号には、まだデータが存在しないことを示す“−”が格納されている。その後、先行ジョブ実行部２０からチャンクを構成する最後尾の処理データが出力されたときに、その処理データの番号を、処理データ管理レコードのチャンク最後尾データ番号に格納する。つまり、チャンク最後尾データ番号に“−”が格納されている場合には、そのチャンクに属する処理データのいずれかが先行ジョブ実行部２０で実行されている状態であることを示す。また、処理データ管理レコードは、チャンクを構成する最後尾の処理データが後続ジョブ実行部２０でジョブが実行されてコミットされたときに削除される。
【００２０】
後続処理中データ番号４２２には、処理データ格納領域４１に格納されている処理データのうち、後続ジョブ実行部２０で処理中の処理データに付与された番号（データ情報）が格納される。
【００２１】
図１を参照して、エージェント部１０について詳細に説明する。図１に示すように、エージェント部１０は、処理結果データ受信部１１０と、終了コード確認部１１１と、処理データ更新部１１２と、データ要求受信部１２０と、処理対象データ管理部１２１と、処理データ取得部１２３と、データ送信部１２４と、コミット通知受信部１３０と、障害発生通知部１４０と、障害発生通知受信部１４１と、ダンプ部１４２と、データ復旧部１４３と、を有する。
【００２２】
処理結果データ受信部１１０は、先行ジョブ実行部２０から処理結果データを受信する。処理結果データは、ジョブ実行部２０に入力されたデータごとに、ジョブ実行部２０から出力される。処理結果データには、ジョブを実行した結果出力される処理データおよびジョブの終了コードが含まれる。処理データには、チャンクの最後尾データであるか否かを示す情報が格納される。終了コードには、処理が正常に終了したか否かを示す情報が格納される。なお、ジョブ実行中に障害が発生すると、処理結果データには処理データが含まれず、終了コードのみが含まれることになる。
【００２３】
終了コード確認部１１１は、先行ジョブ実行部２０から受信した処理結果データに含まれる終了コードに基づいて、処理が正常に終了したか否かを判定する。
【００２４】
処理データ更新部１１２は、終了コード確認部１１１によって処理が正常に終了したと判定された場合に、先行ジョブ実行部２０から受信した処理データを処理データ格納領域４１に格納する。
【００２５】
処理データ更新部１１２は、処理結果データに含まれる処理データがチャンクの最後尾データであるか否かを判定する。処理データ更新部１１２は、処理データがチャンクの最後尾データである場合には、チャンク最後尾データ番号に“−”が格納されているデータ情報管理レコードを検索する。処理データ更新部１１２は、検出したデータ情報管理レコードのチャンク最後尾データ番号に、先行ジョブ実行部２０から受信した処理データの番号を格納する。
【００２６】
データ要求受信部１２０は、後続ジョブ実行部２０から、処理データを送信するように要求するデータ要求を受信する。データ要求受信部１２０は、データ要求を受信した場合に、その旨を処理対象データ管理部１２１に通知する。
【００２７】
処理対象データ管理部１２１は、後続ジョブ実行部２０で直前に処理されていたデータを特定し、後続ジョブ実行部２０に送信するデータを決定する。具体的に、処理対象データ管理部１２１は、処理データ情報格納領域４２に格納されている後続処理中データ番号４２２を参照することで、後続ジョブ実行部２０で直前に処理されたデータの番号を特定する。処理対象データ管理部１２１は、特定した番号に１を加算した番号を送信対象データ情報として処理データ取得部１２３に通知する。
【００２８】
処理データ取得部１２３は、処理対象データ管理部１２１から受信した送信対象データ情報に対応するデータが処理データ格納領域４１に格納されているか否かを判定する。処理データ取得部１２３は、送信対象データ情報に対応するデータが格納されている場合には、送信対象データ情報に対応するデータを取得する。処理データ取得部１２３は、送信対象データ情報に対応するデータが格納されていない場合には、所定時間待機してから再度データの有無を判定する処理を繰り返す。処理データ取得部１２３は、この再判定処理を所定回数繰り返しても送信対象データ情報に対応するデータを取得できない場合には、その旨のエラー通知を発行する。
【００２９】
データ送信部１２４は、処理データ取得部１２３によって取得されたデータを後続ジョブ実行部２０に送信する。データ送信部１２４は、処理データ取得部１２３によって発行されたエラー通知を後続ジョブ実行部２０に送信する。
【００３０】
コミット通知受信部１３０は、後続ジョブ実行部２０からコミット通知を受信する。コミット通知は、各ジョブ実行部２０においてチャンク単位で処理が確定するたびに発行される。コミット通知には、チャンク内の最後尾データの番号が含まれる。
【００３１】
処理対象データ管理部１２１は、後続ジョブ実行部２０からコミット通知が受信された場合に、処理データ管理テーブル４２１のチャンク最後尾データ番号を参照し、このチャンク最後尾データ番号が、コミット通知に含まれるチャンク内の最後尾データの番号以下となる処理データ管理レコードを削除する。
【００３２】
処理データ更新部１１２は、後続ジョブ実行部２０からコミット通知が受信された場合に、処理データ格納領域４１に格納されている処理データの番号を参照し、この処理データの番号が、コミット通知に含まれるチャンク内の最後尾データの番号以下となる処理データをチャンク単位で削除する。
【００３３】
障害発生通知部１４０は、終了コード確認部１１１によって処理が異常終了したと判定された場合には、障害が発生した旨を示す障害発生通知をエージェント管理部３０に送信する。
【００３４】
障害発生通知受信部１４１は、障害発生通知を受信した場合に、処理データ更新部１１２および処理対象データ管理部１２１での処理機能を停止させる。障害発生通知受信部１４１は、障害発生通知を受信した場合に、ダンプ処理の実行指示をダンプ部１４２に送出する。
【００３５】
ダンプ部１４２は、処理データ格納領域４１に格納されている処理データ、処理データ管理テーブル４２１に格納されている処理データ管理レコードおよび後続処理中データ番号４２２に格納されている処理データの番号をそれぞれダンプ情報ファイル５０にダンプする。
【００３６】
データ復旧部１４３は、ダンプ情報ファイル５０に格納された各データを処理データ格納領域４１、処理データ管理テーブル４２１および後続処理中データ番号４２２にそれぞれ格納することで、メモリ４０の各データを障害直前の状態に復旧させる。
【００３７】
次に、図面を参照して本実施形態におけるジョブ実行装置１の動作について説明する。図３を参照して、エージェント部が後続ジョブ実行部に処理データを送信する際の動作について説明する。
【００３８】
最初に、データ要求受信部１２０は、後続ジョブ実行部２０からデータ要求を受信する（ステップＳ１０１）と、データ要求を受信した旨を処理対象データ管理部１２１に通知する（ステップＳ１０２）。
【００３９】
続いて、処理対象データ管理部１２１は、処理データ情報格納領域４２に格納されている後続処理中データ番号４２２を参照し、後続ジョブ実行部２０で直前に処理されたデータの番号を特定する（ステップＳ１０３）。
【００４０】
続いて、処理対象データ管理部１２１は、特定した番号に１を加算した番号を送信対象データ情報として処理データ取得部１２３に送信する（ステップＳ１０４）。
【００４１】
続いて、処理データ取得部１２３は、処理対象データ管理部１２１から受信した送信対象データ情報に対応する処理データが処理データ格納領域４１に格納されているか否かを判定する（ステップＳ１０５）。この判定がＹＥＳである場合（ステップＳ１０５；ＹＥＳ）に、処理データ取得部１２３は、送信対象データ情報に対応する処理データを処理データ格納領域４１から取得する（ステップＳ１０６）。
【００４２】
続いて、データ送信部１２４は、送信対象データ情報に対応する処理データを後続ジョブ実行部２０に送信する（ステップＳ１０７）。
【００４３】
続いて、処理対象データ管理部１２１は、後続ジョブ実行部２０に送信した処理データの番号を後続処理中データ番号４２２に格納して更新する（ステップＳ１０８）。
【００４４】
一方、上記ステップＳ１０５の判定で送信対象データ情報に対応する処理データが処理データ格納領域４１に格納されていないと判定された場合（ステップＳ１０５；ＮＯ）に、処理データ取得部１２３は、判定回数をカウントアップし（ステップＳ１０９）、判定回数が所定回数を超えたか否かを判定する（ステップＳ１１０）。この判定がＹＥＳである場合（ステップＳ１１０；ＹＥＳ）に、処理データ取得部１２３は、エラー通知を発行して後続ジョブ実行部２０に送信する（ステップＳ１１１）。
【００４５】
一方、上記ステップＳ１１０の判定で判定回数が所定回数以下である場合（ステップＳ１１０；ＮＯ）に、処理データ取得部１２３は、所定時間待機してから上述したステップＳ１０５に移行する。
【００４６】
図４を参照して、エージェント部が先行ジョブ実行部から処理結果データを受信する際の動作について説明する。
【００４７】
最初に、先行ジョブ実行部２０から処理結果データを受信する（ステップＳ２０１）と、終了コード確認部１１１は、処理結果データに含まれる終了コードに基づいて、処理が正常に終了したか否かを判定する（ステップＳ２０２）。この判定がＮＯである場合（ステップＳ２０２；ＮＯ）に、障害発生通知部１４０は、エージェント管理部３０に障害発生通知を送信する（ステップＳ２０３）。これにより、エージェント管理部３０が、全てのエージェント部１０に障害発生通知を送信し、各エージェント部１０は障害時の処理を行うことになる。
【００４８】
一方、上記ステップＳ２０２の判定で処理が正常に終了したと判定された場合（ステップＳ２０２；ＹＥＳ）に、処理データ更新部１１２は、処理結果データに含まれる処理データを処理データ格納領域４１に格納する（ステップＳ２０４）。
【００４９】
続いて、処理データ更新部１１２は、処理結果データに含まれる処理データがチャンクの最後尾データであるか否かを判定する（ステップＳ２０５）。この判定がＮＯである場合（ステップＳ２０５；ＮＯ）には処理を終了する。
【００５０】
一方、上記ステップＳ２０５の判定で処理データがチャンクの最後尾データであると判定された場合（ステップＳ２０５；ＹＥＳ）に、処理データ更新部１１２は、チャンク最後尾データに“−”が格納されているデータ情報管理レコードを検索する（ステップＳ２０６）。処理データ更新部１１２は、検出されたデータ情報管理レコードのチャンク最後尾データに、上記ステップＳ２０１で受信した処理結果データに含まれる処理データの番号を格納して更新する（ステップＳ２０７）。
【００５１】
図５を参照して、障害が発生した際の動作について説明する。
【００５２】
最初に、障害発生通知受信部１４１は、エージェント管理部３０から送信された障害発生通知を受信する（ステップＳ３０１）と、処理対象データ管理部１２１および処理データ更新部１１２の処理機能を停止させる（ステップＳ３０２）。
【００５３】
続いて、障害発生通知受信部１４１は、ダンプ処理の実行指示をダンプ部１４２に送出する（ステップＳ３０３）。
【００５４】
続いて、ダンプ部１４２は、処理データ格納領域４１に格納されている処理データ、処理データ管理テーブル４２１に格納されている処理データ管理レコードおよび後続処理中データ番号４２２に格納されている処理データの番号をそれぞれダンプ情報ファイル５０にダンプする（ステップＳ３０４）。
【００５５】
続いて、障害が解消した場合（ステップＳ３０５；ＹＥＳ）に、データ復旧部１４３は、ダンプ情報ファイル５０ファイルにダンプさせた各データをメモリ４０に格納する（ステップＳ３０６）。これにより、メモリ４０の各データを障害直前の状態に復旧させることができる。なお、障害が解消したことは、例えば、管理者の入力操作にしたがってエージェント管理部３０から送信される障害解消通知を受信することで判定することができる。
【００５６】
図６を参照して、エージェント部が後続ジョブ実行部からコミット通知を受信した際の動作について説明する。
【００５７】
最初に、コミット通知受信部１３０は、後続ジョブ実行部２０からコミット通知を受信する（ステップＳ４０１）と、コミット通知に含まれるチャンク内の最後尾データの番号を処理対象データ管理部１２１に通知する（ステップＳ４０２）。
【００５８】
続いて、処理対象データ管理部１２１は、処理データ管理テーブル４２１のチャンク最後尾データ番号を参照し、このチャンク最後尾データ番号が、コミット通知に含まれるチャンク内の最後尾データの番号以下となる処理データ管理レコードを削除する（ステップＳ４０３）。
【００５９】
続いて、処理対象データ管理部１２１は、コミット通知に含まれるチャンク内の最後尾データの番号を処理データ更新部１１２に通知する（ステップＳ４０４）。
【００６０】
続いて、処理データ更新部１１２は、処理データ格納領域４１に格納されている処理データの番号を参照し、この処理データの番号が、コミット通知に含まれるチャンク内の最後尾データの番号以下となる処理データをチャンク単位で削除する（ステップＳ４０５）。このように、コミットされたデータを削除していくことでメモリの記憶効率を向上させることができる。
【００６１】
上述してきたように、実施形態におけるジョブ実行装置１によれば、障害が発生した場合、並列に実行されるジョブごとに障害発生時に未確定の処理データをその処理状態とともに退避させることができる。したがって、障害が回復した場合に、その退避データを復旧させることで、各ジョブの処理データを障害発生時の状態に戻すことができる。つまり、データ復旧後に各ジョブの実行を再開させることで、障害発生時の状態から処理を再開させることが可能になる。それゆえに、複数のジョブを並列して実行する場合であっても障害回復後のデータ復旧時間を短縮することができる。
【００６２】
ここで、ジョブ実行装置１には、上述した各部の機能を実現させるプログラムがインストールされている。このプログラムを実行することで、上述した各部の機能を実現することができる。
【００６３】
なお、上述した実施形態は、単なる例示に過ぎず、実施形態に明示していない種々の変形や技術の適用を排除するものではない。すなわち、本発明は、その趣旨を逸脱しない範囲で様々な形態に変形して実施することができる。
【符号の説明】
【００６４】
１…ジョブ実行装置、１０…エージェント部、２０…ジョブ実行部、３０…エージェント管理部、４０…メモリ、４１…処理データ格納領域、４２…処理データ情報格納領域、５０…ダンプ情報ファイル、１１０…処理結果データ受信部、１１１…終了コード確認部、１１２…処理データ更新部、１２０…データ要求受信部、１２１…処理対象データ管理部、１２３…処理データ取得部、１２４…データ送信部、１３０…コミット通知受信部、１４０…障害発生通知部、１４１…障害発生通知受信部、１４２…ダンプ部、１４３…データ復旧部、４２１…処理データ管理テーブル、４２２…後続処理中データ番号。
【図１】
0005397076.tif 000002
【図２】
0005397076.tif 000003
【図３】
0005397076.tif 000004
【図４】
0005397076.tif 000005
【図５】
0005397076.tif 000006
【図６】
0005397076.tif 000007