(57)【特許請求の範囲】
【請求項１】
予め登録されている任意数のジョブステップの内、バッチ処理条件に適合したジョブステップを選択的に実行するためのバッチジョブ管理方法であって、
コンピュータが、
バッチ処理の実行指示に呼応して、その時点で確定しているバッチ処理条件に照らして全ての前記ジョブステップについて個々に実行の要否を判定するステップと、
その判定結果に応じて実行すべきジョブステップのみから構成される実行ジョブを生成するステップと、
生成した前記実行ジョブのみをバッチジョブとして起動するステップと、
を実行することを特徴とするバッチジョブ管理方法。
【請求項２】
コンピュータに、全ての前記ジョブステップを含むバッチジョブモデルを設けておき、
前記実行ジョブを、前記バッチジョブモデルから実行不要の前記ジョブステップを削除することによって生成する
ことを特徴とする請求項１記載のバッチジョブ管理方法。
【請求項３】
バッチ処理の内容を特定する任意数のジョブステップを記憶し、バッチ処理条件に適合した前記ジョブステップを選択的に実行するデータ処理システムにおいて、
前記各ジョブステップに関係するリアルタイム処理の実行回数を記憶するファイルと、
バッチ処理の実行指示に呼応して前記ファイルを参照し、その時点の前記実行回数に基づいて、全ての前記ジョブステップについて個々に実行の要否を判定するジョブステップ判定手段と、
判定の結果に応じて実行すべき前記ジョブステップのみを組み合わせて実行ジョブを生成するジョブ生成手段と、
生成された前記実行ジョブのみをバッチジョブとして起動するジョブ起動手段と、
を備えたことを特徴とするデータ処理システム。
【請求項４】
前記実行ジョブの起動前に、前記実行ジョブの内容のプリントアウトを行う出力制御手段と、
コンソール操作に応じて前記実行ジョブの内容を変更するジョブ変更手段と
を備えたことを特徴とする請求項３記載のデータ処理システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、各種形態のデータ処理システムによるバッチ処理のジョブ管理方法に関する。
【０００２】
一般に、事業活動を支援するオンラインシステムでは、１日の内のオンライン停止期間に、集計やマスタファイルの更新などのバッチ処理が行われる。業務の多様化にともなって、必然的にバッチ処理の内容は豊富になり、処理時間が延びる。このため、特にシステム管理者の負担を軽減する上で、バッチ処理時間の短縮が望まれている。
【０００３】
【従来の技術】
毎日のバッチ処理におけるジョブの投入、すなわちジョブ制御文（ＪＣＳ）の入力作業の手間を省くため、予め所望のジョブとその実行の要否を規定する条件（バッチ処理条件）とを登録しておくことにより、オペレータがバッチ処理の実行開始を指示するだけで、条件に適合した実行すべきジョブを自動的に選択して実行するように構成されたシステムがある。例えば、日単位、月単位及び年単位の各売上帳票を出力する３つのジョブを登録した場合、月及び年単位の帳票は登録日に該当する日のみに作成される。
【０００４】
従来、この種のシステムでは、図７のように任意数のジョブＪ１〜ｎのそれぞれに実行の要否を判別するジョブステップｊｓｘが設けられ、登録されている全てのジョブＪ１〜ｎがＯＳの一部である図示しないジョブスケジューラにより特定の順序で起動され、ジョブステップｊｓｘの実行段階でジョブ自体の実行の要否判別が行われていた。そして、実行すべきジョブの場合には、ジョブステップｊｓｘに続いて以降のジョブステップｊｓが実行され、実行不要のジョブの場合には、ジョブを終了する最後のジョブステップｊｓｚ以外のジョブステップｊｓをスキップすることにより、実質的にジョブの実行が省略されていた。
【０００５】
このようなジョブ管理によれば、システムの汎用性を容易に高めることができる。つまり、上述のように処理条件の登録によりジョブ単位でバッチ処理の内容が組み立てられるので、各種の業務（適用分野）における要望を網羅したバッチ処理プログラムを作成し、それを適当にジョブ分割してシステムに組み込めば、適用分野に応じてプログラムを変更する必要はなく、且つ登録条件を変更するだけで、バッチ処理内容を運用事情に応じて動的に設定することができる。なお、より細かなジョブ分割を行えば、処理内容の設定の自由度が増大し、システムの利便性が高まる。
【０００６】
【発明が解決しようとする課題】
しかし、従来では実行の要否に係わらず全てのジョブＪ１〜ｎが一旦起動されるので、ジョブ分割の細分化によってジョブ数が多くなるにつれて、起動の回数も多くなる。起動は、主記憶域などの資源の割り当てやプログラムのロードを含み、ＯＳにとって負担の大きい処理である。通常は１回の起動に１０〜２０秒を要する。
【０００７】
このため、バッチ処理の所要時間が長いという問題があった。例えばジョブ数が１０００程度のシステムにおいては、起動だけで合計２．５〜５時間が費やされてしまう。
【０００８】
本発明は、上述の問題に鑑みてなされたもので、データ処理システムの汎用性及び利便性を損なうことなく、ジョブの起動回数を低減してバッチ処理の所要時間を短縮することを目的としている。
【０００９】
【課題を解決するための手段】
請求項１の発明に係る方法は、上述の課題を解決するため、図１に示すように、予め登録されている任意数のジョブステップｊｓの内、バッチ処理条件に適合したジョブステップｊｓを選択的に実行するためのバッチジョブ管理方法であり、コンピュータが、バッチ処理の実行指示に呼応して、その時点で確定しているバッチ処理条件ＦＵに照らして全ての前記ジョブステップｊｓについて個々に実行の要否を判定するステップと、その判定結果に応じて実行すべきジョブステップのみから構成される実行ジョブＪＰを生成するステップと、生成した前記実行ジョブＪＰのみをバッチジョブとして起動するステップと、を実行するものである。
【００１０】
請求項２の発明に係る方法は、コンピュータに、全ての前記ジョブステップｊｓを含むバッチジョブモデルＪＭを設けておき、前記実行ジョブを、前記バッチジョブモデルＪＭから実行不要の前記ジョブステップｊｓを削除することによって生成するものである。
【００１１】
請求項３の発明に係るシステムは、バッチ処理の内容を特定する任意数のジョブステップｊｓを記憶し、バッチ処理条件に適合した前記ジョブステップを選択的に実行するデータ処理システム１において、前記各ジョブステップｊｓに関係するリアルタイム処理の実行回数ｄ７を記憶するファイルＦ１１と、バッチ処理の実行指示に呼応して前記ファイルＦ１１を参照し、その時点の前記実行回数ｄ７に基づいて、全ての前記ジョブステップｊｓについて個々に実行の要否を判定するジョブステップ判定手段２１１と、判定の結果に応じて実行すべき前記ジョブステップｊｓのみを組み合わせて実行ジョブＪＰを生成するジョブ生成手段２１２と、生成された前記実行ジョブＪＰのみをバッチジョブとして起動するジョブ起動手段２２０とを備える。
【００１２】
請求項４の発明に係るシステムは、前記実行ジョブＪＰの起動前に、前記実行ジョブＪＰの内容のプリントアウトを行う出力制御手段２１３と、コンソール操作に応じて前記実行ジョブＪＰの内容を変更するジョブ変更手段２３２とを備える。
【００１３】
【作用】
バッチ処理に対応したジョブステップｊｓの中から、実行すべきジョブステップｊｓを抽出して合成することにより、起動の対象となる実行ジョブＪＰが生成される。ここで、実行すべきジョブステップｊｓは、日時、リアルタイム処理期間中の処理依頼の有無、処理対象データの有無といったバッチ処理条件に適合したジョブステップｊｓである。
【００１４】
全ての実行すべきジョブステップｊｓを合成して単一の実行ジョブＪＰを生成すれば、バッチ処理におけるジョブの起動回数は「１」となる。
【００１５】
【実施例】
図１は本発明に係るデータ処理システム１の要部の機能構成を示す図であり、図２は図１のリアルタイムジョブ処理部１００の機能構成を示す図である。
【００１６】
データ処理システム（以下、「システム」という）１は、図２に示すようにホスト１０と複数の端末２０とから構成されたオンラインシステムであり、金融システムや流通業の受発注システムなどとして利用される。そして、このシステム１においては、就業日の所定時間帯に取引の集計や帳票作成などのバッチ処理がホスト１０内で行われる。バッチ処理には、日次、月次、及び年次などの対象期間の異なる処理がある。
【００１７】
さて、図１のように、システム１は、バッチ処理の実現手段として、バッチ前処理部２１０、バッチジョブ処理部２２０、及びバッチ条件設定部２３０を有する。なお、これらの各部は、ＯＳの一部を含むプログラムを中心に構成される。
【００１８】
また、システム１では、図示しないプログラムファイルとともに、バッチ処理条件ＦＵを構成する各種のファイルＦ１０〜Ｆ１３、最も内容の豊富なバッチジョブであるバッチジョブモデルＪＭを記憶するファイルＦ２０、実際の処理内容を規定する実行ジョブＪＰを一時的に記憶するファイルＦ２１、及び、バッチ処理の対象データを記憶するファイル（業務ファイル）Ｆ３０が設けられている。
【００１９】
コンソールＯＣによるバッチ処理の実行指示Ｑは、バッチ前処理部２１０に与えられる。バッチ前処理部２１０は、要否判定部２１１、ジョブ生成部２１２、及び出力部２１３から構成されている。
【００２０】
要否判定部２１１は、バッチジョブモデルＪＭの各ジョブステップｊｓについて、先頭から順にその実行の要否を判定し、１つの判定を行う毎に、又は所定数（全数を含む）の判定の終了後に、判定結果をジョブ生成部２１２へ通知する。このとき、要否の判定は、後述のように各ファイルＦ１０〜Ｆ１３を参照して行われる。なお、予め条件マスタファイルＦ１０には、バッチ条件設定部２３０の登録部２３１によって、システム運用形態に応じた所定の条件データが登録されている。また、リアルタイムジョブ処理部１００によって、カウントファイルＦ１１及び依頼ファイルＦ１２にリアルタイム処理の内容に応じたデータが格納されている。
【００２１】
ジョブ生成部２１２は、バッチジョブモデルＪＭを構成する各ジョブステップｊｓの内、要否判定部２１１が実行すべきものと判定したジョブステップｊｓを抽出し、実行ジョブＪＰを生成する。すなわち、処理条件に適合するジョブステップｊｓをファイルＦ２０からファイルＦ２１へ転送し、バッチジョブモデルＪＭの不要部分を削除した形のジョブ制御文（ＪＣＳ）の集合を生成する。なお、各ジョブステップｊｓの実行順序は、バッチジョブモデルＪＭの作成段階（システム設計時）で決定されている。
【００２２】
実行ジョブＪＰが生成されると、出力部２１３は、図６のように実行ジョブＪＰの内容を示す確認リストＬ１をプリントアウトする。図６の例では、プリントアウトの日付ＤＸとともに、内容一覧表（ジョブステップ名ｄ１、作業内容ｄ９、判定結果ｄ１０、及び取引件数ｄ７）がプリントされている。
【００２３】
オペレータが確認リストＬ１によってバッチ処理内容を確認した上で再び実行指示操作を行うと、バッチジョブ処理部２２０は、実行ジョブＪＰを起動して各ジョブステップｊｓを実行する。つまり、実行ジョブＪＰが指定する資源割当を行い、必要なバッチ処理プログラムをロードして所定の処理結果を生み出す。
【００２４】
ところで、実際の運用に際しては、例えば、時間が足りないとか特定の出力装置が故障中であるといった理由で、その日に限ってバッチ処理内容の一部を変更したい場合が生じる。その場合に、条件マスタファイルＦ１０を修正してもよいが、そうすると次回のバッチ処理に備えて修正箇所を元に戻す必要がある。そこで、システム１では、バッチ条件設定部２３０の一部である変更部２３２と、ファイルＦ１３とが設けられている。
【００２５】
オペレータは、確認リストＬ１により示された処理内容に対して、特定処理の省略又は追加を望むときには、変更対象のジョブステップｊｓに対応する処理条件の変更データをコンソール操作により入力する。その変更データは、変更部２３２によって変更ファイルＦ１３に格納される。このような処置の後、再び実行指示操作を行うと、以前に生成された実行ジョブＪＰは破棄され、改めてファイルＦ１３のデータを踏まえて各ジョブステップｊｓの実行の要否判別が行われ、実行ジョブＪＰの再生成が行われる。このとき、要否判別において、条件マスタファイルＦ１０の所定部分がファイルＦ１３の変更データに読み替えられる。
【００２６】
次に、バッチ処理条件について詳しく説明する。
システム１においては、日次や月次などといった単なる日時条件だけでなく、リアルタイム処理の内容を加味したバッチ処理条件を登録することができる。例えば、特定の日次集計については、対象データがリアルタイム処理で発生しなかった場合には省略するようにしたり、特定の帳票作成は端末２０から依頼があった日のみに行うようにすることができる。
【００２７】
図３は条件マスタファイルＦ１０の内容の一例を示す図である。
条件マスタファイルＦ１０は、バッチジョブモデルＪＭの全てのジョブステップｊｓのそれぞれに対応したレコードの集合である。各レコードは、キーとなるジョブステップ名ｄ１、実行月日ｄ２、判定種別ｄ３、対象取引区分ｄ４、及び指定件数ｄ５  から構成されている。実行月日ｄ２は、日次、月次、又は年次といった日時条件を示し、これに続く３つのデータ項目ｄ３〜ｄ５は、リアルタイム処理の内容（カウントファイルＦ１１及び依頼ファイルＦ１２）の参照条件を示す。参照の手順は後述する。
【００２８】
図４はカウントファイルＦ１１の内容の一例を示す図、図５は依頼ファイルＦ１２の内容の一例を示す図である。
カウントファイルＦ１１は、取引区分ｄ４、日付ｄ６、及び取引件数ｄ７をデータ項目として有し、リアルタイム処理を分類した各処理項目（取引区分）について、日単位で実行回数をカウントした結果（取引件数）を記憶するファイルである。取引件数ｄ７の記憶期間は一ヵ月であり、ロータリー形式で日付が更新される。図４の例では１９９４年２月３日付けのデータが最新データである。
【００２９】
依頼ファイルＦ１２は、ジョブステップ名ｄ１と依頼端末名ｄ８とをデータ項目として有し、実行依頼のあった特定のバッチ処理項目に対応するジョブステップｊｓを示す累積記憶方式のファイルである。図５の例では、「ｎ」及び「ｐ」の２つのバッチ処理項目について実行依頼がなされている。
【００３０】
カウントファイルＦ１１及び依頼ファイルＦ１２のそれぞれのデータ更新は、上述したようにリアルタイムジョブ処理部１００によって行われる。
例えば、カウントファイルＦ１１は、図２のようにカウント処理プログラムＰ５０によって管理される。カウント処理プログラムＰ５０は、オンライン処理プログラムＰ１０、Ｐ１９やオフライン処理プログラムＰ３０によって適時にコールされ、コール元の処理に対応した取引区分ｄ４の本日の取引件数ｄ７に所定値（例えば起動毎のコールでは「１」）を加算する。その際、コール電文では、リアルタイム処理内容がそれを実現する処理プログラム名によって示されるので、ファイルＦ１１のアクセスに先立って、処理プログラム名と取引区分ｄ４とを対応づける変換テーブルＴＣが参照される。なお、プログラムＰ１０は、端末側のオンライン処理プログラムＰ２１〜２３からの処理要求をホスト側の所定の処理プログラムＰ１１〜１３に振り分ける分配プログラムＰ１０であり、プログラムＰ１０は、端末側のオンライン処理プログラムＰ２９と直接に通信する個別のオンライン処理プログラムである。
【００３１】
図３に戻って、判定種別ｄ３は、カウントファイルＦ１１及び依頼ファイルＦ１２の参照の要否を示し、その値は「０」「１」又は「２」である。
まず、判定種別ｄ３が「０」の場合は、ファイルＦ１１，１２の参照は不要である。すなわち、リアルタイム処理の内容に係わらず実行すべきジョブステップｊｓについては、判定種別ｄ３に「０」が登録される。図３の例では、バッチジョブモデルＪＭの先頭のジョブステップｊｓなどが該当し、これらのジョブステップｊｓは変更ファイルＦ１３（図１参照）に変更データがない限り、日時条件に適合しさえすれば、必ず実行ジョブＪＰに組み込まれる。
【００３２】
次に、判定種別ｄ３が「１」の場合は、カウントファイルＦ１１を参照する必要がある。この場合に対象取引区分ｄ４及び指定件数ｄ５が有効となる。対象取引区分ｄ４はカウントファイルＦ１１の取引区分ｄ４に対応し、参照すべき取引件数ｄ７を特定する。そして、指定件数ｄ５は、ジョブステップｊｓを実行すべきものとする場合の最低の取引件数を示す。すなわち指定件数ｄ５が例えば「１（件）」のジョブステップｊｓは、それに関係するリアルタイム処理の実行回数が１以上であれば、実行すべきジョブステップとして判定される。図２の例において、ジョブステップ名「ｂ」のジョブステップｊｓは、それに対応する取引区分「ＡＡ」のリアルタイム処理が１回でも行われている場合に実行されるが、図４の例では、本日（ここでは１９９４年２月３日）は、取引件数ｄ７の値が「０（件）」であるので、その実行が省略される。
【００３３】
最後に、判定種別ｄ３が「２」の場合は、依頼ファイルＦ１２を参照する必要がある。図２の例では、ジョブステップ名「ｍ」「ｎ」のジョブステップｊｓの判定種別ｄ３が「２」であるが、図５の例ではジョブステップ名「ｍ」のジョブステップｊｓに対応する依頼はない。したがって、本日はジョブステップ名「ｍ」のジョブステップｊｓは実行ジョブＪＰに組み込まれない。
【００３４】
以上の説明から明らかように、システム１においては、各種の要望を網羅したバッチジョブモデルＪＭを設けることにより、汎用性を確保することができ、条件マスタファイルＦ１０に所望の条件を登録しておくことにより、運用事情に応じてバッチ処理内容を任意に設定変更できるという利便性を確保することができ、しかもバッチジョブの起動回数を最小限に抑えて処理時間を短縮することができる。
【００３５】
上述の実施例によれば、カウントファイルＦ１１を設けるととともに、条件設定項目として指定件数ｄ５を設け、リアルタイム処理項目の実行回数（取引件数ｄ７）に応じてバッチ処理内容を自動的に変更するようにしたので、例えば対象データが所定数以上あって有意義な結果が得られる場合のみに特定のジョブステップｊｓを実行させるといった効率的なバッチ処理を容易に実現することができる。
【００３６】
上述の実施例において、バッチジョブモデルＪＭの個数は、バッチジョブ処理部２２０による起動の回数を低減する上では、より少なくするのが有利であるが、必ずしも「１」に限定されるものではない。例えば金融や流通などの異種の業務を担う総合的なシステム１では、各業務毎にバッチジョブモデルＪＭを設けるというように、運用の都合に応じてバッチジョブ数を適当に選定してもよい。
【００３７】
上述の実施例において、確認リストＬ１のプリント内容は、実行するジョブステップｊｓのみ、又は逆に省略したジョブステップｊｓのみというように確認作業の都合に応じて任意に設定することができるが、図６に示したように、バッチジョブモデルＪＭの全てのジョブステップｊｓについて、要否の判定結果ｄ１０と取引件数ｄ７とをプリントすれば、オペレータによるバッチ処理内容の適否判断が容易になる。
【００３８】
【発明の効果】
本発明によれば、データ処理システムの汎用性及び利便性を損なうことなく、ジョブの起動回数を低減してバッチ処理の所要時間を短縮することができる。
いる。
【００３９】
請求項４の発明によれば、運用事情に応じた臨機応変のバッチ処理内容の設定が容易となり、利便性をより高めることができる。
【図面の簡単な説明】
【図１】本発明に係るデータ処理システムの要部の機能構成を示す図である。
【図２】図１のリアルタイムジョブ処理部の機能構成を示す図である。
【図３】条件マスタファイルの内容の一例を示す図である。
【図４】カウントファイルの内容の一例を示す図である。
【図５】依頼ファイルの内容の一例を示す図である。
【図６】実行ジョブの内容リストの一例を示す図である。
【図７】従来のバッチジョブの構成を示す模式図である。
【符号の説明】
１  データ処理システム
２１１  要否判定部（ジョブステップ判定手段）
２１２  ジョブ生成部（ジョブ生成手段）
２１３  出力部（出力制御手段）
２２０  バッチジョブ処理部（ジョブ起動手段）
２３２  変更部（ジョブ変更手段）
ｄ７  取引件数（リアルタイム処理の実行回数）
Ｆ１１  カウントファイル（ファイル）
ＦＵ  バッチ処理条件
ＪＰ  実行ジョブ
ＪＭ  バッチジョブモデル
ｊｓ  ジョブステップ
【図１】
0003544555.tif 000002
【図２】
0003544555.tif 000003
【図３】
0003544555.tif 000004
【図４】
0003544555.tif 000005
【図５】
0003544555.tif 000006
【図６】
0003544555.tif 000007
【図７】
0003544555.tif 000008