Oracle Tuxedo Application Rehosting Workbenchカタロガはソース環境から抽出されたすべてのコンポーネントを個別および一緒に分析し、アセットに一貫性があるか、移行できるかどうかを決定します。カタロガはまた別のツールで使用される内部形式を生成します。
カタロガはRehosting Workbenchを構成する移行ツールの1つです。その目的は次の2つです。
プロジェクトおよび移行プラットフォームの構成の必要に応じて、これらのフェーズは単一の実行または増分的に、順次または同時に実行することができます。詳細は、繰返しおよび増分操作およびOracle Tuxedo Application Runtimeのプロセス・ガイドを参照してください。
カタロガはz/OSプラットフォームで実行している、完全な作業ソフトウェア・アプリケーションのソース・ファイルを入力として受け入れます。これは、この後の項で詳細に説明する、次のタイプのファイルで完全に構成されている必要があります。
Oracle Tuxedo Application Rehosting Workbench COBOLパーサーはCOBOL言語を、IBM Enterprise COBOL for z/OS Language Reference Version 3 Release 4(資料番号SC27-1408-04)での仕様のとおり受け入れます。
COBOLパーサーはサブパーサーを使用して埋込みEXEC CICS文(コマンド)を解析します。パーサーはIBM CICS Application Programming Reference Version 3 Release 1(資料番号SC34-6434-05)で定義された言語を受け入れます。
同じパーサーがスタンドアロン・モードで使用されてSQL DDLファイルを解析し、サブパーサーとしてCOBOLプログラムに埋め込まれたEXEC SQLコードを解析します。これはIBM DB2 Version 9.1 for z/OS Application Programming and SQL Guide(資料番号SC18-9841-00)およびIBM DB2 Version 9.1 for z/OS SQL Reference(資料番号SC18-9854-00)の言語仕様に基づきます。
JCLパーサーはIBM z/OS MVS JCL Reference(資料番号SA22-7597-09)の言語仕様に基づきます。
システム記述ファイルで指示されているように、パーサーは様々な形式のサブファイルおよびファイル・インクルード・ディレクティブ(EXEC [PROC]、INCLUDE、SYSINなど)を処理し、アセットのサブファイルを検索します。カタロガおよびJCLトランスレータのようなその他のツールは、処理するすべてのJCLスクリプトのすべての手順を完全に理解している必要があり、すべての参照されるサブファイルがアセットに存在し、そのファイル・タイプおよび検索パスは、すべての参照でサブファイルが正しく検索されるように設定されることが非常に重要です。カタロガはサブファイルの欠落を、すべての影響を受けるJCLの正しい分析および変換を妨げるという理由で、重要度の高い異常としてレポートします。変換はこのような異常がすべてなくなるまで試行できません。
すべての参照されるPROCおよびINCLUDEサブファイルはアセットに存在する必要があります。
パーサーはまたストリーム内PROC(PROCおよびPENDカードで区切られる)およびSYSIN(DD *)を処理する(もちろん欠落していない場合)ことに注意してください。
JCLジョブは、実行条件を含むまたは含まない、ステップのシーケンスです。カタロガ・オプション・ファイルでjob-card-optionalオプションが指定されている場合を除き、JOBカードで開始する必要があります。XXXXXを参照してください。
すべてのJCL、JES2およびJES3文が解析されます。JCLはJES2から直接実行できる必要があります。パーサーはJES変数置換を実行します。JCLでローカルに定義されていない変数は、システム記述ファイルのJCL-globalsオプションを使用して設定できます。「特別なオプション」を参照してください。
コメント・カード("//*"で開始)は 同様に認識され、変換用に保持されます。
パーサーはすべての種類のJCLカードを認識します。PROCのオーバーライドおよびrefbackを処理しますがDDカードに限ります。継続カードも処理します。
特定の状況では、同じサブファイルをPROCファイルおよびINCLUDE
ファイルの両方として使用できます。しかしターゲット・ファイルへの変換はそれぞれのケースで異なるので、問題のターゲット・ファイルを複製する必要があり、その1つのコピーを使用してPROCとして変換し、別のコピーをINCLUDE
ファイルとして変換します。これを達成するには、もちろん2つのコピーが別のディレクトリに配置されていることが必要で、これらのファイルをPROCとして使用するJCLはPROCバージョンを先に見つけ、INCLUDEとして使用するJCLはINCLUDEバージョンを先に見つけるように、検索パスを設定する必要があります(同じJCLが同じファイルをPROCおよびINCLUDEの両方として使用することはできません)。
JCLごとに1つのJOBカードのみを使用できます。複数のJOBカードを含むファイルがある場合、カタロガを実行する前に分割する必要があります。JOBカード内のジョブ名と(単純な)ファイル名が一致することを確認してください。
JCLパーサーは様々な標準ユーティリティ用のコマンドファイル(SYSIN、 SYSTSINなど)の内容をフェッチ(ストリーム内でない場合)し解析します。そのようなユーティリティの現在のリストは次のとおりです。
注意: | これらのユーティリティのサポート、たとえばコマンド言語を処理するパーサー機能などは、部分的である可能性があります。 |
BMSパーサーは次のドキュメントで定義されているようにBMS言語を処理します。
パーサーはすべての正しいBMS定義を受け入れます。また、これは明らかな構文エラーのほとんどをレポートしますが、そのようなエラーのすべての認識しているという意味ではありません。
CICS構成パーサーはCICSリソース定義言語をバッチ・ユーティリティDFHCSDUP(IBM CICS Transaction Server for z/OS Resource Definition Guide Version 3 Release 2、資料番号SC34-6815-00を参照)による読取りとして処理します。コマンド、DELETE ALL、ADD、REMOVEおよびDEFINEが認識されます。すべてのリソース・タイプおよび属性が認識されますが、パーサーおよびエクストラクタで実際に利用されるのはほんのわずかしかありません。
システム記述ファイルには、処理するアセットの全ソース・ファイルの場所、タイプ、可能性のある依存関係が記述されます。これ自体は、カタロガだけでなくすべてのRehosting Workbenchツールが、これらのソース・ファイルおよび対応するコンポーネントにアクセスするためのキーです。システム記述ファイルはまた解析に影響を与えるパラメータの数も指定します。
Sys-desc-file ::= “system”system-name
“root”system-root-path
global-options
special-options
directories
注意: | ファイルの形式は基本的には自由で、行の長さの制限もありません。コメントはパーセント文字で開始し、行の終わりで終了します。 |
注意: | 記号(名)の形式には[A-Z][a-z][0-9][*-_]の文字を含めることができます。記号は数字を先頭にできますが、少なくとも1つの文字が必要です。キーワードおよび記号(名)では大/小文字は区別されません。文字列では大/小文字は区別されます。 |
この句の要素は、解析、カタログ化、一般的に言えば、ソース・ファイルの処理に影響を与える様々な設定を指定します。この句の一般的な構文は次のとおりです。
( “options” | “global-options” ) opt-name-1 “=” opt-value-1 “,”
opt-name-2 “=” opt-value-2 “,” ... “.”
各オプションの値には、整数、記号、文字列またはブール・インジケータを使用できます。(次のものがブール・インジケータとして認められます。
オプション名およびオプション値は文字列を除き、大文字・小文字は区別されません。一般的に、これらの設定はアセット全体にグローバルに適用することも、特定のディレクトリにローカルに上書きすることもできます(次を参照)。
このシステムまたはディレクトリで使用するJCLランチャ仕様ファイルのパス。これらのファイルの内容と使用方法の詳細は、「JCLランチャ仕様ファイル」を参照してください。このパスは絶対形式または相対形式のいずれでも指定できます。後者の場合、パスはシステム記述ファイル自体を含むディレクトリへの相対パスです。
|
特別オプションは、主に構文上の理由で、前述のグローバル・オプション・メカニズムに統合できない句です(値はリストです)。このオプションはグローバル・オプションの前でも後ろでもかまいませんが、間にはできません。すべて次の構文形式をとります。
opt-name “=” opt-value “.”
イコール記号と末尾のピリオドは必須です。値がリストの場合、リスト内の項目はカンマで区切る必要があります。特別オプションを次の表で説明します。
システム記述ファイルのメイン・コンポーネントはディレクトリ句のリストで、指定したアセットの様々なソース・ファイルの場所、そのタイプと相互関係を指定します。各句の構文は次のとおりです。
“directory” directory-path
type-clause file-clause logical-name-clause options-clause
libraries-clause sql-libraries-clause
subdirectories “.”
(必須)ディレクトリ・パスが最初に来ます。オプションのサブディレクトリがあれば最後である必要があります。他の句はどの順序でもかまいません。これらの句のうち、type句とfile句のみが必須で他はオプションです。
これはディレクトリの、システムのルート・ディレクトリに対する相対パス(場所)を指定する文字列です(system-root-pathを参照)。絶対要件ではありませんが、同じシステムのすべてのディレクトリをシステム・ルート・ディレクトリの物理的な子孫にすることを強くお薦めします。(これを実現する単純で理解しやすい方法はディレクトリ・パスに、上に移動する"../"を含めないことです。)異なるディレクトリは異なるパスを持つ必要があります。
“type” directory-type
type句はディレクトリのタイプを指定しますが、これは含まれるソース・ファイル(コンポーネント)のタイプのことです。このタイプは大文字・小文字を区別しない記号として指定されます。次のタイプだけが受け入れられます。
JCLスクリプトのユーティリティ・プログラムまたはプログラム・ランチャにより使用されるSYSINファイル。すべてのSYSINファイルが、パーサー/カタロガで必須なわけではありません。詳細は、Rehosting Workbench JCL Translatorリファレンス・マニュアル(入力コンポーネントの説明に関する項)を参照してください。
|
|
“files” file-specs “,” ...
file-specs
はディレクトリ内の1つまたは複数のファイルを指定する文字列です。この文字列はアセットに含まれるメンバーを特定し、その他を除外します。file-spec
の最も単純な形式はtoto.cbl
のような完全なファイル名です。ディレクトリの表示を指定する必要はなく、指定されたファイルは問題のディレクトリに直接配置する必要があります。ディレクトリ内のすべてのコンポーネントを明示的にリストする作業を避けるために、*.cbl
や[A-F][D-Z]*.jcl
といったシェルのような正規表現を使用することもできます。
注意: | システム記述ファイルで指定されたすべてのファイル(アセット内のすべてのソース・ファイル)のファイル名は、拡張子付きであることが重要です。この拡張子は自由に選択できますが、存在している必要があり、COBOLプログラムにはcbl 、COBOLコピー・ファイルにはcpy 、メインJCLファイルにはjcl というように、"標準の"拡張子を使用することをお薦めします。 |
logical-name lname
この句は、JCL-Sysinタイプのディレクトリで、特別オプションstrict-jcl-libraries
(前述を参照)とともに使用されます。ともに使用することで、厳密なJCL-Sysin検索モードが有効になります。lnameは、フォーム“A.B.C”
の文字列で、ソース・プラットフォームのJCL SYSINファイルのライブラリ(PDS)の名前を指定します。この句を有するディレクトリ内のすべてのファイルは、このライブラリに属していると想定されます。
特別オプションstrict-jcl-libraries
が設定されていない場合、logical-name句は無視されます。
“options” opt-name-1 “=” opt-value-1 “,”
opt-name-2 “=” opt-value-2 “,” ...
構文的には、このディレクトリ特有のoptions
句は、システム全体のGlobal Options句と似ていますが、末尾のピリオドが違います。意味としては、リストされたオプションと値はグローバル・オプションと同じ効果がありますが、ローカルにディレクトリに含まれるファイルのみに適用されます(同じ名前でグローバル・オプションを上書きします)。グローバル・オプション表のlocal?
列にyes
とマークされているものと同じオプションは、それが関係するソース・ファイルのタイプを含むディレクトリに適用されます。たとえば、オプションcobol-right-margin
はCOBOL-Batch、COBOL-TPRまたはCOBOL-Subタイプのディレクトリに関係しますが、JCLまたはSQLスクリプト・タイプには関係しません。
さらに、JCLタイプのディレクトリに対するディレクトリ特有のオプション"Right-margin"があります。この値はJCLファイルの"行末"列を指定する整数です。デフォルト値は72で、これはほとんどのIBM JCLソース・ファイルに適しています。
“libraries” directory-path “,” ...
libraries句はアセット内の(他の)ディレクトリのパスを検索する順序を指定します。カタロガがソース・ファイルで他のコンポーネントへの参照を見つけるときは常に、参照と一致する名前およびタイプを持つコンポーネント(ソース・ファイル)を見つけるまで、この句で指定したディレクトリのリストを最初から最後まで検索します(後述のサブファイル検索オプションの項を参照)。これはCOBOLプログラムのコピー・ファイルの参照やJCLファイルのPROCの参照などの、コンパイルおよび解析時の参照と、COBOLプログラムのCOBOLサブプログラムの呼出しやJCLジョブのCOBOLプログラムの起動などの実行時の参照の両方で使用されます。この方法で、COBOLコンパイル用のSYSLIBまたはCOPYLIB、JCLの準備および実行用のJOBLIBおよびSTEPLIBなどといった、様々なソース・プラットフォームのライブラリ検索操作の影響をシミュレートできます。
注意: | このディレクトリパスは参照されるディレクトリの定義で指定されたものと一致する必要がある文字列です。しかし、ディレクトリの定義はその参照の前または後に配置される可能性があります。 |
“sql-libraries” directory-path “,” ...
sql-libraries句はCOBOLプログラムのEXEC SQL INCLUDEディレクティブを解決するためのibraries句と同じ働きをします。省略すると、このような参照の解決は通常のibraries句と同じ検索パスを使用しますが、通常のCOPYディレクティブおよびSQL INCLUDEディレクティブに異なる順序を使用するために必要な場合があります。
system BNL root "../source"
options catalog = "./options-catalog.desc",
no-end-xxx-warnings,
cobol-left-margin = 7,
cobol-right-margin = 72,
SQL-Schema = DB2A1,
SQL-Server = BNL.
minimum-free-ram-percent = 20.
%
% Copies
%
directory "COPY" type Cobol-Library files "*.cpy".
directory "INCL" type Cobol-Library files "*.cpy".
directory "IBMCPY" type Cobol-Library files "*.cpy".
%
% Sysin
%
directory "SYSIN" type JCL-SYSIN files "*.sysin".
directory "SYSINCDB" type JCL-SYSIN files "*.sysin".
%
% DDL
%
directory "DDL" type SQL-SCRIPT
files "*.sql"
options SQL-Schema = "DB2A0".
%
% Batch
%
directory "Batch" type COBOL-Batch files "*.batch"
libraries "COPY", "INCL", "IBMCPY"
options cobol-right-margin=73.
%
% TPR
%
directory "TPR" type COBOL-TPR files "*.tpr"
libraries "COPY", "INCL", "IBMCPY".
%
% JCL
%
directory "JCL" type JCL files "*.jcl"
libraries "SYSINCDB", "SYSIN".
%
% CICS
%
directory "MAPS" type BMS files "*.bms".
directory "CICS" type RDO files "*.rdo".
このシステム記述ファイルはBNLという名前のアセット用で、顧客や大規模システムのスタンドアロン・アプリケーションの名前の例です。このファイルの名前と場所に制約はありませんが、慣例的にはその完全なパスは、/.../BNL/param/system.desc
のようにします。これを前提として、このファイルに指定されたシステム・ルート・ディレクトリのパスが相対的(../source
)なので、ルート・ディレクトリの絶対パスは/.../BNL/source
です。同様に、カタロガ・オプション・ファイルは./options-catalog
と指定されているので、その絶対パスは/.../BNL/param/options-catalog
です。グローバル・オプションは次のコメントを呼び出します。
様々なディレクトリの名前と構造は完全に標準で、アセット内のソース・ファイルはそのファイル拡張子によってのみ識別されます。ここで通常とは違う機能は"Batch"ディレクトリに対する特別なcobol-right-marginの値です。
ほとんどのIBMソース・アセットにはプログラム・ランチャ、つまり適用できるプログラムを起動するユーティリティ・プログラムを起動するJCLステップが含まれます。DB2ランチャIEKJFT01などの多くのランチャは、Rehosting WorkbenchカタロガのJCLパーサーおよびアナライザにより直接認識されます。しかし、多くの場合、このようなランチャはインストールに特有であり、特別な処理を必要とします。幸いにも、これらのほとんどは汎用的なJCL起動メカニズムと構文(EXEC PGMカード)を使用し、関連する起動情報はPARM値に含まれます。
JCLランチャ仕様ファイルの目的は、カタロガおよびJCLトランスレータが、起動する実際のプログラムの名前などの関連情報を抽出できるように、指定したアセットで使用されるランチャを説明することです。仕様はほとんどの場合、PARM値はいくつかの区切り文字(標準のJCLの区切り文字であるカンマであるとは限らない)により個々のパラメータに分割され、プログラム名、PSB名、PLAN名などを指定するパラメータはシーケンス中で適切に定義された位置にあるという事実に基づきます。
JCLランチャ仕様ファイルは、次の構文の自由形式テキスト・ファイルで、ここではすべてのキーワードと記号は大文字・小文字を区別しません。
LAUNCHER <Launcher name>
[<option-name> = <option-value> [,
... ]
]
END
...
最後の3つのオプションはデフォルト値がありません。オプションがない場合、対応する情報は単に使用できません。
ディレクトリに添付されたローカルのjclz-launcher-spec-file
オプションは存在する場合、通常はグローバル・オプションをオーバーライドします。指定したディレクトリおよびシステム全体のいずれにもランチャ仕様ファイルが指定されていない場合、デフォルト値は次のファイルを使用したかのようになります。
LAUNCHER DFSRRC00
IndexProg : 2,
IndexPSB : 3
END
LAUNCHER DB2BATCH
IndexProg : 2,
IndexPSB : 3
END
これらのレポートはすべてCSV形式で生成され、フィールドは1つのセミコロンで区切られます。
これは$SYSROOT/Reports-${SYSNAME}ディレクトリに生成され、ここで$SYSROOTは現在のアセットのルート・ディレクトリで、$SYSNAMEはアセット名で、いずれもシステム記述ファイルで定義されています。
競合を避けるため、各レポートの名前には$SYSNAMEも含まれています。
注意: | UNUSEDおよびMISSINGは(コンポーネント間)異常とみなされます。 |
注意: | コンポーネントがMISSINGの場合、すべてユーザーにより提供された情報に応じて、このフィールドはアセットに存在しないコンポーネントに対する句を記述する識別子で置き換わります(SYSTEM、CORRECTまたはPROBLEM)。 |
このレポートはアセット内で定義または参照されたすべての(COBOL)プログラムをリストします。これは-Cobol-Batch、-Cobol-TPRおよび-Cobol-Subレポートから成ります。
フィールド定義を参照してください。これはプログラムを定義する(メイン)ソース・ファイルのパスです。
|
||||
フィールド定義を参照してください。
|
||||
フィールド定義を参照してください。
|
次のフィールドは、コンポーネントがMISSINGの場合には空(未定義)です。
また、SUBタイプのコンポーネントの場合、この名前は、サブプログラム自体の名前ではなく、サブプログラムのエントリ・ポイントの名前である可能性があります。これはCALL
で参照される名前であり、カタロガではそれが指定しているのがエントリ・ポイントと完全なサブプログラムのどちらなのかを特定できません。
このレポートはアセットに含まれるまたは参照されるすべてのCOBOLコピー・ファイル(コピーブック)をリストします。次のフィールドがレポートに含まれます。
次のフィールドは、コンポーネントがMISSINGの場合には空(未定義)です。
ファイルごとに複数のジョブを処理するため、JCLについては、(メイン)ソース・ファイルのレポートとジョブのレポートは別になります。(メイン)ソース・ファイルでは、次のフィールドがレポートに含まれます。
フィールド定義を参照してください。
|
||
フィールド定義を参照してください。これは含まれているすべてのジョブの最高異常レベルと少なくとも同じ高さで、構文エラーの場合にはさらに高いこともあります。
|
JCLソース・ファイルは決してMISSINGにはならず、JCLジョブだけが欠落する可能性があります。
このレポートはメイン・ファイルの分析に必要なJCLサブファイルである、PROC、INCLUDEおよび一部のSYSINファイルを説明します。次のフィールドがレポートに含まれます。
次のフィールドは、コンポーネントがMISSINGの場合には空(未定義)です。
このレポートはアセット内で定義または参照されたすべてのJCLジョブをリストします。次のフィールドがレポートに含まれます。
フィールド定義を参照してください。これはジョブを定義する(メイン)ファイルのパスです。
|
||
フィールド定義を参照してください。
|
||
フィールド定義を参照してください。これはジョブ自体の異常レベルで、通常は構文エラーは考慮しません(後者はジョブの分析を妨げるため)。
|
このレポートは、アセットで定義または参照されるすべてのBMS画面をリストします。次のフィールドがレポートに含まれます。
フィールド定義を参照してください。これは画面を定義するファイルのパスです。
|
||
フィールド定義を参照してください。
|
||
フィールド定義を参照してください。実際、これはソース・ファイル全体の異常レベルであり、その異常が実際のこの画面定義に適用されるかどうかは異常レポートを参照してください。
|
このレポートはアセット内で定義または参照されたすべてのSQL表をリストします。次のフィールドがレポートに含まれます。
このレポートはアセット内で定義または参照されたすべてのSQLビューをリストします。次のフィールドがレポートに含まれます。
フィールド定義を参照してください。これはビューを定義するファイルのパスです。 |
||||
フィールド定義を参照してください。
|
||||
このレポートは、アセット内のRDOファイルに定義されたすべてのCICSトランザクションをリストします。次のフィールドがレポートに含まれます。
フィールド定義を参照してください。これはトランザクションを定義するファイルのパスです。 |
||
トランザクションがアセットで参照され(RETURN TRANSID文など)、それがRDOファイルで定義されていない場合、パスおよび行番号フィールドは空でこのレポートにリストされます。
このレポートは、アセット内のすべてのコンポーネントで検出されたすべての異常をリストします。次のフィールドがレポートに含まれます。
フィールド定義を参照してください。これは異常が発生したコンポーネントを定義するメイン・ファイルのパスです。 |
||
フィールド定義を参照してください。エラーの実際の場所(文またはその他の構成)がサブファイル(COBOLコピー・ファイル、JCL PROCファイルなど)の中にある場合、これはそのサブファイルのパスで、そうでない場合はこのフィールドは空です。 |
||
異常が発生した実際のソース・ファイル(前述のフィールドが空でなければサブファイル、そうでなければメイン・ファイル)の行番号。 |
||
異常がサブファイルで発生した場合、このフィールドにはサブファイルが含まれるメイン・ソース・ファイルの行番号が含まれ、そうでない場合は空です。 |
||
異常の正確な種類を識別する、統合的で重要な名前。実際に、取り得る値は有限の列挙ですが、ここにすべてをリストするには多すぎます。 |
||
異常の正確で詳細な説明で、原因となるソース構成への参照を含む場合もあります。たとえば、 "SQL-TABLE variable is not defined: LVDSYS00"などです。 |
カタロガの結果は、前述した一連のカタロガ・レポートで表示できます。これらのレポートが唯一の出力ではなく、また最も重要な出力でもありません。この項では、その他の結果ファイルについて簡単に説明します。これらは独自形式のバイナリファイルで、Persistent Object Base (POB)と呼ばれます。これらのファイルは、人間による処理や、従来のテキストベースのツールでの処理には適しておらず、カタロガ自体やRehosting Workbenchのその他のツールでの使用に向いています。
解析フェーズ中に(カタロガ・プロセスを参照)、システムの各解析可能コンポーネントのソース・ファイルA/B/C/file.ext
に対し、カタロガはA/B/C/pob/file.ext.pob
(pob
ディレクトリはカタロガにより要求時に作成)という名前のPOBファイルを生成します。このファイルにはコンポーネントの抽象構文ツリー(AST)という名前の解析結果が含まれます。これはカタロガの分析フェーズで、またCOBOLコンバータやJCLトランスレータなどのその他のOracle Tuxedo Application Rehosting Workbenchツールにより、再度読み取られます。
CDM (Common Data Model)ファイルには、COBOL変数(データ記述エントリと呼ばれる)に関する追加の情報が含まれます。システムの各COBOLプログラムA/B/C/prog.cbl
ごとに、カタロガはA/B/C/pob/prog.cbl.cdm
という名前のCDMファイルを生成して、メイン・ソース・ファイルで定義された変数についての情報を格納します。また、変数を定義する各COBOLコピー・ファイル D/E/file.cpy
ごとに(たとえば、Procedure Divisionコードを含むコピー・ファイルとは対照的に)、カタロガはD/E/pob/file.cpy.cdm
という名前のCDMファイルを生成して、これらの変数を格納します。このCDMファイルは、このコピー・ファイルを含むすべてのプログラムで共有されます。
コピー・ファイルで明らかに定義された変数についての情報を、このコピー・ファイルを含むすべてのプログラムで実際には共有できない場合もあります。たとえば、REPLACINGディレクティブに含まれるコピー・ファイル、または完全構成の一部のみを定義するファイル(01レベル・レコード)の場合です。このような場合、CDM情報はコピー・ファイル自体ではなく、プログラムのCDMファイルに格納されます。コピー・ファイルに関連付けられる共有CDM情報がまったくない場合、CDMファイルは生成されません。
$SYSROOT/symtab-$SYSNAME.pob
: このファイルには(分析フェーズ中に)カタロガにより作成された記号表が格納され、アセット内のすべてのコンポーネントのサマリー情報が含まれます。この情報はこれらのコンポーネント間の相互参照情報を計算するために使用されます。$SYSROOT/Cobol-dump-map.pob
: COBOLプログラムの抽象構文ツリー(AST)POBの読取りおよび書込みに必要な情報(ダンプ記述子と呼ばれる)を含みます。既存のCOBOL POBを再読取りできなくなるので、このファイルを削除しないでください。$SYSROOT/sql-system-$SYSNAME.pob
、$SYSROOT/sql-system-$SYSNAME-State-ments.pob
: アセットの完全なSQLスキーマの様々な内部形式を含み、すべてのDDLファイルの結合(SQLスクリプト・ファイル)から導出されます。これらのファイルはCOBOLプログラムの解析(およびリンク)に必要です。
「カタロガ・プロセス」で説明したように、この操作は解析、分析、分析後およびレポート生成(詳細は下記を参照)の4つのフェーズに論理的に分割されます。プロジェクトおよび移行プラットフォームの構成の必要に応じて、これらのフェーズは単一の実行または増分的に、順次または同時に(解析フェーズのみ)実行することができます。
プロジェクトおよび移行プラットフォームの構成の必要に応じて、これらのフェーズは単一の実行または増分的に、順次または同時に(解析フェーズのみ)実行することができます。次の3つの基本的なOracle Tuxedo Application Rehosting Workbenchコマンドがカタロガを起動します。
preparse
およびそのバリアントpreparse-files
: 解析フェーズのみ実行します。 これは、少なくともSQLシステム・ファイルが生成された後で、同時実行が可能な唯一のフェーズです。これはまた、1つまたは複数の特定のコンポーネントの処理をリクエストできる唯一のフェーズです。そうでない場合、カタロガは処理する必要のあるプロセスを自ら特定します(「アセットでの変更: 増分処理」を参照)。このフェーズでは、カタロガはコンポーネント・ソース・ファイル、含まれるサブファイルおよびSQLシステム・ファイルを読み取り、処理されるコンポーネントのPOBファイル(のみ)を生成します。
analyze
: 分析フェーズで実行します。各コンポーネントのPOBファイルが再読み込みされ、コンポーネントで最も重要な構成がより小さなサマリー情報に変換されて、カタロガの記号表(symtab)に保管されます。Symtabが同時アクセスをサポートしていないため、このフェーズは同時実行モードで実行できません。このフェーズでは、カタロガはコンポーネントのPOBファイルを読み取り(必要に応じて要求時に解析)し、Symtabファイルを変更(読取りおよび書込み)します。
fast-final
: 分析後およびレポート生成フェーズの両方で実行します。 注意: | これらすべてのコマンドで、すべての構成情報はシステム記述ファイルおよびカタロガ・オプション・ファイルから取得します。preparse-files を除き、コマンドライン引数のみがシステム記述ファイルへのパスおよび標準のOracle Tuxedo Application Rehosting Workbenchツールの引数です。 |
カタロガはrefine
コマンドを使用して実行するようになっています。refine
コマンドは汎用的なOracle Tuxedo Application Rehosting Workbenchランチャで、これを使用して主なOracle Tuxedo Application Rehosting Workbenchツールを起動します。ランチャは後述する(繰返しおよび増分操作)実行ログ管理、増分および繰返し操作などの、これらのツールの様々な操作を処理します。Oracle Tuxedo Application Rehosting Workbenchランチャはいくつかの汎用のコマンドライン・オプションも処理します。
コマンドラインで、Oracle Tuxedo Application Rehosting Workbenchツールを起動するのに使用される一般的な形式は次のとおりです。
$REFINEDIR/refine command
[ launcher-options… ] \
( -s | -system-desc-file ) system-desc-path \
[ command-specific-options-and-arguments… ]
次のオプションがRehosting Workbenchのcommand
と関係があります。
次のオプションは技術的にはランチャ・オプションではありませんが、すべてのRehosting Workbenchツールで受け入れます(実際には必須です)。
注意: | 多くのRehosting Workbenchツールが使用するその他の多くのパスは、このファイルの場所から導出されます。これにより異なる作業ディレクトリから同じコマンドを実行しやすくなります。 |
さらに、次のオプションが将来の使用のために予約されています(現在、これは受け入れられますがそれ以外は無視されます)。
最後に、ランチャは次の汎用的なオプションを使用して、コマンドなしで起動することができます。
処理フェーズで説明したとおり、システム全体のコマンドは、preparse、analyze、fast-finalおよびcatalogです。これらはアセット全体でグローバルに動作します。これらすべてのコマンドの汎用的なコマンドライン構文は次のとおりです。
$REFINEDIR/refine command [ launcher-options… ] \
-s | -system-desc-file ) system-desc-path
これらのコマンドには特有のオプションはありません。すべての構成情報はシステム記述ファイル、カタロガのオプション・ファイル 、および場合によってはヒント・ファイルにあります。
上記で説明した、アセット全体でグローバルに動作し処理するコンポーネントをそれ自身が決定するシステム全体のカタログ化コマンドとは異なり、preparse-filesコマンドでは、解析するコンポーネントを指定することができます。
処理するコンポーネントを指定できるということから、preparse-filesコマンドはmakefileでの使用に適しています。また、特にソース・ファイルをいくつかのリストに区切って各リストを個別のプロセスに与える場合には、これは同時実行の対象になります。
注意: | COBOLプログラムの解析前に、カタロガはSQLシステムのPOBファイルが存在し、すべてのSQL DDLファイルに対して最新であることを確認します。これはPOBファイルの構築または再構築を伴う可能性があり、それにはある程度の時間がかかる可能性があります。 |
preparse-filesのコマンドラインは次のとおりです。
$REFINEDIR/refine preparse-files [ launcher-options… ] \
( -s | -system-desc-file ) system-desc-path \
( source-file-path | ( -f | -file | -file-list-file ) file-of-files )…
追加のオプションは、処理するコンポーネント・ソース・ファイルを示します。
$SYSROOT
に対する相対パスで指定する必要があります。
この項では、カタロガがライブラリおよびシステム記述ファイル内のsql-libraries句を使用して、現在処理されているコンポーネントの特定の構成内で参照されるコンポーネントを検索する方法を説明します。この操作は、参照がどれであるかによって多少異なります。
コンパイル時のケースは、現在のコンポーネントの重要な部分であるサブファイルへの参照に適用されるため、サブファイルが見つからないと、コンポーネントは分析および正確に"理解"されません。たとえば、COBOLメイン(プログラム)ソース・ファイルから参照されるCOBOLコピーブックです。
PROC
ファイル、INCLUDE
ファイルおよびいくつかのSYSIN
ファイルのようなJCLジョブから参照されるJCLサブファイルも含まれますが、これは、MVSプラットフォームでは、これらのサブファイルはJCLジョブが実行されるときに検索される(したがって実行時参照である)のに対し、移行プラットフォームでは、カタロガがこれらの参照を解析時に解決し、JCLトランスレータが使用できるようにする(したがってコンパイル時参照とみなされる)必要があるためです。SYSIN
ファイルも、DB2ランチャにより起動されるプログラムなど、解析時に必要な情報を含んでいるため、この場合にあてはまります。カタロガでは、"コンパイル時"は解析に、"実行時"は分析後に相当します。
検索は、ディレクトリSRCDIRに配置され、特定のタイプTGTTYP のTGTFILという名前のコンポーネントを参照する、 特定のタイプSRCTYPのSRCFILとして識別されたコンポーネントから開始されます。次の表に可能性のある様々な組合せを示します。
このアルゴリズムは、strict-jcl-libraries
特別オプションが指定されている場合に、JCL-Sysinファイルを検索するために変更されます。このオプションが設定されている場合、SYSINファイルA.B.
TGTFILまたはA.B(
TGTFIL)
の検索が次のように続行されます。
この動作は、JCL-Sysinファイルを検索する場合でも、libraries
句がタイプJCLのディレクトリ上で無視されることを意味します(JCL-Selectファイルの検索は依然有効です)。一方、前述したように、strict-jcl-libraries
特別オプションが設定されていない場合、JCL=Sysinディレクトリのlogical-name
句は無視されます。
重複する名前が多数存在する場合、つまり、異なるライブラリに同じ名前のファイルが数多く存在する場合(PDS)、パス・ベースの検索ではなく、厳密な検索を使用することをお薦めします。この場合、個別のディレクトリ内の各SYSINライブラリの内容全体を転送し、ライブラリの名前にディレクトリの論理名を指定する方が、適切なファイルが各参照で検出されるようにJCLディレクトリのlibraries
句内の様々なJCL-Sysinディレクトリ名を指定するよりも簡単です。
実行時のケースは、実際には参照するコンポーネントの一部ではない外部コンポーネントへの参照に適用されます。参照されるコンポーネントが存在しなくても、参照するコンポーネントの分析または変換は可能ですが、不適切な実行が発生します。たとえば、サブプログラムを呼び出すCOBOLプログラムまたはプログラムを実行するJCLジョブなどです。カタロガでは、このような参照は分析後フェーズで処理されます。
タイプTGTTYPの名前TGTFILを参照するディレクトリSRCDIR に配置されたタイプSRCTYPのコンポーネントSRCFILから検索が開始します。考慮する2つのケースがあります。
このケースは、ディレクトリSRCDIRに関連するlibraries句にタイプTGTTYPの要素(ディレクトリ)が含まれていない場合に適用されます。これは"デフォルト・ケース"と見なすことができます。検索アルゴリズムは次のとおりです。
指定検索は、コンパイル時参照の通常のサブファイル検索と似ています。指定検索は、ディレクトリSRCDIRに関連するlibraries
句にタイプTGTTYPの要素(ディレクトリ)が1つ以上含まれている場合に適用されます。検索アルゴリズムは次のようになります。
このアルゴリズムでは、「参照が曖昧です。」という異常が発生することはありません。これは、指定したディレクトリにある指定したベース名のファイルは多くても1つだけであるためです。このため、このアルゴリズムは、異なるディレクトリ(またはライブラリ)に同じ名前を持つコンポーネントが複数含まれるシステムを分析する場合に適しています。ただし、SRCTYPの各ディレクトリに対して、ライブラリ句の適切なTGTTYP要素を適切な順序で定義する必要があるため、追加の設定作業が必要になります。
検索対象のコンポーネントの指定したTGTTYP、および適切なSRCTYPそれぞれについて、一部のSRCTYPディレクトリには指定検索、同じタイプの別のディレクトリには無制限検索を使用できます。実際には、コンポーネント名が重複する場合、それらが実際に参照された場合のみ問題(異常)が発生します。ただし、このような状況は混乱を招くため、次のようにすることをお薦めします。指定したSRCTYP/TGTTYPの組合せに対して、すべてのソース・ディレクトリに無制限検索を使用するか、または指定検索を使用するかのいずれかにしてください。
注意: | 指定検索は、カタロガの現在のバージョンではまだ使用可能ではありません。libraries 句を使用して、実行時参照に含まれるコンポーネントを指定する場合、これらの要素は無視されます。指定検索は、将来のバージョンで、選択したSRCTYP/TGTTYPの組合せに対して徐々に追加されます。リリース・ノートを確認してください。 |
強力なコンピューティング・プラットフォームが容易に使用可能である今日であっても、Rehosting Workbenchを使用した完全なアセットの処理は、依然として計算集中的で長時間の実行、メモリーを消費するタスクのままです。
そのため、Oracle Tuxedo Application Rehosting Workbenchツールは容易に停止および再起動できるように設計されています。このツールはmakeに似たメカニズムを使用して、すでに実行された作業を繰り返さないようにします。これにより、移行プロジェクトのすべてのフェースで効率的な操作が可能です。
最初のフェーズでは、完全に新しいアセットから、安定したアセットの最初の変換、生成のサイクルの終わりまで、makeに似たメカニズムが使用されて、次のような繰返し操作が可能になっています。
処理するファイルの量が多くなるに従い、Refineプロセスはより多くのメモリーを消費します。
このモードは、カタロガの分析またはカタログ化コマンドのような、アセット全体でグローバルに動作するツールまたはコマンドに特に適しています。これは Rehosting Workbenchツールの通常モードでの動作であり、これを選択するのに何も特別なことは必要ありません。
カタロガは様々なコンポーネントと関連する結果ファイルの間の依存関係を認識しています。たとえば、どのCOBOLプログラムでどのコピー・ファイルが使用されたかを記録します。この情報を使用して、アセットで変更が発生したときに増分的に対処することができます。たとえば、コンポーネント・ソース・ファイルが追加、変更または削除されたとき、カタロガはこの変更で影響を受ける結果ファイルを特定し、そのファイルのみを再計算します。これもRehosting Workbenchツールの通常モードでの動作であり、これを選択するために何かをする必要はありません。
注意: | 重要: 増分操作はアセットの最初の処理が完了した後でのみ有効です。最初のサイクルが終わる前にアセットで変更を実行すると、記録されない依存関係がある可能性があり、その場合、再実行する作業の評価は正しくなくなり、最終結果に一貫性がなくなります。そのため、最初のアセットでカタロガの実行を完了させてから、そのアセットでの変更を行うことが非常に重要です。 |