|
|
この章では、ソースz/OS環境をターゲット環境に移行するための、Rehosting Workbench File-to-Fileコンバータのインストール、実装および構成方法について説明します。
ファイルを移行する場合、COBOL、JCL、z/OSユーティリティおよびUNIX/Linux Kornシェルの知識が必要です。
移行プロセスの包括的な視点については、Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドのデータ変換およびCOBOL変換の章と、このガイドのOracle Tuxedo Application Rehosting Workbench COBOLコンバータの章を参照してください。
z/OSソース・プラットフォームからターゲット・プラットフォームへ移行する時の最初の問題は、VSAMに関する場合、ファイルを保持するかまたはデータをOracle表に移行するかということです。
Oracle Tuxedo Application Rehosting Workbench File-to-Fileコンバータは、ソース・プラットフォームの形式(順次、相対または索引付きファイル)をターゲット・プラットフォーム上で保持するファイル向けに使用されます。ターゲット・プラットフォームでは、これらのファイルはソース・プラットフォームでの編成に相当するターゲットのCOBOL (Micro Focus/COBOL-IT)のファイル編成を使用します。
表3-1は、z/OSにより処理されるファイル編成をリストし、ターゲット・プラットフォームで提案される編成を示します。
| 注意: | z/OSファイルのISAM UNIXファイルへの変換には、COBOLアプリケーション・プログラムまたはJCLの変換への直接リンクがありません。 |
PDSの一部であるファイルは、METAW00.NIV1.ESSAI(FIC)などの物理ファイル名自体で識別されます。
このケースでは、PDSに合せて調整されたアンロード用JCLが生成されます。前述の表に示したソースとターゲットのファイル編成が適用されます。
世代別データ・グループ(GDG)ファイルは、その特殊性(アンロードおよび再ロードするGDGアーカイブの数)を維持するように、アンロード・コンポーネントおよび再ロード・コンポーネントによって特別に処理されます。その後、世代ファイルとしてOracle Tuxedo Application Runtime Batchで管理されます(Oracle Tuxedo Application Runtime Batchのリファレンス・ガイドを参照)。ターゲット・プラットフォームでは、これらのファイルはLINE SEQUENTIAL編成になります。
この章で詳細が説明されている、ファイルからファイルへの移行プロセスの原則的な手順は次のとおりです。
この項ではファイルの移行の開始前に実行する手順について説明します。
z/OSファイルのUNIX/Linuxへの移行は、Oracle Tuxedo Application Rehosting Workbenchカタロガの結果に依存します。これはCOBOLコンポーネントまたはJCLコンポーネントの変換に影響を与えません。
最初のタスクは、移行するファイルをすべてリストすることで、これにはOracle表から取得されない処理ユニットへの永続ファイル入力などが含まれます。
移行の候補となる各ファイルについて、その構造をCOBOL形式で記述する必要があります。この記述は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で直接使用および宣言できます。 |
COBOL記述では、同じメモリー・フィールドを記述する方法がいくつかあり、これは異なる構造と記述でオブジェクトを同じ場所に格納することを意味します。
同じメモリー・フィールドに異なる記述のオブジェクトを含めて、ファイルを読み取ることができるので、このデータ領域を適切に解釈するために、使用する記述を決定するメカニズムが必要です。
ある条件に従い、一般的にレコードの1つまたは複数のフィールドの内容により、再定義領域の読取りに使用する記述を決定(識別)できるルールが必要です。
Rehosting Workbenchではこのルールは識別ルールと呼ばれます。
識別ルールなしでのCOBOL記述内の再定義では、ファイルのトランスコード時に重大なリスクが存在します。そのため、等価でない再定義済フィールドは識別ルールをリクエストします。他方、等価な再定義(テクニカル再定義と呼ばれる)はCOBOL記述内でクレンジングの対象となる必要があります(次の例を参照)。
識別ルールはファイルごとに用意し、相違点と識別される領域を明確に指定する必要があります。ファイルに関しては、ファイル記述の外部のフィールドを参照することはできません。
次の記述は、Rehosting Workbenchで必要なCOPYのサンプルです。
01 FV14.
05 FV14-X1 PIC X.
05 FV14-X2 PIC XXX.
05 FV14-X3.
10 FV14-MTMGFA PIC 9(2).
10 FV14-NMASMG PIC X(2).
10 FV14-FILLER PIC X(12).
10 FV14-COINFA PIC 9(6)V99.
05 FV14-X4 REDEFINES FV14-X3.
10 FV14-MTMGFA PIC 9(6)V99.
10 FV14-FILLER PIC X(4).
10 FV14-IRETCA PIC X(01).
10 FV14-FILLER PIC X(2).
10 FV14-ZNCERT.
15 FV14-ZNALEA COMP-2.
15 FV14-NOSCP1 COMP-2.
15 FV14-NOSEC2 COMP-2.
15 FV14-NOCERT PIC 9(4) COMP-3.
15 FV14-FILLER PIC X(16).
05 FV14-X5 REDEFINES FV14-X3.
10 FV14-FIL1 PIC X(16).
10 FV14-MNT1 PIC S9(6)V99.
05 FV14-X6 REDEFINES FV14-X3.
10 FV14-FIL3 PIC X(16).
10 FV14-MNT3 PIC S9(6).
10 FV14-FIL4 PIC X(2).
Field FV14-X3
Rule if FV14-X1 = “A” then FV14-X3
elseif FV14-X1 = “B” then FV14-X4
elseif FV14-X1 = “C” then FV14-X5
else FV14-X6
| 注意: | COBOL記述では、フィールドFV14-X3が再定義される最初のフィールドである必要があります。それに続くフィールド、FV14-X4、FV14-X5およびFV14-X6の順序は重要ではありません。 |
01 FV15.
05 FV15-MTMGFA PIC 9(2).
05 FV15-ZNPCP3.
10 FV15-NMASMG PIC X(2).
10 FV15-FILLER PIC X(12).
10 FV15-COINFA PIC 9(6)V99.
05 FV15-ZNB2T REDEFINES FV1 5-ZNPCP3.
10 FV15-MTMGFA PIC 9(4)V99.
10 FV15-FILLER PIC X(4).
10 FV15-IRETCA PIC X(01).
10 FV15-FILLER PIC X(2).
10 FV15-ZNCERT
15 FV15-ZNALEA COMP-2.
15 FV15-NOSCP1 COMP-2.
15 FV15-NOSEC2 COMP-2.
15 FV15-NOCERT PIC 9(4) COMP-3.
15 FV15-FILLER PIC X(16).
上記の例では、2つのフィールド(FV15-ZNPCP3およびFV15-ZNB2T)の構造が異なります。最初のフィールドはEBCDIC英数字、次のフィールドはEBCDICデータおよびCOMP2、COMP3データから構成されます。
識別ルールの実装は、データをUNIXプラットフォームに移行するのに必要です。
Field FV15-ZNPCP3
Rule if FV15-MTMGFA = 12 then FV15-ZNPCP3
elseif FV15-MTMGFA = 08 and FV15-NMASMG = "KC " then FV15-ZNB2T
01 FV1.
05 FV1-ZNPCP3.
10 FV1-MTMGFA PIC 9(6)V99.
10 FV1-NMASMG PIC X(25).
10 FV1-FILLER PIC X(12).
10 FV1-COINFA PIC 9(10).
10 FV2-COINFA REDEFINES FV1-COINFA.
15 FV2-ZNALEA PIC 9(2).
15 FV2-NOSCP1 PIC 9(4).
15 FV2- FILLER PIC 9(4).
10 FV15-MTMGFA PIC 9(6)V99.
10 FV15-FILLER PIC X(4).
10 FV15-IRETCA PIC X(01).
10 FV15-FILLER PIC X(2).
01 FV1. 01 FV1.
05 FV1-ZNPCP3. 05 FV1-ZNPCP3.
10 FV1-MTMGFA PIC 9(6)V99. 10 FV1-MTMGFA PIC 9(6)V99.
10 FV1-NMASMG PIC X(25). 10 FV1-NMASMG PIC X(25).
10 FV1-FILLER PIC X(12). 10 FV1-FILLER PIC X(12).
10 FV1-COINFA PIC 9(10). 10 FV2-COINFA.
10 FV15-MTMGFA PIC 9(6)V99. 15 FV2-ZNALEA PIC 9(2).
10 FV15-FILLER PIC X(4). 15 FV2-NOSCP1 PIC 9(4).
10 FV15-IRETCA PIC X(01). 15 FV2- FILLER PIC X(4).
10 FV15-FILLER PIC X(2). 10 FV15-MTMGFA PIC 9(6)V99.
10 FV15-FILLER PIC X(4).
10 FV15-IRETCA PIC X(01).
10 FV15-FILLER PIC X(2).
上記の例では、2つの記述が単純なEBCDIC英数文字列(バイナリ、パックまたは符号付数字フィールドを除く)に相当します。この種の構造は識別ルールの実装を必要としません。
この項では、データ・ファイルを移行するのに使用されるコンポーネントの生成前に実行するタスクについて説明します。
Rehosting Workbenchの実行前に次の環境変数を設定します。
次を使用して記述された3つのファイルはRehosting Workbenchファイル構造に置く必要があります。
ファイルからファイルへの変換ではこれらのファイルを自分で作成する必要があります。
| 注意: | データマップおよびマッパー構成ファイルは同じ構成名を使用する必要があります。 |
これらのファイルはRehosting Workbenchのインストール時にファイル構造に自動的に置かれます。これらのファイルの特定のバージョンが特定のz/OSファイルに必要な場合は、$PARAM/fileファイル構造に置かれます。
次の例は3つのファイル、つまり2つのQSAMファイルと1つのVSAM KSDSファイルの構成を示します。これらのファイルを実装するための識別ルールはありません。
db-param.cfg ファイルで、変更する必要のある可能性のあるパラメータはtarget_osパラメータのみです。
# This configuration file is used by FILE & RDBMS converter
# Lines beginning with "#" are ignored
# write information in lower case
# common parameters for FILE and RDBMS
# source information is written into system descriptor file (OS, DBMS=,
# DBMS-VERSION=)
target_rdbms_name:oracle
target_rdbms_version:11
target_os:unix# optional parametertarget_cobol:cobol_mf#
# specific parameters for FILE to RDBMS conversion
file:char_limit_until_varchar:29
# specific parameters for RDBMS conversion
rdbms:date_format:YYYY/MM/DD
rdbms:timestamp_format:YYYY/MM/DD HH24 MI SS
rdbms:time_format:HH24 MI SS
# rename object files
# the file param/rdbms/rename-objects-<schema>.txt is automatically loaded # by the tool if it exists.
COBOL言語の名前許容値は"cobol_mf"(デフォルト値)および"cobol_it"です。
システム記述ファイルでのカタログ化中に決定されます。
|
||
| 注意: | 使用される様々なパラメータの説明は、Oracle Tuxedo Application Rehosting Workbenchのリファレンスガイドのファイルからファイルへのコンバータを参照してください。 |
次の例では、最初の2つのファイルはQSAMファイルなので編成は常に順次です。PJ01AAA.SS.VSAM.CUSTOMERファイルはVSAM KSDSファイルなので編成は索引付きです。パラメータkeys offset 1 bytes length 6 bytes primaryはキーを記述しています。この例では、キーは6バイトの長さでポジション1から開始します。
%% Lines beginning with "%%" are ignored
data map FTFIL001-map system cat::PROJ001
%%
%% Datamap File PJ01DDD.DO.QSAM.KBCOI001
%%
file PJ01DDD.DO.QSAM.KBCOI001
organization Sequential
%%
%% Datamap File PJ01DDD.DO.QSAM.KBCOI002
%%
file PJ01DDD.DO.QSAM.KBCOI002
organization Sequential
%%
%% Datamap File PJ01AAA.SS.VSAM.CUSTOMER
%%
file PJ01AAA.SS.VSAM.CUSTOMER
organization Indexed
keys offset 1 bytes length 6 bytes primary
データマップ構成ファイルに含まれている、移行する各z/OSファイルをリストする必要があります。
| 注意: | 使用される様々なパラメータの説明は、Oracle Tuxedo Application Rehosting Workbenchのリファレンスガイドのファイルからファイルへのコンバータを参照してください。 |
%% Lines beginning with "%%" are ignored
ufas mapper FTFIL001
%%
%% Desc file PJ01DDD.DO.QSAM.KBCOI001
%%
file PJ01DDD.DO.QSAM.KBCOI001 transferred
include "#VAR:RECS-SOURCE#/BCOAC01E.cpy"
map record REC-ENTREE defined in "#VAR:RECS-SOURCE#/BCOAC01E.cpy"
source record REC-ENTREE defined in "#VAR:RECS-SOURCE#/BCOAC01E.cpy"
logical name FQSAM01
converter name FQSAM01
%%
%% Desc file PJ01DDD.DO.QSAM.KBCOI002
%%
file PJ01DDD.DO.QSAM.KBCOI002 transferred
include "#VAR:RECS-SOURCE#/BCOAC04E.cpy"
map record REC-ENTREE-2 defined in "#VAR:RECS-SOURCE#/BCOAC04E.cpy"
source record REC-ENTREE-2 defined in "#VAR:RECS-SOURCE#/BCOAC04E.cpy"
logical name FQSAM02
converter name FQSAM02
%%
%% Desc file PJ01AAA.SS.VSAM.CUSTOMER
%%
file PJ01AAA.SS.VSAM.CUSTOMER transferred
include "COPY/ODCSF0B.cpy"
map record VS-ODCSF0-RECORD defined in "COPY/ODCSF0B.cpy"
source record VS-ODCSF0-RECORD in "COPY/ODCSF0B.cpy"
logical name ODCSF0B
converter name ODCSF0B
コピー・ファイルを保持する$PARAM/file/recs-sourceディレクトリを作成します。
COBOL記述ファイルを準備したら、mapper-<構成名>.reファイルに記述したコピー・ファイルを$PARAM/file/recs-sourceディレクトリに置く必要があります。
ソース・プラットフォームからのCOBOLコピー・ブックを使用してファイルを記述する場合(「COBOL記述」の注意を参照)、それが、上述のCOPY/ODCSF0B.cpyの例のように、マッピング・パラメータ・ファイルで直接使用されるコピー・ブックの場所です。
z/OSファイルの移行に使用するコンポーネントを生成するのに、Rehosting Workbenchはfile.shコマンドを使用します。この項ではこのコマンドについて説明します。
file.sh - z/OS移行コンポーネントを生成します。
file.sh [ [-g] [-m] [-i <installation directory>] <configuration name> | -s <installation directory> (<configuration name>,...) ]
file.shはRehosting Workbenchを使用してz/OSファイルの移行に使用するコンポーネントを生成します。
attributes句がLOGICAL_MODULE_ONLYに設定されている場合を除き、ファイルからファイルへの移行は適用されません。 この場合、このオプションにより、Cobolコンバータで使用する構成ファイルおよびDMLユーティリティの生成が可能になります。すべての構成ファイルは$PARAM/dynamic-configに、DMLファイルは<trf>/DMLディレクトリに作成されます。
file.sh -gmi $HOME/trf FTFIL001
-i $HOME/trfオプションを使用して生成されたアンロードおよびロード・コンポーネントは次の場所に置かれます。
生成されたコンポーネントはプロジェクトの固有のスクリプトを使用して変更することができます。これらのスクリプト(sed、awk、perlなど)は次の場所に置く必要があります。
$PARAM/file/file-modif-source.sh
このファイルが存在している場合、生成プロセスの最後に自動的に実行されます。引数として<configuration name>を使用して呼び出されます。
Makeはターゲット(ファイルまたはアクション)の構成を自動化および最適化することを目的としたUNIXユーティリティです。
すべての操作が実装されるソース・ディレクトリにmakefileという名前の記述子ファイルが存在する必要があります(makefileはプロジェクトの初期化中にソース・ディレクトリに準備されます)。
次の2つの項では、Makeファイルの構成と、Makeファイルを使用したRehosting Workbench File-To-Fileコンバータ機能の使用方法について説明します。
$PARAMのversion.mk構成ファイルを使用して、Makeユーティリティで必要な変数およびパラメータを設定します。
version.mkには、各種のコンポーネントがインストールされる場所とその拡張を、使用される様々なツールのバージョンとともに指定します。このファイルにはログ・ファイルの構成方法も記述されます。
次の一般的な変数を、version.mkファイルでの移行プロセスの最初に設定する必要があります。
また、FILE_SCHEMAS変数はファイルの移行に特有で、処理する様々な構成を示します。
この構成はMakeファイルの使用の前に完了する必要があります。
makefileおよびversion.mkファイルはRehosting Workbench Simple Applicationとともに提供されます。
make FileConvertコマンドを使用して、Rehosting Workbench File-To-Fileコンバータを起動できます。これによりz/OSファイルのUNIX/Linuxターゲット・プラットフォームへの移行に必要なコンポーネントを生成できます。
MakeファイルはFILE_SCHEMAS変数に含まれるすべての構成に対し、-g、-mおよび-iオプションを指定してfile.shツールを起動できます。
この項では、Rehosting Workbenchを使用して生成されたコンポーネント(コンポーネントの生成を参照)を使用する、アンロード、転送および再ロードのタスクについて説明します。
アンロードに使用されるコンポーネント($HOME/trf/unload/fileに生成)は、ソースz/OSプラットフォームにインストールする必要があります。生成されたJCLは、JOBカード、ライブラリ・アクセス・パス、入力および出力ファイル(データ・セット名: DSN)へのアクセス・パスを含む、特定のサイトの制約への適合が必要な場合があります。
再ロードに使用されるコンポーネント($HOME/trf/reload/fileに生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。
次の環境変数をターゲット・プラットフォームに設定する必要があります。
アンロード用JCLがデータマップ・パラメータ・ファイル(Datamap-<configuration name>.re)にリストされた各 z/OSファイルに対して生成されます。これらのアンロード用JCLの名前は<論理ファイル名>.jclunloadです。
| 注意: | .jclunload拡張子は、z/OSで実行する場合には削除する必要があります。 |
ファイルは、サイトで使用可能なファイル転送ツール(CFT、FTPなど)を使用して、バイナリ形式で、ソースz/OSプラットフォームとターゲット・プラットフォーム間で転送される必要があります。
トランスコードおよび再ロードに使用される生成されたCOBOLプログラムの名前は次のとおりです。
マッピング・パラメータ・ファイル(mapper-<configuration name>.re)での例で、生成されるプログラムは次のとおりです。
シーケンシャル・ファイルの移行時には、ターゲットのCOBOL LINE SEQUENTIAL出力ファイルが生成されます。
…
SELECT SORTIE
ASSIGN TO "SORTIE"
ORGANIZATION IS LINE SEQUENTIAL
FILE STATUS IS IO-STATUS.
…
VSAM KSDSファイルの移行時には、INDEXED出力ファイルが生成されます。
…
SELECT MW-SORTIE
ASSIGN TO "SORTIE"
ORGANIZATION IS INDEXED
ACCESS IS DYNAMIC
RECORD KEY IS VS-CUSTIDENT
FILE STATUS IS IO-STATUS.
…
これらのCOBOLプログラムは、Rehosting Workbenchリファレンス・ガイドのCOBOLコンバータに関する項に記載されたオプションを使用して、ターゲットのCOBOLコンパイラでコンパイルされる必要があります。
トランスコードおよび再ロード・スクリプトは次のパラメータを使用します。
loadfile-<logical file name>.ksh [-t/-l] [-c <method>]
loadgdg-<logical file name>.ksh [-t/-l] [-c <method>]
マッピング・パラメータ・ファイル(mapper-<configuration name>.re)での例で、生成されるスクリプトは次のとおりです。
デフォルトでは、入力ファイルは$DATA_SOURCEで示されたディレクトリに置かれ、出力ファイルは$DATAで示されたディレクトリに置かれます。
これらのファイルはマッピング・パラメータ・ファイル(mapper-<configuration name>.re)で使用される論理ファイル名を使用して名前付けされます。
実行ログは$MT_LOGで示されたディレクトリに作成されます。
問題が発生すると、ゼロ以外のリターン・コードが生成されます。
この確認は次のloadfile-<論理ファイル名>.kshのオプションを使用します。
-c ftp:<name of transferred physical file>:<name of FTP log under UNIX>
| 注意: | このオプションは、再ロード後、z/OSから転送された物理ファイルとターゲット・プラットフォームに再ロードされたファイルに、同じレコード数が含まれていることを検証します。このチェックは、FTPログと再ロード・プログラムの実行レポートを使用して実行されます。レコード数が異なる場合は、エラー・メッセージが生成されます。 |
この項では、ファイルをソースからターゲット・プラットフォームへ移行するときに発生した使用エラーにより生じる問題について説明します。
Rehosting Workbenchツールを実行するときに、ユーザーは次のことを確認する必要があります。
Mapper-log-<構成名>ファイルにエラーが含まれているか(共通の問題と解決策を参照)。エラー・メッセージと関連する説明はOracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドの付録にリストされています。
Refine error...
Mapper-log-STFILEORAログ・ファイルの内容には次が含まれます。
file PJ01AAA.SS.QSAM.CUSTOMER.REPORT loaded/unloaded
file logical name MW-SYSOUT
*** Unknown file organization : *UNDEFINED*
mapping record MW-SYSOUT
record MW-SYSOUT: logical name MW-SYSOUT
record MW-SYSOUT: logical name MW-SYSOUT
移行するファイルがmapper-<configuration name>.reファイルに存在し、Datamap.<configuration name>.reファイルには存在しません。
Refine error...
Mapper-log-STFILEORA1ログ・ファイルの内容には次が含まれます。
file PJ01AAA.SS.QSAM.CUSTOMER.REPORT loaded/unloaded
file logical name MW-SYSOUT
file is sequential: no primary key
*** record `MW-SYSOUT in COPY/MW_SYSOU2T.cpy' not found ***
*** ERROR: all records omitted ***
mapping records
Refine error...
Mapper-log-STFILEORA2ログ・ファイルの内容には次が含まれます。
file PJ01AAA.SS.QSAM.CUSTOMER.REPORT loaded/unloaded
file logical name MW-SYSOUT
file is sequential: no primary key
*** record `MW-SYSOUTTT in COPY/MW_SYSOUT.cpy' not found ***
record MW-SYSOUT reselected (all records omitted)
mapping record MW-SYSOUT
record MW-SYSOUT: logical name MW-SYSOUT
Refine error...
Mapper-log-STFILEORA3ログ・ファイルの内容には次が含まれます。
*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-
############################################################################
Control of schema STFILEORA3
External Variable PARAM is not set!
ERROR : Check directive files for schema STFILEORA3
  
|