JPH10510649A - 計算機システムの起動システム - Google Patents

Abstract

(57)【要約】 複雑な計算機システムのプログラムシステムは非常にカスタマ固有であり、従って起動は非常に種々多様である。従ってこのような計算機システムの起動システムは非常に高い融通性を有しなければならない。他方、それにもかかわらず、複雑な起動に関する早期でかつ密なコントロールが保証されなければならない。これらの要求は、オフラインで本発明の方法で生成された起動テーブルを有する起動システムにより満足される。

Description

【発明の詳細な説明】 計算機システムの起動システム 例えば交換システム等の複雑な計算機システムの起動（リカバリ）において、 多数のプロセッサ及び大量のソフト（すなわち計算機システムのプログラムシス テム）が作動されなければならない。複雑な計算機システムのプログラムシステ ムは非常にカスタマ固有であるので起動が計算機システム毎に大幅に異なる。 従って今まで、カスタマ固有の起動を定める起動テーブルはダイナミックに生 成された。しかしこのダイナミック生成に起因して起動の設計は早期の時点では 不可能であった。更に、個々のソフトウェア部分の間の依存性は、テーブルがオ ンラインで完全に形成されると初めて認識することが可能である。 従って一方では、起動の全経過に関するより早期で強力なコントロールが望ま れ、他方ではしかし、起動に高い融通性を持たせて、すなわち異なるカスタマ固 有の起動プログラムシステムのために可変に保持することが望まれる。 更に全システムの起動が確実かつ迅速に行われるべきである。 本発明の課題は、前述の要求を満足することにある。 この課題は請求項１に記載の起動システムにより解決される。 テーブルのスタティックな生成により、起動の全経過にわたって早期で密なコ ントロールが可能になり、確実で迅速な起動が保証される。 早期にコントロールできるのでエラー（例えばデッドロック）が既にオンライ ンテストフェーズの前、すなわち既にリアルタイムシステムの実際の起動の前に 当該のツールにより認識され、補正することが可能である。 ある１つのソフトウェアコンポーネントのための起動関係（起動情報）をそれ ぞれそのソフトウェアコンポーネントの中で宣言することにより、スタティック に生成された起動テーブル（スタートアップテーブル）において、カスタマ固有 のプログラムシステムにそれぞれ存在するソフトウェアのみが考慮される。 更にこれにより起動の微細なユニット化と、ひいては変化及び／又は拡張に対 するＳＷコンポーネントの独立性又は融通性が促進される。 さらに、ＳＷコンポーネントの中での起動関係の宣言により起動ソフトウェア の部分の間の依存性が既に実際の起動の前に見ることが可能であり、これにより 起動全体の設計が容易化される。 本発明の１つの実施の形態は請求項２に記載されている。本発明のこの実施の 形態ではＳＷコンポーネン トのコンパイルの後に既に部分テーブルが存在し、この部分テーブルは（当該の ツールにより見えるようにされて）既に設計時においてコントロールすることが 可能である。 本発明の１つの実施の形態が請求項４に記載されている。この実施の形態によ りテーブルの中で、プラットフォームを越えて同期化を行うべきかべきでないか を定めることが可能となる。これにより、プラットフォームを越たシステム状態 を全システムの中で及びシステムの部分の中で定めることが可能にされる。従っ て１つのプラットフォームで、別の１つのプラットフォームで形成されたシステ ム状態を待つことが可能である。すなわちこれは、リアルタイムシステムの種々 異なる計算機におけるソフトウェアの種々異なる部分の間の依存性を簡単に既に 設計時において考慮することが可能であることを意味する。 本発明の１つの実施の形態は請求項５に記載されている。この実施の形態によ りユーザソフトウェアに関する起動が今までに比して大幅により微細になりかつ より高い融通性を有する。ユーザソフトウェアは、これが起動と何らかの関係を 有する場合にのみ実行される。従って起動はより迅速でありより安定している。 次に本発明の１つの実施の形態が図面を用いて詳細に説明される。 まず初めに、以下において頻繁に使用される表現の 説明が行われる。 起動（リカバリ）： エラーの発生の後、停電の後、作動開始の際等に、アプリケーションプログラ ムシステムの実行に適するハードウェア及びソフトウェア状態を形成するための 手段。 アプリケーションプログラムシステム（ＡＰＳ＝Ａｐｐｌｉｃａｔｉｏｎ Ｐ ｒｏｇｒａｍ Ｓｙｓｔｅｍ）： アプリケーションプログラムシステムは、例えば交換局の計算機システムで必 要とされるすべてのプログラム及びデータを含む（例外としてリアルタイムシス テムのイニシャルプログラムローダがある）。それぞれの複雑な計算機システム ごとに、個別のすなわち当該の計算機システムの使用に固有の構成に適合された アプリケーションプログラムシステム（カスタマ固有のＡＰＳ）が必要である。 アプリケーションプログラムシステムは、機械言語で既にバインドされているプ ログラムシステムである。 サービスプロビジョンユニット，カプセル： ソフトウェアはプログラミング言語レベルでユニットに構造化される。Ｃｈｉ ｌｌでは、互いに密な関係にあるユニットはより大きいＳＷ（ソフトウェア）コ ンポーネントいわゆるサービスプロビジョンユニット（Ｓｅｒｖｉｃｅ Ｐｒｏ ｖｉｓｉｏｎ Ｕｎｉｔ＝ＳＰＵ）に統合される。ＳＰＵは、それぞれコンパイ ラにより翻訳されるソフトウェアユニットである。カプセルは、リアルタイムシ ステムでロードすることが可能であり、アプリケーションプログラムシステムの 作成時にビルダによりサービスプロビジョンユニットから形成されるソフトウェ アユニットである。 ソフトウェアコンポーネントプール： ソフトウェアコンポーネントプールは、（ソースコード）ＳＷコンポーネント 全体を含む。これらコンポーネントのそれぞれ１つの部分がカスタマ固有ＡＰＳ の形成のためのコンパイルされ、共にバインドされる。 起動制御プログラム： 起動制御プログラムは起動を制御し、以下においてスタートアップ制御プログ ラム（略称ＳＵ−ＰＯ）とも呼称される。起動制御プログラムは、オペレーティ ングシステムモードすなわちスーパバイザモードで動作する起動部分（ＳＵＰＯ ＿ＳＹＮＣ）と、ユーザモードで動作しプロセスとして実現されている起動部分 （ＳＵＰＯ＿ＰＲＯＣＥＳＳ）とを含む。 まず初めに本発明の簡潔な説明が行われる。 本発明の基礎となる課題は、一方では、起動の全過 程にわたって早期かつ密な制御を獲得し、他方、起動全体を融通性を持たせて、 すなわちカスタマ固有のＡＰＳから独立して保持することにある。 この課題を解決するために、ＳＷ生産全体が新起動コンセプトの中に組込まれ る。既に設計時においてＳＷディベロッパは、別の同期点及び実行するアクショ ンに対する関係（条件及び寄与）の形での複数のＳＰ（サービスプロビジョン） を宣言しなければならない。これらの宣言は、ディベロッパによりそれぞれ設計 されたＳＷコンポーネントの中で行われる。 コンパイルによりＳＰ宣言から部分テーブルが形成される。 カスタマ固有のアプリケーションプログラムシステムの作成時にＳＷコンポー ネントをバインドすることにより、これらの部分テーブルはバインドされて最終 的に１つの分散配置されたテーブル（論理的観点からはただ１つのテーブル）を 形成する。このバインドは１つの特別のツールにより、別の複数のＳＰに対する 、ＳＷコンポーネント（サービスプロビジョンユニット又はより正確な表現では サービスプロビジョンユニットの中に含まれているユニット）の中で宣言された 関係に従って行われる。 このようにして起動制御プログラムは、オフラインで形成されバインドされた テーブルにアクセスし、これにより、テーブルの中に含まれている起動情報に従 って起動が実行される。 オフラインで形成された起動テーブルを用いて、起動制御プログラムをアプリ ケーションプログラムシステムのフィーチャから独立して保持することが可能と なる。従って起動制御プログラムは、起動自身が新しいフィーチャを得るべき場 合にのみ更に変化されなければならない。 アプリケーションプログラムシステムに関してアプリケーション制御プログラ ムは完全に独立している。この独立性は、起動同期化情報がアプリケーションプ ログラムシステムの個々のコンポーネント自身により設定され、オフラインで起 動制御テーブルに書込むことにより得られる。 起動によりリアルタイムシステムは１ステップづつ始動され、それぞれのステ ップは安定状態を表す。これらの状態は以下において同期点とも呼称される。こ れらの同期点のうちのいくつかは局所的意味しか有さず、これに対して別の同期 点はシステム範囲の意味を有する。意味範囲は、同期点を収容する記述レベルに 完全に依存する。 図１は、一例としての交換システムの起動セグメントの（階層）レベル、すな わちシステムレベル、機能レベル、アプリケーションレベル、及びユーザレベル を示す。 アプリケーションプログラムシステムの起動は、す べてのテーブル、すなわちすべての起動セグメントを利用して行われる。起動セ グメントの異なる階層レベルの中でそれぞれ記述の観点は異なる、すなわち最上 位置のレベルでは起動セグメントはシステム全体を記述するがしかし非常に大域 的に記述し、階層レベルを下方へ向かってより移動する程、記述はより詳細にな る。しかしそれぞれの起動セグメントの中で、記述されたソフトウェアの量は減 少する。最下位置のレベルではＳＰＵの個々のプロセスの相互作用のみが記述さ れるが、しかし完全に記述される、すなわちこの場合には個々のプロセスの間の 関係が分かる。 システムレベル（第１の段階）の中では個々のＳＷ機能複合体の相互作用は起 動の間に記述される。このレベルは、アプリケーションプログラムシステム全体 の起動を定める同期点を含む。このＳＰは原始ラスタを形成し、この原始ラスタ の中に残りのソフトウェアが組込まれる。 機能レベル（第２の段階）は、システムの重要な機能複合体、例えばハードウ ェアメンテナンス、ソフトウェアメンテナンス、ＣＣＳ７等に関するコンポーネ ントのための起動を記述する。これらは同じようにシステム範囲の意味を有する 。 アプリケーションレベルは、機能的コンポーネント（いくつかの機能的コンポ ーネントはこの時点でもまだ大域的意味を有する）のための起動を記述する。Ｃ ＣＳ７の場合にはこのような機能的コンポーネントのための例としてシグナリン グマネージャＳＭ及びシグナリングリンクターミナルＳＬＴを挙ることができる 。 プロセスレベル（階層レベル４）は、以下においてユーザＳＷとも呼称される 、アプリケーションプログラムシステムのプロセスソフトウェアのための起動を 記述する。プロセスレベルのためのコンポーネントのための例としてアプリケー ションデータベースＡＤＢ、ハイパーフォマンスデータベースＨＰＤＢ及びプロ トコルハンドラマネージャ（ＰＲＨマネージャ）を挙げることができる。 ＳＷコンポーネントのそれぞれの起動セグメントは同期点のリストを含み、そ れぞれの同期点は、起動情報（関係情報）から成る実質的に２つのクラスを含む 。 関係情報の一方のクラスはいわゆる”アクション”である。この”アクション ”は、同期点により表現されるシステム状態が到達されると直ちに、実行されな ければならないアクティビティを表現する。 関係情報の他方のクラスは、満足されなければならない”条件”である。 複数のＳＰ（サービスプロビジョン）の間の関係はそれぞれ次の２つの構成部 分を含む。 １） 一方のＳＰの中で、このＳＰ（一方のＳＰ）が他方のＳＰへの寄与を提供 することを記述する部分と、 ２） 他方のＳＰの中で、このＳＰ（他方のＳＰ）が一方のＳＰの条件を待たな ければならないことを記述する部分とである。 例えば２つのＳＰの間の関係を定めなければならない（ＳＰ＿ｘ及びＳＰ＿ｙ ）場合であって、ＳＰ＿ｘがＳＰ＿ｙの前に到達されなければならない場合、こ の関係のために次の２つの構成部分が存在する。 １） ＳＰ＿ｘにおいて、ＳＰ＿ｘがＳＰ＿ｙへの寄与を行わなければならない ことが記述されている（これはＳＰ＿ｘの”アクション”の中に記述されている ）。 ２） ＳＰ＿ｙにおいて、ＳＰ＿ｘがＳＰ＿ｙへの寄与を行わなければならない ことが記述されている（これはＳＰ＿ｙの”条件”の中に記述されている）。 関係情報の双方のクラス（アクション及び条件）は１つの混合から成る。すな わち双方のクラスは、プロセス関連の部分とセグメント関連の部分とを含む。 １） アクション： ａ） セグメント構成部分： − その他のＳＰへの寄与 ｂ） プロセス構成部分： − プロセスのスタート − サスペンドされたプロセスの続行 − （１つの通信毎の）プロセスの伝達 ２） 条件： ａ） セグメント構成部分： − その他のＳＰの寄与を”待つ” ｂ） プロセス構成部分： − プロセスの寄与を”待つ” ある１つの同期点に対するその他の同期点への関係情報は、この１つの同期点 の定義の中の当該のステートメントにより定められる。 複数の起動セグメント間の過度に複雑な関係構造を回避するために、１つのセ グメントの中に含まれているＳＰは、最大でも１つの階層レベルの段階差を有す るその他のセグメントの同期点のみにしか関係してはならない。 オペレーティングシステムにより管理されるプロセス（以下においてユーザプ ロセスとも呼称される）を起動の中に組込むためにユーザＳＷプログラマはまず 初めに、１つ又は複数のバインドするプロセスを含む サービスプロビジョンユニットの中の１つ又は複数の起動セグメントを定め、起 動セグメントを当該の結合ステートメント（関係ステートメント）によりアプリ ケーション階層レベルの起動セグメントに結合する。更にユーザは自分のプロセ スの関係をユーザ起動セグメントに対して指示しなければならない。このことは 、ユーザが自分のプロセスを通報することにより行われ、その際、通報情報はそ れぞれ１つのＳＰに関係されている。通報情報は、ユーザプロセスをスタートす るために複数のユーザ起動セグメントのうちの１つのユーザ起動セグメントの中 のいずれの同期点が利用されるかに関し、そしていずれの同期点のためにプロセ スが寄与を供給するかに関する情報を含む。 以下において起動テーブルの構造及び起動テーブルの中に含まれている情報が 詳細に説明され、次いでＳＵＰＯによる起動テーブルの利用が詳細に説明される 。 図２は１つのプロセッサの中の起動テーブルの構造を示す。 起動テーブルはプロセッサのＳＷプラットフォーム全体にわたり分散配置され 、それぞれのサービスプロビジョンユニットＳＰＵは、このサービスプロビジョ ンユニットのための起動に関連して重要である、起動情報の中の部分を含む。 起動テーブルへのアクセスはいわゆる”カプセルプ ロログ”及び”ＳＰＵプロログ”の中のアドレス情報を介して行われる。起動テ ーブルのセグメントは、いわゆる同期点セル（ＳＰセル）のテーブルを含み、そ れぞれのＳＰセルはセグメントの中の同期点を表す。ＳＰセルは、この同期点に 結合されている”関係”の記述を含む。図２は例として、３つの同期点を含むセ グメント（ｓｅｇｍｅｎｔ＿ｙ）が起動テーブルの中に表される構成を示す。 以下において、起動テーブルの中に含まれている起動情報が詳細に説明される 。 前述のように起動セグメントは、いわゆるＳＰセルの中の実際の起動情報すな わち同期点情報を含む、起動テーブルの中の単体である。 起動セグメントの宣言（定義）のために次のプログラミング言語手段より正確 にはデータ構造を利用することが可能である。 セグメントのアイデンティティーを定めるための”セグメント名称”というデ ータ構造。このデータ構造はカプセルアイデンティティー（カプセルＩＤ）、サ ービスプロビジョンユニットアイデンティティー（ＳＰＵ−ＩＤ）及びセグメン トアイデンティティー（セグメントＩＤ）から成り、セグメントアイデンティテ ィーはＳＥＴデータタイプのＳＥＴ値である。 起動階層の中の起動セグメントが所属する階層レベルを定めるのに用いられる ”セグメント段階”という データ構造。このデータ構造のタイプもＳＥＴタイプである。このデータ構造の 値すなわち階層レベルは、同期点情報の中で、１つより多い数の階層段階に関す る起動情報を供給する試みが行われなかったことを検査するために利用される。 起動状態とひいてはシステム状態を定めるために用いられる”同期点”という データ構造。このデータ構造は、”ＳＰ名称”、”条件”、”寄与”、”ＳＰの タイミング”、”外部ＳＰ”及び”アクション”に細分化されている。 データ構造”ＳＰ名称”はＳＰのアイデンティティーに用いられ、”ＳＥＴ” タイプである。 データ構造”条件”により、同期点が到達される前に満足されなければならな い条件が定めることが可能である。指示された条件は、プロセス又はその他の同 期点に関連することにより表現される。 指示された条件が、階層レベルの上昇方向での関係を形成するためにのみ許容 される（例えば階層レベル４の中のＳＰ（サービスプロビジョン）は階層レベル ３の中の同期点に関連することが可能である）。 データ構造”寄与”を介して、ＳＰに到達した後に少なくとも１つの別のＳＰ のために行われる寄与が定められることが可能である。寄与は”アクション”の 構成部分である。 換言すれば”より上の段階の”ＳＰのためのこれら の”寄与”は、より上の段階のＳＰが到達される前に、より下の段階が同期点に より形成されるか又は満足されなければならない条件を表す。 寄与は値上昇方向でのみ許容される（すなわち階層レベル３の中の同期点は階 層レベル２の中の同期点に関連することが許容される）。 複数のＳＰの間の関係は常に、前述の２つの構成部分、すなわち条件とアクシ ョンとから成る。関係の定義は常に、同期化相手方のうちの１つから行われる、 すなわち前述の例ではＳＰ＿ｘにおいて、ＳＰ＿ｘがＳＰ＿ｙに寄与を行いたい ことが記述されているか、又はＳＰ＿ｙにおいて、ＳＰ＿ｙがＳＰｘからの寄与 を待つことが記述されているかである。すなわち同期化関係の定義においてこの 定義はまだ完全ではなく、関係の半分が欠落している。この半分はＡＰＳ生産の 間にリンカ／オフラインビルダにより補足される。 起動の間の複数のＳＰの順序は、複数のＳＰの間の関係により定められる。１ つのＳＰを収容する、セグメント階層のレベルは全く重要でない。階層レベルは 、ＳＰ（及び起動セグメント）を構造化するためのみにしか必要でない、すなわ ちＳＰ及びそれらの関係の概観を失わないためにのみにしか必要でない。 従って１つのＳＰの別の１つのＳＰへの寄与により、この別の１つのＳＰの” 条件”によるものと完全に同一のことが達成される。従って同期化関係の定義に おいて自由度が得られる。この自由度は、”フィーチャ独立性”を達成されるた めに利用される。すなわち同期化関係は常に、セグメント階層の中で更に下方に 位置するＳＰにより定められる。前述の例において（ＳＰ＿ｘはより高い階層レ ベルの中に位置することを前提として）定義は次のようである。 ＳＰ＿ｙは”条件”（ｗａｉｔ＿ｆｏｒ）（すなわち”を待つ”）を定める、 すなわちＳＰ＿ｙは、ＳＰ＿ｘがＳＰ＿ｙの前に到達されなければならないこと を定める。 これら２つのそれらの作用において同一の言語手段”寄与”及び”条件”と、 自由度の利用とにより初めてスタートアップは”フィーチャ独立”になることが 可能である。 データ構造”Ｔｉｍｉｎｇ＿ｏｆ＿ＳＰ”（すなわち”ＳＰのタイミング”） は、１つの同期点から対の同期点に前進するためにセグメントに許容されている 最大時間間隔を表示する情報を含む。同期点が、この最大時間間隔により定めら れたタイマが終了しない前に到達されない場合、当該のエラー条件が当該のフラ グによりシグナリングされる。 データ構造”外部同期点”は、この同期点の局所的前提条件が満足されている ことを表示する情報がいわゆる親プラットフォームに伝送されるべきかどうかを 指示する。親プラットフォームは、所属の従属プラッ トフォームのメンテナンスアクティビティのコントロールを引受けるプラットフ ォームである。従ってこのデータ構造は、プラットフォーム全体に及ぶ同期化に 用いられ、従って同様に、同期点に関連して実行すべきアクションを形成する。 同期化情報は、親プラットフォームのみに伝送されるべきであり、すべての隣 接のプラットフォームに伝送されてはならない（これらの隣接プラットフォーム は個々の従属プラットフォームには全く知られておらず、初めて起動の間にロー ドされるＤＢからのみ読出すことが可能である）。 これまでは、起動セグメントの中で宣言可能な起動情報が説明され、以下にお いては、同期化された起動に関与するユーザプロセスのために重要である起動情 報が説明される。 プロセスのための起動情報の宣言は、プロセスが所属するＳＰＵ、すなわちＳ ＰＵの中でプロセスが宣言されたところのＳＰＵの中で定められている同期点に のみ関係することが可能である。 プロセスのための前述宣言はオフラインですなわちコンパイラ及び／又はバイ ンダにより処理され、これにより、起動テーブルの中に含まれる情報が生成され る。 次の宣言又はそれらから生成された起動情報が可能である。 プロセスのために宣言”Ｓｔａｒｔ＿ａｔ＿ＳＰ”（すなわち”ＳＰでスター ト”）により、いつ、すなわちいずれのＳＰに到達した時にプロセスをスタート すべきかを定めることが可能である。この宣言は、１つの同期点毎に存在し、こ のＳＰでスタートすべきプロセスをリストしているいわゆるスタートテーブルへ の書込みを行わせる。宣言は、スタートすべきプロセスを含むユニットの中で行 われる。 更にプロセスは、ある特定の同期点が到達されるまでこのプロセスの延期が所 望であることを指示する手段を有する。この手段はオペレーティングシステムコ ール”Ｗａｉｔ＿ｆｏｒ＿ＳＰ”（すなわち”ＳＰを待つ”）の宣言により実現 され、オペレーティングシステムコール（略称ＳＶＣ）は引渡しパラメータとし てある特定のＳＰの情報を含まれなければならない。 更にプロセスは、（そのＳＰＵの中の）ある特定の同期点が到達された時に通 報されることを要求できる。これは２つの部分で実現される。 第１の部分（スタティック部分）は宣言により作用され、この宣言に起因して オフラインで、１つのＳＰ毎に存在する”ウォッチテーブル”の中への書込みが 行われ。ウォッチテーブルはプロセスのウォッチ要求を受取る。宣言は、スター トすべきプロセスを含むユニットの中で行われる。 第２の部分（ダイナミック部分）はオペレーティン グシステムコール”Ｗａｔｃｈ＿ｆｏｒ＿ＳＰ”（すなわち”ＳＰをウォッチす る”）の宣言により、要求するプロセス自身の中で作用される。 最後に、プロセスは、そのスタートの後に同期点への寄与を供給でき、オペレ ーティングシステムコール”Ｃｏｎｔｒｉｂｕｔｅ＿ｔｏ＿ＳＰ”（すなわち” ＳＰに寄与する”）の宣言により、その寄与が行われた後、寄与が満足されたこ とを指示できる。これも２つの部分で実現される。 第１の部分（スタティック部分）は宣言により作用され、この宣言に起因して オフラインで、１つのＳＰ毎に存在する”寄与テーブル”への書込みが行われ、 寄与テーブルはプロセスの寄与指示を受取る。宣言は、スタートすべきプロセス を含むユニットの中で行われる。 第２の部分（ダイナミック部分）はオペレーティングシステムコール”Ｃｏｎ ｔｒｉｂｕｔｅ＿ｔｏ＿ＳＰ”により、指示されたプロセス自身の中で作用され る。 ”Ｃｏｎｔｒｉｂ ｔｏ”において次の２つの部分が論理的に必要である。 − アナウンスメントテーブル（スタティック部分，宣言）により、所属のＳＰ がプロセスの寄与を待つことが作用される。 − オペレーティングシステムコール”Ｃｏｎｔｒｉｂｕｔｅ＿ｔｏ＿ＳＰ”に よりプロセスは（プロセスが必要なアクションを実行した後）ＳＰへのその寄与 を行う、すなわちオペレーティングシステムコールによりプロセスはスタートア ップに、ＳＰのためのその条件が満足されていることを通報する。 − これに対して”Ｗａｔｃｈ Ｆｏｒ”のこれら２つの部分は論理的に必要で ない、これら２つの部分は、情報を伝送するのに用いられるバッファＩＤがオフ ラインで知られていない場合にのみ必要である。このここで仮定されている場合 にはこれら２つの部分がスタートアップにオンラインで伝達されなければならな い。このためにスタティック部分は、スタートアップに必要な場所のみをリザー ブし、これにより（オフラインで知られていない）バッファＩＤが書込まれれる ことが可能となる。 次に起動制御プログラムの機能ＳＵＰＯ＿ＳＹＮＣ及びＳＵＰＯ＿ＰＲＯＣＥ ＳＳが詳細に説明される。 起動制御プログラムは（前述のように）起動テーブルを使用して起動を制御す る。より正確には起動制御プログラムは、起動制御プログラムがＳＰセルを１つ の状態から他方の状態へ移行することにより、同期化された起動を制御する。 ＳＰの処理は、ＳＰが収容されている階層レベル及びシェルから独立している 。 ＳＵＰＯ＿ＳＹＮＣとＳＵＰＯ＿ＰＲＯＣＥＳＳとの間の区別は、ＳＰに付加 されている課題に起因して必要である。すべてのＳＰのための同一の課題は常に 同一のＳＵＰＯ部分により実行される。 ＳＰの処理はほぼ完全にＳＵＰＯ＿ＳＹＮＣにより行われる。ＳＵＰＯ＿ＳＹ ＮＣは、条件が満足されているかどうかを検査し、場合に応じて（”ｒｅａｄｙ −ｐｏｏｌ”（レディープール）の中への新”仕上り”ＳＰセルの書込みを含む ）アクションを実行する。 ＳＵＰＯ＿ＰＲＯＣＥＳＳは、ＡＰＳのシェル３の中で実行可能である次の課 題のみを引受ける。 − ＳＰを時間監視する。 − 外部ＳＰの場合に親プラットフォームへ情報を伝達する。 − スタートアップテーブルの初期化をトリガし、同期化メカニズムをスタート する。 図３は、ＳＰセルがとることができる３つの状態と、ＳＰセルを１つの状態か ら次の状態へ移行する方法とを示す。 起動方法全体は、第１のＳＰセルが実行のために仕上げられる、すなわち”レ ディ”状態に移行されるこ とにより初期化される。これは例えば特別インターフェースを介して行うことが 可能である。 ＳＰの間の関係に起因してただ一度だけ”第１の”ＳＰ”が”レディ”にされ るだけでよい、すなわちそれぞれのＳＰＵの中で第１のＳＰが”レディ”にされ る必要はない（そしてしてはならない）。むしろ、”第１のＳＰ”とその他のＳ Ｐとの関係に起因してこれらその他のＳＰは自動的に”レディ”となる、何故な らば”第１のＳＰのアクションはその他のＳＰへの寄与を含み、その他のＳＰは 寄与に起因して”レディ”にことが可能であるからである。添付の図（図４）に おいて”第１のＳＰ”は”ＳＰＵ５”の中の第１のＳＰである。 図４はプロセスレベルを組込での例としての起動を示す。 プロセスが寄与を行う場合には常にＳＵＰＯ＿ＳＹＮＣは、（プロセスがその 寄与を行う）所属のＳＰのすべての条件が満足されている（すなわちメカニズム がイベント制御されている）かどうかを検査する。 ＳＰのすべて条件が満足されている場合、（まだＣｏｎｔｒｉｂｕｔｅ＿Ｔｏ ＿ＳＶＣの中のＳＵＰＯＳＹＮＣにより）ＳＰのアクションが次のように実行さ れる。 − なかんずくプロセスがスタートされる。 − 情報がプロセスに伝送される。 − 延期されたプロセスが再びトリガされる。 − その他のＳＰへの寄与が行われる。 これらのアクションに起因してまだＣｏｎｔｒｉｂｕｔｅ＿Ｔｏ＿ＳＶＣの中 で更なるＳＰが（寄与が行われるＳＰのために寄与の後にすべての条件が満足さ れている場合には）”レディ”になる。これらのＳＰのアクションもまだＣｏｎ ｔｒｉｂｕｔｅ＿Ｔｏ＿ＳＶＣの中で実行される（以下同様）。 ”レディ”であるすべてのＳＰのアクションが実行された後、このＣｏｎｔｒ ｉｂｕｔｅ＿Ｔｏ＿ＳＶＣは終了される。スタートするプロセスが（オペレーテ ィングシステムすなわちスーパバイザにより）選択される。 前述のようにそれぞれのＳＰは、ＳＰが”レディ”となる前にいずれの条件が 満足されなければならないかに関する情報を含む。これらの条件は２つの部分か ら成る。 − 前もって到達されなければならない複数のＳＰ。 この情報は（当該のＳＰが、より高い階層レベルの中の１つのＳＰを待つ場合 には）直接に当該のＳＰにおいて定められるか、又は（より低い階層レベルの１ つのＳＰが、前に到達されなければならないと定め ている場合には）リンカ／オフラインビルダにより生成される。 − プロセスの寄与： 起動の間の実際の作業はプロセスが行う。従ってこれらのプロセスの寄与はと りわけ重要である。 既に１６）に記載のようにプロセスの寄与は２つの部分から成る。すなわちス タティック部分とダイナミック部分とから成る。スタティック部分は、所属のＳ Ｐが、このＳＰがある特定のプロセスの寄与を待たなければならないことを”知 っている”ためのみにある。 ＳＰセルは”ｎｉｃｈｔ＿ｂｅｒｅｉｔ＿Ｐｏｏｌ”（すなわちｎｏｔ−ｒｅ ａｄｙ−ｐｏｏｌすなわち非レディープール）”から”ｂｅｒｅｉｔ＿Ｐｏｏｌ ”（すなわちｒｅａｄｙ−ｐｏｏｌすなわちレディ−プール）へ、次のイベント ａ）及びｂ）のうちの１つのイベントの結果として移行される。 ａ） ＳＵＰＯ＿ＳＹＮＣは、セグメントレベルで”ｎｉｃｈｔ＿ｂｅｒｅｉｔ ＿Ｐｏｏｌ”の中にあるＳＰへの寄与を行う。この寄与を処理した後にＳＵＰＯ ＿ＳＹＮＣは、同期点のすべての条件が満足されているかどうかを検査する。イ エスの場合、ＳＵＰＯ＿Ｓ ＹＮＣはＳＰセルを”ｂｅｒｅｉｔ＿Ｐｏｏｌ”に移行する。 ｂ） １つのプロセスが、起動にとって重要であり従ってスタートアップテーブ ルの中の前述の宣言（すなわちテーブルアナウンスメントすなわちプロセス寄与 のスタティック部分）を介してもある特定のＳＰのための条件となっている課題 を処理する。 この課題を処理した後にプロセスは、前述のアクションが起動しているＣｏｎ ｔｒｉｂｕｔｅ＿Ｔｏ＿ＳＶＣ”をコールする。 ＳＰセルを”レディ”状態から”終了”状態への移行は、ＳＵＰＯ＿ＳＹＮＣ により制御されるアクションにより達成される。 同期点に関連して次のアクションが実行されることが可能である。 − スーパバイザの同期点に関連してスタートされなければならないプロセスの リスト。 − 別のＳＰセルへ行われなければならない寄与。 − 待ち行列の中で、この同期点が到達されることを待っているプロセスのリス トが再び”ｒｅａｄｙ ｔｏ ｒｕｎ”（すなわち”ランのためにレディ”）待 ち行列の中に入れられる。 − 標準情報が、この同期点が達成された時に伝達さ れることを望むすべてのプロセスのバッファに伝送される。 − １つのセグメントのＳＰセルがＳＵＰＯにより”ｂｅｒｅｉｔ＿Ｐｏｏｌ” （ｒｅａｄｙ−ｐｏｏｌ）の中に動かされる。（同一のセグメントの中の次の同 期点のすべての条件が満足されるとこのセグメントの次の同期点は、実行される ためにレディとなり、この同期点は”ｒｅａｄｙ−ｐｏｏｌ”の中に動かされる 。 同期点のすべての前述のアクションが実行されるとＳＰセルの中で当該のフラ グが設定される。 総括的に述べると、ＳＵＰＯ＿ＳＹＮＣがＳＰセルを”レディ”状態から”終 了”状態に移行することを作用し、この作用は、ＳＵＰＯ＿ＳＹＮＣがＳＰセル をｒｅａｄｙ−ｐｏｏｌから取出すことにより実現される。”ｒｅａｄｙ ｐｏ ｏｌ”の中のすべてのＳＰが到達され、すべてのこれらのＳＰのアクションは実 行されなければならない。 実際にはプールはＳＰセルのチェーンとして実現されている。処理の際にチェ ーンの中で前のＳＰから開始され、常に新の中の次のＳＰが処理される。新ＳＰ は後部でチェーンの中に組込まれる。従って、すべてのＳＰが処理されることが 保証される。 更に実際には”ｎｏｔ ｒｅａｄｙ ｐｏｏｌ”は存在せず、”ｂｅｅｎｄｅ ｔ＿Ｐｏｏｌ”（”ｆｉｎ ｉｉｓｈｅｄ ｐｏｏｌ”すなわち”終了プール”）も存在しない。これらのプ ールはＳＰセルの中のフラグにより置換され、フラグは、ある１つのＳＰのため のいくつの条件がまだ欠落しているか、又はある１つのＳＰのアクションが既に 処理されたかどかを指示する。 ｂｅｒｅｉｔ＿Ｐｏｏｌ（ｒｅａｄｙ ｐｏｏｌすなわちレディプール）の中 にＳＰセルがもはや存在しないと、ＳＵＰＯ＿ＳＹＮＣは何等の作業も有せず、 ユーザプロセスがオペレーティングシステムコール”Ｃｏｎｔｒｉｂｕｔｅ ｔ ｏ ＳＰ”を用いてＳＰセルをレディプールに移行するのを待たなければならな い。 外部的意味を有する同期点が到達されると、ＳＵＰＯ＿ＳＹＮＣは、この同期 点に結合されているアクションを直ちに実行するのではなく、ＳＵＰＯ＿ＰＲＯ ＣＥＳＳに作用し、これによりＳＵＰＯ＿ＰＲＯＣＥＳＳは情報を親プラットフ ォームに伝送し、この情報により親プラットフォームに、当該のＳＰが、情報を 伝送するプラットフォームですなわち局所的面で到達されたことが支持される。 同時にＳＵＰＯ＿ＳＹＮＣは、この同期点に結合されているアクションの実行を 、親プラットフォームによりＳＵＰＯ＿ＰＲＯＣＥＳＳを介して情報”ＳＰ大域 的に到達された”が受信さ れるまで遅延する。 外部同期点は２つの仮想同期点から成ると見なすことが可能であり、これは図 ５に示されている。 Ｓｅｇｍｅｎｔ＿ａの中の第１の仮想同期点は、当該の同期点に関連して同期 点のすべての（局所的）条件と、ただ１つのアクションすなわち情報（”ＳＰが 局所的に到達された”）を親プラットフォームに伝送することとを含む。 第２の仮想同期点は、情報”ＳＰが大域的に到達された”が親プラットフォー ムにより受信されたとのただ１つの条件を含み、更に、当該の同期点のすべての 残りの（局所的）アクションを含む。 次に、ユーザプロセスの起動に対するオペレーティングシステムコール（ｓｕ ｐｅｒｖｉｓｏｒｙ ｃｏｌｌｓ，略称ＳＶＣ）が詳細に説明される。 オペレーティングシステムすなわちスーパバイザによりスタートされたすべて のプロセスは、何時にすなわちいずれの同期点でこれらのプロセスがスタートさ れることを望むかを表明しなければならない。この同期点が到達されると直ちに 、この同期点でスタートすべきプロセスはＳＵＰＯ＿ＳＹＮＣによりスタートさ れる。ＳＵＰＯ＿ＳＹＮＣは１つのプロセスタイプのすべての具現をスタートす る。 ユーザプロセスにより行われるオペレーティングシステムコール”Ｃｏｎ ｔｒｉｂｕｔｅ＿ｔｏ＿ＳＰ”は、第一に、セグメン トと、寄与が行われるべき（同様にプロセスを含むＳＰＵの中の）同期点を指示 し、第二に、寄与がポジティブであるか又はネガティブであるか、すなわち寄与 を実行することが可能であったか又はエラーが発生したかを指示するパラメータ を有する。 ＳＵＰＯ＿ＳＹＮＣはそのコールの後にセグメント名称及び指示された同期点 を利用し、これにより、寄与が行われるべき当該ＳＰセルにアクセスすることが 可能となる。次いでＳＰセルはタイムスタンプを得、これにより、寄与が行われ たことと、何時に寄与が行われたかが指示される。ＳＰセルにより予測されるす べての寄与が行われるとＳＰセルは、実行されるためにレディである、すなわち 、同期点と結合されているアクセスが実行されるためにレディである。これは、 ＳＰセルがＳＵＰＯ＿ＳＹＮＣによりレディプールに移行されることにより表さ れる。その直後に、すなわち同一のコールの枠内で、同期点に結合されているす べてのアクションはＳＵＰＯ＿ＳＹＮＣのコントロールの下に実行される。 オペレーティングシステムコール”Ｗａｉｔ＿ｆｏｒ＿ＳＰ”はユーザプロセ スにより実行され、これによりユーザプロセスはある特定の同期点に到達するま で自身を延期する。オペレーティングシステムコールは、セグメントと（固有の ＳＰＵの中の）同期点を指示するパラメータを有する。 オペレーティングシステムコールの実行もＳＵＰＯにより行われ、ＳＵＰＯは 、オペレーティングシステムすなわちスーパバイザにより認可されたルーチンを 利用し、これにより、延期されたプロセス（より正確にはプロセスコントロール ブロック、略称ＰＣＢ）が、スーパバイザカプセルの中の対応するリストに結合 される。リスト場所も、同期点に結合される。同期点が到達されるとプロセスが リストから取出され、”Ｒｅａｄｙ ｔｏ ｒｕｎ”状態に移行される。同期点 が既に到達された場合、オペレーティングシステムコールが実行されると、オペ レーティングシステムコールをトリガするプロセスは勿論延期されない。 オペレーティングシステムコール”Ｗａｔｃｈ＿ｆｏｒ＿ＳＰ”（すなわち” ＳＰをウォッチする”）は、ユーザプロセスが、到達された同期点に関して通報 することを望む場合にユーザプロセスにより実行される。このオペレーティング システムコールは、ＳＵＰＯにユーザプロセスのバッファ識別子に関して通報す るために必要である、何故ならばバッファ識別子はＡＰＳ（すなわちアプリケー ションプログラムシステム）の生産時間において知られていないからである（バ ッファとひいてはプロセスのバッファ識別子とは走行時間において初めて生成さ れる）。 オペレーティングシステムコールは次のパラメータを有する。 − セグメントと、ユーザプロセスが通報される（固有のＳＰＵの中の）同期点 。 − ユーザプロセスのバッファ識別子。 − ユーザプロセスに、同期点が発見されたかどうか、そして、同期点に到達さ れるとメッセージを受信するバッファ識別子のリストのバッファ識別子が添付さ れることができたかどうかを指示する応答パラメータ。応答がノーの場合、同期 点に到達されたことを指示する情報はユーザプロセスに伝送されない。 次に起動のオフライン支援のためのツールが詳細に説明される。 − 起動セグメントとその中に収容すべき起動情報とが適切に宣言されることを 可能にする宣言手段（定義手段）。 − 定義手段により記載されている起動情報を用いて、ＳＵＰＯ（すなわちスタ ートアップ制御プログラム）に適する起動テーブルを生成するテーブル生成手段 。 前述の定義手段は既に詳細に説明されたので、以下にテーブル生成手段が詳細 に説明される。 起動テーブルを、ある１つのプロセッサに対して定 められたサービスプロビジョンユニットから生成するためにコンパイラはまず初 めに、サービスプロビジョンユニットの中に含まれるセグメントから部分起動テ ーブル（セグメントテーブル）を生成する。この目的のためにＳＰＵ（すなわち サービスプロビジョンユニット）とユーザユニットの特別のコンパイルシーケン スとが必要である。更にコンパイラはサービスプロビジョンユニットのセグメン トテーブルをＳＰＵプロログとバインドする。 異なるセグメントの間の関係はリンカ及びオフラインビルダにより形成される 。この場合、セグメントテーブルに、これに関して必要な情報が付加される。 前述のテーブル生成手段に起因して起動テーブルは既に、最後のＡＰＳ（アプ リケーションプログラムシステム）ロード生成の前に使用可能である。従って起 動の全経過は既にこの時点で当該検査ツールにより検査される。この検査手段は 例えば起動テーブルをコンシステンシー（デッドロック等）に関して検査し、全 経過の中のクリティカルなパスに関して解析を実行し、ボトルネック及びクリテ ィカルなタイムパスを識別する。これにより（全）起動テーブルを早期に最適化 することが可能である。 最後に、指示手段を用いて、対応する起動プランの形の（全）起動テーブルが ディベロッパに見えるようにすることが可能である。これによりディベロッパは エラーを容易に発見することが可能である。

Claims (1)

1. 【特許請求の範囲】 １． プログラムシステム（ＡＰＳ）の起動を定める少なくとも１つの起動テ ーブルと、 前記起動テーブルの中に含まれる起動情報を用いて起動を制御する起動制御プ ログラム（ＳＵＰＯ＿ＳＹＮＣ，ＳＵＰＯ＿ＰＲＯＣＥＳＳ）とを有する計算機 システムの起動システムにおいて、 前記起動テーブルをオフラインで起動情報から作成し、該起動情報は前記プロ グラムシステムのソフトウェアコンポーネント（ＳＰＵすなわちサービスプロビ ジョンユニット）の中で前記起動テーブルの設計時に宣言されている、 ことを特徴とする計算機システムの起動システム。 ２． 前記起動テーブルは、複数の部分起動テーブルから成るテーブルであり 、 部分テーブルをそれぞれ、ソフトウェアコンポーネント（ＳＰＵ）の起動に対 する宣言のコンパイルにより生成する、請求項１記載の計算機システムの起動シ ステム。 ３． 種々異なる部分テーブルを、プログラムシステムの作成のために設けら れているプロダクトツールにより１つの完全なテーブルに統合する、請求項１又 は請求項２記載の計算機システムの起動システム。 ４． テーブルの中で、１つの条件を満足するため に同期化をプロセッサ限界を越えて実行すべきであるか否かを設定する、請求項 １から請求項３までのいずれか１に記載の計算機システムの起動システム。 ５． ユーザソフトウェアもテーブルを用いてその起動自体を定義することが 可能である、請求項１から請求項４までのいずれか１に記載の計算機システムの 起動システム。 ６． テーブルが第一にシステム状態（ＳＰ）を所定の順序で定め、第二にそ れぞれの前記システム状態に到達した後に実行すべきアクションを定め、このこ とによって起動を定める、請求項１から請求項５までのいずれか１に記載の計算 機システムの起動システム。 ７． 満足されるとシステム状態が到達されたと見なされる条件（Ｃｏｎｄｉ ｔｉｏｎ，Ｃｏｎｔｒｉｂｕｔｉｏｎ）をテーブルが定め、このことによってシ ステム状態を定める、請求項１から請求項６までのいずれか１に記載の計算機シ ステムの起動システム。 ８． 計算機システムの起動を定める方法において、 計算機システムのコンポーネントプールのソフトウェアコンポーネントの中で 、前記ソフトウェアコンポーネントの設計時に、ソフトウェアコンポーネントを 計算機システムの起動全体へバインドするための起動関係を宣言し、 前記コンポーネントプールから前記計算機システムのカスタマ固有のプログラ ムシステムのために選択されたソフトウェアコンポーネントに基づいてオフライ ンで、リアルタイムシステムの起動全体を定める起動テーブルを作成し、 当該起動テーブルを起動制御プログラムがオンラインで使用して起動を制御す る、 ことを特徴とする方法。