JP2010176303A - バッチ処理システムおよびこれに用いる情報端末装置、バッチ処理のリカバリ方法 - Google Patents

Abstract

【課題】リカバリ処理が無駄に何度も繰り返し行われる不都合を解消できるようにする。
【解決手段】バッチ処理の実行結果を管理する情報として、従来の処理ステータスおよび内部処理番号に加えて、エラー種別およびリトライ回数をバッチ処理のデータ番号に関連付けてバッチ処理結果管理テーブル記憶部１４に記録する。バッチ処理部１５は、リトライ回数がエラー種別に応じてあらかじめ定められた規定回数より少なくなっているデータ番号を対象として、内部処理番号の次のトランザクションからリカバリ処理を開始する。これにより、途中のトランザクションで異常終了となったバッチ処理が何度も繰り返しリカバリ処理の対象となることがなくなるようにする。
【選択図】 図２

Description

本発明は、各々がバッチ処理のトランザクションを実行する複数台の処理用コンピュータと、トランザクションのスケジューリングおよび投入を行う投入用コンピュータとから構成されるバッチ処理システムおよびこれに用いる情報端末装置、バッチ処理のリカバリ方法に関し、特に、何らかの障害が発生してバッチ処理が異常終了したときに自動的にリカバリを行う技術に関する。

一般に、旅行代理店が使用するオンライン予約システムは、旅行代理店内に設置される予約入力端末と、各種の予約に関する処理を行う複数のサーバとを備えて構成されている。複数のサーバは、例えば、宿泊施設の予約に関する処理を行う施設予約サーバ、航空チケットの予約に関する処理を行う航空予約サーバ、鉄道チケットの予約に関する処理を行う鉄道予約サーバなどである。これら複数のサーバと予約入力端末との間は、通信ネットワークを介して接続されている。そして、予約入力端末から各サーバに送信される処理要求に応じて、各サーバが所定の処理を実行してその処理結果を予約入力端末に返信することにより、種々の予約処理を実行するようになされている。

このようなオンライン予約システムでは、多くの場合、予約入力端末と各サーバとの間のオンライン処理を、予約入力端末への予約データの入力とは非同期に起動されるバッチ処理として行うようになされている。バッチ処理は、一連の内部処理（トランザクション）をあらかじめ登録しておき、それらを順番に実行していく方式の処理である。例えば、複数のトランザクションをまとめて一括処理できるように定義しておくことで、スケジューリングされた時間に内部処理が自動的に実行される。オンライン予約システムでは、予約入力端末において入力される予約データをもとに１つのサーバで行われる予約処理が、１つのトランザクションに相当する。

すなわち、予約入力端末において随時入力される予約データに対して随時トランザクションが割り当てられ、当該トランザクションが予約入力端末内の管理テーブルに蓄積されていく。そして、一定期間毎に、管理テーブルに蓄積されたトランザクションに従って予約データが順番に予約入力端末から各サーバに送信され、所定の予約処理が各サーバにおいて順次実行される。このように、バッチ１回の起動で複数のトランザクションが順番に実行され、その結果として宿泊施設、航空チケット、鉄道チケットなどの予約処理が行われる。

その他、リアルタイムのレスポンスが求められない処理で大量のデータを処理する場合や、業務上の理由により纏まったデータでの処理を求められる場合は、まとめて一括処理を行うバッチ処理が用いられる。上述のように、バッチ処理では、スケジューリングされた時間に自動的に処理が実行される。そのため、コンピュータのリソースがあまり使用されていない時間にまとめて処理するようにスケジューリングしておくことにより、コンピュータリソースの効率的な使用が可能になる。

ところが、このようなバッチ処理の実行途中において、何らかのエラー発生によりトランザクションが異常終了してしまうことがある。非同期のバッチ処理ではなく、オペレータが予約入力端末に予約データを入力したときにすぐにサーバにアクセスして予約処理を行うのであれば、異常終了のメッセージを受けてオペレータが直ちに対処することが可能である。これに対して、予約データの入力とは非同期で行われるバッチ処理の場合は、その途中で異常終了が発生したときには、何らかの方法で自動的にリカバリ（傷害復旧）する仕組みが必要となる。

従来、このリカバリは、どのトランザクションで異常終了が発生したかによらず、バッチ処理を先頭から再実行する方法が採用されていた。しかしそれでは、正常終了したトランザクションについても再処理が行われるため、無駄が多い。そのため、リカバリ処理に多くの時間がかかってしまうという問題があった。このような問題に対して、リカバリ時間の短縮と不必要な再処理の削減とを目的として、異常終了したところからリカバリ処理を開始できるようにした技術が提案されている（例えば、特許文献１，２参照）。

特許文献１に記載の技術では、複数のデータベースにそれぞれ対応したデータベース更新アプリケーションを設けている。そして、当該複数のデータベース更新アプリケーションの起動制御を行うバッチ処理監視部を備え、バッチ処理におけるデータの更新単位をデータベース単位としている。具体的には、データベース更新アプリケーションが異常終了を通知すると、バッチ処理監視部は、バッチ状態制御ファイルを更新してバッチ処理を停止する。その後バッチ処理監視部は、バッチ状態制御ファイルを参照して、異常終了したデータベース更新アプリケーションから再処理を開始する。

また、特許文献２に記載の技術では、アプリケーションプログラムによるデータベースに対するバッチジョブ（バッチの内部処理であるトランザクション）の進行状態を、データベースとして構成されたチェックポイントテーブルで監視、記録する。そして、異常終了後の再開始時には、チェックポイントテーブルに記録されているジョブ進行管理情報に基づいてジョブを開始する。

特開平１０−４９４１７号公報 特開２００３−８５０２１号公報

上記特許文献１，２に記載の技術によれば、バッチ処理の過程で異常終了が発生した箇所からリカバリ処理を開始することができるので、リカバリ処理に要する時間を短縮することができる。しかしながら、異常終了の発生原因であるエラーが解消していればリカバリは成功するが、エラーが依然として解消していなければ、リカバリは失敗する。その場合は、一定時間後に再びリカバリ処理が行われる。このため、１回のリカバリ処理に要する時間は短縮されていても、エラーが解消していないためにリカバリ処理が何度も繰り返し行われる無駄が生じてしまうことがあるという問題があった。

また、一定時間毎のバッチ処理に同期してリカバリ処理を行う仕組みを採用している場合には、前回のバッチ処理で異常終了した箇所以降のトランザクションと、前回のバッチ処理から一定時間の間に新たにスケジューリングされたトランザクションとが、今回のバッチ処理時に合わせて実行される。このとき、新たにスケジューリングされたトランザクションよりも、リカバリ対象のトランザクションが優先して処理される。

ここで、前回のバッチ処理時に発生したエラーが解消していなくてリカバリに失敗すると、それ以降のトランザクション（新たにスケジューリングされたトランザクションも含む）が未処理のままの状態で、今回のバッチ処理が終了してしまう。そのため、エラーが解消されるまでの間にリカバリ処理が繰り返し行われ、その都度同じトランザクションでリカバリに失敗すると、未処理のトランザクションがどんどん増えてしまうという問題もあった。

本発明は、このような問題を解決するために成されたものであり、リカバリ処理が無駄に何度も繰り返し行われる不都合を解消できるようにすることを目的とする。
また、本発明は、リカバリ処理が繰り返し行われて未処理のトランザクションがどんどん増えてしまう不都合を解消できるようにすることを目的とする。

上記した課題を解決するために、本発明では、バッチ処理の実行結果を管理する情報として、バッチ処理が途中のトランザクションで異常終了したか否かを表す処理ステータス、バッチ処理のどのトランザクションまで成功したかを表す内部処理番号に加えて、バッチ処理が異常終了した原因を表すエラー種別およびリカバリ処理の実行回数を表すリトライ回数をバッチ処理結果管理テーブルに記録する。そして、リトライ回数がエラー種別に応じてあらかじめ定められた規定回数より少なくなっているバッチ処理を対象として、内部処理番号の次のトランザクションからリカバリ処理を開始するようにしている。

本発明の他の態様では、バッチ処理の複数のトランザクションを所定のグループ単位で実行するように成し、あるグループの内部処理であるトランザクションを実行している時（あるグループに関する小バッチ処理の実行時）に処理続行不可能なエラーが発生した場合には、バッチ処理を終了する。一方、あるグループのトランザクションの実行時に処理続行可能なエラーが発生した場合には、当該あるグループについてはリカバリ対象として処理を中断した上で、他のグループのトランザクションを引き続き実行するようにしている。

上記のように構成した本発明によれば、途中のトランザクションで異常終了となったバッチ処理が何度も繰り返しリカバリ処理の対象となることはなく、リトライ回数が規定回数より少なくなっているバッチ処理のみがリカバリ処理の対象となる。しかも、リトライ回数の上限を決める規定回数がエラー種別に応じて定められているので、エラー種別に応じて適切な回数だけリカバリ処理が実行されることとなる。これにより、リカバリ処理が無駄に何度も繰り返し行われる不都合を解消することができる。また、リカバリ処理が何度も繰り返されて、途中のトランザクションがその都度異常終了するためにそれ以降のトランザクションに処理が進めないという事態を回避することもできる。これにより、リカバリ処理が繰り返し行われて未処理のトランザクションがどんどん増えてしまう不都合を解消することもできる。

さらに、本発明の他の態様によれば、あるグループに関する小バッチ処理の実行時に発生したエラーが、処理の続行が可能なエラーである場合には、当該グループに関する小バッチ処理は異常終了（次回のリカバリ対象）としつつも、他のグループについては小バッチ処理が引き続き実行されることとなる。このため、バッチ処理の途中でトランザクションが異常終了した場合にそれ以降のトランザクションは処理せずに直ちにバッチ処理を終了していた従来技術とは異なり、異常終了が発生したトランザクション以降のトランザクションについても可能な限り処理を進めることができる。これにより、リカバリ処理が繰り返し行われて未処理のトランザクションがどんどん増えてしまう不都合を更に効率よく解消することができる。

本実施形態によるバッチ処理システムの概略構成例を示すブロック図である。 本実施形態による情報処理端末の機能構成例を示すブロック図である。 本実施形態のバッチ処理結果管理テーブル記憶部に記憶されるバッチ処理結果管理テーブルの構成例を示す図である。 本実施形態によるバッチ処理結果管理テーブルの記憶内容の一例を示す図である。 本実施形態による情報処理端末の動作例を示すフローチャートである。

以下、本発明の一実施形態を図面に基づいて説明する。図１は、本実施形態によるバッチ処理システムの概略構成例を示すブロック図である。図１に示すように、本実施形態のバッチ処理システムは、複数台のサーバ装置１Ａ，１Ｂ，１Ｃ・・・（本発明の処理用コンピュータに相当）と、情報処理端末２（本発明の投入用コンピュータに相当）とを備え、これらが通信ネットワーク３により互いに接続されて構成されている。複数台のサーバ装置１Ａ，１Ｂ，１Ｃ・・・（以下、これらをまとめてサーバ装置１と記す）は、各々がバッチ処理のトランザクションを実行する。また、情報処理端末２は、トランザクションのスケジューリングおよび当該スケジューリングしたトランザクションのサーバ装置１への投入を行う。

本実施形態ではバッチ処理システムの一例として、旅行代理店が使用するオンライン予約システムに組み込まれるバッチ処理システムについて説明する。この場合、複数台のサーバ装置１Ａ，１Ｂ，１Ｃ・・・は、例えば、宿泊施設の予約に関する処理を行う施設予約サーバ、航空チケットの予約に関する処理を行う航空予約サーバ、鉄道チケットの予約に関する処理を行う鉄道予約サーバなどである。これら複数台のサーバ装置１Ａ，１Ｂ，１Ｃ・・・は、予約入力端末として使われる情報処理端末２から送信される処理要求（トランザクションの投入）に応じて、所定の予約処理を実行してその処理結果を情報処理端末２に返信する。

サーバ装置１での予約処理は、情報処理端末２への予約データの入力とは非同期に起動されるバッチ処理として行う。すなわち、情報処理端末２において随時入力される予約データに対してトランザクションを割り当て、当該トランザクションを情報処理端末２内の管理テーブルに蓄積していく。そして、一定期間毎に、管理テーブルに蓄積されたトランザクションに従って予約データを順番に情報処理端末２から各サーバ装置１に送信し（トランザクションを投入し）、所定の予約処理を各サーバ装置１において順次実行する。このように、バッチ１回の起動で複数のトランザクションを順番に実行し、その結果として宿泊施設、航空チケット、鉄道チケットなどの予約を行う。

図２は、本実施形態による情報処理端末２の機能構成例を示すブロック図である。図２に示すように、本実施形態の情報処理端末２は、操作部１１、トランザクション登録処理部１２、実行トランザクション管理テーブル記憶部１３、バッチ処理結果管理テーブル記憶部１４、バッチ処理部１５、バッチスケジュール制御部１６、タイマ部１７およびメモリ部１８を備えている。このうちバッチ処理部１５は、データ取得部２１およびトランザクション実行部２２を備えている。トランザクション実行部２２は、リカバリ制御部２２ａ、終了判定部２２ｂおよびエラー種別判定部２２ｃを備えている。

以下、これらの機能構成について１つ１つ順に説明していく。操作部１１は、情報処理端末２のユーザが予約データの入力に使用するものであり、例えばキーボードやマウスなどの入力デバイスにより構成される。なお、予約のバッチ処理を行う情報処理端末２において予約データの入力を行うようにしているが、これに限定されない。例えば、バッチ処理を行う情報処理端末２とは別に専用の予約入力端末を備え、これらを通信ネットワーク３により接続する。そして、専用の予約入力端末にて予約データの入力を行い、その予約データを情報処理端末２に対して通信ネットワーク３を介して供給するようにしてもよい。

トランザクション登録処理部１２は、操作部１１の操作を通じて入力された予約データを実行トランザクション管理テーブル記憶部１３の実行トランザクション管理テーブルに登録する。予約データの登録に際し、トランザクション登録処理部１２は、一顧客に関して入力された１以上の予約データのそれぞれに対してトランザクションを割り当てて、実行すべきトランザクションとして予約データを実行トランザクション管理テーブル記憶部１３に登録する。

例えば、ある顧客に関して宿泊施設の予約データと鉄道チケットの予約データとが操作部１１から入力された場合、トランザクション登録処理部１２は、宿泊施設の予約のためのトランザクションと、鉄道チケットの予約のためのトランザクションとを登録する。このときトランザクション登録処理部１２は、当該２つのトランザクションを１つのグループとして登録する。同様に、別の顧客に関して何らかの予約データが入力された場合、トランザクション登録処理部１２は、それらの予約データに割り当てたトランザクションを１つのグループとして、実行トランザクション管理テーブル記憶部１３に登録する。このようにして登録される各グループのトランザクションが、バッチ処理の対象となる。

また、トランザクション登録処理部１２は、上述のような各トランザクションをグループ単位でバッチ処理結果管理テーブル記憶部１４に登録する。なお、バッチ処理結果管理テーブル記憶部１４に登録するトランザクションは、実行トランザクション管理テーブル記憶部１３と同じように予約データの実体まで登録する必要は必ずしもない。例えば、予約データの実体としてのトランザクションの代わりに、トランザクションのまとまりの単位であるグループを識別する識別情報を、バッチ処理結果管理テーブル記憶部１４に登録するようにしても良い。本実施形態では、識別情報を登録する例について説明する。

図３は、本実施形態のバッチ処理結果管理テーブル記憶部１４に記憶されるバッチ処理結果管理テーブルの構成例を示す図である。図３に示すように、本実施形態のバッチ処理結果管理テーブルは、データ番号、処理ステータス、エラー種別、内部処理番号およびリトライ回数を項目として含んでいる。これらの各項目で１つのレコードが構成される。このうち、データ番号が、上述したグループを識別する識別情報に相当する。なお、１グループ内に含まれる各トランザクションは、一顧客に関して入力された各予約データに対応するものであるから、データ番号（グループの識別情報）は、顧客毎の予約番号という意味合いを有する。また、１グループ内に含まれる各トランザクションで構成されるバッチ処理は、本発明の「小バッチ処理」に相当する。

処理ステータスは、各グループに関するバッチ処理（グループの内部処理）が最後のトランザクションまで正常に終了したか途中のトランザクションで異常終了したかの判定結果を表す情報である。例えば、あるデータ番号で示されるグループ内に３つのトランザクションが登録されていた場合において、当該グループに関するバッチ処理が３つ目のトランザクションまで正常に終了したときは、処理ステータスは“処理済”となる。一方、３つのトランザクションの何れかにおいてエラーが発生して異常終了したときには、処理ステータスは“異常終了”となる。

なお、まだバッチ処理が行われていない状態では処理ステータスは“未処理”となっている。また、現在処理中の状態では処理ステータスは“処理中”となるが、これはその後“処理済”または“異常終了”の何れかに切り替わる。ただし、何れかのトランザクションの実行中に情報処理端末２のフリーズやダウンが生じた場合には、処理ステータスを“異常終了”に切り替えることができない。この場合には、処理ステータスは“処理中”のままでバッチ処理が終了する。

エラー種別は、各グループに関するバッチ処理（グループの内部処理）が途中のトランザクションで異常終了した場合に、その異常終了した原因であるエラーの種別を表す情報である。実際のところ、異常終了の原因となるエラーは種々様々である。ただし、本実施形態では、それらのエラー種別を全て識別可能にした状態でバッチ処理結果管理テーブルに登録する形態はとらない。もちろんそうしても構わないが、本実施形態では、発生したエラーが、バッチ処理の続行が不可能なエラーなのか、バッチ処理の続行が可能なエラーなのかを判別し、その何れであるかをエラーの種別としてバッチ処理結果管理テーブルに登録する形態とする。

なお、処理の続行が不可能なエラーは、情報処理端末２のフリーズ、ダウン、ハードウェア障害などである。何れかのトランザクションの実行中に情報処理端末２のフリーズやダウンが生じた場合には、その後にエラー種別を判定してバッチ処理結果管理テーブルに記録することができないので、エラー種別は初期値を表す“０”のままとなる。発生したエラーがハードウェア障害の場合は、エラー種別を判定してバッチ処理結果管理テーブルに記録することができる場合もある。その場合には、処理ステータスが“異常終了”、エラー種別が“バッチ処理の続行が不可能なエラー”となる。

一方、バッチ処理の続行が可能なエラーは、サーバ装置１との間で行う通信のタイムアウト、サーバ装置１による排他制御、データ不具合などである。タイムアウトとは、情報処理端末２がサーバ装置１に対してトランザクションを送ったにもかかわらず、所定時間以内に応答が返ってこない状態をいう。排他制御とは、情報処理端末２からサーバ装置１に送られたトランザクションによる予約処理要求をサーバ装置１が受け付けない状態をいう。この場合は、サーバ装置１から情報処理端末２に排他制御を行った旨の通知をしてくるので、情報処理端末２では排他制御エラーが生じていることを検知できる。データ不具合とは、情報処理端末２からサーバ装置１に送られたトランザクションにデータの不具合が生じているために、サーバ装置１が予約処理を実行できない状態をいう。この場合は、サーバ装置１から情報処理端末２にデータ不具合の通知をしてくるので、情報処理端末２ではデータ不具合があったことを検知できる。

タイムアウト、排他制御、データ不具合の何れの場合もそうであるが、これらのエラーが発生していてもバッチ処理を続行可能というのは、エラーの発生したトランザクション自体を続行可能という意味ではない。エラーの発生していない以降のトランザクションからバッチ処理の続きを実行可能という意味である。例えば、あるサーバ装置１Ａに対して投入したトランザクションでタイムアウトのエラーが発生していても、他のサーバ装置１Ｂ，１Ｃ，・・・との間でタイムアウトのエラーが生じるとは限らない。本実施形態では、トランザクション毎にそれを処理するサーバ装置１が変わるので、何れかのサーバ装置１に対して投入したトランザクションでエラーが発生して異常終了したとしても、他のトランザクションについてはバッチ処理を続行することが可能である。

内部処理番号は、グループ毎のバッチ処理がどのトランザクションまで成功したかを表す情報である。例えば、あるデータ番号で示されるグループ内に３つのトランザクションが登録されていた場合において、当該グループに関するバッチ処理が最後のトランザクションまで正常に終了したときは、内部処理番号は“３”となる。一方、例えば２つ目のトランザクションの実行時にエラーが発生して異常終了したときは、内部処理番号は“１”となる。なお、内部処理番号が“１”であっても、処理ステータスが“処理済”となっていれば、そのグループ内にはトランザクションが１つしかなく、そのトランザクションが正常に終了していることを示している。

リトライ回数は、異常終了後に行われるリカバリ処理の実行回数を表す情報である。詳しくは後述するが、本実施形態では、異常終了したトランザクションのリカバリ処理は、トランザクション登録処理部１２により実行トランザクション管理テーブル記憶部１３に対して新規に登録されたトランザクションの処理と同期して行う。すなわち、バッチ処理は一定の時間間隔で繰り返し行われるが、あるタイミングでバッチ処理が行われたときに異常終了したトランザクションのリカバリ処理は、次のバッチ処理が行われるタイミングで、その間に登録された新しいトランザクションの処理と共に実行する。この場合に、新規のトランザクションの処理よりも、前回までに異常終了したトランザクションのリカバリ処理を優先して実行する。

異常終了したトランザクションについてリカバリ処理を行うタイミングで、前回のバッチ処理時に発生していたエラーが解消していれば、当該トランザクションの処理は完了する。しかし、依然としてエラーが解消していない場合には、そのトランザクションは再び異常終了となる。その場合は、次のバッチ処理のタイミングで、当該トランザクションのリカバリ処理を再び行うこととなる。このようにしてトランザクションのリカバリ処理が行われる都度、そのトランザクション（正確には、そのトランザクションが属するグループのデータ番号）に対応付けてバッチ処理結果管理テーブルに記憶されるリトライ回数の値は、１つずつ増えていく。

図２に戻って説明する。バッチ処理部１５は、実行トランザクション管理テーブル記憶部１３の実行トランザクション管理テーブルに登録されたトランザクションのバッチ処理を実行する。このときバッチ処理部１５は、バッチ処理結果管理テーブル記憶部１４に記憶されているバッチ処理結果管理テーブルを参照し、トランザクションの実行順序を決定する。すなわち、バッチ処理部１５は、前回のバッチ処理から今回のバッチ処理までの間に新規に登録されたトランザクションと、前回のバッチ処理で異常終了となったリカバリ対象のトランザクションとを、バッチ処理結果管理テーブルにより示される順番に従ってバッチ処理する。

具体的に、バッチ処理部１５は、バッチ処理結果管理テーブルにより示される順番に従って、実行トランザクション管理テーブルに登録されているトランザクションを、その予約データの種類に応じて、複数台のサーバ装置１Ａ，１Ｂ，１Ｃ・・・に対して投入する。そして、各サーバ装置１Ａ，１Ｂ，１Ｃ・・・が宿泊施設の予約、航空チケットの予約、鉄道チケットの予約などに関する処理を行った結果を受け取る。

バッチスケジュール制御部１６は、バッチ処理部１５により行うバッチ処理の実行タイミングを制御する。タイマ部１７は、バッチ処理を行う一定の時間間隔を測定する。すなわち、バッチスケジュール制御部１６は、タイマ部１７により測定される時間を監視して、一定の時間が経過する毎に、バッチ処理の起動命令をバッチ処理部１５に出力する。バッチ処理部１５は、この起動命令を受けて、上述したバッチ処理を実行する。

それでは、ここでバッチ処理部１５の詳細な機能構成について説明する。データ取得部２１は、バッチ処理結果管理テーブル記憶部１４に記憶されているバッチ処理結果管理テーブルから、今回のバッチ処理で処理対象となるレコードのデータを取得してメモリ部１８に格納する。処理対象となるレコードとは、処理ステータスが“未処理”となっているレコード、および処理ステータスが“異常終了”または“処理中”となっているリカバリ対象のレコードである。

本実施形態では、処理ステータスが“異常終了”または“処理中”となっているレコードであっても、その全てをリカバリ処理の対象とする訳ではない。本実施形態では、エラー種別に応じてあらかじめ定められた規定回数よりリトライ回数が少なくなっているもののみをリカバリ処理の対象とする。そのためにデータ取得部２１は、バッチ処理結果管理テーブルのエラー種別とリトライ回数とを参照し、リトライ回数が規定回数より少なくなっているレコードのデータを取得してメモリ部１８に格納する。

本実施形態では一例として、エラー種別が“バッチ処理の続行が不可能なエラー”を示している場合は、リトライ回数の規定回数は“０”とする。すなわち、オペレータが情報処理端末２に対して何らかの処置をしなければ解消しないエラーであるので、リカバリ処理を行わないようにする。一方、エラー種別が“バッチ処理の続行が可能なエラー”の場合は、リトライ回数の規定回数は“１”とする。すなわち、１回のみリカバリ処理を行うものとする。なお、ここに示した数値は単なる一例に過ぎず、これ以外の数値としても良い。

また、データ取得部２１は、メモリ部１８に格納されたデータ番号で示されるグループの内部処理であるトランザクションの実体を実行トランザクション管理テーブル記憶部１３から取得し、メモリ部１８に格納する。このときデータ取得部２１は、バッチ処理結果管理テーブルにより示される順番に従って、実行トランザクション管理テーブルから取得したトランザクションを順番にメモリ部１８に格納する。

トランザクション実行部２２は、メモリ部１８に格納されたトランザクションを順番に実行する。具体的には、トランザクション実行部２２は、メモリ部１８に格納されたバッチ処理対象の複数のトランザクションを、データ番号で示されるグループ単位で実行するように制御する。このとき、処理ステータスが“未処理”となっているデータ番号のトランザクションに関しては、そのデータ番号で示されるグループの先頭から順番にトランザクションを実行する。

これに対して、処理ステータスが“異常終了”または“処理中”となっているデータ番号のトランザクションに関しては、リカバリ制御部２２ａにより以下のような制御を行う。すなわち、リカバリ制御部２２ａは、エラー種別に応じてあらかじめ定められた規定回数よりリトライ回数が少なくなっているデータ番号について、内部処理番号（前回のバッチ処理で処理が成功したトランザクションの最終番号）の次のトランザクションからリカバリ処理を開始するように制御する。

終了判定部２２ｂは、データ番号で示されるグループ単位で、バッチ処理が最後のトランザクションまで正常終了したか途中のトランザクションで異常終了したかを判定する。エラー種別判定部２２ｃは、終了判定部２２ｂによりバッチ処理が異常終了したと判定された場合に、異常終了した原因であるエラーの種別（バッチ処理の続行が不可能なエラーか、バッチ処理の続行が可能なエラーかの種別）を判定する。

トランザクション実行部２２は、リカバリ制御部２２ａ、終了判定部２２ｂおよびエラー種別判定部２２ｃによる処理結果に応じて、バッチ処理結果管理テーブル記憶部１４に記憶されているバッチ処理結果管理テーブルの記憶内容を適宜更新する。すなわち、リカバリ制御部２２ａによりリカバリ処理が行われたデータ番号のレコードについて、リトライ回数をインクリメントする。また、終了判定部２２ｂによる判定結果に応じて、処理ステータスを“処理済”または“異常終了”の何れかにするとともに、内部処理番号を更新する。さらに、処理ステータスを“異常終了”としたデータ番号のレコードについては、エラー種別判定部２２ｃによる判定結果に応じてエラー種別を記録する。

トランザクション実行部２２があるデータ番号のトランザクションを実行しているときに、エラー種別判定部２２ｃにより処理続行不可能なエラーが発生したと判定された場合、トランザクション実行部２２は、直ちに今回のバッチ処理を終了する。一方、あるデータ番号のトランザクションを実行しているときに、エラー種別判定部２２ｃにより処理続行可能なエラーが発生したと判定された場合には、トランザクション実行部２２は、当該データ番号で示されるグループに関するバッチ処理はリカバリ対象として処理を中断した上で、次のデータ番号のトランザクションを引き続き実行する。

このように本実施形態では、あるグループ（データ番号）のバッチ処理に関するトランザクションの実行時に発生したエラーが処理続行可能なエラーである場合には、当該グループのバッチ処理は異常終了（次回のリカバリ対象）としつつも、他のグループのバッチ処理に関するトランザクションは引き続き実行する。このため、異常終了が発生したトランザクション以降のトランザクションについても、今回のバッチ処理の中で可能な限り処理を進めることができる。

以上に説明した本実施形態による情報処理端末２の機能構成は、ハードウェア構成、ＤＳＰ、ソフトウェアの何れによっても実現することが可能である。例えばソフトウェアによって実現する場合、本実施形態の情報処理端末２は、実際にはコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどを備えて構成され、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。

したがって、コンピュータが上記実施形態の機能を果たすように動作させるプログラムを例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。上記プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、フレキシブルディスク、ハードディスク、磁気テープ、光ディスク、光磁気ディスク、ＤＶＤ、不揮発性メモリカード等を用いることができる。また、上記プログラムをインターネット等のネットワークを介してコンピュータにダウンロードすることによっても実現できる。

次に、上記のように構成した本実施形態による情報処理端末２の動作を、具体例に沿って説明する。図４は、本実施形態によるバッチ処理結果管理テーブルの記憶内容の一例を示す図である。このうち、図４（ａ）は、初回のバッチ処理時に記憶されているバッチ処理結果管理テーブルの例を示している。また、図４（ｂ）は、２回目のバッチ処理時に記憶されているバッチ処理結果管理テーブルの例を示している。また、図４（ｃ）は、３回目のバッチ処理時に記憶されているバッチ処理結果管理テーブルの例を示している。

図４（ａ）の例では、バッチ処理結果管理テーブルに４つのレコードが記憶されている。初回のバッチ処理時であるからリカバリ対象のトランザクションは存在せず、何れのデータ番号のレコードも、処理ステータスは“未処理”を表す「０」、エラー種別は初期値の「０」、内部処理番号は初期値の「０」、リトライ回数は初期値の「０」となっている。バッチ処理部１５は、このバッチ処理結果管理テーブルに登録されているデータ番号の順番に従ってトランザクションを処理していく。すなわち、データ取得部２１は４つのレコードを全て取得する。

図４（ｂ）の例では、バッチ処理結果管理テーブルに６つのレコードが記憶されている。最初の４つのレコードは、初回のバッチ処理時に記憶されていたレコードである。残り２つのレコードは、初回のバッチ処理時から今回のバッチ処理時までの間に新規に登録されたレコードである。新規に登録されたデータ番号「ＥＥＥ」および「ＦＦＦ」の２つのレコードは何れも、処理ステータスは“未処理”を表す「０」、エラー種別は初期値の「０」、内部処理番号は初期値の「０」、リトライ回数は初期値の「０」となっている。

一方、初回のバッチ処理時に登録されていた４つのレコードのうち、データ番号「ＡＡＡ」のレコードは、そのグループ内に含まれる２つのトランザクションが全て正常に終了したことを示している。データ番号「ＢＢＢ」のレコードは、そのグループ内に含まれる１つ目のトランザクションが異常終了したこと、エラー種別が“バッチ処理の続行が可能なエラー”であることを示している。

データ番号「ＣＣＣ」のレコードは、そのグループ内に含まれる２つ目のトランザクションが異常終了したこと、エラー種別が“バッチ処理の続行が不可能なエラー”であることを示している。データ番号「ＢＢＢ」でトランザクションの異常終了が発生したものの、その原因となったエラーが“バッチ処理の続行が可能なエラー”であったために、その後のデータ番号「ＣＣＣ」についてトランザクションの処理が実行され、その結果として２つ目のトランザクションが“バッチ処理の続行が不可能なエラー”により異常終了したものである。

データ番号「ＤＤＤ」のレコードは、依然として未処理のままであることを示している。データ番号「ＣＣＣ」でトランザクションの異常終了が発生し、その原因となったエラーが“バッチ処理の続行が不可能なエラー”であったために、その時点で直ちにバッチ処理が終了し、その後のデータ番号「ＤＤＤ」についてはトランザクションの処理が実行されなかったためである。

図４（ｂ）のようにバッチ処理結果管理テーブルが記憶されている場合、データ取得部２１は、データ番号「ＢＢＢ」「ＤＤＤ」「ＥＥＥ」「ＦＦＦ」の４つのレコードを取得してメモリ部１８に格納する。そして、トランザクション実行部２２は、メモリ部１８に格納された４つのレコードに関するバッチ処理を、格納されたデータ番号の順番に従って実行していく。ここで、データ番号「ＡＡＡ」のレコードを処理対象から外しているのは、既に処理が完了しているからである。また、データ番号「ＣＣＣ」のレコードを処理対象から外しているのは、異常終了の原因となったエラーの種別がリカバリ対象となっていないからである。

図４（ｃ）の例では、バッチ処理結果管理テーブルに９つのレコードが記憶されている。最初の６つのレコードは、初回および２回目のバッチ処理時に記憶されたレコードである。残り３つのレコードは、２回目のバッチ処理時から今回のバッチ処理時までの間に新規に登録されたレコードである。新規に登録されたデータ番号「ＧＧＧ」、「ＨＨＨ」および「ＩＩＩ」の３つのレコードは何れも、処理ステータスは“未処理”を表す「０」、エラー種別は初期値の「０」、内部処理番号は初期値の「０」、リトライ回数は初期値の「０」となっている。

一方、初回のバッチ処理時に登録されていた４つのレコードのうち、データ番号「ＡＡＡ」および「ＣＣＣ」の２つのレコードについては、２回目のバッチ処理時に処理の対象外とされている。そのため、処理ステータス、エラー種別、内部処理番号およびリトライ回数の値は何れも更新されておらず、図４（ｂ）と同じ値になっている。

データ番号「ＢＢＢ」のレコードは、そのグループ内に含まれる１つ目のトランザクションが２回目のバッチ処理でも異常終了したこと、エラー種別が“バッチ処理の続行が可能なエラー”であることを示している。また、リカバリ処理が行われているので、リトライ回数は「１」にインクリメントされている。データ番号「ＤＤＤ」のレコードは、そのグループ内に含まれる２つ目のトランザクションが異常終了したこと、エラー種別が“バッチ処理の続行が可能なエラー”であることを示している。

データ番号「ＥＥＥ」のレコードは、そのグループ内に含まれる３つのトランザクションが全て正常に終了したことを示している。同様に、データ番号「ＦＦＦ」のレコードは、そのグループ内に含まれる２つのトランザクションが全て正常に終了したことを示している。データ番号「ＤＤＤ」でトランザクションの異常終了が発生したものの、その原因となったエラーが“バッチ処理の続行が可能なエラー”であったために、その後のデータ番号「ＥＥＥ」および「ＦＦＦ」についてトランザクションの処理が実行され、その結果として全てのトランザクションが正常に終了したものである。

図４（ｃ）のようにバッチ処理結果管理テーブルが記憶されている場合、データ取得部２１は、データ番号「ＤＤＤ」「ＧＧＧ」「ＨＨＨ」「ＩＩＩ」の４つのレコードを取得してメモリ部１８に格納する。そして、トランザクション実行部２２は、メモリ部１８に格納された４つのレコードに関するバッチ処理を、格納されたデータ番号の順番に従って実行していく。

ここで、データ番号「ＡＡＡ」「ＥＥＥ」「ＦＦＦ」の３つのレコードを処理対象から外しているのは、既に処理が完了しているからである。また、データ番号「ＣＣＣ」のレコードを処理対象から外しているのは、異常終了の原因となったエラーの種別がリカバリ対象となっていないからである。また、データ番号「ＢＢＢ」のレコードを処理対象から外しているのは、リトライ回数が規定回数に達しているためである。

次に、上記のように構成した本実施形態による情報処理端末２の動作の詳細について、フローチャートに沿って説明する。図５は、本実施形態による情報処理端末２の動作例を示すフローチャートである。なお、図５のフローチャートは、１回のバッチ処理の動作を示している。

図５において、バッチスケジュール制御部１６は、タイマ部１７により測定される時間に基づいて、前回のバッチ処理実行時から一定の時間が経過したことを検知したとき、バッチ処理の起動命令をバッチ処理部１５に出力する（ステップＳ１）。バッチ処理部１５は、この起動命令を受けて、以下に述べるバッチ処理を実行する。

まず、データ取得部２１は、バッチ処理結果管理テーブル記憶部１４に記憶されているバッチ処理結果管理テーブルから、今回のバッチ処理で処理対象となるレコードのデータを取得してメモリ部１８に格納する（ステップＳ２）。ここでは上述したように、バッチ処理結果管理テーブルの処理ステータス、エラー種別およびリトライ回数を参照し、処理ステータスが“未処理”となっているレコードのデータを新たな処理対象として取得するとともに、処理ステータスが“異常終了”となっているレコードのうちリトライ回数がエラー種別に応じてあらかじめ定められた規定回数より少なくなっているレコードのデータをリカバリ対象として取得する。

次に、トランザクション実行部２２は、メモリ部１８に格納された処理対象のデータが存在するか否かを判定する（ステップＳ３）。処理対象のデータが存在しなければ、今回のバッチ処理を終了する。一方、処理対象のデータが存在する場合、トランザクション実行部２２は、メモリ部１８に記憶されている１つのレコード（最初は１つ目のデータ番号のレコード）を参照して、処理ステータスが“未処理”であるか否かを判定する（ステップＳ４）。以下、現在参照しているレコードを「処理対象レコード」という。

処理対象レコードの処理ステータスが“未処理”であった場合、トランザクション実行部２２は、その処理ステータスを“処理中”に書き換えた後（ステップＳ５）、処理対象レコードのデータ番号の内部処理、すなわちトランザクションの実行処理を行う（ステップＳ６）。この場合は、処理対象レコードのデータ番号で示されるグループ内の先頭のトランザクションから処理を開始する。具体的には、データ取得部２１は、メモリ部１８に格納されたデータ番号で示されるトランザクションの実体（予約データ）を実行トランザクション管理テーブル記憶部１３から取得し、メモリ部１８に格納する。そして、当該取得したトランザクションをサーバ装置１へ投入して実行させる。

一方、処理ステータスが“未処理”でなかった場合は、処理ステータスはリカバリ対象となる“異常終了”または“処理中”ということなので（処理ステータスが“処理済”のものはステップＳ２でデータ取得の対象外となっている）、トランザクション実行部２２は、処理対象レコードについてバッチ処理結果管理テーブルのリトライ回数をインクリメントする（ステップＳ７）。その後、リカバリ制御部２２ａは、メモリ部１８に格納されている処理対象レコードの内部処理番号を参照して、今回のリカバリ処理で実行を開始するトランザクションを特定する（ステップＳ８）。そして、トランザクション実行部２２は、バッチ処理結果管理テーブルの処理ステータスを“処理中”に書き換えた後（ステップＳ５）、ステップＳ８で特定されたトランザクション、すなわち、内部処理番号の次のトランザクションから内部処理を行う（ステップＳ６）。

トランザクション実行部２２の終了判定部２２ｂは、実行されたトランザクションが正常に終了したか否かを判定する（ステップＳ９）。ここで、終了判定部２２ｂは、トランザクションが正常に終了したと判断した場合、処理対象レコードについてバッチ処理結果管理テーブルの内部処理番号をインクリメントする（ステップＳ１０）。続いて、トランザクション実行部２２は、処理対象レコードのデータ番号で示されるグループ内に後続のトランザクションが存在するか否かを判定する（ステップＳ１１）。

ここで、後続のトランザクションが存在する場合はステップＳ６に戻り、当該処理対象レコードの処理を続ける。一方、後続のトランザクションが存在しない場合、トランザクション実行部２２は、処理対象レコードについてバッチ処理結果管理テーブルの処理ステータスを“処理済”に更新する（ステップＳ１２）。その後、ステップＳ３の処理に戻り、メモリ部１８に格納されている次のレコードを処理対象レコードとして、以上と同様の処理を行う。

上記ステップＳ９において、トランザクションが正常に終了していない、つまり異常終了したと終了判定部２２ｂにて判断した場合、エラー種別判定部２２ｃは、異常終了の原因となったエラーが“バッチ処理の続行が可能なエラー”であるか否かを判定する（ステップＳ１３）。ここで、バッチ処理の続行が可能なエラーであった場合は、トランザクション実行部２２は、処理対象レコードについてバッチ処理結果管理テーブルの処理ステータスを“異常終了”に更新するとともに、エラー種別を“バッチ処理の続行が可能なエラー”にする（ステップＳ１４）。その後、ステップＳ３の処理に戻り、メモリ部１８に格納されている次のレコードを処理対象レコードとして、以上と同様の処理を行う。

一方、バッチ処理の続行が不可能なエラーであった場合は、トランザクション実行部２２は、処理対象レコードについてバッチ処理結果管理テーブルの処理ステータスを“異常終了”に更新するとともに、エラー種別を“バッチ処理の続行が不可能なエラー”にして（ステップＳ１５）、今回のバッチ処理を終了する。なお、バッチ処理の続行が不可能なエラーのうち、情報処理端末２のフリーズやダウンが発生した場合、実際にはステップＳ１３、Ｓ１５の処理を行う間もなくバッチ処理が強制終了してしまう。その場合には上述したように、バッチ処理結果管理テーブルの処理ステータスは“処理中”のままであり、エラー種別は初期値の「０」のままである。

以上詳しく説明したように、本実施形態では、バッチ処理の実行結果を管理する情報として、従来の処理ステータスおよび内部処理番号に加えて、エラー種別およびリトライ回数をバッチ処理のデータ番号に関連付けてバッチ処理結果管理テーブルに記録する。そして、リトライ回数がエラー種別に応じてあらかじめ定められた規定回数より少なくなっているデータ番号を対象として、内部処理番号の次のトランザクションからリカバリ処理を開始するようにしている。

このため、途中のトランザクションで異常終了となったグループ（データ番号）のバッチ処理が何度も繰り返しリカバリ処理の対象となることはなく、リトライ回数が規定回数より少なくなっているグループのバッチ処理のみがリカバリ処理の対象となる。しかも、リトライ回数の上限を決める規定回数がエラー種別に応じて定められているので、エラー種別に応じて適切な回数だけリカバリ処理を実行することができる。これにより、リカバリ処理が無駄に何度も繰り返し行われる不都合を解消することができる。

また、本実施形態では、あるグループのトランザクションを実行している時に処理続行が不可能なエラーが発生した場合には、バッチ処理を終了する。一方、あるグループのトランザクションの実行時に処理続行が可能なエラーが発生した場合には、当該グループについてはリカバリ対象として処理を中断した上で、次のグループのトランザクションを引き続き実行するようにしている。

このため、あるグループのバッチ処理に関するトランザクションの実行時に発生したエラーが、処理の続行が可能なエラーである場合には、当該グループのバッチ処理は異常終了（次回のリカバリ対象）としつつも、他のグループのバッチ処理に関するトランザクションを引き続き実行することができる。よって、バッチ処理の途中でトランザクションが異常終了した場合にそれ以降のトランザクションは処理せずに直ちにバッチ処理を終了していた従来技術とは異なり、異常終了が発生したトランザクション以降のトランザクションについても、今回のバッチ処理の中で可能な限り処理を進めることができる。

特に、本実施形態の場合は、バッチ処理の途中で異常終了が発生しても、今回のバッチ処理で続行できるトランザクションはできる限り処理を行い、仮にリカバリ対象として次回のバッチ処理に回れたとしても、そのトランザクションについて行うリカバリ処理は１回のみに限定される。これにより、リカバリ処理が繰り返し行われて未処理のトランザクションがどんどん増えてしまう不都合を効率よく解消することができる。

なお、上記実施形態において、バッチ処理の途中でトランザクションが異常終了した場合に、処理の続行が可能なエラーである場合には、それ以降のトランザクションについても処理を続行する例について説明した。これが好ましい実施形態ではあるが、必ずしも必須の構成ではない。すなわち、このような構成を採用しない場合であっても、あるレコードのリトライ回数が上限の規定回数を超えていればリカバリ対象から外されるので、次のレコードに関するバッチ処理が実行され、未処理のまま残っていたトランザクションの処理が進められていくこととなる。したがって、あるレコードのリカバリ処理が何度も繰り返されて、その都度異常終了するために次のレコードに進めないという事態を回避することができる。これにより、あるレコードに関するリカバリ処理が繰り返し行われて未処理のトランザクションがどんどん増えてしまう不都合を解消することができる。

また、上記実施形態では、バッチ処理の対象となる複数のトランザクションをグループ単位（一顧客の予約単位）で管理するようにしている。すなわち、バッチ処理結果管理テーブルにおいて、データ番号を主キーとして処理ステータス、エラー種別、内部処理番号およびリトライ回数を管理する構成としている。しかし、本発明はこの例に限定されない。例えば、バッチ処理の対象となる複数のトランザクションを個別に管理するようにしても良い。この場合、全てのトランザクションを含むグループが１つだけ存在することに相当する。

この場合は、例えばバッチ処理結果管理テーブルの主キーとして、個々のトランザクションをユニークに識別可能なトランザクション番号をデータ番号の代わりに使用する。また、上記実施形態で内部処理番号はグループ内のバッチ処理でどのトランザクションまで処理が成功したかを表すものであった。これに対し、上記変形例においては、バッチ処理全体の中のどのトランザクションまで処理が成功したかを表すのが内部処理番号となる。

また、エラー種別に応じてリトライ回数の上限値が決まるが、エラー種別によらず（すなわち、処理の続行が可能なエラーであっても）、異常終了の発生時点でバッチ処理は終了する。なお、発生したエラーが“処理の続行が可能なエラー”であった場合には、異常終了したトランザクション自体はリカバリ対象とするものの、その次のトランザクションから処理を続行するようにしても良い。このようにすると、一定時間後のリカバリ処理で実行されるトランザクションは、異常終了したトランザクション自体のみとなる。

また、上記実施形態では、図４に例示したように、トランザクション登録処理部１２により登録されたトランザクションが随時蓄積されていく例について説明したが、本発明はこれに限定されない。例えば、バッチ処理の対象外（データ取得部２１による取得対象外）のレコードについては、バッチ処理結果管理テーブルから消去するようにしても良い。

また、上記実施形態では、エラー種別が“バッチ処理の続行が可能なエラー”と“バッチ処理の続行が不可能なエラー”との２種類であるものとして説明したが、本発明はこれに限定されない。例えば、情報処理端末２のフリーズ、ダウン、ハードウェア障害、あるいは、情報処理端末２とサーバ装置１との間で行う通信のタイムアウト、サーバ装置１による排他制御、データ不具合などの各種エラーをエラー種別としてバッチ処理結果管理テーブルに登録し、これらのエラー種別に応じてリトライ回数の上限値を変えるようにしても良い。

その他、上記実施形態は、本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

１Ａ，１Ｂ，１Ｃ サーバ装置
２ 情報処理端末
３ 通信ネットワーク
１３ 実行トランザクション管理テーブル記憶部
１４ バッチ処理結果管理テーブル記憶部
１５ バッチ処理部
１８ メモリ部
２１ データ取得部
２２ トランザクション実行部
２２ａ リカバリ制御部
２２ｂ 終了判定部
２２ｃ エラー種別判定部

Claims (5)

1. 各々がバッチ処理のトランザクションを実行する複数台の処理用コンピュータと、上記トランザクションのスケジューリングおよび当該スケジューリングしたトランザクションの上記処理用コンピュータへの投入を行う投入用コンピュータとが通信ネットワークにより接続されて構成されるバッチ処理システムであって、上記投入用コンピュータが、
   上記バッチ処理が途中のトランザクションで異常終了したか否かを判定する終了判定部と、
   上記終了判定部により上記バッチ処理が異常終了したと判定された場合に、異常終了した原因であるエラーの種別を判定するエラー種別判定部と、
   上記終了判定部による判定結果を表す処理ステータス、上記エラー種別判定部による判定結果を表すエラー種別、上記バッチ処理のどのトランザクションまで成功したかを表す内部処理番号、および上記異常終了後のリカバリ処理の実行回数を表すリトライ回数をバッチ処理結果管理テーブルとして記憶するテーブル情報記憶部と、
   上記バッチ処理結果管理テーブルに記憶されたデータに基づいて上記リカバリ処理の実行を制御するリカバリ制御部とを備え、
   上記リカバリ制御部は、上記エラー種別に応じてあらかじめ定められた規定回数より上記リトライ回数が少なくなっているバッチ処理について、上記内部処理番号の次のトランザクションからリカバリ処理を開始するように制御することを特徴とするバッチ処理システム。
2. バッチ処理の複数のトランザクションをスケジューリングするとともに、スケジューリングしたトランザクションの各々を複数台の処理用コンピュータに投入して実行させる情報処理端末であって、
   上記バッチ処理が途中のトランザクションで異常終了したか否かを判定する終了判定部と、
   上記終了判定部により上記バッチ処理が異常終了したと判定された場合に、異常終了した原因であるエラーの種別を判定するエラー種別判定部と、
   上記終了判定部による判定結果を表す処理ステータス、上記エラー種別判定部による判定結果を表すエラー種別、上記バッチ処理のどのトランザクションまで成功したかを表す内部処理番号、および上記異常終了後のリカバリ処理の実行回数を表すリトライ回数をバッチ処理結果管理テーブルとして記憶するテーブル情報記憶部と、
   上記バッチ処理結果管理テーブルに記憶されたデータに基づいて上記リカバリ処理の実行を制御するリカバリ制御部とを備え、
   上記リカバリ制御部は、上記リトライ回数が上記エラー種別に応じてあらかじめ定められた規定回数より少なくなっているバッチ処理について、上記内部処理番号の次のトランザクションからリカバリ処理を開始するように制御することを特徴とする情報処理端末。
3. 上記バッチ処理は、１以上のトランザクションを含む所定単位のグループに関するバッチ処理である小バッチ処理の集合から成り、
   上記テーブル情報記憶部は、上記処理ステータス、上記エラー種別、上記内部処理番号および上記リトライ回数をバッチ処理結果管理テーブルにおいて上記グループ毎に記憶し、
   上記終了判定部は、上記小バッチ処理が途中のトランザクションで異常終了したか否かを上記グループ毎に判定し、
   上記エラー種別判定部は、上記終了判定部により上記小バッチ処理が異常終了したと判定された場合に、異常終了した原因であるエラーの種別を判定し、
   上記リカバリ制御部は、上記エラー種別に応じてあらかじめ定められた規定回数より上記リトライ回数が少なくなっているグループの小バッチ処理について、上記内部処理番号の次のトランザクションからリカバリ処理を開始するように制御することを特徴とする請求項２に記載の情報処理端末。
4. あるグループに関する小バッチ処理の実行時に上記エラー種別判定部により処理続行が不可能なエラーが発生したと判定された場合には、上記バッチ処理を終了し、上記あるグループに関する小バッチ処理の実行時に上記エラー種別判定部により処理続行が可能なエラーが発生したと判定された場合には、上記あるグループに関する小バッチ処理の実行を中断して他のグループに関する小バッチ処理を実行するように制御することを特徴とする請求項３に記載の情報処理端末。
5. 各々がバッチ処理のトランザクションを実行する複数台の処理用コンピュータと、上記トランザクションのスケジューリングおよび上記処理用コンピュータへの投入を行う投入用コンピュータとが通信ネットワークにより接続されて構成されるバッチ処理システムにおいて、上記バッチ処理の実行過程でトランザクションの異常終了が発生した場合にリカバリ処理を行うバッチ処理のリカバリ方法であって、
   上記投入用コンピュータが、上記バッチ処理の進捗状況を表す処理ステータス、上記バッチ処理が異常終了した場合の原因を表すエラー種別、上記バッチ処理のどのトランザクションまで成功したかを表す内部処理番号、および上記異常終了後のリカバリ処理の実行回数を表すリトライ回数がバッチ処理の処理単位であるグループ毎に関連付けて記憶されているバッチ処理結果管理テーブルを参照して、上記処理ステータスが未処理となっているグループを新たな処理対象として取得するとともに、上記処理ステータスが異常終了となっているグループのうち上記リトライ回数が上記エラー種別に応じてあらかじめ定められた規定回数より少なくなっているグループをリカバリ対象として取得する第１のステップと、
   上記第１のステップで取得した１以上のグループについて、当該グループに含まれるトランザクションを上記投入用コンピュータが順次上記処理用コンピュータへ投入して実行させる第２のステップと、
   上記投入用コンピュータが、上記リカバリ対象のグループについて上記バッチ処理結果管理テーブルの上記リトライ回数を更新する第３のステップと、
   上記第２のステップで上記処理用コンピュータが上記トランザクションを実行している過程で、上記グループ毎に最後のトランザクションまで正常終了したか途中のトランザクションで異常終了したかを上記投入用コンピュータが判定する第４のステップと、
   上記第４のステップで上記異常終了が発生したと判定された場合に、異常終了した原因であるエラーの種別を上記投入用コンピュータが判定する第５のステップと、
   上記第４のステップおよび上記第５のステップでの判定結果に基づいて、上記投入用コンピュータが、上記バッチ処理結果管理テーブルの上記処理ステータス、上記エラー種別および上記内部処理番号を更新する第６のステップとを有するバッチ処理のリカバリ方法。

Images