この章は、ソース・プラットフォーム(z/OS)からUNIX/Linux Micro FocusまたはCOBOL-ITファイルまたはRDBMS表へのファイルの移行に使用するRehosting Workbenchのファイル・コンバータの概要を紹介します。これらのファイル・コンバータの各動作についての共通の説明や使用方法を含みます。
構成ファイル内のオプションの句によっては、ファイルとRDBMS表間の変換ターゲットを組み合せることができます。
この章では、生成される移行ツールについて説明します。変換は、Oracle Tuxedo Application Rehosting Workbenchの他のツールによって変換または生成された他のコンポーネントと関連して行われます。
変換プロセスを開始する前に、いくつかの構成ファイルを設定する必要があります。「入力コンポーネントのリスト」を参照してください。
生成される様々なオブジェクトについては、ターゲット別の項で説明します。一部のオブジェクトは、VSAMファイルをOracleに移行するときにのみ生成されます。Oracle用のPCOプログラム、Db2/luw用のSQBプログラム、SQLファイル、リレーショナル・モジュール、論理モジュール、ユーティリティ、構成ファイル、アンロード用JCLおよびCOBOLプログラムの変換などがあります。
この項およびターゲット別のファイル・コンバータの項の目的は、次のようなRehosting Workbenchファイル・コンバータ・ツールのすべての機能を正確に説明することです。
データの変換は、COBOLプログラムの変換と密接に関連しています。次の項目を参照してください。
生成された各出力コンポーネントの詳細は、次を参照してください。
注意: | OracleとDB2/Luwターゲット・データベースの両方を同時に生成することはできません。 |
Oracle Tuxedo Application Rehosting Workbenchのファイル・コンバータは、ターゲット・プラットフォームの様々なファイル編成をサポートします。
表5-1は、z/OSが扱うファイル編成を示しています。
z/OSソース・プラットフォームからターゲット・プラットフォームにファイルを移行するとき、VSAMが関係する場合は、ファイルを維持するかデータをRDBMS表に移行するかをまず確認します。たとえば、後でOracleまたはDb2/luwデータベースで使用される永続ファイルやレコード・レベルでのロックが必要なファイルです。
構成名は、変換される一連のファイルに関連します。それぞれのファイルのセットは自由に組み合せることができます。たとえば、各構成はアプリケーションに関連させることも、テストに必要な一連のファイルに関連させることもできます。
移行を予定している各ファイルについて、構造をCOBOLCOBOL形式で記述する必要があります。この記述はRehosting Workbench COBOLコンバータによってCOBOLコピーで使用され、「COBOL記述」に記載されている制限の対象になります。
移行ファイル・リストが一度作成されたら、同一構造のファイルをパージすることができます。これは、データのトランスコードと再ロードに必要なプログラム数を減らして、ファイルを移行する際の作業を減らすためです。
パージしたファイル・リストを使用し、最後のタスクとして次のファイルを作成します。
COBOL記述は各ファイルと関連し、アプリケーション・プログラムで使用されるCOBOL記述を表すものとみなされます。この記述はOCCURSおよびREDEFINESの概念を含む、すべてのCOBOLデータ型を使用する複雑なCOBOL構造にすることができます。
多くの場合、このCOBOL記述はCOBOLファイル記述(FD)よりも発展させることができます。たとえば、FDフィールドはPIC X(364)と記述できますが、実際には定義された3倍の領域に相当し、COMP-3ベースの数値表や、いくつかの文字フィールドや数値フィールドなどの複雑な記述を含むことができます。
実際のアプリケーションを説明するのはこのような詳細なCOBOL記述です。このため、特定の物理ファイルを移行するための基盤として使用されます。
ファイル処理の実行の品質はこのCOBOL記述の品質に左右されます。この点から、COBOL記述はファイルとは分離されず、関連するファイルを参照する時は、ファイルとそれを表現するCOBOL記述の両方を意味します。記述はCOBOL形式で、次の名前のファイルで提供される必要があります。
<COPY name>.cpy
注意: | ソース・プラットフォームのコピー・ブックにファイルの詳細が記述されている場合は、そのファイルをRehosting Workbenchで直接使用および宣言できます。 |
1つのCOBOL記述内に、同じ領域を記述する方法がいくつかあります。つまり、異なる構造や記述のオブジェクトを同じ場所に格納できます。
同じゾーンが様々な記述のオブジェクトを含むことができるため、そのファイルを読み取るには、このデータ領域を正しく解釈するためにどの記述を使用すべきかを判別するメカニズムが必要です。
ある条件に従い、一般的にレコードの1つまたは複数のフィールドの内容により、再定義領域の読取りに使用する記述を決定(識別)できるルールが必要です。
Rehosting Workbenchではこのルールは識別ルールと呼ばれます。
識別ルールなしでのCOBOL記述内の再定義では、ファイルのトランスコード時に重大なリスクが存在します。そのため、等価でない再定義済フィールドは識別ルールをリクエストします。また、等価の再定義(技術的再定義)は、COBOL記述内で消去の対象にする必要があります(後で示す「COBOL記述形式」の例を参照)。
識別ルールはファイルごとに用意し、相違点と識別される領域を明確に指定する必要があります。ファイルに関しては、ファイル記述の外部のフィールドを参照することはできません。
識別ルールはマッパー・ファイルに指定します。構文は、このドキュメントの「マッパー・ファイル」を参照してください。
ファイル・コンバータでは、ソースおよびターゲット・プラットフォームで使用される移行コンポーネントを生成するために、入力コンポーネントが必要です。必要な入力コンポーネントは次のとおりです。
2つの構成ファイル(mapper
およびdatamap
)については、この項で説明します。その他については、各ターゲットの出力で詳しく説明します。
これは、システムの物理ファイルに関する情報を追加または変更するためにRehosting Workbenchファイル・コンバータによって使用される構成ファイルです。
移行する各ZOSファイルをこのファイルに指定する必要があります。このファイルには、移行するファイルのリストのみが含まれます。
データマップ・ファイルは、次の完全な名前を付けてディレクトリ$PARAM/file
に作成する必要があります。
Datamap-<configuration name>.re
<configuration name>
は、使用される現在の構成の名前です。
data map <configuration name>-map system cat::<project name>
file <physical file name>
organization <organization>
[is-gdg limit <p> [scratch/noscratch] [empty/noempty]
[keys offset <n> bytes length <m> bytes primary]
[relkey size <m> bytes]
システム記述ファイルに指定されるプロジェクト名。
|
|
|
|
data map STFILEORA-map system cat::STFILEORA
%% Datamap File PJ01AAA.SS.QSAM.CUSTOMER
file PJ01AAA.SS.QSAM.CUSTOMER
organization Sequential
%% Datamap File PJ01AAA.SS.VSAM.CUSTOMER
file PJ01AAA.SS.VSAM.CUSTOMER
organization Indexed
keys offset 1 bytes length 6 bytes primary
file PJ01AAA.SS.VSAM.CODPAY
organization Relative
relkey size 6 bytes
これは、移行する各ファイルを次の項目と関連付けるためにRehosting Workbenchファイル・コンバータによって使用される構成ファイルです。
データマップ・ファイルにリストされている各z/OSファイルは、マッパー・ファイルに指定する必要があります。
ファイルのマッピングでは、処理する物理ファイルごとに、関連するCOBOL記述と識別ルールを選択します。
file <Physical file name>
[converted] [transferred]
table name <Table Name>
include <"path/Copy name">
map record <record name> defined in <"path/Copy name">
source record <record name> defined in <"path/Copy name">
logical name <logical file name>
converter name <converter name>
[attributes <attribute clause>]
[mapping strategies clauses]
注意: | アクセス機能については、「File-to-Oracleコンバータ」の「アクセス機能およびユーティリティ・プログラム」または「File-to-Db2/luw (udb)コンバータ」の「アクセス機能およびユーティリティ・プログラム」を参照してください。 |
ufas mapper STFILEORA
file PJ01AAA.SS.VSAM.CUSTOMER converted transferred
table name CUSTOMER
include "COPY/ODCSF0B.cpy"
map record VS-ODCSF0-RECORD defined in "COPY/ODCSF0B.cpy"
source record VS-ODCSF0-RECORD defined in "COPY/ODCSF0B.cpy"
logical name ODCSF0B
converter name ODCSF0B
attributes LOGICAL_MODULE_IN_ADDITION
この例では、マッパー・ファイルの名前はSTFILEORA
です。このファイルで処理するのは、変換オプションを使用してRDBMS表に移行されるPJ01AAA.SS.VSAM.CUSTOMER
という名前の1ファイルのみです。このファイルを記述するために使用されるODCSF0B.cpy
コピー・ファイルは、ソース・コピー・ファイルの1つです。
OracleまたはDb2/luw (udb)の選択はdb-param.cfg
構成ファイルで行います。
Oracle Tuxedo Application Rehosting Workbenchファイル・コンバータは、各表に関連付けられている記述が必要です。このため、最初の手順でCOBOLコピーの記述を生成します。
COBOL記述ファイルが用意されると、mapper-<configuration name>.re
ファイルに指定されているコピー・ファイルを$PARAM/file/recs-source
ディレクトリに配置する必要があります。
ソース・プラットフォームのCOBOLコピー・ブックを使用してファイルを記述する場合(「COBOL記述」を参照)、コピー・ブックの場所が直接使用されます。
これらのファイルはカタログ化の際に使用されます。詳細は、「ASTのPOBファイル」を参照してください。
symtab-<schema name>.pob
このファイルはカタログ化の際に作成されます。ファイル・コンバータがDB2オブジェクトをOracleに移行するためには、このファイルが最新状態で存在している必要があります。「カタロガSymtabおよびその他のファイル」を参照してください。