JPH0390953A - 手順呼出しシステム及び方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、一般にコンピュータ・システムに関し、より
詳しくは手順呼出しを作る技術に関する。

Ｂ、従来の技術及びその課題 プログラミング言語は、再利用できるコードが画定され
た位置に置かれ、必要な時に実行される、手順呼出しを
行なうための機能を提供する。パラメータは呼び出され
た手順にバスされ、結果が戻される。ここで使用される
ように、用語”手順（ｐｒｏｃｅｄｕｒｅ）”は、総称
的な意味で使い、特に手順、機能、及びサブルーチンと
呼ぶプログラム・セグメントを、ここではすべて手順と
呼ぶ。

手順呼出し規定の詳細は、プログラミング言語によって
異なる。いくつかのパラメータは９手順スタック上のレ
ジスタ内、またはレジスタ、またはスタックの位置に保
待されたポインタによって指定されたメモリ・ブロック
内に渡すことができる。手１頓呼出しを、異なる言語に
よって使用された異なる呼出し規定のために、同じ言語
、または同じ呼出し規定を用いた他の言語内に初めから
書き込まれた手順のために作らなければならない。

異なる言語に初めから書き込まれた手順に対する呼出し
を望み、元の言語と同一であることが分かる場合、特定
のステップがそのような手順で正確に機能するために１
時には呼出しを再構成するために取ることができる。こ
の再構成は、アセンブリ言語レベルでの呼出し修正を必
要とする。

事実上すべての大型、及び中型システムを含む多くのコ
ンピュータ・システムで、手順の共通ライブラリが、標
準的でよく使用されている機能のために保待される。シ
ステム・サービスと呼ばれることもあるこれらの手順は
、アプリケーション・プログラムから呼び出され、アプ
リケーション・プログラマを、共通の機能を実行するた
めにコードの書込みとデパックを行なうことから解放す
る。

ライブラリ機能を、リンク時にアプリケーション・プロ
グラムにリンクすることができるか、または、これが動
作システムによって支援される場合には、実行時間に動
的にリンクする。

上記の言語呼出し規定問題は、手順ライブラリの使用で
存在する。多重手順が同じライブラリ機能を実行するた
めに存在するように、−股肉には、ライブラリ手順はシ
ステムによって支援された各言語で書かれなければなら
ない。１つの代替方法は、特定の言語で書かれた１つま
たは限られた数の手順を有し、たとえどんなステップが
異なる言語で書かれた手順を呼び出すために必要であっ
ても、実行するためにアプリケーション・プログラマを
必要とすることである。

いくつかのコンピュータ・システムが構内ネットワーク
を介して共に接続されると、できる限り多くの資源を共
用することが望ましい。これは、従来の技術システムは
異なる機械に置かれた手順を透過的（トランスペアレン
ト）に呼び出す準備をしていないので、−股肉にライブ
ラリ手順にとって実現可能なことではない。これは、手
順呼出し規定が異なるシステム構成の間で異なる非同期
ネットワークに対しては、特に真実である。

ネットワークに取り付けた遠隔ノードに置かれたライブ
ラリ手順を呼び出すために、アプリケーション・プログ
ラムに対して能力を与えることは、システムにとって望
ましい。さらに、そのようなシステムにとって、アプリ
ケーション・プログラムが、それらが構内ネットワーク
・ノード、または、遠隔ノード上に置かれるのか否かを
知ることなく、ライブラリ手順を呼び出せることが望ま
しい。また、そのような呼出しが、アプリケージタン・
プログラムによって作られた言語特定翻訳の必要なしに
、異なる手順呼出し規定を用いた言語で書き込まれた手
順に対し行なわれるのが望ましい。

したがって本発明の１つの目的は、アプリケーション・
プログラムがネットワークによって構内機械に接続され
た遠隔機械上に置くことのできるライブラリ手順に対し
て、呼出しができるようにするシステム及び方法を提供
することである。

また、本発明の１つの目的は、アプリケーション・プロ
グラムが、そのような手順が構内機械、または遠隔機械
上に置かれているか否かを知ることなく、ライブラリ手
順に呼出しを行なうことができるようにするシステム、
及び方法を提供することである。

本発明のさらにもう１つの目的は、ライブラリ手順に対
する呼出しが、ライブラリ手順によって用いられた規定
とは異なる手順呼出し規定を用いたアプリケーション・
プログラムから作ることができるシステムを提供するこ
とである。

Ｃ０課題を解決するための手段 したがって、本発明によれば、ライブラリ手順に対して
呼出しをするためのシステムは、アプリケーション・プ
ログラムのために標準インタフェイスを提供する。ライ
ブラリ手順に対する要求は、所望の手順が、構内で、ま
たは遠隔機械で利用できるか否かを知るためにチエツク
される。構内で利用できる手順は構内で実行される。遠
隔機械で利用できる手順は、手順識別子、及び遠隔機械
に対する任意の必要なパラメータを通信することによっ
て呼び出される。結果は、アプリケーション・プログラ
ムによって使用するために、構内機械に戻される。

Ｄ、実施例 手順呼出しを行なうためのシステムが、コンピュータの
ネットワークと共に使用できる。構内（ｌｏｃａｌ）　
　ノードのアプリケーション呼出しは、所望のライブラ
リ手順を呼び出す。ライブラリ手順は、構内ノードまた
は遠隔ノードに利用でき、また位置はアプリケージタン
によって知られる必要はない。ライブラリ手順が遠隔ノ
ードに利用できる場合、遠隔ルータ手順は遠隔ノードに
対して手順識別子を通信する。手順が実行され、ど１ん
な結果も構内ノードに戻され、アプリケーション・プロ
グラムに戻される。

本明細書に説明するソフトウェア・システムは、はとん
どどの−膜内な目的のディジタル・コンピュータと共に
使用するのに適している。メインフレーム、ミニコンピ
ユータ、エンジニアリング・ワークスチーシロン、及び
多くのデスクトップ・パーソナル・コンピュータは、後
述のシステムを支援することができる。当業者の能力の
範囲内では、単に小修正だけが、後述のような様々な既
存の言語コンパイラに対して必要とされる。

項目ライブラリ手順、サービス、及びサービス手順は、
同じ意味に使用される。構内ノード、及び構内機械は、
アプリケーション・プログラムが実行しているコンピュ
ータを意味する。遠隔ノード、及び遠隔機械は、構内領
域ネットワークなどの通信リンクによって構内ノードに
接続されたコンピュータを意味する。

第１図で、構内ノードで利用できるライブラリ手順呼出
しを取り扱うためのシステム１０は、サービス・ディレ
クタ１２を含む。サービス・ディレクタ１２は、切取り
（ｓｔｕｂ）手順１４によって呼び出されるソフトウェ
ア手順である。切取り手順工４は、アプリケーション・
プログラム１６の一部分である。

サービス・ディレクタ１２は、内部サービス１８を定義
するいくつかの手順を含む。サービス・ディレクタ１２
は、また、サービス・テーブル２０を定義するデータ構
造にアクセスする。実行中に、サービス・ディレクタ１
２は、ライブラリ手順２２．２４．２６、及び２８に対
し手順呼出しをすることができる。

アプリケーション・プログラム１６は、任意のエンドユ
ース、すなわちシステム機能を実行することができ、−
膜内にはＣまたはＣ０ＢＯＬなどの高レベル言語で書か
れる。アプリケーション１６をアセンブリ言語で書くこ
とは次第に減っている。切取り手順１４は、リンク時に
アプリケーション１６にリンクされる小さな手順である
。

切取り手順１４は、アプリケ−シロン１６によって、任
意の他の手順によって呼び出される。切取り手順１４に
渡されるパラメータは、実行が望まれるシステム・ライ
ブラリ手順、あるいはサービスを定める。切取り手順１
４は、これらのパラメータを使用して、サービス・ディ
レクタ１２に対シて手順呼出しを行なう。

いろいろなプログラミング言語は、いろいろな手順呼出
し規定を使用するので、異なる切取り手順１４は、支援
された各プログラミング言語のためのシステムによって
準備されなければならない。

しかし、単一の切取りプログラム１４が、すべての所望
ライブラリ・サービスのためのサービス・ディレクタｔ
２に対して、すべての呼出しを行なう。

サービス・ディレクタ１２は、ライブラリ手順が呼び出
された時、アプリケーション・プログラム１６により使
用されるインタフェイスである。

サービス・ディレクタ１２は、呼び出された時、それに
渡されたパラメータを調べ、どの手順が呼び込まれるべ
きかを判定する。ある手順は、サービス・ディレクタ１
２のコードに直接食まれるのが好ましい。これらの手順
は、内部サービス１８または環境サービスと呼ぶことが
できる。これらの手順１８は、−膜内にはしばしば実行
されるもので、あまり複雑なものではない。これらの手
順１８に対する効果的な呼出しは、システムの性能低下
を防ぐために好ましい。サービス・ディレクタ１２に対
する内部サービス１８として含まれる一般的なシステム
・サービスは、プログラム、及び記憶マネージメント、
時刻及び同様のシステム・サービス、及び、初期設定及
びサービス・ディレクタ１２自体の動作に向けられた制
御ルーチンを含む。

切取部分１４を介して、アプリケーション１６がサービ
ス・ディレクタ１２を呼び出す時、実行される手順は、
そこに渡されるパラメータによって識別される。いった
ん所望の手順が識別されると、サービス・ディレクタは
、その手順がシステム内のどこに記憶され、それがどの
パラメータを必要としているのか、さらに手順がはじめ
に書かれた言語は何かを判定しなければならない。この
最後の項目は、所望のライブラリ手順が呼び込まれた時
に使用しなければならない手順呼出し規定を示す。サー
ビス・ディレクタ１２は、この情報をサービス・テーブ
ル２０から見つける。サービス・テーブル２０は、シス
テム・ライブラリ手順の名前から、今述べた情報に対す
るマツピングを準備し、いくつかの周知のデータ構造の
どれで゛も実行できるデータ構造である。

いったんサービス・ディレクタ１２が呼び込まれようと
するライブラリ手順を識別すると、それは、手順によっ
て期待される呼出し規定に対し適切にそこにパスされる
任意のパラメータも配置し、その後それを呼び出す。手
順によって戻されたいかなる結果も、サービス・ディレ
クタ１２にパスされる。必要ならば、サービス・ディレ
クタ１２は、その結果を再びフォーマットし、それらを
切取り手順１４に戻す。

多くの場合、アプリケーション・プログラム１６及び呼
び出されたライブラリ手順は、同じ言語で書き込まれ、
その結果、必要な手順呼出しをする際には、はとんど困
難性はない。また他の場合、ある１つの言語の実施態様
は、パラメータをパスし、レジスタ内の結果を戻すこと
ができ、一方で、他の言語のインプリメンテーシコンは
、スタックを使用することができる。サービス・ディレ
クタ１２は、１つの呼出し規定、及び他の呼出し規定の
間で翻訳ないしは変換する必要のあるものを「知り」、
かなり直接的方法でこれらを変える。

たとえば、データ及びポインタは、レジスタからスタッ
クへ移動することができ、逆もまた可能である。

好ましい実施例において、アプリケーションは、任なの
システム・ライブラリ手順を呼び出す前に、サービス・
ディレクタ１２に初期設定呼出しをしなければならない
。この呼出しはアプリケーションを識別し、さらにサー
ビス・ディレクタ１２が適切なサービス・テーブル２０
をみつけるようにすることができるパラメータを渡す。

いろいろなアプリケージ３ンが、いろいろなサービス・
テーブルの組を使用することができる。この呼出しはま
た、第２図で説明される機能をもつ共通の制御ブロック
に対してポインタを準備することができる。

ライブラリ手順に対するすべての呼出しが完了した後で
、サービス・ディレクタ１２に対して終了呼出しをする
ことも、アプリケ−シコン１６にはまた好ましい。これ
によって、サービス・ディレクタｔ２はメモリの割り当
てられた領域を自由にさせ、一般に、アプリケーション
１６の後に、終結処置させる。

第２図は、ライブラリ手順を呼び出すために、アプリケ
ーション１６内で使用するための一般的な命令を示す。

命令前４０は、切取り手順塩″ＦＸＸＺ　　”４２を有
する切取り手順１４に対する呼出し”　ＣＡＬＬ″であ
る。ＦＯＲＴＲＡＮなどのいくつかの言語では、ワード
ＣＡＬＬは、実際には、切取り手順１４を呼び出すステ
ートメントの一部分として現われる。また別の多くの言
語では、ワードＣＡＬＬは使用されず、切取り手順１４
は、単にその名前４２を使用することにより呼び出され
る。

切取り手順塩４２は、記述的な手順塩の使用と矛盾しな
い傾向を有するように、比較的任意であることが好まし
い。システム・リンカは、アプリケーション・プログラ
ム１６の言語に適切な切取部分１４内に連結することが
できるように、切取り手順塩４２はどの言語が使われて
いるのかを表使用される言語を表す１つまたは複数の文
字によって置き換えられるのが好ましい。たとえば、こ
れらの文字は、”Ｃ’　　（ＣＯＢＯＬに対して）“Ｃ
ＢＬ″　または（アセンブリ言語に対して）“ＡＳＭ”
が可能である。代わりに、同じ切取り名がすべての言語
に対して使用され、各コンパイラは、それがアプリケー
ション・プログラム１６をコンパイルする時、それが作
成するオブジェクト・ファイル内に必要な外部連係情報
を置くことにより、適切な切取り手順１４を識別する。

切取り手順１４に渡される第１のパラメータは、サービ
ス・パラメータ″５ＥＲＶＩＣＥ″４４であり、サービ
ス・パラメータ４４は、サービス名ブロック４６と呼ば
れるデータ構造に対するポインタである。渡そうとする
第２のパラメータは共通ブロック識別子”Ｃ０ＭＭ０Ｎ
″４８であり、共通ブロック識別子４８は共通ブロック
５０に対するポインタを含む。第３のパラメータ″ＰＲ
ＯＣＥＤＵＲＥ”５２は、手順ブロック５４に対するポ
インタを含み、さらに、追加パラメータ″ＰＡＲＡＭ１
″５６は、パラメータ・ブロック５８を分離するための
各ポインタである。

かぎかっこで示したパラメータ５２．５６は、いくつか
の場合には自由選択である。すなわち、時刻のようない
くつかの内部サービス呼出しが、インプリメンテーショ
ンに応じてパラメータ４４及び４８だけで足りる場合も
ある。

サービス・パラメータ４４は、サービス名ブロック４６
を指摘し、サービス名ブロック４６は、情報のいくつか
の異なる項目を含むメモリの割り振られたブロックであ
る。ブロック４６に示された数は、そのフィールドが占
める多くのバイトを表す。好ましい実施例では、サービ
ス名ブロック４６内の第１のフィールドは、長さ”ＬＥ
ＮＧＴＨ’フィールドであり、ＬＥＮＧＴＨフィールド
は、サービス名ブロック４６内のバイトのすべての数を
表す。次のフィールドは名前″ＮＡＭＥ″フィールドで
あり、ＮＡＭＥフィールドはサービスの名前である。パ
ラメータカウント”ＰＡＲＭ”フィールドは呼び出され
たサービスに渡そうとするパラメータの数を表す。この
カウントは、手順パラメータ５２がパスされているか否
か、さらに、どれだけのパラメータ項目５６がバスされ
ているかを判定するために使用される。

フラグ′ｖＦＬＡＧＳ”フィールドは、切取り手順１４
からサービス・ディレクタ１２に、情報を渡すために使
用される。−股肉に渡される情報の１型式は、呼出し言
語の識別子である。異なる言語に対するすべての切取り
手順１４は、同じエントリ・ポイントで、サービス・デ
ィレクタ１２を呼び出し、サービス名ブロック内のＦ　
ＬＡＧ　Ｓフィールドは、どの呼出し規定が使用されて
いるかを、サービス・ディレクタ１２に示す。

指標”ＩＮＤＥＸ’フィールドは、特定のサービスにつ
いての情報の位置をより速く識別するために使用される
。サービスが呼び出された初回は、サービス・ディレク
タ１２は、ＮＡＭＥフィールドをテーブル２０内で有効
な様々な名前と突き合わせるために、サービス・テーブ
ル２０を介して探索しなければならない。いったんこの
突合わせが行なわれると、サービス・ディレクタ１２は
、テーブル２０内のそのエントリに対する識別子をＩＮ
ＤＥＸフィールド内に置く。識別子は、たとえば、その
エントリに対するアドレス、または、インデックスをテ
ーブルの中に置くことができる。

このサービスの様々な機能が後で呼び出される時はいつ
でも、この識別子が使用されて、サービス・テーブル２
０内の適切なエントリに直接アクセスする。

共通ブロック５０はサービス・ディレクタ１２によって
使用され、状況及び他の情報をアプリケーション・プロ
グラム１６に戻す。長さ“’ＬＥＮＧＴＨ”フィールド
は、共通ブロック５０のサイズを表す。リターン・コー
ド”ＲＥＴＵＲＮ　　Ｃ０ＤＥ″フイールドが使用され
て、状況コードをアプリケーション・プログラム１６に
戻す。好ましい実施例の規定によって、戻りコードのた
めの正の値は、単に、呼び出されたライブラリ手順によ
って生成された任意の戻りコードを通過する。また規定
によって、戻りコードのための負の値はサービス・ディ
レクタ１２によって使用され、責任領域内の障害を示す
。そのような障害には、たとえば、所望のライブラリ手
順をみつける能力がない、ということも含まれる。拡張
コード″ＥＸＴＥＮＤＥＤ　　Ｃ０ＤＥ″フイールドは
、エラー・コードを戻すための追加能力を準備する。

追加要素″ＡＤＤＩＴＩＯＮＡＬ　　ＥＬＥＭＥＮＴＳ
″フィールドは、任意選択であり、データまたはデータ
・バックのためのポインタを、アプリケーション・プロ
グラム１６に転送するために使用してもよい。

長さＬＥＮＧＴＨ”フィールドの他に、手順ブロック５
４は機能コード″ＦＵＮＣＴＩＯＮＣＯＤＥ″フィール
ドを含む。このフィールドは、どのサービスの機能が望
まれるかを示す数である。

好ましい実施例では、関連した機能は共にグループ化さ
れ、このグループ化をサービスと呼ぶことにする。これ
らの手段の１つにアクセスするために、全体としてサー
ビスに適用される名前が必要であり、それはサービス名
ブロック４６内にあり、さらにサービスの範囲内の手順
が必要とされる指示は、手順ブロック５４内にある。た
とえば、マトリックス操作を実行するためのルーチンの
ｌグループは、行列式の計算、マ）　ＩＪフックス作、
反転、または他のマトリックス操作が必要とされるか否
かを指示する手順ブロックで、単一のサービスにより識
別することができる。

各パラメータ・ブロック５８は、１つのパラメータを要
求されたライブラリ手順に伝送するために使われる。パ
ラメータ・ブロック５８内のサービス・データ″５ＥＲ
ＶＩＣＥ　　ＤＡＴＡ″フィールドは、データを直接合
むことができるか、またはデータに対するポインタを含
む。各パラメータ・ブロック５８内に含まれたデータ・
タイプは、各個別のライブラリ手順が何を期待するかに
依存し、その特定ライブラリ手順のための文書資料に指
定されることになる。

第３図は、アプリケーション・プログラム１６によって
、構内ノードで利用できるライブラリ手順の呼出し中に
発生するステップを示す。第３図のフローチャートは、
サービス・ディレクタ１２に対し行なわれる必要のある
任意の初期化呼出しがすでに行なわれている、と仮定す
る。第３図は、ライブラリ手順に対する単一呼出し中に
発生する事象の順序のみを示す。

まず、アプリケーション・プログラム１６は切取り手順
を呼び出し、パラメータをそれに渡す（７０）。第２図
に関して述べられたようなこれらのパラメータは、少な
くともサービス、及び、共通ブロックを識別することが
好ましく、さらに必要ならば手順識別子及びパラメータ
を任意選択的に識別する。次に切取り手順は呼出し言語
フラグをセットする（７２）。このフラグは、サービス
・ディレクタ１２に対し、アプリケーション・プログラ
ム１６のプログラミング言語を表示し、それによって、
どの呼出し規定がアプリケーション１６及び切取り手順
１４により使用されるかをｔ旨示する。

それから、切取り手順はサービス・ディレクタを呼出し
く７４）、サービス・ディレクタは、要求が内部サービ
スに対するものであるか否かを決定する（７６）。要求
された手順がサービス・ディレクタに対し内部的でない
場合は、サービス・ディレクタ１２は、所望の手順をサ
ービス・テーブルから探す（７８）。上記のように、サ
ービス・テーブル・エントリは、要求されたライブラリ
手順を適切に呼び出すために、サービス・ディレクタ１
２に必要なその情報を示す。第３図の方法では、サービ
ス・テーブル・エントリは、所望の手順が横内ノードで
使用可能であることを示す。

次に、サービス・ディレクタ１２は、ライブラリ手順を
呼び出すためにパラメータをセットしく８０）、それを
呼び出す（８２）。サービス手順は、通常の方式で実行
しく８４）、どんな生成された結果をもサービス・ディ
レクタに戻す（８６）。

サービス・ディレクタ１２は、ステップ７２内のフラグ
・セットにより示されるアプリケーション・プログラム
１６の呼出し規定を突き合わせるために、その戻りパラ
メータをセットする（８８）。次にその結果は切取り手
順に戻され（９０）、切取り手順はそれらをアプリケー
ション・プログラムへ戻す（９２）。

ステップ７６で、サービス・ディレクタ１２が、内部サ
ービスが要求されていることを検出した場合、それは、
そのような内部手順を実行しく９４）、それからステッ
プへ行＜　（９０）。サービス・ディレクタ１２は、ス
テップ７２内の呼出し言語フラグ・セットのために、ア
プリケーション・プログラム１６によって使われたパラ
メータ受渡しメカニズムを理解し、必要とされるいかな
る翻訳も直接取り扱うことができる。

第４図は、ネットワークの１つのノード上で実行中のア
プリケージタンが、ネットワークの他のノード」二のサ
ービス手順を呼び出すことができる、システムの１実施
例のブロック図である。第４図に示すシステムは、いく
つかの異なる遠隔モードでの動作のために使用すること
ができ、いくつかの異なる遠隔モードは、第５図〜第８
図のフローチャート内に個別に述べる。理解しやすくす
るために、好ましい実施例は同じ技術を用いているが、
第１図で述べた詳細のすべてを第４図内に含めてはいな
い。

第４図では、アプリケージタン・プログラム１００は、
手順呼出し１０４を介してサービス・ディレクタ１０２
を呼び出す。サービス・ディレクタ１０２は、手順ディ
レクタ１０８で遠隔経路指定サービス１０６を呼び出す
。遠隔経路指定サービス１０６は、ネットワークを通し
て構内ノードに接続された遠隔ノードと遠隔通信を始め
るライブラリ手順である。

遠隔経路指定プログラムｌＯ６は、データと結果をネッ
トワークを通して転送のために、ネットワーク・インタ
フェイス１１０と通信する。ネットワーク・インタフェ
イス１１０は、ネットワーク内の２つのノードに接続す
るのに必要なすべてのハードウェア及びソフトウェア・
インタフェイス、及び接続を示す。ネットワーク構造は
互いに非常に異なっており、ネットワーク連係の詳細は
本発明の一部分を形成するものではない、したがって、
ネットワーク・インタフェイス１１０の詳細は省略する
。また遠隔経路指定サービス１０８は、データ・マツパ
１１２と通信し、データ・マツパ１１２は、ネットワー
クを通して転送されるメツセージのフォーマット化を制
御する。遠隔経路指定応答手順１１４は、選択された状
況でネットワーク・インタフェイス１１０と通信する。

これらの状況では、応答手順１１４は遠隔ノードからネ
ットワークを通して戻される結果を受信し、アプリケー
ション１００による後の検索のために、それらを待ち行
列１１６の中に置く。応答手順１１４は、戻された結果
のフォーマットを解釈し、さらに、アプリケーション１
００によって期待された形にそれらをリフオーマットす
るために、データ・マツパ１１２と通信する。

遠隔ノードで、遠隔経路指定アプリケーション１１８は
、ネットワーク・インタフェイス１１０からデータを受
は取る。このデータは、遠隔ノードにおいて呼び出そう
とするサービス手順を説明する。遠隔経路指定アプリケ
ーション手順１１８は、通信の流れから必要な情報を抽
出するために、遠隔ノードでデータ・マツパ１２０と通
信し、手順呼出し１２４でサービス・ディレクタ１２２
を呼び出す。遠隔ノードにおいて、遠隔経路指定アプリ
ケーション手順１１８は、アプリケーション・プログラ
ムとしてサービス・ディレクタ１２２を呼び出し、第１
図で説明したサービス手順を呼び出すために、サービス
・ディレクタ１２２を要求する。サービス・ディレクタ
１２２は、必要などの呼出し規定翻訳をも行ない、要求
されるサービス手順１２４を呼び出す。

要求された手順１２４が終わると、何かあれば、結果を
サービス・ディレクタ１２２に戻し、サービス・ディレ
クタはその結果を手順戻し１２８によってアプリケ−シ
ロン手順１１８に戻す。アプリケーション手順１１８は
データ・マツパ１２０と通信し、ネットワークを通して
通信するために結果をフォーマットし、それらをネット
ワーク・インタフェイス１１０を通って元のノードに戻
す。

使用されている呼出し方法に応じて、アプリケーシａン
手順１１８によって戻された結果は、待ち行列１１６内
に置くために、応答手順１１４に戻すことができる。後
者の場合、サービス手順１゜６は、手順１３０で結果を
サービス・ディレクタに戻し、次に、その結果をアプリ
ケーション１゜Ｏに戻すために手順復帰１３２を使用す
る。

第４図に関して説明されたシステムは、構内ノード及び
遠隔ノードの様々な遠隔経路指定手順の間の通信を行な
うために、いくつかの異なる技術を使用することができ
る。遠隔サービス１２６は、「同期」技術で呼び出すこ
とができ、呼出しアプリケーションは、結果が処理する
前に戻されるまで、待つことを意味する。遠隔サービス
はまた、「非同期」方式で呼び出すこともでき、これは
、アプリケーションがさらに処理を実行し続け、方では
遠隔ノードがサービス手順を呼び出すことを意味し、ま
た遠隔サービスは、結果が応答手順１１４によって待ち
行列に置かれた後で、待ち行列１１６から結果を取り出
す。

遠隔呼出しされるか、または、単一の接続がいくつかの
異なる遠隔呼出しをするために開始できる時間毎に、ア
プリケ−シロン手順１１０に新しいネットワーク接続を
開始させることも可能である。各遠隔呼出し用の新しい
接続を作ることは、一般に、接続をセットするためによ
り多くの諸経費を必要とするが、遊休時間部分であるネ
ットワーク上の専用通信リンクを有することは避けられ
る。

いくつかの遠隔手順呼出し用の単一通信リンクを開設す
る技術は、５ＴＡＲＴ／５ＴＯＰによる遠隔要求と呼ぶ
ことができる。

上記のように、アプリケーション１００は、サービス・
ディレクタ１０２を初期化しなければならない。サービ
ス・テーブル（第４図に別々に図示せず）は、遠隔ノー
ド上で呼び出されたものを含むアプリケ−シリン１００
によって呼び出されることのできるすべてのサービス手
順の位置を識別する。遠隔サービスについては、遠隔ノ
ード及びそれに対するどの通信リンクも、遠隔サービス
１２６を呼び出すために、遠隔サービス・ディレクタ１
２２に必要な情報も、識別されなければならない。遠隔
ノードと通信するために使われる通信プロトコル、並び
に遠隔手順にパスされるパラメータは、データ・マツパ
１１２に記憶され、これによって、遠隔ノードと通信す
るためにいかにデータをフォーマットし抽出するかを知
ることにある。

遠隔データ・マツパ１２０は、遠隔経路指定アプリケー
ション手順１１８が他のノードからサービス手順１２６
にアクセスできるように、初期化される。

第５図は、５ＴＡＲＴ／５ＴＯＰなしの同期遠隔要求を
示す。第５図では、アプリケ−シロン手順１００は、構
内サービス・ディレクタを呼び出しく１５０）、第２図
で説明したように、そこにパラメータを渡す。サービス
・ディレクタ１０２はそのサービス・テーブルを探し、
要求されたサービスのためにエントリを置く。遠隔サー
ビスとして定義されるサービスのために、この事実はサ
ービス・テーブル内で識別される（１５２）。それから
、サービス・ディレクタ１０２は遠隔経路指定サービス
を呼び出す（１５４）。

上記のように、データ・マツパ・ルーチン１１２は、遠
隔サービスが定義された時間に、サービス・テーブル内
の各遠隔サービスに関連していた。

データ・マツパ１１２は、ネットワークによって使用さ
れたプロトコルに専用の通信ブロックを作成することに
よって、ネットワークを通して送信するために、サービ
ス識別子及びパラメータを準備する（１５６）。遠隔ノ
ードにおいて実際に使用されるその情報のみが転送され
るので、サービス名ブロック４６及び共通ブロック５ｏ
内のいくつかのエントリを転送する必要はない。データ
・マツパ１１２はまた、どの遠隔データ・マツパ１２０
が転送されたパラメータを正確に抽出するために使用さ
れるべきかを識別する。

遠隔経路指定アプリケーション手順に対して、ネットワ
ーク通信リンクを開設するための接続が行なわれる（１
５８）。呼び出そうとするサービス手順、及びすべての
必要なパラメータを含むデータは、ネットワークを通し
て送られ（１６０）、遠隔経路指定アプリケーン８フ手
順により受信される（１６２）。これは同期呼出しであ
るため、構内ノードでの遠隔経路指定サービス１０６は
、それが回答を受信するまで待つ（１６４）。

遠隔ノードでは、遠隔経路指定アプリケーションは、デ
ータを抽出するデータ・マツパ１２０と通信する（１６
６）。サービス呼出し識別子及びデータ・マツパ１２０
により抽出されたパラメータを用いて、遠隔経路指定ア
プリケーション１１８は、他の任意のアプリケーション
を呼び出すように、サービス・ディレクタ１２２を呼び
出す（１６８）。サービス・ディレクタ１２２は適切な
サービス手順を呼び出しく１７０）、適切なサービス手
順は通常の方式で実行される（１７２）。

完了時、選択されたサービス手順１２６は、その結果を
サービス・ディレクタに戻しく１７４）、サービス・デ
ィレクタ１７４は、その結果を遠隔経路指定アプリケー
ションに戻す（１７８）。

それから、データ・マツパ１２０はネットワークを通し
て通信するために結果を準備しく１７８）、遠隔経路指
定アプリケージジン１１８はその結果を遠隔経路指定サ
ービスに戻す（１８０）。

いったん遠隔経路指定サービス１０ｆ３が結果を受信す
ると（１８２）、遠隔経路指定アプリケ−シロン１１８
は、終了する（１８４）。データ・マツパ１１２は、そ
の結果を、サービス・ディレクタ１０２によって理解さ
れたフォーマットの中に抽出しく１８６）、それらをサ
ービス・ディレクタに戻す（１８８）。それからサービ
ス・ディレクタ１０２は、これらの結果をアプリケージ
ジンに戻しく１９０）、アプリケーションは処理を続け
る。

第６図（第６Ａ図及び第６Ｂ図）に、５ＴＡＲＴ／５Ｔ
ＯＰなしで非同期遠隔要求を行なうための好ましい方法
を示す。アプリケージジン・プログラムはサービス・デ
ィレクタを呼び出しく２００）、サービス・ディレクタ
は、サービス・テーブル内の遠隔サービスとして要求さ
れたサービス手順を識別する（２０２）。それから、サ
ービス・ディレクタは遠隔経路指定サービスを呼び出し
く２０４）、遠隔経路指定サービスは、送信に対するサ
ービス手順識別子及びパラメータを準備するために、デ
ータ・マツパと通信する（２０６）。

次に通信リンクを設定するために、遠隔ノードに対して
接続開始され（２０８）、それから遠隔サービス手順及
びそのパラメータを説明するデータは遠隔ノードに送ら
れる（２１０）。遠隔ノードでの遠隔経路指定アプリケ
−シロンがデータを受信すると（２１２）　、構内遠隔
経路指定サービスはサービス・ディレクタに戻る手順を
実行しく２１４）、サービス・ディレクタは呼出しアプ
リケーションへの復帰を実行する（２１６）。それから
、アプリケ−シランは処理を続け（２１８）　、後で待
ち行列１１６の戻された結果をチエツクすることができ
る。

遠隔経路指定アプリケ−シロン１１８がサービス手順及
びパラメータ・データを受信すると（２１２）、構内ノ
ードでデータ・マツパ１１２によって識別された遠隔デ
ータ・マツパは、手順識別子及びパラメータを抽出する
（２２０）。次に、他のアプリケーン３ン・プログラム
として作用する遠隔経路指定アプリケーションは、サー
ビス・ディレクタを呼び出しく２２２）、サービス・デ
ィレクタは適切なサービス手順を呼び出す（２２４）。

サービス手順が実行され（２２６）、さらにどんな結果
もサービス・ディレクタに戻される（２２８）。サービ
ス・ディレクタは、その結果を遠隔経路指定アプリケー
ションに戻しく２３０）、遠隔経路指定アプリケージジ
ンは、マツパとの通信によってネットワークを通して送
信するために、結果をフォーマットする（２３２）。

これは非同期要求であったため、結果は、サービス手順
の実行を初めに要求した構内ノードでは、遠隔経路指定
サービス１０６に戻されない。その代わり、データが遠
隔ノードに送られるとぐステップ２１０）、）ランザク
ジョンは、非同期として識別され、結果が戻されなけれ
ばならない遠隔経路指定応答手順１１４が識別される。

したがって、遠隔経路指定アプリケーション１１８は、
識別された遠隔経路指定応答手順２３４への接続を開始
する。−度接続が設定されると、その結果は応答手順２
３Ｇに送られる。いったん応答手順１１４がその結果を
受信すると（２３８）、遠隔経路指定アプリケージ３ン
１１８は終了する（２４０）。それから、構内ノードに
おけるデータ・マツパはその結果を抽出しく２４２）、
それから、応答手順はそれらを待ち行列に置く、（２４
４）。いくらか時間が経ってから、アプリケーション・
プログラムは待ち行列から結果を検索しく２４６）、処
理を続ける。アプリケージ縫ン・プログラム１００が待
ち行列の検索を試みる時（２４６）　、その結果が待ち
行列１１６にまだ置かれていない場合、アプリケージタ
ン・プログラムは、結果が有効になるまで待つか、ある
いはさらに処理を続けて、後で再試行することができる
。

上記のように、５ＴＡＲＴ／５ＴＯＰ）ランザクシロン
を使用して、構内ノード及び遠隔ノードの間に通信リン
クを設定するために必要な諸経費を最小にすることがで
きる。第５図と第６図に関して述べた方法では、遠隔サ
ービス手順１２６が呼び出される度に、新しいネットワ
ーク通信リンクを設定しなければならない。アプリケー
ジタン・プログラム１００が、１つまたは関連したサー
ビス手順１２６の多重連続呼出しがなされることを知っ
た場合、ノードの間の１つの通信リンクを設定し、さら
に、いくつかのトランザクションのためにそのリンクを
利用することは、より有効である。

第７図と第８図は、一連の５ＴＡＲＴ／５ＴＯＰトラン
ザクシｄンを開始し、終了するための好ましい方法を示
す。アプリケージタン・プログラム１００は、一連の５
ＴＡＲＴ／５ＴＯＰトランザクシヨンを開始し、上記の
方法と非常に似た方法で、トランザクションを実行し、
最後にそのシリーズを終了する。

本明細書で述べるシステムは、アプリケーション・プロ
グラム１００に対して透明であるため、特定の要求され
たサービス手順が構内で実行されたのか、または遠隔ノ
ードで実行されたのかが分からないことが多い。したが
って、アプリケージタン・プログラム１００は、あたか
もそれらが遠隔サービス手順であるように、一連のトラ
ンザクションを開始、終了することができる。サービス
・テーブルを探すことによって、サービス・ディレクタ
が、要求されたサービスが実際に構内で利用可能である
と判定する場合、一連のトランザクションのための開始
命令及び終了命令は単に無視される。

したがって、アプリケーション・プログラム１００は、
すべての例で、一連の関連した要求を単に開始、終了し
、特定の要求が構内かまたは遠隔かということは、反対
の影響を持たない。実際、特定の要求は、ある時には、
構内で利用可能であり、別の時には、遠隔で利用可能で
あり、アプリケージタン・プログラムに対しては何の違
いも現われない。非同期要求が行なわれる場合、サービ
ス・ディレクタは、アプリケージタン・プログラム１０
０の代わりに、待ち行列１１６に直接結果を単に戻すこ
とができる。

第７図に、一連の関連したトランザクションを開始する
ための好ましい方法を示す。アプリケーション・プログ
ラム１００はサービス・ディレクタ１０２を呼び出して
５ＴＡＲＴ／５ＴＯＰシリーズが開始されることを要求
する（２８０）。このシリーズの間に呼び出されるサー
ビス手順１２６は、この時識別される。サービス・ディ
レクタ１０２は、要求されたサービス手順を遠隔サービ
スとして識別しく２６２）、さらに、手順呼び出しで遠
隔経路指定サービス１０６を呼び出す（２６４）。上記
のように、要求されたサービス手順が構内ノードで利用
可能な場合、第７図のステップの残りは単に無視される
。

遠隔経路指定サービス１０６は、遠隔経路指定アプリケ
ーション手順への接続を開始する（２６６）。それから
、遠隔経路指定アプリケーション手順１１８はデータを
受信するために待ち（２６８）、また、構内ノードの遠
隔経路指定サービス１０６はサービス・ディレクタに戻
る（２７０）。

次に、サービス・ディレクタ１０２はアプリケージタン
・プログラムに戻り（２７２）、プロセスは完了する。

この時、通信リンクはネソトヮークを通して設定され、
そして、遠隔ノードに要求を送るために再設定される必
要はない。

第８図では、５ＴＡＲＴ／５ＴＯＰシリーズが完了する
と、アプリケーション・プログラム１００は、サービス
・ディレクタ１０２を呼び出して、通信リンクを終了す
る（２８０）。サービス・ディレクタ１０２は、サービ
ス手順を遠隔サービスとして識別しく２８２）、遠隔経
路指定サービスを呼び出す（２８４）。５ＴＡＲＴ／５
ＴＯＰリンクを開始する場合のように、識別されたサー
ビス手順が構内で利用可能である場合、リンクを終了す
る命令は単に無視される。

それから、遠隔経路指定サービスエ０６は、５ＴＡＲＴ
／５ＴＯＰリンクが終了しつつあることを、遠隔経路指
定アプリケーシ一ン１１８に報知し、そして遠隔ノード
へのネットワーク接続を終了する（２８６）。次いで、
遠隔経路指定サービス１０８はサービス・ディレクタに
戻り（２８８）、サービス・ディレクタはアプリケーシ
ョンに戻る（２９０）。

５ＴＡＲＴ／５ＴＯＰシリーズが要求された後、遠隔サ
ービス手順１０６を呼び出すために使われた方法は、５
ＴＡＲＴ／５ＴＯＰなしで使われた方法と事実上同一で
ある。接続を開始したり終了したりする代わりに、利用
可能な接続を使用する。

、同期要求について、第５図に示すステップは、ステッ
プ１５８が除去されていることを除いては同じであり、
ステップ１８４は、遠隔経路指定アプリケーシ一ン１１
８を終了しないが、その代わりに、それが次の要求を待
たせる原因となる。残りのステップは同じである。

５ＴＡＲＴ／５ＴＯＰによる同期要求のために、第８図
のフローチャートは、僅かな例外のある専用ステップを
示す。接続ステップ２０８及び２３４は除去され、その
代わり、終了ステップ２４０は、遠隔経路指定アプリケ
ージジン１１８のための次の要求ステップ待ちとなる。

したがって、フラグがどんな種類のトランザクシロンが
要求されているかを示すために必要であるという差はあ
るが、５ＴＡＲＴ／５ＴＯＰで、または５ＴＡＲＴ／５
ＴＯＰなしで要求するために、同じシステムを使うこと
ができる。５ＴＡＲＴ／５ＴＯＰが要求される時、特別
の開始及び終了手順も使用しなければならない。

上記のシステム及び方法によって、ライブラリ手順がネ
ットワークを通して遠隔ノードで呼び出されることがで
きる。ライブラリ手順の位置は、アプリケーション・プ
ログラムに対して知られる必要はなく、実際には時々変
えることができる。

ライブラリ手１頑を書き込むために使われる言語は、そ
れがアプリケーション・プログラムの言語と合致する必
要はないので、変えることもできる。

したがって、ライブラリ・ルーチンの単一セットは、ネ
ットワークに接続されたすべての機械を支援するために
供給することができる。アプリケーション・プログラム
は、言語とは独立したインタフェイスを通って、ライブ
ラリ手順にアクセスするために書くことができ、それら
が必要とするライブラリ手順が構内ノードあるいはほか
の場所に置かれても、それは問題にはならない。これに
ょって、特殊化されたハードウェアを用いるベクトル動
作などのある機械では、より効率的に動作するライブラ
リ手順がより効率的な機械で実行できるようになる。

Ｅ１発明の詳細 な説明したように本発明によれば、アプリケーション・
プログラムがネットワークによって構内機械に接続され
た遠隔機械上に置くことのできるライブラリ手順に対し
て、呼出しができるシステム及び方法が提供される。

本発明を、特に好ましい実施例を用いて詳しく述べたが
、一方、形状及び詳細の様々な変更を、本発明の意図及
び範囲から逸脱することなく行なうことができることを
、当業者は理解されたい。

【図面の簡単な説明】

第１図は、構内機械でライブラリ手順を呼び出すための
システムのブロック図である。 第２図は、ライブラリ・ルーチンを呼び出すためのフォ
ーマットを示す図である。 第３図は、構内機械でライブラリ手順を呼び出すために
取られるステップを示す流れ図である。 第４図は、遠隔機械でのライブラリ手順呼出し用システ
ムのブロック図である。 第５図は、遠隔機械でライブラリ手順に同期呼出しをす
るために取られるステップを示す流れ図である。 第６Ａ部及び第６Ｂ図は、遠隔機械でライブラリ手順に
同期呼出しをするために取られるステップを示す点れ図
である。 第７図は、遠隔機械でライブラリ手順に対する一連の呼
出し用通信リンクを開始するために取られるステップを
示す流れ図である。 第８図は、遠隔機械でライブラリ手順に対する一連の呼
出し用通信リンクを終了するために取られるステップを
示す流れ図である。 サービス手順 Ｗｌ、６Ａ図

Claims (12)

【特許請求の範囲】
1. （１）所望の手順が遠隔ノード上にあるか否かを判定し
   、所望の手順識別子を遠隔ノードに報告し、さらにそこ
   から結果を受信するために、アプリケーション・プログ
   ラム手順呼出しに応答して呼び出すことのできる、構内
   ノードでの経路指定手順と、所望の手順識別子を遠隔ノ
   ードから受信し、さらに結果をそこに送るために、前記
   構内ノード経路指定手順と通信するための、遠隔ノード
   での経路指定手順と、 前記所望の手順に対応する手順が前記遠隔ノード経路指
   定手順により呼び出され、結果をそこに戻す、前記遠隔
   ノード経路指定手順によって手順呼出しに応答して呼び
   出すことができる、遠隔ノードでの複数の手順 を含む、構内ノードから遠隔ネットワーク・ノード上の
   手順を呼び出すための手順呼出しシステム。
2. （２）所望の手順が遠隔ノード上にある場合、第１イン
   タフェイスが前記構内ノード経路指定手順を呼び出すと
   いう、標準フォーマットでアプリケーシヨン・プログラ
   ムによって呼び出すことができる、前記第１インタフェ
   イスと、 第２インタフェイスが、前記遠隔ノード経路指定手順か
   ら受信された所望の手順識別子に対応する前記複数の手
   順の１つを呼び出すという、基準フォーマット内の前記
   遠隔ノード経路指定手順によって呼び出すことができる
   、第２インタフェイス をさらに含む、請求項１のシステム。
3. （３）所望の手順が構内ノード、または遠隔ノード上で
   利用できるか否かを示すために、前記第１インタフェイ
   スに接続された第１テーブルと、所望の手順を前記第２
   インタフェイスから呼び出すために、位置及び手順呼出
   し要求を示すための前記第２インタフェイスに接続され
   た第２テーブル をさらに含む、請求項２のシステム。
4. （４）戻された結果が前記待ち行列の中に置かれている
   という、アプリケーション・プログラムに対する後での
   利用可能性のために、前記遠隔ノード経路指定手順から
   戻された結果を保待するための待ち行列をさらに含む、
   請求項１のシステム。
5. （５）前記遠隔ノード経路指定手順により戻された結果
   が、前記構内ノード経路指定手順によって、アプリケー
   ション・プログラムに戻される、請求項１のシステム。
6. （６）所望の手順識別子で、アプリケーション・プログ
   ラムから構内ノード上の経路指定手順を呼び出すステッ
   プと、 所望の手順識別子で、構内ノード経路指定手順から遠隔
   ノード上の経路指定手順を呼び出すステップと、 所望の手順識別子に対応する遠隔ノード上の手順を呼び
   出すステップ を含む、アプリケーション・プログラムから手順を呼び
   出すための手順呼出し方法。
7. （７）結果を所望の手順から戻すステップと、結果を構
   内ノード経路指定手順に戻すステップと、 結果をアプリケーション・プログラムに戻すステップ をさらに含む、請求項６の方法。
8. （８）結果をアプリケーション・プログラムに戻す前記
   ステップが、 結果をアプリケーション・プログラムによってアクセス
   できる待ち行列内に置くステップと、待ち行列からアプ
   リケーション・プログラム内への結果を読み取るステッ
   プ を含む、請求項７の方法。
9. （９）所望の手順が遠隔ノードで呼び出される度に、新
   しいネットワーク通信リンクが設定される、請求項６の
   方法。
10. （１０）手順に対する一連の所望の呼出しを遠隔ノード
    上に作る前に、構内ノードと遠隔ノードの間にネットワ
    ーク通信リンクを設定するステップと、一連の呼出し中
    に、そのような通信リンクを維持するステップ をさらに含む、請求項６の方法。
11. （１１）前記第１呼出しステップが、 所望の手順識別子で、アプリケーション・プログラムか
    ら構内ノード上の第１インタフェイスを呼び出すステッ
    プと、 所望の手順が構内ノードまたは遠隔ノードで利用可能で
    あるか否かを判定するステップと、所望の手順が遠隔ノ
    ードで利用可能である場合、所望の手順識別子で構内ノ
    ード経路指定手順を呼び出すステップ を含む、請求項６の方法。
12. （１２）遠隔ノード上の経路指定手順を呼び出す前記手
    段が、 所望の手順識別子で遠隔ノード経路指定手順から、遠隔
    ノード上の第２のインタフェイスを呼び出すステップと
    、 所望の手順に対応する手順を決定するステップを含む、
    請求項１１の方法。