JPH10320338A - Ｃｓｓサーバの一元管理及び処理実行制御方式 - Google Patents

Abstract

(57)【要約】 【課題】ＣＳＳ形態で構成されるシステムにおいて、管
理サーバとして位置付けられたサーバで、全てのサーバ
の稼働状態、アプリケーションの実行状態を管理し、か
つ管理サーバからその他の従属サーバと管理サーバ上で
動作するアプリケーションの実行制御する。 【解決手段】ＣＳＳ形態で構成されるシステムにおい
て、管理サーバ１００に、全サーバのシステム稼働状態
を格納するための連絡ファイル１３０を設ける。管理サ
ーバと従属サーバ間のメッセージの送受信により、連絡
ファイル１３０、２３０の内容を参照・更新し、連絡フ
ァイル１３０に保有された情報に基づき各サーバの稼働
状態の把握・監視を行う。また、各サーバの連絡ファイ
ル１３０、２３０に各サーバでのアプリケーション実行
状態を保有し、連絡ファイル内に保有しているアプリケ
ーション実行状態をチェックすることにより、各サーバ
で実行要求のあった処理の実行可否を判断し、実行可能
な場合に該当する処理を実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＣＳＳ形態のシス
テムにおいてサーバ間の実行処理制御に関し、特に稼働
状態とアプリケーション実行状態といったステータスを
効率良く管理・制御するための一元管理と実行制御方
式。

【０００２】

【従来の技術】従来、ＣＳＳ形態のシステムでは、サー
バ・クライアント・ネットワークといった構成要素につ
いて一定のポーリング方式をもとに、１台のサーバで稼
動状態を管理する方式が採用されている。このような方
式の一例として、特開平４−１５３８５５号公報に記載
されているネットワーク一元管理方式がある。

【０００３】本方式では、複数のホストが複雑に接続さ
れたネットワーク環境において、障害情報を含むネット
ワークの稼動状況情報をそれぞれのホストにおいて採取
し、それぞれのホストはその情報を特定のホストにその
稼動状況情報を送信を行う。その特定のホスト上でのネ
ットワーク稼動状況の集中監視と各種ネットワークの操
作／状態の一元化を実現し、ネットワーク障害の迅速な
把握を目的としている。

【０００４】しかし、このような方式では、サーバ・ク
ライアント・ネットワークといった構成要素の稼動状態
を管理するのみであり、システム全体での整合性のとれ
た運用制御を実現するには至っていない。その一方でＣ
ＳＳシステムにおいては、大規模分散化が急速に進んで
おり、統一的な運用の実現と運用負荷の軽減の為に、シ
ステムの稼動状態の一元管理のみでなく、これらの情報
をもとにして予め設定した実行条件に従い、分散配置さ
れたサーバの運用を制御するための処理実行制御方式が
望まれている。

【０００５】

【発明が解決しようとする課題】上記従来の方式では、
ネットワークの状態を管理する方式として、ネットワー
クに障害が発生した時のオペレータの運用負荷軽減と操
作の簡略化を狙いとしている。従って、オンラインやバ
ッチまたは非稼働状態に区分されるアプリケーションの
実行ステータスに基づく、管理サーバと従属サーバのサ
ーバアプリケーションの実行処理の運用についても、先
に述べたネットワークの運用と同様にサーバ通常運用や
障害運用といった運用局面毎にオペレータに対して運用
負荷がかかると同時にサーバでのコマンド入力等の操作
が発生する。その際の問題点としては、以下のようなこ
とがあげられる。

【０００６】（１）管理サーバと従属サーバについて、
それぞれが接続されているネットワークを含めた、各サ
ーバのＯＳ起動の有無のレベルで考えたサーバの稼働ま
たは非稼働といった、サーバの生死監視については、管
理サーバにより一元管理可能であるが、管理サーバまた
は従属サーバでのオンラインやバッチまたは非稼働のア
プリケーションの実行ステータスについては、各サーバ
で別々に保有しており、管理サーバでの生死監視と同様
な、管理サーバと従属サーバのアプリケーションの実行
処理ステータスの一元管理は不可能であるという問題点
がある。

【０００７】（２）管理サーバや従属サーバでそれぞれ
個別にオンラインやバッチまたは非稼働のアプリケーシ
ョンの実行処理ステータスを保有管理しているため、管
理サーバでは自身のアプリケーションの実行処理ステー
タスは保有管理しているが、従属サーバのアプリケーシ
ョンの実行管理ステータスは保有管理していないため、
各従属サーバのアプリケーションの実行処理ステータス
を意識した形での処理アプリケーションの実行要求を一
括してアプリケーションの実行することはできない。従
って、アプリケーションの実行処理ステータスを管理サ
ーバと従属サーバで保有管理していても、運用の局面に
応じた処理アプリケーションの実行要求は人間系の伝達
手段により、管理サーバと従属サーバの間で、アプリケ
ーションの実行可能処理の同期をとり各サーバでオペレ
ータの操作により、処理アプリケーションの実行要求を
行う方法を取らざるを得ないという問題点がある。

【０００８】本発明では、広範囲のネットワーク環境に
接続されたクライアントサーバ形態のシステムで管理サ
ーバと従属サーバのオンラインやバッチまたは非稼働と
いった各サーバでのアプリケーションの実行処理ステー
タスを管理サーバと従属サーバで個別に保有するのでは
なく、管理サーバで一元管理することに加え、管理サー
バで保有管理している各サーバのアプリケーションの実
行処理ステータスと、予め設定値として定義されたアプ
リケーションの実行条件に従い、各従属サーバでのオペ
レータ操作を必要とせず、管理サーバのみのオペレータ
操作により一括して、各従属サーバにアプリケーション
処理のアプリケーションの実行要求を送信することによ
り、各従属サーバのアプリケーション処理をアプリケー
ションの実行することを実現することを目的とする。

【０００９】

【課題を解決するための手段】本発明では、ＣＳＳ形態
で稼働しているシステム環境下で、複数台のサーバのう
ち１台の管理サーバとその他のサーバである従属サーバ
内で複数のプロセスを生成し処理を実行する機能と、時
刻や個々のサーバ内で動作するプロセスで出力されるメ
ッセージをトリガーとしてプロセスを生成し処理を実行
する機能を用いる。これにより、予め設定された条件に
よる管理サーバと従属サーバ内でのオンラインやバッチ
等のサーバ内アプリケーションの実行処理ステータスの
チェックを行うステータス制御部とアプリケーション実
行要求に対して実行可否を判定し、当該処理の実行制御
を行う実行制御部をそれぞれ独立したプロセスとして生
成し処理を実行することを可能とすると同時に、それぞ
れの機能を相互に出力されるメッセージをトリガーとし
て予め設定された実行条件に基づいて処理の実行制御を
行うことを可能としている。まず、管理サーバのステー
タス制御部は、管理サーバ内で自管理サーバとその配下
にある従属サーバに対応した監視用のプロセスを、それ
ぞれ別プロセスとして起動する。また、従属サーバのス
テータス制御部では管理サーバへのステータス通知を行
うためのプロセスを管理サーバからの起動通知メッセー
ジをトリガーとして起動する。これにより、管理サーバ
のステータス制御部と従属サーバのステータス制御部と
の間で、予め決められた間隔でサーバの生死監視用のメ
ッセージを送受信することにより、管理サーバと従属サ
ーバ毎にそれぞれのサーバの生死監視を行うと同時に、
管理サーバでの自サーバと個々の従属サーバの稼動状態
を管理サーバと従属サーバとの間で必要情報を伝達する
ための連絡ファイルに保有し各サーバの稼動状態の一元
管理を可能としている。また、実行制御部は、常時起動
されているものではなく、予め設定された起動時刻また
は、他プロセスで発生するメッセージをトリガーとして
起動される。起動後は、連絡ファイルに保有している各
サーバのステータスを参照し、それぞれのステータスに
応じた処理を予め設定された実行条件に基づいて実行す
るために、それぞれの処理要求に対応したプロセスを生
成することにより、各サーバ内での実行可能処理の制御
を行う。これと同時に、前記連絡ファイル内に保有する
自サーバのアプリケーション実行状態のステータスを変
更する。

【００１０】さらに、管理サーバと従属サーバの実行制
御部では、管理サーバからの従属サーバへの実行指示
と、それに対する従属サーバから管理サーバへの処理起
動完了通知をメッセージとして送受信することにより、
管理サーバ内の連絡ファイルで保有する管理サーバと個
々の従属サーバのアプリケーション実行状態のステータ
スを変更し、全サーバのアプリケーション実行状態の一
元管理を可能としていると同時に、管理サーバからの従
属サーバに対する実行可能処理の一括制御を可能として
いる。

【００１１】結果として、管理サーバでは、連絡ファイ
ルを利用することにより、自サーバと全従属サーバの稼
動状態とアプリケーション実行状態を一元管理すること
が可能となると同時に、予め定義された内容と自サーバ
と各従属サーバ毎のアプリケーション実行状態を参照す
ることにより実行可能処理を判断し、自サーバと従属サ
ーバに応じた処理の実行を一括制御することが可能とな
る。

【００１２】また、ステータス制御部と実行制御部を管
理サーバでは個々の従属サーバに対応して別々のプロセ
スとして起動しているため、管理サーバでは従属サーバ
毎の稼動状態の管理や処理実行指示による実行処理の制
御が可能である。従属サーバでも他の従属サーバの稼動
状態やアプリケーションの実行状態に関係なく、管理サ
ーバからの処理実行指示に応じた個々のサーバに必要と
される処理の実行が可能である。

【００１３】

【発明の実施の形態】以下、図面を用いて、本発明の一
実施例を説明する。

【００１４】図１は、本発明によるＣＳＳサーバの一元
管理および処理実行制御の仕組みの概念図を示したもの
である。

【００１５】100は管理サーバ、200は管理サーバ100に
よって、運用を制御される従属サーバであり、それぞれ
のサーバは、ネットワーク300を介して接続される。

【００１６】各サーバ内には、ステータス制御部（実行
プロセス）110/210、実行制御部（実行プロセス）120/2
20、連絡ファイル130/230、メッセージ送受信プログラ
ム140/240、その他のプロセス150/250が存在する。

【００１７】管理サーバ100および従属サーバ200のステ
ータス制御部110/210は、それぞれのサーバの稼働状態
を連絡ファイル130/230に書き込んでいる(510)。

【００１８】管理サーバ100内のステータス制御部110
は、従属サーバ200の数だけ存在している。それぞれが
従属サーバ200内のステータス制御部210に対して、メッ
セージ送受信プログラム140/240を利用して、一定間隔
でメッセージを送信している(520)。従属サーバ200のス
テータス制御部210は、その応答として、メッセージ送
受信プログラム140/240を利用して、管理サーバ100内の
ステータス制御部110に対し、メッセージを送信する(53
0)。

【００１９】管理サーバ100において、アプリケーショ
ン起動等の処理要求が入力される(540)と、実行制御部1
20が、連絡ファイル130内の自サーバの状態を読み込み
(550)、処理要求を受け付け可能かチェックする。処理
要求が受け付け可能であれば、連絡ファイル130内の自
サーバステータスを変更し(560)、処理要求に見合った
プロセス150を起動する(570)。

【００２０】さらに、実行制御部120は、連絡ファイル1
30内の従属サーバ200の状態を読み込み(550)、当該処理
要求を行う従属サーバを特定する。そして、メッセージ
送受信プログラム140/240を利用して、従属サーバ200内
の実行制御部220に対し、処理の実行を指示する(580)。
一方、従属サーバ200内の実行制御部220は、連絡ファイ
ル230内の自サーバステータスを読込み(590)、処理要求
を受け付け可能かチェックする。処理要求が受け付け可
能であれば、連絡ファイル230内の自サーバステータス
を変更し(600)、処理要求に見合ったプロセス250を起動
する(610)。そして、プロセスの正常起動後に、管理サ
ーバ100の実行制御部120に対し、メッセージ送受信プロ
グラム140/240を介して、起動完了を通知する(620)。実
行制御部120では、これを受けて、連絡ファイル130内の
従属サーバ200のステータスを変更する(560)。

【００２１】図２は、連絡ファイル130の構成例であ
り、ホスト名称を示すフィールド131、サーバが停止中
か稼働中かといった稼働状態を示すフィールド132、ア
プリケーションの実行状態を示すフィールド133から成
る。また、連絡ファイル230については、１つの従属サ
ーバについて、同様のフィールドから構成される。

【００２２】図３、４、５は、本発明におけるステータ
ス制御部(処理110と処理210)実施例のフローチャートで
あり、図６は同様に実行制御部(処理120と処理220)の実
施例のフローチャートである。また、管理サーバと各従
属サーバのステータス制御部で送受信するメッセージの
フォーマットを図７に、管理サーバと各従属サーバの実
行制御部で送受信する実行指示・起動完了通知メッセー
ジのフォーマットを図８に示す。

【００２３】本処理を開始する場合、まずステータス制
御部(処理110と処理210)を管理サーバと従属サーバ起動
時に開始する。(処理10〜11) ステータス制御部は起動されると、起動されたサーバが
管理サーバか従属サーバかを予め定義されたサーバ定義
情報に基づいて判断する。(処理12) 管理サーバの場合は、各従属サーバのサーバ稼動状態ス
テータスを監視するための監視プロセスの起動処理を実
行する。(処理13) まず、自サーバと各従属サーバのサ
ーバ稼動状態ステータスとアプリケーションサーバ稼動
状態を監視・保有するための連絡ファイルを(ファイル1
30)作成する。(処理14) そして、管理サーバ起動終了
後、自サーバと各従属サーバのステータスを監視するた
めの監視プロセスを自サーバと予め定義している配下に
接続されている従属サーバの数分起動する。(処理15)
起動された監視プロセスは、予め設定された自サーバと
各従属サーバのホスト名称・稼動状態監視間隔・エラー
発生時のリトライ回数・応答待ち時間の定義データを読
み込みステータス監視の制御データの初期設定を行う。
(処理16) ここで初期設定された制御データをもとに、
各従属サーバに対して、サーバの稼動状態を確認するた
めの図７に示すフォーマットの管理サーバ送信メッセー
ジを各従属サーバに対して送信する。(処理18) このメ
ッセージ送信前に、管理サーバではサーバ稼動状態ステ
ータスを更新するための管理プロセスを起動する。(処
理17) さらに、監視プロセスは、監視プロセスプログラ
ム内部で保有しているテーブル内のメッセージ送信終了
フラグを「ＯＮ」にし、制御データに設定した応答待ち時
間が経過するまでの間、各従属サーバからの図７に示す
フォーマットの管理サーバ受信メッセージの受信待ちを
する。(処理19) 応答待ち時間内に各従属サーバからの
サーバ稼動中の応答メッセージ受信した場合(フィール
ド86が稼働中のヒ゛ット)、監視プロセスは、先の送信終了
フラグを「ＯＦＦ」にする。また、この時管理プロセスに
対してサーバ稼動状態ステータスの更新要求を発行し、
管理プロセスではその従属サーバは稼動状態と判定し、
サーバ稼動状態ステータス(フィールド132)を「稼動中」
にする。(処理21) この一連の処理(処理17〜21)を制御
データに設定した稼動状態監視間隔で管理サーバと各従
属サーバの間でメッセージの送受信を行うことにより、
管理サーバでの各従属サーバの稼動状態ステータスの一
元管理を継続実施する。

【００２４】また、管理サーバは、各従属サーバからの
管理サーバ受信メッセージを応答待ち時間内に受信でき
なかった場合、監視プロセスは制御ファイルに設定した
リトライ回数分、管理サーバと従属サーバの間でメッセ
ージの送受信を実行し(処理22)、その間１度も管理サー
バで従属サーバからの応答メッセージを受信出来ない場
合(無応答状態)は、その従属サーバは停止状態と判断し
て、管理プロセスはサーバ稼動状態ステータス(フィー
ルド132)を「停止中」にする。(処理19、23) また、従属
サーバからの管理サーバ受信メッセージがサーバ停止を
表すメッセージの場合（フィールド86が停止中のビッ
ト）も、管理プロセスはサーバ稼動状態ステータス(フ
ィールド132)を「停止中」にする。そして、管理サーバか
らのサーバ稼動状態ステータス(フィールド132)が「停止
中」の従属サーバに対する先に示した管理プロセスを終
了する。(処理24) しかし、監視プロセスは先に示した
処理17〜20の処理を繰り返しており、この間に従属サー
バから管理サーバに対して、サーバ稼動中の管理サーバ
受信メッセージを再受信した場合は、処理17に示す管理
プロセスの起動を行う。(処理28〜30) 管理プロセスは
サーバ稼動状態ステータス(フィールド132)を「稼動中」
にし、管理サーバからの稼動状態監視を継続する。

【００２５】また、管理サーバではオペレータからの監
視終了要求または、管理サーバのシステム終了処理(シ
ステム停止処理)時に、ステータス制御部の終了処理を
実行し、管理プロセスを停止し、連絡ファイル(ファイ
ル130)をクリアし、その後起動している監視プロセスを
終了する。(処理25〜27) 一方、各従属サーバでは、管理サーバと同様に監視プロ
セスを起動する。(処理31) また監視プロセスは、起動
処理中に管理サーバと同様のフォーマットを持つ連絡フ
ァイル(ファイル230)を作成する。そして、自サーバの
サーバ稼動状態を更新するための管理プロセスを起動す
る。(処理32) 従属サーバの監視プロセスでは、管理サ
ーバから一定間隔で送信されるメッセージを受信し、そ
れに対する応答メッセージを管理サーバに向けて送信す
る。(処理33、37) また、送信時に管理サーバと同様に
管理プロセスに対して自サーバの稼動状態更新要求を行
い、連絡ファイル(フォーマット230)内のサーバ稼動状
態ステータス(フィールド132)を「稼動中」にする。(処理
38) この処理(処理33〜34、37〜38)を管理サーバからの
監視終了メッセージ受信時または、オペレータによる監
視終了コマンド投入まで繰り返し実行する。但し、管理
サーバからの送信メッセージが監視終了メッセージの場
合または、オペレータからの監視終了コマンド投入時
は、監視プロセスは、管理プロセスを停止し連絡ファイ
ル(ファイル230)をクリアする。その後、ステータス制
御部は監視プロセスの終了処理を行う。(処理35〜36) 実行制御部(処理120、220)は、ステータス制御部のよう
に常時起動されているものではなく、予め設定された時
刻または、各サーバ内他プロセスで出力するメッセージ
をトリガーとして、起動される。(処理50、51) 実行制
御部も先に述べたステータス制御部と同様に、予め定義
されたサーバ定義情報に基づいて、起動されたサーバが
管理サーバか従属サーバかを判断する。(処理52) 管理
サーバの場合は、予め設定された自サーバと各従属サー
バの実行処理定義ファイル(ファイル90)を実行制御部の
内部情報として保持し、起動対象処理の確定を行う。
(処理53) 先に述べた時刻または他プロセスで出力する
メッセージをトリガーとして起動されると、ステータス
制御部で更新・管理している連絡ファイル(ファイル13
0)の内部に保有する、サーバ稼動状態ステータス(フィ
ールド132)とアプリケーション実行状態ステータス(フ
ィールド133)のチェック処理を実行する。(処理54) こ
のチェック対象としている自サーバまたは従属サーバの
それぞれについて、稼動状態が「稼動中」かつ実行しよう
としているアプリケーション処理が未実行状態であれ
ば、自サーバもしくは従属サーバに対して、図８に示す
フォーマットの管理サーバ送信メッセージを用いて実行
指示処理のＩＤ（フォーマット91、フォーマット90が起
動要求のビット）を送信する。(処理55〜56) 自サーバ
または従属サーバの稼動状態が「停止中」もしくは実行し
ようとしているアプリケーション処理が既に実行済みで
ある場合は、何も処理をせずに管理サーバの実行制御部
の処理を終了する。(処理60) その後、自サーバ内での
実行完了応答または、従属サーバからの図８に示すフォ
ーマットの管理サーバ受信メッセージ送信されるで該当
処理の起動完了通知（フォーマット94が起動完了のビッ
ト）の受信待ち状態に入る。(処理57) 実行指示を受けた従属サーバでは、その実行指示受信に
従い、自サーバ内の実行制御部の起動を行う。(処理61)
実行制御部の起動終了後、従属サーバの実行制御部は
該当する処理が未実行か否かを自サーバ内に保有してい
る連絡ファイル(ファイル230)を参照し、再チェックを
実行する。(処理63)この再チェックを行うことにより、
管理サーバと従属サーバ間の伝送上の制御電文のすれ違
いによる２重起動を防止している。チェックの結果、未
実行であれば管理サーバからの実行指示を受けた処理を
実行する。(処理64)その処理の正常終了を受けて、自サ
ーバ内の連絡ファイル(ファイル230)のアプリケーショ
ン実行状態ステータス(フィールド133)を更新する。(処
理65) 実行指示を受けた処理が正常終了しなかった場合
は、アプリケーション実行状態ステータス(フィールド1
33)の更新は実行しない。またチェックの結果、実行指
示を受けた処理が既に起動されている状態にある場合
は、実行指示を受けた処理の実行は行わず、アプリケー
ション実行状態ステータス(フィールド133)の更新も実
行しない。いずれの場合もアプリケーション実行状態ス
テータス(フィールド133)に対する処理が終了した時点
で、管理サーバ受信メッセージ（図６）で起動完了の旨
を管理サーバ側へ通知する。(処理66) 従属サーバの実
行制御部の処理は、この起動完了通知のメッセージの送
信完了後終了する。(処理67) 管理サーバ側ではこの管理サーバ受信メッセージを受信
し、メッセージの待ち状態を解除する。(処理62) 受信
した管理サーバ受信メッセージの内容が、実行指示した
処理が正常終了（フォーマット94が起動完了のビット）
した場合は、管理サーバ内の連絡ファイル(ファイル13
0)のアプリケーション実行状態ステータス(フィールド1
33)を更新を行い、管理サーバの実行制御部の処理を終
了する。(処理59〜60) 実行指示した処理が正常終了し
なかった場合は、正常終了しなかった旨のエラーメッセ
ージを出力し、アプリケーション実行状態ステータス
(フィールド133)を更新せず、管理サーバの実行制御部
の処理を終了する。(処理60)また、実行指示した処理が
既に実行されていた場合は、管理サーバ受信メッセージ
の受信だけを行い、アプリケーション実行状態ステータ
ス(フィールド133)を更新せず、管理サーバの実行制御
部の処理を終了する。また、管理サーバ自体の実行指示
に対する処理も、従属サーバでの処理と同様に実行指示
した処理の正常終了時は、自サーバのアプリケーション
実行状態ステータス(フィールド133)を更新し、管理サ
ーバの実行制御部の処理を終了する。実行指示した処理
が正常終了しなかった場合は、正常終了しなかった旨の
メッセージを出力し、アプリケーション実行状態ステー
タス(フィールド133)を更新せず、管理サーバの実行制
御部の処理を終了する。

【００２６】

【発明の効果】本発明の実施例によれば、次のような効
果がある。

【００２７】(１)大規模なＣＳＳ形態の分散系システム
において、１台の管理サーバでネットワーク上に接続さ
れる従属サーバ全ての稼動状態を生死監視ならびにアプ
リケーション実行状態として一元管理できる。

【００２８】(２)個々のサーバに関する障害を迅速に把
握することが可能となる。

【００２９】(３)管理サーバで自サーバも含め個々の従
属サーバの実行可能処理を予め設定された条件により実
行可否を判断し、それに基づき管理・従属サーバではア
プリケーションを実行することが可能なため、オペレー
ションレスでのアプリケーションの実行制御が可能とな
る。

【００３０】(４)管理サーバでのステータス制御部・実
行制御部は、各従属サーバ毎に別プロセスとして起動さ
れることから、個々の従属サーバ個別の稼動状態監視・
アプリケーション実行制御が可能となる。

【図面の簡単な説明】

【図１】ＣＳＳサーバの一元管理と処理実行制御の仕組
みの概念図である。

【図２】連絡ファイル構成例である。

【図３】ステータス制御部のフローチャート例である。

【図４】ステータス制御部のフローチャート例である。

【図５】ステータス制御部のフローチャート例である。

【図６】実行制御部のフローチャート例である。

【図７】ステータス制御部の送信メッセージフォーマッ
ト例である。

【図８】実行制御部の送受信メッセージフォーマット例
である。

【符号の説明】

１００…管理サーバ、 ２００…従属サ
ーバ、１１０、２１０…ステータス制御部、 １２０、
２２０…実行制御部、１３０、２３０…連絡ファイル、
１５０、２５０…その他のプロセス、３００…ネ
ットワーク、 ５１０…書き込み、 ５２０…送
信、５３０…応答、 ５４０…処理要求、５５
０、５９０…読み込み、 ５６０、６００…変
更、５７０、６１０…起動、 ５８０…実行指示、
６２０…起動完了通知、１３１…ホスト名、 １
３２…サーバ稼働状態、１３３…アプリケーション実行
状態、８１、８４、８８、９２…従属サーバホスト名、
８２、８５、８９、９３…電文種別、８３、８６、９
０、９４…制御コード、８７、９６…付加メッセージ、
９１、９５…実行指示処理ＩＤ。

Claims (2)

【特許請求の範囲】
1. 【請求項１】同一ネットワークに接続されているクライ
   アントサーバシステム（ＣＳＳ）形態で稼働している複
   数台のサーバ内に、それぞれステータス制御部とアプリ
   ケーションの実行制御部を設け、複数台のサーバのうち
   １台を管理サーバとして位置付け、その他のサーバを従
   属サーバとして位置付けて、これらの管理サーバと従属
   サーバの間で必要な情報を伝達するための連絡ファイル
   を管理サーバと従属サーバにそれぞれ設け、前記のステ
   ータス制御部では、予め設定された条件により管理サー
   バと従属サーバ間でメッセージを送受信することにより
   各サーバの稼働状態を監視し、その結果を前記の連絡フ
   ァイルに出力する。さらに前記アプリケーションの実行
   制御部では、オンラインやバッチ等のサーバ内アプリケ
   ーションの実行処理ステータスのチェックを行い、その
   結果を前記連絡ファイルに出力し、管理サーバで管理サ
   ーバと従属サーバでのアプリケーションの実行処理ステ
   ータスの一元管理を可能とし、各サーバの稼働状態とア
   プリケーション処理ステータスを一元管理することを特
   徴とするＣＳＳシステムにおけるＣＳＳサーバの一元管
   理及び処理の実行制御方式。
2. 【請求項２】前記連絡ファイルを利用し、一定間隔で管
   理サーバへ送信される複数台の従属サーバのオンライン
   やバッチ等のサーバ内アプリケーションの実行処理ステ
   ータスを管理サーバで参照を行い、管理サーバのアプリ
   ケーションの実行制御部は、オペレータや定刻に起動さ
   れる管理サーバまたは従属サーバに対する一括処理実行
   要求に対して、各管理サーバまたは従属サーバの管理サ
   ーバ内の連絡ファイルに保有するアプリケーションの実
   行処理ステータスに応じた実行可能アプリケーション処
   理を判定し、アプリケーションの実行制御することを特
   徴とするＣＳＳサーバの一元管理及び処理実行制御方
   式。