(57)【特許請求の範囲】
【請求項１】
複数のパスを介して接続されたイニシエータとターゲットとで通信するための通信制御方法であって、
前記イニシエータは、前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を前記ターゲットに送信し、
前記ターゲットは、前記消去命令を受信すると、前記消去対象のパスを用いた通信を中断して該消去対象のパスのターゲット側を消去し、応答を前記イニシエータに送信し、
前記イニシエータは、前記ターゲットから応答を受けると、前記消去対象のパスのイニシエータ側を消去することを特徴とする通信制御方法。
【請求項２】
前記ターゲットは、前記消去対象のパスを用いた通信の中断を行う場合に、該消去対象のパスから受信した命令が実行中であれば、該命令の実行を中断することを特徴とする請求項１に記載の通信制御方法。
【請求項３】
前記イニシエータは、前記ターゲットから応答を受けると、
処理待ちの状態にある命令を消去して消去対象のパスのイニシエータ側を消去することを特徴とする請求項１に記載の通信制御方法。
【請求項４】
前記ターゲットは、ターゲット側で消去されたパスを通して前記イニシエータから命令が送信されてきた場合、前記イニシエータに対して、宛先が誤りである旨を応答することを特徴とする請求項１に記載の通信制御方法。
【請求項５】
複数のパスを介して接続されたイニシエータと、前記イニシエータからの中断命令によって前記パス内の命令をすべて消去する機能を有するターゲットとで通信するための通信制御方法であって、
前記ターゲットは前記中断命令を前記イニシエータから受けると、前記パス内の命令をすべて消去するとともに、実行中の命令の実行を中断して、中断された命令の識別子及び未処理のデータの位置を記憶して該命令を消去し、前記イニシエータに応答を返し、
前記イニシエータは、前記ターゲットから前記応答を受けると、前記複数のパス毎に異常の有無を判定して、異常がないパスについては、前記ターゲットにより中断された命令の識別子を付した命令及びそれ以降の命令を再度前記ターゲットに送信し、異常があるパスについては、前記ターゲットにより中断された命令以降の命令をすべて取り消し、
前記ターゲットは、前記中断命令の処理後、前記イニシエータから送信された命令を受けると、中断された命令の識別子と同じ識別子を該命令が有するか判定し、同じであれば、記憶しておいた未処理のデータの位置から該命令の処理を再開することを特徴とする通信制御方法。
【請求項６】
前記イニシエータは、前記ターゲットからの応答を受信した後、異常があるパスについては、命令が中断された旨を、中断された命令の発行の要求元に対して通知し、前記要求元から当該命令の再送要求があった場合には、中断された命令と同じ識別子の命令をターゲットに対して発行することを特徴とする請求項５に記載の通信制御方法。
【請求項７】
複数のパスを介して接続されたイニシエータとターゲットとで通信する通信システムであって、
イニシエータは、
前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を前記ターゲットに送信する手段と、
前記ターゲットから応答を受けると前記消去対象のパスのイニシエータ側を消去する手段とを有し、
前記ターゲットは、
前記消去命令を受信すると、前記消去対象のパスを用いた通信を中断して当該消去対象のパスのターゲット側を消去する手段と、
前記応答を前記イニシエータに送信する手段とを有することを特徴とする通信システム。
【請求項８】
複数のパスを介して接続されたイニシエータと、前記イニシエータからの中断命令によって前記パス内の命令をすべて消去する機能を有するターゲットとで通信する通信システムであって、
前記ターゲットは、
前記中断命令を前記イニシエータから受けると、前記パス内の命令をすべて消去するとともに、実行中の命令の実行を中断して、中断された命令の識別子及び未処理のデータの位置を記憶して該命令を消去する手段と、
前記イニシエータに前記中断命令に対する応答を返す手段と、
前記中断命令の処理後、前記イニシエータから送信された命令を受けると、中断された命令の識別子と同じ識別子を該命令が有するか判定する手段と、
中断された命令の識別子と同じ識別子を前記命令が有する場合、記憶しておいた未処理のデータの位置から当該命令の処理を再開する手段とを有し、
前記イニシエータは、
前記ターゲットから前記応答を受けると、前記複数のパス毎に異常の有無を判定する手段と、
異常がないパスについては、前記ターゲットにより中断された命令の識別子を付した命令及びそれ以降の命令を再度ターゲットに送信する手段と、
異常があるパスについては、中断された命令以降の命令をすべて取り消す手段とを有することを特徴とする通信システム。
【請求項９】
複数のパスを介して他の機器と通信可能な機器であって、
前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を前記他の機器に送信する送信手段と、
前記他の機器から応答を受けると、前記消去対象のパスの前記機器の側を消去する消去手段とを有することを特徴とする機器。
【請求項１０】
前記消去手段は、前記他の機器から応答を受けると、処理待ちの状態に有る命令を消去することを特徴とする請求項９に記載の機器。
【請求項１１】
イニシエータにより、複数のパスを介して接続されたターゲットと通信するためのプログラムを格納するコンピュータ可読の記憶媒体であって、前記プログラムにより、
前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を前記ターゲットに送信し、前記ターゲットから応答を受けると前記消去対象のパスのイニシエータ側を消去する機能を実現することを特徴とする記憶媒体。
【請求項１２】
複数のパスを介して他の機器と通信可能な機器であって、
前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を受信すると、該消去対象のパスを用いた通信を中断する中断手段と、
前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を受信すると、前記消去対象のパスの前記機器の側を消去する消去手段と、
前記消去命令に対する応答を前記他の機器に送信する応答手段とを有することを特徴とする機器。
【請求項１３】
前記中断手段は、前記消去対象のパスを用いた通信の中断を行う場合に、該消去対象のパスから受信した命令が実行中であれば、該命令の実行を中断することを特徴とする請求項１２に記載の機器。
【請求項１４】
前記消去手段は、前記消去対象のパスから受信した命令を消去することを特徴とする請求項１２或いは１３に記載の機器。
【請求項１５】
ターゲットにより、複数のパスを介して接続されたイニシエータと通信するためのプログラムを格納するコンピュータ可読の記憶媒体であって、前記プログラムにより、
前記ターゲットは、前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を受信すると、前記消去対象のパスを用いた通信を中断して前記消去対象のパスのターゲット側を消去し、応答を前記イニシエータに送信する機能を実現することを特徴とする記憶媒体。
【請求項１６】
複数のパスを介して接続されたイニシエータにからの中断命令によって前記パス内の命令をすべて消去する機能を有するターゲットにより前記イニシエータと通信するためのプログラムを格納するコンピュータ可読の記憶媒体であって、前記プログラムは、
前記中断命令を前記イニシエータから受けると、前記パス内の命令をすべて消去するとともに、実行中の命令の実行を中断して、中断された命令の識別子及び未処理のデータの位置を記憶して該命令を消去し、前記イニシエータに応答を返し、前記中断命令の処理後、前記イニシエータから送信された命令を受けると、中断された命令の識別子と同じ識別子を該命令が有するか判定し、同じであれば、記憶しておいた未処理のデータの位置から該命令の処理を再開する機能を実現することを特徴とする記憶媒体。
【請求項１７】
イニシエータにより、前記イニシエータからの中断命令によって前記パス内の命令をすべて消去する機能を有するターゲットと通信するためのプログラムを格納するコンピュータ可読の記憶媒体であって、前記プログラムは、
前記ターゲットから、前記中断命令に応じてパス内の命令をすべて消去するとともに、実行中の命令の実行を中断して、中断された命令の識別子及び未処理のデータの位置を記憶して該命令を消去した旨の応答を受けると、前記複数のパス毎に異常の有無を判定して、異常がないパスについては、前記ターゲットにより中断された命令の識別子を付した命令及びそれ以降の命令を再度前記ターゲットに送信し、異常があるパスについては、中断された命令以降の命令をすべて取り消す機能を実現することを特徴とする記憶媒体。
【請求項１８】
複数のパスを介して接続されたイニシエータと、前記イニシエータからの中断命令によって前記パス内の命令をすべて消去する機能を有するターゲットとで通信する通信システムであって、
イニシエータは前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を前記ターゲットに送信し、前記ターゲットから応答を受けると前記消去対象のパスのイニシエータ側を消去し、
前記ターゲットは、前記消去命令を受信すると、前記消去対象のパスを用いた通信を中断して該消去対象のパスのターゲット側を消去し、応答を前記イニシエータに送信し、
前記ターゲットは中断命令をイニシエータから受けると、前記パス内の命令をすべて消去するとともに、実行中の命令の実行を中断して、中断された命令の識別子及び未処理のデータの位置を記憶して該命令を消去し、前記イニシエータに応答を返し、前記中断命令の処理後、前記イニシエータから送信された命令を受けると、中断された命令の識別子と同じ識別子を当該命令が有するか判定し、同じであれば、記憶しておいた未処理のデータの位置から当該命令の処理を再開し、
前記イニシエータは、ターゲットから前記応答を受けると、前記複数のパス毎に異常の有無を判定して、異常がないパスについては、前記ターゲットにより中断された命令の識別子を付した命令及びそれ以降の命令を再度ターゲットに送信し、異常があるパスについては、中断された命令以降の命令をすべて取り消すことを特徴とする通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、イニシエータ（ホストコンピュータ）とターゲット（プリンタ等）の機器同士を接続する通信制御方法及びシステムに関する。
【０００２】
【従来の技術】
近年、ＩＥＥＥ１３９４インターフェースが、コンピュータと周辺機器、あるいは周辺機器同士の接続に用いられつつある。ＩＥＥＥ１３９４インターフェースは、セントロニクスインターフェースなどのハンドシェイク方式に比べて高速で、しかも双方向通信が可能である。また、メモリバスモデルのインターフェースであり、ＩＥＥＥ１３９４インターフェースで接続された機器は、相手の機器に対して指定されたアドレスのデータを読み書きすることができる。
【０００３】
このＩＥＥＥ１３９４は、広範囲に応用するための物理層及びリンク層のプロトコルを定めたもので、機器ごとの詳細なプロトコルは定められていない。そのため、物理・リンク層としてＩＥＥＥ１３９４を利用したＳＢＰ（ＳｅｒｉａｌＢｕｓ  Ｐｒｏｔｏｃｏｌ）−２などのトランスポート層のプロトコルが提案されている。トランスポート層はアプリケーションに対してデータ転送機能を提供する層であり、この層を利用するアプリケーションは、互いにデータの交換が可能となる。
【０００４】
このＳＢＰ−２なるプロトコルは、ＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かしたプロトコルであり、データの受信側がそれ自身の都合に応じてデータを受信することができる。これに対して、ＳＢＰ−２以外のプロトコルには、非同期に発生するデータの転送が可能となるものも、マルチチャネルが実現できるものもあるが、そのようなプロトコルではＩＥＥＥ１３９４のメモリバスモデルとしての特徴を活かすことができない。すなわち、ホストとプリンタの通信であれば、プリンタ側の都合に応じてデータ転送を行うことができず、ホストがプリンタの状態を監視しながらデータ転送を行わねばならないことになる。
【０００５】
ＳＢＰ−２では、データを転送する場合に、まず送信側でログインという操作を行って通信相手との間のチャネルを確立する。この際、ログインした側がイニシエータと呼ばれ、イニシエータと接続された相手側がターゲットと呼ばれる。データ転送は、イニシエータからの指示に応じて、ターゲットからイニシエータのバッファにデータを読み書きすることで行われる。この方式においては、イニシエータは、送信するデータを格納したバッファのアドレスやサイズ等が書かれたＯＲＢ（Ｏｐｅｒａｔｉｏｎ  Ｒｅｑｕｅｓｔ  Ｂｌｏｃｋ）を作成し、そのＯＲＢのアドレスをターゲットに知らせる。ターゲットでは自分の都合に合わせてＯＲＢに書かれたアドレスやサイズに基づいてイニシエータからデータを読み出し、あるいはデータを書き込み、それらの処理後ステータスブロックを作成して、処理の状態をイニシエータに知らせることになる。
【０００６】
【発明が解決しようとする課題】
このＩＥＥＥ１３９４の上に構築されるＳＢＰ−２プロトコルを利用して通信を行う場合、特に、ホストコンピュータ等のデータ源をイニシエータとし、それからターゲットであるプリンタ装置などの周辺機器へのデータ転送に応用する場合、次のような４つの問題点があった。
（問題点１）全２重通信のために手順が複雑である。
【０００７】
ＳＢＰ−２では、基本的にデータの転送はイニシエータによって管理され、ターゲットはイニシエータへの非同期のデータ転送を行うことができない。すなわち、ＳＢＰ−２では、ターゲットがイニシエータへのデータ転送を行いたい時には、イニシエータに対してアンソリシテドステータスでデータリード要求を送り、イニシエータはそれに応じてＯＲＢ生成し、ペンディング中のＯＲＢ（イニシエータからターゲットへのデータ転送要求などが含まれている）のリストの末尾にその生成したＯＲＢをつける。このＯＲＢは先頭から順番に処理されるため、ターゲットがイニシエータにリード要求を発行したタイミングではなく、イニシエータ側のＯＲＢの処理が進み、ターゲットからのデータリード要求によるＯＲＢが処理されたときに初めてターゲットからイニシエータにデータが転送されることになる。すなわち、双方向の非同期なデータ転送が行えず、ターゲットからイニシエータに転送すべきデータが非同期に発生する場合、例えばターゲットがプリンタであれば、そのプリンタでエラーが発生する場合など、直ちにイニシエータに伝達すべきデータを即時に伝達できない。
【０００８】
このため、例えばプリンタで非同期に発生するデータを即座にホストに転送するためには、プリンタをイニシエータとしてログイン手続きを行い、ホストコンピュータをターゲットとするデータ転送を行わねばならない。
【０００９】
このようにホストコンピュータとプリンタで互いにログインしてそれぞれがイニシエータでありターゲットであるような状況では、ホストコンピュータ及びプリンタの双方にイニシエータとしてのプロセスとターゲットとしてのプロセスを備えなければならない。また、ログインの操作もプリンタから行わねばならない。プリンタのような画像を扱う周辺装置では、画像処理のために大量のメモリ資源やプロセッサ資源を消費する。そのために、装置の構成を簡略化して原価を節減したり、処理を迅速に行うため画像処理用途以外に用いられる資源をできるだけ節約しなければならない。しかし、上述のように多くのプロセスを稼働することになればその分多くの資源を消費することになり、原価低減・処理の効率化という目的に反することになる。
【００１０】
また、ホストコンピュータとプリンタとの関係であれば、各方向に流れるデータは、印刷データとそれに対する処理状況といったように、互いに関連付けられるものであるが、各方向について独立したログインによりチャネルを設定すると、それらデータとレスポンスとを関連づけなければならず、そのための処理手順を新たに追加する必要がある。
【００１１】
このようにＩＥＥＥ１３９４及びＳＢＰ−２をそのままホストコンピュータ−プリンタ装置間の通信に適用することは適切でなく、各装置において必要とされる資源を減らすことや効率を向上させることが難しかった。
（問題点２）マルチチャネルを実現できない。
【００１２】
最近、周辺装置として種々の機能を複合させた複合機が利用されつつある。例えば、ファクシミリ装置を、スキャナ単体，プリンタ単体，ファクシミリとしホストコンピュータ等から利用できるデジタル複合機などがある。このような装置を利用する際には、各単体機能ごとに独立した複数のチャネルを介して通信を行えば、同時に複数の機能を利用することができる。
【００１３】
しかしながら、ＳＢＰ−２では、マルチチャネルを提供できないため、そのように単体機能を同時に利用することが難しい。
【００１４】
また、たとえマルチチャネルが実現されても、ＳＢＰ−２レイヤで定められた“Ａｂｏｒｔ  Ｔａｓｋ  Ｓｅｔ”というコマンドしか、プロトコル違反などの異常事態を解除するための手段を持たない。このコマンドによれば、ＯＲＢリストにチェーンされたＯＲＢがすべて消去されてしまい、異常事態とは無関係に動作しているチャネルについてもリセットされてしまう。このように、エラーを生じていないチャネルあるいはチャネルを構成する単方向のパス（例えば全二重チャネルであれば上りと下りの一対のパスでひとつのチャネルが構成される）を単位とする通信路の管理を行うことができなかった。
（問題点３）バスリセットに対応できない。
【００１５】
ＩＥＥＥ１３９４では、１３９４シリアルバスへの機器の新たな接続や取り外し、あるいは、接続された機器の電源投入や切断といった、ネットワーク構成の変化要因となる状態変化が発生するとバスリセットが発生する。バスリセットは、バス上で上記のような状態変化を検知したノードがバスリセット信号をバス上に送信することで発生する。発生されたバスリセット信号は、ノードからノードへと伝達され、ネットワーク上の全ノードがバスリセット信号を受信すると、バスリセットのための一連の動作が各ノードで行われる。
【００１６】
このようにバスリセットは、ネットワーク上のノードにおける処理とは非同期に発生する。また、バスリセットの原因となったノードとアプリケーションについては無関係なノードであっても、一旦バスリセットが発生してしまえばバスリセットの処理を行わねばならない。このバスリセットの過程で、ＳＢＰ−２で通信を行っているノードでは、設定されていたコネクションが切断されてしまい、再度コネクションをつなげてもバスリセット直前の状態から処理を続行できる保証が与えられていない。
【００１７】
また、イニシエータがターゲットに各キュー毎に数を超えないよう命令を送信していたため、使われないキューに確保されている数が無駄になる事がある。
【００１８】
本発明は上記従来例に鑑みてなされたもので、１回のログインで全２重通信（互いに非同期な双方向通信）を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用できる通信制御方法及び装置を提供することを目的とする。
【００１９】
また、チャネルあるいはパスを単位として管理可能なマルチチャネルを実現する通信制御方法及び装置を提供することを目的とする。
【００２０】
また、バスリセットが発生しても、バスリセット直前の状態から処理の続行を保証する通信制御方法及び装置を提供することを目的とする。
【００２１】
また、イニシエータからターゲットに送信できる命令の数の管理をターゲットの各キュー毎に行うのではではなく、一元管理することにより効率的にリソースを利用できる通信制御方法及び装置を提供することを目的とする。
【００２２】
また、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する通信制御方法及び装置を提供することを目的とする。
【課題を解決するための手段】
上記目的を達成するために本発明は次のような構成から成る。すなわち、複数のパスを介して接続されたイニシエータとターゲットとで通信するための通信制御方法であって、前記イニシエータは、前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を前記ターゲットに送信し、前記ターゲットは、前記消去命令を受信すると、前記消去対象のパスを用いた通信を中断して該消去対象のパスのターゲット側を消去し、応答を前記イニシエータに送信し、前記イニシエータは、前記ターゲットから応答を受けると、前記消去対象のパスのイニシエータ側を消去する。
【００２６】
あるいは、複数のパスを介して接続されたイニシエータと、前記イニシエータからの中断命令によって前記パス内の命令をすべて消去する機能を有するターゲットとで通信するための通信制御方法であって、前記ターゲットは前記中断命令を前記イニシエータから受けると、前記パス内の命令をすべて消去するとともに、実行中の命令の実行を中断して、中断された命令の識別子及び未処理のデータの位置を記憶して該命令を消去し、前記イニシエータに応答を返し、前記イニシエータは、前記ターゲットから前記応答を受けると、前記複数のパス毎に異常の有無を判定して、異常がないパスについては、前記ターゲットにより中断された命令の識別子を付した命令及びそれ以降の命令を再度前記ターゲットに送信し、異常があるパスについては、前記ターゲットにより中断された命令以降の命令をすべて取り消し、前記ターゲットは、前記中断命令の処理後、前記イニシエータから送信された命令を受けると、中断された命令の識別子と同じ識別子を該命令が有するか判定し、同じであれば、記憶しておいた未処理のデータの位置から該命令の処理を再開する。
【００２７】
あるいは、複数のパスを介して他の機器と通信可能な機器であって、前記複数のパスの少なくともひとつを用いて、該パスとは異なる消去対象のパスの消去命令を前記他の機器に送信する送信手段と、前記他の機器から応答を受けると、前記消去対象のパスの前記機器の側を消去する消去手段とを有する。
【００２８】
＜システムのハードウエア構成＞
図２４において、ホストコンピュータ２００は、ＲＯＭ３のプログラム用ＲＯＭに記憶された文書処理プログラム等に基づいて、図形，イメージ，文字，表（表計算等を含む）等が混在した文書処理を実行するＣＰＵ１を備える。ＣＰＵ１はシステムデバイス４に接続される各デバイスをＣＰＵ１が総括的に制御する。また、ＲＯＭ３のプログラム用ＲＯＭには、ＣＰＵ１の制御プログラム等が記憶され、ＲＯＭ３のフォント用ＲＯＭには上記文書処理の際に使用するフォントデータ等が記憶され、ＲＯＭ３のデータ用ＲＯＭは上記文書処理等を行う際に使用する各種データが記憶される。ＲＡＭ２は、ＣＰＵ１の主メモリ，ワークエリア等として機能する。
【００２９】
プログラムはＲＡＭ２に格納されても良い。また、ＲＡＭ２には、送信データバッファやＯＲＢを格納するシステムメモリが確保される。
【００３０】
キーボードコントローラ（ＫＢＣ）５は、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）６は、ＣＲＴディスプレイ（ＣＲＴ）１０の表示を制御する。メモリコントローラ（ＭＣ）７は、プートプログラム，種々のアプリケーション，フォントデータ，ユーザファイル，編集ファイル等を記憶するハードディスク（ＨＤ）、フロッピーディスク（ＦＤ）等の外部メモリ１１とのアクセスを制御する。１３９４インターフェース８は、ＩＥＥＥ１３９４規格に従ってプリンタ１００に接続されて、プリンタ１００との通信制御処理を実行する。なお、ＣＰＵ１は、例えばＲＡＭ２上に設定された表示情報ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴ１０上でのＷＹＳＩＷＹＧを可能としている。また、ＣＰＵ１は、ＣＲＴ１０上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウィンドウを開き、種々のデータ処理を実行する。
【００３１】
プリンタ１００において、プリンタＣＰＵ１２は、ＲＯＭ１３のプログラム用ＲＯＭに記憶された制御プログラム等或いは外部メモリ１４に記憶された制御プログラム等に基づいてシステムバス１５に接続される各種のデバイスとのアクセスを総括的に制御し、印刷部インタフェース１６を介して接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。また、このＲＯＭ１３のプログラムＲＯＭには、後述する各種エージェントや画像処理を実現するＣＰＵ１２の制御プログラム等が記憶される。ＲＯＭ１３のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ１３のデータ用ＲＯＭには、ハードディスク等の外部メモリ１４が無いプリンタの場合には、ホストコンピュータ上で利用される情報等が記憶されている。ＣＰＵ１２は１３９４インターフェース１８を介してホストコンピュータとの通信処理が可能となっており、プリンタ内の情報等をホストコンピュータ２００に通知可能に構成されている。
【００３２】
ＲＡＭ１９は、ＣＰＵ１２の主メモリ、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。なお、ＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。
【００３３】
前述したハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１４は、メモリコントローラ（ＭＣ）２０によりアクセスを制御される。外部メモリ１４は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作パネル１８には、操作のためのスイッチおよびＬＥＤ表示器等が配されている。また、前述した外部メモリは１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード，言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。さらに、図示しないＮＶＲＡＭを有し、操作パネル１０１２からのプリンタモード設定情報を記憶するようにしても良い。
【００３４】
また、付図示ではあるが、ステイプル機能、ソーター機能等を有するフィニッシャーを接続可能である。
【００３５】
＜イニシエータの構成＞
上述したハードウエア構成において、プリンタ１００をターゲットとし、ホストコンピュータ２００をイニシエータとした通信システムを、図１及び図２に示す。本実施形態に置いては、これら構成は、それぞれホストコンピュータ及びプリンタにおけるＣＰＵによりプログラムを実行することで実現される。まず、図２のイニシエータから説明する。
【００３６】
図２において、イニシエータであるホストコンピュータにおいては、プリンタドライバ等のクライアント２０６はＳＨＰＴ−２処理部２０１を介してプリンタに対するデータ転送要求を発行するとともに、プリンタからの応答を受ける。
【００３７】
ＳＨＰＴ−２処理部２０１は、システムメモリに生成されるマネジメント要求キューやＩ／Ｏ要求キューやＯＲＢを管理している。クライアント２０６は単数或いは複数のクライアントプロセスからなり、各クライアントプロセスからのＩ／Ｏ要求コマンドは各クライアントプロセスの通信に用いられる各Ｉ／Ｏ要求キューにそれぞれキューイングされる。図中、４つのＩ／Ｏ要求キューが例示されているが、Ｉ／Ｏ要求キューの数はこれに限られるものではなく、Ｉ／Ｏ要求キューは各クライアントプロセスの通信接続時に動的に用意され、各クライアントプロセスの通信には単数或いは複数のＩ／Ｏ要求キューが用いられる。
【００３８】
図中の例では、クライアントプロセス２０６ａの通信には２つのＩ／Ｏ要求キュー２０２ａ，２０２ｂが用いられ、Ｉ／Ｏ要求キュー２０２ａにはクライアントプロセス２０６ａからのライト要求コマンドが、Ｉ／Ｏ要求キュー２０２ｂにはクライアントプロセス２０６ａからのリード要求コマンドが、それぞれキューイングされ、これらの二つのＩ／Ｏ要求キューにより非同期全二重通信が行なわれる様子を示している。同様にクライアントプロセス２０６ｂの通信にはＩ／Ｏ要求キュー２０２ｃが用いられ、このＩ／Ｏ要求キューにライト要求コマンドがキューイングされ、単方向通信が行われ、また、クライアントプロセス２０６ｃの通信にはＩ／Ｏ要求キュー２０２ｄが用いられ、このＩ／Ｏ要求キューにライト要求コマンド及びリード要求コマンドの一方もしくは両方をキューイングすることで同期半二重通信が行なわれる様子を示している。
【００３９】
マネジメント要求キューは、Ｉ／Ｏ要求キューと異なり、イニシエータへのログイン時に作成される。作成の手順そのものは、後述するＩ／Ｏ要求キューと同一である。マネジメント要求キューは、Ｉ／Ｏ要求キューを管理するために設けられたキューで、後述するマネジメント参照キューとの対でマネジメントパスを構成する。このマネジメント要求キューは、他のＩ／Ｏ要求キューに対する特定の要求を処理するために用いられるものである。このマネジメントキューの使用例については後述する。これらＩ／Ｏ要求キュー及びマネジメントキューは、不図示のキュー管理エージェントにより管理される。
【００４０】
ＯＲＢはイニシエータであるホストコンピュータからターゲットであるプリンタへ、あるいはプリンタからホストコンピュータへ渡されるデータバッファのアドレスやサイズ等を格納したブロックであり、先頭のＯＲＢからＯＲＢリスト２０４に順次リンクされている。このＯＲＢについては、次のような処理の原則がある。
【００４１】
（１）各Ｉ／Ｏ要求キューそれぞれの先頭から取り出したコマンドから順にＯＲＢが作成され、ＯＲＢリストの末尾につけられる。コマンドをＯＲＢリストの末尾につける順序には特に制約はない。各Ｉ／Ｏ要求キューに優先順位を付け、特定のＩ／Ｏ要求キューの先頭のコマンドが優先的にＯＲＢリストの末尾につけられるようにしてもよい。
【００４２】
（２）ＯＲＢは、ＯＲＢリストの先頭から順次フェッチされる。完了通知（ステータスブロック）を受信すると、そのステータスに対応するＯＲＢはＯＲＢリストからはずされる。
【００４３】
（３）リンクされるＯＲＢの数の上限は、後述するターゲットにおけるプリフェッチプールの容量（それぞれ処理中のコマンドも含む）と同一である。
【００４４】
（１），（２）項により、各Ｉ／Ｏ要求キュー毎のＩ／Ｏ要求は、それぞれのＩ／Ｏ要求において、発生した順にターゲットに発行されることが保証される。また、（３）項により、ＯＲＢリスト中のＩ／Ｏ要求はターゲットに渡されていることが保証される。この（３）項を実現するために、ＳＨＰＴ−２処理部２０１は、各要求キューに対してそれぞれ１つのカウンタ及びプリフェッチプールに対して１つのカウンタを用意している。
【００４５】
各Ｉ／Ｏ要求キューに対するカウンタはＣｕｒｒｅｎｔ−ＱＵＥというカウンタであり、図の例では４つのＩ／Ｏ要求キューに対する４つのＣｕｒｒｅｎｔ−ＱＵＥカウンタ２０３ａ，２０３ｂ，２０３ｃ，２０３ｄと、マネジメントキューに対するカウンタ２０３ｆが示されている。それぞれのＣｕｒｒｅｎｔ−ＱＵＥカウンタは、分母（右側）にＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数、及び、分子（左側）にそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を保持している。
【００４６】
図中の例は、各Ｉ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数が“１”であり、各要求キュー２０２ａ，２０２ｂ，２０２ｃ，２０２ｄ及びマネジメントキュー２０３ｆに属するコマンドの現在のＯＲＢリスト内での個数がそれぞれ“３”，“１”，“０”，“２”，“０”である状態を示している。
【００４７】
プリフェッチプールに対するカウンタはＣｕｒｒｅｎｔ−ＰＯＯＬというカウンタ２０３ｅであり、分母（右側）にはプリフェッチプールの全域の数“１０”からそれぞれのＩ／Ｏ要求キュー及びマネジメントキューの予約域の数“１＋１＋１＋１＋１”の総和“５”を減じた値“５”がセットされる。このカウンタは各Ｉ／Ｏ要求キューに割り当てられた予約域以外のプリフェッチプールにおける空数を示している。
【００４８】
また、分子（左側）には、要求キューに貸し出せる数“２”がセットされる。具体的には、２０３ａ〜２０３ｄの分母より分子の大きいものから、この場合、２０３ａと２０３ｄの分子−分母（３−１＝２、２−１＝１）を計算し、各Ｉ／Ｏ要求キューに割り当てられた予約域以外のプリフェッチプールにおける空数５から計算された２と１を加えた３を減じた値“２”がセットされる。
【００４９】
図中の例は各Ｉ／Ｏ要求キューに割り当てられた予約域以外のプリフェッチプールにおける空数が“５”である状態を示している。
【００５０】
このプリフェッチプールの全域の数はターゲットとなる機器が保持しており、ログイン時等にターゲットから読み出され、イニシエータに記憶される。
【００５１】
図中の例は、プリフェッチプールの全域の数が“１０”である状態を示している。各Ｉ／Ｏ要求キューに付随するＣｕｒｒｅｎｔ−ＱＵＥカウンタの現在のＯＲＢリスト内での個数はＯＲＢの生成と削除に合わせて増減される。
【００５２】
ＯＲＢの生成に当たっては、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタの現在の値、すなわちＯＲＢリスト内での個数がＩ／Ｏ要求キューに初期に割り当てられたプリフェッチプール内における予約域の数を超えない場合には、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタを増加させ、ＯＲＢをＯＲＢリストに追加する。そうでない場合にはＣｕｒｒｅｎｔ−ＰＯＯＬカウンタが“１”以上であるかどうかを調べ、“１”以上であれば、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタを減じ、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタを増加させ、ＯＲＢをＯＲＢリストに追加する。Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタが既に“０”になっている場合にはＯＲＢをＯＲＢリストに追加しない。
【００５３】
ＯＲＢの削除にあたっては、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタの現在の値、すなわちＯＲＢリスト内での個数がＩ／Ｏ要求キューに初期に割り当てられたプリフェッチプール内における予約域の数を超えている場合には、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタを増加させる。いずれの場合にもＣｕｒｒｅｎｔ−ＱＵＥカウンタの現在のＯＲＢリスト内での個数は減じられる。
【００５４】
また、ＯＲＢを生成した際には、ターゲット側のドアベルレジスタと呼ばれるレジスタに所定値を書き込む、あるいは、リストの先頭のＯＲＢのアドレスをＯＲＢポインタと呼ばれるレジスタに書き込むことにより、ＯＲＢが発生したことをターゲットに知らせる。既にターゲットが実行しているＯＲＢリストの最後にＯＲＢを追加した場合にはドアベルレジスタへの書き込みを行い、ＯＲＢリストがない状態で新規に先頭のＯＲＢを作成した場合には、ＯＲＢポインタへの書き込みを行う。この手続きはＳＢＰ−２で規定されている。
【００５５】
また、ＳＨＰＴ−２処理部２０１は、ステータスＦＩＦＯ２０５を含む。
【００５６】
１３９４インターフェース１０９を介して受信されたステータスは、ＳＨＰＴ−２処理部２０１により処理される。ＳＨＰＴ−２処理部２０１は、受信したステータスに対応するＯＲＢをＯＲＢリスト２０４から外すとともに、そのＯＲＢに対応するコマンドをＩ／Ｏ要求キューから外す。
【００５７】
また、ＳＢＰ−２レイヤの管理を行うために、イニシエータからターゲットのマネジメントレジスタにコマンドの書き込みを行うことができる。この書き込みはＳＢＰ−２で規定されているもので、ＳＨＰＴ−２レイヤの管理範囲外であるため、詳細は省く。このマネジメントレジスタへの書き込みは、ＳＢＰ−２の管理のために利用される。
【００５８】
イニシエータたるホストコンピュータは以上のような機能的な構成からなっている。
【００５９】
＜ターゲットの構成＞
図１は、ターゲットたるプリンタの機能上の構成を示すブロック図である。図１において、ドアベルレジスタ１０１ａは、イニシエータによって書き込まれるレジスタであり、ＯＲＢが新たに生成されたことを示す。また、ＯＲＢポインタ１０１ｂには、新たに生成されたＯＲＢのアドレスがイニシエータにより書き込まれる。フェッチエージェント１０１は、ドアベル１０１ａに書き込みがあると、１３９４インターフェース１０９を介してＯＲＢポインタで示されるＯＲＢを読み込む。ＯＲＢディスパッチャ１０２は、空参照リスト１０４からポインタを取り出し、ポインタの指し示すプリフェッチプール１０３の空領域にフェッチエージェント１０１により読み込まれたＯＲＢのコマンドを格納するとともに、当該ＯＲＢの後述するＱｕｅｕｅ  ＩＤフィールドにしたがって該当参照キューの末尾にポインタを接続する。
【００６０】
図中の例は、４つの参照キュー１０５ａ，１０５ｂ，１０５ｃ，１０５ｄ及びマネジメント参照キュー１０５ｆが存在する状態を示している。参照キューの数はこれに限られるものではなく、各クライアントプロセスの通信接続時に動的に用意され、各クライアントプロセスの通信には単数或いは複数の参照キューが用いられる。
【００６１】
実行エージェント１０６は、各参照キューにキューイングされたコマンドを先頭から取り出し、コマンドに従ってイニシエータのバッファへのデータの書込み及びイニシエータのバッファからのデータの読み出し等を行う。その後、ホストコンピュータにノーマルステータスを返す。
【００６２】
実行エージェント１０６は１つの実行スレッドがすべての参照キューに対する処理を他の参照キューの処理にブロックされないように独立にスケジューリングして実行するようにしてもよいし、各参照キュー毎に別の実行スレッドでスレッドをスケジューリングし実行してもよいし、またその組み合わせであってもよい。なお、実行エージェント１０６は、例えばＰＤＬを解釈実行してラスタデータを生成するラスタライザ等のクライアントプロセス１０８ａからのデータ転送要求に応じて、参照キュー１０５ｂで参照されるプリフェッチプール内のリードコマンドで指定されたイニシエータのバッファにデータを書き込む。このデータ転送要求は、イニシエータからのライトコマンドやリードコマンドとは非同期に発生するため、イニシエータはリードコマンドＯＲＢによって参照キュー１０５ｂで参照されるプリフェッチプール内にリードコマンドを常時キューイングしておく。ターゲットは、リードコマンドが参照キュー１０５ｂで参照されるプリフェッチプール内にキューイングされている限り、いつでもデータをイニシエータに渡すことができる。なお、バスインターフェース１１０は、ターゲットであるプリンタ１００からイニシエータであるホストコンピュータ２００のシステムメモリ２０８の所望のメモリロケーションにアクセスするためのインターフェースである。
【００６３】
マネジメントレジスタ１１１は、イニシエータからのコマンドであるマネジメントＯＲＢを書き込むためのレジスタである。このマネジメントＯＲＢは、マネジメントレジスタ実行エージェントにより処理される。このレジスタには、後述するAbortTaskSetコマンドなどが書き込まれる。
【００６４】
以上、イニシエータ及びタ−ゲットの構成と動作を簡単に説明した。これらを更に詳しく説明する前に、まずＯＲＢの詳しい内容を説明する。
【００６５】
＜コマンドＯＲＢ（Ｏｐｅｒａｔｉｏｎ  Ｒｅｑｕｅｓｔ  Ｂｌｏｃｋ）の内容＞
図７はＯＲＢ一般の構成を示す図である。図７（Ａ）において、”Ｎｅｘｔ＿ＯＲＢ”（リンク）フィールド３０１は、次のＯＲＢへのリンクである。
【００６６】
次のＯＲＢがない場合にはそれを表す所定の値が入れられる。なお、先頭のＯＲＢは、所定のアドレスレジスタにより示される。
【００６７】
“ｄａｔａ＿ｄｅｓｃｒｉｐｔｅｒ”（データデスクリプタ）フィールド３０２は、データバッファのアドレスを示す。“ｄ”（方向）フィールド３０３は、ホストコンピュータからプリンタへのデータ転送（０：ライト）か、プリンタからホストコンピュータへのデータ転送（１：リード）かを示す。“ｄａｔａ＿ｓｉｚｅ”（データサイズ）フィールド３０４は、アドレスフィールド３０２で指し示されるデータバッファのサイズを示す。以上、図の点線よりも上のフィールド（未説明のフィールドも含めて）がＳＢＰ−２で規定されているフィールドであり、これから説明するフィールド３０５〜３０８が、ＳＨＰＴ−２に固有の処理に用いられるフィールドである。
【００６８】
“ＱｕｅｕｅＩＤ”フィールド３０５は、使用される参照キューのＩＤを表わしている。“ｆｕｎｃｔｉｏｎ”（ファンクション）フィールド３０６は、図７（Ｂ）に示すようにＯＲＢの種類を示している。０Ｈがライトコマンド、４０Ｈがリードコマンドを表わす。
【００６９】
“ｓｅｑ＿ＩＤ”（シーケンスＩＤ）フィールド３０８は、参照キュー毎に、ＯＲＢの生成順に振られるシーケンシャルな識別子である。この識別子は、本実施形態ではＯＲＢが生成されるごとに増加するように与えられる。
【００７０】
“ｓｅｑ＿ＩＤ”フィールドは、最大値まで増加した後、次の増加で０に戻る。なお、このシーケンスＩＤフィールドに値を与える基準となるカウンタは、バスリセットや他の障害による影響を受けない領域に設けられる。それは、ターゲットにおいては、シーケンスＩＤの増加性を前提として処理を行うためである。コントロールブロックフィールド３０９には、ファンクションフィールド３０６の値や、各ファンクションに対してターゲットで実現される機能に応じて様々な値が入れられる。なお、バッファのアドレスやサイズについては、Ｉ／Ｏ要求キューに入れられたコマンドからＯＲＢ生成時に得る。
【００７１】
次に、機能ごとにＯＲＢの内容を説明する。
【００７２】
（ライトコマンドＯＲＢ）
図８はファンクション＝０ＨのライトコマンドＯＲＢを示している。
このコマンドは、指定したバッファ内のデータをイニシエータからターゲットに渡すためのコマンドである。ファンクションフィールドの値は０Ｈである。“ｔ”（タグ）ビット３０７はデータタグを表している。
【００７３】
（リードコマンドＯＲＢ）
図９はファンクション＝４０ＨのリードコマンドＯＲＢを示している。
【００７４】
このコマンドは、イニシエータがターゲットからデータを読み出すためのコマンドである。ファンクションフィールドの値は４０Ｈである。
【００７５】
（コネクトコマンドＯＲＢ）
図１０はファンクション＝Ｃ１ＨのコネクトコマンドＯＲＢを示している。このコマンドは、“ＱｕｅｕｅＩＤ”が０のコネクションサービス用参照キューに対して発行され、新たな接続を開き、その接続に用いる参照キューのＩＤを取得する為に用いられる。“Ｓｅｒｖｉｃｅ＿ＩＤ”フィールド３０９ａには新たな接続先のサービスのＩＤを指定する。“Ｍｏｄｅ”フィールド３０９ｂには接続が全二重双方向、片方向、半二重双方向のいずれかを指定する。
【００７６】
“ｉ”ビット３０９ｅはイニシエータがターゲットにプリフェッチプールの増加を要求するとき１にする。
【００７７】
（ディスコネクトコマンドＯＲＢ）
図１１はファンクション＝Ｃ２ＨのディスコネクトコマンドＯＲＢを示している。このコマンドは前記コネクトコマンドＯＲＢにより、開かれた接続を閉じるのに用いる。このコマンドは閉じようとしている参照キューに対して発行しても良いし、“ＱｕｅｕｅＩＤ”が０のコネクションサービス用参照キューに対して発行してもよい。“ＱｕｅｕｅＩＤ”が０のコネクションサービス用参照キューに対して発行した場合には、“ＱｕｅｕｅＩＤ１”，“ＱｕｅｕｅＩＤ２”フィールド３０９ｃ，３０９ｄで指定された参照キューに対する接続が閉じる。接続に１つの参照キューのみを使用している場合は、“ＱｕｅｕｅＩＤ２”フィールドには０を指定する。
【００７８】
（クエリーコマンドＯＲＢ）
図１２はファンクション＝Ｃ０ＨのクエリーコマンドＯＲＢを示している。このコマンドはログイン後通信に先立ってターゲットからプリフェッチプールの容量を獲得するのに用いる。
【００７９】
（ステータスブロック）
図１３は、ターゲットからイニシエータに返されるステータスの形式及びその内容を示している。図１３において、点線よりも上のフィールドはＳＢＰ−２で規定されたフィールドであるため、特に説明をしない。タグフィールド４０４はデータタグを表しており、リードコマンドＯＲＢに対するステータスでのみ有効である。
【００８０】
“ＳＨＰＴ２＿ｓｔａｔｕｓ１”及び“ＳＨＰＴ２＿ｓｔａｔｕｓ２”（ＳＨＰＴ−２ステータス）フィールドはコマンドＯＲＢの実行結果ステータスを示すフィールドで０以外でエラーを表わす。すなわち、値が０であれば、そのステータス対応するコマンドＯＲＢについての処理は完了したことを示す。例えば、対応するコマンドＯＲＢがライトコマンドであれば、ＳＨＰＴ−２ステータスが０のステータスブロックは、対応するライトコマンドＯＲＢで差し示されたバッファから、ターゲットがデータを全て読み出し、ターゲットの持つバッファに書き込み終えたことを意味する。また、値が０以外であれば、対応するコマンドＯＲＢの処理はエラーにより一部或いは全部が行われなかったことを示す。このエラーを受けたイニシエータは、クライアントにエラーである旨知らせるなどしてエラーに対応する。
【００８１】
“ｒｅｓｉｄｕａｌ”（残余）フィールド４０６は、ＯＲＢで指し示されたバッファに対して処理されたデータ長を除いた残余データ長を示す。
【００８２】
（コネクトステータスブロック）
図１４は、ファンクション＝Ｃ１ＨのコネクトコマンドＯＲＢに対するステータスブロックであり、コネクトコマンド終了時に対してターゲットからイニシエータに渡される。新規接続に用いる参照キューのＩＤは“ＱｕｅｕｅＩＤ１”フィールド４０７ａ及び“ＱｕｅｕｅＩＤ２”フィールド４０７ｂに示される。コネクトコマンドＯＲＢの“Ｍｏｄｅ”フィールドが片方向の場合は“ＱｕｅｕｅＩＤ２”には０が返され、半二重の場合には“ＱｕｅｕｅＩＤ１”、“ＱｕｅｕｅＩＤ２”は同じＩＤが返され、双方向の場合には“ＱｕｅｕｅＩＤ１”、“ＱｕｅｕｅＩＤ２”には異なるＩＤが返される。“ＰＯＯＬ＿Ｉｎｃ”フィールド４０７ｃはターゲットのプリフェッチプールの容量増加分を示す。
【００８３】
（クエリーステータスブロック）
図１５は、ファンクション＝Ｃ０ＨのクエリーコマンドＯＲＢに対するステータスブロックであり、クエリーコマンド終了時に対してターゲットからイニシエータに渡される。”Ｉｎｉｔ＿ＰＯＯＬ”フィールド４０７ｄにはターゲットのプリフェッチプールの容量が返される。
【００８４】
＜ＯＲＢの管理＞
次に、以上説明したイニシエータ及びターゲットの構成や、コマンドＯＲＢ及びステータスブロックの構成に基づいて、ＯＲＢがどのように用いられているか説明する。
【００８５】
図１、図２を用いて、イニシエータ、ターゲット及び各クライアント間におけるコマンドの流れを説明する。ここでは、要求キューＡ２０２ａ及び参照キューＡ１０５ａがイニシエータ側からターゲット側へのデータ転送に使われ、要求キューＢ２０２ｂ及び参照キューＢ１０５ｂがターゲット側からイニシエータ側へのデータ転送に使われるとして説明する。
【００８６】
イニシエータのクライアントからデータ転送要求が発生すると、クライアントはターゲットに渡すデータを格納したバッファのアドレス及びサイズを含むライトコマンドを、Ｉ／Ｏ要求キューＡ２０２ａの末尾につける。
【００８７】
ＳＨＰＴ−２処理部２０１では、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数がＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数以上かどうかをチェックし、予約域の数以下であれば、そのライトコマンドからＯＲＢを生成してＯＲＢリスト２０４の末尾にリンクし、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を１増やす。ＯＲＢリスト内での個数が予約域の数以上であれば、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタ２０３ｅをチェックし空がある、すなわち０でなければそのライトコマンドからＯＲＢを生成してＯＲＢリスト２０４の末尾にリンクし、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を１増やすとともにＣｕｒｒｅｎｔ−ＰＯＯＬカウンタを１減ずる。
【００８８】
Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタ２０３ｅをチェックし空がなければ空を待つ。図２の状態では、要求キューＡから既に３つのＯＲＢがリンクされていて、予約域１以上になっているが、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタは３であるから、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタを２に減じ、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタのＯＲＢリスト内での個数を４に増やして、要求キューで待っていたライト要求Ｑａ−４に対するＯＲＢをＯＲＢリストに追加できる。なお、ＯＲＢが生成されてもそれに対応するライトコマンドはＩ／Ｏ要求キューから削除されず、ターゲットからの完了ステータスを受けた時点で削除される。
【００８９】
ＳＨＰＴ処理部２０１は、ＯＲＢをＯＲＢリストに入れると、１３９４インターフェースを介してターゲットのドアベル１０１ａに書き込む、あるいは、ＯＲＢポインタ１０１ｂに新たなＯＲＢのアドレスを書き込む。
【００９０】
ディスパッチャ１０２は、空参照リスト１０４からポインタを取り出し、ポインタの指し示すプリフェッチプール１０３の空領域にそのＯＲＢのコマンドを格納し、当該ＯＲＢのＱｕｅｕｅＩＤフィールド（この場合は参照キューＡ１０５ａを示している）にしたがって参照キューの末尾にポインタを接続する。実行エージェント１０６は、参照キューで参照されるプリフェッチプール内のコマンドを順次実行する。すなわち、ターゲットのクライアントの用意したバッファに、ライトコマンドで示されるバッファの内容を書き込む。実行エージェントは、コマンドの処理が完了すると、ＳＨＰＴ−２ステータスが「完了」であるステータスブロックをイニシエータのステータスＦＩＦＯ２０５に書き込む。
【００９１】
ＳＨＰＴ−２処理部２０１は、ステータスＦＩＦＯに入れられたステータスブロックを先頭から処理する。すなわち、ＳＨＰＴ−２ステータスが「完了」であれば、そのステータスブロックに対応するＯＲＢをＯＲＢリストから外し、それとともにＩ／Ｏ要求キュー内の対応するライトコマンドを削除する。この時、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタ２０３ａが示すそのＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数がＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数を超えているかどうかをチェックし、超えていなければ、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタ２０３ａが示す現在のＯＲＢリスト内での個数を１減ずる。ＯＲＢリスト内での個数が予約域の数超えている場合には、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタ２０３ｅを１増やし、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタ２０３ａが示す現在のＯＲＢリスト内での個数を１減ずる。
【００９２】
以上の手順は、リードコマンドについても全く同様である。ただし、リードコマンドは、ターゲットにおいてリードすべきデータが発生しない限り処理されない。従って、イニシエータから発行されたリードコマンドＯＲＢは、リードすべきデータが発生するまでプリフェッチプール１０３に格納され参照キューＢ１０５ｂにキューイングされたままということになる。
【００９３】
イニシエータがホストコンピュータ、ターゲットがプリンタである場合、ホストコンピュータからプリンタに印刷データを渡すためには、上述のライトコマンドを用いて、イニシエータのクライアントであるプリンタドライバから、ターゲットのクライアントであるラスタライザに印刷データが渡される。また、ホストコンピュータがプリンタの構成や状態を示す情報を要求する場合には、その旨のコマンド（クライアントレベルのコマンド）をプリンタにライトコマンドで渡す。それを受けたプリンタ（のクライアント）は、プリフェッチプールに格納され、参照キューにキューイングされているリードコマンドを用いて、ホストコンピュータに要求されたデータを渡す。さらに、プリンタでエラーが発生したような場合には、プリンタのクライアントは、プリフェッチプールに格納され、参照キューにキューイングされているリードコマンドを用いて、自発的にエラー情報をホストコンピュータに渡すことができる。このため、ホストコンピュータはプリンタと接続している間は、運用上少なくとも１つのリードＯＲＢをプリンタに対して発行しておく。さらに、リードコマンドを常時プリフェッチプールに格納させ、参照キューにキューイングさせておくためには、少なくとも２つのリードＯＲＢをプリンタに対して発行しておくことが望ましい。
【００９４】
図２のＯＲＢリスト２０４は必ずしも先頭から順にＯＲＢが削除されていくとは限らない。例えば、参照キューＢ１０５ｂに向けられたＯＲＢＴ４（コマンドＱｂ−１）は参照キューＡ１０５ａに向けられたＯＲＢＴ３（コマンドＱａ−２）よりも先に完了し削除されることもある。このため、ＯＲＢＴ３（コマンドＱａ−２）のリンク先はなくなる。この場合、ＯＲＢＴ３（コマンドＱａ−２）及びＯＲＢＴ５（コマンドＱａ−３）へのポインタはＯＲＢＴ４（コマンドＱｂ−１）処理時にターゲットに既に渡っているため、ＯＲＢリスト上でリンク先をつなぎなおす必用はない。また、エラー等でＯＲＢリストがクリアされても、Ｉ／Ｏ要求キューには対応コマンドが残っているため、後述するエラー復旧処理も正常に行うことができる。
【００９５】
＜エラーの復旧（イニシエータ）＞
既に説明したように、ＳＢＰ−２では、ネットワークに異常（エラー）に起因するバスリセットにより、イニシエータとターゲットとの間の接続は断たれてしまう。そこで、ＳＨＰＴ−２では、バスリセットにより失われた状態を復旧するための手順を定めている。
【００９６】
イニシエータはネットワーク上のエラーなどからバスリセットが発生後、バスリセットの処理が終えたなら、ＳＢＰ−２の規定に従い全てのＯＲＢをＯＲＢリストから消去する。各Ｉ／Ｏ要求キューは、バスリセットがあってもリセットされることはない。
【００９７】
イニシエータは、コネクションを再設定した後、Ｉ／Ｏ要求キューを参照して、それらキューの内容から新たにＯＲＢを生成し、ターゲットに対して発行する。このとき、ＯＲＢの生成時に対応するコマンドに対して割り当てられていた”Ｓｅｑ＿ＩＤ”フィールドの値を再度指定することにより、バスリセット直前の状態を再現することができる。
【００９８】
＜エラーの復旧（ターゲット）＞
イニシエータはＯＲＢリストを復旧させるだけでその状態をバスリセット直前の状態に戻せるが、ターゲットはリード／ライトのコマンドに応じてバッファに対してリード／ライトを行うため、リード／ライト中にバスリセットが発生した場合には、復旧後はその続きを行わねばならない。そのために、ターゲットの実行エージェントは、各参照キューで参照されるそれぞれの処理中のコマンドの”Ｓｅｑ＿ＩＤ”フィールドと、その処理中のバッファの位置を各参照キュー毎に記憶している。
【００９９】
例えば、イニシエータがリードＯＲＢを発行し、ターゲットはそれを実行エージェントによって処理する場合、実行前に、実行エージェント１０６はこれから処理するリードコマンドＯＲＢのｓｅｑ＿ＩＤフィールドを読み出し、シーケンス識別子（Ｓｅｑｕｅｎｃｅｉｄｅｎｔｉｆｉｅｒ）として記憶しておく。また、クライアントのバッファにデータを書き込むに当たり、現在書き込んでいるバッファのアドレスを実行ポインタ（Ｎｅｘｔｅｘｅｃｐｏｉｎｔｅｒ）として更新しつづける。これらの領域はバスリセットによって消去されないメモリ領域に確保される。
【０１００】
バスリセットが終了したなら、イニシエータはＯＲＢを改めて発行してくるため、実行エージェントは、プリフェッチプールに格納され、参照キューの先頭で参照されるＯＲＢのｓｅｑ＿ＩＤフィールドが、記憶されているシーケンス識別子よりも古ければ、そのＯＲＢは既に処理は完了しているために、完了ステータスを返す。両者が一致すれば、Ｎｅｘｔｅｘｅｃｐｏｉｎｔｅｒで示されるアドレスから書き込みを続行する。
【０１０１】
ライトコマンドについても同じ要領で復旧される。
【０１０２】
以上、本実施形態の印刷システムにおいて用いられるコマンドおよびステータスについて説明した。次に、イニシエータおよびターゲットにおけるコマンド及びステータスの処理手順を説明する。
【０１０３】
＜イニシエータのクライアントによるデータ転送要求＞
図３は、イニシエータのクライアントであるプリンタドライバ等から、ターゲットに対して、データを送信あるいは要求する際の手順を示している。
【０１０４】
データ転送事項が発生したなら（ステップＳ１３０１）、そのために必用なコマンドがライトであるかリードであるか判定し（ステップＳ１３０２）、ライトならばそのためのデータ転送バッファがあるか調べ（ステップＳ１３０３）、また、ターゲットに渡すべき送信データの準備ができているか調べて（ステップＳ１３０４）、すべて準備できていれば、バッファのアドレスやサイズ等、必用な引き数を与えてライトコマンドを作成し（ステップＳ１３０５）、ライト関数をコールする（ステップＳ１３０６）。
【０１０５】
一方、リードコマンドであると判定されれば、データを受けるための転送バッファがあるか調べ（ステップＳ１３０７）、あればバッファのアドレスやサイズ等、必用な引き数を与えてリードコマンドを作成し（ステップＳ１３０８）、リード関数をコールする（ステップＳ１３０９）。
【０１０６】
例えば、データ転送事項がプリンタに対する印刷データの送信ならば、ＰＤＬなど、クライアントレベルのコマンドやデータをバッファに用意し、ライトコマンドを作成することになるし、データ転送事項がプリンタからの状態の読み出しであれば、その旨を示すクライアントレベルのコマンドを用意してライトコマンドを作成するとともに、ターゲットからデータを受けるためのリードコマンドを作成する必用がある。また、ターゲットとの一連のデータ交換を行うに先立って、イニシエータのクライアントはリードコマンドを幾つか発行する。
【０１０７】
図４は、イニシエータのクライアントが下位すなわちＳＨＰＴ−２の層から処理終了通知を受けた際の処理手順である。まず、終了した処理がリードかライトか判定し（ステップＳ１４０１）、ライトであれば使用したデータバッファを解放する（ステップＳ１４０２）。一方、リードであれば、処理の終了はデータの受信の完了であるから、受信したデータに対応した処理を行い（ステップＳ１４０３）、データバッファを解放する（ステップＳ１４０４）。
【０１０８】
＜イニシエータのＳＨＰＴ処理部による処理＞
図５〜図６は、イニシエータのＳＨＰＴ−２処理部による処理手順である。
【０１０９】
図５（Ａ）及び（Ｂ）は、それぞれクライアントがコールするライト関数及びリード関数の内容を示す。ライト関数では、そのクライアントが接続要求を出しコネクトした時にクライアントに対してＳＨＰＴ−２部が与えたコネクトハンドルが引数として渡され、そのコネクトハンドルに該当するＩ／Ｏ要求キューのＩＤに基づき、そのＩ／Ｏ要求キューにライトコマンドを追加する。リード関数も同様に、そのクライアントが接続要求を出しコネクトした時にクライアントに対してＳＨＰＴ−２部が与えたコネクトハンドルが引数として渡され、そのコネクトハンドルに該当するＩ／Ｏ要求キューのＩＤに基づき、そのＩ／Ｏ要求キューにリードコマンドを追加する。それぞれのＩ／Ｏ要求キューにキューイングされたコマンドは、後にターゲット側でコネクトコマンドのステータスで与えられた“ＱｕｅｕｅＩＤ１”，“ＱｕｅｕｅＩＤ２”で示される参照キューへそれぞれ送られることになる。
【０１１０】
（Ｉ／Ｏ要求キュー管理）
図５（Ｃ）は各Ｉ／Ｏ要求キューの管理手順を示す。これらの手順は、各Ｉ／Ｏ要求キューごとに単独のスレッドでスレッドスケジュールによって独立に行われてもよいし、すべてのＩ／Ｏ要求キューをひとつのスレッド内で管理が他のＩ／Ｏ要求キューの動作によってブロックされないように独立スケジュールすることで実行してもよいし、またこれらの組み合わせであってもよい。図５（Ｃ）は１つのＩ／Ｏ要求キューの管理を示すものである。Ｉ／Ｏ要求キューの管理は各Ｉ／Ｏ要求キュー毎に行う。
【０１１１】
まず、Ｉ／Ｏ要求キュー内にＯＲＢ化されていないコマンドがあるか調べる（ステップＳ１６０１）。あれば、このＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を示すカウンタＣｕｒｒｅｎｔ−ＱＵＥがこのＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数より小さいか判定する（ステップＳ１６０２）。小さければＳ１６０５に進み、大きいか等しければＳ１６０４に進む。Ｓ１６０４では、プリフェッチプールに対するＣｕｒｒｅｎｔ−ＰＯＯＬカウンタが０より大きければＣｕｒｒｅｎｔ−ＰＯＯＬカウンタを１減じる。次にＳ１６０５でＣｕｒｒｅｎｔ−ＱＵＥの値に１を加え（ステップＳ１６０５）、Ｉ／Ｏ要求キューに格納されている、ＯＲＢ化されていない先頭のコマンドを基に、シーケンスＩＤ（Ｓｅｑ＿ＩＤ）やＳＨＰＴ−２コマンド（Ｆｕｎｃｔｉｏｎ）を付加して、ＯＲＢを作成する（ステップＳ１６０６）。
【０１１２】
こうして作成したＯＲＢをＯＲＢリストにつけ（ステップＳ１６０７）、ターゲットのドアベルに書き込む、あるいは、ＯＲＢポインタにＯＲＢのアドレスを書き込む（ステップＳ１６０８）。このようにして、Ｉ／Ｏ要求キュー内のコマンドからＯＲＢが作成される。
【０１１３】
（ステータスブロックに対する処理）
図６は、ステータスブロックをターゲットから受けた際の処理手順である。ＯＲＢに対する処理完了のステータスブロックを受けると、対応するＯＲＢをＯＲＢリストから削除し（ステップＳ１７０１）、対応ＯＲＢに対するコマンドがキューイングされているＩ／Ｏ要求キューを選択する（ステップＳ１７０２）。選択したＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を示すカウンタＣｕｒｒｅｎｔ−ＱＵＥがこのＩ／Ｏ要求キューに割り当てられたプリフェッチプール内における予約域の数以下であるかを判定し、以下であるならばＳ１７０４に進む。そうでなければ、Ｓ１７０４に進む（Ｓ１７０３）。Ｓ１７０４では、プリフェッチプールに対するＣｕｒｒｅｎｔ−ＰＯＯＬカウンタを１増やす。次にＳ１７０５で選択したＩ／Ｏ要求キューに属するコマンドの現在のＯＲＢリスト内での個数を示すカウンタＣｕｒｒｅｎｔ−ＱＵＥを１減ずる。最後に、選択されたＩ／Ｏ要求キューに対応するクライアントに処理の終了を通知する（ステップＳ１７０６）。クライアントはこれを受けて、図４の処理を行うことになる。
【０１１４】
（エラー復旧処理）
ＳＨＰＴ−２処理部における通常の処理は以上のとおりである。次にバスリセット後などに復旧する手順を図１８により説明する。バスリセットが生じてターゲットとのＳＢＰ−２コネクションが切断されてしまった場合、あらためてＳＢＰ−２コネクションの再設定から行わねばならない。
【０１１５】
まず、新規のＯＲＢのリンク処理を中断し（ステップＳ１８０１）、ＯＲＢリストを破棄する（ステップＳ１８０２）。この後  ＳＢＰ−２コネクションの再接続命令を出して（ステップＳ１８０３）、コネクションの確立を調べ（ステップＳ１８０４）、コネクションが再度張られたなら、各Ｉ／Ｏ要求キューの先頭のコマンドから順に対応するＯＲＢを作成する（ステップＳ１８０５）。このとき、各ＯＲＢの”Ｓｅｑ＿ＩＤ”フィールドは、そのコマンドに対してバスリセット前に付与されていたのと同一のＩＤを付与する。作成されたＯＲＢはＯＲＢリストにリンクされ（ステップＳ１８０６）、ＯＲＢポインタにアドレスを書き込んで（ステップＳ１８０７）、ターゲットにＯＲＢの発生を知らせる。
【０１１６】
一方、コネクションが再設定できないまま一定時間経過すると（ステップＳ１８０８）、各Ｉ／Ｏ要求キュー内のコマンドをすべて破棄し（ステップＳ１８０９）、異常である旨をクライアントに知らせて（ステップＳ１８１０）、処理を終える。以上の手順により、リセット後に、あらためてターゲットとのＳＢＰ−２コネクションを確立し、リセット直前のＯＲＢリストを復旧することができる。
【０１１７】
＜ターゲットによる処理＞
図１９〜２０は、ＯＲＢを受けたターゲットによる処理手順である。
【０１１８】
（フェッチエージェントによる処理）
フェッチエージェントは１つのＳＢＰ−２コネクションに対して１つ用意される。フェッチエージェントはドアベルレジスタあるいはＯＲＢポインタに書き込みがあるとＯＲＢをフェッチする。まず、ドアベルレジスタあるいはＯＲＢポインタに書き込みが行われるまで待ち（ステップＳ１９０１）、書き込みがあると、ドアベルレジスタへの書き込みにより起動されたか判定し（ステップＳ１９０２）、そうでなく、ＯＲＢポインタへの書き込みにより起動されたのであればステップＳ１９０３に進む。一方、ドアベルへの書き込みがあったならば、ＯＲＢポインタで指されているＯＲＢの”Ｎｅｘｔ＿ＯＲＢ”フィールドがＮＵＬＬ（後続ＯＲＢ無し）かどうかをテストする（ステップＳ１９０７）。ＮＵＬＬであればステップＳ１９０１に戻る。
【０１１９】
ＮＵＬＬでなければ、ステップＳ１９０８へと進み、現在のＯＲＢポインタで指されているＯＲＢのＮｅｘｔ＿ＯＲＢフィールドの値を、ＯＲＢポインタへと書き込み更新し（ステップＳ１９０８）、ステップＳ１９０３へ進む。
【０１２０】
こうしてＯＲＢポインタに処理すべきＯＲＢのアドレスが得られたなら、そのアドレスからＯＲＢを読み出す（ステップＳ１９０３）。空参照リストからプリフェッチプール内の空領域を指し示すポインタを取り出し、読み出したコマンドＯＲＢをその空領域に格納する（ステップＳ１９０５）。
【０１２１】
またそのＯＲＢの”ＱｕｅｕｅＩＤ”フィールドを参照してコマンドをキューすべき参照キューを選択し（ステップＳ１９０５）、選択した参照キューの末尾に空参照リストから取り出したポインタをキューする（ステップＳ１９０６）。
【０１２２】
この後、キュー処理を終えたＯＲＢのＮｅｘｔ＿ＯＲＢフィールドを参照して、その内容がＮＵＬＬ、すなわちリンクされているＯＲＢがなければ、Ｓ１９０１に戻り次のＯＲＢがリンクされ、ドアベルあるいはＯＲＢポインタへ書き込みがあるまで待つ。一方、リンクされているＯＲＢがあれば、ＯＲＢポインタで指されているＯＲＢのＮｅｘｔ＿ＯＲＢフィールドの値を、ＯＲＢポインタに書き込み更新し（ステップＳ１９０８）、ＯＲＢリストにリンクされているＯＲＢを順次プリフェッチプールに格納していく。
【０１２３】
このようにして、ＯＲＢリストのＯＲＢをプリフェッチプールにいれる。
【０１２４】
また、ステップＳ１９０４〜Ｓ１９０６の処理は、図１においてＯＲＢディスパッチャとして説明した処理である。
【０１２５】
（実行エージェント）
図２０は各参照キューに対する実行エージェントの手順を示す。これらの手順は、各参照キューごとに単独のスレッドでスレッドスケジュールによって独立に行われてもよいし、すべての参照キューをひとつのスレッド内で管理が他の参照キューの動作によってブロックされないように独立スケジュールすることで実行してもよいし、またこれらの組み合わせであってもよい。図２０は１つの参照キューに対する実行エージェントの手順を示すものである。各参照キューに対する実行エージェントの手順は各参照キュー毎に行う。
【０１２６】
実行エージェントは、まず参照キューにプリフェッチプール内のコマンドへのポインタがあるか調べ（ステップＳ２００１）、ＯＲＢをプリフェッチプールから取り出す（ステップＳ２００２）。これらは参照キューの先頭を指し示すポインタを用いることにより行う。ＯＲＢを読み出すと、そのＯＲＢのＳｅｑ＿ＩＤフィールドの値が、実行エージェントが保持する変数ＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒよりも小さい値であるか判定する（ステップＳ２００３）。ただし、Ｓｅｑ＿ＩＤ及びＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒはともに有限の桁数である。そこで、Ｓｅｑ＿ＩＤ及びＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒがともにｎビットで表わされる場合、ステップＳ２００３における比較では、（（２のｎ乗−１）＜０（＝２のｎ乗））と定めておく。
【０１２７】
通常のシーケンスであれば、ひとつのＯＲＢの処理終了後、ＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒには後述のように１加算される。また、ＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒとＯＲＢのＳｅｑ＿ＩＤは同じ桁数であり、Ｓｅｑ＿ＩＤも１ずつ加算される。そのため、支障なく処理が進んでいる場合には、ＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒとＯＲＢのＳｅｑ＿ＩＤとは、ステップＳ２００３において一致しているはずである。したがって、正常に処理が進めば、処理はステップＳ２００３からステップＳ２００４に移行する。
【０１２８】
そこでは、クライアントがバッファを用意してあるか調べ（ステップＳ２００４）、用意できたなら、ＯＲＢのｄａｔａ＿ｄｅｓｃｒｉｐｔｏｒの値と実行エージェントが保持するＮｅｘｔｅｘｅｃＰｏｉｎｔｅｒに格納されたｏｆｆｓｅｔ値とを加えたアドレスから所定サイズのデータアクセスを行い、クライアントが用意したバッファとの間でデータをやりとりする（ステップＳ２００５）。
【０１２９】
新たにＯＲＢの処理を行う場合には、ｏｆｆｓｅｔは０であるから、ＯＲＢにより指し示されるバッファの先頭から読み出すことになる。また、途中まで読み出されているバッファを続きから読む場合には、ｏｆｆｓｅｔは、バッファ中における続きのアドレスを示しているので、これを加算することで続きから読み出しを続行できる。データをバッファに格納したなら、ｄａｔａ＿ｄｅｓｃｒｉｐｔｏｒの値＋ｏｆｆｓｅｔが次に読み出されるアドレスを指すように、ＮｅｘｔｅｘｅｃＰｏｉｎｔｅｒを更新する（ステップＳ２００６）。このような読み書きを、ＯＲＢのｄａｔａ＿ｓｉｚｅで示されるサイズ分に達するまで行う（ステップＳ２００７）。
【０１３０】
こうして１つのＯＲＢの処理を終えると、ＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒに１加算して更新し（ステップＳ２００８）、ＮｅｘｔｅｘｅｃＰｏｉｎｔｅｒ（ｏｆｆｓｅｔ）を０に初期化する（ステップＳ２００９）。
【０１３１】
処理を終えたなら、処理完了を通知するステータスブロックを作成し（ステップＳ２０１０）、ステータスＦＩＦＯに書き込み（ステップＳ２０１１）、ターゲットのクライアントに処理完了を通知する（ステップＳ２０１２）。それと同時に当該コマンドを指していた参照キュー内のポインタを空参照リストに戻す。
【０１３２】
ステップＳ２００３において、ＯＲＢのＳｅｑ＿ＩＤがＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒよりも小さい場合は、バスリセットなどにより、イニシエータが図１８の手順でＯＲＢリストを再生したような場合である。例えば、あるＯＲＢについて、ターゲットは処理を終え、ＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒの値も更新していても、そのステータスブロックがイニシエータに届いていない時点でバスリセットが発生すると、イニシエータはそのＯＲＢもＯＲＢリストに入れてしまう。この場合に、ＯＲＢのＳｅｑ＿ＩＤよりも実行エージェントのＳｅｑｕｅｎｃｅＩｄｅｎｔｉｆｉｅｒの方が大きくなる。この場合には、そのＯＲＢは処理を終えているため、ステップＳ２０１０以降によりステータスブロックをイニシエータに渡す。
【０１３３】
＜イニシエータの接続手順＞
図１６はイニシエータ側のクライアントからのオープン要求に対する処理手順を示したものである。クライアントからのオープン要求を受けると、まず、接続先のターゲットとの間に既にＳＢＰ−２のコネクション（ログイン状態）があるか否かを確認する（ステップＳ２５０１）。既にＳＢＰ−２コネクションがあれば、ステップＳ２５０７へ進み、まだＳＢＰ−２コネクションがなければ、ターゲットに対してログイン要求（ＳＢＰ−２コネクト要求）を発行する（ステップＳ２５０２）。ログインが成功したかどうかを確認し（Ｓ２５０３）、ログインに失敗した場合はステップＳ２５１３に進み戻り値にエラーコードをセットしてリターンし、ログインに成功した場合は、ＱｕｅｕｅＩＤが０のＩ／Ｏ要求キューを作成し、そこにクエリーコマンドを発行する（ステップＳ２５０４）。次にクエリーコマンドが成功したか否かを確認し（ステップＳ２５０５）、失敗ならステップＳ２５１２へ進み、ログアウト実行後Ｓ２５１３へと進む。クエリーコマンドが成功したら、クエリーコマンドに対するステータスブロックの”Ｉｎｉｔ＿ＰＯＯＬ”を元にＣｕｒｒｅｎｔ−ＰＯＯＬカウンタをセットする。この時既にＱｕｅｕｅＩＤが０に対応するＩ／Ｏ要求キューは暗黙に形成されているので、ＱｕｅｕｅＩＤが０に対応するＩ／Ｏ要求キューの予約域として１以上をセットし、残りをＣｕｒｒｅｎｔ−ＰＯＯＬカウンタにセットする（ステップＳ２５０６）。
【０１３４】
さらに、ステップＳ２５０７へ進んでＱｕｅｕｅＩＤが０に対応するＩ／Ｏ要求キューに対して所望のＳｅｒｖｉｃｅＩＤ，Ｍｏｄｅを指定し、コネクトコマンドをキューする（ステップＳ２５０７）。コネクト時、ターゲットに対して、プリフェッチプールの増量を求める場合は”ｉ”ビットを１にセットする。次にコネクトコマンドが成功したか否かを確認し（ステップＳ２５０８）、失敗であれば、ステップＳ２５１１で暗黙に用意されるＱｕｅｕｅＩＤ０以外で既に他のＩ／Ｏ要求キューが存在しているかどうかを確認し、存在していなければターゲットからログアウトし（ステップＳ２５１２）、Ｓ２５１３に進み、存在していれば、ログアウトせずにＳ２５１３に進む。一方、コネクトコマンドが成功するとステータスブロックのＱｕｅｕｅＩＤ１，ＱｕｅｕｅＩＤ２に対応して、新しいＩ／Ｏ要求キューを作成し、後にクライアントがこのコネクションを特定する為のハンドルを対応付ける。また、ステータスブロックのＰＯＯＬ＿Ｉｎｃフィールドと現在のＣｕｒｒｅｎｔ−ＰＯＯＬレジスタの合計から、各キューに対して１以上の予約域をセットし、残りの数でＣｕｒｒｅｎｔ−ＰＯＯＬレジスタを更新する（ステップＳ２５０９）。最後に作成されたＩ／Ｏ要求キューに対応させたハンドルを戻り値にセットし（ステップＳ２５１０）呼び出し元のクライアントにリターンする。
【０１３５】
＜ターゲットの接続手順＞
図１７は、図１６のイニシエータ側のクライアントからのオープン要求に対する処理手順に対応するターゲット側の処理手順を示したものである。
【０１３６】
まず、ターゲットはログイン要求が来るのを待つ（ステップＳ２６０１）。
【０１３７】
ログイン要求が来るとターゲットはＳＢＰ−２に規定された動作であるイニシエータのＩＤの確認、ログインディスクリプタの作成等を行うとともに、少なくとも１つのエントリを持ったプリフェッチプールを作成し、プリフェッチプール内のそれぞれのエントリに対するポインタのリストである空参照リストを作成する。また、ＱｕｅｕｅＩＤが０の参照キューの為のポインタ等も用意する（ステップ２６０２）。これらの準備が整ったら、ターゲットはイニシエータにＳＢＰ−２で規定されているログインレスポンスを返す（ステップ２６０３）。次にターゲットはクエリーコマンドが来るのを待つ（ステップ２６０４）。クエリーコマンドが来たら、作成したプリフェッチプールのサイズを”Ｉｎｉｔ＿ＰＯＯＬ”フィールドに入れてクエリーコマンドに対するステータスブロックを送出する（ステップＳ２６０５）。ここまででＳＨＰＴ−２による通信の準備が出来たことになる。
【０１３８】
以降２６１０以下のループはＱｕｅｕｅＩＤ０の参照キューに基づく実行エージェントの処理手順となる。Ｓ２６０６でコマンドがコネクトコマンドか否かを確認する。コネクトコマンドでなければＳ２６０９でそのコマンドの処理を行い２６１０へ戻る。コネクトコマンドであれば、Ｍｏｄｅフィールドで指定されたモードにしたがって１つ或いは２つの参照キューの為のポインタ等を作成する。この時、コネクトコマンドの”ｉ”ビットが１であれば、作成した参照キューの数以上の数のエントリをプリフェッチキューに追加し（ステップＳ２６０７）、作成した参照キューのＩＤ及びプリフェッチキューに追加したエントリ数をコネクトコマンドに対するステータスブロックでイニシエータに返す（ステップＳ２６０８）。この後から作成された参照キューを用いて  クライアント間の通信が可能となる。
【０１３９】
この図１６及び図１７におけるイニシエータとターゲットそれぞれのオープン処理により、イニシエータにおいては要求キューが、ターゲットにおいては参照キューが作成でき、それらの間にパスが設定される。なお、図１６及び図１７の手順は、ログイン時に作成されるマネジメントパス（マネジメント要求キュー及びマネジメント参照キューの対）の設定時にも用いられる。
【０１４０】
＜イニシエータの接続終了手順＞
図２１はイニシエータ側のクライアントからのクローズ要求に対する処理手順を示したものである。クローズ要求があると、まず、ディスコネクトコマンドを発行する。該当するＱｕｅｕｅＩＤのＩ／Ｏ要求キューに既にキューイングされているコマンドを終了してからディスコネクトしたい場合にはディスコネクトコマンドのＱｕｅｕｅＩＤフィールドを当該ＱｕｅｕｅＩＤにし、キューイングされているコマンドにかかわらずディスコネクトしたい場合は、ＱｕｅｕｅＩＤ０にディスコネクトコマンドを発行する。この場合、ＱｕｅｕｅＩＤ１，ＱｕｅｕｅＩＤ２フィールドでディスコネクトするキューを指定する（ステップＳ２７０１）。次にディスコネクトコマンドが完了するのを待ち（ステップＳ２７０２）、完了後、もし現在のＯＲＢリストの中にディスコネクトしたキューに対するＯＲＢが残っていればそれらをＳＢＰ−２の規定する制御フィールドによって全て無効化し、コネクト時に作成されたＩ／Ｏ要求キューを開放するとともに、そのＩ／Ｏ要求キューのＣｕｒｒｅｎｔ−ＱＵＥカウンタで示されていた現在のＯＲＢリスト内のＯＲＢ数分Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタを増やし、さらにコネクト時に受け取ったプリフェッチプールの増加分を減ずる（ステップＳ２７０３）。さらに、ステップＳ２７０４で暗黙に用意されるＱｕｅｕｅＩＤ０以外で既に他のＩ／Ｏ要求キューが存在しているかどうかを確認し、存在していなければターゲットからログアウトし（ステップＳ２７０５）、そして、コネクト時に割り当てたハンドルを開放し、リターンする。
【０１４１】
＜ターゲットの接続終了手順＞
図２２はターゲットのディスコネクト処理手順を示したものである。この手順は図１７のステップＳ２６０９に位置するものである。まず、ディスコネクトコマンドかどうかを判定し（ステップＳ２８０１）、ディスコネクトコマンドでなければさらに他のコマンドの処理（ステップ２８０７）を行う。ディスコネクトコマンドであれば、ディスコネクトの対象となる参照キューで参照されているコマンドでディスコネクトコマンド以外に実行されているコマンドがあればその実行を停止する（ステップＳ２８０２）。実行を停止した後、その参照キューで参照されているディスコネクト以外のコマンドに対するステータスブロックで未送出のものがあれば全て送出する（ステップＳ２８０３）。その後ディスコネクトコマンドに対するステータスブロックを返す（ステップＳ２８０４）。この時点で当該参照キューに残っている未処理のポインターを全て空参照リストへと戻す（ステップＳ２８０５）。コネクト時にプリフェッチプールの増加を行っていればその増加分を減少し、減少分を参照している空参照リスト内のポインタを削除する。さらに参照キューの為のポインタ等も削除し（ステップＳ２８０６）リターンする。
【０１４２】
図７に示したように、ＯＲＢにはＱｕｅｕｅＩＤというキュー識別子のフィールドを備えている。そのため、ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０１４３】
またこのＱｕｅｕｅＩＤにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０１４４】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０１４５】
＜ＫＩＬＬコマンド＞
上述したように、ＳＨＰＴ−２により、イニシエータとターゲットそれぞれのクライアント間に、マルチチャネルを設けることができる。しかしながら、このままでは、例えばターゲットのプロセスが何らかの理由で停止した場合など、そのプロセスをイニシエータに接続しているパス内のコマンドは処理されることがない。そのため、停止したプロセスに対して処理途中のコマンドを含めて発行したコマンドをまとめてキャンセルする場合など、先行して発行されたＯＲＢによりブロックされてしまいキャンセルのコマンドがターゲットのプロセスに届かず、パス単位のキャンセルは不可能となる。
【０１４６】
例えば、ターゲットとしてプリンタを想定する。プリンタで紙切れが生じるとデータの出力先がなくなるためレンダリングプロセスも停止せざるを得ない。このプリントジョブを取りやめる場合、先行して発行されている、印刷を行わせるためのライトコマンドの後にキャンセルコマンドがつながることになり、レンダリングプロセスに対してキャンセルコマンドを発行できないことになる。
【０１４７】
そこで、当該キュー以外のキュー、本実施形態ではマネジメントキューを用いて、ターゲットに対して当該キューを消滅させるためのＫＩＬＬコマンドを用意した。ＳＨＰＴ−２はＳＢＰ−２の上で動作するため、ＳＢＰ−２の取り決めに従ってＫＩＬＬコマンドの処理を行う必要がある。そのため、ＫＩＬＬコマンドに関して、イニシエータ及びターゲットはおおむね下記の通り動作する。
【０１４８】
１．イニシエータのＳＨＰＴユーザ（ＳＨＰＴ層に指示を与えるものすべてのことである）が特定の（論理）チャネルを指定してその（論理）チャネルをキャンセルするよう指示する。
【０１４９】
２．キャンセル指示を受けたキューの管理エージェントはこの時点であらたなコマンドをＯＲＢ化して発行するのを中止する。そしてマネジメントキュー管理に対して指定されたキューに対するＫＩＬＬコマンドを発行するように依頼する。
【０１５０】
３．依頼を受けたマネジメントキュー管理エージェントはＫＩＬＬコマンドのＯＲＢを作成し、消滅させるキューとして、指定されたキューＩＤを書き込む。
【０１５１】
４．マネジメントキュー管理エージェントは上記ＯＲＢを発行する。
【０１５２】
５．上記ＯＲＢのＫＩＬＬコマンドを受信したターゲットの実行エージェント（マネジメント参照キューに係る実行エージェント）は、その内容を当該キューの実行エージェントに伝達し、そしてＫＩＬＬコマンドに関するステータスブロックを格納する。
【０１５３】
６．ＫＩＬＬコマンドが発行された旨の伝達を受けた各キューの実行エージェントは、
・すでに実行が完了してかつステータスブロックを格納していないＯＲＢがあれば、格納する。
・現在実行中のＯＲＢがあれば、その時点でそのＯＲＢ（コマンド）の実行を中止し、“中断(Aborted)”のステータスを持つステータブロックを格納する。
・その時点で、当該キューの実行エージェントは切断(DISSCONNECT)コマンドを受信したときと同じようにそれ自体の実体をなくす。
【０１５４】
７．それ以降の当該キューに対するＯＲＢはＯＲＢディスパッチャが“キューＩＤエラー(queue ID error)”のステータスでステータスブロックを格納する。
【０１５５】
８．“Aborted”のステータスブロックを受信したイニシエータの当該キューのエージェントは“aborted”のステータスブロックに対応するコマンドに関しては、上位に対して中断の報告を行うとともに、対応ＯＲＢのしめるメモリを解放する。
【０１５６】
９．その“aborted”のステータスブロックに対応するＯＲＢ以降の当該キューに対するすべてのＯＲＢをキャンセルし、上位に対してそれらがキャンセルされたことを報告する。ただし、この時はＯＲＢを解放しない。そしてすべてのＯＲＢをキャンセルすると、当該キューのエージェントはそれ自体の実体をなくす。
【０１５７】
１０．ただしＳＨＰＴ層のモジュールは“queue ID error”のステータスでステータスブロックを受信したことをトリガにＯＲＢを開放する。
【０１５８】
１１．“aborted”のステータスブロックを受信した後、バスリセットが発生しても、そのキルされたキューのＯＲＢを再発行する必要がない。
【０１５９】
このようにＫＩＬＬコマンドを所望のＩ／Ｏ要求キューを対象として発行することで、未処理のコマンドが含まれているキューであっても、その要求キュー及び対応する参照キュー及びキュー管理エージェント及び実行エージェントを消滅させ、それらにより構成されているパスを消滅させることができる。
【０１６０】
なお、ＫＩＬＬコマンドのＯＲＢは、図１１に示したディスコネクトＯＲＢと同一の形式を有する。すなわち、ＱｕｅｕｅＩＤフィールドにはマネジメントキューのＩＤがセットされ、ＱｕｅｕｅＩＤ１及びＱｕｅｕｅＩＤ２には、消滅させるキューのＩＤがセットされる。また、Ｆｕｎｃｔｉｏｎフィールドには、ＫＩＬＬコマンドに対応する所定のコードがセットされる。
【０１６１】
なお、ＫＩＬＬコマンドに対するステータスブロックは、図１３に示したものと同様である。また、ＫＩＬＬコマンドによって中断されたコマンドに対するステータスは“中断(Aborted)”となる。
【０１６２】
次に、イニシエータ及びターゲットの各部の動作を、図２６〜図３０のフローチャートに示す。図２６及び図２７はイニシエータの各Ｉ／Ｏ要求キューを管理するキュー管理エージェントの動作を示し、図２８はＳＢＰ−２層のマネージャの動作を示す。図２８は、ＳＢＰ−２層において行われている処理を説明したものである。図２９は、ターゲットの実行エージェントにより処理で、図３０は、参照キューからコマンドをフェッチするフェッチエージェントの処理である。
【０１６３】
＜イニシエータのキュー管理エージェントによる処理＞
図２６，２７は、あるＩ／Ｏ要求キューのキュー管理エージェントが上位のクライアントからなんらかの要求を受けた際の処理手順である。ただし、キャンセル要求以外の要求については説明を省略してある。
キャンセル要求はユーザがなんらかのジョブのキャンセルをした場合に出される。たとえば印刷ジョブをキャンセルした場合等にそのジョブに対応するキューのキャンセル要求がクライアントからくる。
【０１６４】
まず、クライアントからの要求がキャンセル要求であるか判定し（ステップＳ２６０１）、キャンセル以外であれば要求に応じた処理を実行する（ステップＳ２６１４）。
【０１６５】
キャンセル要求の場合には、そのキューに関する要求をこれ以降受け付けないようにし（ステップＳ２６０２）、内部ステータスを「ｋｉｌｌｉｎｇ（ＫＩＬＬコマンドの処理中）」に設定する（ステップＳ２６０３）。内部ステータスが「ｋｉｌｌｉｍｇ」であれば、それ以降の要求を受け付けないようにしてもよい。その後、マネジメントキュー２０３ｆのキュー管理エージェントに対して、「ＫＩＬＬコマンド(kill queue command)」の送出を依頼する（ステップＳ２６０４）。
【０１６６】
この依頼の後は、ステップＳ２６０５でステータスブロックの受信を待つ。ステータスブロックを受信したなら、受信したステータスの内容を判定する（ステップＳ２６０６）。ＫＩＬＬコマンドが発行されて処理されると、ＫＩＬＬされるキューにすでにつながれているコマンドに対するステータスは“中断”あるいは“キューＩＤエラー”となる。従って、ステータスが正常終了であれば、このステータスはＫＩＬＬコマンド以前に発行したコマンドに対する正常終了の応答であると判断し、Ｉ／Ｏ要求キュー（コマンドキュー）から受信したステータスブロックに対応するコマンドを削除し（ステップＳ２６１５）、上位のクライアントに正常終了を報告する（ステップＳ２６１６）。この後、ＫＩＬＬコマンドに対するステータスブロックを待つ。
【０１６７】
受信したステータスブロックが正常終了でない場合、このステータスはＫＩＬＬコマンドに対する応答であると判定して、Ｉ／Ｏ要求キューからステータスに対応するコマンドを削除する（ステップＳ２６０７）。そして、上位のクライアントに正常終了でない（中断された）旨報告する（ステップＳ２６０８）。
【０１６８】
その後、ステップＳ２６１０で内部ステータスが"killing"であるか判定する。これは、ステップＳ２６０５〜Ｓ２６０９及びステップＳ２６１５〜Ｓ２６１６は、後述するアボートタスクセット(AbortTaskSet)等、他の処理と共有し得るためである。
【０１６９】
内部ステータスが"killing"の場合には、Ｉ／Ｏ要求キュー（コマンドキュー）に、ステータスブロックが未受信のコマンドがキューされているか判定する（ステップＳ２６１１）。コマンドがなければ、ＫＩＬＬコマンドにより消滅させられたキューの占有していたリソースをすべて解放し（ステップＳ２６１２）、消滅させられたキューの管理エージェント自体を消滅させる（ステップＳ２６１３）。
【０１７０】
一方、ステータスを未受信のコマンドがキューに残っている場合、このコマンドはもう実行されることはないため、キューからこのコマンドを削除し（ステップＳ２６１８）、上位のクライアントに対して未実行のまま削除した旨を通知する（ステップＳ２６１９）。
【０１７１】
以上の手順により、キャンセル要求に応じて指定されたキューに対してＫＩＬＬコマンドを発行し、ターゲットにおいてＫＩＬＬコマンドが処理されたなら、ＫＩＬＬコマンドによって消滅させられるキューに入れられた未処理のコマンドもすべてキャンセルする。
【０１７２】
＜イニシエータのＳＢＰ−２マネージャによる処理＞
図２８は、ＳＨＰＴ−２層の下に位置するＳＢＰ−２層のマネージャによる処理である。ＫＩＬＬコマンドによりある実行エージェントが削除されると、その実行エージェントで処理されるはずのコマンドに対しては、宛先のキューがないことを示すキューＩＤエラーが、フェッチエージェントからＳＢＰ−２層の応答として返される。図２８は、それを処理するための手順である。
【０１７３】
まず、ステータスブロックの受信を待つ（ステップＳ２８０１）。なお、図２８以外の図においても同様であるが、ステータスうあコマンド等を待つ処理は、本実施形態ではループで待つものとしている。しかし、待ちに入る時点でいったんそのタスクを終了し、ステータス受信の割込みによって再開するようにしてもかまわない。
【０１７４】
ステータスを受信すると、そのステータスブロックがキューＩＤエラーであるか判定する（ステップＳ２８０２）。キューＩＤエラーでなければ、そのステータスに応じた処理を行う（ステップＳ２８０６）。キューＩＤエラーであれば、このキューは存在しないため、対応するＯＲＢのメモリリソースを解放する（ステップＳ２８０３）。そして、削除され、解放されたＯＲＢの発行元、すなわちキューＩＤエラーステータスに対応するＳＨＰＴ層のキュー管理エージェントがまだ消滅していないか（アクティブか）判定し（ステップＳ２８０４）、アクティブでなければ報告する相手がいないため、何もしないで再びステータスブロックを待つ（ステップＳ２８０５）。
【０１７５】
一方、対応するエージェントがアクティブである場合、そのエージェントにキューＩＤエラーを報告する（ステップＳ２８０７）。
【０１７６】
この手順により、ターゲットにおいて、消滅した実行エージェントにより処理されるはずのコマンドに対するステータスブロックを処理できる。
【０１７７】
＜ターゲットの実行エージェントによる処理＞
ターゲットにおいて、マネジメントキューの実行エージェントからＫＩＬＬコマンドの通知を受けた各参照キューの実行エージェントは、図２９のように動作する。ＫＩＬＬコマンドの通知は割込みによって受けつけられる。
【０１７８】
まず、通知がＫＩＬＬコマンドの通知であるか判定し（ステップＳ２９０１）、そうでなければ割込み要因に合った処理を行い（ステップＳ２９０９）、ＫＩＬＬコマンドであれば、現在実行されているコマンドを直ちに中断する（ステップＳ２９０２）。
【０１７９】
その後、実行が完了しているのに、ステータスブロックを格納していないコマンドがあるか判定し（ステップＳ２９０３）、あればそのコマンドに対するステータスブロックを格納してイニシエータに返す（ステップＳ２９１０）。
【０１８０】
完了したコマンドの処理が終えたなら、処理途中で中断したコマンドに対して、“Aborted”のステータスを応答する（ステップＳ２９０４）。そして、中断されたコマンドのＯＲＢを通常の手順で解放する（ステップＳ２９０５）。そして、フェッチエージェントに対してこの実行エージェントが消滅する旨（“dead”）を通知し（ステップＳ２９０６）、この実行エージェントの占有するリソースを解放し（ステップＳ２９０７）、最後にこの実行エージェント自身を消滅させる（ステップＳ２９０８）。
【０１８１】
このようにして、ＫＩＬＬコマンドが発行されたターゲットのエージェントでは、ターゲットにおけるキュー及びコマンド及びエージェント自身を消滅させ、Abortedステータスを返すことで、これらＫＩＬＬに係る一連の処理が行われることをイニシエータに知らせる。
【０１８２】
＜ターゲットのフェッチエージェントによる動作＞
図２９のステップＳ２９０６でdeadの通知を受けたフェッチエージェントは、図３０の手順で動作する。
【０１８３】
まず、割込みの要因が実行エージェントからのdead通知であるか判定し、そうでなければ要因に応じた処理を行う（ステップＳ３００１）。dead通知でなければ、フェッチエージェントが保有する、アクティブなエージェントのリストであるアクティブキューリストから、dead通知をよこしたエージェントに対応するキューＩＤ（エージェントキューＩＤ）を削除する（ステップＳ３００２）。そのあと、そのエージェントキューＩＤに属するコマンド、すなわち、削除されたキューＩＤを有するＯＲＢがＯＲＢリストに含まれているか判定し（ステップＳ３００３）、含まれていればそのＯＲＢについてはキューＩＤエラーステータスをステータスブロックに格納し、イニシエータに返す（ステップＳ３００６）。含まれていなければ、dead通知をよこしたキューのためにフェッチエージェントが確保していた資源をすべて解放する（ステップＳ３００４）。
【０１８４】
以上説明したように、イニシエータ及びターゲットそれぞれにおけるプロセスが動作することで、消滅させたいキューが処理されないコマンドによりブロックされている場合であっても、キュー（パス）を指定して消滅させることができる。これにより、他のキュー（パス）ではＫＩＬＬコマンドの影響をうけることなく処理が進められる。
【０１８５】
＜ＡｂｏｒｔＴａｓｋＳｅｔ処理＞
次にアボートタスクセット処理について説明する。このＡｂｏｒｔＴａｓｋＳｅｔは、ＳＨＰＴ−２で定められているコマンドではなく、ＳＢＰ−２において定められている命令である。この命令は、ＳＢＰ−２レイヤのモジュールの不具合等によってイニシエータとターゲットと間に不整合が生じた場合等に、その不整合を解消するために発行され、実行される。
【０１８６】
ＡｂｏｒｔＴａｓｋＳｅｔコマンドが実行されると、その時点でＯＲＢリストにリンクされているすべてのＯＲＢが消去される。このため、不整合の原因がＳＨＰＴ−２で提供される１つのチャネルにある場合であっても、他のすべてのチャネルに対して影響が及ぶ。これでは互いに独立したチャネルを提供するというＳＨＰＴ−２の本来の目的が損なわれるため、ＳＨＰＴ−２では、ＳＢＰ−２層でＡｂｏｒｔＴａｓｋＳｅｔコマンドが実行されても、ＯＲＢを消去するといったＳＢＰ−２で規定されている動作を規定通りに実行するとともに、その影響を最小限に押さえる機能を提供する。以下、その概略を説明する。
【０１８７】
＜AbortTaskSetコマンドに対する動作の概略＞
（異常を生じたキューに関する動作）
ターゲットがマネジメントレジスタにAbortTaskSetコマンドを受信する。
【０１８８】
各キューの実行エージェントに対して即座に実行を中止するようにマネジメント実行エージェントが通知する。
【０１８９】
実行中止の通知を受けた各実行エージェントは即時実行を中止し、実行を完了しているが実行完了のステータスブロックを格納していないＯＲＢがあれば、そのＯＲＢに対して実行完了のステータスブロックを格納する。
【０１９０】
実行を中止したコマンドの現在の実行情報を中断点のSeqIDに中止したコマンドのSeqIDを、中断点のresidualにそのコマンドの未実行のバイト数を格納する。なお、SeqIDとはコマンドに付された識別子であり、residualとは、コマンドにリンクしたデータの未処理の領域を指し示すポインタである。これらは、コマンドの処理中には随時更新されながらターゲットで保持されている。ここでは、そのSeqID及びresidualを、処理中のコマンドのための領域（現在のSeqID及びresidualと呼ぶ）とは異なる領域（アボート時点のSeqID及びresidualと呼ぶ）にセーブする。すなわち、中断によって未処理となっているデータ領域が記憶される。
【０１９１】
次に、現在のSeqIDに実行を中断したコマンドのSeqID+1を書き込む。そして現在ののresidualをＮｕｌｌ（１バイトも実行せず）を書き込む。
【０１９２】
そして中止したコマンド（ＯＲＢ）に対して中断（Aborted）のステータスをもつステータスブロックを格納する。
【０１９３】
そして当該キューを対象とした、ターゲット内のＯＲＢ（コマンド）をすべて破棄する。
【０１９４】
Abortedのステータスをもつステータスブロックを受信したとき、イニシエータ内のＳＨＰＴのキューのエージェントはAbortTaskSetが発行されたと認識する。
【０１９５】
そして、そのキューに属するすべての未処理のＯＲＢをＳＢＰ−２層は破棄する。そしてAbortedのステータスをもつステータスブロックに対応するコマンドおよび、そのキューに属する、それに続くコマンドに対して上位にＳＨＰＴ層はキャンセルの報告を行う。
【０１９６】
そして上位層に再開の意思があれば、上位層はAbortedのステータスをもつステータスに対応するＯＲＢに関連ついたメモリバッファ、およびそれ以降のコマンドに関連ついたメモリバッファの内容を維持して、再開要求をＳＨＰＴ層に要求する。
【０１９７】
そして、ＳＨＰＴ層は受信したAbortedのステータスをもつステータスブロックに対応するＯＲＢのコマンドと同じSeqIDを、再開要求のパラメータに付与してＳＢＰ−２層にＯＲＢの作成、発行を依頼する。
【０１９８】
もし、中断コマンドの再開の意思が上位層になければ、新規要求をＳＨＰＴ層に要求しＳＨＰＴ層は受信したabortedのステータスを持つステータスブロックに対応するコマンドのSeqID+1を新しいコマンドに付与して、ＳＢＰ−２層にＯＲＢの作成を依頼する。
【０１９９】
AbortTaskSet後、初めてＯＲＢ（コマンド）を受信した当該キューの実行エージェントは、受信したコマンドのSeqIDを参照する。
【０２００】
そして参照の結果、現在のSeqIDと同じであれば、新規のコマンドと理解し、そのコマンドを最初から実行する。そして最初のデータ転送が正常終了した時点でアボート時点のSeqID及びresidualの内容をすべてクリアする。
【０２０１】
そして参照の結果、現在のSeqIDと異なれば、アボート時点のSeqIDと比較し、同じであれば中断したコマンドの再開と理解し、アボート時点のSeqID及びresidualの内容を現在のSeqID及びresidualにコピーし、コピーされた内容に従って実行を再開する。
【０２０２】
そして最初のデータ転送のトランザクションが成功したとき、アボート時点のSeqID及びresidualの内容をすべてクリアする。
【０２０３】
（異常のなかったキューに関する動作）
ターゲットがマネジメントレジスタにAbortTaskSetコマンドを受信する。
【０２０４】
各キューの実行エージェントに対して即座に実行を中止するようにマネジメント実行エージェントが通知する。
【０２０５】
実行中止の通知を受けた各実行エージェントは即時実行を中止し、実行を完了しているが実行完了のステータスブロックを格納していないＯＲＢがあれば、そのＯＲＢに対して実行完了のステータスブロックを格納する。
【０２０６】
実行を中止したコマンドの現在の実行情報をアボート時点のSeqIDに中止したコマンドのSeqIDを、residualにそのコマンドの未実行のバイト数を格納する。現在のSeqIDに実行を中断したコマンドのSeqID+1を書き込む。そして現在のresidualをＮｕｌｌ（１バイトも実行せず）を書き込む。
【０２０７】
そして中止したコマンド（ＯＲＢ）に対して中断（Aborted）のステータスをもつステータスブロックを格納する。
【０２０８】
そして当該キューを対象とした、ターゲット内のＯＲＢ（コマンド）をすべて破棄する。
【０２０９】
Abortedのステータスをもつステータスブロックを受信したとき、イニシエータ内のＳＨＰＴのキューのエージェントはAbortTaskSetが発行されたと認識する。
【０２１０】
そのキューの属する未処理のＯＲＢをＳＢＰ−２層は破棄する。
【０２１１】
ＳＨＰＴ層は、中断されたコマンドを再開するため、受信したAbortedのステータスをもつステータスブロックに対応するＯＲＢのコマンドと同じパラメータ、同じSeqIDを、同じ内容のバッファを持ったコマンドを作成しＳＢＰ−２層にＯＲＢの作成、発行を依頼する。
【０２１２】
AbortTaskSet後、初めてＯＲＢ（コマンド）を受信した当該キューの実行エージェントは受信したコマンドのSeqIDを参照する。
【０２１３】
そして参照の結果、現在のSeqIDと同じであれば、新規のコマンドと理解し、そのコマンドを最初から実行する。そして最初のデータ転送が正常終了した時点でアボート時点のSeqID及びresidualの内容をすべてクリアする。
【０２１４】
そして参照の結果、現在のSeqIDと異なれば、アボート時点のSeqIDと比較し、同じであれば中断したコマンドの再開と理解し、アボート時点のSeqID及びresidualの内容を、現在のSeqID及びresidualにコピーし、コピーされた内容に従って実行を再開する。
【０２１５】
そして最初のデータ転送のトランザクションが成功したとき、アボート時点のSeqID及びresidualの内容をすべてクリアする。
【０２１６】
このように、異常が生じたキューに関しては上位のクライアントの意志によって、続きを行わせることも新たなコマンドを処理させることもできる。また、異常が生じていないキューに関しては、ＳＨＰＴ層の上位のクライアントに対しては何ら影響を及ぼさずに、AbortTaskSetコマンドを処理することができる。
【０２１７】
図３６は、AbortTaskSetコマンドのマネジメントＯＲＢのフォーマットである。このコマンドが何のコマンドであるかは、ファンクション(function)フィールドによって示される。また、ステータスを返すためのＦＩＦＯのアドレスをコマンドのstatus_FIFOフィールドで指定しておく。このコマンドは、図１には示されていないマネジメント実行エージェントによって実行される。
【０２１８】
また、図３７は、AborteTaskSetコマンドに対するステータスブロックのフォーマットである。AbortTaskSetの発行者は、このステータスを見てこのコマンドが正常に処理されたか判定できる。
【０２１９】
次に、イニシエータ及びターゲットそれぞれによる処理の内容を、図３１〜図３５のフローチャートを参照して説明する。図３１はターゲットにあるマネジメントレジスタに書き込みが行われた際の、マネジメントレジスタ実行エージェントによる処理手順である。図３２，３３はターゲットの各キューについての実行エージェントにおける処理である。また、図３４はイニシエータのキュー管理エージェントがステータスブロックを受信した際の処理手順であり、図３５は同じくキュー管理エージェントが上位のクライアントから送信要求を受けた際の処理手順である。
【０２２０】
＜ターゲットにおけるマネジメントレジスタ実行エージェントによる処理＞
マネジメントレジスタは図１に示すようにターゲットに存在し、イニシエータから何らかのデータを書き込むことができる。この書き込みは、ＳＢＰ−２層を管理するためのコマンドをターゲットに与えるためのもので、クライアントプロセスなどによりＳＢＰ−２層の異常、例えばキューＩＤの異常やリトライのタイムアウト、上位からの異常通報等が見いだされた場合等に、例えばAbortTaskSetの書き込みが行われる。図３１はこのマネジメントレジスタに値が書き込まれた場合、その値に応じた処理を行う手順を示す。
【０２２１】
まず、ステップＳ３１０１で、マネジメントレジスタに書き込みが行わるのを待つ。これは割込みをトリガとしても良い。書き込みがあると、その内容がAbortTaskSetであるか判定する（ステップＳ３１０２）。AbortTaskSetでなければ、その内容に応じた処理を行うが。ここではその説明は省く（ステップＳ３１０８）。AbortTaskSetであれば、フェッチエージェントによるＯＲＢのフェッチを停止させる（ステップＳ３１０３）。そして、すべてのキューに関して、実行エージェントにAbortTaskSetコマンドが発行されたことを通知する（ステップＳ３１０４）。実行エージェントはこの通知に基づいて後述する処理を行い、マネジメントレジスタ実行エージェントに対してAbortTaskSetコマンドに対する処理完了を報告する。ステップＳ３１０５では、すべての実行エージェントからこの完了報告が届くまで待つ。
【０２２２】
すべての実行エージェントから完了報告が届いたなら、AbortTaskSetコマンドに対する完了のステータスを、イニシエータに対して返す（ステップＳ３１０６）。この応答はＳＨＰＴ層には関係しない。最後に、フェッチエージェントに対してＯＲＢのフェッチの再開を要求して（ステップＳ３１０７）、処理を終了する。
【０２２３】
＜ターゲットにおける実行エージェントによる処理＞
図３２，３３は、図３１のステップＳ３１０４で通知を受けた実行エージェント各々による処理手順である。
【０２２４】
まず、AbortTaskSetコマンド受信通知がきたか判定し（ステップＳ３２０１）、きていなければ通常の処理を行う（ステップＳ３２２１）。きていれば、現在実行中の処理を粗機￥くじ中止する。なお図３２は、割込みによりステップＳ３２０２から開始されてもよい。それとともに、各実行エージェント毎に、中止したコマンドのSeqIDを、アボート時点のSeqIDとしてセーブし（ステップＳ３２０３）、中止によって未処理となったデータバッファのアドレス、すなわち現在のresidualを、アボート時点のresidualとしてセーブする（ステップＳ３２０４）。
【０２２５】
コマンド処理の中止後、完了しているにもかかわらず完了通知のステータスブロックを格納していない、すなわちイニシエータに完了した旨応答していないコマンド（ＯＲＢ）があるか判定し（ステップＳ３２０５）、あればそれらのコマンドすべてについて完了のステータスブロックを格納する（ステップＳ３２２２）。
【０２２６】
それが終えたなら、実行を中断したコマンドに対して中断のステータスを持つステータスブロックを格納し、イニシエータに応答する（ステップＳ３２０６）。そして、当該実行エージェントに属するすべてのＯＲＢ及びコマンドを破棄する（ステップＳ３２０７）。また、中止したコマンドのSeqIDを、現在のSeqIDとして格納し（ステップＳ３２０８）、現在のresidualとしてＮＵＬＬを格納する（ステップＳ３２０９）。以上でAbortTaskSetに対する処理が終了し、新たなコマンドを処理するための準備が整うため、マネジメントレジスタ実行エージェントにAbortTaskSetの処理完了を報告する（ステップＳ３２１０）。
【０２２７】
ステップＳ３２１１では、図３１のステップＳ３１０７において付勢されたフェッチエージェントが新たなＯＲＢをフェッチするまで待つ。ここでも、フェッチ後に割込みによって処理を開始するようにすることもできる。
【０２２８】
フェッチされた場合、フェッチされたコマンド（ＯＲＢ）のSeqIDが、ステップＳ３２０８でセットされた現在のSeqIDと等しいか判定する（ステップＳ３２１２）。等しくないと判定された場合、フェッチされたコマンドのSeqIDが、ステップＳ３２０３でアボート時点のSeqIDとしてセーブされた値と等しいか判定する（ステップＳ３２１３）。フェッチされたコマンドのSeqIDがいずれの値でもない場合、そのコマンドは誤ったSeqIDを与えられているため、異常処理が行われる（ステップＳ３２２７）。
【０２２９】
フェッチされたコマンドのSeqIDが、ステップＳ３２０３でアボート時点のSeqIDとしてセーブされた値と等しい場合には、そのコマンドは中断されたコマンドの再開の要求であると認識し、ステップＳ３２０３でアボート時点のSeqIDとしてセーブされた値を、現在のSeqIDとしてコピーする（ステップＳ３２１４，Ｓ３２１５）。同様に、ステップＳ３２０４でセーブされたアボート時点のresidualを、現在のresidualとしてコピーする（ステップＳ３２１６）。不要になったアボート時点のSeqID及びresidualは、無効にされる（ステップＳ３２１７，Ｓ３２１８）。
【０２３０】
そして、ステップＳ３２１５及びステップＳ３２１６でセットされた現在のSeqID及びresidualに従って、コマンドの実行を再開し（ステップＳ３２１９）、以後、通常の処理に戻る（ステップＳ３２２０）。
【０２３１】
一方、ステップＳ３２１２において、フェッチされたコマンド（ＯＲＢ）のSeqIDが、ステップＳ３２０８でセットされた現在のSeqIDと等しいと判定された場合、このコマンドは新しいコマンドであると認識し、不要になったアボート時点のSeqID及びresidualを無効にする（ステップＳ３２２３〜Ｓ３２２５）。そして、フェッチされた新しいコマンドを実行し、通常の処理に戻る。
【０２３２】
このように、ターゲットでは、コマンドに付されたSeqIDの値によって、そのコマンドが中断後の再開のためのコマンドであるか、それとも新たなコマンドであるか判定して、判定結果に応じて、再開のためのコマンドであれば続きを実行し、新たなコマンドであれば、そのコマンドを改めて実行する。
【０２３３】
＜イニシエータにおけるキュー管理エージェントによる処理手順（ステータス処理）＞
図３４は、イニシエータの各Ｉ／Ｏ要求キューを管理する各キュー管理エージェントによる処理手順である。
【０２３４】
ステータスブロックを受信すると、受信したステータスブロックに中断（Aborted）のステータスがあるか判定し（ステップＳ３４０１）、なければ通常処理を行い（ステップＳ３４０８）、あれば、ＫＩＬＬコマンドを発行しているか判定する（ステップＳ３４０２）。この判定は、図２６のステップＳ２６０３でセットされた内部ステータスを参照して行えばよい。ＫＩＬＬコマンドであれば、図２６，２７に示したＫＩＬＬコマンドの処理を実行する（ステップＳ３４０９）。
【０２３５】
ＫＩＬＬコマンドを発行していない場合には、AbortTaskSetコマンドに対する応答であると認識し、本処理を実行しているキュー管理エージェントに係るキューに異常が発生したか判定する（ステップＳ３４０３，Ｓ３４０４）。ここで、発生した異常の内容としては、いろいろなものが考えられる。例えばキューＩＤの異常やリトライのタイムアウト、上位のクライアントから通知された異常状態などである。
【０２３６】
異常が発生していないと判定された場合には、中断されたコマンドに中断前と同じSeqIDを付し（ステップＳ３４０５）、ＳＢＰ−２層にＯＲＢの発行を依頼する（ステップＳ３４０６）。ＯＲＢの発行依頼そのものは、通常行われている処理と同様である。
【０２３７】
その後、中断されたコマンド以降の同じキューのＳＨＰＴが上位から要求を受信済みのすべてのコマンドに対するＯＲＢ発行をＳＢＰ−２に依頼する（ステップＳ３４０７）。すなわち、本処理を実行するエージェントの管理対象の要求キューにつながれたコマンドすべてについて、再びＯＲＢの発行をＳＢＰ−２に依頼する。
【０２３８】
ステップＳ３４０５〜Ｓ３４０７によって、異常がないと判定されたキューに入れられたコマンドについては、AbortTaskSetにより中断される前の状態に戻る。
【０２３９】
一方、ステップＳ３４−４で異常が発生していると判定された場合には、異常が生じたキューに係るコマンドはすべてキャンセルされる。そこで、まず中断されたコマンドを上位のクライアントに対して報告し（ステップＳ３４１０）、中断フラグ(Aborted FLG)をオンにする（ステップＳ３４１１）。そして、中断されたコマンドの後にキューされているコマンドについては、すべて消去し、クライアントに対しては、消去されたコマンドはキャンセルされた旨通知する。
【０２４０】
この手順により、異常がないキューに関しては、AbortTaskSetコマンドが実行されても実行以前の状態に戻ることが保証される。また、異常があったキューに関しては、上位のクライアントプロセスによる処理次第で、処理を続行することも、あらためて他の処理を開始することもできる。
【０２４１】
＜イニシエータにおけるキュー管理エージェントによる処理手順（上位からの指示）＞
図３５は、キュー管理エージェントが上位からの要求を受けた際の手順を示す。
【０２４２】
まず、上位から送信要求を待ち（ステップＳ３５０１）、送信要求がきたなら、中断フラグ(Aborted FLG)をテストする（ステップＳ３５０２）。中断フラグはAboprtedというステータスブロックを受信したキュー管理マネージャが、管理対象のキューに異常があると判定した場合に、図３４のステップＳ３４１１でセットするフラグである。このフラグがオンでなければ、この送信要求は通常のようきゅうであるので、通常通り処理する（ステップＳ３５０７）。
【０２４３】
このフラグがオンの場合には、その送信要求が、中断された送信要求の再送かそれとも新規の送信要求か判定する。この判断基準は、例えば再送のためのフラグ等をキュー毎に設け、そのオンあるいはオフで判定すればよい。
【０２４４】
再送要求の場合には、再送を要求されたコマンドに、中断されたコマンドと同じSeqIDを付与して（ステップＳ３５０４）、ＳＢＰ−２層にＯＲＢの発行を依頼する（ステップＳ３５０５）。その後は通常の処理に戻り、処理が終えたなら送信要求を待つ（ステップＳ３５０６）。
【０２４５】
一方、新規送信要求であれば、送信するコマンドに、中断されたコマンドよりも１多いSeqIDを付与し（ステップＳ３５０８）、ＳＢＰ−２層にＯＲＢの発行を依頼する（ステップＳ３５０９）。その後は通常処理を行う（ステップＳ３５１０）。
【０２４６】
このように、AbortTaskSetコマンドによりコマンド実行が中断された場合、異常が発生していたキューに関しては、そのキューにつけられたコマンドはすべてキャンセルされる。しかし、中断されたコマンドに関しては、SeqIDを中断されたコマンドと同一の値にすることで、処理を続行することができる。また、新たな処理に切り替えることもできる。
【０２４７】
＜AbortTaskSet処理のまとめ＞
図３８〜４０を参照して、上述した処理を説明する。ここではターゲットの実行エージェントはライト実行エージェントとしてある。
【０２４８】
まず、図３８は、ライトＩ／Ｏ要求キューに関して、異常がなかった場合の、AbortTaskSet処理後の様子を例示している。イニシエータ３８０１のライトＩ／Ｏ要求キュー３８０２には、AbortTaskSet発行時にキューに入っていたコマンドＷ２，Ｗ３（数字はSeqID）がそのままキューイングされている。AbortTaskSetはＷ２処理中に発行され、Ｗ２のSeqIDは２、中断したときのresidualの値は４０００であった。これらの値は、アボート時点のセーブ値３８０６として保持されている。また、中断時には、現在のSeqIDとして２＋１＝３がセットされる。
【０２４９】
このライトＩ／Ｏ要求キューには異常がなかったため、ＯＲＢリスト３８０７及びライトキュー３８０４の内容はいったんすべて消去され、あらためてライトＩ／Ｏキュー３８０２内のコマンドに対するＯＲＢが発行される。その際には、コマンドＷ２にSeqIDとして２が与えられる。その結果、ターゲットのライトキューには、中断前と同様にコマンドＷ２，Ｗ３がキューイングされる。コマンドＷ２のSeqIDには、中断されたコマンドのそれが与えられるので、現在のSeqID及びresidualには、アボート時点でセーブされた値がコピーされて続きが行われる。またアボート時点の値は無効化される。この状態が図３８である。
【０２５０】
この結果、このライトＩ／Ｏ要求キュー及びこのキューに関する及び参照キューは、AbortTaskSet以前の状態に復帰する。
【０２５１】
図３９は、異常があったキューに関して、中断されたコマンドを続行せず、新たなコマンドから開始する際の様子を示す。この場合には、キューに異常があるため、ＯＲＢ３８０７及びターゲットのライトキュー３８０４に加え、ライトＩ／Ｏキュー３８０２の内容もいったんすべてキャンセルされる。この後、クライアントプロセスからコマンドＷ３の送信要求があると、中断された際のSeqIDの次の値３を付したＯＲＢを改めて発行する。このSeqIDは現在のSeqID３８０５と一致するので、このコマンドＷ３をはじめから実行する。この状態が図３９である。
【０２５２】
また、図３９においても、コマンドＷ２について、中断されたコマンドのSeqIDでＯＲＢを発行すれば、コマンドＷ２は中断時点から続行される。
【０２５３】
以上説明したように、本実施形態に係る通信制御方法及び装置によれば、マネジメントキューを用いたＫＩＬＬコマンドによって、所望の要求キューとその管理エージェント及び対応する参照キューとその実行エージェントの組、すなわち所望のパスを所望の時期に消滅させることができる。このため、消滅させたいパスにおけるコマンドの処理が何らかの原因で滞っていたとしても、直ちに消滅させることができる。また、消滅させたいパス以外のパスには影響を及ぼさないため、クライアントプロセス間に張られたチャネルごとの生成及び消滅のみならず、処理中のコマンドが残っているチャネルに関しても、内容のコマンドごと処理の中断及び消滅を実現できる。
【０２５４】
また、ＳＢＰ−２層におけるAbortTaskSetコマンドが実行された場合であっても、異常がないキュー（パス）に関しては、クライアントプロセスが関与することなくAbortTaskSetコマンド実行以前の状態に戻すことができる。また、異常が生じているキュー（パス）に関しては、その内容はすべて消去してしまうものの、クライアントプロセス次第で中断されたコマンドを続行することもできるし、新たなコマンドから再開することもできる。
【０２５５】
（他の実施形態）
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。
【０２５６】
また、本発明の目的は、イニシエータとして図３〜図６、図１６、図１８、図２１、図２６〜図２８、図３４、図３５の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。またターゲットも、図１７、図１９〜図２０、図２２、図２９〜図３３の手順のプログラムコードを記録した記憶媒体をコンピュータに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによって実現できる。
【０２５７】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０２５８】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０２５９】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０２６０】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０２６１】
また、記憶媒体から読み出されたプログラムコードを実行してイニシエータとなる主体はコンピュータに限らず、データ転送機器であって、ＳＢＰ−２のログイン能力があれば、どのような機器であっても良い。
【０２６２】
また、ターゲットは、複数の参照キューを用いることにより、たとえば、第１の参照キューに印刷ジョブを格納し、第２のキューにターゲットの状態を確認するためのリードコマンドを格納し、第３のキューにフィニッシャー制御コマンドを格納することにより、パイプライン処理が実現でき、印刷ジョブに基づく印刷が完了したら、フィニッシャーによる機能の実行が終了する前に、第１の参照キューに次の印刷ジョブを格納できる。
【０２６３】
（第２の実施の形態）
第一の実施の形態においては、ディスコネクト時プリフェッチプールの容量は、対応するコネクト時の増量分だけ減少するように構成されているが、ディスコネクト時にイニシエータが減少分を指示するように構成されてもよい。この場合、図１１のディスコネクトコマンドＯＲＢに対して、図２３の如く、ＰＯＯＬ＿Ｄｅｃフィールド３０９ｆを設け、イニシエータがディスコネクトコマンドを発行時にこのフィールドにターゲットに開放させるプリフェッチプールの量を指定し、図２１のステップＳ２７０１でコマンドを発行し、ターゲットは図２２のステップＳ２８０６でＰＯＯＬ＿Ｄｅｃフィールドで指定された量だけプリフェッチプールを減ずればよい。
【０２６４】
この実施の形態によっても第一の実施の形態同様の下記のごとき効果が得られる。ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。
【０２６５】
このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０２６６】
またこのＱｕｅｕｅＩＤにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０２６７】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０２６８】
（第３の実施の形態）
また、第一の実施の形態においてはイニシエータはコネクトコマンドにおいて”ｉ”ビットにより、プリフェッチプールの増加を要求するか否かのみを指定するように構成されていたが、イニシエータが増加数を指定して増加を要求することも可能である。この場合、図１０のコネクトコマンドにおける”ｉ”フィールドのビット数を増やし、増加数を示すようにすればよい。さらに、第一の実施の形態においては、イニシエータ側におけるキューに対するプリフェッチプールに対応した予約域はコネクト時にのみ設定されるように構成されていたが、コネクト時以外にも予約域を増減できるように構成することも可能である。この場合、予約域の増加分はＣｕｒｒｅｎｔ−ＰＯＯＬカウンタの値を超えないようにし、その範囲内で、予約域数を増し、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタを減ずる。減少するには、Ｃｕｒｒｅｎｔ−ＱＵＥカウンタで示される現在のＯＲＢリスト内での当該キューに属するＯＲＢ数が予約域数を下回っている場合、その差分を上限として、その範囲内でなおかつ減少後の予約域数が１以上となる範囲で減少をさせることが可能である。この場合、その範囲内で予約域数を減じ、Ｃｕｒｒｅｎｔ−ＰＯＯＬカウンタを増やす。
【０２６９】
この実施の形態によっても第一の実施の形態同様の下記のごとき効果が得られる。ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。
【０２７０】
このため、例えばスキャナやプリンタ等、複数の機能を併せ持つデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０２７１】
またこのＱｕｅｕｅＩＤにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０２７２】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０２７３】
（第４の実施の形態）
上記実施の形態においては、プリフェッチプールの増加・減少は、コネクト（図１０）・ディスコネクトコマンド（図２３）の”ｉ”ビット３０９ｅ，”ＰＯＯＬ＿Ｄｅｃ”フィールド等で指定していたか、コネクトステータス（図１４）の”ＰＯＯＬ＿Ｉｎｃ”フィールドで指定されたもとを用いていたが、これらの代わりにプリフェッチプール増加・減少の為の独立したコマンドを設けてもよい。
【０２７４】
図２５はプリフェッチプール容量変更コマンド（ファンクションコード＝Ｃ３Ｈ）のフォーマットを示している。図２５において”ｄｅｌｔａ”フィールド３０９ｇは２の補数形式の符号付の数値を示しており、このフィールドが正であればプリフェッチプールの増加を、負であればプリフェッチプールの減少をターゲットに指示する。ターゲットはこのコマンドの指示に従って実際にプリフェッチプールの増加・減少を行う。
【０２７５】
このコマンドを使った場合、イニシエータのクライアントからのオープン要求処理時には、図１６のステップＳ２５０７に先だって、プリフェッチプールの増加が必要であればイニシエータはプリフェッチプール変更コマンドを発行し、プリフェッチプールを増加させる。ターゲットは図１７におけるステップＳ２６０７以前に必要であればすでにプリフェッチプール変更コマンドを別途受けているので、ステップＳ２６０７では、参照キューの為のポインタ等のみを作成することになる。また、イニシエータのクライアントからのクローズ要求処理時には、ディスコネクトコマンドが成功した後（ステップＳ２７０３）に、プリフェッチプール容量変更命令を発行してプリフェッチプールを減少させる。ターゲットは後にイニシエータからプリフェッチプール容量変更コマンドが発行されるはずなので、ディスコネクトコマンドの処理（図２２）においては、ステップＳ２８０６では参照キューに用いるポインタ等のみを削除し、プリフェッチプールの減少は行わない。
【０２７６】
この実施の形態によっても第一の実施の形態同様の下記のごとき効果が得られる。ＳＨＰＴ−２処理部及びＯＲＢディスパッチャがキュー識別子を識別して、それぞれがキューごとに独立し実行すなわちＯＲＢの生成・処理が行われることにより、複数のキューによるマルチコネクション（チャネル）を実現することができる。この場合、１つの機器であっても、そこに含まれる複数のクライアントそれぞれに１つのコネクション（チャネル）を割り当てることで、クライアントごとに非同期の通信を行わせることができる。
【０２７７】
このため、例えばデジタル複合機であれば、それが有するスキャナやプリンタそれぞれについてクライアントとなるアプリケーションを設けておけば、それと接続されたホストコンピュータからは、あたかもそれぞれの機能を独立した機器であるかのように使用することができる。フローチャートで示したように、各キューの管理や実行エージェントは論理的に独立したプロセスであるために、マルチコネクション（チャネル）化は容易に行うことができる。
【０２７８】
またこのＱｕｅｕｅＩＤにより識別される２つのキューを１つのコネクションに用いることによって、イニシエータとターゲットとの間で、簡素な制御手順によりデータの交換が双方向に行える。すなわち、イニシエータは所望のときに所望のデータをターゲットに渡すことができる。また、ターゲットは、イニシエータから渡されたデータをターゲット自身の都合に合わせて読み出すことができる。また、ターゲットはイニシエータが準備していさえすれば、自発的であろうと、あるいはイニシエータからの要求であろうと、何時でもイニシエータにデータを渡すことができる。また、バスリセットが発生しても、バスリセット直前の状態からの処理の続行を保証することができる。
【０２７９】
さらに、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上する。
【０２８０】
【発明の効果】
以上説明したように、本発明によれば、イニシエータとターゲットとの間において、１回のログインで非同期な双方向通信及びそのマルチチャネル化を可能とし、また、データの交換に必要なプロセスやメモリといった資源を効率的に利用できる。
【０２８１】
また、ＩＥＥＥ１３９４インターフェースを利用しているために、ターゲット側へのデータ転送を、ターゲットがその都合に応じて読み出すことで行うことができ、イニシエータがターゲットの都合によってデータ転送に占有されることを防止できる。
【０２８２】
また、ＳＢＰ−２プロトコルを利用しているため、ターゲットでキューされるのはＯＲＢだけで、実際に転送されるデータそのものは処理待ちの間イニシエータに格納されている。このため、ターゲットのメモリ資源を小容量化できる。
【０２８３】
また、最新の処理状態を保持することで、バスリセットが発生しても、バスリセット後に、バスリセット直前の状態から処理を再開することができ、処理の正常な続行を保証することができる。
【０２８４】
また、イニシエータからターゲットに送信できる命令の数の管理をターゲットの各キュー毎に行うのではではなく、一元管理することにより効率的にリソースを利用できる。
【０２８５】
また、キューによる多重化路におけるターゲットのコマンドプール領域全体の割り当てをイニシエータが動的に行うことによって、通信効率及びターゲットのリソース利用効率が向上するとともに、コネクションに用いられるキュー数に応じてターゲットのコマンドプール領域の増減が行われることにより、ターゲットのリソース利用効率が向上できる。
【０２８６】
また、所望の要求キューとその管理エージェント及び対応する参照キューとその実行エージェントの組、すなわち所望のパスを所望の時期に、そのパスの状態に関わらず消滅させることができる。
【０２８７】
また、ＳＢＰ−２層におけるAbortTaskSetコマンドが実行された場合であっても、異常がないキュー（パス）に関しては、クライアントプロセスが関与することなくAbortTaskSetコマンド実行以前の状態に戻すことができる。また、異常が生じているキュー（パス）に関しては、その内容はすべて消去してしまうものの、クライアントプロセス次第で中断されたコマンドを続行することもできるし、新たなコマンドから再開することもできる。
【図面の簡単な説明】
【図１】ターゲット（プリンタ）のブロック図である。
【図２】イニシエータ（ホストコンピュータ）のブロック図である。
【図３】イニシエータのクライアントによる、データ転送要求の発生時の処理手順のフローチャートである。
【図４】イニシエータのクライアントによる、ＳＨＰＴ−２からの処理終了通知受信時の処理手順のフローチャートである。
【図５】イニシエータのＳＨＰＴ−２処理部により実行される、クライアントからコールされるライト関数、リード関数のフローチャート、及び、イニシエータのＳＨＰＴ−２処理部により実行される、Ｉ／Ｏ要求キューの管理手順のフローチャートである。
【図６】イニシエータのＳＨＰＴ−２処理部により実行される、ステータスブロック受信時の処理手順のフローチャートである。
【図７】ＯＲＢ一般のフォーマットを示す図である。
【図８】ライトコマンドＯＲＢのフォーマットを示す図である。
【図９】リードコマンドＯＲＢのフォーマットを示す図である。
【図１０】コネクトコマンドＯＲＢのフォーマットを示す図である。
【図１１】ディスコネクトコマンドＯＲＢのフォーマットを示す図である。
【図１２】クエリーコマンドＯＲＢのフォーマットを示す図である。
【図１３】ステータスブロック一般のフォーマットを示す図である。
【図１４】コネクトステータスブロックのフォーマットを示す図である。
【図１５】クエリーステータスブロックのフォーマットを示す図である。
【図１６】イニシエータのＳＨＰＴ−２処理部により実行される、クライアントからのオープン要求に対する処理手順のフローチャートである。
【図１７】ターゲットのコネクト要求に対する処理手順のフローチャートである。
【図１８】イニシエータのＳＨＰＴ−２処理部により実行される、バスリセット直後の復旧処理手順のフローチャートである。
【図１９】ドアベルレジスタあるいはＯＲＢポインタに書き込みが行われた際のターゲットのフェッチエージェントによる処理手順のフローチャートである。
【図２０】ターゲットの実行エージェントによる処理手順のフローチャートである。
【図２１】イニシエータのＳＨＰＴ−２処理部により実行される、クライアントからのクローズ要求に対する処理手順のフローチャートである。
【図２２】ターゲットのディスコネクト要求に対する処理手順のフローチャートである。
【図２３】第２の実施の形態におけるディスコネクトコマンドＯＲＢのフォーマットを示す図である。
【図２４】ＩＥＥＥ１３９４インターフェースを用いたプリンタシステムのハードウエア構成図である。
【図２５】プリフェッチプール容量変更コマンドのフォーマットを示す図である。
【図２６】イニシエータのキュー管理エージェントによるＫＩＬＬコマンド発行処理のフローチャートである。
【図２７】イニシエータのキュー管理エージェントによるＫＩＬＬコマンド発行処理のフローチャートである。
【図２８】イニシエータのＳＢＰ−２層によるステータス処理のフローチャートである。
【図２９】ターゲットの実行エージェントによるＫＩＬＬコマンド処理のフローチャートである。
【図３０】参照キューからコマンドをフェッチするフェッチエージェントの処理フローチャートである。
【図３１】ターゲットのマネジメントレジスタ実行エージェントによるAbortTaskSetコマンドの処理フローチャートである。
【図３２】各ターゲットの実行エージェントによるAbortTaskSetコマンド受信後の処理フローチャートである。
【図３３】各ターゲットの実行エージェントによるAbortTaskSetコマンド受信後の処理フローチャートである。
【図３４】イニシエータにおけるキュー管理エージェントによるステータス受信処理のフローチャートである。
【図３５】イニシエータにおけるキュー管理エージェントによるクライアントからの要求処理のフローチャートである。
【図３６】  AbortTaskSetコマンドのマネジメントＯＲＢのフォーマットを示す図である。
【図３７】  AborteTaskSetコマンドに対するステータスブロックのフォーマットを示す図である。
【図３８】  AborteTaskSetコマンド実行後の様子（異常なし）を示す図である。
【図３９】  AborteTaskSetコマンド実行後の様子（異常あり）を示す図である。
【符号の説明】
１  ＣＰＵ
２  ＲＡＭ
３  ＲＯＭ
４  システムバス
１２  ＣＰＵ
１３  ＲＯＭ
１９  ＲＡＭ
１０１  フェッチエージェント
１０３  プリフェッチプール
１０５  参照キュー
１０６  実行エージェント
１０８  ターゲット側クライアント
１０９  １３９４インターフェース
１１０  バスインターフェース
２０１  ＳＨＰＴ−２処理部
２０２ａ  Ｉ／Ｏ要求キュー
２０４  ＯＲＢリスト
２０５  ステータスＦＩＦＯ
２０６  イニシエータ側クライアント
２０７  ライトバッファ
２０８  リードバッファ
【図１】
0003990833.tif 000002
【図２】
0003990833.tif 000003
【図３】
0003990833.tif 000004
【図４】
0003990833.tif 000005
【図５】
0003990833.tif 000006
【図６】
0003990833.tif 000007
【図７】
0003990833.tif 000008
【図８】
0003990833.tif 000009
【図９】
0003990833.tif 000010
【図１０】
0003990833.tif 000011
【図１１】
0003990833.tif 000012
【図１２】
0003990833.tif 000013
【図１３】
0003990833.tif 000014
【図１４】
0003990833.tif 000015
【図１５】
0003990833.tif 000016
【図１６】
0003990833.tif 000017
【図１７】
0003990833.tif 000018
【図１８】
0003990833.tif 000019
【図１９】
0003990833.tif 000020
【図２０】
0003990833.tif 000021
【図２１】
0003990833.tif 000022
【図２２】
0003990833.tif 000023
【図２３】
0003990833.tif 000024
【図２４】
0003990833.tif 000025
【図２５】
0003990833.tif 000026
【図２６】
0003990833.tif 000027
【図２７】
0003990833.tif 000028
【図２８】
0003990833.tif 000029
【図２９】
0003990833.tif 000030
【図３０】
0003990833.tif 000031
【図３１】
0003990833.tif 000032
【図３２】
0003990833.tif 000033
【図３３】
0003990833.tif 000034
【図３４】
0003990833.tif 000035
【図３５】
0003990833.tif 000036
【図３６】
0003990833.tif 000037
【図３７】
0003990833.tif 000038
【図３８】
0003990833.tif 000039
【図３９】
0003990833.tif 000040