JP4141921B2 - ファイル処理方法 - Google Patents

Description

本発明は、クラスタ・システムにおけるファイル処理方法に関するものである。

現用系の処理装置と待機系の処理装置と各処理装置のローカルディスクとで構成されるクラスタ・システムにおける処理では、通常、現用系の処理装置で生成されたファイル（例えばトレースログ等）は、現用系のローカルディスクに格納される。一般的にトレースログのデータは、ファイル・サイズがある程度以上になると消去される。従って、例えば取引等の処理の増大に伴ってトレースログのファイル・サイズが急激に増えるような場合には、トラブル発生時の情報等、必要なデータが短期間で消されてしまう可能性がある。

そのため、トレースログのデータが一杯になったときにＭＯ（Magneto-Optical）ディスクにデータを移して保管するための技術が存在する（例えば特許文献１参照）。すなわち、検査機の動作状況をトレースデータとしてトレースバッファメモリに逐次に記憶し、記憶したトレースデータが満杯になると、それを主制御部のハードディスク装置に移して保存し、そのハードディスク装置内のトレースデータ群を一日の業務の終了ごとに集中制御卓のＭＯドライブでＭＯディスクに移して保管する。
特開平１０−２４０９９９号公報

しかしながら、上記の従来技術に従って例えばクラスタ・システムにおける現用系の処理装置がトレースログのバックアップ処理を行うような場合には、本来行うべき業務処理以外の負荷がかかってしまい、中継装置等、取引性能（応答時間）を求められるシステムにおいては好ましくない。一方、待機系の処理装置に共有ディスクに格納されたトレースログのバックアップ処理を行わせることも考えられるが、そのためには現用系の処理装置とのファイルへの同時アクセスを回避する必要がある。そこで、現用系及び待機系の処理装置間で同期をとるための通信処理を行うと、その通信処理は現用系の処理装置に余分な負荷を与えることになってしまう。

そのため、本発明の目的は、現用系及び待機系の処理装置間での通信を行うことなく、待機系の処理装置が、現用系の処理装置によって生成されたファイルを処理できるようにするための新規な技術を提供することである。

本発明の第１の態様に係るファイル処理方法は、現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける待機系の処理装置により実行されるファイル処理方法であって、現用系の処理装置により生成され且つ共有ディスクに格納されているファイルから、制御情報格納部に格納されている制御情報に基づき、処理対象となるファイルを特定するファイル特定ステップと、共有ディスク内の特定されたファイルに対して所定の処理を実施するファイル処理ステップとを含む。

これにより、待機系の処理装置は、現用系の処理装置との通信を行うことなく、すなわち現用系の処理装置に何ら負荷をかけることなく、処理対象となるファイルを特定することができ、例えば圧縮や転送等のファイル・バックアップ処理を行うことができる。

また、共有ディスクの所定の領域に格納されているファイルのファイル名が、世代管理を可能とするネーミング・ルールに従って設定されている場合、上記ファイル特定ステップにおいて、共有ディスクの所定の領域に格納されているファイルのファイル名から特定される世代に基づき、処理対象となるファイルを特定するようにしてもよい。

これにより、待機系の処理装置は、ファイル名から世代を特定し、自己が処理すべきファイルかどうか判断することができる。例えばシステム内に待機系の処理装置が複数存在するような場合、各待機系の処理装置が自己に振り分けられた処理のみ実行するような設定が可能となる。

また、上記制御情報は、待機系の処理装置が処理すべきファイルの世代を示すデータを含み、ファイル特定ステップにおいて、上記データが示す世代以降のファイルを、処理対象として特定するようにしてもよい。

これにより、待機系の処理装置は、複数世代に渡ってファイルを処理することができるようになる。例えばシステム内に待機系の処理装置が複数存在し、ファイルの世代によって処理の振り分けがなされているような場合、待機系の処理装置のいずれかが障害等により処理を行わなかったとしても、他の待機系の処理装置がまとめて処理するような設定が可能となる。

本発明の第２の態様に係るファイル処理方法は、現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける現用系の処理装置により実行されるファイル処理方法であって、生成したファイルに対して、待機系の処理装置における処理対象とするための所定のネーミング・ルールに従ったファイル名を決定するファイル名決定ステップと、生成したファイルを、決定したファイル名で共有ディスクの所定の領域に格納するファイル格納ステップとを含む。

このように、現用系の処理装置は、自己が生成・管理していたファイルの名前を変更（以下、リネームと呼ぶ）するだけで、待機系の処理装置に当該ファイルの処理を引き渡すことができる。すなわち、例えばファイルの圧縮や転送の際には、現用系の処理装置には負荷が全くかからないようになる。

また、所定の条件を満たした場合、共有ディスクの所定の領域に格納されているファイルのファイル名を設定しなおすリネーム処理ステップをさらに含むようにしてもよい。これにより、例えばシステム内に待機系の処理装置が複数存在する場合、現用系の処理装置による、各待機系の処理装置に対する処理の振り分けが可能となる。

なお、本発明に係る方法を実施するためのプログラムを生成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。

本発明によると、現用系及び待機系の処理装置間での通信を行うことなく、待機系の処理装置が、現用系の処理装置によって生成されたファイルを処理することができ、効率の良いファイル・バックアップ処理を行うことができる。

本発明の一実施の形態に係るシステム構成図を図１に示す。例えば社内ネットワークである社内ＬＡＮ１には、所定の業務処理を行う１又は複数の現用系処理装置５と、現用系処理装置５の１つに対して１又は複数存在する待機系処理装置３と、例えば本実施の形態とはあまり関連のない処理を行う１又は複数の他システム９とが接続されている。また、現用系処理装置５と待機系処理装置３とには、各々からアクセス可能な共有ディスク７が接続されている。

現用系処理装置５には、トレースログ書き込み処理部５１０とトレースログ・リネーム処理部５２０とトレースログ削除処理部５３０と制御テーブル格納部５４０とが含まれている。これら各処理部の処理内容及び制御テーブル格納部５４０に格納されるテーブルについては後に詳述するが、この他にも現用系処理装置５には、図示しない所定の業務処理を行うための処理部が含まれている。

待機系処理装置３には、トレースログ監視処理部３１０とトレースログ圧縮処理部３２０とトレースログ削除処理部３３０と制御部３４０と制御テーブル格納部３５０とトレースログ転送処理部３６０とが含まれている。これら各処理部の処理内容及び制御テーブル格納部３５０に格納されるテーブルについては後に詳述するが、この他にも待機系処理装置３には、図示しない所定の業務処理を行うための処理部が含まれている。現用系に切り替わった場合に処理を実行するためである。

また、現用系処理装置５及び待機系処理装置３は、互いに切り替わって処理ができるように、同様の機能及びデータを有している。すなわち、実際には、各機能部はいずれの処理装置にも含まれている。但し、現用系と待機系との切り替えについては本実施の形態の要旨ではないため、切り替え後の処理を行うための機能部については図示していない。

なお、他システム９と待機系処理装置３とは、社内ＬＡＮ１を介して通信が可能となっており、待機系処理装置３のトレースログ転送処理部３６０の機能により、他システム９に対してトレースログのデータを送信することができる。他システム９は、受信したトレースログのデータを用いて障害の分析処理を実行したり、バックアップとしてデータを所定の記憶装置に格納する等の処理を行う。

図２に、共有ディスク７に格納されるファイルの概要図を示す。図２には、現用系処理装置５が処理の対象とするファイル群が実線で囲まれ、現用系処理対象ファイル７０１として示されている。また、待機系処理装置３が処理の対象とするファイル群が点線で囲まれ、待機系処理対象ファイル７０２として示されている。

現用系処理対象ファイル７０１には、トレースログ・ファイル７１０と、リネーム済みファイル第１世代７１１と、リネーム済みファイル第２世代７１２と、・・・、リネーム済みファイル第５世代７１５と、現用系削除済みファイル７１９とが含まれ得る。トレースログ・ファイル７１０には、現用系処理装置５が業務処理を行った際のトレースログが記録される。実際には現用系処理装置５のトレースログ書き込み処理部５１０が記録処理を行うが、各機能部の具体的な機能については処理フローの説明において述べるため、以下の説明では処理主体の明示を割愛する。なお、現用系削除済みファイル７１９は削除されたファイルを示しているので実際には存在しない。

待機系処理対象ファイル７０２には、リネーム済みファイル第１世代７１１と、リネーム済みファイル第２世代７１２と、・・・、リネーム済みファイル第５世代７１５と、圧縮済みファイル第１世代７２１と、圧縮済みファイル第２世代７２２と、・・・、圧縮済みファイル第５世代７２５と待機系削除済みファイル７２９とが含まれ得る。なお、待機系削除済みファイル７２９は削除されたファイルを示しているので実際には存在しない。

リネーム済みファイル第１世代７１１とリネーム済みファイル第２世代７１２と、・・・、リネーム済みファイル第５世代７１５とは、現用系処理対象ファイル７０１及び待機系処理対象ファイル７０２に共通に含まれている。すなわち、これらのファイルは、現用系処理装置５によって生成され、待機系処理装置３によって所定の処理が施される。

図２に示されている各ファイルの詳細については後に説明するが、ここでは各ファイルの関係について簡単に述べておく。まず、現用系処理装置５によって生成されたトレースログ・ファイル７１０は、所定のファイル・サイズになるとリネームされ、リネーム済みファイル第１世代７１１となる。リネーム済みファイル第１世代７１１は、待機系処理装置３によって例えば圧縮処理が施されると、圧縮済みファイル第１世代７２１となる。待機系処理装置３が処理を実施しなかった場合、リネーム済みファイル第１世代７１１はそのまま共有ディスク７に残る。

なお、トレースログ・ファイル７１０には随時データが記録され続けており、再びトレースログ・ファイル７１０が所定のファイル・サイズになるとリネームされ、リネーム済みファイル第１世代７１１となる。この際、既にリネーム済みファイル第１世代７１１が存在している場合、そのファイルはリネームされ、リネーム済みファイル第２世代７１２となる。世代は通常、数が大きくなると新しくなるが、本実施の形態においては、このように古いファイルほど数を大きくしている。昇順に世代を設定していくようにしてもよい。

各世代のリネーム済みファイルは、待機系処理装置３によって例えば圧縮処理が施されると、当該世代の圧縮済みファイルとなる。例えば、リネーム済みファイル第２世代７１２は、待機系処理装置３によって圧縮処理が施されることにより、圧縮済みファイル第２世代７２２となる。待機系処理装置３が処理を実施しなかった場合、リネーム済みファイル第２世代７１２はそのまま共有ディスク７に残る。新しいリネーム済みファイル第１世代７１１も同様である。なお、以下の処理フローでは、圧縮済みファイルについては、例えば第１世代がないのに第２世代が生成されるようなこともあり、最古世代の削除処理に用いる以外には、世代としての管理は行っていない。

図３及び図４に、現用系処理装置５の制御テーブル格納部５４０と待機系処理装置３の制御テーブル格納部３５０とに格納されているテーブルの構成及びテーブルに格納されるデータの一例を示す。図３に示す現用系制御テーブルの一例には、トレースログ・ファイル格納ディレクトリ名の行３７０とトレースログ・ファイル名の行３７２とトレースログ・ファイル上限サイズの行３７４とリネーム・ファイル拡張子書式の行３７６とリネーム・ファイル世代数の行３７８とリネーム付加情報の行３８０とリネーム済みファイル格納ディレクトリ名の行３８２と開始拡張子の行３８４と最古拡張子の行３８６とディスク・クォータ・チェックの行３８８とディスク・クォータ残割合の行３９０とが含まれている。そして各行の第２列（設定値の列）に設定された値が格納されている。

トレースログ・ファイル格納ディレクトリ名の行３７０には、共有ディスク７内の所定のディレクトリを示すデータが格納されている。現用系処理装置５は、生成したトレースログ・ファイルをこのディレクトリに格納する。トレースログ・ファイル名の行３７２には、トレースログに付けるファイル名を示すデータが格納されている。現用系処理装置５は、このファイル名でトレースログ・ファイルを生成し、トレースログ・ファイル格納ディレクトリ名の行３７０に示されたディレクトリに格納する。

トレースログ・ファイル上限サイズの行３７４には、トレースログ・ファイルのサイズがこの値以上になったら、ファイル名を変えるという上限の数値が格納されている。図３の例では、例えば１メガ・バイト以上になったらトレースログのファイル名を変え、新しいファイルにトレースログを格納していくという設定がなされている。

リネーム・ファイル拡張子書式の行３７６には、ファイル名を変える場合に従うべき拡張子の書式を示す値が格納されている。図３の例では「000」という値が格納されているが、この場合、現用系処理装置５は、リネームの際、ファイルの拡張子を三桁の数値で昇順に設定していく。例えば、図２に示したリネーム済みファイル第１世代７１１の拡張子を「000」、リネーム済みファイル第２世代７１２の拡張子を「001」というように設定していく。なお、降順に設定するようにしてもよい。

リネーム・ファイル世代数の行３７８には、同時に存在し得る、本制御テーブルに従ってリネームされたトレースログ・ファイルの最大数、すなわち、最大の世代数が格納されている。図３の例では「１０」と示されているが、この場合、１０世代までは共有ディスク７の以下で述べる所定のディレクトリにファイルを格納しておくことを意味している。例えば拡張子が「000」から「009」までのファイルを格納しておき、次のトレースログのリネームをする時は、最古の世代である「009」の拡張子を持つファイルを削除する。

リネーム付加情報の行３８０には、トレースログをリネームする（第１世代のファイルにする）際にファイル名に含める情報が登録されている。図３の例では「YYYYMMDDHHMMSS」と示されているが、この場合、ファイル名には年月日時分秒が含まれるということを示している。例えば、２００３年７月７日の７時７分７秒にトレースログのファイル名（図３の例では「Trace.log」）を変更する場合には「Trace20030707070707.000」というファイル名に変更する。このファイルは拡張子が「000」であり、図２のリネーム済みファイル第１世代７１１にあたる。なお、このファイルがリネーム済みファイル第２世代７１２（図２）になる際には再びリネームされるが、例えば「Trace20030707070707.001」というように拡張子が変更されるだけで、リネーム付加情報である年月日時分秒の部分は変更されない。

リネーム済みファイル格納ディレクトリ名の行３８２には、共有ディスク７内の所定のディレクトリを示すデータが格納されている。現用系処理装置５は、１回又は複数回リネームしたトレースログ・ファイル（図２のリネーム済みファイル第１世代７１１、リネーム済みファイル第２世代７１２、リネーム済みファイル第５世代７１５等）をこのディレクトリに格納する。

開始拡張子の行３８４には、トレースログをリネームする（第１世代のファイルにする）際に設定する最初の拡張子が登録される。図３の例では初期値の「000」と登録されているため、現用系処理装置５は、ファイルの拡張子を上で述べたように「000」（第１世代）、「001」（第２世代）、「002」（第３世代）と変更していく。開始拡張子の行３８４に例えば「004」と登録されている場合には、現用系処理装置５は、ファイルの拡張子を「004」（第１世代）、「005」（第２世代）、「006」（第３世代）と変更していく。

最古拡張子の行３８６には、リネーム済みファイル格納ディレクトリ名の行３８２に示されているディレクトリに格納されているファイルのうち、最も古い世代のファイルの拡張子が登録される。図３の例では初期値の「000」が登録されている。

なお、この現用系制御テーブルの各行のうち、開始拡張子の行３８４と最古拡張子の行３８６とについては、処理中に値が更新される場合がある。

また、共有ディスク７の空き領域のチェックを行うような設定である場合には、ディスク・クォータ・チェックの行３８８に「Yes」と設定され、ディスク・クォータ残割合の行３９０に、例えば「２０％」等の基準割合が格納される。このような設定がなされている場合には、共有ディスク７の容量の残りが例えば２０％以下になると、現用系処理装置５は、最古世代のトレースログ・ファイルを削除する。

図４に示す待機系制御テーブルの一例には、リネーム済みファイル格納ディレクトリ名の行４００と処理対象ファイル拡張子固定の行４０２と処理対象ファイル拡張子（最上位）の行４０４と監視間隔の行４０６と標準監視間隔の行４０８と最小監視間隔の行４１０と最大監視間隔の行４１２と監視間隔増減割合の行４１４と圧縮方式の行４１６と圧縮ファイル格納ディレクトリ名の行４１８と転送先サーバの行４２０と転送方法の行４２２と転送先ディレクトリの行４２４と圧縮ファイルのトータル・サイズ上限の行４２６とディスク・クォータ・チェックの行４２８とディスク・クォータ残割合の行４３０とが含まれている。

リネーム済みファイル格納ディレクトリ名の行４００には、図３のリネーム済みファイル格納ディレクトリ名の行３８２と同じ値が格納されている。すなわち、現用系処理装置５によってリネームされ且つこのディレクトリに格納されたファイルを、待機系処理装置３が処理対象とする。

処理対象ファイル拡張子固定の行４０２には、待機系の処理装置が処理対象とするファイルの拡張子を固定とするかどうかを示す値が「Yes」又は「No」で登録されている。図４に示したように「Yes」の場合には、例えば待機系処理装置３は、特定の拡張子（世代）のファイルのみを処理対象とする。この設定により、待機系の処理装置が複数存在する場合、処理装置毎に処理対象とする拡張子（世代）を振り分けることができる。

また、処理対象ファイル拡張子（最上位）の行４０４には、当該待機系の処理装置、例えば待機系処理装置３が処理対象とするファイルの拡張子が登録されている。図４の例では「002」と登録されており、待機系処理装置３は拡張子が「002」のファイルに対して例えば圧縮等の処理を行う。なお、処理対象ファイル拡張子固定の行４０２に「No」が登録されている場合には、ここでの「002」という値は、処理対象のファイルの最上位の拡張子（世代）を示すものとなり、下位の拡張子である「001」又は「000」の拡張子を持つファイルも、待機系処理装置３の処理対象となる。

監視間隔の行４０６には、待機系の処理装置が、自己の処理対象となるファイルの存在をチェックする間隔が登録されている。初期値は標準監視間隔の行４０８の値と同じ例えば６０（秒）であり、後に述べる監視間隔設定処理により更新される。標準監視間隔の行４０８には、監視間隔の標準値が登録されている。また、最小監視間隔の行４１０には、監視間隔として設定可能な最小値が登録され、最大監視間隔の行４１２には、監視間隔として設定可能な最大値が登録されている。そして、監視間隔増減割合の行４１４には、監視間隔を長くしたり短くしたりする際の割合が登録されている。

圧縮方式の行４１６には、圧縮処理後のファイルの拡張子が登録されている。すなわち、圧縮されたファイルがこのような拡張子となるような圧縮方法を用いてファイルの圧縮処理を行うということが規定されている。また、圧縮ファイル格納ディレクトリ名の行４１８には、圧縮したファイルを格納しておくディレクトリが登録されている。

また、待機系の処理装置が、処理対象となるファイルを他システム９等に送信するような場合には、転送先サーバの行４２０と転送方法の行４２２と転送先ディレクトリの行４２４とに値が格納される。

圧縮ファイルのトータル・サイズ上限の行４２６には、圧縮処理されたファイルの合計サイズがこの値以上になったら、最古世代の圧縮済みファイルを削除するという上限の数値が格納されている。ディスク・クォータ・チェックの行４２８とディスク・クォータ残割合の行４３０とについては、図３のディスク・クォータ・チェックの行３８８及びディスク・クォータ残割合の行３９０と同様の設定がなされる。但し、処理の主体（現用系又は待機系の処理装置）は異なっている。

以上、図３及び図４に示したような例えば２種類のテーブルが、現用系処理装置５の制御テーブル格納部５４０と待機系処理装置３の制御テーブル格納部３５０とにそれぞれ格納されている。現用系と待機系とが切り替わる場合もあるため、通常使用しないテーブルも保持しておくようになっている。

次に、図５乃至図１０−３を用いて、図１に示したシステムの処理内容について説明する。始めに、図５の処理フロー、及び図６−１乃至図６−６のディスク状態遷移図を用いて、現用系処理装置５の実施する処理について、処理の流れ、具体例の順に説明する。

まず、現用系処理装置５のトレースログ書き込み処理部５１０は、現用系制御テーブル（図３）のトレースログ・ファイル格納ディレクトリ名の行３７０及びトレースログ・ファイル名の行３７２の値に基づき、業務処理に伴うトレースログをファイルに書き込む（図５：ステップＳ１）。例えば共有ディスク７の「/apl/trace」というディレクトリにある「Trace.log」というファイルにデータを追加する。

そして、トレースログ書き込み処理部５１０は、現用系制御テーブル（図３）のトレースログ・ファイル上限サイズの行３７４の値に基づき、トレースログ・ファイルが、例えば１メガ・バイトである所定のサイズを超えたかどうか判定する（ステップＳ３）。超えていないと判定された場合（ステップＳ３：Ｎｏルート）、ステップＳ１の処理に戻る。

一方、トレースログ・ファイルが所定のサイズを超えたと判定された場合（ステップＳ３：Ｙｅｓルート）、トレースログ・リネーム処理部５２０は、現用系制御テーブル（図３）のリネーム・ファイル拡張子書式の行３７６及びリネーム・ファイル世代数の行３７８の値に基づき、又はディスク・クォータ・チェックの行３８８及びディスク・クォータ残割合の行３９０の値に基づき、リネーム済みファイルの世代オーバ、又はディスク・サイズ・オーバの状態であるか判定する（ステップＳ５）。

なお、ここでいうディスク・サイズとは、共有ディスク７において、現用系制御テーブル（図３）のディスク・クォータ残割合の行３９０の値に基づき算出されるディスク容量を空き容量として確保した後の、残りのディスク容量を指す。例えば、共有ディスク７の容量が１０ギガ・バイトであり、現用系制御テーブル（図３）のディスク・クォータ残割合の行３９０の値が１０（％）であったとすると、ディスク・サイズは９（10-10*0.1）ギガ・バイトとなる。すなわちこの場合、共有ディスク７内のデータ容量が９ギガ・バイトを超えた場合、ディスク・サイズ・オーバであると判定される。

世代又はディスク・サイズがオーバしていないと判定された場合（ステップＳ５：Ｎｏルート）、後に述べるステップＳ９の処理に移行する。一方、世代又はディスク・サイズがオーバしていると判定された場合（ステップＳ５：Ｙｅｓルート）、トレースログ削除処理部５３０は、リネーム済みファイルのうち、最古世代のものを削除する（ステップＳ７）。

そして、トレースログ・リネーム処理部５２０は、開始拡張子が「000」であるか判定する（ステップＳ９）。すなわち、現用系制御テーブル（図３）のリネーム開始拡張子の行３８４の値が初期値の「000」であるか判定する。開始拡張子が「000」ではないと判定された場合、後で述べるステップＳ１５の処理に移行する。この際、トレースログ・リネーム処理部５２０は、開始拡張子のデータを、図示しないワーク・メモリ領域等の記憶装置に一旦格納しておく。

一方、開始拡張子が「000」であると判定された場合、トレースログ・リネーム処理部５２０は、最古拡張子が「000」ではなく且つ最古世代ファイルが処理済みであるか判定する（ステップＳ１１）。すなわち、現用系制御テーブル（図３）の最古拡張子の行３８６及びリネーム済みファイル格納ディレクトリ名の行３８２の値を特定し、最古世代の拡張子が初期値の「000」ではなく、当該最古世代のファイルが、所定のディレクトリ（例えば「/apl/rename」）に格納されていない（すなわち、待機系の処理装置によって処理済み）状態となっているか確認する。

最古拡張子が「000」ではなく且つ最古世代ファイルが処理済みであると判定されなかった場合（ステップＳ１１：Ｎｏルート）、後で述べるステップＳ１５の処理に移行する。この際、トレースログ・リネーム処理部５２０は、開始拡張子のデータ（ここでは「000」）を、図示しないワーク・メモリ領域等の記憶装置に一旦格納しておく。

一方、最古拡張子が「000」ではなく且つ最古世代ファイルが処理済みであると判定された場合（ステップＳ１１：Ｙｅｓルート）、トレースログ・リネーム処理部５２０は、最古拡張子を開始拡張子に設定する（ステップＳ１３）。すなわち、現用系制御テーブル（図３）の最古拡張子の行３８６の値を開始拡張子の行３８４に登録する。この際、トレースログ・リネーム処理部５２０は、これまでの開始拡張子、すなわち更新前開始拡張子のデータを、図示しないワーク・メモリ領域等の記憶装置に一旦格納しておく。

以上のステップＳ９乃至ステップＳ１３の処理は、例えば複数の待機系の処理装置のうち、ある待機系の処理装置がファイル処理を行わなかったことを検出した場合、当該待機系の処理装置へのファイルの割り当て（当該待機系の処理装置が処理するトレースログ・ファイル名の生成）をスキップできるようにするための処理である。具体例は後に述べる。

そして、トレースログ・リネーム処理部５２０は、リネーム済みのファイルをリネームする（ステップＳ１５）。リネーム済みファイルのリネームは、拡張子の変更によって行う。新拡張子を求める式は、「（更新後の開始拡張子）＋（リネーム済みファイルの変更前拡張子）−（更新前の開始拡張子）＋１」で示される。更新前の開始拡張子には、図示しないワーク・メモリ領域等の記憶装置に一旦格納しておいたものを用いる。

例えば、リネーム済みファイルの変更前拡張子が「000」で、更新前及び更新後の開始拡張子がともに「000」であった場合、当該ファイルの新拡張子は「001」（000+000-000+1）となる。また例えば、リネーム済みファイルの変更前拡張子が「002」で、更新前の開始拡張子が「001」で、更新後の開始拡張子が「003」であった場合、当該ファイルの新拡張子は005（003+002-001+1）となる。なお、リネーム済みのファイルが所定のディレクトリ（例えば「/apl/rename」）に存在しなければ、この処理をスキップする。

リネーム処理の終了後、トレースログ・リネーム処理部５２０は、リネーム処理後の最古拡張子のデータ（拡張子の最大値）を現用系制御テーブル（図３）の最古拡張子の行３８６に登録する（ステップＳ１７）。ステップＳ１５の処理をスキップした場合には、同じ値で更新することになるため、この処理をスキップしてもよい。

そして、トレースログ・リネーム処理部５２０は、トレースログ・ファイル（Trace.log）をリネームし、所定のディレクトリ（例えば「/apl/rename」）に格納する（ステップＳ１９）。すなわち、現用系制御テーブル（図３）のリネーム付加情報の行３８０の値と開始拡張子の行３８４の値とリネーム済みファイル格納ディレクトリ名の行３８２の値とを用いて、トレースログ・ファイルのリネーム処理を行う。拡張子には、開始拡張子の行３８４の値をそのまま用いる。これにより、トレースログ・ファイルの退避ができたので、ステップＳ１の処理に移行し、新しいトレースログ・ファイルにデータを追加していく。

このようにして、現用系処理装置５によるトレースログ・ファイルの生成処理、削除処理及びリネーム処理が行われる。このように現用系処理装置５は通信を行う必要はなく、同期をとることもない。

以下、図６−１乃至図６−６のディスク状態遷移図を用いて具体例を説明する。なお、処理主体については上の処理フローの説明において明示しているため、以下の説明では割愛する。

まず、処理開始時点では、現用系制御テーブル（図３）には初期値が登録されている。なお、最大世代数、すなわちリネーム・ファイル世代数の行３７８の値は「５」に設定されており、また、ディスク・サイズのチェックは行わない、すなわちディスク・クォータ・チェックの行３８８の値は「Ｎｏ」に設定されているものとする。そして、現用系処理装置５による処理が開始されると、トレースログ・ファイルにデータが格納及び追加されていく。

図６−１のＳＴＥＰ１には、トレースログ格納ディレクトリ６１０とリネーム済みファイル格納ディレクトリ６１２とトレースログ・ファイル６１４とが含まれている。トレースログ・ファイル６１４の全体が縦線模様で示されているが、これは、トレースログ・ファイル６１４が一杯になった、すなわち、トレースログ・ファイル６１４のサイズが、現用系制御テーブル（図３）のトレースログ・ファイル上限サイズの行３７４の値に達したことを表している。

これを図５の処理フローに当てはめると、ステップＳ１を経由し、ステップＳ３の判定においてＹｅｓルートに進む。そして、ステップＳ５の判定においては、リネーム済みファイル格納ディレクトリ６１２にファイルが格納されていないので、Ｎｏルートに進む。ステップＳ９の判定においては、開始拡張子が未だ初期値の「000」であるため、Ｙｅｓルートに進む。

そして、ステップＳ１１の判定においては、最古拡張子が未だ初期値の「000」であるため、Ｎｏルートに進む。この際、ワーク・メモリ領域に更新前の開始拡張子である「000」を格納するが、リネーム済みのファイルがないため、次のステップＳ１５の処理をスキップするので、今回は使用しない。ステップＳ１７の処理においては、ステップＳ１５同様にスキップする又は同じ値「000」で更新する。

そして、ステップＳ１９の処理によって、トレースログ・ファイル６１４がリネームされ、図６−１のＳＴＥＰ２に示したような状態となる。図６−１のＳＴＥＰ２では、リネーム済みファイル６１６が含まれている。リネーム済みファイル６１６は、ＳＴＥＰ１のトレースログ・ファイル６１４のファイル名及び格納ディレクトリを変更したものである。例えば２００３年７月１日９時０分２０秒にリネーム処理されたファイルであり、開始拡張子は「000」であるため、新しいファイル名は「Trace20030701090020.000」と示されている。

トレースログ・ファイル６１４のリネーム処理が終了すると、図５の処理フローでは、再びステップＳ１の処理に移行する。すなわち、新しいトレースログ・ファイルにデータが書き込まれていく。そのような状態を図６−１のＳＴＥＰ３に示す。図６−１のＳＴＥＰ３には、トレースログ・ファイル６１８が含まれている。トレースログ・ファイル６１８の一部が縦線模様で示されているが、これは、トレースログ・ファイル６１８のサイズの上限（全体）に対して、縦線模様で示されている割合だけデータが格納されていることを表している。

この状態を図５の処理フローに当てはめると、ステップＳ１を経由し、ステップＳ３の判定においてＮｏルートに進む。そして、ステップＳ１において、トレースログ・ファイル６１８にさらにデータが追加される。このように、例えばステップＳ１及びステップＳ３が繰り返され、トレースログ・ファイル６１８が一杯になった状態を、図６−１のＳＴＥＰ４に示す。

図６−１のＳＴＥＰ４では、トレースログ・ファイル６１８の全体が縦線模様で示されており、トレースログ・ファイル６１８が一杯になったことが表されている。すなわち、図５の処理フローに当てはめると、ステップＳ３の判定において、Ｙｅｓルートに進む。そして、ステップＳ５の判定においては、リネーム済みファイル格納ディレクトリ６１２に格納されているファイルが１つ（１世代）だけなので、Ｎｏルートに進む。

ステップＳ９の判定においては、開始拡張子が未だ初期値の「000」であるため、Ｙｅｓルートに進む。そして、ステップＳ１１の判定においては、最古拡張子が未だ初期値の「000」であるため、Ｎｏルートに進む。この際、ワーク・メモリ領域に、更新前の開始拡張子として「000」を格納しておく。そして、ステップＳ１５におけるリネーム処理によって、リネーム済みファイル６１６をさらにリネームする。リネーム済みファイルのリネームは、拡張子の変更によって行われ、新しい拡張子は「（更新後の開始拡張子）＋（リネーム済みファイルの変更前拡張子）−（更新前の開始拡張子）＋１」となる。図６−１のＳＴＥＰ４の時点では、更新後の開始拡張子、リネーム済みファイル６１６の変更前拡張子及び更新前の拡張子はいずれも「000」であり、新しい拡張子は「001（000＋000-000+1）」となる。更新前の開始拡張子には、ワーク・メモリ領域に格納されているデータを用いる。

そして、ステップＳ１７の処理において、現用系制御テーブル（図３）の最古拡張子の行３８６の値を、リネーム済みファイルの拡張子の最大値である「001」に更新する。さらに、ステップＳ１９の処理によって、トレースログ・ファイル６１８がリネームされ、図６−２のＳＴＥＰ５に示したような状態となる。図６−２のＳＴＥＰ５には、リネーム済みファイル６２０とリネーム済みファイル６２２とが含まれている。リネーム済みファイル６２０は、ＳＴＥＰ４（図６−１）のトレースログ・ファイル６１８のファイル名及び格納ディレクトリを変更したものである。例えば２００３年７月２日１５時２５分３０秒にリネーム処理されたファイルであり、開始拡張子は「000」であるため、新しいファイル名は「Trace20030702152530.000」と示されている。リネーム済みファイル６２２は、ＳＴＥＰ４（図６−１）のリネーム済みファイル６１６の拡張子が変更されたものである。拡張子の変更（リネーム）処理の詳細については、上で述べた通りである。

トレースログ・ファイル６１８（図６−１のＳＴＥＰ４）のリネーム処理が終了すると、図５の処理フローでは、再びステップＳ１の処理に移行する。すなわち、新しいトレースログ・ファイルにデータが書き込まれていく。そのような状態を図６−２のＳＴＥＰ６に示す。図６−２のＳＴＥＰ６には、トレースログ・ファイル６２４が含まれている。トレースログ・ファイル６２４の状態は、図６−１のＳＴＥＰ３におけるトレースログ・ファイル６１８の状態と同様である。

この状態を図５の処理フローに当てはめると、ステップＳ１を経由し、ステップＳ３の判定においてＮｏルートに進む。そして、ステップＳ１において、トレースログ・ファイル６２４にデータが追加される。このように、例えばステップＳ１及びステップＳ３が繰り返され、トレースログ・ファイル６２４が一杯になった状態を、図６−２のＳＴＥＰ７に示す。

図６−２のＳＴＥＰ７では、トレースログ・ファイル６２４の全体が縦線模様で示されており、トレースログ・ファイル６２４が一杯になったことが表されている。すなわち、図５の処理フローに当てはめると、ステップＳ３の判定において、Ｙｅｓルートに進む。そして、ステップＳ５の判定においては、リネーム済みファイル格納ディレクトリ６１２に格納されているファイルが２つ（２世代）であり、最大世代数である５に満たないので、Ｎｏルートに進む。

ステップＳ９の判定においては、開始拡張子が未だ初期値の「000」であるため、Ｙｅｓルートに進む。そして、ステップＳ１１の判定においては、最古拡張子は「001」であり「000」ではないが、拡張子が「001」であるリネーム済みファイル６２２がリネーム済みファイル格納ディレクトリ６１２内に存在しており、待機系の処理装置による処理がなされていないと判定されるため、Ｎｏルートに進む。この際、ワーク・メモリ領域に開始拡張子の「000」を格納しておく。そして、ステップＳ１５におけるリネーム処理によって、リネーム済みファイル６２０及びリネーム済みファイル６２２を、さらにリネームする。リネーム済みファイルのリネーム方法については、上で述べた通りであり、リネーム済みファイル６２０の拡張子を「001（000＋000-000+1）」に、また、リネーム済みファイル６２２の拡張子を「002（000＋001-000+1）」に変更する。

そして、ステップＳ１７の処理において、現用系制御テーブル（図３）の最古拡張子の行３８６の値を、リネーム済みファイルの拡張子の最大値である「002」に更新する。さらに、ステップＳ１９の処理によって、トレースログ・ファイル６２４がリネームされ、図６−３のＳＴＥＰ８に示したような状態となる。図６−３のＳＴＥＰ８には、リネーム済みファイル６３０とリネーム済みファイル６３２とリネーム済みファイル６３４とが含まれている。リネーム済みファイル６３０は、ＳＴＥＰ７（図６−２）のトレースログ・ファイル６２４のファイル名及び格納ディレクトリを変更したものである。例えば２００３年７月４日１０時１２分４５秒にリネーム処理されたファイルであり、開始拡張子は「000」であるため、新しいファイル名は「Trace20030704101245.000」と示されている。リネーム済みファイル６３２は、ＳＴＥＰ７（図６−２）のリネーム済みファイル６２０の拡張子が変更されたものであり、リネーム済みファイル６３４は、ＳＴＥＰ７（図６−２）のリネーム済みファイル６２２の拡張子が変更されたものである。

トレースログ・ファイル６２４（図６−２のＳＴＥＰ７）のリネーム処理が終了すると、図５の処理フローでは、再びステップＳ１の処理に移行する。すなわち、新しいトレースログ・ファイルにデータが書き込まれていく。そして、例えばステップＳ１及びステップＳ３が繰り返され、新しいトレースログ・ファイルが一杯になった状態を、図６−３のＳＴＥＰ９に示す。

図６−３のＳＴＥＰ９には、トレースログ・ファイル６３６が含まれている。そして、トレースログ・ファイル６３６の全体が縦線模様で示されており、トレースログ・ファイル６３６が一杯になったことが表されている。すなわち、図５の処理フローに当てはめると、ステップＳ３の判定において、Ｙｅｓルートに進む。そして、ステップＳ５の判定においては、リネーム済みファイル格納ディレクトリ６１２に格納されているファイルが２つ（２世代）であり、最大世代数である５に満たないので、Ｎｏルートに進む。

ステップＳ９の判定においては、開始拡張子が未だ初期値の「000」であるため、Ｙｅｓルートに進む。そして、ステップＳ１１の判定においては、最古拡張子は「002」であり「000」ではなく、且つ拡張子が「002」であるリネーム済みファイル６３４（図６−３のＳＴＥＰ８）がリネーム済みファイル格納ディレクトリ６１２に存在しないため、待機系の処理装置による処理がなされたと判定され、Ｙｅｓルートに進む。そして、ステップＳ１３の処理において、最古拡張子である「002」を開始拡張子に設定する。すなわち、現用系制御テーブル（図３）の開始拡張子の行３８４に、最古拡張子の行３８６の値である「002」を登録する。この際、ワーク・メモリ領域に更新前の開始拡張子の「000」を格納しておく。

そして、ステップＳ１５におけるリネーム処理によって、リネーム済みファイル６３０及びリネーム済みファイル６３２を、さらにリネームする。リネーム済みファイルのリネーム方法については、上で述べた通りであり、リネーム済みファイル６３０の拡張子を「003（002＋000-000+1）」に、また、リネーム済みファイル６３２の拡張子を「004（002＋001-000+1）」に変更する。

そして、ステップＳ１７の処理において、現用系制御テーブル（図３）の最古拡張子の行３８６の値を、リネーム済みファイルの拡張子の最大値である「004」に更新する。さらに、ステップＳ１９の処理によって、トレースログ・ファイル６３６がリネームされ、図６−４のＳＴＥＰ１０に示したような状態となる。図６−４のＳＴＥＰ１０には、リネーム済みファイル６４０とリネーム済みファイル６４２とリネーム済みファイル６４４とが含まれている。リネーム済みファイル６４０は、ＳＴＥＰ９（図６−３）のトレースログ・ファイル６３６のファイル名及び格納ディレクトリを変更したものである。例えば２００３年７月５日１５時２２分３０秒にリネーム処理されたファイルであり、開始拡張子は「002」であるため、新しいファイル名は「Trace20030705152230.002」と示されている。リネーム済みファイル６４２は、ＳＴＥＰ９（図６−３）のリネーム済みファイル６３０の拡張子が変更されたものであり、リネーム済みファイル６４４は、ＳＴＥＰ９（図６−３）のリネーム済みファイル６３２の拡張子が変更されたものである。

このように、待機系の処理装置によって処理されなかったファイルの拡張子をスキップしてリネームすることにより、効率的な処理が実現できる。例えば上の例のように、拡張子が「002」になって初めてファイルが処理されるような場合には、「000」及び「001」であるファイルの処理を行うはずであった待機系の処理装置に不具合が生じている可能性もあるため、トレースログ・ファイルを始めから「002」という拡張子を用いてリネームすることにより、無駄な処理を省略することができる。

そして、トレースログ・ファイル６３６（図６−３のＳＴＥＰ９）のリネーム処理が終了すると、図５の処理フローでは、再びステップＳ１の処理に移行する。すなわち、新しいトレースログ・ファイルにデータが書き込まれていく。そして、例えばステップＳ１及びステップＳ３が繰り返され、新しいトレースログ・ファイルが一杯になった状態を、図６−４のＳＴＥＰ１１に示す。

図６−４のＳＴＥＰ１１には、トレースログ・ファイル６４６が含まれている。そして、トレースログ・ファイル６４６の全体が縦線模様で示されており、トレースログ・ファイル６４６が一杯になったことが表されている。すなわち、図５の処理フローに当てはめると、ステップＳ３の判定において、Ｙｅｓルートに進む。そして、ステップＳ５の判定においては、リネーム済みファイル格納ディレクトリ６１２に格納されているファイルが２つ（２世代）であり、最大世代数である５に満たないので、Ｎｏルートに進む。

ステップＳ９の判定においては、開始拡張子が「002」であるため、Ｎｏルートに進む。この際、ワーク・メモリ領域に、更新前の開始拡張子として「002」を格納しておく。

そして、ステップＳ１５におけるリネーム処理によって、リネーム済みファイル６４０及びリネーム済みファイル６４２を、さらにリネームする。リネーム済みファイルのリネーム方法については、上で述べた通りであり、リネーム済みファイル６４０の拡張子を「003（002＋002-002+1）」に、また、リネーム済みファイル６４２の拡張子を「004（002＋003-002+1）」に変更する。なお、図６−４のＳＴＥＰ１１では、リネーム済みファイル６４４が処理されているが、現用系の処理装置による処理には影響しない。

そして、ステップＳ１７の処理において、現用系制御テーブル（図３）の最古拡張子の行３８６の値を、リネーム済みファイルの拡張子の最大値である「004」に更新する（今回は同じ値で変わらず）。さらに、ステップＳ１９の処理によって、トレースログ・ファイル６４６がリネームされ、図６−５のＳＴＥＰ１２に示したような状態となる。図６−５のＳＴＥＰ１２には、リネーム済みファイル６５０とリネーム済みファイル６５２とリネーム済みファイル６５４とが含まれている。リネーム済みファイル６５０は、ＳＴＥＰ１１（図６−４）のトレースログ・ファイル６４６のファイル名及び格納ディレクトリを変更したものである。例えば２００３年７月６日１２時２４分２１秒にリネーム処理されたファイルであり、開始拡張子は「002」であるため、新しいファイル名は「Trace20030706122421.002」と示されている。リネーム済みファイル６５２は、ＳＴＥＰ１１（図６−４）のリネーム済みファイル６４０の拡張子が変更されたものであり、リネーム済みファイル６５４は、ＳＴＥＰ１１（図６−４）のリネーム済みファイル６４２の拡張子が変更されたものである。

トレースログ・ファイル６４６（図６−４のＳＴＥＰ１１）のリネーム処理が終了すると、図５の処理フローでは、再びステップＳ１の処理に移行する。すなわち、新しいトレースログ・ファイルにデータが書き込まれていく。

このようにしてトレースログ・ファイルの生成処理及びリネーム処理が行われる一方で、待機系の処理装置によるファイル処理が行われず、リネーム済みファイルの世代数が上限値である例えば５に達した場合におけるディスク状態を図６−５のＳＴＥＰ１３に示す。

図６−５のＳＴＥＰ１３には、トレースログ・ファイル６５６と最古世代リネーム済みファイル６５８とが含まれている。そして、トレースログ・ファイル６５６の全体が縦線模様で示されており、トレースログ・ファイル６５６が一杯になったことが表されている。すなわち、図５の処理フローに当てはめると、ステップＳ１を経由した後、ステップＳ３の判定において、Ｙｅｓルートに進む。そして、ステップＳ５の判定において、リネーム済みファイル格納ディレクトリ６１２に格納されているファイルが５つ（５世代）であり、最大世代数である５に達しているので、Ｙｅｓルートに進む。

そして、ステップＳ７の処理において、最古世代リネーム済みファイル６５８が削除され、図６−６のＳＴＥＰ１４に示したような状態となる。ステップＳ９の判定においては、開始拡張子が「002」であるため、Ｎｏルートに進む。この際、ワーク・メモリ領域に、更新前の開始拡張子として「002」を格納しておく。

そして、ステップＳ１５におけるリネーム処理によって、各リネーム済みファイルをさらにリネームする。リネーム済みファイルのリネーム方法については、上で述べた通りである。そして、ステップＳ１７の処理において、現用系制御テーブル（図３）の最古拡張子の行３８６の値を、リネーム済みファイルの拡張子の最大値である「006」に更新する（今回は同じ値で変わらず）。

さらに、ステップＳ１９の処理によって、トレースログ・ファイル６５６がリネームされ、図６−６のＳＴＥＰ１５に示したような状態となる。図６−６のＳＴＥＰ１５には、リネーム済みファイル６６０が含まれている。リネーム済みファイル６６０は、ＳＴＥＰ１４のトレースログ・ファイル６５６のファイル名及び格納ディレクトリを変更したものである。例えば２００３年７月１５日５時４１分１８秒にリネーム処理されたファイルであり、開始拡張子は「002」であるため、新しいファイル名は「Trace20030715054118.002」と示されている。その他のリネーム済みファイルは、ＳＴＥＰ１４の各リネーム済みファイルの拡張子が変更されたものである。

以上、図５に示した処理フローを網羅する具体例を示したが、このようにして、現用系処理装置５によるトレースログ・ファイルの生成処理、削除処理及びリネーム処理が行われる。

次に、図７乃至図９の処理フロー、及び図１０−１乃至図１０−３のディスク状態遷移図を用いて、待機系の処理装置、例えば待機系処理装置３の実施する処理について、処理の流れ、具体例の順に説明する。

まず、待機系処理装置３のトレースログ監視処理部３１０は、待機系制御テーブル（図４）のリネーム済みファイル格納ディレクトリ名の行４００及び処理対象ファイル拡張子（最上位）の行４０４の値に基づき、共有ディスク７から、待機系処理装置３の処理対象となる拡張子のファイルを検索する（図７：ステップＳ３１）。例えば共有ディスク７の「/apl/rename」というディレクトリにあり且つ拡張子が「002」であるファイルを検索する。

そして、トレースログ監視処理部３１０は、該当するファイルがあったか判定する（ステップＳ３３）。該当するファイルがなかったと判定された場合（ステップＳ３３：Ｎｏルート）、後に述べるステップＳ４９の処理に移行する。一方、該当するファイルがあったと判定された場合（ステップＳ３３：Ｙｅｓルート）、制御部３４０は、待機系制御テーブル（図４）の処理対象ファイル拡張子固定の行４０２の値に基づき、処理対象となるファイルの拡張子を固定とする設定であるか判定する（ステップＳ３５）。固定とする設定であると判定された場合（ステップＳ３５：Ｙｅｓルート）、後に述べるステップＳ３９の処理に移行する。

一方、固定とする設定ではないと判定された場合（ステップＳ３５：Ｎｏルート）、トレースログ監視処理部３１０は、上位ファイルが存在するか判定する（ステップＳ３７）。本実施の形態において、上位ファイルとは、処理対象となるファイルよりも大きい数値の拡張子を持つファイルを指す。例えば、処理対象となるファイルの拡張子が「002」であった場合、「003」や「004」等、「002」よりも大きい数値の拡張子を持つファイルが、上位ファイルである。

上位ファイルが存在すると判定された場合（ステップＳ３７：Ｙｅｓルート）、後に述べるステップＳ４９の処理に移行する。一方、上位ファイルが存在しないと判定された場合（ステップＳ３７：Ｎｏルート）、制御部３４０は、待機系制御テーブル（図４）の圧縮ファイル格納ディレクトリ名の行４１８及び圧縮ファイルのトータル・サイズ上限の行４２６の値に基づき、又はディスク・クォータ・チェックの行４２８及びディスク・クォータ残割合の行４３０の値に基づき、圧縮ファイルのトータル・サイズ・オーバ、又はディスク・サイズ・オーバの状態であるか判定する（ステップＳ３９）。ディスク・サイズの定義については、上のステップＳ５（図５）における説明と同様である。

圧縮ファイルのトータル・サイズ又はディスク・サイズがオーバしていないと判定された場合（ステップＳ３９：Ｎｏルート）、後に述べるステップＳ４３の処理に移行する。一方、圧縮ファイルのトータル・サイズ又はディスク・サイズがオーバしていると判定された場合（ステップＳ３９：Ｙｅｓルート）、トレースログ削除処理部３３０は、圧縮処理済みのファイルのうち、最古世代のものを削除する（ステップＳ４１）。なお、圧縮処理済みのファイルは、待機系制御テーブル（図４）の圧縮ファイル格納ディレクトリ名の行４１８に示されるディレクトリに格納されている。

そして、トレースログ圧縮処理部３３０は、ステップＳ３１において検出された、処理対象となる（リネーム済み）ファイルに圧縮処理を施す（ステップＳ４３）。待機系制御テーブル（図４）の圧縮方式の行４１６の値に基づく圧縮方法で圧縮したファイルを、圧縮ファイル格納ディレクトリ名の行４１８の値で示されるディレクトリに格納する。例えば、拡張子が「tar.gz」となるような圧縮処理を行い、共有ディスク７の「/apl/comp」ディレクトリに格納する。

そして、制御部３４０は、待機系制御テーブル（図４）の処理対象ファイル拡張子固定の行４０２の値に基づき、処理対象となるファイルの拡張子を固定とする設定であるか判定する（ステップＳ４５）。固定とする設定であると判定された場合（ステップＳ４５：Ｙｅｓルート）、後に述べるステップＳ４９の処理に移行する。

一方、固定とする設定ではないと判定された場合（ステップＳ４５：Ｎｏルート）、制御部３４０は、全ての下位ファイルの処理が終了したか判定する（ステップＳ４７）。本実施の形態において、下位ファイルとは、上で述べた上位ファイルと反対の概念であり、処理対象となるファイルよりも小さい数値の拡張子を持つファイルを指す。例えば、処理対象となるファイルの拡張子が「002」であった場合、「001」や「000」等、「002」よりも小さい数値の拡張子を持つファイルが、下位ファイルである。

全ての下位ファイルの処理が終了していないと判定された場合（ステップＳ４７：Ｎｏルート）、ステップＳ４３の処理に戻る。このようにして、全ての下位ファイルについて処理を行う。例えば、拡張子が「002」、「001」及び「000」のファイルをまとめて処理する。これにより、拡張子が「001」や「000」のファイルの処理を割り当てられている他の待機系の処理装置が行わなかった処理をカバーすることができる。

一方、全ての下位ファイルについて処理が終了したと判定された場合（ステップＳ４７：Ｙｅｓルート）、トレースログ監視処理部３１０は、監視間隔設定処理を行う（ステップＳ４９）。この処理については後に詳述するが、処理対象のファイルを監視する間隔を調節する処理である。

そして、トレースログ監視処理部３１０は、ステップＳ４９の監視間隔設定処理において設定された監視間隔に従って待機する（ステップＳ５１）。そして、ステップＳ３１の処理に移行する。

このようにして、待機系の処理装置は、自己に割り当てられたファイルに対して圧縮処理を行う。また、設定によっては他の待機系の処理装置に割り当てられたファイルに対しても圧縮処理を行う。

次に、図８及び図９に示した処理フローを用いて、監視間隔設定処理（図７：ステップＳ４９）の処理の詳細について説明する。なお、この監視間隔設定処理は、制御部３４０によって実施される。以下の説明においては、処理主体の明示を割愛する。

監視間隔設定処理では、まず、ステップＳ３３（図７）において処理対象のファイルがあったか判定する（図８：ステップＳ６１）。処理対象のファイルがなかったと判定された場合（ステップＳ６１：Ｎｏルート）、端子Ａを介して図９の処理に移行する。

一方、処理対象のファイルがあったと判定された場合（ステップＳ６１：Ｙｅｓルート）、待機系制御テーブル（図４）の監視間隔の行４０６及び最小監視間隔の行４１０の値に基づき、現在の監視間隔が最小値であるか判定する（ステップＳ６３）。すなわち、監視間隔の行４０６の値と最小監視間隔の行４１０の値とが等しいか確認する。なお、監視間隔の行４０６と最小監視間隔の行４１０とには、値が登録されているものとする。監視間隔の行４０６には、初期値（例えば標準監視間隔）又は更新された値が登録されている。

そして、現在の監視間隔が最小値であると判定された場合（ステップＳ６３：Ｙｅｓルート）、監視間隔設定処理を終了し、元の処理に戻る。一方、現在の監視間隔が最小値ではないと判定された場合（ステップＳ６３：Ｎｏルート）、待機系制御テーブル（図４）の監視間隔増減割合の行４１４の値に基づき、監視間隔を短くする（ステップＳ６５）。例えば、現在の監視間隔である監視間隔の行４０６の値が６０（秒）で、監視間隔増減割合の行４１４の値が１０（％）であった場合、監視間隔を１０％短くして５４（60-60*0.1）秒とする。

そして、監視間隔を短くした結果、最小値（待機系制御テーブル（図４）の最小監視間隔の行４１０の値）以下になったか判定する（ステップＳ６７）。最小値以下になったと判定された場合（ステップＳ６７：Ｙｅｓルート）、監視間隔を最小値に設定する（ステップＳ６９）。すなわち、待機系制御テーブル（図４）の監視間隔の行４０６に、最小監視間隔の行４１０の値を登録する。このようにして、監視間隔が際限なく短くなっていくことを防止している。そして、元の処理に戻る。

一方、監視間隔を短くしても、最小値以下にならなかったと判定された場合（ステップＳ６７：Ｎｏルート）、短くした監視間隔を、新しい監視間隔として設定する（ステップＳ７１）。すなわち、待機系制御テーブル（図４）の監視間隔の行４０６に、ステップＳ６５において算出された監視間隔を登録する。そして、元の処理に戻る。

次に、図９を用いて、端子Ａを介して移行した処理（ステップＳ６１：Ｎｏルート）について説明する。まず、監視間隔の最大値の設定がなされているか判定する（図９：ステップＳ８１）。すなわち、待機系制御テーブル（図４）の最大監視間隔の行４１２に、値が格納されているか確認する。

監視間隔の最大値の設定がなされていないと判定された場合（ステップＳ８１：Ｎｏルート）、現在の監視間隔は標準値であるか判定する（ステップＳ８３）。すなわち、待機系制御テーブル（図４）の監視間隔の行４０６の値が、標準監視間隔の行４０８の値と等しいか判定する。現在の監視間隔は標準値であると判定された場合（ステップＳ８３：Ｙｅｓルート）、端子Ｂを介して図８の処理に戻り、監視間隔設定処理を終了して元の処理に戻る。

一方、現在の監視間隔は標準値ではないと判定された場合（ステップＳ８３：Ｎｏルート）、待機系制御テーブル（図４）の監視間隔増減割合の行４１４の値に基づき、監視間隔を長くする（ステップＳ８５）。例えば、現在の監視間隔である監視間隔の行４０６の値が５０（秒）で、監視間隔増減割合の行４１４の値が１０（％）であった場合、監視間隔を１０％長くして５５（50+50*0.1）秒とする。

そして、監視間隔を長くした結果、標準値（待機系制御テーブル（図４）の標準監視間隔の行４０８の値）以上になったか判定する（ステップＳ８７）。標準値以上になったと判定された場合（ステップＳ８７：Ｙｅｓルート）、監視間隔を標準値に設定する（ステップＳ８９）。すなわち、待機系制御テーブル（図４）の監視間隔の行４０６に、標準監視間隔の行４０８の値を登録する。このようにして、監視間隔の最大値が設定されていなくても、監視間隔が際限なく長くなっていくことを防止している。そして、端子Ｂを介して図８の処理に戻り、監視間隔設定処理を終了して元の処理に戻る。

一方、監視間隔を長くしても、標準値以上にならなかったと判定された場合（ステップＳ８７：Ｎｏルート）、長くした監視間隔を、新しい監視間隔として設定する（ステップＳ９１）。すなわち、待機系制御テーブル（図４）の監視間隔の行４０６に、ステップＳ８５（又は後に述べるステップＳ９５）において算出された監視間隔を登録する。そして、端子Ｂを介して図８の処理に戻り、監視間隔設定処理を終了して元の処理に戻る。

また一方、ステップＳ８１の判定において、監視間隔の最大値の設定がなされていると判定された場合（ステップＳ８１：Ｙｅｓルート）、現在の監視間隔は最大値であるか判定する（ステップＳ９３）。すなわち、待機系制御テーブル（図４）の監視間隔の行４０６の値が、最大監視間隔の行４１２の値と等しいか判定する。現在の監視間隔は最大値であると判定された場合（ステップＳ９３：Ｙｅｓルート）、端子Ｂを介して図８の処理に戻り、監視間隔設定処理を終了して元の処理に戻る。

一方、現在の監視間隔は最大値ではないと判定された場合（ステップＳ９３：Ｎｏルート）、待機系制御テーブル（図４）の監視間隔増減割合の行４１４の値に基づき、監視間隔を長くする（ステップＳ９５）。例えば、現在の監視間隔である監視間隔の行４０６の値が７０（秒）で、監視間隔増減割合の行４１４の値が１０（％）であった場合、監視間隔を１０％長くして７７（70+70*0.1）秒とする。

そして、監視間隔を長くした結果、最大値（待機系制御テーブル（図４）の最大監視間隔の行４１２の値）以上になったか判定する（ステップＳ９７）。最大値以上になったと判定された場合（ステップＳ９７：Ｙｅｓルート）、監視間隔を最大値に設定する（ステップＳ９９）。すなわち、待機系制御テーブル（図４）の監視間隔の行４０６に、最大監視間隔の行４１２の値を登録する。このようにして、監視間隔が際限なく長くなっていくことを防止している。そして、端子Ｂを介して図８の処理に戻り、監視間隔設定処理を終了して元の処理に戻る。一方、監視間隔を長くしても、最大値以上にならなかったと判定された場合（ステップＳ９７：Ｎｏルート）、上で述べたステップＳ９１の処理に移行する。

このようにして、監視間隔設定処理が行われる。これにより、待機系の処理装置は、処理対象のファイルが生成される頻度に合わせた監視処理を行うことができるようになる。 以下、図１０−１乃至図１０−３のディスク状態遷移図を用いて、図７に示した処理フローの具体例を説明する。なお、処理主体については処理フローの説明において明示しているため、以下の説明では割愛する。

処理開始時点では、待機系制御テーブル（図４）には初期値が登録されており、ディスク・サイズのチェックは行わない、すなわちディスク・クォータ・チェックの行４２８の値は「Ｎｏ」に設定されているものとする。

図１０−１のＳＴＥＰ２１には、トレースログ格納ディレクトリ１０１０とリネーム済みファイル格納ディレクトリ１０１２と圧縮済みファイル格納ディレクトリ１０１４とが含まれている。そして、リネーム済みファイル格納ディレクトリ１０１２には、リネーム済みファイル１０１６が含まれている。トレースログ格納ディレクトリ１０１０及びリネーム済みファイル格納ディレクトリ１０１２は、図６−１乃至図６−６に示したトレースログ格納ディレクトリ６１０及びリネーム済みファイル格納ディレクトリ６１２と同様のものであり、これらには、現用系処理装置５によって生成・リネームされた各ファイルが格納されている。圧縮済みファイル格納ディレクトリ１０１４には、待機系の処理装置によって圧縮されたファイルが格納される。

共有ディスク７の少なくとも一部が、図１０−１のＳＴＥＰ２１に示したような状態にある場合に、図７の処理フローに示した処理が開始されると、まず、待機系の処理装置である例えば待機系処理装置３が、処理対象の拡張子を持つリネーム済みファイルを、リネーム済みファイル格納ディレクトリ１０１２から検索する（図７：ステップＳ３１）。

待機系処理装置３の処理対象となるファイルの拡張子（待機系制御テーブル（図４）の処理対象ファイル拡張子（最上位）の値）が、例えば「004」やそれ以上の値であった場合には、該当するファイルがないため、ステップＳ３３の判定においてＮｏルートに進む。この場合、ステップＳ４９の監視間隔設定処理において、監視間隔を長くするような（変わらない場合もある）設定がなされる。

一方、待機系処理装置３の処理対象となるファイルの拡張子（待機系制御テーブル（図４）の処理対象ファイル拡張子（最上位）の値）が、例えば「001」であった場合、該当するファイルとしてリネーム済みファイル１０１６が検出され、ステップＳ３３の判定においてＹｅｓルートに進む。

そして、待機系制御テーブル（図４）の処理対象ファイル拡張子固定の行４０２の値が、例えば「Ｎｏ」である場合、ステップＳ３５の判定においてＮｏルートに進み、さらにステップＳ３７の判定においては上位ファイルが存在する（拡張子が「002」のファイル及び拡張子が「003」のファイルがある）ため、Ｙｅｓルートに進む。この場合、ステップＳ４９の監視間隔設定処理において、監視間隔を短くするような（変わらない場合もある）設定がなされる。

また一方、待機系制御テーブル（図４）の処理対象ファイル拡張子固定の行４０２の値が、例えば「Ｙｅｓ」である場合、ステップＳ３５の判定においてＹｅｓルートに進む。そして、ステップＳ３９の判定においては、圧縮済みファイル格納ディレクトリ１０１４にファイルが格納されていないので、Ｎｏルートに進む。

そして、ステップＳ４３において、処理対象として検出されたリネーム済みファイル、すなわちリネーム済みファイル１０１６に圧縮処理を施し、圧縮されたファイルを圧縮済みファイル格納ディレクトリ１０１４に格納すると、図１０−１のＳＴＥＰ２２に示したような状態となる。

図１０−１のＳＴＥＰ２２には、圧縮済みファイル１０１８が含まれている。すなわち、リネーム済みファイル１０１６が圧縮処理され、圧縮済みファイル１０１８になったことが示されている。なお、圧縮方法については、上に述べた通りである。

そして、ステップＳ４５の判定では、ステップＳ３５の判定同様、Ｙｅｓルートに進み、ステップＳ４９の監視間隔設定処理において、監視間隔を短くするような（変わらない場合もある）設定がなされる。そして、ステップＳ５１において監視間隔に従い待機して、再びステップＳ３１の処理に移行する。

このようにしてリネーム済みファイルの圧縮処理が行われ、生成された圧縮済みファイルの合計サイズが、上限値である、待機系制御テーブル（図４）の圧縮ファイルのトータル・サイズ上限の行４２６に達した場合におけるディスク状態を図１０−２のＳＴＥＰ２３に示す。

図１０−２のＳＴＥＰ２３には、リネーム済みファイル１０２０と、リネーム済みファイル１０２２と、圧縮済みファイル１０２４と、圧縮済みファイル１０２６と、・・・、が含まれている。なお、圧縮済みファイル格納ディレクトリ１０１４に格納されている圧縮済みファイルの合計サイズが、待機系制御テーブル（図４）の圧縮ファイルのトータル・サイズ上限の行４２６の値に達しているものとする。

図７の処理フローに当てはめると、ステップＳ３１において、処理対象の拡張子を持つリネーム済みファイルを、リネーム済みファイル格納ディレクトリ１０１２から検索する。例えば待機系処理装置３の処理対象となるファイルの拡張子（待機系制御テーブル（図４）の処理対象ファイル拡張子（最上位）の値）が、例えば「001」であった場合、該当するファイルとしてリネーム済みファイル１０２２が検出され、ステップＳ３３の判定においてＹｅｓルートに進む。

そして、待機系制御テーブル（図４）の処理対象ファイル拡張子固定の行４０２の値が、例えば「Ｎｏ」である場合、ステップＳ３５の判定においてＮｏルートに進み、さらにステップＳ３７の判定においては上位ファイルが存在しない（拡張子が「002」以上のファイルがない）ため、Ｎｏルートに進む。そして、ステップＳ３９の判定において、圧縮ファイルのトータル・サイズ・オーバであると判定され、Ｙｅｓルートに進み、ステップＳ４１において最古世代の圧縮済みファイルを削除する。最古世代の検出は、ファイル名によって行う（例えば「Trace20030707070707.005.tar.gz」の下線部「005」）。なお、この場合、削除対象となるファイルが複数存在したり、必ずしも古いファイルが削除対象になるとは限らないため、生成日時が最も古いファイルを削除するようにしてもよい。

図１０−２のＳＴＥＰ２３に示した例では、圧縮済みファイル１０２４が最古世代の圧縮済みファイルに該当し、削除される。そして、図１０−２のＳＴＥＰ２４に示したような状態となる。

ディスク・スペースができたので、ステップＳ４３において、処理対象として検出されたリネーム済みファイル、すなわちリネーム済みファイル１０２２に圧縮処理を施し、圧縮されたファイルを圧縮済みファイル格納ディレクトリ１０１４に格納すると、図１０−３のＳＴＥＰ２５に示したような状態となる。図１０−３のＳＴＥＰ２５には、圧縮済みファイル１０２８が含まれている。すなわち、リネーム済みファイル１０２２が圧縮処理され、圧縮済みファイル１０２８になったことが示されている。

そして、ステップＳ４５の判定では、ステップＳ３５の判定同様、Ｎｏルートに進み、さらにステップＳ４７の判定においては、未処理の下位ファイルが存在する（拡張子が「000」のリネーム済みファイルがある）ため、Ｎｏルートに進む。そして、ステップＳ４３において、下位ファイルであるリネーム済みファイル１０２０に圧縮処理を施し、圧縮されたファイルを圧縮済みファイル格納ディレクトリ１０１４に格納すると、図１０−３のＳＴＥＰ２６に示したような状態となる。図１０−３のＳＴＥＰ２６には、圧縮済みファイル１０３０が含まれている。すなわち、リネーム済みファイル１０２０が圧縮処理され、圧縮済みファイル１０３０になったことが示されている。

このように、処理対象となるファイルの拡張子を固定に設定しない場合には、本来、他の待機系の処理装置が処理すべきであったファイルも処理対象となる。なお、ステップＳ３７の判定において、上位ファイルを検出した場合に圧縮処理を実行しないのは、他の待機系の処理装置との同時アクセスを防止するためである。

そして、図７のステップＳ４５の判定においては、上と同様、Ｎｏルートに進み、ステップＳ４７の判定においては、未処理の下位ファイルは存在しないため、Ｙｅｓルートに進む。そして、ステップＳ４９の監視間隔設定処理において、監視間隔を短くするような（変わらない場合もある）設定がなされる。そして、ステップＳ５１において監視間隔に従い待機して、再びステップＳ３１の処理に移行する。

このようにして、待機系の処理装置、例えば待機系処理装置３によるファイル圧縮処理が行われる。なおその際、現用系処理装置５との通信処理や同期処理は行われない。

以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば、図３及び図４に示したテーブル構成は一例であって、同様のデータを格納するためであれば別の構成を採用するようにしてもよいし、必要に応じて項目を追加又は削除してもよい。

また、図１に示した現用系処理装置５及び待機系処理装置３の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。また、各処理装置が複数のサーバやコンピュータによって構成されていてもよい。

また、図２、図６−１乃至図６−６及び図１０−１乃至図１０−３に示した共有ディスク７内におけるファイル・イメージは一例であって、実際のディレクトリ構成やファイル名とは異なる場合がある。例えば、トレースログ・ファイルと同一のディレクトリにリネーム済みファイルを格納するようにしてもよいし、世代が新しくなるにつれ、大きい数値の拡張子を設定するようにしてもよい。また、ファイルの圧縮方法も一例であって、他の圧縮方法を用いてもよい。

また、図５及び図７乃至図９に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。

（付記１）
現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける前記待機系の処理装置により実行されるファイル処理方法であって、
前記現用系の処理装置により生成され且つ前記共有ディスクに格納されているファイルから、制御情報格納部に格納されている制御情報に基づき、処理対象となるファイルを特定するファイル特定ステップと、
前記共有ディスク内の特定されたファイルに対して所定の処理を実施するファイル処理ステップと、
を含むファイル処理方法。

（付記２）
前記ファイル特定ステップにおいて、
前記共有ディスクの所定の領域に格納されているファイルの個数と生成順序との少なくともいずれかに基づき、当該共有ディスクの所定の領域内の処理対象となるファイルを特定することを特徴とする
付記１記載のファイル処理方法。

（付記３）
前記共有ディスクの所定の領域に格納されているファイルのファイル名が、世代管理を可能とするネーミング・ルールに従って設定されている場合、
前記ファイル特定ステップにおいて、前記共有ディスクの所定の領域に格納されているファイルのファイル名から特定される世代に基づき、処理対象となるファイルを特定することを特徴とする
付記１記載のファイル処理方法。

（付記４）
前記制御情報は、前記待機系の処理装置が処理すべきファイルの世代を示すデータを含み、
前記ファイル特定ステップにおいて、前記データが示す世代以降のファイルを、処理対象として特定することを特徴とする
付記３記載のファイル処理方法。

（付記５）
処理対象となるファイルの特定可否状況に基づき前記共有ディスクに対する監視間隔を設定し、前記制御情報格納部に格納するステップをさらに含む、
付記１乃至４のいずれか１つに記載のファイル処理方法。

（付記６）
前記ファイル処理ステップにおいて、特定されたファイルの圧縮を命じ、圧縮されたファイルを圧縮ファイル格納部に格納することを特徴とする
付記１乃至５のいずれか１つに記載のファイル処理方法。

（付記７）
前記ファイル処理ステップにおいて、特定されたファイルを所定のコンピュータに送信することを特徴とする
付記１乃至５のいずれか１つに記載のファイル処理方法。

（付記８）
現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける前記現用系の処理装置により実行されるファイル処理方法であって、
生成したファイルに対して、前記待機系の処理装置における処理対象とするための所定のネーミング・ルールに従ったファイル名を決定するファイル名決定ステップと、
前記生成したファイルを、決定した前記ファイル名で前記共有ディスクの所定の領域に格納するファイル格納ステップと、
を含むファイル処理方法。

（付記９）
所定の条件を満たした場合、前記共有ディスクの所定の領域に格納されているファイルのファイル名を設定しなおすリネーム処理ステップをさらに含む
付記８記載のファイル処理方法。

（付記１０）
前記所定のネーミング・ルールは、ファイルを世代管理可能とするネーミング・ルールであって、
前記リネーム処理ステップにおいて、前記共有ディスクの所定の領域に格納されているファイルのファイル名を、世代を変えたファイル名に設定しなおすことを特徴とする
付記９記載のファイル処理方法。

（付記１１）
前記共有ディスクの所定の領域に格納されているファイルが前記待機系の処理装置によって処理されたか否かを判断するステップをさらに含み、
特定の世代のファイルが未処理であると判断された場合、前記ファイル名決定ステップにおいて、当該特定の世代をスキップした態様でファイル名を決定することを特徴とする
付記１０記載のファイル管理方法。

（付記１２）
前記所定の条件は、前記共有ディスクの所定の領域に、既にファイルが格納されており且つ新規なファイルを格納するという条件であることを特徴とする
付記９乃至１１のいずれか１つに記載のファイル管理方法。

（付記１３）
現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける前記待機系の処理装置に実行させるファイル処理プログラムであって、
前記現用系の処理装置により生成され且つ前記共有ディスクに格納されているファイルから、制御情報格納部に格納されている制御情報に基づき、処理対象となるファイルを特定するステップと、
前記共有ディスク内の特定されたファイルに対して所定の処理を実施するステップと、
を待機系の処理装置に実行させるファイル処理プログラム。

（付記１４）
現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける前記現用系の処理装置に実行させるファイル処理プログラムであって、
生成したファイルに対して、前記待機系の処理装置における処理対象とするための所定のネーミング・ルールに従ったファイル名を決定するステップと、
前記生成したファイルを決定した前記ファイル名で前記共有ディスクの所定の領域に格納するステップと、
を現用系の処理装置に実行させるファイル処理プログラム。

（付記１５）
現用系の処理装置と共有ディスクとを含むクラスタ・システムに接続される待機系の処理装置であって、
前記現用系の処理装置により生成され且つ前記共有ディスクに格納されているファイルから、制御情報格納部に格納されている制御情報に基づき、処理対象となるファイルを特定する手段と、
前記共有ディスク内の特定されたファイルに対して所定の処理を実施する手段と、
を有する待機系の処理装置。

（付記１６）
待機系の処理装置と共有ディスクとを含むクラスタ・システムに接続される現用系の処理装置であって、
生成したファイルに対して、前記待機系の処理装置における処理対象とするための所定のネーミング・ルールに従ったファイル名を決定する手段と、
前記生成したファイルを決定した前記ファイル名で前記共有ディスクの所定の領域に格納する手段と、
を有する現用系の処理装置。

本発明の一実施の形態におけるシステム構成図である。 共有ディスクに格納されるファイルの概要図である。 現用系制御テーブルの一例を示す図である。 待機系制御テーブルの一例を示す図である。 本発明の一実施の形態における処理フロー（その１）を示す図である。 ディスク状態遷移の一例（その１）を示す図である。 ディスク状態遷移の一例（その２）を示す図である。 ディスク状態遷移の一例（その３）を示す図である。 ディスク状態遷移の一例（その４）を示す図である。 ディスク状態遷移の一例（その５）を示す図である。 ディスク状態遷移の一例（その６）を示す図である。 本発明の一実施の形態における処理フロー（その２）を示す図である。 監視間隔設定処理の処理フロー（その１）を示す図である。 監視間隔設定処理の処理フロー（その２）を示す図である。 ディスク状態遷移の一例（その７）を示す図である。 ディスク状態遷移の一例（その８）を示す図である。 ディスク状態遷移の一例（その９）を示す図である。

符号の説明

１ 社内ＬＡＮ ３ 待機系処理装置
５ 現用系処理装置 ７ 共有ディスク
９ 他システム
３１０ トレースログ監視処理部
３２０ トレースログ圧縮処理部
３３０，５３０ トレースログ削除処理部
３４０ 制御部
３５０，５４０ 制御テーブル格納部
３６０ トレースログ転送処理部
５１０ トレースログ書き込み処理部
５２０ トレースログ・リネーム処理部

Claims (5)

1. 現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける前記待機系の処理装置により実行されるファイル処理方法であって、
   制御情報格納部に格納されている制御情報に基づき、所定の間隔で、処理対象のファイルが前記共有ディスクに格納されているか検索するファイル検索ステップと、
   前記ファイル検索ステップで前記処理対象のファイルが検出された場合、当該処理対象のファイルに対して所定の処理を実施するファイル処理ステップと、
   前記ファイル処理ステップで前記所定の処理を実施した後に前記共有ディスクに前記処理対象のファイルがあった場合、前記制御情報格納部に格納されている前記所定の間隔を短く設定する監視間隔短縮ステップと、
   前記ファイル検索ステップで前記処理対象のファイルが検出されなかった場合、前記制御情報格納部に格納されている前記所定の間隔を長く設定する監視間隔延長ステップと、
   を含むファイル処理方法。
2. 前記ファイル検索ステップにおいて、前記制御情報格納部に格納されている、処理対象の世代の情報に基づき、前記所定の間隔で、当該処理対象の世代のファイルが前記共有ディスクに格納されているか検索し、
   前記ファイル処理ステップにおいて、前記ファイル検索ステップで前記処理対象のファイルとして最古世代のファイルが検出された場合、当該処理対象の世代以降の世代のファイルに対して所定の処理を実施する
   ことを特徴とする請求項１記載のファイル処理方法。
3. 現用系の処理装置と待機系の処理装置と共有ディスクとで構成されるクラスタ・システムにおける前記待機系の処理装置に実行させる処理プログラムであって、
   制御情報格納部に格納されている制御情報に基づき、所定の間隔で、処理対象のファイルが前記共有ディスクに格納されているか検索するファイル検索ステップと、
   前記ファイル検索ステップで前記処理対象のファイルが検出された場合、当該処理対象のファイルに対して所定の処理を実施するファイル処理ステップと、
   前記ファイル処理ステップで前記所定の処理を実施した後に前記共有ディスクに前記処理対象のファイルがあった場合、前記制御情報格納部に格納されている前記所定の間隔を短く設定する監視間隔短縮ステップと、
   前記ファイル検索ステップで前記処理対象のファイルが検出されなかった場合、前記制御情報格納部に格納されている前記所定の間隔を長く設定する監視間隔延長ステップと、
   を実行させるファイル処理プログラム。
4. 前記ファイル検索ステップにおいて、前記制御情報格納部に格納されている、処理対象の世代の情報に基づき、前記所定の間隔で、当該処理対象の世代のファイルが前記共有ディスクに格納されているか検索し、
   前記ファイル処理ステップにおいて、前記ファイル検索ステップで前記処理対象のファイルとして最古世代のファイルが検出された場合、当該処理対象の世代以降の世代のファイルに対して所定の処理を実施する
   ことを特徴とする請求項３記載のファイル処理プログラム。
5. 現用系の処理装置と共有ディスクとを含むクラスタ・システムに接続される待機系の処理装置であって、
   制御情報格納部に格納されている制御情報に基づき、所定の間隔で、処理対象のファイルが前記共有ディスクに格納されているか検索するファイル検索手段と、
   前記ファイル検索手段で前記処理対象のファイルが検出された場合、当該処理対象のファイルに対して所定の処理を実施するファイル処理手段と、
   前記ファイル処理手段で前記所定の処理を実施した後に前記共有ディスクに前記処理対象のファイルがあった場合、前記制御情報格納部に格納されている前記所定の間隔を短く設定する監視間隔短縮手段と、
   前記ファイル検索手段で前記処理対象のファイルが検出されなかった場合、前記制御情報格納部に格納されている前記所定の時間を長く設定する監視間隔延長手段と、
   を備えることを特徴とする待機系の処理装置。

Images