JPH0477938B2 - - Google Patents

Description

請求の範囲 １ サービス要求に応答するオペレーテイングシ
ステム手段２０を含み、そのオペレーテイングシ
ステム手段へアクセス可能なサービスをユーザに
提供するための第１コンピユータ１０と、 第１コンピユータに通信接続された第２コンピ
ユータ１１と、 第２コンピユータに通信接続された少なくとも
１つの第３コンピユータ１２と、 サービス要求をトラツプし、第１手段２１から
第２コンピユータの第４手段３１へのトラツプさ
れたサービス要求の通知をオペレーテイングシス
テム手段によつて通信するオペレーテイングシス
テム・カーネルレベル・プロセス手段２２を含
み、オペレーテイングシステム手段に対するユー
ザのサービス要求をトラツプし、ユーザの介入な
くその要求を第２コンピユータに通知する、第１
コンピユータ内の第１手段と、 第１手段からの要求通知を受信しおよび収集
し、受信された要求を第３手段３３，３４へ引き
渡す、オペレーテイングシステム・カーネルレベ
ル・ドライバ第４手段を含み、要求通知の受信に
応答して、第２および第３コンピユータと協力し
て、ユーザの介入なくオペレーテイングシステム
手段へのサービスのアクセス可能性を確保する、
第２コンピユータ内の第２手段３２と、 第２および第３コンピユータのうちのいずれが
要求されたサービスを有するかを判定し、第２コ
ンピユータによつて、要求されたサービスを有す
るコンピユータから第２コンピユータを通してオ
ペレーテイングシステム手段へ、要求されたサー
ビスをアクセス可能にし、第４手段にアクセス可
能性を通知する、アプリケーシヨンレベル・プロ
セス第３手段と、 それぞれ対応する要求に応答するサービス・ア
クセス可能性の通知を第３手段から受信し、アク
セス可能性を第１手段に通知するために、受信し
たサービス・アクセス可能性の通知を第１手段に
引き渡す第４手段からなり、 第１手段は、アクセス可能性の通知の受信に応
答して、ユーザの介入なく、トラツプされた要求
をオペレーテイングシステム手段に引き渡し、 オペレーテイングシステム・カーネルレベル・
プロセス手段は、オペレーテイングシステム手段
によつてサービス・アクセス可能性の通知を第４
手段から第１手段へ通信し、オペレーテイングシ
ステム手段がサービス要求を満たすように、オペ
レーテイングシステム手段へサービス要求を引き
渡し、 オペレーテイングシステム手段は、引き渡され
た、トラツプされた要求の受信に応答して、要求
されたサービスが、第２手段の動作前にすでにオ
ペレーテイングシステム手段へアクセス可能であ
つたか、または、第２手段の動作によつてはじめ
てオペレーテイングシステム手段へアクセス可能
になつたかに関わらず同一の方法で、ユーザに、
要求されたサービスを提供することを特徴とする
装置。

２ サービス要求はフアイルに対する要求を含
み、 第３手段は、第２および第３コンピユータのう
ちのいずれに要求されたフアイルが存在するかを
判定し、フアイルが第３コンピユータに存在する
と判定された場合、要求されたフアイルを第３コ
ンピユータから第２コンピユータへ転送し、第２
コンピユータ上でそのフアイルをオペレーテイン
グシステム手段へアクセス可能にする手段を有す
ることを特徴とする請求項１の装置。

３ サービス要求はリソースに対する要求を含
み、 第３手段は、第２および第３コンピユータのう
ちのいずれに要求されたリソースが存在するかを
判定し、リソースが第２コンピユータに存在する
と判定された場合、第２コンピユータ上でそのリ
ソースをオペレーテイングシステム手段へアクセ
ス可能にし、リソースが第３コンピユータに存在
すると判定された場合、第３コンピユータ上でそ
のリソースを第２コンピユータを通してオペレー
テイングシステム手段へアクセス可能にする手段
を有することを特徴とする請求項１の装置。

４ 第２コンピユータは動作環境を有し、 第３コンピユータは、 第２コンピユータに含まれる動作環境と等しい
動作環境を有するコンピユータと、 第２コンピユータに含まれる動作環境とは異な
る動作環境を有するコンピユータからなり、 第３手段は、 第２コンピユータが要求されたサービスを有す
るかどうかを判定する手段と、 第２コンピユータが要求されたサービスを有し
ないとの判定に応答して、第２コンピユータと等
しい動作環境を有する第３コンピユータが要求さ
れたサービスを有するかどうかを判定する手段
と、 第２コンピユータと等しい動作環境を有する第
３コンピユータが要求されたサービスを有しない
との判定に応答して、第２コンピユータとは異な
る動作環境を有する第３コンピユータが要求され
たサービスを有するかどうかを判定する手段から
なることを特徴とする請求項１の装置。

５ 複数の第１コンピユータと、 互いに通信接続され、それぞれ第１コンピユー
タの相異なる群に通信接続された複数の第２コン
ピユータからなり、 各第１コンピユータの第１手段は、トラツプさ
れたユーザ要求を、接続された第２コンピユータ
のみに通知し、 各第２コンピユータの第２手段は、その第２コ
ンピユータが接続されている群の第１コンピユー
タのオペレーテイングシステム手段への、要求さ
れたサービスのアクセス可能性を確保することを
特徴とする請求項１の装置。

６ サービス要求に応答して、オペレーテイング
システム手段へアクセス可能なサービスをユーザ
に提供するオペレーテイングシステム手段をそれ
ぞれ有する複数の第１コンピユータを有し、 第２コンピユータは第１コンピユータに通信接
続され、 各第１コンピユータに存在する第１手段は、そ
れぞれ、ユーザの要求をトラツプし、その要求を
第２コンピユータに通知し、アクセス可能性の通
知の受信にそれぞれ応答して、トラツプされた要
求をオペレーテイングシステム手段に引き渡し、 第４手段は、複数の第１コンピユータの第１手
段からの要求通知を受信しおよび収集し、受信し
た要求を第３手段に引き渡し、受信した要求に対
応する各第１手段へのサービス・アクセス可能性
の受信された通知を分配することを特徴とする請
求項１の装置。

７ 第１コンピユータ１０のアプリケーシヨンレ
ベルに存在するユーザプログラム２００のサービ
ス要求を、要求中のプログラムに対し透過的な、
第１コンピユータのオペレーテイングシステム・
カーネルレベルに存在する第１配置２１によつ
て、トラツプするステツプと、 第１コンピユータに接続された第２コンピユー
タ１１のオペレーテイングシステム・カーネルレ
ベルに存在する第２配置３１にその要求を通知す
るステツプと、 要求通知を、第２配置から、第２コンピユータ
のアプリケーシヨンレベルに存在する第３配置３
２に引き渡すステツプと、 要求通知の受信に応答して、要求中のプログラ
ムに対して透過的な第３配置の作用によつて、オ
ペレーテイングシステム手段２０へのサービスの
アクセス可能性を確保するステツプと、 第２配置から第１配置へアクセス可能性の通知
を引き渡すステツプと、 アクセス可能性の通知の受信に応答して、ユー
ザプログラムの介入なく、第１配置からオペレー
テイングシステム手段へ、トラツプされた要求を
引き渡すステツプと、 引き渡された、トラツプされた要求の、オペレ
ーテイングシステム手段による受信に応答して、
オペレーテイングシステム手段の動作によつて、
要求されたサービスをユーザプログラムに提供す
るステツプからなり、 アクセス可能性確保ステツプは、 第２コンピユータ上の要求されたサービスのア
クセス可能性を判定するステツプと、 第２コンピユータ上のサービスのアクセス不可
能の判定に応答して、第２コンピユータに接続さ
れた第３コンピユータ上の要求されたサービスの
アクセス可能性を判定するステツプと、 第２コンピユータを通してオペレーテイングシ
ステム手段へ、要求されたサービスのアクセス可
能性を調整するステツプと、 第３配置によつて第２配置に、要求されたサー
ビスのアクセス可能性を通知するステツプからな
り、 オペレーテイングシステム手段は、要求された
サービスが、第３配置の動作前にすでにオペレー
テイングシステム手段へアクセス可能であつた
か、または、第３配置の動作によつてはじめてオ
ペレーテイングシステム手段へアクセス可能にな
つたかに関わらず同一の方法で、ユーザプログラ
ムに、要求されたサービスを提供することを特徴
とする、サービス要求に応答してオペレーテイン
グシステム手段へアクセス可能なサービスを提供
するオペレーテイングシステム手段を有する第１
コンピユータ上のユーザプログラムにサービスを
提供する方法。

８ 第３コンピユータ上の要求されたサービスの
アクセス可能性を判定するステツプが、 第２コンピユータ上のサービスのアクセス不可
能の判定に応答して、第２コンピユータに含まれ
る動作環境と等しい動作環境を有する第３コンピ
ユータ上の要求されたサービスのアクセス可能性
を判定するステツプと、 第２コンピユータに含まれる動作環境と等しい
動作環境を有する第３コンピユータ上のサービス
のアクセス不可能の判定に応答して、第２コンピ
ユータに含まれる動作環境とは異なる動作環境を
有する第３コンピユータ上の要求されたサービス
のアクセス可能性を判定するステツプからなるこ
とを特徴とする請求項７の方法。

９ 第３コンピユータ上の要求されたサービスの
アクセス可能性を判定するステツプが、 第２コンピユータ上のサービスのアクセス不可
能の判定に応答して、その不可能性を第１コンピ
ユータに通知するステツプと、 アクセス不可能の通知に応答して、ユーザの介
入なく、第１コンピユータから第２コンピユータ
に対し、第３コンピユータ上のサービスのアクセ
ス可能性を判定することを要求するステツプから
なることを特徴とする請求項７の方法。

１０ 第１コンピユータ上で、オペレーテイング
システム手段に対するユーザのサービス要求を、
ユーザの介入なくトラツプするステツプと、 その要求を、第１コンピユータに接続された第
２コンピユータに通知するステツプと、 その通知に応答して、ユーザの介入なく、第２
コンピユータの作用によつて、オペレーテイング
システム手段へのサービスのアクセス可能性を確
保するステツプと、 サービスが第２および第３コンピユータのうち
のいずれかの上でアクセス可能であることの判定
に応答して、サービスのアクセス可能性を第１コ
ンピユータに通知するステツプと、 アクセス可能性の通知に応答して、ユーザの介
入なく、トラツプされた要求をオペレーテイング
システム手段へ引き渡すステツプと、 引き渡された、トラツプされた要求の、オペレ
ーテイングシステム手段による受信に応答して、
オペレーテイングシステム手段の動作によつて、
要求されたサービスをユーザに提供するステツプ
からなり、 アクセス可能性を確保するステツプは、 第２コンピユータ上の要求されたサービスのア
クセス可能性を判定するステツプと、 第２コンピユータ上の要求されたサービスのア
クセス不可能の判定に応答して、その不可能性を
第１コンピユータに通知する第１通知ステツプ
と、 アクセス不可能の第１通知に応答して、ユーザ
の介入なく、第２コンピユータに含まれる動作環
境と等しい動作環境を有する第３コンピユータ上
のサービスのアクセス可能性を判定することを、
第１コンピユータから第２コンピユータに対して
要求する第１要求ステツプと、 第１要求に応答して、第２コンピユータに接続
され、第２コンピユータに含まれる動作環境を有
する第３コンピユータ上の要求されたサービスの
アクセス可能性を判定するステツプと、 第３コンピユータ上の要求されたサービスのア
クセス不可能の判定に応答して、そのアクセス不
可能性を第１コンピユータに通知する第２通知ス
テツプと、 アクセス不可能の第２通知に応答して、ユーザ
の介入なく、第２コンピユータに含まれる動作環
境とは異なる動作環境を有する第３コンピユータ
上のサービスのアクセス可能性を判定すること
を、第１コンピユータから第２コンピユータに対
して要求する第２要求ステツプと、 第２要求に応答して、第２コンピユータに接続
され、第２コンピユータに含まれる動作環境とは
異なる動作環境を有する第３コンピユータ上の要
求されたサービスのアクセス可能性を判定するス
テツプと、 第２コンピユータを通じて、オペレーテイング
システム手段への要求されたサービスのアクセス
可能性を調整するステツプからなり、 オペレーテイングシステム手段は、要求された
サービスが、第２コンピユータの動作前にすでに
オペレーテイングシステム手段にアクセス可能で
あつたか、または、第２コンピユータの動作によ
つてはじめてオペレーテイングシステム手段にア
クセス可能になつたかに関わらず同一の方法で、
要求されたサービスをユーザに提供することを特
徴とする、サービス要求に応答してオペレーテイ
ングシステム手段にアクセス可能なサービスを提
供するオペレーテイングシステム手段を有する第
１コンピユータ上のユーザにサービスを提供する
方法。

［技術分野］ 本発明は、概してコンピユータに関し、具体的
には通信網内のコンピユータのインタフエースに
関する。

［背景技術と問題点］ ユーザ、つまりアプリケーシヨン・レベルのプ
ログラムにサービスの提供するのがコンピユータ
のオペレーテイング・システムの役割である。し
かし、コンピユータのオペレーテイング・システ
ムは、それが提供可能なサービスの種類が限られ
ることがしばしばある。例えば、小型のハーソナ
ル・コンピユータ（PC）では、そのPC自体の上
で直接利用できないサービスをユーザに提供でき
ないことが多い。このようなサービスの例として
は、資源を共有するような通信網に関するサービ
スである。

局所的に利用できないサービスも、２つの方法
のいずれかによれば、PCユーザに利用できるよ
うにすることが可能な場合も従来からあつた。

第１の方法は、サービスを得るためにとるべき
手続きをユーザがオペレーテイング・システムに
指示するものである。この方法では、ユーザ・プ
ログラムは、オペレーテイング・システムに必要
な指示を与えることができるように、そのPCの
環境と、その環境へのインタフエースとを知る必
要がある。この方法の大きな欠点は、ユーザ・プ
ログラムが可搬性を失い、環境やインタフエース
が代わるたびに、その変化を保証するためにプロ
グラムを変更する必要があることである。もう一
つの重大な欠点は、それ自体のサービスを提供す
る責任の所在である。ユーザをこの責任から解放
することがオペレーテイング・システムの第１の
目的であるにもかかわらず、現在はこれをユーザ
が負つていることである。

第２の方法は、局所的に利用できないサービス
の幾つかを提供することができる「付属物」をオ
ペレーテイング・システムに接続することであ
る。この付属物は、局所的に利用できないサービ
スに対するユーザの要求を受けて、オペレーテイ
ング・システムに代わつてそれを満足させるもの
である。つまり、その利用できないサービスに対
して、その付属物は、ユーザの観点からは別のオ
ペレーテイング・システムとして動作する。しか
し、この方法の欠点は、従来の付属物は、それが
あることを知つた上で、オペレーテイング・シス
テムとは別個に、そして恐らくは異なつたふうに
それと相互利用することをユーザに要求し、従つ
て最初にのべた方法と同様の負担を少なくとも幾
らかはユーザに負わせることである。もう一つの
欠点は、局所的に利用できないサービスを与える
目的で、この付属物がオペレーテイング・システ
ムの代わりを務めるため、オペレーテイング・シ
ステムの機能のかなりの部分を重複する必要があ
り、概して不足がちなPCのメモリ空間を浪費す
る一つの事情となることである。この方法がさら
に不利なのは、従来の付属物は提供可能なサービ
スの種類が限られていることである。例えば、そ
のPCに直接接続された単一のコンピユータ上で
局所的に利用可能なプリンタ・サービスしか提供
できない付属物もある。

最後に述べた欠点は、PCが通信網を構成する
ことを許さないので、重大である。コンピユータ
を通信網に相互接続することは、多くの利点があ
る。そうすることで、個々のコンピユータのユー
ザが、互いに通信することができるようになり、
また個々のコンピユータが、他のコンピユータと
の共用が可能な特殊化された資源及び能力を提供
できるようになる。

しかし、いかなる態様であれ通信網形成能力さ
え与えれば万能の策となるというわけではない。
特に、PCが大きな「メインフレーム」コンピユ
ータとのインタフエースをとることは、両方の性
能にとつて一般に損失となる。PCは、一般にシ
ングル・ユーザ用であり、従つて、早いユーザ応
答を有する傾向があるが、他方、メインフレーム
は、高い処理能力とスピードを持つ傾向がある。
しかし、多数のPCがメインフレーム・コンピユ
ータにインタフエースをとると、一般的に、メイ
ンフレームの限られた数のＩ／Ｏ（入力及び出力
の）ポートへの入出力アクセスをめぐる競合にお
いてPC間に起こる衝突と、その結果の待ち時間
のためにPC応答時間は低下する。同様に、多数
のPCがメインフレーム・コンピユータにインタ
フエースをとると、PCに要求されるＩ／Ｏ転送
によつて消費される処理能力及び時間のために、
メインフレームの処理能力も低下する。

この問題は、単にユーザにウインドウ環境を与
えるだけでは一般に解決されない。なぜなら、人
間であるユーザは、必要とする資源を得ようとす
ると、PCとメインフレームのどちらと対話しな
ければならないかを決めるためには、やはり、そ
の両方と対話しなければならないからである。人
間であれ、プログラムであれ、ユーザが、PCと
メインフレーム・コンピユータの両方と対話する
必要があると言うことは、ユーザがメインフレー
ムとの対話方法を知るだけでなく、PCを介して
間接的にそれを行う方法も知る必要があるという
点で、さらに不便である。

［解決法］ 本発明は、従来の技術の問題点及び不便を解消
することを目的とする。本発明によれば、ユーザ
に対しアプリケーシヨン・プログラム等のサービ
スを提供するオペレーテイング・システム手段
（実例としては、MS−DOSにPCインタフエース
を加えたもの）を含む装置において、そのオペレ
ーテイング・システム手段とは区別され、(a)その
オペレーテイング・システム手段に向けられたサ
ービスに対するユーザの要求をとらえ、(b)有意義
な点としてユーザの介在なく、そのサービスのオ
ペレーテイング・システム手段へのアクセス可能
性を保証し、さらに(c)とらえた要求をオペレーテ
イング・システムに渡すための手段が、提供され
る。そこで、オペレーテイング・システム手段
は、その要求に従来のように応答し、それを満た
す。

この手段は、求められたサービスのオペレーテ
イング・システムへのアクセス可能性を保証する
ので、サービスが利用できない場合はOS手段へ
のサービスの利用可能性を獲得して、オペレーテ
イング・システム手段が提供するように設計され
ていないサービスをOS手段が提供することを可
能にし、それによつて、ユーザが利用できるサー
ビスを広げることを可能にする。この性質のサー
ビスの例としては、資源及びフアイルの共有、及
ひロツキング・サービスなどの通信網関連のサー
ビスがある。

この手段は、ユーザの介入のない動作を約束す
るので、必要とされるサービスは、ユーザに透過
的に提供される。つまり、要求されたサービスの
提供においてユーザがその手段の介在に気付く必
要なく、ユーザの動作環境を変えることなく、さ
らにその、オペレーテイング・システム手段が提
供するように設計され、手段の介在なしに提供す
ることができるサービスを得るために必要な種類
の作業以外に、別な種類の作業がユーザに求めら
れることもなく提供される。

この手段は、要求されたサービスをユーザに直
接提供するわけではなく、単にオペレーテイン
グ・システム手段がサービスを提供できるように
するだけであるから、この手段は、ユーザの動作
環境を変えず、また、オペレーテイング・システ
ム手段の機能の重複を避ける。むしろ、この手段
は、オペレーテイング・システム手段の機能を補
足するのみである。

実際に説明すると、この手段は、オペレーテイ
ング・システム手段を備えた第１のコンピユータ
（例えば、パーソナル・コンピユータ）と、第１
のコンピユータに通信できるように接続された第
２のコンピユータ（例えば、UNIX（登録商標）
オペレーテイング・システムを基本としたコンピ
ユータ）とを有する。第１の手段（例えば、第１
のコンピユータのオペレーテイング・システムに
おけるパツチ（部分的な修正））により、プログ
ラムの行うオペレーテイング・システム手段への
サービス要求をとらえ、その要求を第２のコンピ
ユータに知らせる。第２の手段は（例えば、第２
のコンピユータにおけるデイバイス・ドライバ、
リクエスト・サーバ、及びサービスを行う個々の
プロセス）は、その通知の受信に応じて、要求し
ているプログラムの介入はやはり必要とすること
なくオペレーテイング・システム手段のサービス
へ確実にアクセスできるようにし、第１の手段に
アクセスできることを知らせる。第１の手段は、
その知らせを受けると、今度はこれに応じて、と
らえた要求をオペレーテイング・システム手段に
渡す。第１のコンピユータに要求をとらえる仕組
みのみを含めることは、第１のコンピユータに施
さなければならない変更は最小限で済むので、比
較的簡単で費用もそれ程かからない上に、その手
段の機能及び装備の大部分、従つて複雑で高価な
部分を、別個のコンピユータに含めることが可能
となる。よつて、複数のコンピユータの第１の手
段からの要求通知を受信し、それらをアクセス可
能性を保証する実体（例えば、リクエスト・サー
バ及びサービスを行う個々のプロセス）に渡し、
さらに、要求されたサービスのアクセス可能性の
通知をそのアクセス可能性を保証する実体から受
信して、それを要求している第１の手段に渡す実
体を、第２の手段に含めることによつて、手段の
主な費用及び機能を複数の第１のコンピユータ間
で共有することが可能になり、従つて、この機能
を提供するコンピユータ１台当たりの費用をかな
り低くすることが可能となる。

具体的には、第２のコンピユータは、複数の構
成要素からなり、そのうちの１つは、第２の手段
を備え、他の構成要素に通信できるように接続さ
れている。従つて、この手段の便宜は、通信網全
体のコンピユータ及び、それによつて通信網関連
のサービスが、第１のコンピユータ・ユーザに提
供される。

説明するために開示した本発明の実施例によれ
ば、メインフレーム・コンピユータからPCの
Ｉ／Ｏリクエストの負担を取り除くと共に、メイ
ンフレームのためにPCの速度が低下しないよう
に、PCとメインフレームとの間に、両者の相互
作用を緩衝するインタフエースが与えられる。こ
のインタフエースは、PCとメインフレーム・コ
ンピユータとの間にあり、少なくとも１台のコン
ピユータを備えたコンピユータ媒体の３番目の層
である。第３層のコンピユータは、通信網に接続
されて、フアイル及び資源を提供すると共に、ロ
ツキング・サービスも提供する。第３層のコンピ
ユータは、PCのために、メインフレームのデー
タベースからフアイルをダウンロードし、PCユ
ーザによつて要求されたフアイルの格納場所を求
めてその中間層を探索し、第３層内部にあるその
フアイルを要求中のPCユーザがそれらをアクセ
ス可能な場所まで移動させ、いずれのPCユーザ
も第３層のいずれの点に接続されたいかなる資源
にもアクセスできるようにし、さらに一PCユー
ザによるアクセス排他性を資源またはフアイルに
与える。フアイル提供サービスによつて、各ユー
ザがメインフレームへのポートを持つ必要性が回
避される。資源提供サービスによつて、各ユーザ
は、資源を共有することが可能となる。また、ロ
ツキング・サービスによつて１つのフアイルまた
は資源にアクセスしようとする二人以上のユーザ
が衝突することが防止される。このインタフエー
スは、これらのサービスをユーザに透過的に提供
する、つまり人であるPCユーザもPCのアプリケ
ーシヨン・プログラムも、単にPCと対話するの
みであり、それらPC環境を変えることなく通常
どうりに対話するところに意義がある。

本発明の前記及びその他の利点及び特徴は、本
発明の具体的な実施例に関する以下の説明を添付
図面と共に参照すれば明らかとなる。

【図面の簡単な説明】

第１図は、本発明の具体的な実施例を含むコン
ピユータのシステムのブロツク図、 第２図は、第１図のパーソナル・コンピユータ
のメモリのブロツク図、 第３〜４図は、第１図のパーソナル・コンピユ
ータのパツチの流れ図、 第５図は、第１図の中間コンピユータのドライ
バのブロツク図、 第６〜８図は、それぞれ第５図のドライバのポ
ート制御、ポート・マスク、及びグローバル・マ
スク・レジスタのブロツク図、 第９〜１２図は、それぞれ第５図のドライバの
オープン、クローズ、リード、及びライトのルー
チンの流れ図、 第１３〜１５図は、第５図のドライバの
IOCTLルーチンの流れ図、 第１６図は、第１図の中間コンピユータのリク
エスト・サーバのブロツク図、 第１７〜２０図は、第１６図のリクエスト・サ
ーバのリクエスト・スケジユーラの流れ図、 第２１図は、第１６図のリクエスト・サーバの
スケジユール管理サポート関数のRUNQルーチ
ンの流れ図、 第２２図は、第１６図のリクエスト・サーバの
ユーザ関数のLOCKREQの流れ図、 第２３図は、第１６図のリクエスト・サーバの
ユーザ関数のNETGET関数及びSNAGET関数
の流れ図、 第２４図は、第１６図のリクエスト・サーバの
ユーザ関数のRESRCGET関数の流れ図、 第２５図は、第１６図のリクエスト・サーバの
ユーザ関数の一般資源クラス関数の流れ図、 第２６〜２７図は、第１図のNETSVRのリク
エスタ部の流れ図、 第２８〜３１図は、RASSISTプロセスを含
む、第１図のNETSVRのアクセプタ部の流れ
図、 第３２図は、第１図の中間コンピユータのメモ
リのAPISVRに関する部分のブロツク図、 第３３〜３６図は、第１図のAPISVERブロツ
ク図である。

［詳細な説明］ システムの概要（第１図） 第１図に、コンピユータ網を示す。これは、複
数のパーソナル・コンピユータ１０、複数の中間
または「部門サーバ」型のコンピユータ１１、及
びデータベース１３を備えたメインフレーム・コ
ンピユータ１２からなる。パーソナル・コンピユ
ータと中間コンピユータとは通信媒体１４によつ
て相互に接続されて、網を成している。各中間コ
ンピユータ１１は、複数のPC１０に接続され、
それらのPC１０にサービスを行う。中間コンピ
ユータ１１は、プリンタ１６またはその他の装
置、または通信網リンクへのアクセス等をユーザ
にそのPCによつて提供する。１つ以上の中間コ
ンピユータ１１が、それぞれ通信媒体１５によつ
てメインフレーム・コンピユータ１２に接続され
ている。

前記のようにする代わりに、それぞれが１つ以
上の中間コンピユータに接続された複数のメイン
フレーム・コンピユータを網に含めてもよい。

前記のコンピユータ網は、所望の任意の装置で
構成することが可能であつて、例えば、PC１０
は、MS−DOSオペレーテイング・システム２０
の下で動作するAT＆T6300PCであり、中間コン
ピユータ１１は、UNIXオペレーテイング・シス
テムの下で動作するAT＆T3B2コンピユータで
あり、メインフレーム・コンピユータ１２は、
IBM（登録商標）System／370のようなIBM機ま
たはIBM互換機であり、網通信媒体１４は、AT
＆T3BNET網であり、中間コンピユータ１１と
メインフレーム・コンピユータ１２とを相互接続
する媒体１５は、システムズ・ネツトワーク・ア
ーキテクチヤ（SNA）リンクである。具体的に
は、PC１０及び中間コンピユータ１１は、
3BNETを介してルーカス（Locus）コンピユー
テイング・コーポレーシヨンのPCインターフエ
ース２２によつて互いに通信しあう。PCインタ
フエース２２は、オペレーテイング・システムの
カーネル・レベルで動作して、MS−DOSオペレ
ーテイング・システム２０が提供できないオペレ
ーテイング・システム型のサービスを提供するの
で、PCインタフエースは、MS−DOSオペレー
テイング・システムと共に、PC１０のオペレー
テイング・システム手段を構成していると考える
ことができる。

また、媒体１４は、STARLAN網であり、イ
ンタフエース２２は、AT＆ＴのSTARLANク
ライアント／サーバソフトウエアである。

中間コンピユータ１１は、網のフアイル及び資
源のサービス、網の資源及びフアイルのロツク、
及びメインフレーム・データベース・サービスを
複数の各PC及び相互に提供する。データベー
ス・サービスはメイン・フレーム・コンピユータ
１２からフアイルを検索し、それらを中間コンピ
ユータ１１に分配してデータベース１３をフラツ
ト・フアイルに分割することによつて提供され
る。そして、それらのフアイルは、中間コンピユ
ータ１１の間を移動させられて、メインフレー
ム・コンピユータ１２との対話を必要とすること
なくアクセスされる。フアイル提供サービスは、
要求されたフアイルを求めて中間コンピユータを
全て探し、見付かつた場合、要求中のユーザがそ
のフアイルを使用できるように、要求中のPC１
０のサービスを行う中間コンピユータ１１にフア
イルを移動させることによつて与えられる。この
ように、フアイルは、ユーザがメインフレーム・
コンピユータ１２と対話することなくユーザから
ユーザへと渡される。資源提供サービスも、同様
に与えられる。即ち、要求された資源を求めて中
間コンピユータ１１を全て探し、要求側のサービ
スを行う中間コンピユータ１１から資源を保有し
ている中間コンピユータ１１に要求がて転送さ
れ、そこで満足されるように、両方の中間コンピ
ユータ１１間に論理的リンクを与える。PC１０
同志の間の資源の共有が可能となるため、各PC
が、プリンタ、保存用記憶装置、及びメインフレ
ーム・コンピユータ１２へのポート等を独自に持
つ必要がない。ロツキング・サービスは２人以上
のユーザが競合することがないように、フアイル
の使用を一度に一人のユーザのみに制限するため
に提供される。

UNIXオペレーテイング・システム３０は、そ
れによつて制限された資源に対する順序だつた排
他的なアクセスを自動的に提供するので、資源の
ロツキングをわざわざ行う必要はない。しかし、
資源のアクセスの排他性が自動的には提供されな
いシステムにおいては、資源ロツキング・サービ
スをフアイル・ロツキング・サービスと同じ要領
で提供することができる。

前記のサービスをユーザに対し透過的に提供す
る主な構成要素は、各PC上のPCオペレーテイン
グ・システム（MS−DOS）のパツチ２１、並び
に各中間コンピユータ１１上にある、中間コンピ
ユータのオペレーテイング・システム（UNIX）
のドライバ３１、アプリケーシヨン水準のリクエ
スト・サーバ３２、及びアプリケーシヨン水準の
NETSVR３３及びAPISVR３４である。パツチ
２１はオペレーテイング・システム２０に対する
フアイル・サービスまたは資源・サービスの要求
を捕らえ、それらをインタフエース２２を介して
関係する中間コンピユータ１１に転送する。ドラ
イバ３１は、複数のPC１０のパツチ２１をリク
エスト・サーバ３２に橋渡しする。即ち、ドライ
バ３１は、PC１０から集めた要求をリクエス
ト・サーバ３２に渡し、リクエスト・サーバ３２
の応答を要求中のPC１０に送り返す。そして、
リクエスト・サーバ３２は要求されたサービスを
提供するために、要求されたフアイルまたは資源
を求めて中間コンピユータを探査して、他の中間
コンピユータ１１やメインフレーム・コンピユー
タ１２からPC上で利用できないフアイル及び資
源を獲得し、さらにフアイル及び資源のロツクや
アンロツクを行う。明確に言えば、リクエスト・
サーバ３２、NETSVR３３、及びAPISVR３４
によつて、要求されたフアイル及び資源がオペレ
ーテイング・システム２０及びインタフエース２
２にアクセスできることが保証されるのである。

パツチ（第２図〜４図） インタフエース２２及び、それを介した中間コ
ンピユータ１１は、通常のように追加デイスク・
ドライブとしてPC１０に登録される。具体的に
は、PCのオペレーテイング・システム２０は、
インタフエース２２及び、それを介した中間コン
ピユータ１１を仮想的な補助デイスク・ドライブ
とみなす。従つて、第２図に示したように、中間
コンピユータ１１によつて提供されるべきサービ
スに対するPC１０上のユーザ・プログラム２０
０によるコールは、オペレーテイング・システム
２０におけるEXIT及びデイスクのサービス・ル
ーチン２０２（本実施例では、DOS BIOSサー
ビス・ルーチン）を指し示すPCオペレーテイン
グ・システム割り込みベクトル２０１に写像され
る。

このように、フアイル・サービス及び資源サー
ビスに対するコールは、サービス・ルーチン２０
２に写像されるが、これは、本実施例において、
プリンタ１６以外の資源は、PC１０上てフアイ
ルとして扱われるからである。しかし、プリン
タ・サービスに対するコールは、PC１０上でPC
インタフエース２２によつて処理される。

前記の割り込みベクトルの１つで、フアイル
（これにより、以降、資源も示すものとする）の
「open」コール及び「exit」コールの写像先のベ
クトルは、初期化の際に、これらのコールのサー
ビスを行うPCオペレーテイング・システムのル
ーチン２０２の１つではなくパツチ２１を示すよ
うに、指示先が変更される。このようにして、パ
ツチ２１は、サービス要求を捕らえることができ
るようになる。

パツチ２１はPCメモリ２１０に駐在するプロ
グラムである。PC１０のオペレーテイング・シ
ステム２０が起動されたときのPC１０の初期化
の際に、DOSのautoexec.batフアイルの自動実
行によつて、ユーザ・プログラム２００と同様に
パツチ２１のプログラム・テキストがユーザのメ
モリ空間にロードされる。第３図に移ると、
DOSのautoexec.batフアイルよつて始動された
パツチ２１の初期実行によつてオペレーテイン
グ・システム２０は、ステツプ298において
「open」及び「exit」コール・ベクトル２０１の
指示先を、PCメモリのパツチ２１を示すように
変更する。また、パツチ２１により、オペレーテ
イング・システム２０は、ステツプ299において、
パツチ２１が占めるメモリ空間を「終了／駐在続
行」システム・コールによつてオペレーテイン
グ・システム２０のカーネル空間に写像する。こ
れにより、パツチ２１のプロセスが、メモリ２１
０に駐在し、その空間がオペレーテイング・シス
テム２０により他の用途のために明け渡しを要求
されることがないことが保証される。

第３図及び第４図を考察すると、サービスに対
するユーザ（つまり、アプリケーシヨン水準の）
プログラム２００の要求に応じて、ステツプ300
において、「open」及び「exit」コール・ベクト
ルがパツチ２１を呼び出すと、パツチ２１は、３
０１〜３０３において、それが所定の補助デイス
ク・ドライブに向けられた「open」コールか、
または「exit」コールかを判定するために、その
要求を調べる。それらのいずれでもない場合、ス
テツプ331において、パツチ２１は、パツチ２１
が存在しない場合にベクトルによつて呼び出され
ていたはずのオペレーテイング・システム２０の
サービス処理ルーチンを呼び出すのみで、とらえ
た要求を通常どうりに処理を行うルーチンに、そ
のまま渡す。

ステツプ301及び302において、とらえた要求が
補助デイスク・ドライブへの「open」コールで
あると判断された場合、パツチ２１はステツプ
304において内部のスラグを調べ、関係付けられ
た中間コンピユータ１１上のドライブ３１が既に
開かれているかどうかを判定する。開かれていな
い場合、パツチ２１は、ステツプ305で、そのフ
ラグをセツトし、次に、ステツプ306において、
オペレーテイング・システム２０のシステム・コ
ールを行う。このシステム・コールは、パツチ２
１を呼び出した「open」コールと同じであるが、
唯一の違いは、ユーザ・プロセス２００によつて
要求されたフアイルのフアイル名が、関係付けら
れた中間コンピユータ１１のドライバ３１のフア
イル名で置き換えられていることだけである。こ
の実施例においては、このフアイル名は／
DEV／PCである。このコールは、ドライバ３１
を通常どうりに開くように作用する。

オペレーテイング・システム２０は、このコー
ルに対して通常どうりに応答する。インタフエー
ス２２を介して「open」を実行し、ドライバ３
１のアクセスの際に使用するフアイル・デイスク
リプタを返す。次に、パツチ２１は、ステツプ
307において、ドライバのフアイル・デイスクリ
プタを用いてドライバ３１を読む。オペレーテイ
ング・システム２０に対し、フアイル・デイスク
リプタを引数として渡して「read」のオペレー
テイング・システム・コールを行う。オペレーテ
イング・システム２０は、インタフエース２２を
介して通常どうりに「read」を実行し、読んだ
データをパツチ２１に返す。この情報は、ドライ
バ３１が要求中のPC１０に割り当てた、ドライ
バ３１のポートのフアイル名（マイナー番号）で
ある。

ステツプ307において、ポート番号を得ると、
パツチ２１は、ステツプ308において、オペレー
テイング・システム２０に対し「close」のオペ
レーテイング・システム・コールを行い、そのド
ライバのフアイル・デイスクリプタを引数として
渡すことにより、ドライバ３１を閉じる。オペレ
ーテイング・システム２０は、このコールに対し
通常どうりに応答する。

また、PC１０が中間コンピユータ１１にログ
インしたときに、ポート番号が自動的にPC１０
に割り当てられ、PC１０が、ドライバ３１にア
クセスする間中、そのポート番号を維持するなら
は、前記のステツプ304〜308は省くことができ
る。

パツチ２１がステツプ304においてドライバ３
１は開いていると判断した場合に、またはステツ
プ308に続き、パツチ２１は、ステツプ309におい
て、オペレーテイング・システム２０に対し
「open」のオペレーテイング・システム・コール
を行い、割り当てられたポートのフアイル名を引
数として渡すことにより、割り当てられたポート
を開く。オペレーテイング・システム２０は、通
常どうりに応答する。即ち、開く動作を行い、割
り当てられたポートのアクセスに使用するフアイ
ル・デイスクリプタを返す。

次に、パツチ２１は、ステツプ310において、
オペレーテイング・システム２０に対し、
「write」のオペレーテイング・システム・コール
を行い、引数として、ポートのフアイル・デイス
クリプタ、LOCKREQ要求、及びユーザが開く
ことを要求したフアイルのフアイル名を渡す。こ
の場合も、オペレーテイング・システム２０は、
「write」動作を通常どうりに行い、その要求をイ
ンタフエース２２を介してドライバ・ポートに書
き込む。ドライバ３１が要求に応じると、オペレ
ーテイング・システム２０は、完了コードをパツ
チ２１に返す。ステツプ311において、パツチ２
１は、この完了コードを調べる。このコードによ
り、パツチ２１は、要求の成否を知ることができ
る。

その要求がかなつた場合、ユーザの要求したフ
アイルが、いずれかの中間コンピユータ１１に存
在し、かつ要求中のユーザにロツクされたことを
意味する。ステツプ319において、パツチ２１の
指示により、オペレーテイング・システム２０
は、この情報をPC画面上に表示する。次にパツ
チ２１は、ステツプ320で、このユーザ・プロセ
ツサ２００が開いた全てのフアイル名のリストに
追加することによつて、ロツクされたフアイルの
フアイル名を保存する。

ステツプ322において、パツチ２１はそのポー
トを閉じるために、オペレーテイング・システム
２０に対し「close」オペレーテイング・システ
ム・コールを行い、引数としてポートのフアイル
名を渡す。このコールに対し、オペレーテイン
グ・システム２０は、通常どうりに応答する。

最後に、ステツプ331において、パツチ２１は、
割り込みベクトル２０によつて呼び出されていた
はずの、オペレーテイング・システム２０のサー
ビス処理ルーチンを呼び出し、本来のユーザ・プ
ログラム２００の要求をオペレーテイング・シス
テム２０に渡した後、ステツプ333において終了
（exit）する。このユーザ要求に対して、オペレ
ーテイング・システム２０は、通常どうりに応じ
て、補助デイスク・ドライブ上の要求されたフア
イルをインタフエース２２によつて開く。

ステツプ311において、要求されたフアイルが
他のいずれかのユーザにロツクされていたために
要求が受け入れられなかつたことが、戻された終
了コードに示されている場合パツチ２１は、ステ
ツプ314において、この情報をPC画面上に表示さ
せる。そして、パツチ２１は、ドライバ・ポート
を閉じるために、ステツプ315において、オペレ
ーテイング・システム２０に「close」オペレー
テイング・システム・コールを行い、引数として
そのポートのフアイル名を渡す。オペレーテイン
グ・システム２０は、このコールに通常どうりに
応答する。次に、パツチ２１は、ステツプ316に
おいて、ユーザにエラーを強制的に返す。即ち、
要求中のユーザにエラー・コードを送り、ユーザ
の要求を破棄する。そして、パツチ２１は、ステ
ツプ333において終了する。

ステツプ311において、フアイルが中間コンピ
ユータ１１上で発見されなかつたために要求が受
け入れられなかつたことが、戻された終了コード
に示されている場合、ステツプ312において、パ
ツチ２１は、そのポートの新たな要求を書き込
む。つまり、オペレーテイング・システム２０に
「write」オペレーテイング・システム・コールを
行い、引数として、ポートのフアイル・デイスク
リプタ、NETGET要求、及ひユーザによつて要
求されたフアイル名を渡す。オペレーテイング・
システム２０は、再び、「write」動作を通常どう
りに実行する。

NETGET要求によつて、中間コンピユータ１
１のリクエスト・サーバ３２は、網１４全体の指
名されたフアイルまたは資源を求めるコールを、
NETGET３３を介して全ての中間コンピユータ
に１１に発する。リクエスト・サーバ３２が、
NETGET要求に応答すると、オペレーテイン
グ・システム２０は、パツチ２１に終了コードを
返す。ステツプ313において、パツチ２１は、こ
の終了コードを調べる。この終了コードによつ
て、NETGET要求の正否が示される。

要求がなかつた場合、フアイルまたは資源が、
いずれかの中間コンピユータ１１上で発見され、
フアイルの場合であれば、それが要求中のユーザ
にロツクされたことを意味する。フアイルの場
合、そのフアイルは、中間コンピユータ１１に送
られることになる。パツチ２１は、ステツプ319
において、再びこの情報を表示させ、ステツプ
320において、資源またはロツクされたフアイル
のフアイル名を保存し、ステツプ322において、
ポートを閉じるために、オペレーテイング・シス
テム２０に「close」オペレーテイング・システ
ム・コールを行い、引数として、ポートのフアイ
ル名を渡し、ステツプ331において、サービス処
理ルーチンを呼び出して本来のユーザの要求をオ
ペレーテイング・システム２０に伝え、そして、
ステツプ333において終了する。

ステツプ313において、フアイルが発見されて
も、それが他の者にロツクされていることが、戻
された終了コードに示されている場合、ステツプ
314〜316において、パツチ２１は、フアイルがロ
ツクされている事実に関する情報及び現在のフア
イルの所有者の識別情報を表示し、オペレーテイ
ング・システム２０に「close」コールを行つて
ドライバ・ポートを閉じ、ユーザにエラーを返し
た後、ステツプ333において終了する。

ステツプ313において、フアイルまたは資源が
いずれかの中間コンピユータ１１上でも発見され
なかつたために要求が果たされなかつたことが、
戻された終了コードに示されている場合、パツチ
２１は、ステツプ317において、再びポートに新
たな要求を書き込む。即ち、オペレーテイング・
システム２０に「write」コールを行い、引数と
して、ポートのフアイル・デイスクリプタ、
SNAGET要求、及ひユーザが要求したフアイル
名を渡す。オペレーテイング・システム２０は・
再度、「write」動作を従来どうりに行う。

このSNAGET要求の結果、リクエスト・サー
バ３２は、メインフレーム・コンピユータ１２の
データベース１３からAPISVR３４を介して要
求されたフアイルを得ようとする。リクエスト・
サーバ３２がSNAGET要求に応答を返すと、オ
ペレーテイング・システム２０は、終了コードを
返すが、この終了コードにより、ステツプ318に
おいて、SNAGET要求の正否がパツチ２１に再
び示される。

要求がフアイルに対してであり、それが果たさ
れた場合、これは、ロツクされていないフアイル
または対応するデーターベースの記録が、メイン
フレーム・コンピユータ１２のデーターベース１
３において発見され、そこから取り出されて、中
間コンピユータ１１に送られ、要求しているユー
ザにロツクされることを意味する。要求が資源に
対してであり、それが果たされた場合、その資源
がメインフレーム・コンピユータ１２上で発見さ
れたことになる。パツチ２１は、ステツプ319に
おいて、この情報を表示し、ステツプ322におい
て、オペレーテイング・システム２０に「close」
コールを行うことによつてポートを閉じ、ステツ
プ331において、サービス処理ルーチンを呼び出
して本来の要求をオペレーテイング・システム２
０に送つた後、ステツプ333において終了する。

ステツプ318において、要求されたフアイルま
たはデーターベースの記録が発見されても、メイ
ンフレーム・コンピユータ１２によつてロツクさ
れていることが、戻された終了コードに示されて
いる場合、パツチ２１は、ステツプ314〜316にお
いて、フアイルがロツクされている事実に関する
情報を表示し、ドライバ・ポートを閉じ、さらに
ユーザにエラーを強制的に送つた後、ステツプ
333において終了する。

ステツプ318において、SNAGET要求がかな
えられなかつたことが、戻された終了コードに示
されている場合、資源、フアイル、またはデータ
ーベースの記録が、発見されなかつたことを意味
する。この場合、パツチ２１はステツプ321にお
いて、この情報をPC画面に表示し、ステツプ322
において、オペレーテイング・システム２０に
「close」コールを行うことによつてドライバ・ポ
ートを閉じ、ステツプ331において、サービス処
理ルーチンを呼び出して、本来の要求をオペレー
テイング・システム２０に送つた後、ステツプ
333において終了する。オペレーテイング・シス
テム２０が、その要求を満足させようとすると、
失敗する。換言すれば、フアイルまたは資源が利
用できないことを発見する。そこで、これをユー
ザに知らせる。

ユーザの要求が「exit」コールであるとわかつ
た場合、パツチ２１は、ステツプ334において、
要求しているプロセス２００について記憶した情
報を調べ、要求しているプロセスが開いているフ
アイルがあるかどうかを判定する。ない場合、パ
ツチ２１はステツプ335において、単に終了する。
要求中のプロセスが開いているフアイルがあれ
ば、パツチ２１は、それらの開いているフアイル
を閉じ、ロツクを解除する。最初に、ステツプ
323において、パツチ２１は、割り当てられたド
ライバ・ポートを開くために、オペレーテイン
グ・システム２０に「open」オペレーテイン
グ・システム・コールを行い、引数として、ドラ
イバ・ポートのフアイル・デイスクリプタを渡
す。オペレーテイング・システム２０が復帰する
とき、これらのフアイルを他のユーザが使用でき
るように解放するために、ステツプ324において、
パツチ２１は、オペレーテイング・システム２０
に「write」コールを行い、引数として、
UNLOCKREQコマンド及びロツクされているフ
アイルのフアイル名を渡すことによつて、要求中
のユーザにロツクされている全てのフアイルの名
前と共に「unlock」要求をポートに書き込む。
オペレーテイング・システム２０が終了コードと
共に復帰するとき、パツチ２１は、ステツプ325
において、フアイルのロツクが解除されたことを
示す情報をPC画面上に表示する。次に、パツチ
２１は、ステツプ326において、ドライバ・ポー
トを閉じるために、オペレーテイング・システム
２０に「close」コールを行い、引数としてポー
トのフアイル・デイスクリプタを渡す。次に、パ
ツチ２１は、ステツプ327において、ステツプ306
の場合と同様にしてドライバ３１を開く。そし
て、ステツプ328において、割り当てられたポー
トのポート番号をドライバ３１に書き込み、割り
当てられたポートを解放する。オペレーテイン
グ・システム２０に「write」オペレーテイン
グ・システム・コールを行い、引数として、ドラ
イバのデイスクリプタ、及び割り当てられたドラ
イバ・ポートのフアイル名を渡す。次に、パツチ
２１はステツプ329において、ステツプ308と同様
にしてドライバ３１を閉じる。また、ステツプ
330らおいて、パツチ２１は、ステツプ304でセツ
トしたフラグを解除する。最後に、パツチ２１
は、サービス処理ルーチンを呼び出し、ユーザの
exit要求をオペレーテイング・システム２０に送
り、ステツプ333において終了する。オペレーテ
イング・システム２０は、このユーザのexit要求
を通常どうりに処理する。

また、パツチ２１の機能は、インタフエース２
２とオペレーテイング・システム２０との間のパ
ツチとして実現する代わりに、インタフエース２
２のPCに駐在する部分に実現することもできる。

プリンタ１６のサービスに対するユーザ・プロ
グラム２００の要求の場合、その要求は、PC１
０上のPCインタフエース２２によつてとらえら
れ、これによつて、中間コンピユータ１１上の
PCインタフエース２２に送られる。中間コンピ
ユータ１１上では、インタフエース２２が、ライ
ン・プリンタ・プロセス（LPT）を呼び出し、
それに引数として印字されるべきフアイルのフア
イル名を渡す。そして、ライン・プリンタ・プロ
セスは、中間コンピユータ１１上のプリンタ１６
の有無の検査に移り、プリンタを見付けた場合
は、その要求に応える。ライン・プリンタ・プロ
セスが、中間コンピユータ１１上でプリンタ１６
を見つけられない場合、ブロツク３０４〜３２２
においてパツチ２０に対して図解した要領とほぼ
同様の要領で、要求されたサービスをドライバ３
１及びリクエスト・サーバ３２を介して獲得する
ことになる。LPTプロセスは、「RESRC １
LPT １ FILENAME」の書式の要求をドライ
バ３１に書き込む。しかし、パツチ２１とは異な
り、ライン・プリンタ・プロセスは、ドライバ３
１との通信を、オペレーテイング・システム２０
を介して直接行うのであり、オペレーテイング・
システム２０及びインタフエース２２を介して間
接的に行うのではない。

ドライバ（第５図〜１５図） 中間コンピユータ１１が、PC１０のオペレー
テイング・システム２０にとつて、追加のデイス
ク・ドライブ、即ち仮想的なデイスク・ドライブ
「Ｄ」のような補助ドライブとして見えるのに対
し、PC１０は、インタフエース２２を介して中
間コンピユータ１１に登録され、中間コンピユー
タ１１のオペレーテイング・システムにとつて
は、普通のユーザ・プロセスとして映る。

ドライバ３１は、複数のPC１０ユーザ・プロ
グラム２００とリクエスト・サーバ３２との間
で、媒体として、即ち、通信のための多重化され
たパイプとして動作する。また、ドライバ３１
は、リクエスト・サーバ３２によつて提供される
サービスを利用するライン・プリンタ・プロセス
のような、中間コンピユータ１１のリクエスト・
サーバ３２のプロセスへの橋渡しを行う。PC１
０は、PCインタフエース２２を介して中間コン
ピユータ１１のオペレーテイング・システム３０
と通信を行い、このオペレーテイング・システム
３０が、さらにドライバ３１と通信を行う。ま
た、リクエスト・サーバ３２は、アプリケーシヨ
ン水準のプロセスであるが、これも、オペレーテ
イング・システム３０を介してドライバ３１と通
信を行う。

ドライバ３１は、中間コンピユータ１１のオペ
レーテイング・システム３０にとつては、UNIX
システムの通常のキヤラクタ・デイバイス・ドラ
イバとして映る。このようなドライバは、1986年
プレンテイス・ホール社発行のモーリス・Ｊ・バ
ークス（Maurice J.Bach）による「UNIXオペ
レーテイング・システムの設計」の第10章に説明
されている。

第５図に示すように、ドライバ３１は、多重ポ
ートのドライバである。番号付きのデバイス・ポ
ート５０１は、中間コンピユータ１１のプロセス
及びPC１０にとつてドライバ３１への入り口点
の役を果たす一方、制御／状態ポート５０２は、
リクエスト・サーバ３２のための入り口点の役を
果たす。番号のないデイバイス・ポート５００
は、プロセス及びPC１０がリクエスト・サーバ
３２との通信に使用するために番号付きデイバイ
ス・ポートを獲得するために使用するという点
で、特殊である。デイバイス・ポート５００及び
５０１は、プロセス及びPC１０にとつて普通の
シーケンシヤル・フアイルのように見える。従つ
て、PCインタフエース２２は、そのフアイル操
作能力によつてポート５００及び５０１を読んだ
り書いたりすることができる。しかし、番号付き
ポート５０１は、制御／状態ポートを介してリク
エスト・サーバ３２によつて定義されるプロトコ
ルの下で動作するFIFO（先入れ先出し）バツフア
のように動作する。

ドライバ３１は、キヤラクタ・デイバイス・ド
ライバに対する標準UNIXシステムのリード、ラ
イト、オープン、クローズ、及び入出力制御
（IOCTL）のコールを処理するオペレーテイン
グ・システム・カーネル（核）のルーチンの集ま
りを含んでいる。ドライバ３１は、複数のプロセ
スやPC１０が複数の資源要求をリクエスト・サ
ーバ３２に送ることを可能にし、さらに、バツフ
ア、UNIXオペレーテイング・システムの基本構
成、及び制御／状態ポート５０２を通して順序性
を実現しながら、戻されるべき要求に応答する。
また、制御／状態ポート５０２は、番号付きのデ
イバイス・ポート５０１からの刺激に対するドラ
イバ３１の反応をプログラムするためにも使用さ
れる。

「未使用ポート」のデータ構造体（未使用ポー
ト・リスト）５０３は、プロセスにもPC１０に
も割り当てられていない番号付きポート５０１の
リストを含む。番号のないポート５００を介して
ドライバ３１にアクセスを行うには、この構造体
（未使用ポート・リスト）５０３を利用する。

バツフア・プール５２０は、番号付きポート５
０１によつて使用される複数のバツフアを含む。
これらのバツフアは、プロセス、PC１０、及び
リクエスト・サーバ３２によつて番号付きポート
５０１に書き込まれた情報を格納するために使用
される。

各番号付きポート５０１は、ポート関連の情報
を含むポート別データ構造体５０４に関係付けら
れている。入力バツフア・ポインタ５０５は、
PC１０からリクエスト・サーバ３２に渡す要求
を保持する入力バツフア５２１として使用される
プール５２０内部のバツフアを指し示す。出力バ
ツフア・ポインタ５０６は、リクエスト・サーバ
３２からPC１０に渡す要求応答を保持する出力
バツフア５２２として使用されるプール５２０内
部のバツフアを指し示す。PC１０は、入力バツ
フア５２１が空になるより早く書き込もうとする
と、一般に、バツフアが溢れないように休止させ
られる。また、バツフア５２１が一杯になるより
早くバツフアを読むプロセスも、一般に休止させ
られる。出力バツフア５２２も、同様にに動作す
る。即ち、バツフア５２２が一杯になるより早く
読むPC１０は、一般に休止させられ、またバツ
フア５２２をPC１０が読むより早く、これに書
き込むプロセスも、一般に休止させられる。PC
及びプロセスは、番号付きポート５０１に対し、
首尾よくリードやライトを行うと、オペレーテイ
ング・システム３０の標準的なリターン・コード
を受け取る。

入力バツフア５２１に収容可能な最大のデータ
量は、ある調節可能なパラメータによつて制御さ
れる。出力バツフア５２２に収容可能な最大のデ
ータ量を制御する調節可能なパラメータもある。
これらの調節可能なパラメータは、システムの初
期化の際にマスター・フアイルによつて変更する
か、またはIOCTLシステム・コールによつて動
的に変更することができる。

ポート制御レジスタ５０７には、PC１０から
来るいろいろな作用によりPC１０に対し取るべ
き動作が記述されている。レジスタ５０７のフラ
グ領域を第６図に示す。フラグの意味は次のとう
りである。

RTN６００：セツトされている場合は、リード
及びライトのシステム・コール時に、リター
ン・コード・レジスタ５１０に指定されたリタ
ーン・コードを使用し、セツトされていない場
合は、標準のUNIXシステム・リターン・コー
ドを送る。

Ａ−WRT６０１：セツトされている場合は、ポ
ート５０１のライト時に入力バツフア５２１が
一杯になると、PC１０を休止（スリーブ）さ
せ、セツトされていない場合は、失敗コードを
返す。

Ａ−RD６０２：セツトされている場合は、ポー
ト５０１のリード時に入力バツフアが一杯にな
ると、PC１０を休止させ、セツトされていな
い場合は、失敗コードを返す。

WRT６０３：セツトされている場合は、ポート
５０１のライト時に、PC１０を休止させ、セ
ツトされていない場合は、休止させない。

RD６０４：セットされている場合は、ポート５
０１のリード時に、PC１０を休止させ、セツ
トされていない場合は、休止させない。

CLS６０５：セツトされている場合は、ポート５
０１のクローズ時に、PC１０を休止させ、セ
ツトされていない場合は、休止させない。

OPN６０６：セツトされている場合は、ポート
５０１のオープン時に、PC１０を休止させ、
セツトされていない場合は、休止させない。

ポート・マスク・レジスタ５０８は、番号付き
ポート上で行われる動作のうちの何によつて、制
御／状態ポート５０２で休止しているもの（例え
ば、リクエスト・サーバ３２）に、休止を終了さ
せる（復活させる）ものを送るべきかを指定す
る。レジスタ５０８のフラグ領域を第７図に示
す。フラグの意味は、次の通りである。

Ａ−WRT７００：セツトされている場合は、出
力バツフア５２２が一杯のときにリクエスト・
サーバ３２がポート５０１に書き込む場合、リ
クエスト・サーバ３２を休止させ、セツトされ
ていない場合は、休止させない。

Ａ−RD７０１：セツトされている場合は、入力
バツフア５２１が空のときにリクエスト・サー
バ３２がポート５０１を読み出す場合、リクエ
スト・サーバ３２を休止させ、セツトされてい
ない場合は、休止させない。

WRT７０２：セツトされている場合は、PC１０
のポート５０１へのライト時にリクエスト・サ
ーバ３２を復活（の休止を終了）させ、セツト
されていない場合は、復活させない。

RD７０３：セツトされている場合は、PC１０の
ポート５０１からのリード時にリクエスト・サ
ーバ３２を復活させ、セツトされていない場合
は、復活させない。

CLS７０４：セツトされている場合は、PC１０
によるポート５０１のクローズ時にリクエス
ト・サーバ３２を復活させ、セツトされていな
い場合は、復活させない。

OPN７０５：セツトされている場合は、PC１０
によるポート５０１のオープン時にリクエス
ト・サーバ３２を復活させ、セツトされていな
い場合は、復活させない。

グローバル・マスク・レジスタ５０９に設定さ
れたビツトによつて、番号付きポート５０１で行
われる動作に対し全般的に作用する応答が制御さ
れる。グローバル・マスク・レジスタ５０９は、
個々のポート・マスク・レジスタ５０８に優先す
る。レジスタ５０９のフラグ領域を第８図に示
す。フラグの意味は次のとおりである。

Ａ−WRT８００：ゼロの場合は、制御にポー
ト・マスク・レジスタ５０８を使用する。01の
場合は、入力バツフア５２２が一杯ならばリク
エスト・サーバ３２によるポート５０１のライ
ト時にリクエスト・サーバ３２を休止させ、10
の場合は、休止させない。

Ａ−RD８０１：ゼロの場合は、制御にポート・
マスク・レジスタ５０８を使用する。01の場合
は、入力バツフア５２１が空ならばリクエス
ト・サーバ３２によるポート５０１のリード時
にリクエスト・サーバ３２を休止させ、10の場
合は、休止させない。

WRT８０２：ゼロの場合は、制御にポート・マ
スク・レジスタ５０８を使用する。01の場合
は、PC１０によるポート５０１のライト時に
リクエスト・サーバ３２を復活させ、10の場合
は、復活させない。

RD８０３：ゼロの場合は。制御にポート・マス
ク・レジスタ５０８を使用する。01の場合は、
PC１０によるポート５０１のリード時にリク
エスト・サーバ３２を復活させ、10の場合は、
復活させない。

CLS８０４：ゼロの場合は、制御にポート・マス
ク・レジスタ５０８を使用する。01の場合は、
PC１０によるポート５０１のクローズ時にリ
クエスト・サーバ３２を復活させ、10の場合
は、復活させない。

OPN８０５：ゼロの場合は、ポート・マスク・
レジスタ５０８を使用する。01の場合は、PC
１０によるポート５０１のオープン時にリクエ
スト・サーバ３２を復活させ、10の場合は、復
活させない。

リターン・コード・レジスタ５１０は、リード
動作及びライト動作に対して標準UNIXシステム
のリターン・コード以外のリターン・コードが望
ましいときに関数が返すべき値を保持するもので
ある。

サービス・キユー５３０には、リクエスト・サ
ーバ３２からのサービスを待機中の番号付きポー
ト５０１のリストが保存されている。リクエス
ト・サーバ３２によつて行われる種々のIOCTL
コール（後述）によつて、サービス・キユー５３
０の内容がリクエスト・サーバ３２に返される。

パツチ２１との関係において論じると、PC１
０が最初にするべきことは、リクエスト・サーバ
３２との通信に使用する番号付きポート５０１を
獲得することであるが、この割り当てられた番号
付きポート５０１は、ユーザ、プログラムの出口
で、放棄しなければならない。同様に、中間コン
ピユータ１１のプロセスも、ドライバ３１を介し
てリクエスト・サーバ３２へのアクセスを獲得す
ることから始める必要がある。ドライバ３１は、
中間コンピユータ１１のプロセスとPC１０とを
区別しない。従つて、以下の議論は、PC１０に
言及している限り、中間コンピユータ１１のプロ
セスのような、ドライバ３１のいかなるユーザに
対しても等しく当てはまるものとする。

PC１０は、番号付きポート５０１の獲得また
は放棄のためには、特殊な番号無しポート５００
を介してドライバ３１に入る必要がある。番号無
しポート５００を介した番号付きポート５０１の
獲得及び放棄のために使用されるシステム・コー
ルは、標準UNIXシステムのオープン、クロー
ズ、リード及びライトのコールである。

これらのコールは、PC１０が番号付きポート
５０１でリクエスト・サーバ３２からサービスを
得るために利用することもできる。オープン・コ
ール及びクローズ・コールは、同様にリクエス
ト・サーバ３２も、制御／状態ポート５０２にお
いて利用することができる。しかし、リクエス
ト・サーバ３２は、制御／状態ポート５０２では
リードまたはライトのコールは利用できないの
で、ドライバ３１に関する全ての動作を、いろい
ろな種類のIOCTLコールによつて行う必要があ
る。

オープン、クローズ、リード、ライト及び
IOCTLのコールを処理する、ドライバ３１のル
ーチンは、第９図〜１５図に図示する。

第９図に示すように、ステツプ900において、
オペレーテイング・システム３０の「open」コ
ール処理ルーチンによつて呼び出されると、ドラ
イバ３１のopenルーチンは、呼び出しの一部と
して受け取つた引数を調べて、開かれたドライバ
３１ポートの種類を判定する。番号無しポート５
００が開かれた場合、ステツプ901において、オ
ペレーテイング・システム３０は、要求中のPC
１０を番号無しポート５００に自動的に接続する
ので、ドライバ３１は何もする必要がない。従つ
て、ドライバ３１は、ステツプ914において、単
にオペレーテイング・システム３０に終了コード
を返すのみである。

制御／状態ポート５０２が開かれた場合、ステ
ツプ902において、そのオープン・ルーチンは、
内部でドライバ３１に実行中として印を付け、ス
テツプ914において、オペレーテイング・システ
ム３０に終了コードを返す。

番号付きポートが開かれた場合、ステツプ904
において、オープン・ルーチンは、そのポート番
号が有効か否か、即ち、ポート番号が存在するポ
ート５０１の番号であり、かつそのポート５０１
が割り当てられているかどうかを調べる。有効で
ない場合、オープン・ルーチンは、ステツプ909
において、オペレーテイング・システム３０にエ
ラーのリターン・コードを返す。ポート番号が有
効である場合、ステツプ905において、オープ
ン・ルーチンは、ドライバ３１に実行中の印が付
いているか否か（ステツプ903を参照）を調べる。
印がない場合、オープン・ルーチンは、ステツプ
909において、レジスタ５０７のRTN領域600に
よつて指定されたエラー・リターン・コードをオ
ペレーテイング・システム３０に返す。ドライバ
３１が実行中の場合、オープン・ルーチンは、ス
テツプ906において、具体的には、そのPC１０の
識別符号を、そのポートのポート別データ構造体
５０４に入れることによつて、そのポート５０１
をそれを開いている特定のPC１０に結合する。

次に、オープン・ルーチンは、ステツプ907に
おいて、ポート５０１を開いたことに応じてリク
エスト・サーバ３２の休止状態を終了させるべき
か否かを調べる。オープ・ルーチンは、初めにグ
ローバル・マスク・レジスタ５０９のOPN領域
805を調べ、その値がゼロである場合に限り、ポ
ート・マスク・レジスタのOPN領域を調べて、
前記の判断を行う。リクエスト・サーバ３２を復
活させるべきでない場合、オープン・ルーチン
は、ステツプ911において、開かれたポートのポ
ート制御レジスタ５０７のOPNビツト６０６を
調べて、要求中のPC１０がオープン・コール時
に休止させるべきか否かを判断する。休止させる
必要がない場合、オープン・ルーチンは、ステツ
プ914において、単に、成功終了コードをオペレ
ーテイング・システム３０に返す。コール時に
PC１０を休止させる必要がある場合、オープ
ン・ルーチンは、ステツプ912において、オペレ
ーテイング・システム３０のsleep関数を依頼し、
このオープン・ルーチンも含めたPC１０に関す
る状況を休止させ、このルーチン自体がその一部
である前記の状況がステツプ913でリクエスト・
サーバ３２の動作によつて復活させられるまで休
止し、ステツプ914において、オペレーテイン
グ・システム３０に終了コードを返す。

ステツプ907においてリクエスト・サーバ３２
を復活させることになつている場合、オープン・
ルーチンは、ステツプ908において、開かれてい
るポートのポート番号をサービス・キユーに入れ
る。次に、オープン・ルーチンは、ステツプ910
において、オペレーテイング・システム３０の復
活（wakeup）関数を呼び出すことによつてリク
エスト・サーバ３２を復活させた後、ステツプ
911に進む。

「close」システム・コールによつて、ポート
５００〜５０２は閉じた状態になる。第１０図に
示すように、ステツプ1000においてオペレーテイ
ング・システム３０の「close」コール処理ルー
チンによつて呼び出されると、ドライバ３１のク
ローズ・ルーチンは、その呼び出しの一部として
受け取つた引数を調べて、ドライバ３１のポート
が開かれているか否かを判断する。番号無しポー
ト５００が開かれている場合、ステツプ1001にお
いて、オペレーテイング・システム３０の
「close」コール処理ルーチンが、必要な全ての作
業を行うので、ドライバ３１は、何もする必要が
ない。従つて、ドライバ３１は、ステツプ1016に
おいて、単に終了コードをオペレーテイング・シ
ステム３０に返すのみである。

ステツプ1002において制御／状態ポート５０２
が閉じられている場合、クローズ・ルーチンは、
ステツプ1003において、ドライバ３１に関する全
般的な情報を含むデータ構造体（図示せず）にお
いてドライバ３１に非実行中の印を付け、さらに
ステツプ1016において、オペレーテイング・シス
テム３０に終了コードを返す。

番号付きポート５０１が閉じられている場合、
クローズ・ルーチンは、ステツプ1004において、
そのポート番号が有効か否かを調べる。有効でな
い場合、クローズ・ルーチンは、ステツプ1008に
おいて、オペレーテイング・システム３０にエラ
ー・コードを返す。

そのポート番号が有効である場合、クローズ・
ルーチンは、ステツプ1009において、ポート５０
１の番号とPC１０との結合、（第９図のステツプ
906を参照）を取り消す。次に、クローズ・ルー
チンは、ステツプ1010において、ポートを閉じる
時にリクエスト・サーバ３２を復活させる必要が
あるか否かを調べる。クローズ・ルーチンは、初
めに、グローバル・マスク・レジスタ５０９の
CLS領域804を調べ、その値がゼロである場合に
限り、ポート・マスク・レジスタ５０８のCLS領
域704を調べて、前記の判断を行う。リクエスソ
ト・サーバ３２を復活させる必要がない場合、ク
ローズ・ルーチンは、ステツプ1013において、閉
じられたポートのポート制御レジスタ５０７の
CLSビツト６０５を調べて、クローズ・コールの
際に要求中のPC１０を休止させるか否かを判断
する。休止させない場合、クローズ・ルーチン
は、ステツプ1016において、単にオペレーテイン
グ・システム３０に終了コードを返す。クローズ
時にPC１０を休止させる場合、クローズ・ルー
チンは、ステツプ1014において、オペレーテイン
グ・システム３０のスリープ関数を依頼して、こ
のクローズ・ルーチンを含めたPC１０に関する
状況を休止させ、このルーチン自体がその一部で
ある前記の状況がステツプ1015でリクエススト・
サーバ３２の動作によつて復活されるまで、休止
した後、ステツプ1016において、オペレーテイン
グ・システム３０に終了コードを返す。

ステツプ1010においてリクエスト・サーバ３２
を復活させることになつた場合、クローズ・ルー
チンは、ステツプ1011において、閉じているポー
トのポート番号をサービス・キユー５３０に入れ
る。次に、クローズ・ルーチンは、ステツプ1012
において、オペレーテイング・システム３０の復
活関数を呼び出すことによつてリクエスト・サー
バ３２を復活させた後、ステツプ1013に進む。

第１１図に示すように、ステツプ1100におい
て、オペレーテイング・システム３０の「read」
処理ルーチンによつて呼び出されると、ドライバ
３１のリード処理ルーチンは、受け取つた引数を
調べて、ドライバ３１のいずれのポートが読まれ
ているかを判断する。読まれているのが番号無し
ポート５００の場合、リード・ルーチンは、ステ
ツプ1101において、未使用ポート・リスト５０３
にアクセスを行い、そこから未使用のポート５０
１の番号を得る。ステツプ1103において、使用可
能なポート５０１がないと判断した場合、ステツ
プ1108において、オペレーテイング・システム３
０にエラー・コードを返す。未使用のポート５０
１を得た場合、ステツプ1104において、そのポー
ト５０１を割り当てる。具体的には、未使用ポー
ト・リスト５０３において、そのポートに割り当
てた印を付ける。次に、ステツプ1105において、
そのポートの番号をオペレーテイング・システム
３０に返す。この番号は、割り当てられたポート
５０１のマイナー・デイバイス番号の役を果た
し、オペレーテイング・システム３０は、この番
号を要求中のPC１０に返す。

ステツプ1106において、読まれているのが制
御／状態ポートである場合、リード・ルーチン
は、ステツプ1108において、オペレーテイング・
システム３０にエラー・コードを返す。ポート５
０２を読むことのできるのは、IOCTLコールだ
けである。

読まれているのが番号付きポートである場合、
リード・ルーチンは、ステツプ1107において、そ
のポート番号が有効であるか否かを調べる。有効
でない場合、リード・ルーチンは、ステツプ1108
において、エラー・コードを返す。

ポート番号が有効である場合、リード・ルーチ
ンは、ステツプ1122において、ポート５０１の読
み出しに応じてリクエスト・サーバ３２を復活さ
せるべきか否かを調べる。リード・ルーチンは、
まずグローバル・マスク・レジスタ５０９のRD
領域803を調べ、その値がゼロの場合に限り、ポ
ート・マスク・レジスタ５０８のRD領域703を
調べて、前記の判断を行う。リクエスト・サーバ
３２を復活させないことになつた場合、リード・
ルーチンは、ステツプ1125において、レジスタ
507のRDビツト６０４を調べて、要求中のPC１
０を全てのリード時に休止させるか否かを判断す
る。しかし、ステツプ1122においてリクエスト・
サーバ３２を復活させることになつている場合、
リード・ルーチンは、ステツプ1123において、読
まれているポート501の番号をサービス・キユー
５３０に入れた後、ステツプ1124において、オペ
レーテイング・システム３０の復活関数を呼び出
すことによつて、リクエスト・サーバ３２を復活
させる。そして、リード・ルーチンは、ステツプ
1125に進む。

ステツプ1125において、要求中のPC１０を休
止させることになつている場合、リード・ルーチ
ンは、ステツプ1126において、オペレーテイン
グ・システム３０のスリープ関数を呼び出して、
このリード・ルーチンを含めたPC１０に関する
状況を休止させ、そして、このルーチン自体がそ
の一部となつている前記の状況がステツプ1127で
リクエスト・サーバ３２の動作によつて復活させ
られるまで、休止する。

ステツプ1125で、要求中のPC１０を休止させ
ないことになつた場合、またはステツプ1127に続
いて、リード・ルーチンは、ステツプ1110におい
て、ポート出力バツフア５２２が空であるか否か
を判断するために、そのバツフアを調べる。空の
場合、読むことができるデーヘタがないことにな
るので、リード・ルーチンは、ステツプ1111にお
いて、ポートの制御レジスタ５０７のＡ−RDビ
ツト６０２を調べて、行うべき動作を決定する。
ビツト６０２がセツトされていない場合、リー
ド・ルーチンは、ステツプ1112において、読んだ
データが皆無であつたことの指示をオペレーテイ
ング・システム３０に返す。ビツト６０２がセツ
トされている場合、リード・ルーチンは、ステツ
プ1114において、オペレーテイング・システム３
０のスリープ関数を呼び出して、PC１０の状況
を休止させ、さらに、ステツプ1115においてポー
トの出力バツフア５２２にデータを書き込むリク
エスト・サーバ３２の動作によつて前記の状況が
復活されるまで休止する。

リード・ルーチンが、ステツプ1115において、
復活するか、またはステツプ1110でポートの出力
バツフア５２２が空でないことがわかつた場合、
リード・ルーチンは、ステツプ1116において、要
求中のPC１０に関係付けられ、かつリード・ル
ーチンへのコールの引数として指定されたバツフ
アに出力バツフア５２２からデータをコピーす
る。このコピーは、リード・ルーチンへのコール
の引数によつて指定された数に達するまで、可能
な限りのバイト数だけ行われる。次に。リード・
ルーチンは、ステツプ1121において、ステツプ
1116でコピーしたデータのバイト数をオペレーテ
イング・システム３０に返す。

第１２図に示すように、ステツプ1200におい
て、オペレーテイング・システム３０の「write」
コール処理ルーチンによつて呼び出されると、ド
ライバ３１のライト・ルーチンは受け取つた引数
を調べて、ドライバ３１のポートが書かれつつあ
るか否かを判断する。書かれるのが番号無しポー
ト５００であるとステツプ1201でわかつた場合、
ライト・ルーチンは、ステツプ1202において、引
数として渡されたポート５０１の番号を調べてそ
の有効性を判断する。有効ならば、ライト・ルー
チンは、ステツプ1203において、PC１０への割
り当てに利用できる未使用のポート５０１として
印を付けることによつて、そのポートの番号への
割当を解除する。次に、ライト、ルーチンは、ス
テツプ1204において、オペレーテイング・システ
ム３０に終了コードを返す。ステツプ1202におい
て、そのポート番号が有効でないとわかつた場
合、ライト・ルーチンは、ステツプ1207におい
て、エラー・リターン・コードを返す。

制御／状態ポート５０２が書かれつつある場
合、ライト・ルーチンは、ステツプ1207におい
て、オペレーテイング・システム３０にエラー・
コードを返す。ポート５０２は、IOCTLコール
を介してのみ書き込むことができる。

番号無しポートが書かれつつある場合、ライ
ト・ルーチンは、ステツプ1206において、ポート
番号の有効性を判断する。有効でない場合、ライ
ト・ルーチンは、ステツプ1207において、エラ
ー・コードを返す。

ポート番号が有効である場合、ライト・ルーチ
ンは、ステツプ1222において、ポートの書き込み
に応じてリクエスト・サーバ３２を復活させるべ
きか否かを判断する。ライト・ルーチンは、まず
グローバル・マスク・レジスタ５０９のWRT領
域８０２を調べ、その値がゼロの場合に限り、ポ
ート・マスク・レジスタ５０８のWRT領域７０
２を調べて、前記の判断を行う。リクエスト・サ
ーバ３２を復活させないことになつた場合、ライ
ト・ルーチンは、ステツプ1225において、レジス
タ５０７のWRTビツト６０３を調べて、要求中
のPC１０を全てのライト時に休止させるべきか
否かを判断する。しかし、ステツプ1222でリクエ
スト・サーバ３２を復活させることになつた場
合、ライト・ルーチンは、ステツプ1223におい
て、書き込まれつつあるポート５０１の番号をサ
ービス・キユー５３０に入れ、さらに、オペレー
テイング・システム３０の復活関数を呼び出すこ
とによつて、リクエスト・サーバ３２を復活させ
る。そして、ライト・ルーチンは、ステツプ1225
に進む。

ステツプ1225で要求中のPZ１０を休止させる
ことになつた場合、ライト・ルーチンは、ステツ
プ1226において、オペレーテイング・システム３
０のスリープ関数を呼び出して、ライト・ルーチ
ンを含めたPC１０に関する状況を休止させ、こ
のルーチン自体がその一部である前記の状況がス
テツプ1227でリクエスト・サーバ３２の動作によ
つて復活させられるまで、休止する。

ステツプ1225で要求中のPC１０を休止させな
いことになつた場合、またはステツプ1227に続い
て、ライト・ルーチンは、ステツプ1209におい
て、ポートの入力バツフア５２１が一杯か否かを
判断するために、このバツフアを調べる。一杯の
場合、書き込まれるデータを収容する記憶空間が
ないので、ライト・ルーチンはステツプ1201にお
いて、ポートの制御レジスタ５０８のＡ−WRT
ビツト６０１を調べて、行うべき動作を決定す
る。ビツト６０１がセツトされていない場合、ラ
イト・ルーチンは、ステツプ1211において、書き
込まれたデータがゼロバイトであることの指示を
オペレーテイング・システム３０に返す。ビツト
６０１がセツトされている場合、ライト・ルーチ
ンは、ステツプ1213において、オペレーテイン
グ・システム３０のスリープ関数を呼び出して、
PC１０の状況を休止させ、ステツプ1214でポー
トの入力バツフア５１２からデータを読むリクエ
スト・サーバ３２の動作によつて前記の状況が復
活されるまで休止する。

ステツプ1214においてライト・ルーチンが復活
するか、またはステツプ1209においてポートの入
力バツフア５２１が空でないとわかつた場合、ラ
イト・ルーチンは、ステツプ1215において、要求
中のPC１０に関係付けられ、かつライト・ルー
チンへのコールの引数として指定されたバツフア
から入力バツフア５２１にデータをコピーする。
ライト・ルーチンは、入力バツフア５２１の空間
が利用できる限りのバイト数のコピーを、このル
ーチンへのコールの引数によつて指定されたバイ
ト数に達するまで行う。次に、ライト・ルーチン
は、ステツプ1220において、ステツプ1215でコピ
ーしたデータのバイト数をオペレーテイング・シ
ステム３０に返す。

ドライバ３１とリクエスト・サーバ３２との間
のインターフエースは、制御／状態ポート５０２
の標準の「open」コールおよび「close」コール、
およびポート５０２の複数のIOCTLシステム・
コールからなる。IOCTLコールを第１３図〜１
５図に示す。

ドライバ３１のIOCTLルーチンは、ステツプ
1300においてオペレーテイング・システム３０の
IOCTLコール処理ルーチンによつて呼び出され
ると、ステツプ1301において、その呼び出しの一
部として受け取つた引数を調べ、開かれているド
ライバ３１のポートの種類を判定する。それが制
御／状態ポート５０２でない場合、IOCTLルー
チンは、ステツプ1379において、オペレーテイン
グ・システム３０にエラー・コードを返す。制
御／状態ポート５０２である場合、IOCTLルー
チンは、ステツプ1302において、引数として受け
取つたコマンドを調べ、それがいかなる種類の
IOCTLコールかを判断し、それを相応に処理す
る。そのコマンドが、認識済みのコールに含まれ
ていない場合、IOCTLルーチンは、ステツプ
1380において、エラー・コードを返す。

IOCTL（sleep）コールは、呼び出しているプ
ロセス（通常は、リクエスト・サーバ３２であ
る）を休止させる。休止させられたプロセスは、
後に行われるグローバル・マスク・レジスタ５０
９に従う動作によつて復活させられる。IOCTL
コールには、空の準備済みプロセスの構造体が引
数として含まれる。戻る時に、サービス・キユー
５３０の内容が、この構造体に入れられる。サー
ビス・キユー５３０には、リクエスト・サーバ３
２を復活させる全ポート５０１のリストが含まれ
る。このリストに含まれる各ポート５０１には、
原因領域が関係付けられている。原因領域は、リ
クエスト・サーバ３２が復活させられた原因（即
ち、ポート５０１上で行われたオープン、クロー
ズ、リード、またはライトのシステム・コール）
を指定するビツト領域である。リターン・コード
によつて、その構造体の項目数が指定される。
IOCTLルーチンは、コールに応じて、ステツプ
1303において、サービス・キユー５３０を調べ、
リクエスト・サーバ３２を復活させる原因となる
新たなポート５０１活動の存在を判断する。新た
なポート活動がある場合、リクエスト・サーバ３
２を休止させず、ステツプ1304において、準備済
みプロセスの構造体にサービス・キユー５３０の
内容をロードした後、ステツプ1305において、そ
の構造体の項目数を指定するコードを返す。ステ
ツプ1303において、新たなポート５０１の活動が
示されなかつた場合、IOCTLルーチンは、オペ
レーテイング・システム３０のカーネルのスリー
プ関数を呼び出して、そのスーリプ・ルーチンを
含めたリクエスト・サーバ３２に関する状況を休
止させ、ステツプ1307で新たなポート活動によつ
て前記の状況が復活させられるまで、休止する。
そして、スリープ関数は、1304に進み、サービ
ス・キユー５３０の内容を返す。

IOCTL（poll）コールは、空の準備済みプロセ
ス構造体へのポインタを引数として含み、リクエ
スト・サーバ３２を復活させる原因となるポート
５０１のリストをその構造体に入れて返す。リク
エスト・サーバ３２が既に実行中である場合、普
通であれば、それを復活させるようなポート５０
１の活動もあり得るが、リクエスト・サーバ３２
は、既に復活しているので、リクエスト・サーバ
３２を復活させることはできない。このシステ
ム・コールは、これらのポート５０１のリストを
得るために提供されているのである。IOCTLル
ーチンは、このコールに応じて、ステツプ1310に
おいて、準備済みプロセス構造体にサービス・キ
ユー５３０の内容をロードした後、ステツプ1311
において、この構造体内の項目数を指定するコー
ドを返す。

IOCTL（PCUID）コールにより、リクエス
ト・サーバ３２がポート５０１の所有者を判定す
ることが可能となる。このコールにより、
IOCTLルーチンは、ステツプ1313において、指
定されたポート５０１のポート別情報５０４にア
クセスし、ステツプ1314において、そこから、ポ
ートの所有者の一義的なユーザIDを抽出して、
ステツプ1315において、そのIDをリクエスト・
サーバ３２に返す。

IOCTL（wakeup）コールは、番号付きポート
５０１または制御／状態ポート５０２で休止中
で、引数により指定された喪のを復活させる。こ
のコールにより、IOCTLルーチンは、ステツプ
1316において、オペレーテイング・システム３０
のカーネルの復活関数を呼び出して、復活させ
る。次に、このルーチンは、ステツプ1317におい
て、リクエスト・サーバ３２に戻る。

IOCTL（set qisize）コールは、ポートの入力
バツフア５２１の大きさを変化させる。ポート番
号およびバツフアの大きさは、コールによつて指
定する。このIOCTLルーチンは、ステツプ1319
において、指定されたポート５０１のポート別情
報５０４にアクセスし、ステツプ1320において、
そこにおける入力バツフア・サイズの項目を指定
した値に設定した後、ステツプ1321において、戻
る。

IOCTL（set qosize）コールは、ポートの出力
バツフアの大きさを変化させる。ポート番号およ
びバツフアの大きさは、コールによつて指定す
る。このIOCTLルーチンは、ステツプ1323にお
いて、指定されたポート５０１のポート別情報５
０４にアクセスし、ステツプ1324において、そこ
における出力バツフア・サイズの項目を指定され
た値に設定した後、ステツプ1325において、戻
る。

IOCTL（set retcode）コールは、ポート５０
１に対するリターン・コード・レジスタ（図示せ
ず）を設定する。ポート制御レジスタ５０７にお
けるRTNビツト６００がセツトされている場合、
コノリターン・コード・レジスタの値は、リード
時およびライト時にPC１０に返される。このコ
ールにより、そのリターン・コード・レジスタの
値が設定されるべきポート５０１、およびそのリ
ターン・コード自体が識別される。このIOCTL
ルーチンは、ステツプ1327において、指定された
ポート５０１のポート別情報５０４にアクセス
し、ステツプ1328において、そこにおけるリター
ン・コードを指定された値に設定した後、ステツ
プ1329において、戻る。

IOCTL（write）コールは、指定されたポート
５０１にデータを書き込む。このコールには、ポ
ートIDを含むリード／ライト構造体へのポイン
タ、データへのポインタ、およびデータのバイト
数が引数として含まれる。IOCTLルーチンは、
ステツプ1331において、指定されたポート５０１
の出力バツフア５２２にアクセスし、それを、ス
テツプ1332において、調べる。出力バツフア５２
２が一杯の場合、IOCTLルーチンは、ステツプ
1333において、バツフア・プール５２０の使用さ
れていないメモリ空間の利用可能性を調べて、出
力バツフア５２２の大きさ拡張可能性を判断す
る。出力バツフア５２２が拡張できない場合、
IOCTLルーチンは、ステツプ1336において、エ
ラー・コードを返す。出力バツフアが５２２が拡
張可能な場合、このルーチンは、ステツプ1334に
おいて、メモリ空間を割り当てて、サイズを大き
くする。

ステツプ1332で出力バツフアが一杯でないこと
がわかつた場合、またはステツプ1334に続いて、
IOCTLルーチンは、ステツプ1337において、ポ
インタによつて指定されたデータを出力バツフア
５２２にコピーする。次に、このルーチンは、ス
テツプ1338において、ポート制御レジスタ５０７
を調べて、PC１０が、このポートから読み出す
ために持ちながら休止している可能性を判定す
る。休止している場合、ルーチンは、ステツプ
1339において、オペレーテイング・システム３０
の復活関数を呼び出すことによつて、休止中の
PC１０を復活させる。休止する可能性がない場
合、またはステツプ1339に続いて、このルーチン
は、ステツプ1340において、出力バツフア５２２
へコピーしたバイト数を返す。

IOCTL（read）コールは、指定されたポート５
０１からデータを読む。このコールも、リード／
ライト構造体へのポインタを引数として含む。こ
のIOCTLルーチンは、ステツプ1341において、
指定されたポート５０１の入力バツフア５２１に
アクセスして、ステツプ1342において、それを調
べる。入力バツフア５２１が空の場合、IOCTL
ルーチンは、ステツプ1346において、「ゼロ・バ
イト分コピーした」ことを示すリターン・コード
を返す。

ステツプ1342において、入力バツフア５２１が
空でないことがわかつた場合、IOCTLルーチン
は、ステツプ1347において、入力バツフア５２１
からポインタによつて示されたメモリ領域にデー
タをコピーする。次に、このルーチンは、ステツ
プ1348において、ポート制御レジスタ５０７を調
べて、PC１０がこのポートに書き込むために待
ちながら休止している可能性を判断する。休止し
ている場合、このルーチンは、ステツプ1349にお
いて、オペレーテイング・システム３０の復活関
数を呼び出すことによつて、休止中のPC１０を
復活させる。休止している可能性がない場合、ま
たはステツプ1349に続いて、このルーチンは、ス
テツプ1350において、入力バツフア５２１にコピ
ーしたバイト数を返す。

IOCTL（flush）コールは、ポート５０１を他
のPC１０が使用できるように、ポート５０１を
解放する。このコールにより、IOCTLルーチン
は、ステツプ1380において、引数として指定され
たポート５０１のポート別情報５０４にアクセス
する。このルーチンは、ステツプ1381において、
ポインタ５０５および５０６を用いて、そのポー
トの入力バツフア５２１および出力バツフア５２
２にアクセスして、それらの内容をクリアする。
また、このルーチンは、ステツプ1382において、
そのポートのポート制御レジスタ５０７およびポ
ート・マスク・レジスタ５０８の内容をデフオル
ト値に設定する。次に、このルーチンは、ステツ
プ1383において、そのポート５０１とPC１０と
の結合（第９図のステツプ906において成立した）
を断つことによつて、そのポートを解放し、さら
にその番号を使用されていないポートのリスト５
０３に返すことによつて、そのポートの割り当て
を解除する。その後、このルーチンは、ステツプ
1384において、戻る。

ポート制御レジスタ５０７は、PCがポート５
０１に働きかけた場合に、PC１０に対して行う
べき動作を指定する手段を提供する。レジスタ５
０７は、IOCTL（set−port−control）コールに
よつて設定される。このコールには、ポート制御
データ構造体へのポインタが引数として含まれ
る。ポート制御データ構造体には、影響されるポ
ート５０１のポートID、およびポートの制御レ
ジスタ５０７の新たな値が含まる。このコールに
よつて、IOCTLルーチンは、ステツプ1355にお
いて、指定されたポート５０１の制御レジスタ５
０７へアクセスし、さらにステツプ1356におい
て、そのレジスタの内容を指定された新たな値に
指定する。そして、ステツプ1357において、戻
る。

ポート・マスク・レジスタ５０８は、PCがポ
ート５０１に働きかけた場合に、リクエスト・サ
ーバ３２に対して行うべき動作を指定する手段を
提供する。レジスタ５０８は、IOCTL（set−
port−mask）コールによつて設定される。この
コールには、ポート・マスク・データ構造体への
ポインタが引数として含まれる。この構造体に
は、影響されるポート５０１のポートID、およ
びそのポートのマスク・レジスタ５０８の新たな
値が含まれる。このコールによつて、IOCTLル
ーチンは、ステツプ1358において、指定されたポ
ート５０１のマスク・レジスタ５０８へアクセス
し、さらにステツプ1359において、そのレジスタ
の内容を指定された新たな値に設定する。そし
て、ステツプ1360において、戻る。

グローバル・マスク・レジスタ５０９は、ポー
ト・マスク・レジスタ５０８に優先する手段を提
供する。レジスタ５０９は、実行すべき動作を決
定するために、先に参照される。レジスタ５０９
は、IOCTL（set−glbl−mask）コールによつて
設定される。このコールは、引数として、新たな
レジスタ５０９の内容を含んでいる。このコール
によつて、IOCTLルーチンは、ステツプ1362に
おいて、グローバル・マスク・レジスタ５０９に
アクセスし、さらにステツプ1363において、その
内容を指定された新たな値に設定する。そして、
ステツプ1364において、戻る。レジスタ５０９
は、IOCTL（get−glbl−mask）コールによつて
読み出される。このコールには、レジスタ５０９
の内容が返されるバツフアへのポインタが引数と
して含まれる。このコールによつて、IOCTLル
ーチンは、ステツプ1366において、グローバル・
マスク・レジスタ５０９にアクセスし、ステツプ
1367において、レジスタ５０９の内容を指定され
たバツフアにコピーする。そして、ステツプ1368
において、戻る。

IOCTL（get−port−status）システム・コール
によつて、リクエスト・サーバ３２は、そのポー
ト５０１の状態についてドライバ３１に問い合わ
せることが可能となる。このコールに引数として
含まれるものは、問い合わせを受けるポート５０
１のポート番号、ポート５０１の状態、ポート制
御エジスタ５０７の内容、ポート・マスク・レジ
スタ５０８の内容、そのポートの入力バツフア５
２１内のデータのバイト数、およびそのポートの
出力バツフア５２２内のデータのバイト数を、収
容する領域を備えたポート状態データの構造体へ
のポインタである。ポート番号は、リクエスト・
サーバ３２によつて書き込まれる。IOCTLルー
チンは、このコールに応じて、ステツプ1369にお
いて、指定されたポート５０１のポート別情報５
０４にアクセスし、ステツプ1370において、その
中の関係する内容をポート状態データ構造体にコ
ピーした後、ステツプ1371において、戻る。

IOCTL（get−global−status）システム・コー
ルにより、リクエスト・サーバ３２は、ドライバ
３１に、そのドライバの全体的状態について問い
合わせることが可能となる。このコールに引数と
して含まれるものは、自由になるバツフア・プー
ル５２０の大きさ、自由なポート５０１の数、入
力バツフア５２１の大きさおよび出力バツフア５
２２の大きさを、収容するための領域を備えた
glbl−statusデータ構造体へのポインタである。
IOCTLルーチンは、このコールに応じて、ステ
ツプ1373において、そのドライバの全体的情報に
アクセスし、ステツプ1374において、その情報を
glbl−statusデータ構造体にコピーした後、ステ
ツプ1375において、戻る。

リクエスト・サーバ（第１６図〜２５図） リクエスト・サーバ３２は、コンピユータ１１
および１２の網全体に要求されたサービスを提供
するNETSVR３３およびAPISVR３４のような
プロセスとドライバ３１との間のアプリケーシヨ
ン・レベルのインタフエースである。リクエス
ト・サーバ３２は、ユーザ・レベルで実行する
が、内部的にはオペレーテンイング・システムの
ような構造となつている。リクエスト・サーバ３
２は、ドライバ３１を介して、sleep（休止）や
wakeup（復活）などのオペレーテイング・シス
テム３０のカーネル関数に直接アクセスを行う
が、これは、ユーザ・レベルのプロセスには一般
にできないことである。リクエスト・サーバ３２
によつて、UNIXオペレーテイング・システム・
コールは、フアイルおよび資源のサービスをサポ
ートする他の関数ので増加する。リクエスト・サ
ーバ３２の役割は、ドライバ３１によつて向けら
れたPC１０（及び他のプロセス）からのサービ
ス要求を受理し、これらの要求の結果として取る
べき処置を判断・計画し、さらにPC１０のため
にそれらの処理を予定し、実行する。

第１６図に示すように、リクエスト・サーバ３
２には、次のものが含まれる。即ち、受理した要
求をそれを構成する要素領域まで規格どうりに分
析するパーサ（parser）１６００、到来する分析
された要求を格納するためのジヨブ・シーケンス
１６０８の中を循環し、さらに格納したジヨブの
実行を計画するリクエスト・スケジユラ１６０
１、リクエスト・スケジユラ１６０１が呼び出
し・参照できるように種々の関数のアドレスを格
納する関数テーブル１６０２、PCによつて要求
された実際の仕事を行うユーザ関数１６０３、リ
クエスト・サーバ３２からPC１０へ状態情報を
返すためのPCリータン・コード・サポート関数
１６０４、ユーザ関数１６０３が新たなプロセス
を開始することを可能にするプロセス・サポート
関数１６０５、リクエスト・サーバ３２とそれ以
外のNETSVR３３およびAPISVR３４などのプ
ロセスとの間のプロセス間通信を行うためのメツ
セージ・サポート関数１６０６、ならびに、時間
を延長してシステム内部に留まる必要があるか、
またはアプリケーシヨン・レベルで周期的な呼び
出しを必要とするユーザ関数１６０３のためのス
ケジユール・サポート関数１６０７が、含まれ
る。

関数テーブル１６０２は、関数名１６３０、な
らびにユーザ関数およびサポート関数の関数アド
レス１６３１を１対１に関係付けて含む。パーサ
１６００から受け取つた要求の関数名は、リクエ
スト・スケジユラ１６０１によつてテーブル１６
０２で参照され、それに関係付けられた関数アド
レスが、ジヨブ・キユー１６０８に格納される。
テーブル１６０２は、ヌル・ネーム・ポインタに
よつて最後となる。これには、要求された関数が
テーブル１６０２にない場合に呼び出されるエラ
ー・ルーチンが結合されている。このエラー・ル
ーチンによつて、エラー・メツセージが要求中の
PC１０に返される。

PCリターン・コード・サポート関数１６０４
により、状態を末端５０１に返すことが可能とな
る。PCRETURNルーチンは、番号付きポート
５０１の出力バツフア５２２に情報を返し、サー
ビス要求によつて指定された文字数が出力バツフ
アにロードされた文字数と一致しない場合、それ
に関係付けられたPC１０を復活させる。この呼
び出しには、番号付きポート５０１、およびポー
トの出力バツフア５２２にロードされるデータ文
字列へのポインタを、指定する引数を付ける。ル
ーチンPCWAKEUPは、PC１０を復活させ、さ
らに、出力バツフア５２２の内容の文字数がサー
ビス要求によつて指定された数に一致する／しな
いに関わらず、前者を返す。この呼び出しは、番
号付きポート５０１を指定する引数を付けて行
う。

プロセス・サポート関数１６０５は、
STARTPROCルーチンを備えている。これによ
つて、ユーザ関数は、オペレーテイング・システ
ム３０の下で実行する他のプロセスを通常どうり
作成（fork）、起動（exec）することが可能であ
る。STARTPROCルーチンは、引数として、
PROC−NAEM、NUM−ARGS、（NO）
WAIT、AND ARG（複数可）を付けて呼び出
す。PROC−NAMEは、通常のオペレーテイン
グ・システム３０環境におけるPATH変数の中
で見つけられて、実行される。NUM−ARGSに
よつて、そのコマンドに渡されるARGの総数が
与えられる。ARGは、所望の数だけ渡すことが
できる。（NO）WAITにより、そのプロセスが
実行を終了するのを持つかどうかを指定する。
WAITは、そのプロセスが終了するまで待つこ
とを意味し、NOWAITは、プロセスを生成する
と、直ちに戻ることを示す。WAITとした場合、
終了したプロセスからリターン・コードが返され
る。NOWAITを設定した場合、戻る際に、その
新たなプロセスのプロセス番号、または失敗コー
ドのいずれかが、呼び出し中の関数に返される。
さらに、STARTPROCのために、オペレーテイ
ング・システム３０の通常のSIGCLD信号は無視
されるので、このコールによつてゾンビ・プロセ
ス（終了したにも関わらずプロセス・テーブルに
残るプロセス）が生成されることはない。

メツセージ・サポート関数１６０６は、リクエ
スト・サーバ３２とそれ以外のNETSVR３３お
よびAPISVR３４などのプロセスとの間に、通
常のオペレーテイング・システム３０のメツセー
ジ・キユーに基づくインターフエースを提供す
る。メツセージ・サポート関数１６０６は、
SENDMESSAGEルーチンを含む。このルーチ
ンは、チヤネル番号（後述）、およびそのチヤル
ネルを通してプロセスに送られる任意の長さのメ
ツセージを、引数として受け取る。メツセージ受
信関数は必要ない。後述のように、チヤネル・ウ
エイト・ジヨブ機構によつて受信が処理されるか
らである。

ジヨブ・キユー１６０８は、PC１０の要求な
どのジヨブを定義する記録事項１６４０の結合リ
ストとして構造化されている。各記録事項１６４
０は、複数の領域１６５０〜１６５４からなり、
受信された各要求は、パーサ１６００によつてそ
れらの領域に分析される。関数アドレス領域１６
５０には、テーブル１６０２から得たその要求に
対応する関数のアドレスが入る。引数領域１６５
２には、その関数に渡された引数からなる文字列
へのポインタが入る。PC領域１６５３により、
そのジヨブの資源である番号付きポート５０１が
識別される。状態領域１６５４により、ジヨブの
型、即ち、優先度、時間規定、またはチヤネル・
ウエイトなどが確認される。エイジ（age）領域
１６５１の意味は、領域１６５４によつて識別さ
れるようなジヨブの種類に依存する。優先度のあ
るジヨブの場合、エイジ領域１６５１は、そのジ
ヨブの優先度番号を保持し、時間的に規定された
（時間規定）ジヨブの場合は、エイジ領域１６５
１は、そのジヨブが実行される時間を保持し、チ
ヤネル・ウエイト・ジヨブの場合は、エイジ領域
１６５１は、対応するチヤネル番号を保持する。

優先度付きのジヨブには、PC10のパツチ２１
から来るサービス要求がすべて含まれる。サービ
ス要求は、パツチ２１によつて生成されるとき
に、自動的にそのように指定される。具体的に
は、パツチ２１は、基本的なサービス要求に、自
動的に所定の優先度を割り当てる。この実施例に
おいては、PCのサービス要求は、１の優先度が
割り当てられている。優先度付きのジヨブは、リ
クエスト・スケジユラ１６０１によつて、スケジ
ユール・サポート関数１６０７のPUTQ関数を
呼び出すことにより、ジヨブ・キユー１６０８上
に置かれる。優先度付きのジヨブは、実行するた
めに優先度に基づいて選択されると、ジヨブ・キ
ユー１６０８から削除される。領域１６５０によ
つて指定された関数が、ジヨブ・キユー１６０８
から削除されると、領域１６５２および１６５３
を引数として受け取る。

時間規定ジヨブは、実時間を基に呼び出され
る。これらのジヨブは、ユーザ関数によつて、ス
ケジユール・サポート関数１６０７の
TIMEOUT関数を呼び出すことにより、ジヨ
ブ・キユー１６０８に置かれる。時間規定ジヨブ
が呼び出されるフオーマツトには、待ち時間、時
間終了時に呼び出される関数名、この関数を呼び
出しているポート５０１の番号、および呼び出し
時にその関数に渡すべきものが入つているユーザ
により初期化される文字列へのポインタが、含ま
れる。この関数は、前記の待ち時間が過ぎると、
ジヨブ・キユー１６０８から削除され、そして、
指定された関数が実行される。ジヨブ・キユー１
６０８に留まる必要のある関数は、TIMEOUT
関数の働きによつてスケジユールを組み直さなけ
ればならない。

チヤネル・ウエイト・ジヨブは、事象（通常
は、リクエスト・サーバの外部の事象）の発生を
持つジヨブである。これらは、次のように、ユー
ザ関数１６０３によつて、優先度付きの関数に応
答するように設定されちる。即ち、PC１０の要
求を表す優先度付きのジヨブが、１つ以上のチヤ
ネル・ウエイト・ジヨブを生成可能なユーザ関数
１６０３を呼び出して、非同期の幾つかのタスク
の終了を待つと、非同期のタスクの終了により、
応答する部分、即ち、チヤネル・ウエイト・ジヨ
ブが呼び出される。

チヤネル・ウエイト・ジヨブが呼び出されるフ
オーマツトには、事象の発生時に呼び出される関
数名、チヤネル番号、そのジヨブについて待機
（休止）しているポート５０１の番号、および呼
び出し時に呼び出された関数に渡すべき情報の文
字列へのポインタが、含まれる。チヤネル番号
は、メツセージ・サポート関数１６０６によつて
提供される、メツセージ・キユーに基づくインタ
フエースのメツセージ・キユーにあるジヨブを一
義的に識別するのに役立つ一義的な番号に過ぎな
い。スケジユール・サポート関数１６０７には、
一義的なチヤネル番号を返すために呼び出すこと
ができるGETCHANNEL関数が含まれる。具体
的には、GETCHANNEL関数は、ある数から開
始して、それが呼び出されるたびに増加させなが
ら、一義的なチヤネル番号を生成する。チヤネ
ル・ウエイト・ジヨブは、ユーザ関数１６０３に
よつて、スケジユール・サポート関数１６０７の
CHANNEL関数を呼び出すことにより、ジヨ
ブ・キユー１６０８に置かれる。チヤネル番号
は、ジヨブ・キユー１６０８の記録事項１６４０
におけるエイジ領域１６５１に使用される他、メ
ツセージ・キユーにおけるメツセージ型としても
使用される。メツセージ・キユーにおいて、ある
チヤネル・ウエイト・ジヨブのチヤネル番号と型
が一致するメツセージを受け取ると、そのチヤネ
ル・ウエイト・ジヨブは、実行され、ジヨブ・キ
ユー１６０８から削除される。

リクエスト・スケジユラ１６０１の役目は、到
来する要求の優先度を整理し、適切なユーザ関数
１６０３を呼び出し、さらにジヨブ・キユー１６
０８および関係付けられた状態を処理することで
ある。リクエスト・スケジユラは、非同期の事象
の発生によつて起動されると、ドライバ３１が新
たな要求を受け取つたことを確認し、その新たな
要求をジヨブ・キユー１６０８に置き、さらに、
特定の事象の発生に応じて、ジヨブ・キユー１６
０８の中から実行させるに相応しいジヨブを実行
させる。リクエスト・スケジユラ１６０１を第１
７図〜２０図に示す。

リクエスト・スケジユラ１６０１は、初期化に
際し、ステツプ1701において、メツセージ・サポ
ート関数１６０６を用いて、通常のUNIXシステ
ムのようにリクエスト・サーバ３２をメツセー
ジ・キユーに結合させる。また、スケジユラ１６
０１は、ステツプ1702において、ジヨブ・キユー
１６０８も初期化する。次に、ステツプ1703にお
いて、制御／状態ポート５０２を開き、さらに、
ステツプ1704において、IOCTLコールによつて、
クローバル・マスク・レジスタ５０９を設定し、
番号付きポート５０１のオープン、クローズ、お
よびライトの動作時にリクエスト・サーバ３２を
復活させる。ここで行われる動作に含まれるの
は、入力バツフア５２１および出力バツフア５２
２の大きさを設定すること、さらに、オープン時
に休止し、クローズ時に休止し、出力バツフア５
２２が空の場合のリード時に休止し、入力バツフ
ア５２１が一杯の場合のライト時には休止せず、
かつ通常のコードを返すようにポート制御レジス
タ５０７を設定することである。

ステツプ1701〜1705におる初期化手続きの最中
に、スケジユラ１６０１がエラーを検出した時は
いかなる場合も、ステツプ1707〜1708に示したよ
うに終了する。

初期化の後、スケジユラ１６０１は、ステツプ
1709において、スケジユール・サポート関数１６
０７を用いて、ジヨブ・キユー１６０８における
時間規定ジヨブの存在を調べる。ジヨブ・キユー
１６０８にそのようなジヨブがある場合、リクエ
スト・サーバ３２は、ステツプ1710において、通
常のUNIXシステムの信号処理方法で、アラーム
を設定する。しかし、ジヨブ・キユー１６０８が
初期化された直後であり、ジヨブが存在しないの
で、スケジユラ１６０１は、ステツプ1711におい
て、IOCTL（sleep）コールによつて、リクエス
ト・サーバ３２をドライバ３１上で休止させ、番
号付きポート５０１の動作を待たせる。

ステツプ1712において、番号付きポート５０１
上の動作、またはドライバ３１の制御／状態ポー
ト５０２にwakeupコールを送ることによつて、
リクエスト・サーバ３２が、復活する。復活する
と、スケジユラ１６０１は、ステツプ1713におい
て、スケジユール・サポート関数１６０７を用い
て、ジヨブ・キユー１６０８における時間規定ジ
ヨブの存在を調べる。時間規定ジヨブが存在する
場合、スケジユラ１６０１は、後の動作中に前記
のアラームが鳴り出すのを防ぐために、ステツプ
1753において、SIGALRM信号によつて標準
UNIXシステムのALARM関数をリセツトする。
ジヨブ・キユー１６０８に期間規定ジヨブが存在
しない場合、またはステツプ1753に続いて、スケ
ジユラ１６０１は、ステツプ1714において、前記
の復活の一部として戻された値を調べて、何が原
因で復活したかを判断する。

戻された値が、０を越える場合、リクエスト・
サーバ３２は、番号付きポート５０１上の動作の
結果として復活したことになる。したがつて、ス
ケジユラ１６０１は、ステツプ1715において、そ
の休止に関係付けられた準備済みプロセス構造体
（ドライバ３１のサービス・キユー５３０の内容
が入つている）の内容を調べて、それが空かどう
か、つまり要求が全てサービスされたかどうか
を、判断する。この時点では、要求のサービスは
開始されていないので、サービス済みの要求はな
いはずであるから、スケジユラ１６０１はステツ
プ1716に進む。

ステツプ1716において、スケジユラ１６０１
は、準備済みプロセス構造体の中から次のサービ
ス要求を取り出す。つぎに、スケジユラ１６０１
は、ステツプ1717および1721において、その要求
の原因領域を調べて、いずれのポート動作によつ
て復活したかを判断する。

ステツプ1717において、復活の原因がポート
「open」コールであるとわかつた場合、スケジユ
ラ１６０１は、ステツプ1718において、IOCTL
（ポート制御を参照）コールを用いて要求中のポ
ート５０１のポート制御レジスタ５０７のＡ−
WRTフラグ６０１およびＡ−RDフラグ６０２
をセツトすることにより、そのポートの入力バツ
フア５２１が一杯の場合ライト時と、そのポート
の出力バツフア５２２が空の場合のリード時に、
そのポート５０１に関係付けられたPC１０が、
休止するようにする。また、スケジユラ１６０１
は、ステツプ1719において、ポート・マスク・レ
シスタ５０８を設定することにより、そのポート
５０１のリード・ライト、およびクローズ時に、
リクエスト・サーバ３２を復活するようにする。
そして、スケジユラ１６０１は、ステツプ1732に
おいて、要求中のポート５０１にIOCTL
（wakeup）コールを発する。

ステツプ1721において、復活の原因がポートの
「write」コールであることがわかつた場合、スケ
ジユラ１６０１は、ステツプ1722において、
IOCTL（read）コールを用いて、要求中のポート
５０１の入力バツフア５２１を読み出し、それか
らPCの要求を得る。スケジユラ１６０１は、ス
テツプ1723において、その要求の分析をパーサ１
６００に依頼し、ステツプ1724において、パーサ
１６００がエラーを報告するか否かを調べる。パ
ーサ１６００がエラーを報告した場合、スケジユ
ラ１６０１は、ステツプ1727において、IOCTL
（flush）コールを用いて、要求中のポート５０１
のバツフア５２１および５２２を空にし、ステツ
プ1728において、IOCTL（write）コールを用い
て、要求中のポート５０１の出力バツフア５２２
に、PC１０に対するエラー・メツセージを書き
込む。

ステツプ1724でパーサ１６００がエラーを報告
せずに、スケジユラ１６０１に分析した要求を渡
した場合、スケジユラ１６０１は、ステツプ1725
において、関数テーブル１６０２において要求さ
れたユーザ関数を探す。ステツプ1726に示したよ
うにテーブル１６０２において見付からなかつた
場合、スケジユラ１６０１は、ステツプ1727およ
び1728と進み、要求中のポート５０１のバツフア
を空にし、ユーザにエラー・メツセージを返す。
テーブル１６０２において要求されたユーザ関数
を見付けた場合、スケジユラ１６０１は、ステツ
プ1729において、要求の優先度が含まれている要
求のエイジ領域１６５１の値を調べて、その有効
性を判断する。優先度の値が、10を下回りかつ０
以上ではないならば、それは無効であるが、スケ
ジユラ１６０１は、ステツプ1730において、単
に、その値を最低の優先度である９に設定する。
ステツプ1729において優先度が有効である場合、
またはステツプ1730に続いて、スケジユラ１６０
１は、ステツプ1731において、スケジユール・サ
ポート関数PUTQを依頼して、その要求をジヨ
ブ・キユー１６０８に置く。

PUTQは、それに応じて、新たなキユー記録
事項のためのメモリ空間の割り当てをオペレーテ
イング・システム３０に依頼し、記録事項の領域
に要求情報を書き込み、その新たな記録事項をジ
ヨブ・キユー１６０８を成すジヨブのリストに結
合し、さらにジヨブ・キユー１６０８に関係付け
られたグローバル変数を管理する。

ステツプ1717〜1720において、復活の原因がオ
ープンまたはライト以外のポート動作による（つ
まり、ポート・リードによるか、またはポート・
クローズによる）ものである場合、またはポート
のオープンおよびライトのために行われる前記の
動作に続いて、スケジユラ１６０１は、ステツプ
1732において、要求中のポート５０１にIOCTL
（wakeup）コールを発して、そのポートで休止
しているもの、例えばPC１０など、を復活させ
る。次に、スケジユラ１６０１は、ステツプ1715
に戻り、未決の要求が全てサービスされたかどう
かを判断する。

ステツプ1715において、休止準備済みプロセス
構造体によつて示さるる未決の要求がすべてサー
ビス済みである場合、スケジユラ１６０１は、ス
テツプ1735において、IOCTL（poll）コールをド
ライバ３１に発して、スケジユラ１６０１の復活
以降に新たな要求が成されたかどうかを判断す
る。IOCTL（poll）は、IOCTL（sleep）と全く同
様に、サービス・キユー５３０の内容を準備済み
プロセス構造体の中に入れて返す。次に、スケジ
ユラ１６０１は、ステツプ1736において、その構
造体の内容を調べて、新たなサービス要求がある
かどうか判断する。ある場合、スケジユラ１６０
１は、ステツプ1715に戻つて、それらの要求に応
える。

ステツプ1736の判定時に新たなサービス要求が
ない場合、スケジユラ１６０１は、ステツプ1737
において、ジヨブ・キユー１６０８における優先
度付きジヨブの存在を調べる。具体的には、前記
のように、PUTQによつて維持されているグロ
ーバル変数を調べることによつて行う。優先度付
きジヨブがある場合、スケジユラ１６０１は、ス
テツプ1738において、引数としてPRIORITYと
いうジヨブ型を渡してスケシユール・サポート関
数１６０７のRUNQルーチンを呼び出すことに
よつて、その優先度付きジヨブを実行させる。
RUNQルーチンは、第２１図に示す。

ステツプ1737において、優先度付きジヨブがな
い場合、スケジユラ1601は、ステツプ1739におい
て、ジヨブ・キユー１６０８にチヤネル・ウエイ
ト・ジヨブがあるかどうかを調べる。ある場合、
スケジユラ１６０１は、ステツプ1740において、
メツセージ・キユーを調べて、チヤネル・ウエイ
ト・ジヨブへのメツセージがそれに入つているか
どうかを判断する。これは、具体的には、メツセ
ージ・サポート関数１６０６を呼び出すことによ
つて行う。呼び出されると、この関数は、メツセ
ージ・キユーを探査し、リクエスト・サーバ３２
にアドレス指定されたメツセージを見付け、それ
を第１のメツセージとして返す。そのメツセー
ジ・キユーに、チヤネル・ウエイト・ジヨブへの
メツセージがある（つまり、スケジユラ１６０１
に返されるメツセージがある）場合、スケジユラ
１６０１は、ステツプ1741において、第２１の
RUNQルーチンを呼び出し、CHANNELという
ジヨブ型と受信したメツセージとを引数として渡
す。RUNQが戻るときに、スケジユラ１６０１
は、ステツプ1740に戻つて、メツセージ・キユー
に、チヤネル・ウエイト・ジヨブに対するメツセ
ージがさらにあるかどうかを調べる。

ステツプ1739において、ジヨブ・キユー１６０
８に、チヤネル・ウエイト・ジヨブがないとわか
つた場合、スケジユラ１６０１は、ステツプ1742
において、ジヨブ・キユー１６０８に期間規定ジ
ヨブが入つているかどうかを調べる。ある場合、
スケジユラ１６０１は、ステツプ1743において、
第２１図のRUNQルーチンを呼び出し、TIMER
というジヨブ型を引数として渡す。

ジヨブ・キユー１６０８に期間規定ジヨブがな
いか、若しくはステツプ1740でチヤネル・ウエイ
ト・ジヨブへのメツセージがメツセージ・キユー
にない場合、またはステツプ1738若しくは1748に
おけるRUNQのリターンに続いて、スケジユラ
１６０１は、ステツプ1709に戻つて、あるかもし
ない時間規定ジヨブに対しアラームを設定した
後、ドライバ３１上で休止状態に戻る。

ステツプ1714においてリクエスト・サーバ３２
の復活の一部としてスケジユラ１６０１に返され
た値が、０ならば、リクエスト・サーバ３２は、
制御／状態ポート５０２で行われた「wakeup」
コールの結果として復活したことになる。リクエ
スト・サーバ３２を復活させるためには、制御／
状態ポート５０２を識別するIOCTL（wakeup）
コールを、制御／状態ポート５０２に対して何時
発してもよい。そのシステム内の別なプロセス
が、リクエスト・サーバ３２にメツセージ・キユ
ーを読ませたい場合、この方法を用いれば、リク
エスト・サーバ３２を復活させることができる。
これによつて、非同期の事象を契機として、種々
の機能を果たすプロセスに即座にサービスを行わ
せることが可能となる。

スケジユラ１６０１は、wakeupコールに応じ
て、ステツプ1750において、ジヨブ・キユー１６
０８にチヤネル・ウエイト・ジヨブがあるかどう
かを調べる。ある場合、スケジユラ１６０１は、
ステツプ1751において、メツセージ・キユーを調
べて、チヤネル・ウエイト・ジヨブへのメツセー
ジがそれに含まれているかどうかを判断する。含
まれている場合、スケジユラ１６０１はステツプ
1752において、第２１図のRUNQルーチンを呼
び出し、CHANNELのジヨブ型および発見した
メツセージを引数としてそれに渡す。RUNQが
戻るとき、スケジユラ１６０１はステツプ1751に
戻つて、メツセージ・キユーにチヤネル・ウエイ
ト・ジヨブへのメツセージが更にあるかどうかを
調べる。

ステツプ1750において、ジヨブ・キユー１６０
８にチヤネル・ウエイト・ジヨブが含まれていな
いか、またはステツプ1751において、チヤネル・
ウエイト・ジヨブへのメツセージがメツセージ・
キユーにない場合、スケジユラ１６０１は、ステ
ツプ1735に進み、新たなサービス要求を求めてド
ライバ３１を調べる。

ステツプ1714において、リクエスト・サーバ３
２の復活の一部としてスケジユラ１６０１に返さ
れた値が、０を下回る場合、リクエスト・サーバ
３２は、時間規定ジヨブ・アラームの満了などの
信号を受信した結果として復帰されたことにな
る。満了していれば、その結果として、
ALARM関数は、引数としてTIMERを付けて第
２１図のRUNQルーチンを呼び出しており、し
たがつて、満了となつた時間規定ジヨブは、実行
させられているはずであるから、スケジユラ１６
０１は、するべきことがないので、結局、ステツ
プ1709において、ALARM関数を再起動するこ
とになる。しかし、ステツプ1709に戻る前に、ス
ケジユラ１６０１は、ステツプ1735に進み、新た
なサービス要求を求めてドライバ３１を調べる。

第２１図は、RUNQルーチンの流れ図である。
ステツプ1800において、引数としてジヨブ型を付
けて呼び出されると、RUNQは、要求されたジ
ヨブを求めてジヨブ・キユー１６０８を探査し、
見つけて、それを実行する。RUNQは、ステツ
プ1801において、ジヨブ・キユー１６０８の先頭
にある第１の記録事項１６４０からはじめて、キ
ユーの記録事項１６４０を順番にアクセスし、ス
テツプ1802において、その記録事項がヌル
（null）かどうか、即ち、それがジヨブ・キユー
１６０８の最後かどうか、を調べる。最後なら
ば、RUNQは、ステツプ1816において、戻るの
みである。

アクセスした記録事項１６４０が、ヌルの記録
事項でない場合、RUNQは、ステツプ1804にお
いて、その状態領域１６５４の内容を調べて、引
数としてRUNQに渡される型のジヨブが、そこ
に定義されているかどうかを判断する。そうでな
い場合、RUNQは、ステツプ1801に戻つて、次
の順番にキユー記録事項１６４０を取り出して調
べる。しかし、そのジヨブが所望の型のジヨブで
ある場合、RUNQの以降の動作は、ステツプ
1805、1808、および1810に示したようなジヨブ型
に依存する。

ジヨブが、ステツプ1805で判定されるような優
先度付きジヨブの場合、RUNQは、ステツプ
1806において、記録事項の中でジヨブの優先度が
入つているエイジ領域１６５１を調べて、それが
ゼロかどうか判断する。ゼロでない場合、
RUNQは、ステツプ1807において、エイジ領域
をデクリメントして、そのジヨブの優先度を高め
た後、ステツプ１801に戻つて、次の順番のキユ
ー記録事項１６４０を取り出して調べる。そのジ
ヨブの優先度がゼロの場合、RUNQは、そのジ
ヨブを実行させるために、ステツプ1813におい
て、キユー記録事項１６４０の関数アドレス領域
１６５０によつて特定される１つのユーザ関数１
６０３を、これに引数として引数領域１６５２お
よびPC領域１６５３を渡して、呼び出す。次に
RUNQは、ステツプ1814において、ジヨブ・キ
ユー１６０８から、その記録事項１６４０を削除
する。ステツプ1815に示したように、実行された
ジヨブがチヤンネル・ウエイト・ジヨブである場
合、RUNQは、ステツプ1816において、スケジ
ユラ１６０１に戻り、そのほかの場合は、ステツ
プ1801に戻つて、次の順番のジヨブ・キユー記録
事項１６４０を取り出して調べる。

ステツプ1808で判断されるように、ジヨブが、
チヤネル・ウエイト・ジヨブである場合、
RUNQは、キユー記録事項においてジヨブのチ
ヤネル番号が入つているエイジ領域１６５１を調
べて、引数としてRUNQが受け取つたチヤネル
番号が、それと一致するかどうかを判断する。一
致する場合、RUNQは、ステツプ1813に進み、
そのチヤネル・ウエイト・ジヨブを実行させる。
一致しない場合は、ステツプ1801に戻つて、次の
順番のジヨブ・キユー記録事項１６４０を取り出
して調べる。

ステツプ1810において判断されるように、ジヨ
ブが時間規定ジヨブである場合、RUNQは、ス
テツプ1811において、キユー記録事項内でジヨブ
の実行されるべき時間を示すエイジ領域１６５１
を調べて、これをアラーム・タイマーの現在の値
と比較する。タイマーの値がエイジ領域の値を越
えている場合、まだそのジヨブを実行する時間で
はないので、RUNQは、ステツプ1801に戻つて、
次の順番のジヨブ・キユー記録事項１６４０を取
り出して調べる。それ以外の場合、RUNQは、
ステツプ1813に進み、その時間規定ジヨブを実行
させる。

ジヨブが未知の型である場合、RUNQは、ス
テツプ1812において、エラーを記録して、表示コ
ンソール上に表示した後、ステツプ1816におい
て、スケジユラ１６０１に戻る。

ユーザ関数１６０３は、システムによつて異な
る。システム構成面からみた特定のシステムによ
つて異なる。システム構成面からみた特定のシス
テムと、それが適用されるアプリケーシヨンとの
要求に合うように、ユーザ関数１６０３が提供さ
れる。しかしながら、システムの説明を完全にす
るために、このような関数の具体例を、以下にお
いて簡単に説明する。

第２２図に流れ図を示したLOCKREQユーザ
関数は、ステツプ1950において、リクエスト・ス
ケジユラ１６０１によつて、LOCKREQ要求に
応じて呼び出される。この関数は、ステツプ1955
において、要求されたフアイルを求めてローカ
ル・フアイル・システムを探査する。ステツプ
1956において、フアイルが見つからない場合、
LOCKREQ関数は、ステツプ1957において、要
求中のPC１０に「フアイルがありません」のメ
ツセージを返すように関数１６０４に依頼した
後、ステツプ1962において、戻る。

ステツプ1956において、フアイルが見つかつた
場合、LOCKREQ関数は、ステツプ1958におい
て、それが、あるユーザにロツクされているかど
うかを調べる。そのフアイルがロツクされている
場合、この関数は、ステツプ1961において、要求
中のPC１０に「フアイルはありますが、ロツク
されています」のメツセージを返すように関数１
６０４に依頼した後、ステツプ1962において、戻
る。

ステツプ1958において、フアイルがロツクされ
ていない場合、LOCKREQ関数は、ステツプ
1954において、フアイル記述情報を調べて、その
フアイルはロツク可能かどうかを判断する。可能
な場合、ステツプ1959において、それをロツクす
る。具体的には、要求中のPC１０のIDをフアイ
ルシステム中のそのフアイルに関係付ける。ステ
ツプ1954においてフアイルがロツク可能でないこ
とがわかつた場合、またはステツプ1959に続い
て、LOCKREQ関数は、ステツプ1960において、
要求中のPC１０に「フアイルがありました」の
メツセージを返すように関数１６０４に依頼した
後、ステツプ1962において、戻る。

UNLOCKREQユーザ関数（図示せず）は、リ
クエスト・スケジユラ１６０１によつて、
UNLOCKREQに応じて呼び出される。パツチ２
１に関連して説明したように、この要求は、PC
１０のユーザ・プログラム２００が終了するとき
に、パツチ２１によつて発生される。現在のユー
ザ・プログラム２００にロツクされたすべてのフ
アイルFILENAMESは、その要求に付随するも
のであり、UNLOCKREQ関数に引数として渡さ
れる。UNLOCKREQ関数は、それらのフアイル
を求めてローカル・フアイルシステムを探査し、
それらのロツクを解除する。これは、具体的に
は、そのフアイルから現在の所有者のIDを取り
去る代わりに、それらのフアイルの各々にデイフ
オルトの所有者IDを結合させることによつて行
われる。

NETGETユーザ関数は、これがPC１０からの
NETGET要求が入つたジヨブ・キユー１６０８
の記録事項１６４０を処理する準備が整つたとき
に、RESRCGET関数（第２４図）またはリクエ
スト・スケジユラ１６０１によつて呼び出され
る。NETGET関数の構造は、SNAGET関数の
構造とほぼ同じであり、後者は、それがPC１０
からのSNAGET要求が入つたジヨブ・キユー１
６０８の記録事項１６４０を処理する準備が整つ
たときに、リクエスト・スケジユラ１６０１によ
つて呼び出される。従つて、SNAGET関数およ
びNETGET関数の両方を、第２３図にまとめて
示す。

それが、リクエスト・サーバ３２によつて処理
さるる最初のNETGET要求であり、ステツプ
1901において判断されるように、NETSVR３３
を要求するプロセスが存在しない場合、ユーザ関
数はそれを生成する必要がある。まず、ユーザ関
数は、ステツプ1902において、スケジユール・サ
ポート関数１６０７のGETCHANNELルーチン
を呼び出すことによつて、チヤネルを割り当て
る。次に、ユーザ関数は、ステツプ1903におい
て、プロセス・サポート関数１６０５へのコール
によつて、サーバ・プロセス３３または３４を生
成し、ステツプ1904において、そのプロセスへの
引数として、メツセージ・サポート関数１６０６
のメツセージ・キユーのIDおよびユーザ関数が
GETCHANNELから得たチヤネルIDを渡して、
それを、リクエスト・サーバ３２から外に向か
い、新たに生成されたサーバ・プロセス３３また
は３４に達する通信に使用できるようにする。

サーバ・プロセス３３または３４が、生成され
るか、ステツプ1901で存在していた場合、それに
要求が送られる。サーバ・プロセス３３または３
４からの復路通信を処理できるように、ステツプ
1905において、GETCHANNELへのコールを行
つて、チヤネルをもう一つ割り当てる。次に、ユ
ーザ関数は、ステツプ1905において、その要求を
吟味・分析することにより、そこから引数を取り
出すと共に、サーバ・プロセス３３または３４が
その要求へのサービスを終了したときにいずれの
型の動作が必要かを判断する。そして、ユーザ関
数は、ステツプ1907において、もう一つのユーザ
関数を選択し、それより、サーバ・プロセス３３
または３４からの通信の戻りを待つチヤネル・ウ
エイト・ジヨブを生成する。ユーザ関数は、次に
ステツプ1908において、スケジユール・サポート
関数１６０７のCHANNELルーチンを呼び出し
て、前記のチヤネル・ウエイト・ジヨブをジヨ
ブ・キユー１６０８に置く。復路チヤネルIDは、
そのジヨブのエイジ領域１６５１に置かれる。ユ
ーザ関数は、ステツプ1909において、往路チヤネ
ルを介してサーバ・プロセス３３または３４を呼
び出し、さらに要求および復路チヤネルIDを引
数としてサーバ・プロセス３３または３４に渡す
ように、メツセージ・サポート関数１６０６に依
頼する。

サーバ・プロセス３３または３４は、このタス
クを終了すると、CHANNEL型のメツセージを
メツセージ・キユーに入れて返し、さらにドライ
バ３１のポート５０２にIOCTL（wakeup）コー
ルを発して、ポート５０２で休止中のものを復活
させる。

wakeupコールは、ステツプ1920において、第
１８図において既に説明したように、スケジユラ
１６０１に、そのチヤネルに結合されているチヤ
ネル・ウエイト・ジヨブを実行させ、これが、ス
テツプ1921において、そのチヤネル・ウエイト・
ジヨブによつて特定され、リターン・メツセージ
を処理するユーザ関数を呼び出す。この関数は、
終了すると、ステツプ1922において、リターン・
コード・サポート関数１６０４を用いて、要求中
のPC１０に状態情報を返した後、ステツプ1923
において、リクエスト・スケジユラ１６０１に戻
る。

パツチ２１との関連において説明したように、
LPTプロセスによつてドライバ３１に書き込ま
れたプリンタ要求は、「RESRC １ LPT １
FILENAME」の形式をとる。ここで、RESRC
は、優先度１を有する優先度付きジヨブとして呼
び出されるべきユーザ関数を指定するコマンドで
あり、LPTは、優先度１を有する優先度付きジ
ヨブとして他の中間コンピユータ１１上で呼び出
されるべき関数を指定するコマンドであり、そし
てFILENAMEは、印字されるフアイルの名前で
ある。プリンタ要求は、資源要求の具体例であ
る。資源要求は、PC１０または中間コンピユー
タ１１上で実行中のプロセスから発することがで
きる。これらの要求は、資源要求識別子RESRC
と優先度の後に、資源クラス識別子（LPTが一
例である）と優先度があり、その後に引数、さら
にオプシヨンでサブクラス識別子があるという形
式をとる。

リクエスト・サーバ３２が、資源要求を含むジ
ョブを処理する準備ができている場合、リクエス
ト・スケジユラ１６０１は、ユーザ関数である
RESRCGET関数を呼び出し、その要求のサブク
ラスおよび引数部分（例えば、「LPT １
FILENAME」の部分）を引数として渡す。
RESRCGET関数を、第２４図に示す。

RESRCGET関数は、ステツプ1950において呼
び出されると、第２３図のNETGETユーザ関数
に渡す変数を特定の値に設定し、これにより、ス
テツプ1951において復路チヤネル・ウエイト・ジ
ヨブを生成する元となる特定のユーザ関数を、
NETGETに選択（ステツプ1907）させる。つぎ
に、RESRCGET関数は、その要求に資源要求と
して印を付けるために、ステツプ1952において、
その要求に所定の接頭文字を加える。最後に、
RESRCGETは、ステツプ1953において、前記の
変数および要求を引数として付けてNETGET関
数を呼び出す。そして、RESRCGETは、ステツ
プ1954において、戻る。

第２３図に戻る。RESRCGETの指示により
NETGETがステツプ1907においてチヤネル・ウ
エイト・ジヨブを生成する元となるユーザ関数
は、ステツプ1921において、実行される。この関
数は、単に、要求された資源がNETSVR３３に
よつて発見されているかどうかを判断するだけで
ある。発見済みである場合、ステツプ1922で、
「pass」の状態情報が返されるようにし、発見済
みでない場合は、「失敗」の状態情報が返される
ようにする。

第２５図の資源クラス・ユーザ関数は、第２６
図〜３１図のNETSVR３３の説明後に述べる。

サーバ・プロセス（第２６図〜３６図） NETSVR３３は、２つの機能部分からなる。
即ち、他の中間コンピユータ１１上のNETSVR
３３からの要求を受け取るアクセプタ、および他
の中間コンピユータ１１上のNETSVR３３への
要求を生成するリクエスタである。

第２６図および２７図にNETSVRのリクエス
タを示す。ステツプ2000において、最初の
NETGETコールによつて起動されると、そのリ
クエスタは、ステツプ2001において、オペレーテ
イング・システム３０の3BNET媒体１４のドラ
イバを通常どおり開いて初期化する。次に、ステ
ツプ2002において、媒体１４に接続された
NETSVR担体（つまり、NETSVR３３のコピ
ーを備えた中間コンピユータ１１）をすべて載せ
たテーブルを、自ら使用するために作成する。リ
クエスタは、この情報をオペレーテイング・シス
テム３０のフアイルから通常どおり入手する。次
に、ステツプ2003において、制御／状態ポート
502を指定してIOCTL（wakeup）コールをドライ
バ３１のポート502に発することにより、リクエ
スト・サーバ３２を復活させる。そして、リクエ
スタは、ステツプ2004において、メツセージ・キ
ユー上で休止して、リクエスタ・サーバ３２から
の要求の受信を待つ。

メツセージ・キユーが・リクエスト・サーバ３
２から要求を受信すると、ステツプ1005におい
て、リクエスタが復活する。リクエスタは、ステ
ツプ2005において、メツセージ・キユーからメツ
セージを取り出し、ステツプ2007において、媒体
１４に接続された、それ自体を含めた、すべての
NETSVR担体に対し、そのメツセージが媒体１
４のドライバとの通常の相互作用によつて送られ
るようにする。そして、リクエスタは、ステツプ
2008において、その要求への応答を待ちながら休
止する。

応答が受信されると、リクエスタは、ステツプ
2010において、復活させられる。リクエスタは、
ステツプ2011において、媒体１４のドライバから
の受信応答を取り出し、ステツプ2012において、
その応答を調べて、要求されたフアイルまたは資
源が見つかつたかどうか判断する。見つかつてい
ない場合、リクエスタは、ステツプ2013におい
て、それが最後に待たれた応答か、つまり網の他
のすべてのNETSVR担体からの応答が既に受信
されたかどうかを判断する。そうであるなら、リ
クエスタは、ステツプ2014において、要求された
フアイルまたは資源が見つからなかつたことを示
すメツセージを、メツセージ・キユーを介してリ
クエスト・サーバ３２に返した後、ステツプ2004
において、メツセージ・キユー上で休止状態に戻
り、資源サーバ３２からの新たな要求を待つ。応
答が、ステツプ2013において、最後に期待された
ものでない場合、リクエスタはステツプ2008にお
いて、単に休止に戻り、さらになる応答を待つ。

ステツプ2012において、応答により、フアイル
または資源が発見されたことがわかる場合、リク
エスタは、ステツプ2015において、要求項目が、
フアイルか、資源かを判断する。資源である場
合、リクエスタは、ステツプ2016において、資源
が発見されたことを告げるメツセージをリクエス
タ・サーバ３２に返す。そして、リクエスタは、
ステツプ2004において、メツセージ・キユー上で
休止する。

ステツプ2015において、要求項目がフアイルで
あると判断した場合、リクエスタは、ステツプ
2017において、その応答を調べ、それがロツクさ
れているユーザがあるかどうかを判断する。ロツ
クされている場合、ステツプ2018において、それ
を示すメツセージをリクエスト・サーバ３２に返
し、ステツプ2004において、メツセージ・キユー
上で休止する。

ステツプ2017において判断した時に、フアイル
がユーザにロツクされていない場合、そのフアイ
ルは、媒体１４によつて、応答の一部として送ら
れ、バツフアに置かれているはずである。従つ
て、リクエスタは、ステツプ2019において、その
バツフアからそのフアイルを取り出し、それを中
間コンピユータ１１のフアイルシステムに入れ、
さらにステツプ2020において、それを要求中のユ
ーザにロツクする。次に、リクエスタは、ステツ
プ2012において、フアイルを発見しロツクしたの
で要求中のユーザが利用できる旨のメツセージ・
キユーを介してリクエスタ・サーバ３２に返す。
そして、リクエスタは、ステツプ2004において、
メツセージ・キユー上で休止する。

第２８図〜３１図に、NETSVRのアクセプタ
を示す。アクセプタは、それが常駐する中間コン
ピユータ１１の初期化時に生成・起動される。ア
クセプタは、ステツプ2100において、起動される
と、ステツプ2101において、それ自体を初期化し
て、ローカル・サーチ・パス・テーブルを設定す
る。このテーブルには、アクセプタが、所与のフ
アイル名を有するフアイルを求めて探査する場合
に、たどることができる、いくつかの選択可能な
サーチ・パスが、定義される。アクセプタは、こ
の情報を、オペレーテイング・システム３０のフ
アイルから得る。また、アクセプタは、ステツプ
2102において、そのコンピユータ上で利用可能な
資源を指定するローカル資源テーブルを設定す
る。この情報も、オペレーテイング・システム３
０のフアイルから得る。次に、アクセプタは、ス
テツプ2103において、オペレーテイング・システ
ム３０にある、媒体１４のドライバ３１を通常ど
おり開いて初期化する。そして、アクセプタは、
ステツプ2104において、休止に入り、他の中間コ
ンピユータ１１のNETSVR33からの要求を媒体
１４を介して受信するのを待つ。

要求が受信されると、アクセプタは、ステツプ
2105において、復活させられる。アクセプタは、
ステツプ2106において、媒体１４のバツフアから
要求を取り出し、ステツプ2107および2108におい
て、それを吟味することにより、その要求がフア
イルに対するものか、資源に対するものかを、そ
れぞれ判断する。資源の要求は、RESRCGET関
数によつて追加されたそれらを識別するための接
頭文字によつて識別される。要求が、これらのい
ずれでもない場合、アクセプタは、ステツプ2109
において、エラーを記録し、ステツプ2104におい
て、新たな要求を待つために休止に入る。（要求
は、このように中断されるので、その要求を発し
たNETSVRリクエスタは、応答を受信しないこ
とになる。これにより、オペレーテイング・シス
テム３０の制御下で時間満了となり、その要求を
発したPC１０に失敗のリター・コードが送られ
る。これは、システムに致命的な欠陥がない限
り、起こつてはならないことである。） ステツプ2107の判断で、要求がフアイルである
場合、アクセプタは、ステツプ2110において、ロ
ーカル・サーチ・パス・テーブルの記録事項を用
いて、そのフアイルを求めてローカル・フアイル
システムを探査する。ステツプ2112において、フ
アイルが見つからない場合、ステツプ2112におい
て、否定的応答メツセージを要求発生源に送つた
後、ステツプ2104において、休止に入つた、新た
な要求を待つ。

ステツプ2113において、発見されたフアイルが
ロツクされていない場合、アクセプタは、ステツ
プ2115において、そのフアイルが実行可能か、つ
まりプログラム・フアイルかどうかを調べる。実
行可能でない場合、アクセプタは、ステツプ2116
において、そのフアイルをロツクする。ステツプ
2115において、フアイルが実行可能である場合、
またはステツプ2116において、フアイルをロツク
した後で、アクセプタは、ステツプ2117におい
て、媒体１４と相互に作用し、ステツプ2117にお
いては、肯定的応答メツセージを、ステツプ2118
においては、フアイルのコピーを、媒体１４を介
して要求発生源に送る。ステツプ2119の判断で、
フアイルがデータ・フアイルである（つまり、実
行可能なフアイルでない）場合、アクセプタは、
ステツプ2120において、それをローカル・フアイ
ルシステムから削除する。フアイルが実行可能な
フアイルである場合、または削除に続いて、アク
セプタは、ステツプ2104において、休止に入り、
新たな要求を持つ。

ステツプ2108においては、要求が資源に対する
ものである場合、アクセプタは、ステツプ2121に
おいて、資源テーブルを探査し、ステツプ2122に
おいて、その資源が、そのコンピユータ上で入手
可能かどうかを判断する。資源が、そのテーブル
にない場合、アクセプタは、ステツプ2123におい
て、媒体１４のドライバと作用し合うことでもつ
て、その旨のメツセージを要求の資源である網構
成体に送るようにした後、ステツプ2104におい
て、休止に入り、新たな要求を待つ。資源がテー
ブルにある場合、アクセプタは、ステツプ2126に
おいて「資源あり」のメツセージを要求発生源に
送る。次に、アクセプタは、ステツプ2128におい
て、関数RASSISTを呼び出し、ドライバ３１の
番号付きポート５０１に要求を書き込む。そし
て、ステツプ2104において、休止に戻り、新たな
要求を待つ。

パツチ２１を扱つた節において既に述べたよう
に、プロセスは、番号付きポート５０１を獲得し
て、PC１０のように、それを開き、それに書き
込むことができる。RASSIST関数は、そのよう
なプロセスである。この関数は、NETSVRアク
セプタのプロセスの拡張として機能し、アクセプ
タがドライバ３１上で休止するのを防いで効率を
向上させるために別個のプロセスとして実現され
る。第３１図に、RASSISTを示す。

RASSIST関数は、それが常駐する中間コンピ
ユータ１１の初期化の際に、ステツプ2210におい
て、起動される。RASSISTは、ステツプ2211に
おいて、ドライバ３１の番号無しポート５００を
開き、さらにステツプ2212において、それを読む
ことにより。それから番号付きポート５０１を獲
得する。次に、RASSISTは、ステツプ2213にお
いて、番号無しポート５００を閉じ、ステツプ
2214において、その割り当てられた番号付きポー
ト５０１を開く。通常のUNIXシステムのよう
に、RASSISTは、ステツプ2215において、
NETSVRアクセプタに対しメツセージ・キユー
を生成して開く。このキユーは、一定の識別子を
有するため、NETSVRアクセプタは、キユーの
存在を察することができるので、その存在の知ら
せを受ける必要はない。次に、RASSISTは、ス
テツプ2216において、メツセージ・キユー上で休
止に入り、入力を待つ。

NETSVRアクセプタが、要求をメツセージ・
キユーに書き込むと、ステツプ2217において、
RASSISTが、復活させられる。そして、
RASSISTは、ステツプ2218において、メツセー
ジ・キユーから要求を取り出し、ステツプ2214で
開いた番号付きポート５０１に要求を書き込む。
そして、ステツプ2216において、メツセージ・キ
ユー上で休止に戻る。資源要求が、RASSISTに
よつてドライバ３１に書き込まれると、この要求
は、要求された資源が位置する中間コンピユータ
１１で、そのコンピユータ上の要求として処理さ
れる。ドライバ３１に書き込まれる要求は、本来
の資源要求の資源クラス部分および、引数部分で
ある。換言すれば、この時は、既に資源要求識別
子RESRCは、前に付いていないのである。した
がつて、リクエスト・サーバ３２が、ジヨブ・キ
ユー１６０８から、この要求を取り出すときは、
RESRCGET関数は呼び出さず、代わりに、その
要求の資源クラス部分に相当するユーザ関数を呼
び出す。

典型的な資源クラスのユーザ関数を、第２５図
に流れ図で示す。このユーザ関数は、ステツプ
2500において呼び出されると、ステツプ2501にお
いて、要求の引数部分を分析し、ステツプ2502に
おいて、要求を満たすためには、他のコンピユー
タで入手可能なデータを必要とする（例えば、要
求により、そのコンピユータ上で利用できないフ
アイルを表示することになつている場合）かどう
かを判断する。そうでない場合、ステツプ2505に
おいて、ユーザ関数は、そのクラスの資源のため
の通常のUNIXシステム・ドライバのような、
UNIXシステムをサポートするプロセスを呼び出
して、通常のUNIXシステムの要領で要求を満足
させる。要求が満たされると、ステツプ2506にお
いて、関数は、終了する。

ステツプ2502において、他のコンピユータで入
手可能なデータが必要なことがわかつた場合、ユ
ーザ関数は、ステツプ2503において、第２３図の
NETGETユーザ関数を呼び出して、要求された
データが入つているフアイルを、前記のように探
して入手する。NETGET関数の実行後、ステツ
プ2504においてそのチヤネル・ウエイト・ジヨブ
が資源クラスユーザ関数に戻ると、ユーザ関数
は、ステツプ2505に進み、要求を満たす、 第３２図に示すように、APISVR３４は、
SNAドライバ２２０３からなるSNAリンク１５
を介してメインフレーム・コンピユータに接続さ
れたIBMのSNA Ｉ／Ｏシステムへのアプリケー
シヨン・プログラム・インタフエース（API）を
提供するライブラリ２２００へのコールを行うユ
ーザ・レベルのプロセスであるる。APISVRは、
SNAドライバ２２０３のためのプレゼンテーシ
ヨン空間２２０１として役立つようにリンク時に
APIライブラリ２２００に結合された、中間コン
ピユータ１１のメモリ３７の空間を使用する。

この実施例においては、中間コンピユータ１１
は、UNIXシステム・ベースの装置であるため、
ユーザのコンソール（図示せず）は、AT＆Ｔの
Te3278端末エミユレータ２２０２を介してSNA
ドライバ２２０３と通信を行う。これによつて、
メインフレーム・コンピユータ１２からは、コン
ソールが、3278端末のように見える。端末エミユ
レータ２２０２は、プレゼンテーシヨン空間２２
０１でプロトコルの変換を行い、SNA入出力フ
オーマツトからUNIXシステム・キヤラクタＩ／
Ｏフオーマツトに写像する。

第３３図〜第３６図に、APISVR３４の流れ
図を示す。APISVR３４は、ステツプ2800にお
いて生成されると、ステツプ2801において、プレ
ゼンテーシヨン空間２２０１を初期化し、メツセ
ージ・キユーのIDおよび生成時に渡された制御
チヤネルIDを格納する。次に、ステツプ2802に
おいて、SNAドライバ２２０３の実行を通常ど
おり開始し、これを通しステツプ2803〜2819にお
いて、APIライブラリ２２００を用いてメインフ
レーム・コンピユータ１２にログインする。次に
APISVR３４は、ステツプ2820において、メツ
セージ・サポート関数１６０６のメツセージ・キ
ユー上で休止に入り、呼び出しているユーザ関数
からの要求の受信を待つ。

ログインの手順は、次のとおりである。まず、
APISVR３４は、ステツプ2803において、「端
末」に電源が投入されたことを、メインフレー
ム・コンピユータ１２に知らせる。次に、ステツ
プ2804において、ログイン要求をプレゼンテーシ
ヨン空間２２０１に置き、さらにステツプ2805に
おいて、端末の「enter」キーの打鍵をシミユレ
ートすることにより、メインフレーム・コンピユ
ータ１２が、プレゼンテーシヨナ空間２２０１の
内容を受け取るようにする。そして、APISVR
３４は、ステツプ2806において、プレゼンテーシ
ヨン空間２２０１上で休止に入る。

コンピユータ１２が、応答をプレゼンテーシヨ
ン空間２２０１に入れて返すと、ステツプ2807に
おいて、APISVR３４か、復活させられる。
APISVR３４は、ステツプ2808において、応答
を調べることにより、それが正しいパスワードの
プロンプトかどうかを判断する。そうでない場
合、APISVR３４は、ステツプ2819において、
呼び出し中のユーザ関数にエラーを返して、中止
する。応答が正しい場合、APISVR３４はステ
ツプ2809において、パスワードをプレゼンテーシ
ヨン空間２２０１に置き、ステツプ2801におい
て、端末の「enter」キーをシミユレートした後、
ステツプ2811において、プレゼンテーシヨン空間
２２０１上で休止に入る。

これに応じて、メインフレーム・コンピユータ
１２は、プレゼンテーシヨン空間２２０１からパ
スワードを受け取る。コンピユータ１２が、応答
をプレゼンテーシヨン空間２２０１に入れて返す
と、ステツプ2812において、APISVR３４が、
復活させられる。APISVR３４は、ステツプ
2513において、応答を調べることにより、それが
正しい外部パスワードのプロンプトかどうかを判
断する。そうでない場合、APISVR３４は、ス
テツプ2819において、呼び出し中のユーザ関数に
エラーを返して、中止する。応答が正しい場合、
APISVR３４は、ステツプ2814において、その
外部（保護）パスワードをプレゼンテーシヨン空
間２２０１に置き、ステツプ2815において、端末
「enter」キーをシミユレートした後、ステツプ
2816において、プレゼンテーシヨン空間２２０１
上で休止に入る。

コンピユータ１２は、パスワードを受け取り、
応答をプレゼンテーシヨン空間２２０１に入れて
返す。これに応じて、APISVR３４は、ステツ
プ2817において復活させられ、ステツプ2818にお
いて、その応答を調べることにより、それが、ロ
グインによつて起動することを意図したアプリケ
ーシヨンからの正しいプロンプトかどうかを判断
する。そうでない場合、APISVR３４は、ステ
ツプ2819において、呼び出し中のユーザ関数にエ
ラーを返して、中止する。応答が正しい場合、
APISVR３４は、ステツプ2820において、メツ
セージ・キユー上で休止する。

要求が、（例えば、リクエスト・サーバ３２か
ら）メツセージ・キユーに届くと、APISVR３
４は、ステツプ2821において、復活させられる。
APISVR３４は、ステツプ2822において、その
要求を取り出し、その要求の種類を判断する。

ログイン要求の場合、APISVR３４は、単に
ステツプ2803に戻る。

メインフレーム・コンピユータ１２のデーター
ベース１３からの指名されたフアイルのダウンロ
ードに対する要求である場合、APISVR３４は、
ステツプ2823〜2836において、APIライブラリを
通常どおり使用して、要求されたフアイルを得
る。

APISVR３４は、ダウンロード要求に応じて、
ステツプ2823において、「クリア・スクリーン」
および「ホーム・カーソル」の端末動作をシミユ
レートし、プレゼンテーシヨン空間２２０１の特
定の領域のみでなく、その全体を受け取る必要が
あることを、メインフレーム・コンピユータ１２
に知らせる。次に、APISVR３４は、ステツプ
2824において、フアイルの検索を要求するコマン
ド、および要求されたフアイルのフアイル名を、
プレゼンテーシヨン空間２２０１に置き、さら
に、ステツプ2825において、端末の「enter」キ
ーの打鍵をシミユレートする。そして、
APISVR３４は、ステツプ2826において、要求
されたフアイルのフアイル名を有するフアイルを
ローカル・フアイル・システムにおいて、開いた
後、ステツプ2827において、プレゼンテーシヨン
空間２２０１上で休止に入る。

コンピユータ１２が、プレゼンテーシヨン空間
２２０１の内容を受け取り、それに応答を返す
と、ステツプ2828において、APISVR３４が、
復活させられる。APISVR３４は、ステツプ
2829において、その応答が、エラー・コードか、
またはフアイル・データかを判断する。エラー・
コードの場合、APISVR３４は、ステツプ2836
において、呼び出しているユーザ関数にエラー・
コードを返す。応答が、フアイル・データの場
合、APISVR３４は、ステツプ2830において、
プレゼンテーシヨン空間２２０１の内容をバツフ
アにコピーし、ステツプ2831において、そのデー
タを、コンピユータ１２で使用される形式からコ
ンピユータ１１で使用される形式に変換する。次
に、ステツプ2823において、APISVR３４は、
変換したフアイル・データを、バツフアからステ
ツプ2826でAPISVR３４が開いたフアイルにコ
ピーする。

コンピユータ１２が最後のフアイル・データで
返した情報の一部は、「エンド・オブ・データ」
コマンドである。APISVR３４は、ステツプ
2833において、この返された情報を調べることに
より、それが、このコマンドを含むかどうか、ま
たは受け取るべきバツフア分のデータが、まだあ
るかどうか、を判断する。受け取るべきデータ量
を越えるデータがある場合、APISVR３４は、
ステツプ2834において、端末の「クリア・スクリ
ーン」キーの打鍵をシミユレートすることによ
り、コンピユータ１２が次のバツフア分のフアイ
ルデータを返すようにし、さらにステツプ2835に
おいて、端末の「enter」キーの打鍵をシミユレ
ートする。そして、APISVR３４は、ステツプ
2827に戻る。

ダウンロード関数は、PC１０の要求の結果と
して直接呼び出すことのできる唯一のAPISVR
３４関数である。しかし、APISVR３４は、ロ
グイン関数およびダウンロード関数のみならず、
ログオフ関数およびアツプロード関数も、中間コ
ンピユータ１１のプロセスに提供している。いず
れの場合も、APISVR３４は、APIライブラリ２
２００を通常どおり使用して、これらの機能を果
たす。

アツプロード関数をステツプ2850〜2869に示
す。この関数により、中間コンピユータ１１のフ
アイル・システムからメインフレーム・コンピユ
ータ１２のデータベース１３に、フアイルが転送
される。APISVR３４は、アツプロード要求に
応じて、ステツプ2850において、ローカル・フア
イル・システムにあるアツプロードするべきフア
イルを開く。次に、ステツプ2851において、「ク
リア・スクリーン」および「ホーム・カーソル」
の端末動作をシミユレートし、ステツプ2852にお
いて、フアイルの格納を要求するコマンド、その
フアイルの名前、およびそのフアイルの大きさ
を、プレゼンテーシヨン空間２２０１に置き、さ
らにステツプ2853において、端末の「enter」キ
ーの打鍵をシミユレートする。そして、
APISVR３４は、ステツプ2854において、プレ
ゼンテーシヨン空間２２０１上で休止する。

コンピユータ１２が、プレゼンテーシヨン空間
２２０１の内容を受け取り、それに応答を返す
と、APISVR３４は、ステツプ2855において、
復活させられる。APISVR３４は、ステツプ
2856において、応答を調べて、それが、エラーの
応答か、またはフアイル・データのための正しい
プロンプトか、を判断する。それが、エラー応答
である場合、APISVR３４は、ステツプ2869に
おいて、呼び出しているユーザ関数にエラー・コ
ードを返す。応答が正しいプロンプトである場
合、APISVR３４は、ステツプ2857において、
プレゼンテーシヨン空間２２０１に見合うだけの
フアイルをバツフアにコピーし、ステツプ2858に
おいて、中間コンピユータ１１で使用される形式
からメインフレーム・コンピユータ１２で使用去
れる形式に、データを変換する。つぎに、
APISVR３４では、ステツプ2859において、「ク
リア・スクリーン」および「ホーム・カーソル」
の端末動作をシミユレートし、ステツプ2860にお
いて、変換したフアイル・データをバツフアから
プレゼンテーシヨン空間２２０１にコピーし、ス
テツプ2861において、端末の「enter」キーの打
鍵をシミユレートし、さらにステツプ2826におい
て、プレゼンテーシヨン空間２２０１上で休止す
る。

コンピユータ１２が、プレゼンテーシヨン空間
２２０１からデータを受け取り、受信通知を返す
と、APISVR３４は、ステツプ2863において、
復活させられる。APISVR３４は、ステツプ
2864において、その通知を調べ、エラーがあつた
かどうかを判断する。エラーがある場合、
APISVR３４は、ステツプ2869において、呼び
出しているユーザ関数にエラー・コードを返す。
エラーがない場合、ステツプ2865において、すべ
てのフアイル・データがコンピユータ１２に送ら
れたかどうか、またはバツフア分送るだけのデー
タが、まだあるかどうか、を判断する。送る量以
上のデータがある場合、APISVR３４は、ステ
ツプ2857に戻る。すべてのデータが送られた場
合、APISVR３４は、ステツプ2866において、
「クリア・スクリーン」および「ホーム・カーソ
ル」の端末動作をシミユレートし、ステツプ2867
において、終了コマンドをプレゼンテーシヨン空
間２２０１において、フアイル全体を受信したこ
とをコンピユータ１２に通知し、ステツプ2868に
おいて、端末の「enter」キーの打鍵をシミユレ
ートした後、ステツプ2820に戻り、他の要求を待
つ。

ログオフ関数をステツプ2881〜2888に示す。こ
の関数により、中間コンピユータ１１のメインフ
レーム・コンピユータ１２との対話期間が終了す
る。ログオフ要求があると、APISVR３４は、
ステツプ2881において、「クリア・スクリーン」
および「ホーム・カーソル」の端末動作をシミユ
レートする。次に、ステツプ2882において、exit
コマンドをプレゼンテーシヨン空間２２０１に置
き、ステツプ2883に置いて、端末の「enter」キ
ーの打鍵をシミユレートした後、ステツプ2884に
おいて、プレゼンテーシヨン空間２２０１上で休
止する。

コンピユータ１２は、プレゼンテーシヨン空間
２２０１の内容を受け取ると、それに受信通知に
よつて応答する。これによつて、APISVR３４
は、ステツプ2885において、復活させられ、ステ
ツプ2886において、その通知を調べて、コンピユ
ータ１２が対話を適切に終わらせたかを判断す
る。そうでない場合、APISVR３４は、ステツ
プ2888において、エラー・コードを呼び出し元に
返す。対話を適切に終わつた場合、APISVR３
４は、ステツプ2887において、成功コードを呼び
出し元に返す。