(57)【要約】【課題】  この発明の課題は、帳票配信管理システムをマルチサーバ構成とした場合に、制御用のサーバを備えたりすることなく、システムダウンしたサーバを検出し、他のサーバがこのシステムダウンしたサーバのジョブを引き継ぐことを可能とすることにある。【解決手段】  マルチサーバで共有しているデータベースに、出力先のプリンタを示すフィールドである論理デバイス、帳票配信を実行しているサーバを示すフィールドであるホスト名、配信処理の日時を示すフィールドである更新日時という３つのフィールドを1レコードにもった配信スレッド監視テーブルを備える。  各サーバには、常駐して監視スレッドを備え、当該監視スレッドにより一定間隔ごとに前記配信スレッド監視テーブルを参照し、更新日時フィールドが所定の期間以上更新されていないものを見つけた場合、その配信処理を引き継ぐようにする。【選択図】            図１
2006313441.tif 000002
【特許請求の範囲】
【請求項１】
マルチサーバで構成された、帳票配信管理システムにおいて、
マルチサーバで共有しているデータベースに、印刷先プリンタを示す論理デバイス名フィールドと、帳票データ、帳票フォーマットなどを配信するホスト名を示すホスト名フィールドと、配信処理の開始、終了時間を示す更新日時フィールドとを一つのレコードとする配信スレッド監視テーブルを備え、
各サーバ上で常駐して動作する配信サービス中の監視スレッドが、一定間隔ごとに前記配信スレッド監視テーブルの更新日時を参照し、これが所定の時間以上更新されていない場合、そのホスト名フィールドに記録されているホストがシステムダウンしていると判断し、そのレコードの帳票配信処理を引き継ぐようにした、
ことを特徴とする帳票配信管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、センター集中型の帳票管理・配信システムに関し、マルチサーバのシステム構成とすることで、高信頼性、及び、高可用性を実現することに関するものである。
【背景技術】
【０００２】
通常はシングルサーバのシステムに対し、マルチサーバのシステムは、サーバの1台がシステムダウンした場合でも、他のサーバがシステムダウンしたサーバのジョブを引き継ぐことで処理を続行することができ、高信頼性、高可用性に優れたものである。
【０００３】
従来のマルチサーバ構成のシステムにおいては、制御用のサーバを備えるように構成し、システムダウンしたサーバを制御用のサーバが監視することで検出するようにしたり（特許文献１を参照）、サーバ同士で通信し合うことによりシステムダウンしたサーバを検出したり（特許文献２を参照）するようにしていた。
【０００４】
しかし、このような方法でシステムダウンしたサーバを検出するようにすると、制御用のサーバが必要となるためシステムの構築コストが増えたり、サーバ同士で通信し合う場合にはサーバを追加・削除する際に別のサーバの設定変更が必要となるため手間がかかったりするという問題があった。
【０００５】
【特許文献１】特開２００１−１１７８９９号公報
【特許文献２】特開平６−２５９３６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
前記のごとく、従来の技術では次のような問題点がある。
一般にシングルサーバのシステムよりマルチサーバで構成されたシステムは、高信頼性、及び、高可用性に優れたものであるが、各サーバのシステムダウン検知の方法によっては、例えば、制御用のサーバを備えて他のサーバの監視を行うことでシステムダウンの検出を行うようにした場合には、制御用のサーバが必要となるためシステムの構築コストが増えたり、また、例えば、マルチサーバのサーバ同士で通信し合うことでシステムダウンの検出を行うようにした場合には、サーバを追加・削除する際に別のサーバの設定変更が必要となるため手間がかかったりするという問題があった。
【０００７】
この発明の課題は、センター集中型の帳票配信管理システムをマルチサーバ構成とした場合に、制御用のサーバを備えたり、サーバ同士で通信し合うようにしたりすることなく、システムダウンしたサーバを検出し、他のサーバがこのシステムダウンしたサーバのジョブを引き継ぐことを可能とすることにある。
【課題を解決するための手段】
【０００８】
前記の問題点を解決するために、この発明では次に示す手段を取った。
マルチサーバで共有しているデータベースに、出力先のプリンタを示すフィールドである論理デバイス、帳票配信を実行しているサーバを示すフィールドであるホスト名、帳票配信の開始、終了した日時を示すフィールドである更新日時という３つのフィールドを1レコードにもった配信スレッド監視テーブルを備える。
【０００９】
各サーバには、常駐して帳票の配信を実行する配信サービス内に監視スレッドを備え、当該監視スレッドにより一定間隔ごとに前記配信スレッド監視テーブルを参照し、更新日時フィールドが所定の期間以上更新されていないものを見つけた場合、その配信処理を引き継ぐようにする。
【発明の効果】
【００１０】
この発明により、以下に示すような効果が期待できる。
マルチサーバ構成の帳票配信管理システムにおいて、制御用のサーバを備えたり、サーバ同士で通信し合ったりすることなく、個々の帳票管理サーバが、他の帳票管理サーバとは独立して動作しながら、帳票の配信処理の自動リカバリを行うことができるようになる。
【発明を実施するための最良の形態】
【００１１】
この発明は、次に示す実施の形態を取った。
センターに帳票管理を行うサーバを複数台備える。
【００１２】
これにより、帳票管理を行うサーバの内の何台かに障害が発生し、システムダウンなどが発生した場合でも、残りの正常に動作しているサーバが、システムダウンなどで停止した処理を引き継ぎ、処理を続行することができるようになる。
【００１３】
帳票データファイルや帳票資源（定義体、オーバレイなど）を格納したマルチサーバで共有されるディスクを備える。
【００１４】
これにより、ある帳票配信処理中にシステムダウンが発生した場合でも、その他のサーバがその帳票配信処理に必要な帳票データなどを参照し、処理を引き継ぐことができるようにしている。
【００１５】
帳票管理テーブルや配信スレッド監視テーブルなどを格納したマルチサーバで共用されるデータベースサーバを備える。
【００１６】
これにより、配信スレッド監視テーブルを各サーバの監視スレッドが参照することで、システムダウンしたサーバを特定し、そのサーバの帳票配信処理をその他のサーバが引き継ぐことができるようにしている。
【実施例】
【００１７】
この発明による代表的な実施例を図によって説明する。なお、以下において、同じ箇所は同一の符号を付してあり、詳細な説明を省略することがある。
【００１８】
図１は本発明の帳票配信管理システムの全体構成の実施例を示す。
【００１９】
図に示すように、センター側には複数台の帳票管理サーバ１と、これらのサーバに共用される共有ディスク２とデータベースサーバ３、それと負荷分散装置４を備えている。
【００２０】
拠点側には、帳票出力サーバ５と実際に帳票を印刷する出力装置６を備えている。
【００２１】
センター側の帳票管理サーバ１をマルチサーバ構成とすることで、高信頼性、及び高可用性を備えたシステムとしている。
【００２２】
実際に高信頼性、高可用性を持たせるため、システムダウンしたサーバの処理の引き継ぎをどのように行っているかであるが、図２に示すように、データベースサーバ３のデータベース３ａには、帳票の出力先を示す論理デバイス名フィールドと、その処理を担当している帳票管理サーバを示すホスト名フィールドと、帳票配信の開始、終了の日時を示す更新日時フィールドとを一つのレコードとする配信スレッド監視テーブルをもっている。
【００２３】
この配信スレッド監視テーブルを一定間隔で各帳票管理サーバの配信サービス１ａ中に常駐している監視スレッドで監視し、更新日時フィールドが規定時間以上更新されていないレコードがないか検査し、規定時間以上更新されていないレコードが見つかった場合、配信スレッドを起動して帳票配信処理の引き継ぎを実行する。
【００２４】
具体的な例としては、図３に示すように、例えば、ホストＡが（１）として配信開始時、配信スレッド監視テーブルにレコードを作成する。
【００２５】
（２）として正常に配信された場合、作成したレコードを削除する。（２）としてホストＡがシステムダウンした場合、レコードは削除されず、更新日時が更新されないまま残る。
【００２６】
（３）として別の帳票管理サーバ（ホストＢ）が、配信スレッド監視テーブルを一定間隔でアクセスし、レコードの更新日時が規定時間以上更新されていないかチェックする。
【００２７】
（４）として更新日時が規定時間以上更新されていない場合、ホスト名フィールドをホストＢに更新し、更新日時フィールドも更新する。
【００２８】
これによりホストＢがホストＡの帳票配信処理を引き継ぐこととなるが、ホストＢが引き継いだ後、ホストＡが復旧した場合、配信スレッド監視テーブルのホスト名はホストＢに更新されているため、ホストＡでは、論理デバイスであるＬＤＥＶ１の挿入／更新に失敗し、配信は行われない。よって、同一の帳票が二重で配信されることはない。
【００２９】
システムダウンを検知する監視スレッドの処理を図４に示すフローチャートを使用して説明する。
【００３０】
Ｓ１ステップとして監視スレッドが起動される。
【００３１】
起動された監視スレッドは、Ｓ２ステップとしてデータベースサーバのデータベースに格納されている配信スレッド監視テーブルのレコードを取得する。
【００３２】
配信スレッド監視テーブルのレコードを取得した監視スレッドは、Ｓ３ステップとして各レコードの更新日時と現在の日時とを比較し、規定時間以上更新されていないレコードがないかチェックしていく。
【００３３】
すべてのレコードが規定時間以内に更新されている場合には、Ｓ４ステップとして一定間隔のスリープ状態になり、一定時間が経過するとＳ２ステップに戻って監視処理を続行する。
【００３４】
Ｓ３ステップとして、規定時間以上更新されていないレコードを見つけた場合には、Ｓ５ステップとして、配信スレッド監視テーブルのホスト名／更新日時フィールドを更新し、処理の引き継ぎを行う。
【００３５】
処理の引き継ぎを行った監視スレッドは、Ｓ６ステップとして配信スレッドを起動し、停止していた帳票配信処理を続行し、監視スレッド自体はＳ４ステップに戻って一定間隔のスリープ状態になり、一定時間が経過するとＳ２ステップに戻って監視処理を続行する。
【図面の簡単な説明】
【００３６】
【図１】帳票配信管理システムの全体構成の実施例である。
【図２】配信スレッド監視テーブルの説明図である。
【図３】配信スレッド監視テーブルの更新処理説明図である。
【図４】監視スレッドのフローチャートである。
【符号の説明】
【００３７】
１：帳票管理サーバ
１ａ：配信サービス
２：共有ディスク
３：データベースサーバ
３ａ：データベース
４：負荷分散装置
５：帳票出力サーバ
６：出力装置
【図１】
2006313441.tif 000003
【図２】
2006313441.tif 000004
【図３】
2006313441.tif 000005
【図４】
2006313441.tif 000006