JPH065524B2 - 記憶装置管理方法 - Google Patents

Description

【発明の詳細な説明】 Ａ．産業上の利用分野 本発明はバスにおけるプロセス間の作業の流れの制御に
係り、特に対称的なＤＭＡ機能を持たないバス装置のプ
ロセス間通信の通常の流れを逆にする技術に係る。

Ｂ．従来技術 通信方法がプロセスに対してトランスペアレントである
従来のプロセス間通信においては、要求元のプロセスを
含むバス装置が他のバス装置に対して作業の実行を要求
する。処理すべきデータは要求元の記憶装置にあり、サ
ーバ装置、すなわち要求された作業を実行するバス装置
によりアクセスされる。

通常の流れでは、作業要求及びそれに関連するデータが
要求元バス装置の記憶装置からサーバ・バス装置の記憶
装置へＤＭＡ転送される。サーバ・バス装置が入出力バ
スに接続された直接アクセス記憶制御装置の場合、この
ようなＤＭＡ転送は容易である。というのは、入出力制
御装置はマスタＤＭＡ機能を有しており、かつ作業要求
を出したホスト・バス装置はスレーブＤＭＡ機能を有し
ているからである。その場合、マスタＤＭＡ機能を有す
る入出力制御装置は、ホスト・バス装置のプロセッサに
割込みをかけることなく、入出力バスを介してホスト主
記憶装置を直接アクセスすることができる。

Ｃ．発明が解決しようとする課題 しかし、入出力装置が作業要求を出した場合は問題が生
じる。米国特許第４６４９４７３号明細書に記載のごと
きサーバ駆動型の作業処理アーキテクチャでは、従来の
システムとは異なり、要求された作用を実行するプロセ
スが所望の時にデータをアクセスする必要があり、作業
要求に係るデータを受け取る必要はない。ホストはマス
タＤＭＡ機能を、入出力制御装置はスレーブＤＭＡ機能
をそれぞれ持っていないので、サーバであるホストは、
作業要求元である入出力制御装置のデータをアクセスで
きない。したがって、上述のアーキテクチャに適合する
何らかのデータ流れ制御手段が必要である。システムに
よっては、要求に関連するすべてのデータを通常のバス
通信によってサーバへ転送するようにしたものがある。

プロセスに対してトランスペアレントなデータの流れを
実現するため、従来のシステムではバス転送機構が使用
されていた。バス転送機構は、普通、バス装置の１つが
常に作業要求を出し、他のバス装置が常にサーバとなる
ことを想定している。各バス装置には対応するＤＭＡ機
能が与えられる。しかし、バス装置がより高度になって
くると、これはあてはまらなくなる。新しいバス装置は
より多くのインテリジェンスを備えるようになり、した
がって、作業要求を出すことも必要になる。実際、もし
バス装置が対等プロセッサであれば、各プロセッサは作
業要求の発生及び要求された作業の実行を同程度に行な
うことになろう。追加ハードウェアのコストを抑えるた
め、あるいは主記憶装置を完全に制御したいために、プ
ロセッサにスレーブＤＭＡ機能を持たせたくない場合が
多くある。バス装置のＤＭＡ機能にアンバランスがある
と、データの流れを制御する能力が重要になってくる。

Ｄ．課題を解決するための手段 本発明によれば、要求元のバス装置は特別のメッセージ
（記憶域リスト要求）を用いることによって、サーバ・
バス装置の主記憶装置における遠隔記憶域の管理を要求
する。この要求メッセージは、必要な遠隔記憶域の容量
及び希望するバッファの長さを示すフィールドを含んで
いる。サーバ・バス装置はメッセージを受け取ると、少
なくとも示された長さのバッファを検査し、見出した各
バッファの開始アドレス及び長さを識別する制御ブロッ
ク（記憶域リスト制御ブロック）を作成する。これらの
各バッファの管理責任は要求元バス装置が持つことにな
る。次にサーバ・バス装置は、十分長いバッファが見つ
かったかどうか、及びどこに制御ブロックがあるかを示
すメッセージ（記憶域リスト使用可能）を要求元バス装
置に送る。

後述する良好な実施例においては、要求元バス装置はマ
スタＤＭＡ機能を持った記憶制御装置であり、サーバ・
バス装置はスレーブＤＭＡ機能を持ったホストである。
バス装置とは、分散処理ネットワークにおいてバスに接
続された処理装置のことであり、たとえば１台以上のホ
スト・プロセッサを含んでいてもよい。マスタＤＭＡ機
能は、スレーブＤＭＡ機能を持ったバス装置のプロセッ
サに割込みをかけることなく、その主記憶装置へのアク
セスを可能にする。

ホストは制御装置の主記憶装置をアクセスすることはで
きず、したがって作業要求及びそれに関連するデータを
得ることができない。したがって、制御装置内のプロセ
スを作業要求を出した時、制御装置は自身が管理できる
ホスト中の記憶域にその作業要求及び関連するデータを
置く。上述の管理責任には、必要に応じて遠隔記憶域の
読取り及び書込みを行なう権利が含まれる。ホストも、
この遠隔記憶域の読取り、及び制御装置が指定した記憶
位置への応答の書込みを行なえる。次に制御装置は操作
開始メッセージをホストへ送る。操作開始メッセージ
は、サーバ・プロセスが処理すべき作業要求があること
を示し、遠隔記憶域（サーバにとってはローカル記憶
域）において制御ブロックがある記憶位置を識別する。
制御ブロックは、遠隔記憶域において作業要求及び関連
するデータがある記憶位置を識別する。次にホストは、
サーバ・プロセスがアクセスできるように、自身が管理
する記憶域へ情報を転送する。ホストは、制御ブロック
で指定された記憶域に応答を書き込む。

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

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

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

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

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

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

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

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

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

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

バス管理機構 第１図で、バス装置５０及び５２は入出力バス５４等の
物理的経路で結合されている。好ましい一実施例では、
バス装置５０は、線６０を介して主記憶装置５８と結合
されたプロセッサ５６を備えたホスト処理システムを含
む。ホスト・プロセッサ５６は、財務会計プログラムか
らオペレーティング・システム・プログラムに至るま
で、複数のプログラムを実行する。プログラムの実行段
階はプロセスと呼ばれる。幾つかのプロセスＰＡ１〜Ｐ
Ａｎ、ＰＢ１〜ＰＢｎ及びＰＣ１〜ＰＣｎがホスト・プ
ロッサ５６内に示してある。

バス装置５２は、好ましい一実施例では、線７０によっ
て主記憶装置６８と結合された入出力プロセッサ６６を
含む。入出力プロセッサ６６もまた実行可能な幾つかの
プロセスＰＤ１〜ＰＤｎ、ＰＥ１〜ＰＥｎ及びＰＦ１〜
ＰＦｎを有する。プロセッサ５６及び６６の各々に多数
のプロセスが示されているが、プロセッサがただ１つの
プロセスを有する場合もあり得る。他の実施例では、プ
ロセッサ６６はプロセッサ・ネットワーク内の対等プロ
セッサである。プロセスは、その位置がどこであって
も、バス装置５０内のＩＰＣＦ７２及びバス装置５２内
のＩＰＣＦ７４を介して互いに通信をする。通信を行な
うプロセスの各対は、バス装置５０内の８０及びバス装
置５２内の８２で示す論理的接続により、ＩＰＣＦを介
して論理的に接続される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

好ましい一実施例では、Ｘ．２５、ＬＡＮ、ＳＤＬＣ及
びその他の通信プロトコルを実行するプロセスに対する
接続を含む各通信プロトロコルごとに別々の接続グルー
プがバス装置５０内で定義される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

８．次に、サーバは操作開始(3)メッセージを認識し、
待ち行列満杯(3)メッセージを返す。

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

１０．１１．１２．要求元プロセッサは操作開始メッセ
ージを正しい順序で送り直す。

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

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

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

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

各バス装置が完全なＤＭＡ機能を有することが保証され
た通常の流れでは、バス管理機構８８は、プロセスが作
業要求を送ろうとしていることを示す情報をＩＰＣＦ７
４からのＩＰＣＦ動詞から受け取る。バス管理機構８８
は次に、操作開始メッセージを送って、行なうべき作業
があることをバス管理機構８６に通知する。操作開始メ
ッセージのフォーマットを第１３図に示す。このメッセ
ージは、サーバ・バス装置５０内のバス管理機構８６
が、可能ならば制御情報及びデータ・アドレスを指定す
る要求／応答制御ブロック（ＲＲＣＢ）をバス装置５２
の主記憶装置６８からバス装置５０の主記憶装置５８に
移すのに十分な情報を有する。ＲＲＣＢを第１４図及び
第１５図にさらに詳細に示す。バス管理機構８６は次
に、ホスト・プロセッサ５６内の意図されたプロセスに
対し、このプロセスによって待ち行列に入れられる未処
理の作業要求があることをＩＰＣＦ７２を介して通知す
ることができる。プロセスは次にその要求を実行する
が、それにはバス装置間でのデータ移動が必要となる。
バス装置間のデータ転送を制御するために、このとき主
記憶装置５８にあるＲＲＣＢのコピーがバス管理機構８
６で使用される。操作終了（第１６図参照）メッセージ
がバス管理機構８８に送られることにより、要求された
動作が完了したことが知らされ、バス管理機構８８はＩ
ＰＣＦ７４を介して要求元プロセスに通知する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

３．遠隔バス管理機構はＳＬＣＢの全部または一部をそ
の記憶装置にＤＭＡ転送する。

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

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

６．要求元プロセッサ内のバス管理機構は、もはや必要
でないＳＬＣＢを示す記憶域リスト返却メッセージを送
る。

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

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

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

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

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

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

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

１．要求元プロセスはプロセス間動詞インターフェース
における要求をプロセス間機構、すなわち、第２図のＩ
ＰＣＦ７４に出す。

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

３．要求元のバス管理機構８８はバッファ内へデータを
ＤＭＡ転送する。

４．バス管理機構８８は次にサーバ記憶装置のバッファ
内へＲＲＣＢをＤＭＡ転送する。ＲＲＣＢはこのとき、
ステップ２及び３でサーバ・バス装置内の遠隔記憶域内
へＤＭＡ転送された要求及びデータのサーバ記憶装置内
でのアドレスを使用する。

５．要求元プロセッサ６６内のバス管理機構８８は、Ｒ
ＲＣＢ及びデータがサーバ記憶装置内にあることを示す
操作開始バス装置メッセージをサーバ・プロセッサに送
る。操作開始メッセージが送られた時点で、プロセス間
機構を使用するプロセスに関連するすべてのデータは、
サーバの記憶装置内へＤＭＡ転送されている。

６．要求はプロセス間機構７２によってサーバ・プロセ
スに渡される。

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

８．サーバ・プロセスが要求された操作を完了すると、
ＩＰＣＦ動詞を使ってプロセス間機構７２にそのことが
知らされる。

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

１０．プロセス間機構７４は次に、操作が完了したこと
を要求元プロセスに知らせる。

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

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

２０−アテンション（受信側への警告用） ２１−即値データ−１バイト ２２−即値データ−２バイト ２３−即値データ−３バイト ２４−即値データ−４バイト ２５−即値エラー・データ ２６−即値ユーザ・タイプ１データ ２７−即値ユーザ・タイプ２データ ２８−即値ユーザ・タイプ３データ ２９−即値ユーザ・タイプ４データ ２Ａ−２Ｆ−将来の使用のため予約されている。

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

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

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

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

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

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

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

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

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

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

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

バイト 説 明 ０〜１ コマンド長 ２ コマンド修飾子 ３ コマンド・コード＝Ｘ′２３′ ４ 修飾子 ビット０〜１−アクセス・ モード ＝′００′ ビット２〜７−予約 ５〜７ 予約 ８〜１５ アドレス：オフセット−先行 ０を加えて右寄せする。

１６〜２３ 目標 バイト１６：信号メッセージのタ イプ バイト１７〜２３：予約 ２４〜２７ 活動化ＩＤ＝バス装置資源ＩＤ ２８〜３１ ＧＥＴＭＡＸ＝信号メッセージか らの長さ ホストの要求に対する応答が入出力バス装置から返され
る時、その要求に関連するデータを記述する以下の情報
を含む。

バイト 説 明 ０〜１ コマンド長 ２ コマンド修飾子 ３ コマンド・コード（信号メッセー ジのタイプに関連する） ４ 修飾子 ５〜（ｎ−１）コマンド・テキスト （ｎ＝コマンド長） ｎ〜Ｌ データ（Ｌ＝データ入力記述子の 長さ） ＤＭＡ要求による逆の流れ データの流れの制御を逆転するためのさらに別の方法
は、第２８図及び第２９図に示す１対のバス装置メッセ
ージを使用することである。ＤＭＡ要求バス装置メッセ
ージ（第２８図）は、記憶装置へのＤＭＡ転送を要求す
るため、サーバ・バス装置から要求元に送られる。要求
元バス装置からのＤＭＡ完了バス装置メッセージ（第２
９図）は、ＤＭＡ動作が完了したことを示す。要求元の
バス装置、すなわちマスタＤＭＡを備えたバス装置が、
サーバ・バス装置に対するサービスを実行する。要求元
バス装置内のバス管理機構は、どのＣＩＤがこのサービ
ス要求を引き起こしたかを知らない。

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

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

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

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

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

タイプＩＤ（ＯＸ）は、バス装置メッセージのタイプ及
びＤＭＡの方向を定義するために使用される。ＤＭＡ要
求は２つの可能な１６進値を有する。

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

サーバ・プロセッサ・データ・アドレス・フイールド
は、サーバの記憶装置内でのデータ転送の開始アドレス
である。データ転送の方向はタイプ・フイールドによっ
て指定される。

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

ＤＭＡ完了バス装置メッセージのフイールドは以下の通
りでる。

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

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

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

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

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

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

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

２．要求元、この例では入出力プロセッサＩＯＰ内のプ
ロセスは、データをホスト・プロセッサ内のサーバ・プ
ロセスに送ろうとする。要求元プロセスはＩＰＣＦ要求
送信動詞を出す。プロセスからのＩＰＣＦバス管理機構
マップ情報をＲＲＣＢにマップする。

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

４．ホスト内のバス管理機構は、バス装置メッセージに
よって指定された場所に、ＩＯＰ内のバス管理機構がＤ
ＭＡ転送を行なうことを要求するＤＭＡ要求バス装置メ
ッセージを送る。

５．ＩＯＰバス管理機構は要求されたＤＭＡ動作を実行
して、ＲＲＣＢをＩＯＰの記憶装置からホストの記憶装
置に移す。

６．ＩＯＰ内のバス管理機構は、要求されたＤＭＡ動作
が完了したことを示すＤＭＡ完了バス装置メッセージを
ホストに送る。

７．ホスト内のバス管理機構は、バス装置メッセージに
よって指定された場所から、ＤＭＡ動作を実行するよう
ＩＯＰ内のバス管理機構に要求するＤＭＡ要求バス装置
メッセージを送る。これはホストのバス管理機構によっ
て所有される記憶域から行なわれる。

８．ＩＯＰのバス管理機構は要求されたＤＭＡ動作を実
行して、その要求をＩＯＰの記憶装置からホストの記憶
装置に移す。

９．ＩＯＰ内のバス管理機構は、要求されたＤＭＡ動作
が完了したことを示すＤＭＡ完了バス装置メッセージを
送る。上記３つのステップは、要求が４バイトよりも小
さい（たとえばＲＲＣＢ内の即値データ）場合は必要で
ない。

１０．ノートがＩＰＣＦを介して該当のサーバ・プロセ
スに送られる。これで、未処理の待ち行列受信が満たさ
れる。

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

１２．ホスト内のバス管理機構は、バス装置メッセージ
によって指定された場所へのＤＭＡ転送を実行するよう
ＩＯＰ内のバス管理機構に要求するＤＭＡ要求バス装置
メッセージを送る。このアドレスは、ＩＰＣＦデータ受
信動詞によって指定される。

１３．ＩＯＰ内のバス管理機構は要求されたＤＭＡ動作
を実行して、ユーザ・データをＩＯＰの記憶装置からホ
ストの記憶装置に移す。

１４．ＩＯＰ内のバス管理機構は、要求されたＤＭＡ動
作が完了したことを示すＤＭＡ完了バス装置メッセージ
を送る。

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

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

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

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

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

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

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

Ｆ．発明の効果 本発明によれば、記憶装置の一部の管理責任を異なった
バス装置の間で動的に移すことができる。このようにし
て管理される遠隔記憶域は、ハードウェアの追加なし
に、非対称的なハードウェアをマスクする働きがある。
すなわち、たとえハードウェアが対称的でなくても、プ
ロセス間インターフェースに対称性が与えられる。

また遠隔記憶域は、バス装置のパフォーマンスを平衡化
するのに用いることができる。もしあるバス装置のパフ
ォーマンスが主記憶装置の欠如のために制限されている
と、遠隔バッファを用いることによってそのパフォーマ
ンスを上げることができる。したがって、十分な資源を
備えたバス装置からそのような資源に乏しいバス装置へ
資源を移すことにより、システム全体のパフォーマンス
が上がる。

【図面の簡単な説明】

第１図は、プロセス間の論理的接続を有する論理的接続
グループを示す多重処理システムの概略ブロック図であ
る。 第２図は、米国特許第４６４９４７３号に記載のプロセ
ス間通信機構を有する多重処理システムの概略ブロック
図である。 第３図は、第１図の論理的接続グループの管理に使用さ
れるテーブル及び制御ブロックを示す図である。 第４図及び第５図は、もっと多くの要求を受け入れるの
に十分な資源を持たない接続グループに向けられた作業
要求のための待ち行列満杯状況に応答する要求元バス装
置の動作を示す流れ図である。 第６図は、待ち行列間の関係を示すブロック図である。 第７図は、十分な資源が接続グループ中で使用可能であ
るかどうか判定し、使用可能でない場合には待ち行列満
杯メッセージを送るサーバ・バス装置の流れ図である。 第８図は、接続グループに対して資源がいつ使用可能に
なったかを判定し、待ち行列空間使用可能メッセージを
送るサーバ・バス装置のもう１つの流れ図である。 第９図は、バス・エラー状態メッセージのフォーマット
を示すブロック図である。 第１０図は、資源が接続グループにとって解放されてい
ることを示す待ち行列使用可能メッセージのフォーマッ
トを示すブロック図である。 第１１図は、接続グループに作業要求の受入れを開始す
るよう知らせる待ち行列再開メッセージのフォーマット
を示すブロック図である。 第１２図は、接続グループに対する待ち行列満杯状態に
関係するメッセージの流れの図である。 第１３図は、識別されたプロセスに対する作業要求があ
ることを示す操作開始メッセージのフォーマットを示す
ブロック図である。 第１４図は、要求及びデータの場所を識別するために使
用される要求／応答制御ブロックＲＲＣＢのフォーマッ
トを示すブロック図である。 第１５図は、要求／応答制御ブロックに対する追加のフ
ォーマットを示すブロック図である。 第１６図は、作業要求に対する応答があることを示す操
作終了メッセージのフォーマットを示すブロック図であ
る。 第１７図は、管理すべき遠隔記憶域を要求する記憶域要
求メッセージのフォーマットを示すブロック図である。 第１８図は、遠隔的に管理される記憶域リストの場所を
示す記憶域リスト使用可能メッセージのフォーマットを
示すブロック図である。 第１９図は、管理される遠隔記憶域を識別するために使
用される記憶域リスト制御ブロックＳＬＣＢのフォーマ
ットを示すブロック図である。 第２０図は、遠隔記憶域の管理権を返すために使用され
る記憶域リスト完了メッセージのフォーマットを示すブ
ロック図である。 第２１図は、遠隔記憶域の管理権の返却を要求するため
に使用される記憶域リスト返却メッセージのフォーマッ
トを示すブロック図である。 第２２図は、遠隔記憶域の管理の制御権の転送に関係す
るメッセージの流れの図である。 第２３図は、遠隔記憶域の管理権の授与を示す流れ図で
ある。 第２４図は、遠隔記憶域の管理権の返却を示す流れ図で
ある。 第２５図は、作業要求の流れの逆転に関係するメッセー
ジの流れの図である。 第２６図は、少量のデータを非公式に転送するために使
用される信号メッセージのフォーマットを示すブロック
図である。 第２７図は、作業要求の流れを逆転するための信号メッ
セージの代替バージョンを示すブロック図である。 第２８図は、ＤＭＡ転送を要求するために使用されるＤ
ＭＡ要求メッセージのフォーマットを示すブロック図で
ある。 第２９図は、ＤＭＡ転送が完了したことを示すために使
用されるＤＭＡ完了メッセージのフォーマットを示すブ
ロック図である。 第３０図は、データを転送するために第２８図及び第２
９図のＤＭＡメッセージを使用することに関連するメッ
セージの流れの図である。 ５０、５２……バス装置、５６……ホスト・プロセッ
サ、５８、６８……主記憶装置、６６……入出力プロセ
ッサ、７０、７２……ＩＰＣＦ、８６、８８……バス管
理機構、９０……スレーブＤＭＡ機能、９２……マスタ
ＤＭＡ機能。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 フレデリック・ジヨセフ・ジイーシイナ アメリカ合衆国ミネソタ州ロチエスター、 サウス・ウエスト・トウエンテイス・アヴ エニユー703番地

Claims (1)

【特許請求の範囲】
1. 【請求項１】マスタＤＭＡ機能を有する第１バス装置及
   びスレーブＤＭＡ機能を有する第２バス装置がバスを介
   して接続されているデータ処理システムにおいて、 前記第２バス装置の記憶装置の使用を要求する第１メッ
   セージを前記第１バス装置から前記第２バス装置へ送
   り、 前記第１メッセージに応答して特定の記憶域が使用可能
   であることを示す第２メッセージを前記第２バス装置か
   ら前記第１バス装置へ送り、 前記第２メッセージに応答して前記第１バス装置が前記
   記憶域を直接アクセスする、 ことを特徴とする記憶装置管理方法。