カタロガ

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

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

•

カタロガの概要

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

•

構成ファイルの説明

•

出力ファイルの説明

•

詳細処理

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

•	繰返しおよび増分操作

カタロガの概要

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

•	ソース・ソフトウェア・システムのすべてのコンポーネントを個別および一緒に分析して、このシステムに一貫性があるか、移行できるかどうかを決定します。この分析中に検出された異常は、他のインベントリ情報とともに、カタログ化レポートで報告されます。

•	Tuxedo ART Workbenchのその他のツールで使用される、このコンポーネントおよび相互関係の内部形式を生成します。

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

•	ソース・プラットフォームから移行プラットフォームに転送され、より適切に表示および処理されるように変換された後の、ソース・アセットのコンポーネントのソース・ファイル。

•	次の1つまたは複数の構成ファイル

•	移行プラットフォーム・ファイル・システムでの入力ソース・ファイルの編成方法を記述し、その解析に必要な追加のパラメータも指定した、システム記述ファイル(必須)。

•	カタロガの分析フェーズにパラメータを提供する、カタロガ・オプション・ファイル(オプション)(「詳細処理」を参照)。

•	カタロガおよびJCLトランスレータが起動する実際のプログラムの名前などの関連情報を抽出できるように、指定したアセットで使用されるランチャの記述に使用されるJCLランチャ仕様ファイル。

•	動的プログラム呼出しなど、カタロガ自体では検出できない情報を提供するヒント・ファイル(オプション)。

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

•	アセットのコンポーネントおよびそのステータス(正常、未使用、欠落)を記述した、CSV形式の、カタログ・レポートのセット。

•	各(解析可能)コンポーネントに対するコンポーネントの内部形式を含み、変換などのその後の処理に適したバイナリPOBファイル。

•	カタロガおよびその他のTuxedo ART Workbenchツールで使用される、Symtab (「カタロガSymtabおよびその他のファイル」を参照)などのその他のシステム全体のPOBファイル。

•	必要な場合、その他のTuxedo ART Workbenchツールにより使用される、その他のバイナリ以外のファイル。

カタロガ・プロセス

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

1.	解析: 各コンポーネントが順番に読み出され、解析(構文分析)およびリンクされ(セマンティック分析)、対応するPOBファイルが生成されます。

2.	分析: 各コンポーネントのPOBファイルが再度読み取られ、コンポーネントで最も重要な構造が、カタロガ記号表(symtab)に格納されたより小さなサマリー情報に変換されます。

3.	分析後: symtabおよびサマリー情報を使用して、カタロガは、各コンポーネントに対する正常、未使用または欠落のラベル付けを可能にする相互参照リンクを計算します。

4.	レポート生成: 相互参照リンクで修飾されたsymtabが巡回され、各コンポーネントに対して情報が出力されます。

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

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

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

•	COBOLプログラム(EXEC SQLまたはEXEC CICS文、あるいは両方を含む可能性もあり)

•

JCLスクリプト

•	データベース・スキーマを定義するSQL DDLスクリプト

•	CICSトランザクションを定義するCICS RDOファイル

•	関係のある場合、前述のタイプのサブファイル

COBOL

参考資料

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

制約

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

•	コンパイラ・ユニットごとに複数のプログラム、特にネストされたプログラム。

•	すべてのオブジェクト指向機能。

•	DBCS (USAGE DISPLAY-1)およびUnicode (USAGE NATIONAL)構成。

•	MBCSは変数名をサポートしません。

•	ミレニアム言語拡張(日付フィールド)。

サブプログラム

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

例:

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

リスト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 Runtimeシステムで提供されます。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つのタイプがあります。

•	ユーティリティ・プログラム用SYSIN (またはSYSTSINまたは他のコマンド・ファイル): 多くの場合、これらのファイルにはカタロガの対象となる情報(DB2ランチャIEKJFT01により起動されるプログラムの名前など)またはトランスレータの対象となる情報(IDCAMSにより実行される操作やDFSORTのソート・スクリプトなど)が含まれます。その結果、これらはカタログ化の前にアセットに存在している必要があります(JCL-Sysinタイプ使用、「type句」を参照)。

•	適用可能(COBOL)プログラムのSYSIN (またはSYSTSIN): これらのファイルは標準のデータ・ファイルと同様に処理され、Tuxedo ART Workbenchにより処理されるアセットに存在する必要はありません。

すべての参照される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など)の内容をフェッチ(ストリーム内でない場合)して解析します。そのようなユーティリティの現在のリストは次のとおりです。

•

IEBUPDTE

•

IEBGENER

•

IEBCOMPR

•

IEBCOPY

•

IEHPROGM

•

IEBDG

•

IEHLIST

•

IEBMOVE

•

IEBPTPCH

•

IDCAMS

•

DFHSORT

•

ICETOOL

•

IEH-MOVE

•

IEKJFT01

•

DSNUTILB

•

DSNTIAUL。

注意:	これらのユーティリティのサポート、たとえばコマンド言語を処理するパーサー機能などは、部分的である可能性があります。

BMS画面定義

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

•	IBMのマニュアル『CICS Application Programming Reference』(資料番号SC34-6434-05、CICS V3R1用)の付録Detailed reference information for the CICS API commandsのBMS macrosの章。

•	IBMのマニュアル『CICS Application Programming Guide』(資料番号SC34-6433-04、CICS V3R1用)のPart 6 Basic Mapping Support (BMS)のCreating the mapの章。

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

CICS構成

CICS構成パーサーは、バッチ・ユーティリティDFHCSDUP (『IBM CICS Transaction Server for z/OS Resource Definition Guide Version 3 Release 2』、資料番号SC34-6815-00を参照)で読み取られるCICSリソース定義言語を処理します。認識されるコマンドは、DELETE ALL、ADD、REMOVEおよびDEFINEです。すべてのリソース・タイプおよび属性が認識されますが、パーサーおよびエクストラクタで実際に利用されるのはほんのわずかしかありません。

構成ファイルの説明

システム記述ファイル

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

一般構造

リスト3-2 システム記述ファイルの構造

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

global-options special-options

directories

 

注意:	ファイルの形式は基本的には自由で、行の長さの制限もありません。コメントはパーセント文字で開始し、行の終わりで終了します。

注意:	記号(名)の形式には[A-Z][a-z][0-9][*-_]の文字を含めることができます。記号は数字を先頭にできますが、少なくとも1つの文字が必要です。キーワードおよび記号(名)では大/小文字は区別されません。文字列では大/小文字は区別されます。

system-name

システム記述ファイルの最初の要素は、アセットの名前を指定する記号です。この名前は、Tuxedo ART Workbenchツールが参照にのみ使用するため、自由に選択できます。また、Tuxedo ART Workbenchツールにより生成される一部のファイルおよびディレクトリの名前にもこの名前が含まれます。

system-root-path

2番目の要素は、Linux移行プラットフォーム上のすべてのコンポーネント・ソース・ファイルを含むディレクトリのパスを指定する文字列です。このディレクトリはファイル・システムのどこにでも配置できます。このパスは絶対形式(スラッシュ文字で開始)または相対形式のいずれかで指定できます。後者の場合、パスはシステム記述ファイル自体を含むディレクトリへの相対パスです(通常、ソース・ファイルを含むsourceディレクトリの他にparamディレクトリに配置されますが、Tuxedo ART Workbenchツールはここで記述された構成を受け入れます)。

グローバル・オプション

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

リスト3-3 システム記述ファイルのグローバル・オプション

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

 

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

•

なし(true)。

•	文字列trueまたはTRUE。

•	記号true(大文字・小文字を区別せず)

•	文字列falseまたはFALSE。

•	記号(false)。

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

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

 

表3-1 グローバル・オプション

オプション名	タイプ	ローカル	説明
Catalog、catalog-option	文字列	いいえ	カタロガ・オプション・ファイルのパス(次を参照)。このパスは絶対形式または相対形式のいずれでも指定できます。後者の場合、パスはシステム記述ファイル自体を含むディレクトリへの相対パスです。この句はオプションで、指定しない場合、カタロガはオプション・ファイルを読み取ろうとせず、すべてのオプションにデフォルト値が使用されることに注意してください。
Cobol-Right-Margin	整数(> 60)	はい	COBOLプログラムの領域Cの開始列。デフォルト値は66で、列1-6および72-80が削除された固定形式のプログラムに適しています。
Cobol-Left-Margin	整数(< 12)	はい	COBOLプログラムのコメント列。デフォルト値は1で、列1-6および72-80が削除された固定形式のプログラムに適しています。
Remove-Cobol-Reserved-Word	文字列	はい	このオプションは、COBOLパーサーに、(IBM COBOL LE言語で)予約済とみなされたキーワードが、実際には、このアセットまたはディレクトリで使用される実際の言語で予約されていないことを伝えるために使用されます。このオプションは同じシステムまたはディレクトリで複数回指定できます。各プログラムで、予約済ではないとみなされるこのようなキーワードのリストは、この名前のすべてのローカル(ディレクトリ)またはグローバル(システム)オプションで指定されたすべての値を累積することで作成されます。デフォルト値は空のリストです。
No-END-Xxx-Warnings、No-END-Xxx	ブール	はい	trueの場合、構成を含むある文が適切なEND-xxxキーワード以外のために閉じられていないときでも報告しません。デフォルト値はfalse、つまり報告します。false値をこのオプションに関連付けることはできますが、その意味が逆になることに注意してください。
Yes-End-Xxx-Warnings、Yes-End-Xxx、END-Xxx-Warnings	ブール	はい	前のオプションNo-END-Xxx-Warningsの逆です。同じディレクトリまたはグローバル・レベルで、両方のオプションは使用できませんが、片方のオプションをグローバル・レベルで、もう片方のオプションをいくつかのディレクトリで使用することはできます。false値をこのオプションに関連付けることはできますが、その意味が逆になることに注意してください。
SQL-Schema、Default-SQL-Schema	文字列または記号	はい	明示的に指定されていない場合にSQLコードで使用するスキーマの名前。これは、スタンドアロンSQLコード(DDL、SQLスクリプト・タイプのファイル)およびCOBOLプログラムに埋め込まれているSQLコードに適用されます。
SQL-Use-Reversed-Delimiters、SQL-Reversed-Delimiters	ブール	はい	trueの場合、このディレクトリまたはシステムのSQLコードは、文字列に二重引用符、デリミタ付き識別子に一重引用符を使用します。デフォルトの動作(false値の場合)はこの逆で、文字列に一重引用符、デリミタ付き識別子に二重引用符を使用します。
SQL-No-Keyword-Is-Reserved、SQL-Keywords-Not-Reserved	ブール	はい	trueの場合、このディレクトリまたはシステムのSQLコードのキーワードは予約済とみなされません(DB2バージョン8以前で使用)。デフォルトの動作(false値の場合)は、すべてのキーワードが予約済とみなされるので、他の目的で使用されると報告されます(DB2バージョン9と同様)。
SQL-Right-Margin	整数(> 0)	はい	SQLスクリプト・ファイルの行末列(COBOLプログラムに埋め込まれたSQLコードには適用されません)。列1-6および72-80が削除された固定形式のファイルでは66を設定します(COBOL)。デフォルト値は「infinite」で、自由形式のファイルに適しています。左マージンは常に1のため、固定形式のファイルの列1-6を無視する場合は、これらを物理的に削除する必要があることに注意してください。
jclz-launcher-spec-file、jclz-launcher-specs-file	文字列	はい	このシステムまたはディレクトリで使用するJCLランチャ仕様ファイルのパス。これらのファイルの内容と使用方法の詳細は、「JCLランチャ仕様ファイル」を参照してください。このパスは絶対形式または相対形式のいずれでも指定できます。後者の場合、パスはシステム記述ファイル自体を含むディレクトリへの相対パスです。

特別オプション

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

リスト3-4 システム記述ファイルの特別オプション

opt-name “=” opt-value “.”

 

等号および末尾のピリオドは必須です。値がリストの場合、リスト内の項目はカンマで区切る必要があります。特別オプションを次の表で説明します。

 

表3-2 特別オプション

オプション名	タイプ	説明
minimum-free-ram-percent	整数(> 0および< 100)	カタロガおよび様々なすべてのTuxedo ART Workbenchツールの実行中に、他のプロセスが使用できる空き物理メモリーの割合。一般に、これらのツールは処理するコンポーネントの数に応じて、より多くのメモリーを消費します。この限界に到達すると、ツールは停止し実行を再開します。増分実行により、すでに処理したコンポーネントは再度処理されないため、結局、必要な作業はすべて行われます。
JCL-globals	ペアvar-name = var-valueのリスト(カンマ区切り)	Var-nameは記号(または記号として解釈される文字列)で、var-valueは文字列です。JCLスクリプトの解析時に、パーサーはJES2により実行されるJCL変数置換プロセスをシミュレートします。ここで指定されるname-valueペアは(パラメータなどとは対照的に)グローバル変数の置換に使用されます。パーサーは変数に適した値が見つからないとエラーをレポートします。
strict-jcl-libraries	なし(ブール・フラグ)	このオプションの存在は、JCLにより参照されるSYSIN/SYSTSINファイルがシステム全体で検索される方法に影響を与えます。後述の「サブファイル検索」の章を参照してください。
Dbms-version	文字列または記号	ソース・プラットフォームで使用されるDB2リレーショナルDBMSのバージョン。これはRDBMSツールで使用されます(q.v.)。
use-file-catalog	なし(ブール・フラグ)	このオプションの存在により、ファイルまたはDDにカタログおよびボリュームの情報が提供されます。存在しない場合、カタログおよびボリュームは提供されません。詳細は、「JCLトランスレータ」およびファイル・コンバータに関する項を参照してください。これは、FILE-TO-FILE、FILE-TO-ORACLEおよびFILE-TO Db2/luw (udb)コンバータにも影響します。
enable-buffer-converter	なし(ブール・フラグ)	このオプションが存在する場合は、バッファ・コンバータ機能が有効になり、z/OS形式とUNIX/Linux形式間でデータを変換するための2つのCOBOLプログラムが生成されます。バッファには、ソース・データとターゲット・データの両方が格納されます。 このオプションが設定されていない場合、関連するCOBOLプログラムは生成されません。詳細は、FILE-TO-FILEに関する項を参照してください。
enable-reverse-converter	なし(ブール・フラグ)	このオプションが存在する場合は、逆コンバータ機能が有効になり、UNIX/Linuxレコード・シーケンシャル・ファイルからz/OSシーケンシャル・ファイルにファイルを変換するための1つのCOBOLプログラムが生成されます。このCOBOLプログラムを呼び出すための1つのスクリプトも生成されます。 このオプションが設定されていない場合、関連するCOBOLプログラムとスクリプト・ファイルは生成されません。詳細は、FILE-TO-FILEに関する項を参照してください。
default-sequential-mode	文字列または記号	このオプションは、シーケンシャル・ファイルの移行のデフォルト動作を示しています。 default-sequential-modeは、recordまたはlineに設定できます。 • lineは、ライン・シーケンシャル・ファイルへの移行を示しています。これがデフォルト値です。 • recordは、レコード・シーケンシャル・ファイルのままにすることを示しています。
dont-parse-exec-sql	なし(ブール・フラグ)	このオプションは、EXEC SQL文の解析を無効にします(ただし、EXEC SQL INCLUDE文の解析は無効にできません)。
microfocus-cobol (またはmf-cobol)	なし(ブール・フラグ)	このオプションは、COMP-6、STOP RUN RETURNING 1文のサポートなど、Micro Focus COBOLの拡張を有効にします
use-fileschema-as-dbschema	なし(ブール・フラグ)	このオプションでは、生成された表およびその他のデータベース・オブジェクトにデータベース・スキーマとして構成されたファイル・スキーマを適用します。 設定されない場合、生成されたデータベース・オブジェクトに対してデータベース・スキーマは指定されません。これは、デフォルトの動作です。これは、File-to-Oracleコンバータにのみ有効です。

ディレクトリ

システム記述ファイルのメイン・コンポーネントはディレクトリ句のリストで、指定したアセットの様々なソース・ファイルの場所、そのタイプと相互関係を指定します。各句の構文は次のとおりです。

リスト3-5 システム記述ファイルのディレクトリ

“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句はディレクトリのタイプを指定します。これは、ディレクトリに含まれるソース・ファイル(コンポーネント)のタイプです。タイプは大/小文字を区別しない記号として指定されます。次のタイプのみを使用できます

 

表3-3 有効なディレクトリ・タイプの句

タイプ	説明
Cobol-Batch	バッチ操作で使用される主要なCOBOLプログラム(JCLによって参照されます)。EXEC SQLコード(データ操作言語(DML))が含まれる場合があります。
Cobol-TPR	TP操作で使用される主要なCOBOLプログラム(トランザクションおよびCICS XCTLコマンドによって参照されます)。EXEC SQLおよびEXEC CICSコードが含まれる場合があります。
COBOL-Library、COBOL-Copy	COBOLコピー・ファイル(コピー・ブック)。主要プログラム・ファイルに含まれます。
SQL-Script	原則的にDDL (データ定義言語)文を含むスタンドアロンSQLコード。SQLスクリプト・ファイルのセットは、システム内で使用されるデータベース・スキーマをまとめて定義します。
JCL	メインJCLファイルで、1つまたは複数のJCLジョブを定義します。
JCL-Lib	JCLサブファイルで、EXECにより起動されるプロシージャを定義する、またはINCLUDEにより起動される文を含みます。
JCL-Sysin	JCLスクリプトのユーティリティ・プログラムまたはプログラム・ランチャにより使用されるSYSIN/SYSTSINファイル。すべてのSYSINファイルが、パーサー/カタロガで必要なわけではありません。詳細は、Tuxedo ART Workbench JCLトランスレータのリファレンス・マニュアル(「入力コンポーネントの説明」)を参照してください。
BMS	BMS画面の定義(ソース・フォーム内)
RDO	CICSを構成するためにRDOによって使用される、CICSシステム定義ファイル(CSD)。IBM社の『CICS Resource Definition Guide』を参照してください。

files句

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

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

注意:	システム記述ファイルで指定されたすべてのファイル(アセット内のすべてのソース・ファイル)は、ファイル名のみでなく、ファイル拡張子が付いていることが重要です。この拡張子は自由に選択できますが、存在している必要があります。COBOLプログラムにはcbl、COBOLコピー・ファイルにはcpy、メインJCLファイルには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句

リスト3-6 options句

“options” opt-name-1 “=” opt-value-1 “,”
opt-name-2 “=” opt-value-2 “,” ...

 

構文的には、このディレクトリ固有のoptions句は、システム全体のグローバル・オプション句と似ていますが、末尾のピリオドが違います。意味としては、リストされたオプションと値はグローバル・オプションと同じ効果がありますが、ローカルにディレクトリに含まれるファイルのみに適用されます(同じ名前でグローバル・オプションをオーバーライドします)。グローバル・オプション表のlocal?列にyesとマークされているものと同じオプションは、それが関係するソース・ファイルのタイプを含むディレクトリに適用されます。たとえば、オプションcobol-right-marginはCOBOL-BatchおよびCOBOL-TPRタイプのディレクトリに関係しますが、JCLまたはSQLスクリプト・タイプには関係しません。

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

libraries句

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

libraries句は、アセット内の(他の)ディレクトリの順序付けられた検索パスを指定します。カタロガがソース・ファイルで他のコンポーネントへの参照を見つけるときは常に、参照と一致する名前およびタイプを持つコンポーネント(ソース・ファイル)を見つけるまで、この句で指定したディレクトリのリストを最初から最後まで検索します(詳細は、後述の「Sub-file search operation」の項を参照)。これは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ディレクティブを解決するためのlibraries句と同じように機能します。これを省略すると、このような参照の解決は通常のlibraries句と同じ検索パスを使用しますが、通常のCOPYディレクティブおよびSQL INCLUDEディレクティブに異なる順序を使用する必要がある場合があります。

システム記述ファイルの例

リスト3-7 システム記述ファイルの例

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です。グローバル・オプションは次のコメントを呼び出します。

•	no-end-xxx-warningsオプションにより、暗黙的に閉じられたCOBOL構成をlenientモードで解析できます。

•	cobol-left-marginおよびcobol-right-margin値は、左側に番号列および右側にコメント列(領域C)がある、未変換のIBM形式の固定形式プログラムに設定されます。この形式がCOBOL解析に対し何も問題を引き起こさなかったとしても、そのCOBOL変換の正しい操作を保証できないことに注意してください。

様々なディレクトリの命名と構造は完全に標準で、アセット内のソース・ファイルはそのファイル拡張子によってのみ識別されます。ここで通常と異なる機能は、Batchディレクトリに対する特別なcobol-right-marginの値です。

JCLランチャ仕様ファイル

目的

IBMソース・アセットの多くにはプログラム・ランチャ、つまり適用できるプログラムを起動するユーティリティ・プログラムを起動するJCLステップが含まれます。DB2ランチャIEKJFT01などの多くのランチャは、Tuxedo ART WorkbenchカタロガのJCLパーサーおよびアナライザにより直接認識されます。ただし、多くの場合、このようなランチャはインストールに固有であり、特別な処理を必要とするものがあります。幸いにも、これらの多くは汎用的なJCL起動メカニズムと構文(EXEC PGMカード)を使用し、関連する起動情報はPARM値に含まれます。

JCLランチャ仕様ファイルの目的は、カタロガおよびJCLトランスレータが、起動する実際のプログラムの名前などの関連情報を抽出できるように、指定したアセットで使用されるランチャを説明することです。仕様はほとんどの場合、PARM値は特定のセパレータ文字(標準のJCLのセパレータであるカンマであるとはかぎらない)により個々のパラメータに分割され、プログラム名、PSB名、PLAN名などを指定するパラメータはシーケンス内で適切に定義された位置にあるという事実に基づきます。

構文

JCLランチャ仕様ファイルは、次の構文の自由形式テキスト・ファイルで、ここではすべてのキーワードと記号は大文字・小文字を区別しません。

リスト3-8 JCLランチャ構文

LAUNCHER <Launcher name>

[<option-name> = <option-value> [,

... ]

]

END

...

 

オプション・リスト

最後の3つのオプションはデフォルト値がありません。オプションがない場合、対応する情報は単に使用できません。

•	セパレータ: フィールドの区切りとして使用される文字で、1文字である必要があります。デフォルトはカンマ文字「,」です。

•	IndexProg: プログラム名の索引で、整数である必要があります。これは、指定されたランチャの唯一の必須オプションです。

•	IndexPSB: PSB名の索引で、整数である必要があります。

•	IndexPlan: プラン名の索引で、整数である必要があります。

•	IndexParm: パラメータ名の索引で、整数である必要があります。

使用方法とデフォルト値

ディレクトリにアタッチされたローカルのjclz-launcher-spec-fileオプションが存在する場合、通常はグローバル・オプションをオーバーライドします。指定したディレクトリおよびシステム全体のいずれにもランチャ仕様ファイルが指定されていない場合、デフォルト値は次のファイルを使用したかのようになります。

リスト3-9 デフォルト・ランチャ値

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)

CORRECT

コンポーネントがアセット内に存在し、少なくとも1つのそこへの参照が1つまたは複数の他のコンポーネントに見つかりました。つまりコンポーネントは使用されています。

UNUSED

コンポーネントがアセット内に存在していますが、そこへの参照が他のコンポーネントに見つかりませんでした。

MISSING

コンポーネントがアセットに存在せず、少なくとも1つのそこへの参照が見つかりました。

注意:	UNUSEDおよびMISSINGは(コンポーネント間)異常とみなされます。

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

内部分析中に、問題のコンポーネントで検出された異常の最大レベルです。

FATAL

構文エラーなどのリカバリ不能なエラーが検出されました。分析の結果は不完全で、コンポーネントまたはアセットは変換に適していません。

ERROR

宣言されていない変数などのリカバリ可能なエラーが検出されました。分析の結果は正確でない可能性があり、コンポーネントまたはアセットは変換に適していません。

WARNING

分析中または変換後に、問題(不正確)を引き起こす可能性のある状況が検出されましたが、コンポーネントは変換に適しています。

NOTICE

注目すべき状況が検出されましたが、問題を引き起こすものではありません。

OK

異常は検出されませんでした。

注意:	コンポーネントがMISSINGの場合、すべてユーザーにより提供された情報に応じて、このフィールドはアセットに存在しないコンポーネントに対する句を記述する識別子で置き換わります(SYSTEM、CORRECTまたはPROBLEM)。

MISSING

コンポーネントがMISSINGの場合、すべてユーザーにより提供された情報に応じて、このフィールドはアセットに存在しないコンポーネントに対する句を記述する識別子で置き換わります(SYSTEM、CORRECTまたはPROBLEM)。

report-${SYSNAME}-COBOL-Programs

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

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

 

表3-4 COBOLレポート・フィールド

フィールド	タイプ	説明
名前	記号	(エンベロープ)ファイル名で定義されたプログラム名。
パス	文字列	「フィールド定義」を参照してください。これはプログラムを定義する(メイン)ソース・ファイルのパスです。 注意: Tuxedo ART Workbenchは現在、同じファイル内で複数のプログラムを処理しません。
タイプ	列挙: BATCH、TPまたはSUB	システム記述ファイルの分類により定義されたプログラムのタイプ(Cobol-Batch、Cobol-TPR)。
場所	整数	コピー拡張後のプログラムの合計行数。
NPar	整数	Procedure Divisionのパラグラフ数。
ステータス	列挙	「フィールド定義」を参照してください。
異常レベル	列挙	「フィールド定義」を参照してください。

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

•

パス

•

場所

•

Npar

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

report-${SYSNAME}-COBOL-Copy

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

 

表3-5 COBOLコピー・レポート・フィールド

フィールド	タイプ	説明
名前	文字列	(エンベロープ)ファイル名により、および場合によってはシステム記述ファイル内の構成ディレクトリのlogical-name句により定義された、コピー・ファイルの論理名。
パス	文字列	「フィールド定義」を参照してください。
場所	整数	コピー・ファイルの行数。
ステータス	列挙	「フィールド定義」を参照してください。

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

•

パス

•

場所

report-${SYSNAME}-JCL-Files

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

 

表3-6 JCLソース・ファイル・レポート・フィールド

フィールド	タイプ	説明
パス	文字列	「フィールド定義」を参照してください。
場所	整数	PROC、 INCLUDEおよびSYSINの拡張後の、JCLファイルの合計行数。
NJob	列挙	このファイルに定義されたジョブの数。
異常レベル	列挙	「フィールド定義」を参照してください。これは含まれているすべてのジョブの最高異常レベルと少なくとも同じ高さで、構文エラーの場合にはさらに高いこともあります。

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

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

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

 

表3-7 JCLサブファイル・レポート・フィールド

フィールド	タイプ	説明
名前	文字列	メイン・ファイルから参照されるサブファイルの名前。
パス	文字列	「フィールド定義」を参照してください。
タイプ	列挙: PROC、INCLUDEまたはSYSIN	システム記述ファイルおよびメイン・ファイルでの参照に使用される構成の分類により定義されたサブファイルのタイプ。
場所	整数	サブファイルの行数。
ステータス	列挙	「フィールド定義」を参照してください。

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

•

パス

•

場所

report-${SYSNAME}-JCL-Jobs

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

 

表3-8 JCLジョブ・レポート・フィールド

フィールド	タイプ	説明
名前	文字列	JOBカードで定義されたジョブの名前。
パス	文字列	「フィールド定義」を参照してください。これはジョブを定義する(メイン)ファイルのパスです。
場所	整数	サブファイルの拡張後の、ジョブ自体の行数(JOBカードからENDJOBカードまで)。
NStep	整数	このジョブで定義されたステップ数。
ステータス	列挙	「フィールド定義」を参照してください。
異常レベル	列挙	「フィールド定義」を参照してください。これはジョブ自体の異常レベルで、通常は構文エラーは考慮しません(後者はジョブの分析を妨げるため)。

report-${SYSNAME}-Screens

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

 

表3-9 画面レポート・フィールド

フィールド	タイプ	説明
名前	文字列	mapset-name.map-nameという形式の画面の名前。
パス	文字列	「フィールド定義」を参照してください。これは画面を定義するファイルのパスです。
行	整数	画面定義が開始するソース・ファイル中の行番号(DFHMDIマクロが含まれている行)。
NField	整数	この画面で定義されるフィールド数。
ステータス	列挙	「フィールド定義」を参照してください。
異常レベル	列挙	「フィールド定義」を参照してください。実際、これはソース・ファイル全体の異常レベルであり、その異常がこの画面定義に実際に当てはまるかどうかは異常レポートを参照してください。

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

•

パス

•

行

•

NField

•

異常レベル

report-${SYSNAME}-SQL-Tables

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

 

表3-10 SQL表レポート・フィールド

フィールド	タイプ	説明
名前	記号	CREATE TABLE文で定義したSQL表の名前。
スキーマ	記号	表定義を含むスキーマの名前またはその所有者の名前。
パス	文字列	「フィールド定義」を参照してください。これは表を定義するSQLスクリプト・ファイルのパスです。
行	整数	このソース・ファイルで表の定義が開始する行番号。
NCol	整数	表に定義された列数。
ステータス	列挙	「フィールド定義」を参照してください。
コメント	文字列	表に関連するコメント(ある場合)。

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

•

パス

•

行

•

Ncol

•

コメント。

report-${SYSNAME}-SQL-Views

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

 

表3-11 SQLビュー・レポート・フィールド

フィールド	タイプ	説明
名前	記号	CREATE VIEW文で定義したSQLビューの名前。
スキーマ	記号	ビュー定義を含むスキーマの名前またはその所有者の名前。
パス	文字列	「フィールド定義」を参照してください。これはビューを定義するファイルのパスです。
行	整数	このソース・ファイルでビューの定義が開始する行番号。
NCol	整数	ビューに定義された列数。
ステータス	列挙	「フィールド定義」を参照してください。 注意: ビューへの参照は表への参照と区別できないため、ビューはMISSINGになりません。そのため、表またはビューへの参照がなんらかの定義とリンクしていない場合、カタロガは欠落ビューではなく欠落表を作成します。
コメント	文字列	表に関連するコメント(ある場合)。

report-${SYSNAME}-Transactions

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

 

表3-12 CICSトランザクション・レポート・フィールド

フィールド	タイプ	説明
名前	記号	DEFINE TRANSACTION文で定義したトランザクションの名前。
グループ	記号	トランザクション定義を含むグループ名。
パス	文字列	「フィールド定義」を参照してください。これはトランザクションを定義するファイルのパスです。
行	整数	このソース・ファイルでトランザクションの定義が開始する行番号。

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

report-${SYSNAME}-Anomalies

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

 

表3-13 異常レポート・フィールド

フィールド	タイプ	説明
パス	文字列	「フィールド定義」を参照してください。これは異常が発生したコンポーネントを定義するメイン・ファイルのパスです。
サブパス	文字列	「フィールド定義」を参照してください。エラーの実際の場所(文またはその他の構成)がサブファイル(COBOLコピー・ファイル、JCL PROCファイルなど)の中にある場合、これはそのサブファイルのパスで、そうでない場合はこのフィールドは空です。
行	整数	異常が発生した実際のソース・ファイル(前述のフィールドが空でなければサブファイル、そうでなければメイン・ファイル)の行番号。
サブ行	整数	異常がサブファイルで発生した場合、このフィールドにはサブファイルが含まれるメイン・ソース・ファイルの行番号が含まれ、そうでない場合は空です。
重大度	列挙: FATAL、ERROR、WARNING、NOTICE	異常の重大度、最大のFATALから最低のNOTICEまで。
カテゴリ	列挙: SYNTAX、LINKAGE、ANALYSIS、MISC	異常が属するカテゴリを定義します。 • SYNTAXは解析エラーおよび構文に関連するすべてのエラーです。 • LINKAGEは宣言されていない変数など、構成への参照と対応する定義の間のリンクに関連するエラーです。 • ANALYSISは動的呼出しなど、カタロガがコンポーネントの正確な分析を実行できない構成に関連する異常です。 • MISCはその他のすべてです。
タグ	記号	異常の正確な種類を識別する、統合的で重要な名前。実際に、使用可能な値は有限の列挙ですが、ここにすべてをリストするには多すぎます。
説明	文字列	異常の正確で詳細な説明で、原因となるソース構成への参照を含む場合もあります。たとえば、 "SQL-TABLE variable is not defined: LVDSYS00"などです。

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

カタロガの結果は、前述した一連のカタログ化レポートで表示できます。これらのレポートが唯一の出力ではなく、また最も重要な出力でもありません。この項では、その他の結果ファイルについて簡単に説明します。これらは独自形式のバイナリ・ファイルで、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およびその他のファイル

•	$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プログラムの解析(およびリンク)に必要です。

デフォルト・ファイル・コンバータ構成ファイル

カタログ化プロセス中、Tuxedo ART Workbenchは、JCLファイルとバッチCOBOLプログラムの両方を解析してメタデータ関連のデータセットを収集し、それをparam/dynamic-config/datasetディレクトリに格納し、ファイル・コンバータ構成ファイル(たとえば、param/fileディレクトリのDatamap-<schema>.reおよびmapper-<schema>.reファイル)を生成します。

その後、生成された構成ファイルを使用して、ファイル変換を行うことや、ファイル変換に必要な変更を加えることができます。

詳細処理

処理フェーズ

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

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

•	preparseおよびそのバリアントpreparse-files: 解析フェーズのみ実行します。

これは、少なくともSQLシステム・ファイルが生成された後で、同時実行が可能な唯一のフェーズです。また、これは、1つ以上の特定のコンポーネントの処理をリクエストできる唯一のフェーズです。それ以外の場合、カタロガは処理する必要のあるコンポーネントを自ら特定します(「アセットでの変更: 増分操作」を参照)。このフェーズでは、カタロガはコンポーネント・ソース・ファイル、含まれるサブファイルおよびSQLシステム・ファイルを読み取り、処理されるコンポーネントのPOBファイル(のみ)を生成します。

•	analyze: 分析フェーズを実行します。各コンポーネントのPOBファイルが再度読み取られ、コンポーネントで最も重要な構成が、カタロガ記号表(symtab)に格納されるより小さなサマリー情報に変換されます。

Symtabが同時アクセスをサポートしていないため、このフェーズは同時実行モードで実行できません。このフェーズでは、カタロガはコンポーネントのPOBファイルを読み取り(必要に応じて要求時に解析)、Symtabファイルを更新(読取りおよび書込み)します。

•	fast-final: 分析後およびレポート生成フェーズの両方を実行します。

•	分析後: symtabおよびサマリー情報を使用して、カタロガは、各コンポーネントに対する正常、未使用または欠落のラベル付けを可能にする相互参照リンクを計算します。

•	レポート生成: 相互参照リンクで修飾されたsymtabが巡回され、各コンポーネントに対して情報が出力されます。

これは特にシステム全体の操作を実行するため、このフェーズを同時に実行する必要はありません。このフェーズでは、カタロガはSymtabファイルを(更新しようとはせずに)読み取り、カタログ化レポートを書き込みます。

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

•	catalog: 分析フェーズ(したがって要求により解析フェーズ)、分析後フェーズおよびレポート生成フェーズを順序どおりに実行します。

注意:	これらすべてのコマンドでは、構成情報のすべてをシステム記述ファイルおよびカタロガ・オプション・ファイルから取得します。preparse-filesを除き、コマンド行引数のみがシステム記述ファイルへのパスおよび標準の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のコマンドと関係があります。

-h, -help, --help

コマンドの短い説明(使用方法)を出力して終了します。

–whoami

コマンドのバージョン番号とビルド履歴を出力して終了します。

-archi64 / -archi32

指定されたアーキテクチャ用にビルドされた実行可能ツールを使用します。デフォルトではホスト・マシンのネイティブ・アーキテクチャ用のツールを使用します。

-quiet

ログにエラー以外出力させません(現在、すべてのツールはこれに従っていません)。

-time

コマンド実行の最後に時間の情報を表示します。

-nolog

ログのリダイレクトを無効にして、ログが端末に表示され、永続ファイルに取得されないようにします。

-n, -N, -verbose, -VERBOSE

コンポーネントで実行する必要があるが、実際には実行されない作業(フェーズ)の説明を出力します。「アセットでの変更: 増分操作」を参照してください。

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

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

システム記述ファイルの場所を指定します。Unix/Linuxコマンドで一般的なように、パスには絶対パスまたは現在の作業ディレクトリに対する相対パスを指定できます。

注意:	多くのTuxedo ART Workbenchツールが使用するその他の多くのパスは、このファイルの場所から導出されます。これにより異なる作業ディレクトリから同じコマンドを実行しやすくなります。

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

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

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

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

$REFINEDIR/refine (-h | -help)

ランチャ自体の短い一般的な説明(使用方法)を出力します。

$REFINEDIR/refine -print-info-version

ランチャ自体、より一般的には、Tuxedo ART Workbench全体のバージョン情報を出力します。

システム全体のコマンド

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

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

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

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

preparse-filesコマンド

説明

上記で説明した、アセット全体でグローバルに動作し処理するコンポーネントをそれ自身が決定するシステム全体のカタログ化コマンドとは異なり、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 )…

オプション

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

source-file-path

このパスで指定したコンポーネント・ソース・ファイルを作業リストに追加します。このパスは、現在の作業ディレクトリが異なっていても、システムのルート・ディレクトリである$SYSROOTに対する相対パスで指定する必要があります。

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

このパスで指定したファイルにリストされたコンポーネント・ソース・ファイルを作業リストに追加します。file-of-files自体はどこに配置してもよく、そのパスは絶対パスまたは現在の作業ディレクトリに対する相対パスのいずれかです。ただし、このファイルにリストされたコンポーネント・ソース・ファイルは、システムのルート・ディレクトリに対する相対パスで指定する必要があります。

必要な数の個別のコンポーネントまたはfiles-of-filesを指定できます。作業リストは、コマンド行がカタロガによって分析されるときにビルドされ、その各要素は順番に検査されます。

•	指定したパスがシステム内の実際のコンポーネント・ソース・ファイルと一致しない場合、エラー・メッセージが出力され、カタロガは次の要素にスキップします。

•	指定したパスで特定されたコンポーネントがすでに解析され、そのPOBファイルがソース・ファイルに対し最新である場合、何も起こらず、カタロガはそのまま次の要素にスキップします。

•	そうでない場合、コンポーネントは正常(および詳細、-quietオプションがlauncher-optionsで指定されている場合は除く)に解析され、そのPOBファイルが生成されます。

コンポーネント検索操作

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

•	ソース・プラットフォームから見て

•

コンパイル時の参照

•

実行時の参照。

コンパイル時参照

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

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

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

 

表3-14 コンパイル時参照

ソース・タイプ(SRCTYP)	構文	ターゲット・タイプ(TGTTYP)	検索パス
COBOLプログラム(Cobol-Batch、Cobol-TPR)	COPY TGTFIL COPY TGTFIL REPLACING …	COBOLコピーブック(COBOL-Copy、COBOL-Library)	libraries
COBOLプログラム	EXEC SQL INCLUDE TGTFIL END-EXEC.	COBOLコピーブック	sql-librariesまたは指定されない場合はlibraries
JCLジョブ	EXEC TGTFIL, …	JCL PROC (JCL-Select)	libraries
JCLジョブ	INCLUDE TGTFIL…	JCL INCLUDE (JCL-Select)	libraries
JCLジョブ	SYSIN DD A.B.TGTFIL… SYSIN DD A.B.C(TGTFIL)…	JCL SYSIN (JCL-Sysin)	libraries

通常のサブファイル検索

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

1.	システム記述ファイルのSRCDIRの定義に関連するlibraries (または該当する場合はsql-libraries)句にリストされた各ディレクトリSUBDIRに対して、順番に、同じファイルでSUBDIRの定義を探してから次のことを行います。

•	該当する定義がない場合、報告(これは、カタロガが開始してシステム記述ファイルを読み取るときにのみ行われます)し、リストの次の要素にスキップします。

•	SUBDIRのタイプがその参照に適しているTGTTYPではない場合、リストの次の要素にスキップします。

•	そうではない(タイプが一致した)場合、(files句と一致した)そのディレクトリのコンポーネント・ファイルのリストを検索します。

•	ベース名TGTFIL(および適切な拡張子)のコンポーネントが存在する場合、それを戻します。

•	そうでなければ、リストの次の要素にスキップします。

2.	すべてのライブラリ・ディレクトリを検査して適切なTGTFILが見つからないと、not foundを戻します。

厳密なJCL-Sysin検索

このアルゴリズムは、strict-jcl-libraries特別オプションが指定されている場合に、JCL-Sysinファイルを検索するために変更されます。このオプションが設定されている場合、SYSINファイルA.B.TGTFILまたはA.B(TGTFIL)の検索が次のように続行されます。

•	論理名がA.BのタイプJCL-Sysinのディレクトリが存在する場合、このディレクトリでTGTFILが検索されます(files句および物理拡張子に応じたベース名検索)。同じ論理名を持つディレクトリが2つ以上存在する場合、エラーになることに注意してください。

•	これ以外の場合、「見つかりません」と戻されます。ベース名がTGTFILのファイルが、別のJCL-Sysinディレクトリに存在している場合でも同様です。

この動作は、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が使用されます。

注意:	strict-jcl-librariesとfull-name-sysin-searchの両方が設定されている場合、strict-jcl-librariesが優先されます。

実行時参照

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

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

無制限検索

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

1.	タイプTGTTYPの(順序付けされていない)コンポーネントのセットを、このタイプのディレクトリの検索と、それに含まれるコンポーネントの分析により収集します。

2.	その(ベース)名を記録します。

3.	名前がTGTFILのコンポーネントのセットを検索します。

•	これらのうちのいずれかが確かに存在する場合、それと参照とリンクします。

•	これらのうち複数が存在する場合、そのすべてと参照をリンクしますが、特定できない参照について報告します。

•	存在しない場合、コンポーネントの欠落について報告します。

指定検索

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

1.	システム記述ファイルのSRCDIRの定義に関連するlibraries句にリストされた各ディレクトリSUBDIRに対して、順番に、同じファイルでSUBDIRの定義を探してから次のことを行います。

•	該当する定義がない場合、報告(これは、カタロガが開始してシステム記述ファイルを読み取るときにのみ行われます)し、リストの次の要素にスキップします。

•	SUBDIRのタイプがその参照に適しているTGTTYPではない場合、リストの次の要素にスキップします。

•	そうではない(タイプが一致した)場合、(files句と一致した)そのディレクトリのコンポーネント・ファイルのリストを検索します。

•	ベース名TGTFIL(および適切な拡張子)のコンポーネントが存在する場合、それを戻します。

•	そうでなければ、リストの次の要素にスキップします。

2.	すべてのライブラリ・ディレクトリを検査して適切なTGTFILが見つからないと、not foundを戻します。

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

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

注意:	指定検索は、カタロガの現在のバージョンではまだ使用できません。libraries句を使用して、実行時参照に含まれるコンポーネントを指定する場合、これらの要素は無視されます。指定検索は、将来のバージョンで、選択したSRCTYP/TGTTYPの組合せに対して徐々に追加されます。リリース・ノートを確認してください。

繰返しおよび増分操作

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

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

最初の処理: 繰返し操作

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

1.	カタロガのようなツールが開始する場合、最初にアセット(POBファイルまたはSymtabのようなソース・ファイルおよびターゲット・ファイル)の現在の状態を調べ、完全で一貫性のある結果のセットを得るためにはどの作業の実行が残っているかを特定します。

2.	次にこの作業を実行し、さらに多くの結果ファイルを生成(または新しい結果でSymtabを更新)します。

処理するファイルの量が多くなるに従い、Refineプロセスはより多くのメモリーを消費します。

3.	ツールは、使用可能な物理メモリーがシステム記述ファイルのminimum-free-ram-percentオプションで指定したしきい値を下回っているかどうかを定期的にチェックします。

•	メモリー不足になる前に実行すべき作業が完了すると、プロセスは終了します。

•	そうでない場合、プロセスは停止しますが、メモリーの解放後、すぐに再起動します。前述の手順1に戻りますが、実行する作業が少なくなっているため、プロセスは最終的に終了します。

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

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

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

注意:	重要: 増分操作はアセットの最初の処理が完了した後でのみ有効です。最初のサイクルが終わる前にアセットで変更を実行すると、記録されていない依存関係がある可能性があり、その場合、再実行する作業の評価は正しくなくなり、最終結果に一貫性がなくなります。そのため、最初のアセットでカタロガの実行を完了させてから、そのアセットでの変更を行うことが非常に重要です。