JPH1074159A

JPH1074159A - 計算機システムの制御方法

Info

Publication number: JPH1074159A
Application number: JP8229693A
Authority: JP
Inventors: Chisato Konno; 千里金野; Katsuro Kikuchi; 克朗菊地
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1996-08-30
Filing date: 1996-08-30
Publication date: 1998-03-17
Also published as: US6078955A

Abstract

(57)【要約】（修正有）【課題】複数の計算機群より構成される計算機システ
ムにおいて、各ユーザはその計算機システム上で所有し
ているファイル群およびプログラム群をどの計算機から
でも同一のインタフェースで利用できること。【解決手段】計算機システム内のある特定の計算機Ａ
１０５が、この計算機システムに属する各計算機のＣＰ
Ｕやファイルやメモリなどの計算機資源情報および稼働
状況情報と、ファイルデータやプログラムなどのユーザ
資産情報を管理する。この計算機システムを構成する計
算機Ｃ１０６からユーザが介入要求を出すと、その要求
はまず該計算機Ａに報告され、該計算機Ａの所有するユ
ーザ資源情報を参照してそのユーザに該当する情報を計
算機Ｃに戻す。計算機Ｃは、その情報を用いて、この計
算機システム内にユーザの所有するファイルと使用可能
なプログラムを把握し、実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】複数の計算機がネットワーク
で接続されて利用される計算機システムを複数のユーザ
が複数の種別の計算機を介して利用する計算機システム
において、計算機システム全体を一体として各ユーザの
計算機資源として利用可能とし、複数の計算機から構成
されている事および該システムに介入する計算機の種別
を意識させることなく利用できる環境を提供する、計算
機システムの制御方法。

【０００２】

【従来の技術】従来の複数の計算機がネットワークで接
続されて利用される計算機システムは、利用する個々の
計算機の違いや、利用するファイルやプログラムの計算
機システム内での所在を意識して、計算機システムに指
示（処理の依頼）を与える事が前提であった。プログラ
ムの存在する計算機にリモートログインで介入するかリ
モートプロシージャコールで、その計算機上でのプログ
ラムの実行を指示するが、実行に先だってプログラムの
必要とするファイルは予め該計算機上に移動しておく必
要があった。

【０００３】これに対して、計算機システム全体のプロ
グラムの所在とプログラム間の連携を保証する米Object
Management Group(OMG) が提案するCORBA(Common Obje
ct Request Broker Architecutue) 仕様によれば、予め
本仕様のORB(Object RequestBroker) に登録しておけ
ば、該計算機システム上の実所在を意識しなくてもプロ
グラム群の利用や連携を実現することが可能である。し
かし、本仕様の定めるところは、予めORB に登録された
プログラムの所在を論理的にみせることであり、プログ
ラムの所在は予め登録された計算機に固定されている。
また、計算機システムの全体リソースの最適な使用に関
しては、何も規定していない。

【０００４】また、従来の複数の計算機がネットワーク
で接続されて利用される計算機システムは、計算機シス
テムに介入する計算機上でなんらかの処理プログラムを
行なう際に、プログラムやファイルが該計算機上に存在
しない場合には、ネットワークを介して計算機システム
内から取り寄せることが可能であるが、その際、全てユ
ーザが明示的に計算機にその取り寄せを指示する必要が
あった。

【０００５】また、従来の複数の計算機がネットワーク
で接続されて利用される計算機システムは、計算機シス
テムに介入する計算機（端末）に依存して、インタフェ
ースが異なっていた。しかもその上から依頼できる処理
の種類も介入した計算機に依存していた。

【０００６】

【発明が解決しようとする課題】計算機群より構成され
る計算機システムにおいて、各ユーザがその計算機シス
テム上で所有しているファイル群および利用できるプロ
グラム群は該ユーザにとっては不変で、どの計算機を介
して計算機システムに介入しようと、全く同一のインタ
フェースで利用できることを保証する計算機システムの
制御方法を提案することにある。また、計算機システム
内のファイルおよびプログラムを利用した処理の実行に
おいて、ユーザは対象プログラムやファイルの物理的な
所在箇所を一切意識する必要がない計算機システムの制
御方法を提案することにある。また、計算機システムの
処理の実行場所は、依頼された処理の性質や負荷および
その時点での計算機システム利用状況から動的に決定さ
れる計算機システムの制御方法を提案することにある。

【０００７】

【課題を解決するための手段】複数の計算機群からなる
計算機システムにおいて、この計算機システム内のある
特定の計算機Ａが、この計算機システムに属する各計算
機のＣＰＵやファイルやメモリなどの計算機資源情報お
よび稼働状況情報と、ファイルデータやプログラムなど
のユーザ資産情報を管理する手段を有する。この計算機
資源情報とユーザ資源情報は、随時各計算機から該計算
機に報告する手段を持つ。この計算機システムに対し
て、ユーザがいずれかの計算機Ｃから介入要求を出す
と、その要求はまず該計算機Ａに報告する手段を有し、
該計算機Ａの所有するユーザ資源情報からそのユーザに
該当する情報を計算機Ｃに戻す手段を有する。計算機Ｃ
は、その情報を用いて、この計算機システム内にユーザ
の所有するファイルと使用可能なプログラムの一覧を計
算機Ｃのディスプレイ上にインタフェースとして表示す
る手段を有する。これにより、ユーザが介入してくる計
算機に依らず、システム内に於てユーザ資産の不変的な
管理が可能となる。

【０００８】また、計算機Ａからプログラムを発信し
て、該プログラムはネットワークに接続されている計算
機を巡回して、新たに接続された計算機を検出する手段
を有する。新たに検出された計算機には、上記計算機資
源情報とユーザ資源情報を計算機Ａに報告するプログラ
ムを移植する手段を有し、該計算機システムのリソース
の一員として使用が可能となる。

【０００９】計算機Ｃから上記インタフェースを介し
て、計算機システム内のファイルとプログラムを用いた
処理の要求が指示されると、この要求指示はまず計算機
Ａに送付され、計算機Ａはそのファイルとプログラムの
物理的な所在位置および上記計算機資源情報に基づい
て、その処理を実行する計算機（群）を決定する手段を
有し、その決定に基づいて、必要であればファイルもし
くはプログラムを転送して処理を実行する手段を有す
る。処理が終了するとそれを依頼元の計算機Ｃに報告す
る手段を有する。また、処理を実行した計算機では、転
送されたファイルやプログラム、および処理の結果生成
された新たなファイルデータは、必要に応じて別の計算
機にそれを送付するか、削除するか、あるいは該計算機
上の新たなユーザ情報資源として、計算機システムを統
括する計算機Ａに報告する手段を有する。これにより、
ユーザはファイルやプログラムの実際の物理的な所在箇
所を意識することなく、かつ要求した処理の最適な実行
場所で処理を実行することが可能となる。

【００１０】

【発明の実施の形態】本発明の一実施例を第１図から第
１８図を用いて説明する。

【００１１】最初に本発明の達成しようとする概念とシ
ステムの構成を第１図を用いて説明し、ついで各処理部
の詳細フローを説明する。

【００１２】第１図に本発明の対象となるネットワーク
１０１で接続された複数の計算機群からなる一般的な計
算機システムを示している。計算機の中には多数のユー
ザによって共用されるサーバと、主に（特定とは限らな
いが）一人のユーザが占有して用いる端末１０４があ
る。また、本システムでは、本発明の中心的な役割を果
たす統括サーバ１０２を設けており、該サーバは計算機
システム内の全ての計算機資源や計算機上で行なわれる
全てのJob （計算機の処理単位）を管理すると共に、全
てのユーザ情報を管理する。

【００１３】初めに動作原理を説明する。端末１０４か
らの処理要求は全て一旦統括サーバ１０２に暗黙の内に
送付される。統括サーバでは、処理要求に対応するプロ
グラムとファイルの所在を検証し、かつネットワーク内
のサーバのその時点での処理負荷と処理対象となるファ
イルとプログラムの性質や所在箇所から、その処理に最
も効率的と判断できる計算機（サーバもしくは端末）を
決定し、端末に該処理の実行場所（接続サーバアドレ
ス）を通知し、端末はその通知情報に従って、該当する
計算機に処理を依頼して実行する。その際、ファイルや
プログラムの移動が必要な場合は、統括サーバが予め移
動処理を行なっておく。ここで、ユーザ自身は処理の依
頼を行なうだけで、上記動作は端末や統括サーバおよび
サーバ群上に設置されたプログラム（以下ではそれぞれ
のプログラム単位をAgentと呼ぶ）が暗黙の内に実行す
る。

【００１４】この動作を実現するために、統括サーバ１
０２にはシステム統括Agent （プログラム）１０５が、
各サーバ群１０３にはそれぞれサーバ管理Agent１０６
が、端末には端末管理Agent１０７の各プログラムが配
置されている。また、統括サーバから発信される、リソ
ース管理Agent １０８が用意されている。

【００１５】システム統括Agent１０５は、ユーザ管理
情報とシステムリソース管理情報と利用可能なアプリケ
ーションプログラムの情報１１０を有している。各サー
バの稼働状況やリソース管理情報を、サーバ管理Agent
から受け取り、前記情報の更新をすると共に、端末から
送信されてきた処理依頼に対して、処理をする計算機の
決定とファイルやプログラムの移動を行なう。

【００１６】サーバ管理Agent１０６は、該当サーバの
リソース管理情報（CPU、ファイル、メモリなどのハー
ドウェアリソース、ユーザファイルデータやプログラム
などのソフトウェアリソース）および稼働状況情報を検
出し、統括サーバ１０２に該情報を送信する。この検出
処理は定期的もしくは該当サーバ上のあるJobの起動／
終了を契機に行なわれるように設定しておく。

【００１７】端末管理Agent１０７は、ユーザ情報や端
末情報を検出して統括サーバに送付すると共に、ユーザ
の処理要求を統括サーバ１０２へ送付してシステム統括
Agent１０５からの該処理の実行場所となる接続サーバ
アドレスの指示に従って、そのサーバと接続して処理を
実行する。

【００１８】リソース管理Agent１０８は、ネットワー
クへの新しいサーバの接続に対して統括サーバより新規
接続サーバ１０９へ送付され、サーバ管理Agent１０６
のインストールを行なうことにより、新サーバをネット
ワークシステム内の一部として利用可能とする。

【００１９】次に、処理の詳細フローを説明する。第２
図はより具体的な処理の全体フローと後続の詳細フロー
図との対応を示している。

【００２０】初めに、システム統括Agent１０５とサー
バ管理Agent１０６の処理による、各サーバのシステム
リソースの情報や稼働状況情報の収集・管理のメカニズ
ムを第２図、第３図〜第５図を用いて説明する。

【００２１】第２図において、サーバ群１０３における
各サーバに常駐するサーバ管理Agent１０６によって、
該サーバのシステムリソース情報や稼働状況情報が取得
され、該情報２０５は統括サーバ１０５に送付される。
送付された情報は、システム統括Agent１０５により、
システムリソース管理情報ファイル２０３に格納する。

【００２２】第３図にサーバ管理Agentプログラム１０
６の動作フローを示す。サーバ管理Agentは、ＯＳから
のタイマー割り込み、プログラムによるリソースの開放
割り込み、もしくはプロセス起動／終了割り込みを待っ
て、以下の動作を開始する（３０１）。初めに、ファイ
ルとプログラムリソースの変更情報の収集を行なう（３
０２）。これは、ＯＳの命令を使って、生成もしくは更
新された日時情報を利用することにより実現することが
できる。ついで、サーバリソースを検出する一番最初の
時だけ、ハードウェアリソース（CPU、メモリ、ファイ
ル）の能力と容量を検出する（３０３）。これは、静的
な情報なので、最初の一回だけやればよく、これもＯＳ
の機能を利用することで実現できる。ついで、ハードウ
ェアリソースの使用状況情報を同じくＯＳの機能を利用
して収集する（３０４）。収集情報の詳細は第５図で説
明する。収集された情報をシステム統括サーバへ送付す
る（３０５）。ついで送付されたデータ３０６は、第４
図によって処理される。

【００２３】第４図に、システム統括サーバにおいて、
サーバ管理Agentより収集された情報４０１を入手・管
理するフローを、第５図に、収集・管理される情報の一
覧と格納ファイルフォーマットを示す。システム統括Ag
ent１０５はサーバ管理Agentより送付されてきた情報を
入手する（４０２）。入手情報に従って、システムリソ
ース管理情報ファイル（第５図）の内容を更新する（４
０３）。

【００２４】システムリソース管理情報テーブル２０３
のヘッダ部分５００は、個々のサーバ計算機を特定する
計算機名、計算機を特定するCPU-ID、システムのネット
ワーク内のアドレスを示すＩＰアドレスなどの情報を有
し、ポインタによって更に詳細情報のテーブルにリンク
されている。該ポインタは、格納情報を分類した複数の
サブテーブルを更にさすポインタ群を持つ、ポインタテ
ーブル５０１をさしている。各サブテーブルは、計算機
のハードウェア上のリソースを示すハードリソーステー
ブル５０２、各時点でのハードリソースの使用状況を記
録する稼働状況テーブル５０５、このサーバ上のファイ
ルに格納されている情報を記録するファイル管理テーブ
ル５１０などからなる。また、必要に応じてその他の情
報５２０も、このポインタテーブルからリンクされた同
一形式のサブテーブルによって管理される。

【００２５】ハードリソーステーブル５０２は、基本的
にはハードウェアの改変や増設がない限り静的な情報
で、第３図の３０３によって収集される。稼働状況テー
ブル５０５は、第３図３０１の割り込みを契機に収集さ
れるハードウェアのその時点での稼働状況を記録してお
くもので、収集日時５０６、CPU利用状況５０７、メモ
リ使用状況５０８、ファイル使用状況５０９などが格納
される。ファイル管理テーブル５１０には、そのサーバ
のファイルに格納されている情報に対して、ファイル名
称５１１、ディレクトリ名やフォルダ名等の所在位置５
１２、ファイルデータなのかプログラムなのかを示す種
別５１３、プログラムの場合に対話実行（I）されるも
のか、バッチ実行（B）されるを示す属性、そのファイ
ルの所有者のユーザＩＤ５１５、ファイルのコピーや他
のユーザの利用範囲を示すアクセス権限５１６、ファイ
ルの容量およびプログラムの場合には実行に際して必要
となるメモリおよびCPUパワーなどの負荷量５１７など
が格納されている。

【００２６】これにより、各サーバの所有するハードウ
ェアリソースとソフトウェアリソースが管理され、ま
た、各時点での稼働状況情報が管理される。第３図の各
サーバ管理Agentから送られてくるデータ３０６の形式
は、本テーブルの形式をそのまま利用することが可能だ
が、採取した更新情報だけに圧縮した形式であってもよ
い。

【００２７】また、第３図の実施例では、タイマー割り
込み、リソース開放割り込み、プロセス起動／終了割り
込みの各割り込みに対して同一の収集処理を行なう例を
示したが、各割り込みの種別に応じて、採取するデータ
を、第５図のサブテーブルの一部に特定する事も可能で
ある。例えば、タイマー割り込みに対しては、稼働状況
テーブル５０５に該当する情報のみを採取する等の変形
が考えられる。

【００２８】再び第２図にもどって、次に、システム統
括Agent１０５と端末管理Agent１０４の処理による、ユ
ーザ管理情報の登録やlogin端末に依存しないユーザの
操作性の実現方法を、第２図と、第６図〜第９図を用い
て説明する。

【００２９】第２図において、ユーザがloginすると、
端末管理Agentによって、login情報とloginに使用して
いる端末情報２０６が統括サーバ１０２に送付される。
統括サーバ上のシステム統括Agent１０５は、ユーザ管
理情報２０２（第８図）をアクセスして、login処理を
行なうと同時に、このネットワークシステム全体におい
て、該ユーザが所有しているファイル情報と利用可能な
プログラムなどの一覧であるユーザ情報２０７を端末管
理Agentに返送する。端末管理Agentは、その情報を利用
して、どの端末からユーザがloginしてこようと変わら
ないユーザインタフェース（第９図）を画面に表示し
て、ユーザの操作を支援する。

【００３０】第６図は、システムにユーザが初めて登録
する際の動作フローである。まず、端末より、ユーザ登
録情報６０２を入力する（６０１）。この処理は通常は
システムで決められた特定のユーザ（システム管理者
等）もしくは端末からのみ操作可能である。システム統
括Agentは、ユーザ登録情報に基づいて、アカウント、
パスワードの設定、およびファイルなどのユーザ資産の
登録をユーザ管理ファイル（第８図）に対して行なう
（６０４）。以後、ユーザはシステムのユーザとして、
第７図の処理により、システムにloginが可能となる。

【００３１】第７図が端末管理Agentによるユーザのlog
inの処理フローである。初めに、ユーザのlogin情報と
して、アカウントおよびパスワードの入力を行なう（７
０１）。ついで端末管理Agentプログラムは、loginに使
用している端末情報を抽出する（７０２）。端末情報
は、第８図８０９のテーブルにあたる。ついで抽出した
login情報と端末情報７０４をシステム統括サーバのシ
ステム統括Agent１０５に送付する（７０３）。

【００３２】ここで、第８図を用いて、ユーザ管理情報
ファイル（第２図２０２）のテーブル内容に関して説明
する。ユーザ管理情報テーブルは、個々のユーザID、対
応するパスワードのリストをヘッダにした階層テーブル
で構成され、ポインタによって更に詳細情報のテーブル
にリンクされている（８００）。該ポインタは、格納情
報を分類した複数のサブテーブルを更にさすポインタ群
を持つ、ポインタテーブル８０１をさしている。各サブ
テーブルは、ユーザの利用上の権限や課金、使用料金の
総計や上限といったユーザ管理テーブル８０２、該ユー
ザがネットワークシステム内全域で所有もしくは利用可
能なファイルの一覧を示すユーザ資産ファイル管理テー
ブル８０３、ユーザがシステムへのloginに用いた端末
に付随する情報を有するlogin端末管理テーブル８０９
などからなる。また、必要に応じてその他の情報８２０
も、このポインタテーブルからリンクされた同一形式の
サブテーブルによって管理される。ユーザ資産ファイル
は第５図のファイル管理テーブル５１０から該当ユーザ
のアクセス権限のあるものだけを抽出したもので、情報
もファイル名称８０４、所在位置８０５、種別８０６、
属性８０７に絞られている。login端末管理テーブル８
０９は、login端末のIPアドレス、端末の計算機能力と
してCPU性能、メモリ容量（絶対容量と使用量）、ファ
イル容量、ディスプレイ表示能力（画面サイズと表示色
など）を有する他、端末がローカルに所有する資産ファ
イルテーブルへのポインタを有している。端末資産ファ
イル管理テーブル８１０は、テーブル内容は第５図のフ
ァイル管理テーブル５１０と同一形式の情報を保持す
る。

【００３３】第７図にもどって、端末からの送付情報に
基づいて、第８図８００のテーブルを用いてlogin情報
のチェックを行ない、端末情報の登録（具体的には第８
図８０１、８０９、８１０の生成）を行なう（７０
５）。ここで、省略しているが、勿論登録情報が誤りや
不備の場合にはその旨端末に報告し、以降の処理は行な
われない。次いで、該ユーザの所有ファイルおよび利用
可能ファイル（プログラムを含む）を抽出する。これは
第８図のユーザ管理ファイル８００、８０１を辿って、
８０３のテーブルを参照すればよい。次いで抽出したユ
ーザ情報を端末に送付する（７０７）。送付されたユー
ザ情報７０８を用いて、端末管理Agentは、用いている
端末に依存しないユーザインタフェースを構築して表示
する（７０９）。

【００３４】ここで想定する端末に依存しないユーザイ
ンタフェースの実施例を第９図に示す。従来のユーザイ
ンタフェースは、端末毎にインストールされているオペ
レーティングシステムのウィンドウに依存した固有の表
示となる点と、端末以外のネットワークシステム内に存
在するユーザ資産の表示がなされないか、なされても特
定のコマンド等を用いて異なったウィンドウに表示され
る点など、使用する端末に大きく依存していた。本発明
のインタフェースは、端末も含めたネットワークシステ
ム全域におけるユーザ資産を、使用する端末に依存する
ことなく、表示することを特徴としている。ユーザのネ
ットワークシステム内で所有するファイルや使用可能な
プログラムは、上述のユーザ管理テーブル（第８図）の
参照により全て抽出することができ、これは第７図のユ
ーザ情報７０８としてシステム統括Agentより端末管理A
gentに送付されている。また、端末ローカルに所有する
ファイルは第８図８１０を参照してもよいが、これはも
ともと端末から送付された情報で端末側にあるものであ
る。従って、該端末を用いてシステム内で処理を行なう
際の使用可能なファイルとプログラムの全ての情報は端
末管理Agentが保有している。ユーザが計算機に指示を
与える場合には、用いるファイル（データ）、処理の単
位となるプログラム、そして処理の手順を表すプロシー
ジャ部分からなる。これを、第９図に示すようにファイ
ル９０１、プログラム９０２、プロシージャ９０３のよ
うに、分別してシステムで共通の表示方法（例えばアイ
コン）によって表示する。ただし、実際のそのファイル
の物理的な所在箇所をユーザに意識させる必要はなく、
ユーザのつけた論理的な名称で表示される。ただし、所
在を意識したいユーザに対しては、端末（ローカル）、
サーバ、メインフレーム（バックエンドサーバ）位の階
層的位置をウィンドウ上に９０５、９０６、９０７のよ
うに設けて、該当するファイルのアイコンをその範囲に
表示すればよい。これはプログラムに対しても同様であ
る。プロシージャに対しては、ファイルやプログラムを
組み合わせて処理の手順が記述できるツールのアイコン
を９０８のように表示し、それを選択することで詳細の
記述をうながすサブウィンドウを表示すればよい。この
インタフェースを用いて、ユーザは処理の指定を行な
う。以上の記述で明らかなように、画面の構築にあたっ
て、端末やシステムに固有の情報は一切利用していない
ので、いかなる端末からloginしようと共通のユーザイ
ンタフェースを表示することが可能である。次にこのイ
ンタフェースを用いて指示された処理を端末管理Agent
にどのように解釈して、実際の処理を実現するかについ
て説明する。

【００３５】再び第２図にもどって、次に、システム統
括Agent１０５と端末管理Agent１０４のもう一つの処理
である、端末から端末管理Agentを介して依頼された処
理に対する統括管理サーバでの処理実行場所の決定方法
およびそれに基づく処理の実行方法を、第２図と、第１
０図〜第１５図を用いて説明する。

【００３６】初めに第２図でフローの概要を述べる。端
末より上記インタフェースを介してJob依頼２０８が統
括サーバ１０２に送付されると、システム統括Agent１
０５は、ユーザ管理情報２０２とシステムリソース管理
情報２０３の情報を用いて、ファイルやプログラムの物
理的な所在位置を検出する。更に、処理の実行に際し
て、システム全体にとって最も適切と考える計算機（サ
ーバもしくは端末）を決定し、接続サーバアドレス２０
９を端末に送付する。また、必要であれば、ファイルや
プログラムがシステム統括Agentによってローディング
される（２１１、２１２）。端末管理エージェントは接
続サーバ（端末も含む）に対して処理の依頼をするが、
実際には、第２図２０１のいずれかの形態で実行されて
いるが、ユーザはそれを意識することはない。

【００３７】では第１０図を用いて、処理の実行場所の
決定のフローを説明する。上述のインタフェースを介し
てユーザより入力されたJob指定情報１００１は、端末
管理Agent１０７によって、実際のファイル名やプログ
ラム名に解釈されて（１００２）、システム統括サーバ
へのJob依頼として送信される（１００３）。システム
統括AgentはJob依頼情報１００４から、以下の処理１０
０５を行なう。ユーザ管理情報テーブル２０２を用いて
依頼Jobに対応するファイル／プログラムの所在箇所を
抽出する。システムリソース管理情報ファイル２０３を
参照して、該当Jobの実行場所を決定する。その際、実
行場所の環境に従って、必要に応じて、実行場所の計算
機へのプログラム、ファイルのローディングを行なう。
この１００５の処理の詳細フローを第１１図から第１３
図を用いて説明する。

【００３８】第１１図のフローにおいて、まず、ユーザ
管理情報テーブル２０２より、依頼Job のプログラム／
ファイルの所在場所を検出し、それを用いてシステムリ
ソース管理情報テーブル２０３を参照して、所在場所の
リソース情報としてCi：CPU処理性能，Mi：メモリ量，F
i：ファイル容量を抽出する（１１００）。これは所在
場所は第８図８０５を参照し、それに従って第５図５１
０を参照すればよい。ここで所在場所が複数あることを
想定して添字にiを用いている。ついで、システム統括A
gentは、実行対象のプログラムに対して、実行に必要と
なるメモリ量を示すプログラムサイズ（Ｐ）、バッチ処
理なのか対話処理なのかを示す処理モード（Ｂ：バッチ
処理／Ｉ：対話処理）、平均処理負荷（Ｌ）を抽出し、
処理対象のファイルに対して、そのデータファイル量
（Ｄ）の抽出を行なう（１１０１）。これは、サーバ上
のプログラム／ファイルであれば、第５図５１０テーブ
ルの５１３、５１７を参照すればよく、端末のユーザ資
産であれば、第８図８１０テーブルの８１３、８１７を
参照すれば実現できる。ついで、ユーザ管理情報テーブ
ル２０２（第８図）より、login 端末リソース情報とし
て、C0：CPU処理性能，M0：メモリ量，F0：ファイル容
量の情報を抽出する（１１０２）。これは第８図テーブ
ルの８０９を参照すればよい。ここで、処理負荷は総処
理量を、CPU処理性能は単位時間当たりの処理量を想定
している。

【００３９】これらの情報を利用して該Jobの実行場所
を以下のアルゴリズムで決定する。

【００４０】まず、プログラムの移動の可否によって、
２つのモードに分かれる（１１０３）。これは、プログ
ラムの使用契約に際して、実行する計算機が指定（固
定）されている場合には、移動が否となる。

【００４１】移動が否の場合は、login端末上に該プロ
グラムが存在する場合には、端末での実行が可能かを検
証する（１１０４）。処理対象のファイルが端末上にあ
れば（１１０５）、実行場所を端末として、ファイルの
移動も必要がない（１１０６）。処理対象ファイルが端
末上になければ（１１０５）、端末に処理ファイルを移
動可能か（１１０７。処理対象のファイルの容量Ｄが端
末のファイル容量Ｆ０より小さいかで判断）を検証し、
可能であれば、実行場所を端末として、ファイルの移動
を行なう（１１０８）。移動不可能である場合（１１０
７のnoのケース）、および端末にプログラムが存在しな
い場合（１１０４のnoのケース）には、プログラムの他
の所在箇所での実行を検討する次の処理を行なう。

【００４２】プログラムの存在するサーバ（i）の内、
処理負荷の軽い順に条件を満たすサーバがみつかるま
で、以下の処理を繰り返す。ここで、稼働負荷の情報は
該当プログラムの存在するサーバに対して、第５図シス
テムリソース管理情報テーブルの稼働状況テーブル５０
５を参照すれば判明する。例えばCPU処理能力の余りの
絶対値の大きい順に選んでいけばよく、余りは５０２の
絶対能力から最新の５０７の値を減算すればよい。各対
象のサーバに対して、処理能力が充分にあるかを検証す
る（１１１０）。処理能力の十分条件として、CPU能力
とメモリ容量に対して、本実施例では以下の条件を用い
ている。想定される処理負荷Ｌに対して、CPU能力Ciが
あるレベル以上であるか（Ｌ＜α＊Ci）。プログラムの
実行に必要なメモリサイズＰに対して、サーバ上のメモ
リ量Miがある割合以上あるか（Ｐ＜β＊Mi）、また、仮
想記憶としてファイルを併用するとして、ファイルを含
めてメモリ量が十分にあるかＰ＜（Mi＋Fi）。ここで、
αとβはある与えられた定数を用いるが、処理時間が極
端に長大にならないようにこれらは定められ、例えばα
＝１０、β＝０．５が設定されているものとする。この
条件に合格した場合には（１１１１）、該サーバ上に処
理ファイルが格納可能かを検証し（１１１１）、可能で
あれば、実行場所を該サーバとして（１１１２）、処理
ファイルが該サーバ上になければファイルの移動（コピ
ー）を行なう（１１１３）。不可能であれば、次のサー
バの候補を検証する事になる。

【００４３】プログラムの移動が可能である場合には、
プログラムの処理の性質やプログラムの処理量やファイ
ルの容量に応じて、実行場所の優先場所（端末、プログ
ラム／ファイルの所在場所）を決めて、上記で述べた判
断条件を適用しながら、実行場所を決定する（１１１
５）。以下、そのフローを第１２図を用いて説明する。

【００４４】プログラムの処理のモードが対話処理の場
合には、端末を処理場所に優先し、処理が可能かを検証
する（１２００）。これは、頻繁な対話処理の性能を維
持するため、極力ユーザに近いところで処理を実行する
方針からである。対話処理の場合、login端末上で実行
が可能かを検証するが（１２０２〜１２０５）、これは
第１１図の１１１０〜１１１３の処理と全く同じアルゴ
リズムで行ない、可能である場合には必要に応じて、プ
ログラム、ファイルを端末に移動（コピー）する。CPU
性能やファイル容量の制約で不可能な場合は、およびバ
ッチ型の処理の場合には以下の手順に従う。

【００４５】まず、処理対象のプログラムの処理負荷の
絶対値がある処理量γ以下の場合は、プログラムの所在
箇所を優先的に実行場所の候補として、可能かを検証す
る（１２１０）。ある処理量γは、予め決めておくが、
例えば想定総演算量１００億演算命令と決めておく。こ
れは、ある程度以上大きな処理は。より処理能力の大き
な実行場所を探すが、それ以下の処理は予めプログラム
のある場所で実行することをまず検討する方針からであ
る。ある処理量γ以下の場合は（１２１１）、プログラ
ムの所在箇所での実行が可能かを検証するが（１２１２
〜１２１５）、これは上と同様に第１１図の１１１０〜
１１１３の処理と全く同じアルゴリズムで行ない、可能
である場合には必要に応じて、プログラム、ファイルを
決定した実行場所のサーバに移動（コピー）する。な
お、本処理はプログラムの所在箇所が複数ある場合に
は、実行場所が決定するまで所在箇所分繰り返す。

【００４６】ついで、処理対象のファイルのデータ量が
あるサイズδ以上の容量である場合は、ファイルの所在
箇所を優先的に実行場所の候補として、可能かを検証す
る（１２２０）。あるサイズδは、予め決めておくが、
例えば３Ｍbytesと決めておく。これは、大規模なデー
タベース等をネットワークで移動することを避ける方針
からである。あるサイズδ以上の容量である場合は（１
２２１）、ファイルの所在箇所での実行が可能かを検証
するが（１２２２〜１２２５）、これは上と同様に第１
１図の１１１０〜１１１３の処理と全く同じアルゴリズ
ムで行ない、可能である場合には必要に応じて、プログ
ラムを決定した実行場所のサーバに移動（コピー）す
る。ただし、ファイルは該サーバ上に予めあるので、フ
ァイル容量の条件判定１２２３は必ずyesとなる。な
お、本処理はファイルの所在箇所が複数ある場合には、
実行場所が決定するまで所在箇所分繰り返す。

【００４７】ついで、ここまでの判定で実行場所が決ま
らなかった場合には、ネットワーク内の全てのサーバを
対象に、リソース上の観点から最適な実行場所を決定す
ることになる（１２３０）。

【００４８】第１３図で、ネットワーク内のサーバ(i)
の内、稼働負荷の軽い順に、条件を満たすサーバが見つ
かるまで（１３０１）、以下の処理を繰り返す。ここ
で、稼働負荷の軽さの情報は、第１１図の１１０９での
処理と同様に、第５図のシステムリソース管理情報テー
ブルの稼働状況テーブル５０５を参照すれば判明する。
例えばCPU処理能力の余りの絶対値の大きい順に選んで
いけばよく、余りは５０２の絶対能力から最新のCPU負
荷５０７の値を減算すればよい。あるいは最新の負荷で
はなく、最近の負荷量の平均を用いることも考えられ
る。選択されたサーバの順に、実行が可能かを検証する
が（１３０２〜１３０５）、これは上と同様に第１１図
の１１１０〜１１１３の処理と全く同じアルゴリズムで
行ない、可能である場合には必要に応じて、プログラ
ム、ファイルを決定した実行場所のサーバに移動（コピ
ー）する。

【００４９】以上がシステム統括Agent１０５による、
端末から依頼されたJobの実行場所の決定方法の詳細フ
ローである。

【００５０】第１０図にもどって、実行場所が上記のア
ルゴリズムで決定されれば、実行場所および移動された
ファイルの情報を、決定できなければその要因を端末に
送付する（１００７）。１００８の情報は、実行場所に
対してはCPU-IDおよびIPアドレスが、また、ファイル移
動に対しては、プログラムもしくはファイルの移動元の
CPU-IDおよびIPアドレスを送付する。送信情報を入手し
た端末管理Agent（１０１０）は、その情報に基づい
て、実行場所の計算機に対してJobの依頼し（１０１
１）、Jobの内容に応じて実行場所の計算機との交信を
行なう。以下、この端末管理Agentの処理の詳細フロー
を第１４図を用いて説明する。

【００５１】第１４図において、実行場所が決定できな
い場合には（１４０１）、実行場所が決定できなかった
要因を画面に表示し、ユーザの次の指示を待つ（１４０
２）。決定できない要因としては、移動不可能なプログ
ラムに対しては、プログラムの所在する特定のサーバに
おけるリソースが不足している場合か、移動可能なプロ
グラムに対しては、システム全体としてリソースが不足
している場合が考えられる。

【００５２】実行場所が決定した場合には、プログラム
の実行モード、実行場所に従って、該当計算機にJobを
依頼する（１４０３）。Jobの依頼先は送られてきたCPU
-ID、IPアドレスで一意に決定できる。実際のJobは、第
２図２０１のいずれかの形態で行なわれる。クライアン
ト端末上のプログラムが起動されるケース（１４０
４）、サーバ上のプログラムが対話実行されるケース
（１４０５）、サーバ上のプログラムがバッチ実行され
るケース（１４０６）などである。実行にあたっては、
Jobに応じて実行場所の計算機と交信が行なわれるが、
これは実行されるプログラムの下で行なわれる。端末管
理Agentが介在するのは、Jobの終了時である。終了時、
処理の実行によってその結果として新たなファイルが生
成される場合があるが、その場合にはユーザファイルと
して、登録する必要がある。新規ファイルが生成された
場合（１４０７）、システム統括サーバに新規生成ファ
イルの登録を行なう（１４０８）。これは新規生成ファ
イル情報１４０９をシステム統括Agentに送付し、シス
テム統括Agentは、第５図のシステムリソース管理情報
テーブルの該当サーバのファイル管理テーブル５１０に
ファイル情報を登録すると共に、第８図のユーザ管理テ
ーブルのファイル管理テーブルに登録すればよい。つい
で、Jobの終了処理として、プログラムが実行場所にロ
ーディングされたのであれば（１４１０）、実行場所
（端末もしくはサーバ）にローディングされた該プログ
ラムの削除を行なう（１４１１）。ファイルが実行場所
に移動（コピー）されたのであれば（１４１２）、実行
場所（端末もしくはサーバ）にコピーされたファイルが
更新されていれば、コピー元のファイルへ更新情報を反
映し、実行場所の該移動ファイルの削除を行なう（１４
１３）。ローディングの有無や移動元の情報は、上述し
た第１０図１００８の情報で端末管理Agentは得てい
る。

【００５３】以上が、システム統括Agent１０５、サー
バ管理Agent１０６、端末管理Agent１０７の協調によ
る、システム全体を一体型で管理する方法の実施例であ
る。本方法では、いかなる端末からloginしようとユー
ザにとってはシステム内でユーザが使用可能なリソース
（プログラムおよびファイルデータ）が、見え方（イン
タフェース）を含めて不変である。また、端末からのJo
bの依頼に対してシステム内に最適な実行場所を自動的
に探して処理を実行する。

【００５４】本実施例のいくつかの変形例を示す。

【００５５】本実施例では、１つのJobを対象に記述し
たが、いくつかのJobが連携して行なわれる処理も同様
にシステム統括Agentと端末管理Agent間の連携で実現可
能である。その方法として、２通りの方法が考えられ
る。第１の方法は、連携した全てのJobに対して、処理
の依頼時点でどの実行場所で実行するかを、上述の実行
場所の決定アルゴリズムを繰り返し用いてシステム統括
Agentが決定し、それを端末管理Agentに戻して、端末管
理Agentは順次それに基づいて実行を行なう方法であ
る。第２の方法は、Jobの順番にその都度システム統括A
gentにその時点での該当Jobの最適な実行場所を問い合
わせ、それを実行し、その終了後に、次の後続のJobの
実行場所を決定する。この実現にあたっては、上述の端
末管理Agentの処理を、連結されているJobの個数分繰り
返す手順で行なえばよい。

【００５６】本実施例では、処理の負荷は、そのプログ
ラムの平均的な負荷の推定値（もしくは統計値）を第５
図５１６のフィールドに保有し、それを参照して処理の
実行場所を決定しているが、処理の負荷は処理対象のフ
ァイルにも大きく依存し、確定値ではない。従って、処
理の負荷の量をJob依頼時に、ユーザが予め申告（入
力）する方法も考えられ、その値を代用することも可能
である。

【００５７】本実施例では、処理の実行場所を予め定め
られたアルゴリズム（第１１図〜第１３図）で決定して
おり、端末、プログラム所在箇所、ファイル所在箇所の
優先順位で実行場所を探していくが、この優先順位も例
えばファイル所在をプログラム所在より優先させる変形
も考えられる。また、本実施例は、システムが実行場所
を探す順序を固定しているが、ユーザに順序を選択させ
ることも考えられる。

【００５８】本実施例は、第１１図〜第１３図で実行場
所を決める判定式で用いるパラメータα、β、γを固定
しているが、これをシステム全体のリソースの量に応じ
て、動的に変更することも考えられる。あるいは、シス
テムを構成するサーバ群の能力の平均などの分布に従っ
て設定することも考えられる。

【００５９】本実施例では、ある処理のためにある実行
場所にローディングされたプログラムは、処理終了後は
無条件に削除することにしている（第１４図１４１１、
１４１３）。しかし、ローディングされる頻度の高いプ
ログラムはローディングしたままにして、再度使われる
時は再ローディングするのではなく、それを使うことが
考えられる。これを実現するには、ローディングしたま
まにする該プログラムを、第５図システムリソース管理
情報テーブルの５１０に登録しておけばよい。登録は、
該プログラムのローディング元の本テーブルの該当行を
所在位置のみを該実行場所のサーバ上の所在位置に変更
して、コピーすればよい。

【００６０】本実施例では、計算機をヘッダとした第５
図のシステムリソース管理テーブルを中心に、処理を実
現する例を示した。この実施例では、プログラムの所在
箇所を探す場合には、計算機から第５図５１０のテーブ
ルをサーチすることになる。これに対して、ファイルを
ヘッダにしたテーブルを用意する方法が考えられる。第
１５図に、そのテーブルの構成を示す。本テーブルはフ
ァイルに対して、その所在位置を複数保持できるように
なっている。１５００は第５図５１０のテーブルと内容
的には同じだが、所在位置１５０９は、所在位置を示す
サブテーブル１５１０へのポインタとなっている。サブ
テーブル１５１０は、ファイルの所在位置として、計算
機を特定するCPU-ID１５１１、システムのネットワーク
内のアドレスを示すIPアドレス１５１２、計算機上での
位置を示すDirectory１５１３、Folder１５１４からな
り、個々の計算機上での特有の別名称がある場合にはエ
リアス名１５１５に格納する。他の所在場所がある場合
には他の本サブテーブルへのポインタ１５１６により、
複数の所在位置を格納できる。本テーブルを用いれば、
第１１図１１０９のプログラムの所在するサーバは容易
に抽出でき、また、第５図５１０や第８図８０３はファ
イル名称のみのテーブルとして、他の情報は必要に応じ
て本テーブルを参照すればよい。ただし、システムリソ
ース管理テーブルとの整合性を保証しておく必要があ
り、例えば前述のローディングプログラムをそのまま常
駐させる場合には、そのサーバを１５１０のサブテーブ
ルとして、該当するファイル欄に連結しておく操作が必
要である。

【００６１】次に、新しいサーバがネットワークシステ
ムに接続された場合の処理について第１６図を用いて説
明する。システム統括Agent１０５は、タイマー割り込
みもしくは新規リソース追加を検出した場合、以下の処
理を行なって、本ネットワークシステム内のリソースの
一部として、該新規サーバを取り込む。新規サーバ接続
の有無を調査し（１６０１）、ある場合にはリソース管
理Agentプログラムを該当IPアドレスに送付する（１６
０２）。システム内のサーバは第５図５００に登録され
るが、ポインタ以降の情報が設定されていないサーバ
を、新規サーバと判断する。リソース管理Agentプログ
ラム１０８の主要な機能は、サーバ管理Agentプログラ
ムを該サーバ上にインストールして、起動をかけること
である。初めにサーバのソフトウェアリソースの調査を
行なう（１６０３）。これはサーバに搭載された基本プ
ログラム（OS）の種別やバージョンなどを調査する。そ
の調査に基づき、サーバの基本プログラムに適合するサ
ーバ管理Agentプログラムの送付をシステム統括Agentに
対して行なう（１６０４）。それを受け、システム統括
Agentは該当するサーバ管理Agentプログラムを送付する
（１６０６）。リソース管理Agent は該サーバ管理Agen
tプログラムをサーバにインストールし、そのプログラ
ムの起動をかけて処理を終了する。あとは第３図で述べ
たように、ある割り込みを契機に、インストールされた
サーバ管理Agentによる情報収集が行なわれ、収集情報
のシステム統括サーバへの報告が行なわれる（１６０
７）。システム統括Agentは受け取った情報に対して、
初めてであればシステムリソーステーブルの生成（第５
図５０１、５０２、５０５、５１０などの生成）を行な
い、入手情報の設定を行なう（１６０８）。これによ
り、新規サーバは本システムのリソースの一部として組
み込まれる。ここで、リソース管理Agentプログラムは
どのようなサーバでも稼働可能となるよう、プラットフ
ォームに依存しない言語（例えばJava言語）で作られて
いる。

【００６２】ここまでは、初めにファイルのある場所を
前提に、最適な実行場所や必要に応じて実行場所の計算
機へのファイルの一時的なローディングを決定した。シ
ステムを稼働させていると、ローディングの頻度やファ
イルの転送量の統計情報から、システム全体の効率的な
運用を考えたファイルのより適切な所在箇所が問題とな
ってくることが考えられる。以下の実施例では、その際
のファイルのサーバ間のコピーや移動方法について第１
７図、第１８図を用いて説明する。

【００６３】初めに第１５図で説明したファイル管理テ
ーブルを拡張して、各ファイルがどのサーバ上での処理
に利用されたかを記録しておけるようにする。第１８図
がその拡張例である。各ファイルに対して、そのファイ
ルが処理に用いられた回数である実行回数１８０１、更
に各実行位置を格納するテーブルへのポインタ１８０２
を格納するフィールドを用意する。各実行場所での実行
回数を格納するサブテーブル１８１０は、実行場所を示
すCPU-IDとIPアドレスと処理に使用されたトータルの回
数１８０５を有している。サブテーブルは異なった実行
場所の個数分ポインタで連結されている。Jobの実行場
所が決定された際に、該当ファイルの実行回数１８０１
がカウントアップされ、１８０２の実行場所のチェイン
にその実行場所が既に登録済みであれば、そのサブテー
ブルの回数１８０５をカウントアップし、なければ新た
なサブテーブルをチェインの最後に連結して回数を１に
セットする。この操作を、第１１図１１１６の直後に挿
入すれば情報を保持することができる。

【００６４】第１７図において、システム統括Agent１
０５は、ある期間毎に以下の処理を行なって、ファイル
の動的な再配置を行なう。ある期間とは、例えば、日時
的に１週間毎としてもよいし、あるいは、Jobの依頼件
数が１０００件に達する毎のように設定することも考え
られる。初めに使用頻度の高いファイルと低いファイル
を抽出する（１７０１）。抽出件数は例えば上位何件と
かと予め定めておけばよい。抽出は第１８図の実行回数
１８０１を参照すれば可能である。ついで、サーバ負荷
の軽いサーバと重いサーバの上位何件かを抽出する（１
７０２）。これは、第５図のシステムリソース管理情報
テーブルの稼働状況テーブル５０５による統計的な使用
量とハードリソース５０２から、各サーバの平均的な余
力を算定することができ、それを利用すれば抽出でき
る。ついで、ファイル容量の使用率の高いサーバと低い
サーバを同様にシステムリソース管理情報テーブルを利
用して抽出できる。ここで上位何件を抽出するかは、例
えばファイルであれば全ファイル数量の５％とか、サー
バであれば全サーバの１０％とかと予め定めておくこと
も考えられる。これらに対して、ファイルの移動をある
条件の下で行なう。

【００６５】この条件の考え方は、（１）あるファイルの使用頻度が高く、しかも他のサー
バへローディングされて用いられることが多ければ、ロ
ーディングされる機会の多いサーバにファイルを設け
る。リソース負荷の軽いサーバにコピーを設ける。

【００６６】（２）あるファイルの使用頻度が低いファ
イルは、複数同じものがサーバ上にあればその一部をサ
ーバから削除する。

【００６７】（３）ファイル容量の使用率が大きいサー
バから、使用頻度の低いファイルを、使用率の小さいサ
ーバへ移動する。

【００６８】これらを実際に実現する手順は以下だが、
以下に現われるｎ１、ｎ２、ｎ３、ｎ４は、予め与えた
定数である。例えば、ある時期の情報を元にあまり大幅
にリソースの配置を変えても、その後のユーザの利用状
況にも大きく依存するので、なだらかな変更を前提に１
か２程度を設定しておく。

【００６９】抽出された使用頻度の高いファイルに対し
て、以下の処理を行なう（１７０４）。ファイル所在サ
ーバ以外での実行場所のサーバの上位ｎ１個に対して
（１７０５）、そのサーバにファイル容量の空きがあれ
ば、該ファイルをそのサーバにコピーし、管理テーブル
を更新する（１７０６）。ここで、ファイル所在サーバ
以外での実行場所のサーバは、第１８図１８１０の連結
テーブルの中で所在位置以外のCPU-IDを持つものの中か
ら、回数１８０５の大きいものを抽出すればよい。ま
た、管理テーブルの更新は、第１８図の所在位置のチェ
インに、そのコピー先のサーバのサブテーブル１５１０
を生成して、チェインの最後に連結し、また第５図シス
テムリソース管理テーブルの該当サーバのファイル管理
テーブルにそのファイルを登録する。更に、負荷の軽い
サーバの上位ｎ２個に対して（１７０７）、１７０６と
同一の処理を行なう（１７０８）。

【００７０】抽出された使用頻度の低いファイルに対し
て、以下の処理を行なう（１７１０）。該ファイルの所
在箇所が複数ある場合（１７１１）、使われなかった所
在箇所、もしくはサーバ能力の低いサーバを優先して、
ｎ３箇所から削除し、管理テーブルを更新する（１７１
２）。ここで、第１８図のテーブルを参照すれば、ファ
イルの所在場所１５０９も、実行位置１８０２も分か
り、従って使われなかった所在箇所を抽出でき、また第
５図のテーブルを参照すれば各サーバの能力も抽出でき
る。

【００７１】抽出されたファイル容量の使用率の高いサ
ーバに対して、以下の処理を行なう（１７１５）。該サ
ーバ上の使用頻度の低いファイルｎ４個に対して（１７
１６）、ファイル容量の使用率の低いサーバへ移動し、
管理テーブルを更新。（１７１７）。これはほぼ１７０
６の処理と同様である。ファイル容量の使用率の低いサ
ーバは、同様に第５図のテーブルを参照すれば、抽出で
きる。

【００７２】以上が、本発明の一実施例である。

【００７３】

【発明の効果】本発明によれば、ネットワークを介して
接続された複数の計算機からなるシステムにおいて、シ
ステム全体を各ユーザのリソースとして使用することが
可能となる。しかも、本システム内でユーザが使用可能
であるデータファイルやプログラムは、どのような端末
から本システムにloginしようと不変であり、その見え
方（インタフェース）も端末に依存しないので、ユーザ
は端末に応じて使い方を変える負担がない。本発明に
依れば、ユーザが端末も含むシステムに処理を依頼した
場合、その処理の最も効率的な実行形態をシステムが自
動的に決定してくれ、それに伴うファイルやプログラム
のネットワーク内での移動もシステムが保証してくれる
ので、ユーザは一つのシステムに処理を依頼するだけで
よい。また、本ファイルやプログラムの所在場所が、シ
ステム全体の処理負荷やネットワーク移動量から考えて
動的変わるので、効率的なシステムの活用が可能とな
る。しかも、サーバを新規に追加接続した場合、システ
ムのリソースの一部として自動的に取り込まれ、ファイ
ルやプログラムが自動的に常駐するので、システム負荷
に応じたシステム拡張が容易に実現できる。

【図面の簡単な説明】

【図１】本発明の概念説明図。

【図２】処理の全体フロー図。

【図３】サーバ管理Agentプログラムのリソース情報収
集フロー。

【図４】システム統括Agentのサーバリソース情報管理
フロー。

【図５】システムリソース管理テーブルの構造。

【図６】ユーザのシステムへの登録フロー。

【図７】端末管理Agentによるシステムへのloginの処理
フロー。

【図８】ユーザ管理テーブルの構造。

【図９】端末に依存しないユーザインタフェース例。

【図１０】システム統括Agentと端末管理Agentの交信フ
ロー。

【図１１】端末から依頼された処理（Job）の処理場所
の決定フロー。

【図１２】端末から依頼された処理（Job）の処理場所
の決定フロー。

【図１３】端末から依頼された処理（Job）の処理場所
の決定フロー。

【図１４】端末管理Agentの処理実行場所の計算機への
処理依頼フロー。

【図１５】ファイル管理テーブルの構造。

【図１６】リソース管理Agentの動作フロー。

【図１７】システム統括Agentによるファイル移動フロ
ー。

【図１８】拡張したファイル管理テーブルの構造。

【符号の説明】

１０２・・システム統括サーバ、１０５・・システム統
括Agentプログラム、１０６・・サーバ管理Agentプログ
ラム、１０７・・端末管理Agentプログラム、１０８・
・リソース管理Agentプログラム、２０２・・ユーザ管
理情報ファイル、２０３・・システムリソース管理情報
ファイル。

Claims

【特許請求の範囲】

【請求項１】ネットワークを介して接続された複数の計
算機群からなる計算機システムにおいて、各計算機はＣ
ＰＵやファイルやメモリなどの計算機資源情報およびそ
の稼働状況情報とファイルデータやプログラムなどのユ
ーザ資産情報を取得して監視する手段を有し、該計算機
システム内の特定の計算機Ａが該計算機システム全体の
計算機資源情報を各計算機から収集管理する手段を有
し、ユーザがある計算機Ｂを介して該計算機システムに
ファイルデータとプログラムを用いた処理を依頼した場
合、該特定の計算機Ａは、ファイルデータとプログラム
の所在箇所と計算機資源の利用状況の情報を利用して、
その処理の最適な実行場所（計算機システム内のある計
算機Ｃ）を選定する手段を有し、ユーザが要求した処理
は該計算機Ｃ上において実行することにより、計算機シ
ステム全体をユーザの資源として処理依頼時に最も効率
的な実行形態を動的に決定することを特徴とする計算機
システムの制御方法。
【請求項２】上記請求項１の計算機システムの制御方法
において、計算機Ａより実行場所（計算機Ｃ）の指示を
受けた計算機Ｂは計算機Ｃに該処理を再度依頼する手段
を有し、ユーザの依頼した処理がどこで実行されている
かをユーザには意識させないことを特徴とする計算機シ
ステムの制御方法。
【請求項３】上記請求項１の計算機システムの制御方法
において、ユーザの依頼した処理の実行場所として選定
された計算機上に該当するプログラムまたはファイルデ
ータが存在しない場合には、その存在場所からそれらを
移動（コピー）する手段を有し、ユーザの依頼した処理
がどこで実行されているかをユーザには意識させないこ
とを特徴とする計算機システムの制御方法。
【請求項４】上記請求項３の計算機システムの制御方法
において、ユーザの依頼した処理の実行場所として選定
された計算機上に該当するファイルデータが存在しない
場合にその存在場所からそれを移動（コピー）して実行
された処理が、該ファイルデータを変更した場合には、
そのコピー元のデータファイルへその変更を反映する手
段を有することを特徴とする計算機システムの制御方
法。
【請求項５】上記請求項３の計算機システムの制御方法
において、ユーザの依頼した処理の実行場所として選定
された計算機上に、該当するプログラムが存在しない場
合にその存在場所からそれを移動（コピー）して実行さ
れた処理の終了後、該プログラムをそのまま該計算機上
に残すか削除するかを判断する手段を有し、その判断に
基づいて該プログラムを削除することを特徴とする計算
機システムの制御方法。
【請求項６】上記請求項３の計算機システムの制御方法
において、実行場所として選定された計算機上での処理
の実行に伴ってその結果として新たなファイルデータが
生成された場合、生成されたファイルは該計算機上での
ユーザの資産として該計算機より、システム全体の計算
機資源を収集管理する計算機Ａに報告して計算機資源情
報を更新する手段を有し、これによりどの計算機上で処
理が実行されようとも計算機システム全体としてのユー
ザ資産を管理することを特徴とする計算機システムの制
御方法。
【請求項７】上記請求項１の計算機システムの制御方法
において、ユーザの依頼した処理の実行場所として選定
する手段において、プログラムの存在箇所、ファイルデ
ータの存在箇所、ユーザがシステムに介入（login）し
た計算機、処理の依頼時点で使える計算機処理能力の高
い計算機の４つの選択肢を有し、依頼された処理の対話
処理かバッチ処理といった性質と、処理に使うプログラ
ムとファイルの所在場所の移動が許可されているかとい
った情報と、その処理の計算量や記憶容量といった負荷
に依存して、実行場所を決定する手段を有することを特
徴とする計算機システムの制御方法。
【請求項８】ネットワークを介して接続された複数の計
算機群からなる計算機システムにおいて、各計算機のフ
ァイルデータやプログラムなどのユーザ資産情報を取得
して監視する手段を有し、該計算機システム内の特定の
計算機Ａが該計算機システム全体のユーザ資源情報を各
計算機から収集管理する手段を有し、ユーザがある計算
機Ｂを介して該計算機システムに参入（ｌｏｇｉｎ）し
てきた時に、該計算機システム上の全体で、ユーザの所
有するファイルデータおよびユーザの利用可能なプログ
ラムの一覧を表示する手段を有し、いかなる計算機Ｂか
らのｌｏｇｉｎに対しても一様のユーザインタフェース
を提供することを特徴とする計算機システムの制御方
法。
【請求項９】上記請求項８の計算機システムの制御方法
において、計算機Ｂ上でのユーザのファイルデータ群と
プログラム群を用いた処理の指示を、ファイルデータ群
やプログラム群の実際の所在場所である計算機環境には
依存しない一様な方法により指定できる手段を有し、い
かなる計算機Ｂからの処理指定に対しても一様のユーザ
インタフェースを提供することを特徴とする計算機シス
テムの制御方法。
【請求項１０】ネットワークを介して接続された複数の
計算機群からなる計算機システムにおいて、各計算機は
ＣＰＵやファイルやメモリなどの計算機資源情報および
その稼働状況情報とファイルデータやプログラムなどの
ユーザ資産情報を取得して監視する手段を有し、該計算
機システム内の特定の計算機Ａが該計算機システム全体
の計算機資源情報を各計算機から収集管理する手段を有
し、更にネットワークを介してそこに接続されている計
算機群を巡回して新たに接続された計算機Ｘを検出する
手段を有し、検出された該計算機Ｘに上記監視手段を設
定する事により、新たに接続された計算機が全体システ
ムの管理下に自動的に組み込まれることを特徴とする計
算機システムの制御方法。
【請求項１１】上記請求項１０の計算機システムの制御
方法において、新たに接続された計算機の計算機資源情
報に基づいて、既存の計算機間の負荷が集中しないよう
にファイルおよびプログラムを計算機Ａが自動的に移動
させる手段を有し、新たに接続された計算機Ｘが該計算
機システム全体の負荷緩和に自動的に組み込まれること
を特徴とする計算機システムの制御方法。
【請求項１２】ネットワークを介して接続された複数の
計算機群からなる計算機システムにおいて、各計算機は
ＣＰＵやファイルやメモリなどの計算機資源情報および
その稼働状況情報とファイルデータやプログラムなどの
ユーザ資産情報を取得して監視する手段を有し、該計算
機システム内の特定の計算機Ａが該計算機システム全体
の計算機資源情報を各計算機から収集管理する手段を有
し、ユーザがある計算機Ｂを介して該計算機システムに
ファイルデータとプログラムを用いた処理を依頼した場
合、該特定の計算機Ａは、ファイルデータとプログラム
の所在箇所と計算機資源の利用状況の情報を利用して、
その処理の最適な実行場所（計算機システム内のある計
算機Ｃ）を選定する手段を有し、ユーザが要求した処理
は該計算機Ｃ上において実行する手段を有する計算機シ
ステムにおいて、各処理に対するファイルデータとプロ
グラムの利用状況および計算機間の移動状況を監視する
手段を有し、その統計情報にもとづいてファイルデータ
もしくはプログラムを所在位置から他の計算機へ移動
（コピー）する手段を有することにより、ある期間の利
用状況に応じたファイルとプログラムの再配置を行なう
ことを特徴とする計算機システムの制御方法。
【請求項１３】上記請求項１２の計算機システムの制御
方法において、各ファイルに対して、定められたある期
間内での使用頻度、利用にあたっての移動頻度と移動実
行場所、実在場所のファイル領域の使用率をパラメータ
として、それに基づいてファイルの移動と削除を決定す
ることを特徴とする計算機システムの制御方法。