JPH0786867B2 - 作業フロー制御方法、作業要求フロー制御方法及び装置、並びに通信管理装置 - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明はバスにおけるプロセス間の作業の流れの制御に
関し、具体的には、プロセッサ資源の共用のためのプロ
セス間の論理的接続の管理に関する。

B.従来技術 通信を行なうプロセスにとって通信方法がトランスペア
レントになっている従来の通信処理方法では、プロセス
を含む１つの装置が、バス上の別の装置によって作業が
実行されることを要求する。作用を受けるデータは要求
元の記憶域にあり、サーバ装置、すなわち、要求を実行
する装置はデータにアクセスできる。従来システムは、
プロセス間の論理的接続を正しく管理するための手段を
欠いていたので、最低水準のサービスしか得られなかっ
た。サービスの水準は、割り振られたシステム資源によ
り左右される。

プロセスのプログラミング処理の見地からいうと、共用
される資源とは、サーバ・プロセスによって提供される
作業である。この資源の単位は作業要求である。任意の
サーバのすべてのユーザは、その資源に対する最低水準
のアクセスを保証されていなければならない。すなわ
ち、すべてのユーザは、幾つかの未処理の作業要求を有
することを許されなければならず、かつこれらの要求が
最後には処理のためにサーバにもたらされることを保証
されていなければならない。

大部分のバス・システムは、個々の信号線を使って、作
業要求を示すメッセージの受容または拒絶を確認する。
遠隔通信アプリケーションの場合は、流れ制御のために
歩調合せ機構が設けられている。SNAはカウント機構を
使用する。メッセージの送り手は、確認を受け取るま
で、最大数のメッセージが未処理であることを許され
る。未処理であることが可能なメッセージの数はメッセ
ージの受信側が設定しなければならず、未処理のメッセ
ージの歩調合せ制御はメッセージの送信側の責任でなけ
ればならない。したがって、個々の送信側及び受信側が
流れ制御に直接係る。

米国特許第4449182号では、コマンド・リング及び応答
リングが、ホスト・プロセッサの主記憶装置に記憶され
ている。それらは、入出力制御プロセッサに対するコマ
ンド用のスペース、及び制御装置からのコマンドに対す
る応答用のスペースを含む。各入出力制御装置ごとに１
つの応答リング及び１つのコマンド・リングがある。所
有権ビットを使って、入出力制御装置によってまだ処理
されていないコマンドまたはホスト・プロセッサによっ
てまだ読み取られていない応答をプロセッサの１台が書
き換えることを防止する。コマンド・リングが満杯であ
るか、または応答リングが空である場合は、ホストは、
コマンド・リングが満杯になっていないか、または応答
リングが空になっていないことを示す割込み信号を受け
取るまで、リングの検査をしないよう指示される。両方
のプロセッサは、読み取るべき、または書き込むべきリ
ング内の次の場所を示すポインタを含む。したがって、
非常に原始的な形で、装置間の簡単な形式の流れ制御が
確立された。

C.発明が解決しようとする課題 上記特許は、互いに通信する複数のプロセスに対する資
源割振りの問題を扱っていない。上記特許は、いずれか
のプロセッサで実行される複数のプロセスによる最低水
準のサービスを保証しない。多重プロセス環境における
通信は、異なる待合せ遅延及びプロセスの独立性のた
め、はるかに複雑である。

D.課題を解決するための手段 分散プロセッサ・ネットワークにおけるバス装置用の通
信管理機構は、各プロセスで最低水準のサービスが得ら
れるように、通信プロセス間の論理的接続を管理する。
バス装置とは、分散プロセッサ・ネットワークにおける
バスに接続された処理装置であり、たとえば、１台ない
し複数のホスト・プロセッサまたは入出力プロセッサを
備えることができる。プロセス間の論理的接続は、バス
管理機構により、各プロセッサで接続グループとしてま
とめられる。各接続グループは、少なくとも１つの作業
要求を実行するのに十分なプロセッサ資源を与えられ
る。接続グループが既にその限界まで未処理の作業要求
を有するときは、バス管理機構は、そのグループが満杯
になった後で作業を要求したプロセスを含むバス装置
に、それらの要求が今は実行できないことを知らせる。

ハードウェアの待合せ遅延のため、要求元プロセスは、
満杯になった接続グループに接続されたプロセス向けに
さらに作業要求を送る場合がある。バス管理機構は再び
この要求を拒絶し、起動側のバス装置にその旨を知らせ
る。作業が接続グループ内のプロセスによって終了され
ると、バス管理機構は、今や他の作業要求を受け入れる
ことができることをバス装置に知らせる。送られた順に
作業要求を処理することが望ましいので、要求元バス装
置はその作業要求を正しい順序で再開し、次に作業要求
の受入れを再開することをサーバ・プロセスのバス装置
に知らせる。要求元バス装置は次に、要求元から再開メ
ッセージを受け取った後に始めて、サーバのバス装置に
よって受け入れられる要求を送る。

接続グループは大きな利点をもたらす。それは最低のプ
ログラミング・レベルにおける単一の流れ制御機構であ
り、すべてのバス装置に対して使用される。バス装置の
役割とは無関係に、ホスト・プロセッサ、または通信、
補助記憶装置、作業端末等様々な種類の装置をサポート
する入出力制御装置は、すべてこの流れ制御機構を使用
する。それは、すべてのバス装置に対して同じであるの
で、バス上で対等環境をサポートする。

接続グループは、他のバス装置による大量の活動により
バス装置が別のバス装置のサービスから切断されるのを
防ぐ。そうするために、バスに接続された各プロセッサ
ごとに少なくとも１つの接続グループを必要とし、かつ
その接続グループを２台の独自のプロセッサ上のプロセ
ス間の接続用にのみ使う。したがって、他の２台のプロ
セッサに結合されたプロセッサは、少なくとも２つの接
続グループ（各プロセッサについて１つ）を有さねばな
らない。

１つの好ましい実施例では、通信が所望される他の各プ
ロセッサとの通信用に、３種類の接続グループがある。
低活動プロセスは、任意の一時に少量の作業要求しか受
け入れることができない接続グループに属する。中活動
プロセスは、それよりも多くの作業要求を受け入れるこ
とができる接続グループに属し、高活動プロセスは、大
量の作業要求を受け入れるため多くのシステム資源を有
する接続グループに属する。したがって、予想される作
業水準に基づいて様々なプロセスに対してサービスの水
準が保証される。

上記メッセージを使って接続グループが満杯になったと
きを示し、かつその接続グループで拒絶されたメッセー
ジの再送を調整すると、さらに利益がもたらされる。作
業がその意図された順序で実行されることが保証され
る。

接続グループを用いると、１つの接続グループを、臨界
状況で資源を解放することを役割とするプロセスに割り
当てることが可能となる。したがって、少なくとも１つ
の作業要求をこのグループが受け取ることができる場合
は、資源を解放することができる。資源を解放する１つ
の手段は、作業を完全に中止し、システムをリセットす
ることである。

資源をグループにまとめることのもう１つの利点は、一
層多くの装置をサポートできることである。各装置は、
装置が動作するために必要とされる最小限の資源を有す
る。（１台の装置当り必要とされる最小数×グループ内
の装置数）よりも少ない資源を接続グループに設けるこ
とにより、一層多くの装置をシステムに接続することが
できる。一例はテープ駆動装置である。複数のテープ駆
動装置を接続することが望ましく、各駆動装置がデータ
を緩衝記憶するために大量の記憶域を必要とする場合
は、各テープ駆動装置に十分な資源を割り当てると、直
接アクセス記憶装置が利用できる資源がほとんど残らな
いことになる。テープ駆動装置を１つの接続グループに
組み入れ、同時に１台または２台だけが動作するのに十
分な資源を割り振ることにより、直接アクセス記憶装置
に十分な資源が利用できるようになる。テープ駆動装置
に、また直接アクセス記憶装置にも、保証された水準の
サポートが与えられる。５台のテープ装置が同時に動作
することはまずあり得ないので、全体的サービスは低下
しない。

E.実施例 第２図は、本出願人の米国特許第4649473号から取った
ものである。第２図は、読者が本発明をより明確に理解
するための基礎知識を与える。すぐ後で、根底にある通
信管理にプロセスが気づかないようなプロセス間通信を
中心にして、第２図について説明する。根底となるバス
転送機構、及び本発明の主題であるバス管理機構につい
ては後の部分で説明する。

第２図で、分散処理環境の概略図を全体的に10で示す。
プロセッサA12は、線14で示す物理的経路によって、プ
ロセッサB16に結合される。プロセッサＡは、その中に
プロセスA18とプロセスB19が存在するものとして示され
ている。記憶部20は、それぞれデータ記憶部のプロセス
制御及びデータ記憶部に対するアクセスをもたらす線21
及び22によって示すように、プロセスＡ及びプロセスＢ
と関連づけられている。

プロセッサＢは、その中にプロセスC23とプロセスD24が
存在するものとして示されている。記憶部25は、それぞ
れデータ記憶部のプロセス制御及びデータ記憶部に対す
るアクセスをもたらす線26及び28によって示すように、
プロセスＣ及びプロセスＤと関連づけられている。

プロセス、すなわち、プロセッサ内の実行プログラムは
互いに通信する必要がある。異なる構成のプロセッサ、
または経時変化する同一プロセッサでは、２つのプロセ
スは異なる相対位置をとることがあり、またそれらの間
の物理的経路が異なることがある。

プロセス間通信機構（IPCF）が、プロセッサＡ及びプロ
セッサＢ内のそれぞれ30及び32に設けられ、プロセス間
通信を調整する。これは、通信を行なうプロセスにとっ
てトランスペアレントな位置である。IPCF30は、線34で
示すように、プロセッサＡ内のプロセスＡに結合され、
また、線36で示すように、プロセスＢに結合されてい
る。線34及び36はプロセスＡ及びプロセスＢとIPCF30の
間のインターフェースを表わす。これらのインターフェ
ースは、適当なデータ経路が確立されていることを条件
として、プロセスＡとプロセスＢの間の通信を可能にす
る。IPCF30またはプロセッサＢ内の転送機構40を介して
IPCF32に結合されている。IPCF32は、インターフェース
線42及び44で示すように、プロセスＣ及びプロセスＤに
結合されている。これらのインターフェースは、通信を
している相手のプロセスの位置について当該プロセスが
知ることなく、示されたすべてのプロセス間の通信を確
立することを可能にする。転送機構38及び40は、プロセ
スＡ及びプロセスＢ、またはプロセスＣ及びプロセスＤ
が単一プロセッサ内で通信するときに使用できるよう
に、ローカル転送機構等の複数の転送機構を含むことが
好ましい。プロセッサＡとプロセッサＢが同じ機械内に
ある場合は、バス転送機構を使って、プロセッサＡ及び
プロセッサＢ上のプロセス間の通信を容易にする。機械
間の通信のためには、SNA等の通信プロトコルが使用に
適する。

転送機構38、40はデータ移動機構である。それらは、デ
ータ・バイトをある場所から別の場所に転送する責任を
負い、移動される情報の意味を理解しない。すなわち、
プロセッサＡ内の記憶部20は、線46で示すように転送機
構38に結合され、プロセッサＢ内の記憶部25は、線48で
示すように転送機構40に結合され、転送機構38、40によ
る直接の情報転送を可能にする。

通信を試みるプロセス用のIPCFは、通信のために転送機
構を選ぶ。通信を行なうプロセスは、使用される機構に
ついて知っている必要はない。通信を試みるプロセスは
既に知っている目標プロセスの名前をIPCFに供給し、IP
CFは適当なディレクトリ・サービスを使ってそれを探し
出す。IPCFは次に適当な転送機構を選択し、システムか
ら供給されるサービスを使って通常の方法でプロセス間
の接続をセットアップする。IPCFは、アプリケーション
からページング管理機構等の基本システム・サービスま
で、すべてのレベルのプロセスで使用することができ
る。

各々異なる能力及び特性を有する多数の異なる転送機構
の使用を可能にするため、IPCFは各プロセスに対する総
称転送機構インターフェースを含んでいる。このインタ
ーフェースは、接続の確立及びプロセス間での情報の移
動のための一組の機能を定義する。定義された機能は、
IPCFにより使用される転送機構にマップされる。インタ
ーフェースに対して書かれるプログラムは転送機構から
独立しており、したがって、通信時のそれらの相対位置
から独立している。

プロセス間の通信は、IPCFによって確立されたそれらの
間の接続を介するメッセージの送受信による。メッセー
ジは作業要求またはデータあるいはその両方を含む。特
定の作業要求に関して、プロセスは要求元またはサーバ
の役を引き受ける。要求元は、要求を実行するサーバに
要求を送ることにより作業要求を開始する。要求は作業
要求（コマンドとそのパラメータ）及び任意選択として
幾らかのデータを含む。要求及びデータは共に可変長で
ある。

IPCF、及び接続の確立方法についてさらに詳しい情報を
知りたい場合は、上記特許にさらに詳細な説明が出てい
る。次に、転送機構38及び40の一部であるバス管理機構
について説明する。

バス管理機構 第１図で、バス装置50及び52は入出力バス54等の物理的
経路で結合されている。好ましい一実施例では、バス装
置50は、線60を介して主記憶装置58と結合されたプロセ
ッサ56を備えたホスト処理システムを含む。ホスト・プ
ロセッサ56は、財務会計プログラムからオペラーティン
グ・システム・プログラムに至るまで、複数のプログラ
ムを実行する。プログラムの実行段階はプロセスと呼ば
れる。幾つかのプロセスPA1〜PAn、PB1〜PBn及びPC1〜P
Cnがホスト・プロセッサ56内に示してある。

バス装置52は、好ましい一実施例では、線70によって主
記憶装置68と結合された入出力プロセッサ66を含む。入
出力プロセッサ66もまた実行可能な幾つかのプロセスPD
1〜PDn、PE1〜PEn及びPF1〜PFnを有する。プロセッサ56
及び66の各々に多数のプロセスが示されているが、プロ
セッサがただ１つのプロセスを有する場合もあり得る。
他の実施例では、プロセッサ66はプロセッサ・ネットワ
ーク内の対等プロセッサである。プロセスは、その位置
がどこであっても、バス装置50内のIPCF72及びバス装置
52内のIPCF74を介して互いに通信をする。通信を行なう
プロセスの各対は、バス装置50内の80及びバス装置52内
の82で示す論理的接続により、IPCFを介して論理的に接
続される。

接続の確立は、上記特許にさらに詳細に記載されてい
る。要約すると、IPCFオープン動詞が２つのプロセス間
のIPCF接続を確立する。接続は、通信する各プロセス対
にとって固有である。したがって、線80の各々が線82の
１本と対になる。第１図に示すよりも多くの入出力プロ
セッサまたはホスト・プロセッサがあることもあるの
で、線82よりも線80の方が多い場合は、図示していない
プロセッサ内のプロセスに対する接続を表わす。通信を
開始しようとするプロセスによってオープン動詞が出さ
れると、IPCFは、オープン動詞を出したプロセスと、オ
ープン動詞によって指定される目標プロセスの間に論理
的接続を生成させる。オープン動詞の目標はエンティテ
ィ名によって識別される。オープン動詞は、オープン動
詞に供給されたエンティティ名に基づいて、プログラム
の新しい段階または既に実行中の段階に対する接続を確
立する。

オープン動詞は、サーバ内のプログラム、及び接続され
るそのプログラムの実行段階（プロセス）を判定するた
めにIPCF及び関連するオペレーティング・システムが使
用するエンティティ名を含む。接続IDは、接続を識別す
るもので、IPCFによって返される。接続IDは、後続の操
作でこの接続を参照するために使用される。特定の接続
IDは単一プロセッサ内でのみ知られている。接続された
２つのプロセスは一般に、同じ接続に対して異なる接続
IDを有する。接続IDはローカルIPCFによって割り当てら
れ、プロセッサ内で一意的である。IPCFは、戻りコード
を用いて、オープン動詞の完了をプロセスに示す。

バス管理機構86は、図では、既に確立された幾つかの論
理的接続80によってホスト・プロセッサ56に結合されて
いる。図では、同様のバス管理機構88が、バス装置52内
にあり、同様に82で複数の接続を有する。バス管理機構
86は、第２図のバス装置中の38及び40で示されるバス転
送機構によって実行されるのと同じ機能を提供する。

バス管理機構86及び88は接続を管理し、バス54上に作業
要求の流れを制御するメッセージを出す。90及び92で示
される、バスをサポートするハードウェアは、各バス装
置についてバス・アービトレーションを実行し、別のバ
ス装置の主記憶装置に対するDMA転送を制御し、更にバ
スの制御が得られてメッセージとデータの転送が可能に
なるまでそれぞれのバス管理機構からのメッセージを待
ち行列に入れる。バス・ハードウェアはまた、バス装置
からのメッセージの主記憶待ち行列への入力を制御す
る。

バス管理機構86は、バス装置52で出されるオープン動詞
によって起こる通信を受け取り、指示されたプロセスに
対する接続を確立する。目標プロセス（すなわち、サー
バ・プロセス）の識別子、要求元プロセスの識別子、特
定の装置が実行する作業の種類その他の情報を使って、
その接続に対する接続IDを、CG1、CG2、…、CGnで示さ
れる複数の接続グループの１つに割り当てる。これらの
情報の一部は、バス装置52との通信に含まれ、他の情報
は主記憶装置58に含まれ、バス装置52から供給された情
報に基づいてアクセスされる。次にその情報に基づいて
割当てが行なわれ、好ましい一実施例では開発者が予め
構成する。

接続グループは、作業要求の流れを制御するために使わ
れる。各作業要求は、プロセスのためにシステム資源を
必要とする。全作業要求が先入れ先出し方式で処理され
る場合、幾つかの高資源要求装置が、他の装置がサービ
スされるのを妨げることになる。

大量の主記憶資源を必要とする装置の一例はテープ駆動
装置である。テープ装置を、その最も効率的な動作モー
ドであるストリーミング・モードで動作させるには、大
きい主記憶バッファが必要である。複数のテープ駆動装
置を接続しようとし、各々が、ストリーミング・モード
で動作するときにデータを緩衝記憶するために大量の記
憶域を必要とする場合は、各テープ駆動装置に十分な資
源を割り当てると、直接アクセス記憶装置に割り振るの
に使用できる資源がほとんど残らなくなる。テープ駆動
装置を１つの接続グループに組み入れ、同時に１台また
は２台だけが動作するのに十分な資源を割り振ることに
より、直接アクセス記憶装置が利用できる資源がずっと
多くなる。テープ駆動装置にも直接アクセス記憶装置に
も保証された水準のサポートが提供される。５台のテー
プ装置が同時に動作することはまずあり得ないので、全
体的サービスの低下はない。

また接続グループを使って、幾つかのホスト・プロセス
にサービスするために資源が常に使用できるようにする
ことができる。その一例は、ホスト保管／復元プロセス
とそれに対応する入出力プロセスとの間のサーバ側接続
を、その接続だけを含む接続グループに入れることであ
る。すなわち、サーバ・プロセスは他のグループに対す
る接続を持つことができるが、資源は常にホスト保管／
復元作業要求を処理するために使用できる。

グループを割り当てるための１つの基準は装置の動作特
性である。テープ駆動装置等の大量データ移動装置はと
きどき使用されるだけであり、１つのグループに入れら
れる。主記憶装置へのページ・イン及び主記憶装置から
のページ・アウトを頻繁に行なう直接アクセス記憶装置
等の装置は、別の１グループに入れ、高水準のサービス
を確保するために大量の資源がそのグループに割り振ら
れる。作業端末等の他の装置はさらに別のグループに入
る。十分な資源が使用可能な場合、各装置はそれぞれ独
自のグループを構成する。

装置のグループ分けを簡単に言うと、その装置に関連す
るプロセスへの接続が１つのグループに入れられる、と
いうことになる。接続のグループへの割当ては、さら
に、サービスされている作業要求の種類に基づいて行な
われる。エラー状態の処理及び保守に関連するその他の
作業要求に関係する接続は、そのような要求に対して最
低水準のサービスを保証するため、さらに別のグループ
に入れてもよい。接続グループを使って資源を割り振
り、したがって作業の流れを制御することにより、大き
な融通性がもたらされることが分かる。

バス装置50がサーバとして働くとき、その各接続グルー
プは主記憶装置58内の第３図の制御ブロック120にリス
トされる。制御ブロック120は、各接続グループCG1〜ｎ
ごとにGPID（グループIDを表わす）と記した項目を含
む。欄122に示すカウンタは、GPID項目と関連してお
り、グループ内の接続を介して受け取ったがバス装置50
内のプロセスによってまだサービスされていない作業要
求の数を記録するために使用される。活動接続ID（CI
D）のテーブル125は、120の接続グループ項目を指すポ
インタを有し、ある接続が含まれるグループを識別す
る。バス装置52も未処理の作業要求の数を記録するため
の同様の機構を有する。

上記作業要求の流れの利点の１つは、接続グループ内の
（同じ優先順位を有する単一接続に対する）作業が、最
終的に要求元バス装置によって要求された順に処理され
ることである。したがって、１つのプロセスに対して、
ある優先順位のデータ書込み要求が複数発生した場合
は、たとえ、資源が使用可能でない時間があったとして
も、要求された順にデータが書き込まれる。このことは
すべて、要求元プロセスにとってトランスペアレントな
形で行なわれる。

次に第４図及び第５図を参照しながら要求元バス装置内
の流れ図について説明する。要求元バス装置から出る作
業要求を記録するために４つの待ち行列が使用される。
各待ち行列は、作業要求を指すポインタ、要求ID、及び
オープン・プロセス中に通信されるサーバ・バス装置内
の対応する接続グループを含む。送信準備完了待ち行列
は、サーバ・プロセッサに送られる準備ができた作業要
求をエンキューするため、通常の作業要求の流れで使用
される。送信準備完了待ち行列内の要求に対して操作開
始メッセージが送られると、ポインタは取り除かれ、応
答待機待ち行列に入れられる。操作終了メッセージを受
け取ると、その作業要求に対する項目がすべての待ち行
列から取り除かれる。この通常の流れを、第４図のブロ
ック150、152及び154で示す。なお、図面では待ち行列
をＱで表わしてある。

作業要求に応答して待ち行列満杯標識が返されると、15
6で、完了待機待ち行列から拒絶待ち行列に移され、待
ち行列満杯メッセージを受け取ったという標識が、その
対象となる接続グループに関連づけられる。次に158
で、その接続グループがこのとき使用可能な空間を有す
ることを示すＱ空間フラグが検査される。このフラグは
通常はオフであり、バス管理機構は通信の送受信を続行
する。このようにして、待ち行列満杯標識が返された完
了待機待ち行列上の各作業要求は、拒絶待ち行列に入れ
られる。

第５図では、バス管理機構が、送信準備完了待ち行列内
の次の項目に対応する別の操作開始メッセージを送る準
備ができると、160で、サーバ・バス装置内の接続グル
ープに対する接続グループ満杯標識の有無について検査
する。接続グループ待ち行列が一杯であることを示す場
合は、162でその要求に対する項目が中間待ち行列に入
れられる。一杯でない場合は、164で操作開始メッセー
ジが送られ、166で、要求項目が完了待機待ち行列に入
れられる。

第４図の流れ図に戻って、168で要求元プロセッサが待
ち行列空間使用可能メッセージを受け取ると、170でＱ
空間フラグがセットされ、識別された接続グループ内で
待ち行列満杯メッセージを受け取った項目の後に項目が
あるかどうか完了待機待ち行列が検査される。完了を待
つすべての要求について待ち行列満杯メッセージが返さ
れていない場合は、174でバス装置は次の通信を待ち続
ける。

172で全部が肯定応答された場合は、176で拒絶待ち行列
から送信準備完了待ち行列の先頭に項目が移される。次
に178で、要求項目が中間待ち行列から送信準備完了待
ち行列における拒絶待ち行列からの要素の後に移され、
180でＱ空間フラグがリセットされる。182で待ち行列再
開メッセージが送信され、184でバス管理機構が送信準
備完了待ち行列から送信を開始する。

第６図に、上記の流れで使用される待ち行列を示す。作
業要求に対応する待ち行列項目の流れを矢印で示す。送
信準備完了待ち行列200は通常、線202を介して完了待機
待ち行列210に項目を転送する。待ち行列満杯状況を受
け取った場合は、線222を介して完了待機待ち行列210か
ら拒絶待ち行列220に項目が転送される。その間に、送
信準備完了待ち行列200で新しい作業が開始されると
き、既に満杯の接続グループに対する作業要求があるこ
とが検出された場合、その作業要求は、線232を介して
中間待ち行列230に転送される。満杯の接続グループに
向けられた完了待機待ち行列210からの全項目が拒絶待
ち行列220に転送され、待ち行列空間使用可能メッセー
ジに応答して待ち行列再開メッセージが送られると、拒
絶された要求が線234を介して送信準備完了待ち行列200
の１番上に送り返される。次に、線236を介して、この
とき他の作業に使用可能な資源を有するグループに向け
られた他の要求が、送信準備完了待ち行列200の前に拒
絶された要求の後ろに転送される。

サーバ・バス装置での対応する流れを第７図及び第８図
に示す。250でサーバ・バス装置が操作開始メッセージ
を受け取ると、252で接続グループが決定され、254でそ
のカウンタが増分される。カウンタの限界値を使って、
ある接続グループが任意の一時点で持ち得る未処理の作
業要求の数が指定される。256でカウンタの値がカウン
タ限界値と比較され、値が限界値よりも大きい場合は、
258で待ち行列満杯フラグがセットされ、かつ260で待ち
行列満杯状況がバス・エラー状態メッセージで要求元バ
ス装置に送られ、261で処理が継続する。他の実施例で
は、使用可能な実際の資源が監視され、操作開始メッセ
ージで示される作業要求にとって必要とされる資源と比
較される。カウンタの値は限界値よりも大きくないが、
262で待ち行列満杯フラグがオンであることが検出され
た場合は、260に戻り、操作開始メッセージに応答して
待ち行列満杯状況が送られ、そうでない場合は、264で
要求の処理が続行し、266で流れが継続する。250で受け
取ったメッセージが操作開始メッセージでない場合は、
268でそれが待ち行列再開メッセージかどうか調べるた
め検査される。違う場合は、270で処理が継続する。待
ち行列再開メッセージである場合は、272で待ち行列満
杯フラグがリセットされ、274で処理が継続する。

待ち行列満杯状態を解消するには、サーバ・プロセッサ
はもっと多くの資源を割り振り、未処理の要求の限度を
増大させるか、または満杯接続における要求の少なくと
も１つに関する作業を完了しなければならない。この流
れを第８図に示す。作業要求が完了されると、280で関
連する接続グループのカウンタが減分される。282で操
作終了メッセージまたはバス・エラー状態メッセージの
いずれかが送られる。次に、284で待ち行列満杯フラグ
が検査され、フラグがオフである場合は、285で処理が
継続する。待ち行列満杯フラグがオンにセットされてい
る場合は、286で接続グループ・カウンタが限界値未満
であるかどうか調べるための検査が行なわれる。この限
界値はブロック286で「低値」と呼ばれているが、前述
の限界値と同じである必要はない。多数の要求に十分な
資源が使用可能であるようにするため、さらに低い限界
値を設定することが望ましい。こうすると、要求元の待
ち行列の再開に続いて複数の要求が迅速に送られるとい
う待ち行列満杯がずっと続く状態をなくすのに役立つ。
カウンタが低値よりも小さくない場合は、287で処理が
継続する。286でカウンタが低値未満の場合は、288で待
ち行列空間使用可能メッセージが送られ、290で処理が
継続する。

好ましい一実施例では、X.25、LAN、SDLC及びその他の
通信プロトコルを実行するプロセスに対する接続を含む
各通信プロトコルごとに別々の接続グループがバス装置
50内で定義される。

別のグループは、エラー処理プロセス接続を含む。更に
別のグループは、一般的保守プロセスに関連する接続用
である。

さらに別のグループが、バス装置52によって制御される
ディスク駆動装置との間のデータ転送に関係するプロセ
スに対する接続等の通常の機能を含む。

接続グループの数が様々に変わっても、それは本発明の
範囲内に含まれる。プロセスによっては大量の資源を必
要とするものもあるので、そのような各プロセスに対す
る接続に対して単一の接続グループを設けることが望ま
しいことがある。どんな接続のグループ分けが望ましい
かは、実際のインプリメンテーションと、互いに通信し
合うプロセスの特性に応じて決まる。

ホスト・プロセッサ56内のプロセスと入出力プロセッサ
66内のプロセス間の接続を確立すると、バス管理機構88
は接続を完了し、そのプロセス接続を多数の接続グルー
プCG1、CG2……CGnの１つに割り当てる。したがって、
別のプロセスに対する接続を有するバス装置を含むシス
テムでの各プロセスごとに、目標プロセスがあるプロセ
ッサのバス管理機構は、その接続をあるグループに割り
当て、そのグループに割り当てられた接続上の作業要求
を処理するために使用される資源を、その接続グループ
に割り振る。

流れ制御バス・メッセージ 接続グループが、そのグループに接続されたプロセスに
向けられた要求をプロセスするのに十分な資源を持たな
いときは、メッセージを制御し再同期するために、メッ
セージがバス管理機構間で転送される。目標バス装置が
特定の接続グループに対する追加の作業を受け入れるこ
とができないときは、待ち行列満杯状況を示すメッセー
ジを返す。この状況はバス・エラー状態メッセージ内に
含まれ、このメッセージのフォーマットを第９図に示
す。バス・エラー状態メッセージは、動作の正しい完了
または継続を妨げる障害を報告するため、要求に対する
通常の応答の代わりに返される。バス・エラー状態メッ
セージが送られるその他の幾つかの状態には、メモリ・
アクセス要求におけるアドレッシング・エラー、フォー
マット・エラー、及び未定義メッセージまたはサポート
されていないメッセージの受取りがある。他の幾つかの
状態でも、バス転送機構の物理的インプリメンテーショ
ンに応じて、このメッセージの送信が必要となることが
ある。

バス・エラー状態メッセージ内の予約と記されたフィー
ルドは、将来の使用のために予約されている。バス装置
フィールドは、メッセージの出所を識別するために使用
される。これは本発明では無視される。３番目のフィー
ルドであるメッセージID（82）は、メッセージをバス・
エラー状態メッセージとして識別するために使用され
る。制御フィールドは、障害に出会っている固有の要求
または接続を識別するための情報を含む。このフィール
ドの内容は、障害及び障害に出会っている特定の転送メ
ッセージ/DMA及び流れの方法によって決まる。CFIDフィ
ールドは制御フィールドの内容を識別する。様々な値
で、制御フィールド内の情報が要求元ID、またはサーバ
接続ID、または制御ブロックのアドレス等であることを
示す。それは、メッセージが送られた理由、及び誰が送
ったかに依存する。ACTNフィールドは、講じるべき回復
処置を識別する。ある値は、処置が講じられないことを
示し、別の値は接続のクローズ開始を要求し、別の値
は、通信を再同期するためのリセットを引き起こす。

待ち行列満杯状態はエラー状況フィールドで示され、そ
の後に満杯になった接続グループを識別する接続グルー
プIDが続く。これは、アドレスされたバス装置によって
メッセージが実行されなかったことを示す。制御フィー
ルドは、待ち行列満杯状況が示されるとき、異なった値
を含む。このフィールドは、データが転送される方式に
応じて、制御ブロック・アドレス、または要求元のIDを
含むことがある。データを転送する種々の方式について
は、本明細書の流れ制御の部分でさらに説明する。また
エラー状況フィールドは、上記のような他のエラー状態
の状況を識別するためにも使用される。

待ち行列満杯状況を要求元バス装置に送った後、それを
送った目標バス装置のバス管理機構は、接続グループに
サービスするのに十分な資源がいつ使用可能か判定する
ため、当該の接続グループを監視する。

目標バス装置が、その特定の接続グループ内で使用可能
な空間を有するときは、待ち行列空間使用可能メッセー
ジを要求元バス装置に送る。待ち行列空間使用可能メッ
セージは、待ち行列空間が使用可能であることを要求元
のバス管理機構に示すために使用される。このメッセー
ジは、バス装置が待ち行列満杯状況を要求元バス装置に
送った後に始めて、該バス装置によって送られる。この
メッセージは、どの接続グループが使用可能な待ち行列
空間を有するかを示す。待ち行列空間使用可能メッセー
ジのフォーマットを第10図に示す。４つの予約フィール
ド、メッセージIDフィールド、及び使用可能な待ち行列
空間がある接続グループを一意的に定義するグループ・
フィールドがある。

要求元バス装置は待ち行列空間使用可能メッセージを受
け取り、目標バス装置上のその接続グループに送られた
作業要求の数を決定する。通信は非同期的に行なわれ、
要求元バス装置のハードウェアに内部的な待ち行列遅延
があり得るので、要求元バス装置が、作業を開始するた
めにより多くのメッセージを既に送ってしまっている可
能性がある。

再度送るべき通信、すなわち、待ち行列満杯状況を返さ
せたメッセージよりも時間的に後で生じ、かつ満杯の接
続グループに向けられた通信が識別されると、要求元バ
ス装置のバス管理機構は待ち行列再開メッセージを出
す。このメッセージは、目標プロセッサ内の接続グルー
プに順番通りでなく受け取られたメッセージがないこと
を確認するために使用される。待ち行列空間使用可能メ
ッセージが出された直後に接続グループがメッセージの
受取りを開始する場合は、ある作業が順番通りでなく処
理されることがあり得る。これは、要求元バス装置が待
ち行列満杯状況を受け取る前に要求元バス装置から出さ
れ、かつ待ち行列空間使用可能メッセージの発生後に、
目標バス装置管理機構に受け取られたメッセージによっ
て開始される作業である。

待ち行列再開メッセージのフォーマットを第１図に示
す。このフォーマットは、メッセージ（0D）IDフィール
ドでそれがどのような種類のメッセージであるか識別
し、グループ・フィールドで、その待ち行列を再開する
ための接続グループを識別する点で、待ち行列空間使用
可能メッセージに類似している。目標バス装置のバス管
理機構は、待ち行列再開メッセージを受け取るまで、作
業開始の各メッセージに対して待ち行列満杯状況を返
す。

メッセージの流れの例 第12図に、目標バス装置内の接続グループについての待
ち行列満杯に応答して行なわれるメッセージの交換を示
す。目標バス装置はサーバと記し、要求元バス装置は要
求元と記してある。要求元とサーバの間の矢印は、各メ
ッセージを受け取ったバス装置を指す。かっこ内の数字
はメッセージの順序を示している。次に、各事象をそれ
らが第12図で現われる順に列挙する。

1.要求元プロセッサは、作業を開始するメッセージをサ
ーバ・プロセッサに送る。このメッセージは操作開始
（１）メッセージ（後ほど定義する）と呼ばれる。

2.サーバ・プロセッサは、操作開始メッセージが向けら
れた接続グループに対する待ち行列満杯状態を認識し、
待ち行列満杯状況を含むエラー・メッセージを返す。

3.バス装置が非同期であるため、要求元は待ち行列満杯
状況にまだ気づかず、第２のメッセージ、すなわち操作
開始（２）をサーバに送る。

4.サーバは前の作業要求を完了していると、操作終了メ
ッセージを送って、そのことを要求元に知らせる。

5.サーバは前の作業要求を完了したので、使用可能な資
源、すなわち、使用可能な待ち行列空間を有し、待ち行
列空間使用可能メッセージを要求元に送る。

6.要求元のハードウェアの待合せ遅延のため、要求元は
待ち行列満杯状態を認識しておらず、操作開始（３）メ
ッセージを送る。

7.サーバは、待ち行列再開メッセージを受け取るまで、
待ち行列満杯状況を要求元に返し続けなければならな
い。したがって、サーバは、操作開始（２）メッセージ
を認識したのに応答して待ち行列満杯（２）状況を返
す。

8.次に、サーバは操作開始（３）メッセージを認識し、
待ち行列満杯（３）メッセージを返す。

9.次に、要求元は操作開始（１）、（２）及び（３）に
対する待ち行列満杯状況及び待ち行列空間使用可能メッ
セージを認識し、どのメッセージを送り直さなければな
らないか、及びそれを送る順序を決定した後、待ち行列
再開メッセージを送る。

10.11.12.要求元プロセッサは操作開始メッセージを正
しい順序で送りなおす。

作業がサーバにより完了されると、作業が完了したこと
を示す操作終了メッセージが要求元バス装置に送られ
る。

データの流れ 第１図の好ましい実施例では、バス装置50及び52のバス
・ハードウェア90及び92は、直接メモリ・アクセス（DM
A）機能を有するものとして示されている。この機能
は、今日、大部分のバス装置に存在する標準的なハード
ウェア機能である。マスタDMA機能を有するバス装置
は、スレーブDMA機能を有するバス装置内のプロセッサ
に割り込むことなく、このスレーブDMAバス装置の主記
憶装置に直接アクセスすることができる。その動作は本
発明の完全な理解にとって必要ではないので、詳しく説
明しない。

バス装置50はスレーブDMAハードウェア90を有する。好
ましい実施例では、バス装置50はホスト・プロセッサで
ある。スレーブDMAハードウェア90は、ホスト・プロセ
ッサ56に割り込むことなく、他のバス装置にその主記憶
装置58をアクセスさせることができる。したがって、ホ
スト・プロセッサ56が主記憶装置58にアクセスするため
の線60は、バス管理機構86にも接続され、また、スレー
ブDMAハードウェア90が主記憶装置58に直接アクセスで
きるようにスレーブDMAハードウェア90にも接続されて
いる。このため、マスタDMAハードウェア92を有するバ
ス装置52等の別のバス装置が、ホスト・プロセッサ56に
割り込むことなく、バス装置50の主記憶装置58にアクセ
スすることができる。スレーブDMA機能のみを備えたバ
ス装置は他のバス装置の主記憶装置に直接アクセスする
ことができず、一方、マスタDMA機能のみを備えたバス
装置は、他のバス装置にその主記憶装置の直接アクセス
を試みさせることができない。

バス装置52内のプロセスがバス装置50内のプロセスに作
業要求を送る場合、実際のデータ転送はこれらのプロセ
スにとってトランスペアレントな形で行なわれねばなら
ない。IPCF72及び74は、これらのプロセスが作業を処理
するめに使用する動詞インターフェースである。サーバ
・プロセスは、要求元によって識別されたデータに自分
のペースでアクセスする。この場合のサーバ・バス装置
はスレーブDMA機能しかもたないので、IPCF及びプロセ
スに対してトランスペアレントな形でデータを得るため
の手段が設けられる。

各バス装置が完全なDMA機能を有することが保証された
通常の流れでは、バス管理機構88は、プロセスが作業要
求を送ろうとしていることを示す情報をIPCF74からのIP
CF動詞から受け取る。バス管理機構88は次に、操作開始
メッセージを送って、行なうべき作業があることをバス
管理機構86に通知する。操作開始メッセージのフォーマ
ットを第13図に示す。このメッセージは、サーバ・バス
装置50内のバス管理機構86が、可能ならば制御情報及び
データ・アドレスを指定する要求／応答制御ブロック
（RRCB）をバス装置52の主記憶装置68からバス装置50の
主記憶装置58に移すのに十分な情報を有する。RRCBを第
14図及び第15図にさらに詳細に示す。バス管理機構86は
次に、ホスト・プロセッサ56内の意図されたプロセスに
対し、このプロセスによって待ち行列に入れられる未処
理の作業要求があることをIPCF72を介して通知すること
ができる。プロセスは次にその要求を実行するが、それ
にはバス装置間でのデータ移動が必要となる。バス装置
間のデータ転送を制御するために、このとき主記憶装置
58にあるRRCBのコピーがバス管理機構86で使用される。
操作終了（第16図参照）メッセージがバス管理機構88に
送られることにより、要求された動作が完了したことが
知らされ、バス管理機構88はIPCF74を介して要求元プロ
セスに通知する。

上記流れの問題点は、第１図のように実施された場合、
バス・ハードウェア90が主記憶装置68を直接アクセスで
きないことである。たとえバス・ハードウェア90がマス
タDMA機能を有しているとしても、スレーブDMA機能も持
たねばならない。この問題点は、記憶リスト制御ブロッ
ク及び幾つかの新しいバス・メッセージを使って、ホス
ト・バス装置50の主記憶装置58内のバッファの管理権を
バス装置52のバス管理機構88に与えることによって解決
される。こうすると、通常の作業の流れに従って、要求
元のバス管理機構88が、その要求に関係するデータをサ
ーバの主記憶装置58内のバッファに転送し、次にサーバ
がデータをバッファからサーバ・プロセスの使用可能な
記憶域に転送することができる。したがって、データの
流れはIPCF72には正常に見える。RRCBは通常通り、サー
バがアクセスしなければならないデータがどこにあるか
を示すために使用される。要求元のバス管理機構88は、
データが主記憶装置58内のバッファにあるようにするだ
けである。次に、RRCB及びメッセージについてさらに詳
細に説明する。

RRCBを第14図及び第15図に示す。RRCBは、作業要求、及
びそれに関連するデータを識別するために使用される。
RRCBは制御ブロックであり、バス装置間のデータ移動を
制御するために、要求元バス装置内のバス管理機構及び
サーバ・バス装置内のバス管理機構によって使用され
る。RRCB内の情報は物理的DMAプロセスのために使用さ
れる。RRCBの内容は読取り専用であることが好ましい。
これらの内容は、サーバ・バス装置内のバス管理機構に
よって変更または修正されない。

RRCBは、要求元のバス管理機構によって指定される、最
大4088バイトまでの任意の長さでよい。要求元による固
定ブロック・バッファ管理を容易にするため、RRCBをセ
グメント化し、互いに連鎖することができる。固定ブロ
ックが、たとえば512バイトの長さであり、RRCBがそれ
より長い場合は、RRCBは、何らかのヘッダ情報を含む第
１のタイプのセグメントと、第15図に示す複数の第２の
タイプのセグメントに分割される。これらのセグメント
のいずれも固定ブロックよりも長くない。RRCBの第１の
タイプの最初のフィールドは、バイトで表わしたRRCB全
体の長さである。この長さはRRCBセグメントのすべての
長さの和である。RRCBタイプ・フィールドは、それが第
１のタイプのRRCBセグメントであることを指定する。サ
ーバ接続IDはこの要求に対する目標プロセスの識別を指
定する。要求優先順位フィールドは、サーバ・プロセス
の入力待ち行列に要求項目を挿入するときにサーバ・プ
ロセッサによって使用される優先順位を指定する。フラ
グ・フィールドは、サーバが確定応答を必要とするの
か、それとも例外応答のみを必要とするのかを規定す
る。要求元RIDフィールドは要求の識別を指定する。こ
れは要求元にのみ知られる。

拡張状況ポインタは、拡張状況（状況に対して許容され
る設計寸法を超える状況データ）を入れることができる
区域のアドレスを指定する。好ましくは、この区域は使
用可能でなければならず、使用前に要求元のバス管理機
構により０にセットされねばならない。アドレスは、要
求元によって管理されるRRCB記憶域と同じ記憶域に対す
るものである。

第１のタイプのセグメントの残りの部分は、第２のタイ
プのセグメントと同じである。それは、記述要素によっ
てデータ・フラグ・フィールドに記述されるデータのタ
イプを指定する複数の記述要素ワードから成る。データ
・フラグ・フィールド内の記述子のタイプは、要求、サ
ーバの記憶装置から要求元記憶装置へのデータ入力、要
求元記憶装置からサーバの記憶装置へのデータ出力、ま
たはさらにセグメントが必要とされるときの次のRRCBに
対するセグメント・リンク等の記述子のタイプを識別す
る。RRCBセグメント・リンク記述要素は、別のRRCBセグ
メントがある場合に、RRCBセグメントの終りに現われな
ければならない。データ・フラグ・フィールド内の記述
子フォーマット・フィールドは、データ・ワードで開始
し、最大44バイトにわたって続く即値データが左寄せさ
れることを指定するために使用される。要求記述子また
はデータ出力記述子は、例えば、データをどこに、また
はどこからDMA転送するかを識別するためのバス装置番
号とデータ・アドレスを含む即値データまたは参照であ
る。バス装置番号は、参照記述子形式が指定されるとき
は常に現われなければならない。データ・フラグ・フィ
ールドは、次のフィールドのアドレスが参照するバス装
置を、バス装置番号によって識別する。

データ長フィールドは、次のアドレス・フィールドで指
定されるフィールドのデータの長さをバイトで指定す
る。それは、連続した実記憶域を指定する符号なしの整
数値である。データは８バイトの倍数になるまで０を埋
め込まれる。

データ・アドレス／データ・フィールドはアドレスまた
は即値データのいずれかとして使用される。このフィー
ルドは、RRCBのセグメントの前のワードのデータ・フラ
グ記述子フォーマットで即値データが指定される場合
は、即値データである。そうでに場合は、アドレスであ
る。このアドレスは、サーバの記憶装置、要求元の記憶
装置、または図示しない第３のバス装置の記憶装置のア
ドレスである。このアドレスは、他方のプロセッサの記
憶装置との間で、またはサーバ記憶装置中の要求元によ
って制御されるバッファ中でDMA動作を行なうために、
サーバ・バス管理機構によって使用される。

バッファ管理メッセージ バッファ管理権は２つのバス管理機構の間でやり取りさ
れる。一方のバス装置は、他方のバス装置が使用し管理
する遠隔記憶域をその主記憶装置内に提供する。この実
施例では、バス装置52は、ホスト・プロセッサ56に緊密
に結合された主記憶装置58内のバッファの管理権を有す
る。バス装置52のプロセッサ66は、その必要を満たす目
的のために主記憶装置58内の遠隔記憶域を使用すること
ができる。遠隔記憶域は、プロセッサ66からはそれ自体
の記憶装置の論理的拡張部分に見える。

バス装置52は、バス管理機構88から送られる記憶域要求
バス装置メッセージにより遠隔記憶域に対する要求を行
なう。記憶域要求メッセージのフォーマットを第17図に
示す。通常のシステムの立上げの直後に、ホストの遠隔
記憶域を得るためにバス装置がこのメッセージを使用す
る。

記憶域要求バス装置メッセージはまた、遠隔プロセッサ
が使用可能なバッファを他に持たないときにも送られ
る。要求されたバッファの長さはバッファ長フィールド
で指定できる。ローカル・プロセッサは、要求されたバ
ッファ・サイズを提供できないことがあるが、それより
大きなサイズのバッファが設けられている場合には要求
を満たす。それよりも小さいサイズのバッファは設けら
れない。いくつかの予約フィールドが示され、０として
指定されている。メッセージID（06）フィールドは、メ
ッセージを記憶要求バス装置メッセージとして識別す
る。記憶域サイズ・フィールドは、バイトで表わした要
求された記憶域の長さである。好ましい実施例では、単
一メッセージで要求できる最大の記憶域は65535バイト
である。バッファ長フィールドは、要求されるバッファ
の最小の長さを指定する。したがって、要求された全記
憶域サイズが満足されれないことがあるとはいえ、１つ
のバッファさえ設けられれば、それは少なくともバッフ
ァ長フィールドの値と同じ長さになる。

記憶域リスト使用可能バス装置メッセージ及び記憶域リ
スト制御ブロック（SLCB）は、記憶域要求バス装置メッ
セージに応答して、ローカル・バス装置内のバス管理機
構によって送られる。SLCBは、遠隔バス装置が使用でき
るバッファのリストをローカル・バス装置の記憶装置内
に提供する。記憶域要求に応答してのみ、１つの記憶域
リスト使用可能メッセージ/SLCBだけが送られる。

記憶域リスト使用可能バス装置メッセージのフォーマッ
トを第18図に示す。フラグ・フィールドは、記憶域が使
用可能である、資源が使用可能でなく記憶域が提供され
ない、あるいは要求された大きさのバッファが使用可能
でなく要求に応じて提供されない、といったタイプの応
答を示す。メッセージID（07）フィールドは、これが記
憶域リスト使用可能バス装置メッセージであるこを識別
する。SLCBアドレス・フィールドは、遠隔記憶域を含む
バス装置記憶装置内のSLCBの実アドレスを指定する。こ
のフィールドは、記憶域が使用可能であることをフラグ
・フィールドが示す場合にのみ有効である。長さフィー
ルドはローカル・バス装置の記憶装置内のSLCBの長さを
示す。

SLCBのフォーマットを第19図に示す。バス番号フィール
ドは、このバス装置がローカル・バス装置内で現われる
バス番号を指定する。好ましい実施例では、最大８本の
異なるバスがある。バス装置フィールドは、このSLCBが
向けられる遠隔バス装置のバス装置番号を指定する。バ
ッファの数及びそれらの長さが次の２つのフィールドで
指定される。このフィールドが記憶域リスト使用可能メ
ッセージ中の長さフィールドと一致するようにするの
は、ローカル・バス装置内の送信機構の責任である。

遠隔記憶域を含むバス装置内のバス管理機構は同じバス
装置上の主記憶装置の一部を管理する。このバス管理機
構は主記憶装置内のバッファを監視し、主記憶装置を要
求する他のバス装置に制御権を与える。したがって、接
続及び他のバス装置はバス管理機構を介して主記憶装置
内のバッファを争奪する。

バッファ・アドレス・フィールドは、ローカル・バス装
置内でバッファの実記憶アドレスを指定するために使用
される。これは、「バッファ数」フィールドで指定され
たバッファの数を満たすために、必要な回数だけ反復さ
れる。

遠隔バス装置が、SLCBで指定された遠隔記憶域にもはや
アクセスする必要がないことを示す記憶域リスト完了バ
ス装置メッセージが、遠隔バス装置のバス管理機構から
送られる。遠隔記憶域の返却はまた、マスタDMAを備え
た別のバス装置に対して記憶域を使用可能にしたスレー
ブDMA機能に備えたバス装置によって開始されることが
あり、その場合、記憶域リスト返却バス装置メッセージ
が未使用のバッファを返すべきことを示す。記憶域リス
ト完了メッセージはまた、記憶域リスト返却メッセージ
で指定された要求を充たすことができないことを示すた
めに使用される。

記憶域リスト完了メッセージのフォーマットを第20図に
示す。フラグ・フィールドは記憶域リストの通常の返
却、または返却要求の拒絶を指定する。フラグ・フィー
ルドは、通常の返却がリスト全体について行なわれるこ
と、記憶域リスト返却メッセージに応答して返却がなさ
れること、記憶域リスト返却メッセージで示される特定
のサイズのバッファの返却が行なわれていること、ある
いは、要求された記憶域が見つかったが使用する必要が
あり返却できないことを示すことができる。

SLCBアドレス・フィールドは、ローカル・プロセッサ内
のSLCBの実アドレスである。記憶域リスト返却メッセー
ジがバッファの長さを含み、バッファが記憶域リスト完
了メッセージで返却されていないときは、バッファ長フ
ィールドは、記憶域リスト返却メッセージで指定される
バッファの長さを含む。

記憶域リスト返却メッセージのフォーマットを第21図に
示す。要求元は、要求されたバッファ・サイズを有する
任意の記憶域リストを返却すべきであると指定でき、あ
るいは返却される特定の記憶域リストを識別することが
できる。このバス装置メッセージのフラグ・フィールド
は、指定されたサイズのバッファを有する任意の記憶域
リストまたは特定の記憶域リストを返却するかどうかを
示す。記憶域リストの制御権が遠隔バス装置制御からロ
ーカル・バス装置制御に渡されることは、上述の記憶域
リスト完了バス装置メッセージによって示される。メッ
セージID（09）フィールドはこのメッセージを記憶域リ
スト返却メッセージとして識別する。アドレス・フィー
ルドは、特定のリストが要求されていることをフラグ・
フィールドが示す場合に返却される、記憶域リストのア
ドレスを指定する。バッファ長フィールドは、特定の記
憶域リストが要求されていない場合に、この要求で返却
されるバッファの長さを指定する。

第22図に、記憶域リストと関連する流れを簡略化して示
す。マスタDMAを備えた要求元バス装置を図の右側に示
し、その下にメッセージを列挙する。スレーブDMAを備
えたサーバ・バス装置は図の左側に示す。各操作を、以
下のようにステップ１ないしステップ６と名付け、説明
する。

1.マスタDMA機能を備えた要求元プロセッサ内のバス管
理機構は、記憶域リスト要求メッセージを送ることによ
り、バッファを必要とすることをサーバ・プロセッサに
知らせる。

2.サーバ・プロセッサ内のバス管理機構は、記憶域リス
ト制御ブロックSLCBが要求元プロセッサにとって使用可
能であることを示すメッセージを送る。

3.遠隔バス管理機構はSLCBの全部または一部をその記憶
装置にDMA転送する。

4.要求元プロセッサ内のバス管理機構は所望のバッファ
を使用する。

5.サーバ・プロセッサ内のバス管理機構が１日の終り等
のある種の遮断を行なおうとし、あるいは、バス装置が
ピーク負荷を過ぎているのに、記憶域を返していない場
合、記憶域リスト返却メッセージを要求元プロセッサに
返す。

6.要求元プロセッサ内のバス管理機構は、もはや必要で
ないSLCBを示す記憶域リスト完了メッセージを送る。

第23図で、スレーブDMA機能のみを有するバス装置のバ
ス管理機構がバスを介して通信を受け取ったとき、300
で、その通信が記憶域要求であるかどうか判定するため
に検査を行なう。そうである場合は、ブロック302、304
及び306に示すように、バス管理機構は、周知の記憶管
理技術を使って、要求を満たすためにシステム記憶管理
機構に主記憶装置を要求する。バス管理機構は、その記
憶域に対して管理責任を負うことを識別するため、許可
された記憶域を拘束する。管理責任には、別のバス装置
がその記憶域を独立に使用しないというある水準の保証
のもとで記憶域の読取り及び書込みを行なう能力が含ま
れる。次いでバス管理機構は記憶域を、要求された数の
ブロックにブロック化し、記憶域リスト制御ブロックSL
CBを組み立て、記憶域を要求するバス装置を許可された
ブロックの記憶アドレスに接続するポインタを保持す
る。バス管理機構は次に要求元バス装置に記憶域リスト
使用可能メッセージを送り、308で処理を継続する。

ブロック300に戻り、バスの通信が記憶域要求でない場
合は、310で、記憶域リスト完了メッセージであるかど
うか判定するため、通信が検査される。そうである場合
は、312で識別された記憶域がシステム記憶管理機構に
返され、記憶域管理権を返却したバス装置を指すポイン
タが削除される。314で処理が継続する。ブロック310で
記憶域リスト完了メッセージが検出されない場合は、31
6で処理が継続する。

ホスト自体が記憶域が返されることを望んでいることを
示す要求を、スレーブDMAのみを備えたバス装置のバス
管理機構が受け取った場合は、ブロック330で、第24図
に示す流れに入る。そのような要求は、オペレータによ
る遮断コマンドの結果として、または、ある種の時刻割
込みによって発生することがある。いずれにしても、記
憶域返却要求を受け取ると、バス管理機構は、別のバス
管理機構によって管理されているために拘束されている
記憶域を調べ、返却すべき記憶域を選択する。バス管理
機構が使用量に関するある種の統計を保持することもで
き、あるいは要求で、遮断すべき装置の種類を指定する
こともできる。このようにして、バス装置は、返却を要
求する記憶域に関して選択的である。332で、記憶域を
返却するためのバス・メッセージが所望のバス装置に送
られる。バス装置は、第23図の流れに示すように、記憶
域リスト完了メッセージを返す。次に、334で処理が継
続する。

遠隔記憶管理機構はまた、システムの処理能力を均衡さ
せるために使用することもできる。バス装置が十分な主
記憶装置を持たない場合は、ホストの主記憶装置内のバ
ッファの使用を要求することができる。十分なバス処理
能力がある場合、バス装置の処理能力を高めることがで
きる。システムは他のバス装置の処理能力を容易に追跡
して、作業要求に対する応答が遅いバス装置により多く
の遠隔記憶域を割り振ることができる。ホストの主記憶
装置が余りにも多く遠隔的に管理されている場合は、割
り振られた量がホストの処理能力の潜在的な低下によっ
て相殺されるはずである。

逆の流れ 上述のように、作業要求の通常の流れは、ホスト・プロ
セッサ56から入出力プロセッサ66に向かう。それには、
入出力プロセッサ66に結合された補助記憶装置に対する
データの読取り及び書込み、あるいは入出力プロセッサ
66を介する通信の開始等の作業が含まれる。マスタDMA
機能を備えた入出力プロセッサ66及びスレーブDMA機能
を備えたホスト・プロセッサ56があると、この関係に理
想的に適合する。入出力プロセッサであるサーバは、ホ
ストに割り込むことなくデータの転送を駆動する。

作業要求をホストに送るプロセスを入出力プロセッサ16
が有することが一般的になってきた。そうすると、作業
に関連するデータの逆の流れが生じる。ホストは入出力
プロセッサからデータをDMA転送できないので、入出力
プロセッサは、前述のメッセージを用いて得た、ホスト
の主記憶装置内の遠隔バッファを使用する。

次に、逆の流れの一例について第25図を参照しながら説
明する。マスタDMA機能を備えた要求元バス装置、すな
わち、入出力プロセッサ66は、図の右側に示すステップ
を実行し、スレーブDMA機能を備えたサーバ・バス装
置、すなわち、ホスト・プロセッサ56は、図の左側に示
すステップを実行する。１ないし10の番号を付したステ
ップについて説明する。

1.要求元プロセスはプロセス間動詞インターフェースに
おける要求をプロセス間機構、すなわち、第２図のIPCF
74に出す。

2.バス管理機構88はホスト・プロセッサの主記憶装置58
内で十分な大きさのバッファを得（まだ持っていない場
合）、バス・ハードウェア92を介してマスタDMA動作を
開始して要求をサーバ・バス装置50内の遠隔記憶域に移
す。

3.要求元のバス管理機構88はバッファ内へデータをDMA
転送する。

4.バス管理機構88は次にサーバ記憶装置のバッファ内へ
RRCBをDMA転送する。RRCBはこのとき、ステップ２及び
３でサーバ・バス装置内の遠隔記憶域内へDMA転送され
た要求及びデータのサーバ記憶装置内でのアドレスを使
用する。

5.要求元プロセッサ66内のバス管理機構88は、RRCB及び
データがサーバ記憶装置内にあることを示す操作開始バ
ス装置メッセージをサーバ・プロセッサに送る。操作開
始メッセージが送られた時点で、プロセス間機構を使用
するプロセスに関連するすべてのデータは、サーバの記
憶装置内へDMA転送されている。

6.要求はプロセス間機構72によってサーバ・プロセスに
渡される。

7.サーバ・プロセスは、サーバのローカル記憶装置にあ
る必要なデータを要求する。バス管理機構88は依然とし
てバッファの制御権をもつが、バス管理機構88は、操作
開始メッセージを処理しながら、これらのバッファにア
クセスすることができる。サーバ・プロセスのバス管理
機構86は、サーバ・プロセスがアクセスできる主記憶装
置58の区域にそのデータを転送する。

8.サーバ・プロセスが要求された操作を完了すると、IP
CF動詞を使ってプロセス間機構72にそのことが知らされ
る。

9.サーバ・プロセッサ56内のバス管理機構86は、状況情
報を含む操作終了メッセージを出す。このメッセージ
は、バス管理機構86によってバッファに入れられた応答
を要求元プロセッサ66内のバス管理機構88に知らせる。
そのような応答を検索した後、バス管理機構88は、次の
ものが使用できるようにバッファを解放し、要求された
操作が完了したことを要求元プロセスに示す。

10.プロセス間機構74は次に、操作が完了したことを要
求元プロセスに知らせる。

信号メッセージによる逆の流れ 信号バス装置メッセージのフォーマットを第26図に示
す。信号バス装置メッセージはバス管理機構が出し、短
いメッセージを別のプロセッサ内のプロセスに転送する
ために使用される。１回の使用で一度に４文字までのデ
ータ転送が含まれる。信号メッセージを送るバス管理機
構は、信号メッセージの受信側が応答を送ることを要求
しない。要求元とサーバ・プロセスの間で上位レベルの
プロトコルによる応答があり得るが、好ましい実施例で
はバス管理機構は何も要求しない。信号メッセージの送
信側は、信号メッセージをサーバ・バス装置が受け取る
ことを保証できない。信号メッセージのための流れ制御
機構は存在しない。たとえば、受信側プロセスが記憶域
を得ることができなかったので、信号を実行できないと
送信側に知らせるための機構はない。このため、応答が
必要でない場合に融通性が得られる。作業要求ではなく
信号メッセージを使用するとオーバーヘッドが少なくな
る。RRCBは必要でない。

信号メッセージは２つの予約フィールドを含み、これら
の予約フィールドは好ましい実施例ではＯである。2Xフ
ィールドはバス装置メッセージのタイプを定義するため
に使用される。このフィールドの２は、これを信号バス
装置メッセージとして定義する。Ｘはユーザ・データ・
フィールドの内容を指定する。信号メッセージのタイプ
は次の通りである。

20−アテンション（受信側への警告用） 21−即値データ−１バイト 22−即値データ−２バイト 23−即値データ−３バイト 24−即値データ−４バイト 25−即値エラー・データ 26−即値ユーザ・タイプ１データ 27−即値ユーザ・タイプ２データ 28−即値ユーザ・タイプ３データ 29−即値ユーザ・タイプ４データ 2A−2F−従来の使用のため予約されている。

メッセージのユーザ・データ・フィールドは、ユーザ定
義データ、すなわち、即値データを含む。このフィール
ドの即値データは左寄せすることが好ましい。目標CID
フィールドはこのバス装置メッセージの目標プロセスを
識別する。

マスタDMAを備えたバス装置からの作業要求及び関連デ
ータを転送する責任を逆にして、マスタDMAを備えたバ
ス装置によって転送されるようにするための機構をもた
らすために、信号メッセージの変形を使用する。第27図
に示すように、遠隔記憶域バージョンの代わりとして異
なる形式の信号メッセージを使用する。逆の流れのバー
ジョンを実施することはたやすいが、逆の流れの遠隔記
憶域バージョンがもたらすのと同じ保証を与えない。

入出力バス装置がホスト・バス装置で信頼性／可用性／
保守容易性（RAS）タイプのプロセスに対する要求を開
始する必要があるときは、第27図に示すフォーマットの
信号メッセージを送る。ユーザ・データは、検索される
レコードの長さを示す２バイトの長さフィールド、及び
２バイトのオフセットとして定義される。オフセット・
フィールドは、入出力バス装置によって割り当てられ
る、符号化された値であり、信号メッセージを３つのタ
イプの信号メッセージの１つに応答して発生される作業
要求に関連づけるための追跡機構として使用される。入
出力バス装置の作業要求に対応するタイプは以下のよう
に定義される。

26−タイプ１の要求−エラー・データ 27−タイプ２の要求−資源データ 28−タイプ３の要求−テスト・データ 他のタイプは容易に識別することができる。

RASタイプのプロセスは入出力バス装置からのタイプ要
求を検索し、要求中の信号メッセージのタイプ・フィー
ルド、オフセット・フィールド及び長さフィールドの値
を返す。入出力バス装置は要求に応答して、識別された
タイプ要求コマンド及び関連データを返す。これらのタ
イプ要求それぞれのフォーマットは、以前の逆の流れ方
式を使って、または通常の流れによって送られた場合と
同じになる。

この逆の流れ方式の１つの使用例は、エラー・データを
検索する際に見られる。信号メッセージを受け取ったホ
ストは、コマンド・バイト及び関連データを検索するた
めの作業要求を送る責任がある。以下の作業要求フィー
ルドは、所与の信号メッセージ・フィールドを含む。

目標−タイプ アドレス−オフセット GETMAX−長さ 入出力バス装置は次に、タイプ１、２または３の要求に
対応するプロセスの要求された待ち行列の１つから、次
の使用可能な項目をFIFO順に返す。

長さフィールドは、入出力バス装置が返すデータの長さ
を指定する。たとえば、返すことができる最大長は、好
ましい実施例においては、送られる信号メッセージのタ
イプが与えられていれば、タイプ１、２及び３に対して
それぞれ268、272、または48である。ただし、バイトで
表わした入出力装置内の作業要求の実際の長さと、関連
データの和がそれよりも小さくなることもあり得る。入
出力バス装置の作業要求は、関連データの実際の長さを
指定する。

システムの待合せ限度またはエラー状態により信号メッ
セージが失われる可能性があるので、メッセージを処理
するためのシステム待ち行列のサイズは最小にすること
が好ましい。少なくとも、EN要求に対して17個の信号、
タイプ２の要求に対して24個の信号、及びタイプ３の要
求に対して16個の信号があれば、信号メッセージを失う
ことなく、大部分の状況に対処することができる。これ
らの数はバス装置資源サポートがどんなタイプであるか
に大きく依存しており、ここではバス装置が直接アクセ
ス記憶制御装置である好ましい実施例として上記の数字
を提示した。

上記の数は、入出力バス装置の作業要求を含む入出力内
部バッファ内の項目数である。項目がホストの作業要求
でそれらのバッファからクリアされず、しかもバッファ
が満杯の場合は、エラー・データ・タイプが送られる。
信号メッセージのオフセット値は、信号メッセージが失
われたかどうか判定するための追跡手段として使用され
る。予想されないオフセット値を含むホスト作業要求
は、信号メッセージの消失を示す。次に信号メッセージ
が入出力バス装置によって送り直される。ホストの要求
に対する応答は、ホスト・バス装置がその要求を廃棄す
べきことを示すエラー・コードを含む。この追跡方式は
また、要求されたレコードが既に送られているというタ
イミング状態を扱うための相関をも行なう。

ホスト作業要求は以下の情報を含む。

ホストの要求に対する応答が入出力バス装置から返され
る時、その要求に関連するデータを記述する以下の情報
を含む。

DMA要求による逆の流れ データの流れの制御を逆転するためのさらに別の方法
は、第28図及び第29図に示す１対のバス装置メッセージ
を使用することである。DMA要求バス装置メッセージ
（第28図）は、記憶装置へのDMA転送を要求するため、
サーバ・バス装置から要求元に送られる。要求元バス装
置からのDMA完了バス装置メッセージ（第29図）は、DMA
動作が完了したことを示す。要求元のバス装置、すなわ
ちマスタDMAを備えたバス装置が、サーバ・バス装置に
対するサービスを実行する。要求元バス装置内のバス管
理機構は、どのCIDがこのサービス要求を引き起こした
かを知らない。

サーバ・バス装置内のバス管理機構が操作開始バス装置
メッセージを受け取った場合がその一例である。バス管
理機構は次に、要求元の記憶装置内のRRCBのアドレス
と、それを入れるべきサーバの記憶装置内の場所とを指
定するDMA要求バス装置メッセージを送る。要求元バス
装置はサービスを実行し、動作が完了したことをDMA完
了バス装置メッセージで他方のバス装置に知らせる。DM
A要求メッセージを受け取ったバス管理機構は、サービ
スの本当の要求者を知ることなく、要求されたサービス
を実行する。バス管理機構は他方のバス転送機構のため
のサービスを行なう。

DMA要求バス装置メッセージのフィールドは以下の通り
である。

予約フィールドは、０でなければならない。

長さフィールドは、このDMA要求動作で転送されるデー
タの長さを示す。

DMA IDは、このDMA要求に使用されるIDであり、このDMA
要求メッセージを識別するためにDMA完了バス装置メッ
セージでこのIDを返さなければならない。この識別は当
該DMA要求及びDMA完了バス装置メッセージ以外では意味
を持たない。

タイプID（OX）は、バス装置メッセージのタイプ及びDM
Aの方向を定義するために使用される。DMA要求は２つの
可能な16進値を有する。

“03"−−要求元プロセッサからサーバ・プロセッサへ “04"−−サーバ・プロセッサから要求元プロセッサへ 要求元プロセッサ・データ・アドレス・フィールドは要
求元記憶装置でのデータ転送の開始アドレスである。デ
ータ転送の方向はタイプ・フィールドによって指定され
る。これは、操作開始バス装置メッセージから得られた
RRCBのアドレス、またはRRCBの内容から得られたデータ
・フィールド・アドレスでもよい。サーバ・プロセッサ
・データ・アドレス・フィールドは、サーバの記憶装置
内でのデータ転送の開始アドレスである。データ転送の
方向はタイプ・フィールドによって指定される。

要求元が要求されたDMA動作を完了すると、動作が完了
したことをサーバに知らせる。これは、第29図のDMA完
了バス装置メッセージを送ることによって行なわれる。
サーバ・プロセッサが要求されたDMA動作を実行中にバ
ス・エラーが発生した場合は、DMA完了バス装置メッセ
ージではなくバス・エラー状態バス装置メッセージが返
される。

DMA完了バス装置メッセージのフィールドは以下の通り
である。

予約フィールドは０でなければならない。

DMA IDは、DMA要求でもたらされたIDであり、このDMA要
求の要求元を識別するために使用される。

タイプ・フィールド（05）はバス装置メッセージのタイ
プを定義するために使用される。

他の２つの予約フィールドはすべて０でなければならな
い。

操作開始バス装置メッセージで開始されたシーケンスは
操作終了バス装置メッセージで完了する。

第30図は、スレーブDMA機能を持たないバス装置で開始
された要求送信動作の簡略化したメッセージの流れの一
例である。

1.サーバ・プロセス、この場合にはホスト・バス装置内
の処理が、その処理中の待機したい地点に到達する。IP
CF待ち行列受信動詞（前出の米国特許第4649473号参
照）を出す。（この例では、サーバが待ち行列受信によ
り作業要求を要求したと仮定する。）その入力待ち行列
には要求ノートはないので、目標プロセスは待機状態に
入る。前記米国特許に記載されているように、待ち行列
受信動詞は入力待ち行列から要求ノートを受け取るため
のものであり、要求ノートは要求の長さ及び識別子（RI
D）要求元等の情報を含んでいる。

2.要求元、この例では入出力プロセッサIOP内のプロセ
スは、データをホスト・プロセッサ内のサーバ・プロセ
スに送ろうとする。要求元プロセスはIPCF要求送信動詞
を出す。プロセスからのIPCFバス管理機構マップ情報を
RRCBにマップする。

3.IOP内をバス転送機構は、要求元が出した要求送信の
結果として、バス上での動作を開始する。IOPのバス管
理機構は操作開始バス装置メッセージをホストに送る。

4.ホスト内のバス管理機構は、バス装置メッセージによ
って指定された場所に、IOP内のバス管理機構がDMA転送
を行なうことを要求するDMA要求バス装置メッセージを
送る。

5.IOPバス管理機構は要求されたDMA動作を実行して、RR
CBをIOPの記憶装置からホストの記憶装置に移す。

6.IOP内のバス管理機構は、要求されたDMA動作が完了し
たことを示すDMA完了バス装置メッセージをホストに送
る。

7.ホスト内のバス管理機構は、バス装置メッセージによ
って指定されが場所から、DMA動作を実行するようIOP内
のバス管理機構に要求するDMA要求バス装置メッセージ
を送る。これはホストのバス管理機構によって所有され
る記憶域から行なわれる。

8.IOPのバス管理機構は要求されたDMA動作を実行して、
その要求をIOPの記憶装置からホストの記憶装置に移
す。

9.IOP内のバス管理機構は、要求されたDMA動作が完了し
たことを示すDMA完了バス装置メッセージを送る。上記
３つのステップは、要求が４バイトよりも小さい（たと
えばRRCB内の即値データ）場合は必要でない。

10.ノートがIPCFを介して該当のサーバ・プロセスに送
られる。これで、未処理の待ち行列受信が満たされる。

11.サーバ・プロセスは次に、ホストの記憶装置のどこ
にデータを入れるかを指定するIPCFデータ受信動詞を出
さねばならない。

12.ホスト内のバス管理機構は、バス装置メッセージに
よって指定された場所へのDMA転送を実行するようIOP内
のバス管理機構に要求するDMA要求バス装置メッセージ
を送る。このアドレスは、IPCFデータ受信動詞によって
指定される。

13.IOP内のバス管理機構は要求されたDMA動作を実行し
て、ユーザ・データをIOPの記憶装置からホストの記憶
装置に移す。

14.IOP内のバス管理機構は、要求されたDMA動作が完了
したことを示すDMA完了バス装置メッセージを送る。

15.サーバのデータ受信は、上記の動作によって満たさ
れる。

ステップ12ないし15は、要求されたすべてのデータを転
送するのに必要な回数だけ反復する。

16.要求元プロセス、この場合はIOP内のプロセスは、そ
の処理中の待機したい地点に到達する。要求元プロセス
は待ち行列受信動詞を出す。その入力待ち行列には要求
はないので、要求元プロセスは待機状態に入る。

17.サーバ・プロセスは次に、状況情報を含む応答送信
動詞を出す。

18.ホスト内のバス管理機構は、要求された動作が完了
したことを示す操作終了バス装置メッセージを送る。

19.ノートが要求元の待ち行列に送られる。これで要求
元の待ち行列受信が満たされる。

逆の流れ方式を使用することにより、プロセス間の通信
をプロセスから独立にし、かつプロセスに対してトラン
スペアレントにしようとするという目標が維持された。
実際には、バス管理機構は、IPCF層を通信の細部から隔
離するためにも使用される。接続グループを使用したた
め、流れ制御の水準を高めて、保証された最低水準のサ
ービスが得られるように資源がプロセスに割り当てられ
るようにすることが可能になった。様々な好ましい実施
例について説明したが、特許請求の範囲内で多くの変形
が可能であることは当業者にとって明らかである。

【図面の簡単な説明】

第１図は、プロセス間の論理的接続を有する論理的接続
グループを示す多重処理システムの概略ブロック図であ
る。 第２図は、米国特許第4649473号に記載のプロセス間通
信機構を有する多重処理システムの概略ブロック図であ
る。 第３図は、第１図の論理的接続グループの管理に使用さ
れるテーブル及び制御ブロックを示す図である。 第４図及び第５図は、もっと多くの要求を受け入れるの
に十分な資源を持たない接続グループに向けられた作業
要求のための待ち行列満杯状況に応答する要求元バス装
置の動作を示す流れ図である。 第６図は、待ち行列間の関係を示すブロック図である。 第７図は、十分な資源が接続グループ中で使用可能であ
るかどうか判定し、使用可能でない場合には待ち行列満
杯メッセージを送るサーバ・バス装置の流れ図である。 第８図は、接続グループに対して資源がいつ使用可能に
なったかを判定し、待ち行列空間使用可能メッセージを
送るサーバ・バス装置のもう１つの流れ図である。 第９図は、バス・エラー状態メッセージのフォーマット
を示すブロック図である。 第10図は、資源が接続グループにとって解放されている
ことを示す待ち行列使用可能メッセージのフォーマット
を示すブロック図である。 第11図は、接続グループに作業要求の受入れを開始する
よう知らせる待ち行列再開メッセージのフォーマットを
示すブロック図である。 第12図は、接続グループに対する待ち行列満杯状態に関
係するメッセージの流れの図である。 第13図は、識別されたプロセスに対する作業要求がある
ことを示す操作開始メッセージのフォーマットを示すブ
ロック図である。 第14図は、要求及びデータの場所を識別するために使用
される要求／応答制御ブロックRRCBのフォーマットを示
すブロック図である。 第15図は、要求／応答制御ブロックに対する追加のフォ
ーマットを示すブロック図である。 第16図は、作業要求に対する応答があることを示す操作
終了メッセージのフォーマットを示すブロック図であ
る。 第17図は、管理すべき遠隔記憶域を要求する記憶域要求
メッセージのフォーマットを示すブロック図である。 第18図は、遠隔的に管理される記憶域リストの場所を示
す記憶域リスト使用可能メッセージのフォーマットを示
すブロック図である。 第19図は、管理される遠隔記憶域を識別するために使用
される記憶域リスト制御ブロックSLCBのフォーマットを
示すブロック図である。 第20図は、遠隔記憶域の管理権を返すために使用される
記憶域リスト完了メッセージのフォーマットを示すブロ
ック図である。 第21図は、遠隔記憶域の管理権の返却を要求するために
使用される記憶域リスト返却メッセージのフォーマット
を示すブロック図である。 第22図は、遠隔記憶域の管理の制御権の転送に関係する
メッセージの流れの図である。 第23図は、遠隔記憶域の管理権の授与を示す流れ図であ
る。 第24図は、遠隔記憶域の管理権の返却を示す流れ図であ
る。 第25図は、作業要求の流れの逆転に関係するメッセージ
の流れの図である。 第26図は、少量のデータを非公式に転送するために使用
される信号メッセージのフォーマットを示すブロック図
である。 第27図は、作業要求の流れを逆転するための信号メッセ
ージの代替バージョンを示すブロック図である。 第28図は、DMA転送を要求するために使用されるDMA要求
メッセージのフォーマットを示すブロック図である。 第29図は、DMA転送が完了したことを示すために使用さ
れるDMA完了メッセージのフォーマットを示すブロック
図である。 第30図は、データを転送するために第28図及び第29図の
DMAメッセージを使用することに関連するメッセージの
流れの図である。 50、52……バス装置、56……ホスト・プロセッサ、58、
68……主記憶装置、66……入出力プロセッサ、70、72…
…IPCF、86、88……バス管理機構、90……スレーブ部DM
A機能、92……マスタDMA機能。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 フレデリック・ジヨセフ・ジイーシイナ アメリカ合衆国ミネソタ州ロチエスター、 サウス・ウエスト・トウエンテイース・ア ヴエニユー703番地 (56)参考文献 特開 昭62−92061（ＪＰ，Ａ) 特開 昭62−189550（ＪＰ，Ａ)

Claims (14)

【特許請求の範囲】
1. 【請求項１】プロセスのグループ間のメッセージに関連
   する、作業のフローを制御する方法であって、 各前記グループは緩やかに結合した分散処理ネットワー
   ク内のプロセッサ上にあり、 各前記グループ内の前記プロセスはプロセッサ資源を共
   有しており、 作業要求メッセージを、１のグループ内の要求プロセス
   を含む要求プロセッサから、他のグループ内のサーバ・
   プロセスを含むサーバ・プロセッサに送るステップと、 前記作業要求メッセージを受信し、前記サーバ・プロセ
   スを含む前記サーバ・プロセッサにおいて作業を開始す
   るステップと、 前記要求プロセスからの作業要求を前記サーバ・プロセ
   ッサに開始させるために、前記サーバ・プロセッサ内で
   使用可能となっている資源が不十分であるか否か含む、
   前記サーバ・プロセッサ内の状態を認識するステップ
   と、 前記サーバ・プロセッサから前記要求プロセッサに、前
   記サーバ・プロセッサ内の資源が不十分であったという
   状態を示す不十分資源メッセージを、前記作業要求メッ
   セージを受け取るごとに送るステップと、 前記サーバ・プロセッサが不十分資源メッセージを送っ
   た後に、前記サーバ・プロセッサに送った作業要求メッ
   セージを、前記要求プロセッサ内の待ち行列に入れるス
   テップと、 資源が前記サーバ・プロセッサ内で使用可能になった
   時、前記サーバ・プロセッサから前記要求プロセッサ
   に、資源使用可能メッセージを送るステップと、 前記資源使用可能メッセージに応答して、前記要求プロ
   セッサから前記サーバ・プロセッサに再開メッセージを
   送るステップと、 前記サーバ・プロセッサが前記要求プロセッサからの再
   開メッセージを受信するのに応答して、前記サーバ・プ
   ロセッサに、前記待ち行列内の前記作業要求メッセージ
   を送るステップと を含む作業フロー制御方法。
2. 【請求項２】バスにより結合された複数のバス装置を有
   するマルチ・プロセッサ・サーバ駆動作業処理システム
   において、作業要求のフローを制御する方法であって、 各バス装置の所定量の資源を、各バス装置内の、プロセ
   ス間論理接続の集合である複数の接続グループ各々に割
   り当てるステップと、 バス・マネージャにより、発信元バス装置から宛先バス
   装置の特定の接続グループに、作業要求を送るステップ
   と、 前記接続グループに送られた前記作業要求の完了に必要
   な資源が該接続グループに割り当てられた資源の量を超
   える時、前記宛先バス装置内の接続グループから作業要
   求を返信するステップと、 前記宛先バス装置から前記発信元バス装置に、先に前記
   発信元バス装置に作業要求を返信した接続グループが該
   作業要求を完了するのに使用することができる資源を有
   していることを示すメッセージを送るステップと、 先に返信された作業要求を、先に送った順番で前記発信
   元バス装置に送るステップと を含む作業要求フロー制御方法。
3. 【請求項３】複数のバス装置を有する、緩やかに結合し
   た分散処理ネットワーク内の、前記バス装置ごとに存在
   する通信管理装置であって、 前記バス装置はバスにより互いに結合しており、 前記通信管理装置は宛先及び発信元バス装置上に存在す
   るプロセス間の通信を処理するために動作し、 作業を開始させる、発信元バス装置からの作業開始メッ
   セージを受信する受信手段と、 前記受信手段に結合した資源管理手段であって、 前記バス装置上のプロセスの選択されたグループのため
   にバス装置資源を管理する管理手段と、 １の前記選択されたグループにおける作業開始メッセー
   ジに応答して、前記選択されたグループのため使用可能
   であって、前記作業を行うための十分な資源がないこと
   を示す満杯メッセージを前記発信元に返信する満杯伝達
   手段と、 資源が前記選択されたグループに対し使用可能となった
   時、前記発信元バス装置に資源使用可能メッセージを送
   信する資源使用可能伝達手段と を有する前記資源管理手段と を有し、前記発信元バス装置が再開メッセージを出力し
   且つ前記グループが十分な使用可能な資源を有している
   時に、前記発信元バス装置からの作業開始メッセージを
   再び受信する通信管理装置。
4. 【請求項４】前記資源管理手段が、 先に送られ且つ前記宛先バス装置により前記満杯メッセ
   ージの返された前記作業開始メッセージを格納する保持
   手段と、 前記作業開始メッセージに対し前記満杯メッセージを返
   してきたバス装置に、前記バス装置からの資源使用可能
   メッセージの受領に続いて再開メッセージを送る再開伝
   達手段と、 前記再開伝達手段と前記保持手段とに結合され、前記バ
   ス装置により送られた先の満杯メッセージを引き起こし
   た、前記バス装置内の作業を開始させるメッセージを再
   度送信する送信手段と を有する請求項３記載の通信管理装置。
5. 【請求項５】前記資源管理手段が、 前記宛先バス装置に送られた作業要求を保持する完了待
   ち待ち行列と、 前記宛先バス装置に送信されるべき作業要求を保持する
   送信待ち行列と、 前記保持手段に格納されている作業開始メッセージに応
   答した満杯メッセージを前記宛先バス装置が送信した後
   に、前記満杯メッセージを送信した、前記バス装置の前
   記選択されたグループへ送信すべき作業要求を保持する
   中間待ち行列と、 前記満杯メッセージが、特定の前記グループに向けられ
   た、前記保持手段内の各作業要求に対し受領されたなら
   ば、前記送信待ち行列から前記中間待ち行列に、前記特
   定のグループに向けられた作業開始メッセージを転送す
   る転送手段と、 前記満杯メッセージを前記特定のグループから受信した
   後に前記特定のグループに送られた全ての作業要求が前
   記保持手段にあるかどうかを判定するために、前記保持
   手段を検査する手段と をさらに有する請求項４記載の通信管理装置。
6. 【請求項６】前記再度送信する手段は、前記検査手段に
   応答して、前記保持手段にある前記特定のグループに向
   けられた全ての作業要求を、先に送った順番と同じ順番
   で送信し、その後に前記中間待ち行列ある作業要求を、
   前記中間待ち行列に送られた順番で送信する請求項５記
   載の通信管理装置。
7. 【請求項７】複数のプロセスがサーバ駆動環境において
   互いに通信するマルチ・プロセッサ・コンピュータ・シ
   ステムの作業要求フロー制御装置であって、 主記憶装置と、第１プロセスを実行する手段と、プロセ
   ス間論理接続の集合である複数の接続グループを有する
   第１バス装置と、 主記憶装置と、第２プロセスを実行する手段と、プロセ
   ス間論理接続の集合である複数の接続グループを有する
   第２バス装置と、 前記第１バス装置と前記第２バス装置に接続され、前記
   第１バス装置に関連する前記複数の接続グループの１つ
   及び前記第２バス装置に関連する前記複数の接続グルー
   プの１つを介して前記第１及び第２バス装置間の通信を
   行わせるI/Oバスと を有しており、 前記第１バス装置は、前記第１及び第２プロセス間の接
   続を確立し、有限量の第１バス装置資源が使用可能とな
   っている前記複数の接続グループの１つと、該接続を関
   連付けるバス・マネージャを有し、 前記第２バス装置は、前記第１及び第２プロセス間の接
   続を確立し、有限量の第１バス装置資源が使用可能とな
   っている前記複数の接続グループの１つと、該接続を関
   連付けるバス・マネージャを有し、 前記第２プロセスは、前記第１プロセスにより行われる
   作業の作業要求を発生し、 前記第２バス装置のバス・マネージャは、前記第２プロ
   セスにより発生された前記作業要求を前記第１バス装置
   に知らせるために、前記第１バス装置のバス・マネージ
   ャに操作開始メッセージを送信し、前記第１バス装置の
   バス・マネージャは前記操作開始メッセージを受信し、
   前記作業要求を行うのに使用すべき接続グループを決定
   し、 前記第１バス装置内の前記接続グループが前記作業要求
   を実行するのに使用可能な十分な資源を有しているかを
   判定する、前記第１バス装置のバス・マネージャ内の手
   段を有する作業要求フロー制御装置。
8. 【請求項８】前記第１バス装置のバス・マネージャは、 前記各接続グループに接続されたプロセスにより実行さ
   れる作業要求の数をカウントする、前記複数の接続グル
   ープの各々に対するカウンタと、 前記カウンタに結合され、作業開始メッセージが、前記
   複数の接続グループに割り当てられた前記有限量の第１
   バス装置の資源に依存する所定のカウント値を超えた値
   を有するカウンタがある接続グループの接続を有するプ
   ロセスにより受信された場合、前記第２バス装置に待ち
   行列満杯メッセージを送信する手段と をさらに有する請求項７記載の作業要求フロー制御装
   置。
9. 【請求項９】前記第１バス装置のバス・マネージャは、 前記第１バス装置内の前記複数の接続グループの各々に
   ある前記カウンタに結合され、接続グループに対する前
   記カウンタの値が所定の値を下回った時に、前記第２バ
   ス装置に待ち行列使用可能メッセージを送る手段であっ
   て、 待ち行列満杯メッセージを送る前記手段は、待ち行列満
   杯メッセージが先に前記第２バス装置に送られた接続グ
   ループの接続を有するプロセスに対する作業開始メッセ
   ージに応答して、前記待ち行列満杯メッセージを送り、 前記第１バス装置は、再開待ち行列メッセージを前記待
   ち行列使用可能メッセージの受信に応答して前記第２バ
   ス装置から送られるまで、待ち行列満杯メッセージを送
   る 前記待ち行列使用可能メッセージを送る手段と をさらに有する請求項８記載の作業要求フロー制御装
   置。
10. 【請求項１０】前記第２バス装置のバス・マネージャ
    が、 待ち行列満杯メッセージを受信する手段と、 前記第２バス装置から前記第１バス装置に送られ、前記
    第１バス装置からの待ち行列満杯メッセージを生じた操
    作開始メッセージの後に送られ且つ待ち行列満杯メッセ
    ージを生じた作業開始メッセージの元の順序を判定する
    手段と、 前記第２バス装置から前記接続グループに送られた前記
    作業要求メッセージの元の順番が判定され、前記第２バ
    ス装置が前記待ち行列使用可能メッセージを受信した後
    に、前記接続グループに再開待ち行列メッセージを送る
    手段と、 前記作業開始メッセージが前記接続グループに送られた
    順序で前記第１バス装置に前記作業開始メッセージを送
    る手段と をさらに有する請求項９記載の作業要求フロー制御装
    置。
11. 【請求項１１】バスにより結合された複数のバス装置を
    有するマルチ・プロセッサ・サーバ駆動作業処理システ
    ムにおける作業要求のフローを制御する方法であって、 ａ）要求プロセスと異なるバス装置上で実行されている
    サーバ・プロセス間の複数の論理接続を確立するステッ
    プと、 ｂ）各バス装置内の各接続を、それぞれが所定のプロセ
    ッサ資源を有する複数の論理接続グループに割り当てる
    ステップと、 ｃ）作業要求を開始するために、前記バスを使用して、
    前記論理接続を介して、サーバ・プロセスに作業開始メ
    ッセージを送信するステップと、 ｄ）前記作業要求のサーバとして前記作業開始メッセー
    ジ内で識別されたプロセスを実行しているバス装置で作
    業開始メッセージを受信するステップと、 ｅ）前記作業開始メッセージ内で識別された前記サーバ
    ・プロセスに対し、前記論理接続を含む前記論理接続グ
    ループを識別するステップと、 ｆ）各論理接続グループにより実行される作業要求の数
    をトラックするステップと、 ｇ）受信された作業開始メッセージが、識別された論理
    接続グループに対する作業要求の所定の数を超えるかど
    うかを判定するステップと を含む作業フロー制御方法。
12. 【請求項１２】緩やかに結合した分散処理ネットワーク
    において複数のバス装置に対する通信管理装置であっ
    て、 前記バス装置は、バスにより結合されており、前記通信
    管理装置は宛先及び発信元バス装置上にあるプロセス間
    の通信を処理するために動作しており、 前記発信元バス装置から発生されており、作業を開始さ
    せるメッセージを受信する受信手段と、 前記受信手段に結合された前記宛先バス装置及び前記発
    信元バス装置の資源を管理する資源管理手段であって、 前記バス装置上のプロセスの所定のグループに対するバ
    ス装置資源を管理する管理手段であって、各バス装置は
    使用可能な有限量の資源を有し、前記バス装置上のプロ
    セスの所定のグループの各々は前記バス装置に対し使用
    可能である有限量の資源の部分を有する前記管理手段
    と、 前記発信元バス装置からの作業を受信する、メッセージ
    による作業を開始するための手段と、 前記作業を開始させるメッセージの受信が、前記バス装
    置上の前記プロセスの所定のグループに対し使用可能で
    ある有限量の資源の部分より多くの資源使用を生ずる場
    合には、作業を開始させるメッセージを拒絶する制限手
    段と を有する前記資源管理手段と を有する通信管理装置。
13. 【請求項１３】緩やかに結合した分散処理ネットワーク
    において複数のバス装置に対する通信管理装置であっ
    て、 前記バス装置は、バスにより結合されており、前記通信
    管理装置は宛先及び発信元バス装置上にあるプロセス間
    の通信を処理するために動作しており、 プロセス間論理接続の集合である接続グループと、 所定の順番で作業開始メッセージを宛先バス装置に送信
    する手段と、 前記メッセージにより要求された作業を処理するには十
    分な資源を前記宛先バス装置内の接続グループが有して
    いないことを示す、前記宛先バス装置からのメッセージ
    を受信する手段と、 前記発信元バス装置からの前記接続グループに向けられ
    た作業開始メッセージの前記順番を判定する手段と、 作業開始メッセージの前記所定の順番が決定され、前記
    接続グループが前記メッセージにより要求された作業の
    処理に使用可能な資源があることを示した後に、前記接
    続グループに、前記作業開始メッセージが前記所定の順
    番になっていることを示す再開待ち行列メッセージを送
    信する手段と、 前記所定の順番で前記宛先バス装置に前記作業開始メッ
    セージを送る手段と を有する通信管理装置。
14. 【請求項１４】バスにより結合された複数のバス装置を
    有するマルチ・プロセッサ・サーバ駆動作業処理システ
    ムにおいて、作業要求のフローを制御する方法であっ
    て、 各バス装置の所定量の資源を、各バス装置内の、プロセ
    ス間論理接続の集合である複数の接続グループ各々に割
    り当てるステップと、 バス・マネージャにより、発信元バス装置から宛先バス
    装置の特定の接続グループに、作業要求を送るステップ
    と、 前記接続グループに送られた前記作業要求の完了に必要
    な資源が該接続グループに割り当てられた資源の量を超
    える時、前記宛先バス装置内の接続グループから満杯メ
    ッセージを送信するステップと、 前記宛先バス装置から前記発信元バス装置に、先に前記
    発信元バス装置に満杯メッセージを送信した接続グルー
    プが該作業要求を完了するのに使用することができる資
    源を有していることを示すメッセージを送るステップ
    と、 先に送信された満杯メッセージに対応する作業要求を、
    先に送った順番で前記発信元バス装置に送るステップと を含む作業要求フロー制御方法。