|
|
このツールの役割は、ソース・プラットフォーム(z/OS、IBM COBOLダイアレクト)で実行しているCOBOLプログラムを、アプリケーションの動作を維持したままでターゲット・プラットフォーム(UNIXまたはLinux、Micro-Focus COBOLダイアレクトまたはCOBOL-IT)で実行するCOBOLプログラムに変換することです。変換は、Oracle Tuxedo Application Rehosting Workbenchの他のツールによって変換または生成された他のコンポーネントと関連して行われます。
この項の目的は、次のようなCOBOLコンバータのすべての機能を正確に説明することです。
Refine COBOLコンバータにより、次のトランスフォーメーションが1回の実行で処理されます。
結果として生成されるプログラムをコンパイルすると、ソース・プラットフォームと同じ動作でターゲット・プラットフォームで実行できます。ただし、「スコープ 」で説明する一部のケースを除きます。
COBOLコンバータで入力として扱われるものを次に示します。
COBOL変換プロセスは論理的に次の2つのフェーズに分かれます。
個別変換フェーズは、いくつかのプログラムに対して同時に実行できますが、コピー調整フェーズはグローバルなコピー・ファイル・ベースを更新するため、1つのプロセスとしてできれば増分的に実行する必要があります。こうすることで、COBOLコンバータの可能な実行モードを指示できます。詳細は、「コマンドライン構文」を参照してください。
定義では、Rehosting Workbench COBOLコンバータは、Rehosting Workbench COBOLカタロガで受け入れたプログラムのみを受け入れます。エントリにはそれ以外の制約はありません。
結果として生成されるプログラムは、ターゲット・プラットフォームでコンパイルして実行すると、次に示す潜在的な問題を除いてソース・プラットフォームの場合と同じように動作します。これらの問題はオラクル社が責任を負うものではありません。
Oracle Tuxedo Application Rehosting Workbench COBOLコンバータは、移植可能なバイナリ整数型(BINARY、COMP、COMP-4)をネイティブ・バイナリ型COMP-5に変換します。これは、トランザクション処理フレームワークなどの、C言語で記述されたサブプログラムとの互換性を保証し(『Oracle Tuxedo Application Rehosting 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の最も重要でない(下位オーダー)バイトが含まれます。これにより確実に動作は変化し、目にする結果もおそらく異なります。ただし、Rehosting Workbench COBOLコンバータでは、このような状況の箇所をすべて検出して修正することはできません(たとえば、上の例は明らかなものですが、多くの複雑なケースが存在します)。これらは手動で処理する必要があります。
前の段落で説明したように、Rehosting Workbench COBOLコンバータは移植可能なバイナリ整数型(BINARY、COMP、COMP-4)をネイティブ・バイナリ型COMP-5に変換します。エンディアンの問題に加え、ソース・プラットフォームで(デフォルトの)TRUNC(STD)オプションでコンパイルされたアプリケーションでは動作が変化する別の問題が発生することがあります。このオプションはMicro Focus COBOLではTRUNCオプションまたはCOBOL-ITではBINARY-TRUNCATEオプションに相当します。実際、ソース・プラットフォームとターゲット・プラットフォームの両方で移植可能なバイナリ型はこのオプションの対象となりますが、ネイティブ型は対象となりません。通常、バイナリ整数型の変数は、実用的な値ではなく制御値(ループ・カウンタ、配列索引など)を保持するために使用されるため、実際に動作の変化が見られる確率は非常に低いと考えられます。いずれにしても、動作の変化が見られた場合には、Rehosting Workbenchユーザーが変化を受け入れるか、手動で修正する(たとえば、少数の変数を選択して元のバイナリ型に戻す)かの対応を取ることになります。
ターゲット・プラットフォームでのネイティブ・ユーティリティ・プログラム(たとえば端末でのデータ・ファイルのブラウズ)の効率性と互換性の理由から、Rehosting 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句」を参照してください。
| 注意: | 標準コピー・ファイルに文字リテラルとして定義されているCICS関連の値およびコードでは問題は発生しません。Rehosting WorkbenchおよびOracle Tuxedo Application Runtime for CICSには、これらのコピー・ファイルの事前に変換された検証済のバージョンが含まれているためです。問題が発生する可能性があるのはユーザー定義の定数のみです。 |
ソースの浮動小数点変数型(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ランタイム・システムによって処理されます。ただし、この形式の処理はすべてソフトウェア内で行われるためランタイム性能の負担になります。一方、ネイティブ形式はプロセッサが直接対応します。さらに、この形式は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変数で置き換えることで、ごくわずかな誤差を除きソースと同じ動作をターゲットで常に再現できると考えられます。
| 注意: | ネイティブIEEE 754形式の使用を決定する場合は、NATIVEFLOATINGPOINTコンパイラ・オプションの設定をお薦めします。これにより、実行時のオプションやチューニング変数にかかわらず、コンパイル時にこの形式の使用が強制されます。したがって、実行時の形式テストが不要になります。 |
デフォルトでは、ソース・プラットフォームでSEQUENTIALであるデータ・ファイルは、ターゲット・プラットフォームでは使用しやすいLINE SEQUENTIALファイルに変換されます。一般的にこれは適切な選択であり、このようなファイルはターゲットCOBOLシステムで十分にサポートされます。ただし、難点があります。こうしたファイルは本質的に可変レコード・サイズであるため、REWRITE操作によって予測できない結果が生じて動作が変わる可能性があります(Micro FocusおよびCOBOL-ITのドキュメントを参照)。特定のSEQUENTIALファイルをLINE SEQUENTIALに変換したとき、そのファイルに対するREWRITE操作が必ず成功するかどうか不確かな場合は、SEQUENTIALのまま変更しないことをお薦めします。このためには、後で示すpure-seq-map-file句で参照される構成サブファイルに記述を挿入します。
この問題の処理を簡易にするため、将来のバージョンでは、REWRITE操作で問題が生じるSEQUENTIAL論理ファイルのリストがRehosting Workbenchカタロガによって生成されるようになります。
ソース・プラットフォームでは、型がPOINTERの変数は、メモリー内の4バイト(32ビット)を占めます。64ビットのオペレーティング・システムに基づくすべてのサポート対象ターゲット・プラットフォームでは、このような変数は8バイトを占めます。これにより、次のように様々な動作の違いが発生することがありますが、オラクル社が責任を負うものではありません。
POINTER変数をPIC X(4)またはPIC S9(9) COMP変数によって直接再定義して、ポインタ値の表現を操作するために使用する場合は、再定義する変数とそのためのコードを手動で再作成する必要があります。ただし、このようなマシン依存の方法はお薦めしません。POINTER変数がバリアント(再定義)を含む構造の一部であり、1つのバリアントの特定の1フィールドが他のバリアントの他のフィールドと同様のアライメントになるように(同じ位置になるように)様々なバリアント(サブ構造)が設計されている場合、POINTER変数のサイズが変わった後でも、埋め合せるためのフィラーを挿入するなどしてこのプロパティを維持する必要があります。これも手動で処理する必要があります。このように意図されたアライメントは再定義全体で維持する必要があり、他の構造に移動するときにも維持する必要があります。POINTER変数が含まれる構造が、POINTER変数のサイズが変わる前に、その構造を十分に保持できる大きさの構造化されていないPIC X(…)変数に移される場合、サイズが変わった後もそのままかどうかを確認する必要があります。ソース・プラットフォームとターゲット・プラットフォームの両方で、かわりに明示的なOMITTED項目が渡された、あるいは呼出し元が呼出し先の想定よりも少ない引数を渡したために、実際には呼出し元によって渡されないプログラム・パラメータ(Linkage Sectionに定義され、Procedure DivisionのUSING句に指定される)は、呼出し先ではNULLアドレスを持つようになります。したがって、パラメータの値にアクセスする前にパラメータのADDRESSがNULLかどうかをチェックすることは非常に有効であり、お薦めする方法です。
この状況およびこれに伴う動作の変化を自動的に処理することは不可能です。コンバータによってアドレス・チェックを挿入できても、テストで無効になったときに何もできません。さらに、この問題で実際に影響を受けるサブプログラムとパラメータのセットは、すべてのサブプログラムとパラメータのごく一部であるため、そうしたアドレス・チェックをそのすべてに挿入するには手間がかかります。これも、ポストトランスレーションを使用して手動で処理する必要があります。
NULLポインタ値の表現は、プラットフォームごとに異なる可能性があります。特にソース・プラットフォームとターゲット・プラットフォームの間では、他のすべてのポインタ値のようにサイズが同じにならないというだけでも異なります。この結果、この値の特定の表現を想定しているすべてのプログラムは(たとえば、バイナリ整数値との間でのキャストなど)は、プラットフォームごとに動作が異なる可能性があります。COBOLコンバータが自動的にこの問題を処理することはできません。手動で問題を処理する必要があります。いずれにしても、マシン依存の処理はお薦めしません。
入力コンポーネントは、カタロガによる解析が終了したアセット内のすべてのCOBOLプログラムです。実際、COBOLコンバータはプログラムのソース・ファイルではなくPOBファイルをロードします。カタロガによって課された制約(ネスト・プログラムなしなど、「カタロガ」を参照)に加え、COBOL変換を試行する前には次のルールに従う必要があります。
AddCommentを使用して変換済COBOLファイルに再び追加できることに注意してください。
システム記述ファイルには、処理するアセットの全ソース・ファイルの場所、タイプ、可能性のある依存関係が記述されます。このように、このファイルは、カタロガだけでなくCOBOLコンバータも含めたすべてのRehosting Workbenchツールがこれらのソース・ファイルや対応するコンポーネントにアクセスするために不可欠です。
| 注意: | COBOLソースファイルの番号領域とコメント領域Cを除去する必要があるため、オプションCobol-left-marginを1に設定し、オプションCobol-right-marginを66に設定する必要があります。これらはデフォルト値です。 |
このファイルは、必須コマンドライン・オプション-cまたは-configを使用してCOBOLコンバータに指定されます。変換に影響する様々なスカラー・パラメータが定義され、大規模な構成データ(ファイル名変更など)を含む下位ファイルが指定されます。
| 注意: | このファイルで構成できるパラメータの多くは、コマンドラインでも設定できます。その場合は、コマンドラインの値によって構成ファイルの値がオーバーライドされます。 |
| ヒント: | 必須ではありませんが、このファイルはシステム記述ファイルと同じパラメータ・ディレクトリに格納することをお薦めします。 |
メイン変換構成ファイルの内容は自由な形式で指定できます。キーワードで始まりピリオドで終了する句を任意の順序で指定します。1つ以上の引数を指定する句と、引数を指定しないブール句があります。キーワードは大文字小文字が区別されないシンボルです。引数は、整数、シンボルまたは(大文字小文字が区別される)文字列です。空白や改行などはコメントです。コメントは構成ファイルには次の2つの方法で記述できます。
この句は、ターゲット・ファイル(プログラムとコピー・ファイルの両方)の完全な階層を含むディレクトリの場所を指定します。ソース・プログラムA/B/name.extがアセットのルート・ディレクトリにある場合(システム記述ファイルに定義)、対応するターゲット・プログラムはターゲット・ディレクトリにA/B/name.extとして配置されます(ファイル拡張子は変わる可能性があります。後続の内容を参照してください)。コピー・ファイルにも同じ仕組みが適用されますが、ターゲット・パスはMaster-copy/A/B/name.extとなります(拡張子は変わる可能性があります)。Master-copyディレクトリはコピー調整プロセスに関連します。「コマンドライン構文」を参照してください。
Sql-rules : target-sql-syntax.
この句は、ターゲットSQL構文を指定します。値は、oracleまたはnoneです。値がnoneの場合、ソース・ファイル内のsqlコードは変換されません。ターゲット・コンポーネントにそのまま転送されます。この句のデフォルト値はoracleです。後者では、構成ファイルでsql-rulesをoracleに設定する必要はありません。
keep-same-file-names.
target-program-extension :extension. (or)tpe :extension.
target-copy-extension :extension.(or)tce :extension.
これらの句は、変換されるファイル(メイン・ソース・ファイル)とコピー・ファイルのファイル拡張子の決定方法を次のように指示します。
verbosity-level : level .
この句は、COBOLコンバータが実行ログに書き込む詳細のレベルを指定します。デフォルト値2は詳細、これよりも高い値はさらに詳細、値1では重要な(エラー)メッセージのみが表示されます。
deferred-copy-reconcil.
deferred-crp.
dcrp.
この句は、変換が終了するまでコピー調整プロセスcrpを延期することを指定します。こうすることで、COBOL変換が複数の同時プロセスで実行できます。デフォルトでは、この句を指定しないと、コピー調整プロセスは、各プログラムの変換が終了するたびすぐに増分的に実行され、単一プロセス実行になります。詳細は、次のコピー調整プロセスを参照してください。
force-translation.
この句は、COBOLコンバータが、FATALエラーを含むプログラムも変換(の試行)するように指示します。ただし、保証はありません。正しくない結果が生成されたり、コンバータが異常終了したりする可能性があります。デフォルトでは、この場合、コンバータはプログラムの処理を拒否し、次のプログラムに進みます。
rename-copy-map-file : file-path .
この句は、コピー・ファイルの名前変更の情報を含む下位構成ファイルの場所を指定します。下記の「copy-renaming構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
rename-call-map-file : file-path .
この句は、サブプログラムと呼出しの名前変更の情報を含む下位構成ファイルの場所を指定します。「Call-Renaming構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
post-translation-file : file-path .
この句は、Rehosting Workbenchコンバータの後で適用する手動変換の説明を含む下位構成ファイルの場所を指定します。「Post-Translation構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
on-size-error-call: proc-name .
この句は、プログラムを確実に終了させるために呼び出すプロシージャの名前をシンボルとして指定します。この名前は、IBMコンパイラが終了を構成するがターゲット・コンパイラは終了を強制しない状況(算術文でのサイズ・エラーなど)で、終了を強制するために使用されます。デフォルトの名前はABORTです。
hexa-map-file : file-path .
この句は、16進形式の文字に適用するEBCDIC-to-ASCII変換を含む下位構成ファイルの場所を指定します。「16進変換構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
conv-ctrl-file : file-path or conv-ctrl-list-file : file-path .
alt-key-file : file-path
これらの句は、file-to-Oracle変換に関する情報を含む2つの下位構成ファイルの場所を指定します。これらのファイル(Conv-ctrl-fileまたはConv-ctrl-list-fileおよびAlt-keyファイル)は、Rehosting Workbench File-to-Oracle変換ツールによって生成されます。「File-to-RDBMS構成ファイル」を参照してください。
最初の2つの句のうち1つだけを指定する必要があります。conv-ctrl-file句またはconv-ctrl-list-file句のいずれかです。両方ではありません。
ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
RDBMS-conversion-file : file-path .
この句は、リレーショナルDBMS変換(DB2からOracle)の情報を含む最上位の下位構成ファイルの場所を指定します。詳細は「RDBMS-conversion構成ファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
keywords-file : file-path .
この句は、ターゲットのCOBOLダイアレクトでキーワードまたは予約語に相当するCOBOL識別子の名前変更の情報を含む下位構成ファイルの場所を指定します。「keywordsファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
accept-date: date-entry-name .
accept-day: day-entry-name .
これらの句は、ACCEPT … FROM DATE文およびACCEPT … FROM DAY文を置換するサブプログラム名を指定します。次に文の例を示します。
CALL "DATE-ENTRY-NAME" USING MY-DATE BY VALUE LENGTH OF MY-DATE
これにより、プログラムが現在の日付を取得する方法を管理しやすくなり柔軟性も高まります。たとえば、リグレッション・テストの際に、移行されたプログラムをソース・プログラムが実行されたときと同じ現在日付で実行する必要があります。これらのサブプログラム(Rehosting Workbenchユーザーによって要件に基づいて提供される)によってこの処理が可能になります。
これらの句のいずれかを指定しないと、対応する文は変換されません。ターゲットCOBOLパラメータ(Microfocus Cobolランタイム・システムのcurrent_day、current_monthおよびcurrent_yearパラメータなど)を使用して、ACCEPT文によって返される日付を制御できます。MicroFocus/COBOL-ITのドキュメントを参照してください。
sql-stored-procedures-file: file-path .
この句は、COBOLから直接呼び出されるDB2ストアド・プロシージャのリストを含む下位構成ファイルの場所を指定します。詳細は、「stored-procedureファイル」を参照してください。ファイル・パスは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
remove-sql-qualifier.
この句は、スキーマ修飾子を含むすべてのSQL識別子からスキーマ修飾子を除去するトランスフォーメーション・ルールを有効にします。このため、結果として生成されるプログラムは暗黙のスキーマ修飾に依存します。
| ヒント: | これは通常は必要ありません。おそらく要望されることもありませんが、たとえば複数テスト・コリドーなど、複数環境(複数のデータベースまたはスキーマに接続)でプログラムを同時に実行したい場合には役立ちます。 |
activate-cics-rules.
この句を指定すると、COBOLコンバータによって、現在の実行で処理中のすべてのプログラムにEXEC CICS文を標準化するルールが強制的に適用され、Oracle Tuxedo Application Runtime for CICS環境(CICSプリプロセッサなど)でプログラムを使用する準備が行われます。
| 注意: |
EXEC CICS文を含むすべてのプログラムに適用されます。したがって、この句(または同等のコマンドライン引数)はCICS環境で使用されるサブプログラム(暗黙のCOMMAREAなど)のみで有効ですが、それ自体がCICS操作を実行することはありません。pure-seq-map-file: file-path .
purely-sequential-map-file: file-path .
この句は、LINE SEQUENTIALに変換せずにSEQUENTIALのまま保存(記録)されるSEQUENTIAL論理ファイルのリストを含む下位構成ファイルの場所を指定します。詳細は、「purely-sequential構成ファイル」を参照してください。file-pathは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
dont-print-what-string .
この句を指定すると、変換のタイムスタンプとコンバータのバージョン情報を含むwhat-stringがこの実行で出力されません(通常、この情報はコンバータによってすべての変換済ファイルの先頭に挿入されます)。Rehosting Workbenchを使用してアプリケーションが移行されたという事実を隠す必要がないかぎり、これはほとんど使用されません。
remove-empty-copies .or rec.
この句を指定すると、変換後に役立つCOBOLコードを含まなくなったコピー・ファイルを参照するCOPYディレクティブがコメント・アウトされます。デフォルトでは、これらのディレクティブはアクティブなままになります。たとえば、これは、データベース表に移行されるファイルのFDパラグラフ全体を定義するコピー・ファイルに適用されます。
sql-return-codes-file: file-path .
この句は、DB2とOracleの対応するSQLCODE値の追加の組合せを含む下位構成ファイルの場所を指定します。詳細は「sql-return-codes構成ファイル」を参照してください。file-pathは文字列として指定します。絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します(Rehosting Workbenchツールでの共通の方法)。
このファイルは、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つのコピー・ファイルの名前が同じターゲット・ファイル名に変更されるかどうかはチェックされないことに注意してください。原則としては、これはコピー調整プロセスで適切に処理されるはずですが、保証のかぎりではありません。
このファイルは、前に説明した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-file句に対応します。次の構文の一連のルールが含まれます。
rule rule_name
filter [
(+|-)program_name_regexp
]
transform [
source_lines_block
]
into [
target_lines_block
]
このようなルールのセマンティクスは単純です。プログラムの(ベース)名が、プラス記号のprogram_name_regexpのいずれかと一致するがマイナス記号とは一致しないとき、source_lines_block1と一致する行ブロックが検出されると、target_lines_blockによって置換されます。rule_nameは、変換アプリケーションに関連付けられるコメントで使用されます。詳細は、ポストトランスレータの説明を参照してください。
post-translationファイルには必要なだけのルールを任意の順序で含めることができます(ただし、2つのsource_lines_blocksが重なるとき、またはsource_lines_blockとtarget_lines_blockが重なるときは、ポストトランスレータの動作は定義されません)。
| ヒント: | この構文では、filter句、transform句およびinto句を囲む角カッコが、行の先頭の列1にあることが非常に重要です。他の位置では、カッコがブロックの一部として解釈されます。 |
コメントはシャープ記号(#)から行の最後までです。ルールの間、4つの句の間、ルール名の後であれば、どこにでも挿入できます。コメントを角カッコで囲んだフィルタの内側またはtransformブロックやintoブロックに挿入すると、コメントではなくブロックの内容として認識されます。
このファイルは、前述の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変換を記述していること)はチェックされないことに注意してください。
| ヒント: | データとソース・ファイルの変換に使用されるグローバルなプロジェクト固有変換表からこの表を導出することを強くお薦めします。詳細は、Oracle Tuxedo Application Runtimeプロセス・ガイドを参照してください。このようにしないとターゲット・プラットフォームで動作が変わる可能性がありますが、オラクル社が責任を負うものではありません。 |
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ファイルの内容を参照してください。
これらのファイルはconv-ctrl-file句およびalt-key-file句に対応します。これらには、file-to-RDBMS変換に関する情報が含まれます。たとえば、どの論理ファイル(FD)をRDBMS表に変換するかを定義するための情報です(実際、論理ファイルが関連する物理ファイルがそのようなDB表に変換されるため)。これらのファイルはRehosting Workbench File-to-Oracle変換ツールによって自動的に生成されるため、手動で変更しないでください。内容をさらにここで指定することはありません。
これらのファイルは、前述のRDBMS-conversion-file句に対応します。含まれる情報には次のように2つのレベルでアクセスできます。
schema-name;file-path.
File-pathは、SQLスキーマschema-nameに関するRDBMS-conversion情報を含むファイルのパスです。通常は、絶対パスまたは相対パスのどちらも可能です。後者の場合は、システム記述ファイルを含むディレクトリに関して相対的に指定します。このファイルは、Rehosting Workbenchユーザーが作成する必要があります。
このファイルは、keywords-file句に対応します。内容は、セミコロンが区切り文字として使用されるCSV表です。各行の形式を次に示します。
old-name;new-name.
このような行により、すべてのプログラムにおける名前がold-nameであるすべてのCOBOL識別子(変数名、パラグラフ名など)は、名前がnew-nameに変更されます。これは、ターゲットのCOBOLダイアレクトでキーワードまたは予約語に相当する名前(TESTなど)に関して必要ですが、リエンジニアリングの目的で単純な識別子を名前変更するときにも役立ちます。
このファイルはsql-stored-procedures-file句に対応します。内容は、1行に1つずつ記述されたサブプログラム名のリストです。これらの名前のうち1つがCOBOL CALL文に含まれると、SQL CALL文で置換されます。さらに、CALLのパラメータの宣言(ある場合)がSQL文で使用できるように調整されます。
このファイルは、pure-seq-map-file句に対応します。内容は、セミコロンが区切り文字として使用されるCSV表です。各行の形式を次に示します。
program-name;FD-name
名前は両方ともシンボルです。このような行は、ソース・プラットフォームで(レコード)SEQUENTIALであると仮定される特定の論理ファイル(所定のプログラムの所定のFD)が、ターゲット・プラットフォームでLINE SEQUENTIALに変換されないようにします。つまり、レコードSEQUENTIALファイルのまま変化しません。こうすることで、このファイルは標準のターゲットプラットフォーム・ユーティリティでの処理に対応しにくくなりますが、無制限のREWRITE操作をサポートします(前のLINE SEQUENTIALファイルに対するREWRITE操作に関する項を参照してください)。これは、z/OSプラットフォームからバイナリ形式で交換されるファイルでも有効です。
このファイルは、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
| 注意: | 現在、COBOLコンバータはこの変換表の一貫性のチェックは行いません。たとえば、同じDB2値が複数のOracle値にマップされていてもエラーにはなりません。 |
前述したように、Rehosting Workbench COBOLコンバータの主な目的は、変換されたCOBOLコンポーネントをソース・ファイルの形式で生成することです。ソース・ルート・ディレクトリ内のメイン・プログラム・ファイルの階層とターゲット・ルート・ディレクトリ内のメイン・プログラム・ファイルの階層には、1対1の直接の対応があります。ファイル名に関するかぎり、異なる可能性があるのは、CALL-renamingマップとターゲットのprogram-file拡張子の選択によるもののみです。「rename-call-map-file句」および「keep-same-file-names、target-program-extensionおよびtarget-copy-extension句」を参照してください。これは、ターゲットのコピー・ファイルについても該当しますが、次の点に注意してください。
Master-copyサブディレクトリにあります。COPY-renamingマップと、ターゲットのcopy-file拡張子の選択のために、ターゲット・コピー・ファイルの名前がソース・ファイルと異なることがあります。ファイルORIGCOPY(.s-ext)が複数のバージョンに変換されると、それらのバージョンにはORIGCOPY(.t-ext)、ORIGCOPY_V1(.t-ext)、ORIGCOPY_V2(.t-ext)などのように名前が付けられます。
ターゲット・プラットフォームのCOBOLとソース・プラットフォームのCOBOLが大きく異なるわけではなく、原則としてCOBOLの変換は容易なプロセスです。このプロセスが翻訳ではなく変換と呼ばれるのはそのためです。実際、変換されたファイル(メイン・ファイルまたはコピー・ファイル)が対応するソース・ファイルと異なるのは、ごく少数の箇所のみです。内容の大部分は何も影響を受けずに、ソース・ファイルとまったく同じ状態でターゲット・ファイルに再生成されます。ただし、異なる場所は特定のトランスフォーメーション・コメントで示されます。
なんらかのトランスフォーメーションが実際に行われた場所では、コンバータによって、トランスフォーメーションの影響を説明するトランスフォーメーション・コメントが挿入されます。影響を受けるコードの内容は次のとおりです。
ルールによっては、既存のコードが変更されるだけでなく、離れた場所にまったく新しいコードが挿入されることがあります。たとえば、Working-Storage Sectionでの中間変数の宣言などです。このケースでは、プログラム内の影響を受ける領域は次のとおりです。
ルールによってコードが変更されるのではなくただ削除されると、プログラム内の影響を受ける領域には、変更されるコードと同じ内容が配置されますが、新しいコードの部分は空になります。
ルールによっては、プログラム内のある場所から別の場所にコードが移動されます。たとえば、ファイルがリレーショナルDB表に移行されると、対応するFDは削除され、それに含まれるデータ・レコードはWorking-Storage Sectionに移されます。このケースでは、元の場所のコードは削除として示され、新しい場所のコードは挿入として示されます。
COBOLコンバータがトランスフォーメーション・ルールをコードの一部に適用するときは、元のバージョンと新しいバージョンの両方に存在するコード要素の移動を最小限に抑えることで、新しいコードでも同じレイアウトを保とうとします。また、コンバータが新しい要素(文や変数の宣言など)を挿入するとき、新しい要素の位置を前後の同種の要素とあわせようとします。このようなガイドラインに従うことで、変更されたコード行や新しいコード行が固定形式に対して長くなりすぎた場合、コンバータによって、一番右側の適切な位置(おそらく語と語の間)で行が切られ、残りは次の行に折り返されます。これは、右マージンに寄せて表示され、折り返された要素が論理的には前の行の一部であることが示されます。
メイン・プログラム・ファイルでREPLACING句で呼び出されるコピー・ファイルをコンバータが出力するとき、置換の影響を元に戻すために特別な処理を行います。ただし、コンバータによって実行されるトランスフォーメーションが、置換で生成されたテキストのいくつかに適用されるときは、コンバータが逆トランスフォーメーションを計算して、元の置換句を作成するのが非常に難しくなります。たとえば、COPY句によって「何か」が「無」によって置換されたとき、領域がトランスフォーメーションによって影響を受けていると、コンバータは「何か」の置換を戻すための「無」を見つけるのが極めて難しいことがあります。このようなケースでは手動での修正が必要になることがあります。ポストトランスレーション機能を使用して、繰り返し可能な方法で適用します。
ソース・プログラムと、COBOLコンバータによって生成されたターゲット・プログラムの同一の動作を保証するには、これまでに説明した制限に加え、実際にターゲット・プログラムをコンパイルするときにコンパイラ・オプションの特定のセットを使用する必要があります。実際、ターゲットCOBOLコンパイラの一部のオプションでは実行コードの動作が変更します。Rehosting Workbench COBOLコンバータによって適用されたトランスフォーメーションは、次に示すオプション・セットに合うようにここで調整します。別のオプション・セット(少なくとも相反するオプション・セット)でコンパイルされたプログラムはサポートされません。詳細は、Micro Focus COBOLのドキュメント、特にコンパイラ・ディレクティブ・ブックおよびCOBOL-IT Compiler Suite Enterprise Editionのリファレンス・マニュアルを参照してください。
必須のコンパイラ・オプションを次に示します。それぞれについて、デフォルトで設定されるかどうかを記載し、簡単な説明とそのオプションが必要な理由を示します。
DISPLAY数値についてオーバーパンチ符号を表すためにASCII規約ではなくEBCDIC規約を使用します。これは、ソース・プラットフォームと同じ規約であるため、このような数値の最後の桁が文字変数によって再定義された場合に動作が大きく変化しません。
ACCEPT文が、UNIXの標準入力ファイルではなく、指定した論理ファイルを読み取るようにします。これはソース・プラットフォームと同じ動作であり、ART変換されたKSHスクリプトに適しています。このスクリプトは、SYSINをCOBOLプログラムの他のファイルと同様に扱います。
DISPLAY文が、UNIXの標準出力ファイルではなく、指定した論理ファイルに書き込むようにします。これはソース・プラットフォームと同じ動作であり、Rehosting Workbenchで変換されたKSHスクリプトに適しています。このスクリプトは、SYSOUTをCOBOLプログラムの他のファイルと同様に扱います。
SYNC[HRONIZED]句がマシン固有型(バイナリ整数、バイナリ浮動小数点数、ポインタなど)に対して有効になります。メモリー消費が少し増加しますが、最高のパフォーマンス効率を得られます。
OCCURS DEPENDING句が付いた項目の後にあるが、その項目には従属しない項目です。ODOSLIDEでは、これらの項目は表のサイズに関係なく常に表の直後に続きます。つまり、表のサイズが変わるとアドレスが変わります。NOODOSLIDEでは、これらの項目のアドレスは固定されており、表の最大長として割り当てられた領域が終了してから開始します。ODOSLIDEを設定すると、ソース・プラットフォームと同じ動作になります。
PERFORM文のネストに関してソース・プラットフォームと同じ動作を実現します。デフォルト・オプションPERFORM-TYPE"MF"はセマンティックがよりクリーンで、実行の効率は高くなりますが、動作が変化する可能性があります。これは検出および診断が困難なため、PERFORMの範囲の動作に問題がなく、範囲が重なっていないことが明らかでないかぎり、デフォルト設定はお薦めしません。
FDの最初のレコードの直前にある隠された長さ変数を提供して、可変長シーケンシャル・ファイルから読み取ったばかりのレコードの長さを知ることができます(詳細はMicroFocusのドキュメントを参照)。この方法はソース・プラットフォームで使用できます。このオプションは強く推奨されてはいませんが、これを使用すると同じ動作を再現できます。
EXTERNALファイル割当て方法を使用するように指示します。この方法では、SELECT名が、DD_NAMEという形式の環境変数で実際のファイル名を、探すためのキーとして使用されます。これは、ファイル割当てをプログラムの外部に指定できる(すなわちKSHスクリプトの呼出し)Rehosting Workbenchのために選択するモードです。これは概念においてソースの動作に似ているだけではなく、最も柔軟性の高い方法です。
ZEROLENGTHFALSEを設定すると、0長のグループ項目間の比較、および0長の項目と表意定数の比較では、常にfalseが返されます。設定しないと、常にtrueが返されます。ソース・プラットフォームと同じ動作を再現するには設定する必要があります。
CALL文で参照されるサブプログラムの名前が切り詰められません。これは、Rehosting Workbenchで移行したアセットで必要です。Rehosting Workbenchによって生成されるデータ・アクセス・ルーチンの名前はロング・ネームであるためです。また、将来的にアセットを活用するためにも、ソース・プラットフォームで課せられていた名前の長さ制限を排除することをお薦めします。
COPYディレクティブで参照されるコピー・ファイルの名前が切り詰められません。これは、Rehosting Workbenchで移行したアセットで必要です。Rehosting Workbenchによって生成または挿入されるコピー・ファイルの名前はロング・ネームであるためです。また、将来的にアセットを活用するためにも、ソース・プラットフォームで課せられていた名前の長さ制限を排除することをお薦めします。
.lbrファイル)ではなく、単純なパスとして扱います。これは、Rehosting Workbenchで移行されるアセットで必要です。Rehosting Workbenchによって変換または生成されるコピー・ファイルはアーカイブとしてグループ化されないためです。
NOSIGN-FIXUPは、HOST-NUMCOMPAREおよびHOST-NUMMOVEディレクティブを使用するときに、メインフレームのコンパイラ・オプションNUMPROC(PFD)のエミュレーションを提供します。このオプションでは、NUMPROC(NOPFD)動作の完全なエミュレーションを提供できませんが、最高のパフォーマンスを実現します。
.cpy拡張子が付いており、Rehosting Workbenchによって変換されるコピー・ファイルにも通常は同じ拡張子が付いているためです。ただし、別の拡張子についてCOBOLコンバータを構成する場合は、それに応じてこのオプションの設定を調整する必要があります。
デフォルト・オプションと明示的なオプションおよび依存関係を考慮すると、必須オプション・リストを次のように開始できます。
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の現在のバージョンは、このオプション・リストに対して検証されています。
| 注意: | Pro*COBOLプリプロセッサ用のOracle SQL必須コンパイル・オプションのリストは、『ART Workbench RDBMSコンバータ・リファレンス・ガイド』を参照してください。 |
| 注意: | デフォルトで64ビット・モードとしてコンパイルするためのP64オプションは、Micro Focusインストール・セットアップでは必要ありません。 |
次のオプションは厳密には必要ではありませんが、大文字と小文字が混在するプログラムが含まれるアセットの処理に役立つことがあります。
これらの設定を試すことで、特定のアセットに適した組合せがわかります。たとえば、FOLDCALLNAME"UPPER"とMAPNAMEを一緒に設定すると、ソースコンパイラのオプションPGMNAME(COMPAT)の適切なエミュレーションを得られますが、このオプションの別の値をエミュレートする確実な方法はありません。
次のオプションはターゲット・アセットの動作に影響しますが、ARTシステムのユーザーの意思によって設定できます。
SSRANGEオプションに似ています。少なくとも移行テストと運用開始直後の数か月は、これら両方のオプションを設定することを強くお薦めします(SSRANGEを設定するとBOUNDも設定されることに注意してください)。この選択には少し問題があります。それは、ソース・プラットフォームで正しく実行しているように見えるいくつかのプログラム(SSRANGEオプションなし)が停止することがあるためです。ただし、経験によると、停止するプログラムはソース・プラットフォームで偶然作動できていた誤ったプログラムのみです。ターゲット・プラットフォームでは同様に作動しないか、まったく作動しません。このようなプログラムの検出と修正は早く行うのに越したことはありません。同じく、CHECKオプションの設定も検討してください。これは、様々な(他の)実行時チェックを有効にし、他の一見正常なプログラムを検出できます。
BINARY変数(またはCOMPまたはCOMP-4)に割り当てたときに、指定されたPICサイズの切捨てが行われるかどうかを指定します。これは、IBMコンパイラのTRUNC(STD)オプションに似ています。ただし、ART COBOLコンバータの現在の仕様では、そのようなすべての変数はCOMP-5変数に変換され、この変数はTRUNCオプションの対象になりません。前述の「COMP-5型およびTRUNCコンパイラ・オプションの使用」での説明を参照してください。
ALTER文の存在を禁止します。ALTER文は以前使用されていましたが、存在している場合は深刻な問題になります。ART Workbenchでアセットを移行する機会に、残っているALTERがあれば削除してしまうことをお薦めします。その後、このオプションを設定して再び使用しないようにし、コンパイルされたコードの効率と安全性を高めます。
AREACHECKを指定しないと、ピリオドの後のトークンのみがラベルとして扱われます。このディレクティブによりIBMのエラー処理(ラベルの前のピリオドが省略されていても、深刻度の低いメッセージが生成される)との互換性が高まります。そのようなエラーを招くソース・コードは修正することをお薦めします。
BYTE-MODE-MOVEが指定される場合、データはソースからターゲットに1バイトずつ移動します。NOBYTE-MODE-MOVEが指定される場合、データは(環境に応じて)一度に2バイトや4バイト(またはそれ以上)のグラニュルでソースからターゲットに移動します。結果として、重なりがグラニュル・サイズよりも小さい場合は、グラニュルを移動するたびに次に移動するグラニュルの一部が上書きされます。NO-BYTE-MODE-MOVEではパフォーマンスが向上しますが、ソース・プラットフォームで正しく作動しているごく一部のプログラムに正しくないコードが生成されることがあります。比較的互換性が高い設定(BYTE-MODE-MOVE)から開始し、完全なリグレッション・テストを満足できるまで実行してから、他のオプションを選択して再テストすることをお薦めします。
CANCEL文が無視されないことを指定します。これは同名のIBMオプションに似ています(まったく同じではありません。MicroFocusのドキュメントを参照してください)。このオプションの設定を強くお薦めします。応用CICSプログラムを実行するART TP Run-timeシステム内のTuxedoサーバーは、CANCEL文を使用して、それらのプログラムのロードと実行に使用されたメモリーを解放するためです。NODYNAMが有効になっていると、それらのサーバーが違うプログラムを実行するにつれ使用されるメモリー容量は増加し続けます。
FD使用方法の制限が再現されます(FDレコードはOPEN時にのみ割り当てられ、レコードの内容はWRITEの後でなくなるなど)。このような制限には意味がないと考え、これらのオプションは使用しないことをお薦めします。
STICKY-LINKAGE"2"設定は、特にCICSプログラムに関してソース・プラットフォームの動作との互換性は比較的高いのですが、標準ではなくエラーが発生しやすい傾向があります。また、これはART TPランタイム・システムの特定の機能(特に、共有メモリーのない1つのクラスタ内で実行するいくつかのサーバー上にTPトランザクションを分散する機能)との互換性がない場合があります。このため、最初からデフォルトのNOSTICKY-LINKAGE設定を使用し、リグレッション・テストで検出されるsticky-linkage関連の不具合を修正することを強くお薦めします。また、前述の「NULLアドレスのLinkage-Section引数」を参照してください。
次のオプションはコンパイル・リストの生成のみに影響します。自由に選択できます。
必須のコンパイラ・オプションを次に示します。それぞれについて、デフォルトで設定されるかどうかを記載し、簡単な説明とそのオプションが必要な理由を示します。
DIALECT"MF"(デフォルト): ネイティブで最も効率的な操作モードを設定します。Oracle ARTの目的は、ソース・メインフレームのエミュレートのみではなく、メインフレームにとらわれずにターゲット・プラットフォームのメリットを活用することであるため、これは最適な選択です。Unicodeサポートやオブジェクト指向プログラミングなど、MF COBOLの最新機能を使用できるようになります。デフォルト・オプションと明示的なオプションおよび依存関係を考慮すると、必須オプション・リストを次のように開始できます。
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"
| 注意: | Pro*Cobolプリプロセッサ用のOracle SQL必須コンパイル・オプションのリストは、 『ART Workbench RDBMSコンバータ・リファレンス・ガイド』 を参照してください。 |
次のオプションは厳密には必要ではありませんが、大文字と小文字が混在するプログラムが含まれるアセットの処理に役立つことがあります。
これらの設定を試すことで、特定のアセットに適した組合せがわかります。たとえば、FOLDCALLNAME"UPPER"とMAPNAMEを一緒に設定すると、ソースコンパイラのオプションPGMNAME(COMPAT)の適切なエミュレーションを得られますが、このオプションの別の値をエミュレートする確実な方法はありません。
次のオプションはターゲット・アセットの動作に影響しますが、ARTシステムのユーザーの意思によって設定できます。
次のオプションはコンパイル・リストの生成のみに影響します。自由に選択できます。
ソース・プログラムと、Cobolコンバータによって生成されたターゲット・プログラムの同一の動作を保証するには、これまでに説明した制限を考慮すると、実際にターゲット・プログラムをコンパイルするときにコンパイラ・オプションの特定のセットを使用する必要があります。実際、MicroFocus Cobolコンパイラの一部のオプションでは実行コードの動作が変更します。Rehosting Workbench Cobolコンバータによって適用されたトランスフォーメーションは、次に示すオプション・セットに合うようにここで調整します。別のオプション・セット(少なくとも相反するオプション・セット)でコンパイルされたプログラムはサポートされません。詳細は、MicroFocus Cobolのドキュメント、特に『コンパイラ・ディレクティブ・ブック』を参照してください。
動作に影響を及ぼす、設定が必須な主要オプションは、DIALECT"ENTCOBOL"です。実際に、このダイアレクト・オプションは、PERFORM-TYPE"ENTCOBOL"などの多くのサブオプションを設定します。このサブオプションにより、ターゲット・プログラムは、IBM Enterprise Cobol Compilerによってコンパイルされる元のソース・プログラムとできるかぎり同じように動作します。
ただし、Refine Cobolコンバータは、ターゲット・プラットフォームのネイティブ・キャラクタ・セット、すなわちASCIIを使用することで、Enterprise Cobolの基本選択ではなくなります。このため、オプションCHARSET"ASCII"の設定が必須になります。反対に、DISPLAY数値のオーバーパンチ符号の表示にはIBM規約が使用されます。したがって、オプションSIGN"EBCDIC"を設定する必要があります。
ターゲット・プログラムが正しく動作することを保証するには、主要オプション以外の次のオプションを設定する必要があります。
ソースCOBOLコンパイラの動作を再現するために、COBOL-ITは、IBMと互換性のある構成ファイル(ibm.conf)を提供します。この構成ファイルは、ターゲットCOBOLアセットのコンパイルに使用されます。
構成ファイルibm.confで設定されているコンパイラ・オプションに加えて、ソースとターゲットのCOBOL環境間の互換性を向上させるために、少なくとも次のオプションを追加する必要があります。
顧客のニーズに応じて、その他のコンパイラ・オプションを設定できます。COBOL-ITコンパイラ・オプションについては、COBOL-IT Compiler Suite Enterprise Editionのリファレンス・マニュアルを参照してください。
COBOLコンバータが開始すると、様々な構成ファイルをメイン構成ファイルから順に読み取ってチェックします。この段階で矛盾が検出されると、1つ以上のエラー・メッセージが出力されてコンバータが終了します。それ以外の場合、コンバータはコマンドライン・オプションと構成ファイル・オプションの両方を使用し、処理する(ソース)プログラムのリストなどの内部パラメータを設定します。次に、これらのプログラムそれぞれを順に処理し始めます。各プログラムの処理を次に示します。
deferred-copy-reconcil句がコマンドラインまたは構成ファイルに指定されている場合、コンバータは一度にいくつかの同時プロセスによって実行できます。それ以外の場合、これらの同時プロセスのコピー調整フェーズによって、最終的に調整されたコピー・ファイルのデータベースに対してのアクセス競合が発生して、異常終了することがあります。
COBOLコンバータはrefineコマンドを実行するように設計されています。これは、一般的なOracle Tuxedo Application Rehosting Workbenchランチャであり、すべての重要なOracle Tuxedo Application Rehosting Workbenchツールの起動にも使用されます。このランチャは、これらのツール操作の様々な側面(実行ログの管理や増分または反復操作など)を扱います。
$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
強力なコンピューティング・プラットフォームが容易に使用可能である今日であっても、Rehosting Workbenchを使用した完全なアセットの処理は、依然として計算集中的で長時間の実行、メモリーを消費するタスクのままです。このため、Workbenchツールは、停止と再起動が容易に行えるように設計されています。makeに似たメカニズムのおかげで、一度終了した作業を繰り返す必要はありません。これにより、移行プロジェクトのすべてのフェースで効率的な操作が可能です。
最初のフェーズでは、完全に新しいアセットから、安定したアセットの最初の変換、生成のサイクルの終わりまで、makeに似たメカニズムが使用されて、次のような繰返し操作が可能になっています。
このモードが特に適しているのは、カタロガのようにアセット全体にグローバルな処理を行うツールまたはコマンドです。COBOLコンバータのようにコンポーネント対応のツールでも役立ちます。これは Rehosting Workbenchツールの通常モードでの動作であり、これを選択するのに何も特別なことは必要ありません。
COBOLコンバータは、様々なコンポーネント(メイン・プログラム・ファイル)と対応する結果ファイル(POBファイルおよびターゲット・プログラム・ファイル)の間の依存関係を認識しています。この情報を使用して、アセットで変更が発生したときに増分的に対処することができます。たとえば、COBOLソース・ファイルが追加、変更または削除されると、カタロガは影響を受けたプログラムを再解析し、COBOLコンバータはそれらを再変換します。これもRehosting Workbenchツールの通常モードでの動作であり、これを選択するために何かをする必要はありません。
1ここでの一致は、2つの行ブロックの一連のスペースを減らして1つのスペースにするときに、両方のブロックが同一でなければならないことを意味します。基本的に同一であれば柔軟に解釈されます。
  
|