以下の表には、それぞれのオプションの目的、パフォーマンス上の利点と欠点、および使用上の注意 (該当する場合) が示されています。
| コンパイラー・オプション | 目的 | パフォーマンス上の長所 | パフォーマンス上の欠点 | 使用上の注意 |
|---|---|---|---|---|
| ARITH(EXTEND)
(ARITH を参照) |
10 進数で許可される最大桁数を増やします | 一般には、ありません。 | ARITH(EXTEND) を使用すると、中間結果が大きくなるため、すべての 10 進数データ型でパフォーマンスがいくらか低下します。 | どれほど低下するかは、使用する 10 進数データの量に直接左右されます。 |
| AWO | バッファーおよび装置スペースの最適使用を入手する | このオプションを使用すると、パフォーマンス上の節約になります。これは、入出力を処理するためにデータ管理サービスを呼び出す回数が減るからです。 | 一般には、ありません。 | AWO を使用すると、APPLY WRITE-ONLY 節は、V モード・レコードを持つ物理順次のプログラム内において、すべてのファイルに適用されます。 |
| DATA(31)
(DATA を参照) |
DFSMS に、16MB 境界より上の QSAM バッファーを割り振らせる (RENT および DATA(31) コンパイラー・オプションを使用して) | 拡張形式 QSAM データ・セットは大量のバッファーを必要とする可能性があるので、制限のないストレージでバッファーを割り振ると、仮想記憶域の制約問題を回避することができます。 | 一般には、ありません。 | DFSMS が備わった z/OS システムでは、アプリケーションがストライプ拡張形式 QSAM データ・セットを使用する場合には、RENT および DATA(31) コンパイラー・オプションを使用して、16MB 境界より上のストレージから、QSAM ファイル用の入出力バッファーを割り振らせるようにしてください。 |
| DYNAM | サブプログラム (CALL ステートメントによって呼び出された) が実行時に動的にロードされるようにする | サブプログラムが変更されても、アプリケーションをリンク・エディットする必要がないので、サブプログラムの保守が容易になります。 | 呼び出しは言語環境プログラム・ルーチンを介して行う必要があるので、ちょっとしたパフォーマンス・ペナルティーがあります。 | 不要になった仮想記憶域を解放するには、CANCEL ステートメントを出してください。 |
| FASTSRT | IBM DFSORT プロダクト (または同等の製品) がすべての入出力を処理することを指定する | 各レコードの処理後に Enterprise COBOL に戻るというオーバーヘッドを排除します。 | なし | 直接作業ファイルをソート作業ファイルとして使用する場合は、FASTSRT の使用をお勧めします。すべてのソートがこのオプションに適格とは限りません。 |
| NUMPROC(PFD)
(NUMPROC を参照) |
数値演算の無効な符号処理をバイパスさせる | 数値比較に関してはかなり効率のよいコードを生成します。 | COMP-3 および DISPLAY 数値データ項目へのほとんどの参照では、NUMPROC(PFD) を使用すると、符号を「調整」するための余分のコードの生成が禁止されます。この余分のコードは、他のタイプの最適化も妨げる可能性があります。NUMPROC(MIG) および NUMPROC(NOPFD) を使用した場合は、余分のコードが生成されます。 | NUMPROC(PFD) を使用すると、コンパイラーは、データには正しい符号があるので、データは符号「修正」プロセスを迂回すると想定します。すべての外部データ・ファイルに COMP-3 または DISPLAY 符号付き数値データの適切な符号が入っているとは限らないので、NUMPROC(PFD) が不適切なプログラムもあります。パフォーマンスを重視するアプリケーションについては、NUMPROC(PFD) の使用をお勧めします。 |
| OPTIMIZE(STD)
(OPTIMIZE を参照) |
パフォーマンスがよくなるように、生成されるコードを最適化する | 一般に、もっと効率的な実行時コードが得られます。 | コンパイル時間が長くなること。OPTIMIZE は、NOOPTIMIZE に比べ、コンパイルにかかる処理時間が長くなります。 | NOOPTIMIZE は通常、頻繁なコンパイルが必要となるプログラム開発の段階で使用されます。これにより、シンボリック・デバッグも可能になります。 実稼働用には、OPTIMIZE の使用をお勧めします。 |
| OPTIMIZE(FULL)
(OPTIMIZE を参照) |
生成されたコードをパフォーマンスがよくなるように最適化し、さら に DATA DIVISION も最適化する | 一般に、もっと効率的な実行時コードが得られ、ストレージ使用量が少なくなります。 | コンパイル時間が長くなること。OPTIMIZE は、NOOPTIMIZE に比べ、コンパイルにかかる処理時間が長くなります。 | OPT(FULL) は未使用データ項目を削除しますが、それは、ダンプ読み取り用マーカーとしてのみ使用されるタイム・スタンプまたはデータ項目の場合には、望ましくないことがあります。 |
| RENT | 再入可能プログラムを生成する | プログラムを共用ストレージ (LPA/ELPA) に入れ、実行をより高速化することができます。 | プログラムを再入可能にするために追加のコードが生成されます。 | |
| RMODE(ANY)
(RMODE を参照) |
プログラムをどこにでもロードできるようにする | RMODE(ANY) と NORENT を使用すると、プログラムとその WORKING-STORAGE を 16MB 境界より上に置き、16MB 境界より下のストレージを解放することができます。 | 一般には、ありません。 | |
| NOSSRANGE
(SSRANGE を参照) |
すべてのテーブル参照および参照変更式が適切な範囲内にあるかどうかを検査する | SSRANGE は、テーブル参照を検査するための追加コードを生成します。NOSSRANGE を使用すると、コードは生成されません。 | なし | 一般に、テーブル参照のたびに検査する必要はなく、数度の検査だけで済む場合には、独自の検査をコーディングする方が、SSRANGE を使用するより速くなります。 CHECK(OFF) ランタイム・オプションを使用して、実行時に SSRANGE をオフにすることができます。パフォーマンスを重視するアプリケーションについては、NOSSRANGE の使用をお勧めします。 |
| TEST(NOHOOK) または
NOTEST
(TEST を参照) |
デバッグ・ツール をフルに活用するために必要な追加のオブジェクト・コードを回避するには、TEST(NOHOOK) または NOTEST を使用する。 TEST(NOHOOK) の場合は、SEP サブオプションを使用して、オブジェクト・コードのサイズをさらに縮小することができる。 | TEST(HOOK) を使用した場合は追加のコードが生成されるので、実動環境で使用すると、パフォーマンスが大きく低下する可能性があります。 | なし | サブオプション NOHOOK を含まないTEST は、コンパイラー・オプション NOOPT を強制的に有効にします。
実稼働の場合は、NOTEST または TEST(NOHOOK) を使用することをお勧めします。その際、SEP サブオプションの指定は任意です。
この結果、コンパイルされたフックではなく、オーバーレイ・フックとなります。 実稼働時、プログラムが異常終了したときにデータ項目のシンボリック・ダンプを定様式ダンプで取得したい場合は、TEST(NOHOOK) を使用してコンパイルします。その際、SEP サブオプションの指定は任意です。 |
| THREAD | 複数の POSIX スレッドまたは PL/I タスクを含む言語環境プログラムのエンクレーブで、プログラムを実行できるようにする | なし | シリアライゼーション・ロジックのオーバーヘッドがあるため、ちょっとしたパフォーマンス・ペナルティーがあります。 | これはスレッド化または非スレッド化環境に当てはまります。 |
| TRUNC(OPT)
(TRUNC を参照) |
算術演算の受信フィールドを切り捨てるためのコードの生成を回避する | 余分のコードを生成しないので、一般にパフォーマンスは向上します。 | TRUNC(BIN) と TRUNC(STD) はともに、BINARY データ項目が変更されるたびに、余分のコードを生成します。TRUNC(BIN) は、そのパフォーマンスについては COBOL for OS/390 & VM で改善されたとはいえ、上記のオプション中では最も低速のオプションです。 | TRUNC(STD) は標準 COBOL 85 に準拠しますが、TRUNC(BIN) および TRUNC(OPT) は準拠しません。TRUNC(OPT) を使用すると、コンパイラーは、データが PICTURE および USAGE の仕様に従っていると見なします。可能な場合は、TRUNC(OPT) を使用することをお勧めします。 |