JPH03504175A - データ処理ネツトワーク - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 データ処理ネットワーク ［技術分野］ 本発明は、データ処理ネットワークの分野に関するものである。具体的には、本 発明は、第１のプロセッサによって使用されるファイルのコピーが第２のプロセ ッサに記憶される、データ処理ネットワークに関するものである。

［背景技術］ １つまたは複数のホスト・メインフレーム・コンピュータニ接続された多数のプ ログラム式ワークステージ１ン（パーソナル・フンピユータなど）を含むデータ 処理ネットワークの使用が、最近増加してきた。一部のデータ処理機能はプログ ラム式ワークステージ１ンで実行できるが、他のデータ処理機能は、ホスト・メ インフレーム・コンピュータで実行スるのに適している。最近の開発によって、 データ処理機能のある部分をプログラム式ワークスチーシロンで実行し、同じデ ータ処理機能の別の部分をメインフレーム・フンピユータで実行するシステムの 使用が増加してきた。これがいわゆる分散処理または共同処理である。このよう なシステムでは、ホストとワークステーションの双方が同じ更新レベルにあるこ とが決定的に重要である。

ネットワークを採用することによって、プログラム式ワークステージ、ンで使用 するアプリケーンロン・プログラムおよびデータ・ファイルの導入および保守に 、ホスト・メインフレーム・コンピュータを使用できるようになった。これを行 うことによって、ネットワークは、プログラム式ワークステーションに保持され たファイルが、それらのファイルのうちで最新のパーシーンであることを保証で きるようになる。

欧州特許第２８４９２４号に、そのプログラム自体の保守用のコード部分を含む プログラムを、プログラム式ワークスチーシロン上で実行させるデータ処理ネッ トワークを提供することが提案されている。このプログラムは、起動されると、 そのファイルのより新しいバージジンがホスト・メインフレーム・コンピュータ に保持されているか否かを検査し、必要があればそれをダウンロードする。

もう１つの手法は、ホストまたはメインフレームのいずれかで実行される特定の 保守プログラムを提供することである。

このプログラムは、ワークスチーシロンに保持されたファイルの一部または全部 を検査して、そのファイルの新しいバージせンをダウンロードしなければならな いか否かを調べ、必要な場合にはそれを実行する機能を備えている。このような プログラムは通常、ユーザによって実行をトリガされるか、あるいは定期的に実 行するように自動的に設定される。

［発明の開示］ 本発明は、第１プロセツサ、第２プロセツサ、詔よび前記第１プロセツサと前記 第２プロセツサをリンクする通信システムを有し、前記プロセッサに付随する制 御論理機構が、前記第１プロセツサ上で実行中の１つまたは複数のアプリケージ ジン・プログラムに代わって、前記第１プロセツサと前記第２プロセツサの間の 情報の流れを管理する働きをするデータ処理ネットワークであって、前記制御論 理機構は、前記アプリケーンロンによって、またはそれに代わって発行された呼 出しに応答して、呼出し側アプリケーシーンに関連し、前記第１プロセツサによ って記憶された１つまたは１組のファイルが、そのアプリケージ１ンに使用可能 な、前記第２プロセツサに記憶された１つあるいは１組のファイルと同じ最新の バージ１ンであるか否かを判定し、そうでない場合には、第１プロセツサ上の前 記の１つあるいは１組のファイルを、適宜前記第２プロセツサからダウンロード された選択されたファイルと交換しまたはそれで増補しあるいはその両方を行う ことを特徴とする、データ処理ネットワークを提供するものである。

本発明は、ソフトウェア保守に対する従来技術の手法に関連する問題を認識し、 これらの問題の解決策を提供する。欧州特許第２８４９２４号で開示されたシス テムの場合、保守機能は、保守コードを追加された特定のアプリケーンロンだけ が利用できる。したがって、その保守コードの利益は、そのシステム上で実行中 の他のアプリケーンロンには利用できない。特定の独立型保守プログラムの場合 、それを具体的に呼び込んだ後に、所定の更新シーケンスに従うか、あるいはユ ーザ入力によって駆動しなければならないので、柔軟性に欠ケル。さらに、ホス ト・レベルで所与の更新が行われなかった場合には、この独立型プログラムが呼 び込まれる保証はない。

本発明は、システム上でローカルにまたは分散式に実行中のすべてのアプリケ− シロンに利用でき、そのサービスが必要な際には、アプリケ−ジーン自体が実際 にそれを呼び込むという柔軟性を備えた、更新機能を提供する。

とのを利な結果は、アプリケ−２１７間の制御論理機構によって提供される機能 として、更新サービスを実現することによって達成される。次に、あるアプリケ −シロンは、たとえばそれ用のデ・−夕の特定の一部を回復するためにディスク ・オペレーティング・システムに呼出しを発行するのと同様にして、共用制御論 理機構に呼出しを発行して、ファイルを更新する必要があるか否か判定し、必要 な場合にはそれを実行することができる。これが、本発明の中心であり、上述の 利点をもたらす、共用制御論理機構の一部として更新機能を提供するという新規 な構造である。

本発明の好ましい実施例では、あるアプリケ−シロンを起動する時、前記第１プ ロセツサと前記第２プロセツサの間で、前記アプリケージジンが使用する通信セ ツションを確立するために、前記アプリケーンロンの代理が、前記制御論理機構 に呼出しを発行する。ローカル・プロセッサとリモート・プロセッサの間で通信 を確立するために代理アプリケージジンをどのように使用するかは、本明細書と 同日付けの本発明者等の同時継続の特許出願ＰＣＴ／ＧＢ　　８９１００８８３ 号明細書１″Ｗｏｒｋｓｔａｔｉｏｎ　ａｎｄ　Ｄａｔａ　Ｐｒｏｃｅｓｓｉｎ ｇ　ＮｅｔｗｏｒｋＣｏｎｔａｉｎｉｎｇ　Ｗｏｒｋｓｔａｔｉｏｎｓ”　　に 記載され、特許請求されて％ｉる。

したがって、あるアプリケ−シロンがそっくり第１のプロセッサ（たとえば、プ ログラム式ワークスチーシロン）上にある場合、そのアプリケーンロン用の適当 なファイルシカ（第１のプロセッサで利用可能であり、最新のレベルである力） どうか検査するため、第１プロセツサと第２プロセツサ（たとえば、ホスト・コ ンピュータ）の間で通信セック１ン力ｆ確立される。この検査の結果、必要に応 じて、新しｂ１ファイルと更新されたファイルが第１プロセツサにダウンロード され、既存のファイルを増補または交換しあるいはその両方を行う。

実際によく見られるように、あるアプリケ−シロンが第１プロセツサ（たとえば プログラム式ワークスチーシロン）と第２プロセツサ（たとえばホスト・コンピ ュータ）の間に分散されている場合、ワークスチーシロン（たとえば）上のユー ザがアプリケ−シロンを呼び出すと、ワークスチーシロンとホストの間の通信セ ラシランが自然に確立される。アプリケーンロンの本来の実行を開始する前に、 代理アプリケージ冒ンからの呼出しに応答して通信セッシ目ンを使用して更新検 査を行ない、正しいファイルがワークステージ１ンで利用可能であり、それらが ホストに保持されているファイルの最新のバージロンに対応するレベルであるこ とを確認する。分散アプリケ−シロンを実行する場合、このことは特に重要であ る。

というのは、システムの保全性を保証するには、アプリケーションの分離された 部分同士の厳密な整合性を維持しなければならないからである。

分散アプリケ−シーンでは、この好ましい特徴を提供することによって、システ ムは、追加の通信セラシロンを確立する際に生じる不要な遅延を回避でき、かつ 通信システムが同時に１つの通信セッシ靜ンしかサポートできないことから生じ る問題をも回避できるようになる。この特徴のもう１つの利点は、その一部が全 く使用されない可能性のあるすべてのアプリケ−シーンについて検査するのでは なくて、起動されることがわかっているアプリケーンロン用のファイルだけが検 査され、その結果、処理オーバヘッドが最小限に保たれることによるものである 。

本発明の特に好ましい実施例では、前記制御論理機構は、前記１つまたは複数の アプリケ−シロンの実行中のどの時点でも、アプリケ−シロンから発行された呼 出しに応答する。

分散アプリケーションの場合、アプリケ−シロン実イテ中に呼出しを発行できる ことが最も有用である。たとえば、ユーザがＨＥＬＰ　（ヘルプ）を要求すると 、ＨＥＬＰパネルの現バージ１ンをホストからワークスチーシロンにダウンロー ドするために、アプリケーションが呼出しを発行する。この特徴を提供すること によって、アプリケ−シロンがその実行に必要なファイルを保守する方法に関し て、非常に大きな柔軟性が得られる。一部のファイル（静的ファイル）は、アプ リケージ贅ンが実行される場合に必ず必要であるが、他のファイル（動的ファイ ル）は一部の場合にしか必要でない。したがって、本発明を使用すると、代理ア プリケーションが、そのアプリケージ叢ンが実行されるたびに必要なファイルを 保守するために呼出しくＵＰＤＡＴＥ　　ＡＰＰＬ　（アプリケーション更新） ）を発行し、それに引き続いて、アプリケーションが、アプリケーションの実行 中に必要な任意選択のファイルを必要な時に保守するために、別の呼出しくＰＲ ＥＰＡＲＥＦＩＬＥＳ（ファイル作成））を発行することができるようになる。

したがって、この任意選択ファイルの更新手順を実行するためにプロセッサ間で 交換されるデータは、アプリケーションを実行した結果生じるプロセッサ間の通 常のデータ流れと混合されることがわかる。

本発明の好ましい特徴は、第２のアプリケ−シロン用のダウンロードされるファ イルのための場所を空けるために、前記第１プロセツサが第１のアプリケーンロ ン用のファイルをその記憶域から削除するようになっていることである。この特 徴により、第１プロセツサは、ダウンロードされるファイル用の空間ができるよ うにその記憶域を管理することができ、同時に、更新機能を提供することによっ て、削除されたファイルが次に必要になった時、ユーザの介入なしに第１アプリ ケージ四ンがそれをダウンロードできるようになる。したがって、本発明とこの 好ましい特徴の間には、強い相乗作用があることがわかる。

本発明のもう１つの好ましい特徴は、前記ファイルを更新する必要があるかどう か判定するため、前記第１プロセツサが前記ファイルを検査することである。実 際のファイルのパラメータおよび属性を検査して、そのバージＬンを決定すると いうこの特徴には、ファイルが事故（破壊）または故意（たとえば、コンピュー タ・ビールス）のどちらによって改変されたのかを本発明によって決定できると いう利点がある。

［図面の簡単な説明コ 第１図は、本発明を実施するデータ処理ネットワークの概略図である。

第２図は、現アプリケ−シロン以外のアプリケーションを更新するために、ワー クスチーシロンで呼出しが発行された場合の、本発明の１実施例のデータ処理の ステップを示す流れ図である。

第３図は、現アプリケージ１ンを更新するために、ワークスチーシロンで呼出し が発行された場合の、本発明の１実施例のデータ処理のステップを示す流れ図で ある。

第４図は、現アプリケーションを更新するためにホストで呼出しが発行された場 合の、本発明の１実施例のデータ処理のステップを示す流れ図である。

第５図は、現アプリケーション以外のアプリケ−シロンを更新するために、ホス トで呼出しが発行された場合の、本発明の１実施例のデータ処理のステップを示 す流れ図である。

［発明を実施するための最良の形態コ 第１図に、通信システム６によって、第２プロセツサ４（この実施例ではホスト ・コンピュータ）にリンクされた第１プロセツサ２（この実施例ではプログラム 式ワークスチーシロン）を示す。第１プロセツサ２には、第１プロセツサ２が保 持するファイルを記憶するためのファイル・システム８が付随している。データ ベース１０は、以前に第１プロセツサ２にダウンロードされたすべてのファイル のリストを保持している。代理アプリケ−シーン１１およびアプリケーション・ プログラム１２は、共に第１プロセツサ２上で実行され、制御論理機構１４を利 用して、第２プロセツサ４との通信を管理する。

第２プロセツサ４には、第１プロセツサ２との通信を管理するための制御論理機 構１６が付随している。また、第２プロセツサ４は、第１プロセツサ２がそのア プリケ−シロンを実行する際に必要なファイルを含めて、すべてのファイルの最 新バージロンを記憶する、ファイル・システム１８ををする。アプリケージ１ン ・パッケージ・ファイル２０は、第２プロセッサ４の保持するファイルのリスト を、ホストでのファイルの「作成日」、アプリケーションが実行されるたびごと にファイルが必要（「静的ファイル」）なのかそれとも時々必要になるだけ（「 動的ファイル」）かなど、各ファイルに関連する属性と共に保持している。アプ リケージ１ン・パッケージ・ファイルは、別々の構成要素として図示されてはい るが、実際にはファイル・システムの一部として組み込まれている。

第１図の実施例では、アプリケ−シロン・プログラム１２がワークステージリン 上にあるが、これはアプリケーション１３としてホスト上にあってもよく、また アプリケ−７ツン・プログラム１２および１３の組合せとして、ホストとワーク スチーシロンの間に分散されていてもよい。したがって、ユーザとの高度な対話 を要求するアプリケ−シロンは、ワークスチーシロン上にあることが多く、一方 、たとえば共用データにアクセスする必要のあるアプリケーションは、ホスト上 にあることが多い。分散アプリケーションでホストとワークステージ２ンの境界 線をどこに引くかは、アプリケーション・プログラム設計の問題である。

したがって、ワークスチーシロン上のローカル・アプリケ−シロンの更新検査手 順では、ワークスチーシロンがホストとの間で、他の場合なら不要な通信セラシ ロンを確立する必要があるが、リモート・アプリケージ１ンまたは分散アプリケ ーションでは、ワークスチーシロンにいるユーザがそのアプリケーションを呼び 込んだ結果として、通信セラシーンがすでに存在しているので、このステップが 不要であることは明白である。どの場合でも、通信セラシーンがセットアツプさ れた後は、実行されるアプリケ−シロンがローカル、リモートまたは分散式のど れであるかには無関係に、本発明の対象である共通手順に従う。

アプリケーション起動処理中に通信セラシーンをセットアツプするには、標準的 なデータ処理ネットワーク手順を用いるが、これについては本明細書では説明し ない。実際の事象のシーケンスとしては、通信セラシロンを確立した後に、アプ リケーションは従来通り処理を開始し、ホストにログ・オンし、ホストの制御論 理機構１６を起動する。後で説明する本発明のすべての実施例では、識別された アプリケ−シロンに関連するワークスチーシーンにあるファイルを、ホストに維 持されているファイルの最新バージロンと比較してレベル検査を行う。

この処理の一部として、すでにワークスチーシロンにダウンロードされたファイ ルに関する情報は、コンパイルされた後にリスト３２としてワークスチーシーン に保持され、ホストで保持されている現在の最新バージロンのファイルに関する 情報は、コンパイルされた後にもう１つのリスト３８としてホスト側に保持され る。

より詳細にいうと、ワークステージジンの制御論理機構１４は、識別されたアプ リケーションに関連するファイルのうちのどれが以前にホストからワークスチー シロンにダウンロードされたかを決定するため、データベース１０に照会する。

次に制御論理機構１４は、ファイル・システム８に照会して、ファイルのコピー が存在するか否かを判定し、存在する場合は、その属性を検査して、「作成日ｊ 　（このファイルが最新のファイルとしてホストに保持された時に、ホストから 割り当てられた日付）を確定する。制御論理機構はこの情報を用いて、識別され たアプリケーションに関連すると思われる現ファイル、およびその当該のレベル 、すなわち存在するか否か、および存在するならばその作成日のりスト３２を生 成する。

同様に、ホストにある制御論理機構１６は、アプリケージ鱈ン・パッケージ・フ ァイル２０を読み取って、最新のホスト・ファイルとそれに関連する属性、すな わち作成日、静的か動的かなどを決定する。制御論理機構はこの情報をコンパイ ルして、リスト３８としてホストに保持する。

ファイルが現在の最新のレベルであるかどうかの判定は、以下に詳細に説明する ように、これら２つのリストを直接比較することによって行われる。したがって 、ワークスチーシロンとホストに常に両方のリストのコピーを用意することが有 用である。

したがって、ユーザがアプリケーションを呼び込んだ時、制御論理機構は上述の ２つのリストをコンパイルする。次に、アプリケ−シロン起動処理の最後の部分 として、ワークステーションにあるリスト３２をコピーしてホストに送り、そこ でリスト３３として保持し、ホスト・ファイルのリスト３８をコピーしてワーク スチーシロンに送り、そこでリスト３９として保持する。この処理の終了時の状 況を、第１図に破線で囲んで示す。このとき、ワークスチーシーン・ファイル情 報は、リスト３２として、ワークスチーシーンに、またリスト３３としてホスト に保持され、ホスト・ファイル情報は、リスト３８としてホストに、またリスト ３９としてワークステージ１ンに保持される。

以下に示す６つの異なる状況が起こり得る。

１、現アプリケ−シーンを更新するための、ワークスチーシーン呼出しく　Ｕ　 Ｐ　Ｄ　Ａ　Ｔ　Ｅ　　Ａ、　Ｐ　Ｐ　Ｌ　）２、アプリケーションの実行中に 必要な任意選択ファイルのレベル検査を行うための、ワークスチーシロン呼出し く　Ｐ’ＲＥＰＡＲＥ　　ＦＩＬＥ） ３、現アプリケ−シロンを更新するための、ホスト呼出しくＵＰＤＡＴＥ　　Ａ ＰＰＬ） ４、アプリケ−シロンの実行中に必要な任意選択ファイルのレベル検査を行うた めの、ホスト呼出しくＰＲＥＰＡＲＥＦ　Ｉ　ＬＥ） ５、現アプリケ−シロン以外のアプリケーションを更新するための、ワークステ ージ１ン呼出し ６、現アプリケージジン以外のアプリケ−シロンを更新するための、ホスト呼出 し 本発明を完全に理解するために、現アプリケーション以外のアプリケ−シーンに 対するワークステージ闘ン呼出しが行われるというより複雑な状況（上記の５） を、本発明の最初の主要な実施例として説明する。その後、この最初の例を参照 しながらその他の状況について説明する。

第２図は、起動された現アプリケーション以外のアプリケ−シロンを更新するた めにワークステーションで呼出しが発行された後に、更新検査を実行する場合の 詳細な動作シーケンスを示す流れ図である。たとえば、アプリケーション管理プ ログラムは、その制御下にある他のアプリケーションを管理するために、この機 能を使用することができる。第２図の線２２の左側は、第１プロセツサ２、すな わちワークスチーシロンで実行されるステップである。線２２の右側は、第２プ ロセツサ４、すなわちホストで実行されるステップである。

ステップ２４で、アプリケーション・プログラム１２は、関連する制御論理機構 １４に呼出しくＵＰＤＡＴＥ　　ＡＰＰＬ）−を発行して、その呼出しに含まれ るパラメータ（ＡＰＰＬＩＤ）で識別される別のアプリケーションのファイルを 検査し、更新する。次に、制御論理機構１４に制御が移る。上記の呼出しは、現 アプリケージ１ンが起動した後にだけ行われ、したがって、そのファイルは、ワ ークステーションにある以前にコンパイルされ記憶されたりスト３２および３９ を用いて検査され、更新されることを理解されたい。これらの記憶されたりスト ３２および３９は、現アプリケーション以外のアプリケーションを更新するには 不適であり、その代りに、識別されたアプリケ−シロンに関する情報を含む別の リストをコンパイルしなければならない。したがって制御論理機構は、リスト３ ２および３８のコンパイルに関して上述したステップを、今度は呼出されたアプ リケ−シロンについて繰り返す。現アプリケージ１ンに属する元のりスト３２． ３３．３８および３９は、この動作によって破壊されない。

したがって、制御論理機構は、ステップ２６で、識別されたアプリケ−シロンの ために以前にダウンロードされたファイルのリスト２８を、データベース１０か らコンパイルする。

この例では、このリストは４つのファイルからなり、ファイルはそれぞれ、通常 通りワークスチーシロン内での当該のファイルの位置を識別するＡｌＢ、Ｃおよ びＥの標識をつけられている。

制御論理機構１４は、ステップ３０で、リスト２８に載っている、ファイル・シ ステム８内のファイルを検査する。制御論理機構１４は、ファイルごとに、その ファイルがファイル・システム８に存在するか否か、およびそのホストでの元の 「作成日」など、そのファイルの属性を問い合わせる。次に制御論理機構は、見 つかった属性をリスト２８に加えて、新しいりスト３２を形成する。したがって 、更新されたリストから、ファイルＡは作成日が８９年５月３日であり、ファイ ルＢはファイル・システムには見あたらず（前述の空間回復手順が使用された場 合にこうなる）、ファイルＣは作成日が８８年４月２１日であり、ファイルＥは 作成日が８９年４月１日であることがわかる。制御論理機構１４は、ステップ３ ４で、アプリケ−シーン・ファイル・パッケージ用の位置アドレス情報（ＰＫＧ ＬＯＣ）をホストの制御論理機構１６に送り、ファイル情報のりスト３２をホス トに送り、返答を待つ。アドレス情報は、呼び出されたアプリケーションのＡＰ ＰＬ　Ｉ　Ｄを用いて、ワークスチーシロンのデータベース１０から導出される 。

ステップ３５で、第２プロセツサ４の制御論理機構１６が、ＰＫＧＬＯＣを受は 取り、リスト３２を複製リスト３３として第２プロセツサ４に記憶する。ステッ プ３６で、制御論理機構１８は、パッケージ・ファイル位置（ＰＫＧＬＯＣ）を 用いて、アプリケーション・パッケージ・ファイル２０を読み取り、第２プロセ ツサ４が識別されたアプリケーション用の現在最新のファイルとしてどんなファ イルを保持しているかをその属性と共に突き止め、新しいりスト３８をコンパイ ルする。

４つのファイルが必要であると示されている。作成日が８９年５月４日のファイ ルＡは、静的ファイル、すなわちアプリケーションを実行するたびに必要なファ イルである。作成日が８９年３月２３日のファイルＢも、やはり静的ファイルで ある。作成日が８９年４月１５日のファイルＤは、動的ファイル、すなわちアプ リケージ「ンを実行する際に時々しか必要でない任意選択ファイルである。作成 日が８９年４月１日のファイルＥは、もう１つの静的ファイルである。

ステ、ブ４０で、リスト３３をリスト３８と比較して、必要な更新動作のｒ差分 りスト」４２を生成する。動作としては、ＲＥＰＬＡＣＥ　（交換、第２プロセ ツサにファイルのより新しいバージョンが保持されている場合）　、ＤＥＬＥＴ Ｅ（削除、ファイルがリスト３３にはあるが、リスト３８にはない場合）および ＣＲＥＡＴＥ　（作成、ファイルがリスト３８にはあるが、リスト３３にはない 場合）が可能である。更新呼出しの場合、静的ファイルだけが更新される。差分 りスト４２の動作には、それらのファイルの新しい属性が関連する。したがって 、この例では、選ばれた差分りスト４２は、下記のものを含む。

ワークスチーシロンにあるリスト３２よりも新しいパージ、ｖンであるため、Ｒ ＥＰＬＡＣＥファイルのフラグをつけられたファイル八〇 ワークスチーシロンにはないため、ＲＥＰＬＡＣＥファイルのフラグをつけられ たファイルＢ０ ファイルＣは、そのアプリケ−シロンにはもはや不要な古いファイルであるため 、リスト３８には含まれない。したがって、ファイルＣは、差分りスト中でＤＥ ＬＥＴＥファイルのフラグをつけられ、ワークステーションにある対応するファ イルを削除することが必要となる。

ファイルＤは、アプリケーションからの要求時にのみ必要になる動的ファイルで あるため、差分りストには含まれない。

ファイルＥは、作成日が同じであることから証明されるように、ワークステージ タンにあるファイルがホストにあるファイルと同じレベルにあるので、差分りス トには現れない。

差分りスト４２は、ステップ４４で第１プロセツサ２に送られ、続いてステップ ４６で、それぞれのＣＲＥＡＴＥ／ＲＥＰＬＡＣＥ動作に対応するファイルがフ ァイル・システム１８から送られる。

アプリケ−シロンの実行中に必要なその他の静的または動的ファイルは、前述し たように、アプリケーション自体が発行するＰＲＥＰＡＲＥ　　ＦＩＬＥ呼出し に応答して、必要に応じてレベル検査および更新を受ける。

第１プロセツサ２に戻って、ステップ４８で差分りスト４２を受は取り、続いて ステップ５０で、現在の最新ファイルがそれぞれ必要に応じてダウンロードされ る。ステップ５２で、第１プロセツサ２は、送られてきたファイルを用いて、差 分りスト４２で指定された動作、すなわちデータ・ファイルの交換ならびにもは や不要となったファイルの削・除を実行する。たとえばファイルがすでに使用中 であるなど、理由はなんであれ更新動作に失敗した場合、後続の更新動作は試み られず、失敗が記憶され、その結果、ステップ５５で、成功／失敗のリターン・ コードをアプリケーションに戻すことができる。

ファイル更新が首尾よ〈実施されるのを助けるため、第１プロセツサ２は、ダウ ンロードされるファイルのために場所を空けるのに必要であれば、使用中でない 以前のアプリケーションのダウンロードされたファイルを追加的に削除する。

ファイルをファイル・システムに書き込む際に、その目的にとって十分なスペー スがない場合、システムがその旨の信号を送り返すことが示唆される。したがっ て、万一これが発生した場合、制御論理機構はデータベース１０を検査して、よ り多くの記憶スペースを提供するために削除できる、以前のアプリケ−シロンに 関連するファイルを探し、必要に応じてそれらを削除する。

最後にステップ５４で、データベース１０が、差分りスト４２からのファイルの リストで更新され、その後ステップ５５で、第１プロセツサ２からアプリケ−シ ロン・プログラム１２に制御が戻され、成功／失敗のリターン・コードが戻され る。失敗リターン・コードの場合、どのような動作を取るかはアプリケ−シロン が決定する。

第２の例では、第３図を参照して、現アプリケーションを更新するためにワーク ステーションで呼出しが発行された（上記の状況１）のに続いて、更新検査を実 行する動作の詳細なシーケンスを説明する。このより単純な状況では、必要な情 報はすべて、最初にコンパイルおよび複写され、通信システム６の両端で保持さ れるファイル・レベルのりスト３２．３３．３８および３９から即座に使用可能 である。この呼出しは、主として、アプリケ−シロン自体が制御を受は取る前に 、代理アプリケ−シロン１１が、そのアプリケーション・ファイルを更新するた めに発行する。

処理ステップのほとんどは第２図に示した処理ステップに対応しており、図中の 対応する囲みには同じ参照番号を付けである。変更された処理ステップおよび新 しい処理ステップだけについて説明する。

更新のための呼出しに続いて、ステップ１００（これは第２図のプロセッサ２の ステップ４０と等価である）で、ワークステージタンの制御論理機構１４は、先 に第１図を参照して説明したアプリケージ好ン起動処理の一部としてコピーされ 、ワークステージタンにダウンロードされ、ワークステージタンにリスト３９と して記憶された、ホスト・ファイル・リストと、現ワークスチーシロン・ファイ ルのりスト３２を比較する。ステップ１０１で、必要な更新動作の差分リストを 生成し、ホストに送る。ステップ１０２で、ホストの制御論理機構１６が差分り ストを受は取る。ステップ４Ｅｉ、５０．５２および５４は、第２図を参照して 説明したのと全く同じなので、ここでは繰り返さない。ステップ１０３で、ワー クステージタンの制御論理機構１４は、差分りストからのりスト３２を更新し、 ステップ１０４で、更新されたリス）・３２をホストに送り、アプリケーション に制御を戻す。ステップ１０５で、ホストの制御論理機構はワークステージタン にある新しいバージョンのリスト３２を受は取り、それを新しいりスト３３とし て記憶する。

第３の例では、現アプリケーションに必要な任意選択ファイルのレベルを検査す るためにワークステージ１ン呼出しが発行される、上記の状況２を説明する。こ のようなファイル（静的でも動的でもよい）を得るためには、アプリケージ四ン は第３図のＵＰＤＡＴＥ　　ＡＰＰＬ呼出しの代わりに、ＰＲＥＰＡＲＥ　　Ｆ ＩＬＥ呼出しを発行する。この呼出しは、アプリケーション実行中のどの段階で 発行してもよく、パラメータとして、第３図のＡＰＰＬ　Ｉ　Ｄの代わりに、レ ベル検査が要求された特定のファイルの識別子（Ｆ　Ｉ　ＬＥ　　Ｉ　Ｄ）が含 まれる。基本的にこの処理は、第３図に示した例を最適化したバージョンであり 、動的ファイルと静的ファイルの両方が作用を受け、各差分りストはせいぜい１ つのエントリしか含まない。この場合も制御論理機構は、ＰＲＥＰＡＲＥＦＩＬ Ｅ呼出しに応答して、その差分りストを作るのに必要なすべての情報を使用可能 である。

したがって、ステップ２４で、アプリケージロンが制御論理機構１６に呼出しく ＰＲＥＰＡＲＥ　　ＦＩＬＥ）を発行する。この呼出しには、パラメータとして 、必要なファイルを識別する変数（Ｆ　Ｉ　ＬＥ　　Ｉ　Ｄ）が含まれている。

したがってステップ４０で、ホストの制御論理機構は、ワークステ−シロンから のリスト３３とホストにあるリスト３８を比較し、差分りスト４２の単一エント リを生成する。この例では、選択されたファイルはファイルＤ１すなわち作成日 が８９年４月１５日の動的ファイルである。これはりスト３２には見つからない ので、差分りスト中で、作成日８９年４月１５日と共に、ＣＲＥＡＴＥファイル のフラグをつけられる。ステップ１０１で、差分りストが第１プロセツサ２に送 られる。ステ、プ４６で、プロセッサ２は、要求されたファイルをプロセ、す１ に送る。このとき、実際のファイルはファイル・システム１８から得られる。残 りの処理ステップは、第３図を参照して先に説明したのと同じである。

第４の例では、現アプリケージｅンに対するホスト更新呼出しが発行される、上 記の状況３を説明する。実際には、ワークステーションのＵＰＤＡＴＥ　　ＡＰ ＰＬＰＰ上が起動時に処理されるおかげで、アプリケージ甘ンは常に最新のもの になるので、これは有用な呼出しではない。しかし、完璧を期してここに含める 。やはり、第４図に示した処理ステップの多くは、第２図および第３図を参照し て以前の例で説明したのと同じである。すなわち、ステップ４０．４４．４Ｂ、 ４８．５０．５２および５４は、第２図を参照して説明したのと同じである。ス テップ１０３．１０４および１０５は、第３図で説明したのと同じである。ステ ップ４５で、ＡＰＰＬＩＤがプロセッサ１に送られ、ステップ４７でプロセッサ １がＡＰＰＬ　Ｉ　Ｄを受は取る。ステップ１０６で、ワークスチーシロンの制 御論理機構１４が、制御論理機構１６に成功／失敗標識を送る。ステップ１０７ で、制御論理機構１６が、成功／失敗［１１を受は取り、ステップ１０８でこれ を呼出し側に送る。

第５の例では、アプリケ−シロンに必要な任意選択ファイルに対するＰＲＥＰＡ ＲＥ　　ＦＩＬＥ呼出しをホストが発行する、上記の状況４を説明する。これは 、下記の細かい相違を除いて、第４図を参照して説明したＵＰＤＡＴＥ　　ＡＰ ＰＬＰＰ上の場合と同じである。ＵＰＤＡＴＥ　　ＡＰＰＬの代わりにＰＲＥＰ ＡＲＥ　　ＦＩＬＥ呼出しが発行され、この呼出しには、アプリケ−シロン・パ ラメータＡＰＰＬＩＤの代わりにファイル・パラメータＦＩＬＥ　　ＩＤが含ま れる。もう１つの相違点は、単一エントリの差分りストを作る際に、ＦＩＬ’Ｅ 　　ＩＤに一致する、静的ファイルおよび動的ファイルが存在するかどうか検査 することである。

上記の状況５は、すでに第２図を参照して、最初の例として詳細に説明済みであ る。

最後の第６の例では、第５図を参照して、現アプリケージ１ン以外のアプリケー ジ騨ンに対するＵＰＤＡＴＥ　　ＡＰＰＬをホストが発行する、上記の状況６を 説明する。上記と同様に、含まれる処理ステップの多くは、すでに説明した以前 の例と共通であり、ここでは説明しない。最初のステップ１０９は、ＵＰＤＡＴ Ｅ　　ＡＰＰＬＰＰ上に続く新しいステップであり、ホストの制御論理機構１６ は、ＡＰＰＬｉＤで識別されるアプリケージジンのホストのパッケージ・ファイ ル位置を、ワークスチーシロン・ファイル・レベルのコピーと共にワークスチー シロンから送るように要求する。ステップ１１０で、ワークスチーシロンの制御 論理機構１４は、ホストのパッケージ・ファイル位置とワークスチーシロン・フ ァイル・レベルを求める要求を受は取る。その後、第２図のステップ２６．３０ ．３４．３５および３６が続く。その後、第４図のステップ４０から始まる処理 ステップが最後まで続く。

ｌ１１１プロセツサ 第２プロセツサ プロセッサ２ 国際調査報告 国際調査報告 Ｇ８　ｇ９００８８６ ５＾　３０４３９

Claims (14)

【特許請求の範囲】
1. １．第１プロセッサ、第２プロセッサ、および前記第１プロセッサと前記第２プ ロセッサをリンクする通信システムを有し、前記プロセッサに付随する制御論理 機構が、前記第１プロセッサ上で実行中の１つまたは複数のアプリケーション・ プログラムに代わって、前記第１プロセッサと前記第２プロセッサの間の情報の 流れを管理する働きをするデータ処理ネットワークであって、前記制御論理機構 は、前記アプリケーションによって、またはそれに代わって発行された呼出しに 応答して、呼出し側アプリケーションに関連し、前記第１プロセッサによって記 憶された１つまたは１組のファイルが、そのアプリケーションに使用可能な、前 記第２プロセッサに記憶された１つまたは１組のファイルと同じ最新のバージョ ンであるか否かを判定し、そうでない場合には、第１プロセッサ上の前記の１つ または１組のファイルを、適宜前記第２プロセッサからダウンロードされた選択 されたファイルと交換しまたはそれで増補しあるいはその両方を行うことを特徴 とする、データ処理ネットワーク。
2. ２．請求項１に記載のデータ処理ネットワークにおいて、前記の１つまたは１組 のファイルが、呼出し側アプリケーションの必要とするものである、データ処理 ネットワーク。
3. ３．請求項１または２に記載のデータ処理ネットワークにおいて、前記の１つま たは１組のファイルが、呼出し側アプリケーションに関連する別のアプリケーシ ョンの必要とするものであり、呼出し側アプリケーションが、前記の別のアプリ ケーションに代わって、そのアプリケーション用の前記の１つまたは１組のファ イルに対して更新検査を実行するために呼出しを発行する、データ処理ネットワ ーク。
4. ４．請求項１または２または３に記載のデータ処理ネットワークにおいて、前記 第１プロセッサと第２プロセッサの間に制御論理機構が分散されており、プロセ ッサ１にあるファイルのレベルを検査するための更新呼出しを、制御論理機構の プロセッサ１にある部分または制御論理機構のプロセッサ２にある部分から開始 できる、データ処理ネットワーク。
5. ５．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前記制 御論理機構が、前記第１プロセッサによって記憶されたファイルを、前記第２プ ロセッサによって記憶された前記ファイルの更新されたバージョンと交換する必 要があるか否かを判定し、必要なら前記第１プロセッサによって記憶された前記 ファイルを交換するために、前記ファイルの前記更新されたバージョンを、前記 第２プロセッサからダウンロードする、データ処理ネットワーク。
6. ６．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前記制 御論理機構が、前記第１プロセッサによって記憶された１組のファイル中の１フ ァイルが古くなったファイルであるか否かを判定し、必要なら前記第１プロセッ サによって記憶された前記１組のファイルから前記の古くなったファイルを削除 する、データ処理ネットワーク。
7. ７．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前足制 御論理機構が、前記の１つまたは１組のファイルが、呼出し側の必要とする唯一 のものであるかどうか判定し、そうでない場合には、必要に応じて前記プロセッ サに記憶された１つまたは複数の追加ファイルをダウンロードすることによって 、前記の１つまたは１組のファイルを増補する、データ処理ネットワーク。
8. ８．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前記制 御論理機構に対して発行された呼出しによってアプリケーションが起動され、そ れによって前記第１プロセッサと前記第２プロセッサの間に前記アプリケーショ ン用の通信セッションが確立され、また前記通信セッションを用いて、前記の１ つまたは１組のファイルが、前述の交換または増補あるいはその両方を必要とす るかどうかが判定される、データ処理ネットワーク。
9. ９．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前記１ つまたは複数のアプリケーションを起動する際に、それらによって、またはそれ らに代わって呼出しが発行される、データ処理ネットワーク。
10. １０．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前記 制御論理機構がさらに、前記１つまたは複数のアプリケーションの実行中のどの 時点でも、前記アプリケーションが実行中に必要とするファイルを検査すること を要求する呼出しに応答する、データ処理ネットワーク。
11. １１．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前記 第１プロセッサが、第２アプリケーション用にダウンロードされるファイルのた めの場所を空けるために、第１アプリケーション用に保持されたファイルをその 記憶域から削除するようになされている、データ処理ネットワーク。
12. １２．前記のいずれかの請求項に記載のデータ処理ネットワークにおいて、前記 第１プロセッサが前記ファイルを検査して、前記ファイルが交換または削除ある いはその両方を必要とするかどうか判定する、データ処理ネットワーク。
13. １３．請求項１２に記載のデータ処理ネットワークにおいて、第１プロセッサに ある前記制御論理機構が、考慮中のアプリケーションに関連し、第２プロセッサ から以前にダウンロードされたファイルのリストを、第１プロセッサに記憶され た前記ファイルの検査から導出された、各ファイルごとのレベル情報と共にコン パイルする働きをし、第２プロセッサにある前記制御論理機構が、前記考慮中の アプリケーションが必要とし、前記第２プロセッサに最新バージョンとして記憶 されている現ファイルのリストを、前記各ファイルごとのレベル情報と共にコン パイルする働きをし、さらに前記制御論理機構が、この２つのリストを比較して 、前記第１プロセッサにある前記ファイルを更新するために必要な動作を指定す る差分リストを生成し、それに従ってこれらの活動を実行する働きをする、デー タ処理ネットワーク。
14. １４．請求項１３に記載のデータ処理ネットワークにおいて、第１プロセッサで コンパイルされたファイルのリストのコピーが、第２プロセッサに転送されて記 憶され、第２プロセッサでコンパイルされたファイルのリストのコピーが、第１ プロセッサに転送されて記憶される、データ処理ネットワーク。