JP2016189101A - バッチ処理システム、バッチ処理方法、バッチ処理プログラムおよびバッチ処理プログラムが記憶されたコンピュータで読み取り可能な記憶媒体 - Google Patents

Abstract

【課題】 バッチプログラムの処理の進捗を把握することができ、処理時間が長期化した場合であっても、その後の対応作業を迅速に実施することができるバッチ処理システムを提供する。
【解決手段】 処理状況収集部７では、実行中のバッチプログラム１１における処理の処理状況１２を送信させるためのＡＰＩが定められ、ＡＰＩに基づいて処理状況１２が処理状況収集部７に収集される。処理状況照会部８では、実行バッチプログラムの処理よりも前に終了した先行終了バッチプログラムの処理状況１２に基づいて、実行バッチプログラムの予測終了時刻が算出される。
【選択図】 図２

Description

本発明は、バッチプログラムによる処理の進捗を監視するバッチ処理システム、バッチ処理方法、バッチ処理プログラムおよびバッチ処理プログラムが記憶されたコンピュータで読み取り可能な記憶媒体に関するものである。

従来、バッチ処理によれば、大量のデータを一括して処理することができるが、例えば、コンピュータ・リソースの不足、ハードウェアの不調、バッチプログラムのアボードや処理の長期化などが生じる場合がある。バッチプログラムの処理の長期化の原因は様々であり、例えば、データ量の急激な増加や、レスポンスの低下、バッチプログラムの実行状態を記憶する記憶装置の障害などが考えられるが、その場合、後続のバッチプログラムのスケジュール調整や、関連部署への連絡など、対応作業を要する。

そこで、バッチプログラムの処理時間の長期化を防ぐためにバッチ処理を監視するものとして、例えば下記特許文献１に記載されたバッチ処理監視システムがある。このバッチ処理監視システムによれば、所定単位の処理が正常に完了する毎に、記憶装置にバッチプログラムの実行状態が記録されるが、冗長化などによって記憶装置の稼働状態が低下した場合、記録方法が変更され、エラー発生時にのみバッチプログラムの実行状態が記憶装置に記録されるようになる。記憶装置への記録がエラー発生時のみであれば、処理が完了する毎に記憶装置に記録する場合と比べて、記憶装置へのアクセス頻度が低いため、記憶装置の障害を回避し、結果としてバッチプログラムの処理時間の長期化を防止することができる。

特開２０１３−１９６２３８号公報

しかし、上記したバッチ処理監視システムでは、バッチプログラムの実行状態を記録する方法を変更することで、記憶装置の障害を回避し、バッチプログラムの処理時間の長期化を防止するものであるため、記憶装置の障害以外の様々な原因によって仮に処理時間が長期化した場合、その後の対応作業を要する。

本発明は、上記の実情に鑑みて提案されたものである。すなわち、バッチプログラムの処理の進捗を把握することができ、仮に処理時間が長期化した場合であっても、その後の対応作業を迅速に実施することができるバッチ処理システム、バッチ処理方法、バッチ処理プログラムおよびバッチ処理プログラムが記憶されたコンピュータで読み取り可能な記憶媒体の提供を目的とする。

上記目的を達成するために、本発明に係るバッチ処理システムは、実行中のバッチプログラムにおける処理の処理状況を送信させるための規則が定められた処理状況収集部が備えられ、前記規則に基づいて前記処理状況が前記処理状況収集部に収集される、ことを特徴とする。

本発明に係るバッチ処理システムは、前記処理状況が、前記バッチプログラムによる処理の開始情報である開始処理状況、前記バッチプログラムによる処理の経過情報である経過処理状況、前記バッチプログラムによる処理の終了情報である終了処理状況である、ことを特徴とする。

本発明に係るバッチ処理システムは、前記規則に、前記バッチプログラムによる処理の開始後に前記開始処理状況を送信させ、前記経過処理状況を送信するためのスケジューリングを実行する開始ＡＰＩと、前記バッチプログラムによる処理の終了前に前記終了処理状況を送信させる終了ＡＰＩと、が含まれた、ことを特徴とする。

本発明に係るバッチ処理システムは、前記規則に、前記処理の処理済み件数をカウントする処理済み件数インクリメントＡＰＩが含まれ、前記処理状況に前記処理済み件数が含まれた、ことを特徴とする。

本発明に係るバッチ処理システムは、前記規則に、前記処理済み件数インクリメントＡＰＩでカウントされた前記処理の他の任意の処理の処理済み件数をカウントする任意処理済み件数インクリメントＡＰＩが含まれ、前記処理状況に前記任意の処理の処理済み件数が含まれた、ことを特徴とする。

本発明に係るバッチ処理システムは、前記処理状況収集部にリソース状況が収集される、ことを特徴とする。

本発明に係るバッチ処理システムは、実行中の前記バッチプログラムである実行バッチプログラムの前記処理よりも前に終了したバッチプログラムである先行終了バッチプログラムの前記終了処理状況に基づいて、前記実行バッチプログラムの予測終了時刻を算出する処理状況照会部が備えられた、ことを特徴とする。

本発明に係るバッチ処理システムは、前記処理の処理済み件数および前記経過処理状況の送信時刻である送信時現在時刻が、前記経過処理状況および前記終了処理状況に含まれ、
前記経過処理状況ごとに更新されて増加した前記処理済み件数である増加件数、および、前記経過処理状況ごとに更新されて経過した前記送信時現在時刻である経過時間を、前記経過処理状況および前記終了処理状況と関連付けて記憶する記憶部が備えられ、
前記処理状況照会部が、
前記先行終了バッチプログラムの処理済み件数と前記実行バッチプログラムの処理済み件数とから、前記実行バッチプログラムの残り件数を算出し、前記実行バッチプログラムの残り件数と、前記実行バッチプログラムの増加件数と、前記実行バッチプログラムの経過時間とから、前記実行バッチプログラムにおける前記処理が終了するまでの残り処理時間を算出し、前記実行バッチプログラムの残り処理時間と、前記実行バッチプログラムの送信時現在時刻とから、前記実行バッチプログラムの予測終了時刻を算出する、ことを特徴とする。

本発明に係るバッチ処理方法は、バッチプログラムにおける処理の実行中に、前記バッチプログラムの処理状況を送信させるための規則に基づいて、前記処理状況を処理状況収集部に収集する手順を含む、ことを特徴とする。

本発明に係るバッチ処理プログラムは、バッチプログラムにおける処理の処理状況を送信するための規則が定められた処理状況収集部が備えられ、前記バッチプログラムにおける処理の実行中に、前記規則に基づいて前記処理状況を前記処理状況収集部に収集させる手順をコンピュータに実行させる、ことを特徴とする。

本発明に係るコンピュータで読み取り可能な記憶媒体は、バッチ処理プログラムが記憶された、ことを特徴とする。

本発明に係るバッチ処理システムは上記した構成である。すなわち、処理状況収集部で定められた規則は、実行中のバッチプログラムの処理状況を送信させるものであるため、バッチプログラムの処理の進捗を把握することができ、仮に処理時間が長期化した場合であっても、その後の対応作業を迅速に実施することができる。

本発明に係るバッチ処理システムは、処理状況が、バッチプログラムによる処理の開始情報である開始処理状況、バッチプログラムによる処理の経過情報である経過処理状況、バッチプログラムによる処理の終了情報である終了処理状況である。この構成により、三種類の処理状況が収集される。したがって、バッチプログラムの処理の詳細な進捗を把握することができる。

本発明に係るバッチ処理システムは、規則に、バッチプログラムによる処理の開始後に開始処理状況を送信させ、経過処理状況を送信するためのスケジューリングを実行する開始ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）と、バッチプログラムによる処理の終了前に終了処理状況を送信させる終了ＡＰＩと、処理の処理済み件数をカウントする処理済み件数インクリメントＡＰＩとが含まれ、処理状況に処理済み件数が含まれている。この構成により、各ＡＰＩが、バッチプログラムの所定の箇所で呼び出され、各処理状況が送信される。したがって、各処理状況を送信することを意識せずにバッチプログラムを設計することができる。また、処理状況に処理済み件数が含まれているため、バッチプログラムの処理の詳細な進捗を把握することができる。

本発明に係るバッチ処理システムは、規則に、処理済み件数インクリメントＡＰＩでカウントされた処理の他の任意の処理の処理済み件数をカウントする任意処理済み件数インクリメントＡＰＩが含まれ、処理状況に任意の処理の処理済み件数が含まれている。この構成により、例えば、バッチプログラムにおける処理として複数の処理がある場合、そのうちの任意の処理の件数をカウントすることができる。したがって、バッチプログラムの処理の詳細な進捗を把握することができる。

本発明に係るバッチ処理システムは、処理状況収集部にリソース状況が収集される。したがって、リソース状況を把握することができ、仮に不具合が発生した場合であっても、その後の対応作業を迅速に実施することができる。

本発明に係るバッチ処理システムは、実行中のバッチプログラムである実行バッチプログラムの処理よりも前に終了したバッチプログラムである先行終了バッチプログラムの終了処理状況に基づいて、実行バッチプログラムの予測終了時刻を算出する処理状況照会部が備えられている。詳説すれば、処理の処理済み件数および経過処理状況の送信時刻である送信時現在時刻が、経過処理状況および終了処理状況に含まれ、経過処理状況ごとに更新されて増加した処理済み件数である増加件数、および、経過処理状況ごとに更新されて経過した送信時現在時刻である経過時間を、経過処理状況および終了処理状況と関連付けて記憶する記憶部が備えられ、処理状況照会部が、先行終了バッチプログラムの処理済み件数と実行バッチプログラムの処理済み件数とから、実行バッチプログラムの残り件数を算出し、実行バッチプログラムの残り件数と、実行バッチプログラムの増加件数と、実行バッチプログラムの経過時間とから、実行バッチプログラムにおける処理が終了するまでの残り処理時間を算出し、実行バッチプログラムの残り処理時間と、実行バッチプログラムの送信時現在時刻とから、実行バッチプログラムの予測終了時刻を算出する。したがって、実行中のバッチプログラムの終了時刻を予測することができ、仮に処理時間が長期化した場合であっても、その後の対応作業を迅速に実施することができる。

本発明に係るバッチ処理方法、バッチ処理プログラムおよび記録媒体は、上記したバッチ処理システムと同じ効果を生じさせることができる。

本発明の実施形態に係るバッチ処理システムのハードウェア構成図である。 本発明の実施形態に係るバッチ処理システムのシステム構成の概略が示されたシステム構概略成図である。 本発明の実施形態に係るバッチ処理システムの処理状況が示された処理状況説明図である。 本発明の実施形態に係るバッチ処理システムにおいて加工された処理状況が示された加工処理状況説明図である。 本発明の実施形態に係るバッチ処理システムのＡＰＩの一覧が示されたＡＰＩ説明図である。 本発明の実施形態に係るバッチ処理システムの開始ＡＰＩの書式が示された開始ＡＰＩ書式説明図である。 本発明の実施形態に係るバッチ処理システムの開始処理状況が示された開始処理状況説明図である。 本発明の実施形態に係るバッチ処理システムの経過処理状況が示された経過処理状況説明図である。 本発明の実施形態に係るバッチ処理システムの入力済み件数インクリメントＡＰＩの書式が示された入力済み件数インクリメントＡＰＩ書式説明図である。 本発明の実施形態に係るバッチ処理システムの任意入力済み件数インクリメントＡＰＩの書式が示された任意入力済み件数インクリメントＡＰＩ書式説明図である。 本発明の実施形態に係るバッチ処理システムの終了ＡＰＩの書式が示された終了ＡＰＩ書式説明図である。 本発明の実施形態に係るバッチ処理システムの終了処理状況が示された終了処理状況説明図である。 本発明の実施形態に係るバッチ処理システムのバッチプログラムの一例が示され、（ａ）がバッチプログラムの概略図、（ｂ）がバッチプログラムによる処理の流れが示されたフロー図である。 本発明の実施形態に係るバッチ処理システムのＡＰＩの呼出し箇所が示されたＡＰＩの呼出し箇所説明図である。 本発明の実施形態に係るバッチ処理システムのリソース状況が示されたリソース状況説明図である。 本発明の実施形態に係るバッチ処理システムにおいて加工されたリソース状況が示された加工リソース状況説明図である。 本発明の実施形態に係るバッチ処理システムに備えられた機能の項目が示された機能説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部の画面遷移が示された画面遷移図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による処理の条件が示された処理条件説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示形式が示された表示形式説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示され、（ａ）が表示画面図であり、（ｂ）が画面説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部の画面遷移が示された画面遷移図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による処理の条件が示された処理条件説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示形式が示された表示形式説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示され、（ａ）が表示画面図であり、（ｂ）が画面説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムのバッチプログラムの一例が示された概略図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示さた表示画面図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。 本発明の実施形態に係るバッチ処理システムの処理状況照会部による表示例が示された表示例説明図である。

以下に、本発明の実施形態に係るバッチ処理システムを図面に基づいて説明する。図１は、本実施形態に係るバッチ処理システム１０を実現するためのハードウェアの一般的な構成が示されている。

図１に示されているとおり、バッチ処理システム１０は、少なくとも記憶部２、入力部６、出力部９、制御部（図示省略）などが備えられている。記憶部２は、ＲＯＭ３、ＲＡＭ４、ＨＤＤ５から構成される。入力部６は、例えば、キーボード、マウス、タッチパネルなどから構成され、また、出力部９は、例えば、液晶ディスプレイなどから構成される。制御部はＣＰＵ１などにより実現され、入力部６からの入力情報を検出すると共に、ＲＯＭ３に格納されたプログラムに従って、ＣＰＵ１に実行させるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のプログラムやアプリケーションプログラムの一部が格納されたＲＡＭ４を使用して処理状況収集部７および処理状況照会部８を制御し、入力情報の処理結果を出力部９に出力する。

バッチ処理システム１０は、ハードウェア構成、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ソフトウェアによって実現することが可能である。例えば、ソフトウェアによって実現する場合、実際にはコンピュータのＣＰＵ１、あるいはＭＰＵ、ＲＯＭ３、ＲＡＭ４などを備えて構成し、ＲＯＭ３やＲＡＭ４に記憶されたプログラムが動作することによって実現できる。

したがって、コンピュータが処理状況収集部７および処理状況照会部８の機能を果たすように動作させるバッチ処理プログラムを、例えばＣＤ−ＲＯＭなどの記録媒体に記録し、コンピュータに読み込ませることによって実現できる。バッチ処理プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、例えばフレキシブルディスク、光ディスクなどを用いることができる。

バッチ処理システム１０は、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）として機能させてもよく、バッチ処理プログラムをインターネットなどのネットワークを介してコンピュータにダウンロードすることによっても実現できる。さらに、これらのハードウェア、ソフトウェア資源を、ネットワークを介してアクセス可能なクラウドなどの態様で提供することもできる。

次に、バッチ処理システム１０の全体構成を図面に基づいて説明する。図２は、本実施形態に係るバッチ処理システム１０の全体のシステム構成の概略が示されている。バッチ処理システム１０は、本発明に係るバッチ処理方法およびバッチ処理プログラムを実現する。

＜バッチ処理システム＞
図２に示されているとおり、バッチ処理システム１０は、処理状況収集部７および処理状況照会部８が備えられている。処理状況収集部７は、実行中のバッチプログラム１１の処理状況１２を送信させるための規則としてのＡＰＩが定められている。端末で実行されるバッチプログラム１１の処理状況１２は、ＡＰＩに基づいて、ネットワークを通じて処理状況収集部７で受信され、収集される。収集された処理状況１２は、記憶部２に記憶される。処理状況照会部８は、記憶部２に記憶された処理状況１２を、利用者の端末２０から要求された照会の抽出条件１８に基づいて抽出し、抽出結果１９として利用者の端末２０に照会する。その際、実行中のバッチプログラムの終了時刻を予測し、予測終了時刻を算出する。なお、処理状況収集部７および処理状況照会部８に関し、ひとつのシステムに実装されて構成されるか、ネットワークなどで接続された複数のシステムから構成されるかは任意である。

端末は、例えばパーソナルコンピュータ、ワークステーション、タブレット端末、スマートフォン、通信ネットワークに接続可能なテレビ端末などである。ネットワークは、例えばインターネット、専用線により接続されたネットワーク、企業内ＬＡＮ、企業間ＬＡＮ、ＷＡＮなどである。通信回線の形態は、例えば有線通信、無線通信、衛星通信などである。処理状況１２の送受信における通信プロトコルは、例えば、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）などである。

＜処理状況収集部＞
まず、処理状況収集部７について説明する。図２に示されているとおり、処理状況収集部７は、例えば、処理状況収集機能を有するサーバーなどによって実現され、ＡＰＩを通じてバッチプログラム１１の実行中に処理状況１２を収集する。処理状況１２は、バッチプログラム１１による処理の開始情報である開始処理状況、処理の経過情報である経過処理状況、処理の終了情報である終了処理状況がある。受信された各処理状況１２は、受信される度に各処理状況１２ごとに更新され、さらに、利用者の端末２０への照会用に加工され、最新情報１３および累積情報１４として出力される。最新情報１３はメモリに格納され、各処理状況１２が受信される度にバッチプログラム１１ごとに上書きされて記憶される。累積情報１４はディスクに格納され、受信された各処理状況１２の全てが記憶される。

処理状況収集部７は、エージェントプラグラム１５が端末にインストールされている場合、バッチプログラム１１の実行中に、リソース状況１６を収集する。また、処理状況収集部７は、処理状況１２を所定の閾値と比較し、その結果に応じてアラームを通知する。リソース状況１６およびアラーム通知機能（図示省略）については後述する。

次に、処理状況１２、最新情報１３および累積情報１４の詳細を図面に基づいて説明する。図３は、本実施形態に係るバッチ処理システム１０の処理状況１２の内容が示され、図４は、最新情報１３および累積情報１４の内容が示されている。

＜処理状況＞
処理状況１２は、バッチプログラム１１の進捗情報であり、図３に示されているとおり、項目として「バッチプログラム名」「開始時刻」「送信時現在時刻」「データ区分」「入力済み件数」「オプション件数０〜９９」が設定されている。

「バッチプログラム名」は、バッチプログラム１１を識別するための一意の名称であり、同じバッチプログラム１１が平行して実行される場合は、並列番号などが付加されて識別される。「開始時刻」は、バッチプログラム１１が実行されて処理が開始された時刻である。「送信時現在時刻」は、処理状況１２を送信した送信時刻である。「データ区分」は、処理状況１２の区分であり、「開始」「経過」「終了」の三種類がある。すなわち、データ区分に応じて、処理状況１２は、開始処理状況、経過処理状況および終了処理状況がある。「入力済み件数」は、バッチプログラム１１が処理状況１２を送信する時点における入力データの読み込み件数である。「オプション件数０〜９９」は、バッチプログラム１１が処理状況１２を送信する時点において、バッチプログラム１１における処理のうち、「入力済み件数」における処理の他の処理がある場合に、他の任意の処理の読み込み件数である。任意の処理は、必要に応じて、バッチプログラム１１ごとに最大１００個まで設定することができる。

＜最新情報、累積情報＞
最新情報１３および累積情報１４は、利用者の端末２０への照会用に処理状況１２が加工された情報であり、図４に示されているとおり、処理状況１２の項目に加え、「端末名」「増加件数」「経過時間」が設定されている。

「端末名」は、各処理状況１２の送信元の端末の名称であり、すなわち、バッチプログラム１１が実行されている端末の名称である。「増加件数」は、各処理状況１２が受信される度に上書きされて更新された「入力済み件数」の増加量である。すなわち、最新情報１３において各処理状況１２が更新される前の「入力済み件数」と、更新された後の「入力済み件数」との差である。「経過時間」は、各処理状況１２が受信される度に上書きされて更新された「送信時現在時刻」の経過時間である。すなわち、最新情報１３において各処理状況１２が更新される前の「送信時現在時刻」と、更新された後の「送信時現在時刻」との差である。

＜ＡＰＩ＞
次に、実行中のバッチプログラム１１の各処理状況１２を送信させるために処理状況収集部７で定められたＡＰＩの詳細を図面に基づいて説明する。ＡＰＩは、開始ＡＰＩ、入力済み件数インクリメントＡＰＩ、任意処理済み件数インクリメントＡＰＩとしてのオプション件数インクリメントＡＰＩおよび終了ＡＰＩが含まれている。図５は、本実施形態に係るバッチ処理システム１０のＡＰＩの一覧が示されている。図６は、本実施形態に係るバッチ処理システム１０の開始ＡＰＩの書式が示され、図７は、開始ＡＰＩが送信する開始処理状況の内容が示されている。図８は、本実施形態に係るバッチ処理システム１０の経過処理状況の内容が示されている。図９は、本実施形態に係るバッチ処理システム１０の入力済み件数インクリメントＡＰＩの書式が示されている。図１０は、本実施形態に係るバッチ処理システム１０のオプション件数インクリメントＡＰＩの書式が示されている。図１１は、本実施形態に係るバッチ処理システム１０の終了ＡＰＩの書式が示され、図１２は、終了ＡＰＩが送信する終了処理状況の内容が示されている。

＜開始ＡＰＩ＞
図５に示されているとおり、開始ＡＰＩでは、端末の作業領域の確保などの初期処理が実行された後、「データ区分」が「開始」である処理状況１２（開始処理状況）が送信される。また、開始ＡＰＩでは、経過処理状況を送信するためのスケジューリングが実行される。「データ区分」が「経過」である処理状況１２（経過処理状況）は、スケジュールに基づいて定期的に送信される。送信する間隔は任意である。

＜開始処理状況＞
図７に示されているとおり、開始処理状況の各項目の値は、処理状況１２の項目に則り、次のとおりである。「バッチプログラム名」は、開始ＡＰＩのパラメータ（図６参照）に則って「バッチプログラム名」が設定される。「開始時刻」は、開始ＡＰＩが呼び出された時刻が設定される。「送信時現在時刻」は、「開始時刻」と同時刻が設定される。「データ区分」は、「開始」が設定される。「入力済み件数」は、「０」が設定される。「オプション件数０〜９９」は、設定されない。

＜経過処理状況＞
図８に示されているとおり、経過処理状況の各項目の値は、処理状況１２の項目に則り、次のとおりである。「バッチプログラム名」は、開始ＡＰＩのパラメータ（図６参照）で指定された「バッチプログラム名」が設定される。「開始時刻」は、開始ＡＰＩが呼び出された時刻が設定される。「送信時現在時刻」は、経過処理状況が送信される時刻が設定される。「データ区分」は、「経過」が設定される。「入力済み件数」は、経過処理状況が送信される時点における入力済み件数が設定される。「オプション件数０〜９９」は、経過処理状況が送信される時点におけるオプション件数が設定される。

＜入力済み件数インクリメントＡＰＩ＞
図５に示されているとおり、入力済み件数インクリメントＡＰＩでは、端末の作業領域に保持された「入力済み件数」に“１”が加算される。なお、入力済み件数インクリメントＡＰＩでは、処理状況１２は送信されない。

＜オプション件数インクリメントＡＰＩ＞
図５に示されているとおり、オプション件数インクリメントＡＰＩでは、端末の作業領域に保持された「オプション件数」のうち、パラメータ（図１０参照）で指定されたオプション番号に対応する任意の処理の件数（処理済み件数インクリメントＡＰＩでカウントされた入力の他の任意の入出力の処理済み件数）に“１”が加算される。なお、オプション件数インクリメントＡＰＩでは、処理状況１２は送信されない。

＜終了ＡＰＩ＞
図５に示されているとおり、終了ＡＰＩでは、データ区分が「終了」である処理状況１２（終了処理状況）が送信され、端末の作業領域の開放などの終了処理が実行される。

＜終了処理状況＞
図１２に示されているとおり、終了処理状況の各項目の値は、処理状況１２の項目に則り、次のとおりである。「バッチプログラム名」は、開始ＡＰＩのパラメータに則って「バッチプログラム名」が設定される。「開始時刻」は、開始ＡＰＩが呼び出された時刻が設定される。「送信時現在時刻」は、終了処理状況が送信される時刻が設定される。「データ区分」は、「終了」が設定される。「入力済み件数」は、最終的な入力済み件数が設定される。「オプション件数０〜９９」は、最終的なオプション件数が設定される。

次に、開始ＡＰＩ、入力済み件数インクリメントＡＰＩ、オプション件数インクリメントＡＰＩ、終了ＡＰＩの呼出し手順を図面に基づいて説明する。図１３は、本実施形態に係るバッチ処理システム１０における各ＡＰＩの呼出し手順を説明するためのバッチプログラムａの概略と、処理の流れが示されている。図１４は、本実施形態に係るバッチ処理システム１０おける各ＡＰＩの呼出し箇所が示されている。なお、以下の説明のバッチプログラムａは一例であり、任意である。

図１３（ａ）において、バッチプログラムａは、データベースからデータａを読み込み、読み込んだデータをデータｂに書き込むものである。

図１３（ｂ）に示されているとおり、バッチプログラムａは、処理を開始し、ステップＳ１においてデータａから“１件”を読み込む。ステップＳ２において、“１件”を正しく読み込むことができたか否かを判定する。判定の結果、“１件”を正しく読み込むことができなかった場合、バッチプログラムａは処理を終了する。一方、“１件”を正しく読み込むことができた場合、ステップＳ３において、“１件”をデータｂに書き込むか否かを判定する。判定の結果、“１件”をデータｂに書き込む場合、ステップＳ４において“１件”をデータｂに書き込み、ステップＳ５に進む。また、“１件”をデータｂに書き込まない場合もステップＳ５に進む。ステップＳ５において、データａから次の“１件”を読み込み、ステップＳ２に戻る。

上記したバッチプログラムａにおける処理の流れにおいて、図１３および図１４に示されているとおり、開始ＡＰＩは、バッチプログラムａの開始直後（図１３（ｂ）における符号Ａ）に呼び出される。バッチプログラムａの処理の開始直後に共通的な処理がある場合は、その中から開始ＡＰＩが呼び出される。開始ＡＰＩに基づいて、端末は、作業領域の確保などの初期処理を実行した後、開始処理状況を送信する。また、端末は、経過処理状況を送信するためのスケジューリングを実行し、スケジュールに従って定期的に経過処理状況を送信する。

入力済み件数インクリメントＡＰＩは、バッチプログラムａにおける「入力済み件数」をカウントすることができる箇所（図１３（ｂ）における符号Ｂ）で呼び出される。例えば、ステップＳ２において“１件”が読み込まれる度に呼び出される。入力を実行する共通的な処理がある場合は、その中から入力済み件数インクリメントＡＰＩが呼び出される。入力済み件数インクリメントＡＰＩに基づいて、端末は、作業領域に保持された「入力済み件数」に“１”を加算する。

オプションインクリメントＡＰＩは、バッチプログラムａにおける複数の処理のうち、入力済み件数インクリメントＡＰＩでカウントされた処理の他の任意の処理の処理済み件数をカウントすることができる箇所（図１３（ｂ）における符号Ｃ）で呼び出される。例えば、ステップＳ４において、“１件”がデータｂに書き込まれる度に呼び出される。オプションインクリメントＡＰＩに基づいて、端末は、作業領域に保持された「オプション件数」のうち、パラメータで指定されたオプション番号に対応する、他の任意の処理の件数に“１”を加算する。なお、オプションインクリメントＡＰＩは、任意であり、呼び出す箇所も任意である。

終了ＡＰＩは、バッチプログラムａの終了直前に呼び出される（図１３（ｂ）における符号Ｄ）。例えば、ステップＳ２の直後に呼び出される。バッチプログラム１１の終了直前に共通的な処理がある場合は、その中から終了ＡＰＩが呼び出される。終了ＡＰＩに基づいて、端末は、終了処理状況を送信し、端末の作業領域の開放などの終了処理を実行する。

開始処理状況、経過処理状況および終了処理状況の送受信は、ＵＤＰデータ転送手順に基づいて実行され、リモートコンピュータで実行されているバッチプログラム１１からも各処理状況１２が収集される。

次に、リソース状況について図面に基づいて説明する。

図２に示されているとおり、リソース状況１６は、バッチプログラム１１の実行中にエージェントプログラム１５が実行され、処理状況収集部７によって収集される。受信されたリソース状況１６は、利用者の端末２０への照会用に加工され、リソース情報１７として出力される。リソース情報１７はディスクに格納される。

ここで、リソース状況１６およびリソース情報１７の詳細を図面に基づいて説明する。図１５は、本実施形態に係るバッチ処理システム１０のリソース状況１６の内容が示され、図１６は、リソース情報１７の内容が示されている。

＜リソース状況＞
リソース状況１６は、バッチプログラム１１が実行されている端末のリソースの状態に関する情報であり、図１５に示されているとおり、項目として「送信時現在時刻」「ＣＰＵ使用状況」「メモリ使用状況」「ＩＯ発生状況」が設定されている。

「送信時現在時刻」は、リソース状況１６を送信した送信時刻である。「ＣＰＵ使用状況」は、リソース状況１６を送信する時点におけるＣＰＵの使用状況である。「メモリ使用状況」は、リソース状況１６を送信する時点におけるメモリの使用状況である。「ＩＯ発生状況」は、リソース状況１６を送信する時点におけるＩＯの使用状況である。

＜リソース情報＞
リソース情報は、利用者の端末２０への照会用にリソース状況１６が加工された情報であり、図１６に示されているとおり、リソース状況１６に加え、「端末名」が設定されている。「端末名」は、リソース状況１６の送信元の端末の名称であり、すなわち、エージェントプログラム１５およびバッチプログラム１１が実行されている端末の名称である。

次に、アラーム通知機能について図面に基づいて説明する。図１７は、本実施形態に係るバッチ処理システム１０の処理状況収集部７において閾値を設定することができる項目が示されている。

＜アラーム機能＞
図１７に示されているとおり、閾値は、項目として「入力済み件数」「処理時間」「オプション件数０〜９９」「１分あたりの入力件数」が設定されている。

「入力済み件数」では、処理状況１２の「入力済み件数」が閾値を上回った場合にアラームが通知される。「処理時間」では、処理状況１２の「送信時現在時刻」から「開始時刻」を減算した値が閾値を上回った場合にアラームが通知される。「オプション件数０〜９９」では、処理状況１２の「オプション件数」が閾値を上回った場合に通知される。「１分あたりの入力件数」では、処理状況１２の「入力済み件数」を「処理時間」で除算した値が閾値を下回った場合にアラームが通知される。

次に、処理状況照会部８について図面に基づいて説明する。図１８は、本実施形態に係るバッチ処理システム１０の最新情報１３における画面遷移の概略が示されている。図２６は、本実施形態に係るバッチ処理システム１０の累積情報１４における画面遷移の概略が示されている。

＜処理状況照会部＞
図２に示されているとおり、処理状況照会部８は、例えば、処理状況収集機能を有するサーバーなどによって実現される。処理状況照会部８は、図１８および図２６に示されているとおり、利用者の端末２０のブラウザを介して要求された抽出条件１８に基づいて、抽出条件１８に合致したものを最新情報１３または累積情報１４から抽出し、抽出結果１９を利用者の端末２０のブラウザに表示する。バッチプログラム１１の最新の処理状況１２は、最新情報１３から抽出され、一方、過去の処理状況１２は、累積情報１４から抽出される。複数の抽出条件１８が指定された場合は、すべての抽出条件１８に合致するバッチプログラム１１が抽出され、指定された表示形式に基づいて抽出結果１９が表示される。

ここで、最新情報１３における抽出条件１８および表示形式の詳細を図面に基づいて説明する。図１９は、本実施形態に係るバッチ処理システム１０の最新情報１３における抽出条件１８の内容が示されている。図２０は、最新情報１３における表示形式の内容が示され、図２１から図２５は、表示形式ごとの表示例が示されている。

＜最新情報における抽出条件＞
図１９に示されているとおり、抽出条件１８は「端末名」「バッチプログラム名」「開始時刻」「終了時刻」「ステータス」が設定されている。

「端末名」では、名称が入力されることで端末が指定され、指定された端末で実行中、または実行されていたバッチプログラム１１が抽出される。「バッチプログラム名」では、名称が入力されることでバッチプログラム１１が指定され、指定された名称と合致するバッチプログラム１１が抽出される。なお、ワイルドカードでもよい。「開始時刻」では、時刻の範囲が入力されることで時間が指定され、指定された時間内に処理が開始されたバッチプログラム１１が抽出される。「終了時刻」では、時刻の範囲が入力されることで時間が指定され、指定された時間内に処理が終了したバッチプログラム１１が抽出される。「ステータス」では、「処理中」「終了」「すべて」の何れかが入力されることでステータスが指定され、指定されたステータスに合致するバッチプログラム１１が抽出される。

＜最新情報における表示形式＞
図２０に示されているとおり、表示形式は、「一覧」「入力済み件数」「処理時間」「時系列処理時間」「処理件数／分」が設定されている。

「一覧」によれば、バッチプログラム１１の最新の処理状況１２が表形式で表示される（図２１参照）。「入力済み件数」によれば、最新情報１３から抽出されたバッチプログラム１１における「入力済み件数」がグラフ形式で表示される（図２２参照）。「処理時間」によれば、最新情報１３から抽出されたバッチプログラム１１における「処理時間」がグラフ形式で表示される（図２３参照）。「時系列処理時間」によれば、最新情報１３から抽出されたバッチプログラム１１における「処理時間」が「開始時刻」に合わせて時系列で表示される（図２４参照）。「処理件数／分」によれば、最新情報１３から抽出されたバッチプログラム１１における「１分当たりの入力済み件数」がグラフ形式で表示される（図２５参照）。

ここで、例えば、表示形式が「一覧」の場合、図２１に示されているとおり、表示項目として「端末」「バッチプログラム」「開始時刻」「終了時刻」「入力済み件数」「入力総件数」「進捗率」「処理中」が設定されている。

「端末」は、バッチプログラム１１が実行された端末の名称であり、最新情報１３の端末名が表示される。「バッチプログラム」は、抽出されたバッチプログラム１１の名称であり、最新情報１３のバッチプログラム名が表示される。「開始時刻」は、バッチプログラム１１の開始時刻であり、最新情報１３の開始時刻が表示される。「終了時刻」は、バッチプログラム１１の終了時刻であり、最新情報１３のデータ区分が「終了」である場合、バッチプログラム１１における処理が終了しているため、最新情報１３（終了処理状況）の「送信時現在時刻」が表示される。一方、最新情報１３のデータ区分が「経過」である場合、バッチプログラム１１が実行中であるため、予測終了時刻が表示される。「入力済み件数」は、バッチプログラムにおける処理のうち、終了した処理の件数であり、最新情報１３の入力済み件数が表示される。「入力総件数」は、バッチプログラム１１における処理の総件数であり、最新情報１３のデータ区分が「終了」である場合、バッチプログラム１１における処理が終了しているため、最新情報１３（終了処理状況）の送信時現在時刻が表示される。一方、最新情報１３のデータ区分が「経過」である場合、バッチプログラム１１が実行中であるため、先行終了バッチプログラム１１の出力件数が表示される。「進捗率」は、バッチプログラム１１の進捗率であり、入力済み件数／入力総件数が百分率で表示される。「処理中」は、バッチプログラム１１における処理の状態であり、最新情報１３のデータ区分が「終了」である場合、空欄で表示される。一方、最新情報１３のデータ区分が「開始」「経過」である場合、チェックが表示される。

次に、累積情報１４における表示形式の詳細を図面に基づいて説明する。図２７は、本実施形態に係るバッチ処理システム１０の累積情報１４における抽出条件１８の内容が示されている。図２８は、本実施形態に係るバッチ処理システム１０の累積情報１４における表示形式の内容が示され、図２９から図３４は、表示形式ごとの表示例が示されている。なお、以下の説明では、最新情報１３における抽出条件１８（図１９参照）および表示形式（図２０参照）と同じ説明を省略し、異なる部分のみを説明する。

＜累積情報における表示形式＞
図２８に示されているとおり、表示形式は「一覧」「入力済み件数」「処理時間」「処理件数／分」「入力済み件数＋処理時間」「処理件数／分＋処理時間」が設定されている。

「一覧」によれば、バッチプログラム１１の過去の実績（過去の処理状況１２）が表形式で表示される（図２９参照）。「入力済み件数」によれば、過去の実績（過去の処理状況１２）から抽出されたバッチプログラム１１における入力済み件数がグラフ形式で表示される（図３０参照）。「処理時間」によれば、過去の実績（過去の処理状況１２）から抽出されたバッチプログラム１１における処理時間がグラフ形式で表示される（図３１参照）。「処理件数／分」によれば、過去の実績（過去の処理状況１２）から抽出されたバッチプログラム１１における１分当たりの入力済み件数がグラフ形式で表示される（図３２参照）。「入力済み件数＋処理時間」によれば、過去の実績（過去の処理状況１２）から抽出されたバッチプログラム１１における入力済み件数の変化がグラフ形式で表示される（図３３参照）。「処理件数／分＋処理時間」によれば、過去の実績（過去の処理状況１２）から抽出されたバッチプログラム１１における１分当たりの処理件数の変化がグラフ形式で比較されて表示される（図３４参照）。

次に、予測終了時刻および入力総件数の算出について図面に基づいて詳説する。図３５は、本実施形態に係るバッチ処理システム１０における予測終了時刻の算出を説明するためのバッチプログラムａ，ｂの概略が示されている。なお、以下の説明のバッチプログラムａ，ｂは一例であり、任意である。

＜予測終了時刻の算出＞
処理状況照会部８によれば、実行中のバッチプログラム１１である実行バッチプログラムｂの処理よりも前に終了したバッチプログラム１１である先行終了バッチプログラムａの終了処理状況に基づいて、実行バッチプログラムｂの予測終了時刻が算出される。

図３５において、先行終了バッチプログラムａは、処理状況収集部７で定められた各ＡＰＩを利用している。先行終了バッチプログラムａは、データａからデータを読み込み、読み込んだすべてのデータをデータｂに書き込むものである。

実行バッチプログラムｂは、先行終了バッチプログラムａと同様に、処理状況収集部７で定められた各ＡＰＩを利用しており、先行終了バッチプログラムａの処理が終了した後に処理を開始するものである。実行バッチプログラムｂは、先行終了バッチプログラムａが出力したデータｂからデータを読み込み、読み込んだデータを加工してデータｃに書き込む。

すなわち、先行終了バッチプログラムａの入力済み件数は、データｂの出力件数と等しくなるため、先行終了バッチプログラムａが終了した後の「入力済み件数」は、実行バッチプログラムｂの入力データの総件数として利用することができる。実行バッチプログラムｂが最新情報１３または累積情報１４から抽出される際、実行バッチプログラムｂにおける処理が実行中である場合、以下の手順で実行バッチプログラムｂの予測終了時刻が算出され表示される。

まず、実行バッチプログラムａの残り件数を算出する。すなわち、次式［１］のとおり、先行終了バッチプログラムａの「入力済み件数」と実行バッチプログラムｂの「入力済み件数」との差から、実行バッチプログラムｂの残り件数を算出する。
式［１］：先行終了バッチプログラムａの入力済み件数−実行バッチプログラムｂの入力済み件数＝実行バッチプログラムｂの残り件数

次に、実行バッチプログラムｂが残り件数を処理するのに要する時間である、実行バッチプログラムｂの残り処理時間を算出する。すなわち、次式［２］のとおり、実行バッチプログラムｂの残り件数を実行バッチプログラムｂの「増加件数」で除算し、その結果に実行バッチプログラムｂの「経過時間」を積算することで、実行バッチプログラムｂの残り処理時間を算出する。
式［２］：実行バッチプログラムｂの残り件数／実行バッチプログラムｂの増加件数＊実行バッチプログラムｂの経過時間＝実行バッチプログラムｂの残り処理時間

最後に、実行バッチプログラムｂの予測終了時刻を算出する。すなわち、次式［３］のとおり、実行バッチプログラムｂの残り処理時間と、実行バッチプログラムｂの「送信時現在時刻」との和から、実行バッチプログラムｂの予測終了時刻を算出する。
式［３］：実行バッチプログラムｂの残り処理時間＋実行バッチプログラムｂの送信時現在時刻＝実行バッチプログラムｂの予測終了時刻

処理状況照会部８は、利用者から情報の照会の要求があった際に、実行中のバッチプログラム１１があった場合、上記した算出方法にしたがって予測終了時刻を算出し、利用者によって指定された表示形式に基づいて予測終了時刻を表示する。

ここで、バッチプログラム１１の実行中における表示形式の詳細を図面に基づいて説明する。図３６から図３８は、本実施形態に係るバッチ処理システム１０のバッチプログラム１１が実行中であり、２２時に利用者から照会された場合の表示形式ごとの表示例が示されている。

図３６に示されているとおり、利用者から指定された表示形式が「一覧」であり、請求処理ａが終了し、請求処理ｂおよび請求処理ｃが実行中であった場合（すなわち、抽出された最新情報１３または累積情報１４のデータ区分が「経過」であった場合）、請求処理ｂおよび請求処理ｃの終了時刻は、予測終了時刻が表示される。また、請求処理ｂ入力総件数は、先行終了バッチプログラム１１である請求処理ａの出力件数（入力済み件数）が表示される。なお、表示形式が「処理時間」「時系列処理時間」の場合は、それぞれ図３７および図３８に示されている。

以上のとおり、本実施形態に係るバッチ処理システム１０が構成されている。次に、バッチ処理システム１０の効果を説明する。

上記したとおり、本実施形態によれば、処理状況収集部７は、実行中のバッチプログラム１１の処理状況１２を送信させるためのＡＰＩが定められている。端末で実行されるバッチプログラム１１の処理状況１２は、ＡＰＩに基づいて、ネットワークを通じて処理状況収集部７で受信され、収集される。したがって、バッチプログラム１１の処理の進捗を把握することができ、仮に処理時間が長期化した場合であっても、その後の対応作業を迅速に実施することができる。

本実施形態によれば、処理状況１２は、バッチプログラム１１による処理の開始情報である開始処理状況、処理の経過情報である経過処理状況、処理の終了情報である終了処理状況がある。この構成により、三種類の各処理状況１２が収集される。したがって、バッチプログラム１１の処理の詳細な進捗を把握することができる。

本実施形態によれば、バッチプログラム１１による処理の開始後に開始処理状況を送信させ、経過処理状況を送信するためのスケジューリングを実行する開始ＡＰＩと、バッチプログラム１１による処理の終了前に終了処理状況を送信させる終了ＡＰＩと、処理の処理済み件数をカウントする処理済み件数インクリメントＡＰＩとが含まれ、処理状況１２に「処理済み件数」が含まれている。この構成により、各ＡＰＩが、バッチプログラム１１の所定の箇所で呼び出され、各処理状況１２が送信される。したがって、各処理状況１２を送信することを意識せずにバッチプログラム１１を設計することができる。また、処理状況１２に「処理済み件数」が含まれているため、バッチプログラム１１の処理の詳細な進捗を把握することができる。

本実施形態によれば、処理済み件数インクリメントＡＰＩでカウントされた処理の他の任意の処理の処理済み件数をカウントするオプション件数インクリメントＡＰＩが含まれ、処理状況１２に任意の処理の「処理済み件数」が含まれている。この構成により、例えば、バッチプログラム１１における処理として複数の処理がある場合、そのうちの任意の処理の件数をカウントすることができる。したがって、バッチプログラム１１の処理の詳細な進捗を把握することができる。

本実施形態によれば、バッチプログラム１１の実行中にエージェントプログラム１５が実行され、処理状況収集部７にリソース状況１６が収集される。したがって、リソース状況１６を把握することができ、仮に不具合が発生した場合であっても、その後の対応作業を迅速に実施することができる。

本実施形態によれば、バッチプログラム１１が最新情報１３または累積情報１４から抽出される際、バッチプログラム１１における処理が実行中である場合、次式［１］［２］［３］を用いて実行バッチプログラムの予測終了時刻が算出され表示される。
式［１］：先行終了バッチプログラムの入力済み件数−実行バッチプログラムの入力済み件数＝実行バッチプログラムの残り件数
式［２］：実行バッチプログラムの残り件数／実行バッチプログラムの増加件数＊実行バッチプログラムの経過時間＝実行バッチプログラムの残り処理時間
式［３］：実行バッチプログラムの残り処理時間＋実行バッチプログラムの送信時現在時刻＝実行バッチプログラムの予測終了時刻
したがって、実行中のバッチプログラム１１の終了時刻を予測することができ、仮に処理時間が長期化した場合であっても、その後の対応作業を迅速に実施することができる。

以上、本発明の実施形態を詳述したが、本発明は上記実施形態に限定されるものではない。そして本発明は、特許請求の範囲に記載された事項を逸脱することがなければ、種々の設計変更を行うことが可能である。

１ ＣＰＵ
２ 記憶部
３ ＲＯＭ
４ ＲＡＭ
５ ＨＤＤ
６ 入力部
７ 処理状況収集部
８ 処理状況照会部
９ 出力部
１０ バッチ処理システム
１１ バッチプログラム
１２ 処理状況
１３ 最新情報
１４ 累積情報
１５ エージェントプログラム
１６ リソース状況
１７ リソース情報
１８ 抽出条件
１９ 抽出結果
２０ 利用者端末

Claims (11)

1. 実行中のバッチプログラムにおける処理の処理状況を送信させるための規則が定められた処理状況収集部が備えられ、前記規則に基づいて前記処理状況が前記処理状況収集部に収集される、
   ことを特徴とするバッチ処理システム。
2. 前記処理状況が、
   前記バッチプログラムによる処理の開始情報である開始処理状況、
   前記バッチプログラムによる処理の経過情報である経過処理状況、
   前記バッチプログラムによる処理の終了情報である終了処理状況、である
   ことを特徴とする請求項１に記載されたバッチ処理システム。
3. 前記規則に、
   前記バッチプログラムによる処理の開始後に前記開始処理状況を送信させ、前記経過処理状況を送信するためのスケジューリングを実行する開始ＡＰＩと、
   前記バッチプログラムによる処理の終了前に前記終了処理状況を送信させる終了ＡＰＩと、が含まれた、
   ことを特徴とする請求項２に記載されたバッチ処理システム。
4. 前記規則に、前記処理の処理済み件数をカウントする処理済み件数インクリメントＡＰＩが含まれ、
   前記処理状況に前記処理済み件数が含まれた、
   ことを特徴とする請求項１から請求項３のいずれか１項に記載されたバッチ処理システム。
5. 前記規則に、前記処理済み件数インクリメントＡＰＩでカウントされた前記処理の他の任意の処理の処理済み件数をカウントする任意処理済み件数インクリメントＡＰＩが含まれ、
   前記処理状況に前記任意の処理の処理済み件数が含まれた、
   ことを特徴とする請求項４に記載されたバッチ処理システム。
6. 前記処理状況収集部にリソース状況が収集される、
   ことを特徴とする請求項１から請求項５のいずれか１項に記載されたバッチ処理システム。
7. 実行中の前記バッチプログラムである実行バッチプログラムの前記処理よりも前に終了したバッチプログラムである先行終了バッチプログラムの前記終了処理状況に基づいて、前記実行バッチプログラムの予測終了時刻を算出する処理状況照会部が備えられた、
   ことを特徴とする請求項２から請求項６のいずれか１項に記載されたバッチ処理システム。
8. 前記処理の処理済み件数および前記経過処理状況の送信時刻である送信時現在時刻が、前記経過処理状況および前記終了処理状況に含まれ、
   前記経過処理状況ごとに更新されて増加した前記処理済み件数である増加件数、および、前記経過処理状況ごとに更新されて経過した前記送信時現在時刻である経過時間を、前記経過処理状況および前記終了処理状況と関連付けて記憶する記憶部が備えられ、
   前記処理状況照会部が、
   前記先行終了バッチプログラムの処理済み件数と前記実行バッチプログラムの処理済み件数とから、前記実行バッチプログラムの残り件数を算出し、
   前記実行バッチプログラムの残り件数と、前記実行バッチプログラムの増加件数と、前記実行バッチプログラムの経過時間とから、前記実行バッチプログラムにおける前記処理が終了するまでの残り処理時間を算出し、
   前記実行バッチプログラムの残り処理時間と、前記実行バッチプログラムの送信時現在時刻とから、前記実行バッチプログラムの予測終了時刻を算出する、
   ことを特徴とする請求項６に記載されたバッチ処理システム。
9. バッチプログラムにおける処理の実行中に、前記バッチプログラムの処理状況を送信させるための規則に基づいて、前記処理状況を処理状況収集部に収集する手順を含む、
   ことを特徴とするバッチ処理方法。
10. バッチプログラムにおける処理の処理状況を送信するための規則が定められた処理状況収集部が備えられ、前記バッチプログラムにおける処理の実行中に、前記規則に基づいて前記処理状況を前記処理状況収集部に収集させる手順をコンピュータに実行させる、
    ことを特徴とするバッチ処理プログラム。
11. 請求項１０に記載されたバッチ処理プログラムが記憶された、
    ことを特徴とするコンピュータで読み取り可能な記憶媒体。