JPH04167040A - ネットワーク通信システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 （イ）産業上の利用分野 本発明は、オフィス・オートメーション（ＯＡ）・シス
テム、テレックス、テレテックス、ファクシミリ等から
なるアクセス装置間の通信を取り扱うためのネットワー
ク通信システムに関するものである。

この明細書中で使う略語及び頭文字語は、発明の詳細な
説明の最後に説明されている。データ・ゼネラルという
参照語は、本願発明の譲り受け人である「データ・ゼネ
ラル・コーポレーション」のことである。

（ロ）従来の技術 現在、多くの専用の通信システムや、メッセージ・ハン
ドリング及びデータ通信に関する種々の国際標準が有る
。それにも拘わらず、総ての種類のアクセス装置に相互
に自由な通信を許すシステムは存在しない。

同一でないノステム間でメツセージの交換を許すことを
意図するソフト・スイッチ及びメイル・バスとして商用
的に知られるゲートウェイ・システムが有ることは事実
である。しかしながら、これらの公知のシステムは、本
質的に私的な企業及び他の大きなユーザに適合するもの
である。というのは、これらは種々のゲートウェイによ
って用いられるメツセージ・プロトコル間の変換をする
中央処理システムによって取り扱われる専用のメツセー
ジ転送プロトコルを用いるからである。更にこれらは、
各ゲートウェイが、システム上に他にどのようなゲート
ウェイが有るか及び種々のゲートウェイがどのような特
徴を持っているかを知っているべき、完全なシステムと
して組み立てられ公知のシステムは公共的なサービスを
意図するものでもなく、それに適してもいない。

本発明が関係するもう１つの問題は、−時に１つの処理
スレッドしか取り扱えない単一スレッド型の計算機オペ
レーティング・システム（例えばＭＳ−ＤＯ８及びＵＮ
　Ｉ　Ｘ）に関連して生ずる。

これは、外部イベントを待機するとき処理経路が停止さ
れた場合、頻繁にルーチンが待たされる結果になる。ル
ーチンは未決（ペンド）であると言われる。他のオペレ
ーティング・システム（例えばＡＯ９／ＶＳ）は多重ス
レッドを処理できるが、本発明のシステムは特定のオペ
レーティング・システムに拘束されず、単一スレッド型
のオペレーティング・システムで動作できることが望ま
しい。

あるシステム、例えばＵＮＩＸは、メモリー内にプログ
ラムの複数のコピーを保持し異なるプロセスに対するＣ
ＰＵの割り当てを計画（スケジュール）することによっ
てマルチ・タスクを模擬する。

しかしながら、これは、メモリー資源の無駄である。Ｍ
Ｓ−ＤＯ５はこのレベルのマルチ・タスク処理を達成す
る機構をなにも内蔵していない。

常にイベント、例えば転送がインターフェースを介して
達成されるとき、が生ずるのを待機しているネットワー
ク通信システム及び単一スレッド型システムは、上述の
理由から計算機資源の利用が効率的でない。

（ハ）発明が解決しようとする課題 本発明の目的は、システム内の他のゲートウェイやノー
ドの性質またはシステムの性質の知識を必要とせずに、
拘束されない方法でゲートウェイやノードを使用するた
めに装置へのアクセスを許す、改良されたシステムを提
供することである。

「ノード」及び「ゲートウェイ」という語は、あるノー
ドは厳密な定義ではゲートウェイではないかもしれない
が、ここでは、交換可能に用いる。

より特定すれば、この改良されたシステムはＰＴＴ（電
気通信生官庁）によって利用可能であることを意図して
おり、同一のシステムまたは異なるＰＴＴによって実現
された他のシステムに接続されたアクセス装置と透過的
な通信をするために、それぞれのアクセス装置がアクセ
スできるゲートウェイを提供する。

この改良されたシステムは、例えば公共及び私的な会社
のような他の大きなユーザによって用いるのにも同様に
適している。

本発明の他の目的は、単一スレッド型のオペレーティン
グ・システムであっても、ルーチンが外部的結果を待機
して未決な状態になる必要を防止することである。その
ようなルーチンはアンペンデド・ルーチンと呼ばれる。

（ニ）課題を解決するための手段 本発明によるネットワーク通信システムは、それぞれの
アクセス装置のために働く複数のゲートウェイまたはノ
ードからなる。例えば、１つのノードはファクシミリ・
ネットワークのために働き、もう１つのノードはテレッ
クス・ネットワークのために、他のゲートウェイは、Ｃ
ＥＯ（データゼネラル・コーポレション）、ＤＩＳＯ５
Ｓ及びＰＲＯＦＳ　（両方共ＩＢＭ）等の複数の専用の
ＯＡシステムのために働く。

ゲートウェイまたはノードは、標準的なメッセージ・ハ
ンドリング・システム、好適にはＣＣＩＴＴ、Ｘ４００
標準を介して相互に通信するように接続されている。Ｘ
４００には多くのユーザによって実現されている１９８
４年版（ここては、１９８４、Ｘ４００と称する）があ
る。Ｘ４００には１９８８年版（ここでは１９８８．Ｘ
４００と称する）もあり、これが本発明のネットワーク
通信システムの「バックボーン」として好適に用いられ
るシステムである。本発明が、他の専用のメッセージ・
ハンドリング・システムでな（、このように受け入れら
れた国際標準を利用できたことは、特に有利な点である
。しかしながら、１９８８、Ｘ４００はまだ広（実現さ
れていないので、１つのゲートウェイとして、ある程度
低級な特性の１９８４．Ｘ４００と「バックボーン」と
をインターフェースし得るＸ４００ゲートウエイを提供
することが特に効果的である。

本発明によるシステムの各ゲートウェイまたはノードは
、アクセス装置またはそのゲートウェイがそのために働
く装置にアクセスするためのネットワーク・インターフ
ェースを含む。これは、ゲートウェイの外部のユーザ定
義インターフェースである。各ゲートウェイは更に、標
準的なメッセージ・ハンドリング・システム即ちバック
ボーンとメツセージをやり取りする、外部メツセージ転
送インターフェース（ＭＴ　Ｉ　）を含む。

内部的に各ゲートウェイは、ソフトウエア・インターフ
ェースを含み、それらは総てのゲートウェイに対して同
一で、更にメツセージ転送インターフェースに適合して
いる。コア・ルーチンのライブラリがメツセージ転送イ
ンターフェースとソフトウエア・インターフェースとの
通信をさせる。

このライブラリは大量のゲートウェイ・ソフトウェアを
含み、総てのゲートウェイに対して同一なので、本発明
は各ゲートウェイに多（の特別のソフトウェアを開発す
る重い負担をなくす。

各ゲートウェイは更に、そのゲートウェイに独特で、ネ
ットワーク・インターフェースとソフトウエア・インタ
ーフェースとの間で通信をさせる特別のルーチンのライ
ブラリを含む。これらのルーチンは、一方ではネットワ
ーク・インターフェースのフォーマットとプロトコル（
これらは各ゲートウェイに特有である）を変換し、もう
一方ではソフトウエア・インターフェースのフォーマッ
トとプロトコルを標準化する。これらのノード特有のル
ーチンは、各ゲートウェイのソフトウェアのより小さな
部分を占める。

コア・ルーチンによって実行される関数の例は、次の通
りである。

データのパケットを組み立ててバックボーンへ転送する
。

バックボーンからのパケットを受け取って分解する。

ディレクトリ内の宛て先アドレスを探索する。

文書を文書フォーマット変換器に与える。

記録、追跡記録、譚金、誤り処理等の総てのハウスキー
ピング機能。

特別のルーチンによって実行される関数の例は、次の通
りである。

ゲートウェイが働くネットワークで特定されたフォーマ
ットとの相互変換。

ゲートウェイが働くネットワーク内のアドレスとホスト
のバックボーン内のアドレスとの間の変換。

標準的メッセージ・ハンドリング・システム上のゲート
ウェイまたはノード間の通信は、プロトコル・データ単
位（ＰＤＵ）によって実行される。

各ＰＤＵはエンベロープ部とメツセージ部からなる（Ｘ
４００を参照）。エンベロープ部は、メツセージの発信
者と受信者とを識別するデータを含むが、メツセージ受
信者のために働くゲートウェイを特定するデータは含ま
ない。１９８８．Ｘ４００によれば、Ｐｌで表されるエ
ンベロープ部は、主として発信者、宛て先、メツセージ
優先順位及び配信報告が必要か否ｂ）の表示からなる。

Ｐ２で表されるメツセージ部は、Ｐ１データの大部分を
繰り返し主題の名称を含むヘッダ、文書タイプ識別子と
、メツセージの主体部からなる。

これは、総てのアクセス装置が、それ自身受け取り側の
ゲートウェイの性質を考えることなく、他の総てのアク
セス装置にメツセージを送ることを可能にするので、本
発明の非常に著しい特徴である。実際に発信者は任意の
ゲートウェイが含まれることを知る必要はない。本発明
によるシステムは、そのユーザに対して完全に透過的で
あり、利用者側の処置の必要なくＰＴＴによってそのメ
ッセージ・ハンドリングの能力を大幅に強化するために
実現され得る。そのうえに、このシステムはゲートウェ
イが付加されたり、除去されても再構　　　　　“成す
る必要がない。もちろん、ユーザは彼らが通信しようと
するアドレスを知る必要はあるが、それらが種々のゲー
トウェイ上にある事実は知る必要がない。これが各ＰＤ
Ｕのエンベロープ部がメツセージ受信者に対して働くゲ
ートウェイを特定するデータを含まない理由である。総
てのメツセージは単に共通メツセージ・バックボーン上
及びメツセージを受け取る受信者アドレスを認知するゲ
ートウェイに送出される。

従属的な問題が異なる文書フォーマットの存在にある。

共通に使われる種々のワードプロセッサ・フォーマット
や、種々のファイル・フォーマット及びテレックスやテ
レテックスを特定するフォーマットがある。本発明の他
の特徴は、アクセスの起動をメツセージ受信者のフォー
マットの詳細を心配する必要から楽にすることである（
しかし常識は普通に用いなければならない、即ち高度に
フォーマットされたワードプロセッサ・ファイルがテレ
ックスの受信者によって満足に取り扱われることを当て
にすることは無用である）。フォーマット変換用の文書
変換器はそれ自身知られており、本発明によるネットワ
ーク通信システムに組み込むことができる。

メツセージ部が文書（または文書の一部）からなる任意
のプロトコル・データ単位のエンベロープ部は、文書フ
ォーマットを識別するフォーマット情報を含む。各ゲー
トウェイの特定のルーチンのライブラリは、受け取った
フォーマット情報に応答して、フォーマット情報が互換
性のないフォーマットを表示するとき、メツセージ部を
自動的に文書変換器に渡すルーチンを含む。従ってゲー
トウェイは、受信者が受け取り可能な文書フォーマット
を考えることなく、もし変換が必要でもそれが自動的に
行われることの保証によって、どのような文書フォーマ
ットの転送も自由である。

１９８８、Ｘ４００のようなメッセージ・ハンドリング
・システムにおいては、メツセージ発信者及び受信者を
識別する多くの部分を含む標準的アドレス構造がある。

殆どのネットワーク・インターフェースは、より限定さ
れた範囲の異なるアドレス・フォーマットを用いる。従
って、各ゲートウェイがメッセージ・ハンドリング・シ
ステムを介してアクセスできる少なくとも１つのディレ
クトリを与えるのが良い。ライブラリ・ルーチンは、発
信者ゲートウェイにおいてメツセージの発信者と受信者
を識別するデータを１つまたは複数のディレクトリに渡
すルーチンを含む。これが、ＰＤＵのエンベロープ部に
含ませるために（メッセージ・ハンドリング・システム
によって）標準的形式の識別データを決定するために用
いられる。

他のルーチンは、少なくとも受信側のゲートウェイのネ
ットワーク・インターフェースによって要求された形式
でメツセージを受信する者を決定するために、受け取っ
たＰＤＵのエンベロープ部の識別データを１つまたは複
数のディレクトリに渡す。

好適には、システムはメッセージ・ハンドリング・シス
テム上の総てのゲートウェイによって直接にアクセス可
能なディレクトリを保持する主ディレクトリ装置を含む
。このディレクトリは、ＣＣＩＴＴ、Ｘ５００標準に従
ったものでよい。しかしながら、１つ以上の補助的なデ
ィレクトリが個々のゲートウェイ内のディレクトリ装置
に保持されてもよい。そのようなディレクトリは、他の
ゲートウェイによってメッセージ・ハンドリング・シス
テム及び保持ゲートウェイを介して間接的にアクセス可
能である。

本発明は更に、コア・ルーチンの一部として、異なるオ
ペレーティング・システム（ＭＶ計算機上のＡＯ８／Ｖ
Ｓ、ＰＣ上のＭＳ−ＤＯ３及びＭＶ計算機や他のハード
ウェア上のＵＮＩＸ）と共に動作可能なインターフェー
スを含む。このインターフェースは汎用アンペンデド・
インターフェース（ＧＵＩ）として参照される。ＣＵＴ
の下において、ルーチンがサービス供給者（プロバイダ
）、特にＧＵＩコンフォーマット・サービス・プロバイ
ダ（ＧＣ８Ｐ）、を要求しようとするとき、ユーザは適
切なルーチンを呼ぶがその完了を待つことは望まない。

そのかわり、ユーザは通知ルーチンによってそのルーチ
ンの完了を知らされる。その間にユーザは他の処理を実
行できる。

（ホ）実施例 この説明は４つの主要な節を含む。

■、システムの一般的な説明 ■、ネットワーク通信 ■、一般的なアンペンデド（ｕｎｐｅｎｄｅｄ）−イン
タフェース ■、省略及び頭字語 ここで強調しておくが、説明全体は例として提示され、
添付の特許請求の範囲によって定義されている場合を除
いて、開示されたいかなる特徴によっても限定されるこ
とはない。例えば、ＧＵＩは通信サーバー（５ｅｒｖｅ
ｒ）システムと関連して主に説明されているが、この特
定の応用に限定されない。ＧＵＩルーチンは開示された
構成を必ずしも備えてはいない。通信サーバー・システ
ム・ルーチンの組織化は変更等に無限の可能性を与える
。

更に、ルーチンの詳細なコード化とルーチンをコード化
する言語は、特定のハードウェアの内容の中で、特定の
応用に対して発明を実行するプログラマの選択事項であ
る。

■、システムの一般的な説明 第１図は、１９８８　　Ｘ４００プロトコルと少なくと
も部分的にはＸ２５パケット切り替え型メツセージ転送
プロトコルとを用いる汎用メッセージング拳バックボー
ン（ｍｅｓｓａｇｉｎｇｂａｃｋｂｏｎｅ）　１５を介
して違いに通信する複数のノード又はゲートウェー１２
を示している（ただし、それぞれのゲートウェーはその
通信経路の一部として他の媒体、例えばランド・ライン
［１ａｎｄ　１ｉｎｅ］を使用することもある）。第１
図は例として８個のゲートウェーを示している。原理的
には、ゲートウェーの数に制限はない。ゲートウェーの
例は、データ・ジェネラル・ＣＥＯ・オフィス・オート
メー７ョン・ネットワーク１３ＡのためのＣＥＯゲート
ウェー１２Ａ　　ＩＢＭ　　ＤＩＳＯ８Ｓオフィス・オ
ートメーション・ネットワーク１３Ｂのための５ＮＡＤ
Ｓゲートウェー１２ＩＢＭ　　ＰＲＯＦＳオフィス・オ
ートメーション・ネットワーク１３Ｃのための５ＮＡＤ
Ｓゲートウエー１２Ｃ Ｘ４００通信ネットワーク１３Ｄと通信する１９８４　
　Ｘ４００のためのＸ４００ゲートウニ−１２Ｄ ファックス及びテレックス・ネットワーク１３Ｅ、Ｆと
通信するファックス／テレックス・ゲートウェー１２Ｅ
０ 各ゲートウェーは標準のインターフェース又はアクセス
・ユニット１４Ａ−１４Ｆを介してそのネットワークと
接続される。明瞭にするために、各ケートウェーは単一
のネットワーク専用のものとして示されているが、こう
した構成は、少なくともいくつかのゲートウェーに関す
る限り、実際に採用され得る。他方、単一のゲートウェ
ーは複数の異なるアクセス・ユニットに奉仕する。後述
する第２図は、ファックス／テレックス（テレファック
ス）とゲートウェーとの結合されたものであり、他の例
として、ゲートウェーはＣＥＯゲートウェーでもファッ
クス／テレファックス・ケートウェーでもある。これに
より、ゲートウェーには、必要なインターフェースと各
タイプのアクセス・ユニットに対する必要な特定のルー
チンとを持つことが要求される。

第１図における全体のシステムは通信サーバー（ｃＳ）
システム１０と表示される。各ゲートウェー１２はメツ
セージ転送インターフェースに対する（ＭＩ　Ｔで表示
される）インターフェース１５Ａを備え、これらインタ
ーフェースは、「バス」１５Ｂ−任意の形の通信リンク
により物理的に構成され得る−によって指示されるよう
に、１９８８　　Ｘ４００プロトコルを介して通信する
。インターフェース１５Ａ及び「バス」１５Ｂはメツセ
ージ・バックボーン１５を構成する。また、「バス」１
５ｂはディレクトリ・サービス４８及びマスク・ドキュ
メント・コンバータ４６との通信を提供する。メツセー
ジ・バックボーン１５そのものと結合されて、これらの
サービスは通信サーバー・システム１０のホストＩＯＡ
とみなされる。

マスク・ドキュメント・コンバータ４６とディレクトリ
・サービス４８との物理的位置は重要ではない。構成的
には、それぞれはデータベースと処理ファシリティとを
備え、ゲートウェー１２の１つに又は専用ゲートウェー
に物理的に位置している。マスク・ドキュメント・コン
バータ４６はＰＣプログラムでそれ自体良く知られてい
るような変換ルーチンばかりでなく、−層複雑な応用ソ
フトウェアを実行する。ディレクトリ・サービス４８デ
ータベースは、既に述べたように、ここに援用するＣＣ
ＩＴＴ　　Ｘ５００基準に従っており、質問・探索ディ
レクトリ項目と加算・補正・削除項目に対する標準デー
タベース・ファシリティを与える。

第２図は、複数のネットワークと装置へインターフェー
スする典型的なゲートウェーの全体的なハードウェア構
成を示す。結合されたテレックス／ファックス（テレマ
チック）ゲートウェー１３Ｅ、Ｆが例示されている。複
数のコンピュータが処理容量を取り扱うことを要求され
ているとし、図の実施例はそれぞれのコンピュータ・プ
ログラムを記憶する関連のディスク・ドライブＤ１．　
Ｄ２、Ｄ３をそれぞれ備える３台のデータ・ジェネラル
ＭＶシリーズ・マルチコンピュータＭＶＩ。

ＭＶ２．ＭＶ３を含む。これらのコンピュータは、４０
０　Ｍ　ｂ　／　ｓを運ぶ標準の（密な）イーサネッ１
−ＬＡＮ又はＭＲＣバスのような高速ＬＡＮ１６によっ
て接続される。更に、コンピュータはディスク・コント
ローラ１８を介して、ユーザ・データを保持するための
ディスク・フレーム２２を（例えば）構成するディスク
・ドライブＤ４−Ｄ８のバンクへ接続される。

コンピュータは端末スイッチ２０を介して、テレックス
・インターフェース１４Ｆ１フアツクス・インターフェ
ース１４Ｅ、プリンタ・インターフェース１４Ｐとして
ここでは示されている複数のインターフェースへ接続さ
れる。端末スイッチ２０は種々のアクセス・ユニットが
コンピュータ・リソースを共用することができるように
すると共に、２台の良好なコンピュータを一方がダウン
したときに使用することができるようにし、リソースを
フレキシブルに使用することを一般的に可能とする。原
理的には、本発明は複数のコンピュータを必要とするも
のではなく、複数のコンピュータが使用される方法は本
発明の一部を形成しない。簡単に言えば、実行される入
力／出力動作に対して、正しいコンピュータが正しいイ
ンターフェースと通信することができるように、１つの
コンピュータがマスクとして動作し、他のコンピュータ
の活動を割り当て、端末スイッチ２０とＸ２５スイッチ
３２とを制御すると共に、誤り状態では別のコンピュー
タがマスクとして引き継ぐように準備する公知のマルチ
プロセッサ・システムの原理にしたがって、コンピュー
タは取り扱われる。簡単なシステムでは、１台のコンピ
ュータがあり、端末スイッチ２０は不要である。

更に、それぞれのコンピュータは、ＰＤＮ　（パブリッ
ク・データ・ネットワーク）インターフェース３４と（
また恐らくは）リースされた（　ｔｅａｓｅｄ）ライン
３６即ち別のゲートウェーとの直接接続である１つの利
用とに接続されるＸ２５スイツチ３２との接続を備える
。インターフェース３４は第１図のメツセージ転送イン
ターフェース１５Ａを与え、汎用メッセージング・バッ
クボーン１５の一部を形成する。

第３図は、別のブロック図として描かれているが、ハー
ドウェアの面よりは機能の面でゲートウェーの構成を示
している。ゲートウェーが一例としてテレックスとファ
ックスとに奉仕するテレマチック・ゲートウェーである
と再び仮定すると、実際のテレックス及びファックスの
通信は、本発明が関係しない標準アイテム、例えばＨａ
ｓｌｅｒテレックス・ユニットやファックス・カード（
例えばガンマファックスＣＰ／Ｔカード）付きのＰＣ等
によって取り扱われる。これらの標準アイテムはゲート
ウェーの１つのポートとして動作するネットワーク・イ
ンターフェース１４と通信し、第２図に示すように、複
数のインターフェースを備える。同様に、ネットワーク
・インターフェース１４はＣＥＯネットワーク、ＰＲＯ
ＦＳネットワーク等と整合を取られる。メツセージ転送
インターフェース１５Ａはメッセーンング・バックボー
ン・バス１５Ｂと通信する第２のポートを形成する。

インターフェース１４．１５Ａは全部のゲートウェーと
同じであるソフトウエア・インターフェース４４によっ
て連結される。このインターフェース４４はメツセージ
転送インターフェース１５Ａとソフトウエア・インター
フェース４４との間の通信を与えるコア・ルーチン（ｃ
ｏｒｅ　ｒｏｕｔｉｎｅｓ）のライブラリを含む。この
コア・ライブラリは単一のライブラリと機能的に常に等
価であるけれども、簡便のために、複数の個別に維持さ
れたライブラリとして扱われる。この実施例では、これ
らのライブラリはＴＯＯＬＳ、ＧＵＩ、ＡＲＴで表され
るライブラリを含む。ＧＵＩはゼネラル・アンペンデド
・インターフェースを表し、以下に詳述する。ＡＲＴは
ＡＳＮ、１　（ＩＳＯ基準）ラン・タイムス（Ｒｕｎ　
Ｔｉｍｅｓ）ライブラリ・ルーチン、即ち、ここに援用
するＩＳＯＡＳＮ、１基準にしたがったフォーマットで
データを符号化するルーチンを表す。これらのルーチン
はＴＯＯＬＳにて使用され、ＰＤＵ特に１９８８　　Ｘ
４００　　ＰＤＵを作る。

不特定ソフトウエア・インターフェース４４は特定のル
ーチン４５のライブラリによりネットワーク・インター
フェースと整合される。特定のルーチンは、それによっ
てサービスされるゲートウェーの本質にしたがって、メ
ツセージの流れを制御するのに一層高いレベルで必要な
ルーチンを含む。他方、ＴＯＯＬＳは全部のゲートウェ
ーに共通の「ツール」又はサービスを提供する。詳細に
は、ＴＯＯＬＳルーチンはＸ４００　１９８８フオーマ
ツトをＡＲＴにより構成されるＰＤＵに課し、メツセー
ジを送出し、メッセーン確認を受信し、ディレクトリ・
サービス及びドキュメント・コンバータにしたがってデ
ィスク・セイブ（ｄｉｓｋ　５ａｖｅｓ）を取り扱い、
ゲートウェーに共通に要求される他の機能を実行する。

ゲートウェーはメッセージング・バックボーン１５を介
してドキュメント・コンバータ４６及び主ディレクトリ
・サービス４８と通信する。オプションとして、独自の
サブディレクトリ・ライブラリ４９を含んでもよい。

■、ネットワーク通信 １つのネットワーク上のユーザが、対応するゲートウェ
ーを介する別のネットワーク上のユーザにゲートウェー
を介してメツセージｒＡＪを送出するとき、ネットワー
ク通信システム１０はこのメツセージをソース・ネット
ワーク（ここではＣＥＯであると仮定する）の特定のフ
ォーマットから宛て先ネットワーク（ここではＰＲＯＦ
Ｓであると仮定する）の別の特定のフォーマットへ変換
する。第４図は、ＣＥＯフォーマットのメツセージｒＡ
Ｊをシステム１０へ送るＣＥＯネットワーク１３Ａを示
す。次いで（第５図）、システム１０はメツセージをＰ
ＲＯＦＳ　（ＳＮＡＤＳ）−フォーマットへ変換し、そ
れをＰＲＯＦＳネットワーク５２へ送る。

典型的には、このプロセスは、ディレクトリ・サービス
４８にり取り扱われるアドレス変換と、特定のルーチン
４５により取り扱われるプロトコル変換と、ドキュメン
ト・コンバータ４６により取り扱われるドキュメント・
フォーマット変換とを含む。別の例をここで詳述する。

この例では、シナリオは、外部１９８４　　Ｘ４００ネ
ツトワーク（例えばＰＴＴにより提供されるもの）から
到着し、ファックス・カードを介して電話回線へ出て行
くメツセージのそれである。

第６図で、Ｘ４００ネツトワーク１３Ｄは１９８４　　
Ｘ４００ゲートウエー１２Ｄへの接続を開き、ＰＴＴネ
ットワークからのメツセージをＸ４００ゲートウエー１
２Ｄへ転送する。このメツセージは５８に示されるよう
に、ディスク即ちディスク・フレーム２２にセーブされ
る（そのため、システムが暴走しても、メツセージが失
われることはない）。

メツセージは有効性をチエツクされ、受信者がネットワ
ーク通信システム「内」にあることを保証するために、
受信者のアドレスがチエツクされる。これらの処理は、
通信ネットワークではそれ自体公知である。次いで、メ
ツセージはメツセージの待ち行列６０に置かれ、さらに
処理される。

メツセージは遠隔（ＰＴＴ）システム１３Ｄに対してア
クノリジされる。

第７図において、メツセージは１９８４　　Ｘ４００フ
オーマツトで既□・に受信されており、システムで使用
される内部フォーマットである１９８８Ｘ４００へ変換
される必要がある。従来の通信技術にしたがって、トレ
ース（ｔｒａｃｅ）情報が追加される。この情報は、メ
ツセージが通過する全／ステムを通してメツセージを追
跡するのに使用され、ループ動作中の（ｌｏｏｐｉｎｇ
）メソセージを検出するのに使用される（メツセージは
同一システムを２回通過する）。次いでメツセージはソ
フトウエア・インターフェース４４のＴＯＯＬＳへ伝え
られる。

第８図において、メツセージがどのゲートウェーへ送ら
れるべきかを知るために、ディレクトリ・サービス４８
において受信者が調べられる。発信者がネットワーク通
信システムを使用することができるかどうかを知るため
に、発信者がチエツクされる。このディレクトリ・サー
ビスの使用はそれ自体普通のことである。

メツセージの新規なコピーが記憶され（６２）、他のゲ
ートウェーのために待ち行列（６４）に配置される。

第９図において、いまメツセージは他のゲートウェー１
０（この場合ではファックス）における対等なＴＯＯＬ
Ｓへ転送される。これは、指令（ＳＵＢＭＩＴ−ＭＥＳ
ＳＡＧＥ）といくつかのデータ（この場合にはメツセー
ジ自体）が転送されることを意味する遠隔操作と呼ばれ
るものを用いて行われる。

メソセージの重複を避けるために、ンーケンス番号も送
られる。

こうして、メツセージはファックス・ゲートウェー１２
ＥのＴＯＯＬＳ４４’　にある。第９〜１２図において
、このゲートウェーの要素はプライムの付加によって区
別される。

第１０図において、メツセージは再び記憶される（７２
）。発信者の名称はＣ８ＩＤとして用いられる、人間に
読み取り可能な形（ファックス・ページの上部に現れる
ストリング）へ変換される（ｃＯＮＶ、０ＲＩＧ）。当
該溌呼者からアドレスされた受信者へディレクトリによ
り許容される呼びを禁止するために、更に呼び禁止チエ
ツクが行われる。

メツセージはファックス・ゲートウェー１２Ｈの特定の
ソフトウェア・ルーチン４５′へ渡される。ファックス
・ゲートウェー１２Ｅでは全部の動作が行われる。

第１１図において、メツセージのコピーが受信者毎に発
生されて記憶され（７６）、ダイアル番号が形成される
。回送されるファックス・アドレスのファックフォーマ
ットは９くカントリー・コード〉く国番号〉である。こ
れはダイアルするための数字列へ変換される。

いま、それぞれのコピーは待ち行列（７８）に配置され
、出線（ファックス・カード）が空きになると送出され
る。

注目されることであるが、メツセージは反復してディス
クにセーブされる。これは、メツセージの大部分がディ
スクに残り、メツセージが適切に記憶されるようにポイ
ンタを構成することにより別の「セーブ」が行われるの
で、重大なオーバーヘッドではない。コピーが削除され
るとき、最後のユーザが記憶されたメツセージを発する
まで、記憶されたメツセージ自体は削除されない。

第１２図において、ファックス・カード８２が利用可能
になる（事象として知らされる）まで、特定のルーチン
はメツセージの各コピーを待ち、次いでこのメツセージ
をファックス・ネットワーク・インターフェース・ユニ
ット８０を介してファックス・アクセス・ユニット即ち
ファックス・カードを持つＰＣ８２へ転送する。これは
、ＧＵＥＳ（ジェネリック・アンベンデド事象）ハンド
ラ（ｈａｎｄｉｅｒ）サービス（これについては後述す
る）が利用されるときの例である。

そこで、ＰＣ８２内で標準動作が行われる。（まだ内部
符号化形態である）メツセージはテキストへ変換される
。ヘッダーはその地方の言語で日時等と共にフォーマッ
ト化される。次いで、メツセージはファックス・カード
へ伝えられる。供給された番号をファックス・カードは
ダイアルし、テキストからその順番に白黒の画像へ変換
しながら、メツセージを送信する。呼びの終了時、ファ
ックス・カードはＰＣへＣ３ｌＤ（被呼加入者識別）を
返送する。ファックス・ゲートウェー１２Ｅは継続時間
及びＣ８ＩＤを含む送信結果を告げられる。

その後、他の動作がファックス・ゲートウェー１２Ｅで
行われる。（まだ記憶されたままである）メツセージが
引き出され、発信者がメツセージの完了時に何等かの通
知（良好又は不良）を要求したかどうかをチエツクする
。この報告が発生され、発信者へ返送するためにＴＯＯ
ＬＳへ渡される。

ここで、課金のために料金の記録がディスクになされる
。

第６〜１２図は、標準の１９８４　　Ｘ４００ネツトワ
ークからファックス・アクセス・ユニットへのメツセー
ジの送信に関係する。反対方向へ伝えられるメツセージ
は相補的な即ち逆の方法（これはこれまでの説明から明
らかである）で取り扱われる。

■、一般的なアンペンデド・インターフェースこの項は
以下の章からなる： 第１章：序 第２章：環境 第３章：ユーザのモデル 第４章：機能性 第５章：ＧＵＩタスク・インターフェースの例 第６章：ＧＵＩタイマ 第７章：ＧＵＩ事象ハンドラー 第８章：ＧＵＩの明細 第９章：ＧＵＴＳの明細 第１０章：ＧＵＥＳの明細 第１１章：ＧＵＩのプログラミングの例第１２章：内部
構造 第１３章：データ構成の明細 第１４章：ＧＵＩ及び通信サービス・インターフェース 第１章　序 １、ＩＧＵＩの概要 ＧＵＩは、インターフェース、外部事象及びタイマにわ
たる要求／応答相互作用を取り扱うための包括的な機構
である。また、ＧＵｒは、アプリケーションが単一の経
路での複数の筋道の処理を支持するためにアンペンデド
・サービスを利用することができる環境を提供する。こ
うした機構により、エンティティ（ｅｎｔｉｔｙ）は（
タイマの場合にはＧＵＩにより、他の場合には別のエン
ティティにより提供される）サービスを要求することが
でき、サービス提供者側のルーチンが要求を満たしなが
ら保留することなしに、サービスの完了をその後動るこ
とができる。こうして、アンペンデド要求のサービス提
供者側の処理と平行して、アプリケーションは他の有用
な処理を実行することができる。

通信サーバー・システムのような複合製品（ｃｏｍｐｌ
ｅｘ　ｐｒｏｄｕｃｔ）では、ユーザにサービス・イン
ターフェースを提供し、ぶつかり合うことなく共存しな
ければならない多くの個別に設計されたモジュールが不
可避的に存在する。従来の課題は、ユーザが従わなけれ
ばならない独自の組の規則と制約を各モジュールが持っ
ているということであり、要件の間に両立性がない。こ
れは、全モジュールを一緒にするとき多くの努力を要し
、システムにバグ（ｂｕｇｓ）が残る危険性が大きい。

例えば、外部のイベントを待つ必要があるライブラリは
該アプリケーションが時々何かが起こるかを判別するよ
うにポールされなければならないルーチンを有する。こ
れは、多分１つのライブラリには良いが、例えば１ダー
スのライブラリでは多くの時間が彼らの全部をポーリン
グする為に費やされる。伝統的なライブラリは、全部の
モジュールが処理において一緒の動作できる様に、注意
深く座標化されなければならない共用資源の排他的使用
を意図する。これは、モジュールが合体されていない時
には、孤立した状態で働く結果となる。

ＧＵＩはこの問題を、全資源（タイマ、信号および他の
外部イベント）のチャージを持つこと及び多種のライン
の全部が資源を調和状態でアクセスするために使用でき
るサービスを提供することにより解決した。ＧＵＩは根
本的な資源の唯一の直接的なユーザであるので、他のモ
ジュールを合体することに問題がないのである。付加的
な利益は、全部の外部のイベントはＧＵＩを通して到着
するので（及びその後に多種のモジュールに発送される
）、該ライブラリの全部をポールする必要がない。事実
、ＧＵＩの原理に前面的に基づくアプリケーションにお
いては、ＧＵＩは実行するジョブがないときはいつでも
可能な外部イベントの全部を自動的に待つので、全（ポ
ーリングが存在しない。これは、彼らが処理するメツセ
ージをでない時には、実質的にＣＰＵタイムを使用しな
いアプリケーションを結果的にもたらす。一般的に言っ
て、ＧＵＩが作業する方法は次ぎの遥りである。

種々の呼び出し及び跳び越しを伴う連続コードとして記
載されるプログラムに代えて、アプリケーションの主構
成はサービス提供者の要求（スケジュールジョブまたは
待ち行列上の通知）を作る。ジョブ又は通知は以下の如
く分類される。

サービスルーチンによりリターンデータ、外部イベント
が生じさせた通知、 タイムインターバルが経過した通知、 処理間隔通信（ＩＰＣ）、即ち２つのコンピュータ処理
間にパスされたメッセイジ。

原理において、１つのジョブ待ち行列だけが必要である
が、アプリケーションは異なるプライオリティを伴う多
重待ち行列にセットアツプでき及び実行するジョブのプ
ライオリティを制御する方法の如（、待ち行列またはサ
ービス提供者がジョブを配列する待ち行列を選択せきる
。アプリケーション（ユーザ）は実行すべきジョブが無
いとき実行ルーチンｇｕｉ　　ｒｕｎＯを読出す。Ｇｕ
ｉ　　ｒｕｎ（）は（ａ）待ち行列の優先度の為及び（
ｂ）各待ち行列が関連している限り第１の続出順序にお
いて待ち行列と異なるスケジュールされたジョブを実行
する。アプリケーションはそれ自身ペンドする必要はな
い。アプリケーションがアイドルである時、アプリケー
ションはペンドオプションと共にｇｕｉ　　ｒｕｎＯを
読出さねばならず、これによりｇｕｉ　　ｒｕｎＯはジ
ョブが処理間隔通信（ＩＰＣ）、以下にＧＵＥＳと示さ
れるイベント処理サイ−ビスまたは以下にＧ　　ＵＴＳ
と示されるタイマサービスによりスケジュールされるま
でペンドする。これは、−旦アイドルになると、ＩＰＣ
または外部イベントが起こるかタイマが終了するまでは
処理はさらに何も行わないとを仮定する。これが、“メ
ツセーシカミングイン”、“ファクスカードレデイ”等
またはインターバルの如きイベントに応答して作業が初
期化される通信サーバーシステムを得る状態である。

そのようなイベントは、例えばハンドシェーキングライ
ン上の論理状態の変化によって合図されるハードウェア
イベントと呼んでよいであろう。ＩＰＣはソフトウェア
イベントの如く見なされる。

入力イベントは発生したイベントを表示できる記入され
たパラメータを伴うユーザールーチンに対する呼び出し
により表されるこれらのイベントはｇｕｉ　　５ｃｈｅ
ｄｕｌｅ　Ｏの呼び出しにより待ち行列上に配置され、
それがｇｕｉ　　ｒｕｎＯを呼び出し時にメインタスク
によりピックアップされる。外部イベントはＧＵＩによ
りスケジュールさ　例えば、外部のイベントを待つ必要
があるライブラリは該アプリケーションが時々何かが起
こるかを判別するようにポールされなければならないル
ーチンを有する。これは、多分１つのライブラリには良
いが、例えば１ダースのライブラリでは多くの時間が彼
らの全部をポーリングする為に費やされる。伝統的なラ
イブラリは、全部のモジュールが処理において一緒の動
作できる様に、注意深（座標化されなければならない共
用資源の排他的使用を意図する。これは、モジュールが
合体されていない時には、孤立した状態で働く結果とな
る。

ＧＵＩはこの問題を、全資源（タイマ、信号および他の
外部イベント）のチャージを持つこと及び多種のライン
の全部が資源を調和状態でアクセスするために使用でき
るサービスを提供することにより解決した。ＧＵＮは根
本的な資源の唯一の直接的なユーザであるので、他のモ
ジュールを合体することに問題がないのである。付加的
な利益は、全部の外部のイベントはＧＵＩを通して到着
するので（及びその後に多種のモジュールに発送される
）、該ライブラリの全部をポールする必要がない。事実
、ＧＵＩの原理に前面的に基づくアプリケーションにお
いては、ＧＵＩは実行するジョブがないときはいつでも
可能な外部イベントの全部を自動的に待つので、全くポ
ーリングが存在しない。これは、彼らが処理するメツセ
ージをでない時には、実質的にＣＰＵタイムを使用しな
いアプリケーションを結果的にもたらす。一般的に言っ
て、ＧＵＩが作業する方法は次ぎの通りである。

種々の呼び出し及び跳び越しを伴う連続コードとして記
載されるプログラムに代えて、アプリケーションの主構
成はサービス提供者の要求（スケジュールジョブまたは
待ち行列上の通知）を作る。ジョブ又は通知は以下の如
く分類される。

サービスルーチンによりリターンデータ、外部イベント
が生じさせた通知、 タイムインターバルが経過した通知、 処理間隔通信（ＩＰＣ）、即ち２つのコンピュータ処理
間にパスされたメツセイジ。

原理において、１つのジョブ待ち行列だけが必要である
が、アプリケーションは異なるプライオリティを伴う多
重待ち行列にセットアツプでき及び実行するジョブのプ
ライオリティを制御する方法の如く、待ち行列またはサ
ービス提供者がジョブを配列する待ち行列を選択せきる
。アプリケーション（ユーザ）は実行すべきジョブが無
いとき実行ルーチンｇｕｊ　　ｒｕｎＯを読出す。Ｇｕ
ｉ　ｒｕｎＯは（ａ）待ち行列の優先度の為及び（ｂ）
各待ち行列が関連している限り第１の続出順序において
待ち行列と異なるスケジュールされたジョブを実行する
。アプリケーションはそれ自身ペンドする必要はない。

アプリケーションがアイドルである時、アプリケーショ
ンはベンドオプションと共にｇｕｉ　　ｒｕｎＯを読出
さねばならず、これによりｇｕｉ　　ｒｕｎＯはジョブ
が処理間隔通信（ＩＰＣ）、以下にＧＵＥＳと示される
イベント処理サイ−ビスまたは以下にＧＵＴＳと示され
るタイマサービスによりスケジュールされるまでペンド
する。これは、−旦アイドルになると、ＩＰＣまたは外
部イベントが起こるかタイマが終了するまでは処理はさ
らに何も行わないとを仮定する。これが、“メッセージ
カミンゲイン”、“ファクスカードレデイ”等またはイ
ンターバルの如きイベントに応答して作業が初期化され
る通信サーバーシステムを得る状態である。

そのようなイベントは、例えばハンドシューキングライ
ン上の論理状態の変化によって合図されるハードウェア
イベントと呼んでよいであろう。■ＰＣはソフトウェア
イベントの如く見なされる。

入力イベントは発生したイベントを表示できる記入され
たパラメータを伴うユーザールーチンに対する呼び出し
により表されるこれらのイベントはｇｕｉ　　５ｃｈｅ
ｄｕｌｅ　Ｏの呼び出しにより待ち行列上に配置され、
それがｇｕｉ　　ｒｕｎＯを呼び出し時にメインタスク
によりピックアップされる。外部イベントはＧＵＩによ
りスケジュールされえる事にだけではない。れえる事に
だけではない。ペンドされないた要求の完了はスケジュ
ールされえる他の明瞭なりラスのユーザールーチンであ
り、メインタスク内のライブラリまたはユーザーのいず
れかが実行しているルーチンはそれが実行されることが
必要であり多少時間後に実行されるであろう一般的な処
理をスケジュールできる。アプリケーションがそれ自身
の処理を行っている時、それは、例えばタイマ誤りを生
じることにより又はネットワーク使用法または応答時間
に影響することによる、ンステムの分裂を十分に連続的
に回避する為にｇｕｉ　　ｒｕｎＯに復帰しなければな
らない。該アプリケーションは次にＧＵｌをポールして
もよいがアプリケーションが一般的なアプローチの如き
多くのハンドラーでなく１つの“イベントハンドラー”
をポールしなければならないことを認めることは重要で
ある。アプリケーションメインタスクは待ち行列を配置
する。

該待ち行列はそれが要求する各優先度のレベルのための
待ち行列標識またはキイドにより示される。

ライブラリルーチンが呼び出されるとそれはそのジョブ
をスケジュールしなければならないキイドを告げなけれ
ばならない。一般に、外部イベントは、高い優先度キイ
ドを与えられ、他方一般な内部処理が低い優先度キイド
を与えられる。

アイデアルアプリケーションの構成はメインルーチンの
以下のアウトラインにより示される。

ｍａｉｎ（） １ｎｉｔｉａｌｉｓｅ　５ｅｌｆ； １ｎｉｔｉａｌｉｓｅ　ＧＵＩ； ａｌｌｏｃａｔｅ　ｇｕｉｄｓ、　ｆｏｒ　ｒｅｑｕｉ
ｒｅｄ　ｐｒｉｏｒｉｔｉｅｓ；１ｎｉｔｉａｌｓｅ　
ａｌｌ　１ｉｂｒａｒｉｅｓ；ｍａｙｂｅ　５ｃｈｅｄ
ｕｌｅ　１ｎｉｔｉａｌ　ｊｏｂｓ　ａｎｄ　５ｔａｒ
ｔ　ａｎｙｒｅｇｕｌａｒ　ｔｉｍｅｒ； ｄｏ　ｆｏｒｅｖｅｒ ｇｕｉ　ｒｕｎ（ＰＥＮＤ） ｇｕｉ　　ｒｕｎ用のペンドオプションの表示はセクシ
ョン４．１．４で説明される。

外部イベント処理および内部ライブラリ処理の全てはｇ
ｕｉ　　ｒｕｎ□に対する読出からのスケジュールされ
たジョブの如（行われる。内部ライブラリ処理は内部の
ペンドされないリクエストルーチンかジョブランからス
ケジュールされ、これは以下にＧＣ３Ｐ’　　ｓと示さ
れた内部サービスを与える外部イベント故である。この
理想的な例において、アプリケーションのそれ自身の処
理はスケジュールされたジョブの如くに実行される。

これはアプリケーションに第１のジョブまたはそれがｇ
ｕｔ　　ｒｕｎＯを読出す前に行われることが必要であ
るジョブをスケジュールすることを要求し、アプリケー
ションはあとでさらなるジョブを常にスケジュールでき
る。この構成は、行うことが無い時にプロセスが自動的
にｇｕｉ　　ｒｕｎ　Ｏ内をスリープし且つアプリケー
ションコードがＧＵＩメカニズム内に統合されるという
利益を有する。しかしながら、本発明は、ユーザルーチ
ンにペンドされたｇｕｉ　　ｒｕｎＯを気付かせること
ができ且つＧＵＩにアイドルユーザループを気付かせる
ことがでる“ｗａｋｅｕｐ”ルーチンを任意的に与える
。

１．２ＧＵＩ及びオペレーティング・システムＧＵＩは
、アプリケーションがＶＳとＮＵＩＸの如き見掛は的に
非両立的なオペレーションシステムの間で携帯可能であ
る様にアプリケーションを記載可能である。ＵＮＩＸは
、ＭＳ−ＤＯ３はリアル、ハイドウェア割り込みを使用
し、ところがＵＮＩＸはソフトウェア割り込みを使用す
る違いを有するＭＳ−ＤＯ３に適用される。ＭＳとＵＮ
ＩＸとの基本的な違いはＶＳ処理はマルチスレートであ
りＵＮＩＸ処理はそうでないことである。

ＶＳの下で、マルチスレート（ＶＳタスク）が可能であ
り、。全は同一処理アドレス空間内に見掛は的に同時的
に実行される。他方、ＵＮＩＸ下で、ソフトウェア割り
込みの使用により他の割り込みレベルパスをホストでき
るが、処理において唯一のスレートランニングが存在す
る。しかしながら、ＶＳは、ＮＵＩＸルーチン０との比
較で、ユーザ処理のメインタスクを割り込むソフトウェ
ア用のドキメントされた機構を有しない。ＭＳ下では、
アプリケーションは外部イベントを待機するために奉納
されたＶＳタスクを使用する。

これらの非両立性にもかかわらず、ＧＵＩ内に記載され
たアプリケーションはｖＳまたはＵＮＩＸ下で実行でき
、アプリケーションは２つのオペレーションシステムに
対する特徴事項は使用されない。したがって、非使用は
ＧＵＩユーザによってＶＳマルチスレートを作成しなけ
ればならず、非使用はＵＮＩＸ割り込みを作成しなけれ
ばならない。比較において、アプリケーションは単一メ
インタスクにより記載されねばならず、割り込み又はイ
ベントはＢＵＩフレームワーク内のイベント処理者によ
り処理されなければならない。ネットワーク通信の如き
“サービス”書込みアプリケーションにおいては、資源
の使用実時間が他のメツセージの処理により作成され間
イベント待機のために多（の時間がペンドされるので、
単一処理内で多くのアイテムが並列に処理されることが
尤も好ましい。ＧＵＩはこの要求を処理でき且つ基礎を
なすオペレーションシステムにかかわらず同じである環
境を与える。マルチメツセージを効率的に処理するため
に資源を用いる公知のアプリケーションパッケージはあ
るオペレーションシステムに特有のものである。上述の
通信サーバーシステム内にＧＵＩがどのように使用され
るかの例はこの記載の１４章に記載される。

１．３　　用語法 ＧＵＩはサービスを与える為の１組のプログラムにより
記載されたライブラリとサービスの使用を作る為に異な
るプログラムで記載されたユーザコードとの間のインタ
ーフェースを与える。ＧＵＩを用いるライブラリコード
はＧＵＩ−Ｃｏｎｆｏｒｍａｎｔ　　５ｅｒｖｉｃｅ　
　Ｐｒｏｖｉｄｅｒ　（ＧＣＳＰ）と呼ばれる。該ユー
ザコードは単にＵｓｅｒと呼ばれる。この記載を通して
、ＧＵＩにより与えられたルーチンは開始“ｇｕｔ”（
例えば、ｇｕｉ　　５ｃｈｅｄｕｌｅ）により示される
。ＧＣＳＰにより与えられたルーチンは開始“ＧＣＳＰ
−”で示され、Ｕｓｅｒにより記載されたルーチンは“
ｕｓｅｒ−”で始まる。

以下は本記載で使用されたタームのリストである。

Ｐｅｎｄ　　その処理パスが外部イベントを待つ間に停
止になるならルーチンをペンドす る。例えば、多くの■Ｓシステム呼出 は該呼出がＶＳバス上で実行される間 呼出タスクをペンドする。

Ｕｎｐｅｎｄｅｄ　　　　待機外部イベントがペンドさ
れない間ペンドしないルーチン。

Ｔａ５ｋ　　他の処理実行スレートから論理的に分離さ
れた処理のスレート／ Ｍａｉｎ　　Ｔａ５ｋ　　　プロセス中のメイン処理ス
レート Ｐａｔｈ　　他の処理の実行スレートから物理的に分離
された処理のスレート。Ｐａｔｈ はマルチＶＳ−Ｔａｓｋの場合の如き Ｐａｒａｌｌｅｌまたは割り込みレベ ルバス且つベースレベルパスの場合の 如きＮｅ５ｔｅｄである。

ＶＳ−Ｔａｓｋ　　物理的にスケジュールされた構成要
素であるパスはＡＯ８／ＶＳオペ レテイング・システム下で？ＴＡＳＫ システム続出により作られる。

ＧＣＳＰ　　ＧＵＩ　　Ｃｏｍｆｏｒｍａｎｔ　　５ｅ
ｒｖｉｃｅ　　Ｐｒｐｖｉｄｅｒ　　ＧＵ■規則および
フォーマットを一致させ るサービスを与えるライブラリ。

Ｕｓｅｒ　　ＧＣ８Ｐのサービスを要求するためにＧＵ
Ｉ使用を成させるコード 第２章　環境 ２．１　　ハードウェア及びＯ８環境 ＧＵＩの目的はＯ８とハードウェア環境の適に依存させ
るインターフェースを与えることである。

これは、例えばＭＶ上でＡＯ８／ＶＳ、ＰＣ上（７）Ｍ
Ｓ−ＤＯＳおよびＭＶまたはたのハードウェア上のＮＵ
ＩＸ下で作業することを意味する。ＭＳ−ＤＯＳおよび
ＵＮＩＸは単一スレーデッドである。この記載は１つ以
上のメインタスクを有するマルチタスクおよびイベント
待機タスクについて述べいる。ＭＳ−ＤＯＳおよびＵＮ
ＩＸ環境において、この用語法はベースレベル“メイン
タスク”と１対の割り込みレベルサービスルーチン“タ
スク“とを同一視する。ＧＵＩはユーザが幾つかの“メ
インタスク”を持つことを許すが、この特徴はＭＳ−Ｄ
ＯＳまたはＵＮＩＸ下において有用でないことに注意を
要する。他のＯ８への将来のポートのための要求の可能
性のためにＡＯ３／ＶＳ下でさえ唯一のメインタスクを
持つことが提案される。マルチタスクを持つ可能性はマ
ルチタスクされたプログラムの実行をＧＵＩの使用の変
換するプログラムを補助することを意図する。物理的な
環境がどのようであろうと、ＧＵＩは単一アドレススペ
ースにおいて実行されるように強制されている。分離し
たアドレススペースにおける実行の存在、例えば２つ異
なるｖＳまたはＵｒｌＸ処理、の間のインターフェース
を供給しない。

２．２　　言語の条件 能率上の理由故に、一般的なＧＵＩライブラリはＣ読出
規則（即ち、バリューウによる続出）で読出される様に
設計されている。ＧＵＩはこの同一の規則でユーザに適
用されたルーチンを読出す。

ＡＯＳ／ＶＳ下で、ＰＬ／ｌの如き言語は、ＧＵＩを使
用したＣｌ１ｃ出規則と両立性でない外部続出シーケン
ス（ＶＳ／ＥＣ８）とよばれる番地読出規則を使用する
。これはＧＵＩはＰＬ／Ｉから直接的に読出しができず
、ＰＬ／Ｉルーチンはｇｕｊ　　５ｃｈｅｄｕｌｅ（）
を用いてスケジュールできないことを意味する。必要が
生じれば、ＧＵｌ（７）ＰＬ／ＩバージョンはＣコード
の薄い層を各ＧＵｌ側に加えることにより実施できる。

１つの層は、パラメータを変換し、その後一般的なＧＵ
Ｉルーチンを読出すＥＣ８読出可能ルーチンを供給しえ
る。コードの他の層はｇｕｉ　　５ｃｈｅｄｕｌｅｄＯ
であることを必要とするＰＬ／Ｉルーチンを要求し、実
際的にスケジュールされその後にＰＬ／Ｉルーチンを修
飾されたパラメータフォーメットで読出すＣルーチンか
らなる。

第３章　ユーザのモデル ＧＵＩユーザのモデルはペンドされない方法でサービス
提供者の要求を作らせことを要求する構成要素である。

要求の作成の為に、ユーザはそれが要求するサービスを
明瞭にするルーチンを読出す。要求を実施するのに要求
されたアクションは長いので、ユーザは即時に完了する
まで待機することを望まず、むしろ終了した時を知るこ
とを望む。これは、ペンドしない要求の基本的な内容で
ある。要求の完了をユーザに告げる方法はユーザのより
提供される通常ＧＵＩにより読出される通知ルーチンで
ある。

３．１　　アンベンデド要求の例 第１３図の描かれた以下の例を考察する。ユーザ１３０
はキーボードからの入力ラインの読取りを望むが、入力
がまだ利用できなければペンドすることを望まず、入力
の利用のための繰り返して赤なポールのも望まない。こ
の機能はＧＣ３Ｐにより与えられるペンドしない要求に
より満足されえる。ＧＣ８Ｐライターは要求ルーチン１
３１を与える。このルーチンは“ＧＣ８Ｐ　　ｇｅｔ　
　１ｉｎｅＯ”　と呼ばれ、これは入力が利用出来る時
を読出すユーザ通知ルーチン１３７の引き数の如きアド
レスを取る。要求ルーチンはサービスを初期化しペンド
なしにリターンする。

要求がＧＣ８Ｐ要求ルーチンにより初期化される多くの
方法がある： （１）ラインが利用可能になるまで、キーポ−ド割り込
みがある毎に入力文字をセーブする割り込みハンドラー
をセットアツプする。

（２）ペンドされた続出を行い、入力ラインが受信され
た時にメインプロセスを信号するプロセスを大量に生じ
る。

（３）ペンドされた続出を行い、入力が完了したときに
通知ルーチンを読出すタスクを大量に生じる。

これらは可能性があり（１）は典型的なＭＳ−ＤｏＳ用
であり、（２）　はＵＮＩＸ用であり、（３）はＭＳ用
である。

一度要求ルーチンがリターンすると、ユーザはそれが行
うでき他の処理１３２を実施できが、該処理はｇｕｉ　
　ｒｕｎＯに対する続出を含まなければならない。この
ユーザの為に確立された処理の２つの分離したスレート
があり、これは（１）メインタスクと（２）他のプロセ
スまたは分離したＶＳ形式タスクにおける割り込みでレ
ベルでの処理により処理される要求処理タスク１３４で
ある。要求タスクが要求の完了を検出したとき（即ち、
１３５と示される様な入力ラインを受信した時）キッド
上のユーザの通知ルーチン１３７を要求結果（入力のラ
イン）で置き換える為にｇｕｉｓｃｈｄｕｌｅ（）を読
出す。１３８で示される様にｇｕｉ　　ｒｕｎＯが次に
読出されるとき通知ルーチンはキッドを切断しユーザ処
理タスクはそれが要求された入力のラインを得る。通知
ルーチンまたはジョブがキッドに置かれ、外されること
はべんりである。キッド上におかれたものは通知ルーチ
ンのアドレスとこのルーチンのための引き数であり、第
２４図に説明される。第１３図の場合には、引き数は入
力ラインの文字である。

本例の全部はＧＵＩなしに成就されえ、他のケースの場
合にはそう簡単でない。どのようなケースでも、ＧＵＩ
は、使用されているオペレーテングシステムを独立させ
る方法の如き機構におけるＧＣ８Ｐ−ライターとユーザ
ライターの両方を目的とするフレームワークを、供給す
る。

第４章　機能性 この章は、ペンドされない環境をサポートするためにＧ
ＵＩにより供給されたルーチンを記載することにより開
始する。その後で、ペンドされないインターフェースを
サポートするためにＧＣ３Ｐの要求されたルーチンとＧ
ＵＳＰユーザとを記載する。

４、ＩＧＵＩ提供ルーチン ＧＵＩのライブラリ部分（その用法を支配するルーチン
に対立する）は後時での実行用、任意ユーザルーチンの
スケジュール用の機構を与える。

スケジュールされたルーチンの１つを使用した一般的な
タームはジョブである。ＧＵＩは、ジョブ（ｇｕｉ　　
５ｃｈｅｄｕｌｅ）を待つためのルーチンと、ユーザが
これらのジョブを実行する準備するときに読出されるべ
きルーチン（ｇｕｉ　　ｒｕｎ）を与える。付加的な柔
軟性の為に、ＧＵＩは、割り当て時間で彼らに関連する
異なる優先度を持つことができるマルチ待ち行列ジョブ
をサポートする。

４、　１．　　Ｉ　　ＧＵＩ初期化　ｇｕｉ−ｉｎｉｔ
ｉａｌｉｓｅ　□このルーチンはパラメータを取らない
。他のＧＵｌルーチンが読出される前に、それは各成分
（各ＧＣ３Ｐとユーザ）により続出去れねばならない。

４１２キュー割り当て 上述の如＜、ＧＵＩはスケジュールされたジョブのマル
チ待ち行列を与える。これは、ユーザにジョブの相対優
先度を明瞭化させえ、他の論理的クラスから分離してい
る待ち行列上の論理的クラスを形成するジョブを訂正さ
せえる。各ＧＵＩ待ち行列１ｊＱＵｅｕｅ指標（ＱＵ　
Ｉ　Ｄ）を有し、このＱＵＩＤは、待ち行列が割り当て
られたときに、即ちｇｕｉ割り当てｇｕｉ（優先度、ユ
ーザーウェイクアップ　キッド−ｐｔｒ）の如く、ＧＵ
Ｉにより割り当てられる。

この続出の為のパラメータは以下の通りである。

＊ｐｒｉｏｒｉｔｙ　　−他の待ち行列に関連し、この
待ち行列と外れたジョブ実行用の優先度を明示する。

＊ｕｓｅｒ　　ｗａｋｅｕｐ　　−この待ち行列上で実
行される得るジョブがあるときはいつでもＧＵＩが読出
すユーザの与えられたルーチンを任意的に明示する。

＊ｑｕｉｄ　　ｐｔｒ　　−ＧＵＩはこの待ち行列に関
連した待ち行列指標によってこのパラメータ内を満たす
。

割り当てられた各待ち行列はそれに割り当てられたパス
である親を有する。

ＶＳ下で、上に説明された適応性の理由故にこれは提案
されないが、ＧＵＩ待ち行列の割り当てが可能であるマ
ルチパス（ＶＳ−Ｔａ　ｓ　ｋ　ｓ）が存在できる。単
一スレードオベレーテングシステム下で、メインスレー
トだけが待ち行列の割り当てるを許される（例えば、彼
らは割り込みレベルから割り当てされれない）。パスは
待ち行列上のジョブをスケジュールするが、親だけが待
ち行列からずれたジョブを実行できる。これは以降の“
ｇｕｉ　　ｒｕｎＯ”の項で述べられる。

４．１．３　　ジョブ・スケジューリングＧＵＩは、特
定のタスクに対して（ＶＳのために）、一定の引き数を
有する特定のルーチンがコールされるようにするため、
ユーザ及びＧＣ３Ｐがコールできる次のようなルーチン
を与える：ｑｕｊ　　５ｃｈｅｄｕｌｅ　（ｑｕｉｄ、
ｒｏｕｔｉｎｅ、ａｒｇｌ、ａｒｇ２．ａｒｇ３．ａｒ
ｇここで、引き数は次の通り・ ＊ｑｕｉｄ−ｒルーチン」がスケジュールされるべきキ
ュー ＊ｒｏｕｔ　１ｎｅ−ＧＵＩがコールすべきルーチンに
対するポインタ ＊ａｒｇｌ・・・ａｒｇ４−「ルーチン」をコールする
引き数 このＧＵＩルーチンはベンドせず、このコールの結果、
ＧＵＩは、特定のキューのオウナーがｑｕｉ　　ｒｕｎ
をコールするとき、「ルーチン」をコールする。従って
、そのルーチンは次のようにコールされる： （＊ｒｏｕｔ　ｉｎｅ）（ａｒｇｌ、ａｒｇ２．ａｒｇ
３．ａｒｇ４、ｑｕｉｄ） ｒａｒｇＮＪパラメータはポインタ（ＭＶに対して３２
ビツト、ＰＣに対して１６または３２ビツト）を含むほ
ど大きくすることができるが、ＧＵＩはそれらを通して
インダイレクトしない。従って、それらのパラメータは
、要求されるように整数またはポインタを通過させるの
に使用することができる。後者の場合、ｑｕｉ　　５ｃ
ｈｅｄｕｌｅのコーラは、スケジュールされたルーチン
が実際に実行されてしまうまで、そのポインタが妥当性
を維持することを確実にしなけれはならない。

ＧＵＩは、スタック間の引き数それ自体の値のみをコピ
ーし、それらがポイントする可能性のあるものについて
はコピーしない。ｒｑｕｉｄＪは、ジョブがスケジュー
ルされるべき特定のＧＵＩキューを識別する。これによ
って、スケジュールされるジョブの相対的優先度が制御
され、オウナーがｑｕｉ　　ｒｕｎをコールするとき、
ジョブが実行されるシーケンスを決定される。複数のメ
イン・タスクを有するｖＳ環境において、ｑｕｉｄは、
また、ジョブが実行されるｖＳタスクの制御を行う。し
かし、これは推奨される構成ではない。

４、　１．４　　実行ジョブ ｑｕｉ　　５ｃｈｅｄｕｌｅされたジョブをＧＵＩが実
行できるようにするために、そのジョブが置かれたキュ
ーを所有するスレッドの制御を得なければならない。こ
の目的のため、ＧＵＩは、ユーザがメイン・スレッドか
らコール出来る次のようなルーチンを与え、そのスレッ
ドによって所有されたキューにスケジュールされたあら
ゆるジョブを実行する： ｑｕｊｒｕｎ（ｆｌａｇ） ここで、引き数は次の通り： 本ｆｌａｇ−このフラッグは実行すべきスケジュールさ
れたルーチンかない場合、ＧＵＩがスレッドをペンドす
べきか否かを示す。ジョブはコーリング・パス（ｒｑｕ
ｉ　　ａｌｌｏｃａｔｅ　　ｑｕｉｄＯＪに関する記載
参照）によって所有されるキューから優先度に基づいて
選択される。１つのキューにおいて、ジョブはＦＩＦＯ
順に実行される。ｒ’ｆｌａｇＪがＮ０ＰＥＮＤにセッ
トされると、ＧＵＩは実行するルーチンのチエツクを行
い、もし動作可能状態にあるものなければ、直ちに戻る
。もし、実行するルーチンがあれば、ＧＵＩそれらのう
ちの１つを実行して、もどる。ｑｕｉ　　ｒｕｎＯから
戻る値はジョブが実行されたか否かを示す。ｒｆｌａｇ
ＪがＰＥＮＤにセットされる場合は、ＧＵＩは、実行す
る動作可能状態のルーチンがあるまで、コーリング・ス
レッドをペンドする。動作可能状態になったいずれかの
ルーチンを実行した後、ＧｔＪＩはコーラをもう１度ペ
ンドする。

４、　１．　５　　スレッド・コントロールペンドされ
る場合、ＱＵＩはｑｕｉ　　ｒｕｎからはけっして戻ら
ないであろうから、ユーザは、必要であれば、スレッド
をリターンさせるためにコールできる次のような別のル
ーチンが設けられる： ｑｕｊｗａｋｅｕｐ（ｑｕｉｄ） このｗ　ａ　ｋ　ｅ　ｕ　ｐルーチンはペンドしない。

従って、特定のｑｕｉｄで既に実行しているジョブを含
みあらゆるバスからコールすることができる。

このコールはｑｕｉｄを所有しているパスを最初の機会
に（即ち、ペンドされた待機ジョブの場合は直ちに、そ
して実行中の場合はそのジョブが終了したとき）ｑｕｉ
　　ｒｕｎからリターンさせる。

ｑｕｉ　　ｒｕｎのペンド／非ベント　オプンヨンを使
用して、ユーザは、アイドルであればいつでもＧＵＩ内
でペンドするか、あるいはそれ自身のアイドル・ループ
から出るため通知をポーリングするかの選択をすること
ができる。付加的オブンヨンとして、ユーザがｑｕｉ　
　ｒｕｎ内でペンドすることを望まない場合、ＧＵＩの
ための次のようなｗａｋｅｕｐルーチンを与え、そのス
レ・ソドによって所有されるｑｕｉｄにおけるジョブを
実行するため、ＧＵＩがスレッドの制御を必要とすると
きはいつでもコールすることができる：ｕｓｅｒ−ｗａ
ｋｅｕｐ（ｑｕｉｄ） このルーチンのアドレスは、割り当てられる各ｑｕｉｄ
のｑｕｉ　　ａｉｉＯｃａｔｅ　　ｑｕｉｄのパラメー
タとして明示される。このメカニズムは、ユーザに、実
行する通知をポーリングすのではなく、利用することが
できるときが告げられるオプションを与える。この場合
、ＧＵＩがＩ”ｕｓｅｒ　　ｗａｋｅｕｐＪをコールす
るときはいつでも、ユーザは、近い将来、即ちそうする
位置になったらすぐに特定のタスクを有するｒｑｕｉ　
　ｒｕｎ」をコールしなければならない。

理想的には、ＧＵＩは、ｑｕｉ　　５ｃｈｅｄｕ１ｅＯ
及びｑｕｉ　　ｒｕｎＯルーチンのみを使用してプログ
ラムされる。しかし、このオプションのｗａｋｅｕｐル
ーチンは、ユーザが異なるタスク構造でそれらの要求に
最も都合の良い方法においてＧＵＩを使用することを可
能にするので、有効である。例えば、ｑｕｉ　　ｗａｋ
ｅｕｐＯは、ユーザ・インターフェース・プログラムを
作成するとき、例えばコミュニケーション・サーバー・
システムのディレクトリにエントリを追加するとき有効
である。特に、ｑｕｉ　　ｗａｋｅｕｐＯは、（この例
では）ディレクトリ要求が終了するとき、ＧＵＩ環境よ
り普通の環境（ユーザ・インターフェースを処理する）
に戻る場合、コールすることができる。

４．２０Ｃ５Ｐ供給ルーチン ここでは、ＧＵＩに対してペンドされないサービスを与
えるため、ＧＣＳＰが供給しなければならないルーチン
について記載する。ＧＣＳＰは、ＧＣＳＰが与えるサー
ビスを開始するため、ユーザによってコールされるリク
エスト・ルーチンを与える。それらのリクエスト・ルー
チンは次のルールに従わなければならない： ＊ペンドしてはならない。

＊リクエストが終了したとき、コールされるべきユーザ
供給通知ルーチンの準備をしなければならない。

スタック・ランナウェイの問題を防止し、リクエスト・
ルーチンがリターンする前にユーザの通知ルーチンがコ
ールされるのを回避するため、ＧＣＳＰはリクエスト・
ルーチンから直接通知ルーチンをコールしてはならない
。しかし、ＧＣＳＰがまえもってスケジュールされてい
たそれ自身のルーチンの１つから通知をコールすること
はさしつかえない。

＊要求された場合、それによってユーザが特定できるメ
カニズムを与えなければならず、通知ルーチンはそのｑ
ｕｉｄにスケジュールされなければならない。ＧＣＳＰ
によって与えられたサービスがリクエスト／レスポンス
　タイプから成るものでなければならない場合、典型的
リクエスト・ルーチンは次のような形式で良い： ＧＣＳｊＲｅｑｕｅｓｔ（Ｎｆｕｎｃ、　ｑｕｉｄ、　
ａｒｇｌ、　−−−ａｒｇＮ）ここで、引き数は次のと
おり： ＊Ｎｆｕｎｃ−コーラの通知ルーチンに対するポインタ ＊ｑｕｉｄ−ｒＮｆｕｎｃＪがスケジュールサレるＧＵ
Ｉｑｕｉｄ ＊ａｒｇｌ・・・ａｒｇＮ−リクエストに特有の付加的
引き数 ＧＣＳＰがそのように決定すれば、ｒＮｆｕｎｃｊ及び
ｒｑｕ　ｉ　ｄＪを特定するのに好ましい他の任意のメ
カニズムを使用することができる（例えば、初期化時に
ハード・コード化あるいは決定される）。特に、ＧＣＳ
Ｐはいつでも任意のユーザ・ルーチンがコールされるよ
うにスケジュールすることができるので、インターフェ
ースに対するインタラクンヨンは厳密にリクエスト／レ
スポンス形式から成る必要はない。

４．３　　ユーザ供給ルーチン 前述の如く、ユーザはすべてのリクエストに対して通知
ルーチンを与えることができる。それらは、ユーザにリ
クエストの完了を知らせるため、コールされるルーチン
である。ユーザがＧＣ３Ｐリクエスト・ルーチンをコー
ルしてからある時間後、そのルーチンあるいは他のある
ＧＣＳＰまたはＧＵＩルーチンがユーザ通知ルーチン（
前述の例では、Ｎｆｕｎｃ）をコールする。この通知ル
ーチンは次の規則に従わなければない：＊ペンドしては
ならない。

＊あらゆるバスにおいて、ｃｃｓｐで別に（例文ば、通
知がスケジュールされるｑｕｉｄを特定することによっ
て）アレンジされなければコールされる準備をしなけれ
ばならない。ｑｕｉ　　ｒｕｎＯをコールしてはならな
い。スタック・ランナウェイの問題を防止するため、ｑ
ｕｉ　　ｒｕｎに対するコールはネストされない。前述
のリクエスト・ルーチンの例を考えると、ＧＣＳＰはＧ
ＵＩを使用してユーザ通知ルーチンを直接的にスケジュ
ールし、そのルーチンは次のようにコールされるであろ
う： （本Ｎｆｕｎｃ）ａｒｇｌ、ａｒｇ２．ａｒｇ３．ａｒ
ｇ４．ｑｕｉｄ）ここで、引き数は次の通り： ＊ａｒｇ１．　　・・・ａｒｇ４−通知に特有の引き数 ＊ｑｕ　ｉ　ｄ−ｒＮｆ　ｕｎ　ｃｌがコールされてい
るＧＵＩｑｕｉｄ ＧＣＳＰから直接的に、あるいはＧＣＳＰにリターンす
るスタックでコールされないので、Ｎｆｕｎｃからのリ
ターン値を使用することはできない。

特定のｑｕｉｄにおいてコールされるＮｆｕｎｃに対し
てユーザがＧＣＳＰで準備していなければ、任意のバス
でコールすることができる。

４．４　　スケジュールされた通知のキューイングｑｕ
ｉｄ毎に、ＧＵＩは、スケジュールされた順番でキュー
されたあらゆるジョブを実行することを保証する。別個
のｑｕｉｄ間で強制されたシーケンスはない。特定の高
い優先度のｑｕｉｄで実行するようにスケジュールされ
たジョブがあり、ユーザがそのｑｕｉｄを所有するバス
てｑｕｉ−ｒｕｎをコールする場合、ＧＵｒはそのジョ
ブを実行する。このことは、通知が他の低い優先度のｑ
ｕｉｄで、あるいはより長い別のバスによって所有され
た高い優先度のｑｕｉｄにおいてさえ、キューされたか
もしれないこととは無関係に生じる。

第５章　使用可能なＧＵＩタスク・インタラクションの
例 ユーザは１以上の「メイン・タスク」を有しくここで、
メイン・タスクはユーザ処理を行うバスを意味するよう
に定義づけされる）、ＧＵＩｑｕｉｄ（即ち、イベント
−ウェイト−タスク及びインタラブド−ハンドラを排除
）を所有することができる。メイン・タスクは、非常に
長い命令を実行し、ディスクＩ１０の如き命令に対する
ペンドさえ可能であるが、可能な限りの無限待ち（例え
ば、ペンドされたタイムアウトされない端末ｌ１０）で
ペンドするのは好ましくない。そうしないと、通知をラ
ンするためＧＵＩがメイン・タスクを「Ｗａｋｅ　　ｕ
ｐＪすることが不可能になる可能性があるので、全体的
ＧＵＩ＠境の重大な分裂を引き起こすかもしれない。

セクション４．１．５で説明したように、ＧＵＩによっ
て与えられ、ｑｕｉ　　ｒｕｎに対するコールの「フラ
グ」によって支持されるスレッド制御の基本的２つの方
法がある。このセクションは、これらのメカニズムの可
能な使用例を説明し、各々についてのインタータスク関
係を図示説明する。

この２つのメカニズムはアイドルの「ウェイト−ポイン
ト」の位置、ＧＵＩ内か、ユーザ内かによって区別され
る。

５、ＩＧＵＩＧＵＩ内ト・ポイント このメカニズムはＧＵＩルーチンに対する次の２つのコ
ールによって支持される： ＊ｑｕｉ　　ｒｕｎ　（ｐｅｎｄ） ＊ｑｕｉ　　　ｗａｋｅｕｐ（ｑｕｉｄ）ユーザは、そ
れがアイドル中に、メイン・タスク・スレッドにおいて
選択されたペンド・オプションを有するｑｕｉ　　ｒｕ
ｎをコールする。ジョブが使用可能になると、コーリン
グ・パスによって所有されるｑｕｉｄで、ＧＵＩはｑｕ
ｉ　　ｒｕｎからスケジュールされたルーチンをコール
する。ユーザがそのメイン・タスク・スレッドの制御を
回復することが必要な場合（それ自身の別のタスクある
いはＧＵＩ通知コールがそれのためのある作業をキュー
したことにより）、ユーザはｑｕｉ−ｗａｋｅｕｐＯを
コールすることができ、それがｑｕｉ〜ｒｕｎをメイン
・タスクにできるだけ速くリターンさせる。もしユーザ
が、このようにして１つより多いメイン・タスクのスレ
ッドを制御することが必要な場合は、ｒｑｕｉｄＪ引き
数を使用して所有パスを一義的に識別することができる
。

第１５図及び第１６図は、第１４図に示す約束事を使用
して、制御の流れ及びこのメカニズムのタスク・インタ
ラクションを図示する。第１４図は、ＧＣ８Ｐルーチン
、ＵＳＥＲルーチン及びＧＵｌルーチンを表すために使
用される３つの異なる種類のボックスと、左、右及び下
方の軸の意味、即ち夫々ＣＡＬＬ、ＲＥＴＵＲＮ及びＴ
ＩＭＥを表している。これらの図及び以下の説明は、た
った１つのメイン・タスクを仮定していることが注目す
べきである。しかし、この仮定は説明を簡単にするため
であり、それによって根本的メカニズムは影響されない
。

結果としてユーザ通知となるペンドされたｑｕｉ　ｕ　
ｎ 第１５図はペンドされたｑｕｉ　　ｒｕｎＯルーチンの
使用を示し、そのルーチンはこのタスクを実行するよう
にスケジュールされたＧＣ５Ｐｉ知ルーチンをコールす
るＧＵＩとなる。図面の上部から下方に進むのであるが
、ユーザはメイン・タスク・スレッド１５０に対するそ
れ自身の処理の一部を行うことによってスタートする。

ユーザ処理１５１の間、ユーザはＧＣＳＰリクエスト・
ルーチン（ここではＧＣＳＰ　　Ｒｅｑｕｅｓｔ１５３
として示される）に対するコール１５２を行う。このル
ーチンは、ある処理、たぶんあるアクティビティを開始
し、そしてリターンする。ユーザがアイドル中でなけれ
ば、ＧＵＩにメイン・タスク・スレッドの制御を与える
ため、ペンド・オプションを有するｑｕｉ　　ｒｕｎ　
０１５５、即ちｑｕｉ　　ｒｕｎ　（ｐｅｎｄ）をコー
ルする。ｑｕｉ　　ｒｕｎ（）の内部で、ＧＵＩはラン
する通知をチエツクし、それがないと仮定すると、ｑｕ
ｉ　　５ｃｈｅｄｕｌｅまたはｑｕｉ　　ｗａｋｅｕｐ
によってボークされるのを待つ。ある時間後、ＧＣＳＰ
によって開始されたパス１５６は入来イベントを受ける
。イベントの簡単な例は、「キー押下コ、「プリンタ使
用可能」、「ディスク・ドライブ使用可能」等である。

コミュニケーション・サーバ・システムの場合の他の例
は、「メツセージ入来」、「ネットワーク使用可能」、
「ネットワークが送信要求」等である。それのほかには
、イベントはＩＰＣである可能性がある。パス１５６は
、イベント（１５７）を取り扱い、ＧＣ３Ｐリクエスト
であることから現在メイン・タスクで実行する通知を有
することを知っている。従って、実行すべきルーチンを
キューアップするｑｕｉ−ｓｃｈｅｄｕｌｅ１５８をコ
ールし、インタータスク・メツセージをメイン・タスク
に送り、このタスクは依然としてインサイドｑｕｉ　　
ｒｕｎＯを待っている。そのイベントに対する責任をメ
イン・タスクに渡してしまうと、ｑｕｉ　　５ｃｈｅｃ
ｌｕｌｅはＧＣ８Ｐイベント・ハンドラに戻り、そのハ
ンドラは別のイベントを待つことになる。

メイン・タスクはここでｑｕｉ　　ｒｕｎ内でウェーク
・アップし、所有のｑｕｉｄのなかに実行する通知がな
いかを見て、スケジュールされたコールのためＧＣ３Ｐ
通知ルーチン１５９をコールする。通知が一旦リターン
すると、ｑｕｉ　　ｒｕｎＯは再びボークされるのを待
つことに戻る（１５５′） ｑｕｉ　　ｗａｋｅｕｐによって割り込まれるベンドさ
れたｑｕｉ　　ｒｕｎ 第１６図は、メイン・タスク・スレッドの制御を回復す
るため別のパスのユーザがｑｕｉ　　ｒｕｎをコールし
ながら、メイン・パス内のｑｕｉ−ｒｕｎ　（ｐｅｎｄ
）１６０の使用を示す。メイン・タスクがアイドル期間
にある間ｑｕｉ　　ｒｕｎ□をコールすると、別のパス
はあるイベントを受け、その処理１６１はユーザにその
メイン・タスクがペンドされたｑｕｉ　　ｒｕｎＯを中
止させることを要求する。

この別のパス（これは、ユーザ通知ルーチンを実行する
ＧＵＩ待ちタスクあるいは別のユーザ・パスであるかも
しれない）は、ｑｕｉ　　ｗａｋｅｕｐＯをコールし、
ＧＵＩをしてメイン・スレッドを解放させ、ｑｕｉ　　
ｒｕｎＯからリターンする。ここで、ユーザは、メイン
・スレッドで望む任意の処理１６３を自由に行うことが
できる。

その処理が完了すると、ユーザはアイドルになり、ｑｕ
ｉ　　ｒｕｎ（）をもう１度コールする。

５．２　ユーザ内の待ちポイント このメカニズムは、ユーザ供給ルーチン及び非ベンド・
オプションｑｕｉ　　ｒｕｎＯルーチンによって作成さ
れる。

＊ｕｓｅｒ　　ｗａｋｅｕｐ　（ｑｕｉｄ）＊ｑｕｉ　
　ｒｕｎ　（ｎｏｐｅｎｄ）ユーザはそのメイン・タス
ク・アイドル・ループにおいて望むあらゆることを行う
ことができる。

ユーザは周期的にｑｕｉ　　ｒｕｎをポールしてスケジ
ュールされたコールがない場合ペンドすべきでないこと
を明示するか、あるいはＧＵＩがスレッドの制御を望む
ことを示すのを待つことができる。

前者の場合については、第１３図の例に例示されている
。後者の場合は、ｑｕｉｄのオウナーがｑｕｉ　　ｒｕ
ｎをコールすることを望むとき、ＧＵＩはｕｓｅｒ　　
ｗａｋｅｕｐ　□ルーチンをコールする。メイン・スレ
ッドの制御をＧＵＩに与えるため、ユーザは近い将来ｑ
ｕｉ　　ｒｕｎＯをコールしなければならない。典型的
には、ＧＵＩは１つのジョブを実行し、次にｑｕｉ　　
ｒｕｎＯからリターンする。

ｒｑｕｉｄＪ引き数は１以上のメイン・スレッドの制御
を許容する。ＧＵＩが一定のｑｕｉｄにおいてスケジュ
ールされたジョブを実行するを欲するとき、ｕｓｅｒ　
　ｗａｋｅｕｐ　Ｏをコールし、それはｑｕｉｄが割り
当てられたとき供給される。ＧＵＩは、ジョブがスケジ
ュールされたｑｕｉｄを所有するメイン・タスクのスレ
ッドにおいてそのジョブを実行するのみである。

ｕｓｅｒ　　ｗａｋｅｕｐルーチンは、ここでは１つの
名前付ルーチンとして考慮されているが、コールする実
際のルーチンはｑｕｉ　　ａｌｌｏｃａｔｅ　　ｑｕｉ
ｄ（）コールに対するパラメータとして特定されること
を注意すべきである。これによって、ユーザが、異なる
ＧＵＩキューのため異なるｗａｋｅｕｐルーチンを示す
ことができ、これは１つのプロセスにおいて複数の分離
されたユーザ・エンティティがある場合有効となる。

第１７図は、ｑｕｉ　　ｒｕｎの非ペンド・バージョン
とｕｓｅｒ　　ｗａｋｅｕｐ　□ルーチンを有するその
インタラクンヨシを示す。それは、ユーザがメイン・タ
スク・スレッドにおいてＧＣ３Ｐ　　ｒｅｑｕｅｓｔ　
（）１７０を行い、次に架空のアイドル・ループ１７１
に入る（周期的にＵＳｅｒ　　ｗａｋｅｕｐをチエツク
する手段を有し明示のアイドル・ループを有する実際の
必要性がない限り）ことを示している。

ある時間後、１つのイベントが到来し、ＧＣ３Ｐイベン
ト・ハンドラ１７２タスクを呼ぶ。このタスクはそのイ
ベントをサービスすることを開始し、そしてこの場合メ
イン・タスクにおいて実行する完了通知があることを発
見する。それによって、その通知を内部的にキューする
ｑｕｉ　　５ｃｈｅｄｕｌｅ１７３をコールし、そして
問題となっているｑｕｉｄのためのｕｓｅｒ　　ｗａｋ
ｅｕｐルーチン１７４をコールする。

このユーザ供給ルーチンは、そのメイン・タスクのｑｕ
ｉ　　ｒｕｎをコールさせるある動作をする。このイン
ター・タスクの正確な形式は、ユーザのイッシューであ
る。ｕｓｅｒ　　ｗａｋｅｕｐルーチンは次にサービス
・ルーチンに戻り、そのルーチンは次に別のイベントの
待機に戻る。近い将来のあるとき、ユーザのメイン・タ
スクはＵＳｅｒ　　ｗａｋｅｕｐによって送られるイン
ター・タスク・メツセージをピックアップし、その結果
メイン・タスク・スレッドの制御ＧＵＩに与えるためｑ
ｕｉ　　’ｒｕｎ　０１７５をコールする。

ｑｕｉ　　ｒｕｎ（’）において、ＧＵＩは、コールし
ているバスが所有しているｑｕｉｄにおいて実行すべき
ジョブを発見するまで、実行を待っているジョブのキュ
ーをスキャンする。発見すると、適切なユーザ通知ルー
チン１７６をコールする。

その通知ルーチンがリターンすると、ＧＵＩはその内部
的処理を終了し、次にｑｕｉ　　ｒｕｎからリターンし
て、ユーザ１７７に制御を戻す。

明細書の浄書（内容に変更なし） ６　　ＧＵＩタイマ 本章は、アンベンド・タイムド・イベント（ｕｎｐｅｎ
ｄｅｄ　ｔｉｍｅｄ　ｅｖｅｎｔｓ）をスヶジ、ｘ　−
１しするための機構を与えるジェネリック　アンベンゾ
イド・タイマ・サービス（Ｇｅｎｅｒｉｃ　Ｕｎｐｅｎ
ｄｅｄ　Ｔｉ１Ｉｅｒ　５ｅｒｖｉｃｅ）　　（ＧＬＩ
ＴＳ）を述べている。これはＧＵＩ周辺の集積部分では
ない、むしろ、それはＧＵＩライブラリの一部としてし
ばしば供給されるＧＣ８Ｐである。この特定サービスの
理解はＧＵＩ自体を理解するために必要でない。タイマ
・サービスは一連のＧＵＴＳ供与のリクエスト・ルーチ
ン、及びユーザ供与の通知ルーチン用の制限を構成して
いる。

６．１Ｇ［ＪＴＳ供与にＱルーチン このセクションはタイマをスタート及びキャンセルする
ために、ＧＵＴＳにより与えられるルーチンを述べてい
る。フォーマル・インターフェイスの明細は９章に述べ
られている。

６、　１．　１　　ｇｕｔｓスタートタイマこのルーチ
ンは記入された遅延が経過した後にタイマをオフにする
ようスゲジュールするために呼び出される。それは、セ
クション４．１で述べているように汎用化されたＧＣ３
Ｐリクエスト・ルーチン・フォーマットに従い、そして
次の引き数を行う。

＊　Ｎｆｕｎｃ−タイマが終了したときに呼び出される
なめ、ユーザの通知ルーチンへのポインタ。

＊　ｑｕｉｃｌ−ＮｆｕｎｃがスゲジュールされるＧ［
Ｊｒキュー。

もし値ＮＵＬＬ　　ＱＵＩＤが特定されると、そのとき
通知が、満期を検出するパスがら直接呼び出されるであ
ろう（これはＶｓのもとての個々の仕事でありそしてＵ
ＮＩＸ又はＭＳ−ＤＯ３のもとての割込ハンドラである
ン。

＊　ｄｅＩａｙ−秒単位で、現在にｒＷｉ係する正の遅
延。

＊　ｕｓｅｒ　ｒｅｆ−ユーザ参照（典型的にはいくつ
かのユーザ制御ブロックへのポインタ）。

＊　　ｔｉｇｅｒ−ｎａｍｅ−ユーザ及びｄＵＴｓに対
し、このタイマを区別する番号。

＊　ｕｓｅｒ　ａｒｇｌ−ユーザの利益のために、通知
ル−チンへ呼出しを戻す引き数。

＊　ｕｓｅｒ−ａｒｇ２−上述のような、別ノユーザ引
キ数。

タイマの１例はｕｓｅｒ−ｒｅｆｅｒｅｎｃｅ／ｌｉｇ
ｅｒ−ｎａｍｅ対により唯一識別される。例えば、もし
ユーザがいくつかのネットワーク・プロトコルを与える
ならば、“ｕｓｅ、ｒ−ｒｅｆ　’は特定結合用の制御
ブロックへのポインタであり、そしてｔｉｇｅｒ〜ｎａ
ｉＩｅ’は調時されるインベントを指示しても良い（例
えば、コネクション−タイムアウト、フレアータイムア
ウトなど）。

’　ｕｓｅｒ−ｒｅｆ　’及び’ｔｉｍｅ　ｎａｍｅ’
は’ｕｓｅｒ　ａｒｇｌ’と’　ｕｓｅｒ−ａｒｇ２’
に沿って、ユーザ通知ルーチン“Ｎｆｕｎｅ”へのパラ
メータとして仕分けられるだろう。

ＧＵＴＳタイマは１回オフ・イベントである。

タイマが経過し、そしてユーザの通知ルーチンがスゲジ
ュールされると、該タイマはもはや存在しない。もしユ
ーザがタイマに規則的間隔でオフすることを要求するな
らば、新しいタイマが通知ルーチンから新しいタイマが
開始されるべきである。

６、　１．　２　　ｇｕｔｓ−ｃａｎｃｅｌ−タイマ〈
）このルーチンは前に開始したタイマをキャンセルする
ために呼出される。それは次の引き数を取る。

＊　ｕｓｅｒ−ｒｅｆ−ユーザ参照、ｇｕｔｓ　５ｔａ
ｒｔ−Ｌｉｎｅｒへの呼出しを指定される。　、 ＊　　ｔｉＩＩｅｒ−ｎａｍｅ−タイマ・ネイム、ｇｕ
ｔｓ−ｓｔａｒｔ−ｔｉｍｅｒへの呼出しを指定される
。

＊　　ｒｅ＋＊ａｉｎ−ｐｔｒ　−Ｇ　Ｕ　Ｔ　Ｓはタ
イマがオフする前に残っている秒数でこのパラメータ中
に満ちる。

６　　、　１　　、　３　　　ｇｕｔｓ　　ｅｈｅｅｋ
ｊｉｍｅｒ　　（）このルーチンはタイマがオフする前
にどのくらいの時間が残っているかをチエツクするため
に呼出される。それはｇｕｔ３ｃａｎｃｅｌ−ｔｉｇｅ
ｒ　□と同じ引き数を取るがタイマはキャンセルされな
い。

６．２　ユーザ供与通知ルーチン 上述のように、ｇｕｔｓ−ｓｔａｒｔ−ｔｉｍｅｒの呼
出者は。

タイマが経過するときに呼出される通知ルーチン’Ｎｆ
ｕｎｃ’を与える。もし我々がこのルーチン’ｕｓｅｒ
　ｔｉｇｅｒ−ｅｘｐｉｒｅｄ’　を呼出すならば、こ
のときそれは次のように呼ばれるだろう。ｕｓｅｒ−ｔ
　ｉｍｅｒ−ｅｘｐｉｒｅｄ　　（ｕｓｅｒ−ｒｅｆ、
　　Ｌｉｎｅｒ　　ｎａｍｅ、　　ｕｓｅｒ−ａｒｇｌ
。

ｕｓｅｒ−ａｒｇ２、ｑｕｉｄ）　、その引き数はｇｕ
ｔｓ　ｓｔａｒｔ−ｔｉｍｅｒへの最初の呼出しで指定
されるものである。

６．３　タイマ正確度 タイマ・サービスの正確度は、メモリ・コンテンション
を有しない通常の負荷されたＭＶ上を動作しているとき
に、タイマの終期が意図された時間の＋１秒内にスケジ
ュールされることであろう。

しかし、ＧＵＴＳが通知スケジュール動作用のＧＵＩを
使用するから、通知が実行される正確な時間は現在スケ
ジュールされるＧＵＩ通知の数及びいかに早急にユーザ
がｇｕｊｒｕｎを呼出すかに依存する。

７　　ＧＵエイベント・ハンドラ 本章はＧＵＩライブラリに含まれても良い別のＧＣＳＰ
、即ちジェネリック・アンベンゾイド・イベント−ハン
ドラ・サービス（ＧＵＥＳ）を述べている。タイマ・サ
ービスと似て、このサービスはＧＵＩ自体の集積部分で
ない、ＧＣＳＰがイベント・ハンドラをセットすること
は、これらが開始する行動の完成を待つために、頻繁な
要請である。このようなハンドラは環境−特定（ｅｎｖ
ｉｒ。

ｎｍｅｎｔ−ｓｐｅｃｉｆ　ｉｃ　）である。ＡＯ３／
ＶＳのもとで、それらはＶＳ型タスクでもよく、これに
対してＵＮＩＸのもとではそれらは明らかではない。

この理由のため、そして多くのユーザが同じサービスを
要求するから、ＧＵＩは、ユーザから待ちタスクの詳細
を隠くそうとするイベント登録サービスを与える。明ら
かに、ユーザは待つべきイベントはどの種類であるかを
ＧＵＩに告げなければならない範囲まで、環境に気付く
であろうが、この気付きはインターフェイス呼出し上の
１つの型のイベントの選択に制限される。発生されたＶ
Ｓ様式のタスクの詳細、又は割込みベクトルの詳細、又
は基礎的な機構のすべてをユーザが知ることは必要ない
。

このサービスの情況において、”ユーザはＧＵＩユーザ
又は他のＧＣ３Ｐでも良い、彼らはＧＵＥＳが関係する
限り、両者が正に“ユーザである。

ＧＵＥＳはＡＯ３／ＶＳ及びＵＮＩＸオペレーティング
・システムのもとでのみ役に立つ。ＭＳ−ＤＯＳハード
ウェア割込の受信に要求されるアクションはＧＬＩＥＳ
のような一般のサービスによって取扱われるにはあまり
にも仕分けされている。

この種類の機能性を要求するＭＳ−ＤＯＳプログラムは
自らのアプリケーション−特有の割込みサービス・ルー
チンを書くであろう。これらのＩＳＲから、それらはア
クションが割込みを退けるために必要とすることを取る
ことができ、そしてアプリケーションの主要部分にイベ
ントを通すためにｇｕｊｓｃｈｅｄｕｌｅ　□を呼出す
ことができる。

７．１ＧＵＥＳ供与ルーチン １クラスのイベントにおけるインターレストを登録する
ために、ＧＬＩＩユーザはＧＵＥＳルーチンを呼出す。

ｇｕｅｓ　５ｕｂｓｃｒｉｂｅ　（） このルーチンは次の引き数を取る。

＊　ｇｕ：ｄ−その上のＮｆｕｎｃがスケジュールされ
るべきｇｕｉｄ。

＊　　１ｎ−ｐａｒｓ−この構造は加入されるイベント
の型の指示、及び特定の予約（例えば信号番号）に要求
される付加的パラメータを含む。

＊　ｏｕｔ　ｐａｒｓ　−Ｇ　Ｕ　Ｔは予約ｉｄ及びこ
の構造、型等のいくつかのイベント特定情報を戻す。

ＧＵＥＳが到来イベントを受信するとき、それは該イベ
ント用の予約のキューを走査し、そして各々の通知ルー
チンをスケジュールする。所与のイベント用に、特に信
号の場合に、登録された１以上の通知ルーチンがあるこ
とに注意されたい。

ＧＵＥＳは、通知がイベントを受け取るか又は拒絶する
ことを認めるよりも、すべての冗長通知ルーチンを呼出
すアプローチを取るだろう、これはユーザ誤りによるイ
ベントの損失を少なくする。

次のイベントはこれらの間で登録に役立つであろう。

＊　　？ＳＴ［；ＮＬ’５（ＡＯ３／ＶＳにおいて）。

＊　ソフトウェア割込（ＵＮＩＸにおいて信号（２＞）
。

＊　チャイルド　プロセス終了。

＊　　ＡＯ３／ＶＳ接続区切り（ＧＵＥＳにより終了と
してシュミレートされる）。

＊　Ｕｎｉｘ　　Ｉ１０用意、セクション（２）により
指示されたように。

これらのイベントの各々に要求される確実なパラメータ
はＧＵＥＳインターフェイス仕様（第１０章）において
仕分けされている。

７．２　ユーザ供与ルーチン このサービスのユーザは通知ルーチンＮｆ　ｕｎｃを与
えなければならない、もし我々がこのルーチンを’　ｕ
ｓｅｒ−ｅｖｅｎｔ−ｏｃｃｕｒｒｅｄ’と呼ぶならば
、このときこの呼出しは次の形をもつ。

ｕｓｅｒ　ｅｖｅｎｊｏｅｃｕｒｒｅｄ　（ｓｕｂ　ｉ
ｄ、　ｅｖｅｎｔ−ｔｙｐｅ。

ｕｄａｔａ、　ｅｖｅｎｔ−ｐａｒａｍ　ｑｕｉｄ）の
引き数は次のようである。

＊　　５ｕｊｉｄ−４ｕｅｓ−ｓｕｂｓｃｒｉｂｅ呼出
しのＧＵＥＳにより戻される予約ｉｄ。

＊　ｅｖｅｎｔｊｙｐｅ−ｇｕｅｓ−ｓｕｂｓｃｒｉｂ
ｅ　（＞へ仕分けされるような、イベントの型。

＊　　ｕｄａｔａ−ｇｕｅｓ−ｓｕｂｓｃｒｉｂｅに）
へｉｎ　ｐａｒｓにおいて仕分けされるようなユーザデ
ータ。

＊　ｅｖｅｎｊｐａｒａｍ−この引き数は通知されるイ
ベントへ特定の情報を伝送する。（例えば、喪失のため
にそれは終了したプロセスのＰ■Ｄ及び出口を含む）。

＊　ｑｕｉｄ−通知が実行されているＧ　Ｕ　Ｉ　ｑｕ
ｉｄ。

再び、各イベント発生の確定パラメータは第１０章に仕
分けされる。

７．３　イベント概念及び警報 このセクションはＧＵＦ、Ｓイベント添え字の夫々と関
係する概念を述べ、そしてこれらの使用により暗示され
るいくっがの制限について警告する。

７．３．Ｉ　　ＡＯ３／ＶＳ？５ＩＧＮＬイヘントコノ
添え字はＧＵＥｓユーザにＡＯ８／ＶＳＦａｓｔ　　Ｉ
ＰＣｓ　（？５ＩＧＮＬ）の受信と同時に通知されるこ
とを許す。

ＧＵＥＳは、？ＷＴＳＩＧ呼出しを行い続けることに従
事するすべての？５ＩＧＮＬ加入者により分担される信
号ＡＯ５／ＶＳタスクを確立する。

このタスクのＵｎｉｑｕｅ　Ｔａ５Ｋ　ｒＤはｇｕｅｓ
　５ｕｂｓｃｒｉｂｅ呼出しからの出力として各加入者
に戻され、そして？５ＩＧＮＬシステム呼出しへのパラ
メータとしてアプリケーションにより使用され得る。

？ＷＴＳＩＧタスクＵＩＤを別のプロセスへ通過するこ
とにより、このＧＵＥＳサービスは非直接データ伝送で
ＦａｓｔｒＰＣ機構を支持するために使用され得る。こ
れはデータ伝送用の分担されたメモリ機構との結合にお
いて又は？ＱＮＥＴのようなアンベンドなＫｅｒｎｅ　
ｌサービスに対するインターフェースにおいて役立つ。

？５ＩＧＮＬイベントに関係する２つの問題がある。

＊　何らの確認がされることなく、あなたの７０セスに
？５ＩＧＮＬを送ることができる。

＊　　？５ＩＧＮＬｓは入れ子にしない、そこでもし十
分に速く処理されないならば失われても良い。

次の警戒はこれらの問題を克服する。

ネ　？５ＩＧＮＬ通知はあなたのなめに意図されている
と決して仮定してはならない。それは別のＧＵＥＳ加入
者のためでも良く、又はＰＭＧＲにより送られても良く
、又は不注意に別のプロセスにより送られても良い。？
５ＩＧＮＬ通知は、いくつかのイベントが生じた指示と
して、そしてそれが実際に有するかを見い出すために使
用されるいくつかの他の手段として使用されるべきであ
る。例えば、キューは走査又はフラグチエツク動作を必
要としても良い。

＊　あなたはすべての送られた？５ＩＧＮＬのための通
知を得るであろうと仮定してはならない。

通知が受信されるときはいつも、すべての未解決のワー
クがチエツクされるべきで（例えば、完全なキューのス
キャンがされる）、なされるべきワークの各ピースのた
めの１つの通知をあなたが入手すると仮定するよりむし
ろ良い。

ＧＵＥ’Ｓは、しかしながら、通知が実行を開始した後
に受信されるいくつから？Ｓ　ＩＧＮＬのための別の通
知をあなたに与えることを保証するであろう、そこで通
知の間に到着する？５ＩＧＮＬに依ってワークが失われ
る情況はない。

７、３．２　　Ｕｎｉｘ信号（２）イベントこの予約は
多重ＧＵＥＳユーザにＵｎｉｘ信号（２）イベントの受
信と同時に通知されることを許容する。

各加入者はＧＵＥＳへ関心のある信号番号を通過し、そ
してＧＬＩＥＳは該信号のために、信号ハンドラ（信号
（２）を使用する）を確立する。各種信号はアプリケー
ションに役立つ、５ＩＧＵＳＲ１とＳ　ＩＧＵＳＲ２信
号はＡＯ５／　ＶＳ　（Ｆａｓｔ、ＩＰＣ機構のように
）のもとで？Ｓ　ＩＧＮＬに対して同様な方法で使用さ
れ得る。これに対して５ＩＧＰＯＬＬのような他の信号
はにｅｒｎｅ　ｌサービスにインターフェイスすること
に役立つ。

同じ警報及び警告は上述のＡＯＳ／ＶＳ？５ＩＧＮＬに
関して適用する。付加的に、ユーザ自身の信号ハンドラ
は予想できない結果で、ＡＬＬ加入者用のＧＵＥＳハン
ドラとインターフェイスするから、ユーザは自らの信号
ハンドラを制限してはならない。

ＧＵＴＳはそのタイマサービスを支持するために内部に
この予約を使用するから、ユーザはＳｆＧＡＬＲＭ信号
への加入をまた止めるべきである。

アプリケーションはＧＵＴＳタイマを替わりに使用すべ
きである。

この予約はＧＬＩＥＳユーザにチャイルド・プロセス終
了、及びＡＯ３／ＶＳのために、カスタマ／サーバー接
続区切りを通知されることを許容する。各加入者は、終
了したプロセスのピット及び出口状態を特定す・る、各
死亡の通知を受ける。

ＡＯ３／ＶＳのもとで、ＧＵＥＳは終了メツセージ（？
ＳＰＴＭ）用のシステムボート上に繰り返しの？ＩＲＥ
Ｃ’ｓをするために個々のタスクを確立する。ユーザは
ＧＵＥＳサービスを中断するだろうから、このボート上
に自らの？ＩＲＥＣ’ｓをしてはならない、ＵＮＩＸの
もとで、ＧＵＥＳはチャイルド終了につき通知されるた
めに、５ＩＧＣＬＤの信号番号で自らの信号（２）サー
ビスに加入する０通知が受けたときに、ＧＵＥＳは、す
べての終了したチャイルドのための終了情報を集めるた
めに、ＷＮＯＨＡＮＧオプションで繰り返してウェイト
３（２）呼出しを行う、ユーザは、これはすべての加入
者用のＧＵＥＳサービスを中断させるであろうので、自
らウェイト（２）又はウェイト３（２）を呼出してはな
らない。

７、３．４　　Ｕｎｉｘセレクト（２）イベントＩ１０
条件が１つの特定された組のファイル記述子上に存在す
る時に通知されることを、この予約はＵＮＩＸユーザに
許容する。

ｕｎｉｘセレクト（２）システム呼出しは３バイトアレ
イ引き数、ｒｅａｄｆｄｓ　Ｃ）　、ｗｒｉｔｅｆｄｓ
　（）及びｅｘｅｅｐｔｆｄｓ　（）を取る。これらの
アレイの夫々の内部で、各ビットは制限されたファイル
記述子を表わす、　ｒｅａｄｆｄｓ　（）マスクは呼出
し人がリード（２）呼出しをすることに関心があるファ
イル記述子を記入し、ｗｒｉｔｅｆｄｓ　（）マスクは
呼出し人がライト（２）呼出しをすることに関心がある
ファイル記述子を記入し、そしてｅｘｅｅｐｔｆｄｓ　
（〕マスクは呼出し人が例外条件に関心があるファイル
記述子を記入する。

セレクト（２）呼出しは、入力において仕分けされた条
件のいずれが実際に存在するかを指示する情報を戻す（
即ち、仕分けられた記述子のいずれが読出し、書込み用
に準備され又はそれらに例外を有するか）、仕分けられ
た条件の１つが存在し又はそれがボールされ得るまで、
呼出しは未処理にされることができる。

ＧＵＥＳは、未決のｇｕｉ−ｒｕｎ　Ｏからの実行する
ジョブがないときはいつも、未決の方法でセレクト（２
）を呼出すためにｇｕｊｒｕｎ　□のために整備する。

また、アンベンドのｇｕｊｒｕｎ　□は、ＧＵＩ内にす
でに列をなすジョブがないときはいつもボールされたセ
レクト（２）呼出しをするだろう。

ＧＵＥＳセレクトサービスへの各加入者は、セレクト（
２）マスクによく似ている１組のファイル記述子マスク
を有する。加入者は彼／彼女ＧＵＥＳ　　５ＥＬＥＣＴ
　　ＭＡＳＫ構造をＨｕｅｓ−ｓｕｂｓｃｒｉｂｅの中
へ通過し、そしてＧＵＥＳはそれを記憶している。ＧＵ
ＥＳはセレク−）（２）に仕分けするｒｅａｄｆｄｓ　
（）　、ｗｒｉｔｅｆｄｓ　（）及びｅｘｃｅｐｔｆｄ
ｓ　（）マスクはそれから全加入者のマスクを共にＯＲ
することにより構成される。ここで彼／彼女ＧＵＥＳ　
　５ＥＬＥＣＴ　　ＭＡＲＫ中のビットを処理すること
により、加入者は彼／彼女が通知されることに関心のあ
るファイルの組から所要のファイル記述子をダイナミッ
クに加え又は除去することができる。

セレクト（２）呼出しがＩ１０条件を指示するときはい
つも、ＧＵＥＳは、各加入者のセレクトマスクがその条
件で１以上の記述子を仕分けしている該各記述子用の単
一の通知をスケジュールするだろう、マスク上に条件を
もったファイルに現在関心のあることをその加入者のマ
スクが示している加入者のみが与えられた通知を受ける
だろう。

次の警報はこのサービスの使用者に適用する。

＊　与えられたファイル記述子に関心のあるのは１Å以
上の加入者であっても良く、そこでいくつかの注意が通
知を取り扱うことに支払わなければならない１例えば、
もし２人の加入者が５ＴＤＩＮの上に可能である読取り
の関心を登録するために彼らのセレクトマスクをセット
するならば、そのとき有効に入力されるとき、彼らは夫
々呼出されるべき通知ルーチンを手に入れるだろう、も
し、最初の加入者が通知ルーチンからすべての有効な入
力を読出すならば、そしてそれから第２の加入者が読出
しを試みるならば、その読出しはおそらく永久に未処理
であろう。

周知のファイル記述子（ＳＴＤＩＮのような）を使用す
るときに、条件がなお存在することをチエツクするため
に、イベント通知から別のボールされたセレクト（２）
呼出しをすることが助言される。

＊　通知の１つがＩ１０条件をクリアすること、又は別
にすべての加入者が彼らのセレクトマスク中のオフエン
デイングビットをクリアにすることは等しく重要である
。上記例において、いずれの通知も有効な入力を読み取
らずそして彼等両方が変更されてないセレクトマスクを
残しているならば、このときプロセスは、すべてのタイ
ムＧＵＥＳがセレクト（２）を呼出すので、ハートルー
ズに移行し、Ｉ１０可能を示し、そして加入者通知は再
びスケジュールされるであろう。

本　もし加入者マスクのいずれかが現在開放されてない
ファイルを仕分けするならば、このときＧＵＩはセレク
ト（２）から誤りを得てそしてプロセスを終了するであ
ろう、加入者はそこで彼等がファイルを閉じるときはい
つも彼等のセレクトマスクを注意深く修正しなければな
らない、また、もしファイルが多数のＧＵＥＳ加入者に
対して見えるならば、該ファイルを閉じる唯かは、他の
加入者がまた彼等のセレクトマスクを補正できるように
、該他の加入者に知らせるための機構を明らかにしなけ
ればならない。

ＧＵＥＳのみが上述された適切に制限されたポイントか
らセレクト（２）呼出しを行うことに注意されたい、特
に、ＧＵＥＳは、ユーザ通知が実行している開法してセ
レクト（２）呼出しをすることができないことに注意さ
れたいく単一ベースレベルパスのみであるから）。そし
てＨｕｉ−ｒｕｎに）が呼出されている（又は戻されて
いる）ときはいつもユーザのセレクトマスクが有効であ
る限り、問題は生じないであろう。明らかに、この予約
は注意して使用されなければならず、しかしもし注意し
て使用すればそれは強力なサービスを与える。

第８章　ＧＵＩインターフェース仕様 この章では、具体例としてのＧ、ＵＩインターフェース
の好適なフオームを機能的に記述する。

ｇｕｉ　１ｎｉｔｉａｌｉｓｅ　　　　Ｇ　Ｕ　Ｉ環境
の初期化。

フォーマットｇｕｉ−ｉｎｉｔｉａｌｉｓｅＯこのルー
チンは、他のＧＵＩルーチンが呼び出される前に各ライ
ブラリおよびメインアプリケーションによって呼び出さ
れねばならない。

ｇｕｉ−ａｌｌｏｃａｔｅ−ｑｕｉｄ ジョブスケジューリングのためのキューの割り当て、お
よびその識別子への復帰。

フォーマット：　　ｇｕｊａｌｌｏｃａｔｅ−ｑｕｉｄ
（ｐｒｉｏｒｉｔｙ、ｕｓｅｒ−ｗａｋｅｕｐ、　ｑｕ
ｉｄ） パラメータ： ｐｒｔｏｒｉｔ７　　　この列にスケジュールされるジ
ップの相対的な優先関係を定義す る。

ｕｓｅｒ　　ｗａｋｅｕｐ　　　もし指定される（ｎｏ
ｎ−ＮＵＬＬ）ならば、ジョブがこ のｑｕｊｄにスケジュールされる時は いつでも、このルーチンはＧＵＩによって呼び出される
。

ｑｕｉｄ　　ＧＵＩは、新しく割り当てられたキューの
ためにキュー識別子と共にこのパ ラメーターの中で対応する。

このルーチンは、内部ＧＵＩキューを割り当て、このキ
ューの上でジョブはｇｕｉ　　５ｃｈｅｄｕ１ｅＯによ
りスケシールされる。このキューがらジョブを引き出す
ために、ユーザーは、同じスレッド（ｔｈｒｅａｄ）（
ＶＳ−Ｔａｓｋ）において、ｇｕｉ　　ｒｕｎＯを呼び
出さねばならず、これはそれ（キュー）を割り当ててい
る。もし“ｕｓｅｒ　　ｗａｋｅｕｐ”ルーチンが指定
されると、そのときこのルーチンは、ジョブがスケジュ
ールされるときはいつでも、それをスケジュールしたス
レッドにおいて呼び出されねばならない。

ユーザーは、その後前記ｑｕｉｄを割り当てたスレッド
の上でｇｕｉ　　ｒｕｎを呼び出さねばならない。

ｇｕｉ　ｓｃｈｅｄｕｌｅ 指定のスレッドで実行するためのジョブのスケジュール
。

フォーマット：　　ｇｕｊｓｃｈｅｄｕｌｅ（ｑｕｉｄ
、　ｒｏｕｔｉｎｅ、　ａｒｇｌ、　ａｒｇ２．　ａｒ
ｇ３．　ａｒｇ４）パラメータ： ｑｕｉｄ　　その上でジョブがスケジュールされるべき
ｑｕｉｄｏ　これは以前のコールからｇｕｉ　　ａｌｌ
ｏｃａｔｅ　　ｑｕｉｄヘリターンされるｑｕｉｄでな
け ればならない。

ｒｏｕｔｉｎｅ　　　コールがスケジュールされる機能
のアドレス。

ａｒｇｌ−ａｒｇ４　　　スケジュールされたルーチン
が呼び出される引き数（ａｒｇｕ ｍｅｎｔｓ）。

特定のｑｕｉｄ上で呼び出されるルーチンをスケジュー
ルする。このルーチンは、ユーザーがｑｕｉｄを割り当
てたスレッドからｇｕｉ　　ｒｕｎを呼び出したとき、
（指定された引き数と共に）呼び出される。ＧＵＩは、
４つのＩＮＴ３２ｓ　（ａｒｇ−ａｒｇ４）をそのまま
通過してスケジュールされたルーチンへ行く。スケジュ
ーリングとスケジュールされたルーチンとの間の引き数
により、これらのパラメータは、それらにより占められ
る全体のスペースが４つのＩＮＴ３２Ｓにより使用され
るそれよりも大きくない限り、何らかのサイズの何らか
の数のパラメータが使用され得る。事実上、ＧＵＩは、
スケジューラ−からスケジュールされたルーチンまでの
間にスタックの４つのダブルワードを複写し、このブロ
ックの解釈はユーザーに委ねられる。

ｇｕｊｒｕｎ 以前にスケジュールされたルーチンの実行。

フォーマット：　　ｇｕｊｒｕｎ（ｆｌａｇ）パラメー
タ： ｆｌａｇ　　　すべてのジョブが実行の用意ができてい
ないときにコーラ−（ｃａｌｌｅ ｒ）が待つことを欲するかどうかの指 示。ＰＥＮＤまたはＮ０ＰＥＮＤへの セット。

このルーチンは以前にスケジュールされたジョブを実行
させる。ジョブは呼び出しタスクにより割り当てられた
ｑｕｉｄから優先順序にしたがって選択される。

もしＧＵＩ　　０ＰＴＩＯＮ　　Ｎ０ＰＥＮＤが選択さ
れると、ＧＵＩは、１つのジョブが実行された後か何ら
のジョブも利用されないときコーラ−に復帰する。

もＬＧＵＩ　　０ＰＴＩＯＮ　　ＰＥＮＤ！ｌ（選択さ
れると、ＧＵＩは、ユーザーがｇｕｔ　　ｗａｋｅｕｐ
を呼び出すまで、復帰しない。ＧＵＩは、何らのジョブ
も準備されてないときはそのまま静止し、ジョブが利用
されるときはそれらを実行する。

ｇｕｉ−ｖａｋｅｕｐ ベンドされたｇｕｉ　　ｒｕｎを復帰させる。

フォーマット：　　ｇｕｊｗａｋｅｕｐ（ｑｕｉｄ）パ
ラメータ： ｑｕｉｄ　　　ｑｕｉｄ”を有するスレッドが起動され
るべきものであることを指定す る、 ユーザーは、ペンドオブシタンと共にｇｕｔｒｕｎを呼
び出すスレッドを発生し、それが次のジョブの実行を終
了するとき復帰するために、この機能を呼び出す。指定
された“ｑｕｉｄ”は起動されるスレッドが有していな
ければならない。

もしスレッドが現在ジョブの実行を待ちでいるときは、
それは直ちに復帰する。もしそれが現在ｇｕｉ　　ｒｕ
ｎＯ内に全くないときは、ｇｕｉｒｕｎＯへの次の呼び
出しは直ちに復帰される。

ルーチンはまた、ジョブをその上にスケジュールするこ
となしに、ｑｕｉｄが変化することをチエツクするため
に提供される。これはＧ　Ｃ’Ｓ　Ｐ　ｓのために有益
であり、ＧＣＰＳｓは、ユーザーによりサービス要求ル
ーチン内ヘバスされたｑｕｉｄが変化することをチエツ
クするために使用し得る。

これは、その処理の後に、ＧＣＰＳが、そのｑｕｉｄが
無効でありユーザーにしらせることができないことを発
見するのを妨げる。

ユーザーはまた、ｇｕｉ　　５ｃｈｅｄｕｌｅのユーザ
ーであるジョブの連続呼び出しのために、ジョブがｇｕ
ｉ　　５ｃｈｅｄｕｌｅへの呼び出しと共にスケジュー
ルされるとき指定される引き数と共に、またジョブがス
ケジュールされるｑｕｉｄと共に、ｕｓｅｒ　　ｊｏｂ
スケジュールド・ルーチンを提供する。

ユーザーは、ジョブをリスケジュールするために、同じ
ｑｕｉｄで、あるいはもしそれがｇｕｉｒｕｎＯからの
復帰を実行するスレッドを欲するなら、ｇｕｉ　　ｗａ
ｋｅｕｐへの呼び出しで、ｑｕｉｄを使用する。

第９章　ＧＵＴ　Ｓ　　インターフェース仕様この章で
は、ＧＵＴＳインターフェースの１例の機能的な記述を
提供する。

ｇｕｔｓ−ｉｎｉｔｉａｌｉｓｅ　　Ｇ　Ｕ　Ｔ　Ｓラ
イブラリの初期化このルーチンは、他のＧＵＴＳルーチ
ンが呼び出される前に各コンポーネントにより呼び出さ
れる。最初の初期化のほかはみな、　ＧＵＴＳによって
無視される。

ｇｕｔｓ　５ｔａｒｔ　ｔｉＩＩｅｒ　　　Ｇ　ＣＳ　
ＰはＧＵＴＳタイマの開始を要求する。

フォーマット　　ｇｕｔｓ　ｓｔａｒｔ−ｔｉｍｅｒ　
（ｎｆｕｎｃ、　ｑｕｉｄ。

ｄｅｌａｙ、　ｕａｒｇｌ、　ｕａｒｇ２）パラメータ
。

ｎｆｕｎｃ　　　これはユーザー通知ルーチンであり、
これはタイマが終了したときＧＬ″ＴＳによってスケジ
ュールされる。

ｑｕｉｄ　　　これはタイマが終了したとき“ｎｆｕｎ
Ｃ”がスケジュールされるｑｕｉ ｄである。

ｄｅｌａｙ　　　タイマが終了し“ｎｆｕｎｃ”がＧＵ
ＴＳによってスケジュールされる 前に経過せねばならない秒の数。

ｕａｒｇｌ　　　このパラメータは、　通知ルーチンで
ユーザーへ返される。

ｕａｒｇ２　　　ｕａｒｇｌと同様。

このルーチンは、ワンスオフタイマイベント（ｏｎｃｅ
−ｏｆｆ　　ｔｉｍｅｒ　　ｅｖｅｎｔ）を開始させる
ために呼び出される。“ｄｅｌａｙ”秒においてタイマ
が終了したとき、ＣＵＴＳはユーザー通知をスケジュー
ルし、それがｇｕｉ−ｒｕｎＯｌ例えば（＊ｎｆｕｎｃ
）　　　（ｕａｒｇｌ、ｕａｒｇ２．ｑｕｉｄ）から呼
び出すレル。

他のパラメータは単一のタイマをユニークに識別するた
めに使用される。

ＧＵＴＳを使用する幾つかの存在の間における特徴を確
保する良い道は、“ｕｓｅｒ　　ｒｅｆ”パラメータの
ための制御ブロックのポインタを使用することである。

前記制御ブロックが割り当てられたままでいる限り、他
の存在が同じアドレスでメモリに割り当てられることは
なく、したがって、“ｕｓｅｒ　　ｒｅｆ″は特有のも
のである。

このアプローチはまた、調節される操作の配置は単純な
ことであることを意味している。

もし規則的に繰り返すタイマが要求されるときは、同じ
（または異なる）名前のタイマは、通知ルーチンからス
ケジュールされ、その都度タイマは終了する。

ｇｕｔｓ−ｃａｎｃｅｌ−ｔｉｍｅｒ 未決定の（ｏｕｔｓｔａｎｄｉｎｇ）タイマのキャンセ
ル フォーマット：　　ｇｕｔｓ　ｃａｎｃｅｌ−ｔｉｍｅ
ｒ（ｉｄｅｎｔｉｆｉｅｒｓ。

ｔｉｍｅｌｅｆｔ） パラメータ： １ｄｅｎｔｉｆｉｅｒｓ　　　タイマをユニークに識別
する。

ｔｉｍｅｌｅｆｔ　　　タイマが見付けられうまくキャ
ンセルされたとき、ＧＵＴＳはタ イマが終了する前のままの時間量に復 帰する。

このルーチンは、ｇｕｔｓ　　５ｔａｒｔ　　ｔｉｍｅ
ｒにより以前にスタートした未決定のタイマをキャンセ
ルするために呼び出す事ができる。これは、もし、例え
ば計られたイベントが正常に終了するか中断されるとき
は、有益である。

ｇｕｔｓ−ｃｈｅｃｋ−ｔｉｇｅｒ タイマが終了する前にどのくらい長くそのままでいたか
を見るためのチエツク。

フォーマット：　　ｇｕｔｓ−ｃｈｅｃｋ−ｔｉｍｅｒ
（ｉｄｅｎｔｉｆｉｅｒｓ。

ｔｉｍｅｌｅｆｔ） パラメータ： １ｄｅｎｔｉｆｉｅｒｓ　　　上記のとおりｔｉｍｅｌ
ｅｆｔ　　　ＧＵＴＳはこのパラメータが終了する前の
時間に復帰する。

このパラメータは、指定されたタイマが終了する前にど
のくらい残されたかをチエツクするために呼び出される
。これは、マネージメントアプリケーションへの情報を
報告するために使用される。

第１０章　　ＧＵＥＳ　　インターフェース仕様この章
では、ＧＵＥＳインターフェースの１例の機能的な記述
が提供される。

ｇｕｅｓ　５ｕｂｓｃｒｉｂｅＯＧ　Ｕ　Ｅ　Ｓライブ
ラリの初期化。

このルーチンは、他のＧＵＥＳルーチンが呼び出される
前に各コンポーネントにより呼び出される。最初の初期
化の外は皆ＧＵＥＳにより無視される。

ｇｕｅｓ　５ｕｂｓｃｒｆｂｅＯＧ　ＣＳ　Ｐリクエス
ト。

イベントの分類について述べることを求める。

フォーマット：　　ｇｕｅｓ−ｓｕｂｓｃｒｉｂｅ（ｇ
ｕｉ−ｑｕｉｄ、　ｉｎ　ｐａｒｓ、　ｏｕｔ−ｐａｒ
ｓ） パラメータ： ｇｕｉ　　ｑｕ’ｉｄ　　　コーラ−がイベント受け取
りの通知を欲するＧＵＩ　　ｑｕｉｄを指定する。　　
”Ｉｎ　　ｆＪａｒＳ″で指定された通知ルーチンは、
イベントが受 け取られる毎にこのｑｕｉｄにスケジュールされる。

ｉｎ　　ｐａｒｓ　　　登録のためのパラメータを入力
する。下記の例参照。

ｏｕｔ　　ｐａｒｓ　　　登録のためのパラメータを出
力する。下記の例参照。

ユーザーは、ＡＯ３／ＶＳ　Ｆａｓｔ　　ＩＰＣ’５（
７ＳＴＧＮＬ）　、ＵＮＩＸ　　ソフトウェア割り込み
（信号）、またはチルド処理ターミネーンヨン（オビチ
ュアリイ）のような、外部イベントのインタレストを記
録するために呼び出される。

“ｉｎ　　ｐａｒｓ”パケットは、イベントの型、指定
されたイベントが受け取られて呼び出される通知ルーチ
ンのアドレス、さらにそのイベントを指定するパラメー
タを含む。

“ｏｕｔ　　ｐａｒｓ”パケットは、記録されたイベン
トに関するＧＵＥＳにより戻される情報を含む。

これらのパケットが従うフオームの例：５ｕｂｓｃｒｉ
ｂｅ　ｔｏ　ＶＳ　？５ＩＧＮＡＬ　ｅｖｅｎｔｓ　ｇ
ｕｅｓ−ｓｕｂｓｃｒｉｂｅＯｃａｌｌ　： 入力パラメータ： ｔｙｐｅｄｅｆ　　５ｔｒｕｃｔ　　ｇｕ＝ｅｓ　　ｉ
ｎａｒｓ ｅｖｅｎｔ　　ｔｙｐｅ　　　＊ＧＵＥＳ　　ＥＶＥＮ
Ｔ　　ＶＳ　　５ＴＧＮＬ　　へのセット。

ｎｆｕｎｃ　　　これはイベントの受け取りでＧＵＥＳ
により呼び出されるユーザー通知 ルーチンのアドレスである。

ｕｄａｔａ　　　“ｎｆｕｎｃ′ヘバスされるユーザー
データ。

出力パラメータ・ ｔｙｐｅｄ　　５ｔｒｕｃｔ　　ｇｕｅｓ　　ｏｕｔａ
ｒｓ ｓｕｂ　　ｉｄ　　　ＧＵＥＳはこのサブスクリブショ
ンのための識別子を戻す。

ｗａｉｔ　　ｔａｓｋ　　ｕｉｄ　　　このメンバーは
タスクを待つのに使用される内部ＧＵ ＥＳタスクのＶＳ　　Ｕｎｉｑｕｅ　　Ｔａ５ｋ　　Ｉ
Ｄを指定する。これは？５ＩＧＮＡＬタスクのために必
要である。

このイベントはＡＯＳ／ＶＳの下でのみ利用でキル。Ｆ
ａｓｔ　　ＩＰＣを受け取ると、コーラ−の通知ルーチ
ンはスケジュールされるが、それは次のように呼び出さ
れる。すなわち： （本ｎｆｕｎｃ）　　（ｓｕｂ−ｉｄ、　　ｅｖｅｎｔ
−ｔｙｐｅ、　　ｕｄａｔａ、　　０．　　ｇｕｉ−ｑ
ｕｉｄ）； “ｇｕｉ　　ｑｕｉｄ”は前記通知が実行されるｑｕｉ
ｄである。

５ｕｂｓｃｒｉｂｅ　ｔｏ　Ｉｎｔｅｒｒｕｐｔ　ｅｖ
ｅｎｔｓ　ｇｕｅｓ　５ｕｂｓｃｒｉｂｅ（）　ｃａｌ
ｌ： ソフトウェア割り込みイベントの共用（ｓｕｂｓｃｒｉ
ｐｔｉｏｎ）のためのパラメータの使用。

入力パラメータ： ｔｙｐｅｄｅｆ　　５ｔｒｕｃｔ　　ｇｕｅｓ　　　ｉ
ｎｐａｒｓ ｅｖｅｎｔ　ｔｙｐｅ　　値ＧＵＥＳ　ＥＶＥＮＴ　　
ＩＮＴのセット。

ｉｎｔ　　ｎｕｍ　　　これは、コーラ−が共用を欲す
る“割り込みナンバー”である。Ｕ ＮＩＸの下では、これは信号数（ｓｉ ｇｎａｌ、ｈ、で定義される）である。

ｎｆｕｎｃ　　　これはイベントが受け取られたときＧ
ＵＥＳにより呼び出されるユーザ ー通知ルーチンのアドレスである。

ｕｄａｔａ　　　″ｎｆｕｎＣ″ヘパスされるユーザー
データ。

出力パラメータ： ｔｙｐｅｄｅｆ　　５ｔｒｕｃｔ　　ｇｕｅｓ　　ｓｉ
ｇｎａｌ　　ｏｕｔ　　ｐａｒｓ ｓｕｂ　　ｉｄ　　　　ＧＵＥＳはこの共用のための識
別子を戻す。この共用は、例えばＵ ＮＩＸの下で、信号の受け取り時に通 知される処理内のマルチ・エンティティを許容する。

指定された割り込みの受け取り時に、　コーラ−の通知
ルーチンはスケジュールされるが、これは次のように呼
び出される。

（本ｎｆｕｎｃ）　　（ｓｕｂ　　ｉｄ、　　ｅｖｅｎ
ｔ　　ｔｙｐｅ、　　ｕｄａｔａ、　　ｉｎｔ　　ｎｕ
ｎ。

ｇｕｔ　ｑｕｉｄ）； “ｇｕｔ　　ｑｕｉｄ″は前記通知が実行されるｑｕｉ
ｄである。

５ｕｂｓｃｒｉｂｅ　ｔｏ　ｃｈｉｌｄ　ｏｂｉｔｕａ
ｒｉｅｓ　ｇｕｅｓ−ｓｕｂｓｃｒｉｂｅＯｃａｌｌ： チルド・オビチュアリイの共用のためのパラメータの使
用 入力パラメータ： ｔｙｐｅｄｅｆ　　５ｔｒｕｃｔ　　ｇｕｅｓ　　ｉｎ
ａｒｓ ｅｖｅｎｔ　ｔｙｐｅ　　値ＧＵＥＳ　ＥＶＥＮＴ　　
０ＢＩＴのセット。

ｎｆｕｎｃ　　　これはイベントの受け取り時にＧＵＥ
Ｓにより呼び出されるユーザー通 知ルーチンのアドレスである。

ｕｄａｔａ　　　″ｎｆｕｎｃ″ヘパスされるユーザー
データ。

出力パラメータ： ｔｙｐｅｄｅｆ　　５ｔｒｕＣｔ　　ｇｕｅｓ　　ｓｉ
ｇｎａｌ　　ｏｕｔ　　ｐａｒｓ この共用は、ＡＯ８／ＶＳとＵＮＩＸの下でサポートさ
れる。それは、チルド処理の終結時に通知される処理内
の１または１以上のエンティティを許容する。チルド処
理の（またはＡＯ８／ＶＳＣｕｓｔｏｍｅｒ−８ｅｒｖ
ｅｒ　　関係におけるハードナーの）終結時に、コーラ
−の通知ルーチンはスケジュールされるが、これは次の
ように呼び出される。

（零ｎｆｕｎｃ）　　（ｓｕｂ　　ｉｄ、　　ＧＵＥＳ
　　ＥＶＥＮＴ　　０ＢＩＴ、　　ｕｄａｔａ、　　ｏ
ｂｉｔ−ｐｔｒ、　ｇｕｉ−ｑｕｉｄ）；前記’ｇｕｉ
　　ｑｕｉｄ”は、通知が実行されるｑｕｉｄであり、
　　“ｏｂｉｔ　　ｐｔｒ”は次のような構造のポイン
タである。

ＵＳＩＮＴ３２　ｐｉｄ； ＵＳＩＮＴ３２５ｔａｔｕｓ； ＩＧＵＥｓ　０ＢＩＴ： ｐｉｄ　　この領域はターミネイト（終結）処理のＰＩ
Ｄを含む。

５ｔａｔｕｓ　　　この領域はどのように処理が終結さ
れるかを含む。

ＡＯＳ／ＶＳの下で、それは正常な終結のためのゼロま
たはこれに代わるエラーコードを含む。

このエラーコードは終結された処理（ｖｉａ　　？ＲＥ
ＴＵＲＮ）から戻され、または異常な終結を示すために
ＧＵＥＳにより供給される。

ＵＮＩＸの下で、“５ｔａｔｕｓ”は、ＵＮＩＸにおい
て記述されたｗａｉｔ３（２）システム呼び出しから得
られるような終結されたチャイルドの出口状態を含む。

５ｕｂｓｃｒｉｂｅ　ｔｏ　５ｅｌｅｃｔ（２）　ｅｖ
ｅｎｔｓ　ｇｕｅｓ−ｓｕｂｓｃｒｉｂｅ（）　ｃａｌ
ｌ ｓｅｌｅｃｔ（２）イベントの共用のためのパラメータ
の使用。

入力パラメータ： ｔｙｐｅｄｅｆ　　５ｔｒｕｃｔ　　ｇｕｅｓ　　ｓｅ
Ｉｅｃｔ　　　ｍａｓｋ ｔｙｐｅｄｅｆ　　５ｔｒｕｃｔ　　ｇｕｅｓ　　ｉｎ
ａｒｓ ｅｖｅｎｔ　ｔｙｐｅ　　値ＧＵＥＳ　ＥＶＥＮＴ　　
５ＥＬＥＣＴのセット。

ｅｖｅｎｔ　　ｍａｓｋ　　　この領域はＧＵＥＳＳＥ
ＬＥＣＴ　　ＭＡＳＫの構造へのポインタを含まねばな
らない。もしこの 構造が動的に割り当てられるなら、そ れは、ＧＵＥＳが処理の持続時間のた めのそれにアクセスすることを含むの で、フリーであってはすらない。

ｎｆｕｎｃ　　　これはイベントの受け取り時にＧＵＥ
Ｓにより呼び出されるユーザー通 知ルーチンのアドレスである。

ｕｄａｔａ　　　　ｎｆｕｎｃ”内ヘパスされるユーザ
ーデータ。出力パラメータ＝ ｔｙｐｅｄｅｆ　　５ｔｒｕｃｔ　　ｇｕｅｓ　　ｏｕ
ｔ　　ｐａｒｓ ｓｕｂ　　ｉｄ　　　ＧＵＥＳはこの共用のための識別
子を戻す。

この共用は、５ｅｌｅｃｔ（２）システム呼び出しによ
り実行されるような、Ｉ１０状態を通知されるマルチプ
ルユーザーを許容する。このＧＵＥＳサービスの各共用
者は、ファイルデスクリブターマスクのセットを有して
おり、これは共用者がリード、ライトおよびイクスペク
ンヨンの状態に関係があるかのファイルを示している。

セレクト（２）呼び出しカ月１０状態を示す時はいつで
も、ＧＵＥＳは各共用者のための単独の通知をスケジュ
ールし、各共用者のセレクトマスクは１または１以上の
デスクリブターをその状態と共に指示する。通知は次の
ように呼び出されるようにスケジュールされる。

（本ｎｆｕｎｃ）　　（ｓｕｂ　　ｉｄ、　　ＧＵＥＳ
　　ＥＶＥＮＴ　　５ＥＬＥＣＴ、　　ｕｄａｔａ。

ｍａｓｋ−ｐｔｒ、　ｇｕｔ　ｑｕｉｄ）；“ｇｕｔ　
　ｑｕｉｄ”は通知が実行されるｑｕｉｄであり、“ｍ
ａｓｋ　　ｐｔｒ”はセレクト（２）呼び出しく例えば
、それはファイルの共用者にその状態が存在することを
示す）からの出力を含むＧＵＥＳ　　５ＥＬＥＣＴ　　
ＭＡＳＫへのポインタである。

ｕｓｅｒ　ｅｖｅｎｔ　ｒｅｃｅｉｖｅｄＯユーザー通
知イベントの連続の呼び出し フォーマット：　　ｖｏｉｄ　ｕｓｅｒ　ｅｖｅｎｔ　
ｒｅｃｅｉｖｅｄ（ｓｕｂ−ｉｄ、　ｅｖｅｎｔ−ｔｙ
ｐｅ、　ｕｄａｔａ、　ｅｖｅｎｔ　ｐａｒａｍ、　ｑ
ｕｉ　ｑｕｉｄ）パラメータ： ｓｕｂ　　ｉｄ　　　これは共用ＩＤで、これはニーザ
ーが通知されたイベントを共用した ときＧＵＥＳにより戻される。

ｅｖｅｎｔ　　ｔｙｐｅ　　　これは、（ＧＵＥＳ−Ｅ
ＶＥＮＴ　　ＶＳ　　５ＩＧＮＬ、ＧＵＥＳ　　ＥＶＥ
ＮＴ　　ＩＮＴ、ＧＵＥＳ　　ＥＶＥＮＴ　　０ＢＩＴ
、又１ｔＧＵＥｓ　　ＥＶＥＮＴ　　５ＥＬＥＣＴ）に
到達するイベントの型を示す。

ｕｄａｔａ　　　これはユーザーデータパラメータであ
り、これはＧＵＥＳによりパスさ れる。それは共用時にユーザーにより 指示される値を有している。

ｅｖｅｎｔ　　ｐａｒａｍ　　　このパラメータの使用
は特定のイベントの型に依存してい る。

ｑｕｉ　　ｑｕｉｄ　　　通知が実行されるＧＵＩｑｕ
ｉｄを指示する。このルーチンは、 以前に共用されたイベントが受け取ら れたとき呼び出される。このルーチン の名前はユーザーにより実際に割り当 てられ、そのアドレスは共用呼び出し にパスされる。例えば“ｕｓｅｒ　　ｅｖｅｎｔ　　ｒ
ｅｃｅｉｖｅｄ（）”の名前が使用される。

ＧＵＴＳタイマと違って、イベント共用は処理の実施の
間有効である。通知ルーチンからの共用を更新する必要
はない。

第１１章　　ＧＵＩ　　プログラミング例この章では、
アンペンドされた（ｕｎｐｅｎｄｅｄ）リードサービス
を提供する単一のＧＣＳＰを実行するためのＧＵＩの使
用を示す。またそれは、アンペンドされたリードを達成
するために、ＧＣＳＰのサービスを実施する単一のユー
ザーを示す。この例は“Ｃ”言語で書かれているが、完
全なプログラムとして意図されてはいない。むしろ、そ
れはＧＵＩの使い方を示すことを意図している。この例
はＡＯ３／ＶＳを示すが、それはベンドされたＩｌｏへ
のスレーブＡＯ３／ＶＳタスクを使用するからである。

これは、もしＵＮＩＸポータビリティが問題ならばＧＵ
Ｉが使用される方法ではないが、より実際的な例は不必
要に複雑となり説明には適さないものとなろう。

この例はまたエラーチエツクでは比較的弱い。

ＧＵＩの実際のユーザーは徹底的にリターンコードをチ
エツクするが、それはＧＵＩリクエストを間違えると後
でトレースすることが深刻かつ困難となるからである。

Ｇｌｏｂａｌｓ ＧＩＪＩ−ＱＵＩＤ　　５ｌａｖｅ　ｑｕｉｄ；　　７
本　Ｑｕｉｄ　　ａｌｌｏｃａｔｅｄ　　ｔｏ　ＧＣＳ
Ｐ　　５ｌａｖｅ　　ｔａｓｋ　　＊／ＧＵｊＱＵＩＤ
　　ｕｓｅｒ−ｑｕｉｄ；　　／ネ　Ｑｕｉｄ　　ｏｆ
　　ｕｓｅｒ’　ｓ　＋ａａｉｎ　　ｔａｓｋ　　本／
Ｅｎｄ　Ｇｌｏｂａｌｓ ＧＣＳＰ　Ｃｏｄｅ ／＊　ＧＣＳＰ　　１ｎｉｔＯ本 ＊　Ｒｏｕｔｉｎｅ　ｔｏ　ｂｅ　ｃａｌｌｅｄ　ｂｙ
　ｕｓｅｒ、　ｔｏ　１ｎｉｔｉａｌｉｓｅ　ｔｈｅ　
ＧＣＳＰ。

本Ｓｐａｗｎｓ　ａ　５ｌａｖｅ　ＶＳ−Ｔａｓｋ、　
ｔｏ　ｄｏ　ｐｅｎｄｅｄ　ｒｅｑｕｅｓｔｓ。

本／ ＧＣＳＰ　１ｎｉｔ　Ｏ（ｅｘｔｅｒｎ　ＧＣＳＰ　５
ｌａｖｅ　Ｏ：ｍｔａｓｋ　　（ＧＣＳＰ−ｓｌａｖｅ
、　　＄５ＴＡＣＫ−３ＩＺＥ）；　　７本　５ｔａｒ
ｔ　　５ｌａｖｅ　　ｔａｓｋ　　本／ｇｕｉ　　１ｎ
ｉｔｉａｌｉｓｅ　　Ｏ＋７本　ＧＣＳＰ　　５ｌａｖ
ｅ　　□ 宰 本Ｒｕｎ５　ａｓ　ａ　５ｌａｖｅ　ＶＳ−ｔａｓｋ、
　Ｊｕｓｔ　ｃａｌｌｓ　ｇｕ辷ｒｖｎ、　ｆｒｏｍ　
ｗｈｅｒｅ　ａｎｙ零５ｃｈｅｄｕｌｅｄ　ｃａｌｌｓ
　ｗｉｌｌ　ｂｅ　ｒｕｎ。

本／ ＧＣＳＰ−ｓｌａｖｅ　　Ｏ ／＊　Ｒｕｎ　　ａｎｙ　　ｒｏｕｔｉｎｅｓ　　ｔｈ
ｅ　ＧＣＳＰ　　ｔｅｌｌｓ　　ｕｓ　　ｔｏ、　　本
／四辷ｒｕｎ　（ＧＵｊＯＦＴＩＯＮ−ＰＥＮＤ）　；
７本　ＧＣＳＰ　　ａｓ）ｍｃ−ｒｅａｄ□ネ 本Ｔｈｅ　ｕｎｐｅｎｄｅｄ　ｒｅａｄ　Ｒｅｑｕｅｓ
ｔ　ｒｏｕｔｉｎｅ、　Ｂｕｉｌｄｓ　ａｎ　１ｎｔｅ
ｒｎａｌ本ｒｅｐｒｅｓｅｎｔａｔｉｏｎ　ｏｆ　ｔｈ
ｅ　ｒｅｑｕｅｓｔ　（ｕｎｄｅｒｓｔｏｏｄ　ｗｉｔ
ｈｉｎ　ｔｈｅ零ＧＣ３Ｐ）、　ａｎｄ　５ｃｈｅｄｕ
ｌｅｓ　ｉｔ　ｔｏ　ｎｍ　ｏｎ　ｔｈｅ　５ｌａｖｅ
　ｔａｓｋ。

零 零Ｔｈｅ　５ｌａｖｅ　ｗｉｌｌ　ｃａｌｌ　ｔｈｅ　
ｕｓｅｒｓ　ｎｏｔｉｆｉｃａｔｉｏｎ　ｒｏｕｔｉｎ
ｅ、　ｗｈｅｎ　ｔｈｅ本　ｒｅａｄ　　ｉｓ　　ｄｏ
ｎｅ、本／ＧＣ３Ｐ−ａｓｙｎｃ−ｒｅａｄ　（Ｎｆｕ
ｎｃ、　ｑｕｉｄ、　ｂｕｆｆ、　ｆｐ、　ｎｂｙｔｅ
ｇ）ｖｏｉｄ　　（本Ｎｆｕｎｃ）　　Ｏ；　　７本　
Ｕｓｅｒｓ　　ｎｏｔｉｆｉｃａｔｉｏｎ　　ｒｏｕｔ
ｉｎｅ　本／ＧＵｊＱ［ＩＩＤ　ｑｕｉｄ；　　／＊　
　Ｕｓｅｒ　ｑｕｉｄ　　ｔｏ　　ｒｕｎ　　ｎｏｔｉ
ｆｉｃａｔｉｏｎ　　ｏｎ　　零）ｃｈａｒ　＊ｂｕｆ
ｆ；　　／＊　　Ｂｕｆｆｅｒ、　　ｔｏ　　ｒｅａｄ
　　１ｎｔｏ　本／ＦＩＬＥ　＊ｆｐ；　　７本　Ｆｉ
ｌｅ　ｄｅｓｃｒｉｐｔｏｒ　　ｔｏ　　ｒｅａｄ　　
ｆｒｏｍ　　本／Ｉ？ＪＴ３２　　ｎｂｙｔｅｓ：　　
７本　Ｎｕｍｂｅｒ　ｏｆ　　ｂｙｔｅｓ　　ｔｏ　　
ｒｅａｄ　　本／ＲＥＡＤ−ＰＫＴ　＊ｒｅａｄＪｅｔ
；ｅｘｔｅｒｎ　５ｌａｖｅ−ｒｅａｄ□　；７本　＾
１１ｏｃａｔｅ　　ａｎ　　１ｎｔｅｒｎａｌ　　ｒｅ
ｑｕｅｓｔ　　ｐａｃｋｅｔ、　　ａｎｄ　　ｆｉｌｌ
　　ａｎ本　ｐａｒａｓｅｔｅｒｓ　　ｆｒｏｓ　　ｏ
ｕｔ　　ａｒｇｕｍｅｎｔｓ、　　本／ｒｅａｄＪｅｔ
　＝　　（ＲＥＡＤ−ＰＫＴ本）ａｌｌｏｃ　　（ｓｉ
ｚｅｏｆ　　（ＲＥＡＤ−ＰＩＴ））；ｒａａｄ、Ｊｔ
−＞ｆｐ　−ｆｐ； ｒｅａｄＪｅｔ−＞ｂｕｆｆ　−ｂｕｆｆ；ｒｅａｄＪ
＜ｔ−＞ｎｂｙｔｅｓ　＝ｎｂｙｔｅｓ；／＊　５ｃｈ
ｅｄｕｌｅ　　ｔｈｅ　ｐｅｎｄｅｄ　　ｒａａｄ　　
ｔｏ　ｈａｐｐｅｎ　　ｏｎ　　ｏｕｒ　　５ｌａｖｅ
　　ｔａｓｋ　　、、　　本／ｇｕｉ−ｓｃｈｅｄｕｌ
ｅ　（ｓｌａｖｅ　ｑｕｉｄ、５ｌａｖｅ　ｒｅａｔ　
ｒｅａｄＪｔｔ）；／＊　、、、　　ａｎｄ　　ｒｅｔ
ｕｒｎ　　寧／ｒｅｔｕｒｎ　（ＯＮ）； ／零　５ｌａｖｅ−ｒｅａｄ　　０ 本 本Ｔｈ１ｓ’　ＧＣＳＰ　ｒｏｕｔｉｎｅ　ａｃｔｕａ
ｌｌｙ　ｄｏｅｓ　ｔｈｅ　ｐｅｎｄｅｄ　ｒｅａｄ。

本Ｉｔ　ｉｓ　ｒｕｎ　ｆｒｏｍ　ｇｕｉ　ｒｕｎ、　
ｏｎ　ｔｈｅ　５ｌａｖｅ　ｔａｓｋ、　ｗｈｅｎ　５
ｃｈｅｄｕｌｅｄ　ｂｙ零　ＧＣＳＰ−ａｓｙｎｃ−ｒ
ｅａｄｙ、本／５ｌａｖｅ　ｒａｎｄ　（ｒｅａｄＪｔ
）ＲＥＡＤ　ＰＫＴ　ｔｒｅａｄ　Ｊｋｔ；／木　Ｄｏ
　　ｔｈｅ　　ｐｅｎｄｅｄ　　ｒｅａｄ、　　零／ｆ
ｒｅａｄ　（ｒｅａｄＪｋｔ−＞ｂｕｆｆ、　ｒｅａｄ
Ｊｅｔ−＞ｎｂｙｔｅｓ、　１．　ｒｅａｄＪｋｔ−＞
ｆｐ）；７本　Ｒｅｑｕｅｓｔ　　ｄｏｎｅ　　−５ｃ
ｈｅｄｕｌｅ　　ｔｈｅ　　ｎｏｔｉｆｉｃａｔｉｏｎ
　　ｈａｃｋ　　ｏｎｔｏ　　ｔｈｅ本Ｕｓｅｒ’　ｓ
　Ｕｉｎ　ｔａｓｋ：　ｐａｓｓｉｎｇ　ｔｈｅ　ｆｕ
ｌｌ　ｄａｔａ　ｂｕｆｆｅｒ　ｂａｃｋ　ｉｓネ　’
ａｒｇｌ’　　本／ ／＊　　Ｆｒｅｅ　　ｕｐ　　ｔｈｅ　　１ｎｔｅｒｎ
ａｌ　　ｒｅｑｕｅｓｔ　ｐａｃｋｅｔ　　本／ｆｒｅ
ｅ　（ｒｅａｄＪｅｔ）； ｒｅｔｕｒｎ　（ＯＫ）； Ｅｎｄ　ＧＣ３Ｐ　Ｃｏｄｅ Ｕｓｅｒ　Ｃｏｄｅ ７車　Ｔｈｅ　　Ｕｓｅｒ’ｓ　　１ａｉｎ　　ｒｏｕ
ｔｉｎｅ、　　Ｔｈ１ｓ　　ｓｉｍｐｌｅ　　ｅｘａｍ
ｐｌｅ　　ｊｕｓｔ　　１ｓｓｕｅｓ＊　Ｕｎｐｅｎｄ
ｅｄ　ｒｅａｄｓ　ａｎｄ　ｗａｉｔｓ　ｆｏｒ　ｔｈ
ｅｍ　ｔｏ　ｃｃｍｐｌｅｔｅ、　ｕｎｔｉｌ　ｔｈｅ
本　Ｅｎｄ−ｏｆ−Ｆｉｌｅ　　ｉｓ　　ｒａａｃｈｅ
ｄ、本／ＵＳＥＲｍａｉｎ　０ ＦＩＬＥ　　＊ｆｐ； ｃｈａｒ　ｂｕｆｆ　［＄ＢＵＦＦ−ＳＩＺＥ］　；ｅ
ｘｔｅｒｎ　ＵＳＥＲｒｅａｄ−ｄｏｎｅ　Ｏ：／木　
Ｉｎ１ｔｉａｌｉｓｅ　　ｔｈｅ　　ｗｏｒｌｄ　　　
宰／四辷１ｎｉｔｉａｌｉｓｅ　Ｏ＋ ＧＣ３Ｐ　１ｎｉｔ　Ｏ； 四辷ａｌｌｏｃａｔｅ　ｑｕｉｄ　（１，ＮＵＬＬ、　
＆ｕｓｅｒ−ｑｕｉｄ）；ｆｐ　＝　ｆｏｐｅｎ　（”
ｔｅｓｔｆｉｌｅ”、”ｒ”）；ｗｈｉｌｅ　（ｌｆｅ
ｏｆ　（ｆｐ））７本　１１ａｋｅ　　ｕｎｐｅｎｄｅ
ｄ　　ｒｅｑｕｅｓｔ、　　本／ＧＣ３Ｐ　ａｓｙｎｃ
　ｒｅａｄ　（ＵＳＥＲ−ｒｅａｄ−ｄｏｎｅ、　ｕｓ
ｅｒ　ｑｕｉｄ、　ｂｕｆｆ、　ｆｐ）；７本　Ｉｎ　
　ｐｒａｃｔｉｃｅ、　　ｔｈｅ　　ｕｓｅｒ　ｗｏｕ
ｌｄ　　ｄｏ　　ｓｏｍｅ　　ｏｔｈｅｒ　ｐｒｏｃｅ
ｓｓｉｎｇ本　ｈｅｒｅ、　　Ａｌ５ｏ、　　ｔｈｅｒ
ｅ　　ｗｏｕｌｄ　　ｐｒｏｈａｂｌｙ　　ｂｅ　ｍｕ
ｌｔｉｐｌｅ　　ｒｅｑｕｅｓｔｓ本ｏｕｔｓｔａｎｄ
ｉｎｇ。

本　Ｆｏｒ　　ｓｉａ＋ｐｌｉｃｉｔｙ　　ｉｎ　　ｔ
ｈｉｓ　　ｅｘａｍｐｌｅ、　　ｗｅ　　ｊｕｓｔ　　
ｗａｉｔ　　ｆｏｒ　　ｔｈｅ本　ｒｅａｄ　　ｔｏ　
ｃｏｍｐｌｅｔｅ、　　零／ｇｕｉ　ｒｕｎ　（ＧＵＩ
−ＯＦｒＩＯＮ　ＰＥＮＤ）＋７本　ＵＳＥＲ，、−ｒ
ｅａｄ−ｃｏｍｐｌｅｔｅネ 本Ｔｈｅ　ｕｓｅｒ’　ｓ　ｎｏｔｉｆｉｃａｔｉｏｎ
　ｒｏｕｔｉｎｅ、　ｃａｌｌｅｄ　ｂｙ　ＧＵｌ、　
ｆｒｏ＋ｎ　ｇｕｉ　ｒｕｎ。

本ｗｈｅｎ　ｔｈｅ　ｒｅｑｕｅｓｔ　ｃｏａ＋ｐｌｅ
ｔｅｓ。

本Ｉｔ　ｄｏｅｓ　５ｏｔａｅ　ｐｒｏｃｅｓｓｉｎｇ
　ｏｆ　ｔｈｅ　ｒｅｃｅｉｖｅｄ　ｄａｔａ、　ａｎ
ｄ　ｔｈｅｎ　ｃａｌｌｓ本ｇｕｉ　ｗａｋｅｕｐ□、
　ｓｏ　ｔｈａｔ　ｗｈｅｎ　ｗｅ　ｒｅｔｕｒｎ、　
ｔｔｒｅ　ｔａｓｋ　ｗｉｌｌ　ｒｅｔｕｒｎ本ｆｒｏ
＋＊　ｇｕ辷ｒｕｎ、　ｅｎａｂＩｉｎｇ　ａｎｏｔｈ
ｅｒ　ｒｅｑｕｅｓｔ　ｔｏ　ｂｅ　ｍａｄｅ、本／ｐ
ｒｏｃｅｓｓ−ｄａｔａ　　（ｂｕｆｆ）；　　／＊　
　Ｄｏｎ’　ｔ　　ｃａｒｅ　　ｗｈａｔ　　ｉｔ　　
ｄｏｅｓ　　本／四辷ｗａｋｅｕｐ　（ｕｓｅｒ−ｑｕ
ｉｄ）　；ｒｅｔｕｒｎ　（ＯＮ）；Ｉ Ｅｎｄ　Ｕｓｅｒ　Ｃｏｄｅ 第１２章　内部構造 この章は、ＧＵＩのＡＯ８／ＶＳ版の設計を表す。ＵＮ
ＩＸ版とＭＳ−ＤＯ８版とは、出来る限り類似しつるか
、相違っは存在する。特定のかつ明白な相違あるいはイ
シュウ（ｉｓｓｕｅ）がある本明細書の各個所で、［Ｕ
ＮＩＸ：ＵＮＩＸイシュウのチクスト］のように鍵括弧
のコメントにより記される。

ＧＵＩは、第１８図に示されるように非常に単純な構造
を有する。ＧＵＩは、単に１組のキュウから成る太線ブ
ロック１８０により表される。この１組のキュウの４つ
が、ここではランされるべき通知待機を含むＱｌ、Ｑ２
．Ｑ３およびＱ４により示される。キュウはｒｇｕｉ　
　ａｌｌｏｃａｔｅ　　ｑｕｉｄＯＪを呼び出すことに
より割り当てられる。通知は、図に示されるように、［
ｇｕｉ　　５ｃｈｅｄｕｌｅ（）ゴを呼び出すことによ
りキュウ上に配置され、ｒｇｕｉ　　ｒｕｎＯＪにより
キュウから取り出される。第１８図は他のＧＵＩルーチ
ンを図示していない。

ＧＵＩは、ネットワーク通信システムに対して制御環境
のタスクとフローの基礎を形成する。

ユーザ・アブリケーンヨン１８１は、１つ以上のＧＣＳ
Ｐ、図においては２つのｃｃｓＰ１８２および１８３に
アンペンデッド要求をする。これらのＧＣＳＰは、次に
他のＧＣＳＰに要求をし、ＧＣ８Ｐ１８および１８３は
、第１８図の例のおいては、経路１８４により互いに通
信することが示される。

そのプロセスの過程において、ＧＣＳＰは、それ自身に
おいて、他のＧＣＳＰにおいて、あるいはユーザにおい
て、呼ばれるルーチンをスケ−ジュールしうる。このス
ケジューリングは、ＧＣＳＰからｒｇｕｉ　　５ｃｈｅ
ｄｕｌｅＪへの矢印１８５により示され、そして内部Ｇ
ＵＩキュウ上に置かれ、かつｒｇｕｉ　　ｒｕｎＪによ
り取り出される通知をもたらす。典型的には、このスケ
ジューリングは、外部イベントを待機する個別のＶＳタ
スクからなされる［ＵＮＩＸ／ＭＳ−ＤＯＳ　：インタ
ラブト・レベルから］。

ユーザが、ｒｇｕ　ｉ　　ｒｕｎＪを呼ぶとき、スケ−
ジュールされたルーチン呼び出しが、ランを得る。これ
は、キュウＱ１ないしＱ４から「ｇｕｉ　　ｒｕｎＪへ
の矢印１８７と、ユーザ１８１からｇｕｉ　　ｒｕｎＯ
への矢印１８８とにより示される。スケ−ジュールされ
た呼び出しは、再び矢印１８６により示されるように、
ユーザ１８１に、あるいは、呼び出されているＧＣＳＰ
１８２．１８３内にルーチンを生じうる。

先に留意したように、ユーザは、ｑｕｉｄｓへのルーチ
ンをスケ−ジュールする必要がありうる。

これは、接続１８９により示される。

第１３章　データ構造の仕様 ＧＵＩの通知の一時的なかつランタイムの特定の性質の
ため、プロセスの呼び出しにかかるいずれの情報を保存
する必要がない。従って、ＧＵＩ構造の全てはメモリ常
駐である。オン・ディスク構造はない。以下のデータ構
造においては、ＭＶ上にあるように示される種々のメン
バー（特にポインタ）のサイズが描かれる。これらは、
かなずしもＰＣ上である同じではない。

１３．１ＧＵＩキユウ ＧＵＩ内のメインデータ構造はジョブ・キュウである。

これらは、ｒｇｕｉ　　５ｃｈｅｄｕｌｅｊとｒｇｕｊ
　　ｒｕｎＪとの間の唯一のカップリングを形成する。

ジョブ・キュウは、パー・タスク・ヘッダからアンカー
オフされる。このパー・タスク・ヘッダは、それ自身で
、リンクされたリスト上にあり、単一のキュウ記述子で
アンカーされる。

従って、唯一のグローバル・アンカーがあり、それを全
てのＧＵＩ構造は直接的にあるいは間接的に解き放つ。

ジョブ・キュウ上のエントリーは、ＧＵＩが、指示され
たパラメータとともに要求された通知をランするのに必
要な情報を含む通知制御ブロック（ＮＣＢ）である。

典型的な構成は、第１９図に示される。この例は、Ｎ個
のオーナ（ＶＳタスク）に対するジョブ・キュウ・リス
トを示す。［ＵＮＩ　Ｘ／ＭＳ−Ｄ。

Ｓ、唯一のオーナが存在する。］ オーナ１は、割り当てられた２つのｒｑｕｉｄＳ」ジョ
ブＱ１、Ｑ２を有し、２つのジョブは、これらの第１の
上ヘスケージュールされ、第２にはなにもない。オーナ
２とオーナＮとは、各々割り当てられた１つのｑｕｉｄ
を有し、スケ−ジュールされたジョブは伴わない。

全てのリストは、二重リンクされたＭＶキュウであ−リ
、そのためＭＶハードウェア・キュウ命令を用いること
ができる。これらの命令は、アトミックであり、ロック
の必要を排除する。［ＵＮＩＸ／ＭＳ−ＤＯＳ：これら
の環境におけるハードウェアが類似した命令を与えない
場合には、エンキュウとデキュウの持続時間に対する割
込みを使用不能にする必要がありうる。コ １３．１．Ｉ　　ＧＵＩ　　ＲＯＯ前記述子これは、全
てのＧＵＩキュウ用のルート・アンカーである。それは
、第２０図に示される構造を有する。この２つのメンバ
ーは、ポインタであり、これらのポインタはそれぞれ、
最初のオーナ・キュウと最後のオーナ・キュウを指示す
る。全てのＭＶキュウに関して、Ｑが空である場合には
、これらのメンバーはともに−１である。

１３、　１．　２　　パー・オーナ・リスト・アンカー
この構造は、リスト上でＧＵＩ　　ＲＯＯＴでアンカー
され、第２１図に示されるものである。それは、ｒｎｅ
ｘｔＪポインタ、ｒｐｒｅｖＪポインタ、オーナ　ｉｄ
ｌおよびそのユーザにより所有されるｒｑｕｉｄｓＪの
リスト用のＱ記述子を含む。このアンカーを解き放つジ
ョブ・キュウは、優先して分類される。オーナによるそ
のＱへのアクセスを制御するために用いられる数フィー
ルドもある。

「オーナ」フィールドは、このリスト上のジョ、　ブ・
キュウのオーナ・タスクを識別する。ＶＳタスク−ＩＤ
を発見するためのシステム呼び出しのオーバヘッドを避
けるため、オーナ・タスクのスタック・ベースが、この
識別のため用いられる。

この方法は、ＤＧ言語ランタイム・ライブラリに共通で
あり、従って、特別の制約を課すことはない。

ｒｍｂｏｘＪは、タスク間メイルボックスであり、所有
されたジョブ・キュウのいずれか上でスケジュールされ
た通知がないとき、オーナが、ペンデッドｒｇｕｉ　　
ｒｕｎＪを行う場合は、そのオーナは、そのメイルボッ
クス上に待機する。タスクが、それに所有されたｒｑｕ
ｉｄＪ上で「ｇｕｉ　　５ｃｈｅｄｕｌｅＪまたはｒｇ
ｕｉ　　ｗａｋｅｕｐＪを行うとき、別のタスクが起動
される。

ＶＳタスク間シスンテム呼び出しく？ＲＥＣと？ＸＭＴ
）は、この目的のために用いられるであろう。

［ＵＩＸ／ＭＳ７ＤＯＳ　：起動は、割込みレベルから
なされるでろう。スピン・ロックはＭＳ−ＤＯＳのため
と、ＵＮＩＸ用のｒｓｅｌｅｃｔＯＪシスンテム呼び出
しのためとに用いられるであろう。］ ｒｓｔａｔｕｓＪフィールドは、種々の制御ビットを含
み、第２２図に定義されている。「ｒｕｎｎｉｎｇＪビ
ットは、ＧＵＩがこのオーナに向けて通知をランしてい
るときセットされ、ｒｇｕ　１ｒｕｎＪのネステッド呼
び出しを阻止するために用いられる。ｒｗａｉｔｉｎｇ
Ｊビットは、タスクがｒｍｂｏｘＪ上で待機していると
き用いられる。ｒｗａ　ｋ　ｅ　　ｕ　ｐＪビットは、
現在ランしているジョブの後にランしているタスクを起
動させるためにセットされる。ｒｊｏｂ　　５ｃｈｅｄ
ｕｌｅｄＪビツトは、ジョブがスケジュールされるとき
は常にｇｕｉ　　５ｃｈｅｄｕｌｅによりセットされる
。このことは、そうでないときに存在するであろうウィ
ンドウを、別の■Ｓタスクがランすべきジョブを検索し
ている間にジョブがスケジュールを得るとき、閉じる。

１３、　１．　３　　ジョブ・キュウ・アンカーこの構
造は、所与のｒｑｕｉｄＪに対する実際のＮＣＲがアン
カーされるものである。それは第２３図に示され、ジョ
ブＱ　　ｉｄ　　ｒｑｕｉｄＪと、ＮＣＢに対して通常
のＱ記述子を加えたその優先順位とを含む。

１３、　１．　４　　通知制御ブロックこれらは、ジョ
ブＱ上ヘキュウされる制御ブロックである。各々は、ス
ケジュールされた通知を表し、それをランするのに必要
な全ての情報を含む。

これらの制御ブロックは、第２４図に示されるフォーマ
ットを有する。ｒｎｅｘｔＪフィールドとｒｐｒｅｖＪ
フィールドとは、このジョブＱ上でそれぞれ次のＮＣＢ
と先のＮＣＢとを指示する。

他のメンバーは、　　「ｇｕｊ　　ｒｕｎ　ＯＪに渡さ
れるパラメータであって、通知ルーチンがランを得ると
き、それへ渡されるであろうパラメータである。

この構造から、各未定のスケジュールされた通知に対す
るメモリ要件は、７ダブルワード（２８バイト）である
ことが理解できる。メモリがこれらはブロックを使用可
能であることを保証することが、ＧＵＩユーザに残され
るであろう。ＧＵＩがＮＣＢを必要とするとき、ＧＵＩ
はＮＣＢを割り当てることが出来ない場合、ＧＵＩはｒ
ｇｕ　１ｓｃｈｅｄｕｌｅＯＪからエラーを戻すであろ
う。

１３．２　　ｑｕｉｄテーブル ＧＵＩジョブ・キュウへのアクセスをスピードアップす
るため、ｒｑｕｉｄＪによりインデックスされたテーブ
ルが存在し、このテーブルは、ｒｑｕｉｄＪにより識別
されるジョブＱのロケー７ョンを与える。このテーブル
の各エントリは、第２５図に示されるフォーマットを有
する。

ｑｕｉｄテーブルをロックする必要を避けるため、エン
トリは自動的に書込みされる。割り当てられていないｑ
ｕｉｄは、そのテーブル・エントリのｒｊｏｂ　　ｑ　
　ｐｔｒｊフィールドにおいてＮＵＬＬの値を有するで
あろう。割り当て中に、このフィールドは、自動的に充
填され、割り当ての最終段階点で、そのｑｕｉｄは有効
になる。

再び、ロックの必要を避けるため、テーブルは、２５６
エントリの固定サイズでありうる。これは、使用可能な
ｑｕｉｄ数を２５６に制限することを課する。共用アク
セス・スキームは交互に実行されえて、ｑｕｉｄテーブ
ルの共用読出し専用アクセスを許容するが、排他的書込
みアクセスを許容しないで、そのため、テーブルが一杯
になるときそのテーブルは成長されうる。

ｑｕｉｄｓは、１の値で開始して割り当てられ、値Ｏを
特別の値（ＮＵＬＬ　　ＱＴＪＩＤ）としてフリーのま
まにしておく。更に、全ての負の値は無効であり、特別
の意味が確保される。

１３．３　　例により上記したデータ構造のコンテツク
スト内で、この章は、ＧＵＩモジュールの１つが取り得
る動作の単一の例、即ちプロシジャ−ｇｕｉ　　ａｌｌ
ｏｃａｔｅ　　ｑｕｉｄ　（ｐｒｉｏｒｉｔｙ、ｕｓｅ
ｒ　　ｗａｋｅｕｐ）で終わる。

ｅｇｉｎ ｇｅｔ　ｔｈｅ　ｃａｌｌｅｒｓ　５ｔａｃｋ　ｂａｓ
ｅ；５ｅａｒｃｈ　ｔｈｅ　ｏｗｎｅｒ　Ｑ　ｃｈａｉ
ｎ　ｆｏｒ　ａｎ　ａｎｃｈｏｒ　ｏｗｎｅｄ　ｂｙ　
ｔｈｉｓ　ｔａｓｋ；ｉｆ　（ｏｗｎｅｒ　ａｎｃｈｏ
ｒ　ｎｏｔ　ｆｏｕｎｄ）ｅｇｉｎ ａｌｌｏｃａｔｅ　ａ　ｎｅｗ　ｐｅｒ−ｏｗｎｅｒ　
１ｉｓｔ　ａｎｃｈｏｒ；ｆｉｌｌ　ｉｔ　ｉｎ； ａｄｄ　ｉｔ　ｔｏ　ｔａｉｌ　ｏｆ　ｔｈｅ　ｏｗｎ
ｅｒ　Ｑ　ｃｈａｉｎ；ｎｄ ａｌｌｏｃａｔｅ　ａｎｄ　１ｎｉｔ　Ｊｏｂ　Ｑ　ａ
ｎｃｈｏｒ；ｐｕｔ　ａｌｌｏｃａｔｅｄ　ｑｕｉｄ　
１ｎｔｏ　Ｊｏｂ　Ｑ　ａｎｃｈｏｒ；ｐｕｔ　ｕｓｅ
ｒ　ｗａｋｅｕｐ　１ｎｔｏ　Ｊｏｂ　Ｑ　ａｎｃｈｏ
ｒ；ａｄｄ　　Ｊｏｂ　　Ｑ　　ｔｏ　　ｔｈｅ　　ｏ
ｗｎｅｒｓ　　Ｊｏｂ　　Ｑ　　ｃｈａｉｎ、　　ａｔ
　　ａ　　ｐｏｉｎｔ　　ｄｅｔｅｒｍｉｎｅｄｂｙ　
ｐｒｉｏｒｉｔｙ： ｏｂｔａｉｎ　ｔｈｅ　ｎｅｘｔ　ａｖａｉｌａｂｌｅ
　ｑｕｉｄ、　ａｎｄ　ｃｌａｉｍ　ｔｈａｔ　５ｌｏ
ｔ　ｉｎ　ｔｈｅｑｕｉｄ　ｔａｂｌｅ； Ｐｕｔ　ｐｏｉｎｔｅｒｓ　ｔｏ　ｔｈｅ　ｏｗｎｅｒ
　ａｎｃｈｏｒ、　ａｎｄ　Ｊｏｂ　Ｑ、　１ｎｔｏ　
ｔｈｅｃｌａｉｍｅｄ　５ｌｏｔ； ｒｅｔｕｒｎ　ｔｈｅ　ｑｕｉｄ　ｊｕｓｔ　ａｌｌｏ
ｃａｔｅｄ；ｎｄ ｇｕｉ　　５ｃｈｅｄｕｌｅ、ｇｕｉ　　ｒｕｎ等のモ
ジュール仕様は、類似して導くことができる。

１３．４ＧＵＩメモリ管理 ＧＵＩは、メモリ・ブロックのプールされたものから成
り、かつＮＣＲ，ジョブＱおよびオーナ・アンカーにと
って適当なサイズからなるＧＵＩ自身のメモリ管理スキ
ームを有することが出来る。

このスキームの目的は、要求された大部分のメモリが同
じサイズのブロックにあるという知識に基づいて、標準
Ｃランタイムより効率的な割り当て機構を提供すること
にある。しかし、標準Ｃ機能ｒａｌｌｏｃＪおよびｒｆ
ｒｅｅＪを用いてもよい。

第１４章　ＧＵｒおよび通信サーバー・システム第２６
Ａ図および第２６Ｂ図は、メツセージがネットワーク・
インターフェースから受信され、その宛て先に送られる
ことを必要とするとき住しる動作の基本的概要を示す。

これは、過剰の詳述から不明が生じることを避けるため
、単純化・された例として純粋に与えられる。送るべき
メツセージがあるという通知が、別のサーバー・プロセ
スからＩＰＣの形式で、特別のルーチン４５（第３図）
から到来するであろう。ソフトウエア・インターフェー
ス４４は、２６２で示されるように、ｑｕｉ　　ｒｕｎ
　（ｐｅｎｄ）内で待機していると想定する。２６４で
、ＩＰＣは到来し、ルーチンをＧＵＩ　　ｑｕｉｄ上に
置く。ゲートウェイがＣＥＯゲートウェイ１２Ａである
場合、例えば、これは、２６６でルーチンＣｅＯｍＳｇ
　　ｒＣＶｄ　Ｏである。ソフトウエア・インターフェ
ースがｑｕｊ　　ｒｕｎ　（ｐｅｎｄ）にあるため、ｃ
ｅｏ　　ｍｓｇ　　ｒｃｖｄＯはランされ、別のルーチ
ン、即ち同様にランされる２６８でのｂｕｉｌｄ　　Ｐ
ＤＵＯをスケジュールする。このルーチンは、それ自体
よく理解された機能を実行するＴ００ＬＳルーチンであ
る。それは、ＵＭＢ上で用いられるＸ４００　１９８８
フオーマツトでＰＤＵを組立て、ＣＥＯメツセージから
の各フィールドを得ることにより、ＡＲＴ　　Ｘ４００
を利用し、そのメツセージをＵＭＢフォーマットに変換
し、それを、組立てられているＰＤＵに加える。これは
、通常実行されつる単純なアト・アイテム・ルーチン　
ａｄｄｉｔｅｍＯにより、かつｑｕｉｓｃｈｅｄｕｌｅ
ｄされ、ｑｕｉ　　ｒｕｎされるプロシジャ−を介さず
になし得る。それは、ＡＲＴルーチンが多数の処理を行
わないからである。

ｃｅｏ　　ｍｓｇ　　ｒｃｖｄ　Ｏはまた、メツセージ
を汎用メツセージ・バックボーン１５上へ送り出すＧＣ
８Ｐ　　ｒｅｑｕｅｓｔ　　ＴＯＯＬＳ−ｓｅｎｄＯを
２７０においてスケジュールスル。

ＴＯＯＬＳ　　５ｅｎｄ　Ｏは、最初に内部処理２７２
を実施し、それは、あらゆる受信者に対する受信者リス
トを介して進み（一般に２以上で有り得る。）、２７４
で示されるようにあらゆる受信者に対してディレクトリ
探索をする。ディレクトリ探索は、個別ディレクトリ・
サーバ・プロセスにより処理され、また２７６でのｑｕ
ｉ　　ｒｕｎ内でランし、各探索は、ＩＰＣ２７８によ
り開始され、その結果は、ＩＰＣ２８０により戻される
。

ディレクトリ完了は、２８２で順に各探索に対して決定
され、次にメツセージは、２８４（第２６Ｂ図）におけ
るＧＣＳＰ要求ルーチンｍｔｉ　　５ｅｎｄＯに提出さ
れる。このルーチンはＵＭＢ１５への実際の送信を実行
する。ネットワークの接続が確立され、イベント「接続
完了」２８８が、ルーチンｍｔｉ　　ｃｏｎｎｅｃｔｅ
ｄ　　２９０を介して送られる。次に、２９２で、ＴＯ
ＯＬＳ−ｄａｔａ　　ａｃｃｅｓｓ　Ｏは、メツセージ
・データをディスクから得て、データを２９４において
送ることを実行する。このプロシジャ−は、全ての受信
者に対して順に続けられる。

平易にするため、メツセージ送信において続くプロトコ
ルの最もありのままの概要が、単にここに与えられてい
る。図面は、データ確認プロシジャ−も、例えばアスタ
スクにより示される、種々の段階で住じるディスクへの
セーブも図示していない。更に、図面は、ＧＵＩの真の
本質を明らかに出来ない。それは、図面が、リニヤ・プ
ログラミング言語の正規の方法で実行されうるルーチン
の通常のシーケンスを図示するようにみえるからである
。ルーチンは、オペレーションのシーケンスを真に実行
しなければならず、このオペレーションのシーケンスは
、データ通信の十分確立された原理に従わなければなら
ない。しかし、ＧＵｌでの実行についての重要な点は、
ルーチンは、正しいシーケンスにおいて互いを単に呼ば
ないで、完了までペンドされる。むしろ、これらの通知
ルーチン又はジョブは、第１３図ないし第１７図を参照
して先に説明したように、ｑｕｊ　　５ｃｈｅｄｕｌｅ
Ｏを呼び出すことによりＧＵＩ　　ｑｕｉｄｓ上に置か
れ、ｑｕｉ　　ｒｕｎＯを呼び出すことによりランされ
る。

更に、現実の状況においては、多くのメツセージが同時
に処理され、メツセージからメツセージへ処理する種々
の段階にありうる。これは、多かれ少なかれ図面で意味
をもって図示することは不可能であるが、上述したよう
に、ＧＵＩが、この状況を処理するため理想的に適合さ
れることは容易に理解されつる。それは、全ての異なる
通知ルーチン又はジョブが、ＧＵＩ　　ｑｕｉｄｓ上に
置かれ、これら全ては、ｑｕｉ　　ｒｕｎ□を呼び出す
結果として順にランを得るからである。また、通信サー
バ・システムにおいては、ジョブは、変化する優先順位
を有し、異なる優先順位を有するｑｕｉｄｓの使用によ
り異なる優先順位を実行するのは容易である。

■、略語と頭字語 ＡＯ５／ＶＳ　　データ・ゼネラルのＭＶコンビュ−夕
用データ・ゼネラル・オペレ ーティング・システム ＡＲＴ　　　　　ＡＳＮ、１　　ランタイム−ライブラ
リ・ルーチン、転送構文と内部 構文間のデコード／エンコード ＡＳＮ、　　１　　　アブストラクト構文表記法１、デ
ータのタイプの表記のアブストラ クトの定義用国際標準（ＩＳＯ） ＡＵ　　　　　　アクセス単位 Ｃプログラミング言語 ＣＣＩＴＴ　　　国際電信電話諮問委員会ＣＥＯデータ
・ゼネラル・オフィス・オートメーション・システム Ｃ８通信サーバ Ｃ８ＩＤ　　　　呼び出された加入者識別子ＤＧ　　　
　　　データ・ゼネラル・コーポレーション ＤＴＳＯ８Ｓ　　ＩＢＭオフィス・オートメジョン・シ
ステム ＥＣ８外部呼び出しンーケンス ＧＣ５Ｐ　　　　ＧＵＩ−コンフォーマント・サービス
・プロバイダー ＧＵＥ　Ｓ　　　　汎用アンペンデッド・イベント・ハ
ンドラー・サービス ＧＵＩ　　　　　汎用アンペンデッド・インターフェー
ス ＧＵＴＳ　　　　汎用アンペンデッド・タイマ・サービ
ス ＩＤ　　　　　　識別子 ＩＰＣプロセス間通信−２つのプロセス間を渡されるメ
ツセージ Ｉｌｏ　　　　人力／出力 ＩＢＭ　　　　　インタナショナル・ビジネス・マシン
・コーポレーション ＩＳＯ国際標準機構 ＬＡＮ　　　　　ローカル・エリア・ネットワークＭＲ
Ｃメツセージ・ベースの信頼しうるチャネル、標準の４
００Ｍｂ／ｓ ノくス ＭＴＩ　　　　　メツセージ転送インターフェースＭＳ
−ＤＯ８ＰＣ用１ｊｌ準オペレーティング・システム ＭＶ　　　　　　ＡＯ３／ＶＳがランしているデータ・
ゼネラル・コンピュータ ＮＣＢ　　　　　通知制御ブロック Ｏ８コンピュータ用オペレーティング・システム ＰＡＤ　　　　　パラケラト組立て／分解装置ＰＣパー
ソナル・コンピュータ（ＩＢ Ｍまたはクローン） ＰＤＮ　　　　　公衆データ・ネットワークＰＤＵ　　
　　　プロトコル・データ・ユニ・ソトー単一構造のチ
ャンク（ｃｈｕｎｋ） の中を通る情報 ＰＩＤ　　　　　プロセス識別子 ＰＲＯＦＳ　　　ＩＢＭオフィス・オートメーション・
システム ＰＳＴＮ　　　　公衆交換電話ネットワークＰＴＴ　　
　　　郵便電信電話管理局 Ｑ　　　　　　キュウの略記号 ＱＵＩＤ　　　　キュウ識別子 ＲＵＡ　　　　　遠隔使用エージェントＳＮＡ　　　　
　システム・ネットワーク・アーキテクチャＩＢＭネッ
トワーク ５ＮＡＤＳ　　　ＩＢＭメツセージ・プロトコルＶＳ　
　　　　　＝ＡＯ８／ＶＳ Ｘ２５　　　　　パラケラト交換プロトコルＸ４００　
　　メツセージ処理用ＣＣＩＴＴ標準Ｘ５００　　　デ
ィレクトリ・サービス用ＣＣＩＴＴ標準 ＡＯ８／ＶＳ用語の説明のために刊行されたマニュアル
を参照することに留意されたい。

【図面の簡単な説明】

第１図は全システムを示す図、 第２図はシステムの１つのゲートウェイのハードウェア
のブロック図、 第３図はシステムの１つのゲートウェイの機能的ブロッ
ク図、 第４図及び第５図は２つの異なるネットワーク間のメツ
セージ転送を示す図、 第６図乃至第１２図はメツセージ取り扱いの手順をより
詳細に示す図、 第１３図はＧＵＩ（汎用アンペンブト・インターフェー
ス）の下での２つの同時実行タスクのふるまいを示す図
、 第１４図は第１５図乃至第１７図に対するキーを示す図
、 第１５図乃至第１７図はＧＵＩの下でのルーチンの流れ
を示す図、 第１８図はＧＵＩの構造を示す図、 第１９図はＧＵＩに対するジョブ・キュー構造を示す図
、 第２０図乃至第２５図は種々のＧＵＩデータ構造を示す
図、 第２６Ａ図及び第２６Ｂ図は通信サーバ・ネットワーク
におけるＧＵＩの使用例を示す図である。 図面の浄書（内容に変更なし） ｔａ２ Ｆ／ａ、４ ＦＩＯ，５ Ｘ４００　’ｒｌつ’ｘ−（−１２Ｄ−Ｆｔａ、７ ２Ｄ− Ｆｌｃｙ、８ ベエーウ゛リ　　　　　　　　　−１２Ｅ−婁ネ定７ Ｆｔａ、　７６ Ｆｔｃｙ、１８ Ｆｔｃｙ、　１９ 砕 王ＱＪ！ マ ＦＩＧ　２６Ｂへ ＦＩＧ、２６Ａつ゛う １、事件の表示 平成２年特許願第２９５１９４号 ２、発明の名称 ネットワーク通信システム ３、補正をする者 事件との関係　　　特許出願人 住所 名　称　　データー・ゼネラル・コーポレーション４、
代理人 住　所　　東京都千代田区大手町二丁目２番１号６、補
正の対象

Claims (1)

1. 【特許請求の範囲】 １、デジタル計算機システムにおいて、 （ａ）複数のルーチンを含む主処理タスクを実行し、 （ｂ）前記主処理タスクの呼び出しルーチンの実行中に
   サービス・ルーチンを呼び出し、（ｃ）前記呼び出しル
   ーチンを未処理にせずに前記主処理タスクにおける処理
   を更に継続し、 （ｄ）前記サービス・ルーチンを終わらせて通知ルーチ
   ンを識別するジヨブ・データを記憶し、 （ｅ）実行されるべき記憶されたジョブ・データによっ
   て識別された通知ルーチンを生じるために、前記主タス
   ク内のラン・ルーチンを実行する、ステップからなる前
   記計算機システムを操作する方法。 ２、請求項１に記載の方法において、前記ラン・ルーチ
   ンが、実行されるべき通知ルーチンがないときは未処理
   にならず、そのようなイベントのときには前記主タスク
   内に直ちに戻る、非ベンド・モードのインターバルにお
   いてランされることを特徴とする計算機システムの操作
   方法。 ３、請求項１に記載の方法において、前記ラン・ルーチ
   ンが、実行されるべき通知ルーチンがあるときは未処理
   になる、ベンド・モードにおいてランされることを特徴
   とする計算機システムの操作方法。 ４、請求項１に記載の方法において、前記複数の通知ル
   ーチンを識別するジョブ・データが、前記通知ルーチン
   が前記ラン・ルーチンに応答して逐次に実行されるため
   に、少なくとも１つのキューに記憶されることを特徴と
   する計算機システムの操作方法。 ５、請求項４に記載の方法において、複数の前記キュー
   があり、該キューは異なる優先順位を持ち、前記通知ル
   ーチンが前記キューの優先順位に従って実行されること
   を特徴とする計算機システムの操作方法。 ６、請求項５に記載の方法において、前記通知ルーチン
   及び前記キューの同一のものに記憶された識別データが
   、前記キュー内のそれらが置かれた順でランされること
   を特徴とする計算機システムの操作方法。 ７、（ｉ）オペレーティング・システムと、 （ｉｉ）前記オペレーティング・システムの下で実行可
   能な複数のルーチンと、 （ｉｉｉ）ランされるべきルーチンを識別するジョブ・
   データに対する少なくとも１つのキューと、を記憶する
   手段を含むデジタル計算機システムにおいて、前記ルー
   チンは第１、第２及び第３のモジュール内のルーチンを
   含み、前記第１のモジュールはユーザ・ルーチンを含み
   、前記第２のモジュールはサービスを提供するサービス
   ・ルーチンを含み、前記第３のモジュールはインターフ
   ェース・ルーチンを含み、 前記ユーザ・ルーチンは、前記サービス・ルーチンから
   のサービスを要求するルーチンを含み、前記インターフ
   ェース・ルーチンは、ジョブ・データを前記キューに置
   くために各サービス・ルーチンから呼び出し得るスケジ
   ュール・ルーチンと、前記キュー上のジョブ・データに
   よって識別された通知ルーチンをランさせるためにユー
   ザ・ルーチンから呼び出し得るラン・ルーチンと、前記
   ルーチンの第１のモジュールに戻り結果を提供する前記
   サービス・ルーチンの少なくとも幾つかとを含み、 サービス・ルーチンの要求に続いて、サービス・ルーチ
   ンからの戻り結果を待つことなしに前記第１のモジュー
   ル内での処理を継続できることを特徴とするデジタル計
   算機システム。 ８、請求項７に記載のシステムにおいて、前記ラン・ル
   ーチンが、前記キュー上にジョブ・データが無いとき前
   記ラン・ルーチンを未決にするかしないかを指示するフ
   ラグと共に呼び出し得ることを特徴とするデジタル計算
   機システム。 ９、請求項８に記載のシステムにおいて、前記スケジュ
   ール・ルーチンが、ジョブ・データが前記キューにあり
   、それによって該ジョブ・データによって識別された前
   記通知ルーチンをランさせるとき、前記ラン・ルーチン
   に信号するように動作可能であることを特徴とするデジ
   タル計算機システム。 １０、請求項８に記載のシステムにおいて、前記第３の
   モジュールが更に、前記ラン・ルーチンが未決にされた
   とき、戻るべきことをそれに信号するようにユーザ・ル
   ーチンによって呼び出し得る起動ルーチンを含むことを
   特徴とするデジタル計算機システム。 １１、請求項８に記載のシステムにおいて、前記第１の
   モジュールが、前記ラン・ルーチンが呼び出されるよう
   に前記スケジュール・ルーチンによって呼び出され得る
   起動ルーチンを含むことを特徴とするデジタル計算機シ
   ステム。 １２、請求項１１に記載のシステムにおいて、各々前記
   通知ルーチンの１つを指示する引き数を取る前記サービ
   ス・ルーチンの少なくとも幾つかが、前記サービス・ル
   ーチンの完了時に前記キュー上にスケジュールされるべ
   き前記通知ルーチンの１つを選択するポインタを渡すた
   めに各ユーザ・ルーチンを可能化することを特徴とする
   デジタル計算機システム。 １３、請求項７に記載のシステムにおいて、前記スケジ
   ュール・ルーチンが、ユーザ・ルーチンから追加的に呼
   び出し可能であることを特徴とするデジタル計算機シス
   テム。 １４、請求項７に記載のシステムにおいて、複数の前記
   キューがあり、前記スケジュール・ルーチンが、通知ル
   ーチンを識別するキュー・ジョブ・データのどれが置か
   れるべきかを識別する引き数を取ることを特徴とするデ
   ジタル計算機システム。 １５、請求項１４に記載のシステムにおいて、前記キュ
   ーが異なる優先順位を持ち、前記ラン・ルーチンが、そ
   れらの優先順位に従って通知ルーチンをランさせること
   を特徴とするデジタル計算機システム。 １６、請求項１５に記載のシステムにおいて、前記ラン
   ・ルーチンが、前記スケジュール・ルーチンによって前
   記キュー上に置かれた順番で、該キュー内の通知ルーチ
   ンをランさせることを特徴とするデジタル計算機システ
   ム。 １７、請求項１４に記載のシステムにおいて、前記第３
   のモジュールが、キューをセットアップするための、か
   つセットアップされたキューに割り当てられるべき優先
   順位を引き数として取る、割り当てルーチンを含むこと
   を特徴とするデジタル計算機システム。 １８、請求項１７に記載のシステムにおいて、前記割り
   当てルーチンが、前記ラン・ルーチンが呼び出されるべ
   きことを表すために、前記スケジュール・ルーチンによ
   って呼び出され得るユーザ起動ルーチンを特定する引き
   数を付加的に取ることを特徴とするデジタル計算機シス
   テム。 １９、請求項１４に記載のシステムにおいて、前記スケ
   ジュール・ルーチンが、どのキューに通知ルーチンが置
   かれるべきかの前記表示と、前記キューに置かれるべき
   前記通知ルーチンへのポインタと、前記サービス・ルー
   チンに渡される複数の引き数とを、引き数として取るこ
   とを特徴とするデジタル計算機システム。 ２０、請求項７に記載のシステムにおいて、前記サービ
   ス・ルーチンが、各々のイベントに対応するイベント・
   サービス・ルーチンを含み、呼び出された前記イベント
   ・サービス・ルーチンの夫々は、前記対応するイベント
   が生じたときはいつでもジョブ・データを前記キュー上
   に置き、このジョブ・データは、生じたイベントを識別
   する通知ルーチンを識別することを特徴とするデジタル
   計算機システム。 ２１、請求項７に記載のシステムにおいて、前記サービ
   ス・ルーチンが、選択された時間間隔の経過に対応する
   少なくとも１つのタイマ・サービス・ルーチンを含み、
   該タイマ・サービス・ルーチンは、呼び出されたとき、
   前記時間間隔が経過したときはいつでもジョブ・データ
   を前記キュー上に置き、このジョブ・データは、経過し
   た時間間隔を識別する通知ルーチンを識別することを特
   徴とするデジタル計算機システム。 ２２、請求項１４に記載のシステムにおいて、前記キュ
   ーは、 （ａ）次と前のキューへのポインタと、 （ｂ）前記キューの優先順位レベルと、 （ｃ）前記キューに対する識別子と、 （ｄ）前記キュー上の最初と最後の通知ルーチンに対す
   る制御ブロックへのポインタとを含むデータ構造によっ
   て確立され、 各制御ブロックは、 （ｅ）次と前の制御ブロックへのポインタと、 （ｆ）前記サービス・ルーチンの完了時に呼び出される
   べき前記通知ルーチンへのポインタと、 （ｇ）前記通知ルーチンへ渡されるべき引き数とを含む
   データ構造を有することを特徴とするデジタル計算機シ
   ステム。 ２３、請求項１４に記載のシステムにおいて、前記キュ
   ーは、複数の異なるオウナーに割り当てられる組の中に
   あり、各オウナーは、その所有するキューに関する前記
   ラン・ルーチンを呼び出し得るのみであることを特徴と
   するデジタル計算機システム。 ２４、請求項２２に記載のシステムにおいて、前記キュ
   ーは、複数の異なるオウナーに割り当てられる組の中に
   あり、各オウナーは、その所有するキューに関する前記
   ラン・ルーチンを呼び出し得るのみであり、前記データ
   構造が更に各オウナーに１つづつの、 （ｈ）次と前のオウナー・アンカー構造へのポインタと
   、 （ｉ）前記オウナーに対するスタック・ベースへのポイ
   ンタと、 （ｊ）複数のステータス・ビットと、 （ｋ）少なくともそのオウナーによって所有された前記
   最初のキューに対する、識別子へのポインタとを含む、
   複数のアンカー構造を含むことを特徴とするデジタル計
   算機システム。 ２５、請求項２４に記載のシステムにおいて、前記ステ
   ータス・ビットが、少なくとも前記ラン・ルーチンが前
   記オウナーに対するジョブ・ルーチンをランさせている
   かどうかを表示するビットと、ジョブ・ルーチンが前記
   オウナーに対してキュー上にスケジュールされているこ
   とを表示するビットと、前記ラン・ルーチンがいつ起動
   ルーチンによって戻りを必要とされたかを表示する起動
   ビットとを含むことを特徴とするデジタル計算機システ
   ム。 ２６、少なくとも１つの転送するメッセージ及び受け取
   ったメッセージを処理するために動作可能な計算機手段
   を有する、ネットワーク通信システム用のゲートウエイ
   において、前記計算機手段は即座に戻る必要の無いサー
   ビス・ルーチンを含む複数のルーチンを実現し、前記計
   算機システムを操作する方法が、 （ａ）複数のルーチンを含む主処理タスクを実行し、 （ｂ）前記主処理タスクの呼び出しルーチンの実行中に
   少なくとも１つのサービス・ルーチンを呼び出し、 （ｃ）前記呼び出しルーチンを未処理にせずに前記主処
   理タスクにおける処理を更に継続し、 （ｄ）前記サービス・ルーチンを終わらせて通知ルーチ
   ンを識別するジョブ・データを記憶し、 （ｅ）実行されるべき記憶されたジョブ・データによっ
   て識別された通知ルーチンを生じるために、前記主タス
   ク内のラン・ルーチンを実行する、ステップからなる方
   法。 ２７、それぞれのアクセス装置に対して働く複数のゲー
   トウエイを含むネットワーク通信システムにおいて、前
   記ゲートウエイはメッセージ・ハンドリング・システム
   を介して相互に通信するように接続されており、 そのゲートウエイが働く前記アクセス装置に対するアク
   セスを提供するネットワーク・インターフェースと、 前記メッセージ・ハンドリング・システムとメッセージ
   をやり取りするメッセージ転送インターフェースと、 前記メッセージ転送インターフェースと前記ネットワー
   ク・インターフェース間での通信を提供し、少なくとも
   フォーマット変換をするために前記ゲートウエイを介し
   て処理データを渡す、ルーチンのライブラリを含むソウ
   トウエア・インターフェースとを含み、 前記ソウトウエア・インターフェース内の前記ルーチン
   が第１、第２及び第３のモジュール内のルーチンを含み
   、前記第１のモジュールはユーザ・ルーチンを含み、前
   記第２のモジュールはサービスを提供するサービス・ル
   ーチンを含み、前記第３のモジュールはインターフェー
   ス・ルーチンを含み、 前記ユーザ・ルーチンは、前記サービス・ルーチンから
   のサービスを要求するルーチンを含み、前記インターフ
   ェース・ルーチンは、ジョブ・データをジョブ・データ
   ・キューに置くために各サービス・ルーチンから呼び出
   し得るスケジュール・ルーチンと、前記キュー上のジョ
   ブ・データによって識別された通知ルーチンをランさせ
   るためにユーザ・ルーチンから呼び出し得るラン・ルー
   チンと、前記ルーチンの第１のモジュールに戻り結果を
   提供する前記サービス・ルーチンの少なくとも幾つかと
   を含み、 サービス・ルーチンの要求に続いて、サービス・ルーチ
   ンからの戻り結果を待つことなしに前記第１のモジュー
   ル内での処理を継続できることを特徴とするネットワー
   ク通信システム。 ２８、請求項２７に記載のシステムにおいて、前記ラン
   ・ルーチンが、前記キュー上にジョブ・データが無いと
   き前記ラン・ルーチンを未決にするかしないかを指示す
   るフラグと共に呼び出し得ることを特徴とするネットワ
   ーク通信システム。 ２９、請求項２８に記載のシステムにおいて、前記第３
   のモジュールが更に、前記ラン・ルーチンが未決にされ
   たとき、戻るべきことをそれに信号するようにユーザ・
   ルーチンによって呼び出し得る起動ルーチンを含むこと
   を特徴とするネットワーク通信システム。 ３０、請求項２７に記載のシステムにおいて、各々前記
   通知ルーチンの１つを指示する引き数を取る前記サービ
   ス・ルーチンの少なくとも幾つかが、前記サービス・ル
   ーチンの完了時に前記キュー上にスケジュールされるべ
   き前記通知ルーチンの１つを選択するポインタを渡すた
   めに各ユーザ・ルーチンを可能化することを特徴とする
   ネットワーク通信システム。 ３１、請求項２７に記載のシステムにおいて、複数の前
   記キューがあり、前記スケジュール・ルーチンが、通知
   ルーチンを識別するキュー・ジョブ・データのどれが置
   かれるべきかを識別する引き数を取ることを特徴とする
   ネットワーク通信システム。 ３２、請求項３１に記載のシステムにおいて、前記キュ
   ーが異なる優先順位を持ち、前記ラン・ルーチンが、そ
   れらの優先順位に従って通知ルーチンをランさせること
   を特徴とするネットワーク通信システム。 ３３、請求項３２に記載のシステムにおいて、前記ラン
   ・ルーチンが、前記スケジュール・ルーチンによって前
   記キュー上に置かれた順番で、該キュー内の通知ルーチ
   ンをランさせることを特徴とするネットワーク通信シス
   テム。 ３４、請求項３１に記載のシステムにおいて、前記スケ
   ジュール・ルーチンが、どのキューに通知ルーチンが置
   かれるべきかの前記表示と、前記キューに置かれるべき
   前記通知ルーチンへのポインタと、前記サービス・ルー
   チンに渡される複数の引き数とを、引き数として取るこ
   とを特徴とするネットワーク通信システム。 ３５、それぞれのアクセス装置に対して働く複数のゲー
   トウエイを含むネットワーク通信システムにおいて、前
   記ゲートウエイはメッセージ・ハンドリング・システム
   を介して相互に通信するように接続されており、 前記複数のゲートウエイの内の少なくとも１つが、 そのゲートウエイが働く前記アクセス装置に対するアク
   セスを提供するネットワーク・インターフェースと、 前記メッセージ・ハンドリング・システムとメッセージ
   をやり取りするメッセージ転送インターフェースと、 前記メッセージ転送インターフェースに適合するソフト
   ウエア・インターフェースと、 少なくとも１つの転送すべきメッセージと受け取ったメ
   ッセージを処理するためのルーチンを実行する計算機手
   段と、 前記メッセージ転送インターフェースと前記ソフトウエ
   ア・インターフェースの間の通信を提供する前記複数の
   ルーチンと、前記ゲートウエイに固有であって前記ネッ
   トワーク・インターフェースと前記ソフトウエア・イン
   ターフェースの間の通信を提供する前記複数のルーチン
   の内の特定のものとを記憶する手段とを含み、 前記特定のルーチンはネットワーク・インターフェース
   のフォーマット及びプロトコルと前記ソフトウエア・イ
   ンターフェースのフォーマット及びプロトコルの間の変
   換をし、前記メッセージ・ハンドリング・システム上の
   前記ゲートウエイ間の通信はエンベロープ部とメッセー
   ジ部とを含むプロトコル・データ単位で実行され、前記
   エンベロープ部はメッセージ発信者を識別するデータと
   メッセージ受信者を識別するゲートウエイを特定しない
   データとを含み、 前記ルーチンはメッセージ・ハンドリングの間に必要な
   サービスを実現するサービス・ルーチンを含み、 前記計算機手段は、複数の前記ルーチンを含む主処理タ
   スクを実行するように動作可能であり、前記サービス・
   ルーチンの少なくとも１つを呼び出すための前記主処理
   タスクの呼び出しルーチンの実行中に、前記呼び出しル
   ーチンを未処理にせずに前記主処理タスクの実行を更に
   継続し、前記サービス・ルーチンを終わらせて通知ルー
   チンを識別するジョブ・データを記憶し、記憶されたジ
   ョブ・データによって識別された通知ルーチンを実行す
   るように前記主処理タスク内のラン・ルーチンを実行す
   ることを特徴とするネットワーク通信システム。 ３６、メッセージ処理用であって複数のメッセージの処
   理を並列に実行可能な計算機手段を含み、各メッセージ
   の処理が少なくとも１つのサービス・ルーチンの呼び出
   しを含み、前記サービス・ルーチンが該サービス・ルー
   チンの実行完了後に続いて呼び出されるべき通知ルーチ
   ンを識別する引き数を伴って呼び出さ、前記サービス・
   ルーチンは該サービス・ルーチンの実行完了時にジョブ
   ・データをキュー上にスケジュールし、複数のメッセー
   ジに対する通知ルーチンに適するジョブ・データが前記
   キュー上に置かれ、前記計算機手段が、それらのジョブ
   ・データが前記キュー上に置かれた順番で前記通知ルー
   チンが実行されるようにラン・ルーチンを実行する手段
   を含むことを特徴とするデジタル通信システム。 ３７、請求項３６に記載のシステムにおいて、外部イベ
   ントが前記キュー上に置かれるべきデータに、生じたイ
   ベントを識別させ、前記ラン・ルーチンが更に前記キュ
   ー上に置かれた前記データに応答してイベント通知ルー
   チンを実行させることを特徴とするデジタル通信システ
   ム。 ３８、請求項３６に記載のシステムにおいて、前記イベ
   ントが、外部イベントとタイマ・イベントを含むことを
   特徴とするデジタル通信システム。 ３９、それぞれのアクセス装置に対して働く複数のゲー
   トウエイを含むネットワーク通信システムにおいて、前
   記ゲートウエイはメッセージ・ハンドリング・システム
   を介して相互に通信するように接続されており、 前記複数のゲートウエイのそれぞれが、 そのゲートウエイが働く前記アクセス装置に対するアク
   セスを提供するネットワーク・インターフェースと、 前記メッセージ・ハンドリング・システムとメッセージ
   をやり取りするメッセージ転送インターフェースと、 前記メッセージ転送インターフェースに適合するソフト
   ウエア・インターフェースと、 少なくとも１つの転送すべきメッセージと受け取ったメ
   ッセージを処理するためのルーチンを実行する計算機手
   段と、 前記メッセージ転送インターフェースと前記ソフトウエ
   ア・インターフェースの間の通信を提供する前記複数の
   ルーチンの汎用のものと、前記ゲートウエイに固有であ
   って前記ネットワーク・インターフェースと前記ソフト
   ウエア・インターフェースの間の通信を提供する前記複
   数のルーチンの内の特定のものとを記憶する手段とを含
   み、前記特定のルーチンはネットワーク・インターフェ
   ースのフォーマット及びプロトコルと前記ソフトウエア
   ・インターフェースのフォーマット及びプロトコルの間
   の変換をし、前記メッセージ・ハンドリング・システム
   上の前記ゲートウエイ間の通信はエンベロープ部とメッ
   セージ部とを含むプロトコル・データ単位で実行され、
   前記エンベロープ部はメッセージ発信者を識別するデー
   タとメッセージ受信者を識別するゲートウエイを特定し
   ないデータとを含むことを特徴とするネットワーク通信
   システム。 ４０、請求項３９に記載のシステムにおいて、前記メッ
   セージ・ハンドリング・システムがＣＣＩＴＴ，Ｘ４０
   ０標準に従うことを特徴とするネットワーク通信システ
   ム。 ４１、請求項３９に記載のシステムにおいて、前記メッ
   セージ・ハンドリング・システムがＣＣＩＴＴ，Ｘ４０
   ０標準の１９８８年版に従うことを特徴とするネットワ
   ーク通信システム。 ４２、請求項４１に記載のシステムにおいて、前記ゲー
   トウェイの１つがＣＣＩＴＴ，Ｘ４００標準の１９８４
   年版ユーザ・エージェントに対するネットワーク・イン
   ターフェースを含むことを特徴とするネットワーク通信
   システム。 ４３、請求項３９に記載のシステムにおいて、前記各ゲ
   ートウエイによってアクセス可能な文書変換装置を含み
   、そのメッセージ部が少なくとも文書の部分からなる任
   意のプロトコル・データ単位の前記エンベロープ部が、
   文書フォーマットを識別する情報を含み、各ゲートウエ
   イの特定のルーチンの前記ライブラリが、受け取ったメ
   ッセージの前記文書フォーマットを識別する受け取った
   情報に応答して、前記文書フォーマットを識別する受け
   取った情報が、前記受け取ったゲートウエイによって提
   供される前記アクセス単位と非互換のフォーマットを識
   別するとき、前記メッセージ部分を自動的に前記文書変
   換装置に与えるルーチンを含み、それによってゲートウ
   エイが受信者が受け取り得る文書フォーマットについて
   考える事なく、任意の文書フォーマットを自由に転送す
   ることを特徴とするネットワーク通信システム。 ４４、請求項３９に記載のシステムにおいて、各ゲート
   ウエイによってアクセス可能な少なくとも１つのディレ
   クトリを含み、前記ライブラリ・ルーチンが、メッセー
   ジの発信者及び受信者を識別するデータを発信者ゲート
   ウエイにおいて前記少なくとも１つのディレクトリに与
   えて前記メッセージ・ハンドリング・システムに従う標
   準形式でそのようなデータの前記エンベロープ部に含ま
   れることを決定するルーチンと、受け取ったプロトコル
   ・データ単位の前記エンベロープ部内の前記メッセージ
   の発信者及び受信者を識別するデータを受信者ゲートウ
   エイにおいて前記少なくとも１つのディレクトリに与え
   て前記受信者ゲートウエイの前記ネットワーク・インタ
   ーフェースによって要求される形式で少なくとも前記メ
   ッセージ受信者を決定するルーチンとを含むことを特徴
   とするネットワーク通信システム。 ４５、請求項４４に記載のシステムにおいて、前記メッ
   セージ・ハンドリング・システム上の総ての前記ゲート
   ウエイによって直接アクセス可能なディレクトリを保持
   する主ディレクトリ装置を含むことを特徴とするネット
   ワーク通信システム。 ４６、請求項４５に記載のシステムにおいて、前記主デ
   ィレクトリ装置が、ＣＣＩＴＴ，Ｘ５００標準に従うデ
   ィレクトリであることを特徴とするネットワーク通信シ
   ステム。 ４７、請求項４４に記載のシステムにおいて、少なくと
   も１つのゲートウエイが、前記他のゲートウエイによっ
   て前記メッセージ・ハンドリング・システム及び前記１
   つのゲートウエイを介して間接的にアクセス可能なディ
   レクトリを保持するディレクトリ装置を含むことを特徴
   とするネットワーク通信システム。 ４８、それぞれのアクセス装置に対して働く複数のゲー
   トウエイを含み、前記ゲートウエイがメッセージ・ハン
   ドリング・システムを介して相互に通信するように接続
   されているネットワーク通信システムにおいて、メッセ
   ージを取り扱う方法が、 （ａ）各ゲートウエイが働く前記アクセス装置に対する
   アクセスを提供するネットワーク・インターフェースを
   そのゲートウエイに提供し、 （ｂ）前記標準メッセージ・ハンドリング・システムと
   メッセージをやり取りするためのメッセージ転送インタ
   ーフェースを各ゲートウエイに提供し、 （ｃ）前記アクセス装置に適合する特定のルーチンのラ
   イブラリによって、前記ネットワーク・インターフェー
   スに入力されたメッセージを処理して、システム標準フ
   ォーマットで中間メッセージを提供し、 （ｄ）エンベロープ部とメッセージ部とを含む少なくと
   も１つのプロトコル・データ単位に形成される、総ての
   ゲートウエイにおいて実質的に同一のコア・ルーチンの
   ライブラリによって前記中間メッセージを処理し、前記
   エンベロープ部はメッセージの発信者と受信者とを識別
   するデータを含むが前記メッセージ受信者のために働く
   前記ゲートウエイを特定するデータは含まず、前記特定
   のルーチンのライブラリは前記ネットワーク・インター
   フェースのフォーマット及びプロトコルと前記中間メッ
   セージのフォーマット及びプロトコルとの間で変換し、
   前記コア・ルーチンのライブラリは前記中間メッセージ
   のフォーマット及びプロトコルと前記メッセージ転送イ
   ンターフェースのフォーマット及びプロトコルとの間で
   変換し、 （ｅ）前記メッセージ・ハンドリング・システム上の前
   記少なくとも１つのプロトコル・データを前記メッセー
   ジ転送インターフェースを介して転送する、 ステップからなるメッセージを取り扱う方法。 ４９、請求項４８に記載の方法において、更に、 （ｆ）前記メッセージ転送インターフェースを入力する
   プロトコル・データ単位を、中間メッセージを形成する
   ために、前記コア・ルーチンのライブラリによって処理
   し、 （ｇ）前記中間メッセージを、局所メッセージを形成す
   るために、前記特定のルーチンのライブラリによって処
   理し、 （ｈ）前記局所メッセージを前記ネットワーク・インタ
   ーフェースを介してアクセス装置に転送する、 ステップを含むメッセージを取り扱う方法。 ５０、請求項４８に記載の方法において、前記メッセー
   ジ・ハンドリング・システムが、ＣＣＩＴＴ，Ｘ４００
   標準の１９８８年版に従うことを特徴とするメッセージ
   を取り扱う方法。