JPH02201653A - アプリケーシヨン・プログラム・インターフエース方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 この発明はコンピュータ・システム・インターフェース
に関し、より具体的には複数の言語で記述きれている種
々のアプリケーションをソフトウェア・システムにイン
ターフェースするのを支援するようにしたものである。

Ｂ、従来の技術 まずこの発明が解決しようとしている問題の概要に触れ
、つぎに問題の詳細な検討および従来の試みについて述
べることにする。コンピュータ・システムにおいて複数
の言語で記述きれた種々のアプリケーションをソフトウ
ェア・システムの機能たとえばＩＢＭ社のＯ３／２　（
商標）オペレーティング・システムのデータ・ベース・
マネジャにインターフェースするよう支援を行うことが
望まれることがしばしばである。しかしながら異なるコ
ンピュータ言語は異なるインターフェース上の仕様を伴
い、たとえば所定の言語で記述きれているプログラムが
、他の言語で記述されている他のプログラムを呼び出す
ときには、当該他のプロ・ダラムはコンピュータ・シス
テムのプロセッサの所定のレジスタの内容を保持するよ
うに期待される。他方呼び出されるプログラムないし被
呼者（ｃａｌｌｅｅ）たとえばデータ・ベース機能は呼
者（ｃａｌ］ｅｒ）が予め定められたパターンでパラメ
ータ情報を引き渡すことを予定している。

このような仕様の例は（１）所定のパラメータは、使用
に供される値であることが予定される一方、他のパラメ
ータはその値が存在するアドレスであることが予定きれ
る、（２）パラメータたとえばバイト・アレイはナル（
零）で終ることが予定される、たとえばゼロの最終バイ
トを有する、（３）値またはアドレスであるパラメータ
の順序は、予め定められたパターンで呼者が引き渡すも
のであると被呼者が予定している、たとえば値が最初に
なったり、組の順序に混在させられるとかになる。

上述のとおりコンピュータ言語はその仕様に関し異なる
ものであるから、異なる言語で記述されたアプリケーシ
ョンのインターフェースを支援するうえでの問題点は、
通常、支援されるべき各言語で表わされたデータ・ベー
ス・マネジャまたは他の機能への個別のインターフェー
スを実現することによって解決されねばならないという
点である。そうでないのであれば、各機能ごとに新しい
エントリ・ポイントを設計し、これがほとんどのコンピ
ュータ言語にとって許容可能な態様でパラメータを受は
付けることができ、現行のエントリ・ポイントの呼び出
しを準備するようにしなければならない。いずれの場合
でも、開発、維持がめんどうである等の欠点があること
は明らかである。

結局、ソフトウェアの一部を他のソフトウェア・データ
・ベース、オペレーティング・システムまたは基本人出
カサ−ビスすなわちＢＩＯ８のようなプログラミング・
サービスの単一カーネルを含んでもよい）にインターフ
ェースしアクセスする必要が生じるときには、常に、ど
のように矛盾なく通信するか、すなわちどのようにパラ
メータを渡し結果ないしコードを返すかについての規則
（コンベンション）が必要となる。規則は個々のプログ
ラム言語によって確立される。プログラム言語はそれぞ
れ異なるインターフェース仕様を有しているのである。

呼者および被呼者が同一のプログラム言語で記述されて
いるときには、単一のプログラム言語たとえばＦＯＲＴ
ＲＡＮで記述された呼者および被呼者アプリケーション
について仕様が同一であるため、その言語でインターフ
ェースの仕様が処理されるかぎりインターフェース上の
問題はない。したがってコンパイラは、呼者に引き渡す
べきパラメータや戻すべきデータ等の結果を引き渡し返
すために実行されるべき際にサービスする。典型的なデ
ータ・ベースの例では、このデータおよびパラメータに
は、データ・ベースを生成する被呼者に引き渡すべき、
生成対象のデータ・ベースの名前や呼者に返ずべきコー
ドの結果たとえばデータ・ベースが生成されたかどうか
のコードの結果が含まれる。

アプリケーションが正しく通信を行う態様を確立するこ
れら規則のより詳細な例を説明する。たとえばＣ言語で
記述されているデータ・ベース・カーネルにおいては、
呼者が名前をカーネルに弓き渡して末端でナル・バイト
をアクセスできるようにし、カーネルが名前の長さまた
は末端を認識すると仮定されている。しｌでがってデー
タ・ベースは絶え間なく仮定を採用してきた。たとえば
どこから来るのであっても名前（内部から来る名前もそ
うである）に関してストリング・キャラクタは常にナル
で終了するという仮定を採ってきた。

このようなことがなぜ常に重要であったかを考えよう。

実行時ライブラリを呼び出すときには、弓き渡されたス
トリングの長さを知らきれることなく機能が呼び出きれ
る。（ストリングはナルで終る）そして以上のような仮
定がなければ所望の機能は一般には正しく動作しないで
あろう。このように規則が必要とされるので、呼者を同
様にＣ言語で記述し、名前のキャラクタ・ストンソング
を引き渡されるときにはいつでもコンパイラが一貫し一
〇 てナルを自動的に付加してカーネルにストリングが引ｔ
ｉすれるときにそれが１つのストリングとして認識され
るようにする必要があると考えられてきた。他の言語た
とえばＦＯＲＴＲＡＮはストリングの終了に異なる規則
を有し、ＦＯＲＴＲＡＮで記述きれたアプリケーション
はそのようなナルの区切りを有しないであろう。ただし
、データ・ベース・カーネルはナルのない区切りを予定
し、プログラムは正しく動作しないであろう。

ストリングの区切りは、インターフェースを成功させる
上で異なる言語の要求仕様に関連する問題の１つの例に
すぎない。異なる言語で記述されたアプリケーションを
インターフェースする際の他の典型的な問題は値および
アドレスの引き渡しに関係していた。この問題は、言語
が１つ１つ引き渡すのみであるかぎりは、ないしは予め
定められた順序で引き渡すかぎりは、一般にもつとも困
難となる。したがって「参照による呼び出し」ないし「
値による呼び出し」の要請が、異なるプログラム言語で
記述されたアプリケーションを有効に呼び出すうえでの
障害となる他の不一致点である。順序およびパラメータ
・タイプの仕様に関連する問題を説明する具体的な例は
つぎのようなものである。すなわちＣ０ＢＯＬでは値に
よるすべてのパラメータが先に引き渡され、つぎに参照
のパラメータが何も伴うことなく引き渡される必要があ
り、他方ＦＯＲＴＲＡＮでは参照によってのみ引き渡し
が行われる。

異なる言語で記述されたアプリケーションをインターフ
ェースする際の問題は、ストリングないし値／参照呼び
出しの態様種々の言語で一貫していないという点に限定
されず、データ・ベースのような被呼者が所定のアプリ
ケーションによって呼び出きれたのち制御を引き受けた
ときにストアきれる、プロセッサの現行状態情報の量の
ような付加的なファクタを含む。１つの言語で記述きれ
た所定のアプリケーションは、アプリケーションへの復
帰時にレジスタの所定の内容が同一であると期待するこ
とがあり、もしデータ・ベース・カーネルが内容を変換
するまえにデータ・ベース・カー＝８− ネルがそれを留保しておないなら、アプリケーションは
それ以降適切には動作しないであろう。これは、とくに
、プログラムの一部すなわちスレッド（ｔｈｒｅａｄ）
を同一また他のプログラムの残りの部分と非同期で実行
するという多重スレッド・コードないし多重スレッド手
法に関連する問題である。プログラム部分の各々が実行
を行っているときマシーンの状態は異なっているであろ
うし、データ・ベース・カーネルまたは他のソフトウェ
アの同一の機能がこれら異なるコード部分により呼び出
されることもある。２番目のスレッドが具体的なアプリ
ケーション・プログラム・インターフェイスを呼び出し
たときに、メモリにストアされている先のスレッドの先
行した呼び出しに関するレジスタ状態情報は通常書き変
えられ、そのためプログラムの以降の動作が適切に動作
しなくなるであろう。

結局、異なるインターフェース上の仕様が異なるプログ
ラム言語および異なるプログラム言語で記述されたアプ
リケーションごとに存在する。データ・ベース等のソフ
トウェア・プロダクトを２以上の言語で記述された種々
アプリケーションでアクセスできるようにする必要があ
るならば、支援言語で記述されたアプリケーションの要
請を満たす方策が、それらアプリケーションが首尾良く
データ・ベースを呼び出すために必要となる。したがっ
て複数のコンピュータ言語で記述されたアプリケーショ
ンを効率良くインターフェースする手段が長い間求めら
れた。ざらに、支援きれるべき各アプリケーションの言
語ごとに個別にインターフェースを実現する必要が回避
されたシステムおよび方法が強く望まれていた。また現
行のエントリ・ポイントの呼び出しを準備するために、
複数のコンピュータ言語で許容できるパラメータを受は
取ることができるようにする、機能の各々への新しいエ
ントリ・ポイントを、デザインする必要がない、解決法
も望まれていた。また異なるインターフェース上の要請
および仕様を有する広範囲の言語で記述されたアプリケ
ーションからソフトウェア・プロダクトに外部からエン
トリ・ポイントを（を勾するうえで必要な、開発の手間
、全体のメインテナンスおよびサポートを実質的に減す
るためにも、複数のコンピュータ言語で記述きれたアプ
リケーションのインターフェースを提供する解決策が緊
急に必要とされていた。

Ｃ０発明が解決しようとする課題 この発明は以上の事情を考慮してなきれたものであり、
複数の言語で記述された種々のコンピュータ・アプリケ
ーション・プログラムをデータ・ベース　マネジャのよ
うなソフトウェア・システムにインターフェースする手
法を提供することを目的としている。

０１課題を解決するための手段 この発明では以上の目的を達成するために、ソフトウェ
ア・システムにより支援される複数の機能の各々に対し
て総括的アプリケーション・プログラム・インターフェ
ースないしエントリ・ポイントを用意し、このインター
フェースないしエンドす・ポイントを、当該機能を実行
するためにシステムが要求するフオームと合致したフオ
ーム（フオームの一貫性）で複数のパラメータを有する
ものとして定義する。ここでフオームの一貫性にはパラ
メータの順序、ナル区切り、値またはアドレスによる変
数の引き渡しの態様等を含む。各エントリ・ポイントは
、上述複数の言語のいずれかで記述きれたアプリケーシ
ョン・プログラムにより呼び出すことができ、このエン
トリ・ポイントが呼び出しのパラメータを一貫性のある
総括的フオームに変換しソフトウェア・システムの機能
を実行できるようにする。

スレッドに対応するプロセッザ状態が呼び出しに応じて
、すべての総括的プログラム・インターフェースにより
アクセス可能で共有されているテーブルにストアされる
。アプリケーション・プログラムによってはテーブルは
アクセスされない。つぎに背景のソフトウェア・システ
ムの機能が呼び出される。呼び出しから戻り、システム
が機能を実行するときには、プロセツザ状態が元に戻さ
れ、戻りコード情報および制御がアプリケーション・プ
ログラムに返される。この手法では、支援され＝１１− ている種々の手続き言語の各々で記述されたアプリケー
ションに対して個別にエントリ・ポイントを設ける必要
がない。各言語に対してエントリ・ポイントが重複して
付随的に開発量、メインテナンス、サポートの必要性が
なくなる。これは種々の言語のインターフェース仕様を
束ねて画一的な順序にすることによって実現される。

具体的な例では、エントリ・ポイントはデータ・ベース
・マネジャにより支援されている複数の機能たとえばデ
ータ・ベースの生成、破壊、付加または走査の各々に対
して定義されている。各アプリケーションにより呼び出
すことができる複数の機能に対して定義されたそのよう
な新しいエントリ・ポイントに対して、個々のデータ・
ベース機能の仕様に応じて一組のパラメータが定義され
た。

このようなパラメータはデータ・ベースと合致しており
、複数の言語で記述されたアプリケーション・プログラ
ムから呼び出し可能である。この具体的の１つのエント
リ・ポイントは、複数の種々の言語に関連するストリン
グ長の特定の仕方に由来する種々のフオームを有する、
ストリング長の表示を受は取って、データ・ベース・マ
ネジャがストリングを認識するうえで必要ときれる現行
の単一の仕様によって理解可能な画一的なフオームに変
換する。具体的には、そのエントリ・ポイントにはスト
リング長を示すパラメータが含まれ、このパラメータに
よりストリングの区切りを指示するためにナル・バイト
が自動的に付加される。

また好ましい例では、多重スレッド・コードを想定して
いる。第１のアプリケーション・プログラム・インター
フェースが呼び出されたときに、システムはオペレーテ
ィング・システムを呼び出して、呼び出しているスレッ
ドの識別番号を検索する。ここで各スレッドは固有の識
別番号を有している。バッファはプロセッサ状態情報の
すべてをストアし、ＩＤをテーブルへのインデックスと
して用いる。個々のスレッド状態情報がセーブされると
き、この情報は、個々のスレッドにのみ割り当てられて
いるメモリ空間を更新する。

Ｅ、実施例 第１図はこの発明のコンピュータ・システムを示す機能
的なブロック図であり、この発明が解決する問題点を示
している。このシステムにおいては、通常オペレーティ
ング・システム１８が設けられ、複数のオペレーティン
グ・システム・アプリケーション・プログラム・インタ
ーフェース２０からのシステム呼び出しは基本的には総
括的ＡＰ　Ｉ　１’４と同一の目的を持っている。たと
えば、システム呼び出しはエントリ・ポイントを供給し
、アプリケーション・プログラム１６がオペレーティン
グ・システム１８をアクセスして必要なサービスを得ら
れるようにする。これらサービスはたとえば、ウィンド
ウの生成、ファイルの読み出し、オーブン等である。こ
れらの機能はデータ・ベース等のプログラム１０をアク
セスする際のアプリケーション１６の種々の機能と類似
している。ここでこの実施例はＯ３／２　（商標）拡張
板コンピュータ・プログラムを基準にして開示されてい
ることに留意されたい。このプログラムはオペレーティ
ング・システムおよびデータ・ベース・マネジャ機能を
具備している。ただし、この発明を説明するうえで具体
的なオペレーティング・システムおよびプログラム・サ
ービス１０を用いるといっても、それによって発明の適
用がそのような態様に限定されるわけではない。以下開
示される発明は広範囲のオペレーティング・システム１
８およびプログラム・サービス１０に容易に適合化でき
ることを理解されたい。

第１図をざらに参照する。従来のシステムに関連する問
題の１つはつぎのような点であったことを思い起こされ
たい。すなわち、オペレーティング・システム１８およ
びプログラム・サービス１０は、アプリケーション１６
が同一の言語で記述され、したがってオペレーティング
・システム１８に対するＡＰ　Ｉ２０のような、または
具体的なプログラム・サービス１０に対するＡＰＩたと
えばデータ・ベース・マネジャＡＰ１１２のようなアプ
リケーション・プログラム・インターフェースは個別の
言語で記述されていると仮定しているのである。したが
って、ＡＰＴ１２および２０は一般的ではなかったし、
２以上のプログラム言語で記述された種々のアプリケー
ション１６から呼び出きれることを予定していない。し
たがって、たとえばデータ・ベース・マネジャ・プログ
ラム・サービス１０が０Ｍ語で記述されていたのであれ
ば、関連するＯＢＭ　　ＡＰ１１２はアプリケーション
１６からの呼び出し、たとえばテ゛−タ・ベースの生成
または削除のための呼び出しがＣ言語の呼び出しと一致
することを予定しており、アプリケーション１６からの
呼び出しが異なる言語のものであれば、アプリケーショ
ン１６は適切に動作しないであろう。しかし、この発明
では複数の総括的ＡＰ１１４をＤＢＭ　　ＡＰ１１２や
オペレーティング・システムＡＰＩ２０の元々のエント
リ・ポイントに設け、多くの予め定められた言語のうち
の任意の言語で記述きれた複数のアプリケーション１６
への現行エントリを生成するようにしている。したがっ
て、この発明の総括的ＡＰ１１４の役割は、アプリケー
ション１６が記述きれた具体的な言語によって決定され
るフォーマット（多くのフォーマットがある）で受は取
られたパラメータを、ＤＢＭ　　ＡＰ１１２およびオペ
レーティング・システムＡＰＩ２０が記述された具体的
な手続き言語で決まる、ＤＢＭ　　ＡＰ１１２およびオ
ペレーティング・システムＡＰ　Ｉ２０が予定する形態
に変換することである。

この発明の詳細な説明するまえに、第１図に示きれる付
加的な特徴について考える。これについても後に詳述す
る。現在のプログラム手法によれば、アプリケーション
１６は多重スレッド・タイプと考えることができ、１つ
またはそれ以上のアプリケーションは、複数のスレッド
すなわちコード部分を含み、これらスレッドの各々が他
のスレッドと非同期的に実行されるようにできる。この
ようなスレッドは機能的にＴ＋　　７４で示される。

この発明では、そのようなスレッドの各々がＡＰ１１４
を呼び出すたびに、この発明のシステムを実行している
コンピュータ中のプロセッサの状態情報を状態保持テー
ブル１７中に所定の態様で保＝１７ 持しなければならない。この発明の１つの特徴は、個々
のスレッドが個別のスレッドＩＤと個別のメモリ空間な
いしロケーションをテーブル１７中に有しているという
点である。各スレッドのプロセッサ状態はテーブル中の
固有の対応する位置に同期的にストアされ、同一のスレ
ッドに対応する情報を上書きする。この態様については
後に詳述する。

第２図においてこの発明のより詳細な説明を行う。ソフ
トウェア・システム４２は一般的にはどのようなシステ
ムであってもよく、ただ、多くのアプリケーションにア
クセスされるものである必要がある。オペレーティング
・システム、データ・ベース機能あるいは基本人出カサ
−ビスＢＩＯ３であってよい。ソフトウェア・システム
４２にはインターフェース４０が提供され、これによっ
てシステム２４が所定の要求を確立する。たとえばイン
ターフェース仕様３４との関連でアプリケーション（第
１図の１６で示すようなもの）の外部に対する予め定め
られたエントリ・ポイント３６である。システム２２は
したがってシステム／′４２に対するインターフェース
３８の仕様を確立する。

動作可能なシステムに対するインターフェース３４およ
び３８−４０はシステム２２および２４か始めから存在
し、同一の言語で記述されるかぎり互換性がある。再言
するならば、この発明では現行エントリが生成され、こ
れによって、インターフェース仕様３４と互換性のある
インターフェース３２をシステム２６に提供できる。た
だし、第２図に関連してつぎの点に留意することは重要
である。すなわちこの発明のシステム２６は異なる言語
で記述された種々のアプリケーション１６に対する総括
的インターフェース２８を提供し、この結果ソフトウェ
ア４２に対する総括的なエントリ・ポイントの集合を提
供するのである。換言すれば、この発明のシステム２６
は現行のソフトウェア・システム４−２に対する一般化
を行っているのである。さらに、システム２２および２
４が予め存在するので、この発明のシステム２６を望み
どおりにマシン・コードやアッセンブリ言語で書くこと
ができ、このため予め存在するインターフェースを、ソ
フトウェア・システム４２へ対する現行エントリ・ポイ
ントとの共通性を持たせることができる。このことはブ
ロセツザのスタックを操作することにより実現でき、こ
のため、インターフェース２８および３２の実質的なマ
ツピングが有益となる。このようなマツピングを実現す
るうえで、呼者の戻りアドレスはスタックから除去され
る。この点についてはフローチャート参照して後に明瞭
にする。このようにして、システム２２に対して総括的
エントリ・ポイントへの呼び出しがなされる。これはあ
たかもアプリケーションから来たようになる。たとえば
その呼び出しが直接にアプリケーション１６から来たか
のようにシステム２２がスタックを判断する。システム
２６がこのようなことを実現するために実行する１つの
機能はスタックから戻りアドレスを除去し、これにより
システム２２がスタックの戻りアドレスを見るのでなく
システム２６からの戻りアドレスを参照するようにする
ことである。このようにして、総括的インターフェース
２８と既存エントリ・ポイント３６の固有の要求を満た
すインターフェース３４との間のマツピングがシステム
２２と無関係に行われる（トランスペアレントである）
。以上の点は第５図〜第７図を参照して後に詳述するス
テップによって達成される。

第３図において、高レベル・コンピュータ言語で記述さ
れたデータ・ベース・アプリケーション・プログラム５
４がこの発明とともに用いられる。

このようなプログラム５４は２ないしそれ以上の非同期
ユニットとして、あるいは実行のスレッドとして構成す
ることができる。これは概念的にスレッド番号１．（５
８）およびスレッド番号２（５６）で示される。プログ
ラム５４はデータ・ベース・マネジャ・ソフトウェア・
システム９６のサービスを利用する。このシステム９６
をアクセスするにはインターフェース・エントリたとえ
ば機能呼び出しを用いる。これはデータ・ベース・イン
ターフェース９５により表ねされている。これらエント
リ・ポイントはシステム９６と同一の言語＝２１− ないしアッセンブリ言語で記述されているアプリケーシ
ョンがアクセスするのに適したものである。

システム９６により付与され、アプリケーション・プロ
グラム５４（およびスレッド５６．５．８）によってア
クセスされるサービスは、通常データ・ベース・マネジ
メント・ソフトウェア・システムたとえば上述Ｏ３／２
オペレーテイング・システムの拡張板のリリース１．０
と関連するサービスである。

システム９６はオペレーティング・システム９８のサー
ビスをオペレーティング・システム・インターフェース
・エントリ・ポイント９７を通じてアクセスする。オペ
レーティング・システム９８によって提供されシステム
９６によってアクセスされるサービスはコンピュータ・
オペレーティング・システムに広く関連するサービスで
ある。

インターフェース・エントリ・ポイントは符号６０およ
び６２で示すように提供きれ、データ・ベース・マネジ
ャ・ソフトウェアを記述するために用いられた言語以外
で、しかもこの発明を実現するのに用いるコンピュータ
・システムで採用されているアッセンブリ言語または機
械語以外の言語で記述きれたデータ・ベース・アプリケ
ーションによって、システム９６をアクセスするのに用
いられる。スレッド５６および５８は実行につき非同期
であるから、双方が総括的ＡＰＩたとえばＡＰＩ６２に
対する呼び出し９２および９４を同時にアクセスするこ
とが可能となる。

ざらに第３図を参照する。符号２００は、コンピュータ
・メモリたとえばＲＡＭの一部でＡＰＩ６０および６２
のような総括的ＡＰＩによってマシーンのプロセッサ５
１のレジスタ５０の内容をストアするために保持され共
用される部分を示す。

プロセッサ・レジスタ５０すべでの組の内容が任意の時
点でプロセッサの状態として知られ一般に５２によって
表わされる。メモリ、より具体的にはレジスタ保持テー
ブル２００は、アプリケーションにおいてオペレーティ
ング・システム９８により許容されるスレッドの最大数
と等しい多数のプロセッサの状態ないしテーブルのエン
トリをス−２３＝ トアするに足る数のバイトを保持する。メモリ部分２０
０については第４図を参照して後に詳述する。符号４８
は能動すなわち現に実行しているスレッド用の情報スタ
ックとして用いる。コンピュータの化メモリの一部を示
す。オペレーティング・システム９８はそのような実行
中のスレッド用に個々にスタックを要求する。呼び出し
９４のような呼び出しにより活動状態になると、ＡＰＩ
は矢印７０で示すようにプロセッサ５１のレジスタ５２
の状態を読み出して現行スレッドのスタック４８に矢印
４６に示すようにストアする。これはＡＰＩがプロセッ
サの状態を変更するまえに行う。

ＡＰ　Ｉ　６２は呼び出し１００および１０１を行って
呼び出しスレッドの各々に対して識別子を得る。

すでに触れたように各識別子番号は個々のスレッドにオ
ペレーティング・システム９８により固有に割り当てら
れ、またこの識別子番号はオペレーティング・システム
９８によって定義された有限集合の要素である。

一旦ＡＰＩ６２が呼び出し９４に対するスレッド識別子
番号を取ると、ＡＰＩ６２は矢印７２に示すようにプロ
セッサの状態４４をスタック４８から呼び出し９４のス
レッド識別子番号に対応するテーブル２００のエントリ
に転送する。これはスレッド５８から来たものである。

つぎにＡＰＩ６２はパラメータを確定するように進む。

このアルゴリズムは第５図〜第７図に示される。このの
ちＡＰＩ６２は呼び出し９４Ａをデータ・ベース・マネ
ジャ・インターフェース９５に対してなす。

ＡＰ　Ｉ　６２がこのようなことを行えるのは、ＡＰＩ
６２がアッセンブリ言語で記述され、したがってインタ
ーフェース９５をアクセスできるからである。呼び出し
９４Ａから制御を受けたとキ、ＡＰＩ６２は矢印８６に
示すように呼び出し９４に対する識別子番号に対応する
テーブル２００のエントリを読み出し、こののち矢印７
１に示すようにプロセッサ５１のレジスタ５２の内容を
再ストアする。このステップは制御を呼者５８に戻す直
前に行われる。

既述したＡＰＩ６２によるプロセッサ状態の読み出しお
よびストアならびに呼び出し］００および］０］を行っ
て識別子番号を得るステップはスレッド５６による呼び
出し９２にも適用でき、また呼び出し９４に関連して説
明したステップと同時に起こり得る。スレッドの識別子
番号は固有のものであるから、レジスタ５２にプロセッ
サの状態をストアするのに用いるテーブル２００のエン
トリもまた固有のものである。このため、アプリケーシ
ョン・プログラム５４が多重実行スレッドを用いるかど
うかにかかわらずプロセッサの状態を保持できる。テー
ブル２００の同一メモリ空間をＡＰ　Ｉ　６２と共有す
る個々の総括的ポイント６０はＡＰＩ６２に対する呼び
出し９４がスレッド５８に実行の制御を戻したのちにの
みスレッド５８によって呼び出すことができる。このよ
うな制約は、実行スレッドのコードを含むマシーン・イ
ンストラクションを順次的に実行する態様において特有
のものである。同一メモリ空間を共有する個々の総括的
エントリ・ポイント６０の当該ステップにより、テーブ
ル２００で表わきれるメモリを共有する総括的Ａ、ＰＩ
はいずれも同一スレッドから同一時点で１度しか呼び出
されないことが保障される。さらにこねによイ′）任意
の所定の呼び出しに対してヨビ７２が裏付されてから再
ストア８６が実行されるまでの間テーブル２００のエン
トりにストアされるデータの保持が保障される。

第４図において、符号］６０によって一般的、模式的に
示されるフォーマットがコンピュータの主メモリの予約
部分に割り当てられ、データ・ベース・マネジメント・
ソフトウェア・システムへの一組の総括的エン１．１ノ
・ポイントへの呼び出しの間、プロセッサ５１の状態情
報を一時的にストアするのに用いられる。第３図に関連
する説明はフォーマツｌ−１６０の使用についての情報
を提供する。フォーマット１６０は複数のエントリたと
えば符号１５２．１５４．１５６および１５８で示され
るエントリに分割される。フォーマット１６０の１つの
エントリはマシーンの主プロセツサの各々しかも任意の
レジスタの内容をストアするのに用いる空間を表わす。

多数のエントリはポック＝２７− ス１５６および１５８によって示すように有限であり、
マシーンのオペレーティング・システム９８によって割
り当てられる。Ｎはアプリケーション・プロセスあたり
に許容された実行スレッドの上限の数に対応する。エン
トリはスレッドの識別子番号により一対−の関係で特定
され、スレッドの識別子番号をフォーマット１６０中の
対応するエントリを特定するのに用いられるようになっ
ている。

第５図はこの発明を具現化するソフトウェア・プロダク
トのフローチャートである。フローは第１図の所定のア
プリケーション・プログラム１６中のスレッドから続い
てブロック１００で開始される。第１図のアルゴリズム
を詳細に説明するまえにそのアルゴリズムにより実行さ
れる機能の概要について説明を行うことは有益である。

第５図のステップはこの発明の総括的ＡＰＩが、−膜化
されたインターフェースを用い呼び出し時にコンピュー
タ・システムのプロセッサの状態を保持するアプリケー
ション・プログラムから呼び出しを最初に受は取るのに
用いるアルゴリズムを示す。

ず。このアルゴリズムはパラメータを調整して、現行Ａ
ＰＩの異なる言語で記述されている背景の機能の要求に
適合化させる。現行ＡＰＩはつぎに呼び出され、プロセ
ッサの状態が、アプリケーションに返された情報の結果
とともに再ストアされる。総括的アプリケーション６ま
たとえば第３図に示される第１のアプリケーションは矢
印４６で示されるように部分的なプロセッサ状態に現行
スレッド・スタック４８にストアする。この状態は第３
図の符号４４で示すようにストアされる。プロセッサ状
態をストア（第５図のステップ１００）したのち、プロ
セッサのレジスタがステップ１０２でセット・アップさ
れ、ＡＰＩ６２が現行スレッド・スタック４８をアクセ
スできるようにする。

ステップ１０４において同様の手続きがデータ・セグメ
ントをセット・アップし、現行ＡＰＩ６２がレジスタ保
持テーブル２００のグローバル・データをアクセスでき
るようにする。これらセット・アップ手続１０２および
］０４に関連して、ここでの実現例ではセグメント・ア
ドレス・モードを用いるプロセッサを採用している。た
だしこの発明はそのように限定されるものではない。各
ＡＰＩは保持テーブル２００中に所定量のメモリを所有
しており、また結合プロセスによって各ＡＰＩに割り振
られる基底アドレスを有している。「セット・アップ」
ステップは各ＡＰＩに対応するデータ・セグメント中に
、そのＡＰＩに対応するテーブル２００のメモリ空間の
基底アドレスをロードすることを指す。

ステップ１０６において、オペレーティング・システム
９８の情報、より具体的にはオペレーティング・システ
ムが現行プロセスに関する情報たとえば現行呼者ないし
実行中のアプリケーションのスレッドＩＤをストアする
メモリのブロックをアクセスすることに関するテストを
実行する。このスレッドＩＤは現行アプリケーションに
より呼び出された第１のＡＰＩにより当初付与きれる必
要がある。ところでＡＰＩたとえば６０および６２はす
べてパッケージ化されていることがわかる。

各ＡＰＩは背景のオペレーティング・システム・ソフト
ウェア９３によって提供きれる種々のサービスの各々に
対するインターフェースを提供するものと考えることが
できる。ここでは「パッケージ化」とはそのようなＡＰ
　Ｉ　６０−６２のすべてがグローバル・データを所有
し、ざらに重要なことであるが、プロセス情報ブロック
をストアする空間に加えてレジスタ保持テーブルを所有
することを１旨す。このようにしてＡＰ　Ｉ　６０−６
２の１つが現行のプロセス情報ブロックを読み出したと
き、同一パッケージの異なるＡＰＩに対する後続の呼び
出しはブロックを読み出す必要がなく、簡単にアクセス
を行える。ブロックがパッケージ内のすべてのＡＰＩに
よって共有されるメモリ空間内にあることから、ステッ
プ１０４でグローバル・アドレスを設定するようにして
いるのは、以上の点に由来する。

ざらにステップ１０６を参照する。すべてのＡＰ　ｌ６
Ｏ−６２はこのテストを実行して当該ブロックが読み出
きれたかどうかを決定する。読み出−３１＝ されていなければ、オペレーティング・システム９８を
呼び出して、オペレーティング・システムが当該ブロッ
クを読み出して個々のＡＰＩに属するメモリ空間に転送
するように要求する。そのような情報はブロック中に残
され、オペレーティング・システムのみが更新する。い
つの時点でもスレッドＩＤは現行のものであるからであ
る。ＡＰＩ６０−６２はブロック自体をストアするので
なく、ブロックのアドレスをストアする。ブロック自体
はオペレーティング・システムに属するからである。こ
の結果、ＡＰＩが共有するものは、アドレスすなわちオ
ペレーティング・システムのみが更新するブロックへの
ポインタを含むメモリ・ロケーションである。ブロック
内の唯−ＡＰＩが関連する部分情報は現行スレッドＩＤ
である。

ブロック１１０においてオペレーティング・システムに
呼び出しがなきれてブロックのアドレスが取り出され、
ＡＰＩがスレッドＩＤをどこから取るべきかを知ったの
ち、オペレーティング・システムが読み出しを成功裡に
実行したかどうかのテスト１１２が行われる。ステップ
１１２でエラーが検出されるとステップ１１６で戻りコ
ードがセット中アップされ、アプリケーション５４にア
プリケーション５４からの呼び出しが成功裡に完了しな
かったことを通知し、またシステム・エラーのため制御
が呼者に戻される（ステップ１４２）。

ステップ１１２でエラーが検出されないならば、ステッ
プ１１４が実行きれ、ここでプロセス情報ブロックのア
ドレスがセーブきれてＡＰＩがどのような時点でもオペ
レーティング・システムを呼び出す必要をともなうこと
なくブロックをアクセスできるようになる。ステップ１
０８において情報ブロックを用いて現行呼者のスレッド
ＩＤ番号を取り出す。とくに重要なことは先に述べたよ
うに、呼び出しているスレッドとの呼者のスレッドＩＤ
番号が、スレッドおよびプロセスの間でプロセッサが分
割されるとき、オペレーティング・システム９８によっ
て更新きれるということである。

ステップ１１８において当該スレッドＩＤ番号を状態保
持テーブルへのインデックスに用いて当該スレッドＩＤ
に対応する領域をアクセスする。状態保持テーブルはす
べてのレジスタないしプロセス情報を保持する領域であ
るエントリを含む。アプリケーション・プログラムが保
持することができるすべての実現可能なスレッドは状態
保持テーブルへの予め割り振られたエントリを有する。

このことは状態保持テーブルが静的な予め割り振られた
テーブルであることを示す。さらにステップ１１８にお
いて、ステップ１０８で得られたスレッドＩＤ番号を用
いてテーブルにインデックスを付与し、呼び出しを行っ
ているスレッドのＩＤ番号に対応するエントリを見出す
。ステップ１００でセーブされた部分プロセッサ状態情
報および今の時点で不変な他のプロセッサの状態はすべ
て状態保持テーブルへの当該エントリにセーブされる。

つぎらアルゴリズムはステップ１２０に進み、ここでは
基本的にスタックから呼者の戻りアドレスを除去する。

このステップの目的は背景の機能ないしＡＰＩに呼び出
しを行えるようにすることである。これはパラメータを
操作する必要がない場合にのみ重要である。場合によっ
ては、ＡＰＩ６１〜６２で実行されるサービスのみが状
態保持であることがあり、この場合パラメータは同一で
あろう。換言すればパラメータをアプリケーションが引
き渡すときにそのパラメータが背景の機能にとって適当
であろう。このような場合、効率の点から、総括的ＡＰ
　ｌ６Ｏ−６２が実行すべきことは、ステップ１２０に
おいて戻りアドレスを除去することのみである。そして
アルゴリズムはステップコア２８に進む。

ステップ１２２においてストリング・パラメータがある
かどうかのチエツクを行う。この場合、つぎの点に留意
することは有益である。すなわち第５図に示されるアル
ゴリズムはエヌスキューション・アルゴリズムでなくイ
ンプレメンテ−ジョン・アルゴリズムであって、アルゴ
リズムの具体例は各総体的ＡＰＩに対してコード化でき
、所定のＡＰＩはアルゴリズムのすべての要素を含む必
要がないのである。たとえばステップ１２２はストリン
グ・パラメータを調整するためにＡＰＩのコードを含む
べきかどうかを決定する。アルゴリズムに対してコーデ
ィングを行う時点でインターフェースがストリング・パ
ラメータを有するかどうかがわかるであろう（ステップ
１２２）。もし有するのであれば、ステップ１２４に示
されるようにナルずなわぢゼロ値のバイトをストリング
の終端に加えてコードへの付加がなされ、この結果、統
合パラメータによりストリングの終端が見出される。こ
れは−膜化プロセスの一部である。ナルはストリングの
一部として引き渡されねばならないから、ストリング中
のバイト数すなわちストリングの長さも引きａきれねば
ならない。アルゴリズムをコンピュータ処理に適合化さ
せるために、ステップ１．２２−１２４を、ステップ１
２２の判別を行うことなしに任意のストリング長のパラ
メータにゼロ値のバイトを付加するステップに置き換え
ている。

ステップ１２６においてアルゴリズムは総括的ＡＰＩに
対するパラメータ・フレーム（パラメータの順序や大き
さによって決定きれる）を識別し、そのスタック・フレ
ームを背景の機能のそれと比較する。同一であればステ
ップ１２８に進む。背景の機能が同一のスタック・フレ
ームを持っていなければ、ステップ１３０においてコー
ドが提供されて、総括的ＡＰＩに渡されたスタック・ク
レームを用いて背景の機能用にその仕様にしたがったス
タック・クレームを生成する。つぎにステップ１３０は
基本的にパラメータの再マツピングを行う。いずれの場
合も、アルゴリズムはステップ１２８に進み、背景の機
能を呼び出す。背景の機能から戻るときにはアルゴリズ
ムはステップ１３２に進み背景機能からの一時的な戻り
コードをスタックに保持する。一般的にはこの戻りコー
ドはレジスタ５２の１つに返されてステップ１３２はス
タックにレジスタをストアするのに等しい。同一のレジ
スタが通常第５図のステップで変更される。

ステップ１３４においてグローバル・データはもう一部
ステップ１０４の場合のようにセット・アップされる。

なぜならレジスタが背景の機能により修正されているか
もしれないからである。プアー ロセス情報から呼び出しスレッドのＩＤ番号を取り出す
際にステップ１３６が実行される。これは基本的にステ
ップ１０８と同じである。アルゴリズムはステップ１３
８に進み、ここでステップ１３６で得た呼び出しスレッ
ドのＩＤ番号を用いてステップ１１８で先にセーブした
プロセッサ状態情報を再度見つける。すなわち当該情報
をプロセッサ・レジスタ５２にコピーして戻し、これに
よりプロセッサ状態を、機能が最初に開始された時点の
状態に戻す。ステップ１４０において、ステップ１２０
で得た呼者の戻りアドレスをスタック４８に再ストアし
なおし、またステップ１４２で制御を呼者に戻す。

Ｆ１発明の詳細 な説明したように、この発明によればソフトウェア・シ
ステムの各機能ごとに総括的なアプリケーション・プロ
グラム・インターフェースを用意し、これによって、種
々の言語で記述されたアプリケーションとソフトウェア
・システムとの間のインターフェースを簡易に行うこと
ができる。

【図面の簡単な説明】 第１図はこの発明の一実施例を示すブロック図、第２図
は第１図例を模式的に示すブロック図、第３図は第１図
例におけるシステム・プロセッサ・レジスタとメモリと
の間のやりとりを説明する図、第４図は第１図例の要部
を示す図、第５図〜第７図は第１図例の動作を説明する
フローチャートである。 １０・・・・プログラム・サービス、１２・・・・デー
タ・ベース・マネジメント・アプリケーション・プログ
ラム・インターフェース、１４・・・・総括的アプリケ
ーション・プログラム・インターフェース、１６・・・
・アプリケーション・プログラム、１７・・・・状態保
持テーブル、１８・・・・オペレーティング・システム
、２０・・・・オペレーティング・システム・アプリケ
ーション・プログラム・インターフェース 第１図 竿２図 スレッド１１１からの呼び出し用の プロセッサ状態 スレッド１１１２からのｌｌ’ｌ”び出し用のプロセッ
サ状態 スレ・ンドＩＩ　Ｎからの呼び出し用のプロセッサ状態 第４図

Claims (1)

1. 【特許請求の範囲】 異なるコンピュータ言語で記述されている複数のアプリ
   ケーション・プログラムをコンピュータ・ソフトウェア
   ・システムにインターフェースする方法において、 上記アプリケーション・プログラムからのプログラム呼
   び出しに応じて対応する総括的アプリケーション・プロ
   グラム・インターフェースを生成するステップと、 上記アプリケーション・プログラムからのプログラム呼
   び出しに応じて対応する総括的アプリケーション・プロ
   グラム・インターフェースから呼び出しを生成させるス
   テップと、 上記総括的アプリケーション・プログラム・インターフ
   ェースからの呼び出しに応じて上記コンピュータ・ソフ
   トウェア・システムの機能を実行するステップとを有す
   ることを特徴とするアプリケーション・プログラム・イ
   ンターフェース方法。