(57)【要約】【課題】最小限のデータ量で日付／時間の管理を行い、又、これを実現する方法として、「日付／運用開始時間／運用終了時間／識別情報フラグ」で１レコードを表現し、所定の日数レコードで日付データを表現させることである。【解決手段】日付を基にしたシステムの稼動スケジュールの管理を行う際に、所定の日数レコードとそれに基づくデータで管理を行うように構成し、現在日付に該当するデータを先頭レコードとして、残りのレコードで、次の所定の日数レコード分を表現する。又、１日分のデータに所定の時間の管理を可能にさせることにより、１日以上のデータを１日分のデータで表現可能にするようにし、日付・時間情報とは別に、データに識別情報を持たせることで、時間以外にも稼動制御を行う。【選択図】図１１
2006221328.tif 000002
【特許請求の範囲】
【請求項１】
日付を基にしたシステムの稼動スケジュールの管理を行う際に、所定の日数レコードとそれに基づくデータで管理を行うことを特徴とする情報処理方法。
【請求項２】
現在日付に該当するデータを先頭レコードとして、残りのレコードで、次の所定の日数レコード分を表現することを特徴とする請求項１記載の情報処理方法。
【請求項３】
１日分のデータに所定の時間の管理を可能にさせることにより、１日以上のデータを１日分のデータで表現可能にすることを特徴とする請求項１記載の情報処理方法。
【請求項４】
日付・時間情報とは別に、データに識別情報を持たせることで、時間以外にも稼動制御を行うことを特徴とする請求項１記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スケジュール管理、システム稼動管理・制御、少量データ等の情報を処理する方法に関する。
【背景技術】
【０００２】
従来、システムの稼動スケジュールの管理を行う際には、各システム毎に年月日とシステム稼動時間を管理するデータベースを持ち、概データベースを使ってシステムの稼動スケジュールの稼動管理する方法が採られてきた。
【０００３】
又、この方法では、多くのレコードを管理する必要があった。例えば、１年間分の日付レコードを管理するには、３６５日分のデータ（うるう年は３６６日）のデータを管理する必要がある。これらのデータを数年分管理するためには、更に多くのデータを管理する必要がある。
【０００４】
又、単純に保持するデータを少なくする方法では、運用者がデータのメンテナンスを頻繁に行う必要があり、非常に負荷のかかる作業であった。又、曜日という単位でスケジュールを組む方法においては、例えば、土曜日、日曜日が運用時間外であるという設定をしておいた場合、特定の週の土曜日は運用時間内としたい等といった要求に応えるのが難しい。又、これに答えるためには、データのメンテナンスが発生すると考えられることから、局所的な要件にしか耐えられない考えとなってしまっていた。更には、特許文献１で示される方法では、例えば月末には翌月のスケジュールが決まっていても、翌月までデータベースに登録することができないという問題もあった。
【０００５】
又、バッチ処理とスケジュール管理を連動させる方法において、特許文献２で示されるような問題があるが、特許文献２の方法では、バッチの処理時間を事前に予測しておかなければ難しいし、非常に複雑である。又、確実にバッチ処理が終わるまで運用開始をすることができない場合が多かった。この運用開始のタイミングを設定するのが困難であった。
【０００６】
更に、特許文献３の「ジョブ運用スケジュール変更方法」では、ジョブの実行可能時間を定義するための方法を提示しているが、昨今のアプリケーションにおいては、日中はオンライン処理、夜間はバッチ処理など絶えず何らかの処理が動いているため、この方法では、オンラインとバッチ等に代表される複数の同時に動作してはならない処理の割り振りができない。又、ジョブの実行可能時間範囲を越えて処理時間が掛かってしまった場合、対応できない。更に、日付を年月日で捉えているため、データ量が多くなってしまうことが避けられない。
【０００７】
【特許文献１】特開平０６−１１９３４３号公報
【特許文献２】特開平０８−１０８０６３号公報
【特許文献３】特開２０００−２９５５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、上記問題に鑑みてなされたもので、その目的とする処は、最小限のデータ量で日付／時間の管理を行い、又、これを実現する方法として、「日付/運用開始時間／運用終了時間/識別情報フラグ」で１レコードを表現し、所定の日数レコードで日付データを表現させることである。
【課題を解決するための手段】
【０００９】
１．日付を基にしたシステムの稼動スケジュールの管理を行う際に、序数を持ち、該序数で検索可能である所定の日数レコードの日付データとそれに基ずくデータで管理を行う。
【００１０】
２．１の方法において、該所定の日数レコードの序数と現在日付を対応づける判定方法を持ち、現在の日付に該当するデータを先頭レコードとして、それ以降の序数の日付レコードを現在以降の日付に対応させ、且つ、それ以前の序数の日付レコードを更にそれ以降の日付に対応させることで、次の所定の日数分の稼動スケジュールを表現する。
【００１１】
３．１及び２の方法において、１日分に該当する日付データに一日を超える場合を含む所定の時間の管理を可能にさせることにより、所定の時間から導き出せる、Ｎ日間に渡るデータを１日で表現可能にすることで、Ｎ日間に渡って連続する稼動スケジュールをも管理することを可能とさせる (その際には、前Ｎ−１日分のデータを判定用に利用する)。
【００１２】
４．１の方法において、日付・時間情報とは別に、データに識別情報を持たせることで、時間以外にも稼動制御を行う。
【発明の効果】
【００１３】
日付データを基に、スケジュール管理を行う必要のあるシステムにおいて、従来と比較してデータベース等の記憶媒体に保存するデータの量を減少させることができる。又、それに伴って、スケジュール管理のためのデータベースの管理負荷を減少させることが可能である。
【００１４】
同じデータ内に識別情報フラグを持たせることで、時間によるスケジュール管理とは別
の部分での、例えば、バッチ処理の管理等も可能である。
【００１５】
従来は１日が２４時間という考え方しかできなかったものが、本発明により、それ以上の時間を（例では４８時間）１日のデータとして管理することが可能になる。
【発明を実施するための最良の形態】
【００１６】
以下に本発明の情報処理方法について図面を参照しつつ説明する。尚、本実施の形態では、日付、運用開始時間、運用終了時間、識別情報（バッチフラグ）を用いてスケジュール管理を行う手法を説明するのに好適な一例であり、本発明を全て説明するものではない。
【００１７】
ここでは、実施例１において、所定の日数レコードを３１、運用時間幅を２４時間とする場合を、実施例２において、所定の日数レコードを３１、運用時間幅を４８時間とする場合を説明する。
【実施例１】
【００１８】
例えば、所定の日数レコードとして３１日を保持する場合を例に説明する。この日付レコードは、序数１〜３１で検索可能である。システムはシステム日付「２００２／１２／９」を取得し、該日数「９」で日付データの序数を検索し、序数「９」のレコードを取得する。取得した日付レコードにより、システム日付における本日の稼動スケジュールを実施する（図１）。
【００１９】
このとき、検索された日付レコードより序数が大きい日付レコードは、本日以降の稼動スケジュールとして判定され、検索された日付レコードより序数が小さい日付レコードは、序数３１より以降、即ち、次月の稼動スケジュールとして判定される。例えば、序数１０の日付レコードは２００２／１２／１０の稼動スケジュールを表し、序数１の日付レコードは２００３／１／１の稼動スケジュールを表す、といった具合である（図２）。
【００２０】
システム日付が進むと、検索の結果取得できる日付レコードの序数も進むが、このとき、以前の序数は次月の最後の稼動スケジュールを表すように判定される。これにより、常に向こう１ヶ月の稼動スケジュールを管理することができるようになる（図３）。
【００２１】
もし、当月に２９〜３１日の何れかが存在しない場合は、システム日付によってその判定を行い、該当する序数の稼動スケジュールを読み飛ばす。システムがシステム日付「２００３／２／９」を取得した場合、当月には２９〜３１日は存在しないので、向こう１ヶ月の稼動スケジュールを判定する際に存在しない、「２００３／２／２９〜２００３／２／３１」に対応する序数２８〜３１の日付レコードを読み飛ばして判定する（図４）。
【実施例２】
【００２２】
本実施例では、日付、運用開始時間、運用終了時間、識別情報（バッチフラグ）を用いてスケジュール管理を行う手法を説明する。この例では、所定の日数レコードを３１とし、１レコード（１日）で表現できる最大時間を４８時間としている。
【００２３】
運用時間の表示方法は００００００（ＨＨＭＭＳＳ）〜４８００００（ＨＨＭＭＳＳ）とする。これは、最大２日間に渡る処理を１日分のレコードで定義可能であることを示している(図５、図６、図７)。月末月初に関しても、図にあるような処理を行い最大２日にわたる処理を実現する。
【００２４】
図及び内容の詳細を以下に示す。
【００２５】
１レコードを日付(日のみ)、運用開始時間、運用終了時間、バッチフラグとする。これを日付分（３１レコード）持つこととする。ここで、日付は０１〜３１とし、運用開始時間/運用終了時間は、ＨＨＭＭＳＳ（ＨＨ：００〜４８、ＭＭ：００〜５９（ＨＨ＜４８、ＨＨ＝４８の場合は００のみ）、ＳＳ：００〜５９（ＨＨ＜４８、ＨＨ＝４８の場合は００のみ））、バッチフラグはＴｒｕｅ／Ｆａｌｓｅとする。この条件の下で、以下のルールに従い、運用時間管理機能を有する。
【００２６】
尚、この運用時間管理機能とは、現在時刻において、アプリケーションの運用時間内かどうかを判定するものである。３１レコードの運用時間管理テーブルの例として図８を示す。
「運用可能状態取得処理フロー」
１．現在の日付時刻（ＤＤＨＨＭＭＳＳ：２４時間表示）と昨日の日付（ＤＤ）をサーバより取得する。
【００２７】
２．１で取得されたローカルの日付をキーに運用時間管理データベースから、運用開始時間／運用終了時間、バッチフラグを取得する。
【００２８】
３．バッチ処理とオンライン処理は同時に動作しないルールに基づき、２で得られたバッチフラグがＴｒｕｅであれば、バッチ処理実行中であるという判断をして、現在は運用時間外であるという判定を行い、終了する。Ｆａｌｓｅであれば、４へ進む。
【００２９】
４．１で得られたローカルの時刻が、２で得られた運用開始時間と運用終了時間との間にあるかの判定を行う。間にあれば、運用時間内であるという判定を行い、終了する。間になければ、５に進む。
【００３０】
５．現在のローカル日付−１の運用開始時刻、運用終了時刻をカレンダーＤＢから取得する。
【００３１】
６．５で得られたデータで運用終了時刻が２４００００よりも大きいデータであれば、２４００００＝１日という計算をして、１で得られた現在のローカル日付・時刻が運用時間内かどうかを判定する。運用時間内であれば、運用時間内であるという判定をして、ここで終了する。この判定の中で運用時間内であるという判定がない場合は、７に進む。
【００３２】
７．運用時間外であるという判定を行う。
【００３３】
又、該当月が３１に満たない月、例えば、その月が２８までしかないような場合は、２９〜３１までのレコードを無視して考えるような仕組みとする。
【００３４】
運用時間を設定するためのサーバの構成を図９に、運用可能かどうかの状態の取得のためのサーバの構成を図１０に示す。又、上記に対するフローチャートを図１１に示す。
【００３５】
尚、上記処理フローの１で表現される現在の日付時刻と昨日の日付の取得は、サーバの持つカレンダーより取得するものとする。
【図面の簡単な説明】
【００３６】
【図１】実施例１において、システム日付における本日の稼動スケジュールを示す図である。
【図２】実施例１において、序数１の日付レコードは２００３／１／１の稼動スケジュールを表すことを示す図である。
【図３】実施例１において、以前の序数は次月の最後の稼動スケジュールを表すように判定されることを示す図である。
【図４】実施例１において、向こう１ヶ月の稼動スケジュールを判定する際に存在しない、「２００３／２／２９〜２００３／２／３１」に対応する序数２８〜３１の日付レコードを読み飛ばして判定することを示す図である。
【図５】実施例２において、最大２日間にわたる処理を１日分のレコードで定義可能であることを示す図である。
【図６】実施例２において、最大２日間にわたる処理を１日分のレコードで定義可能であることを示す図である。
【図７】実施例２において、最大２日間にわたる処理を１日分のレコードで定義可能であることを示す図である。
【図８】実施例２において、３１レコードの運用時間管理テーブルの例を示す図である。
【図９】運用時間を設定するためのサーバの構成を示す図である。
【図１０】運用可能かどうかの状態の取得のためのサーバの構成を示す図である。
【図１１】実施例２で示した、運用可能状態取得処理のフローチャートである。
【図１】
2006221328.tif 000003
【図２】
2006221328.tif 000004
【図３】
2006221328.tif 000005
【図４】
2006221328.tif 000006
【図５】
2006221328.tif 000007
【図６】
2006221328.tif 000008
【図７】
2006221328.tif 000009
【図８】
2006221328.tif 000010
【図９】
2006221328.tif 000011
【図１０】
2006221328.tif 000012
【図１１】
2006221328.tif 000013