JP6303626B2 - 処理プログラム、処理装置および処理方法 - Google Patents

Description

本発明は、処理プログラム、処理装置および処理方法に関する。

業務システムでは、オンライン業務とバッチ業務とが行なわれる。その際、バッチ業務を実行するために必要なデータは、オンライン業務における全てのオンライン処理を完了した時点で出揃うことになる。そのため、オンライン業務を完了して必要なデータが出揃った後にバッチ業務をまとめて実行することが、効率が良いとされている。

そこで、オンライン業務が終了した後、次のオンライン業務の開始（デッドライン）までの間に、バッチ業務を遅延なく終了させるべく、以下のような工夫がなされている。つまり、バッチ業務用の資源を増やす、あるいは、バッチ業務を並列的に処理するなどの工夫であり、いずれもバッチ業務の実行時間内での工夫である。

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

近年のバッチ業務においては、基幹業務処理以外の情報系処理が増加している。情報系処理で取り扱うデータ量は桁違いに大きいため、近年の「実行時間の長いジョブ」は桁違いに長くなっている。ここで、基幹業務処理は、例えば、ＰＯＳ（Point Of Sales；販売時点管理）データ等の店舗売上データに基づいて在庫不足の商品の発注を行なう処理である。また、情報系処理は、例えば、ＰＯＳデータの売上推移情報や、ツイッタやブログ等の口コミ情報など、多様かつ多量の情報を分析して売れ筋商品を予測するなどの処理である。

また、振込処理殺到等による「想定を超えた」入力データ量の増加に伴いバッチ業務が遅延し、その結果、ＡＴＭ（Automated Teller Machine）が停止する場合がある。特に、社会システムと呼ばれるシステムにおいては、このような「想定を超えた」突発的なデータ量増加への対策が求められている。

一方で、サービス向上のための営業時間の長時間化などに伴い、オンライン業務が長時間化しており、バッチ業務を実行できる時間が短くなっている。

上述のように、オンライン業務（第１処理）の実行時間が長くなりバッチ業務（第２処理）の実行時間が短くなり、且つ、想定を超えた突発的なデータ量増加が発生しうる現状では、バッチ業務の実行時間内での工夫だけでは、バッチ業務の遅延を抑止しデッドラインの突き抜けを抑止することは困難である。

一つの側面で、本発明は、第１処理の開始までに第２処理を完了させることを目的とする。
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本件の他の目的の一つとして位置付けることができる。

本件の処理プログラムは、以下の処理を、コンピュータに実行させる。スケジュールされた、第１期間での第１処理と、前記第１期間後の第２期間での第２処理とのうち、前記第２処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されるデータ群に対する第３処理を当該データ群の範囲内で行なう後続ジョブとを含むジョブ群を、前倒し可能ジョブ群として抽出する処理。前記抽出ジョブを含む先行ジョブの出力データを入力とするジョブであって、前記先行ジョブから入力された一の前記データ群に対する一以上の前記第３処理を行ない一以上の出力データ群を出力するジョブを、前記後続ジョブとして抽出する処理。抽出された前記前倒し可能ジョブ群を、前記第２期間から前記第１期間に前倒しして実行する処理。

第１処理の開始までに第２処理を完了させることができる。

（Ａ）は既存技術によるバッチ業務の処理方法の概要を説明する図であり、（Ｂ）は本実施形態におけるバッチ業務の処理方法の概要を説明する図である。 本実施形態におけるバッチ業務の技術課題を説明する図である。 （Ａ）は既存技術によるバッチ業務の処理方法の概要を説明する図であり、（Ｂ）は本実施形態におけるバッチ業務の処理方法の概要を説明する図である。 夜間バッチ処理の構成を示す図である。 抽出ジョブを説明すべく夜間バッチ処理の構成をより詳細に示す図である。 独立して分割実行可能な夜間バッチ処理を説明する図である。 独立して分割実行可能な夜間バッチ処理を説明する図である。 連携処理について説明する図である。 データベースに対するデータの挿入処理，更新処理，削除処理を含むジョブ（アプリケーション）のチェック手法を説明する図である。 （Ａ）は前倒し対象ジョブ範囲のパターン１を説明する図であり、（Ｂ）は前倒し対象ジョブ範囲のパターン２を説明する図である。 図１０（Ｂ）に示すパターン２について前倒し可能な処理の範囲を説明する図である。 前倒し可能ジョブ一覧テーブル作成対象の夜間バッチ（ジョブネット）の一構成例を示す図である。 本実施形態における前倒し可能ジョブ一覧テーブルの一例を示す図である。 本実施形態におけるデータベースアクセスジョブネット管理情報テーブルの一例（初期状態）を示す図である。 本実施形態におけるデータベーストランザクション情報テーブルの一例（初期状態）を示す図である。 テスト運用で採取された各ジョブの実行時間(通常)を記録されたデータベースアクセスジョブネット管理情報テーブルの一例を示す図である。 テスト運用で採取された各データベースに対するトランザクション量(通常)を記録されたデータベーストランザクション情報テーブルの一例を示す図である。 実運用で採取された各データベースに対するトランザクション量(実績)を記録されたデータベーストランザクション情報テーブルの一例を示す図である。 実運用時にトランザクション量の増加がない場合の実行時間(予測)を記録されたデータベースアクセスジョブネット管理情報テーブルの一例を示す図である。 実運用時にトランザクション量の増加がある場合の実行時間(予測)を記録されたデータベースアクセスジョブネット管理情報テーブルの一例を示す図である。 本実施形態における前倒し候補一覧テーブルの一例を示す図である。 本実施形態における前倒しジョブ群一覧テーブルの一例を示す図である。 図１３に示す前倒し可能ジョブ一覧テーブルから要部を抽出して示す図である。 本実施形態における前倒し処理を説明する図である。 前倒し処理を１回だけ実行した場合のバッチ処理の例を説明する図である。 前倒し処理を２回以上実行した場合のバッチ処理の例を説明する図である。 本実施形態におけるジョブ管理サーバ（処理装置）のハードウエア構成例および機能構成例を示すブロック図である。 本実施形態におけるスケジュール装置の機能構成例を示すブロック図である。 図２８に示すスケジュール装置によるジョブ実行時の動作概要を説明するフローチャートである。 図２８に示すスケジュール装置におけるテスト運用設定動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるデッドライン時刻設定動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるオンライン／バッチ業務切替時刻設定動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ抽出部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ抽出部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ抽出部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ抽出部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ抽出部の動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるデータベースアクセス設定部の動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるデータベースアクセス設定部の動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるデータベースアクセス設定部の動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるデータベースアクセス解析部の動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるデータベースアクセス解析部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ決定部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ決定部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における前倒しジョブ決定部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における入力データ管理部の動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるジョブ実行部の動作を説明するフローチャートである。 図２８に示すスケジュール装置におけるジョブ実行部の動作を説明するフローチャートである。 図２８に示すスケジュール装置における出力データ管理部の動作を説明するフローチャートである。 本実施形態におけるシステム定義情報の一例を示す図である。 本実施形態におけるジョブネット定義情報の一例を示す図である。 本実施形態におけるクリティカルパス管理情報テーブルの一例を示す図である。

以下に、図面を参照し、本願の開示する処理プログラム、処理装置および処理方法の実施形態について、詳細に説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能を含むことができる。そして、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔１〕本実施形態におけるバッチ業務の処理方法について
図１〜図２６を参照しながら、本実施形態におけるバッチ業務の処理方法について説明する。

上述した通り、オンライン業務の実行時間が長くなりバッチ業務の実行時間帯が短くなり、且つ、想定を超えた突発的なデータ量増加が発生しうる現状では、バッチ業務の実行時間帯内での工夫だけでは、バッチ業務の遅延を抑止することは困難である。そこで、本実施形態の処理方法は、バッチ業務の遅延を抑止してデッドラインの突き抜けを抑止すべく、図１（Ａ）および図１（Ｂ）に示すようにバッチ業務の開始時刻以前つまりオンライン業務の時間帯に遡り、効率的にバッチ業務を実行可能にする。

なお、図１（Ａ）は、既存技術によるバッチ業務の処理方法の概要を説明する図であり、図１（Ｂ）は、本実施形態におけるバッチ業務の処理方法の概要を説明する図である。また、図１（Ａ）および図１（Ｂ）において、日変わり時刻は、業務の開始の時刻（業務の単位の１日の始まり時刻）であり、デッドラインは、バッチ処理が必ず終了しなければならない時刻（オンライン業務の始まり時刻）である。さらに、終了予定時刻は、業務者が遅延監視のために予め設定しておく業務（ジョブネット）の終了を望む時刻である。

図１（Ａ）に示すように、既存技術によるバッチ業務の処理方法では、例えば、デッドライン時刻７：００からオンライン処理終了時刻２０：００までの間、オンライン処理が実行される。これにより、一日分、例えば１万件分のオンライン処理結果が得られる。この後、例えば、夜間バッチ開始時刻２２：００から一日分（１万件分）のオンライン処理結果に対する一括処理が実行される。

これに対し、図１（Ｂ）に示すように、本実施形態におけるバッチ業務の処理方法では、オンライン業務の時間帯に、オンライン処理と並行して、バッチ処理の一部が分割実行される。つまり、図１（Ｂ）に示す例では、最初の３千件分のオンライン処理結果に対するバッチ処理がオンライン処理と並行して実行された後、次の４千件分のオンライン処理結果に対するバッチ処理がオンライン処理と並行して実行される。そして、オンライン処理終了後から夜間バッチ開始までの間の時間帯に、最後の３千件分のオンライン処理結果に対するバッチ処理が実行される。

図１（Ｂ）に示すような処理を実現するためには、オンライン業務の時間帯において、元々オンライン業務終了後に一括して処理するバッチジョブ（バッチジョブとして登録されたアプリケーション）を動作させることになる。このため、複数のオンライン処理が完了しておらず、一日分の全データ（全てのオンライン処理結果）が出揃っていない状態でアプリケーションを実行することを考慮する必要がある。

〔１−１〕前提条件および技術課題
〔１−１−１〕前提条件
夜間バッチ処理には、大別すると、以下の２種類のジョブ（アプリケーション）Ａ１およびＡ２が含まれる。なお、以下の説明において、「データ区分」は、「データ群」の一例である。

Ａ１： 一のデータ区分に対して一の処理を実施する一括データ処理（例えば、１件の売上入力に対して１枚の売り上げ伝票を作成する処理）
Ａ２： １日分（業務として意味のあるまとまった時間の単位）の全てのデータ区分に対して分析や集計などの処理を実施する一括データ処理（例えば、１日分の店舗売上データに対して商品・地域・時間帯・性別・年齢などで売上傾向を分析したり、集計したりする処理）

オンライン業務の時間帯に並行して処理可能なバッチ処理は、上記項目Ａ１に該当するタイプのアプリケーションであり、上記項目Ａ２に該当するタイプのアプリケーションは、オンライン業務の時間帯に並行して実行することはできない。このため、オンライン業務の時間帯に前倒ししてバッチアプリケーションを動作させようとする場合、事前に上記項目Ａ１に該当するタイプのアプリケーションを特定しておく必要がある。

〔１−１−２〕技術課題Ｉ（アプリケーションを改修することなく、上記項目Ａ１のタイプを特定するとともに、前倒し可能なジョブ範囲を特定すること）
上記項目Ａ１に該当するタイプのアプリケーションを特定するには、業務者（顧客）の資産であるアプリケーションの内容を分析した上で、アプリケーションの改修を行なうことが考えられる。しかし、数万〜数十万のバッチジョブ（アプリケーション）が登録されているバッチ処理システムにおいて、アプリケーションの多種多様な処理内容を人手で分析した上で、正しく上記項目Ａ１のタイプである旨を特定してメンテナンスするには、多大なコストがかかる。あるいは、現実的にメンテナンスを持続することができない。そのため、アプリケーション側で、前倒し処理に必要な情報を出力させるように改修することは困難であり、必要な情報はアプリケーション側からは得られない。

データ分析を行なって前倒し可能なジョブを抽出する場合、前倒し可能なジョブの範囲を決定する必要がある。その際、ジョブの先行後続関係の流れだけでなく、業務データベース（ＤＢ）へのデータ更新，ファイル作成／ファイル転送などを介して後続の処理が待ち合わせを行なう業務（バッチ処理自体）の流れを考慮する必要がある。しかしながら、多種多様なデータのやり取りを行なうバッチ業務全体で、データの流れを一つ一つ追随して前倒し可能なジョブの範囲を特定するのは困難である。

〔１−１−３〕技術課題II（バッチ処理の一部を分割実行してもデータの二重処理や抜けの発生を抑止すること）
オンライン処理の時間帯にバッチ処理の一部を並行して処理することは、これまで夜間に一括で実行していたバッチ処理を、複数回に分割して処理することになる。

上記技術課題Ｉにおいて、上記項目Ａ１に該当するタイプのアプリケーションが特定され前倒し可能なジョブの範囲（ジョブ群）が特定されても、通常、夜間バッチ処理用に開発されたアプリケーションは、全データ区分が出揃った状態を前提として、一括処理を行なっている。

このため、単純にバッチ処理の一部を前倒しして分割実行した場合、分割実行のタイミングで溜まっている全データを対象にしてバッチ処理が実行される。したがって、図２に示すように、データの二重処理が発生し、結局、オンライン業務終了後の最後のバッチ処理の実行時間は短くならない。

図２は、本実施形態におけるバッチ業務の技術課題を説明する図である。図２に示す例では、時刻７：００〜１３：００の間に溜まったデータ区分に対するバッチ処理が時刻１３：００に開始された後、時刻７：００〜２０：００の間に溜まったデータ区分に対するバッチ処理が時刻２０：００に開始されている。つまり、時刻２０：００に開始されるバッチ処理では、１回目に処理済みであるデータ区分も含め、当日分の全てのデータ区分が処理対象になってしまう。このため、バッチ処理の一部を日中に前倒しして実行しても、同一バッチ（アプリケーション）を２回以上実行することになる。したがって、データを分割してバッチ処理を短時間で実行することができない。

バッチ処理の実行時間を短くするには、前倒しして実行した処理済のデータを二重処理しないように制御するとともに、最終出力が夜間バッチを１回で実行したときと同じ結果になるように制御する必要がある。しかしながら、該当するアプリケーション（バッチジョブ）は、多種多様な加工処理のタイプが存在し、入出力データに対する処理も様々であり、全てのアプリケーションに対して上述のような制御を行なうことは困難である。

〔１−２〕技術課題の解決手法
本実施形態におけるバッチ業務の処理方法では、所定の複数処理（オンライン処理；第１処理）を完了した後に実行されるバッチ処理（夜間バッチ；第２処理）から、前倒し可能なジョブ群が抽出される。そして、オンライン処理において突発的なデータの増加が予測された場合、抽出されたジョブ群が、所定の複数処理（オンライン処理）と並行して実行される。これにより、オンライン処理済みのデータ区分に対するバッチ処理が前倒されて実行され、デッドラインの突き抜けが抑止される。

図３（Ａ）に示すように、既存技術によるバッチ業務の処理方法では、一日分、例えば１万件分のオンライン処理結果が出揃った後、一日分のデータに対する夜間バッチ処理が一括して実行される。なお、図３（Ａ）は、既存技術によるバッチ業務の処理方法の概要を説明する図である。

これに対し、図３（Ｂ）に示すように、本実施形態におけるバッチ業務の処理方法では、オンライン業務の時間帯に、オンライン処理と並行して、バッチ処理の一部が分割実行される。その際、日中バッチの資源が活用される。そして、図３（Ｂ）に示す例では、最初の３千件分のオンライン処理結果に対する１回目のバッチ処理がオンライン処理と並行して実行された後、次の４千件分のオンライン処理結果に対する２回目のバッチ処理がオンライン処理と並行して実行される。この後、夜間バッチにおいて、３千件分のオンライン処理結果に対する最終回のバッチ処理が実行される。このように、７千件分のオンライン処理結果に対する夜間バッチ処理が、オンライン処理期間中に前倒しで実行されるため、前倒しして実行したバッチ処理の実行時間分、夜間バッチの実行期間（実行時間）を短縮することができる。なお、図３（Ｂ）は、本実施形態におけるバッチ業務の処理方法の概要を説明する図である。

ここで、バッチ処理について簡単に説明する。バッチ処理は、通常、日中バッチと夜間バッチとに分けられ、それぞれ、以下の特性を有している。なお、本実施形態では、日中バッチおよび夜間バッチを含めたバッチ処理のことを「ジョブネット」、バッチジョブを単に「ジョブ」という場合がある。

日中バッチ（オン中バッチまたはオンラインバッチとも呼ぶ）は、オンライン処理中に発生するデータを、逐次、または、ある程度まとまった時点で処理するバッチである。日中バッチは、データ量が少ないため、処理時間は長くない。また、日中バッチは、オンライン処理中に処理されるため、通常、デッドラインは設定されない。

夜間バッチは、オンライン処理によって溜まったデータを、オンライン処理後にまとめて処理するバッチである。夜間バッチは、大量のデータをまとめて処理するため、処理時間が長時間化する。また、夜間バッチでは、オンライン処理後のデータがまとめて処理されるため、次のオンライン処理でデータが蓄積される前までに完了している必要があり、デッドラインが設定される。

個々の夜間バッチは、例えば図４に示す構成を有している。図４は、夜間バッチ処理の構成を示す図である。図４に示すように、夜間バッチは、複数（図４では３つ）のバッチジョブ（アプリケーション）で構成される。最初のバッチジョブには、ＤＢから入力データ（オンライン処理によって得られたデータ区分）が入力され、最初のバッチジョブによる処理結果として一番目の中間出力データが得られる。また、二番目のバッチジョブには、一番目の中間出力データが入力され、二番目のバッチジョブによる処理結果として二番目の中間出力データが得られる。そして、最後のバッチジョブには、二番目の中間出力データが入力され、最後のバッチジョブによる処理結果として最終出力データが得られる。

〔１−２−１〕技術課題Ｉの解決手法（１）
ここでは、業務者（顧客）の資産であるアプリケーションを改修することなく、１レコード毎に処理されている、上記項目Ａ１に該当するタイプのジョブを抽出する、本実施形態の手法について説明する。

バッチジョブの入力データである、オンライン処理結果のＤＢおよびバッチジョブの中間出力データに着目し、１レコード（一のデータ区分）ずつ処理されている上記項目Ａ１のタイプのジョブを下記手順ｉおよびiiによって類推する。

手順ｉ： 各ジョブが、オンライン処理結果のＤＢを入力としている、データ抽出処理を行なうジョブ（抽出ジョブ）であるか否かを判定する。
手順ii： 抽出ジョブで抽出されたデータ区分を起点に１件ずつ処理が行なわれるジョブであって且つ当該処理によって出力されるデータ区分（中間出力データ）の件数が、抽出されたデータ区分の件数のＮ倍（Ｎは１以上の整数）であるジョブを、上記項目Ａ１のタイプのジョブ（前倒し可能なジョブ）であると類推する。また、中間出力データの件数が、入力されるデータ区分の件数の整数倍である後続のジョブについては、まとめて前倒し可能なジョブ群とする。
上記手順ｉおよびiiの詳細については下記項目〔１−４−１〕の（Ｂ１）において説明する。

ここで、抽出ジョブについて説明する。抽出ジョブとは、ＤＢからデータを抽出する処理を実行するジョブで、入力データ（ＤＢ）から抽出条件に合致するデータをファイルへ抽出するジョブである。大量データを一括処理する夜間バッチは、図５に示すように、基本的に、抽出ジョブと加工ジョブおよび／または集計ジョブとを組み合わせて構成されている。加工ジョブは、抽出ジョブで入力データから抽出した抽出データに対し、加工を施すジョブである。また、集計ジョブは、同抽出データ、もしくは、加工ジョブで加工されて得られた中間出力データについて集計を行なうジョブである。なお、図５は、抽出ジョブを説明すべく夜間バッチ処理の構成をより詳細に示す図である。

一般的な抽出ジョブの特性としては以下の４つの特性(a1)〜(a4)が挙げられる。そして、アプリケーションからＯＳ（Operating System）に対して発行される処理要求の一部をトラップして当該アプリケーションが抽出ジョブの下記特性(a1)〜(a4)を有するか否かを分析することで、当該アプリケーションが抽出ジョブであるか否かを自動識別することができる。

(a1) 抽出アプリケーションは、入力ファイルを、最初から最後まで、レコード単位、もしくは、ある一定のサイズで順番に読み込む。
(a2) 抽出アプリケーションは、レコードのあるカラムの値が、抽出アプリケーションに指定された抽出条件に一致した場合に、該当するレコードを出力ファイルへ、レコード単位、もしくは、ある一定のサイズで順番に書き込む（レコード加工はなし）。
(a3) 抽出アプリケーションは、１つの出力ファイルに固定されず、抽出条件に従って出力を複数の出力ファイルに振り分ける。複数の出力ファイルが存在する場合、抽出条件と出力ファイルとの関係が、抽出条件定義ファイルに予め定義されている。
(a4) 上記抽出条件定義ファイルは、一回の読込み処理でメモリへ展開される。

〔１−２−２〕技術課題Ｉの解決手法（２）
ここでは、バッチ業務全体に影響するデータの流れを考慮して、複数の前倒し可能なジョブの範囲（ジョブ群）を特定する、本実施形態の手法について説明する。本実施形態では、下記手順iiiおよびivによって、前倒し可能なジョブ群が特定される。

手順iii： 前倒し可能と判定されたジョブ群に、他の業務（処理）に情報を受け渡す連携処理が含まれるジョブ、すなわち業務ＤＢに対するデータの挿入（insert），更新（update），削除（delete）の処理を含むジョブが含まれる場合、当該ジョブ群を前倒し対象から除外する。手順iiiの詳細については下記項目〔１−４−１〕の（Ｂ２）で説明する。

手順iv： 前倒し可能と判定されたジョブ群における、抽出ジョブの後続ジョブに、以下のような所定の出力ジョブ（終端ジョブ）が含まれる場合、抽出ジョブから当該所定の出力ジョブの直前の後続ジョブまでのジョブを前倒し可能なジョブ群の範囲とする。ここで、上記所定の出力ジョブは、最終出力データを、ファイル作成／ファイル転送などを通して後続のバッチ処理に受け渡すジョブ、即ちメッセージ発行処理またはファイル転送処理を行なうジョブである。あるいは、上記所定の出力ジョブは、出力ファイルが他のバッチ処理（他の業務）の起動契機（開始契機）となっているジョブである。手順ivの詳細については下記項目〔１−４−２〕で説明する。

〔１−２−３〕技術課題IIの解決手法
ここでは、分割されたデータを活用することで、バッチ処理を複数回実行しても、入力データを二重に処理することなく最終出力の結果を正しく出力するよう制御を行なう、本実施形態の手法について説明する。本実施形態では、下記手順ｖおよびviによって上記制御が行なわれる。

手順ｖ： 抽出ジョブ（入力となる抽出データ）を特定し、その単一の入力データの範囲で加工処理を実施しているアプリケーション（加工ジョブ）を前倒し対象として特定することで、上記技術課題IIを解決するための入出力ファイルの制御を可能にする。また、抽出されたジョブ群の実行タイミング（前倒し実行時刻）を、所定の複数処理（オンライン処理）の処理状況に応じて設定・記録しておく。そして、当該実行タイミングまでに処理されたデータの範囲を正しく認識できるように、前倒し実行されたジョブ群の一時入力ファイルおよび一時出力ファイルを、前倒し実行回数に応じて作成する。手順ｖの詳細については下記項目〔１−８−１〕で説明する。

手順vi： ２回目以降の分割バッチ処理でデータの二重処理が発生しないように、入力ファイルと直前の分割バッチ処理実行時の入力データとを比較し既に処理済みのデータを除外することで得られた未処理データを処理対象にして、前倒し可能なジョブ群を前倒し実行する。実行タイミングが夜間バッチの開始時刻に到達した場合、最終回のバッチ処理として前倒し実行された処理の結果（一時出力ファイル）をマージする。手順viの詳細については下記項目〔１−８−２〕で説明する。

〔１−３〕本実施形態によるバッチ業務の処理方法の概要
本実施形態によるバッチ業務の処理方法は、大きく分けて、下記５つの処理Ｐ１〜Ｐ５を含む。

処理Ｐ１： 業務システムのテスト運用時に、前倒して実行可能な夜間バッチと、前倒し可能な処理（ジョブ）の範囲とを抽出する。
処理Ｐ２： 業務システムのテスト運用時に、バッチジョブが利用するＤＢの単位時間当たりのトランザクション量とジョブの実行時間との相関関係を算出する。
処理Ｐ３： 日々の運用（実運用）で各ＤＢに対するトランザクション量の増大を監視し、バッチ処理の前倒し実行が必要か否かを判断する。
処理Ｐ４： 実運用時に、日中に前倒しする夜間バッチ処理を選択するとともに、日中における夜間バッチ処理の実行開始時刻を決定する。
処理Ｐ５： 前倒して処理されたデータを活用し、バッチ処理を複数回実行してもバッチ処理が正しく実行されるよう制御する。

〔１−４〕処理Ｐ１について
処理Ｐ１は、事前準備の処理で、上述したように、テスト運用時に、前倒して実行可能な夜間バッチと、前倒し可能な処理（ジョブ）の範囲とを抽出する処理であり、下記項目〔１−４−１〕〜〔１−４−３〕の処理を実行する。

〔１−４−１〕オンライン処理期間への前倒し可能な夜間バッチ処理の抽出
通常、オンライン処理を施されて溜まったデータは、一括して夜間バッチで処理されている。夜間バッチ処理期間から日中のオンライン処理期間に前倒しするには、任意のタイミングまでに溜まったデータ区分ごとに、独立して処理を実行することができる必要がある。

独立して実行可能な処理としては、例えば、オンラインで営業が入力した売上データ１件ごとに対して売上伝票を夜間バッチで作成するような処理が該当する。
また、最終的に分析や集計処理を行なう一連のバッチ処理であっても、対象データの抽出処理、および、データ１件ごとに対して加工を行なう加工処理は、図６に示すように、任意のタイミングまでに溜まったデータ分ごとに独立して処理可能な対象になる。

図６は、独立して分割実行可能な夜間バッチ処理（ジョブ）を説明する図である。独立して実行可能な夜間バッチ処理であれば、夜間に一括して実行されていた夜間バッチを、図６に示すように、例えば３つ（１回目，２回目，最終回）に分割して実行することができる。図６に示す例において、時刻７：００〜１８：００にオンライン処理を施されたデータは、時刻１８：００からの１回目の夜間バッチで前倒して処理される。また、時刻１８：００〜１９：００にオンライン処理を施されたデータは、時刻１９：００からの２回目の夜間バッチで前倒して処理される。そして、時刻１９：００〜２０：００にオンライン処理を施されたデータは、時刻２２：００からの最終回の夜間バッチで処理される。

本実施形態では、前倒し可能な夜間バッチ処理の抽出を行なうべく下記項目（Ｂ１）および（Ｂ２）の処理が実行される。
（Ｂ１）任意のタイミングまでに溜まったデータ区分ごとに独立して分割実行可能なジョブつまり前倒し可能なジョブの抽出
任意のタイミングまでに溜まったデータ区分ごとに独立して分割実行可能なジョブとは、データを分割して実行できることを意味する。

業務システムにおけるバッチ業務において、このような特徴をもつ処理（ジョブ）は、以下の考え方で判別することができる。つまり、当該処理（ジョブ）においては、抽出ジョブによる抽出処理で抽出されたデータ区分が１つずつ処理されており、その処理による出力データの件数が、抽出されたデータ件数と同じ、または、抽出されたデータ件数のＮ倍（整数倍）である。このとき、１：Ｎの関係を評価する起点となる抽出ジョブは、上記項目〔１−２−１〕で説明した手法によって識別される。

なお、全てのデータ（例えば日次処理なら１日分のデータ）が揃っていないと実行できない処理は、例えば分析や集計処理である。これらの処理によって出力されるデータの件数は、入力データ（抽出処理で抽出されたデータ）の件数との間に比例関係はなく、例えば、１０００件の入力データに対して、数件の出力結果が得られることになる。

図７に示すような処理を行なうジョブ群は、任意のタイミングまでに溜まったデータ区分ごとに独立して分割実行することができる。図７は、独立して分割実行可能な夜間バッチ処理（ジョブ）を説明する図である。図７に示す例では、抽出ジョブで入力データから抽出された抽出データの件数が１００であり、最初の加工ジョブでは、１００件の入力データ（抽出データ）に対し１００件の中間出力データが得られる。また、２回目の加工ジョブでも、１００件の入力データ（中間出力データ）に対し１００件の中間出力データが得られる。そして、最終回の加工ジョブ（出力）では、１００件の入力データ（中間出力データ）に対し２００件の中間出力データが得られる。したがって、図７に示す例では、抽出ジョブと３つの加工ジョブとの全てが、独立して分割実行可能な夜間バッチ処理、つまり前倒し可能な夜間バッチ処理として抽出され特定される。

上述した前倒し可能なジョブ群の特定は、以下の手順（Ｂ１−１）〜（Ｂ１−６）で行なわれる。なお、抽出ジョブは、上記項目〔１−２−１〕で説明した手法によって識別され、明確化済みであることを前提とする。

（Ｂ１−１）： 抽出ジョブの入力データファイルが、先行するバッチ処理（ジョブネット）で作成される場合、当該抽出ジョブを含むジョブ群は『前倒し対象外』と判断する。なぜならば、このようなジョブ群は、先行するバッチ処理（ジョブネット）の実行完了後でなければ処理できないため、日中に前倒しすることが不可能であるからである。
（Ｂ１−２）： 抽出ジョブの出力データ（抽出データ）の件数をカウントし、当該件数を「入力データ件数」として記憶する。
（Ｂ１−３）： 抽出ジョブの後続ジョブ（通常は加工ジョブや集計ジョブ）が先行ジョブの出力データを入力としており、且つ、当該ジョブの出力データの件数が「入力データ件数」の整数倍と一致するかを判定する。
（Ｂ１−４）： 上記手順（Ｂ１−３）の判定結果が“偽”であれば、当該ジョブ群は『前倒し対象外』と判断し、後述する前倒し可能ジョブ一覧テーブル２１３における前倒し可能フラグ（図１３，図２３参照）に“ＯＦＦ”を設定する。
（Ｂ１−５）： 上記手順（Ｂ１−３）の判定結果が“真”であれば、当該ジョブ群は『前倒し対象』と判断し、前倒し可能ジョブ一覧テーブル２１３における前倒し可能フラグに“ＯＮ”を設定する。
（Ｂ１−６）： 以降、後続のジョブに対して上記手順（Ｂ１−３）の判定処理を後続ジョブがなくなるまで繰り返し実行する。

（Ｂ２）他の業務との連携処理が含まれる場合の前倒し対象からの除外
当該ジョブ群の中には、主目的である業務処理以外に、例えば他の業務に何らかの情報や指示を受け渡す「連携処理」が含まれている可能性があり、その連携処理は、通常、業務データが格納されているＤＢ等を介して行なわれる。その様子を図８に示す。図８は連携処理について説明する図である。図８に示す例では、抽出ジョブ（もしくは加工ジョブ）の実行中に、ある条件に合致する売上データを検知した場合に、当該ジョブは、生産管理業務へ生産管理ＤＢを介して必要なデータを受け渡している。そして、生産管理ＤＢにデータが挿入されたことを契機に、生産管理業務として必要なバッチ処理が実行される。このようなバッチ処理は、当日の生産管理データとの突合せを行なう処理であり、夜間に処理されることを前提とするバッチ処理である。

上述のような連携処理が含まれているジョブ群を、日中（オンライン業務時間帯）に前倒しすると、他の業務（図８に示す例では生産管理業務）のバッチ処理が日中に動作することになる。当該バッチ処理（生産管理業務のバッチ処理）は夜間に動作することが前提であるため、当該バッチ処理が日中に動作すると悪影響が発生する。従って、上述のような連携処理が含まれているジョブ群は、前倒し対象から除外する必要がある。

そこで、本実施形態では、上記項目（Ｂ１）の処理により「前倒し可能」と判断されたジョブ群に属する全てのジョブについて、ＤＢに対するデータの挿入(insert)，更新(update)，削除(delete)のいずれかの処理が存在するか否かをチェックする。当該処理が存在する場合、当該ジョブ群は前倒し対象から除外される。

ＤＢに対しデータの挿入(insert)，更新(update)，削除(delete)の処理を行なうバッチは、ジョブとして実行するアプリケーションの、データの挿入／更新／削除処理をトラップし（図９の処理Ｓ１参照）、解析処理（図９の処理Ｓ２参照）を行なう。そして、当該解析の結果を確認することで（図９の処理Ｓ３参照）、データの挿入／更新／削除処理の存在がチェックされる。なお、トラップ処理は、例えばＤＢＭＳ（DataBase Management System）の機能によって実現される。また、図９は、ＤＢに対するデータの挿入処理，更新処理，削除処理を含むジョブ（アプリケーション）のチェック手法を説明する図である。

〔１−４−２〕前倒し可能なジョブ範囲の抽出
ついで、前倒し可能なジョブ群の、どの処理（ジョブ）までが前倒し可能であるかの選定、つまり、前倒し可能なジョブ群において実際に前倒し可能なジョブ範囲の抽出が実行される。

ジョブ群における抽出ジョブから終端のジョブまでの全てのジョブが前倒し可能であると判断された場合、終端のジョブは、業務目的となるデータを出力する処理であり、例えば売上伝票データをＣＳＶ（Comma Separated Values）形式で出力する。

最終的な出力データを待ち合わせて当日の夜間バッチにおいて後続の処理が実行される場合、出力データを日中に前倒しして作成してしまうと、悪影響が生じる。例えばＣＳＶ形式で出力された売上伝票データを待ち合わせ後続の処理で売上伝票データの集計を行なう場合、集計は、夜間バッチで一括処理された結果のデータで実行される必要がある。それにもかかわらず、前倒しで分割処理されたデータを待ち合わせて動作すると、正しい集計を行なうことができない。

このため、本実施形態では、上記のケースに該当する場合、抽出ジョブから、最終的な出力データを作成するジョブの１つ手前（直前）のジョブまでの範囲を、前倒し対象とする。

したがって、バッチ処理を前倒しして実行するパターンとしては、図１０（Ａ）および図１０（Ｂ）にそれぞれ示すような２つのパターン１およびパターン２がある。図１０（Ａ）は、前倒し対象ジョブ範囲のパターン１を説明する図、図１０（Ｂ）は、前倒し対象ジョブ範囲のパターン２を説明する図である。

図１０（Ａ）に示すパターン１では、終端のジョブ（出力ジョブ）がデータを後続の処理に受け渡すことがないので、悪影響を生じさせることなく、ジョブ群における抽出ジョブから終端のジョブまでの全てのジョブを前倒して実行することができる。

図１０（Ｂ）に示すパターン２では、終端のジョブ（出力ジョブ）がデータを後続の処理に受け渡すため、抽出ジョブから、終端のジョブの１つ手前（直前）のジョブまでの範囲を、前倒し対象とする。前倒し可能なジョブ群がパターン２に該当するか否かは、具体的には以下のように判断される。つまり、図１１に示すように、出力ジョブの結果によって後続の処理が実行される以下の３つの場合(b1)〜(b3)は、抽出ジョブから出力ジョブの直前のジョブまでの範囲を前倒しの対象にする。なお、図１１は、図１０（Ｂ）に示すパターン２について前倒し可能な処理の範囲を説明する図である。

(b1) 出力ジョブがメッセージ発行処理を行なう。
(b2) 出力ジョブがファイル転送処理を行なう。
(b3) 出力ジョブの出力結果のファイルが、他の業務（次のジョブ）の起動契機／開始契機となっている。

前倒し可能なジョブ群が上記項目(b1)および(b2)に該当するか否かは、業務（ジョブネット）の最終ジョブのジョブ定義を参照することで判断される。一方、前倒し可能なジョブ群が上記項目(b3)に該当するか否かは、当該ジョブ群からデータを受け渡される次の業務（ジョブネット）の最初のジョブのジョブ定義を参照することで判断される。

〔１−４−３〕前倒し可能ジョブ一覧テーブルの作成
本実施形態では、上記項目〔１−４−１〕および〔１−４−２〕の処理に従って、図１２に示すようなジョブネットについて、図１３に示すような夜間バッチの前倒し可能ジョブ一覧テーブル２１３が作成される。ここで、図１２は、前倒し可能ジョブ一覧テーブル作成対象の夜間バッチ（ジョブネット）の一構成例を示す図である。また、図１３は、図１２に示す夜間バッチ（ジョブネット）について作成された、本実施形態における前倒し可能ジョブ一覧テーブル２１３の一例を示す図である。

前倒し実行対象のジョブは、ジョブネットの先頭から前倒し可能フラグが“ＯＮ”になっているジョブとする。そして、前倒し実行対象の終端ジョブは、ジョブネット内の一連のジョブのうち、実行順序に従い最初に前倒し可能フラグが“ＯＦＦ”になっているジョブの直前のジョブとする。また、前倒し可能ジョブ一覧テーブル２１３では、前倒し可能フラグが“ＯＮ”のジョブについて、下記項目〔１−８〕で説明する処理Ｐ５を実行する際に必要になる、一時入力ファイル名および一時出力ファイル名が設定される。

図１３に示す前倒し可能ジョブ一覧テーブル２１３の各レコードには、ジョブネット名，ジョブ名，入力ファイル名，出力ファイル名，先行ジョブネット名，先頭フラグ，終端フラグ，抽出ジョブフラグ，入力データ件数，前倒し可能フラグ，一時入力ファイル名，一時出力ファイル名が設定される。図１３に示すテーブル２１３の上側５つのレコードには、例えば図１２に示すような、５つのジョブjobA-001〜jobA-005を含む夜間バッチ（ジョブネット）jobnetA1に係る情報が設定されている。図１２に示す例では、ジョブjobA-001が抽出ジョブであり、３つのジョブjobA-001〜jobA-003が前倒し可能なジョブ範囲に含まれている。

テーブル２１３の一番上のレコードには、ジョブjobA-001に係る情報が設定されている。つまり、ジョブネット名の欄には、ジョブjobA-001の属するジョブネット名“jobnetA1”が設定され、ジョブ名の欄には、当該ジョブjobA-001のジョブ名“jobA-001”が設定される。また、入力ファイル名および出力ファイル名の欄には、それぞれ、当該ジョブjobA-001へ入力される入力ファイル名“input001”と当該ジョブjobA-001から出力される出力ファイル名“001_out”とが設定される。また、当該ジョブjobA-001に対する先行ジョブネットは存在しないので、先行ジョブネット名の欄は空欄になっている。また、当該ジョブjobA-001は、先頭ジョブであり、抽出ジョブであり、前倒し可能なジョブであるので、先頭フラグの欄，抽出ジョブフラグの欄および前倒し可能ジョブフラグの欄に“ＯＮ”が設定され、終端フラグの欄は空欄となっている。さらに、ジョブjobA-001から次のジョブjobA-002へ入力される入力データ件数の欄には“１００”が設定され、一時入力ファイル名および一時出力ファイル名の欄には、それぞれ“input001_copy_n”および“001_out_copy_n”が設定される。なお、一時入力ファイルinput001_copy_nおよび一時出力ファイル001_out_copy_nについては、図２４および図２６を参照しながら後述する。

なお、図１３に示すテーブル２１３において、図１２に示すジョブjobA-002〜jobA-005に係る情報も、上述したジョブjobA-001に係る情報と同様に設定されており、ここでは詳細な説明を省略する。

また、図１３に示すテーブ２１３においては、ジョブネットjobnetB1に係る情報も設定されている。ジョブネットjobnetB1については先行するジョブネットが存在し、ジョブネットjobnetB1の先頭ジョブjobB-001の先行ジョブネット名の欄には、ジョブネット名“jobnetA1”が設定されている。

〔１−５〕処理Ｐ２について
処理Ｐ２は、事前準備の処理で、上述したように、テスト運用時に、トランザクション量と実行時間との相関テーブルを作成する処理であり、下記項目〔１−５−１〕および〔１−５−２〕の処理を実行する。

〔１−５−１〕夜間バッチがアクセスするＤＢの調査、および、トランザクション量を記憶するテーブルの作成
前準備として、夜間バッチがアクセスするＤＢを調査することで、図１４および図１５に示す２つのテーブル２１４および２１５が作成される。なお、図１４は、本実施形態におけるデータベースアクセスジョブネット管理情報テーブル２１４の一例（初期状態）を示す図である。また、図１５は、本実施形態におけるデータベーストランザクション情報テーブル２１５の一例（初期状態）を示す図である。

〔１−５−１−１〕データベースアクセスジョブネット管理情報テーブル
図１４に示すように、データベースアクセスジョブネット管理情報テーブル２１４には、各ＤＢにアクセスするジョブネット（夜間バッチ）に関する情報や、当該ジョブネットに属する各ジョブの実行時間に関する情報が保存される。テーブル２１４に保存される情報は、下記項目(c1)〜(c7)の通りである。

(c1) デッドライン時刻：オンライン業務の開始時刻であり、夜間に実行されるジョブネットを完了させておかなければならない時刻。図１４では例えば時刻７：００が設定されている。
(c2) ＤＢ名：ジョブネットがアクセスするＤＢのＤＢ名。図１４では例えばDBMS_A,DBMS_B,DBMS_Cが設定されている。
(c3) ジョブネット名：各ＤＢにアクセスするジョブネットのジョブネット名。なお、一つのジョブネット内で複数のＤＢへアクセスすることがあるため、同一のジョブネット名が複数のＤＢ名に対応付けられる場合がある。図１４では例えばjobnetA1,jobnetB1,jobnetC1等が設定されている。

(c4) 開始時刻：各ジョブネット（夜間バッチ）の開始時刻。
(c5) ジョブ名：ジョブネット内に登録されているジョブのジョブ名。
(c6) 実行時間(通常)：各ジョブの実行時間（各ジョブの実行に要する時間）。下記項目〔１−５−２〕で後述するごとくテスト運用時に採取される情報。テーブル２１４作成直後の初期状態において実行時間(通常)の欄は空欄になっている。
(c7) 実行時間(予測)：各ジョブの予測実行時間。下記項目〔１−６−２〕で後述するごとく実運用時に採取されるトランザクション量に基づいて予測される情報。テーブル２１４作成直後の初期状態において実行時間(予測)の欄は空欄になっている。

〔１−５−１−２〕データベーストランザクション情報テーブル
図１５に示すように、データベーストランザクション情報テーブル２１５には、日中バッチの処理時間帯（時刻６：００〜２１：００）における各ＤＢに対する単位時間（ここでは１時間）当たりのトランザクション量に関する情報が保存される。テーブル２１５に保存される情報は、下記項目(d1)〜(d3)の通りである。

(d1) ＤＢ名：ジョブネットがアクセスするＤＢのＤＢ名。上記データベースアクセスジョブネット管理情報テーブル２１４に設定されたＤＢ名と同じＤＢ名が設定される。図１５では例えばDBMS_A,DBMS_B,DBMS_Cが設定されている。
(d2) トランザクション量(通常)：単位時間（例えば１時間）ごとの各ＤＢへのトランザクション量。下記項目〔１−５−２〕で後述するごとくテスト運用時に採取される情報。テーブル２１５作成直後の初期状態において、トランザクション量(通常)の欄は空欄になっている。
(d3) トランザクション量(実績)：単位時間（例えば１時間）ごとの各ＤＢへのトランザクション量。下記項目〔１−６−１〕で後述するごとく実運用時に採取される情報。テーブル２１５作成直後の初期状態において、トランザクション量(実績)の欄は空欄になっている。

〔１−５−２〕データベースアクセスジョブネット管理情報テーブルおよびデータベーストランザクション情報テーブルへの記録
業務システムのテスト運用において、各ジョブの実行に要する時間が、採取され、図１６に示すように、データベースアクセスジョブネット管理情報テーブル２１４の実行時間(通常)の欄に記録される。また、業務システムのテスト運用において、各ＤＢに対する日中バッチの単位時間当たりのトランザクション量も、採取され、図１７に示すように、データベーストランザクション情報テーブル２１５のトランザクション量(通常)の欄に記録される。

なお、図１６は、テスト運用で採取された各ジョブの実行時間(通常)を記録されたデータベースアクセスジョブネット管理情報テーブル２１４の一例を示す図である。また、図１７は、テスト運用で採取された各ＤＢに対するトランザクション量(通常)を記録されたデータベーストランザクション情報テーブル２１５の一例を示す図である。

〔１−６〕処理Ｐ３について
処理Ｐ３は、実運用時の処理で、上述したように、日々の運用で各ＤＢに対するトランザクション量の増大を監視し、バッチ処理の前倒し実行が必要か否かを判断する処理であり、下記項目〔１−６−１〕および〔１−６−２〕の処理を実行する。

〔１−６−１〕トランザクション量の監視
業務システムの実運用が開始されると、各ＤＢへの実トランザクション量が単位時間（１時間）ごとに採取される。
採取された実トランザクション量は、図１８に示すように、データベーストランザクション情報テーブル２１５のトランザクション量(実績)の欄に設定される。図１８に示すテーブル２１５では、時刻７：００時点および時刻８：００時点でのデータベースDBMS_A，DBMS_B，DBMS_Cに対する実トランザクション量が、トランザクション量(実績)として記録されている。なお、図１８は、実運用で採取された各ＤＢに対するトランザクション量(実績)を記録されたデータベーストランザクション情報テーブル２１５の一例を示す図である。

〔１−６−２〕前倒し実行の必要性の判断
そして、前倒しが必要か否かの判断が以下のようにして行なわれる。つまり、テーブル２１５における単位時間当たりの実トランザクション量と、テスト運用時に採取されたテーブル２１４における各ジョブの実行時間(通常)とに基づき、当日のジョブネットの実行時間が予測される。ここでは、以下の２つの例１および例２について、ジョブネットjobnetA1の実行時間の予測手法を説明する。

〔１−６−２−１〕例１
例１では、突発的なデータ増加がない場合の予測手法、例えば図１８の時刻７：００時点でのジョブネットjobnetA1の実行時間を予測する手法について説明する。

ここで、図１８に示すように、テスト運用での時刻６：００〜７：００におけるトランザクション量(通常)は１００であり、実運用での時刻６：００〜７：００におけるトランザクション量(実績)は８０である。また、テスト運用でのジョブネットjobnetA1の実行時間は、４つのジョブjobA-001〜jobA-004の実行時間(通常)の総和つまり00:30（３０分）となる。

この場合、テスト運用でのトランザクション量１００よりも実運用でのトランザクション量８０の方が少ないので、突発的なデータ増加は発生していないと見なされる。データ増加がないと見なされた場合には、図１９に示すように、データベースアクセスジョブネット管理情報テーブル２１４の実行時間(予測)の欄に、テスト運用での実行時間(通常)の時間がそのまま設定される。なお、図１９は、実運用時にトランザクション量の増加がない場合の実行時間(予測)を記録されたデータベースアクセスジョブネット管理情報テーブル２１４の一例を示す図である。

〔１−６−２−２〕例２
例２では、データ増加がある場合、例えば図１８の時刻８：００時点でのジョブネットjobnetA1の実行時間を予測する手法について説明する。

ここで、図１８に示すように、テスト運用での時刻７：００〜８：００におけるトランザクション量(通常)は１２０であり、実運用での時刻７：００〜８：００におけるトランザクション量(実績)は２００である。また、テスト運用でのジョブネットjobnetA1の実行時間は、４つのジョブjobA-001〜jobA-004の実行時間(通常)の総和つまり00:30（３０分）となる。

この場合、テスト運用でのトランザクション量１２０よりも実運用でのトランザクション量２００の方が多いので、データ増加が発生していると見なされる。データ増加があると見なされた場合には、テスト運用時と実運用時とのそれぞれについて今までの単位時間当たりのトランザクション量の総和が算出され、テスト運用時の総和と実運用時の総和とが比較される。

つまり、テスト運用での時刻６：００〜８：００でのトランザクション量の総和は１００＋１２０＝２２０であり、実運用での時刻６：００〜８：００でのトランザクション量の総和は８０＋２００＝２８０である。これらの総和を比較すると、テスト運用での総和よりも実運用での総和の方が大きい。この場合、夜間ジョブの実行時間は、下式（１）のごとく、比率計算によって予測される。

[実運用での夜間の各ジョブの予測実行時間]
＝[テスト運用での実行時間]×[実運用でのトランザクション量の総和]／[テスト運用でのトランザクション量の総和] （１）

図１８に示す例では、上式（１）に基づき、ジョブネットjobnetA1内のジョブjobA-001の予測実行時間が、下式（２）のごとく算出される。
[実運用での夜間ジョブjobA-001の予測実行時間]＝５分×２８０／２２０
＝約７分 （２）

このように算出される各ジョブの予測実行時間は、図２０に示すように、データベースアクセスジョブネット管理情報テーブル２１４の実行時間(予測)の欄に設定される。実行時間(予測)の欄に以前に算出された情報が設定されている場合には、最新の予測実行時間が上書き設定される。なお、図２０は、実運用時にトランザクション量の増加がある場合の実行時間(予測)を記録されたデータベースアクセスジョブネット管理情報テーブル２１４の一例を示す図である。

このようにしてテーブル２１４に記録された夜間の各ジョブの予測実行時間に基づき、クリティカルパスが算出され、算出されたクリティカルパスがデッドライン時刻に間に合うか否かが評価される。そして、クリティカルパスがデッドライン時刻に間に合わないと評価された場合、つまりクリティカルパスの処理がデッドライン時刻までに完了しないと評価された場合、夜間バッチ処理の日中への前倒しが必要であると判断される。なお、クリティカルパスは、図５２を参照しながら後述するクリティカルパス管理情報テーブル２１６によって管理される。クリティカルパスの評価等については、図４２，図４３および図５２を参照しながら後述する。

〔１−７〕処理Ｐ４について
処理Ｐ４は、実運用時の処理で、上述したように、日中に前倒しする夜間バッチ処理を選択するとともに、日中における夜間バッチ処理の実行開始時刻を決定する処理であり、下記項目〔１−７−１〕および〔１−７−２〕の処理を実行する。つまり、上述した処理Ｐ３によって夜間バッチ処理の日中への前倒しが必要であると判断された場合、下記項目〔１−７−１〕および〔１−７−２〕の処理が実行される。なお、当日の夜間バッチ処理は、前述の予測実行時間に基づいて算出されたクリティカルパスが明確になっていることを前提とする。クリティカルパスは、各ジョブネットの予測実行時間に基づき、一般的な手法によって導出される。

〔１−７−１〕日中に前倒しする夜間バッチ処理の選択
日中に前倒しする夜間バッチ処理の選択は、以下の手順(e1)〜(e7)で行なわれる。
(e1) トランザクション増加から予測された予測実行時間に基づき、導出された夜間バッチのクリティカルパス上に、日中に前倒し可能なバッチ処理（ジョブ群）が存在するか否かをチェックする。

(e2) 前倒し可能なバッチ処理が存在した場合、図２１に示すような前倒し候補一覧テーブル２１７が作成され、予測実行時間の最も長いバッチ処理（前倒し優先度が１のジョブネット）が抽出される。なお、図２１は、本実施形態における前倒し候補一覧テーブル２１７の一例を示す図である。ここで、前倒し候補一覧テーブル２１７は、以下のようにして作成される。つまり、前倒し可能ジョブ一覧テーブル２１３中の前倒し可能フラグが“ＯＮ”のジョブのうち、クリティカルパス上に存在するジョブが抽出される。そして、抽出された各ジョブの予測実行時間をデータベースアクセスジョブネット管理情報テーブル２１４から抽出して合計することで、前倒し可能なバッチジョブの予測実行時間の合計が算出され、前倒し候補一覧テーブル２１７が作成される。その際、予測実行時間が長い順に、前倒し優先度が“１”から昇順に設定される。前倒し候補一覧テーブル２１７では、ジョブネット名と、前倒し可能なジョブ群に属するジョブのジョブ名と、前記合計および前記前倒し優先度とが対応付けられて保存される。

(e3) 上記手順(e2)で抽出されたバッチ処理を前倒し実行した場合のクリティカルパス全体の実行時間tcが再計算される。つまり、元々のクリティカルパス全体の実行時間toから、上記手順(e2)で抽出されたバッチ処理の実行時間tbを減算した値to−tbが上記実行時間tcとして算出される。そして、当該クリティカルパスの開始時刻Ｔcに上記実行時間tc（＝to−tb）を加算して得られる時刻Ｔc＋tcがデッドライン時刻を超えているか否か、つまり前倒し後のクリティカルパス全体の処理がデッドライン時刻までに完了するか否かがチェックされる。ここで、時刻Ｔc＋tcがデッドライン時刻以前であればクリティカルパス全体の処理はデッドライン時刻までに完了すると判断される一方、時刻Ｔc＋tcがデッドライン時刻を過ぎていればクリティカルパス全体の処理はデッドライン時刻までに完了しないと判断される。

(e4) 上記手順(e3)のチェックの結果、処理がデッドライン時刻までに完了しないと判断された場合、上記手順(e2)の処理に戻り、次の前倒し対象バッチ処理（前倒し優先度が２のジョブネット）が抽出される。そして、抽出された前倒し対象バッチ処理について、上記手順(e3)と同様の処理が行なわれる。上記手順(e2)〜(e4)の処理は、上記手順(e3)でクリティカルパス全体の処理がデッドラインまでに完了すると判断されるまで繰り返し実行される。

(e5) １つ、または複数のバッチ処理を前倒しすることでデッドライン時刻までに処理が完了すると判断された場合、下記項目〔１−７−２〕の処理が実行される。

(e6) 前倒し実行が決定したジョブ群を管理する、図２２に示すような前倒しジョブ群一覧テーブル２１８が作成される。前倒しジョブ群一覧テーブル２１８には、前倒しジョブ群に属するジョブのジョブ名が保持される。また、前倒しジョブ群一覧テーブル２１８には、前倒し実行開始時刻、および、前倒し実行回数（初期状態では０）が保持されて管理される。なお、図２２は、本実施形態における前倒しジョブ群一覧テーブル２１８の一例を示す図である。

(e7) 処理が上記手順(e5)に該当しない場合、つまり、前倒し候補一覧テーブル２１７に登録された前倒し可能なバッチ処理の全てを前倒し実行したとしてもクリティカルパス全体の処理がデッドライン時刻までに完了しない場合、ジョブ群の前倒しは実行せず、アラームがシステム管理者等に対し通知される。

〔１−７−２〕日中における夜間バッチ処理の実行開始時刻の決定
上記項目〔１−７−１〕の処理によって、日中に前倒しする夜間バッチ処理が選択されると、以下の手順(f1)〜(f4)で、日中における夜間バッチ処理の実行開始時刻が決定される。

なお、本実施形態の手法を実現するためには、以下の点を考慮する必要がある。近年の経営スピードの向上のために、以前から、夜間一括処理していた業務処理を、日中バッチとして日中に実行するケースもある。通常、日中バッチの需要は、夜間バッチと比較して極めて低く、日中バッチが稼働していても、サーバリソースには常時余裕があるのが一般的である。このため、一多重〜数多重のバッチジョブを夜間から日中に前倒しするケースにおいては、特にサーバリソースの逼迫を考慮する必要はない。しかし、夜間バッチを大量に前倒しして日中に実行しようとする場合には、サーバリソースが逼迫する虞があるため、サーバリソースの観点から、前倒しした夜間バッチが日中バッチに影響を与えないように考慮する必要がある。

(f1) トランザクションの増加が検知され前倒し実行が必要と判断された場合、即時に夜間バッチ処理が前倒されて実行される。これが、日中に実行される１回目のバッチ処理となる。このとき、図２２に示すように、前倒しジョブ群一覧テーブル２１８の前倒し実行開始時刻の欄に時刻（例えば１２：００）が保存される。
(f2) 上記手順(f1)において、前倒し可能なバッチ処理（ジョブ群）が複数存在する場合、優先順位の高いバッチ処理から順に開始・実行される。

(f3) 上記手順(f2)でバッチ処理を順に開始・実行する際、日中バッチを含め処理多重度の上限チェックが実施され、処理多重度が上限に達していない場合のみ実際にジョブが起動される。処理多重度が上限に達した場合、バッチ処理の実行は保留され、処理多重度の空きが生じると、保留したバッチ処理の実行が開始される。
(f4) 以降、オンライン業務が閉塞するまで１時間ごとに前倒し可能なバッチ処理が実行される。

〔１−８〕処理Ｐ５について
処理Ｐ５は、実運用時の処理で、上述したように、前倒して処理されたデータを活用し、バッチ処理を複数回実行してもバッチ処理が正しく実行されるよう制御する処理であり、下記項目〔１−８−１〕および〔１−８−２〕の処理を実行する。

〔１−８−１〕一時入力ファイルおよび一時出力ファイルの作成
クリティカルパス上にあるジョブネットを前倒して日中に実行する際、前倒し可能ジョブ一覧テーブル２１３および前倒し候補一覧テーブル２１７が参照される。特に、前倒し可能ジョブ一覧テーブル２１３については、図２３に示す要部が参照される。なお、図２３は、図１３に示す前倒し可能ジョブ一覧テーブル２１３から、参照すべき要部を抽出して示す図である。

このとき、前倒し可能ジョブ一覧テーブル２１３のレコードが先頭から順に参照され、前倒し可能フラグが“ＯＮ”になっているジョブが始点として抽出される（図２３に示す例ではジョブjobA-001が抽出される）。また、同じジョブネット内の一連のジョブのうち、実行順序に従い最初に前倒し可能フラグが“ＯＦＦ”になるジョブの直前のジョブが終点として抽出される（図２３に示す例ではジョブjobA-003が抽出される）。そして、上記始点のジョブから上記終点のジョブまでの一連のジョブ（図２３に示す例では３つのジョブjobA-001〜jobA-003）が前倒して実行される。

また、図２４に示すように、ジョブネットの入力データは、前倒し可能ジョブ一覧テーブル２１３に設定された一時入力ファイル名（図２３ではinput001_copy_n）を付与されて保存される。また、ジョブ毎の出力ファイルは、前倒し可能ジョブ一覧テーブル２１３に設定された一時出力ファイル名（図２３では001_out_copy_n〜003_out_copy_n）にリネームして保存される。なお、図２４は、本実施形態における前倒し処理を説明する図である。

図２３および図２４における一時入力ファイル名および一時出力ファイル名における“n”は、前倒しジョブ群一覧テーブル２１８によって保存・管理される前倒し実行回数である。つまり、１回目の前倒し実行時の一時入力ファイルのファイル名はinput001_copy_1であり、１回目の前倒し実行時の一時出力ファイルのファイル名は001_out_copy_1〜003_out_copy_1である。同様に、ｎ回目の前倒し実行時の一時入力ファイルのファイル名はinput001_copy_nであり、ｎ回目の前倒し実行時の一時出力ファイルのファイル名は001_out_copy_n〜003_out_copy_nである。

また、図２４では、時刻１４：００の時点で１回目の前倒しが実行される例が示されている。このとき、時刻７：００〜１４：００のデータinput001が一時入力ファイルinput001_copy_n（ｎ＝１）にコピーされて保存される。当該一時入力ファイルinput001_copy_n（ｎ＝１）はジョブjobA-001に入力され、ジョブjobA-001から得られた出力ファイル001_outが、一時出力ファイル001_out_copy_n（ｎ＝１）にリネームされて保存される。同様にして、一時出力ファイル002_out_copy_n（ｎ＝１）および003_out_copy_n（ｎ＝１）が保存される。ｎは、上述した通り、前倒し実行回数に応じた追番（シリアルナンバ）である。

一時入力ファイルおよび一時出力ファイルは、以下の手順(g1)〜(g5)で作成される。
(g1) 前倒し候補一覧テーブル２１７を参照し、前倒し優先度に基づいて前倒し実行するジョブ群を決定する。
(g2) 前倒し可能ジョブ一覧テーブル２１３で上記手順(g1)に該当するジョブの情報を参照し、以降の手順(g3)〜(g5)を実施する。

(g3) ジョブネットの入力データ（図２４に示す例では入力ファイルinput001）を一時入力ファイル名（図２４に示す例ではinput001_copy_n）でコピーして保存する。その際に、本日、何回目の前倒し処理であるかを、前倒しジョブ群一覧テーブル２１８の前倒し実行回数をカウントアップし、当該前倒し実行回数をファイル名に追番号ｎとして付加する。

(g4) ジョブネットを前倒し実行する。このとき、前倒し対象のジョブは前倒し実行範囲内のジョブである。
(g5) ジョブが終了するごとに、前倒し可能ジョブ一覧テーブル２１３に従って、出力ファイル（図２４に示す例ではファイル001_out〜003_out）を、一時出力ファイル名（図２４に示す例では001_out_copy_n〜003_out_copy_n）にリネームして保存する。この際に上記手順(g3)と同様の追番号ｎがファイル名に付加されている。

〔１−８−２〕バッチ処理を複数回実行してもバッチ処理が正しく実行されるための制御
本実施形態では、バッチ処理を複数回実行してもバッチ処理が正しく処理されるよう、２回目以降の前倒し実行時には、既に処理された処理済みデータに対する処理は行なわないで、入力データにおける処理済みデータ以外の未処理データが処理対象になるようにしている。

図２５は、前倒し処理を１回だけ実行した場合のバッチ処理の例を説明する図である。図２５に示す例では、時刻７：００〜１４：００の間に溜まったデータは、時刻１４：００の時点で１回目の夜間バッチで前倒して処理されている。そして、時刻２２：００から実行される２回目（最終回）の夜間バッチでは、入力データのうち、時刻７：００〜１４：００の処理済みデータに対する処理は行なわれず、時刻１４：００〜２０：００の間に溜まった未処理データ（最終未処理データ）に対する処理が行なわれる。

一方、前倒し実行していないジョブ以降の一連のジョブ（例えば図１２のジョブjobA-004およびjobA-005参照）の処理対象データは、前倒し実行済データを含めた全データである。このため、処理済データと未処理データとを識別し、必要であれば、各前倒し段階で得られたデータのマージ処理を行なう必要がある。したがって、前倒し実行していないジョブ以降の一連のジョブには、前倒し可能なジョブ群のうちの最終ジョブにおいて、各前倒し段階で得られたデータをマージしたものが、入力データとして入力される（図２６の出力ファイル003_outからジョブjobA-004への太点線矢印Ａ参照）。

ここで、前倒し処理を２回以上実行した場合のバッチ処理の例について、図２６および以下の手順(h1)〜(h4)を参照しながら説明する。

(h1) ｎ回目（ｎは２以上の整数）の前倒し実行に際し、まず、以下のようなジョブネット実行前の準備を行なう。つまり、ジョブネットの入力データinput001（オンライン処理によって得られる結果ＤＢの全レコード）を一時入力ファイルinput001_copy_nとしてコピーして保存する。そして、ジョブネットの入力データinput001のうち、前倒し実行で処理済のデータを除外する。具体的には、入力データinput001と、前回の前倒し実行時に保存された一時入力ファイルinput001_copy_(n-1)とを比較し、一致したデータを入力データinput001から削除することで、未処理データが得られジョブネットに入力される。図２６では、ｎ回目の前倒し実行時に、時刻１９：００〜２０：００のデータ（前倒し未処理分）が未処理データ（最終未処理データ）として得られる。

(h2) 上記手順(h1)で得られた未処理データを、入力ファイルinput001として、ジョブネットの先頭ジョブjobA-001に入力し、ジョブネットを実行する。その際、前倒し可能ジョブ一覧テーブル２１３において前倒し可能フラグが“ＯＮ”に設定されているジョブjobA-001〜jobA-003が実行される。ジョブjobA-003の後のジョブjobA-004およびjobA-005による処理は、夜間バッチ(最終回)で実行される。

(h3) 上記手順(h2)で実行した最後のジョブjobA-003の出力データ（図２６上側の出力ファイル003_out参照；第２部分出力データ）と前倒し実行時に保存されたｎ個の一時出力ファイル003_out_copy_1〜003_out_copy_n（第１部分出力データ）とをマージする。そして、マージ結果を、出力ファイル003_out（図２６下側参照）として保存する。

(h4) 上記手順(h3)でマージして全データ分となったファイル（図２６下側の出力ファイル003_out）を前倒し実行していないジョブ群の先頭ジョブjobA-004に入力し（図２６の太点線矢印Ａ参照）、以降のジョブjobA-004およびjobA-005による処理が実行される。

なお、図２６に示すように、前倒し可能フラグが“ＯＮ”のジョブの各出力データ00x_outは、前倒し実行時に保存した一時出力ファイル00x_out_copy_1〜00x_out_copy_n（部分中間出力データ）とマージされ、それぞれ保存される。図２６において、ｘは１または２である。また、マージ後、copyファイルinput001_copy_1〜input001_copy_nおよび00y_out_copy_1〜00y_out_copy_nは削除される。図２６において、ｙは１，２，３である。

〔２〕本実施形態のジョブ管理サーバ（処理装置）の構成
次に、図２７を参照しながら、項目〔１〕で説明した処理方法によってバッチ業務を行なうスケジュール装置１を含む、本実施形態のジョブ管理サーバ（処理装置）１００の構成について説明する。なお、図２７は、本実施形態におけるジョブ管理サーバ１００のハードウエア構成例および機能構成例を示すブロック図である。

図２７に示すように、本実施形態のジョブ管理サーバ１００は、第１期間（日中のオンライン処理期間）に第１処理（オンライン処理）を実行し第１期間後の第２期間（夜間のバッチ処理期間）に第２処理（バッチ処理）を実行する処理装置である。また、ジョブ管理サーバ１００は、ＰＣ（Personal Computer）等のコンピュータであり、後述するスケジュール装置１としての機能を果たす。

ジョブ管理サーバ１００は、少なくとも、ＣＰＵ（Central Processing Unit），ＭＰＵ（Micro-Processing Unit）等の処理部（プロセッサ）１０と、ＲＡＭ（Random Access Memory），ＨＤＤ（Hard Disk Drive），ＳＳＤ（Solid State Device）等の記憶部（メモリ）２０とを有している。

処理部１０は、記憶部２０から所定のアプリケーションプログラム（処理プログラム）を読み出して実行することで後述するジョブスケジューラ部１１としての機能を果たすほか、ジョブ実行部１２としての機能を果たす。なお、前記所定のアプリケーションプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、処理部１０は、当該記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置としての記憶部２０に転送し格納して用いる。

記憶部２０は、前記所定のアプリケーションプログラムを保存するほか、処理部１０による処理に必要な各種情報等を保存する。例えば、記憶部２０は、前記各種情報等としてジョブ定義情報２１を保存する。ジョブ定義情報２１には、図２８を参照しながら後述する各種情報２１１〜２１８が含まれている。

このようなジョブ管理サーバ１００（スケジュール装置１）において、ジョブは、ジョブ定義情報２１として登録される。

また、ジョブスケジューラ部１１は、ジョブの定義，起動条件などを管理するもので、図２８を参照しながら後述するシステム情報登録機能，ジョブ登録機能，ジョブ前倒し機能，トランザクション管理機能およびジョブ前倒し実行制御機能を果たす。これらの機能は、前述した通り、処理部１０が記憶部２０から所定のアプリケーションプログラム（処理プログラム）を読み出して実行することで実現される。

さらに、ジョブ実行部１２は、ジョブの起動条件が満たされた場合に、ジョブスケジューラ部１１からのジョブ起動依頼に応じてジョブを起動する。なお、ジョブ実行部１２としての機能も、処理部１０が記憶部２０から所定のアプリケーションプログラムを読み出して実行することで実現される。

〔３〕本実施形態のスケジュール装置の構成
次に、図２８を参照しながら、上記項目〔１〕で説明した処理方法でバッチ業務を行なうスケジュール装置１の構成について説明する。なお、図２８は、本実施形態におけるスケジュール装置１の機能構成例を示すブロック図である。

図２８に示すように、本実施形態のスケジュール装置１は、図２７を参照しながら上述した通り、ジョブスケジューラ部１１，ジョブ実行部１２およびジョブ定義情報２１（記憶部２０）を有している。

ジョブスケジューラ部１１は、ジョブ起動依頼部１１０と、システム情報登録機能を果たすシステム情報登録部１１１と、ジョブ登録機能を果たすジョブ登録部１１２とを有する。また、ジョブスケジューラ部１１は、ジョブ前倒し機能を果たす前倒しジョブ抽出部１１３および前倒しジョブ決定部１１４と、トランザクション管理機能を果たすＤＢアクセス設定部１１５およびＤＢアクセス解析部１１６とを有する。さらに、ジョブスケジューラ部１１は、ジョブ前倒し実行制御機能を果たす入力データ管理部１１７，ジョブ実行部１１８および出力データ管理部１１９を有する。

ジョブ起動依頼部１１０は、ジョブ実行部１１８からの指示に従ってジョブ起動依頼を、ジョブ実行部１２のジョブ起動部１２１に対して行ない、当該ジョブ起動部１２１に所望のジョブを実行させる。

システム情報登録部１１１は、業務者（顧客），システム管理者等の指示に従って、ジョブ定義情報２１に含まれるシステム定義情報２１１を記憶部２０に登録する。システム定義情報２１１には、図５０に示すように、内部管理ファイルの配置先，履歴ファイルのサイズ，仮想時間の利用有無，仮想時間，テスト運用の有無，デッドライン時刻，オンライン／バッチ業務切替時刻などが含まれる。なお、図５０は、本実施形態におけるシステム定義情報２１１の一例を示す図である。

特に、テスト運用の有無，デッドライン時刻およびオンライン／バッチ業務切替時刻は、それぞれ、図３０〜図３２を参照しながら後述するごとく、業務者（顧客）によって設定される。ここで、テスト運用の有無は、現在の運用がテスト運用であるか本番運用（実運用）であるかを指定する情報である。デッドライン時刻は、前述した通り、オンライン業務の開始時刻で、夜間に実行されるジョブネットを完了させておかなければならない時刻であり（上記項目(c1)参照）、図５０に示す例では、時刻７：００が設定されている。オンライン／バッチ業務切替時刻は、業務をオンライン業務からバッチ業務へ切り替える時刻であり、図５０に示す例では時刻２２：００が設定されている。

ジョブ登録部１１２は、業務者（顧客），システム管理者等の指示に従って、ジョブ定義情報２１に含まれるジョブネット定義情報２１２を記憶部２０に登録する。ジョブネット定義情報２１２は、ジョブ管理サーバ１００（スケジュール装置１）の管理対象であるジョブネットを定義する情報である。ジョブネット定義情報２１２には、図５１に示すように、ジョブネット名と、先行ジョブネット名と、ジョブネットの起動時刻等の起動条件と、当該ジョブネットに属するジョブのジョブ名と、各ジョブのコマンド名と、各ジョブのディレクトリと、ジョブ番号と、先行ジョブ番号とが含まれる。なお、図５１は、本実施形態におけるジョブネット定義情報２１２の一例を示す図である。

ここで、記憶部２０のジョブ定義情報２１には、上述したシステム定義情報２１１およびジョブネット定義情報２１２のほかに、前倒し可能ジョブ一覧テーブル２１３およびデータベースアクセスジョブネット管理情報テーブル２１４が含まれる。また、記憶部２０のジョブ定義情報２１には、データベーストランザクション情報テーブル２１５，クリティカルパス管理情報テーブル２１６，前倒し候補一覧テーブル２１７および前倒しジョブ群一覧テーブル２１８が含まれる。

前倒し可能ジョブ一覧テーブル２１３は、例えば図１３や図２３に示すように、前倒し可能なジョブに関する情報を保持するもので、上記項目〔１−４−３〕で説明したように作成される。

データベースアクセスジョブネット管理情報テーブル２１４は、例えば図１４，図１６，図１９，図２０に示すように、各ＤＢにアクセスするジョブネットに関する情報や、当該ジョブネットに属する各ジョブの実行時間に関する情報を保持する。より具体的に、テーブル２１４は、上記項目〔１−５−１−１〕で説明したように、上記項目(c1)〜(c7)の情報を保存する。

データベーストランザクション情報テーブル２１５は、例えば図１５，図１７，図１８に示すように、日中バッチの処理時間帯における各ＤＢに対する単位時間当たりのトランザクション量に関する情報を保持する。より具体的に、テーブル２１５は、上記項目〔１−５−１−２〕で説明したように、上記項目(d1)〜(d3)の情報を保存する。

クリティカルパス管理情報テーブル２１６は、上記項目〔１−６−２−２〕で説明したように、テーブル２１４に記録された夜間の各ジョブの予測実行時間に基づいて算出されるクリティカルパスを管理する。クリティカルパス管理情報テーブル２１６には、図５２に示すように、クリティカルパス上におけるジョブネットのジョブネット名が保持されている。なお、図５２は、本実施形態におけるクリティカルパス管理情報テーブル２１６の一例を示す図である。また、クリティカルパス管理情報テーブル２１６を用いた処理については、図４２および図４３を参照しながら後述する。

前倒し候補一覧テーブル２１７は、上記項目〔１−７−１〕の手順(e2)で説明したように、バッチ処理を予測実行時間の長い順に抽出するために用いられる。前倒し候補一覧テーブル２１７には、図２１に示すように、ジョブネット名と、前倒し可能なジョブ群に属するジョブのジョブ名と、前記合計および前記前倒し優先度とが対応付けられて保存される。

前倒しジョブ群一覧テーブル２１８は、上記項目〔１−７−１〕の手順(e6)で説明したように、前倒し実行が決定したジョブ群を管理するために用いられる。前倒しジョブ群一覧テーブル２１８には、図２２に示すように、前倒しジョブ群に属するジョブのジョブ名と、前倒し実行開始時刻と、前倒し実行回数（初期状態では０）とが対応付けられて保存される。

前倒しジョブ抽出部１１３は、テスト運用時に全ジョブを対象にジョブ（アプリケーション）処理を解析し、前倒し可能なジョブを特定して前倒し可能ジョブ一覧テーブル２１３に記録する。特に、本実施形態の前倒しジョブ抽出部１１３は、上記項目〔１−４〕で説明した処理Ｐ１、つまり、テスト運用時に、前倒して実行可能な夜間バッチと、前倒し可能な処理の範囲とを抽出する処理（上記項目〔１−４−１〕〜〔１−４−３〕の処理参照）を実行する。前倒しジョブ抽出部１１３のより具体的な動作については、図３３〜図３７を参照しながら後述する。

前倒しジョブ決定部１１４は、トランザクション管理機能（後述するＤＢアクセス解析部１１６）において当日の夜間バッチの長時間化（遅延）が検知された場合に呼び出されて起動される。そして、前倒しジョブ決定部１１４は、上記項目〔１−７〕で説明した処理Ｐ４、つまり、クリティカルパス上のジョブを対象にして、日中に前倒しする夜間バッチ処理の選択処理（上記項目〔１−７−１〕の処理参照）と日中における夜間バッチ処理の実行開始時刻の決定処理（上記項目〔１−７−２〕の処理参照）とを実行する。前倒しジョブ決定部１１４のより具体的な動作については、図４３〜図４５を参照しながら後述する。

ＤＢアクセス設定部１１５は、テスト運用時では、夜間バッチ処理やオンライン処理のジョブ内にてＤＢへアクセスしているジョブを特定し、オンライン処理でのジョブがアクセスするＤＢへのトランザクション量(通常)の情報を取得する処理を実行する。また、ＤＢアクセス設定部１１５は、夜間バッチでのジョブの実行時間(通常)をデータベースアクセスジョブネット管理情報テーブル２１４に設定する。さらに、ＤＢアクセス設定部１１５は、本番運用（実運用）では、オンライン処理でのジョブがアクセスするＤＢへのトランザクション量(実績)の情報を取得する処理を実行する。特に、本実施形態のＤＢアクセス設定部１１５は、上記項目〔１−５〕で説明した処理Ｐ２を実行する。つまり、ＤＢアクセス設定部１１５は、夜間バッチがアクセスするＤＢの調査、および、トランザクション量を記憶するテーブルの作成を行なう（上記項目〔１−５−１〕の処理参照）。また、ＤＢアクセス設定部１１５は、データベースアクセスジョブネット管理情報テーブル２１４およびデータベーストランザクション情報テーブル２１５への記録を行なう（上記項目〔１−５−２〕の処理参照）。ＤＢアクセス設定部１１５のより具体的な動作については、図３８〜図４０を参照しながら後述する。

ＤＢアクセス解析部１１６は、本番運用（実運用）にて、ＤＢアクセス設定部１１５によって取得された、ＤＢへアクセスするジョブのトランザクション量を監視する。そして、ＤＢアクセス解析部１１６は、実運用時のトランザクション量がテスト運用時と比較して多い場合、夜間バッチ処理の実行時間を予測する。また、ＤＢアクセス解析部１１６は、予測実行時間に基づき夜間バッチ処理がデッドライン時刻までに完了しないと判断した場合、前倒し実行制御機能により、夜間バッチ処理の前倒しを実行させる。特に、本実施形態のＤＢアクセス解析部１１６は、トランザクション量の監視処理（上記項目〔１−６−１〕の処理参照）と、前倒し実行の必要性の判断処理（上記項目〔１−６−２〕の処理参照）とを実行する。ＤＢアクセス解析部１１６のより具体的な動作については、図４１および図４２を参照しながら後述する。

入力データ管理部１１７は、前倒しジョブ群を日中に複数回実行すべく、実行対象データ（未処理データ）のみを入力データとして管理し、ジョブに受け渡す処理を行なう。特に、本実施形態の入力データ管理部１１７は、上記項目〔１−８〕で説明した処理Ｐ５を実現するためのものである。入力データ管理部１１７のより具体的な動作については、図４６を参照しながら後述する。

ジョブ実行部１１８は、前倒し実行するジョブ群の範囲で、ジョブを順次起動制御するもので、所望のジョブを起動させる際には、ジョブ起動依頼部１１０を介し、ジョブ実行部１２のジョブ起動部１２１に対しジョブ起動依頼を発行する。ジョブ実行部１１８のより具体的な動作については、図４７および図４８を参照しながら後述する。

出力データ管理部１１９は、前倒しジョブ群を日中に複数回実行すべく、前倒し実行ごとに出力されたデータを個別に管理し、夜間バッチの最終実行時に出力データのマージ処理を行なう。特に、本実施形態の出力データ管理部１１９は、上記項目〔１−８〕で説明した処理Ｐ５を実現するためのものである。出力データ管理部１１９のより具体的な動作については、図４９を参照しながら後述する。

上述したシステム情報登録部１１１，ジョブ登録部１１２，前倒しジョブ抽出部１１３，前倒しジョブ決定部１１４，ＤＢアクセス設定部１１５，ＤＢアクセス解析部１１６，入力データ管理部１１７，ジョブ実行部１１８および出力データ管理部１１９としての機能は、前述した通り、処理部１０が記憶部２０から所定のアプリケーションプログラム（処理プログラム）を読み出して実行することで実現される。

なお、本実施形態の前倒しジョブ抽出部１１３は、以下の抽出部として機能する。当該抽出部は、オンライン処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されたデータ区分に対する処理を当該データ区分の範囲内で行なう後続ジョブとを含むジョブ群（前倒し可能ジョブ）を抽出する。また、当該抽出部は、前段のジョブから入力された一のデータ区分に対する一以上の処理を行ない一以上の出力データ区分を出力するジョブ（加工ジョブ／出力ジョブ）を、後続ジョブとして抽出する。さらに、当該抽出部は、他の業務との連携処理を行なうジョブがジョブ群に含まれる場合、当該ジョブ群を前倒しの対象から除外する。また、当該抽出部は、下記出力ジョブが後続ジョブに含まれる場合、ジョブ群のうち、抽出ジョブから出力ジョブの直前の後続ジョブまでのジョブを前倒しの対象とする。当該出力ジョブは、メッセージ発行処理を行なう出力ジョブ、または、ファイル転送処理を行なう出力ジョブ、または、出力が他の業務（次のジョブ）の開始契機になっている出力ジョブである。

本実施形態の前倒しジョブ決定部１１４，ＤＢアクセス解析部１１６およびジョブ実行部１１８は、抽出されたジョブ群を、バッチ処理期間（第２期間）からオンライン処理期間（第１期間）に前倒ししてオンライン処理と並行して実行する制御部として機能する。

本実施形態のＤＢアクセス解析部１１６は、以下の解析部として機能する。当該解析部は、ジョブ群を前倒ししてオンライン処理と並行して実行する実行タイミングを、オンライン処理の処理状況に応じて設定する。また、当該解析部は、少なくとも、以下の処理(1)〜(4)を実行する。処理(1)は、バッチ処理によって用いられるＤＢに対するオンライン処理のトランザクション量をオンライン処理の処理状況として監視する。処理(2)は、オンライン処理のトランザクション量に基づいてバッチ処理の予測実行時間を算出する。処理(3)は、バッチ処理の予測実行時間に基づいてバッチ処理が予め設定された完了期限（デッドライン時刻）までに完了するか否かを判断する。処理(4)は、バッチ処理が前記完了期限までに完了しないと判断されたタイミングに応じて、前記実行タイミングを設定する。

本実施形態の入力データ管理部１１７は、以下の入力データ管理部として機能する。当該入力データ管理部は、前記ジョブ群を前記実行タイミングで実行する場合、前記ジョブ群による処理済みのデータを除いた未処理データを、前記ジョブ群による処理対象として前記ジョブ群に入力する。また、当該入力データ管理部は、オンライン処理期間からバッチ処理期間になった場合、前記ジョブ群による処理済みのデータを除いた最終未処理データを、前記ジョブ群による最終処理対象として前記ジョブ群に入力する。

本実施形態の出力データ管理部１１９は、以下の出力データ管理部として機能する。当該出力データ管理部は、前記実行タイミング毎に未処理データについて前記ジョブ群によって得られた第１部分出力データと、前記最終未処理データについて前記ジョブ群によって得られた第２部分出力データとを出力データとしてマージする。また、当該出力データ管理部は、オンライン処理期間からバッチ処理期間になった場合、前記実行タイミング毎に前記ジョブ群に属する各ジョブによって得られた部分中間出力データを、各ジョブ毎に中間出力データとしてマージして出力する。

本実施形態のジョブ実行部１１８，１２は、以下のジョブ実行部として機能する。当該ジョブ実行部は、マージされた出力データに対し、バッチ処理における前記ジョブ群以降のジョブを実行する。

〔４〕本実施形態のスケジュール装置の動作
次に、図２９〜図４９を参照しながら、本実施形態に係るスケジュール装置１の動作について説明する。

〔４−１〕ジョブ実行時の動作概要
まず、図２９に示すフローチャート（ステップＳ１０１〜Ｓ１１１）に従って、本実施形態のスケジュール装置１によるジョブ実行時の動作概要について説明する。

スケジュール装置１は、今回の運用がテスト運用であるか否かを判断し（ステップＳ１０１）、テスト運用である場合（ステップＳ１０１のＹＥＳルート）、ジョブ起動依頼部１１０を介しジョブ実行部１２に対しジョブ起動依頼を行なう（ステップＳ１０２）。そして、スケジュール装置１は、ジョブ前倒し機能の前倒しジョブ抽出部１１３を起動し（ステップＳ１０３）、図３３〜図３７を参照しながら後述する処理を前倒しジョブ抽出部１１３に実行させる。この後、スケジュール装置１は、トランザクション管理機能のＤＢアクセス設定部１１５を起動し（ステップＳ１０４）、図３８〜図４０を参照しながら後述する処理をＤＢアクセス設定部１１５に実行させてから、処理を終了する。

一方、テスト運用でない場合、つまり本番運用（実運用）である場合（ステップＳ１０１のＮＯルート）、スケジュール装置１は、トランザクション管理機能のＤＢアクセス設定部１１５を起動し（ステップＳ１０５）、図３９および図４０を参照しながら後述する処理をＤＢアクセス設定部１１５に実行させる。また、スケジュール装置１は、トランザクション管理機能のＤＢアクセス解析部１１６を起動し（ステップＳ１０６）、図４１および図４２を参照しながら後述する処理をＤＢアクセス解析部１１６に実行させる。さらに、スケジュール装置１は、ジョブ前倒し機能の前倒しジョブ決定部１１４を起動し（ステップＳ１０７）、図４３〜図４５を参照しながら後述する処理を前倒しジョブ決定部１１４に実行させる。そして、ジョブ起動依頼部１１０を介しジョブ実行部１２に対しジョブ起動依頼を行なう（ステップＳ１０８）。

この後、スケジュール装置１は、ジョブ前倒し実行制御機能の入力データ管理部１１７を起動し（ステップＳ１０９）、図４６を参照しながら後述する処理を入力データ管理部１１７に実行させる。また、スケジュール装置１は、ジョブ前倒し実行制御機能のジョブ実行部１１８を起動し（ステップＳ１１０）、図４７および図４８を参照しながら後述する処理をジョブ実行部１１８に実行させる。

上述したステップＳ１０７〜Ｓ１１０の処理は、オンライン業務が閉塞するまで繰り返し実行される。オンライン業務が閉塞されると、スケジュール装置１は、ジョブ前倒し実行制御機能の出力データ管理部１１９を起動し（ステップＳ１１１）、図４９を参照しながら後述する処理を出力データ管理部１１９に実行させてから、処理を終了する。

〔４−２〕スケジュール装置に対する設定動作
次に、図３０〜図３２に示すフローチャート（ステップＳ１２１〜Ｓ１２３）に従って、本実施形態のスケジュール装置１におけるテスト運用設定動作，デッドライン時刻設定動作，オンライン／バッチ業務切換時刻設定動作について説明する。

スケジュール装置１が処理を開始するのに先立ち、システム情報登録部１１１は、図３０に示すように、ジョブ定義情報２１のシステム定義情報２１１に、業務者（顧客）等の指示に従って、テスト運用の有無を設定する（ステップＳ１２１）。このとき、業務者（顧客）からの「テスト運用」の入力値（テスト運用／本番運用）が、システム定義情報２１１の「テスト運用の有無」の欄（図５０参照）に設定される。通常、業務システムの実運用開始前には「テスト運用」が設定されて事前準備が行なわれた後、「本番運用」が設定されて実運用が開始される。

また、スケジュール装置１が処理を開始するのに先立ち、システム情報登録部１１１は、図３１に示すように、ジョブ定義情報２１のシステム定義情報２１１に、業務者（顧客）等の指示に従って、デッドライン時刻を設定する（ステップＳ１２２）。このとき、業務者（顧客）からの「デッドライン時刻」の入力値（例えば時刻７：００）が、システム定義情報２１１の「デッドライン時刻」の欄（図５０参照）に設定される。

さらに、スケジュール装置１が処理を開始するのに先立ち、システム情報登録部１１１は、図３２に示すように、ジョブ定義情報２１のシステム定義情報２１１に、業務者（顧客）等の指示に従って、オンライン／バッチ業務切替時刻を設定する（ステップＳ１２３）。このとき、業務者（顧客）からの「オンライン／バッチ業務切替時刻」の入力値（例えば時刻２２：００）が、システム定義情報２１１の「オンライン／バッチ業務切替時刻」の欄（図５０参照）に設定される。

〔４−３〕前倒しジョブ抽出部の動作
次に、図３３〜図３７に示すフローチャートに従って、本実施形態のスケジュール装置１における前倒しジョブ抽出部１１３の動作について説明する。

〔４−３−１〕抽出ジョブの前倒し可能フラグのＯＮ／ＯＦＦ設定
図３３に示すフローチャート（ステップＳ２０１〜Ｓ２１１）に従って、前倒しジョブ抽出部１１３による抽出ジョブについての前倒し可能フラグのＯＮ／ＯＦＦ設定動作、つまり抽出ジョブが前倒し可能か否かの判定動作について説明する。なお、図３３の処理を開始する時点では、図１３に示す前倒し可能ジョブ一覧テーブル２１３において、入力データ件数，前倒し可能フラグ，一時入力ファイル名および一時出力ファイル名の欄は空欄であり、それ以外の欄には各種情報が設定されている。

前倒しジョブ抽出部１１３は、まず、前倒し可能ジョブ一覧テーブル２１３のレコードを、先頭から順に一つずつ読み込む（ステップＳ２０１）。そして、前倒しジョブ抽出部１１３は、読み込んだレコードに対応するジョブが抽出ジョブであるか否か、つまり抽出ジョブフラグが“ＯＮ”か“ＯＦＦ”かを判断する（ステップＳ２０２）。

対応ジョブが抽出ジョブでない場合つまり抽出ジョブフラグが“ＯＦＦ”である場合（ステップＳ２０２のＮＯルート）、前倒しジョブ抽出部１１３は、読み込んだレコードが最終レコードか否かを判断する（ステップＳ２１１）。最終レコードである場合（ステップＳ２１１のＹＥＳルート）、前倒しジョブ抽出部１１３は処理を終了する一方、最終レコードでない場合（ステップＳ２１１のＮＯルート）、前倒しジョブ抽出部１１３はステップＳ２０１の処理に戻る。

対応ジョブが抽出ジョブである場合つまり抽出ジョブフラグが“ＯＮ”である場合（ステップＳ２０２のＹＥＳルート）、前倒しジョブ抽出部１１３は、当該レコードの先行ジョブネット名の欄を参照し、当該抽出ジョブにファイルを入力する先行ジョブネットがあるか否かを判断する（ステップＳ２０３）。先行ジョブネットがある場合（ステップＳ２０３のＹＥＳルート）、前倒しジョブ抽出部１１３は、先行ジョブネットの出力ファイルと当該抽出ジョブの入力ファイルとが一致するか否かを判断する（ステップＳ２０４）。

先行ジョブネットの出力ファイルと当該抽出ジョブの入力ファイルとが一致する場合（ステップＳ２０４のＹＥＳルート）は、上記項目〔１−４−１〕の手順（Ｂ１−１）で説明した状況に該当する。そのため、前倒しジョブ抽出部１１３は、当該抽出ジョブの前倒し可能フラグを“ＯＦＦ”に設定し（ステップＳ２０９）、当該抽出ジョブが属しているジョブネット内のジョブを、前倒し可能ジョブ一覧テーブル２１３から削除する（ステップＳ２１０）。この後、前倒しジョブ抽出部１１３は、ステップＳ２１１の処理へ移行する。

先行ジョブネットがない場合（ステップＳ２０３のＮＯルート）、または、先行ジョブネットの出力ファイルと当該抽出ジョブの入力ファイルとが一致しない場合（ステップＳ２０４のＮＯルート）、前倒しジョブ抽出部１１３は以下の判断を行なう（ステップＳ２０５）。つまり、前倒しジョブ抽出部１１３は、当該抽出ジョブの出力ファイルと後続ジョブの入力ファイルとが同じか否かを判断する（手順（Ｂ１−３）参照）。

当該抽出ジョブの出力ファイルと後続ジョブの入力ファイルとが同じ場合（ステップＳ２０５のＹＥＳルート）、前倒しジョブ抽出部１１３は、抽出ジョブの出力データの件数をカウントし、カウントした件数を、当該レコードの入力データ件数の欄に記録する（ステップＳ２０６；手順（Ｂ１−２）参照）。この後、前倒しジョブ抽出部１１３は、後続ジョブの出力データ件数が、入力データ件数の欄に記録した入力データ件数の整数倍であるか否かを判断する（ステップＳ２０７；手順（Ｂ１−３）参照）。

後続ジョブの出力データ件数が入力データ件数の欄に記録した入力データ件数の整数倍である場合（ステップＳ２０７のＹＥＳルート）、前倒しジョブ抽出部１１３は、当該抽出ジョブは『前倒し対象』と判断し、当該抽出ジョブの前倒し可能フラグを“ＯＮ”に設定する（ステップＳ２０８；上記手順（Ｂ１−５）参照）。この後、前倒しジョブ抽出部１１３は、ステップＳ２１１の処理へ移行する。

当該抽出ジョブの出力ファイルと後続ジョブの入力ファイルとが異なる場合（ステップＳ２０５のＮＯルート）、または、後続ジョブの出力データ件数が入力データ件数の欄に記録した入力データ件数の整数倍でない場合（ステップＳ２０７のＮＯルート）、前倒しジョブ抽出部１１３は以下の処理を行なう。つまり、前倒しジョブ抽出部１１３は、当該抽出ジョブは『前倒し対象外』と判断し、ステップＳ２０９の処理へ移行する（上記手順（Ｂ１−４）参照）。

〔４−３−２〕抽出ジョブ以外のジョブの前倒し可能フラグのＯＮ／ＯＦＦ設定
図３４に示すフローチャート（ステップＳ２２１〜Ｓ２３２）に従って、前倒しジョブ抽出部１１３による抽出ジョブ以外のジョブについての前倒し可能フラグのＯＮ／ＯＦＦ設定動作、つまり抽出ジョブ以外のジョブが前倒し可能か否かの判定動作について説明する。なお、図３４に示す処理は図３３に示す処理の後に実行されるものとする。

前倒しジョブ抽出部１１３は、まず、前倒し可能ジョブ一覧テーブル２１３のレコードを、先頭から順に一つずつ読み込む（ステップＳ２２１）。そして、前倒しジョブ抽出部１１３は、読み込んだレコードに対応するジョブが抽出ジョブであるか否か、つまり抽出ジョブフラグが“ＯＮ”か“ＯＦＦ”かを判断する（ステップＳ２２２）。

対応ジョブが抽出ジョブでない場合つまり抽出ジョブフラグが“ＯＦＦ”である場合（ステップＳ２２２のＮＯルート）、前倒しジョブ抽出部１１３は、ステップＳ２２１の処理に戻る。対応ジョブが抽出ジョブである場合つまり抽出ジョブフラグが“ＯＮ”である場合（ステップＳ２２２のＹＥＳルート）、前倒しジョブ抽出部１１３は、当該ジョブにファイルを入力する先行ジョブがあるか否かを判断する（ステップＳ２２３）。

先行ジョブがある場合（ステップＳ２２３のＹＥＳルート）、前倒しジョブ抽出部１１３は、当該抽出ジョブの先行ジョブの前倒し可能フラグに“ＯＮ”を記録する（ステップＳ２２４）。このように前倒し可能フラグに“ＯＮ”を記録した後、もしくは、先行ジョブがない場合（ステップＳ２２３のＮＯルート）、前倒しジョブ抽出部１１３は、当該抽出ジョブに後続するジョブについてのレコードを、前倒し可能ジョブ一覧テーブル２１３から読み込む（ステップＳ２２５）。そして、前倒しジョブ抽出部１１３は、当該ジョブが抽出ジョブであるか否か、つまり当該ジョブの抽出ジョブフラグが“ＯＮ”か“ＯＦＦ”かを判断する（ステップＳ２２６）。ステップＳ２２６では、次のジョブネットにおける抽出ジョブの検知が行なわれている。

当該ジョブが抽出ジョブである場合つまり抽出ジョブフラグが“ＯＮ”である場合（ステップＳ２２６のＹＥＳルート）、前倒しジョブ抽出部１１３は、ステップＳ２２３の処理に戻る。一方、当該ジョブが抽出ジョブでない場合つまり抽出ジョブフラグが“ＯＦＦ”である場合（ステップＳ２２６のＮＯルート）、前倒しジョブ抽出部１１３は以下の判断を行なう（ステップＳ２２７）。つまり、前倒しジョブ抽出部１１３は、先行ジョブの出力ファイルと当該ジョブの入力ファイルとが同じか否かを判断する（手順（Ｂ１−３）参照）。

先行ジョブの出力ファイルと当該ジョブの入力ファイルとが同じ場合（ステップＳ２２７のＹＥＳルート）、前倒しジョブ抽出部１１３は、当該ジョブの出力データの件数をカウントし、カウントした件数を、当該ジョブの入力データ件数の欄に記録する（ステップＳ２２８；手順（Ｂ１−２）参照）。この後、前倒しジョブ抽出部１１３は、当該ジョブの出力データ件数が、先行ジョブの入力データ件数の整数倍であるか否かを判断する（ステップＳ２２９；手順（Ｂ１−３）参照）。

当該ジョブの出力データ件数が先行ジョブの入力データ件数の整数倍である場合（ステップＳ２２９のＹＥＳルート）、前倒しジョブ抽出部１１３は、当該ジョブは『前倒し対象』と判断し、当該ジョブの前倒し可能フラグを“ＯＮ”に設定する（ステップＳ２３０；上記手順（Ｂ１−５）参照）。この後、前倒しジョブ抽出部１１３は、読み込んだレコードが最終レコードか否かを判断する（ステップＳ２３２）。最終レコードである場合（ステップＳ２３２のＹＥＳルート）、前倒しジョブ抽出部１１３は処理を終了する一方、最終レコードでない場合（ステップＳ２３２のＮＯルート）、前倒しジョブ抽出部１１３はステップＳ２２５の処理に戻る。

先行ジョブの出力ファイルと当該ジョブの入力ファイルとが異なる場合（ステップＳ２２７のＮＯルート）、または、当該ジョブの出力データ件数が先行ジョブの入力データ件数の整数倍でない場合（ステップＳ２２９のＮＯルート）、前倒しジョブ抽出部１１３は以下の処理を行なう。つまり、前倒しジョブ抽出部１１３は、当該ジョブは『前倒し対象外』と判断し、当該抽出ジョブの前倒し可能フラグを“ＯＦＦ”に設定する（ステップＳ２３１；上記手順（Ｂ１−４）参照）。この後、前倒しジョブ抽出部１１３は、ステップＳ２３２の処理へ移行する。

〔４−３−３〕連携処理を含むジョブの除外
図３５に示すフローチャート（ステップＳ２４１，Ｓ２４２）に従って、前倒しジョブ抽出部１１３による、連携処理を含むジョブを前倒し対象から除外する動作について説明する。

前倒しジョブ抽出部１１３は、図３３および図３４に示す処理によってジョブの前倒し可能フラグのＯＮ／ＯＦＦ設定を行なった後、前倒し可能と判断されたジョブ群に属する全てのジョブについて、他の業務との連携処理が存在するか否かをチェックする。つまり、前倒しジョブ抽出部１１３は、前倒し可能ジョブ一覧テーブル２１３において前倒し可能フラグが“ＯＮ”のジョブに、業務用ＲＤＢＭＳ（Relational DataBase Management System）に対するデータの挿入，更新，削除のいずれかの処理が存在するか否かをチェックする（ステップＳ２４１）。

当該処理が存在する場合（ステップＳ２４１のＹＥＳルート）、前倒しジョブ抽出部１１３は、該当するジョブが属しているジョブネット（ジョブ群）を、前倒し可能ジョブ一覧テーブル２１３から削除する（ステップＳ２４２）。一方、当該処理が存在しない場合（ステップＳ２４１のＮＯルート）、前倒しジョブ抽出部１１３は、連携処理を含むジョブの除外動作を終了する。

〔４−３−４〕前倒し可能なジョブ範囲の抽出
図３６に示すフローチャート（ステップＳ２５１〜Ｓ２５７）に従って、前倒しジョブ抽出部１１３による、前倒し可能なジョブ範囲の抽出動作について説明する。前倒しジョブ抽出部１１３は、図３５に示す処理によって連携処理を含むジョブを前倒し対象から除外した後、前倒し可能なジョブ範囲の抽出を行なう。つまり、前倒しジョブ抽出部１１３は、前倒し可能なジョブ群において実際に前倒し可能なジョブ範囲を抽出する。

前倒しジョブ抽出部１１３は、前倒し可能ジョブ一覧テーブル２１３のレコードを、先頭から順に一つずつ読み込む（ステップＳ２５１）。そして、前倒しジョブ抽出部１１３は、読み込んだレコードに対応するジョブが終端のジョブであるか否か、つまり終端フラグが“ＯＮ”か否かを判断する（ステップＳ２５２）。

対応ジョブ（当該ジョブ）が終端ジョブでない場合つまり終端フラグが“ＯＮ”でない場合（ステップＳ２５２のＮＯルート）、前倒しジョブ抽出部１１３は、読み込んだレコードが最終レコードか否かを判断する（ステップＳ２５７）。最終レコードである場合（ステップＳ２５７のＹＥＳルート）、前倒しジョブ抽出部１１３は処理を終了する一方、最終レコードでない場合（ステップＳ２５７のＮＯルート）、前倒しジョブ抽出部１１３はステップＳ２５１の処理に戻る。

該当ジョブが終端ジョブである場合つまり終端フラグが“ＯＮ”である場合（ステップＳ２５２のＹＥＳルート）、前倒しジョブ抽出部１１３は、ジョブネット定義情報２１２（図５１参照）を参照し、当該ジョブがメッセージ発行処理を実施しているか否かを判断する（ステップＳ２５３）。当該ジョブがメッセージ発行処理を実施している場合（ステップＳ２５３のＹＥＳルート）、前倒しジョブ抽出部１１３は、該当ジョブの前倒し可能フラグを“ＯＦＦ”に設定してから（ステップＳ２５６）、ステップＳ２５７の処理へ移行する。

当該ジョブがメッセージ発行処理を実施していない場合（ステップＳ２５３のＮＯルート）、前倒しジョブ抽出部１１３は、ジョブネット定義情報２１２を参照し、当該ジョブがファイル転送処理を実施しているか否かを判断する（ステップＳ２５４）。当該ジョブがファイル転送処理を実施している場合（ステップＳ２５４のＹＥＳルート）、前倒しジョブ抽出部１１３は、該当ジョブの前倒し可能フラグを“ＯＦＦ”に設定してから（ステップＳ２５６）、ステップＳ２５７の処理へ移行する。

当該ジョブがファイル転送処理を実施していない場合（ステップＳ２５４のＮＯルート）、前倒しジョブ抽出部１１３は、ジョブネット定義情報２１２を参照し、当該ジョブの出力ファイルが他のジョブネットの起動契機になっているか否かを判断する（ステップＳ２５５）。当該ジョブの出力ファイルが他のジョブネットの起動契機になっている場合（ステップＳ２５５のＹＥＳルート）、前倒しジョブ抽出部１１３は、該当ジョブの前倒し可能フラグを“ＯＦＦ”に設定してから（ステップＳ２５６）、ステップＳ２５７の処理へ移行する。一方、当該ジョブの出力ファイルが他のジョブネットの起動契機になっていない場合（ステップＳ２５５のＮＯルート）、前倒しジョブ抽出部１１３は、ステップＳ２５７の処理へ移行する。

以上のようにして、前倒しジョブ抽出部１１３によって、前倒し可能なジョブ群の、どの処理（ジョブ）までが前倒し可能であるかの選定、つまり、前倒し可能なジョブ群において実際に前倒し可能なジョブ範囲の抽出が実行される。

〔４−３−５〕一時入力ファイル名および一時出力ファイル名の設定
図３７に示すフローチャート（ステップＳ２６１〜Ｓ２６６）に従って、前倒しジョブ抽出部１１３による、一時入力ファイル名および一時出力ファイル名の設定動作について説明する。

前倒しジョブ抽出部１１３は、図３３〜図３６に示す処理を行なった後、前倒し可能ジョブ一覧テーブル２１３のレコードを、先頭から順に一つずつ読み込む（ステップＳ２６１）。そして、前倒しジョブ抽出部１１３は、読み込んだレコードにおける前倒し可能フラグが“ＯＮ”であるか否かを判断する（ステップＳ２６２）。

前倒し可能フラグが“ＯＦＦ”である場合（ステップＳ２６２のＮＯルート）、前倒しジョブ抽出部１１３は、読み込んだレコードが最終レコードか否かを判断する（ステップＳ２６６）。最終レコードである場合（ステップＳ２６６のＹＥＳルート）、前倒しジョブ抽出部１１３は処理を終了する一方、最終レコードでない場合（ステップＳ２６６のＮＯルート）、前倒しジョブ抽出部１１３はステップＳ２６１の処理に戻る。

前倒し可能フラグが“ＯＮ”である場合（ステップＳ２６２のＹＥＳルート）、前倒しジョブ抽出部１１３は、読み込んだレコードにおける抽出ジョブフラグが“ＯＮ”であるか否かを判断する（ステップＳ２６３）。抽出ジョブフラグが“ＯＮ”である場合（ステップＳ２６３のＹＥＳルート）、前倒しジョブ抽出部１１３は、当該レコードの入力ファイル名を参照し、一時入力ファイル名の欄に「入力ファイル名_copy_n」を設定する（ステップＳ２６４）。例えば図１３に示す前倒し可能ジョブ一覧テーブル２１３における、ジョブjobA-001のレコードでは、入力ファイル名として“input001”が設定され、一時入力ファイル名として“input001_copy_n”が設定される。

一時入力ファイル名の設定を行なった後、または、抽出ジョブフラグが“ＯＦＦ”である場合（ステップＳ２６３のＮＯルート）、前倒しジョブ抽出部１１３は、当該レコードの出力ファイル名を参照し、一時出力ファイル名の欄に「出力ファイル名_copy_n」を設定する（ステップＳ２６５）。例えば図１３に示す前倒し可能ジョブ一覧テーブル２１３における、ジョブjobA-001のレコードでは、出力ファイル名として“001_out”が設定され、一時出力ファイル名として“001_out_copy_n”が設定される。この後、前倒しジョブ抽出部１１３は、ステップＳ２６６の処理へ移行する。

〔４−４〕データベースアクセス設定部の動作
次に、図３８〜図４０に示すフローチャートに従って、本実施形態のスケジュール装置１におけるデータベースアクセス設定部１１５の動作について説明する。

〔４−４−１〕夜間バッチがアクセスするＤＢの調査、および、トランザクション量を記憶するテーブルの作成（上記項目〔１−５−１〕の処理参照）
図３８に示すフローチャート（ステップＳ３０１〜Ｓ３０７）に従って、ＤＢアクセス設定部１１５による、夜間バッチがアクセスするＤＢの調査動作、および、トランザクション量を記憶するテーブルの作成動作について説明する。

ＤＢアクセス設定部１１５は、前倒し可能ジョブ一覧テーブル２１３のジョブのうち、ＤＢにアクセスするジョブについて、ステップＳ３０２〜Ｓ３０４の処理をループさせる（ステップＳ３０１）。ＤＢアクセス設定部１１５は、ＤＢへの接続(CONNECT)ライブラリの置き換えを行ない（ステップＳ３０２）、ジョブの実行時に、ＤＢへの接続(CONNECT)ライブラリにより接続先ＤＢの解析を行なう（ステップＳ３０３）。そして、ＤＢアクセス設定部１１５は、解析結果に基づき、データベースアクセスジョブネット管理情報テーブル２１４に、ＤＢ名，ジョブネット名，各ジョブネットの開始時刻，ジョブ名を設定する（ステップＳ３０４；図１４参照）。

ＤＢアクセス設定部１１５は、全てのジョブを検索するまで、ステップＳ３０１〜Ｓ３０４の処理を繰り返し実行し、全てのジョブの検索を終了すると（ステップＳ３０５）、以下の処理を行なう。つまり、ＤＢアクセス設定部１１５は、データベーストランザクション情報テーブル２１５に、データベースアクセスジョブネット管理情報テーブル２１４のＤＢ名を設定する（ステップＳ３０６；図１５参照）。この後、ＤＢアクセス設定部１１５は、ＤＢへの接続(CONNECT)ライブラリの復元を行なってから（ステップＳ３０７）、処理を終了する。

〔４−４−２〕データベースアクセスジョブネット管理情報テーブルへの記録（上記項目〔１−５−２〕の処理参照）
図３９に示すフローチャート（ステップＳ３１１〜Ｓ３１５）に従って、ＤＢアクセス設定部１１５による、データベースアクセスジョブネット管理情報テーブル２１４への設定（記録）動作について説明する。

ＤＢアクセス設定部１１５は、ジョブの実行前の時刻を採取してから（ステップＳ３１１）、ジョブ実行部１２にジョブを実行させる（ステップＳ３１２）。そして、ＤＢアクセス設定部１１５は、ジョブの実行後の時刻を採取し、実行前時刻と実行後時刻との差分により、ジョブの実行時間を算出する（ステップＳ３１３）。

この後、ＤＢアクセス設定部１１５は、現在の運用がテスト運用か否かを判断する（ステップＳ３１４）。現在の運用がテスト運用である場合（ステップＳ３１４のＹＥＳルート）、データベースアクセスジョブネット管理情報テーブル２１４における、当該実行ジョブに対応する実行時間(通常)の欄に、算出された実行時間を設定してから（ステップＳ３１５；図１６参照）、処理を終了する。一方、現在の運用がテスト運用でない場合つまり本番運用である場合（ステップＳ３１４のＮＯルート）、ＤＢアクセス設定部１１５は処理を終了する。

〔４−４−３〕データベーストランザクション情報テーブルへの記録（上記項目〔１−５−２〕の処理参照）
図４０に示すフローチャート（ステップＳ３２１〜Ｓ３２８）に従って、ＤＢアクセス設定部１１５による、データベーストランザクション情報テーブル２１５への設定（記録）動作について説明する。

ＤＢアクセス設定部１１５は、ＤＢへの接続(CONNECT)ライブラリおよび確定(COMMIT)ライブラリの置き換えを行ない（ステップＳ３２１）、ジョブ実行部１２にジョブを実行させる（ステップＳ３２２）。そして、ジョブの実行に伴う、ＤＢへの確定(COMMIT)回数をカウントする（ステップＳ３２３）。

この後、ＤＢアクセス設定部１１５は、カウントされたＤＢへの確定(COMMIT)回数が０よりも大きいか否かを判断する（ステップＳ３２４）。確定(COMMIT)回数が０である場合つまりＤＢへのアクセスが行なわれていない場合（ステップＳ３２４のＮＯルート）、ＤＢアクセス設定部１１５は、ＤＢへの接続(CONNECT)ライブラリおよび確定(COMMIT)ライブラリの復元を行なってから（ステップＳ３２８）、処理を終了する。

確定(COMMIT)回数が０よりも大きい場合つまりＤＢへのアクセスが行なわれている場合（ステップＳ３２４のＹＥＳルート）、ＤＢアクセス設定部１１５は、現在の運用がテスト運用か否かを判断する（ステップＳ３２５）。現在の運用がテスト運用である場合（ステップＳ３２５のＹＥＳルート）、ＤＢアクセス設定部１１５は、データベーストランザクション情報テーブル２１５のトランザクション量(通常)の欄に、確定(COMMIT)回数に基づく単位時間当たりのトランザクション量を設定する（ステップＳ３２６；図１７参照）。そして、ＤＢアクセス設定部１１５は、ステップＳ３２８の処理へ移行する。

一方、現在の運用がテスト運用でない場合つまり本番運用である場合（ステップＳ３２５のＮＯルート）、ＤＢアクセス設定部１１５は、データベーストランザクション情報テーブル２１５のトランザクション量(実績)の欄に、確定(COMMIT)回数に基づく単位時間当たりのトランザクション量を設定する（ステップＳ３２７；図１８参照）。そして、ＤＢアクセス設定部１１５は、ステップＳ３２８の処理へ移行する。

〔４−５〕データベースアクセス解析部の動作
次に、図４１および図４２に示すフローチャートに従って、本実施形態のスケジュール装置１におけるデータベースアクセス解析部１１６の動作について説明する。

ＤＢアクセス解析部１１６は、業務システムの本番運用でオンライン業務が開始されるのに伴い、トランザクション量の監視を開始すると、例えば１時間ごとに図４２に示す処理（トランザクション量の監視および前倒し実行の必要性の判断）を行なう。つまり、図４１に示すように、ＤＢアクセス解析部１１６は、１時間のスリープ処理（ステップＳ４０１）と、図４２に示す処理の実行（ステップＳ４０２）とを繰り返すことで、１時間ごとに図４２に示す処理を実行する。ＤＢアクセス解析部１１６は、オンライン処理終了時刻になると、トランザクション量の監視を終了する。

図４２に示すフローチャート（ステップＳ４１１〜Ｓ４１７）に従って、ＤＢアクセス解析部１１６による、トランザクション量の監視動作（上記項目〔１−６−１〕の処理参照）および前倒し実行の必要性の判断動作（上記項目〔１−６−２〕の処理参照）について説明する。

ＤＢアクセス解析部１１６は、本番運用に伴い図４０のステップＳ３２７（ＤＢアクセス設定部１１５）によって得られるトランザクション量(実績)に基づき１時間ごとにトランザクション量(実績)を監視する（ステップＳ４１１）。そして、ＤＢアクセス解析部１１６は、１時間ごとに、トランザクション量(実績)に基づいてステップＳ４１２〜Ｓ４１７の処理を実行する。

つまり、ＤＢアクセス解析部１１６は、データベーストランザクション情報テーブル２１５において、対象ジョブの属するジョブネットのトランザクション量(実績)がトランザクション量(通常)よりも多いか否かを判断する（ステップＳ４１２）。

トランザクション量(実績)がトランザクション量(通常)以下である場合（ステップＳ４１２のＮＯルート）、ＤＢアクセス解析部１１６は、実行時間(通常)の値を実行時間(予測)の値とするように、対象ジョブのデータベースアクションジョブネット管理情報テーブル２１４を更新する（ステップＳ４１６；上記項目〔１−６−２−１〕および図１９参照）。この後、ＤＢアクセス解析部１１６は、処理を終了し、一時間のスリープ処理を行なう。

一方、トランザクション量(実績)がトランザクション量(通常)よりも多い場合（ステップＳ４１２のＹＥＳルート）、ＤＢアクセス解析部１１６は、項目〔１−６−２−２〕で上述した式（１）によって算出した値を、実行時間(予測)の値とするように、対象ジョブのデータベースアクションジョブネット管理情報テーブル２１４を更新する（ステップＳ４１３；上記項目〔１−６−２−２〕および図２０参照）。

この後、ＤＢアクセス解析部１１６は、各ジョブの予測実行時間に基づき、デッドライン時刻までのクリティカルパスを再評価する。また、ＤＢアクセス解析部１１６は、再評価されたクリティカルパス上に存在するジョブネットのジョブネット名を、図５２に示すように、クリティカルパス管理情報テーブル２１６に設定する（ステップＳ４１４）。

そして、ＤＢアクセス解析部１１６は、クリティカルパス上のジョブネット内の全てのジョブの予測実行時間の総和に基づいて算出される予測終了時刻が、デッドライン時刻を超えているか否かを判断する（ステップＳ４１５）。予測終了時刻がデッドライン時刻を超えていない場合（ステップＳ４１５のＮＯルート）、ＤＢアクセス解析部１１６は、処理を終了し、一時間のスリープ処理を行なう。

予測終了時刻がデッドライン時刻を超えている場合（ステップＳ４１５のＹＥＳルート）、ＤＢアクセス解析部１１６は、前倒しジョブ決定部１１４に図４３〜図４５の処理を実行させてから（ステップＳ４１７）、処理を終了し、一時間のスリープ処理を行なう。

〔４−６〕前倒しジョブ決定部の動作
次に、図４３〜図４５に示すフローチャートに従って、本実施形態のスケジュール装置１における前倒しジョブ決定部１１４の動作について説明する。

〔４−６−１〕日中に前倒しする夜間バッチ処理の選択（上記項目〔１−７−１〕の処理参照）
図４３に示すフローチャート（ステップＳ５０１〜Ｓ５０７）および図４４に示すフローチャート（ステップＳ５１１〜Ｓ５１８）に従って、前倒しジョブ決定部１１４による、日中に前倒しする夜間バッチ処理の選択動作について説明する。

前倒しジョブ決定部１１４は、まず、図４３に示すように、前倒し候補一覧テーブル２１７の作成処理（上記項目〔１−７−１〕の手順(e1)および(e2)参照）を開始する。つまり、前倒しジョブ決定部１１４は、前倒し可能ジョブ一覧テーブル２１３から同一ジョブネットに関する複数のレコードを取り出す（ステップＳ５０１）。前倒しジョブ決定部１１４は、登録情報（レコード）が存在しレコードの取り出しに成功したか否かを判断する（ステップＳ５０２）。レコードの取り出しに成功した場合（ステップＳ５０２のＹＥＳルート）、前倒しジョブ決定部１１４は、取り出したレコード内に、前倒し可能フラグが“ＯＮ”のレコードが存在するか否かを判断する（ステップＳ５０３）。

前倒し可能フラグが“ＯＮ”のレコードが存在する場合（ステップＳ５０３のＹＥＳルート）、前倒しジョブ決定部１１４は、当該ジョブネットがクリティカルパス管理テーブル２１６（図５２参照）に登録されているか否かを判断する（ステップＳ５０４）。当該ジョブネットがクリティカルパス管理テーブル２１６に登録されている場合（ステップＳ５０４のＹＥＳルート）、前倒しジョブ決定部１１４は、前倒し候補一覧テーブル２１７に、以下の情報を登録する（ステップＳ５０５）。つまり、前倒し候補一覧テーブル２１７の[ジョブネット名]欄に、当該ジョブネットのジョブネット名が登録される。また、前倒し候補一覧テーブル２１７の[前倒し可能なバッチジョブ名]欄に、当該ジョブネットレコード内の前倒し可能フラグが“ＯＮ”となっているジョブのジョブ名が登録される。

その後、前倒しジョブ決定部１１４は、前倒し候補一覧テーブル２１７の[前倒し可能なバッチジョブ名]欄に登録された各ジョブについて、データベースアクセスジョブネット管理情報テーブル２１４から、実行時間(予測)の値を取り出す。そして、前倒しジョブ決定部１１４は、取り出した各ジョブの実行時間(予測)の値の合計を算出し、当該合計を、前倒し候補一覧テーブル２１７の[前倒し可能なバッチジョブの予測実行時間の合計]欄に登録する（ステップＳ５０６；図２１参照）。

さらに、前倒しジョブ決定部１１４は、前倒し候補一覧テーブル２１７の[前倒し可能なバッチジョブの予測実行時間の合計]欄の値が大きい順に、優先度を示す値“１”〜“ｎ”（整数値で昇順）を、[前倒し優先度]欄に登録する（ステップＳ５０７；図２１参照）。

優先度の登録を完了した後、または、前倒し可能フラグが“ＯＮ”のレコードが存在しない場合（ステップＳ５０３のＮＯルート）、または、当該ジョブネットがクリティカルパス管理テーブル２１６に登録されている場合（ステップＳ５０４のＮＯルート）、前倒しジョブ決定部１１４は、ステップＳ５０１の処理に戻る。

レコードの取り出しに失敗した場合（ステップＳ５０２のＮＯルート）、前倒しジョブ決定部１１４は、前倒し候補一覧テーブル２１７の作成処理を終了する。このとき、前倒し候補一覧テーブル２１７が作成されなかった場合、前倒しジョブ決定部１１４は処理を終了する。一方、前倒し候補一覧テーブル２１７が作成された場合、前倒しジョブ決定部１１４は、図４４に示す処理、つまり「デッドライン時刻までにバッチ処理が完了するか否かのチェック処理」（上記項目〔１−７−１〕の手順(e3)〜(e7)参照）を開始する。

前倒しジョブ決定部１１４は、当該チェック処理を開始すると、図４４に示すように、前倒し候補一覧テーブル２１７に、前倒し優先度Ｎｂ（初期値は１）のジョブネットが存在するか否かを判断する（ステップＳ５１１）。前倒し優先度Ｎｂのジョブネットが存在する場合（ステップＳ５１１のＹＥＳルート）、前倒しジョブ決定部１１４は、前倒しジョブ群一覧テーブル２１８に、以下の情報を登録する（ステップＳ５１２）。つまり、前倒しジョブ群一覧テーブル２１８の[ジョブネット名]欄に、当該ジョブネットのジョブネット名が登録される。また、前倒しジョブ群一覧テーブル２１８の[前倒しジョブ群]欄に、当該ジョブネットの“前倒し可能なバッチジョブ”のジョブ名が登録される。

この後、前倒しジョブ決定部１１４は、図４２に示す処理で明確になる当該バッチ処理の「デッドライン時刻からのオーバ時間」を取得する（ステップＳ５１３）。前倒しジョブ決定部１１４は、取得した「デッドライン時刻からのオーバ時間」から、「前倒し候補一覧テーブル２１７の前倒し優先度Ｎｂのレコード（行）に記載されている予測実行時間の合計」を減算する。前倒しジョブ決定部１１４は、減算結果を、新たな「デッドライン時刻からのオーバ時間」とする（ステップＳ５１４）。

そして、前倒しジョブ決定部１１４は、新たな「デッドラインからのオーバ時間」が０以下であるか否かを判断する（ステップＳ５１５）。新たな「デッドラインからのオーバ時間」が０以下である場合（ステップＳ５１５のＹＥＳルート）、前倒しジョブ決定部１１４は、１つ、または複数のバッチ処理を前倒しすることで、デッドライン時刻までに処理が完了すると判断される（ステップＳ５１７）。前倒しジョブ決定部１１４は、デッドライン時刻までに処理が完了すると判断すると、上記「チェック処理」を終了する（ステップＳ５１８）。

一方、新たな「デッドラインからのオーバ時間」が０よりも大きい場合（ステップＳ５１５のＮＯルート）、前倒しジョブ決定部１１４は、処理がデッドライン時刻までに完了しないと判断する。そして、前倒しジョブ決定部１１４は、前倒し優先度Ｎｂに１を加算してから（ステップＳ５１６）、ステップＳ５１１以降の処理を繰り返し実行する。

また、前倒し優先度Ｎｂのジョブネットが存在しない場合（ステップＳ５１１のＮＯルート）、前倒しジョブ決定部１１４は、上記「チェック処理」を終了する（ステップＳ５１８）。なお、ステップＳ５１８で上記「チェック処理」を終了するに当たり、前倒しジョブ決定部１１４は、以下のいずれかの処理を実行する。つまり、デッドライン時刻までに処理が完了すると判断された場合、前倒しジョブ決定部１１４は、図４５に示す処理、つまり「日中の実行開始時刻の決定処理」を開始する。また、上記以外の場合、前倒しジョブ決定部１１４は、アラームをシステム管理者等に対し通知し、前倒しを実行させない。

〔４−６−２〕日中における夜間バッチ処理の実行開始時刻の決定（上記項目〔１−７−２〕の処理参照）
図４５に示すフローチャート（ステップＳ５２１〜Ｓ５２８）に従って、前倒しジョブ決定部１１４による、日中における夜間バッチ処理の実行開始時刻の決定動作（上記項目〔１−７−２〕の手順(f1)〜(f4)参照）について説明する。

前倒しジョブ決定部１１４は、前倒しジョブ群一覧テーブル２１８の[前倒し実行回数]欄に“０”を設定する（ステップＳ５２１）。そして、前倒しジョブ決定部１１４は、前倒しジョブ群一覧テーブル２１８から、ジョブネットのレコードを、先頭から順に一つずつ取り出す（ステップＳ５２２）。前倒しジョブ決定部１１４は、レコードが存在しレコードの取り出しに成功したか否かを判断する（ステップＳ５２３）。

レコードの取り出しに成功した場合（ステップＳ５２３のＹＥＳルート）、前倒しジョブ決定部１１４は、以下の処理を実行する。つまり、前倒しジョブ決定部１１４は、取り出したジョブネットレコードのジョブ群の実行依頼を、上記ジョブ前倒し実行制御機能（図２８参照）およびジョブ起動依頼部１１０経由でジョブ実行部１２に発行する。また、前倒しジョブ決定部１１４は、前倒しジョブ群一覧テーブル２１８の[前倒し実行開始時刻]欄に実行時刻を記入する（ステップＳ５２４）。

そして、前倒しジョブ決定部１１４は、現在、実行中の処理について、日中バッチも含め、処理多重度が上限に達しているか否かを判断する（ステップＳ５２５）。処理多重度が上限に達している場合（ステップＳ５２５のＹＥＳルート）、前倒しジョブ決定部１１４は、５分間待機してから（ステップＳ５２６）、ステップＳ５２５の処理に戻る。これにより、バッチ処理の実行は保留され、処理多重度の空きが生じると、保留したバッチ処理の実行が開始される。一方、処理多重度が上限に達していない場合（ステップＳ５２５のＮＯルート）、前倒しジョブ決定部１１４は、ステップＳ５２２の処理に戻る。

レコードの取り出しに失敗した場合（ステップＳ５２３のＮＯルート）、前倒しジョブ決定部１１４は、以下の処理を行なう。つまり、前倒しジョブ決定部１１４は、前倒しジョブ群一覧テーブル２１８の前倒し実行開始時刻＋６０分の時刻が到来するのを待ち合わせる。そして、前倒しジョブ決定部１１４は、前倒しジョブ群一覧テーブル２１８に登録されている全てのジョブ群の実行依頼を、６０分ごとに、上記ジョブ前倒し実行制御機能（図２８参照）およびジョブ起動依頼部１１０経由でジョブ実行部１２に発行する（ステップＳ５２７）。その際、ステップＳ５２５およびＳ５２６と同様の処理により、前倒しジョブ決定部１１４は、日中バッチも含め処理多重度が上限を超えて実行依頼を行なわないように制御する。

この後、前倒しジョブ決定部１１４は、オンライン業務停止時刻が到来したか否かを判断する（ステップＳ５２８）。オンライン業務停止時刻が到来していない場合（ステップＳ５２８のＮＯルート）、前倒しジョブ決定部１１４はステップＳ５２７の処理に戻る。一方、オンライン業務停止時刻が到来した場合（ステップＳ５２８のＹＥＳルート）、前倒しジョブ決定部１１４は、「日中の実行開始時刻の決定処理」を終了する。

〔４−７〕入力データ管理部の動作（上記項目〔１−８〕の処理参照）
次に、図４６に示すフローチャート（ステップＳ６０１〜Ｓ６０５）に従って、本実施形態のスケジュール装置１における入力データ管理部１１７の動作（特に上記項目〔１−８−２〕の手順(h1)および(h2)参照）について説明する。

時刻が前倒しジョブ群一覧テーブル２１８の前倒し実行開始時刻になると、該当する前倒しジョブ群のジョブネットが起動される。ジョブネット起動の直後に、入力データ管理部１１７が起動され入力データの加工処理を行なう。まず、入力データ管理部１１７は、前倒しジョブ群一覧テーブル２１８の前倒し実行回数に１を加算する（ステップＳ６０１）。

そして、入力データ管理部１１７は、今回のジョブ実行がジョブネット定義による夜間バッチ実行であるか否か、つまり実行対象ジョブ群が夜間バッチ(最終回)で実行されるか否かを判断する（ステップＳ６０２）。ジョブネット定義による夜間バッチ実行でない場合（ステップＳ６０２のＮＯルート）、入力データ管理部１１７は、以下の処理を行なう。つまり、入力データ管理部１１７は、ジョブネットの入力データファイルinput001を、前倒し可能ジョブ一覧テーブル２１３の一時入力ファイル名input001_copy_nの一時入力ファイルとしてコピーする。その際、“ｎ”の値として、前倒しジョブ群一覧テーブル２１８の前倒し実行回数が記入される（ステップＳ６０３）。

この後、入力データ管理部１１７は、今回の前倒し実行が２回目以降の前倒し実行か否か、つまり前倒しジョブ群一覧テーブル２１８の前倒し実行回数が２以上か否かを判断する（ステップＳ６０４）。前倒し実行回数が１である場合、つまり今回の前倒し実行が１回目の前倒し実行である場合（ステップＳ６０４のＮＯルート）、入力データ管理部１１７は処理を終了する。

前倒し実行回数が２以上である場合（ステップＳ６０４のＹＥＳルート）、入力データ管理部１１７は、以下の処理を行なう。つまり、入力データ管理部１１７は、入力データファイルinput001と前回の前倒し実行時に保存された一時入力ファイルinput001_copy_(n-1)とのデータ内容を比較し、一致したデータ分を入力データinput001から削除する（ステップＳ６０５）。これにより、未処理データが得られ、ジョブネットに入力される。この後、入力データ管理部１１７は処理を終了する。

また、今回のジョブ実行がジョブネット定義による夜間バッチ実行である場合、つまり実行対象ジョブ群が夜間バッチ(最終回)で実行される場合（ステップＳ６０２のＹＥＳルート）、入力データ管理部１１７は、ステップＳ６０５の処理へ移行する。

〔４−８〕ジョブ実行部の動作
次に、図４７に示すフローチャート（ステップＳ７０１〜Ｓ７１０）および図４８に示すフローチャート（ステップＳ７１１〜Ｓ７１５）に従って、本実施形態のスケジュール装置１におけるジョブ実行部１１８の動作について説明する。

ジョブ実行部１１８は、ジョブネットの実行開始に伴って起動され、まず、今回開始されたジョブネットが前倒しジョブ群一覧テーブル２１８に存在するか否かを判断する（ステップＳ７０１）。今回開始されたジョブネットが前倒しジョブ群一覧テーブル２１８に存在しない場合（ステップＳ７０１のＮＯルート）、ジョブ実行部１１８は、ジョブネット定義情報２１２（図５１参照）に従って実行される（ステップＳ７０２；通常実行）。

今回開始されたジョブネットが前倒しジョブ群一覧テーブル２１８に存在する場合（ステップＳ７０１のＹＥＳルート）、ジョブ実行部１１８は、今回のジョブネット実行が前倒し実行処理であるか否かを判断する（ステップＳ７０３）。このとき、ジョブ実行部１１８は、前倒しジョブ群一覧テーブル２１８の前倒し実行開始時刻とシステム定義情報２１１のオンライン／バッチ切替時刻とを比較し、前倒し実行開始時刻が切り替え時刻よりも前か否かを判断する。

前倒し実行開始時刻が切り替え時刻よりも前である場合、ジョブ実行部１１８は、今回のジョブネット実行が前倒し実行処理であると判断し（ステップＳ７０３のＹＥＳルート）、入力データ管理部１１７で、入力データの加工（適切化）が行なわれる（ステップＳ７０４；図４６のステップＳ６０５参照）。

この後、ジョブ実行部１１８は、実行対象のジョブが前倒しジョブ群一覧テーブル２１８の前倒しジョブ群に存在するか否かを判断する（ステップＳ７０５）。実行対象のジョブが前倒しジョブ群に存在する場合（ステップＳ７０５のＹＥＳルート）、ジョブ実行部１１８は、以下の処理を行なう。つまり、ジョブ実行部１１８は、ジョブを実行し、ジョブの実行に伴って得られた出力ファイルを、前倒し可能ジョブ一覧テーブル２１３に従い、“出力ファイル名_copy_n”（ｎは前倒し実行回数）にリネームして保存する（ステップＳ７０６）。

そして、ジョブ実行部１１８は、後続ジョブがあるか否かを判断し（ステップＳ７０７）、後続ジョブがある場合（ステップＳ７０７のＹＥＳルート）、ステップＳ７０５の処理に戻る。また、実行対象のジョブが前倒しジョブ群に存在しない場合（ステップＳ７０５のＮＯルート）、ジョブ実行部１１８は、ステップＳ７０７の処理へ移行する。後続ジョブがない場合（ステップＳ７０７のＮＯルート）、ジョブ実行部１１８は処理を終了する。

一方、前倒し実行開始時刻が切り替え時刻以降である場合、ジョブ実行部１１８は、今回のジョブネット実行が前倒し実行処理でないと判断し（ステップＳ７０３のＮＯルート）、今回のジョブ実行がジョブネット定義による起動であるか否かを判断する（ステップＳ７０８）。今回のジョブ実行がジョブネット定義による起動でない場合（ステップＳ７０８のＮＯルート）、ジョブ実行部１１８は処理を終了する。

今回のジョブ実行がジョブネット定義による起動である場合（ステップＳ７０８のＹＥＳルート）、入力データ管理部１１７によって図４６に示す処理（ステップＳ６０５参照）が実行される（ステップＳ７０９）。そして、ジョブ実行部１１８は、夜間バッチ（最終回）のジョブネットの開始処理（図４８に示す処理）を実行する（ステップＳ７１０）。

夜間バッチ（最終回）のジョブネットの開始処理が開始されると、図４８に示すように、ジョブ実行部１１８は、ジョブを実行する（ステップＳ７１１）。そして、ジョブ実行部１１８は、実行したジョブが、前倒しジョブ群一覧テーブル２１８の前倒しジョブ群に存在する最後のジョブであるか否かを判断する（ステップＳ７１２）。実行したジョブが、前倒しジョブ群一覧テーブル２１８の前倒しジョブ群に存在する最後のジョブでない場合（ステップＳ７１２のＮＯルート）、ジョブ実行部１１８は、実行したジョブに後続ジョブがあるか否かを判断する（ステップＳ７１３）。

後続ジョブがある場合（ステップＳ７１３のＹＥＳルート）、ジョブ実行部１１８は、ステップＳ７１１の処理に戻り、後続ジョブを実行する。一方、後続ジョブがない場合（ステップＳ７１３のＮＯルート）、ジョブ実行部１１８は、以下の処理を実行する。つまり、ジョブ実行部１１８は、前倒しジョブ群に存在するジョブ（最後のジョブを除く）について、出力データ管理部１１９に、出力データのマージ処理（図４９に示す処理）を依頼し（ステップＳ７１４）、処理を終了する。

実行したジョブが、前倒しジョブ群一覧テーブル２１８の前倒しジョブ群に存在する最後のジョブである場合（ステップＳ７１２のＹＥＳルート）、ジョブ実行部１１８は、以下の処理を実行する。つまり、ジョブ実行部１１８は、出力データ管理部１１９に、出力データのマージ処理（図４９に示す処理）を依頼し（ステップＳ７１５）、ステップＳ７１３の処理へ移行する。

〔４−９〕出力データ管理部の動作（上記項目〔１−８〕の処理参照）
次に、図４９に示すフローチャート（ステップＳ８０１）に従って、本実施形態のスケジュール装置１における出力データ管理部１１９の動作（特に上記項目〔１−８−２〕の手順(h3)および(h4)参照）について説明する。前倒し実行したジョブ群の出力データは、前倒し実行ごとにファイルで保存されているため、出力データ管理部１１９によって実行される処理は、最終的に、前倒し実行ごとのファイルをマージして一つの出力ファイルにする処理である。

図４９に示すように、出力データ管理部１１９は、ジョブの出力ファイルの内容と、前倒し実行時の出力ファイル00X_out_copy_1〜00X_out_copy_nの内容とをマージして、ジョブの出力ファイル名で保存する（ステップＳ８０１）。

〔５〕本実施形態の効果
夜間バッチを日中のオンライン業務の時間帯に前倒し実行する場合、現状の技術ではバッチ処理アプリケーション自身の処理内容を把握できないため、前倒しして分割実行可能なバッチジョブ群を識別することができない。このため、前倒し可能なバッチジョブ群を人手で定義するしかない。

また、オンライン処理の時間帯にオンライン処理とバッチ処理とを並行して実行することは、これまで夜間に１回で実行されていたバッチ処理を、複数回に分割して実行することになる。通常、夜間バッチ用に開発されたアプリケーションは、全データが揃った状態を前提にして、一括処理（１回で処理）するようになっているため、夜間バッチを分割して複数回処理するためには業務者（顧客）の資産であるアプリケーションを改修しなければならない。

これに対し、本実施形態によれば、バッチ処理を日中に前倒しし分割実行が可能なジョブ群を自動抽出する手法が確立される。つまり、データ処理を行なう各ジョブの入力データ件数と出力データ件数との相関関係から前倒し可能なジョブ群が特定される。その際、当該ジョブ群の各処理における業務ＤＢ更新状況やメッセージ発信／ファイル転送状況から他のバッチ処理への影響の有無が判断され、日中に前倒ししてはならないジョブやジョブ群が特定される。これにより、前倒ししても良いジョブ群を自動的に抽出することができる。

また、本実施形態によれば、１日分の全データが揃った状態を前提にして一括処理する仕様の夜間バッチアプリケーションを改修することなく、バッチ処理を複数回に分割実行しても、同一データの二重処理やデータ不整合などの問題が生じない手段が確立される。つまり、１回目の前倒し実行〜ｎ回目の前倒し実行（最終実行）において、各時点で蓄積された最新データと前回実行時のデータとから差分が抽出され、処理すべき範囲のデータのみがアプリケーション（ジョブ）に入力され、同一データの二重処理が確実に回避される。さらに、１回目の前倒し実行〜ｎ回目の前倒し実行（最終実行）で出力されたデータが、順序性を維持しながら保存され、最後に全データを結合（マージ）することで、夜間に全データに対し一括処理を行なう場合と同一の結果（出力データ）を得ることできる。

これにより、本実施形態では、夜間バッチ処理を自動的に日中に前倒しし、オンライン処理と並列的に分割実行することで、夜間バッチ処理の遅延が大幅に削減され、デッドライン突き抜けが確実に抑止される。つまり、オンライン処理の開始（デッドライン）までに夜間バッチ処理を確実に完了させることができる。特に、オンライン業務の実行時間が長くなりバッチ業務の実行時間が短くなり、且つ、想定を超えた突発的なデータ量増加が発生しうる現状であっても、オンライン業務と並列実行することで、バッチ業務の遅延が抑止されデッドラインの突き抜けが抑止される。

以上詳述したように、本実施形態によれば、オンライン業務の最中に遅延を検知した場合、バッチ業務を前倒ししてオンライン業務と並列実行させることで、確実にデッドラインまでの猶予時間が増え、バッチ業務の突き抜けを確実に抑止することができる。また、バッチ業務の前倒しを、人手ではなく自動で実行することで、人手で実施するスケジュールの再構築やメンテナンスに比べコストが大幅に削減され、且つ人的ミスによる業務の運用品質の低下を防ぐこともできる。

〔６〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。

〔７〕付記
以上の各実施形態を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
コンピュータに、
スケジュールされた、第１期間での第１処理と、前記第１期間後の第２期間での第２処理とのうち、前記第２処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されるデータ群に対する処理を当該データ群の範囲内で行なう後続ジョブとを含むジョブ群を抽出し、
前記抽出されたジョブ群を、前記第２期間から前記第１期間に前倒しして実行する、
処理を実行させる、処理プログラム。

（付記２）
前段のジョブから入力された一の前記データ群に対する一以上の前記処理を行ない一以上の出力データ群を出力するジョブを、前記後続ジョブとして抽出する、
処理を前記コンピュータに実行させる、付記１記載の処理プログラム。

（付記３）
他の業務との連携処理を行なうジョブが前記ジョブ群に含まれる場合、当該ジョブ群を前記前倒しの対象から除外する、
処理を前記コンピュータに実行させる、付記１または付記２に記載の処理プログラム。

（付記４）
メッセージ発行処理を行なう出力ジョブ、または、ファイル転送処理を行なう出力ジョブ、または、出力が他の業務の開始契機になっている出力ジョブが前記後続ジョブに含まれる場合、前記ジョブ群のうち、前記抽出ジョブから前記出力ジョブの直前の後続ジョブまでのジョブを前記前倒しの対象とする、
処理を前記コンピュータに実行させる、付記１〜付記３のいずれか一項に記載の処理プログラム。

（付記５）
前記ジョブ群を前倒しして実行する実行タイミングを、前記第１処理の処理状況に応じて設定する、
処理を前記コンピュータに実行させる、付記１〜付記４のいずれか一項に記載の処理プログラム。

（付記６）
前記第２処理によって用いられるデータベースに対する前記第１処理のトランザクション量を前記第１処理の処理状況として監視し、
前記第１処理のトランザクション量に基づいて前記第２処理の予測実行時間を算出し、
前記第２処理の予測実行時間に基づいて前記第２処理が予め設定された完了期限までに完了するか否かを判断し、
前記第２処理が前記完了期限までに完了しないと判断されたタイミングに応じて、前記実行タイミングを設定する、
処理を前記コンピュータに実行させる、付記５記載の処理プログラム。

（付記７）
前記ジョブ群を前記実行タイミングで実行する場合、前記ジョブ群による処理済みのデータを除いた未処理データを、前記ジョブ群による処理対象として前記ジョブ群に入力する、
処理を前記コンピュータに実行させる、付記５または付記６に記載の処理プログラム。

（付記８）
前記第１期間から前記第２期間になった場合、前記ジョブ群による処理済みのデータを除いた最終未処理データを、前記ジョブ群による最終処理対象として前記ジョブ群に入力し、
前記実行タイミング毎に前記未処理データについて前記ジョブ群によって得られた第１部分出力データと、前記最終未処理データについて前記ジョブ群によって得られた第２部分出力データとを出力データとしてマージし、
マージされた前記出力データに対し、前記第２処理における前記ジョブ群以降のジョブを実行する、
処理を前記コンピュータに実行させる、付記７記載の処理プログラム。

（付記９）
前記第１期間から前記第２期間になった場合、前記実行タイミング毎に前記ジョブ群に属する各ジョブによって得られた部分中間出力データを、前記各ジョブ毎に中間出力データとしてマージして出力する、
処理を前記コンピュータに実行させる、付記８記載の処理プログラム。

（付記１０）
前記第１処理はオンライン処理であり、前記第２処理はバッチ処理である、付記１〜付記９のいずれか一項に記載の処理プログラム。

（付記１１）
前記抽出されたジョブ群を、前記第２期間から前記第１期間に前倒しして前記第１処理と並行して実行する、
処理を前記コンピュータに実行させる、付記１〜付記１０のいずれか一項に記載の処理プログラム。

（付記１２）
スケジュールされた、第１期間での第１処理と、前記第１期間後の第２期間での第２処理とのうち、前記第２処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されるデータ群に対する処理を当該データ群の範囲内で行なう後続ジョブとを含むジョブ群を抽出する抽出部と、
前記抽出されたジョブ群を、前記第２期間から前記第１期間に前倒しして実行する制御部と、を備える、処理装置。

（付記１３）
前記抽出部は、
前段のジョブから入力された一の前記データ群に対する一以上の前記処理を行ない一以上の出力データ群を出力するジョブを、前記後続ジョブとして抽出する、付記１２記載の処理装置。

（付記１４）
前記抽出部は、
他の業務との連携処理を行なうジョブが前記ジョブ群に含まれる場合、当該ジョブ群を前記前倒しの対象から除外する、付記１２または付記１３に記載の処理装置。

（付記１５）
前記抽出部は、
メッセージ発行処理を行なう出力ジョブ、または、ファイル転送処理を行なう出力ジョブ、または、出力が他の業務の開始契機になっている出力ジョブが前記後続ジョブに含まれる場合、前記ジョブ群のうち、前記抽出ジョブから前記出力ジョブの直前の後続ジョブまでのジョブを前記前倒しの対象とする、
付記１２〜付記１４のいずれか一項に記載の処理装置。

（付記１６）
前記ジョブ群を前倒しして実行する実行タイミングを、前記第１処理の処理状況に応じて設定する解析部を、さらに備える、付記１２〜付記１５のいずれか一項に記載の処理装置。

（付記１７）
前記解析部は、
前記第２処理によって用いられるデータベースに対する前記第１処理のトランザクション量を前記第１処理の処理状況として監視し、
前記第１処理のトランザクション量に基づいて前記第２処理の予測実行時間を算出し、
前記第２処理の予測実行時間に基づいて前記第２処理が予め設定された完了期限までに完了するか否かを判断し、
前記第２処理が前記完了期限までに完了しないと判断されたタイミングに応じて、前記実行タイミングを設定する、
付記１６記載の処理装置。

（付記１８）
前記ジョブ群を前記実行タイミングで実行する場合、前記ジョブ群による処理済みのデータを除いた未処理データを、前記ジョブ群による処理対象として前記ジョブ群に入力する入力データ管理部を、さらに備える、付記１６または付記１７に記載の処理装置。

（付記１９）
前記入力データ管理部は、前記第１期間から前記第２期間になった場合、前記ジョブ群による処理済みのデータを除いた最終未処理データを、前記ジョブ群による最終処理対象として前記ジョブ群に入力し、
前記実行タイミング毎に前記未処理データについて前記ジョブ群によって得られた第１部分出力データと、前記最終未処理データについて前記ジョブ群によって得られた第２部分出力データとを出力データとしてマージする出力データ管理部と、
マージされた前記出力データに対し、前記第２処理における前記ジョブ群以降のジョブを実行するジョブ実行部と、をさらに備える、付記１８記載の処理装置。

（付記２０）
コンピュータが、
スケジュールされた、第１期間での第１処理と、前記第１期間後の第２期間での第２処理とのうち、前記第２処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されるデータ群に対する処理を当該データ群の範囲内で行なう後続ジョブとを含むジョブ群を抽出し、
前記抽出されたジョブ群を、前記第２期間から前記第１期間に前倒しして実行する、処理方法。

１００ ジョブ管理サーバ（処理装置）
１ スケジュール装置（コンピュータ）
１０ 処理部（ＣＰＵ，プロセッサ）
１１ ジョブスケジューラ部
１１０ ジョブ起動依頼部
１１１ システム情報登録部
１１２ ジョブ登録部
１１３ 前倒しジョブ抽出部（抽出部）
１１４ 前倒しジョブ決定部（制御部）
１１５ ＤＢアクセス設定部
１１６ ＤＢアクセス解析部（解析部，制御部）
１１７ 入力データ管理部
１１８ ジョブ実行部（制御部）
１１９ 出力データ管理部
１２ ジョブ実行部
１２１ ジョブ起動部
２０ 記憶部（メモリ）
２１ ジョブ定義情報
２１１ システム定義情報
２１２ ジョブネット定義情報
２１３ 前倒し可能ジョブ一覧テーブル
２１４ データベースアクセスジョブネット管理情報テーブル
２１５ データベーストランザクション情報テーブル
２１６ クリティカルパス管理情報テーブル
２１７ 前倒し候補一覧テーブル
２１８ 前倒しジョブ群一覧テーブル

Claims (11)

1. コンピュータに、
   スケジュールされた、第１期間での第１処理と、前記第１期間後の第２期間での第２処理とのうち、前記第２処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されるデータ群に対する第３処理を当該データ群の範囲内で行なう後続ジョブとを含むジョブ群を、前倒し可能ジョブ群として抽出し、
   前記抽出ジョブを含む先行ジョブの出力データを入力とするジョブであって、前記先行ジョブから入力された一の入力データ群に対する一以上の前記第３処理を行ない一以上の出力データ群を出力するジョブを、前記後続ジョブとして抽出し、
   抽出された前記前倒し可能ジョブ群を、前記第２期間から前記第１期間に前倒しして実行する、
   処理を実行させる、処理プログラム。
2. 前記入力データ群に対し前記第３処理を行なった結果出力される出力データの件数が前記入力データ群の件数の整数倍と一致するジョブを、前記後続ジョブとして抽出する、
   処理を前記コンピュータに実行させる、請求項１記載の処理プログラム。
3. 他の業務との連携処理を行なうジョブが前記ジョブ群に含まれる場合、当該ジョブ群を前記前倒し可能ジョブ群から除外する、
   処理を前記コンピュータに実行させる、請求項１または請求項２に記載の処理プログラム。
4. メッセージ発行処理を行なう出力ジョブ、または、ファイル転送処理を行なう出力ジョブ、または、出力が他の業務の開始契機になっている出力ジョブが前記後続ジョブに含まれる場合、前記ジョブ群に含まれ所定実行順序に従って実行される一連のジョブのうち、前記抽出ジョブから前記出力ジョブの直前の後続ジョブまでのジョブを前記前倒しの対象とする、
   処理を前記コンピュータに実行させる、請求項１〜請求項３のいずれか一項に記載の処理プログラム。
5. 前記ジョブ群を前倒しして実行する実行タイミングを、前記第１処理の処理状況に応じて設定する、
   処理を前記コンピュータに実行させる、請求項１〜請求項４のいずれか一項に記載の処理プログラム。
6. 前記第２処理によって用いられるデータベースに対する前記第１処理のトランザクション量を前記第１処理の処理状況として監視し、
   前記第１処理のトランザクション量に基づいて前記第２処理の予測実行時間を算出し、
   前記第２処理の予測実行時間に基づいて前記第２処理が予め設定された完了期限までに完了するか否かを判断し、
   前記第２処理が前記完了期限までに完了しないと判断された場合、前記実行タイミングを設定する、
   処理を前記コンピュータに実行させる、請求項５記載の処理プログラム。
7. 前記ジョブ群を前記実行タイミングで実行する場合、前記ジョブ群による処理済みのデータを除いた未処理データを、前記ジョブ群による処理対象として前記ジョブ群に入力する、
   処理を前記コンピュータに実行させる、請求項５または請求項６に記載の処理プログラム。
8. 前記第１期間から前記第２期間になった場合、前記ジョブ群による処理済みのデータを除いた最終未処理データを、前記ジョブ群による最終処理対象として前記ジョブ群に入力し、
   前記実行タイミング毎に前記未処理データについて前記ジョブ群によって得られた第１部分出力データと、前記最終未処理データについて前記ジョブ群によって得られた第２部分出力データとを出力データとしてマージし、
   マージされた前記出力データに対し、前記第２処理における前記ジョブ群以降のジョブを実行する、
   処理を前記コンピュータに実行させる、請求項７記載の処理プログラム。
9. 前記第１期間から前記第２期間になった場合、前記実行タイミング毎に前記ジョブ群に属する各ジョブによって得られた部分中間出力データを、前記各ジョブ毎に中間出力データとしてマージして出力する、
   処理を前記コンピュータに実行させる、請求項８記載の処理プログラム。
10. スケジュールされた、第１期間での第１処理と、前記第１期間後の第２期間での第２処理とのうち、前記第２処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されるデータ群に対する第３処理を当該データ群の範囲内で行なう後続ジョブとを含むジョブ群を、前倒し可能ジョブ群として抽出する抽出部と、
    抽出された前記前倒し可能ジョブ群を、前記第２期間から前記第１期間に前倒しして実行する制御部と、を備え、
    前記抽出部は、
    前記抽出ジョブを含む先行ジョブの出力データを入力とするジョブであって、前記先行ジョブから入力された一の前記データ群に対する一以上の前記第３処理を行ない一以上の出力データ群を出力するジョブを、前記後続ジョブとして抽出する、処理装置。
11. コンピュータが、
    スケジュールされた、第１期間での第１処理と、前記第１期間後の第２期間での第２処理とのうち、前記第２処理から、データ抽出処理を行なう抽出ジョブと、当該抽出ジョブによって抽出されるデータ群に対する第３処理を当該データ群の範囲内で行なう後続ジョブとを含むジョブ群を、前倒し可能ジョブ群として抽出し、
    抽出された前記前倒し可能ジョブ群を、前記第２期間から前記第１期間に前倒しして実行し、
    前記抽出ジョブを含む先行ジョブの出力データを入力とするジョブであって、前記先行ジョブから入力された一の前記データ群に対する一以上の前記第３処理を行ない一以上の出力データ群を出力するジョブを、前記後続ジョブとして抽出する、処理方法。

Images