JPH0916521A - 並列バッチ処理方式 - Google Patents

Abstract

(57)【要約】 【目的】 クライアント・サーバ型システムにおいて、
複数のバッチジョブを計画的かつ効率的に実行する。 【構成】 複数のクライアント端末２ａ〜２ｎが接続さ
れたサーバ端末１に、複数のバッチジョブを個々のクラ
イアント端末に割り当てるとともに、各バッチジョブの
走行条件及びその実行予定時刻を含むスケジュール情報
を生成するスケジュール情報生成部１５と、生成したス
ケジュール情報をクライアント端末毎に格納した実行管
理テーブル１７とを備えておく。また、クライアント端
末２ａ〜２ｎに、各々実行管理制御部２２とジョブ実行
部２３とを備え、実行管理テーブル１７に格納された自
端末宛のバッチジョブをその走行条件等にしたがって並
列的に自動実行するようにした。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、クライアント・サーバ
型システムにおける運用形態を支援する技術に係り、特
に、サーバ端末が割り当てた複数のクライアント端末に
より複数のバッチジョブを並列的に処理する方式に関す
る。

【０００２】

【従来の技術】従来、ホストマシンを中心とした運用系
処理は、全てミドルウエアパッケージのような、高機能
マシンを前提としたパッケージにより支援されている。
また、バッチジョブ走行に関しては、サーバ端末自体が
一括処理するか、サーバ端末以外の複数の端末が処理し
たジョブ結果をサーバ端末が統括管理する方式を採用す
るのが一般的である。

【０００３】

【発明が解決しようとする課題】近年、ダウンサイジン
グ等により、既存のホスト系モデルの処理環境を維持・
拡張しながら規模を縮小したクライアント・サーバ型シ
ステムの開発が進められている。このようなクライアン
ト・サーバ型システムでは、開発に際してホスト系モデ
ルが備えている機能をいかに効率的に実現するかが重要
な要素となる。しかし、現在のクライアント・サーバ型
システムの開発支援環境において、ホスト系と同等の運
用形態を支援する手段は提案されていないので、従来の
ミドルウエアパッケージのような機能を、相当の工数を
費やしながら新規に開発する必要があった。中でも、複
数のバッチジョブに関しては、従来より単なる縦並びの
ジョブ実行を支援しているパッケージは種々存在するも
のの、走行条件等を踏まえて効率的に運用系処理を支援
することは行われていなかった。

【０００４】本発明の課題は、かかる背景に鑑み、ダウ
ンサイジング等における、クライアント・サーバ型シス
テムのシステム開発支援環境において、従来のホスト系
と同等の運用形態を支援する技術を提供することにあ
る。

【０００５】

【課題を解決するための手段及び作用】本発明は、ハー
ドウエア技術の向上によりサーバ端末とクライアント端
末の性能の差が縮小されており、また、サーバ端末に複
数接続されるクライアント端末が常時稼働しているとは
限らないという点に着目し、クライアント端末を有効に
活用して複数のバッチジョブ処理の効率化を図ろうとし
たものである。

【０００６】具体的には、サーバ端末に、複数のバッチ
ジョブを個々のクライアント端末に割り当てるとともに
各バッチジョブの走行条件及びその実行予定時刻を含む
スケジュール情報を生成するスケジュール情報生成部
と、生成したスケジュール情報をクライアント端末毎に
格納した実行管理テーブルとを備えておく。また、必要
に応じて、ログデータを各端末が随時参照可能に格納す
るログデータ管理部をも備えておく。一方、各クライア
ント端末には、前記実行管理テーブルに格納されたスケ
ジュール情報を取得する第１の手段、及び取得した実行
スケジュール情報に含まれる自端末宛のバッチジョブの
起動可否を判定する第２の手段を少なくとも備えた実行
管理制御部と、前記バッチジョブの起動が可能で且つ該
バッチジョブの実行予定時刻に達した時点で該バッチジ
ョブをその走行条件に従って起動実行するバッチジョブ
実行手段とを備えておく。この場合、前記実行管理部が
前記実行管理テーブルに格納された自端末宛のスケジュ
ール情報を更新する第３の手段をさらに備える構成であ
ってもよく、また、前記サーバ端末に、ログデータ（バ
ッチジョブにより加えられた変分情報を時系列に表した
データ）を各端末が随時参照可能に格納するログデータ
管理部を設けるとともに、前記実行管理部に、バッチジ
ョブの実行中に発生した前記ログデータを前記ログデー
タ管理部に時系列に格納する第４の手段を備える構成に
してもよい。

【０００７】スケジュール情報には、上記バッチジョブ
の走行条件や実行予定時刻のほか、システム稼働日にお
けるオンライン開始／終了時刻等を含ませることができ
る。また、例えば日次、週次、月次、旬次、年次等の基
準周期毎に生成しておくこともできる。

【０００８】クライアント端末は、実行管理制御部の第
１の手段で前記スケジュール情報を取得し、自端末宛の
スケジュール情報が存在するか否かを確認する。そし
て、自端末宛のものが存在する場合は、第２の手段でバ
ッチジョブの起動可否を判定する。この起動可否は、例
えばオンライン終了時刻を経過しているか否かで判定す
ることができる。すなわちデータの矛盾発生を防止する
ために、オンライン終了時刻を契機にオンラインを閉塞
してバッチジョブの起動を可能とし、オンライン開始時
刻を契機にオンライン閉塞を解除してバッチジョブの起
動を不可能にする。バッチジョブの起動が可能なとき
は、バッチジョブ実行手段が、スケジューリングされた
バッチジョブをその走行条件に従って実行する。

【０００９】なお、各クライアント端末に関わるスケジ
ュール情報は、当該クライアント端末の実行制御部（第
３の手段）から任意に修正（変更、追加等）することが
でき、前もって修正事項が判っている場合は、該修正後
のスケジュール情報を予約することができる。また、バ
ッチジョブの実行中にログデータをサーバ端末のログデ
ータ管理部に格納し、故障発生時に随時これを参照する
ようにすることもできる。このログデータ管理部は、ど
の端末からも参照可能なので、どのクライアント端末で
何のバッチジョブが何時何分に開始され、何時何分に終
了したか、正常に終了しているかどうかの確認も可能に
なる。

【００１０】

【実施例】次に、図面を参照して本発明の実施例を詳細
に説明する。図１は、本発明の一実施例に係るオンライ
ンシステムの構成図であり、一つのサーバ端末１と複数
のクライアント端末２ａ〜２ｎとをＬＡＮ等の通信路３
を介して接続して成る。

【００１１】サーバ端末１は、通信路３とのインタフェ
ースとなるＩ／Ｏ制御部１１のほか、クライアント情報
設定部１２、バッチジョブ設定部１３、スケジュール情
報設定部１４、スケジュール情報生成部１５、業務ＡＰ
格納部１６、実行管理テーブル１７、ジョブデータ格納
部１８、及びログデータ管理部１９を備えて構成され
る。一方、クライアント端末２ａ〜２ｎは、それぞれ通
信路３とのインタフェースとなるＩ／Ｏ制御部２１のほ
か、実行管理制御部２２、バッチジョブ実行部２３、及
びオンライン開閉塞制御部２４を備えて構成される。な
お、第１クライアント端末２ａのみの構成を示している
が、他のクライアント端末２ｂ〜２ｎについても基本的
には同様の構成となる。

【００１２】まず、サーバ端末１の構成を具体的に説明
する。クライアント情報設定部１２は、システムで使用
する全クライアント情報の登録と、登録したクライアン
ト端末毎のバッチジョブ開始時刻等を設定するものであ
り、バッチジョブ設定部１３は、各クライアント端末に
割り当てるバッチジョブを決定するとともに、システム
の営業日情報、営業日におけるオンライン開始／終了時
刻、日付変更時刻、休業日等を設定するものである。ま
た、バッチジョブの起動周期、すなわち日次、周次、旬
次、月次、季次、年次での詳細情報（実施日、曜日、
月、間隔、周期が休日にあたった場合の処理等）をも必
要に応じて設定することができる。スケジュール情報設
定部１４は、どの起動周期で何のバッチジョブ（起動業
務ＡＰ）を起動するか、そのバッチジョブを走行させる
クライアント端末はどこか、エラー時の後処理（リトラ
イ、中断、次処理へスキップ等）をどうするか、オンラ
イン中での実行可否、集計処理のクリア／繰り越しの有
無、バッチジョブの自動／手動指定、バッチジョブの走
行条件（何のジョブが終わっていないと実行できない等
の指定）等を設定するものである。

【００１３】スケジュール情報生成部１５は、上記各種
設定情報に基づいて実行管理テーブル１７内に日次スケ
ジュールテーブルのデフォルト値を自動生成するもので
ある。実行管理テーブル１７の詳細については後述す
る。業務ＡＰ格納部１６は、各クライアント端末２ａ〜
２ｎが随時参照可能なバッチジョブ起動用の業務プログ
ラムを格納しておくものであり、ジョブデータ格納部１
８は、各クライアント端末２ａ〜２ｎが実行したジョブ
データを格納するものである。なお、業務ＡＰ格納部１
６とジョブデータ格納部１８は一体構成であってもよ
い。ログデータ管理部１９は、各クライアント端末２ａ
〜２ｎから送られるログデータを、サーバ端末１を含
め、全てのクライアント端末２ａ〜２ｎからも参照可能
に格納するものである。このログデータは、どのクライ
アント端末で何のバッチジョブが何時何分に開始され、
何時何分に終了したかをも表すものである。

【００１４】次に、実行管理テーブル１７について説明
する。この実行管理テーブル１７はシステムに一つだけ
存在し、ホスト端末１のほか、各クライアント端末２ａ
〜２ｎからも随時参照、更新可能なものである。その構
造は、図２に示すように、バッチジョブの走行日及び登
録クライアント毎に日次スケジュールテーブル１７Ａ〜
１７Ｎが複数格納されている。このように、複数のもの
を図示しているのは、上述のようにサーバ端末１で生成
するほか、各クライアントＡ〜Ｎ側から予約等により生
成できることを意味している。日次スケジュールテーブ
ル１７Ａ〜１７Ｎのパートは、タイムテーブル部とクラ
イアント情報部とバッチシーケンス部とに分かれ、各々
情報のリンクがなされている。各部に格納される情報の
一例、及び各部間のリンク状態を図３に示す。

【００１５】図２及び図３に示すように、タイムテーブ
ル部は、日次スケジュールテーブルに一つだけ存在し、
そのテーブル全体で利用する情報、例えば、バッチジョ
ブの走行日や、この走行日とリンクして読み出したオン
ライン開始／終了時刻、日付切替時刻等がデフォルトで
設定されている。

【００１６】また、クライアント情報部は、個々の日次
スケジュールテーブルに登録クライアント個数分存在し
て、クライアント固有の情報が随時修正可能に設定され
ている。そして、タイムテーブル部の「走行日」とクラ
イアント情報部の「走行日」が一致するものを取得する
ことで、設定されたクライアント情報を取得することが
できるようになっている。

【００１７】バッチシーケンス部は、クライアント単位
にスケジュール項目数分存在し、バッチシーケンス順
（周期順）にソートされている。クライアント情報部の
「走行日」、「クライアント識別（図３の例ではクライ
アントＡ）」とバッチシーケンス部の「走行日」、「ク
ライアント識別」の一致するものを取得することで、ク
ライアント単位の日次スケジュール項目を取得できるよ
うになっている。

【００１８】図４は、このような設定内容の日付スケジ
ュールテーブルの内容を、図示しないモニタ手段によっ
てモニタする場合の表示例であり、クライアント端末Ａ
について索出した日次スケジュール項目の内容が示され
ている。これらの項目は、サーバ端末１がデフォルトで
設定したものであるが、クライアントＡ側から、変更、
追加、削除、移動を随時選択的に行うことができる。

【００１９】次に、図１、図５及び図６を参照して、ク
ライアント端末２ａの構成について説明する。実行管理
制御部２２は、サーバ端末１との間でバッチジョブの起
動実行に関するデータの授受を行うとともに、自端末内
の統括制御を司るものであり、バッチジョブ実行部２２
は、自端末宛のバッチジョブを実行するものである。オ
ンライン開閉塞制御部２４は、バッチジョブの実行に先
だってオンラインを閉塞し、バッチジョブの実行終了後
にオンライン閉塞を解除するものである。

【００２０】実行管理制御部２２の具体的なモジュール
構成図を図５に示す。この実行管理制御部２２は、実行
管理テーブル１７、業務ＡＰ格納部１６、ジョブデータ
格納部１８、及びログデータ管理部１９にアクセス（情
報参照、更新等）するサーバアクセス制御部２２１と、
サーバ端末１より取得した情報に含まれるクライアント
識別の内容を認識するクライアント識別部２２２と、オ
ンライン開始／終了時刻や自端末宛のスケジュール情報
がスケジューリングされている時刻に達しているか否か
を監視する時間情報監視部２２３と、バッチジョブが現
在どのくらい消化されているか（処理済み、未処理、実
行中）を監視するジョブ走行監視部２２４と、バッチジ
ョブの起動処理を行うバッチジョブ起動プロセス実行部
２２５とをこの順に配するとともに、実行管理テーブル
１７に格納された自端末に関する日次スケジュールテー
ブル１７Ａ〜１７Ｎの内容の修正や予約等を、例えば図
６に示す表示画面例に従って行うスケジュール設定部２
２６を備えて構成される。

【００２１】次に、上記構成のオンラインシステムにお
いて、複数のクライアント端末２ａ〜２ｎによるバッチ
ジョブの実行手順を図７〜図９に従って説明する。これ
らの図において、Ｓは処理ステップを表す。

【００２２】図７は運用定義（情報設定）系の処理手順
図であり、まず、サーバ端末１が、バッチジョブ名や実
行開始時刻等の走行条件、オンライン開始／終了時刻、
日付切替時刻等を取得し（Ｓ１０１）、各情報の編集
後、各バッチジョブの走行日に関する日次スケジュール
テーブル１７Ａを生成し（Ｓ１０２）、これを実行管理
テーブル１７に格納する（Ｓ１０３）。このときの日次
スケジュールテーブル１７の内容はサーバ端末１側が定
めたデフォルト値であり、クライアント端末２ａ〜２ｎ
側で修正する必要がない場合、あるいはクライアント端
末側２ａ〜２ｎからスケジュール予約がない場合は定義
系の処理を終える（Ｓ１０４）。なお、日付切替時刻に
達したときは翌日分の日次スケジュールテーブルを生成
する。

【００２３】一方、クライアント端末２ａ〜２ｎにおい
て、修正を必要とする場合は該当項目を更新し（Ｓ１０
５）、予約がある場合は予約テーブル（新たな日次スケ
ジュールテーブル）を生成して実行管理テーブル１７に
格納する（Ｓ１０６）。上記更新や予約テーブルの生成
はクライアント端末２ａ〜２ｎ側で行う。

【００２４】次に実行系の処理手順を説明する。図８
は、バッチジョブを実行するクライアント端末側におけ
る初期処理までの手順図である。該当クライアント端末
の実行管理制御部２２は、現在の自端末におけるジョブ
の実行状況と時間情報とを監視し（Ｓ２０１）、オンラ
インが閉塞時刻に達していることを確認した後（Ｓ２０
２）、サーバ端末１にアクセスして実行管理テーブル１
７を参照する（Ｓ２０３）。なお、実行管理テーブル１
７の参照は、オンライン運用中でも可能であり、またオ
ンラインの閉塞は手動によって任意の時刻に行うことが
できるが、本実施例では、便宜上それを考慮しないもの
とする。実行管理テーブル１７を参照した結果、自端末
宛にスケジュールされたものがあるか否かを判定し（Ｓ
２０４）、自端末宛のものである場合は初期処理を行う
（Ｓ２０５）。ここに、初期処理とは、例えばデータ保
全のために行う、関連ファイルやテーブルのバックアッ
プ処理や、その後のバッチジョブ起動プロセス実行のた
めの前処理をいう。

【００２５】初期処理実行後は、図９の処理手順に従っ
てバッチジョブを実行する。すなわち、バッチジョブ起
動プロセスを実行し（Ｓ３０１）、日次スケジュール項
目をゲットしたか否かを判定する（Ｓ３０２）。ゲット
したときは、自端末においてバッチジョブの起動実行が
可能か否かを判定し（Ｓ３０３）、実行不可の場合は初
期処理実行後のプロセスに戻る（Ｓ３０３：実行不
可）。実行可能の場合（Ｓ３０３：実行可）は、業務Ａ
Ｐ格納部１６にアクセスして該当プログラムを読み出
し、スケジューリングされた走行条件でバッチジョブを
実行し、実行結果をジョブデータ格納部に順次格納する
とともに（Ｓ３０４）、ログデータ管理部１９へのログ
データの書込を開始する（Ｓ３０５）。

【００２６】ジョブが途中で中断、再開、強制終了のイ
ベントが発生しないで終了したときは（Ｓ３０７）、ロ
グデータの書込を終了させる（Ｓ３０８）。次のシーケ
ンスのバッチジョブがあるときはＳ３０１の処理に戻
り、ないときは終了時処理を行う（Ｓ３１５）。一方、
Ｓ３０６において、中断イベントが発生したとき（Ｓ３
１０）は、当該バッチジョブの実行を一時停止し（Ｓ３
１３）、再開イベントが発生した時点で再開し（Ｓ３１
４）、再度Ｓ３０６に戻る。Ｓ３０２で日次スケジュー
ル項目をゲットできなかった場合（Ｓ３０２：Ｎｏ）、
あるいは強制終了イベントが発生した場合（Ｓ３１２）
は、直ちに終了時処理を行う。

【００２７】このようにして、各クライアント端末２ａ
〜２ｂは、実行管理テーブル１７に格納された日次スケ
ジュールテーブル１７を参照して各々自端末宛にスケジ
ューリングされたバッチジョブを並列的に自動実行す
る。これにより、システム全体における複数のバッチジ
ョブの処理時間が、サーバ端末１のみ、あるいはサーバ
端末１を中心に行う場合に比べて格段に短縮され、ホス
ト系システムとほぼ同様の運用処理能力、運用形態を確
保することができる。

【００２８】また、実行管理テーブル１７の格納情報を
クライアント端末側から修正、予約することができ、さ
らにログデータ管理部１９をどの端末からも参照できる
ようにしているので、個々のクライアント端末に何らか
のトラブルが発生しても、即座に対応をとることができ
る。

【００２９】

【発明の効果】以上の説明から明らかなように、本発明
によれば、サーバ端末に設けた実行管理テーブルに複数
のクライアント端末が随時アクセスし、該実行管理テー
ブルに格納されたバッチジョブのスケジュール情報にし
たがって各々自端末宛のバッチジョブを並列的に自動実
行するので、バッチジョブの処理効率が格段に高まる効
果がある。また、従来のホスト系システムとほぼ同等の
運用形態をサーバ端末側あるいはクライアント端末から
の修正、予約等による設定で実現できるため、運用形態
プログラムの開発ないしその支援プログラムの開発が容
易になる。

【図面の簡単な説明】

【図１】本発明の一実施例に係るオンラインシステムの
構成図。

【図２】本実施例による実行管理テーブルの構造説明
図。

【図３】本実施例による日付スケジュールテーブルの内
容説明図。

【図４】日付スケジュールテーブルの設定内容を確認す
るときの表示例を示す図。

【図５】本実施例の各クライアント端末が備える実行管
理制御部のモジュール構成図。

【図６】上記実行管理制御が備えるスケジュール設定部
の機能表示説明図。

【図７】運用定義系の処理手順図。

【図８】バッチジョブの実行時のクライアント端末の初
期処理手順図。

【図９】初期処理後のクライアント端末におけるバッチ
ジョブ実行手順図。

【符号の説明】

１ サーバ端末 １１ Ｉ／Ｏ制御部 １２ クライアント情報設定部 １３ バッチジョブ設定部 １４ スケジュール情報設定部 １５ スケジュール情報生成部 １６ 業務ＡＰ格納部 １７ 実行管理テーブル １８ ジョブデータ格納部 １９ ログデータ管理部 ２ａ〜２ｎ クライアント端末 ２１ Ｉ／Ｏ制御部２１ ２２ 実行管理制御部 ２２１ サーバアクセス制御部 ２２２ クライアント識別部 ２２３ 時間情報監視部 ２２４ ジョブ走行監視部 ２２５ バッチジョブ起動プロセス実行部 ２２６ スケジュール設定部 ２４ オンライン開閉塞制御部 ３ ＬＡＮ等の通信路

Claims (3)

【特許請求の範囲】
1. 【請求項１】 サーバ端末に複数のクライアント端末が
   接続されたクライアント・サーバ型システムにおけるバ
   ッチジョブの処理方式であって、 前記サーバ端末は、 複数のバッチジョブを個々のクライアント端末に割り当
   てるとともに、各バッチジョブの走行条件及びその実行
   予定時刻を含むスケジュール情報を生成するスケジュー
   ル情報生成部と、生成したスケジュール情報をクライア
   ント端末毎に格納した実行管理テーブルと、を備え、 各クライアント端末は、 前記実行管理テーブルに格納されたスケジュール情報を
   取得する第１の手段、及び取得した実行スケジュール情
   報に含まれる自端末宛のバッチジョブの起動可否を判定
   する第２の手段を少なくとも備えた実行管理制御部と、 前記バッチジョブの起動が可能で且つ該バッチジョブの
   実行予定時刻に達した時点で該バッチジョブをその走行
   条件に従って起動実行するバッチジョブ実行手段と、を
   有することを特徴とする並列バッチ処理方式。
2. 【請求項２】 前記実行管理部は、前記実行管理テーブ
   ルに格納された自端末宛のスケジュール情報を更新する
   第３の手段を備えることを特徴とする請求項１記載の並
   列バッチ処理方式。
3. 【請求項３】 前記サーバ端末は、ログデータ（バッチ
   ジョブにより加えられた変分情報を時系列に表したデー
   タ）を各端末が随時参照可能に格納するログデータ管理
   部を有し、前記実行管理部は、バッチジョブの実行中に
   発生した前記ログデータを前記ログデータ管理部に時系
   列に格納する第４の手段を備えることを特徴とする請求
   項１又は２記載の並列バッチ処理方式。