リファレンス・ガイド

カタロガ

Oracle Tuxedo Application Rehosting Workbench (Tuxedo ART Workbench)カタロガはソース環境から抽出されたすべてのコンポーネントを個別および一緒に分析し、アセットに一貫性があるか、移行できるかどうかを決定します。カタロガはまた別のツールで使用される内部形式を生成します。

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

カタロガの概要

カタロガはTuxedo ART Workbenchを構成する移行ツールの1つです。その目的は次の2つです。

カタロガ・プロセスへの入力

カタロガ・プロセスからの出力

カタロガ・プロセス

カタロガ・プロセスは4つの論理フェーズに分けられます。

プロジェクトおよび移行プラットフォームの構成の必要に応じて、これらのフェーズは単一の実行または増分的に、順次または同時に実行することができます。詳細は、繰返しおよび増分操作およびOracle Tuxedo Application Runtimeのプロセス・ガイドを参照してください。

入力コンポーネントの説明

カタロガはz/OSプラットフォームで実行している、完全な作業ソフトウェア・アプリケーションのソース・ファイルを入力として受け入れます。これは、この後の項で詳細に説明する、次のタイプのファイルで完全に構成されている必要があります。

COBOL

リファレンス

Tuxedo ART Workbench COBOLパーサーはCOBOL言語を、IBM Enterprise COBOL for z/OS Language Reference Version 3 Release 4 (資料番号SC27-1408-04)での仕様のとおり受け入れます。

制限

次の構成または機能は受け入れません。

サブプログラム

パーサーはCOBOLプログラムとそのサブプログラムを処理します。サブプログラムがWorkbenchプロジェクトに存在せず、COBOLプログラム内で呼び出されている場合、Workbenchはサブプログラムがないことを報告します。このサブプログラムがランタイム・システムで提供され、その名前がカタロガ・オプション・ファイル内のオプションのsupplied-batch-moduleおよびsupplied-cics-moduleで指定されたファイルにリストされている場合、Workbenchはこれらのプログラムについてはないと報告しません。

例:

カタロガ・オプション・ファイルの構成をリスト3-1に示します。

%% Options for cataloguing the system 

call-hints="../param/call-hints.desc". 

supplied-batch-module="../param/supplied-batch-module". 

supplied-cics-module="../param/supplied-cics-module". 

job-card-optional. 

ファイル"../param/supplied-batch-module"での構成は次のとおりです。

#Comment line 

ILBOABN0 

CEE3ABD 

ファイル"param/supplied-cics-module"での構成は次のとおりです。

#Comment line 

CICS001 

CICS002 

ILBOABN0およびCEE3ABDはBatchランタイム・システムで提供されます。CICS001およびCICS002はCICSランタイム・システムで提供されます。Workbenchはこれらのプログラムについてはないと報告しません。

埋込みCICS

リファレンス

COBOLパーサーはサブパーサーを使用して埋込みEXEC CICS文(コマンド)を解析します。パーサーはIBM CICS Application Programming Reference Version 3 Release 1(資料番号SC34-6434-05)で定義された言語を受け入れます。

SQL

リファレンス

同じパーサーがスタンドアロン・モードで使用されて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

リファレンス

JCLパーサーはIBM z/OS MVS JCL Reference(資料番号SA22-7597-09)の言語仕様に基づきます。

一般情報

サブファイル

システム記述ファイルで指示されているように、パーサーは様々な形式のサブファイルおよびファイル・インクルード・ディレクティブ(EXEC [PROC]、INCLUDE、SYSIN、SYSTSINなど)を処理し、アセットのサブファイルを検索します。カタロガおよびJCLトランスレータのようなその他のツールは、処理するすべてのJCLスクリプトのすべての手順を完全に理解している必要があり、すべての参照されるサブファイルがアセットに存在し、そのファイル・タイプおよび検索パスは、すべての参照でサブファイルが正しく検索されるように設定されることが非常に重要です。カタロガはサブファイルの欠落を、すべての影響を受けるJCLの正しい分析および変換を妨げるという理由で、重要度の高い異常としてレポートします。変換はこのような異常がすべてなくなるまで試行できません。

SYSIN/SYSTSINファイルは次の2つのタイプがあります。

すべての参照されるPROCおよびINCLUDEサブファイルはアセットに存在する必要があります。

パーサーはまたストリーム内PROC (PROCおよびPENDカードで区切られる)およびSYSIN/SYSTSIN (DD *)を処理する(欠落していない場合)ことに注意してください。

JCL構文

JCLジョブは、実行条件を含むまたは含まない、ステップのシーケンスです。カタロガ・オプション・ファイルでjob-card-optionalオプションが指定されている場合を除き、JOBカードで開始する必要があります。

すべてのJCL、JES2およびJES3文が解析されます。JCLはJES2から直接実行できる必要があります。パーサーはJES変数置換を実行します。JCLでローカルに定義されていない変数は、システム記述ファイルのJCL-globalsオプションを使用して設定できます。「特別なオプション」を参照してください。

コメント・カード("//*"で開始)は 同様に認識され、変換用に保持されます。

パーサーはすべての種類のJCLカードを認識します。PROCのオーバーライドおよびrefbackを処理しますがDDカードに限ります。継続カードも処理します。

制限

PROCおよびINCLUDEファイルの両方としてサブファイルを使用

特定の状況では、同じサブファイルをPROCファイルおよびINCLUDEファイルの両方として使用できます。しかしターゲット・ファイルへの変換はそれぞれのケースで異なるので、問題のターゲット・ファイルを複製する必要があり、その1つのコピーを使用してPROCとして変換し、別のコピーをINCLUDEファイルとして変換します。これを達成するには、もちろん2つのコピーが別のディレクトリに配置されていることが必要で、これらのファイルをPROCとして使用するJCLはPROCバージョンを先に見つけ、INCLUDEとして使用するJCLはINCLUDEバージョンを先に見つけるように、検索パスを設定する必要があります(同じJCLが同じファイルをPROCおよびINCLUDEの両方として使用することはできません)。

JCLごとに1つのJOBカードを使用

JCLごとに1つのJOBカードのみを使用できます。複数のJOBカードを含むファイルがある場合、カタロガを実行する前に分割する必要があります。JOBカード内のジョブ名と(単純な)ファイル名が一致することを確認してください。

解析される標準ユーティリティ・コマンド

JCLパーサーは様々な標準ユーティリティ用のコマンドファイル(SYSIN、 SYSTSINなど)の内容をフェッチ(ストリーム内でない場合)し解析します。そのようなユーティリティの現在のリストは次のとおりです。

BMS画面定義

BMSパーサーは次のドキュメントで定義されているようにBMS言語を処理します。

パーサーはすべての正しいBMS定義を受け入れます。また、これは明らかな構文エラーのほとんどをレポートしますが、そのようなエラーのすべての認識しているという意味ではありません。

CICS構成

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が認識されます。すべてのリソース・タイプおよび属性が認識されますが、パーサーおよびエクストラクタで実際に利用されるのはほんのわずかしかありません。

構成ファイルの説明

システム記述ファイル

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

一般構造

Sys-desc-file ::= “system” system-name “root” system-root-path

				global-options special-options 

				directories

system-name

system-root-path

グローバル・オプション

この句の要素は、解析、カタログ化、一般的に言えば、ソース・ファイルの処理に影響を与える様々な設定を指定します。この句の一般的な構文は次のとおりです。

( “options” | “global-options” ) opt-name-1 “=” opt-value-1 “,”
                                 opt-name-2 “=” opt-value-2 “,” ... “.”

各オプションの値には、整数、記号、文字列またはブール・インジケータを使用できます。(次のものがブール・インジケータとして認められます。

オプション名およびオプション値は文字列を除き、大文字・小文字は区別されません。一般的に、これらの設定はアセット全体にグローバルに適用することも、特定のディレクトリにローカルに上書きすることもできます(次を参照)。

ここで受け入れられる様々なオプションを次の表に示します。

特別オプション

特別オプションは、主に構文上の理由で、前述のグローバル・オプション・メカニズムに統合できない句です(値はリストです)。このオプションはグローバル・オプションの前でも後ろでもかまいませんが、間にはできません。すべて次の構文形式をとります。

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句

“type” directory-type

type句はディレクトリのタイプを指定しますが、これは含まれるソース・ファイル(コンポーネント)のタイプのことです。このタイプは大文字・小文字を区別しない記号として指定されます。次のタイプだけが受け入れられます。

files句

“files” file-specs “,” ...

file-specsはディレクトリ内の1つまたは複数のファイルを指定する文字列です。この文字列はアセットに含まれるメンバーを特定し、その他を除外します。file-specの最も単純な形式はtoto.cblのような完全なファイル名です。ディレクトリの表示を指定する必要はなく、指定されたファイルは問題のディレクトリに直接配置する必要があります。ディレクトリ内のすべてのコンポーネントを明示的にリストする作業を避けるために、*.cblや[A-F][D-Z]*.jclといったシェルのような正規表現を使用することもできます。

logical-name句

logical-name lname

この句は、JCL-Sysinタイプのディレクトリで、特別オプションstrict-jcl-libraries(前述を参照)とともに使用されます。ともに使用することで、厳密なJCL-Sysin検索モードが有効になります。lnameは、A.B.C形式の文字列で、ソース・プラットフォームのJCL SYSIN/SYSTSINファイルのライブラリ(PDS)の名前を指定します。この句を有するディレクトリ内のすべてのファイルは、このライブラリに属していると想定されます。

特別オプションstrict-jcl-librariesが設定されていない場合、logical-name句は無視されます。

options句

“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タイプのディレクトリに関係しますが、JCLまたはSQLスクリプト・タイプには関係しません。

さらに、JCLタイプのディレクトリに対するディレクトリ特有のオプション"Right-margin"があります。この値はJCLファイルの"行末"列を指定する整数です。デフォルト値は72で、これはほとんどのIBM JCLソース・ファイルに適しています。

libraries句

“libraries” directory-path “,” ...

libraries句はアセット内の(他の)ディレクトリのパスを検索する順序を指定します。カタロガがソース・ファイルで他のコンポーネントへの参照を見つけるときは常に、参照と一致する名前およびタイプを持つコンポーネント(ソース・ファイル)を見つけるまで、この句で指定したディレクトリのリストを最初から最後まで検索します(後述のサブファイル検索オプションの項を参照)。これはCOBOLプログラムのコピー・ファイルの参照やJCLファイルのPROCの参照などの、コンパイルおよび解析時の参照と、COBOLプログラムのCOBOLサブプログラムの呼出しやJCLジョブのCOBOLプログラムの起動などの実行時の参照の両方で使用されます。この方法で、COBOLコンパイル用のSYSLIBまたはCOPYLIB、JCLの準備および実行用のJOBLIBおよびSTEPLIBなどといった、様々なソース・プラットフォームのライブラリ検索操作の影響をシミュレートできます。

sql-libraries句

“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の値です。

JCLランチャ仕様ファイル

目的

ほとんどのIBMソース・アセットにはプログラム・ランチャ、つまり適用できるプログラムを起動するユーティリティ・プログラムを起動するJCLステップが含まれます。DB2ランチャIEKJFT01などの多くのランチャは、Tuxedo ART 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も含まれています。

フィールド定義

次のフィールド定義は様々なレポートで使用されます。

パス(文字列)

ステータス(列挙: CORRECT、UNUSEDまたはMISSING)

異常レベル(列挙: FATAL、ERROR、WARNING、NOTICE、OK)

MISSING

report-${SYSNAME}-COBOL-Programs

このレポートはアセット内で定義または参照されたすべての(COBOL)プログラムをリストします。これは-Cobol-Batchおよび-Cobol-TPRレポートからなります。

次のフィールドがレポートに含まれます。

次のフィールドは、コンポーネントがMISSINGの場合には空(未定義)です。

また、SUBタイプのコンポーネントの場合、この名前は、サブプログラム自体の名前ではなく、サブプログラムのエントリ・ポイントの名前である可能性があります。これはCALLで参照される名前であり、カタロガではそれが指定しているのがエントリ・ポイントと完全なサブプログラムのどちらなのかを特定できません。

report-${SYSNAME}-COBOL-Copy

このレポートはアセットに含まれるまたは参照されるすべてのCOBOLコピー・ファイル(コピーブック)をリストします。次のフィールドがレポートに含まれます。

次のフィールドは、コンポーネントがMISSINGの場合には空(未定義)です。

report-${SYSNAME}-JCL-Files

ファイルごとに複数のジョブを処理するため、JCLについては、(メイン)ソース・ファイルのレポートとジョブのレポートは別になります。(メイン)ソース・ファイルでは、次のフィールドがレポートに含まれます。

JCLソース・ファイルは決してMISSINGにはならず、JCLジョブだけが欠落する可能性があります。

report-${SYSNAME}-JCL-Sub-Files

このレポートはメイン・ファイルの分析に必要なJCLサブファイルである、PROC、INCLUDEおよび一部のSYSINファイルを説明します。次のフィールドがレポートに含まれます。

次のフィールドは、コンポーネントがMISSINGの場合には空(未定義)です。

report-${SYSNAME}-JCL-Jobs

このレポートはアセット内で定義または参照されたすべてのJCLジョブをリストします。次のフィールドがレポートに含まれます。

report-${SYSNAME}-Screens

このレポートは、アセットで定義または参照されるすべてのBMS画面をリストします。次のフィールドがレポートに含まれます。

画面がMISSINGの場合、次のフィールドは空です。

report-${SYSNAME}-SQL-Tables

このレポートはアセット内で定義または参照されたすべてのSQL表をリストします。次のフィールドがレポートに含まれます。

表がMISSINGの場合、次のフィールドは空です。

report-${SYSNAME}-SQL-Views

このレポートはアセット内で定義または参照されたすべてのSQLビューをリストします。次のフィールドがレポートに含まれます。

report-${SYSNAME}-Transactions

このレポートは、アセット内のRDOファイルに定義されたすべてのCICSトランザクションをリストします。次のフィールドがレポートに含まれます。

トランザクションがアセットで参照され(RETURN TRANSID文など)、それがRDOファイルで定義されていない場合、パスおよび行番号フィールドは空でこのレポートにリストされます。

report-${SYSNAME}-Anomalies

このレポートは、アセット内のすべてのコンポーネントで検出されたすべての異常をリストします。次のフィールドがレポートに含まれます。

その他の出力ファイルの説明

カタロガの結果は、前述した一連のカタロガ・レポートで表示できます。これらのレポートが唯一の出力ではなく、また最も重要な出力でもありません。この項では、その他の結果ファイルについて簡単に説明します。これらは独自形式のバイナリファイルで、Persistent Object Base (POB)と呼ばれます。これらのファイルは、人間による処理や、従来のテキストベースのツールでの処理には適しておらず、カタロガ自体やTuxedo ART Workbenchのその他のツールでの使用に向いています。

AST用POBファイル

解析フェーズ中に(カタロガ・プロセスを参照)、システムの各解析可能コンポーネントのソース・ファイルA/B/C/file.extに対し、カタロガはA/B/C/pob/file.ext.pob (pobディレクトリはカタロガにより要求時に作成)という名前のPOBファイルを生成します。このファイルにはコンポーネントの抽象構文ツリー(AST)という名前の解析結果が含まれます。これはカタロガの分析フェーズで、またCOBOLコンバータやJCLトランスレータなどのその他のTuxedo ART Workbenchツールにより、再度読み取られます。

COBOLプログラムおよびコピー・ファイル用CDMファイル

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ファイルは生成されません。

カタロガSymtabおよびその他のファイル

詳細処理

処理フェーズ

「カタロガ・プロセス」で説明したように、この操作は解析、分析、分析後およびレポート生成(詳細は下記を参照)の4つのフェーズに論理的に分割されます。プロジェクトおよび移行プラットフォームの構成の必要に応じて、これらのフェーズは単一の実行または増分的に、順次または同時に(解析フェーズのみ)実行することができます。

プロジェクトおよび移行プラットフォームの構成の必要に応じて、これらのフェーズは単一の実行または増分的に、順次または同時に(解析フェーズのみ)実行することができます。次の3つの基本的なTuxedo ART Workbenchコマンドがカタロガを起動します。

また、組み合わされたコマンドもあります。

コマンド行の構文

Tuxedo ART Workbenchランチャ

カタロガはrefineコマンドを使用して実行するようになっています。refineコマンドは汎用的なTuxedo ART Workbenchランチャで、これを使用して主なTuxedo ART Workbenchツールを起動します。ランチャは後述する(繰返しおよび増分操作)実行ログ管理、増分および繰返し操作などの、これらのツールの様々な操作を処理します。Tuxedo ART Workbenchランチャはいくつかの汎用のコマンド行オプションも処理します。

形式

コマンド行で、Tuxedo ART Workbenchツールを起動するのに使用される一般的な形式は次のとおりです。

$REFINEDIR/refine command [ launcher-options… ] \

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

		[ command-specific-options-and-arguments… ]

オプション

次のオプションがTuxedo ART Workbenchのcommandと関係があります。

-h, -help, --help

– whoami

-archi64 / -archi32

-quiet

-time

-nolog

-n, -N, -verbose, -VERBOSE

次のオプションは技術的にはランチャ・オプションではありませんが、すべてのTuxedo ART Workbenchツールで受け入れます(実際には必須です)。

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

さらに、次のオプションが将来の使用のために予約されています(現在、これは受け入れられますがそれ以外は無視されます)。

(-v | -V | -version) version-string

汎用的なランチャ・オプション

最後に、ランチャは次の汎用的なオプションを使用して、コマンドなしで起動することができます。

$REFINEDIR/refine (-h | -help)

$REFINEDIR/refine -print-info-version

システム全体のコマンド

処理フェーズで説明したとおり、システム全体のコマンドは、preparse、analyze、fast-finalおよびcatalogです。これらはアセット全体でグローバルに動作します。これらすべてのコマンドの汎用的なコマンド行構文は次のとおりです。

$REFINEDIR/refine command [ launcher-options… ] \

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

これらのコマンドには特有のオプションはありません。すべての構成情報はシステム記述ファイル、カタロガのオプション・ファイル 、および場合によってはヒント・ファイルにあります。

preparse-filesコマンド

説明

上記で説明した、アセット全体でグローバルに動作し処理するコンポーネントをそれ自身が決定するシステム全体のカタログ化コマンドとは異なり、preparse-filesコマンドでは、解析するコンポーネントを指定することができます。

処理するコンポーネントを指定できるということから、preparse-filesコマンドはmakefileでの使用に適しています。また、特にソース・ファイルをいくつかのリストに区切って各リストを個別のプロセスに与える場合には、これは同時実行の対象になります。

形式

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 )…

オプション

追加のオプションは、処理するコンポーネント・ソース・ファイルを示します。

source-file-path

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

コンポーネントの検索操作

この項では、カタロガがライブラリおよびシステム記述ファイル内のsql-libraries句を使用して、現在処理されているコンポーネントの特定の構成内で参照されるコンポーネントを検索する方法を説明します。この操作は、参照がどれであるかによって多少異なります。

コンパイル時の参照

コンパイル時のケースは、現在のコンポーネントの重要な部分であるサブファイルへの参照に適用されるため、サブファイルが見つからないと、コンポーネントは分析および正確に"理解"されません。たとえば、COBOLメイン(プログラム)ソース・ファイルから参照されるCOBOLコピーブックです。

PROCファイル、INCLUDEファイルおよびいくつかのSYSINファイルのようなJCLジョブから参照されるJCLサブファイルも含まれますが、これは、MVSプラットフォームでは、これらのサブファイルはJCLジョブが実行されるときに検索される(したがって実行時参照である)のに対し、移行プラットフォームでは、カタロガがこれらの参照を解析時に解決し、JCLトランスレータが使用できるようにする(したがってコンパイル時参照とみなされる)必要があるためです。SYSINファイルも、DB2ランチャにより起動されるプログラムなど、解析時に必要な情報を含んでいるため、この場合にあてはまります。カタロガでは、"コンパイル時"は解析に、"実行時"は分析後に相当します。

検索は、ディレクトリSRCDIRに配置され、特定のタイプTGTTYPのTGTFILという名前のコンポーネントを参照する、特定のタイプSRCTYPのSRCFILとして識別されたコンポーネントから開始されます。次の表に可能性のある様々な組合せを示します。

通常のサブファイルの検索

検索アルゴリズム・プロセスは次のとおりです。

厳密なJCL-Sysin検索

このアルゴリズムは、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ディレクトリ名を指定するよりも簡単です。

フル・ネームによるJCL-Sysin検索

このアルゴリズムは、Full-Name-Sysin-Search特別オプションが指定されている場合に、JCL-Sysinファイルを検索するために変更されます。このオプションが設定されている場合、SYSIN/SYSTSINファイル

A.B.CまたはA.B(C)の検索が次のように続行されます。

JCL-Sysinディレクトリ内のファイルの検索に、ファイル名A.B.CまたはA.B/Cが使用されます。

実行時参照

実行時のケースは、実際には参照するコンポーネントの一部ではない外部コンポーネントへの参照に適用されます。参照されるコンポーネントが存在しなくても、参照するコンポーネントの分析または変換は可能ですが、不適切な実行が発生します。たとえば、サブプログラムを呼び出すCOBOLプログラムまたはプログラムを実行するJCLジョブなどです。カタロガでは、このような参照は分析後フェーズで処理されます。

タイプTGTTYPの名前TGTFILを参照するディレクトリSRCDIRに配置されたタイプSRCTYPのコンポーネントSRCFILから検索が開始されます。考慮する2つのケースがあります。

無制限の検索

これは、ディレクトリSRCDIRに関連するlibraries句にタイプTGTTYPの要素(ディレクトリ)が含まれていない場合に適用されます。これは"デフォルト・ケース"とみなすことができます。検索アルゴリズムは次のとおりです。

指定検索

指定検索は、コンパイル時参照の通常のサブファイル検索と似ています。これは、ディレクトリSRCDIRに関連するlibraries句にタイプTGTTYPの要素(ディレクトリ)が1つ以上含まれている場合に適用されます。検索アルゴリズムは次のようになります。

このアルゴリズムでは、「参照が曖昧です。」という異常が発生することはありません。これは、指定したディレクトリにある指定したベース名のファイルは多くても1つだけであるためです。このため、このアルゴリズムは、異なるディレクトリ(またはライブラリ)に同じ名前を持つコンポーネントが複数含まれるシステムを分析する場合に適しています。ただし、SRCTYPの各ディレクトリに対して、ライブラリ句の適切なTGTTYP要素を適切な順序で定義する必要があるため、追加の設定作業が必要になります。

検索対象のコンポーネントの指定したTGTTYP、および適切なSRCTYPそれぞれについて、一部のSRCTYPディレクトリには指定検索、同じタイプの別のディレクトリには無制限検索を使用できます。実際には、コンポーネント名が重複する場合、それらが実際に参照された場合のみ問題(異常)が発生します。ただし、このような状況は混乱を招くため、次のようにすることをお薦めします。指定したSRCTYP/TGTTYPの組合せに対して、すべてのソース・ディレクトリに無制限検索を使用するか、または指定検索を使用するかのいずれかにしてください。

繰返しおよび増分操作

強力なコンピューティング・プラットフォームが容易に使用可能である今日であっても、Tuxedo ART Workbenchを使用した完全なアセットの処理は、依然として計算集中的で長時間の実行、メモリーを消費するタスクのままです。

そのため、Tuxedo ART Workbenchツールは容易に停止および再起動できるように設計されています。このツールはmakeに似たメカニズムを使用して、すでに実行された作業を繰り返さないようにします。これにより、移行プロジェクトのすべてのフェースで効率的な操作が可能です。

最初の処理: 繰返し操作

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

このモードは、カタロガの分析またはカタログ化コマンドのような、アセット全体でグローバルに動作するツールまたはコマンドに特に適しています。これはTuxedo ART Workbenchツールの通常モードでの動作であり、これを選択するのに何かをする必要はありません。

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

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