JPH01161531A - プログラム・パッケージの作成方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 以下の順序で本発明を説明する。

Ａ、産業上の利用分野 Ｂ、従来技術 Ｃ０発明が解決しようとする間Ｈ煮 り０問題点を解決するための手段 Ｅ、実施例 Ｆ０発明の効果 Ａ、産業上の利用分野 この発明は、データ処理技術の分野に関するものであり
、より詳しくは、ソフトウェアが、多重レベル階層形式
で構成された複数の置換可能なユニットから成っている
場合のコンピュータ・ソフトウェアのためのパッケージ
ング構造に関するものである。

Ｂ、従来技術 データ処理技術は、ユーザーがコンピュータに、きわめ
てわずかの人的介入でその資源を管理することを期待す
るところまで発展してきた。そして、自動構成化や問題
決定手続を通じてコンピュータ・システムのハードウェ
ア部分を管理するための研究は多くなされてきたが、コ
ンピュータのソフトウェア部分を効果的に管理すること
はほとんど研究されていない。

最近の典型的ユーザーは、特定のアプリケーションを実
行するために異なる複数のプログラムを必要とする。こ
れらのプロゲラふは多くの場合具なるプログラム開発者
によって作成されている。

しかし、各プログラムは、ハードウェアとソフトウェア
の両方に依存する要因をもち、ユーザーなリプログラム
開発者なりが、これらのすべての要因が満たされるよう
な統合されたシステムを組立てることがますます困難に
なりつつある。さらに、正しく動作するべくある保守ま
たはリリース・レベルを保つために、１つのソフトウェ
アが他のソフトウェアに依存することがある。多くの場
合、ユーザーがこの依存性の問題を匡正する唯一の方法
は、試行錯誤、あるいは多数の参照マニュアルを労力を
費してめくることである。

ソフトウェアの構造は、しばしば各プログラム開発者の
スタイルとその場の思いつきにまかされるものであって
、２つのプログラムが同一・の作成者によって開発され
た場合ですらも、一方のプログラムが、他方のプログラ
ムについての保守レベルや依存パラメータなどの情報を
容易に見出すことができるように２つのプログラムが一
貫した構造をもつことは稀である。

プログラム開発者とユーザーが最近直面する他の問題と
しては、プログラムが常に、訂正すべきエラーを含んで
いるということがある。通常、プログラム開発者はそれ
らのエラーを直すために、各ユーザーに全く新しいプロ
グラムを送付しなくてはならず、問題のある小部分のコ
ードのみを取り替える有効な方法はないのである。

アプリケーション開発者の仕事は今日複雑さを増してい
る。すなわち、ユーザーがアプリケーション開発者に、
自己の特定の要求に適うようにアプリケーション・パッ
ケージを作成するように要望するとき、アプリケーショ
ン開発者は、ユーザーの要求を満たすように複数の異な
るプログラムを結合し、それでいて将来の機能拡張のた
めの柔軟性を用意しておくという問題に遭遇することが
ある。多くの場合、アプリケーション開発者は、ユーザ
ーが要求しない機能を実行したり、ユーザーが要求する
すべての機能を実行する訳ではない汎用プログラムの高
価な非構造化集合体で満足するよりない。さらに、汎用
プログラムの集合体は、ユーザーが使用しない機能を記
憶することによって、必要以上のメモリを非効率にも使
用してしまう。　このことは、メモリを使い切ってしま
って、コンピュータ上にそれ以上の必要なプログラムを
記憶することのできないユーザーには特に隨事である。

プログラム開発者が、ユーザーに、自らが開発したプロ
グラムに満足してもらいたがっているのは明らかである
。しかし、個々のユーザーすべての要求をみたすように
仕立“ζられたプログラムを開発することは現在ではあ
まりにコストかがかりすぎる。プログラム開発者は、プ
ログラムのすべての機能を必要とするユーザーから、そ
の１つの機能しか必要としないユーザーまでのすべての
ユーザーの要求をみたすようなプログラムを開発しよう
と望んでいることだろう。もしこれを行うことができれ
ば、プログラム開発者は各ユーザーに、必要な機能の分
だけの料金を課せばよくなる。そして、ユーザーの要求
が増大しても、追加の料金を払うだけで、ユーザーに同
一のプログラムの追加の機能が与えられる。

Ｃ０発明が解決しようとする問題点 本発明の目的は、データ処理システムにおいて、ソフト
ウェア・プログラムの効率的管理を可能ならしめること
にある。

本発明の他の目的は、アプリケーション・パッケージが
、多重レベル階層様式で構成された複数の交換可能なユ
ニットからなるような場合にコンピュータ・ソフトウェ
アのためのパッケージング構造を与えることにある。

本発明のさらに他の目的は、アプリケーション・パッケ
ージがその階層構造の一体的部分として自己識別レベル
、保守レベル、及びハードウェアとソフトウェアに対す
る依存性を含むようにすることにある。

本発明のさらに他の目的は、プログラム開発者がプログ
ラム・パッケージを構築するために使用することができ
、アプリケーション開発者がアプリケーション・パッケ
ージを構築するために使用することができるパッケージ
ング・ツールを提供することにある。

Ｄ０問題点を解決するための手段 ソフトウェア・アプリケーション・パッケージは、リン
クされた複数の交換可能なユニット（ＲＵ）からなる。

各ＲＵは、他のＲＵに悪影響を及ぼすことなくサービス
可能である。ＲＵは、一連のレベルで階層的に配列され
ている。好適な実施例では、次の５つのレベルが使用さ
れる：アプリケーション・グループ・レベル（ＡＧ）　
、ロード可能コード・グループ・レベル（ＬＣＧ）、主
要機能グループ・レベル（ＰＦＧ）、２次機能グループ
・レベル（ＳＦＧ）、及びオペレーショナル・コード・
グループ・レベル（ＯＣＧ）。ＡＧレベルは、ユーザー
の要求を満たすように仕立てられ、た高レベル・アプリ
ケーションを実行するように結合されたコンピュータ・
プログラムのグループである。ＬＯＧレベルは、めいめ
いが汎用タスクを実行するように作成された個々のプロ
グラムを定義する。ＰＦＧレベルは、ＬＯＧレベルで定
義された共通プログラムを、より特定の主要な機能のセ
ットまで絞ったものである。ＳＦＧレベルは、ＰＦＧレ
ベルで定義された主要機能を、特定のユーザーの要求に
より緊密に合致するように仕立てられた特殊化された２
次機能のセットまで絞ったものである。ＯＣＧレベルは
、上記４つのレベルによって定義された特殊化されたユ
ーザー・アプリケーション・パッケージを実行するため
に必要なオペレーショナル・コードを含む。

ＡＧ　　ＲＵは１つまたはそれ以上のＬＣＧ　　ＲＵに
リンクし、各ＲＣＧ　　ＲＵは１つまたはそれ以上のＰ
ＦＧ　　ＲＵにリンクし、各ＰＦＧ　　ＲＵは１つまた
はそれ以上のＳＦＧ　　ＲＵにリンクし、各ＳＦＧ　　
ＲＵは１つまたはそれ以上の０ＣＧＲＵにリンクする。

このようにして、５つのレベルの階層構造が決定される
。

各ＲＵは、ヘッダ部分とボディ部分からなる。

各ＲＵのヘッダは、レベルに拘らず、自己識別情報と保
守情報を含み、またそのＲＵに固有のハードウェア及び
ソフトウェア従属性のリストを含むこともできる。ＡＣ
，ＬＣＧ、ＰＦＧ及び５ＦＧＲＵのボディは、追加の自
己識別及び保守情報に加えて、階層的チエインの一部を
なす次レベルのＲＵのリストを含む。ＲＵに含まれる自
己識別メンテナンス及び従属性情報は、必須製品データ
（ＶＰＤ）としても知られる。ＯＣＧレベル上の各ＲＵ
のボディは、プログラムを走らせるために使用されるオ
ペレーショナル・コードヲ含ム。

ソフトウェアの階層構造、ＲＵの交換可能な性質、及び
ＲＵに含まれる自己識別、メンテナンス及び従属性情報
により、ソフトウェアが高度に精巧化されることが可能
となる。この構造化されたソフトウェアは次に、前述し
たような多くのデータ処理に関連する問題を解決するた
めに使用することができる。

プログラム開発者は、ＬＣＧ、、ＰＦＧＳＳＦＧ及びＯ
ＣＧという４つのレベルにパッケージされたプログラム
を作成するために本発明のプログラム・パッケージング
・ツールを使用することができる。また、アプリケーシ
ョン開発者は、アプリケーション・パッケージを作成す
゛るべくこれらのプログラム・パッケージのいくつかを
結合するために、本発明のアプリケーション・パッケー
ジング・ツールを使用することができる。このことは、
選択されたプログラム・パッケージの４つのレベルの頂
点にＡＣレベルを追加することによって行なうことがで
きる。さらに、アプリケーション開発者は、選択された
プログラム・パッケージの主要（１次）及び２次機能を
選択して、残りの主要及び２次機能を省略することがで
きる。本発明のパッケージング構造及・びパッケージン
グ・ツールは、アプリケーション開発者に、特定のユー
ザーの要求をみたすように仕立てられたアプリケーショ
ン・パッケージを作成するための力と柔軟性を与える。

このロード可能なコード階層構造は、マイクロコードや
、市販プログラムや、ユーザーが開発したアプリケーシ
ョンなどの異なるロード可能なコードのタイプのものを
、各ロード可能コード・タイプに個別化されたツールの
組ではなく、共通の管理ツールの組を使用して管理でき
る点で、さらに別の恩恵を与えるものである。この能力
が存在子るのは、各コード・タイプのパッケージング構
造が類似するからである。

Ｅ、実施例 第１図は、本発明の環境を示すものである。この図にお
いて、プログラム開発者２１ないシ２４は、本発明に基
づくパッケージング構造に従いパッケージされたプログ
ラムを開発する。尚、そのパッケージング構造について
は後で詳しく説明する。プログラム開発者２１ないし２
４は通常、互いに独立に作業を進め、多くの場合他のプ
ログラム開発者と協力して完成する。尚、第１図には４
人のプログラム開発者しか示されていないが、本発明の
パッケージング構造に従うなら、数千人もの人々が全世
界でプログラムを開発し、プログラム開発者であること
ができる。

プログラム開発者２１ないし２４によって開発されたプ
ログラムはライブラリ３０中に配置される。ライブラリ
３０は、プログラム開発者３０によって開発されたすべ
てのプログラムの集合をあられす。例えば、ライブラリ
３０は、オペレーティング・システム・プログラム、ワ
ード処理プログラム、スプレッドシート・プログラム、
ゲーｌドブログラム、教育プログラム、通信プログラム
、出版プログラムなどを含むことができる。各プログラ
ムは主要（１次）機能及び２次機能を実行するが、これ
については後述する。ライブラリ３０にはプログラム３
１ないし３５が含まれており、これは第２図で詳述する
。

アプリケーション開発者２６は、ライブラリ３０中のプ
ログラムを取り出して、特定のユーザーの要求に適合す
るように仕立てられたアプリケーション・パッケージを
作成するために、それらをパッケージし直す。ユーザー
が必要とするプログラムは、１つのアプリケーション・
パッケージのもとで結合されて、そのアプリケーション
・パッケージがユーザーに渡される。ユーザーが受取る
アプリケーション・パッケージ中に、ユーザーが必要と
するプログラムの汎用及び特殊機能のみが入れられるよ
うに選択がなされる。

第１図において、アプリケーション開発者２６は、オフ
ィス５０で働くユーザー４１ないし４４のためにアプリ
ケーション・パッケージを作成するという仕事を割当て
られている。オフィス５０は、ユーザー４１ないし４４
によって使用される４つのコンピュータ５１ないし５４
をもつ。コンピュータ５１ないし５４は、それぞれ記憶
領域５６ないし５９をもっている。そして、記憶領域５
６ないし５９は、それぞれアプリケーション・パッケー
ジ６１ないし６４を含んでいる。尚、各記憶領域には１
つしかアプリケーション・パッケージが示されていない
が、複数のアプリケーション・パッケージを格納しても
よい。アプリケーション・パッケージ６１ないし６４は
、プログラム開発者２１ないし２４によって書かれライ
ブラリ３０に収められているプログラムからアプリケー
ション開発者２６によって作成されたものである。

アプリケーション・パッケージ６１ないし６４は、それ
ぞれ、ユーザー４１ないし４４の要求をみたすように仕
立てられている。

プログラム開発者２１ないし２４は、本発明のパッケー
ジング構造に従いプログラムをパッケージするために、
パッケージング・ツール８０を使用する。同様に、アプ
リケーション開発者２６は、プログラム開発者２１ない
し２４によって作成されたプログラムを、特定ユーザー
の要求に適合されたアプリケーション・パッケージ中に
再パッケージするために、パッケージング・ツール９０
を使用する。パッケージング・ツール８０と９０はきわ
めてよく似ており、その詳細は後で第７図ないし第２０
図に関連して説明する。

第２Ａ図および第２Ｂ図は、ライブラリ３０に含まれて
いるプログラム３１ないし３５をより詳細に示すもので
ある。プログラム３１ないし３５が、頂点のないピラミ
ッドのように図形表示されていることに注意されたい。

この図は、これらのプログラムがパッケージング構造に
従って書かれているけれども、未だアプリケーション・
パッケージの１部ではないことを示している。

プログラム３１は、ワード処理プログラムである。この
プログラムは、文書処理とスペル・チエツクという２つ
の主要な機能を有する。この文書処理主要（１次）機能
は、内容テーブル能力、索引生成能力、及び意匠プリン
ティングという３つの２次機能をもつ。スペル・チエツ
ク１次機能は、一般用語、法律用語、及び医学用語とい
う３つの２次機能をもつ。各２次機能は、特定の機能を
実行するために使用されるレベル５０００上に対応する
オペレーショナル・コードをもつ。

プログラム３２は通信プログラム、プログラム３３は通
信プログラム、プログラム３４はオペレーティング・シ
ステム、プログラム３５はチェス・プログラムである。

このとき１、チェス・プログラム３５以外は複数の１次
機能と複数の２次機能をもつことに注意されたい。チェ
ス・プログラム３５は簡単なので、１次且つ２次の機能
を１つしかもっていない。

プログラム３１ないし３５は、パッケージング・ツール
８０を使用してプログラム開発者によって作成されるプ
ログラムの単なる例示である。プログラム開発者は、１
次及び２次機能として望むものを選択することにつき広
い柔軟性を与えられている。そして、より多くの１次及
び２次機能を選択するほど、プログラムはより汎用的に
なり、より一層アプリケーション開発者が、そのプログ
ラムを特定のユーザーの要求をみたすように仕立てられ
たアプリケーション・パッケージ中に含めることができ
るようになる可能性が高まる。

第１図及び第２図を参照して、オフィス５０が小さい法
律事務所であると仮定する。アプリケーション開発者２
６は、ユーザー４１と打合わせた後に、ユーザー４１が
ワード処理プログラム３１と、会計プログラム３３と、
オペレーティング・システム３４は必要としているけれ
ども、通信プログラム３２あるいはチェス・プログラム
３５は必要としないと結論したとする。また、アプリケ
ーション開発者２６が、ユーザー４１がワード処理プロ
グラムの文書処理及びスペル・チエツク１次機能を必要
とするとともに、内容テーブル生成、一般用語及び法律
用語２次機能を必要としているけれども他の２次機能は
必要としていないと結論したとする。同様にして会計プ
ログラム３３及びオペレーティング・システム３４のい
くつかの１次及び２次機能が選択され、ユーザー４１の
要求に基づきいくつかの機能が省かれる。アプリケーシ
ョン開発者２６は、プログラム３１．３３、及び３４を
アプリケーション・パッケージ６１へと再パッケージし
、それをユーザー４１に渡し、ユーザー４１はそれを自
分のコンピュータ５１のメモリ５６中に記憶する。アプ
リケーション・パッケージ６２ないし６４も同様にして
ユーザー４２ないし４４の要求に基づき作成される。ア
プリケーション開発者２６は、アプリケーション・パッ
ケージ６１ないし６４を作成するためにパッケージング
・ツール９０を使用するが、これについては後述する。

第３図は、ユーザー４１のためにアプリケーション開発
者２６によって作成されたアプリケーション・パッケー
ジ６１をあられす。アプリケーション・パッケージ６１
は、頂部が完成されたピラミッドとして図形表示されて
いることに注意されたい。アプリケーション・パッケー
ジ６１は、ユーザー４１が必要とするだけの１次及び２
次機能を含む。そしてもしユーザー４１の要求が変更さ
れるときは、新しいアプリケーション・パッケージをユ
ーザー４１用に作成することができる。

アプリケーション・パッケージ６１が５つのレベル１０
００．２０００．３０００．４０００及び５０００から
成ることに注意されたい。この好適な実施例の５つのレ
ベルのパッケージング構造は第４図以降に詳細に示され
ている。

第４図は、この好適な実施例のソフトウェア管理構造を
あられす。ここで５つのレベルが示され、その階層的性
質を強調するため構造がピラミッド形状として図示され
ていることに注意されたい。

その最上レベルである、アプリケーション・グループ（
ＡＣ）レベル１０００は、高レベル・ユーザー・アプリ
ケーションを形成するように結合される１グループのコ
ンピュータ・プログラムを規定する。第２のレベルであ
る、ロード可能コード・グループ・レベル（ＬＣＧ）２
０００は、めいめいが汎用タスクを実行する個々のプロ
グラムを規定する。例えば、第３図のアプリケーション
・パッケージ６１は、ロード可能コード・グループ・レ
ベル２０００上に、ワード処理プログラムと、会計プロ
グラムと、オペレーティング・システムを有する。第３
のレベル、１次機能グループ・レベル（ＰＦＧ）３００
０は、ＬＣＧレベルに規定されている共通プログラムを
、１次機能のより特定の組へとふるいをかける。例えば
、第３図のアプリケーション・パッケージ６１のＬＣＧ
レベル上のワード処理プログラムの場合、ＰＦＧレベル
が文書処理及びスペル・チエツクの１次機能を含む。そ
れと同一タイプの絞り込みは、ＬＯＧレベル上の他のプ
ログラムにも生じうる。

第４のレベルである、２次機能グループ・レベル（ＳＦ
Ｇ）４０００は、ＰＦＧレベルに規定された２次機能を
、より密接に特定ユーザーの要求をみたすように仕立て
られた一層特殊化された２次機能の組へとふるいをかけ
る。ＳＦＧレベルは、コンピュータ・システム上にロー
ド可能な所与の動作可能機能毎のＲＵの最小の個数を識
別する。

例えば、第３図のアプリケ−シコン・パッケージ６１の
ＰＦＧレベル上のスペル・チエツク１次機能の場合、Ｓ
ＦＧレベルは一触用語及び法律用語の２次機能を含む。

これと同一タイプの絞り込みは、ＰＦＧレベル上の他の
１次機能の場合にも行うことができる。

最後のレベルである、オペレーショナル・コード・グル
ープ・レベル（ＯＣＧ）５０００は、上記４つのレベル
によって決定された特殊化されたユーザー・アプリケー
ションを走らせるのに必要なオペレーショナル・コード
を含む。

第５図は、第４図の好適な実施例の階層構造をより詳細
に図示するものである。ここでＡＧレベル１０００が交
換可能ユニット（ＲＵ）１０００からなることに注意さ
れたい。ＲＵＩｌｏｏの内容は第６Ａ図等で詳細に説明
される。ＲＵＩｌｏｏは、ＬＣＧレベル２０００上の少
くとも１つのＲＵに接続される。第５図は、ＲＵＩｌｏ
ｏが、ＬＣＧレベル２０００上のＲＵ２１００に接続さ
れている様子を示す。ＲＵ２１００の内容も第６Ａ図等
を参照して後述する。ＲＵ２１００は、ＰＦＧレベル３
０００上の少くとも１つのＲＵに接続される。第５図は
、ＲＵ２１００が、ＰＦＧレベル３０００上のＲＵ３１
００に接続されている様子を示す。ＲＵ３１００の内容
もまた、第６Ａ図等を参照して後述する。ＲＵ３１００
は、ＳＦＧレベル４０００上の少くとも１つのＲＵに接
続される。第５図は、ＲＵ３１００がＲＵ４１００に接
続されている様子を示す。ＲＵ４１００の内容もまた、
第６Ａ図等を参照して後述する。ＲＵ４１００は、ＯＣ
Ｃレベル５０００上の少くとも１つのＲＵに接続される
。第５図は、ＲＵ４１００がＲＵ５６００に接続されて
いる様子を示す。

ＲＵ５６００の内容は、第６Ｂ図等を参照して後述する
。

第６Ａ図は、ＡＣＳＬＣＧ、、Ｐ、ＦＣ及びＳＦＧレベ
ルを形成するために使用される交換可能ユニットを詳細
に示す図である。交換可能ユニット１００はヘッダ１１
０とボディ１２０とからなる。

ヘッダ１１０は固定ヘッダ・ブロック２００と可変ヘッ
ダ・ブロック３００とからなる。ボディ１２０は、固定
グループ情報ブロック４００と可変グループ情報ブロッ
ク５００からなる。固定ヘッダ・ブロック２００は長さ
情報部分２２０と、ＲＵ　　１０情報部分２３０と、オ
フセット情報部分２６０からなる。長さ情報部分２２０
は、ＲＵＩｏｏの全体の長さと、ＲＵｌｏｏのボディ１
２０の長さを常に記録する。ＲＵ　　ＩＤ情報部分２３
０は、第５図の他のすべての交換可能ユニットからこの
特定の交換可能ユニットを一意的に識別する自己識別情
報である。さらにＲＵ　　ＩＤ情報部分２３０は、この
特定のＲＵの保守レベルを決定するために使用すること
のできる保守情報を含む。

オフセット情報部分２６０は、可変ヘッダ部分３００中
のデータと、固定グループ情報部分４００へのオフセッ
トを含む。特に、オフセット情報部分２６０は、可変ヘ
ッダ３００中のシステム特定データ部分３２０、ハード
ウェア従属部３３０及びソフトウェア従属部分３６０へ
のオフセットを有する。オフセット情報２６０はまた、
固定グループ情報ブロック４００へのオフセットを有す
る。固定ヘッダ・ブロック２００に含まれている特定の
フィールドは、この後の表１に示し、可変ヘッダ・ブロ
ックはこの後の表２に示す。

再び第６Ａ図を参照すると、ボディ１２０は固定グルー
プ情報ブロック４００と可変グループ情報ブロック５０
０からなる。固定グループ情報ブロック４００は、ボデ
ィ長情報部分４２０と、グループＩＤ情報部分４３０と
、グループ・オフセット情報部分４６０を含む。ボディ
長情報部分４２０は、ボディ１２０の全長を記録し続け
る。グループＩＤ情報部分は、追加的な自己識別情報部
分と保守情報を含む。グループ・オフセット情報部分４
６０は、可変グループ情報ブロック５００へのオフセッ
トを有する。特に、グループ・オフセット情報部分４６
０は、グループ特定データ部分５２０中のデータへのオ
フセットと、次レベル・エントリ部分５４０のリストへ
のオフセットを有する。

固定グループ情報ブロック４００と可変グループ情報ブ
ロック５００に含まれている特定フィールドは、ＲＵｌ
ｏｏがＡＣレベル１０００、またはＬＯＧレベル２００
、またはＰＦＧレベル３０００、またはＳＦＧレベル４
００のどれにあるかに依存する。もし交換可能ユニッ）
１００がＡＣレベル１０００内にあるなら、固定ＡＣ情
報ブロック１４００は表３（後述）に詳述するとおりで
あり、可変ＡＣ情報ブロック１５００は表４（後述）に
詳述するとおりである。もし交換可能ユニット１００が
ＬＣＧレベル２０００にあるなら、固定ＬＣＧ情報ブロ
ック２４００は表５（後述）に詳述するとおりであり、
可変ＬＯＧ情報ブロック２５００は表６（後述）に詳述
するとおりである。同様に、交換可能ユニット１００が
ＰＦＧレベル３０００にあるなら、固定ＰＦＧ情報ブロ
ック３４００は表７（後述）に詳述するとおりであり、
可変ＰＦＧ情報ブロック３５００は表８（後述）に詳述
するとおりである。最後に、交換可能ユニット１００が
ＳＦＧブロック４０００にある場合、固定ＳＦＧ情報ブ
ロック４４００は表９（後述）に詳述するとおりであり
、可変ＳＦＣ情報ブロック４５００は表１０（後述）に
詳述するとおりである。

第６Ｂ図の交換可能ユニット６００について次に説明す
る。交換可能ユニット６００はＯＣＧレベル５０００に
のみ在駐する。ここで、交換可能ユニツ）６００が、第
６Ａ図に示す交換可能ユニット１００のヘッダ部分１１
０と同一のヘッダ部分１１０をもつことに注意されたい
。交換可能ユニット６００もまたボディ部分６２０をも
つが、これは交換ユニット１００のボディ１２０とは異
なる。特に、ボディ６２０はオペレーショナル・コ−Ｆ
６３０を含む。オペレーショナル・コード６３０は構築
されたものではなく、プログラムのデータまたは実行可
能コードである。オペレーショナル・コード６３０はオ
プションとして、追加的な重要製造データ（自己識別、
保守及び従属情報）を含む。

第６Ａ図に関連して既述したように、交換可能ユニット
ｌＯＯのヘッダは、交換可能ユニット１００が位置して
いるレベルに拘らず同一のフィールドをもつ。第１表は
、固定ヘッダ・ブロックをより詳細に示すものである。

聚し」は二ム存副１ 長　　さ　　必　須　　フィールド属性涌１禾　　　　
　　　　　　　　　　　　　　　　　　　　　　　　ｉ
　　　　　Ｎｉ２・・・・・・Ｚ’／３表１において、
フィールド２１１は、この特定のＲＵの長さを識別する
フィールド２２２はこのＲＵのボディの全長を識別する
。この情報は、ＲＵを連鎖させるために使用される。Ｉ
Ｄ情報部分２３０は、自己識別情報の複数のフィールド
と、保守情報の複数のフィールドを含む。ＲＵ名ラフイ
ールド２３１、ＲＵを管理する際に、システムによって
使用される。特定のＲＵに与えられる名前は、そのＲＵ
をシステム中の他のすべてのＲＵから区別し得るように
固有のものである。表１１（後述）の列１７４００がＲ
Ｕ名の例を示している。ＲＵＵ照ＩＤフィールド２３２
は、ＲＵの追加的な視覚識別子を与える。ＲＵロード識
別（ＩＤ）フィールド２３３は、対応する初期プログラ
ム・ロードＩＤをもつ１つの装置によって要求される特
殊なロードとしてＲＵを識別する。これにより、システ
ムが、初期プログラム・ロード処理の間にロードされな
くてはならないＲＵを決定するための機構が与えられる
。尚、ＲＵロードＩＤフィールド２３３がオプションで
あることに注意されたい。ＬＯＧ及びＡＧ　　ＩＤフィ
ールド２３４と、ＰＦＧ　　ＩＤフィールド２３６と、
５ＦＧＩＤフイールド２３７は、階層的チエイン内の他
のＲＵのＩＤを含む。

固定ヘッダ２００のＩＤ情報部分２３０の保守情報フィ
ールドについて次に説明する。ＲＵＵ令セット・フィー
ルド２４１は、ＲＵボディ中のデータが互換であるマシ
ン命令セットを識別する。

このフィールドはオプションである。ＲＵＵ御情報フィ
ールド２４２は、ＲＵを管理するために使用される複数
のフラグを含む。第１のフラグは、ＲＵが修正されてい
たならセットされるＲＵＵ正フラグである。第２のフラ
グは、この特定のＲＵが何らかのハードウェアまたはソ
フトウェア従属性をもつならセットされるＲＵＵ属性フ
ラグである。第３のフラグは、このＲＵが、ＡＧ、ＰＦ
Ｃ，。

ＳＦＧまたはＯＣＧ　　ＲＵのどれであるかを記述する
ＲＵタイプ・フラグである。

ＲＵＵ発情報フィールド２４３は、このＲＵを開発した
特定の研究所などの、このＲＵの初期の開発に関する情
報を含む。ＲＵＵ成日フィールド２４４とＲＵＵ成時間
フィールド２４６は、このＲＵが作成された日時のタイ
ム・スタンプを含む。

ＲＵ導導入ラフイールド２４フＲＵＵ入時間フィールド
は、このＲＵがシステム上に導入された日時のタイム・
スタンプを含む。ＲＵバージョン・レベル・フィールド
２４９とＲＵリリース修正レベル・フィールド２５０は
、この特定ＲＵの保守レベルを識別する。ＲＵ−時固定
ＩＤフィールド２５２及びＲＵパッチ・フィールド２５
３はオプションであって、このＲＵのためになされた一
時的設定（ｆｉｘ）またはパッチに名前を与える。

フィールド２５７及び２５８は、ＲＵのコンパイラにつ
いての情報を識別する。

次に、固定ヘッダ・ブロック２００のオフセット情報部
分２６０を形成するフィールドについて説明する。ＲＵ
ボディ・フィールド２６１へのオフセットは、このＲＵ
のボディの開始位置を指し示す。ＲＵシステム特定デー
タ・フィールド２６２へのオフセットは、ＲＵの可変ヘ
ッダ・ブロックに含まれている何らかのシステム特定デ
ータの開始位置を指し示す。ＲＵハードウェア従属リス
ト・フィールドへのオフセットは、ＲＵの可変ヘッダ・
ブロックに含まれているソフトウェア従属リストの開始
位置を指し示す。フィールド２６５は、ＲＵＵ定情報の
開始位置を指し示す。フィールド２６７は、もし存在す
るなら、ＯＣＧＣデボデイ中込ＶＰＤを指し示す。

ＲＵフィールド２６６を含むシステム各領域は、そのＲ
Ｕが在駐するシステム・メモリ中の位置の名前を含む。

位置名の例は、後述の表１１の列１７６００に示されて
いる。フィールド２７０及び２７１は、ＲＵが最後に修
正された日時を含む。

フィールド２７２は、可変ヘッダ中に含まれているヘッ
ダ拡張データを指し示す。

表２は、可変ヘッダ・ブロック３００のフィールドをよ
り詳しく示すものである。

２：可変ヘッダ３００ 長　さ　必　須　フィールド属性 この表において、システム特定データ部分３２０は、シ
ステム特定データ長フィールド３２１とシステム特定デ
ータ・フィールド３２２からなる。

可変ヘッダ・ブロック３００のハードウェア従属リスト
部分３３０に含まれているフィールドについて次に説明
する。フィールド３３１は、ハードウェア従属リスト中
のエントリの数を含む。フィールド３３２ないし３３７
及び３３９は、ハードウェア従属リスト中の１つのエン
トリを形成し、そのことはそのリスト中の複数のエント
リに対して反復される。フィールド３３２はＲＵハード
ウェア相関ＩＤを含む。もしハードウェアの異なる複数
の部分が常に一緒に使用されるべきであるなら、それら
には同一の相関ＩＤが与えられることになる。フィール
ド３３３．３３５．３３６及び３３７はそれぞれ、この
ＲＵが従属するハードウェアの特定の部分のタイプと、
モデル番号と、レベルＩＤ番号と、部品番号を含む。

可変ヘッダ・ブロック３００のソフトウェア従属リスト
部分３６０に含まれているフィールドについて次に説明
する。フィールド３６１はソフトウェア従属リストのサ
イズを含み、フィールド３６２はソフトウェア従属リス
ト中のエントリの数を含む。これらのフィールドはリス
ト中の各エントリ毎に反復される。フィールド３６３は
ソフトウェア従属リスト中のこの特定のエントリのサイ
ズを含む。フィールド３６４は、ソフトウェア従属リス
ト中のこのエントリのソフトウェア相関ＩＤを含む。も
しソフトウェアの異なる複数の部分が常に一緒に使用さ
れるべきなら、それらには同一の相関ＩＤが与えられる
ことになる。

ソフトウェア従属リスト中に含まれているソフトウェア
・プログラムは、本発明の開示のように構成されている
と想定する。それゆえ、このＲＵが従属するソフトウェ
ア・プログラムを構成するＲＵの階層的チエインが示さ
れなくてはならない。

そして、ＬＣＤ　　ＩＤフィールド３６７、ＬＣＧ−Ｐ
ＦＧ　　ＩＤフィールド３７０及びＰＦＧ−３ＦＧ　　
ＩＤフィールド３７３が、この階層チエインを決定する
情報を与える。フィールド３６８及び３６９は、従属す
るソフトウェア・プログラムのＬＯＧのバージョン・レ
ベル及びリリース／修正レベルを示す。同様に、フィー
ルド３７１及び３７２にはＬＣＧ−ＰＦＧチエインのバ
ージョン・レベル及びリリース／修正レベルが示され、
ＰＦＧ−３ＦＧチエインのバージョン・レベルと、リリ
ース／修正レベルと、中間ＰＣレベルがフィールド３７
４ないし３７６に示されている。フィールド３８１ない
し３８４は、ヘッダ拡張子を形成する。フィールド３８
２は、ＲＵの部品番号を示す。フィールド３８３は、Ｒ
Ｕの短記述を含む。

ＲＵの短記述の例は、表１１（後述）の列１７０５０に
示されている。

次に、第６Ａ図に示した交換可能ユニット１００のボデ
ィ１２０のフィールドについて詳細に記述する。ボディ
１２０は、既述のように、固定グループ情報ブロック４
００と可変グループ情報ブロック５００を含む。ブロッ
ク４００及び５００は、ＲＵが階層チエイン中のどのレ
ベルにあるかに応じて異なるフィールドをもつ。固定Ａ
Ｇ情報ブロック１４００はＡＧレベル１０００上の交換
可能ユニット１１００中にあり、表３により詳しく示さ
れている。

３：　　ＡＧ情１１４００ 長さ必須フィールド属性 画体　　　　　　　　　　　’１ｌＮ１３・・・・拳・
１４ｔｉｂこの表において、長さ情報部分１４２０　ハ
、ＡＧボディの全長を記録し続けるフィールドを含む。

次に、ＲＵＩｌｏｏの固定ＡＣ情報ブロック１４００の
グループ！Ｄ情報部分１４３０を形成するフィールドに
ついて説明する。フィールド１４３１ないし１４３９は
、この特定のＡＧ　　ＲＵを構築したベンダ（納入者）
の名前を識別する。このベンダは通常、アプリケーショ
ン・パッケージを構成したアプリケーション開発者であ
る。フィールド１４４１は、このＲＵがＡＣタイプのＲ
Ｕであることの視覚的識別を与える文字定数である。

フィールド１４４３ないし１４４６は、それぞれ、この
ＡＧ　　ＲＵの識別子、部品番号、バージョン・レベル
及びリリース／修正レベルを記述する。

フィールド１４４７及び１４４８は、このＡＧＲＵに対
してなされた何らかの中間的あるいは一時的な（レベル
間の）変更についての情報を含む。

フィールド１４４９は、ＲＵの所有者からの著作権情報
を含む。

次にＲＵＩｌｏｏの固定ＡＧ情報ブロック１４００のオ
フセット情報部分１４６０を形成するフィールドについ
て説明する。フィールド１４６３は、階層チエインにお
いてこのＡＧ　　ＲＵに接続されたＬＣＧ　　ＲＵのリ
ストを指し示す、このリストは、表４（後述）により詳
しく示されている可変ＡＧ情報ブロック１５００に含ま
れている。

フィールド１４６４は、表４に示されている可変ＡＣ情
報ブロック１５００中に示されているＡＧ特定データの
開始位置を指し示す。

表４の可変ＡＧ　　ＲＵ情報ブロック１５００を形成す
るフィールドについて次に説明する。

４：可ＡＣ報１４００ 長　さ　必　須　フィールド属性 ＬＣＧリリース／修正レベル　　　　　　　　　　４　
　　Ｙ　　Ｃ・・・・・・１５５６この表において、Ａ
Ｇ特定データ部分１５２０は、ＡＧ特定データの長さを
含むフィールド１５２１と、ＡＣ特定データを含むフィ
ールド１５２２からなる。

次に、ＬＣＧリスト１５４０を形成するフィールドにつ
いて説明する。フィールド１５４１は、ＬＣＧリストの
サイズを決定し、フィールド１５４３はＬＣＧＣスリス
ト中ントリの数を決定する。

フィールド１５４５ないし１５５６はＬＣＧＣスリスト
中つのエントリを形成し、それはＬＣＧＣスリスト中エ
ントリ毎に反復される。フィールド１５４５は、選択／
省略フラーグであり、これは、もし有効化されているな
ら、このＬＣＧを、そのＡＧのために選択されていると
識別する。フィールド１５４６は、このＬＣＧがＡＣに
よって利用可能かどうかを示す。フィールド１５４７は
、可用なＬＣＧがシステム上に導入されているかどうか
を示す。フィールド１５４８は、導入されたしＣＧがこ
のシステム上で走るように有効化されているかどうかを
示す。フィールド１５４６ないし１５４８は、拡張また
は性能向上のためにユーザーが必要とするところまで、
ＬＣＧを、ユーザーに送られているけれどもそのユーザ
ー用に有効化されていないアプリケーション・パッケー
ジの一部として含めるものである。例えば、支払可能会
計のＬＯＧをユーザーに供与することができるけれども
、それはユーザーがそのアプリケーションを性能向上し
てこの追加の機能を必要とするまで有効化されない。こ
れらのフィールドまたは、ソフトウェアのコピー保護機
能の一部としても使用することができる。

フィールド１５５０は、この特定のＬＯＧが在駐するシ
ステム中の位置を含む。システム位置の名前の例が表１
１（後述）の列１７６００に示されている。フィールド
１５５２は、この特定のしＣＧを一意的に識別するため
にシステムによって使用されるＬＣＧの名前を含む。Ｒ
Ｕ名の例は、表１１の列１７４００に示されている。フ
ィールド１５５４はＬＯＧの識別子を含む。ＬＯＧ　　
ＩＤの例は表１１の列１７１００に示されている。

フィールド１５５５及びフィールド１５５６はそれぞれ
ＬＣＧエントリのバージョン・レベル及びリリース／修
正レベルを含む。

表５は、ＬＣＧレベル２０００　（第５図）にあるＲＵ
２１００の固定ＬＣＧ情報ブロック２４００内に形成さ
れているフィールドを記述する。尚、これらのフィール
ドの多くは、表３に示されている固定ＡＣ情報ブロック
１４００中のフィールドに類似する。これらのフィール
ドの記述については、表３に関連する記述を参照された
い。フィールド２４３１ないし２４３９に含まれている
ベンダ情報は通常、そのプログラム・パッケージを作成
したプログラム開発者についてのものである。

フィールド２４６３は、このＬＣＧ　　ＲＵにリンクさ
れたＰＦＧ　　ＲＵのリストを指し示す。このリストは
、表６に示されている。可変ＬＣＧ情報ブロック２５０
０に含まれている。フィールド２４６４は、やはり表６
の可変ＬＣＧ情報ブロック２５００に含まれているＡＣ
データを指し示す。

フィールド２４６７は、ブロック２５００にある出ロブ
ログラムを指し示す。

友Ｌ」＄Ｊ匹工蓋皿 長　さ　必　須　アイ−４Ｆ属性 表６＝可変ＬＯＧ情報 長さ必須フィール１性 ＲＵ２１００の可変ＬＣＧ情報ブロック２５００が表６
に示されている。尚、表６の可変ＬＯＧ情報ブロック２
５００中のフィールドの多くは、表４の可変ＡＣ情報ブ
ロック１５００中のフィールドと同様であることに注意
されたい。そしてこれらのフィールドの記述に対応する
表４の説明を参照されたい。また、表５のフィールド２
４６５に述べたＡＣデータが表６のフィールド２５３１
ないし２５３３に示されている。これらのフィールドに
含まれている情報により、ＬＣＧが、接続するＡＣを識
別することが可能となる。出ロブログラムの名前と位置
がフィールド２５６１ないし２５６９に示されている。

これらのプログラムは、アプリケーション・パッケージ
またはプログラム・パッケージを作成しつつある間にエ
ラーが生じたときにコールされる。

表７：固定ＰＦＧ情報３４００ 長　さ　必　須　フィールド属性 ＷＣ４１４Ｎ　　　ｊｊ　””−、ｊ４ｔ＋）表７は、
ＰＦＧレベル３ｏｏｏ（第５図）上のＲＵ３１００（７
）固定ＰＦＧ情報情報ブタツク００を示す。ここで再び
、表７の固定ＰＦ’Ｇ情報ブロック３４００のフィール
ドのいくつがか、表３の固定ＡＣ情報ブロック１４００
中のフィールドと同様であることに注意されたい、よっ
て、これらのフィールドの記述に対応する表３の記載を
参照されたい。しかし、ブロック１４００及び２４００
中に含まれているベンダ情報はブロック３４００には最
早台まれていないことに留意されたい。

フィールド３４３４は、階層的チエイン中でこのＰＦＣ
；　　ＲＵのためのＬＣＧ　　ＩＤを識別する。

フィールド３４６３は、このＰＦＧ　　ＲＵに連結され
たＳＦＧ　　ＲＵのリストを指し示す。このリストは表
８（後述）に示されている可変ＰＦＧ情報ブロック３５
００に含まれている。

フィールド３４６４は、表８の可変ＰＦＧ情報ブロック
３５００にも含まれているＰＦＧ特定情報を指し示す、
フィールド３４６１及び３４６２は、もし存在するなら
ば、可変ＰＦＧ情報ブロック３５００中に含まれている
ハードウェア及びソフトウェア従属データを指し示す。

表８：可　ＰＦＣ情　３５００ 長　さ　必　須　フィールド属性 表８は、レベル３０００　（第５図）上のＲＵ３１００
の可変ＰＦＧ情報ブロック３５００を示す。

尚、表８のブロック３５００のフィールドのいくつかは
表４のブロック１５００中のフィールドと同様であるこ
とに注意されたい。これらのフィールドの記述に対応す
る表４の説明を参照されたい。

ＳＦＧレベル４０００上にあるＲＵ４１００の固定ＳＦ
Ｇ情報ブロック４４００　（第５図）が次の表９に示さ
れている。

９：　　ＳＦＧ情報４４００ 長　さ　必　須　フィールＦ属性 固定ＳＦＧ情報ブロック４４００のフィールドの多くは
、表３の固定ＡＣ情報ブロック１４００と同様であるこ
とに注意されたい、また、これらのフィールドの記載に
ついては、表３の説明を参照されたい、フィールド４４
３３及び４４３４は、このＳＦＧ　　ＲＵのための階層
チエイン中のより高位レベルにあるＲＵを識別する。

フィールド４４６１は、このＳＦＧ　　ＲＵに連結され
たＯＣＧ　　ＲＵのリストを指し示す。このリストは、
表１０に示すように可変ＳＦＧ情報ブロック４５００中
に含まれている。フィールド４４６２は、可変ＳＦＧ情
報ブロック４５００中に含まれている一時設置／パッチ
活動を指し示す。

フィールド４４６３は、やはり可変ＳＦＧ情報ブロック
４５００中に含まれているＳＦＧ特定情報を指し示す。

表１０：可　ＳＦＧ情報４５００ 長　さ　必　須　フィールＦ属性 ＲＵ４１００の可変ＳＦＧ情報ブロック４５００が表１
Ｏに示されている。ブロック４５００（第５図）のフィ
ールドのい（つかは、表４のブロック１５００中のフィ
ールドと同様であることに注意されたい、また、これら
のフィールドの記述に対応する表４の説明を参照された
い。

フィールド４５６１ないし４５７０は、このＲＵに接続
された一時設置／パッチ活動のリストを規定する。

ここで再び第１図を参照して、プログラム・パッケージ
を構築するためにプログラム開発者２１ないし２４によ
って使用されるプログラム・パッケージング・ツール８
０について説明する。プログラム・パッケージング・ツ
ール８０は、第７図以下で示すように適切にプログラム
された、パーソナル・コンピュータ等の汎用コンピュー
タ上で走るソフトウェアである。第７図は、プログラム
・パッケージを作成するためにプログラム開発者が使用
することができるツールのメニューを示す。

プログラム開発者は、４つのレベル、すなわちＬＣＧ、
、ＰＦＧ、ＳＦＧ及びＯＣＧの４つのレベルでパッケー
ジされたプログラムを作成するために、第７図に示すプ
ログラム・パッケージング・ツールを使用する。プログ
ラム・パッケージング・ツール１１０００により、プロ
グラム開発者がプログラム・パッケージを決定するのが
可能となる。

パッケージング・ツール１１０００はその詳細が第８図
以下に示されている。パッケージング・ツール１７００
０は、プログラム開発者が、パッケージング・ツール１
１０００によって決定されたプログラム・パッケージを
表示するのを可能ならしめる。プログラム開発者に表示
されるプログラム・パッケージの例が後述の表１１に示
されている。

第８図は、パッケージング・ツール１１０００の制御の
全体的な流れを示す図である。尚、第８図は、プログラ
ム・パッケージング・ツール１１ＯＯＯとアプリケーシ
ョン・パッケージング・ツール２１０００が類イ以であ
ることにより、アプリケーション・パッケージング・ツ
ール２１０００の制御の全体的な流れをも示しているこ
とに留意されたい。第８図から第２０図に至るフローチ
ャートの中でアプリケーション・パッケージング・ツー
ル２１０００に固有のステップには参照番号２１０００
ないし２１９９９が付与されている。

これらのステップは、後で、アプリケーション・パッケ
ージング・ツール２１０００に関連して説明する。

さて第８図を参照すると、判断ブロック１１０１０は、
プログラム開発者に、ＬＣＧを決定したいと思っている
のかどうかを質問するものである。

そしてもしプログラム開発者が、ＬＣＧボディを決定し
たいということをあられすなら、ブロック１１１００で
ＬＣＧボディが決定される。ブロック１１１００の詳細
は第９図に示されている。次にブロック１１′２００で
はＬＣＧヘッダが決定される。ブロック１１２００の詳
細は第１５図に示されている。判断ブロック１１０２０
はプログラム開発者に、ＰＦＧを決定したいかどうかを
問うものである。もしそうなら、ブロック１１４００で
ブロック１１４００の詳細が決定される。次にブロック
１１２００でＰＦＧヘッダが決定される。

°　　ブロック１１２００−の詳細は第１５図に示され
ている。尚、ブロック１１２００は、ＬＣＧ％ＰＦＧ、
、ＳＦＧ、ＡＣ；及びＯＣＧレベルの決定に共通である
ことに留意されたい。

判断ブロック１１０３０は、プログラム開発者に、ＳＦ
Ｇを決定したいかどうかを問うものである。もしそうな
ら、ＳＦＧボディがブロック１１５００で決定される。

ブロック１１５００の詳細は第１７図により詳細に示さ
れている。次にブロック１１２００でＳＦＧヘッダが決
定される。判断ブロック１１０５０はプログラム開発者
にＯＣＧを決定したいかどうかを問うものである。もし
そうなら、ブロック１１０６０は、プログラムのオペレ
ーショナル・コードまたはデータを含むＯＣＧボディへ
とつながる。ブロック１１２００はＯＣＧヘッダを決定
するものである。ブロック１１０７０はプログラム開発
者に、ツール１１０００を用いて作業を行ったのかどう
かを問うものである。尚、もしプログラム開発者がスク
ラッチからプログラム・パッケージを設計しているので
あれば、最初にＯＣＧを決定し、次にＳＦＧを、次にＰ
ＦＧを、次にＬＣＧを決定することになることに注意さ
れたい。

第９図は、第８図のブロック１１１００がどのようにＬ
ＣＧボディを決定するのかを示すものである。ブロック
１１１１０は、プログラム開発者に、表５に示すフィー
ルド２４３１ないし２４３９に含まれているベンダ情報
を入力するようにプロンプトする。典型的には、これら
のフィールドで求められているベンダは、プログラム開
発者自身であるかまたは彼が所属する会社であるが、他
のベンダをここに記入してもよい。ブロック１１１１０
は、プログラム開発者に、ＬＣＧのための文字定数をセ
ットするように要求する。このデータは表５のフィール
ド２４４０に含まれている。

ブロック１１１１１は、プログラム開発者に、ＬＣＧ　
　ＩＤと部品番号とを要求する。この情報は表５のフィ
ールド２４５０及び２４５１に配置される。ブロック１
１１１２はプログラム開発者に−ＬＣＧ保守レベル情報
と著作権情報を入力するよう要求する。この情報は、表
５のフィールド２４５２ないし２４５６に配置される。

ブロック１１１２０はこのＬＣＧに関連するＰＦＧリス
トを決定する。ブロック１１１２０は第１０図にその詳
細が示されており後で説明する。ブロック２１１１３及
び２１１３０はアプリケーション開発者によって使用さ
れ、これについても後で説明する。

判断ブロック１１１１４はプログラム開発者に、ＬＣＧ
特定データが必要かどうかを問うものである。もしそう
ならブロック１１１４０でＬＣＧ特定データが決定され
る。ブロック１１１４０は第１２図により詳細に示され
、後で詳しく説明される。ブロック１１１１５はプログ
ラム開発者に、このＬＣＧが従属する何らかのハードウ
ェアがあるかどうかを問うものである。もしそうなら、
ブロック１１１６０でＬＣＧハードウェア従属リストが
決定される。ブロック１１１６０は第１３図により詳細
に示され、後で説明される。

判断ブロック１１１１６はプログラム開発者に、このＬ
ＣＧが従属する何らがのソフトウェアがあるかどうかを
問う、そしてもしそうなら、ブロック１１１８０でＬＣ
Ｇソフトウェア従属リストが決定される。ブロック１１
１８０は第１４図により詳細に示され、後で説明される
。ブロック１１１１７は、第９図でプログラム開発者に
よって決定されたＬＣＧボディの内容をセーブする。ブ
ロック１１１１８は制御の流れをブロック１１２００へ
と進め、そこでＬＣＧヘッダが決定される。

ブロック１１２００は第１５図に関連してより詳細に説
明される。

第１０図は、ブロック１１１２０中でＰＦＧリストが決
定される様子をより詳細に示すものである。ブロック１
１１２１はプログラム開発者に、ＰＦＧ名とＩＤを求め
る。この情報は、表６のフィールド２５５０及び２５５
２に配置される。ブロック１１１２２はプログラム開発
者にＰＦＧ保守レベルを要求する。この情報は表６のフ
ィールド２５５３及び２５５４に配置される。ブロック
１１１２４は、ユーザーがこのリスト中で他のＰＦＧを
決定したいと望んでいるかどうかを問うものである。も
しそうなら、すべてのＰＦＧが決定されるまでブロック
１１１２１ないし１１１２３が決定される。すべてのＰ
ＦＧがこのリスト中で決定されると、ブロック１１１２
５が表６の、ＰＦＧエントリ・サイズ及びエントリ数フ
ィールド２５４１及び２５４３をセットする。ブロック
１１１２６は第９図のブロック２１１１３へと戻る。

ブロック１１１４０がＬＣＧ特定データを決定する様子
の詳細が第１２図に示されている。ここでブロック１１
１４１は、プログラム開発者にＬＣＧ特定データを求め
るものである。ＬＣＧ特定データは表６のフィールド２
５２２に配置される。

ブロック１１１４２は、フィールド２５２２の内容に基
づきＬＯＧ特定データの長さをセットする。

その長さは表６のフィールド２５２１に配置される。ブ
ロック１１１４３は、第９図のブロック１１１１５に戻
る。

ブロック１１１６０がＬＣＧハードウェア従属リストを
決定する梯子の詳細が第１３図に示されている。判断ブ
ロック１１１６１はプログラム開発著に、ハードウェア
相関！Ｄがこのハードウェア従属リストに必要かどうか
を問うものである。

そしてもしそうなら、ブロック１１１６２に示すように
、表２のフィールド３３２にハードウェア相関ＩＤが配
置される。ブロック１１１６３はプログラム開発者にハ
ードウェア・タイプとモデル番号を入れるようにプロン
プトする。この情報は表２のフィーｔ’ｖド３３３及び
３３５に配置される。

判断ブロック１１１６４はプログラム開発者にハードウ
ェア従属リスト中のこのエントリにロード１０が必要か
どうかを質問する。そしてもしそうなら、ハードウェア
・ロードＩＤがブロック１１１６５に示すように表２の
フィールド３３６中に配置される。もしそうでないなら
ブロック１１１６５はスキップされる。ブロック１１１
６６はプログラム開発者にハードウェア部品番号を入力
するようにプロンプトする。この情報は表２のフィール
ド３３７に入れられる。判断ブロック１１１６７はこの
リスト上でさらにハードウェア従属性があるかどうかを
質問するものである。モシソうなら、すべての従属性が
このリスト上に取り込まれるまでブロック１１１６１な
いし１１１６６が反復される。そうしてこのリスト上に
すべてのハードウェア従属性が取り込まれると、ブロッ
ク１１１６８が、この新しい情報を取得するために表５
のハードウェア従属リストのサイズ・フィールド３３８
とエントリ数のフィールド３３１を更新する。ブロック
１１１６９は第９図のブロック１１１１６へ制御を戻す
。

ブロック１１１８０がＬＯＧソフトウェア従属リストを
決定する様子の詳細が第１４図に示されている。ブロッ
ク１１１８１はプログラム開発者に、このソフトウェア
従属リストにソフトウェア相関ＩＤが必要かどうかを質
問する。そしてもしそうならブロック１１１８２で示子
ように表２のフィールド３６４にソフトウェア相関ＩＤ
が配置される。もしそうでないならブロック１１１Ｂ２
はスキップされる。ブロック１１１８３はプログラム開
発者にソフトウェア従属タイプを入力するよう要求する
。この情報は表２のフィールド３６６に配置される。ブ
ロック１１１８４はプログラム開発者に、従属するソフ
トウェアのＬＣＧ　　ＩＤ及び保守レベルを人力するよ
う求める。この情報は表２のフィールド３６７ないし３
６９に配置される。ブロック１１１８５はユーザーに、
従属するソフトウェアがＳＦＧ　　ＲＵかどうかを尋ね
る。そしてもしそうならプログラム開発者はブロック１
１１８６でＳＦＧ　　ＩＤと保守レベルを入れるように
プロンプトされる。この情報は表２のフィールド３７３
ないし３７５に配置される。

判断ブロック１１１８７は、ＳＦＧ中間プログラム変更
レベルに対する従属性があるかどうかを尋ねるものであ
る。もしそうなら、ブロック１１１８日はプログラム開
発者にＳＦＧプログラミング変更中間１０を入力するよ
うプロンプトする。

この情報はブロック１１１９０に示すように表２のフィ
ールド３７０ないし３７２に配置される。

一方、もしそうでないなら、ブロック１１１９０はスキ
ップされる。ブロック１１１９１はプログラム開発者に
、すべてのソフトウェア従属性が決定されたかどうかを
尋ねる。もしそうでないなら制御は第１４図の始めに戻
り、すべてのソフトウェア従属性が決定されるまでブロ
ック１１１８１ないし１１１９０が繰り返される。−た
んすべてのソフトウェア従属性が決定されると、ブロッ
ク１１１９２が第２図のソフトウェア従属性サイズ・フ
ィールド３６１とエントリ数フィールド３６２を更新す
る。ブロック１１１９３は第９図のブロック１１１１７
に戻る。

第８図のブロック１１２００がＬＣＧヘッダを決定する
様子の詳細が第１５Ａないし１５ｃ図に示されている。

尚、ＬＯＧヘッダが決定される様子は、第８図でＰＦＧ
ヘッダ、ＳＦＧヘッダ、ＡＧヘッダまたはＯＣＧヘッダ
が決定される様子と同一であることに注意されたい。第
１５Ａ図において、ブロック１１２１１はプログラム開
発者にこのＲｔ、Ｔの名前と参照！Ｄを入力するように
プロンプトする。この情報は表１のフィールド２３１及
び２３２に配置される＝ブロック１１２１２はプログラ
ム開発者にこのＲＵのバージョン・レベルとリリース・
レベルを入力するようにプロンプトする。この情報は、
表１のフィールド２４９及び２５０に配置される。ブロ
ック１１２１３はプログラム開発者にこのＲＵの制御情
報と開発情報を人力するようにプロンプトする。この情
報は、表１のブロック２４２及び２４３に配置される。

ブロック１１２１４はこのＲＵを含むシステム領域の名
前をセットする。この情報は表１のフィールド２６６に
配置される。ブロック１１２１５はこのＲＵが作成され
た日時をセットする。

ブロック１１２１９はこのＲＵがＬＣＧ　　ＲＵかどう
かを尋ねる。もしそうならブロック１１２２０が表１の
フィールド２３４にＬＣＧ　　ＩＤをセットする。ブロ
ック１１２２１はブロック１１１００で決定されたＬＣ
Ｇボディ決定情報を検索する。

ブロック１１’２２２はこのＲＵがＰＦＧ　　ＲＵかど
うかを尋ねる。もしそうなら、ブロック１１２２３に示
すように表１のフィールド２３４及び２３６にＬＣＧ　
　１０及びＰＦＣ；　　ＩＤがセットされる。ブロック
１１４００で決定されたＰＦＧボディ決定情報がブロッ
ク１１２２４で検索される。

ブロック１１２２５はこのＲＵがＳＦＧ　　ＲＵかどう
かを尋ねる。もしそうなら、ブロック１１２２６は表１
のフィールド２３４．２３６及び２３７にこのＳＦＧに
関連するＬＣＧ、ＰＦＧ及びＳＦＧ　　ＩＤをセットす
る。

ブロック１１２５５は次にブロック１１５００で決定し
たＳＦＧボディ決定情報を取得する。ブロック１１２２
７（第１５Ｂ図）は、ハードウェア従属リストがこのＲ
Ｕに決定されているかどうかを尋ねる。そしてもしそう
ならブロック１１２２８が、ハードウェア従属オフセッ
トがＲＵボディとＲＵヘッダのどちらにあるかを決定す
る。ＲＵ従属オフセットはＲＵボディとＲＵヘッダのど
ちらにあってもよいが、好適な実施例では両方にはない
。もしハードウェア従属オフセット・リストがＲＵボデ
ィにあるなら、ブロック１１２３０でＲＵボディにハー
ドウェア従属リストが追加される。もしハードウェア従
属オフセット・リストがＲＵヘッダにあるなら、ブロッ
ク１１２２９でＲＵヘッダにハードウェア従属リストが
追加される。後者の場合、ハードウェア従属リストに対
するオフセットを示すために、情報が表１のフィールド
２６３に配置される。

プロ・シフ１１２３１は、このＲＵにソフトウェア従属
リストが決定されているかどうかを尋ねる。

もしそうなら、ブロック１１２３２が、ソフトウェア従
属性オフセットがＲＵボディとＲＵヘッダのどちらに含
まれているかを尋ねる。もしソフトウェア従属性オフセ
ットがＲＵボディにあるなら、ソフトウェア従属リスト
がブロック１１２３４でＲＵボディに追加される。もし
ソフトウェア従属リスト・オフセットがＲＵヘッダにあ
るなら、ソフトウェア従属リストがブロック１１２３３
でＲＵヘッダに追加される。このオフセットに関する情
報は表１のフィールド２６４に配置される。

ブロック１１２３５はこのＲＵにシステム特定データが
決定されているかどうかを尋ねる。モジそうなら、ブロ
ック１１２３６が、このシステム特定データに対するオ
フセットがＲＵボディマタはＲＵヘッダψどちらに含ま
れているかを尋ねる。

もしシステム特定データへのオフセットがＲＵボディに
含まれているなら、システム特定データカブロック１１
２３８でＲＵボディに追加される。

もしシステム特定データ・オフセットがＲＵヘッダに含
まれているなら、ブロック１１２’３７でシステム特定
データがＲＵヘッダに追加される。このオフセットに関
連するデータは表１のフィールド２６２に配置される。

ブロック１１２３９は、このＲＵにＲＵ特定情報が決定
されているかどうかを尋ねる。もしそうなら、ブロック
１１２４０がこのＲＵ特定情報に対するオフセットがＲ
ＵボディとＲＵヘッダのどちらに含まれているかを尋ね
る。もしＲＵ特定情報オフセットがＲＵボディにあるな
ら、ＲＵ特定データがブロック１１２４２でＲＵボディ
に追加される。もしＲＵ特定情報オフセットがＲＵ−、
ラダ中にあるなら、ＲＵ特定情報はブロック１１２４１
に示すようにＲＵヘッダに追加される。このオフセット
についての情報は表１のフィールド２６５に配置される
。

ブロック１１２４３（第１５Ｃ図）はこのＲＵがＱＣ（
Ｇ　　ＲＵがどうかを尋ねる。もしそうなら、ブロック
１１２４４はこのＯＣＧ用のＬＣＧ、ＰＦＧ及びＳＦＧ
　　ＩＤをセットする。この情報は表１のフィールド２
３４．２３６及び２３７に配置される。ブロック１１２
４５はこのＯＣＧがロードＩＤをもっているかどうかを
尋ねる。もしそうなら、ＯＣＣロードＩＤがブロック１
１２４６に示すように表１のフィールド２３３に配置さ
れる。

ブロック１１２４７は、このＯＣＧが共通名をもつかど
うかを尋ねる。もしそうなら、そのＯＣＧの共通名が１
、ブロック１１２４Ｂに示すように表１のフィールド２
５４中に配置される。ブロック１１２４９はＯＣＧボデ
ィが何らかの重要製造データ（Ｖ　Ｐ　Ｄ）を埋込まれ
ているがどうかを尋ねる。もしそうなら、ブロック１１
２５０に示すように、表１のフィールド２６７が、ｔｌ
込ＶＰＤカ含まれてなるｏｃＧボディの部分へのオフセ
ットに更新される。ブロック１１２５１は表１のフィー
ルド２２２でＲＵボディの全長を更新する。

ブロック１１２５２は、もしこれがＡＧ　　ＲＵなら表
３のフィールド１４２０中のＲＵボディの長さを、ＬＣ
Ｇ　　ＲＵなら表５のフィール￥２４２０を、ＰＦＧ　
　ＲＵなら表７のフィールド３４２０を、ＳＦＧ　　Ｒ
Ｕなら表９のフィールド４４２０を更新する。ブロック
１１２５３は、ＲＵの全長を計算しこの情報を表１のフ
ィールド２２１に配置する。ＲＵの全長には、ヘッダ部
分とボディ部分が含まれる。ブロック１１２５４はブロ
ック１１０２０に戻る。

第８図のブロック１１４００がＰＦＧボディを決定する
様子の詳細が第１６図に示されている。

ブロック１１４１０はプログラム開発者に、このＰＦＧ
のＩＤと、このＰＦＧを所有するＬＣＧのＩＤをも入力
するようにプロンプトする。この情報は表７のフィール
ド３４３２及び３４３４に配置される。ブロック１１４
１１は、プログラム開発者に、ＰＦＧ部品番号、保守レ
ベル及び著作権情報を入力するようにプロンプトする。

この情報は表７のフィールド３４３５及び３４５０に配
置される。ブロック１１４１２はプログラム開発者に、
このＰＦＧが他のハードウェアに従属するかどうかを尋
ねる。もしそうなら、ブロック１１１６０で示すように
ハードウェア従属リストが決定される。ブロック１１１
６０は第１３図に詳細に示されており、これは既に説明
済みである。ブロック１１４１３はプログラム開発者に
二〇ＰＦＧが何らかのソフトウェア従属性をもつかどう
かを尋ねる。もしその答えが肯定的なら、ブロック１１
１８０がこのＰＦＧのソフトウェア従属性を決定する。

ブロック１１１８０の詳細は第１４図に関連して説明済
である。ブロック１１１２０はこのＰＦＧに連結するす
べてのＳＦＧのＳＦＧリストを決定する。ブロック１１
１２０は第１０図に関連して説明済である。ブロック１
１４１４はプログラム開発者にＰＦＧ特定情報が必要か
どうかを尋ねる。もしそうなら、ブロック１１１４０で
ＰＦＧ特定情報が決定される。ブロック１１１４０の詳
細は第１２図に関連して説明済みである。

、：（７）ＰＦＧ特定情報へのオフセットは、表７のフ
ィールド３４６４に配置される。ブロック１１４１５は
第１６図で作成されたこのＰＦＧボディ決定情報をセー
ブする。ブロック１１４１６は第１５Ａ図に示すブロッ
ク１１２００への動作の流れを継続させ、そこでＰＦＧ
ヘッダが決定される。

第８図でブロック１１５００がＳＦＧボディを決定する
様子の詳細が第１７図に示されてし）る。

これにおいて、ブロック１１５１０は、プログラム開発
者にＳＦＧ　　ＩＤのみならず、このＳＦＧを所有する
ＰＦＧ　　ＩＤ及びＬＣＧ　　ＩＤをも入力するように
プロンプトする。この情報は表９のフィールド４４３１
．４４３３及び４４３４に配置される。ブロック１１５
１１は、プログラム開発者にＳＦＧ部品番号と、保守レ
ベｌしと、著作権情報を入力するようにプロンプトする
。この情報は表９のフィールド４４３５ないし４４４０
に配置される。ブロック１１５１２は、プログラム開発
者に、このＳＦＧが他のハードウェアに従属するかどう
かを尋ねる。もしその答えが肯定的であるなら、ＳＦＧ
ハードウェア従属リストがブロック１１１６０で決定さ
れる。ブロック１１１６０の詳細は第１３図に関連して
説明済みである。ブロック１１５１’　３はプログラム
開発者にこのＳＦＧに何らかのソフトウェア従属性があ
るかどうかを尋ねる。この答えが肯定的であるなら、ブ
ロック１１１８０でこのＳＦＧのためにソフトウェア従
属リストが構築される。ブロック１１１８０の詳細は第
１４図に関連して説明済みである。ブロック１１５２０
はこのＳＦＧをそのすべてのＯＣＧに連結するＯＣＧリ
ストを構築する。ブロック１１５２０がこのＯＣＧリス
トを構築する様子の詳細は第１８図に示されており、後
で説明する。

このＯＣＧリストに対するオフセットは表９のフィール
ド４４６Ｌに配置されている。ブロック１１５５０はこ
のＳＦＧのための５ＦＧ−時設置／バッチ活動リストを
構築する。このリストは表１０のフィールド４５６１な
いし４５７０に含まれている。このリストに対するオフ
セットは表９のフィールド４４６２に配置される。ブロ
ック１１５１４は、何−らかのＳＦＧ特定情報が必要か
どうかを尋ねる。もしその答えが肯定的であるなら、Ｓ
ＦＧ特定情報がブロック１１１４０で構築サレる。ブロ
ック１１１４０は第１２図に関連して説明済みである。

ＳＦＧ特定情報はフィールド４５２１に配置され、ＳＦ
Ｇ特定情報の長さはフィールド４５２０に配置され、Ｓ
ＦＧ特定情報に対するオフセットは表９のフィールド４
４６３に配置される。ブロック１１５１５は第１７図で
決定されたＳＦＧボディ決定情報をセーブする。ブロッ
ク１１５１６は制御の流れをブロック１１２００へと継
続させ、そこでＳＦＧヘッダが決定される。

ブロック１１５２０がＯＣＧリストを決定する様子の詳
細が第１８図に示されている。これにおいて、ブロック
１１５２１はプログラム開発者にそのＯＣＧを含むシス
テム位置の名前を入力するようにプロンプトする。この
情報は表１Ｏのフィールド４５４４に配置される。ブロ
ック１１５２２はシステム位置におけるこのＯＣＧを識
別するための引数を取得する。このことは、ある位置の
すべてのＯＣＧを要求するか、ある位置である名前をも
つすべてのＯＣＧを求めるか、またはこれらのすべての
ＯＣＧを手作業で入力させるかのどれかによって行うこ
とができる。

ブロック１１５２３はこのＯＣＧの名前とそのＯＣＧ２
次識別子を求める。ブロック１１５２４は、このＯＣＧ
が他のＳＦＧに属するかどうかを尋ねる。もしその答え
が肯定的なら、ブロック１１５２５でＯＣＧ例外リスト
が更新される。ＯＣＧは１つのＳＦＧにしか属するべき
ではない。ブロック１１５２６はＯＣＧの名前とＯＣＧ
の２次ＩＤを表１０のフィールド４５４７及び４５４８
に入れるものである。ブロック１１５２７はこのＯＣＧ
がシステム位置に存在するかどうかを尋ねるものである
。もしそうでないなら、ブロック１１５２８が保守レベ
ル情報を、このＯＣＧを所有するＳＦＧ決定保守レベル
情報に等しく設定する。

それゆえ、表９のフィールド４４３６中の情報が表１０
のフィールド４５４９にコピーされ、表９のフィールド
４４３７中の保守情報が表１０のフィールド４５５０に
コピーされる。

ブロック１１５２９はＯＣＧ保守レベル情報を求めるも
のである。この情報はフィールド４５４９ないし４５５
４に配置される。ブロック１１５３０はそのシステム位
置中のすべてのＯＣＧが処理されたかどうかを尋ねる。

そしてもしそうでないなら、制御がブロック１１５５２
に戻る。一方、もしすべてのＯＣＧが処理されたのであ
れば、ブロック１１５３１が表１０のフィールド４５４
３にこのシステム位置リストのサイズをセットし、表１
０のフィールド４５４６に、そのリスト中のＯＣＧエン
トリの数をセットする。ブロック１１５３２は、すべて
のシステム位置が処理されたかどうかを尋ねるものであ
る。もしそうでなければ、制御は遠くブロック１１５２
１まで遡る。もしすべてのシステム位置が処理されたな
ら、ブロック１１５３３が表１Ｏのフィールド４５４１
にＯＣＧリストのサイズをセットし、表１０のフィール
ド４５４２にシステム位置エントリの数をセットする。

ブロック１１５３４はユーザーに、リストを形成しなか
ったＯＣＧについて通知する。ブロック１１５３５は第
１７図のブロック１１５５０に制御を戻す。

プログラム開発者が単数または複数のプログラム・パッ
ケージを決定した後、プログラム開発者はパッケージン
グ・ツール１７０００を用いてプログラム・パッケージ
を表示スクリーン上に表示することができる。例えばも
し、プログラム開発者２１がプログラム・パッケージン
グ・ツール１１０００を用いて第２Ａないし２Ｂ図に示
すようにライブラリ３０中に含まれる５個のプログラム
・パッケージを決定したならば、プログラム開発者２１
に表示されるスクリーンは表１１のようになろう。

この表において、列１７０５０には短い記述が示されて
いる０列１７１００にはＬＣＧ　　ＩＤが示されている
。ＰＦＧ　　ＩＤは、もし存在するなら、列１７２００
に表示される。ＳＦＧ　　ＩＤは、もし存在するなら列
１７３００に表示される。ＲＵ名は列１７４００に表示
される。ＰＵタイプは１７５００に表示される。ＲＵが
在駐するシステム位置の名前が列１７６００に表示され
る。列１７７００．１７８００及び１７９００はそれぞ
れＲＵの可用性フラグ、導入フラグ、有効化フラグをあ
られす、これら３つのフラグは、ユーザーがＲＵの機能
を使用できるようになる前にオンにセットされなくては
ならない。尚、ＲＵのうちのあるものは回層であるだけ
であり、またあるものは回層かつ導入済であり、またあ
るものは、回層、導入済かつ有効化されていることに留
意されたい。

ここで再び第１図を参照すると、アプリケーション・パ
ッケージング・ツール９０は、アプリケーション開発者
２６にアプリケーション・パッケージを構成させるため
に使用することができる。

アプリケーション開発者２６は、ライブラリ３０中に収
められたプログラム・パッケージのうちのいくつかを選
択することによってアプリケーション・パッケージを構
成する。さらに、プログラム・パッケージの１次及び２
次機能のうちのいくつかが選択され、他は省略されるこ
とになる。アプリケーション開発者は、５つのレベル、
すなわちＡＣ，ＬＣＧ、、５ＦＧＳＰＦＧ及びＯＣＧを
含むアプリケーションを構成することによって上述のこ
とを達成するためにアプリケーション・パッケージング
・ツール９０を使用する。アプリケーション・パッケー
ジング・ツール９０は、第７図ないし第２０図に示すよ
うに適切にプログラミングされたパーソナル・コンピュ
ータなどの汎用コンピュータ上で走るソフトウェアから
なる。

第２１図は、アプリケーション開発者がアプリケーショ
ン・パッケージを作成するために使用することのできる
パッケージング・ツールのメニュー画面を表示するもの
である。パッケージング・ツール２１０　、ＯＯはアプ
リケーション・パツケージを決定する。パッケージング
・ツール２４０００は、アプリケーション・パッケージ
に収めるべき各プログラム・パッケージの１次及び２次
機能を選択する。パッケージング・ツール２７０００は
作成されたアプリケーション・パッケージを表示する。

パッケージング・ツール２１０００は、前述のパッケー
ジング・ツール１１０００にキワめてよ（似ている。パ
ッケージング・ツール２１０００は、ヅール１１０００
の機能に加えて、プログラム開発者には一般的には利用
可能となされていなかったいくつかの機能をアプリケー
ション開発者に利用可能としている。これらの追加機能
は、第８図ないし第２０図に参照番号２１０００・　な
いし２１９９９で示されており、以下説明する。

先ず第８図を参照すると、判断ブロック２１０４０はア
プリケーション開発者に、ＡＣを決定したいのかどうか
を尋ねるものである。もしそうなら、ＡＧボディがブロ
ック２１６００で決定される。ブロック２１６００は第
１９図に詳述されている。次に、ＡＧヘッダが既述のブ
ロック１１２ＯＯ中で決定される。

次に第９図を参照すると、ブロック２１１１３はアプリ
ケーション開発者に、このＬＯＧに適合させるにはＡＧ
情報が必要かどうかを尋ねるものである。もしそうなら
、ＡＧリストがブロック２１１３０で決定される。ブロ
ック２１１３０は、第１１図に詳述されており、次に説
明する。

ブロック２１１３０はＡＧリストを決定する。

これは第１１図により詳しく示されている。ブロック２
１１３１は、アプリケーション開発者に、ＡＣのＩＤを
入力するようプロンプトする。この情報は表６のフィー
ルド２３５１に配置される。

ブロック２１１３２は、アプリケーション開発者に、Ａ
Ｇの名前を入力するようにプロンプトする。

この情報は表６のフィールド２５３２に配置される。ブ
ロック２１１３３はアプリケーション開発者に、ＡＧ　
　ＲＵが位置するシステム・メモリ中の位置を入力する
ようにプロンプトする。この情報は表６のフィールド２
５３３に配置される。ブロック２１１３６は、第９図の
ブロック２１１１５に戻る。

第１５Ａ図を参照すると、ブロック２１２１６はこのＲ
ＵがＡＧ　　ＲＵかどうかを尋ねる。もしそうなら、ブ
ロック２１２１７に示すようにこのＲＵのＡＧ　　ＩＤ
が表１のフィールド２３４にセットされる。ブロック２
１２１８は第１９図に示すように、ブロック２１６００
で決定されたＡＧボディ決定情報を検索する。

ブロック２１６００がＡＧボディを決定する様子が第１
９図に示されている。ブロック２１６１０は、アプリケ
ーション開発者に、ＡＣベンダ情報と文字定数を入力す
るようにプロンプトする。

この情報は表３のフィールドＩ４３１ないし１４３９に
配置される。ブロック２１６１１はアプリケーション開
発者にＡＧ　　ＩＤとＡＣ部品番号を入力するようにプ
ロンプトする。この情報は表３のフィールド１４３３及
び１４４４に配置される。

ブロック２１６１２はアプリケーション開発者にＡＣ保
守及び著作権情報を入力するようにプロンプトする。こ
の情報は表３のフィールド１４４５ないし１４４９に配
置される。ブロック２１６２０は、このＡＣにリンクさ
れたすべてのＬＣＧのＬＣＧリストを決定する。ブロッ
ク２１６２０がＬＣＧリストを決定する様子は第２０図
に示されており、以下説明する。ブロック２１６１３は
プログラム開発者に、何らかのＡＧ特定情報が必要かど
うかを調べるようにプロンプトする。もしそうなら、Ａ
Ｇ特定情報がブロック１１１４０で決定される。ブロッ
ク１１１４０がＡＣ特定情報を決定する様子の詳細は第
１２図に関連して説明済である。ブロック２１６１４は
、第１９図で作成されたＡＧボディ決定情報をセーブす
る。ブロック１１６１５はブロック１１２００へ制御の
流れを継続させ、そこでＡＣヘッダが決定される。ブロ
ック１１２００がＡＣヘッダを決定する様子の詳細は第
１５図に関連して説明済である。

ブロック２１６２０がＬＣＧリストを決定する様子の詳
細は第２０図に示されている。ブロック２１６２１はア
プリケーション開発者にＬＣＧの名前とＩＤを入力する
ようにプロンプトする。この情報は表４のフィールド１
５５２及び１５５４に配置される。ブロック２１６２２
はアプリケーション開発者に、ＬＯＧ保守レベル情報を
要求する。この情報は表４のフィールド１５５５及び１
５５６に配置される。ブロック２１６２３はＬＣＧ可用
性フィールドをセットし、プログラム開発者に、そのＬ
ＯＧを含むシステム位置を入力するようにプロンプトす
る。この情報は表４のフィールド１５４６及び１５５０
に配置される。ブロック２１６２４はリストのすべての
ＬＣＧが決定されたかどうかを尋ねるものである。もし
そうでなければ、ブロック２１６２１ないし２１６２３
が反復される。こうしてすべてのＬＣＧが決定されると
、ブロック２１６２５が表４のフィールド１５４１にＬ
ＣＧエントリの数をセットし、フィールド１５４３にＬ
ＣＧリストのサイズをセットする。ブロック２１６２６
は第１９図のブロック２１６１３に戻る。

アプリケーション開発者が、ツール２１０００を用いて
、パッケージに収めるべきＬＣＧを選択することによっ
てアプリケーション・パッケージを決定した後は、アプ
リケーション開発者は次にアプリケーション・パッケー
ジ機能を選択するためにツール２４０００を使用する。

例えばもし、アプリケーション開発者２６が第１図に示
すユーザー４１のためにアプリケーション・パッケージ
６１を作成したいと望んだとすると、表１２は選択され
たプログラム・パッケージのメニューを表示するもので
ある。このとき、列２４０５０ないし２４９００は表１
１の列１７０５０ないし１７９００と同一であることに
留意されたい。列２４０１０は、アプリケーション開発
者がアプリケーション・パッケージのための所望の１次
及び２次機能を選択する場所を与える。第３図のアプリ
ケーション・パッケージを決定するためには、アプリケ
ーション開発者は第３図に示した選択された各々の１次
及び２次機能毎に列２４０１０にＸを配置することにな
る。選択されなかった１次機能あるいは２次機能は、ア
プリケーション・パッケージがユーザーに送られる前に
ＬＣＧ及びＰＦＧのボディから除去される。

パッケージング・ツール２７０００は、ツール２１００
０及び２４０００によって作成されたアプリケーション
・パッケージを表示する。表１３は、第３図のアプリケ
ーション・パッケージ６１を作成した後アプリケーショ
ン開発者が眺めることになる表示内容をあられすもので
ある。

既述のように、好適な情報の具体例は、第４図に示す５
つのレベルを有する。しかし、必ずしもこれらすべての
レベルを備えていなくとも本発明の範囲にとどまること
ができる。すなわち、別の実施例も考慮され、これはロ
ード可能コード・グループ（ＬＣＧ）レベル２０００と
オペレーショナル・コード・グループ（ＯＣＧ）レベル
５０００というわずか２つのレベルからなるプログラム
・パッケージを含む、この例は、好適な実施例の５レベ
ル構成はどにはユーザーの要求を満たさないけれども、
これすらも本発明の利点の多くを奏するのである。この
簡易化された例では表３．４．７．８．９、及びｌＯが
使用されない。そして、表５のフィールド２４６３はｒ
ｏｃｃリストへのオフセット」となり、フィールド２４
６５は「留保」となる、同様に、表６に示されているＰ
ＦＧリストはＯＣＧリストによって置き換えられ、選択
／省略フィールド２５４４は「留保」となる。

この簡易化例では、フィールド２５３１ないし２５３３
が用いられない。また同様に、わずか２レベルのパッケ
ージを決定するためには、第８図ないし第２０図のフロ
ーチャートのブロックの多くは不要である。

Ｆ８発明の詳細 な説明したように、この発明によれば、複数のプログラ
ムをパッケージングして所望の機能だけを具備するアプ
リケーション・プログラムを系統的に且つ容易に作成す
ることができる。

【図面の簡単な説明】

第１図は、本発明の全体的な環境を示す図、第２Ａ図及
び第２Ｂ図は、本発明に基づきパッケージソゲされたプ
ログラムの構成を示す図、第３図は、アプリケーション
・パッケージの構成を示す図、 第４図は、階層的に配列されたアプリケーション・パッ
ケージのレベルをあられす図、第５図は、第４図の階層
レベルをより詳細に示す図、 第６Ａ図は、ＡＧ、、ＬＣＧ、、ＰＦＧ及びＳＦＧレベ
ルを形成するために使用される交換可能ユニットの図、 第６Ｂ図は、ＯＣＧレベルを形成するために使用される
交換可能ユニットの図、 第７図は、プログラム開発者パッケージング・ツールの
メニューを示す図、 第８図ないし第２０図は、プログラム・パッケージ・、
ツール及びアプリケーション・パッケージ・ツールの動
作を示すフローチャートである。 第２１図は、アプリケーション・パッケージング・ツー
ルのメニューを示す図である。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　山　　本　　仁　　朗（外１名） 第２Ｂ巳 第４ｍ 第６１１ ノ入＆”Ｎ’１（１）／（Ｕへ 系６Ｂ国 １−　　　　　　　　　　　　　　　　　　　　　　　
　　　　Ｊ第７ＴｉＸ プロプ°ラヘ閉亮あハ・７．γ、ンングツー、し第２１
国 アブ！ノアーシヅン聞毛シ眉バ・ｌγ−シン７゛ヅーＩ
し第８田 某１１記 第１２回 第１６Ｉ２１ ＰＦＱ；に−ｆ；　：ｉ：定−１１４００第１９記 ＡＧ、ｆ；ｆ″＋　赳／２１６０）

Claims (3)

【特許請求の範囲】
1. （１） （ａ）第１のヘッダと、第１のボディをもち、該第１の
   ヘッダは第１の識別データを有してなる第１の交換可能
   ユニットと、 （ｂ）第２のヘッダと、第２のボディをもち、該第２の
   ヘッダは第２の識別データを有してなる第２の交換可能
   ユニットとを具備し、 （ｃ）上記第１のボディが上記第２の識別データを有し
   、以て上記第１の交換可能ユニットを上記第２の交換可
   能ユニットに階層的に連結することが可能ならしめられ
   ることを特徴とする、 階層的プログラム構造体。
2. （２）１次機能と２次機能をもつプログラム・パッケー
   ジの作成方法において、 （ａ）上記２次機能を実行するために必要なオペレーシ
   ョナル・コードまたはデータをもつ第５レベルの交換可
   能ユニットを作成する段階と、（ｂ）上記２次機能のた
   めの第４レベルの交換可能ユニットを作成する段階と、 （ｃ）上記第４レベルの交換可能ユニットを上記第５レ
   ベルの交換可能ユニットに連結する段階と、（ｄ）上記
   １次機能のための第３レベルの交換可能ユニットを作成
   する段階と、 （ｅ）上記第３レベルの交換可能ユニットを上記第４レ
   ベルの交換可能ユニットに連結する段階と、（ｆ）第２
   レベルの交換可能ユニットを作成する段階と、 （ｇ）上記第２レベルの交換可能ユニットを上記第３レ
   ベルの交換可能ユニットに連続する段階とを有する、 プログラム・パッケージの作成方法。
3. （３）アプリケーション・パッケージの作成方法におい
   て、 （ａ）複数の１次機能と２次機能をもつ第１のプログラ
   ム・パッケージを選択する段階と、 （ｂ）複数の１次機能と２次機能をもつ第２のプログラ
   ム・パッケージを選択する段階と、 （ｃ）上記第１のプログラム・パッケージを上記第２の
   プログラム・パッケージと結合する段階と、（ｄ）上記
   アプリケーション・パッケージに収めるべき１次機能と
   ２次機能を上記第１及び第２のプログラム・パッケージ
   から選択する段階を有する、 アプリケーション・パッケージの作成方法。