JP4071678B2 - バッチアプリケーション実行制御方法，バッチアプリケーション実行制御装置およびバッチアプリケーション実行制御プログラム - Google Patents
バッチアプリケーション実行制御方法，バッチアプリケーション実行制御装置およびバッチアプリケーション実行制御プログラム Download PDFInfo
- Publication number
- JP4071678B2 JP4071678B2 JP2003161556A JP2003161556A JP4071678B2 JP 4071678 B2 JP4071678 B2 JP 4071678B2 JP 2003161556 A JP2003161556 A JP 2003161556A JP 2003161556 A JP2003161556 A JP 2003161556A JP 4071678 B2 JP4071678 B2 JP 4071678B2
- Authority
- JP
- Japan
- Prior art keywords
- batch
- execution
- execution control
- batch application
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は，バッチアプリケーションを高速に実行処理するための方法，装置およびプログラムに関する。
【０００２】
バッチアプリケーションとは，処理対象のデータを一括して処理するソフトウェアプログラムである。通常，業務アプリケーションの実行形態として，オンラインアプリケーションとバッチアプリケーションの二つの形態があり，オンラインアプリケーションでは，伝票などの処理をリアルタイムで行うのに対し，バッチアプリケーションでは，例えば一日の売上集計のように，蓄えられたデータをまとめて処理する。
【０００３】
【従来の技術】
従来，例えばデータベース（以下，「ＤＢ」という）アクセスを行うクライアント・サーバシステムにおけるＤＢを用いたバッチアプリケーション処理を行う場合，バッチアプリケーション毎にＤＢ（例えば「ＯＲＡＣＬＥ」（登録商標））に対するコネクト／ディスコネクト処理を行っていた。ここで，コネクト処理とは，ＤＢにアクセスするためにＤＢ管理システムに接続する処理であり，ディスコネクト処理とは，ＤＢへのアクセスを終了し，ＤＢ管理システムとの接続を切る処理である。
【０００４】
図１４は，従来のバッチアプリケーションの動作説明図である。図中，１０はバッチアプリ情報ファイル，１１はバッチアプリケーションを表す。バッチアプリ情報ファイル１０は，バッチアプリケーション１１の実行に必要な情報が格納されているファイルである。図１４に示すように，従来は，バッチアプリ情報ファイル１０を読み込み，バッチアプリケーション１１を起動していた。各バッチアプリケーション１１は，起動時にＤＢへのコネクト処理を，終了時にＤＢへのディスコネクト処理を実行していた。
【０００５】
なお，上記バッチアプリケーションの動作処理に関して，実行時間を短縮して処理を高速化するための技術を記載した先行技術文献は，特に見当たらない。
【０００６】
【発明が解決しようとする課題】
上記従来技術では，バッチアプリケーション毎にＤＢに対するコネクト／ディスコネクト処理を行っていたため，バッチアプリケーションの数に比例してその処理時間が長くなるという問題があった。
【０００７】
すなわち，複数のジョブステップから構成される業務アプリケーションのバッチアプリケーションを動作させる場合，従来技術では，ジョブステップ単位に各バッチアプリケーションのプロセスを起動し，各ジョブステップのプロセス毎にＤＢコネクト／ディスコネクト処理を実行するため，ＤＢコネクト／ディスコネクト処理に時間がかかり，バッチアプリケーションの処理が遅くなるという問題があった。なお，ＤＢコネクト／ディスコネクト処理には，システム負荷によっては２〜３秒の処理時間がかかることがある。
【０００８】
以上のようなＤＢコネクト／ディスコネクト処理に時間がかかるという問題に限らず，多量のバッチアプリケーションの実行に関して，次のような場合に，処理に時間がかかり，処理の負荷が大きくなるという問題があった。
（１）ジョブ実行制御の起動処理に時間（１秒程度の起動時間）がかかる。
（２）ＥＪＢ（Enterprise-JavaBeans）との共通開発を図った場合，バッチアプリケーションをＪａｖａ（登録商標）で開発することになるが，従来はバッチアプリケーションの各ジョブステップ毎にＪａｖａ仮想マシン（ＪａｖａＶＭ）の起動を行っており，ＪａｖａＶＭの起動処理に時間（１〜２秒）がかかる。
【０００９】
オンラインアプリケーションは，リアルタイムでの応答が要求されるため，従来から高速化についての種々の工夫がなされていたが，ジョブの一括投入，処理結果の一括出力というオフライン処理のバッチアプリケーションでは，応答の即時性が要求されないため，処理の高速化に関する考慮はあまり払われていなかった。
【００１０】
バッチアプリケーションとオンラインアプリケーションとを比較すると，バッチアプリケーションの処理速度は，オンラインアプリケーションの処理速度より格段に遅く，オンラインアプリケーションでは，１００トランザクション／秒（ＴＰＳ）の処理を狙えるが，バッチアプリケーションでは，１００トランザクション／分（ＴＰＭ）程度の処理時間がかかっていた。
【００１１】
最近の業務アプリケーションでは，バッチアプリケーションの数が多くなる傾向にあるが，バッチアプリケーションの数が多くなると，バッチ処理といえども，これまでのように処理時間が長くかかることは望ましいことではない。
【００１２】
本発明は，上記従来技術の問題点を解決し，多数のバッチアプリケーションの高速処理を可能にすることを目的とする。
【００１３】
【課題を解決するための手段】
上記課題を解決するため，本発明は，複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，１または複数のプログラム実行制御部を生成するステップと，前記生成された１または複数のプログラム実行制御部が，該プログラム実行制御部で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，前記共通処理の実行後に，前記バッチアプリケーションを順次，一つのプログラム実行制御部が一つずつ呼び出して実行する処理を，終了の指示があるまで繰り返すステップとを有することを特徴とする。
【００１４】
また，本発明は，複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，前記複数のバッチアプリケーションの実行を制御するためのバッチ実行プロセスを起動するステップと，前記バッチ実行プロセスが，プログラム実行制御部を複数生成するステップと，前記生成された複数のプログラム実行制御部毎に，該プログラム実行制御部で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，前記バッチ実行プロセスが，前記バッチアプリケーションの実行依頼を受け付けるステップと，前記バッチ実行プロセスが，前記実行依頼を受け付けたバッチアプリケーションの実行を，現在バッチアプリケーションを実行していないプログラム実行制御部に指示するステップと，前記実行指示を受けたプログラム実行制御部が，指示されたバッチアプリケーションを呼び出して実行するステップとを有することを特徴とする。
【００１５】
また，上記発明において，前記プログラム実行制御部を複数生成するステップでは，前記バッチ実行プロセスの起動時に読み込んだ情報に含まれる実行多重度数分のプログラム実行制御部を生成することを特徴とする。
【００１６】
また，本発明は，複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御装置であって，バッチ実行制御手段と，複数のプログラム実行制御手段とを備え，前記バッチ実行制御手段は，前記バッチアプリケーションの実行依頼を受け付ける手段と，前記プログラム実行制御手段に対し，前記実行依頼を受け付けたバッチアプリケーションの実行指示を行う手段とを備え，前記複数のプログラム実行制御手段の各々は，該プログラム実行制御手段で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行する手段と，前記バッチ実行制御手段からのバッチアプリケーションの実行指示に対し，指示されたバッチアプリケーションを呼び出して実行する手段とを備えることを特徴とする。
【００１７】
以上のバッチアプリケーション実行制御方法の処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。
【００１８】
【発明の実施の形態】
以下，図を用いて本発明の実施の形態を説明する。
【００１９】
図１は，本発明を実施する装置の構成例を示す図である。図中，１００はＣＰＵおよびメモリなどからなるデータ処理装置，１はバッチアプリケーション，２はプログラム実行制御部（スレッド）を生成し，プログラム実行制御部に実行命令を出してバッチアプリケーションを実行させるバッチ実行プロセス，４，４’はバッチアプリケーションを実行するプログラム実行制御部（スレッド）である。
【００２０】
バッチ実行プロセス２において，プログラム実行制御部生成部２０は，あらかじめ定められた個数のプログラム実行制御部４，４’のスレッドを生成する。実行依頼受付け部２１は，各バッチアプリケーション１の実行依頼を受け付ける。実行待ち管理部２２は，バッチアプリケーション１の実行依頼を実行待ちキュー２３にキューイングする。バッチアプリ実行命令部２４は，プログラム実行制御部４，４’に空きがあれば，そのプログラム実行制御部４，４’に実行命令を出す。
【００２１】
プログラム実行制御部４（４’も同様）は，バッチアプリ共通処理部４０，４１およびバッチアプリ呼出し部４２を備える。バッチアプリ共通処理部４０は，どのバッチアプリケーション１も共通に最初に実行しなければならない必須処理の実行部分であり，例えばバッチアプリケーション１がデータベースにアクセスするプログラムであった場合には，ＤＢコネクト処理を実行する部分である。また，バッチアプリケーション１がＪａｖａプログラムであった場合には，ＪａｖａＶＭの起動処理などを実行する部分である。
【００２２】
バッチアプリ共通処理部４１は，どのバッチアプリケーション１も共通に最後に実行しなければならない必須処理の実行部分であり，例えばバッチアプリケーション１がデータベースにアクセスするプログラムであった場合には，ＤＢディスコネクト処理を実行する部分である。また，バッチアプリケーション１がＪａｖａプログラムであった場合には，ＪａｖａＶＭを終了させる処理などを実行する部分である。
【００２３】
バッチアプリ呼出し部４２は，バッチ実行プロセス２のバッチアプリ実行命令部２４からの実行命令により，指定されたバッチアプリケーション１を呼び出して実行する処理部である。バッチアプリケーション１は，プログラム実行制御部４のスレッド上で関数呼出し，もしくはサブルーチン呼出しのような形態で動作する。オブジェクト指向システムの場合には，バッチアプリケーション１は，一つまたは複数のオブジェクトとして実現されてもよい。
【００２４】
プログラム実行制御部４は，バッチ実行プロセス２から生成され，起動されると，最初に一度だけバッチアプリ共通処理部４０による処理を実行し，その後は，バッチアプリ実行命令部２４からの実行命令によって一度に一つのバッチアプリケーション１を呼び出す。そのバッチアプリケーション１の処理が終了すると，次のバッチアプリケーション１の実行命令受付け可能状態になり，終了の指示があるまで，各実行命令に対し，バッチアプリ呼出し部４２によるバッチアプリケーション１の呼び出しを繰り返す。バッチ実行プロセス２から実行終了指示があると，最後に一度だけバッチアプリ共通処理部４１による処理を実行し，終了する。
【００２５】
図１に示す例では，バッチアプリケーションＡ，Ｂ，Ｃ…の実行依頼に対して，プログラム実行制御部４が，最初にバッチアプリ共通処理部４０による処理を実行した後，バッチアプリ実行命令部２４からの実行命令（Ａ）に対し，バッチアプリ呼出し部４２によってバッチアプリケーションＡを呼び出して処理させ，プログラム実行制御部４’は，バッチアプリ共通処理部４０’の実行後，実行命令（Ｂ）に対し，バッチアプリ呼出し部４２’によって，バッチアプリケーションＢを呼び出して処理させている。他の実行依頼Ｃ，Ｄ，Ｅ，…は，実行待ちキュー２３に接続されている。
【００２６】
バッチアプリケーションＡの実行が終了すると，バッチアプリ実行命令部２４からの次の実行命令（Ｃ）により，プログラム実行制御部４のバッチアプリ呼出し部４２は，バッチアプリケーションＣを呼び出して処理させる。
【００２７】
従来技術では，各バッチアプリケーション毎にＤＢコネクト処理などのバッチアプリ共通処理部４０による処理を実行することが必要であったのに対し，本発明では，プログラム実行制御部４が実行するので，各バッチアプリケーション１におけるバッチアプリ共通処理部４０の処理は不要となる。
【００２８】
図２は，本発明の実施の形態によるバッチアプリケーションの実行制御の例を説明する図である。本実施の形態では，図１のバッチアプリ共通処理部４０の処理がＤＢコネクトであり，バッチアプリ共通処理部４１の処理がＤＢディスコネクトであるものとする。
【００２９】
図中の３はバッチ実行プロセス２にバッチアプリケーションの実行依頼をする起動プロセス，５は起動プロセス３の起動に必要なパラメタが書き込まれたパラメタファイル，６は実行プログラム名等のバッチアプリケーションを特定する情報が書き込まれたバッチアプリ情報ファイル，７はバッチ実行プロセス２の初期化に必要な情報が書き込まれた初期化ファイル，８はバッチ実行プロセス名，実行多重度，ログファイルのファイル数等の情報が書き込まれたパラメタファイルである。
【００３０】
パラメタファイル５は，起動プロセス３を起動させるために読み込まれる。また，初期化ファイル７およびパラメタファイル８は，バッチ実行プロセス２を起動させるために読み込まれる。
【００３１】
以下，図２に示す（ａ）〜（ｆ）に従って，本実施の形態の動作例を説明する。
（ａ）まず，初期化ファイル７の内容とパラメタファイル８の内容を読み込み，バッチ実行プロセス２を起動させる。
（ｂ）バッチ実行プロセス２は，パラメタファイル８の内容をもとにプログラム実行制御部（スレッド）４を生成する。そして，バッチ実行プロセス２は，初期化ファイル７の内容をもとにプログラム実行制御部（スレッド）４に命令を出し，プログラム実行制御部（スレッド）４毎にＤＢコネクトさせる。
（ｃ）その後，バッチアプリケーション１の実行依頼をするために，パラメタファイル５，バッチアプリ情報ファイル６を読み込み，起動プロセス３を立ち上げる。
（ｄ）起動プロセスは３，パラメタファイル５とコマンド引数で渡されるバッチアプリ情報ファイル６の内容をもとに，バッチ実行プロセス２にバッチアプリケーション１の実行処理を依頼する。なお，起動プロセス３からバッチ実行プロセス２への実行依頼には，ＴＣＰ／ＩＰの通信プロトコルを用いる。
（ｅ）バッチ実行プロセス２は起動プロセス３からの実行依頼を受けると，受け付けた実行依頼のパラメタを取り込み，実行可否の条件を判定し，現在空いているプログラム実行制御部（スレッド）４に実行命令を出す。現在空いているプログラム実行制御部（スレッド）４が存在しない場合には，受け付けた実行依頼を実行待ちキュー２３にキューイングし，実行待ち状態にする。
（ｆ）バッチアプリケーション１の実行命令を受けたプログラム実行制御部（スレッド）４は，指定された実行プログラム名のバッチアプリケーション１を起動する。バッチアプリケーション１の実行が終了した場合には，実行終了をバッチ実行プロセス２に報告し，次のバッチアプリケーション１の実行命令を待つ。
【００３２】
すべてのバッチアプリケーション１の実行を終了した後に，プログラム実行制御部（スレッド）４は，バッチ実行プロセス２からの指示によりＤＢディスコネクトを行い，スレッドを閉じる。
【００３３】
上記のように，本発明の実施の形態では，システムの起動時に生成した複数のプログラム実行制御部（スレッド）４毎に一度だけＤＢへの接続処理（コネクト）を実施し，システムの終了時に一度だけＤＢへの切断処理（ディスコネクト）を実施する。また，バッチアプリケーション１の実施の際には，必ずプログラム実行制御部（スレッド）４からバッチアプリケーション１を呼び出す。プログラム実行制御部（スレッド）４内では，すでにＤＢへのコネクト処理を完了し，コネクト状態が保持されているため，バッチアプリケーション１毎にＤＢへのコネクト／ディスコネクト処理をする必要がなくなる。
【００３４】
図３は，本発明の実施の形態における初期処理のフローを示す図である。本システムを立ち上げる場合，まず，バッチ実行プロセス２を起動させるために，初期化ファイル７の読み込みを行う（ステップＳ１）。初期化ファイル７の一例（ＳＵＳＶＩＮＩＴ）を図４に示す。初期化ファイル７には，例えば図４に示すように，ＤＢアクセスするユーザ名，ＤＢアクセスするユーザのパスワード，インスタンス名，ログファイルの最大サイズ，ログを出力するレベル，ログファイルの最大数，インスタンスのＵＲＬ（Ｊａｖａの場合），ＪＤＢＣ（Java Database Connectivity）のドライバ名（Ｊａｖａの場合），また，ＣＯＢＯＬ業務アプリケーションを実行するかどうかの情報が書き込まれている。ＪＤＢＣは，ＪａｖａプログラムからＤＢにアクセスするための標準アプリケーションプログラムインタフェース（ＡＰＩ）である。
【００３５】
次に，パラメタファイル８の読み込みを行う（ステップＳ２）。パラメタファイル８の一例（fbdef.txt ）を図５に示す。パラメタファイル８には，例えば図５に示すように，バッチ実行プロセス名，Ｃ／ＣＯＢＯＬ／Ｊａｖａといった言語の種別，ポート番号（Ｎｏ），生成するプログラム実行制御部（スレッド）４の数を示す実行多重度，実行待ちとして接続できる最大実行依頼数であるキューの最大数（ＭＡＸキュー），パラメタファイルを複写する作業フォルダ，ログファイルを書き込むフォルダ，ログファイルのファイル数等の情報が書き込まれている。
【００３６】
上記初期化ファイル７，パラメタファイル８の読み込み処理（ステップＳ１，Ｓ２）が行われることにより，バッチ実行プロセス２の起動が行われる（ステップＳ３）。その後，バッチ実行プロセス２によって，パラメタファイル８で指定された実行多重度の数分のプログラム実行制御部（スレッド）４の生成が行われる（ステップＳ４）。
【００３７】
図６は，本発明の実施の形態におけるプログラム実行制御部（スレッド）生成処理のフローを示す図である。まず，バッチ実行プロセス２は，パラメタファイル実行多重度数分のプログラム実行制御部（スレッド）４を生成する（ステップＳ１１）。プログラム実行制御部（スレッド）４を開始する（ステップＳ１２）。プログラム実行制御部（スレッド）４は，最初にＤＢコネクトして（ステップＳ１３），実行命令を待つ。バッチ実行プロセス２は，すべてのプログラム実行制御部（スレッド）４を生成した後，実行依頼を待つ。
【００３８】
図７は，本発明の実施の形態におけるバッチアプリケーション実行処理フローを示す図である。バッチアプリケーション１を実行させる場合，オペレータの指示により，またはシステムの自動起動処理により，起動プロセス３を起動させるために，まず，パラメタファイル５の読み込みを行う（ステップＳ２１）。パラメタファイル５の一例（fbdef.txt ）を図８に示す。パラメタファイル５には，例えば図８に示すように，バッチ実行プロセス名，Ｃ／ＣＯＢＯＬ／Ｊａｖａといった言語の種別，ポート番号（Ｎｏ），実行多重度，キューの最大数が書き込まれている。
【００３９】
次に，バッチアプリ情報ファイル６の読み込みを行う（ステップＳ２２）。バッチアプリ情報ファイル６の一例（inp1.txt）を図９に示す。バッチアプリ情報ファイル６には，例えば図９に示すように，実行プログラム名，打切り経過時間，データ１，データ２，会社コード，拠点コードというように，バッチアプリケーション１の実行に必要な情報が書き込まれている。
【００４０】
具体的には，図９に示すバッチアプリ情報ファイル６に書き込まれた情報中，「ｐｇｍ＝ｐｇｍ１」は，バッチ実行プロセス２上で実行させるバッチアプリケーション名（「ｐｇｍ１」）を探すキーであり，「ｔｉｍｅ＝２０」は，バッチ実行プロセス２上で待ちの場合，待機させておくタイムアウトが２０秒であることを示す。
【００４１】
また，「ｄａｔａ１＝１１１１１１１１」，「ｄａｔａ２＝２２２２２２２」は，実行させるバッチアプリケーション１固有の引数であり，「ｃｄｃｏｍｐａｎｙ＝０００」は，実行させるバッチアプリケーション１上で，ＤＢ領域への検索に使用する会社コードのキーであり，「ｃｄｓｔｏｒｅ＝０００」は，実行させるバッチアプリケーション１上で，ＤＢ領域への検索に使用する拠点コードのキーである。
【００４２】
次に，起動プロセス３の起動が行われる（ステップＳ２３）。その後，図１０に示すバッチ実行プロセス処理が行われる（ステップＳ２４）。バッチ実行プロセス２からの実行命令により，プログラム実行制御部（スレッド）４がバッチアプリケーション１の呼び出し処理を行い（ステップＳ２５），バッチアプリケーション１を実行する（ステップＳ２６）。
【００４３】
図１０は，図７のステップＳ２４におけるバッチ実行プロセス処理のフローを示す図である。まず，バッチ実行プロセス２が，起動プロセス３から実行依頼を受ける（ステップＳ３１）。次に，現在の実行待ちキュー２３中の実行依頼数がＭＡＸキューの値（最大待ち実行依頼数）になったかどうかを判定し（ステップＳ３２），現在の待ち実行依頼数がＭＡＸキューの値になった場合には，エラー情報設定をして，起動プロセス３に実行依頼を受け付けできない旨を通知する（ステップＳ３５）。
【００４４】
現在の待ち実行依頼数がＭＡＸキューの値より小さい場合には，実行多重度とアクティブスレッド数が異なるか否かを判定する（ステップＳ３３）。すなわち，現在バッチアプリケーション１を実行していない空きスレッドがあるかどうかを判定する。空きスレッドがあった場合，そのプログラム実行制御部（スレッド）４に実行命令を送り，バッチアプリケーション１を実行させる（ステップＳ３４）。実行多重度とアクティブスレッドの数が同じであり，空きスレッドがない場合には，受け付けた実行依頼を実行待ちキュー２３にキューイングし，空きスレッドができるまで待つ（ステップＳ３６）。
【００４５】
図１１は，本発明の実施の形態における終了処理のフローを示す図である。すべてのバッチアプリケーション１の終了により，またはオペレータ等の指示により，バッチ実行プロセス２の終了指示が行われると（ステップＳ４１），バッチ実行プロセス２は，まず，すべてのプログラム実行制御部（スレッド）４に終了指示を出す（ステップＳ４２）。プログラム実行制御部（スレッド）４は，ＤＢディスコネクトを行い（ステップＳ４３），終了する（ステップＳ４４）。バッチ実行プロセス２は，プログラム実行制御部（スレッド）４の終了を確認した後，終了する（ステップＳ４５）。
【００４６】
図１２は，バッチアプリケーション起動までのデータの流れを示す図である。（１）図１２（Ａ）に示すバッチアプリ情報ファイル６を起動プロセス３に読み込ませる。
（２）起動プロセス３で読み込まれたデータをバッチ実行プロセス２にＴＣＰ／ＩＰ通信で図１２（Ｂ）に示す電文形式で送信する。
（３）起動プロセス３から送信されたきた電文をもとに，バッチ実行プロセス２上で図１２（Ｃ）に示すようなハッシュマップを作成する。ハッシュマップとは，バッチアプリケーション１の実行に必要なパラメタおよびキーを集めたデータである。
（４）空いているプログラム実行制御部（スレッド）４に，図１２（Ｃ）に示すハッシュマップを送る。空きスレッドがない場合，タイムアウト値まで空きスレッドができるのを待つ。タイムアウト値を超えた場合には，処理をしないで，エラー終了とする。
（５）図１２（Ｄ）に示すハッシュマップのデータを引数にして，バッチアプリケーション「ｐｇｍ１」を実行させる。ｐｇｍ１内の処理で，引数の各キーをもとにデータを入力する。
【００４７】
図１３は，本発明の実施の形態におけるバッチアプリケーション実行処理のシーケンス図である。図１３では，ＤＢにコネクトしてデータ操作を行い，操作終了後にＤＢからディスコネクトする処理を行う業務アプリケーションであるバッチアプリケーションＡおよびバッチアプリケーションＢの実行処理を例にとって説明する。また，業務アプリケーション（バッチアプリケーションＡ，バッチアプリケーションＢ）は，例えば，Ｊａｖａで開発されているものとする。
【００４８】
図１３において，まず，バッチ実行プロセス２が起動すると（ａ），バッチ実行プロセス２は，プログラム実行制御部（スレッド）４を生成し，プログラム実行制御部（スレッド）４に命令を出してＤＢコネクトさせる（ｂ）。
【００４９】
次に，起動プロセス３が起動すると（ｃ），起動プロセス３は，バッチ実行プロセス２に実行依頼を行う（ｄ）。バッチ実行プロセス２は，現在空いているプログラム実行制御部（スレッド）４に実行命令を出す（ｅ）。実行命令を受けたプログラム実行制御部（スレッド）４は，業務アプリクラスを生成し，バッチアプリケーションＡを呼び出して実行する（ｆ）。実行処理が完了すると，バッチ実行プロセス２が，プログラム実行制御部（スレッド）４から実行完了通知を受ける（ｇ）。
【００５０】
再度，起動プロセス３が起動すると（ｈ），起動プロセス３は，バッチ実行プロセス２に実行依頼を行う（ｉ）。バッチ実行プロセス２は，現在空いているプログラム実行制御部（スレッド）４に実行命令を出す（ｊ）。実行命令を受けたプログラム実行制御部（スレッド）４は，業務アプリクラスを生成し，バッチアプリケーションＢを呼び出して実行する（ｋ）。
【００５１】
バッチ実行プロセス２は，プログラム実行制御部（スレッド）４から実行完了通知を受け（ｌ），その後，実行すべきバッチアプリケーションがないことを確認すると，プログラム実行制御部（スレッド）４に命令を出してＤＢディスコネクトさせ，終了処理を行う（ｍ）。
【００５２】
以上から把握できるように，本発明の実施の形態の特徴を述べると，以下のようである。
【００５３】
（付記１）複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，
１または複数のプログラム実行制御部を生成するステップと，
前記生成された１または複数のプログラム実行制御部が，最初に前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，
前記共通処理の実行後に，前記バッチアプリケーションを順次，一つのプログラム実行制御部が一つずつ呼び出して実行する処理を，すべてのバッチアプリケーションの実行が終了するまで繰り返すステップとを有する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５４】
（付記２）複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，
前記複数のバッチアプリケーションの実行を制御するためのバッチ実行プロセスを起動するステップと，
前記バッチ実行プロセスが，プログラム実行制御部を複数生成するステップと，
前記生成された複数のプログラム実行制御部毎に，最初に前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，
前記バッチ実行プロセスが，前記バッチアプリケーションの実行依頼を受け付けるステップと，
前記バッチ実行プロセスが，前記実行依頼を受け付けたバッチアプリケーションの実行を，現在バッチアプリケーションを実行していないプログラム実行制御部に指示するステップと，
前記実行指示を受けたプログラム実行制御部が，指示されたバッチアプリケーションを呼び出して実行するステップとを有する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５５】
（付記３）付記２に記載のバッチアプリケーション実行制御方法において，
前記バッチ実行プロセスが，前記プログラム実行制御部を複数生成するステップでは，前記バッチ実行プロセスの起動時に読み込んだ情報に含まれる実行多重度数分のプログラム実行制御部を生成する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５６】
（付記４）付記１から付記３までのいずれか１項に記載のバッチアプリケーション実行制御方法において，
さらに，前記プログラム実行制御部が，終了する前に，前記バッチアプリケーションの終了時に共通に必要となる共通処理を実行するステップを有する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５７】
（付記５）複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御装置であって，
バッチ実行制御手段と，複数のプログラム実行制御手段とを備え，
前記バッチ実行制御手段は，
前記バッチアプリケーションの実行依頼を受け付ける手段と，
前記プログラム実行制御手段に対し，前記実行依頼を受け付けたバッチアプリケーションの実行指示を行う手段とを備え，
前記複数のプログラム実行制御手段の各々は，
最初に前記複数のバッチアプリケーションに共通に必要となる共通処理を実行する手段と，
前記バッチ実行制御手段からのバッチアプリケーションの実行指示に対し，指示されたバッチアプリケーションを呼び出して実行する手段とを備える
ことを特徴とするバッチアプリケーション実行制御装置。
【００５８】
（付記６）付記１から付記４までのいずれか１項に記載のバッチアプリケーション実行制御方法を，コンピュータに実行させるためのバッチアプリケーション実行制御プログラム。
【００５９】
（付記７）付記１から付記４までのいずれか１項に記載のバッチアプリケーション実行制御方法を，コンピュータに実行させるためのバッチアプリケーション実行制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【００６０】
【発明の効果】
本発明により，バッチアプリケーションを高速に処理することができるため，夜間時などに行う定期バッチアプリケーションの処理時間を短縮することが可能となる。
【００６１】
また，本発明を用いることにより，例えば，データベースのコネクト／ディスコネクト処理やＪａｖａＶＭの起動処理を，バッチアプリケーション毎に行わなくてよいので，システム全体の負荷を軽減することが可能となる。
【図面の簡単な説明】
【図１】本発明を実施する装置の構成例を示す図である。
【図２】本発明の実施の形態によるバッチアプリケーションの実行制御の例を説明する図である。
【図３】初期処理のフローを示す図である。
【図４】初期化ファイルの一例を示す図である。
【図５】パラメタファイルの一例を示す図である。
【図６】プログラム実行制御部（スレッド）生成処理のフローを示す図である。
【図７】バッチアプリケーション実行処理フローを示す図である。
【図８】パラメタファイルの一例を示す図である。
【図９】バッチアプリ情報ファイルの一例を示す図である。
【図１０】バッチ実行プロセス処理のフローを示す図である。
【図１１】終了処理のフローを示す図である。
【図１２】バッチアプリケーション起動までのデータの流れを示す図である。
【図１３】バッチアプリケーション実行処理のシーケンス図である。
【図１４】従来のバッチアプリケーションの動作説明図である。
【符号の説明】
１，１１ バッチアプリケーション
２ バッチ実行プロセス
３ 起動プロセス
４ プログラム実行制御部（スレッド）
５ パラメタファイル
６，１０ バッチアプリ情報ファイル
７ 初期化ファイル
８ パラメタファイル
２０ プログラム実行制御部生成部
２１ 実行依頼受付け部
２２ 実行待ち管理部
２３ 実行待ちキュー
２４ バッチアプリ実行命令部
４０，４１ バッチアプリ共通処理部
４２ バッチアプリ呼出し部
１００ データ処理装置
【発明の属する技術分野】
本発明は，バッチアプリケーションを高速に実行処理するための方法，装置およびプログラムに関する。
【０００２】
バッチアプリケーションとは，処理対象のデータを一括して処理するソフトウェアプログラムである。通常，業務アプリケーションの実行形態として，オンラインアプリケーションとバッチアプリケーションの二つの形態があり，オンラインアプリケーションでは，伝票などの処理をリアルタイムで行うのに対し，バッチアプリケーションでは，例えば一日の売上集計のように，蓄えられたデータをまとめて処理する。
【０００３】
【従来の技術】
従来，例えばデータベース（以下，「ＤＢ」という）アクセスを行うクライアント・サーバシステムにおけるＤＢを用いたバッチアプリケーション処理を行う場合，バッチアプリケーション毎にＤＢ（例えば「ＯＲＡＣＬＥ」（登録商標））に対するコネクト／ディスコネクト処理を行っていた。ここで，コネクト処理とは，ＤＢにアクセスするためにＤＢ管理システムに接続する処理であり，ディスコネクト処理とは，ＤＢへのアクセスを終了し，ＤＢ管理システムとの接続を切る処理である。
【０００４】
図１４は，従来のバッチアプリケーションの動作説明図である。図中，１０はバッチアプリ情報ファイル，１１はバッチアプリケーションを表す。バッチアプリ情報ファイル１０は，バッチアプリケーション１１の実行に必要な情報が格納されているファイルである。図１４に示すように，従来は，バッチアプリ情報ファイル１０を読み込み，バッチアプリケーション１１を起動していた。各バッチアプリケーション１１は，起動時にＤＢへのコネクト処理を，終了時にＤＢへのディスコネクト処理を実行していた。
【０００５】
なお，上記バッチアプリケーションの動作処理に関して，実行時間を短縮して処理を高速化するための技術を記載した先行技術文献は，特に見当たらない。
【０００６】
【発明が解決しようとする課題】
上記従来技術では，バッチアプリケーション毎にＤＢに対するコネクト／ディスコネクト処理を行っていたため，バッチアプリケーションの数に比例してその処理時間が長くなるという問題があった。
【０００７】
すなわち，複数のジョブステップから構成される業務アプリケーションのバッチアプリケーションを動作させる場合，従来技術では，ジョブステップ単位に各バッチアプリケーションのプロセスを起動し，各ジョブステップのプロセス毎にＤＢコネクト／ディスコネクト処理を実行するため，ＤＢコネクト／ディスコネクト処理に時間がかかり，バッチアプリケーションの処理が遅くなるという問題があった。なお，ＤＢコネクト／ディスコネクト処理には，システム負荷によっては２〜３秒の処理時間がかかることがある。
【０００８】
以上のようなＤＢコネクト／ディスコネクト処理に時間がかかるという問題に限らず，多量のバッチアプリケーションの実行に関して，次のような場合に，処理に時間がかかり，処理の負荷が大きくなるという問題があった。
（１）ジョブ実行制御の起動処理に時間（１秒程度の起動時間）がかかる。
（２）ＥＪＢ（Enterprise-JavaBeans）との共通開発を図った場合，バッチアプリケーションをＪａｖａ（登録商標）で開発することになるが，従来はバッチアプリケーションの各ジョブステップ毎にＪａｖａ仮想マシン（ＪａｖａＶＭ）の起動を行っており，ＪａｖａＶＭの起動処理に時間（１〜２秒）がかかる。
【０００９】
オンラインアプリケーションは，リアルタイムでの応答が要求されるため，従来から高速化についての種々の工夫がなされていたが，ジョブの一括投入，処理結果の一括出力というオフライン処理のバッチアプリケーションでは，応答の即時性が要求されないため，処理の高速化に関する考慮はあまり払われていなかった。
【００１０】
バッチアプリケーションとオンラインアプリケーションとを比較すると，バッチアプリケーションの処理速度は，オンラインアプリケーションの処理速度より格段に遅く，オンラインアプリケーションでは，１００トランザクション／秒（ＴＰＳ）の処理を狙えるが，バッチアプリケーションでは，１００トランザクション／分（ＴＰＭ）程度の処理時間がかかっていた。
【００１１】
最近の業務アプリケーションでは，バッチアプリケーションの数が多くなる傾向にあるが，バッチアプリケーションの数が多くなると，バッチ処理といえども，これまでのように処理時間が長くかかることは望ましいことではない。
【００１２】
本発明は，上記従来技術の問題点を解決し，多数のバッチアプリケーションの高速処理を可能にすることを目的とする。
【００１３】
【課題を解決するための手段】
上記課題を解決するため，本発明は，複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，１または複数のプログラム実行制御部を生成するステップと，前記生成された１または複数のプログラム実行制御部が，該プログラム実行制御部で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，前記共通処理の実行後に，前記バッチアプリケーションを順次，一つのプログラム実行制御部が一つずつ呼び出して実行する処理を，終了の指示があるまで繰り返すステップとを有することを特徴とする。
【００１４】
また，本発明は，複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，前記複数のバッチアプリケーションの実行を制御するためのバッチ実行プロセスを起動するステップと，前記バッチ実行プロセスが，プログラム実行制御部を複数生成するステップと，前記生成された複数のプログラム実行制御部毎に，該プログラム実行制御部で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，前記バッチ実行プロセスが，前記バッチアプリケーションの実行依頼を受け付けるステップと，前記バッチ実行プロセスが，前記実行依頼を受け付けたバッチアプリケーションの実行を，現在バッチアプリケーションを実行していないプログラム実行制御部に指示するステップと，前記実行指示を受けたプログラム実行制御部が，指示されたバッチアプリケーションを呼び出して実行するステップとを有することを特徴とする。
【００１５】
また，上記発明において，前記プログラム実行制御部を複数生成するステップでは，前記バッチ実行プロセスの起動時に読み込んだ情報に含まれる実行多重度数分のプログラム実行制御部を生成することを特徴とする。
【００１６】
また，本発明は，複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御装置であって，バッチ実行制御手段と，複数のプログラム実行制御手段とを備え，前記バッチ実行制御手段は，前記バッチアプリケーションの実行依頼を受け付ける手段と，前記プログラム実行制御手段に対し，前記実行依頼を受け付けたバッチアプリケーションの実行指示を行う手段とを備え，前記複数のプログラム実行制御手段の各々は，該プログラム実行制御手段で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行する手段と，前記バッチ実行制御手段からのバッチアプリケーションの実行指示に対し，指示されたバッチアプリケーションを呼び出して実行する手段とを備えることを特徴とする。
【００１７】
以上のバッチアプリケーション実行制御方法の処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。
【００１８】
【発明の実施の形態】
以下，図を用いて本発明の実施の形態を説明する。
【００１９】
図１は，本発明を実施する装置の構成例を示す図である。図中，１００はＣＰＵおよびメモリなどからなるデータ処理装置，１はバッチアプリケーション，２はプログラム実行制御部（スレッド）を生成し，プログラム実行制御部に実行命令を出してバッチアプリケーションを実行させるバッチ実行プロセス，４，４’はバッチアプリケーションを実行するプログラム実行制御部（スレッド）である。
【００２０】
バッチ実行プロセス２において，プログラム実行制御部生成部２０は，あらかじめ定められた個数のプログラム実行制御部４，４’のスレッドを生成する。実行依頼受付け部２１は，各バッチアプリケーション１の実行依頼を受け付ける。実行待ち管理部２２は，バッチアプリケーション１の実行依頼を実行待ちキュー２３にキューイングする。バッチアプリ実行命令部２４は，プログラム実行制御部４，４’に空きがあれば，そのプログラム実行制御部４，４’に実行命令を出す。
【００２１】
プログラム実行制御部４（４’も同様）は，バッチアプリ共通処理部４０，４１およびバッチアプリ呼出し部４２を備える。バッチアプリ共通処理部４０は，どのバッチアプリケーション１も共通に最初に実行しなければならない必須処理の実行部分であり，例えばバッチアプリケーション１がデータベースにアクセスするプログラムであった場合には，ＤＢコネクト処理を実行する部分である。また，バッチアプリケーション１がＪａｖａプログラムであった場合には，ＪａｖａＶＭの起動処理などを実行する部分である。
【００２２】
バッチアプリ共通処理部４１は，どのバッチアプリケーション１も共通に最後に実行しなければならない必須処理の実行部分であり，例えばバッチアプリケーション１がデータベースにアクセスするプログラムであった場合には，ＤＢディスコネクト処理を実行する部分である。また，バッチアプリケーション１がＪａｖａプログラムであった場合には，ＪａｖａＶＭを終了させる処理などを実行する部分である。
【００２３】
バッチアプリ呼出し部４２は，バッチ実行プロセス２のバッチアプリ実行命令部２４からの実行命令により，指定されたバッチアプリケーション１を呼び出して実行する処理部である。バッチアプリケーション１は，プログラム実行制御部４のスレッド上で関数呼出し，もしくはサブルーチン呼出しのような形態で動作する。オブジェクト指向システムの場合には，バッチアプリケーション１は，一つまたは複数のオブジェクトとして実現されてもよい。
【００２４】
プログラム実行制御部４は，バッチ実行プロセス２から生成され，起動されると，最初に一度だけバッチアプリ共通処理部４０による処理を実行し，その後は，バッチアプリ実行命令部２４からの実行命令によって一度に一つのバッチアプリケーション１を呼び出す。そのバッチアプリケーション１の処理が終了すると，次のバッチアプリケーション１の実行命令受付け可能状態になり，終了の指示があるまで，各実行命令に対し，バッチアプリ呼出し部４２によるバッチアプリケーション１の呼び出しを繰り返す。バッチ実行プロセス２から実行終了指示があると，最後に一度だけバッチアプリ共通処理部４１による処理を実行し，終了する。
【００２５】
図１に示す例では，バッチアプリケーションＡ，Ｂ，Ｃ…の実行依頼に対して，プログラム実行制御部４が，最初にバッチアプリ共通処理部４０による処理を実行した後，バッチアプリ実行命令部２４からの実行命令（Ａ）に対し，バッチアプリ呼出し部４２によってバッチアプリケーションＡを呼び出して処理させ，プログラム実行制御部４’は，バッチアプリ共通処理部４０’の実行後，実行命令（Ｂ）に対し，バッチアプリ呼出し部４２’によって，バッチアプリケーションＢを呼び出して処理させている。他の実行依頼Ｃ，Ｄ，Ｅ，…は，実行待ちキュー２３に接続されている。
【００２６】
バッチアプリケーションＡの実行が終了すると，バッチアプリ実行命令部２４からの次の実行命令（Ｃ）により，プログラム実行制御部４のバッチアプリ呼出し部４２は，バッチアプリケーションＣを呼び出して処理させる。
【００２７】
従来技術では，各バッチアプリケーション毎にＤＢコネクト処理などのバッチアプリ共通処理部４０による処理を実行することが必要であったのに対し，本発明では，プログラム実行制御部４が実行するので，各バッチアプリケーション１におけるバッチアプリ共通処理部４０の処理は不要となる。
【００２８】
図２は，本発明の実施の形態によるバッチアプリケーションの実行制御の例を説明する図である。本実施の形態では，図１のバッチアプリ共通処理部４０の処理がＤＢコネクトであり，バッチアプリ共通処理部４１の処理がＤＢディスコネクトであるものとする。
【００２９】
図中の３はバッチ実行プロセス２にバッチアプリケーションの実行依頼をする起動プロセス，５は起動プロセス３の起動に必要なパラメタが書き込まれたパラメタファイル，６は実行プログラム名等のバッチアプリケーションを特定する情報が書き込まれたバッチアプリ情報ファイル，７はバッチ実行プロセス２の初期化に必要な情報が書き込まれた初期化ファイル，８はバッチ実行プロセス名，実行多重度，ログファイルのファイル数等の情報が書き込まれたパラメタファイルである。
【００３０】
パラメタファイル５は，起動プロセス３を起動させるために読み込まれる。また，初期化ファイル７およびパラメタファイル８は，バッチ実行プロセス２を起動させるために読み込まれる。
【００３１】
以下，図２に示す（ａ）〜（ｆ）に従って，本実施の形態の動作例を説明する。
（ａ）まず，初期化ファイル７の内容とパラメタファイル８の内容を読み込み，バッチ実行プロセス２を起動させる。
（ｂ）バッチ実行プロセス２は，パラメタファイル８の内容をもとにプログラム実行制御部（スレッド）４を生成する。そして，バッチ実行プロセス２は，初期化ファイル７の内容をもとにプログラム実行制御部（スレッド）４に命令を出し，プログラム実行制御部（スレッド）４毎にＤＢコネクトさせる。
（ｃ）その後，バッチアプリケーション１の実行依頼をするために，パラメタファイル５，バッチアプリ情報ファイル６を読み込み，起動プロセス３を立ち上げる。
（ｄ）起動プロセスは３，パラメタファイル５とコマンド引数で渡されるバッチアプリ情報ファイル６の内容をもとに，バッチ実行プロセス２にバッチアプリケーション１の実行処理を依頼する。なお，起動プロセス３からバッチ実行プロセス２への実行依頼には，ＴＣＰ／ＩＰの通信プロトコルを用いる。
（ｅ）バッチ実行プロセス２は起動プロセス３からの実行依頼を受けると，受け付けた実行依頼のパラメタを取り込み，実行可否の条件を判定し，現在空いているプログラム実行制御部（スレッド）４に実行命令を出す。現在空いているプログラム実行制御部（スレッド）４が存在しない場合には，受け付けた実行依頼を実行待ちキュー２３にキューイングし，実行待ち状態にする。
（ｆ）バッチアプリケーション１の実行命令を受けたプログラム実行制御部（スレッド）４は，指定された実行プログラム名のバッチアプリケーション１を起動する。バッチアプリケーション１の実行が終了した場合には，実行終了をバッチ実行プロセス２に報告し，次のバッチアプリケーション１の実行命令を待つ。
【００３２】
すべてのバッチアプリケーション１の実行を終了した後に，プログラム実行制御部（スレッド）４は，バッチ実行プロセス２からの指示によりＤＢディスコネクトを行い，スレッドを閉じる。
【００３３】
上記のように，本発明の実施の形態では，システムの起動時に生成した複数のプログラム実行制御部（スレッド）４毎に一度だけＤＢへの接続処理（コネクト）を実施し，システムの終了時に一度だけＤＢへの切断処理（ディスコネクト）を実施する。また，バッチアプリケーション１の実施の際には，必ずプログラム実行制御部（スレッド）４からバッチアプリケーション１を呼び出す。プログラム実行制御部（スレッド）４内では，すでにＤＢへのコネクト処理を完了し，コネクト状態が保持されているため，バッチアプリケーション１毎にＤＢへのコネクト／ディスコネクト処理をする必要がなくなる。
【００３４】
図３は，本発明の実施の形態における初期処理のフローを示す図である。本システムを立ち上げる場合，まず，バッチ実行プロセス２を起動させるために，初期化ファイル７の読み込みを行う（ステップＳ１）。初期化ファイル７の一例（ＳＵＳＶＩＮＩＴ）を図４に示す。初期化ファイル７には，例えば図４に示すように，ＤＢアクセスするユーザ名，ＤＢアクセスするユーザのパスワード，インスタンス名，ログファイルの最大サイズ，ログを出力するレベル，ログファイルの最大数，インスタンスのＵＲＬ（Ｊａｖａの場合），ＪＤＢＣ（Java Database Connectivity）のドライバ名（Ｊａｖａの場合），また，ＣＯＢＯＬ業務アプリケーションを実行するかどうかの情報が書き込まれている。ＪＤＢＣは，ＪａｖａプログラムからＤＢにアクセスするための標準アプリケーションプログラムインタフェース（ＡＰＩ）である。
【００３５】
次に，パラメタファイル８の読み込みを行う（ステップＳ２）。パラメタファイル８の一例（fbdef.txt ）を図５に示す。パラメタファイル８には，例えば図５に示すように，バッチ実行プロセス名，Ｃ／ＣＯＢＯＬ／Ｊａｖａといった言語の種別，ポート番号（Ｎｏ），生成するプログラム実行制御部（スレッド）４の数を示す実行多重度，実行待ちとして接続できる最大実行依頼数であるキューの最大数（ＭＡＸキュー），パラメタファイルを複写する作業フォルダ，ログファイルを書き込むフォルダ，ログファイルのファイル数等の情報が書き込まれている。
【００３６】
上記初期化ファイル７，パラメタファイル８の読み込み処理（ステップＳ１，Ｓ２）が行われることにより，バッチ実行プロセス２の起動が行われる（ステップＳ３）。その後，バッチ実行プロセス２によって，パラメタファイル８で指定された実行多重度の数分のプログラム実行制御部（スレッド）４の生成が行われる（ステップＳ４）。
【００３７】
図６は，本発明の実施の形態におけるプログラム実行制御部（スレッド）生成処理のフローを示す図である。まず，バッチ実行プロセス２は，パラメタファイル実行多重度数分のプログラム実行制御部（スレッド）４を生成する（ステップＳ１１）。プログラム実行制御部（スレッド）４を開始する（ステップＳ１２）。プログラム実行制御部（スレッド）４は，最初にＤＢコネクトして（ステップＳ１３），実行命令を待つ。バッチ実行プロセス２は，すべてのプログラム実行制御部（スレッド）４を生成した後，実行依頼を待つ。
【００３８】
図７は，本発明の実施の形態におけるバッチアプリケーション実行処理フローを示す図である。バッチアプリケーション１を実行させる場合，オペレータの指示により，またはシステムの自動起動処理により，起動プロセス３を起動させるために，まず，パラメタファイル５の読み込みを行う（ステップＳ２１）。パラメタファイル５の一例（fbdef.txt ）を図８に示す。パラメタファイル５には，例えば図８に示すように，バッチ実行プロセス名，Ｃ／ＣＯＢＯＬ／Ｊａｖａといった言語の種別，ポート番号（Ｎｏ），実行多重度，キューの最大数が書き込まれている。
【００３９】
次に，バッチアプリ情報ファイル６の読み込みを行う（ステップＳ２２）。バッチアプリ情報ファイル６の一例（inp1.txt）を図９に示す。バッチアプリ情報ファイル６には，例えば図９に示すように，実行プログラム名，打切り経過時間，データ１，データ２，会社コード，拠点コードというように，バッチアプリケーション１の実行に必要な情報が書き込まれている。
【００４０】
具体的には，図９に示すバッチアプリ情報ファイル６に書き込まれた情報中，「ｐｇｍ＝ｐｇｍ１」は，バッチ実行プロセス２上で実行させるバッチアプリケーション名（「ｐｇｍ１」）を探すキーであり，「ｔｉｍｅ＝２０」は，バッチ実行プロセス２上で待ちの場合，待機させておくタイムアウトが２０秒であることを示す。
【００４１】
また，「ｄａｔａ１＝１１１１１１１１」，「ｄａｔａ２＝２２２２２２２」は，実行させるバッチアプリケーション１固有の引数であり，「ｃｄｃｏｍｐａｎｙ＝０００」は，実行させるバッチアプリケーション１上で，ＤＢ領域への検索に使用する会社コードのキーであり，「ｃｄｓｔｏｒｅ＝０００」は，実行させるバッチアプリケーション１上で，ＤＢ領域への検索に使用する拠点コードのキーである。
【００４２】
次に，起動プロセス３の起動が行われる（ステップＳ２３）。その後，図１０に示すバッチ実行プロセス処理が行われる（ステップＳ２４）。バッチ実行プロセス２からの実行命令により，プログラム実行制御部（スレッド）４がバッチアプリケーション１の呼び出し処理を行い（ステップＳ２５），バッチアプリケーション１を実行する（ステップＳ２６）。
【００４３】
図１０は，図７のステップＳ２４におけるバッチ実行プロセス処理のフローを示す図である。まず，バッチ実行プロセス２が，起動プロセス３から実行依頼を受ける（ステップＳ３１）。次に，現在の実行待ちキュー２３中の実行依頼数がＭＡＸキューの値（最大待ち実行依頼数）になったかどうかを判定し（ステップＳ３２），現在の待ち実行依頼数がＭＡＸキューの値になった場合には，エラー情報設定をして，起動プロセス３に実行依頼を受け付けできない旨を通知する（ステップＳ３５）。
【００４４】
現在の待ち実行依頼数がＭＡＸキューの値より小さい場合には，実行多重度とアクティブスレッド数が異なるか否かを判定する（ステップＳ３３）。すなわち，現在バッチアプリケーション１を実行していない空きスレッドがあるかどうかを判定する。空きスレッドがあった場合，そのプログラム実行制御部（スレッド）４に実行命令を送り，バッチアプリケーション１を実行させる（ステップＳ３４）。実行多重度とアクティブスレッドの数が同じであり，空きスレッドがない場合には，受け付けた実行依頼を実行待ちキュー２３にキューイングし，空きスレッドができるまで待つ（ステップＳ３６）。
【００４５】
図１１は，本発明の実施の形態における終了処理のフローを示す図である。すべてのバッチアプリケーション１の終了により，またはオペレータ等の指示により，バッチ実行プロセス２の終了指示が行われると（ステップＳ４１），バッチ実行プロセス２は，まず，すべてのプログラム実行制御部（スレッド）４に終了指示を出す（ステップＳ４２）。プログラム実行制御部（スレッド）４は，ＤＢディスコネクトを行い（ステップＳ４３），終了する（ステップＳ４４）。バッチ実行プロセス２は，プログラム実行制御部（スレッド）４の終了を確認した後，終了する（ステップＳ４５）。
【００４６】
図１２は，バッチアプリケーション起動までのデータの流れを示す図である。（１）図１２（Ａ）に示すバッチアプリ情報ファイル６を起動プロセス３に読み込ませる。
（２）起動プロセス３で読み込まれたデータをバッチ実行プロセス２にＴＣＰ／ＩＰ通信で図１２（Ｂ）に示す電文形式で送信する。
（３）起動プロセス３から送信されたきた電文をもとに，バッチ実行プロセス２上で図１２（Ｃ）に示すようなハッシュマップを作成する。ハッシュマップとは，バッチアプリケーション１の実行に必要なパラメタおよびキーを集めたデータである。
（４）空いているプログラム実行制御部（スレッド）４に，図１２（Ｃ）に示すハッシュマップを送る。空きスレッドがない場合，タイムアウト値まで空きスレッドができるのを待つ。タイムアウト値を超えた場合には，処理をしないで，エラー終了とする。
（５）図１２（Ｄ）に示すハッシュマップのデータを引数にして，バッチアプリケーション「ｐｇｍ１」を実行させる。ｐｇｍ１内の処理で，引数の各キーをもとにデータを入力する。
【００４７】
図１３は，本発明の実施の形態におけるバッチアプリケーション実行処理のシーケンス図である。図１３では，ＤＢにコネクトしてデータ操作を行い，操作終了後にＤＢからディスコネクトする処理を行う業務アプリケーションであるバッチアプリケーションＡおよびバッチアプリケーションＢの実行処理を例にとって説明する。また，業務アプリケーション（バッチアプリケーションＡ，バッチアプリケーションＢ）は，例えば，Ｊａｖａで開発されているものとする。
【００４８】
図１３において，まず，バッチ実行プロセス２が起動すると（ａ），バッチ実行プロセス２は，プログラム実行制御部（スレッド）４を生成し，プログラム実行制御部（スレッド）４に命令を出してＤＢコネクトさせる（ｂ）。
【００４９】
次に，起動プロセス３が起動すると（ｃ），起動プロセス３は，バッチ実行プロセス２に実行依頼を行う（ｄ）。バッチ実行プロセス２は，現在空いているプログラム実行制御部（スレッド）４に実行命令を出す（ｅ）。実行命令を受けたプログラム実行制御部（スレッド）４は，業務アプリクラスを生成し，バッチアプリケーションＡを呼び出して実行する（ｆ）。実行処理が完了すると，バッチ実行プロセス２が，プログラム実行制御部（スレッド）４から実行完了通知を受ける（ｇ）。
【００５０】
再度，起動プロセス３が起動すると（ｈ），起動プロセス３は，バッチ実行プロセス２に実行依頼を行う（ｉ）。バッチ実行プロセス２は，現在空いているプログラム実行制御部（スレッド）４に実行命令を出す（ｊ）。実行命令を受けたプログラム実行制御部（スレッド）４は，業務アプリクラスを生成し，バッチアプリケーションＢを呼び出して実行する（ｋ）。
【００５１】
バッチ実行プロセス２は，プログラム実行制御部（スレッド）４から実行完了通知を受け（ｌ），その後，実行すべきバッチアプリケーションがないことを確認すると，プログラム実行制御部（スレッド）４に命令を出してＤＢディスコネクトさせ，終了処理を行う（ｍ）。
【００５２】
以上から把握できるように，本発明の実施の形態の特徴を述べると，以下のようである。
【００５３】
（付記１）複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，
１または複数のプログラム実行制御部を生成するステップと，
前記生成された１または複数のプログラム実行制御部が，最初に前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，
前記共通処理の実行後に，前記バッチアプリケーションを順次，一つのプログラム実行制御部が一つずつ呼び出して実行する処理を，すべてのバッチアプリケーションの実行が終了するまで繰り返すステップとを有する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５４】
（付記２）複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，
前記複数のバッチアプリケーションの実行を制御するためのバッチ実行プロセスを起動するステップと，
前記バッチ実行プロセスが，プログラム実行制御部を複数生成するステップと，
前記生成された複数のプログラム実行制御部毎に，最初に前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，
前記バッチ実行プロセスが，前記バッチアプリケーションの実行依頼を受け付けるステップと，
前記バッチ実行プロセスが，前記実行依頼を受け付けたバッチアプリケーションの実行を，現在バッチアプリケーションを実行していないプログラム実行制御部に指示するステップと，
前記実行指示を受けたプログラム実行制御部が，指示されたバッチアプリケーションを呼び出して実行するステップとを有する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５５】
（付記３）付記２に記載のバッチアプリケーション実行制御方法において，
前記バッチ実行プロセスが，前記プログラム実行制御部を複数生成するステップでは，前記バッチ実行プロセスの起動時に読み込んだ情報に含まれる実行多重度数分のプログラム実行制御部を生成する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５６】
（付記４）付記１から付記３までのいずれか１項に記載のバッチアプリケーション実行制御方法において，
さらに，前記プログラム実行制御部が，終了する前に，前記バッチアプリケーションの終了時に共通に必要となる共通処理を実行するステップを有する
ことを特徴とするバッチアプリケーション実行制御方法。
【００５７】
（付記５）複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御装置であって，
バッチ実行制御手段と，複数のプログラム実行制御手段とを備え，
前記バッチ実行制御手段は，
前記バッチアプリケーションの実行依頼を受け付ける手段と，
前記プログラム実行制御手段に対し，前記実行依頼を受け付けたバッチアプリケーションの実行指示を行う手段とを備え，
前記複数のプログラム実行制御手段の各々は，
最初に前記複数のバッチアプリケーションに共通に必要となる共通処理を実行する手段と，
前記バッチ実行制御手段からのバッチアプリケーションの実行指示に対し，指示されたバッチアプリケーションを呼び出して実行する手段とを備える
ことを特徴とするバッチアプリケーション実行制御装置。
【００５８】
（付記６）付記１から付記４までのいずれか１項に記載のバッチアプリケーション実行制御方法を，コンピュータに実行させるためのバッチアプリケーション実行制御プログラム。
【００５９】
（付記７）付記１から付記４までのいずれか１項に記載のバッチアプリケーション実行制御方法を，コンピュータに実行させるためのバッチアプリケーション実行制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【００６０】
【発明の効果】
本発明により，バッチアプリケーションを高速に処理することができるため，夜間時などに行う定期バッチアプリケーションの処理時間を短縮することが可能となる。
【００６１】
また，本発明を用いることにより，例えば，データベースのコネクト／ディスコネクト処理やＪａｖａＶＭの起動処理を，バッチアプリケーション毎に行わなくてよいので，システム全体の負荷を軽減することが可能となる。
【図面の簡単な説明】
【図１】本発明を実施する装置の構成例を示す図である。
【図２】本発明の実施の形態によるバッチアプリケーションの実行制御の例を説明する図である。
【図３】初期処理のフローを示す図である。
【図４】初期化ファイルの一例を示す図である。
【図５】パラメタファイルの一例を示す図である。
【図６】プログラム実行制御部（スレッド）生成処理のフローを示す図である。
【図７】バッチアプリケーション実行処理フローを示す図である。
【図８】パラメタファイルの一例を示す図である。
【図９】バッチアプリ情報ファイルの一例を示す図である。
【図１０】バッチ実行プロセス処理のフローを示す図である。
【図１１】終了処理のフローを示す図である。
【図１２】バッチアプリケーション起動までのデータの流れを示す図である。
【図１３】バッチアプリケーション実行処理のシーケンス図である。
【図１４】従来のバッチアプリケーションの動作説明図である。
【符号の説明】
１，１１ バッチアプリケーション
２ バッチ実行プロセス
３ 起動プロセス
４ プログラム実行制御部（スレッド）
５ パラメタファイル
６，１０ バッチアプリ情報ファイル
７ 初期化ファイル
８ パラメタファイル
２０ プログラム実行制御部生成部
２１ 実行依頼受付け部
２２ 実行待ち管理部
２３ 実行待ちキュー
２４ バッチアプリ実行命令部
４０，４１ バッチアプリ共通処理部
４２ バッチアプリ呼出し部
１００ データ処理装置
Claims (5)
- 複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，
１または複数のプログラム実行制御部を生成するステップと，
前記生成された１または複数のプログラム実行制御部が，該プログラム実行制御部で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，
前記共通処理の実行後に，前記バッチアプリケーションを順次，一つのプログラム実行制御部が一つずつ呼び出して実行する処理を，終了の指示があるまで繰り返すステップとを有する
ことを特徴とするバッチアプリケーション実行制御方法。 - 複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御方法であって，
前記複数のバッチアプリケーションの実行を制御するためのバッチ実行プロセスを起動するステップと，
前記バッチ実行プロセスが，プログラム実行制御部を複数生成するステップと，
前記生成された複数のプログラム実行制御部毎に，該プログラム実行制御部で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行するステップと，
前記バッチ実行プロセスが，前記バッチアプリケーションの実行依頼を受け付けるステップと，
前記バッチ実行プロセスが，前記実行依頼を受け付けたバッチアプリケーションの実行を，現在バッチアプリケーションを実行していないプログラム実行制御部に指示するステップと，
前記実行指示を受けたプログラム実行制御部が，指示されたバッチアプリケーションを呼び出して実行するステップとを有する
ことを特徴とするバッチアプリケーション実行制御方法。 - 請求項２に記載のバッチアプリケーション実行制御方法において，
前記バッチ実行プロセスが，前記プログラム実行制御部を複数生成するステップでは，前記バッチ実行プロセスの起動時に読み込んだ情報に含まれる実行多重度数分のプログラム実行制御部を生成する
ことを特徴とするバッチアプリケーション実行制御方法。 - 複数のバッチアプリケーションの実行を制御するバッチアプリケーション実行制御装置であって，
バッチ実行制御手段と，複数のプログラム実行制御手段とを備え，
前記バッチ実行制御手段は，
前記バッチアプリケーションの実行依頼を受け付ける手段と，
前記プログラム実行制御手段に対し，前記実行依頼を受け付けたバッチアプリケーションの実行指示を行う手段とを備え，
前記複数のプログラム実行制御手段の各々は，
該プログラム実行制御手段で実行すべきバッチアプリケーションのうち最初に呼び出して実行するバッチアプリケーションを呼び出す前に，前記複数のバッチアプリケーションに共通に必要となる共通処理を実行する手段と，
前記バッチ実行制御手段からのバッチアプリケーションの実行指示に対し，指示されたバッチアプリケーションを呼び出して実行する手段とを備える
ことを特徴とするバッチアプリケーション実行制御装置。 - 請求項１から請求項３までのいずれか１項に記載のバッチアプリケーション実行制御方法を，コンピュータに実行させるためのバッチアプリケーション実行制御プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003161556A JP4071678B2 (ja) | 2003-06-06 | 2003-06-06 | バッチアプリケーション実行制御方法，バッチアプリケーション実行制御装置およびバッチアプリケーション実行制御プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003161556A JP4071678B2 (ja) | 2003-06-06 | 2003-06-06 | バッチアプリケーション実行制御方法，バッチアプリケーション実行制御装置およびバッチアプリケーション実行制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004362376A JP2004362376A (ja) | 2004-12-24 |
| JP4071678B2 true JP4071678B2 (ja) | 2008-04-02 |
Family
ID=34053936
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003161556A Expired - Fee Related JP4071678B2 (ja) | 2003-06-06 | 2003-06-06 | バッチアプリケーション実行制御方法，バッチアプリケーション実行制御装置およびバッチアプリケーション実行制御プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4071678B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4801761B2 (ja) | 2009-08-12 | 2011-10-26 | 株式会社日立製作所 | データベース管理方法およびシステム並びにその処理プログラム |
-
2003
- 2003-06-06 JP JP2003161556A patent/JP4071678B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004362376A (ja) | 2004-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8332845B2 (en) | Compile timing based on execution frequency of a procedure | |
| KR100763316B1 (ko) | 그리드에서 상태 정보를 입수하기 위한 방법 및 장치 | |
| US7330872B2 (en) | Method for distributed program execution with web-based file-type association | |
| US7117243B2 (en) | Methods for distributed program execution with file-type association in a client-server network | |
| US6237005B1 (en) | Web server mechanism for processing multiple transactions in an interpreted language execution environment | |
| US5504898A (en) | Threaded environment for AS/400 | |
| US6952714B2 (en) | Method for distributed program execution with server-based file type association | |
| CA2462271C (en) | Methods for distributed program execution with file-type association in a client-server network | |
| JP5347016B2 (ja) | 仮想サーバを効率的に管理および構成するための方法ならびにシステム | |
| JP4242458B2 (ja) | ライセンス管理システム | |
| US8458727B2 (en) | Asynchronous client to server updates | |
| US8136127B1 (en) | System and method for linearly managing client-server communication | |
| CN112668386A (zh) | 使用机器人过程自动化用于文档处理的长时间运行工作流 | |
| US8789058B2 (en) | System and method for supporting batch job management in a distributed transaction system | |
| JP2001249907A (ja) | 起動処理方式 | |
| TW200828118A (en) | Method and process for using common preinstallation environment for heterogeneous operating systems | |
| US6938257B1 (en) | Apparatus and method to provide persistence for application interfaces | |
| WO2021022714A1 (zh) | 跨区块链节点的消息处理方法及装置、设备、介质 | |
| JP3307329B2 (ja) | ネットワーク構成管理対象アクセスシステム及び方法 | |
| US20040049544A1 (en) | In-context launch management method, system therefor, and computer-readable storage medium | |
| JP4071678B2 (ja) | バッチアプリケーション実行制御方法，バッチアプリケーション実行制御装置およびバッチアプリケーション実行制御プログラム | |
| JP2007141056A (ja) | 情報処理システムおよびライセンス管理方法 | |
| JP2013186765A (ja) | バッチ処理システム、進捗状況確認装置、進捗状況確認方法、及びプログラム | |
| JP3586943B2 (ja) | プログラムロード装置と方法 | |
| WO2011118048A1 (ja) | プログラム実行方法、計算機システム及びプログラム実行制御プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070612 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070808 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080115 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080117 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4071678 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110125 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110125 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120125 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130125 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130125 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140125 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |