(57)【特許請求の範囲】
【請求項１】
複数のジョブをバッチ処理するジョブ処理システムであって、
各ジョブの処理内容の登録とジョブの処理順の登録をユーザから受け付け、それぞれをジョブ情報記憶部に格納するジョブ登録部と、
前記ジョブ情報記憶部に格納されたジョブの処理順を参照しながら、各ジョブの処理内容を前記ジョブ情報記憶部から読み出しバッチ処理を実行するとともに、各ジョブの終了時刻を記録するジョブ処理部と、
基準となるジョブの処理開始前に処理するように登録されているジョブのうち、前記ジョブ処理部におけるバッチ処理時に最後に処理が終了したジョブの処理終了時刻から、その直前に処理が終了したジョブの処理終了時刻までの時間を、当該基準となるジョブの待ち時間として、各ジョブの待ち時間を取得し、前記待ち時間が所定のしきい値を超える長時間待機ジョブを検出する待ち時間判定部と、
前記長時間待機ジョブが検出された際、その旨の警告をユーザに対し行う出力部と、
を備えたことを特徴とするジョブ処理システム。
【請求項２】
前記長時間待機ジョブが検出された際、当該ジョブの待機の原因となっている待機原因ジョブと前記長時間待機ジョブの処理内容の依存関係の有無を、登録されたジョブの処理内容から判定する制約条件判定部をさらに備え、
前記出力部は、前記警告を行う際、前記依存関係の有無を併せて通知することを特徴とする請求項１に記載のジョブ処理システム。
【請求項３】
前記制約条件判定部は、前記ジョブ登録部がジョブの処理内容の登録を受け付けた際、登録された各ジョブの処理内容から、各ジョブが利用するリソースおよびファイル操作に係る情報を抽出して記憶装置に記憶させ、前記依存関係の有無は、前記長時間待機ジョブと前記待機原因ジョブがそれぞれ利用するリソースおよびファイル操作に係る情報を参照して特定することを特徴とする請求項２に記載のジョブ処理システム。
【請求項４】
前記制約条件判定部において処理内容の依存関係がないと判定された際、登録された処理順において前記待機原因ジョブと前記長時間待機ジョブの前後関係の設定を解除して調整した処理順候補を作成する処理順調整部をさらに備え、
前記出力部は、前記処理順候補をユーザに提示することを特徴とする請求項２または３に記載のジョブ処理システム。
【請求項５】
前記ジョブ処理部は、バッチ処理を実行する際、各ジョブの処理時間を記録し、
前記待ち時間判定部は、前記ジョブ処理部が記録した各ジョブの処理時間の実績値に基づき、前記処理順調整部が生成した処理順候補に則りバッチ処理を行った場合に各ジョブに発生すると予測される待ち時間を算出し、当該予測される待ち時間が所定のしきい値を超える長時間待機ジョブをさらに検出し、
前記処理順調整部は、前記予測される待ち時間が所定のしきい値を超える長時間待機ジョブが検出された場合に、処理順をさらに調整した新たな処理順候補を作成することを特徴とする請求項４に記載のジョブ処理システム。
【請求項６】
前記制約条件判定部は、前記待機原因ジョブの完了後に処理するように登録されているジョブのうち、当該待機原因ジョブと処理内容の依存関係のあるジョブを抽出し、
前記処理順調整部は、前記待機原因ジョブと処理内容の依存関係のあるジョブを、当該待機原因ジョブの完了後に処理するように前記処理順候補を作成することを特徴とする請求項４または５に記載のジョブ処理システム。
【請求項７】
前記処理順調整部は、前記バッチ処理部が記録した各ジョブの処理時間の実績値に基づき、前記処理順候補に則りバッチ処理を行った場合の総処理時間を予測し、
前記出力部は、前記処理順調整部が予測した総処理時間が総処理時間の実績値より短縮された場合に、前記処理順候補をユーザに提示することを特徴とする請求項４から６のいずれかに記載のジョブ処理システム。
【請求項８】
前記制約条件判定部は、前記処理順調整部が作成した処理順候補が、ユーザが設定した処理順に係る制約条件に違反しているか否かをさらに判定することを特徴とする請求項４から７のいずれかに記載のジョブ処理システム。
【請求項９】
前記各ジョブの処理時間の実績値は、前記ジョブ処理部が記録した各ジョブの処理時間のうち、所定の周期で抽出した処理時間を平均した値とすることを特徴とする請求項５または７に記載のジョブ処理システム。
【請求項１０】
前記待ち時間判定部はさらに、各月の同じ日にちにおいて取得した前記待ち時間の平均値を算出して前記しきい値と比較し、当該日にちに対して前記長時間待機ジョブを検出することを特徴とする請求項１から９のいずれかに記載のジョブ処理システム。
【請求項１１】
複数のジョブをバッチ処理するジョブ処理システムにおいて、
各ジョブの処理内容の登録をユーザから受け付け記憶装置に格納するステップと、
ジョブの処理順の登録をユーザから受け付け前記記憶装置に格納するステップと、
前記記憶装置に格納されたジョブの処理順を参照しながら、各ジョブの処理内容を前記記憶装置から読み出しバッチ処理を実行するとともに、各ジョブの終了時刻をメモリに記録するステップと、
メモリに記録された各ジョブの終了時刻に基づき、一のジョブの処理終了を待って所定のしきい値より長い時間処理が開始されないジョブを検出するステップと、
検出されたジョブと、処理終了を待たせているジョブとの間に処理内容の依存関係がない場合に、登録された処理順においてそれらのジョブの前後関係の設定を解除した新たな処理順を作成するステップと、
作成した処理順をユーザに提示するステップと、
を含むことを特徴とするジョブ管理方法。
【請求項１２】
複数のジョブをバッチ処理する際、各ジョブの処理時間をメモリに記録するステップと、
メモリに記録された各ジョブの処理時間に基づき、作成された前記新たな処理順でバッチ処理を行った場合に予測される総処理時間を算出するステップと、
登録された順序でバッチ処理した際の総処理時間の実績値と、前記予測される総処理時間とを比較するステップと、
をさらに含むことを特徴とする請求項１１に記載のジョブ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理技術に関し、特にユーザの登録に従いバッチ処理を行うジョブ処理システムおよび当該システムに適用されるジョブ管理方法に関する。
【背景技術】
【０００２】
近年の情報処理技術の発展およびネットワーク環境の充実化に伴い、様々な情報がネットワークを行き来し、企業、社内の部門など端末に入力された個々のデータを統括管理する組織には、入力された膨大なデータおよびシステムを厳密に管理する技術が必要不可欠となっている。データバックアップ、各種数値算出などデータを管理するための処理やシステムメンテナンスなどは一般的に、毎日、毎月、など定期的に行われるルーチン処理である。そのため、あらかじめ指定した複数のジョブをバッチで処理するように設定しておくことにより、夜間などに自動で行われることが多い。
【０００３】
ジョブをバッチ処理する場合、システムの処理能力、効率性、ジョブ同士の依存関係、優先順位などに基づき、ジョブの処理順序をあらかじめ決定しておく。そして各ジョブの処理内容、すなわちジョブフローと、ジョブの実行順序とをシステムに登録しておくことにより、基本的には所望の時間に所望の処理が自動で終了していることになる。これにより人件費を削減しつつ、各種処理の効率化が望める（例えば特許文献１）。
【特許文献１】特開平５−０１２０３７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
営業時間外の夜間にジョブをバッチ処理させるようなシステムにおいては、営業開始時間までに終了していないと営業開始に支障をきたすジョブが含まれることがある。このような場合を含め、一般的にバッチ処理は効率的に短期間で完了することが望まれる。しかし、バッチ処理はあらかじめ登録された処理内容、および順序でジョブを実行させているのみであるため、運用担当者が監視していても、当該バッチ処理が“効率的”に遂行されているか否かを判断することは難しい。システムの開発環境において開発者が“効率的”であると考えて処理順を決定しても、実機で運用してみると、扱うデータ量が想定していた量と異なっていると、効率性が低下してくることも考えられる。
【０００５】
特にシステムがインターネット上で公開されている場合などは、アクセス数が変動しやすいため、このような効率性の変化が発生しやすい。しかしそのような変化に応じてバッチ処理環境をたびたび見直すことは容易ではなく、見直しに要する人件費や時間などを考慮すると実現が難しい。同様に、既存のシステムにおけるバッチ処理のシーケンスに新たなジョブを１つ追加したり元からあるジョブを削除したりする場合も、効率性を考慮してジョブの実行順序を組み直すことは困難な作業である。
【０００６】
本発明はこうした状況に鑑みてなされたものであり、その目的は、常時最適な実行環境でジョブのバッチ処理を行うようにユーザを支援することのできるジョブ処理技術を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のある態様は、ジョブ処理システムに関する。このジョブ処理システムは、処理内容が登録されたジョブを登録された処理順でバッチ処理するジョブ処理システムであって、各ジョブの終了時刻を記録しながらバッチ処理を実行するジョブ処理部と、基準となるジョブの処理前に処理するように登録されているジョブのうち、バッチ処理時に最後に処理が終了したジョブの処理終了時刻から、その直前に処理が終了したジョブの処理終了時刻までの時間を、当該基準となるジョブの待ち時間として、各ジョブの待ち時間を取得し、待ち時間が所定のしきい値を超える長時間待機ジョブを検出する待ち時間判定部と、長時間待機ジョブが検出された際、その旨の警告をユーザに対し行う出力部と、を備えたことを特徴とする。
【０００８】
このジョブ処理システムは、長時間待機ジョブが検出された際、当該ジョブの待機の原因となっている待機原因ジョブと長時間待機ジョブの処理内容の依存関係の有無を、登録されたジョブの処理内容から判定する制約条件判定部をさらに備え、出力部は、警告を行う際、依存関係の有無を併せて通知するようにしてもよい。ここで「依存関係」とは、あるジョブの処理結果が別のジョブの処理に影響を与える関係、すなわち、前に処理されるジョブが終了しないと後に処理されるジョブが正常に処理されないような関係をいう。一般的には、前に処理されるジョブが操作するファイルやリソースを、後に処理されるジョブが参照したり操作したりする場合に、このような関係が発生する。
【０００９】
本発明の別の態様は、ジョブ管理方法に関する。このジョブ管理方法は、複数のジョブを登録された順序でバッチ処理し、各ジョブの終了時刻をメモリに記録するステップと、メモリに記録された各ジョブの終了時刻に基づき、一のジョブの処理終了を待って所定のしきい値より長い時間処理が開始されないジョブを検出するステップと、検出されたジョブと、処理終了を待たせているジョブとの間に処理内容の依存関係がない場合に、登録された処理順においてそれらのジョブの前後関係の設定を解除した新たな処理順を作成するステップと、作成した処理順をユーザに提示するステップと、を含むことを特徴とする。
【００１０】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、バッチ処理を行うシステムにおいて状況に応じた最適な実行環境を容易に実現することができる。
【発明を実施するための最良の形態】
【００１２】
図１は本実施の形態を適用できるシステムの構成例を示している。同図においてジョブ処理システム１０は第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８の４つのサーバを含む。また第１サーバ１２はデータベース２０に接続している。ユーザは各サーバの端末などを操作し、設定、登録を行うことにより、所望のジョブを所望の時間に処理させる。なお、サーバやデータベースの数、データベースの接続先は図１に示したものに限らず、ジョブを処理できるシステムであればいかなる構成においても本実施の形態を適用できる。また各サーバにさらにクライアント端末などが接続していてもよい。
【００１３】
第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８はそれぞれ、一以上のＣＰＵとメモリ、記憶装置、入出力装置、表示装置など、あるいはそのいずれかの組み合わせを備えた一般的な情報処理装置であればよく、パーソナルコンピュータ、汎用大型コンピュータなどその規模は限定されない。同図は一例として第１サーバ１２がハードディスク１３を、第２サーバ１４がハードディスク１５をそれぞれ備えた構成を示している。また第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８はネットワーク２２に接続され、互いにデータを送受することができる。
【００１４】
ユーザは第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８のいずれかに対しジョブフロー、バッチ処理時の処理の順序、処理開始時間などの設定を行うことにより、ジョブ処理システム１０にジョブを処理させる。ここで「ジョブフロー」とは、ジョブごとの具体的な処理内容のことである。各ジョブを第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８のいずれかひとつのサーバで処理するようにしてもよいし、複数のサーバで処理するようにしてもよい。ジョブをどのサーバでどのような順序で処理させるか、また、並列に複数のジョブを処理させるかどうかなどは、ＣＰＵの処理能力やネットワークの帯域など利用可能なリソースや、データベースへのアクセス順といった処理内容に鑑み、ユーザが設定を行う。これらの手続きは、ジョブのバッチ処理に際し行われる 一般的な手法を用いることができる。
【００１５】
さらに本実施の形態では、ユーザにより設定されたジョブの処理順でバッチ処理を行った結果に基づき、ジョブ処理システム１０自身がジョブ処理の効率性の評価を行い、必要に応じてユーザに対し警告を行ったり、新たな処理順候補を提案したりする。ユーザはその警告や提案に基づきジョブの処理順を設定し直すことができる。
【００１６】
図２はジョブ処理システム１０でバッチ処理されるジョブの処理順の例を模式的に示している。ジョブの処理順は上述のとおりユーザが設定し、ジョブ処理システム１０が例えば図２に示すようなジョブネット図の形式で記憶する。同図では、各矩形が一つのジョブを表し、矢印によってその処理順を示している。すなわち同図のジョブネット図９０の例では、「ジョブＡ」、「ジョブＢ」を並列に処理したあと、「ジョブＣ」と「ジョブＤ」をこの順で処理するように設定されている。
【００１７】
ユーザは各ジョブのジョブフローを、ジョブネット図９０とは別に設定する。このときジョブ処理システム１０は、例えばジョブネット図を参照しながら各ジョブのジョブフローを呼び出すことによりバッチ処理を進捗させる。図２の場合、すなわちジョブネット図９０のように処理順が設定されたジョブのバッチ処理においては、「ジョブＡ」と「ジョブＢ」の双方の処理が終了しないと「ジョブＣ」の処理は開始されない。例えば「ジョブＢ」の処理時間が「ジョブＡ」の処理時間より長い場合、「ジョブＣ」の処理を開始するには、「ジョブＡ」の処理が終了した後も、「ジョブＢ」の処理終了を待ち続ける必要がある。
【００１８】
以後、基準となるジョブの処理前に処理するように登録されているジョブのうち、最後に処理が終了するジョブの処理終了時刻と、その直前に処理が終了したジョブの終了時刻との差分を、当該基準となるジョブの「待ち時間」とする。図２の例で「ジョブＣ」を基準とすると、その待ち時間は、「ジョブＡ」が終了してから「ジョブＢ」が終了するまでの時間となる。このような例で「ジョブＣ」の待ち時間が長い、すなわち「ジョブＡ」が終了してから「ジョブＢ」が終了するまでに長い時間を要するとき、処理効率の観点から改善の余地がある場合が多くなる。
【００１９】
例えば「ジョブＣ」が、「ジョブＢ」の処理終了を待つ必要のないジョブである場合がそれにあたる。すなわち、「ジョブＢ」が出力した結果を「ジョブＣ」が利用するなど処理内容上の依存関係がない場合、これらのジョブの処理順には制約条件は発生しない。この場合、「ジョブＣ」の処理を「ジョブＢ」の処理終了を待たずに開始するように処理順の設定を変更することにより、バッチ処理の効率性が向上する。一方、ジョブの処理内容において先行する一のジョブの出力結果を後続の一のジョブが何らかの形で利用するような場合は、ジョブの前後関係を保持する必要がある。以後、このような場合に先行ジョブは後続ジョブの「前提ジョブ」であるという。
【００２０】
本実施の形態におけるジョブ処理システム１０は、待ち時間の発生に関与しているジョブの処理順を、処理内容の前提条件を考慮しながら見直す。具体的には、バッチで処理される各ジョブについて実際に生じた「待ち時間」を取得し、所定のしきい値を超える待ち時間を有するジョブ（以後、「長時間待機ジョブ」と呼ぶ）と、当該待ち時間を発生させている、すなわち待たせているジョブ（以後、「待機原因ジョブ」と呼ぶ）との依存関係を確認して、処理順における改良の余地を模索する。そして待ち時間の発生について警告を行ったり、処理順の調整を行った結果得られた、候補となる処理順をユーザに提示したりする。
【００２１】
図３は第１サーバ１２の構成をより詳細に示している。第２サーバ１４、第３サーバ１６、第４サーバ１８も同様の構成としてよい。第１サーバ１２はジョブ処理時に適宜アクセスする前出のハードディスク１３の他、ユーザが登録したジョブフローや処理順から後の処理に必要な情報を有するデータを作成するジョブ登録部３２、作成したジョブフローや処理順に係るデータを記憶するジョブ情報記憶部４４、登録されたジョブを処理するジョブ処理部３４、ジョブの実際の終了時刻や処理時間を記録する実行状況記憶部４６、待ち時間がしきい値を超えるジョブの有無を検出する待ち時間判定部３６、各ジョブの前提ジョブの有無などジョブの処理順の制約条件を確認する制約条件判定部３８、ジョブの処理順を可能な範囲で入れ替えて調整を行う処理順調整部４０、ユーザに対し待ち時間の発生についての警告や処理順の候補の提示を行う出力部４２を含む。
【００２２】
図３において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、演算やファイル操作、データベースへのアクセスを行うプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００２３】
ジョブ登録部３２は、ジョブフローやジョブの処理順など、ジョブの処理に必要な情報をユーザが登録するためのインターフェースである。ジョブ登録部３２は、登録画面を表示した表示装置と、キーボード、ポインティングデバイスなど登録画面に対して入力を行う入力装置との組み合わせなどでよく、ジョブを処理する一般的なシステムで用いられる装置を適用することができる。登録された情報は、スクリプトコードやジョブネット図など所定の形式でジョブ情報記憶部４４に格納する。
【００２４】
ジョブ登録部３２はジョブフローの登録を受け付けた際、当該ジョブフローから各ジョブが利用するリソースなどを抽出して、利用リソース情報のテーブルを作成する。利用リソース情報のテーブルは、バッチで処理される各ジョブの名前と、それが利用するリソース、サーバ、処理内容の特徴などを対応づけたテーブルである。ジョブ登録部３２は、ユーザが入力したジョブフローのデータから、入出力を行うハードディスク、アクセスするサーバ、作成するファイルの名前などの情報を所定の項目ごとに抽出し、利用リソース情報のテーブルを作成する。
【００２５】
一般に、ジョブの処理順を表すジョブネット図は図面として表示可能であるため、運用担当者などによって容易に確認が可能である。しかしそこから得られる情報は、設定されたジョブ処理の前後関係であって、同一のファイルを操作するなどの処理内容上の依存関係ではない。ジョブの処理内容はプログラムやスクリプトコードによって提供されていることもあるため、このような依存関係を、処理内容を詳細に把握せずに確認することは困難である。そこで本実施の形態では、ジョブ同士の処理内容上の関係を利用リソースの観点から紐づける。利用リソース情報のテーブルの具体例は後に述べる。
【００２６】
本実施の形態では、各ジョブが利用するリソースに基づき、ジョブがどのサーバで処理されているかに関わらず全体として処理順の効率性を評価する。従って利用リソース情報は、どのサーバでどのジョブが処理されているかに関わらず、ジョブ処理システム１０でバッチ処理している全てのジョブについての情報を第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８間で共有してもよい。その場合、あるサーバで利用リソース情報のテーブルが更新されるたびに、その更新情報を他のサーバに送信して各自が保持する利用リソース情報のテーブルを更新する。あるいは、あるサーバのジョブ情報記憶部４４を他のサーバからアクセス可能とすることにより同一の利用リソース情報のテーブルを参照する。
【００２７】
ジョブ処理部３４は、ユーザが登録したジョブフロー、ジョブネット図などの情報をジョブ情報記憶部４４から読み出し、実行する。これはジョブを処理する一般的なシステムで用いられる手法を適用することができる。ジョブ処理部３４はさらに、ジョブを処理する都度、各ジョブの終了時刻と開始から終了までの処理時間を実行状況記憶部４６に記録する。
【００２８】
待ち時間判定部３６は、ジョブ処理部３４が実行状況記憶部４６に記録した各ジョブの終了時刻を参照して、上述した待ち時間を各ジョブについて計算する。そしてあらかじめ設定されたしきい値と比較することにより、待ち時間がしきい値を超えるジョブを検出する。しきい値は標準的な値を実験などにより求めてもよいし、ユーザがジョブ登録部３２に対して設定できるようにしてもよい。あるいは、システムで実行されるジョブの待ち時間の実績値からその標準偏差を計算し、待ち時間が当該標準偏差に基づく所定の範囲から逸脱して長く生じているジョブを抽出するようにしてもよい。これにより、実際の運用状況を考慮したうえでより改善効果の高い修正案を導出することができる。
【００２９】
ここで待ち時間判定部３６は、ジョブが１回バッチ処理される都度、当該１回の処理における各ジョブの終了時刻から待ち時間を算出してしきい値と比較してもよいし、所定の回数のバッチ処理が行われたら、その回数分の各ジョブの待ち時間の平均値を算出してしきい値と比較するようにしてもよい。あるいは、システム固有の運用形態によってあらかじめ設定した状況別に平均待ち時間を算出するようにしてもよい。例えば入出金の管理システムなどでは、経理上の締め日や年度末にはデータが増加し処理時間が増加することが考えられる。また、並列処理されているジョブの数が増加するほど、リソースへのアクセスの排他制御などによって処理時間が増加することが考えられる。
【００３０】
各ジョブの処理時間の変動によって待ち時間も変化するため、システムの運用形態によって待ち時間が周期的に変動することもあり得る。そのため、例えば一ヶ月で平均処理時間が周期的に変動するようなシステムにおいては、各月の同日における待ち時間の平均値を算出するようにしてもよい。待ち時間が月末のみに長くなっている、といった、待ち時間の変動の傾向をユーザが正確に把握できると、処理順を実際に変更すべきか否か、といった判断の拠り所となる。場合によっては、処理順の変更より効率的な改良点を見出せる可能性もある。
【００３１】
処理順調整部４０は、待ち時間がしきい値を超えるジョブがあった場合に、処理順を調整できる箇所を検出し、新たな処理順の候補を作成する。具体的には、待機原因ジョブが長時間待機ジョブの前提ジョブに含まれていない場合に、待機原因ジョブと長時間待機ジョブの前後関係の設定を解除する。さらに後続のジョブのうち、待機原因ジョブを前提ジョブとしているジョブの有無を確認し、そのようなジョブがある場合は、待機原因ジョブの後に当該ジョブを処理するような処理順候補を作成する。
【００３２】
図２の例で、長時間待機ジョブが「ジョブＣ」、待機原因ジョブが「ジョブＢ」であり、「ジョブＢ」が「ジョブＣ」の前提ジョブでなく「ジョブＤ」の前提ジョブであった場合は、「ジョブＣ」の処理を「ジョブＡ」の処理終了後に開始するようにし、「ジョブＤ」の処理を「ジョブＢ」の処理終了後に開始するような処理順の候補を作成する。このようにすることで、「ジョブＢ」が予想外に長い処理になっていたとしても、その処理終了を無意味に待ち続けることなく「ジョブＣ」の処理を開始させることができ、処理効率が向上して、全体的なバッチ処理時間の短縮が見込まれる。
【００３３】
ただし、長時間待機ジョブを待機原因ジョブの後に処理するという制約を解除したことにより、長時間待機ジョブが新たな待機原因ジョブとなって後続のジョブに待ち時間を発生させてしまうなど、必ずしも上述の処理を一度行ったのみで全てのジョブの待ち時間が解消されたり処理時間が短縮されたりするとは限らない。そのため処理順調整部４０は、暫定的に作成した処理順の候補を待ち時間判定部３６に一旦戻し、再度、待ち時間の評価を行わせる。そして待ち時間がしきい値を超えるジョブが再度検出されたら同様の調整を行い、新たな処理順の候補を作成する。この作業を、しきい値を超える待ち時間を有するジョブがなくなるまで繰り返す。
【００３４】
さらに処理順調整部４０は、このようにして作成した処理順の候補に対し、処理時間の評価を行う。このとき処理順調整部４０は、実行状況記憶部４６に記録された、各ジョブの実際の処理時間を、作成した処理順候補における各ジョブに当てはめていき、バッチ処理の総処理時間の予測値を算出する。算出に用いる各ジョブの処理時間は、ある期間の平均値でもよいし、前述のように、ある周期ごとに待ち時間を評価している場合はその周期における平均値でもよい。そして総処理時間の予測値を実績値と比較し、処理順の見直しによって処理時間の短縮が見込まれるか否かを判断する。短縮できると判断した場合に、その処理順を最終的な候補として決定する。
【００３５】
制約条件判定部３８は、処理順調整部４０がジョブの処理順を調整する際に、待機原因ジョブが長時間待機ジョブの前提ジョブであるか否かの判定、待機原因ジョブを前提ジョブとする後続のジョブを検出する。判定に際しては、ジョブ情報記憶部４４に記憶された利用リソース情報のテーブルを参照する。制約条件判定部３８はさらに、前提ジョブ以外に設定されたジョブの処理順に関する制約条件に基づき、処理順調整部４０が作成する処理順の候補に違反がないかを判定する。制約条件としては、例えば並列に処理するジョブの最大数が挙げられる。
【００３６】
処理順調整部４０は、待ち時間を短縮する方針で適宜ジョブの前後関係の切り離しおよび接続を行っていくが、その結果、システムの処理能力を超える数のジョブを一度に処理するような処理順となっても、それを実現することは困難となる。そこで制約条件の範囲内で処理順が調整できるように、制約条件判定部３８が処理順の候補の是非を判定する。制約条件は、同じデータベースやハードディスクなどのリソースにアクセスするジョブを並列に処理できる最大数や、同じデータベースを同時に更新するなど、あるリソースを同時に利用するジョブが並列に実行されないか、など、より細かい制約でもよい。それらの情報は利用リソース情報のテーブルから取得できる。また能力上、不可能か可能かを基準に決定されるものばかりでなく、フローが複雑すぎないかなど、ユーザの趣向によって適宜ポリシーを定めてもよい。
【００３７】
制約条件は、あらかじめ定めておいたものをジョブ情報記憶部４４に記憶させておいてもよいし、ユーザが入力したものをジョブ登録部３２がジョブ情報記憶部４４に格納するようにしてもよい。制約条件判定部３８は、当該制約条件をジョブ情報記憶部４４から読み出し、処理順調整部４０が作成する処理順の候補に違反がある場合に、その旨の通知を処理順調整部４０に対し行う。
【００３８】
出力部４２は、処理順調整部４０が作成した処理順の最終的な候補を出力してユーザに提案を行う。待機原因ジョブが長時間待機ジョブの前提ジョブであったり、処理順を調整しても待ち時間がしきい値を超えるジョブが解消されない、処理時間が改善されないなどの場合は、処理順の候補を出力せず、長時間待機ジョブの存在についての警告や、長時間待機ジョブが待機原因ジョブの前提ジョブである旨の情報を出力することによりユーザに警告してもよい。あるいは、調整の途中で作成した暫定的な処理順候補を提示し、これ以上の調整は制約違反である、などといった問題点を提示するようにしてもよい。これにより最適な解決策を決定する際の手がかりをユーザに与えることができる。出力部４２は一般的な表示装置やプリンタなどの出力装置でもよいし、電子メールやファクシミリなどの通信機器をさらに含んでもよい。
【００３９】
次に、ジョブ登録部３２が生成する利用リソース情報のテーブルについて説明する。それに先立ち、ジョブ処理システム１０で処理されるジョブフローの例を示す。図４はジョブ登録部３２に対しユーザが登録するジョブフローの一例を示している。この例のジョブフローは、第１ステップ５０および第２ステップ５２の２段階の処理によって構成されている。第１ステップ５０は、第１サーバ１２のハードディスク１３のドライブＤに格納されたファイルを、シェル５４によって同じくドライブＤに別名で保存する処理である。同図の例は、前日に作成した入出金明細のファイル「ａａａ．ｔｘｔ」を、作成した年月日を表す数列「ｙｙｙｙｍｍｄｄ」を含むファイル名「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」を有するファイルとして保存する。すなわち入出金明細のバックアップファイルを作成する。
【００４０】
第２ステップ５２は、別に作成したプログラム５６により、第１サーバ１２に接続したデータベース２０に格納されたデータを参照して新たな入出金ファイルを作成し、ファイル「ａａａ．ｔｘｔ」としてドライブＤに格納する処理である。以上の処理を含むジョブを例えば毎日所定の時間に処理することにより、ハードディスク１３のドライブＤには日々の入出金明細のバックアップデータがファイル名に日付を含む形で蓄積されていくことになる。
【００４１】
第１ステップ５０において入出金明細のファイル「ａａａ．ｔｘｔ」をバックアップファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」として保存するためのシェル５４は、ユーザ自身が作成してジョブ情報記憶部４４に登録してもよいし、対話式の登録手段を用いてジョブ登録部３２が自動で作成してジョブ情報記憶部４４に格納してもよい。第２ステップにおいて新たな入出金明細ファイルを作成するプログラム５６は、あらかじめ作成しておいたものをジョブ情報記憶部４４に格納しておいてもよいし、図示しない他の記憶装置から呼び出してロードするようにしてもよい。
【００４２】
ユーザはジョブ登録部３２に対し、図４のようなジョブフローを対話形式で、あるいはスクリプトファイルを自作するなどしてジョブの名前とともに登録する。ジョブ登録部３２は登録されたジョブの名前などをファイル名として、各ジョブフローをジョブ情報記憶部４４に格納する。さらに次に述べる利用リソース情報のテーブルを作成してジョブ情報記憶部４４に格納する。
【００４３】
図５はユーザが入力したジョブフローに対しジョブ登録部３２が作成する、利用リソース情報のテーブルのデータ構造例を示している。利用リソース情報テーブル１００において、１つのジョブに含まれる所定単位の処理が１行分のデータとなる。図５の例では、リソースへのアクセス、例えばファイルの読み出し（参照）や書き込み（更新）を１つの単位として記載している。利用リソース情報テーブル１００は、ジョブ名欄１０２、利用サーバ欄１０４、利用リソース種類欄１０６、リソース詳細欄１０８、処理内容欄１１０、参照先ファイル欄１１２、更新先ファイル欄１１４、前提ジョブ欄１１６を含む。前述の通りジョブ登録部３２は、新たなジョブフローが登録されるたびに当該ジョブフローから必要な情報を抽出し、利用リソース情報テーブル１００にエントリを追加していく。
【００４４】
ジョブ名欄１０２には、ユーザが登録を行ったジョブの名前を記載する。利用サーバ欄１０４にはそれぞれのジョブが利用するリソースが属するサーバの名前を記載する。利用リソース種類欄１０６には利用するリソースの種類、例えばハードディスク、データベース、ＬＡＮカードなどを識別する情報を記載する。リソース詳細欄１０８には、具体的なリソースの識別情報を記載する。処理内容欄１１０には、リソース詳細欄１０８に記載したリソースを利用して行われる具体的な処理内容を記載する。ここでは前述のとおり、リソースへのアクセスごとに行を設けているため、「参照」や「更新」が記載されている。ここで「更新」とは新たなファイルの作成処理も含む。また、参照と更新からなる１対の処理が、バックアップなどを目的とする、ファイルのコピーである場合は、それらの処理を他と区別できるように記載する。図５の例では、「参照（コピー）」、「更新（コピー）」なる表記がそれにあたる。処理内容欄１１０にはその他、リソースへのアクセス内容を表す「転送」、「出力」などを適宜記載する。
【００４５】
参照先ファイル欄１１２には、ファイルの参照処理において参照されるファイルの名前を記載する。更新先ファイル欄１１４には、ファイルの更新処理よって更新、または新たに作成されるファイルの名前を記載する。前提ジョブ欄１１６には各ジョブの前提ジョブのジョブ名を記載する。
【００４６】
前提ジョブは、各ジョブの参照先のファイルと同リソースにある同名のファイルを更新しているジョブのうち、処理順が前のジョブを抽出することによって得られる。あるいは、ジョブネット図の登録時などにユーザによって設定できるようにしてもよい。図５はジョブ登録部３２が前提ジョブを前提ジョブ欄１１６に記載する例を示しているが、利用リソース情報テーブル１００には前提ジョブ欄１１６を設けなくてもよい。この場合、制約条件判定部３８が、処理順調整部４０からの依頼を受けて利用リソース情報テーブル１００の参照先ファイル欄１１２および更新先ファイル欄１１４などを参照し、対象ジョブの前提ジョブを上述の手法で適宜抽出するようにしてもよい。同様に、本実施の形態ではいずれかの段階でジョブフローから前提ジョブの情報を取得できればよく、利用リソース情報テーブル１００は図５のデータ構造に限定されるものではない
【００４７】
図５に示した利用リソース情報テーブル１００のうち「ジョブＢ」なるジョブは、図４で示したジョブに対応する。すなわち、第１ステップ５０では第１サーバ１２のハードディスク１３のドライブＤにアクセスし、入出金明細ファイル「ａａａ．ｔｘｔ」のバックアップファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」を作成しているため、図５に示した利用リソース情報テーブル１００の４、５行目において、利用サーバ欄１０４には「第１サーバ」、利用リソース種類欄１０６にはハードディスクを示す「ＤＩＳＫ」、リソース詳細欄１０８には「ドライブＤ」、処理内容欄１１０には「参照（コピー）」および「更新（コピー）」、参照先ファイル欄１１２には「ａａａ．ｔｘｔ」、更新先ファイル欄１１４には「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」と記載されている。
【００４８】
また「ジョブＢ」は、第２ステップ５２において、第１サーバ１２に接続したデータベース２０を参照して新たなファイル「ａａａ．ｔｘｔ」を作成しているため、利用リソース情報テーブル１００の６、７行目において、利用サーバ欄１０４には「第１サーバ」、利用リソース種類欄１０６にはデータベースへのアクセスを示す「ＤＢＭＳ」、およびハードディスクを示す「ＤＩＳＫ」、リソース詳細欄１０８には「データベース」および「ドライブＤ」、処理内容欄１１０には「参照」および「更新」、参照先ファイル欄１１２には参照するデータベース名である「会計ＤＢ」、更新先ファイル欄１１１には「ａａａ．ｔｘｔ」と記載されている。
【００４９】
さらに「ジョブＢ」は前提ジョブがないとして、前提ジョブ欄１１６は無記入となっている。「ジョブＡ」、「ジョブＣ」、「ジョブＤ」も同様に記載され、特に「ジョブＣ」は前提ジョブが「ジョブＡ」、「ジョブＤ」は前提ジョブが「ジョブＢ」であることが前提ジョブ欄１１６にそれぞれ記載されている。
【００５０】
次にこれまで述べた構成で実現できる、ジョブ処理システム１０の動作について説明する。図６は、ジョブ処理システム１０が行う、ジョブ処理の順序の調整に係る処理の手順を示すフローチャートである。まず、ジョブ処理部３４はジョブ情報記憶部４４からジョブネット図やジョブフローを読み出し、ユーザの設定通りにジョブのバッチ処理を行う（Ｓ１０）。この際、各ジョブの処理終了時刻と処理時間を実行状況記憶部４６に記録していく。
【００５１】
待ち時間判定部３６は、バッチ処理が行われた都度、あるいは所定の周期で、実行状況記憶部４６に記録された各ジョブの終了時刻から待ち時間あるいはその平均値をジョブごとに算出し、しきい値と比較する（Ｓ１２）。しきい値を超える待ち時間を有するジョブを検出したら（Ｓ１２のＹ）、処理順調整部４０に検出した長時間待機ジョブとその待ち時間を発生させている待機原因ジョブの情報を与え、処理順調整部４０が調整を行うことにより処理順の暫定的な候補を作成する（Ｓ１４）。一方、しきい値を超える待ち時間を有するジョブが検出されない場合はそのまま処理を終了する（Ｓ１２のＮ）。
【００５２】
処理順調整部４０が処理順の候補を作成した場合は（Ｓ１２のＹ、Ｓ１４）、待ち時間判定部３６が、作成された処理順の候補に、実行状況記憶部４６から読み出した、各ジョブの処理時間あるいはその平均値を当てはめていき、各ジョブの待ち時間の予測値を算出してしきい値と比較する（Ｓ１８）。待ち時間の予測値がしきい値を超えるジョブがある場合は（Ｓ１８のＮ）、実際の長時間待機ジョブが検出された場合と同様、処理順調整部４０にその情報を与え、処理順調整部４０が調整を行うことにより新たな処理順の候補を作成する（Ｓ１４）。その後、待ち時間の予測値算出、しきい値との比較による評価、処理順候補の作成を、待ち時間の予測値がしきい値を超えるジョブがなくなるまで繰り返す（Ｓ１６、Ｓ１８のＮ、Ｓ１４）。
【００５３】
待ち時間の予測値がしきい値を超えるジョブがなくなったら（Ｓ１８のＹ）、処理順調整部４０は、作成した処理順候補に各ジョブの処理時間あるいはその平均値を当てはめて、その順でバッチ処理を行った場合の総処理時間の予測値を算出し、実行状況記憶部４６から読み出した実績値と比較する（Ｓ２０）。総処理時間の予測値が実績値より少ない、すなわち総処理時間が短縮されると見込まれる場合は（Ｓ２０のＹ）、当該処理順を最終的な候補として出力部４２に出力する（Ｓ２２）。
【００５４】
一方、総処理時間の予測値が実績値以上であった場合は（Ｓ２０のＮ）、待ち時間がしきい値を超える長時間待機ジョブがあること、および当該長時間待機ジョブおよび待機原因ジョブのジョブ名や、ジョブネット図上の位置など、それらのジョブの情報を出力部４２において出力することにより警告を行う（Ｓ２４）。上述のとおり、調整の途中で作成した暫定的な処理順候補を出力し、それ以上の調整は制約違反である、あるいは処理時間が短縮されない、といった問題点を提示するようにしてもよい。
【００５５】
図７は、図６のＳ１４において処理順調整部４０が制約条件判定部３８の判定に基づき新たな処理順候補を作成する処理手順を示すフローチャートである。まず処理順調整部４０は、制約条件判定部３８に問い合わせを行うことにより、待機原因ジョブが長時間待機ジョブの前提ジョブであるか否かを確認する（Ｓ３０）。待機原因ジョブが長時間待機ジョブの前提ジョブである場合は（Ｓ３０のＮ）、待機原因ジョブと長時間待機ジョブの前後関係を保持する必要があるため、それ以上の処理順の調整はできないとして、図６のＳ２４と同様、長時間待機ジョブの存在に関する警告を出力部４２に行わせる（Ｓ３４）。
【００５６】
一方、待機原因ジョブが長時間待機ジョブの前提ジョブでない場合は（Ｓ３０のＹ）、待機原因ジョブと長時間待機ジョブの前後関係の設定を解除する（Ｓ３２）。具体的には、長時間待機ジョブの前に処理すると設定されたジョブが待機原因ジョブ以外にあれば、単に待機原因ジョブとの前後関係を解除する。長時間待機ジョブの前に処理すると設定されたジョブが待機原因ジョブしかなければ、長時間待機ジョブを待機原因ジョブの１つ前に処理が終了したジョブの次に処理するように設定を行う。この際、長時間待機ジョブの後に処理するように設定されているジョブは、仮にその前後関係を保持しておく。また、並列で処理できる最大ジョブ数などの制約条件を制約条件判定部３８に確認し、制約違反となる場合は、それ以上の調整は行わずにＳ３４と同様の警告を行うか（図示せず）、あらかじめ定めた規則に則り、制約条件に違反しない、別のジョブの次に処理するように設定を行う。
【００５７】
次に処理順調整部４０は、再度制約条件判定部３８に問い合わせを行うことにより、長時間待機ジョブの次に処理するように設定されているジョブから、待機原因ジョブを前提ジョブとするジョブを抽出する（Ｓ３６）。そのようなジョブがある場合は（Ｓ３６のＹ）、当該ジョブを待機原因ジョブの次に処理するように設定する（Ｓ３８）。そのようなジョブの処理が前提ジョブである待機原因ジョブの終了を待たずに開始されるのを防ぐためである。以後、待機原因ジョブを前提ジョブとするジョブを次々に抽出して待機原因ジョブの後続ジョブに追加していく処理を繰り返し（Ｓ３６のＹ、Ｓ３８）、そのようなジョブがなくなった時点で処理を終了する（Ｓ３６のＮ）。このような処理により、処理内容上の依存関係および並列処理が可能な最大ジョブ数などの制約条件の範囲内で、長時間待機ジョブと待機原因ジョブの前後関係を解除し、しきい値を超える待ち時間を解消できる処理順候補を作成できる。
【００５８】
図８は、これまで述べた処理によって生成される、ジョブの処理順候補の具体例を示している。同図においては右方向が時間軸であり、各ジョブを表す矩形の幅が処理時間を表す。矩形間の矢印は処理順に前後関係が設定されていることを表す。まず初めに、図８の（ａ）に示すような処理順、すなわち、「ジョブａ」の処理後に「ジョブｂ」、「ジョブｃ」、「ジョブｄ」が並列に処理され、それらのジョブの処理後に「ジョブｅ」が処理される処理順がユーザによって設定されていたとする。ここで「ジョブｃ」の終了時刻から「ジョブｄ」の終了時刻までの時間ｔ１がしきい値より大きかった場合、待ち時間判定部３６は「ジョブｄ」を待機原因ジョブ、「ジョブｅ」を長時間待機ジョブとして検出する。
【００５９】
ここで「ジョブｄ」が「ジョブｅ」の前提ジョブでないことが制約条件判定部３８により判明すると、処理順調整部４０は「ジョブｄ」の後に「ジョブｅ」を処理する、という前後関係の設定（線１２０）を解除する。その結果、「ジョブｅ」は「ジョブｄ」の１つ前に処理が終了する「ジョブｃ」の処理終了後に処理が開始されるジョブとなる。同図の場合、待機原因ジョブである「ジョブｄ」の後に処理すると設定されていたジョブは「ジョブｅ」以外にないため、図７のＳ３８のように「ジョブｄ」の次に処理するジョブを抽出することはない。そのため、図８の（ｂ）が暫定的な処理順候補となる。
【００６０】
続いて待ち時間判定部３６は、当該処理順候補について再度、しきい値を超える待ち時間を有するジョブの検出を行う。この際、図８（ｂ）の暫定的な処理順候補に、各ジョブの処理時間の実績値あるいはその平均値を当てはめていくことにより、各ジョブの待ち時間の予測値を算出できる。同図の場合、「ジョブｂ」と「ジョブｃ」はおよそ同時に処理が開始されるため、「ジョブｂ」の処理時間と「ジョブｃ」の処理時間の差分の時間ｔ２が「ジョブｅ」の待ち時間となる。当該時間ｔ２がしきい値より大きかった場合、待ち時間判定部３６は「ジョブｃ」を「ジョブｅ」の待機原因ジョブとして検出する。
【００６１】
そして上述同様、「ジョブｃ」が「ジョブｅ」の前提ジョブでないことが制約条件判定部３８により判明すると、処理順調整部４０は「ジョブｃ」の後に「ジョブｅ」を処理する、という前後関係の設定（線１２２）を解除する。その結果、「ジョブｅ」は「ジョブｃ」の１つ前に処理が終了する「ジョブｂ」の処理終了後に処理が開始されるジョブとなり、図８（ｃ）に示すような暫定的な処理順候補が再度決定する。
【００６２】
次に待ち時間判定部３６は、当該暫定的な処理順候補について待ち時間を算出するが、この場合は、「ジョブａ」の終了時刻と「ジョブｂ」の終了時刻との差分、すなわちおよそ「ジョブｂ」の処理時間である時間ｔ３を「ジョブｅ」の待ち時間とする。そして時間ｔ３がしきい値より大きい場合、「ジョブｂ」は「ジョブｅ」の待機原因ジョブとして検出される。ここで「ジョブｂ」が「ジョブｅ」の前提ジョブでないとすると、処理順調整部４０はそれらのジョブの前後関係の設定（線１２４）を解除する。さらに、「ジョブｅ」の前に処理するジョブを、「ジョブｂ」の前に処理が終了する「ジョブａ」とし、「ジョブａ」、「ジョブｅ」なる前後関係（線１２６）を設定することにより、さらに新たな処理順候補とする。
【００６３】
制約条件判定部３８によってこのような処理順候補が制約条件違反でないことが確認され、それ以上待ち時間がしきい値を超えるジョブが検出されなかったら、当該処理順候補に対し、各ジョブの処理時間の実績値を当てはめていき、総処理時間の予測値を算出する。総処理時間の予測値が実績値を下回ったら、この処理順を最終的な処理順候補として出力部４２から出力する。一方、例えば並列に処理するジョブの最大数が「３」として設定されていた場合、「ジョブａ」の後に処理するジョブの数を当初の設定以上に増やすことはできないため、制約条件判定部３８は「ジョブａ」、「ジョブｅ」なる前後関係を追加することを制約条件違反とする。
【００６４】
この場合、処理順調整部４０はそれ以上の調整をせずに、出力部４２に待ち時間に係る警告を出力してもよいし、図８（ｃ）のような暫定的な処理順候補を出力してもよい。あるいは、実際の運用形態や処理内容などによってさらに詳細な調整規則を定めておくことにより、自動で調整を行える範囲を増やしてもよい。例えば図８（ｃ）のような状況まで調整を行った後、並列に処理するジョブの最大数が「３」と設定されていて「ジョブｅ」の処理を「ジョブａ」の処理後に設定できない場合は、さらに「ジョブａ」の前に「ジョブｅ」を処理できるか調整を試みるようにしてもよい。この場合、「ジョブａ」が「ジョブｅ」の前提ジョブでないか確認し、前提ジョブでなかった場合は最終的な処理順候補とすることができる。
【００６５】
図８に示したいずれかの段階で、待機原因ジョブが長時間待機ジョブの前提ジョブとなっていて、それらのジョブの前後関係を解除することができなくなった場合は、前述のとおり、待ち時間に係る警告を出力したり、その時点までに作成した処理順候補を出力したりできる。
【００６６】
以上述べた本実施の形態によれば、ジョブを処理する都度、ジョブの終了時刻を記録し、各ジョブの待ち時間、あるいはその平均値を算出する。そしてしきい値を超える待ち時間を発生させているジョブがあった場合に、その部分のジョブ処理の前後関係を調整する。これにより、運用段階では把握しづらい、処理効率上問題のある箇所の検出を容易に行うことがでる。これまでは一旦決定した処理順を調整することは容易ではなかったが、運用している間にアクセス数が変化したり、新たなジョブを追加したりと状況が変化しても、状況に応じて、最適な処理順での運用が可能となる。システム導入前など最初に処理順を決定する際にも、処理効率を気にせずに初期設定を行っても、問題箇所の洗い出しと処理順の調整をシステムが自律的に行うため、開発にかかる負担を減らすことができる。
【００６７】
処理順の調整にあたっては、ジョブネット図などでは把握しにくい、ジョブの処理内容上の依存関係を、利用リソース情報などから確認し、さらに、並列で処理できるジョブの最大数など処理順の制約条件やユーザが所望とするポリシーにも照らし、それらの条件が許す範囲で調整を行う。そのため、処理順を安全かつ迅速に調整することが可能となり、処理内容の詳細を把握していなくてもシステムの保守、改善を行うことができる。このことは、各ジョブの処理内容の全貌を把握することが困難な、多数のジョブを実行する大規模なシステムにおいて特に有効である。
【００６８】
また、待ち時間の算出を、運用形態に合わせて周期的に行うなどの詳細な設定ができる。これにより、ある期間で限定的に待ち時間が増加する、などの傾向をユーザが把握しやすくなるとともに、あまり重要でない場面において不用意に警告を出したり、重要な場面での待ち時間の増加が平均値でならされてしまい警告が出なかったり調整されなかったりするのを防ぐことができる。
【００６９】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００７０】
例えば本実施の形態では、処理順調整部４０が、処理順の調整を行った後に自らが作成した処理順の候補でバッチ処理した場合の待ち時間および総処理時間の予測値を、各ジョブの処理時間の実績値に基づき算出し、評価した。一方、処理順の候補をユーザが入力し、当該処理順でバッチ処理を行った場合の待ち時間および総処理時間の予測値を、処理順調整部４０が同様に算出するようにしてもよい。例えば、処理順調整部４０が処理順の調整を行ったが、途中で制約条件に違反して最終的な処理順の候補を絞りきれなかった場合に、ユーザに制約条件に違反する前までに得られた、暫定的な処理順の候補を提示するようにし、処理順候補の最終決定をユーザに行わせる。
【００７１】
このような場合に、ユーザが決定した処理順の候補で待ち時間はどのくらい発生するか、効率性が向上するか否かをシステムが評価する。こうすることにより、処理時間、各種制約条件などの中からユーザが求める優先順序に即した処理順候補を評価することができるとともに、システムが示す評価に基づき、より複雑な調整をユーザの手により行うことができる。結果として、ユーザの意志を一部反映させた調整を効率的に行うことができる。
【００７２】
また待ち時間判定部３６は、所定の場合においては、基準となるジョブの前に処理されるジョブのうち、最後に処理が終了したジョブ以外のジョブとの関係から待ち時間判定を行ってもよい。例えば、図８の「ジョブｂ」、「ジョブｃ」、「ジョブｄ」のように複数のジョブを並列に実行する場合、最後に処理が終了する「ジョブｄ」とその前に処理が終了する「ジョブｃ」の終了時刻に差がない場合でも、その直前に処理が終了する「ジョブｂ」と「ジョブｃ」の終了時刻の差がしきい値を超えていれば待ち時間が発生していると判定する。この場合、「ジョブｃ」、「ジョブｄ」の双方が「ジョブｅ」の前提ジョブでなければ、「ジョブｃ」、「ジョブｄ」と「ジョブｅ」の前後関係をまとめて解消することができる。このように、基準となるジョブの前に複数のジョブが並列処理されている場合などは、最後に処理が終了したジョブ以外のジョブとの関係から待ち時間を判定し、前後関係の解消を複数のジョブに対しまとめて行うようにしてもよい。
【図面の簡単な説明】
【００７３】
【図１】本実施の形態を適用できるシステムの構成例を示す図である。
【図２】ジョブ処理システムでバッチ処理されるジョブの処理順の例を模式的に示す図である。
【図３】本実施の形態におけるサーバの構成をより詳細に示す図である。
【図４】本実施の形態において登録されるジョブフローの一例を示す図である。
【図５】本実施の形態においてジョブ登録部が作成する利用リソース情報のデータ構造例を示す図である。
【図６】本実施の形態においてジョブ処理システムが行うジョブ処理の順序の調整に係る処理の手順を示すフローチャートである。
【図７】図６のＳ１４において処理順調整部が制約条件判定部の判定に基づき新たな処理順候補を作成する処理手順を示すフローチャートである。
【図８】本実施の形態において作成されるジョブの処理順候補の具体例を示す図である。
【符号の説明】
【００７４】
１  ジョブ処理システム、１２  第１サーバ、  １３  ハードディスク、  １４  第２サーバ、  ２０  データベース、  ３２  ジョブ登録部、  ３４  ジョブ処理部、  ３６  待ち時間判定部、  ３８  制約条件判定部、  ４０  処理順調整部、  ４２  出力部、  ４４  ジョブ情報記憶部、  ４６  実行状況記憶部、  １００  利用リソース情報テーブル。
【図１】
0005111186.tif 000002
【図２】
0005111186.tif 000003
【図３】
0005111186.tif 000004
【図４】
0005111186.tif 000005
【図５】
0005111186.tif 000006
【図６】
0005111186.tif 000007
【図７】
0005111186.tif 000008
【図８】
0005111186.tif 000009