| Application Server の使用 | 32 ビットモードおよび 64 ビットモードでの作業 | |
この章では、アプリケーションをパッケージ化する方法をいくつか説明します。それぞれの方法が、プログラムのコンパイル、およびリンクプロセスに与える影響についても説明します。
この章の以降の項で使用する「アプリケーション」という言葉は、これからユーザに提供しようとする製品を指し、「プログラム」という言葉は、アプリケーションを作るプログラム自体を特に示す場合に使用します。
Server Express を使用すると、次の要素を組み合わせてアプリケーションを作成することができます。
ここで説明するオプションには、それぞれにメリットとデメリットがあります。
アプリケーション作成の際には、次の点を検討してください。
次の章では、実行可能ファイルのタイプについて説明し、アプリケーションの様々なパッケージ化方法を示します。
Cob ユーティリティの使用方法については、『COBOL システムインターフェイス (Cob)』の章を参照してください。 64 ビットモードで使用している場合は、『32 ビットモードおよび 64 ビットモードでの作業』の章も参照してください。
呼び出し可能な共有オブジェクトは、オペレーティングシステム形式の実行可能ファイルで、Server Express が提供する COBOL ランタイムシステムで動的にロードされます。これらのファイルの使用方法については、『呼び出し可能ファイル形式を使用したアプリケーションのパッケージ化』の章を参照してください。
中間コードファイル、および生成コードファイルは独自形式の実行可能ファイルで、Server Express が提供する COBOL ランタイムシステムで動的にロードされます。 これらのファイルの使用方法については、『呼び出し可能ファイル形式を使用したアプリケーションのパッケージ化』の章を参照してください。
共有ライブラリは、システムにリンクされるファイルで、実行可能ファイルにリンク可能です。
システムの実行可能ファイルとは、コンパイル、およびリンクにより、オペレーティングシステムの形式で作成された実行可能ファイルです。
プログラムのコンパイルに関しては、『コンパイラの使用』の章を参照してください。呼び出し可能な共有オブジェクトに関する詳細は、『呼び出し可能な共有オブジェクト』の章を参照してください。プログラムのリンクに関する詳細は、『システムの実行可能プログラムへのリンク』の章を参照してください。
実行可能ファイルのタイプに関する詳細については、以降の項で説明します。
いずれのファイル形式を使用した場合も、アプリケーションとともに Application Server を提供する必要があります。Application Server に関しては、『Application Serverの使用』の章を参照してください。
呼び出し可能な共有オブジェクトファイルは、オペレーティングシステム形式のファイルで、複数のプロセスで共有できます。たとえば、2 つの異なるシステムの実行可能プログラムにより、呼び出し可能な共有オブジェクトとして作成された 1 つのサブプログラムが同時に呼び出された場合は、そのプログラムが 1 度だけロードされ、呼び出された時に実行されます。オペレーティングシステムは、手続き型コードを共有し、プロセスごとに異なるデータ領域を作成します。
呼び出し可能な共有オブジェクトは、ランタイムシステムが動的にロードして実行します。呼び出し可能な共有オブジェクトは解釈されないため、通常の場合、これらの実行時間は、中間コード、または生成コードよりも早くなります。
呼び出し可能な共有オブジェクトファイルの名前には、myprog.so のように拡張子、 .so が付けられます。
呼び出し可能な共有オブジェクトファイルは、cob -z
コマンドを使用して作成します。詳細は、『COBOL システムインターフェイス (Cob)』 および『呼び出し可能な共有オブジェクト』の章を参照してください。
中間コードファイルは、コンパイラでプログラムの構文チェックを実行すると作成されます。これらのファイルは、CPU にも、オペレーティングシステムにも依存していないため、他のプラットフォームへの移植性が高くなっています。中間コードファイルは、複数のプロセスで共有することができません。中間コードにコンパイルされた 1 つのサブプログラムを、2 つの異なる実行可能プログラムで同時に呼び出した場合は、そのサブプログラムが、それぞれのプロセスの仮想メモリ空間に 1 つずつコピーされて実行されます。
中間コードファイルは、ランタイムシステムが動的にロードして解釈します。中間コードはランタイムシステムで解釈されるため、通常の場合、他の実行可能形式のファイルよりも、実行に時間がかかります。
中間コードファイルの名前には、 myprog.int のように、拡張子、 .int が付けられます。「中間コードファイル」は「.int ファイル」とも呼ばれます。
中間コードファイルは、プログラムの構文チェックを実行すると作成されます。構文チェックはコンパイルプロセスの段階の 1 つです。プログラムは、cob
-i コマンドを使用してコンパイルされます。詳細は、『COBOL
システムインターフェイス (Cob)』の章を参照してください。
生成コードファイルは、指定により、コンパイラの生成フェーズで作成されます。これらのファイルは同じ系列の CPUに移植可能ですが、オペレーティングシステムに依存します。生成コードファイルは複数のプロセスで共有することはできません。生成コードにコンパイルされた 1 つのサブプログラムを、2 つの異なるプログラムが同時に呼び出した場合は、そのサブプログラムが、それぞれのプロセスの仮想メモリ空間に別々にロードされ、実行されます。
生成コードファイルは、ランタイムシステムが動的にロードして実行します。生成コードファイルの実行速度は、多くの場合、.int ファイルよりも早くなります。
生成コードファイルの名前には、myprog.gnt のように拡張子、 .gnt が付きます。 「生成コードファイル」は「.gnt ファイル」とも呼ばれます。
プログラムは、cob -u コマンドを使用してコンパイルします。詳細については、『COBOL
システムインターフェイス (Cob)』の章を参照してください。
共有ライブラリファイルは、システムの実行可能ファイルにリンクされます。これらはシステムの実行可能プログラムをロードして実行する際にロードされます。共有ライブラリファイル自体は実行することができません。これらのファイルは、複数のプロセスで共有することができます。共有ライブラリの複数のコピーが同時に使用されると、オペレーティングシステムは手続き型コードを共有し、プロセスごとに異なるデータ領域を作成します。これは、共有ライブラリファイルにリンクされた COBOL の手続き型コードを共有した場合も同様です。
共有ライブラリファイルの名前には、libmyprog.so のように、先頭に lib が付加され、拡張子、 .so が付けられます。HP/UX の場合は、拡張子が .sl になります。
プログラムは、cob -Z コマンドを使用してコンパイルします。詳細は、『COBOL
システムインターフェイス (Cob)』 および『システムの実行可能プログラムへのリンク』の章を参照してください。
システムの実行可能ファイルは、オペレーティングシステム形式のファイルです。これらのファイルはプロセス間で共有できます。システムの実行可能プログラムの複数のコピーが同時に実行されると、オペレーティングシステムは手続き型コードを共有し、プロセスごとに異なるデータ領域を作成します。 これは、システムの実行可能ファイルにリンクされた COBOL の手続き型コードを共有した場合も同様です。
システムの実行可能ファイルは、オペレーティングシステムによりロードされ、オペレーティングシステムはこれらのファイルを実行するプロセスを新規に作成します。CALL 文を使用して、COBOL からこれらのファイルを呼び出すことはできません。
通常の場合、システムの実行可能ファイルの名前には拡張子が付けられず、a.out ファイルと呼ばれることもあります。
プログラムは、cob -x コマンドを使用してコンパイルします。詳細は、『COBOL
システムインターフェイス (Cob)』および『システムの実行可能プログラムへのリンク』の章を参照してください。
Server Express で使用できる実行可能ファイルの各形式の主な利点を、次の表にまとめています。
| 利点 | ファイルタイプ |
|---|---|
| オペレーティングシステム形式 | 呼び出し可能な共有オブジェクト システムの実行可能ファイル 共有ライブラリ |
| 高速実行が可能 | 呼び出し可能な共有オブジェクト 生成コード システムの実行可能ファイル 共有ライブラリ |
| 共有可能 | 呼び出し可能な共有オブジェクト システムの実行可能ファイル 共有ライブラリ |
| 複合言語アプリケーションで使用可能 | 呼び出し可能な共有オブジェクト システムの実行可能ファイル 共有ライブラリ |
| 動的にロードされ、COBOL プログラムから呼び出されたときにのみ実行 | 呼び出し可能な共有オブジェクト 生成コード 中間コード |
| 他のプロセッサやオペレーティングシステムに移植可能 | 中間コード |
| アプリケーション全体を再リンクせずに、簡単にサブモジュールが置換可能 | 呼び出し可能な共有オブジェクト 生成コード 中間コード 共有ライブラリ |
プログラムのデバッグ時には、すべてのファイル形式が使用できます。
ここまでの項からもわかるように、独自形式、およびシステム形式の実行可能ファイルを使用して、様々な方法で、要求を満たすアプリケーションを作成することができます。
アプリケーションをパッケージ化する最良の方法は、共有ライブラリにリンクしたシステムの実行可能ファイルを作成し、そこから、呼び出し可能な共有オブジェクトファイルを呼び出すことです。
多くの COBOL システムでは、コンパイル後、リンカユーティリティ を使用して、サブプログラムやサポートモジュールをプログラムにリンクする必要があります。Server Express では、リンクを行なうこともできますが、リンク作業は不要です。(リンクの概要については、この章の 『COBOL のリンクオプション』の項で説明します)。
Server Express を使用すると、呼び出し可能な共有オブジェクト、.int ファイル、および .gnt ファイルを、システムの実行可能ファイルにリンクしなくても実行できます。これは、COBOL dynamic loader で実現します (詳細は、『動的ロード』 の項を参照してください)。 動的ロードは、次の動作の際に実行されます。
dynamic loader を使用するには、作成したプログラムを、呼び出し可能な共有オブジェクト、中間コードファイル、または生成コードファイルにコンパイルする必要があります。これらのファイルの形式は、呼び出し可能ファイル形式と呼ばれます。これらのファイルへのコンパイルは、次のコマンドで実行します。
cob -z myprog.cbl
上記のコマンドを使用すると、呼び出し可能な共有オブジェクト myprog.so が作成されます。
cob -u myprog.cbl
上記のコマンドを使用すると、myprog.gnt が作成されます。
呼び出し可能な共有オブジェクト、.int ファイル、および .gnt ファイルは、実行する際に、システムの実行可能ファイルにリンクする必要がありません。しかし、これらのファイルは、COBOL ランタイムシステムにリンクされている、システムの実行可能プログラムから呼び出す必要があります。Server Express には、デフォルトのトリガプログラム cobrun (マルチスレッドアプリケーションの場合は cobrun_t) が用意されています。 下の図は、呼び出し可能形式のファイル、および cobrun トリガを使って、アプリケーションをパッケージ化する方法を示します。
図 3-1: トリガ 実行可能プログラム
cobrun および cobrun_t の使用方法に関する詳細は、『実行』 の章を参照してください。マルチスレッドプログラミングに関する詳細については、『Multi-threaded Programming』 を参照してください。
必要な場合は、独自のシステムの実行可能ファイルを作成して、作成したアプリケーションを起動させることができます。 システムの実行可能ファイルの作成に関する詳細は、『システムの実行可能プログラムへのリンク』の章を参照してください。
UNIX システムには、プログラムのビルドと実行に必要な基本的な機能が備わっています。ご使用の COBOL システムはこの機能を使用し、更に、COBOL 固有の追加機能を提供します。リンカは、オペレーティングシステムの実行可能形式でプログラムを作成するのに使用します。
リンクされたプログラムは、次のいずれかのオブジェクト形式の副プログラムです。
すべてのプログラム、副プログラム、またはサポートルーチンは、これらのタイプのファイルにリンクできます。
リンクされたファイルタイプの手続き型コードは、複数のユーザで同時に共有されます。呼び出し可能な共有オブジェクト、および共有ライブラリの手続き型コードも、複数のアプリケーションで共有されます。
COBOL アプリケーションを実行する場合はまず、UNIX システム標準の実行可能ファイルを起動します。このファイルは、システムのローダがロードし、制御が主入口点に渡されます。 アプリケーションが実行されると、制御は、呼び出された副プログラムに明示的に渡されるか、暗黙的に実行時サポートルーチンに渡されます。 主入口点の指定方法に関する詳細は、『COBOL システムインターフェイス (Cob)』の章を参照してください。
実行時に指定されて、最初に入口点から実行される実行可能ファイルは、一般的に、実行可能ランタイムシステム (RTS) と呼ばれます。リンク時に、最初の入口点が組みこまれている実行可能ファイルは、一般的に、実行可能アプリケーションと呼ばれます。 デフォルトの実行可能 RTS は、次のようになっています。
アプリケーション内のプログラムをリンクするには、Cob ユーティリティを使用します。Cob を使用すると、プログラムを様々なシステム、または言語のサポートルーチンに、あるいは、必要な場合は、実行時に呼び出されたサブルーチンにリンクできます。
詳細は、『システムの実行可能プログラムへのリンク』の章を参照してください。
UNIX では通常、リンク時にプログラムを呼び出す場合に、呼び出すプログラムの名前と、プログラムそのものが必要です。しかし、Server Express を使用すると、プログラムは、最初にシステムの実行可能プログラムにリンクしなくても実行することができます。これは、これらのプログラムを動的にロードすることができるためです。COBOL ランタイムシステムは、動的にロード可能な COBOL プログラム、または副プログラムをロードして実行することができる dynamic loader を提供します。
動的にロードできる実行可能ファイルのタイプは、呼び出し可能な共有オブジェクト、.int ファイル、および .gnt ファイルです。 呼び出し可能な共有オブジェクトの場合は、どんなタイプのプログラム、またはサブプログラム（たとえば、COBOL、C、または C++ など）でも、動的にロードできます。.int ファイル、および .gnt ファイルの場合は、COBOL のプログラム、または副プログラムのみを動的にロードできます。これらのファイルは、システムの実行可能プログラムにリンクする必要はありませんが、システムの実行可能プログラムをトリガとして使用する必要があります。Server Express が提供する cobrun プログラム (マルチスレッドアプリケーションの場合は cobrun_t) をトリガとして使用できます (詳細は、『実行』 の章を参照してください)。
動的ロードでロードされたプログラム、およびサブモジュールは、システムの実行可能プログラムにリンクする必要はありません。これにより、コンパイル -> 実行プロセスが高速化され、実行時の柔軟性が高くなります。たとえば、動的にロードしたサブモジュールを、アプリケーションの他の部分に影響を与えずに、修正して再コンパイルすることができます。この時、システムの実行可能プログラムに再リンクする必要はありません。
COBOL システムを使用すると、プログラムの呼び出しを、呼び出されたプログラムがリンク時に使用可能であれば、直接そのプログラムにリンクすることも、あるいは、dynamic loader にリンクすることもできます。dynamic loader は、指定された名前のプログラムを実行時に検索し、必要に応じて動的にロードします。
プログラム名は、リテラル定数、またはデータ項目の値として、dynamic loader に渡されます。dynamic loader は次の場所で、指定された名前のプログラムを検索します。
プログラムをリンクして直接参照するか、動的にロードするかは、cob コマンドでフラグを使用して明示的に指定することができます。明示的な指定がない場合、cob コマンドは、COBOL ソースによるプログラムの呼び出し方法に応じたデフォルトのアクションを実行します。
CALL データ名 文を使用すると、呼び出される副プログラム名を実行時に動的に指定し、動的ロードを実行することができます。CALL
文の ON EXCEPTION 句で、副プログラムがロードできなかった場合の実行アクションを指定します。 リンクされたプログラムは、動的にロードされるプログラムとは異なり、例外が発生することは考えられません。そのため、ON
EXCEPTION 句があると、動的ロードが行われます。
リンクされたプログラムで、ON EXCEPTION 句を含まない CALL リテラル 文を使用した場合にのみ、動的ロードではなく、直接参照が実行されます。パフォーマンスは、直接参照の方が動的ロードよりも優れています。
動的ロードを伴う方法でプログラムが起動されると、COBOL ランタイムシステムの dynamic loader が起動します。dynamic loader
は、ディスクからプログラムを動的にロードする前にまず、ロードされたプログラム、サブプログラム、およびサポートルーチンのリストを検索します。 呼び出されたプログラムがすでにリンクされている場合や、一旦ロードされた後、CANCEL
されていないなどの理由でロードされた状態にある場合は、dynamic loader がそのプログラムに制御を渡します。 プログラムがまだロードされていない場合は、dynamic
loader が動的にロード可能な適切なファイルを検索します。
検索順序は、環境変数、 COBPATH および、実行時調整可能変数、 program_search_order によって決まります。
呼び出し可能な共有オブジェクトも
LIBPATH、SHLIB_PATH、または LD_LIBRARY_PATH 環境変数の影響を受けます。環境変数に関する詳細は、付録 『Micro
Focus の環境変数』を、実行時調整可能変数に関する詳細は、『実行時の構成』の章を参照してください。
動的にロード可能なプログラムには、次の 3 つのタイプがあります。呼び出し可能な共有オブジェクトファイル、.int ファイル、 および .gnt ファイルです。 dynamic loader でプログラムがロードされる場合、プログラムのロードには優先順位があります。まず、呼び出し可能な共有オブジェクトファイル がロードされ、次に .gnt ファイル、最後に .int ファイルがロードされます。 CALL 文では、プログラムファイルの名前、拡張子、およびパスを 参照することができますが、パスや拡張子は省略し、プログラム名に相当する動的にロード可能なファイルの基本名のみを指定することをお奨めします。
COBOL システムでは、1 つのプログラムに対して様々な形式のファイルが認められ、1 つのプログラムに関連するすべてのファイルは、ファイル名に同じ基本名を共有するものとされています。 この基本名がプログラム名として認識されます。 COBOL システムでは、プログラム名を使ってプログラムを識別しますが、dynamic loader も、これを使ってプログラムを検索します。 それぞれのプログラムには、プログラム名と同じ名前の主入口点があります。
プログラム内の主入口点は、実行開始位置で、デフォルトでは、プログラムの実行がそこから開始されます。 これは、手続き部のヘッダーの後に来る、最初の非宣言文です。 COBOL 言語では、PROGRAM-ID 段落でプログラム名を指定します。指定したプログラム名が主入口点の名前になります。
ENTRY 文 (詳細は、『言語リファレンス』を参照してください) を使って、複数の入口点の名前を追加することができます。これらの入口点から、プログラムを起動することもできます。
プログラムはプログラム名で識別されますが、リンク、または動的ロードによって一度ロードされたプログラムについては、その入口点名を CALL 文で使用できます。CANCEL
文で参照できるのはプログラム名のみです。CANCEL 文の参照先プログラムがシステムの実行可能プログラムにリンクされていない場合は、CANCEL 文の実行時にそのプログラムはアンロードされます。
『ランタイムスイッチの詳細』の章の、『-l
ランタイムスイッチ』も参照してください。
快適に使用するために、PROGRAM-ID 段落を指定する場合は、プログラム名とプログラムのソースファイルの基本名を同一にすることをお奨めします。
複数のプログラムをコンパイルして、1 つの呼び出し可能な共有オブジェクト、システムの実行可能プログラム、または共有ライブラリを作成することができます。 この場合に、cob に -e フラグが指定されていないと、コマンド行の最初のプログラムの基本名が主入口点になります。
ロングファイル名をサポートするファイルシステムでは、動的にロード可能なプログラムのファイル名の、先頭の 30 字が一意である必要があります。 これは、入口点名の長さ制限を超えるファイル名は、リンクまたは動的にロードされた際に、この制限長に切り捨てられるためです。 このため、プログラムのソースファイル名は 30 字以下にする方が安全です。 『プログラマーズガイド − アプリケーション作成』の『システム要件とプログラミング制限』の章も参照してください。
プログラムへのアクセスは、直接参照で直接アクセスした方が、dynamic loader を使用してアクセスするよりも効率が良く、これは、システムの実行可能プログラムにリンクされているプログラムの場合も同じです。 動的ロードが必要なプログラムは、ディスクから読み取られる必要があります。プログラムが .int ファイル、または .gnt ファイルの場合は、プログラム内のその後のすべての呼び出しで dynamic loader が使用されるため、パフォーマンスは更に悪くなります。 しかし、dynamic loader を使用すると、ビルド時や実行時の柔軟性が著しく改善されます。
プログラムの動的ロードは、開発環境で特に便利です。 動的ロードでは、リンクプロセスが不要になり、編集 -> コンパイル -> 実行サイクルの高速化が可能です。 さらに、デバッグの際にも、変更を加えた副プログラムを、それ以外のアプリケーションを実行したままで再読み込みできるという柔軟性を備えています。
通常は、単一ユーザが使用するアプリケーションの実行環境で、空きメモリに制限がある場合は、動的にロードされた .int ファイル、または .gnt ファイルを使った方が良い場合もあります。 動的ロードを使用すると、Server Express dynamic loader のメモリ管理オプションがすべて使用できます。これを使うとアプリケーションで必要とされるメモリ容量を制御することができます。
複数のユーザが使用するアプリケーションの実行環境では、メモリ容量の面でも、パフォーマンスでも、 システムの実行可能プログラム、リンクされた共有ライブラリ、呼び出し可能な共有オブジェクトの任意の組み合わせ、またはすべてで構成されているアプリケーショの方が、一般に有利です。 サブプログラムが大きい場合や数が多い場合は、これらを結合して、呼び出し可能な共有オブジェクトにまとめることができます。また、パフォーマンスよりもサイズが重要な場合は、.int ファイル、または .gnt ファイルにまとめることもできます。 パフォーマンスに関する詳細は、『プログラマーズガイド − アプリケーション作成』 の『プログラム開発』 の章を参照してください。
Copyright(C) 2001 Micro Focus. All rights reserved.
本書ならびに、使用されている固有の商標と商品名
は国際法で保護されています。
| アプリケーションサーバーの使用 | 32 ビットモードおよび 64 ビットモードでの作業 | |