リファレンス・ガイド

COBOLコンバータ

この章には次のトピックが含まれます:

COBOLコンバータの概要

このツールの役割は、ソース・プラットフォーム(z/OS、IBM COBOLダイアレクト)で実行しているCOBOLプログラムを、アプリケーションの動作を維持したままでターゲット・プラットフォーム(UNIXまたはLinux、Micro Focus COBOLダイアレクトまたはCOBOL-IT)で実行するCOBOLプログラムに変換することです。変換の実行は、他のOracle Tuxedo Application Rehosting Workbench (Tuxedo ART Workbench)ツールによって変換または生成される他のコンポーネントと関連しています。

この項の目的は、次のようなCOBOLコンバータのすべての機能を正確に説明することです。

スコープ

Refine COBOLコンバータにより、次のトランスフォーメーションが1回の実行で処理されます。

結果として生成されるプログラムをコンパイルすると、ソース・プラットフォームと同じ動作でターゲット・プラットフォームで実行できます。ただし、「スコープ 」で説明する一部のケースを除きます。

入力

COBOLコンバータで入力として扱われるものを次に示します。

出力

次の出力が生成されます。

変換フェーズ

COBOL変換プロセスは論理的に次の2つのフェーズに分かれます。

個別変換フェーズは、いくつかのプログラムに対して同時に実行できますが、コピー調整フェーズはグローバルなコピー・ファイル・ベースを更新するため、1つのプロセスとしてできれば増分的に実行する必要があります。こうすることで、COBOLコンバータの可能な実行モードを指示できます。詳細は、「コマンド行構文」を参照してください。

制約および制限

定義では、Tuxedo ART Workbench COBOLコンバータは、Tuxedo ART Workbench COBOLカタロガで受け入れたプログラムのみを受け入れます。エントリにはそれ以外の制約はありません。

結果として生成されるプログラムは、ターゲット・プラットフォームでコンパイルして実行すると、次に示す潜在的な問題を除いてソース・プラットフォームの場合と同じように動作します。これらの問題はオラクル社が責任を負うものではありません。

この項では、次の節について説明します。

LinuxプラットフォームでのCOMP-5タイプの使用

Tuxedo ART Workbench COBOLコンバータは、移植可能なバイナリ整数型(BINARY、COMP、COMP-4)をネイティブ・バイナリ型COMP-5に変換します。これは、トランザクション処理フレームワークなどの、C言語で記述されたサブプログラムとの互換性を保証し(Tuxedo ART Workbenchリファレンス・ガイドのCICSに関する項を参照)、実行パフォーマンスを向上させるためです。このために問題が発生する可能性があるのは、ターゲット・プラットフォームのエンディアンがソース・プラットフォームと異なる場合、特にLinuxとIntelのプラットフォームの場合です(Intelプロセッサ・ラインはリトルエンディアンですが、zSeriesプロセッサはビッグエンディアンです。他の多くのプロセッサ、IBM pSeriesやHP-RISCなどもビッグエンディアンです)。実際、このケースでは、バイナリ変数のバイト・オーダーはソース・プラットフォームと同様に保持されます。バイナリ変数が文字(PIC X)変数で再定義され、この再定義を使用してバイナリ変数の個々のバイトにアクセスする場合には、動作が変わる恐れがあります。例:

WORKING-STORAGE SECTION.

01 FILLER.

	02 BINVAR                   PIC S9(9) COMP.

	02 CHARVAR REDEFINES BINVAR PIC X(4).

PROCEDURE DIVISION.

	...

	MOVE ... TO BINVAR

	IF CHARVAR(1:1) = ... THEN ...

z/OSハードウェアなどビッグエンディアン・マシンでは、CHARVAR(1:1)にはBINVARの最も重要な(上位オーダー)バイトが含まれます。ただし、リトルエンディアン・マシンでは、同じコードCHARVAR(1:1)にはBINVARの最も重要でない(下位オーダー)バイトが含まれます。これにより確実に動作は変化し、目にする結果もおそらく異なります。ただし、Tuxedo ART Workbench COBOLコンバータでは、このような状況の箇所をすべて検出して修正することはできません(たとえば、上の例は明らかなものですが、多くの複雑なケースが存在します)。これらは手動で処理する必要があります。

COMP-5型およびTRUNCコンパイラ・オプションの使用

前の段落で説明したように、Tuxedo ART Workbench COBOLコンバータは移植可能なバイナリ整数型(BINARY、COMP、COMP-4)をネイティブ・バイナリ型COMP-5に変換します。エンディアンの問題に加え、ソース・プラットフォームで(デフォルトの)TRUNC(STD)オプションでコンパイルされたアプリケーションでは動作が変化する別の問題が発生することがあります。このオプションはMicro Focus COBOLではTRUNCオプションまたはCOBOL-ITではBINARY-TRUNCATEオプションに相当します。実際、ソース・プラットフォームとターゲット・プラットフォームの両方で移植可能なバイナリ型はこのオプションの対象となりますが、ネイティブ型は対象となりません。通常、バイナリ整数型の変数は、実用的な値ではなく制御値(ループ・カウンタ、配列索引など)を保持するために使用されるため、実際に動作の変化が見られる確率は非常に低いと考えられます。いずれにしても、動作の変化が見られた場合には、Tuxedo ART Workbenchユーザーが変化を受け入れるか、手動で修正する(たとえば、少数の変数を選択して元のバイナリ型に戻す)かの対応を取ることになります。

EBCDICからASCIIへの変換の問題

ターゲット・プラットフォームでのネイティブ・ユーティリティ・プログラム(たとえば端末でのデータ・ファイルのブラウズ)の効率性と互換性の理由から、Tuxedo ART Workbenchで実行される移行の基本的な設計選択肢の1つは、ソース・プラットフォームのネイティブ文字セット(EBCDICまたはその派生形)から、ターゲット・プラットフォームのネイティブ文字セット(ASCIIまたはその派生形)へのテキスト(アルファベット)データの変換です。ただし、この常識的な決定により移行プロセスに重要な影響が及ぼされます。

ほとんどのケースでは、これらの指示を正しく守ると、結果として生成されるアプリケーションは問題なく実行します。ただし、効果的なソリューションが見つからない問題が1つあります。EBCDIC文字セットとASCII文字セットの照合順序がまったく同じではないということです。このために、ソートや文字列比較において動作が異なる可能性があります。多くの場合、ソートまたは比較するデータは名前(英字)または日付(数値)のように同種であるため問題はありません。アクセント記号が付いた文字など特殊な文字のソート順が若干変わる可能性がありますが、大きな問題ではありません。ただし、文字と数字が混在するデータをソートまたは比較するとき、動作の違いが明らかになることがあります。EBCDICでは文字が数字よりも先にソートされますが、ASCIIでは文字は数字の後にソートされるためです。典型的な例は、数字と文字の両方を含むデータ(アカウント番号など)のキーの計算です。これはCOBOL変数の内容に関連する動的な問題であり、変数の宣言に関連する静的な問題ではないため、COBOLコンバータではこうした問題を処理できません。

リテラル定数: 文字または数値

前述のように、COBOLプログラムの文字列または文字リテラル(16進文字リテラルを含む)はEBCDIC-to-ASCII変換の対象になります。これは、これらのリテラルがテキストまたはテキストの一部を示す場合には適切です。ただし、場合によってはこのような定数値が(数値)コード(ファイル・ステータス・コード、条件コード、CICS関連値など)を示すことがあります。このケースでは、通常はEBCDIC-to-ASCII変換をこれらの値に適用するのは適切ではありません。しかしながら、COBOLコンバータは他の自動処理ツールと同様に、COBOLの変数またはリテラルのセマンティックな性質を確実に推測することはできないため、自分自身ではこれらの例外を処理できません。これは、ポストトランスレーションを使用して手動で行う必要があります。「post-translation-file句」を参照してください。

浮動小数点変数の使用

ソースの浮動小数点変数型(COMP-1およびCOMP-2)は、ターゲット・プラットフォームの同じ型に変換されます。このため、Micro Focus COBOLコンパイラおよびランタイム・システムでは、浮動小数点データ(COMP-1およびCOMP-2変数)をIBM16進形式またはネイティブ(IEEE 754)形式のどちらでも使用できます。NONATIVEFLOATINGPOINTオプションがコンパイル時に設定されると(デフォルトはtrue)、浮動小数点形式が実行時に選択されます。これは、次のようにMAINFRAME_FLOATING_POINT環境変数またはmainframe_floating_pointチューニング変数(あるいは両方)によって変わります。

1つ目のケースでは、動作の違いがわからないようにMicro Focus COBOLランタイム・システムによって処理されます。ただし、この形式の処理はすべてソフトウェア内で行われるためランタイム性能の負担になります。一方、ネイティブ形式はプロセッサが直接対応します。さらに、この形式はOracle浮動小数点データ型(BINARY_FLOATおよびBINARY_DOUBLE)と直接の互換性がなく、Oracleエンジンによって他の数値型に変換できません。実際、このデータ型はopaque列(それぞれRAW(4)およびRAW(8))に格納するしかありません。このような値はSQLコードでは使用できません。

結果として、移行時またはその後で、ネイティブIEEE754浮動小数点の使用を検討することをお薦めします。これは、少なくともOracleに対しては、高い効率性、移植性(国際標準で定義)および互換性を備えています。次に理由を示します。

元のアプリケーションと移行したアプリケーションの動作の違いに気づく場合がありますが、動作の違いの大部分は受け入れられるものです。浮動小数点の計算は数学的な正確さからいえば概算であることに留意してください。ターゲット・マシンで得られる概算値はソース・マシンでの概算値と異なるということです。

ソース・プラットフォームとターゲット・プラットフォームの両方に含まれる範囲に同じ計算を行うと、表示される結果(DISPLAYによる出力)の相対的な誤差は、COMP-1変数の使用時は常に10^-6未満、COMP-2変数の使用時は常に10^-14未満となりました。これは、すべてが問題なく機能するという決定的な証明にはなりませんが、少なくとも有望な目安といえます。

このような結果から、COMP-1変数をCOMP-2変数で置き換えることで、ごくわずかな誤差を除きソースと同じ動作をターゲットで常に再現できると考えられます。

LINE SEQUENTIALファイルでのREWRITE操作

デフォルトでは、ソース・プラットフォームでSEQUENTIALであるデータ・ファイルは、ターゲット・プラットフォームでは使用しやすいLINE SEQUENTIALファイルに変換されます。一般的にこれは適切な選択であり、このようなファイルはターゲットCOBOLシステムで十分にサポートされます。ただし、難点があります。こうしたファイルは本質的に可変レコード・サイズであるため、REWRITE操作によって予測できない結果が生じて動作が変わる可能性があります(Micro Focus COBOLおよびCOBOL-ITのドキュメントを参照)。特定のSEQUENTIALファイルをLINE SEQUENTIALに変換したとき、そのファイルに対するREWRITE操作が必ず成功するかどうか不確かな場合は、SEQUENTIALのまま変更しないことをお薦めします。このためには、後で示すpure-seq-map-file句で参照される構成サブファイルに記述を挿入します。

この問題の処理を簡易にするため、将来のバージョンでは、REWRITE操作が生じるSEQUENTIAL論理ファイルのリストがTuxedo ART Workbenchカタロガによって生成されるようになります。

ポインタの操作

ポインタ・サイズの変更: 再定義の認識

ソース・プラットフォームでは、型がPOINTERの変数は、メモリー内の4バイト(32ビット)を占めます。64ビットのオペレーティング・システムに基づくすべてのサポート対象ターゲット・プラットフォームでは、このような変数は8バイトを占めます。これにより、次のように様々な動作の違いが発生することがありますが、オラクル社が責任を負うものではありません。

NULLアドレスのLinkage-Section引数

ソース・プラットフォームとターゲット・プラットフォームの両方で、かわりに明示的なOMITTED項目が渡された、あるいは呼出し元が呼出し先の想定よりも少ない引数を渡したために、実際には呼出し元によって渡されないプログラム・パラメータ(Linkage Sectionに定義され、Procedure DivisionのUSING句に指定される)は、呼出し先ではNULLアドレスを持つようになります。したがって、パラメータの値にアクセスする前にパラメータのADDRESSがNULLかどうかをチェックすることは非常に有効であり、お薦めする方法です。

この状況およびこれに伴う動作の変化を自動的に処理することは不可能です。コンバータによってアドレス・チェックを挿入できても、テストで無効になったときに何もできません。さらに、この問題で実際に影響を受けるサブプログラムとパラメータのセットは、すべてのサブプログラムとパラメータのごく一部であるため、そうしたアドレス・チェックをそのすべてに挿入するには手間がかかります。これも、ポストトランスレーションを使用して手動で処理する必要があります。

NULLポインタ値の表現

NULLポインタ値の表現は、プラットフォームごとに異なる可能性があります。特にソース・プラットフォームとターゲット・プラットフォームの間では、他のすべてのポインタ値のようにサイズが同じにならないというだけでも異なります。この結果、この値の特定の表現を想定しているすべてのプログラムは(たとえば、バイナリ整数値との間でのキャストなど)は、プラットフォームごとに動作が異なる可能性があります。COBOLコンバータが自動的にこの問題を処理することはできません。手動で問題を処理する必要があります。いずれにしても、マシン依存の処理はお薦めしません。

SQL文のQUERYNO

QUERYNO句はDB2のみでサポートされており、Oracle DBはサポートしていません。ターゲットDBがOracle RDBMSの場合、SQL文からQUERYNOが自動的に削除されます。

入力コンポーネントおよび前提条件の説明

入力コンポーネントは、カタロガによる解析が終了したアセット内のすべてのCOBOLプログラムです。実際、COBOLコンバータはプログラムのソース・ファイルではなくPOBファイルをロードします。カタロガによって課された制約(ネスト・プログラムなしなど、「カタロガ」を参照)に加え、COBOL変換を試行する前には次のルールに従う必要があります。

構成ファイルの説明

システム記述ファイル

システム記述ファイルには、処理するアセットの全ソース・ファイルの場所、タイプ、可能性のある依存関係が記述されます。このように、このファイルは、カタロガのみでなくCOBOLコンバータも含めたすべてのTuxedo ART Workbenchツールがこれらのソース・ファイルや対応するコンポーネントにアクセスするために不可欠です。

メイン変換構成ファイル

このファイルは、必須コマンド行オプション-cまたは-configを使用してCOBOLコンバータに指定されます。変換に影響する様々なスカラー・パラメータが定義され、大規模な構成データ(ファイル名変更など)を含む下位ファイルが指定されます。

一般的な構文

メイン変換構成ファイルの内容は自由な形式で指定できます。キーワードで始まりピリオドで終了する句を任意の順序で指定します。1つ以上の引数を指定する句と、引数を指定しないブール句があります。キーワードは大文字小文字が区別されないシンボルです。引数は、整数、シンボルまたは(大文字小文字が区別される)文字列です。空白や改行などはコメントです。コメントは構成ファイルには次の2つの方法で記述できます。

target-dir句

構文

Target-dir : dir-path .

この句は、ターゲット・ファイル(プログラムとコピー・ファイルの両方)の完全な階層を含むディレクトリの場所を指定します。ソース・プログラムA/B/name.extがアセットのルート・ディレクトリにある場合(システム記述ファイルに定義)、対応するターゲット・プログラムはターゲット・ディレクトリにA/B/name.extとして配置されます(ファイル拡張子は変わる可能性があります。後続の内容を参照してください)。コピー・ファイルにも同じ仕組みが適用されますが、ターゲット・パスはMaster-copy/A/B/name.extとなります(拡張子は変わる可能性があります)。Master-copyディレクトリはコピー調整プロセスに関連します。「コマンド行構文」を参照してください。

Sql-rules句

構文

Sql-rules : target-sql-syntax.

この句は、ターゲットSQL構文を指定します。値は、Oracle、db2luwまたはnoneです。db2luwのサポートには大きな制限があります。

値がnoneの場合、ソース・ファイル内のsqlコードは変換されません。ターゲット・コンポーネントにそのまま転送されます。この句のデフォルト値はoracleです。後者の場合は、構成ファイルでsql-rulesをoracleに設定する必要はありません。

keep-same-file-names、target-program-extensionおよびtarget-copy-extension句

構文

keep-same-file-names.

target-program-extension : extension . (または) tpe : extension .

target-copy-extension : extension . (または) tce : extension .

これらの句は、変換されるファイル(メイン・ソース・ファイル)とコピー・ファイルのファイル拡張子の決定方法を次のように指示します。

Verbosity-Level句

構文

verbosity-level : level .

この句は、COBOLコンバータが実行ログに書き込む詳細のレベルを指定します。デフォルト値2は詳細、これよりも高い値はさらに詳細、値1では重要な(エラー)メッセージのみが表示されます。

deferred-copy-reconcil句

構文

deferred-copy-reconcil.

または

deferred-crp.

または

dcrp.

この句は、変換が終了するまでコピー調整プロセスcrpを延期することを指定します。こうすることで、COBOL変換が複数の同時プロセスで実行できます。デフォルトでは、この句を指定しないと、コピー調整プロセスは、各プログラムの変換が終了するたびすぐに増分的に実行され、単一プロセス実行になります。詳細は、次のコピー調整プロセスを参照してください。

force-translation句

構文

force-translation.

この句は、COBOLコンバータが、FATALエラーを含むプログラムも変換(の試行)するように指示します。ただし、保証はありません。正しくない結果が生成されたり、コンバータが異常終了したりする可能性があります。デフォルトでは、この場合、コンバータはプログラムの処理を拒否し、次のプログラムに進みます。

rename-copy-map-file句

構文

rename-copy-map-file : file-path .

この句は、コピー・ファイルの名前変更の情報を含む下位構成ファイルの場所を指定します。下記の「copy-renaming構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

rename-call-map-file句

構文

rename-call-map-file : file-path .

この句は、サブプログラムと呼出しの名前変更の情報を含む下位構成ファイルの場所を指定します。「Call-Renaming構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

post-translation-file句

構文

post-translation-file : file-path .

この句は、Tuxedo ART Workbenchコンバータの後で適用する手動変換の説明を含む下位構成ファイルの場所を指定します。「Post-Translation構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

on-size-error-call句

構文

on-size-error-call: proc-name .

この句は、プログラムを確実に終了させるために呼び出すプロシージャの名前をシンボルとして指定します。この名前は、IBMコンパイラが終了を構成するがターゲット・コンパイラは終了を強制しない状況(算術文でのサイズ・エラーなど)で、終了を強制するために使用されます。デフォルトの名前はABORTです。

hexa-map-file句

構文

hexa-map-file : file-path .

この句は、16進形式の文字に適用するEBCDIC-to-ASCII変換を含む下位構成ファイルの場所を指定します。「16進変換構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

conv-ctrl-file句およびalt-key-file句

これら2つの句は一緒に指定します。

構文

conv-ctrl-file : file-pathまたはconv-ctrl-list-file : file-path .

alt-key-file : file-path

これらの句は、file-to-Oracle変換に関する情報を含む2つの下位構成ファイルの場所を指定します。これらのファイル(Conv-ctrl-fileまたはConv-ctrl-list-fileおよびAlt-keyファイル)は、Tuxedo ART Workbench File-to-Oracle変換ツールによって生成されます。「File-to-RDBMS構成ファイル」を参照してください。

最初の2つの句のうち1つだけを指定する必要があります。conv-ctrl-file句またはconv-ctrl-list-file句のいずれかです。両方ではありません。

ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

RDBMS-conversion-file句

構文

RDBMS-conversion-file : file-path .

この句は、リレーショナルDBMS変換(DB2からOracle)の情報を含む最上位の下位構成ファイルの場所を指定します。詳細は「RDBMS-conversion構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

keywords-file句

構文

keywords-file : file-path .

この句は、ターゲットのCOBOLダイアレクトでキーワードまたは予約語に相当するCOBOL識別子の名前変更の情報を含む下位構成ファイルの場所を指定します。「keywordsファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

accept-dateおよびaccept-day句

構文

accept-date: date-entry-name .

accept-day: day-entry-name .

これらの句は、ACCEPT … FROM DATE文およびACCEPT … FROM DAY文を置換するサブプログラム名を指定します。次に文の例を示します。

ACCEPT MY-DATE FROM DATE

これは次の文で置換されます。

CALL "DATE-ENTRY-NAME" USING MY-DATE BY VALUE LENGTH OF MY-DATE

これにより、プログラムが現在の日付を取得する方法を管理しやすくなり柔軟性も高まります。たとえば、リグレッション・テストの際に、移行されたプログラムをソース・プログラムが実行されたときと同じ現在日付で実行する必要があります。これらのサブプログラム(Tuxedo ART Workbenchユーザーによって要件に基づいて提供される)によってこの処理が可能になります。

これらの句のいずれかを指定しないと、対応する文は変換されません。ターゲットCOBOLのパラメータ(Micro Focus COBOLランタイム・システムのcurrent_day、current_monthおよびcurrent_yearパラメータなど)を使用して、ACCEPT文によって返される日付を制御できます。Micro Focus COBOL/COBOL-ITのドキュメントを参照してください。

sql-stored-procedures-file句

構文

sql-stored-procedures-file: file-path .

この句は、COBOLから直接呼び出されるDB2ストアド・プロシージャのリストを含む下位構成ファイルの場所を指定します。詳細は、「stored-procedureファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

remove-sql-qualifier句

構文

remove-sql-qualifier.

この句は、スキーマ修飾子を含むすべてのSQL識別子からスキーマ修飾子を除去するトランスフォーメーション・ルールを有効にします。このため、結果として生成されるプログラムは暗黙のスキーマ修飾に依存します。

activate-cics-rules句

構文

activate-cics-rules.

この句を指定すると、COBOLコンバータによって、現在の実行で処理中のすべてのプログラムにEXEC CICS文を標準化するルールが強制的に適用され、Oracle Tuxedo Application Runtime for CICS環境(CICSプリプロセッサなど)でプログラムを使用する準備が行われます。

pure-seq-map-file句

構文

pure-seq-map-file: file-path .

または

purely-sequential-map-file: file-path .

この句は、LINE SEQUENTIALに変換せずにSEQUENTIALのまま保存(記録)されるSEQUENTIAL論理ファイルのリストを含む下位構成ファイルの場所を指定します。詳細は、「purely-sequential構成ファイル」を参照してください。file-pathは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

dont-print-what-string句

構文

dont-print-what-string .

この句を指定すると、変換のタイムスタンプとコンバータのバージョン情報を含むwhat-stringがこの実行で出力されません(通常、この情報はコンバータによってすべての変換済ファイルの先頭に挿入されます)。Tuxedo ART Workbenchを使用してアプリケーションが移行されたという事実を隠す必要がないかぎり、これはほとんど使用されません。

remove-empty-copies句

構文

remove-empty-copies .またはrec.

この句を指定すると、変換後に役立つCOBOLコードを含まなくなったコピー・ファイルを参照するCOPYディレクティブがコメント・アウトされます。デフォルトでは、これらのディレクティブはアクティブなままになります。たとえば、これは、データベース表に移行されるファイルのFDパラグラフ全体を定義するコピー・ファイルに適用されます。

sql-return-codes-file句

構文

sql-return-codes-file: file-path .

この句は、DB2とOracleの対応するSQLCODE値の追加の組合せを含む下位構成ファイルの場所を指定します。詳細は「sql-return-codes構成ファイル」を参照してください。file-pathは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

list-of-cics-file句

構文

list-of-cics-file: file-path.

この句は、ユーザー定義のCICSファイルのリストが含まれる下位構成ファイルの場所を指定します。詳細は、「list-of-cics構成ファイル」を参照してください。file-pathは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Tuxedo ART Workbenchツールでの共通の方法)。

force-add-cics-stub-for-dynamic-calls句

構文

force-add-cics-stub-for-dynamic-calls.

この句を指定すると、その呼出し先がワークベンチで解決できない場合、CICSスタブ(DFHEIBLKおよびDFHCOMMAREA)が動的呼出しの引数に追加されます。

repair-sql-pair-declare-section-stmt Clause

構文

repair-sql-pair-declare-section-stmt.

COBOLプログラムの場合、埋込みSQL文DECLAREとEND DECLAREはペアにする必要がありますが、END DECLAREを使用しなくてもメインフレームで動作できる場合があります。オープン・プラットフォーム上では、2つの文をペアにする必要があります。

この句を指定すると、END DECLARE文が前のDECLARE文にない場合に、COBOLコンバータによって強制的に追加されます。

copy-renaming構成ファイル

このファイルは、rename-copy-map-file句に対応します。内容はCSV形式で、セミコロンが区切り文字として使用されています。各行の形式を次に示します。

original-copy-name;original-library-name;new-copy-name. 

すべての名前は、COBOLと同様の大文字小文字が区別されないシンボルです。この行の意味は次のとおりです。

COPY ORIGINAL-COPY-NAME OF ORIGINAL-LIBRARY-NAME { REPLACING … }

プログラムで検出されると、次のように置き換えられます。

COPY NEW-COPY-NAME { REPLACING … }

ライブラリ名は不便なためターゲット・プラットフォームでは使用されないことに注意してください。検索パスを使用する方が便利です。COBCPY環境変数を参照してください。original-library-nameフィールドが空の場合、このルールでは、次の形式の修飾されていないディレクティブを置換します。

COPY ORIGINAL-COPY-NAME { REPLACING … }

同じ名前変更がコピー・ファイルそのものにも適用されます。コンバータが、このディレクティブで参照されるコピー・ファイルをターゲットのプライベート・コピー・ディレクトリに出力するとき、新しい名前で出力します(コピーの調整の詳細は下記を参照してください)。

rename-copy-map-file句がないとき、またはこのファイルが空の場合、コピーの名前変更は行われません。エラーとなるのは、ファイルが見つからないか読み取れない場合、または同一のoriginal-copy-name;original-library-nameの組合せがファイルの別の行で別のnew-copy-namesに関連付けられている場合です。このケースでは、コンバータはエラー・メッセージで停止し、プログラムの変換は行われません。ただし、同じディレクトリにある異なる2つのコピー・ファイルの名前が同じターゲット・ファイル名に変更されるかどうかはチェックされないことに注意してください。原則としては、これはコピー調整プロセスで適切に処理されるはずですが、保証のかぎりではありません。

Call-Renaming構成ファイル

このファイルは、前に説明したrename-call-map-file句に対応します。内容はCSV形式で、セミコロンが区切り文字です。各行の形式を次に示します。

original-call-name.new-call-name. 

すべての名前は、COBOLと同様の大文字小文字が区別されないシンボルです。この行の意味は次のとおりです。

CALL "ORIGINAL-CALL-NAME" { USING … }

プログラムで検出されると、次のように置き換えられます。

CALL "NEW-CALL-NAME" { USING … }

コンバータは、直接構造体(VALUE、MOVEなど)を使用する動的呼出しで使用される変数に関連するリテラル文字列の名前変更も試行します。理由は明白ですが、本当に動的な呼出しを処理することはできません。呼出し先名が、複雑な操作(STRINGなど)を使用して計算される場合、opaqueコンテナを介して転送される場合、あるいは呼出し元プログラムの外部から取得される場合(たとえば、ファイルから読み取るかパラメータとして渡される)などです。このような状況は手動で処理する必要があります。

同じ名前変更が、呼び出されたサブプログラムとそのエントリ・ポイントにも適用されます。コンバータが、名前変更ファイルにリストされた元の名前のいずれかとベース名が一致するプログラムをターゲット・ディレクトリに出力するとき、対応する新しい名前を付けて出力します。同様に、元の名前のいずれかと文字列が一致する引数を含むENTRY文では、その文字列が新しい名前に変換されます。

rename-call-map-file句がないとき、またはこのファイルが空の場合、呼出しの名前変更は行われません。エラーとなるのは、ファイルが見つからないか読み取れない場合、または同一のoriginal-call-nameがファイルの別の行で別のnew-call-namesに関連付けられている場合です。このケースでは、コンバータはエラー・メッセージで停止し、プログラムの変換は行われません。ただし、同じディレクトリにある異なる2つのサブプログラムの名前が同じターゲット・ファイル名に変更されるかどうかはチェックされないことに注意してください。

Post-Translation構成ファイル

このファイルは、post-translation-file句に対応します。リスト10-2に示すように、一連のルールが含まれます。

rule rule_name
filter [
(+|-)program_name_regexp
]

transform [
	source_lines_block

]
into [
	target_lines_block
]

このようなルールのセマンティクスは単純です。プログラムの(ベース)名が、プラス記号のprogram_name_regexpのいずれかと一致するがマイナス記号とは一致しないとき、source_lines_blockと一致する行ブロックが検出されると、target_lines_blockによって置換されます。rule_nameは、変換アプリケーションに関連付けられるコメントで使用されます。詳細は、ポストトランスレータの説明を参照してください。

post-translationファイルには必要なだけのルールを任意の順序で含めることができます(ただし、2つのsource_lines_blocksが重なるとき、またはsource_lines_blockとtarget_lines_blockが重なるときは、ポストトランスレータの動作は定義されません)。

コメントはシャープ記号(#)から行の最後までです。ルールの間、4つの句の間、ルール名の後であれば、どこにでも挿入できます。コメントを角カッコで囲んだフィルタの内側またはtransformブロックやintoブロックに挿入すると、コメントではなくブロックの内容として認識されます。

リスト10-3に示すように、program_name_regexpは、*.cblやBATCH/[A-F][D-Z]*などの正規表現です。

regle add-wait 
filtre [ 
+*.cbl 
] 

transform [ 
	DISPLAY "Welcome..." 
	DISPLAY "Begin..." 
] 
into [ 
	DISPLAY "Welcome..." 
	DISPLAY "Wait..." 
	DISPLAY "Begin..." 
	DISPLAY "Wait..." 
] 

リスト10-4に示すように、前述の例では、2つのWait...文字列が変換済*.cblファイルに追加されます。

	*{ Post-Translation add-wait 
	*     DISPLAY "Welcome..." 
	*     DISPLAY "Begin..." 
		DISPLAY "Welcome..." 
		DISPLAY "Wait..." 
		DISPLAY "Begin..." 
		DISPLAY "Wait..." 
	*} Post-Translation

16進変換構成ファイル

このファイルは、前述のhexa-map-file句に対応します。内容は、16進形式の文字に適用するEBCDIC-to-ASCII変換表です(テキスト形式の文字は、ソース・ファイルそのものと同時に変換されます)。構文は、セミコロンが区切り文字の単純なCSVファイルです。各行の形式を次に示します。

source-hexa-code;target-hexa-code, 

各16進コードは通常どおり2つの16進文字(0-9、A-F)で書き込まれます。この変換表のセマンティクスでは、ソース・ファイルの16進リテラルがこの表のソース・コードと一致しない場合は、そのまま変換されずに残されます。このような変換は埋込みSQLコードに対しても機能します。コンバータでは変換表そのものの一貫性(source-hexa-codeまたはtarget-hexa-codeが重複していることや、実際にはEBCDIC-to-ASCII変換を記述していること)はチェックされないことに注意してください。

hexa-mapファイルの生成方法

Oracle Tuxedo Application Rehosting Workbenchでは、CONVERTMWコピー・ファイルに基づいてhexa-mapファイルを生成するスクリプトを使用できます。「コードセットの変換」の章の「COBOL CONVERTMW.cpyファイルの使用」を参照してください。

hexa-mapファイルを生成するスクリプトは、次のディレクトリに配置されます。

REFINEDIR/scripts/

スクリプト名は次のとおりです。

convert-hexa-copy-to-map.sh

構文

REFINEDIR/scripts/convert-hexa-copy-to-map.sh convertmw_copy_file

convertmw_copy_file: location of the CONVERTMW.cpy file

スクリプトにより、現在のディレクトリ(PARAMディレクトリの方がより適した選択です)にtr-hexa.mapファイルが自動的に生成されます。この生成されたファイル名は、hexa-map-file属性とともにfile-path値として使用する必要があります。

正常終了すると、リターン・コード0が戻されます。それ以外の場合、表示されたメッセージおよびtr-hexa.mapファイルの内容を参照してください。

エラー・メッセージ

WBART-1001:

WBART-1003:

File-to-RDBMS構成ファイル

これらのファイルはconv-ctrl-file句およびalt-key-file句に対応します。これらには、file-to-RDBMS変換に関する情報が含まれます。たとえば、どの論理ファイル(FD)をRDBMS表に変換するかを定義するための情報です(実際、論理ファイルが関連する物理ファイルがそのようなDB表に変換されるため)。これらのファイルはTuxedo ART Workbench File-to-Oracle変換ツールによって自動的に生成されるため、手動で変更しないでください。内容をさらにここで指定することはありません。

RDBMS-conversion構成ファイル

これらのファイルは、前述のRDBMS-conversion-file句に対応します。含まれる情報には次のように2つのレベルでアクセスできます。

keywordsファイル

このファイルは、keywords-file句に対応します。内容は、セミコロンが区切り文字として使用されるLISPのような表です。各行の形式を次に示します。

old-name;new-name. 

このような行により、すべてのプログラムにおける名前がold-nameであるすべてのCOBOL識別子(変数名、パラグラフ名など)は、名前がnew-nameに変更されます。これは、ターゲットのCOBOLダイアレクトでキーワードまたは予約語に相当する名前(TESTなど)に関して必要ですが、リエンジニアリングの目的で単純な識別子を名前変更するときにも役立ちます。

stored-procedureファイル

このファイルはsql-stored-procedures-file句に対応します。内容は、1行に1つずつ記述されたサブプログラム名のリストです。これらの名前のうち1つがCOBOL CALL文に含まれると、SQL CALL文で置換されます。さらに、CALLのパラメータの宣言(ある場合)がSQL文で使用できるように調整されます。

purely-sequential構成ファイル

このファイルは、pure-seq-map-file句に対応します。内容は、セミコロンが区切り文字として使用されるCSV表です。各行の形式を次に示します。

program-name;FD-name

名前は両方ともシンボルです。このような行は、ソース・プラットフォームで(レコード)SEQUENTIALであると仮定される特定の論理ファイル(所定のプログラムの所定のFD)が、ターゲット・プラットフォームでLINE SEQUENTIALに変換されないようにします。つまり、レコードSEQUENTIALファイルのまま変化しません。こうすることで、このファイルは標準のターゲットプラットフォーム・ユーティリティでの処理に対応しにくくなりますが、無制限のREWRITE操作をサポートします(前のLINE SEQUENTIALファイルに対するREWRITE操作に関する項を参照してください)。これは、z/OSプラットフォームからバイナリ形式で交換されるファイルでも有効です。

sql-return-codes構成ファイル

このファイルは、sql-return-codes-file句に対応します。内容は、セミコロンが区切り文字として使用されるCSV表です。各行の形式を次に示します。

DB2-sqlcode-value;Oracle-sqlcode-value

値は両方とも正または負の整数です。このような行により、特徴的なDB2 SQLCODE値を対応するOracle SQLCODE値にマップするために使用される変換表に値のペアが追加されます。この変換表は、次のファイルを読み取ったように初期化されます。

+100;+1403

-810;-1422

-803;-1

-530;-2291

-516;-1002

-501;-1001

-407;-1451

-305;-1405

-180;-1820

-181;-1821

-811;-2112

-204;-942

-911;-51 

-911;-60 

-532;-2292 

もちろん、値0は0にマップされます。

list-of-cics構成ファイル

このファイルは、前述のlist-of-cics-file句に対応します。その内容は、1行に1プログラムのCICSプログラムの名前です。このファイルに定義されたプログラムは、CICSプログラムとみなされます。CICSプログラム(MAIN1)に、次のコードの断片があると仮定します。

CALL "SUB1". 

CALL "SUB2".

SUB1とSUB2は、両方ともCICSプログラムです。しかし、パフォーマンスを向上させるため、MAIN1、SUB1、SUB2を別々のプロジェクト、たとえば、MAIN1とSUB1をプロジェクト1、SUB2をプロジェクト2に分割することもあります。この場合、ART Workbenchは、プロジェクト1ではSUB2がCICSプログラムであることがわからないため、前述のコードを次のように変更します。

CALL "SUB1" USING  DFHEIBLK DFHCOMMAREA. 

CALL "SUB2".

しかし、期待されるターゲット・コードは次のものです。

CALL "SUB1" USING  DFHEIBLK DFHCOMMAREA.

CALL "SUB2" USING  DFHEIBLK DFHCOMMAREA.

この例を処理するには、SUB2をプロジェクト1のlist-of-cics構成ファイル内に構成します。

出力ファイルの説明

変換されるプログラムとコピー・ファイル

ネーミング方法

前述したように、Tuxedo ART Workbench COBOLコンバータの主な目的は、変換されたCOBOLコンポーネントをソース・ファイルの形式で生成することです。ソース・ルート・ディレクトリ内のメイン・プログラム・ファイルの階層とターゲット・ルート・ディレクトリ内のメイン・プログラム・ファイルの階層には、1対1の直接の対応があります。ファイル名に関するかぎり、異なる可能性があるのは、CALL-renamingマップとターゲットのprogram-file拡張子の選択によるもののみです。「rename-call-map-file句」および「keep-same-file-names、target-program-extensionおよびtarget-copy-extension句」を参照してください。これは、ターゲットのコピー・ファイルについても該当しますが、次の点に注意してください。

トランスフォーメーション・コメント

ターゲット・プラットフォームのCOBOLとソース・プラットフォームのCOBOLが大きく異なるわけではなく、原則としてCOBOLの変換は容易なプロセスです。このプロセスが翻訳ではなく変換と呼ばれるのはそのためです。実際、変換されたファイル(メイン・ファイルまたはコピー・ファイル)が対応するソース・ファイルと異なるのは、ごく少数の箇所のみです。内容の大部分は何も影響を受けずに、ソース・ファイルとまったく同じ状態でターゲット・ファイルに再生成されます。ただし、異なる場所は特定のトランスフォーメーション・コメントで示されます。

コードの変更

なんらかのトランスフォーメーションが実際に行われた場所では、コンバータによって、トランスフォーメーションの影響を説明するトランスフォーメーション・コメントが挿入されます。影響を受けるコードの内容は次のとおりです。

コードの追加

ルールによっては、既存のコードが変更されるだけでなく、離れた場所にまったく新しいコードが挿入されることがあります。たとえば、Working-Storage Sectionでの中間変数の宣言などです。このケースでは、プログラム内の影響を受ける領域は次のとおりです。

コードの削除

ルールによってコードが変更されるのではなくただ削除されると、プログラム内の影響を受ける領域には、変更されるコードと同じ内容が配置されますが、新しいコードの部分は空になります。

コードの移動

ルールによっては、プログラム内のある場所から別の場所にコードが移動されます。たとえば、ファイルがリレーショナルDB表に移行されると、対応するFDは削除され、それに含まれるデータ・レコードはWorking-Storage Sectionに移されます。このケースでは、元の場所のコードは削除として示され、新しい場所のコードは挿入として示されます。

その他のコメント・ルール

レイアウト

COBOLコンバータがトランスフォーメーション・ルールをコードの一部に適用するときは、元のバージョンと新しいバージョンの両方に存在するコード要素の移動を最小限に抑えることで、新しいコードでも同じレイアウトを保とうとします。また、コンバータが新しい要素(文や変数の宣言など)を挿入するとき、新しい要素の位置を前後の同種の要素とあわせようとします。このようなガイドラインに従うことで、変更されたコード行や新しいコード行が固定形式に対して長くなりすぎた場合、コンバータによって、一番右側の適切な位置(おそらく語と語の間)で行が切られ、残りは次の行に折り返されます。これは、右マージンに寄せて表示され、折り返された要素が論理的には前の行の一部であることが示されます。

その他の問題

メイン・プログラム・ファイルでREPLACING句で呼び出されるコピー・ファイルをコンバータが出力するとき、置換の影響を元に戻すために特別な処理を行います。ただし、コンバータによって実行されるトランスフォーメーションが、置換で生成されたテキストのいくつかに適用されるときは、コンバータが逆トランスフォーメーションを計算して、元の置換句を作成するのが非常に難しくなります。たとえば、COPY句によって「何か」が「無」によって置換されたとき、領域がトランスフォーメーションによって影響を受けていると、コンバータは「何か」の置換を戻すための「無」を見つけるのが極めて難しいことがあります。このようなケースでは手動での修正が必要になることがあります。ポストトランスレーション機能を使用して、繰り返し可能な方法で適用します。

コンパイラ・オプション

ソース・プログラムと、COBOLコンバータによって生成されたターゲット・プログラムの同一の動作を保証するには、これまでに説明した制限に加え、実際にターゲット・プログラムをコンパイルするときにコンパイラ・オプションの特定のセットを使用する必要があります。実際、ターゲットCOBOLコンパイラの一部のオプションでは実行コードの動作が変更します。Tuxedo ART Workbench COBOLコンバータによって適用されたトランスフォーメーションは、次に示すオプション・セットに合うようにここで調整します。別のオプション・セット(少なくとも相反するオプション・セット)でコンパイルされたプログラムはサポートされません。詳細は、Micro Focus COBOLのドキュメント、特にコンパイラ・ディレクティブ・ブックおよびCOBOL-IT Compiler Suite Enterprise Editionのリファレンス・マニュアルを参照してください。

Micro Focus COBOL

必須オプション

必須のコンパイラ・オプションを次に示します。それぞれについて、デフォルトで設定されるかどうかを記載し、簡単な説明とそのオプションが必要な理由を示します。

DIALECT"MF"(デフォルト)

CHARSET"ASCII"(デフォルト)

SOURCEFORMAT"FIXED"(デフォルト)

ALIGN"8"(デフォルト)

COMP5-BYTE-ORDER"NATIVE"(デフォルト)

P64(明示的に設定、Micro Focus COBOLインストール・セットアップ以外でのデフォルトの64ビット・モード・コンパイル)

SIGN"EBCDIC"(明示的に設定)

DEFAULTBYTE"00"(明示的に設定、前のオプションが指定される場合以外)

RWHARDPAGE(明示的に設定)

INDDまたはINDD"SYSIN80L"(明示的に設定)

OUTDDまたはOUTDD"SYSOUT80L"(明示的に設定)

HOSTARITHMETIC、HOST-NUMMOVE"2"、HOST-NUMCOMPARE"2"、ARITHMETIC"ENTCOBOL"、CHECKDIV"ENTCOBOL"、FP-ROUNDING"ENTCOBOL"、REMAINDER"2"(明示的に設定)

IBMCOMP(明示的に設定)

ODOSLIDE(明示的に設定)

PERFORM-TYPE"ENTCOBOL"(明示的に設定)

RDW(明示的に設定)

RECMODE"ENTCOBOL"(明示的に設定)

ASSIGN"EXTERNAL"(明示的に設定)

SYSPUNCH"80"(明示的に設定)

ZEROLENGTHFALSE(明示的に設定)

NOADV(デフォルト)

NOTRUNCCALLNAME(デフォルト)

NOTRUNCCOPY(デフォルト)

NOCOPYLBR(デフォルト)

NOSPZERO / NOSIGN-FIXUP(デフォルト)

REPORT-LINE"256"(デフォルト)

COPYEXT"cpy,cbl"(明示的に設定)

デフォルト・オプションと明示的なオプションおよび依存関係を考慮すると、必須オプション・リストを次のように開始できます。

P64 SIGN"EBCDIC" RWHARDPAGE INDD OUTDD HOSTARITHMETIC HOST-NUMMOVE"2"

HOST-NUMCOMPARE"2" ARITHMETIC"ENTCOBOL" CHECKDIV"ENTCOBOL"

FP-ROUNDING"ENTCOBOL" IBMCOMP ODOSLIDE PERFORM-TYPE"ENTCOBOL" RDW

RECMODE"ENTCOBOL" REMAINDER"2" ASSIGN"EXTERNAL" SYSPUNCH"80"

ZEROLENGTHFALSE COPYEXT"cpy,cbl"

このリストと相反するオプションを使用してコンパイルしたプログラムの保証はありません。Oracle Tuxedo Application Rehosting WorkbenchおよびOracle Tuxedo Application Runtime for CICSの現在のバージョンは、このオプション・リストに対して検証されています。

インストール依存のオプション

次のオプションは厳密には必要ではありませんが、大文字と小文字が混在するプログラムが含まれるアセットの処理に役立つことがあります。

FOLDCALLNAME"UPPER"(明示的に設定)

FOLDCOPYNAME"UPPER"(明示的に設定)

MAPNAME(明示的に設定)

これらの設定を試すことで、特定のアセットに適した組合せがわかります。たとえば、FOLDCALLNAME"UPPER"とMAPNAMEを一緒に設定すると、ソースコンパイラのオプションPGMNAME(COMPAT)の適切なエミュレーションを得られますが、このオプションの別の値をエミュレートする確実な方法はありません。

1.1.1.3 顧客の選択に基づくオプション

次のオプションはターゲット・アセットの動作に影響しますが、ARTシステムのユーザーの意思によって設定できます。

BOUNDおよびSSRANGE

TRUNC

APOSTおよびQUOTE

NOALTER

AREACHECK

NOBYTEMODEMOVE

DYNAM

NOFDCLEARおよびNOHOSTFD

NATIVEFLOATINGPOINT

NOSEG

STICKY-LINKAGE"2" / NOSTICKY-LINKAGE

1.1.1.4 コンパイル時の操作に影響するオプション

次のオプションはコンパイル・リストの生成のみに影響します。自由に選択できます。

LIST

SETTINGS

TRACE

WARNING

FLAG "dialect"

必須オプション

必須のコンパイラ・オプションを次に示します。それぞれについて、デフォルトで設定されるかどうかを記載し、簡単な説明とそのオプションが必要な理由を示します。

デフォルト・オプションと明示的なオプションおよび依存関係を考慮すると、必須オプション・リストを次のように開始できます。

P64 SIGN"EBCDIC" RWHARDPAGE INDD OUTDD HOSTARITHMETIC HOST-NUMMOVE"2"

HOST-NUMCOMPARE"2" ARITHMETIC"ENTCOBOL" CHECKDIV"ENTCOBOL"

FP-ROUNDING"ENTCOBOL" IBMCOMP ODOSLIDE PERFORM-TYPE"ENTCOBOL" RDW

RECMODE"ENTCOBOL" REMAINDER"2" ASSIGN"EXTERNAL" SYSPUNCH"80"

ZEROLENGTHFALSE COPYEXT"cpy,cbl"

インストール依存のオプション

次のオプションは厳密には必要ではありませんが、大文字と小文字が混在するプログラムが含まれるアセットの処理に役立つことがあります。

これらの設定を試すことで、特定のアセットに適した組合せがわかります。たとえば、FOLDCALLNAME"UPPER"とMAPNAMEを一緒に設定すると、ソースコンパイラのオプションPGMNAME(COMPAT)の適切なエミュレーションを得られますが、このオプションの別の値をエミュレートする確実な方法はありません。

顧客の選択に基づくオプション

次のオプションはターゲット・アセットの動作に影響しますが、ARTシステムのユーザーの意思によって設定できます。

コンパイル時の操作に影響するオプション

次のオプションはコンパイル・リストの生成のみに影響します。自由に選択できます。

ソース・プログラムと、COBOLコンバータによって生成されるターゲット・プログラムの動作の同一性を保証するには、これまでに説明した制限を考慮し、実際に有効なコンパイラ・オプションのセットを使用してターゲット・プログラムをコンパイルする必要があります。実際、Micro Focus COBOLコンパイラの一部のオプションにより、実行コードの動作が変わります。Rehosting Workbench COBOLコンバータによって適用されるトランスフォーメーションは、次に示すオプション・セットにより調整されます。別のオプション・セット(少なくとも相反するオプション・セット)でコンパイルされたプログラムはサポートされません。詳細は、Micro Focus COBOLのドキュメント、特に『コンパイラ・ディレクティブ・ブック』を参照してください。

動作に影響を及ぼす、設定が必須な主要オプションは、DIALECT"ENTCOBOL"です。実際に、このダイアレクト・オプションは、PERFORM-TYPE"ENTCOBOL"などの多くのサブオプションを設定します。このサブオプションにより、ターゲット・プログラムは、IBM Enterprise COBOL Compilerによってコンパイルされる元のソース・プログラムとできるかぎり同じように動作します。

ただし、Refine COBOLコンバータは、ターゲット・プラットフォームのネイティブ文字セット、すなわちASCIIを使用することで、Enterprise COBOLの基本の選択肢ではなくなります。このため、オプションCHARSET"ASCII"の設定が必須になります。反対に、DISPLAY数値のオーバーパンチ符号の表示にはIBM規約が使用されます。したがって、オプションSIGN"EBCDIC"を設定する必要があります。

ターゲット・プログラムが正しく動作することを保証するには、主要オプション以外の次のオプションを設定する必要があります。

COBOL-IT

ソースCOBOLコンパイラの動作を再現するために、COBOL-ITは、IBMと互換性のある構成ファイル(ibm.conf)を提供します。この構成ファイルは、ターゲットCOBOLアセットのコンパイルに使用されます。

構成ファイルibm.confで設定されているコンパイラ・オプションに加えて、ソースとターゲットのCOBOL環境間の互換性を向上させるために、少なくとも次のオプションを追加する必要があります。

External-mapping

Binary-truncate

Spzero

顧客のニーズに応じて、その他のコンパイラ・オプションを設定できます。COBOL-ITコンパイラ・オプションについては、COBOL-IT Compiler Suite Enterprise Editionのリファレンス・マニュアルを参照してください。

詳細処理

概要

COBOLコンバータが開始すると、様々な構成ファイルをメイン構成ファイルから順に読み取ってチェックします。この段階で矛盾が検出されると、1つ以上のエラー・メッセージが出力されてコンバータが終了します。それ以外の場合、コンバータはコマンド行オプションと構成ファイル・オプションの両方を使用し、処理する(ソース)プログラムのリストなどの内部パラメータを設定します。次に、これらのプログラムそれぞれを順に処理し始めます。各プログラムの処理を次に示します。

deferred-copy-reconcil句がコマンド行または構成ファイルに指定されている場合、コンバータは一度にいくつかの同時プロセスによって実行できます。それ以外の場合、これらの同時プロセスのコピー調整フェーズによって、最終的に調整されたコピー・ファイルのデータベースに対してのアクセス競合が発生して、異常終了することがあります。

コマンド行の構文

Refineランチャ・インタフェース

COBOLコンバータはrefineコマンドを実行するように設計されています。これは、一般的なOracle Tuxedo Application Rehosting Workbenchランチャであり、すべての重要なOracle Tuxedo Application Rehosting Workbenchツールの起動にも使用されます。このランチャは、これらのツール操作の様々な側面(実行ログの管理や増分または反復操作など)を扱います。

cobol-convertコマンド

形式

$REFINEDIR/refine cobol-convert [ launcher-options… ] \

	( -s | -system-desc-file ) system-desc-path \

   ( -c | -config ) main-config-file-path \

	[ other-specific-flags… ] \

	( source-file-path | ( -f | -file | -file-list-file ) file-of-files )…

オプション

必須オプションを次に示します。

( -s | -system-desc-file ) system-desc-path

( -c | -config ) main-config-file-path

処理するソース・プログラムを定義する一般オプションを次に示します。

source-file-path

( -f | -file | -file-list-file ) file-of-files

オプションの固有フラグまたはオプションを次に示します。

-dcrpまたは-deferred-copy-reconcil

-tpe extensionまたは-target-program-extension extension

-tce extensionまたは-target-copy-extension extension

-keepまたは-keep-same-file-names

-forceまたは-force-translation

-cicsまたは-activate-cics-rules

繰返しおよび増分操作

強力なコンピューティング・プラットフォームが容易に使用可能である今日であっても、Tuxedo ART Workbenchを使用した完全なアセットの処理は、依然として計算集中的で長時間の実行、メモリーを消費するタスクのままです。このため、Workbenchツールは、停止と再起動が容易に行えるように設計されています。makeに似たメカニズムのおかげで、一度終了した作業を繰り返す必要はありません。これにより、移行プロジェクトのすべてのフェースで効率的な操作が可能です。

最初の処理: 繰返し操作

最初のフェーズでは、完全に新しいアセットから、安定したアセットの最初の変換、生成のサイクルの終わりまで、makeに似たメカニズムが使用されて、次のような繰返し操作が可能になっています。

このモードが特に適しているのは、カタロガのようにアセット全体にグローバルな処理を行うツールまたはコマンドです。COBOLコンバータのようにコンポーネント対応のツールでも役立ちます。これはTuxedo ART Workbenchツールの通常モードでの動作であり、これを選択するのに何かをする必要はありません。

アセットでの変更: 増分操作

COBOLコンバータは、様々なコンポーネント(メイン・プログラム・ファイル)と対応する結果ファイル(POBファイルおよびターゲット・プログラム・ファイル)の間の依存関係を認識しています。この情報を使用して、アセットで変更が発生したときに増分的に対処することができます。たとえば、COBOLソース・ファイルが追加、変更または削除されると、カタロガは影響を受けたプログラムを再解析し、COBOLコンバータはそれらを再変換します。これもTuxedo ART Workbenchツールの通常モードでの動作であり、これを選択するのに何かをする必要はありません。