『Oracle Tuxedo Application Rehosting Workbenchユーザーズ・ガイド』

『Oracle Tuxedo Application Rehosting Workbenchユーザーズ・ガイド』

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

•

はじめに

•

前提条件

•

コンポーネントおよびレイアウト

•

詳細なリホスティングの方法

•

データ移行の実行

はじめに

リホスティングとは

リホスティングとは、プロプライエタリ・ハードウェアおよびソフトウェアに閉じ込められた状態のビジネス・ロジックやビジネス・データへの高額投資を守りつつ、拡張性が高いオープン・アーキテクチャに移行して、将来の最新化への道を開く方法です。

製品概要

Refine for Z/OS Replatformingパッケージで提供される自動移行ツールを使用すると、COBOL、JCL、DB2、VSAMファイルおよびIBM DB2メインフレーム環境の関連アセットのプラットフォームを変更して、Oracle Tuxedoトランザクション・プロセッサとOracleデータベースを含むUNIX環境に移行できます。

プラグインの目的は、次の機能を提供することで複雑な処理に対応することです。

•

移行プロセスはART Workbenchプロジェクトによって編成されます。これにより、Tuxedo ART Workbenchナビゲータのプロジェクト・アーティファクトをナビゲートでき、選択したプロジェクトの対応するアーティファクトを実行できます。

•

プロジェクト全体および特定のツールの構成設定を定義するために必要なパラメータとオプションを選択および指定できます。フラット構成ファイルのオプションの多くは、プロジェクト・プロパティで構成および変更できます。

•

コマンド行で指定するパラメータ/オプションの構成およびその他のリソースを使用して、プロセスの特定の手順で必要な特定のツール/コマンドを実行します。Tuxedo ART Workbenchコンソールで出力メッセージをリアルタイムで確認します。

•

カタログの生成レポートを確認します。

•

変換の進行に伴い、変換中のソース・ファイルが進捗モニターに表示されます。

•

手順を追って移行プロセスを示します。

Oracle Tuxedo Application Rehosting Workbench

Refine for Z/OS ReplatformingおよびOracle Tuxedo Application Runtime for CICS and Batchは、リホスティング・プロジェクトのコンテキスト内で使用されます。このプロセス・ガイドでは、リホスティングの概要およびこのプロセスでの変換ツールやランタイム・ツールの使用方法を説明します。リホスティング・プロジェクトでは、特定のテスト環境、統合環境および本番環境の作成が必要になります。通常、リホスティング・プロジェクトの様々な機能は次のとおりです。

•

プロジェクトの計画を作成します。一般的な要件を設定し、ターゲット・アーキテクチャ・オプションを設計します。

•

変換するアセットを準備し、ターゲット環境のインストールと構成を行います。

•

アセットを変換します。

•

ターゲット環境にアセットを統合します。

これらは繰り返して行うことができます。通常、プロジェクトは次のフェーズで構成されます。

•

プロジェクト戦略の設定。

•

アセスメント調査。

•

パイロット・プロジェクト。

•

実装。

これらの各フェーズは様々なステップで構成されます。ステップの結果はテストできます。また、ステップは必要に応じて繰り返されます。

リホスティング・ライフサイクルの概要

リホスティングは、フェーズとステップに編成されたプロジェクト内で実行されます。各ステップは、1つ以上の成果物を生成します。リホスティング・プロジェクトの様々なステップと並行して、プロジェクトの様々なフェーズを検証する一連の並列テスト・ステップが存在します。

プロジェクトには様々な人がかかわっており、それぞれがプロジェクト内で様々な役割および責任を負っています。プロジェクトは環境内で実行されるため、プロジェクトの様々なフェーズおよびステップについて説明するには、まずそれらを実行する必要のある環境について説明する必要があります。

プロジェクトの環境

リホスティング・プロジェクトを実行するには5つの異なる環境が必要です。次に示す2つのソース環境(移行前)と3つのターゲット環境(移行後)です。

1.

変換するアセットの現在の本番ソース環境。

2.

本番環境から抽出した操作を格納して分離し、テスト・データベースを作成するためのテスト・ソース環境。

3.

変換されたアセットの実行、チューニングおよびテストのためのテスト・ターゲット環境。

4.

統合、操作の移行またはスイッチオーバー前処理など、すべてのアクティビティをホストするために使用される統合ターゲット環境。

5.

変換とテストが行われたアセットのための本番ターゲット環境。

表1-1 プロジェクトの環境

環境

本番

統合

テスト

ソース

本番ソース

テスト・ソース

ターゲット

本番ターゲット

統合ターゲット

テスト・ターゲット

ニーズによっては同一のプラットフォームを複数配置して、同じプロジェクトの作業をチームで並行して行うことが可能です。

プロジェクト・フェーズの概要

1つのプロジェクトは複数の作業フェーズに分割されており、明瞭な成果物が生成されます。これらの成果物は、プロジェクトの次のフェーズに進む前に検証されます。これらのフェーズは次のとおりです

表1-2 プロジェクト・フェーズ

フェーズ

移行ステップ

テスト・ステップ

環境

言語/

データ

プロジェクト管理

プロジェクトの定義

変換前

アセットの生成

ソース本番からソース・テスト

両方

アセットのカタログ化およびアセットの合理化(必要な場合)

ソース・テスト

言語

外部仕様アーキテクチャの開発

ターゲット環境の計画および準備

データ変換

ソース・テストからターゲット・テスト

データ

テストの準備

テストの設計

テストの準備

テストのツール

ソース・テスト

両方

パイロット

パイロット・セットの変換

パイロット・セットのテスト

ターゲット・テスト

言語

残余

残余の変換

残余のテスト

ターゲット・テスト

言語

統合

システムの統合および操作の移行

システムのテストおよび操作のテスト

ターゲット・テストからターゲット統合

両方

スイッチオーバー

保守作業の変換および保守作業の変換テスト

保守作業のテストおよび予行演習

ターゲット・テスト

両方

スイッチオーバー

ターゲット統合からターゲット本番

教育

教育およびトレーニング

様々なフェーズは次の図のようにグループ分けできます。

図1-1 プロジェクトのフェーズとプロセス

プロジェクトでの製品使用の概要

Refine for Z/OS Replatformingは、プログラム・コンポーネントとデータを変換および統合するために使用されます。次の図は、プログラム・コンポーネントの用途と、異なる環境への移行に備えてソース・ファイルを準備するためにプログラム・コンポーネントがどのように使用されるかを示します。

図1-2 言語の移行

Refine for Z/OS Replatformingのコンポーネントを使用してアセットを変換し、変換後の調整の後で、アセットをソース・テスト環境からターゲット・テスト環境に移動できるようにします。

Oracle Tuxedo Application Runtime for CICS and Batchのコンポーネントは、ターゲット・テスト環境でのテストと統合準備の後で、変換されたアセットを統合するために使用されます。COBOLプログラム、JCLおよび関連コンポーネントが、UNIX、OracleデータベースおよびTuxedoトランザクション環境に統合されます。これらのコンポーネントは、変換プロセスで生成されるバッチおよびCICSコンポーネントとともに動作するかどうかテストされます。

図1-3 データの移行

移行するアセットが生成され、ソース・テスト・マシンに移動されます。その後、移行されたアセットは変換され、Oracleデータベースがあるターゲット・テスト・マシンに移動されます。テスト後、データは、リホスティング・ツールがプログラムと統合された統合環境に移動され、変換されたデータを使用して品質とパフォーマンスがテストされます。スイッチオーバーが発生すると、最新データがソース本番環境からターゲット本番環境に直接変換されます。

図1-4 移行アーキテクチャ

前提条件

プラットフォーム

Linux32/Linux64

ソフトウェア環境

JRE 1.6.0以上

Eclipse IDE for Java Developers Galileo (3.5)以上

Perlバージョン5.8.8以上

スキル

次のスキルが必須です。

•

移行プロセスおよび概念

Rehosting Workbenchカタロガで使用されるプロセス、概念および用語を理解する(つまり、カタロガが必要とする入力、出力および構成を知り、どのようにしてすべてのコンポーネントを個別および一緒に分析して、アセットに一貫性があるか、移行できるかを決定するのかを知る)必要があります。

•

Eclipseのスキル

移行プロセスに伴う特定のアクションを実行するためには、Eclipseのスキルが必要になります。次のことを理解しておく必要があります。

•

ビュー、ナビゲータ、パースペクティブなど。

•

新しいプロジェクト・ウィザード、プロジェクト・プロパティ・ページおよびビューを開くための一連の操作。

•

プラグインをテストする場合は、次の手順を実行する必要があります。

•

ワークスペースを削除する。

•

-cleanオプションを使用してEclipseを実行する。

プラグインのインストール

プラグインをインストールするには、com.oracle.tuxedo.wbplugin_x.x.x.x.jarファイル(Tuxedo ART Workbenchインストール・ディレクトリの下のutils/eclipse_pluginサブディレクトリにあります)を$ECLIPSE_HOME/pluginsディレクトリにコピーしてから、Eclipseを再起動する必要があります。

注意:

プラグインは一度に1つのバージョンのみ使用できます。新バージョンをインストールする前に、旧バージョンのプラグインをすべて削除する必要があります。

ただし、バージョンを更新しても、新しいプラグインはEclipseの再起動後に有効にならない場合があります。Eclipseでこれらのキャッシュを強制的に再初期化する場合は、Eclipseを起動する際に-cleanオプションをコマンド行引数として使用します。

コンポーネントおよびレイアウト

プラグインには、Eclipse関連のTuxedo ART Workbenchビュー、メニューおよびツールバーを編成するTuxedo ART Workbenchパースペクティブがあります。また、Tuxedo ART Workbenchプロジェクト用に作成されたナビゲータもあります。

プラグインには、移行プロセスを分析するためのカタロガ・レポート・ビューおよびプロセス・モニター・ビューがあります。

•

Tuxedo ART Workbenchパースペクティブ

•

Tuxedo ART Workbenchナビゲータ

•

移行プロセス・チート・シート

•

Eclipseのプリファレンス

•

メニュー項目およびタスク

Tuxedo ART Workbenchパースペクティブ

Eclipseプラットフォームで、パースペクティブは、ウィンドウ内で表示可能なアクションおよびビューを決定します。

Tuxedo ART Workbenchパースペクティブは、次のビューから構成されます。

•

Workbenchナビゲータ

•

一般ナビゲータ

•

問題

•

レポート

•

進捗モニター

Tuxedo ART Workbenchパースペクティブでは、Tuxedo ART Workbench固有のアクション/コマンドもメニュー項目およびツールバー・ボタンとして表示されます。

Tuxedo ART Workbenchナビゲータ

Tuxedo ART Workbenchナビゲータは、内部のEclipseの一般ナビゲータとよく似ています。違いは、Tuxedo ART WorkbenchナビゲータにはARTプロジェクトのみが表示されることです。

カタロガ・レポート・ビュー

カタロガの出力レポートは、レポート・ビューに表示されます(図1-5を参照)。タブに各レポートが表示されます。ビューはARTパースペクティブに統合されています。「クローズ」ボタンをクリックして閉じるか、メイン・メニューから再度開きます。

図1-5 レポート・ビューの例

レポート・ビューには、次の機能があります。

•

ソート

レポートの内容は、表に編成されます。表の見出しをクリックするとソートできます。

•

色付きの警告

各レポートの異常レベルはレベル別に色づけされます。

表1-3 色付きの警告

異常レベル

色

OK

緑

警告

黄

ERROR

赤

FATAL

赤

•

リフレッシュ

レポートの内容は、変換操作または新規プロジェクトの作成操作の後に自動的にリフレッシュされます。

レポート・ビューのメニュー・バーの「リフレッシュ」ボタンをクリックしても、内容をリフレッシュできます。

進捗モニター・ビュー

進捗モニター・ビューを使用すると、処理中のソース・ファイルまたはスキーマを確認できます。最初にソース・ツリーが表示され、図1-6に示されているようにソース・タイプ別に編成されている現在のプロジェクト内のソースまたはスキーマの構造が示されます。

カタログ化、JCL変換およびCOBOL変換のプロセスとともに、現在処理中のソース・ファイルがソース・ツリー内でハイライトされます。

DB変換およびファイル変換では、現在処理中のDBスキーマまたはファイル・スキーマがスキーマ・リスト内でハイライトされます。

図1-6 進捗モニター・ビューのサンプル

移行プロセス・チート・シート

プラグインには、変換タスクを手順を追って説明する移行プロセス・チート・シートが含まれます。チート・シートを開くには、メイン・メニューの「ヘルプ」→チート・シートをクリックし、ARTグループの下のSTDB2ORAサンプルのART移行プロジェクトの作成というチート・シートを選択します。

このチート・シートは、Tuxedo ART Workbench Eclipseプラグインを使用した、メインフレーム・アーティファクトの移行の実行方法を示しています。ARTプロジェクトの作成後、すべてのTuxedo ART Workbenchの機能(カタログ化、VSAMファイルの変換、DB2スキーマの変換、COBOLおよびJCLソースの変換など)をEclipseで実行できます。

Eclipseのプリファレンス

Tuxedo ART Workbenchグローバル・オプションの一部は、Eclipseのプリファレンスのページで設定されます。次のものが含まれます。

Workbenchのインストール・ディレクトリ

このグローバル・プリファレンスは、デフォルトですべてのARTプロジェクトに影響します。

メニュー項目およびタスク

この項では、メニュー項目とそれらの関連タスクの全般的な概要を説明します。

メニュー項目例の詳細は、付録Bおよび「付録C: Oracle Tuxedo Application Rehosting Workbenchのログ」を参照してください

•

インポート

•

準備

•

分析

•

変換

•

構成

•

ビルド

•

デプロイ

•

実行

•

リセット

図1-7は、Tuxedo ART Workbenchのハイレベル・ワークフローの図です。

図1-7 Tuxedo ART Workbenchのハイレベル・ワークフロー

インポート

アセットをARTプロジェクトにコピーするプロセスです。ユーザーは、インポート・ウィザードを使用してインポートするサブディレクトリを指定できます。これらのRAWファイルは、移行プロセス全体で変更されません。

準備

準備には、移行アセットの収集と変換するための事前処理が必要です。これには、ファイルのトランスコーディング、未認識文字の削除およびファイルの名前変更など、元のアセットの形式の更新プロセスが含まれます。

準備のタスクは、表1-4に示すとおりです。

表1-4 準備のタスク

タスク

説明

ソース・アセット

出力

準備手順の前におけるカスタム・スクリプトの実行

準備プロセスの前に、ユーザーによりカスタマイズされた特殊タスクを実行できます。

ユーザーが指定した範囲。

カスタム・スクリプトが準備前に実行されます。

MBCSコード・ページ変換

EBCDICエンコーディングのマルチバイト文字をASCIIベース・エンコーディングのマルチバイト文字に変換します。

すべて

すべてのファイルはASCIIベースのエンコーディングに変換されます。

dos2unix変換

ファイルをDOS形式(0x0D0Aを改行として使用)からUNIX形式(0x0Aを改行として使用)に変換します。

すべて

すべてのWindowsリターンはUNIXリターンで置換されます。

ソース・ファイル名を大文字に変更

拡張子を除いてファイル名を大文字に変更します。

すべて

すべてのファイル名は大文字で、小文字の接尾辞が付きます。

準備手順の後におけるカスタム・スクリプトの実行

準備プロセスの後に、ユーザーによりカスタマイズされた特殊タスクを実行できます。

ユーザーが指定した範囲

カスタム・スクリプトが準備後に実行されます。

分析

ソース・アセットにデータを移入し、分析レポートを生成します。

分析のタスクは、表1-5に示すとおりです。

表1-5 分析のタスク

タスク

説明

ソース・アセット

出力

スコープの構成

詳細な構成項目はウィザードで表示されます。

すべて

アセット説明ファイル(名前はsystem.desc)

COBOL形式の変換。

COBOLおよびコピー・ブックを自由な形式に変換します。

COBOL/コピーブック

自由形式のファイルと.origファイル

ソース・アセットのカタログ化

system.descファイルで定義されたソース・アセットはすべて、カタログ化されます。

すべて

POBリポジトリ・レポート

変換

変換フェーズでは、COBOL変換とJCL変換に対して増分変換がサポートされています。増分変換はPOBファイルと対応するターゲット・ファイルのタイムスタンプに基づきます。そのタイムスタンプが対応するターゲット・ファイルよりも新しい場合のみ、POBファイルの変換が行われます。ただし、RDBMSとFILEの変換における基本的なメカニズムの相違により、変換フェーズではそれらの増分変換をサポートしていません。

変換のタスクは、表1-6に示すとおりです。

表1-6 変換のタスク

タスク

説明

ソース・アセット

出力

ファイル定義の変換

z/OSファイルを移行するために使用するコンポーネントを生成します。

Datamap.reおよびmapper.re

プログラムのアンロードと再ロードを行います。

DBスキーマの変換

z/OS DB2データベースを移行するために使用するコンポーネントを生成します。

POBリポジトリ。

変換されたDDLスクリプト。プログラムのアンロードと再ロード。

COBOLコンポーネントの変換

COBOLプログラムをz/OS COBOLからMicro Focus COBOLまたはCOBOL-ITへ変換します。

POBリポジトリ。

変換されたCOBOLプログラム。

JCLコンポーネントの変換

Kornシェル構文を使用して、z/OS JCLファイルをUnix/Linuxシェル・スクリプトに変換します。

POBリポジトリ。

Kornシェル・プログラム。

CICS CSDの変換

RDOをリソース説明に変換します。

RDOファイル

変換されたRDOファイル。

注意:

ファイル定義の変換には、バッファ・コンバータと逆コンバータも含まれます。デフォルトでは、これら2つのコンバータは無効になっており、プロジェクトのプロパティ・ページで有効にできます。

構成

この手順では、デフォルトのビルド・スクリプト、Tuxedo構成ファイル、CICS and Batchのランタイム環境構成ファイルが生成されます。構成メニューにあるウィザードで、ユーザー指定オプションを使用してカスタマイズできます。

構成のタスクは、表1-7に示すとおりです。

表1-7 構成のタスク

タスク

説明

構成可能なオプション

出力

ビルド設定の構成

ターゲット・コンポーネント・ディレクトリごとのmakefileとルートmakefileを生成します。

データベース・オプション。COBOLコンパイラ・オプション。ART CICSプリプロセッサ・オプションなど。

ターゲット・ディレクトリ下のmakefile。

Tuxedoドメインの構成

ubbconfigテンプレートの生成

IPC KEYやマシン名などのubb構成。

ubbconfig.em

ubbconfig.null

ubbconfig.tsam

CICS Runtimeの構成

CICS Runtimeのubbconfigとsetenvファイルの生成

CICS Runtimeの場所やモニター設定など。

configure/CICS_RTディレクトリにあるubbconfigやsetenvなどのファイル

Batch Runtimeの構成

Batch Runtimeのubbconfigとsetenvファイルの生成

Batch Runtimeの場所、JESROOTおよびモニター設定など。

configure/BATCH _RTディレクトリにあるubbconfigやsetenvなどのファイル

IMS Runtimeの構成

IMS Runtimeのubbconfigとsetenvファイルの生成

IMS Runtimeの場所やモニター設定など

configure/IMS_RTディレクトリにあるubbconfigやsetenvなどのファイル

注意:

現時点では、Oracle Databaseへのクライアントとしての接続のみがサポートされています。接続文字列はsqlplus user/password@connect_identifierです。

ビルド

この手順では、データベース・スキーマが作成されます。アプリケーション・コンポーネント、データ再ロード・プログラム、データ・アクセス・プログラムおよびTUXEDO構成ファイルがコンパイルされます。

ビルドのタスクは、表1-8に示すとおりです。

表1-8 タスク

タスク

説明

出力

データベース・スキーマの作成

データベースを使用する場合、データベース・スキーマをこの手順で作成します。

表などのデータベース・オブジェクトがターゲット・データベースに作成されます。

アプリケーション・コンポーネントのビルド

COBOLソース・ファイル(BatchとCICSが含まれます)とBMSファイルがコンパイルされます。

ターゲット・コンポーネント・ディレクトリの下のバイナリ・ファイル。

データ再ロード・プログラムのビルド

データ再ロード・プログラムがコンパイルされます。

ターゲット再ロード・ディレクトリの下のバイナリ・ファイル。

データ・アクセス・プログラムのビルド

データ・アクセス・プログラムがコンパイルされます。

ターゲットDMLディレクトリの下のバイナリ・ファイル。

TUXEDO構成ファイルのビルド

TUXEDO構成ファイルがコンパイルされます。

デプロイ・ディレクトリ(BATCH_RT/config/tux/とCICS_RT/config/tux)の下にあるバイナリTUXEDO構成ファイル(名前はtuxconfig)

デプロイ

変換済アセットを圧縮して、ローカル・マシンの場合、ターゲット・プラットフォームで解凍するプロセスです。

デプロイメントのタスクは、表1-9に示すとおりです。

表1-9 デプロイメントのタスク

タスク

説明

出力

ターゲットのパック

すべての変換済ファイル、生成されたmakefile、KIXリソース・ファイルおよびARTJES構成ファイルを含みます。

packディレクトリのTarファイル。

アプリケーションのデプロイ

指定ディレクトリの下でパッケージを解凍します。

デプロイ・ディレクトリのファイル。

Runtimeの設定

ランタイム用に必要なコンポーネントを作成します。具体的には、必要なディレクトリ、TLOG、JES用/Q、IMSなどを作成します。

デプロイ・ディレクトリの下にあるサブディレクトリIMS_RT、BATCH_RTおよびCICS_RTにあるファイル。

ファイル・データのリロード

ファイル・データを指定ディレクトリにリロードします。

ユーザーがウィザードで指定した場所にあるファイル。

DB2データのリロード

db2データをOracleデータベースにリロードします。

Oracleデータベースのデータ。

実行

ターゲット・プラットフォーム上で変換済アプリケーションをテストのために実行するプロセスです。欠落している実行のタスクは、表1-10に示すとおりです。

表1-10 実行のタスク

タスク

説明

出力

CICS Runtimeの起動または停止

CICS Runtimeの環境を設定します。

CICS Runtime用に構成されたTuxedoドメインを起動するか停止します。

ART CICS Runtime。ドメインが起動するか停止します。

Batch Runtimeの起動または停止、ジョブの操作

Batch Runtimeの環境を設定します。

Batch Runtime用に構成されたTuxedoドメインを起動するか停止します。

ジョブの発行/取消/保持/リリース/パージ/再起動、ジョブ・ログの表示など

ART Batch Runtime。ドメインが起動するか停止します。ジョブ・プロパティがリストされます

IMS Runtimeの起動または停止

IMS Runtime環境を設定します。

IMS Runtime用に構成されたTuxedoドメインを起動するか停止します。

ART IMS Runtime。ドメインが起動するか停止します。

リセット

指定したステップをロールバックします。リセットのタスクは、表1-11に示すとおりです。

表1-11 リセットのタスク

タスク

説明

インポートの消去

インポート・プロセスを元に戻します。$project/importedディレクトリのファイルがすべて削除されます。

準備の消去

準備プロセスを元に戻します。$project/preparedディレクトリのファイルがすべて削除されます。

ソースの消去

分析プロセスを元に戻します。$project/sourceディレクトリのファイルがすべて削除されます。

POBリポジトリを消去

$project/sourceディレクトリのpobファイルをすべて消去します。

ターゲットの消去

変換プロセスを元に戻します。変換手順の出力が削除されます。

構成の消去

構成プロセスを元に戻します。ubbconfigやsetenvなどの構成ファイルが削除されます。

ビルド・バイナリの消去

ビルド・プロセスを元に戻します。ビルド手順の出力が削除されます。

すべての消去

前述のプロセスをすべて元に戻します。$project/paramと$project/scriptsにあるファイルを除いてすべてのファイルを削除します。

詳細なリホスティングの方法

ARTプロジェクトの作成

プロジェクト・プロパティの構成

ARTプロジェクトの作成

新規プロジェクト・ウィザードを使用して、新しいARTプロジェクトを作成する必要があります。次の手順を実行します。

1.

図1-8に示すように、ウィザードを選択します。

図1-8 ウィザードの選択

2.

図1-9に示すように、プロジェクト名を指定します。

図1-9 プロジェクト名

3.

図1-10に示すように、Tuxedo ART Workbenchインストール・ディレクトリを指定します。

図1-10 Workbenchインストール・ディレクトリの選択。

4.

図1-11に示すように、ソース・ファイルを含むルート・ディレクトリを指定します。

図1-11 ルート・ディレクトリのソース・ファイルの指定

5.

図1-12に示すように、ターゲット・データベースとCOBOLコンパイラを指定します。

図1-12 データベースとコンパイラの選択

プロジェクト・プロパティの構成

新しいARTプロジェクトの作成後、図1-13に示すように、プロジェクトのプロパティ・ページ内のプロジェクト・プロパティを構成する必要があります。

図1-13 プロジェクトのプロパティ・ページ

Tuxedo ART Workbenchの構成可能オプションの多くは、プロジェクトのプロパティ・ページで構成できます。これを使用すると、Tuxedo ART Workbenchの構成オプションを簡単に表示および変更できます。これらのオプションは、タイプ別に編成されます。詳細は、『Tuxedo ART Workbenchリファレンス・ガイド』の構成ファイルの説明に関する項を参照してください。

インポート

この項では、Eclipseプラグイン・インポート・ウィザードを使用する方法について説明します。

プロジェクト作成中に指定したディレクトリのサブディレクトリすべてが、表で最初の列に表示されます。2番目の列をクリックすると、関連サブディレクトリをインポートしたりインポートしないことができます。最後の列はインポートのステータスです。このサブディレクトリが前にインポートされる必要がある場合、「はい」と表示されます。それ以外の場合、「いいえ」と表示されます。

インポート済ソース・ファイルで分析や変換のフェーズをユーザーが実行してから、インポート・ウィザードを実行して、ソース・ファイルが格納されている新規サブディレクトリや新規ソース・ファイルをインポートする場合、後でインポートされたソース・ファイルのみが、分析フェーズで処理されます。ユーザーが分析フェーズの出力を消去する必要がある場合でなければ、これは増分処理です。

準備

この項では、Eclipseプラグイン準備ウィザードを使用する方法に関する情報と手順について説明します。

準備手順の前におけるカスタム・スクリプトの実行

準備プロセスの前に、インタプリタによりカスタム・スクリプトが自動的に実行されます。ディレクトリ・パスを引数として使用してコールされます。

複数のディレクトリが選択されていると、カスタム・スクリプトが複数回実行されます。その際、毎回ディレクトリ・パスを引数として使用します。

標準出力と標準カスタム・スクリプト実行エラーがログ・ファイルにダンプ出力されます。

MBCSコード・ページ変換

IBMメインフレームではEBCDICベースのエンコーディングが使用されます。オープン・システムではASCIIベースのエンコーディングが使用されます。

このユーティリティを使用して、EBCDICエンコーディングのマルチバイト文字(IBM-1390など)をオープン・システムのマルチバイト文字(Shift-JISなど)に変換できます。ICUで使用されるエンコーディング名は、iconvで使用されるものと同じであり、UNIX/Linuxで一般的なユーティリティであるため、iconvオンライン・ヘルプを参照することで、エンコーディング名を簡単に取得できます。

ヒント:

uconv -lコマンドをシェルで入力すると、エンコーディング名がリストされます。

dos2unix変換

改行マーカーはDOSシステム(0x0D0Aを使用)とUNIX/Linuxシステム(0x0Aを使用)とで異なります。

このユーティリティを使用して、DOS形式のテキスト・ファイルをUNIX/Linux形式に変換できます。

ソース・ファイル名を大文字に変更

拡張子を除いてファイル名を大文字に変更する機能が実現されます。

準備手順の後におけるカスタム・スクリプトの実行

これは、「準備手順の前におけるカスタム・スクリプトの実行」と同様なタスクを実行します。ここでのスクリプトが、準備タスクにより処理されたソース・ファイルに適用されます。

分析

この項の目的は、次のとおりです。

•

Tuxedo ART Workbenchカタロガの使用方法に関する情報と手順を説明します。

•

Tuxedo ART Workbenchカタロガ・ツールの構成と実行を支援します。

•

メッセージとステータス情報の解釈結果を検証する方法を示します。

このガイドには次情報が含まれます。

•

移行プロセス全体におけるTuxedo ART Workbenchカタロガの使用方法。

•

移行するアセットの準備、作業領域の構成およびTuxedo ART Workbenchツールの効果的な使用方法についてのベスト・プラクティス。

注意:

これらのプラクティスおよび方法はTuxedo ART Workbench製品の一部ではありませんが、新しいユーザーを支援する目的でこのガイドに示しています。必要ない場合は先に進み、独自の方法でTuxedo ART Workbenchをカスタマイズし、独自のメソッドを作成できます。

Tuxedo ART Workbenchカタロガは、次の項で説明されています。

•

スキル

•

要件および前提条件

•

プラットフォーム移行プロセスにおけるカタロガの概要

•

カタログ化の手順

•

Makeユーティリティの使用

•

POBリポジトリを消去

スキル

移行プロセスおよび概念

Tuxedo ART Workbenchカタロガで使用されるプロセス、概念および用語を理解し、カタロガが必要とする入力、出力および構成を知る必要があります。また、アセットに一貫性があるか、移行できるかどうかを決定するために、どのようにすべてのコンポーネントが個別および一緒に分析されるかを知る必要があります。

『Tuxedo ART Workbenchリファレンス・ガイド』には、カタロガのすべての機能が詳しく説明されています。概念、用語、入力と出力および構成の概要について、カタロガの章の少なくとも最初の3つの項を読んでください。

UNIX/Linuxスキル

UNIX/Linuxスキルは、移行プラットフォーム環境で正しく作業し、カタログ化プロセスに伴う特定のアクションを実行するために必要です。次のことを理解しておく必要があります。

•

構成ファイルおよび出力ファイルの作成、変更、表示および削除を行う、標準のUnix/Linuxコマンド。

•

カタログ化の前後で、元のz/OSアセットを格納および管理を行う、標準のUnix/Linuxコマンドおよび特化したスクリプト(シェル、makefile、cvs)。

•

Tuxedo ART Workbenchカタロガの実行を開始、モニターおよび終了するコマンドのセット(シェル、makefile)。

z/OSスキル

z/OSコンポーネントおよびプログラミング言語を識別し、理解できる必要があります。z/OS環境については一般的なスキル(COBOL、ファイル、DB2、CICS、JCL、ユーティリティ)で十分です。

要件および前提条件

移行プラットフォームの準備

移行プラットフォームとは、カタロガなどのTuxedo ART Workbench移行ツールが実行されるプラットフォームのことです。このプラットフォームは、Intel互換のハードウェア・プラットフォーム上で実行するLinuxをベースにしています。

アクションを実行する前に、Oracle Tuxedo Application Rehosting Workbenchインストレーション・ガイドに記載されている仕様および要件に従い、Tuxedo ART Workbenchをインストールおよび構成する必要があります。

スコープの構成

この項では、スコープの構成ウィザードの使用方法について説明します。インポートされたすべてのサブディレクトリは、表の最初の列に表示されます。プラグインではソース・タイプを自動的に検出できる場合があり、ルールは次のようになります。

1.

(1) プラグインでは各サブディレクトリのソース・タイプを組込みファイル拡張子でのみ識別します。

*.cpy - COPYBOOK

*.cbl - CICS、BatchおよびSubを含む、COBOLソース・プログラム

*.jcl - JCLスクリプト

*.bms、*.map - BMSマップ

*.sql、*.ddl、*.db2 - SQLスクリプト

*.sysin - SYSINファイル

*.rdo - RDOファイル

*.proc、*incl - JCLライブラリ

2.

ソースの各サブフォルダの下で、前述の既知の接尾辞が1つのみのソース・ファイルを1種類のみ配置することをお薦めします。これによって、分析ウィザードで各サブディレクトリのソース・タイプを識別できます。そうしないと、ユーザーはそのようなサブフォルダでソース・ファイルの接尾辞または接尾辞リスト、およびディレクトリ・タイプを指定する必要が発生する場合があります。ソース・タイプ検出のルールとソース接尾辞の指定ルールは、次の項目で説明します。

接尾辞

タイプ

*.jcl

JCL

*.bms、*.map

BMS

*.ddl、*db2、*.sql

SQL-Script

*.sysin

JCL-Sysin

*.proc

CL-Lib(Proc)

*.incl

JCL-Lib(Include)

*.cpy

COBOL-Library

*.cbl

COBOL-Batch、COBOL-TPR、COBOL-Sub、COBOL-IMS

*.rdo

RDO

既知の拡張子が見つかると、分析ウィザードでは検索を停止し、検出した拡張子に対応するタイプとしてサブディレクトリのソース・タイプを決定します。

3.

次の拡張子順で既知の拡張子のいずれかのファイルかどうかをチェックすることで、サブディレクトリのソース・タイプを調べます。

既知の拡張子が見つかると、分析ウィザードでは検索を停止し、検出した拡張子に対応するタイプとしてサブディレクトリのソース・タイプを決定します。

4.

項目(3)のルールに基づいて分析ウィザードによりサブディレクトリのソース・タイプが指定されているが、同じタイプで異なる接尾辞の他のソース・ファイルが存在することをエンド・ユーザーが知っている場合、エンド・ユーザーは分析ウィザードで接尾辞のリストを指定する必要があります。たとえば、エンド・ユーザーは*.ddlや*.sqlを指定して、接尾辞がddlやsqlであるソース・ファイルがすべてSQLスクリプトであることを分析ウィザードに示すことができます。

5.

分析ウィザードによりサブディレクトリのソース・タイプが指定されているが、それが正しくないことをエンド・ユーザーが知っている場合があります。つまり、ソース・アセットのネーミング規則が、ARTライフ・サイクルで事前定義されたネーミング規則と一致していません。この場合、サブディレクトリに適切なタイプとそのタイプに対応する接尾辞をエンド・ユーザーは指定する必要があります。

6.

既知の拡張子のいずれが付加されているソース・ファイルが格納されていないためにサブディレクトリでソース・タイプを指定できない場合、エンド・ユーザーは最初にサブディレクトリのタイプを指定してから、拡張子を1つ以上指定する必要があります。これによって、このタイプが属するソース・ファイルを分析ウィザードで識別できます。

7.

一般的にエンド・ユーザーは接尾辞を*.xxxのように指定するので、多くの場合、機能します。ただし、処理対象の一部のソース・ファイルで実際に接尾辞がない場合、エンド・ユーザーは特殊なパターンNULLを使用して、接尾辞がないことを指定する必要があります。さらに、エンド・ユーザーはディレクトリ・タイプを指定する必要があります。指定したソース・タイプに対応する接尾辞を追加することで、接尾辞のないソース・ファイルの名前が変更されます。

表で最後の列をクリックすると、ユーザーは各サブディレクトリのプロセスを有効または無効にできます。

サブディレクトリの詳細設定をクリックすると、多数のオプションが表示されます。各オプションの意味を確認するには、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』のカタロガに関する項を参照してください

プラットフォーム移行プロセスにおけるカタロガの概要

この項では、カタログ化の手順の入力および出力と、プラットフォーム移行プロセスにおける他の移行の手順との依存関係を説明します。

サンプルのSimple Application

実行されるすべての移行アクティビティと、Tuxedo ART Workbenchカタロガを使用してアセットに一貫性があるかどうか、ターゲット・プラットフォームに移行できるかどうかの判断方法を説明するために、Simple Application STFILEORAを使用します。STFILEORAはTuxedo ART Workbenchのツールのセットとともに提供されます。

カタログ化移行手順

カタログ化操作の説明を図で説明します。

1.

構成ファイルと、カタログ化のために準備されたソース・ファイルの説明を読みます。

2.

ソース・アセットの各コンポーネントを解析し、パック・オブジェクト・ベースと呼ばれる内部表現(拡張子.pob)を作成します。これらのコンポーネントの内部的な不整合(構文エラーや宣言されていない変数の参照など)を特定します。

3.

COBOLプログラムからCOBOLサブプログラムへのCALL文などの、これらのコンポーネント間の相互参照を計算します。

4.

アセットから欠落しているサブプログラムへのCALL文の参照、またはアセットのどのCOBOLプログラムからも参照されないSQL表(未使用のコンポーネント)などの、これらの関係における相互の不整合を特定します。

5.

アセット内のすべてのコンポーネントをそのステータス(欠落、未使用または正常)と前述で検出されたすべての異常(不整合)とともにリストするCSV形式のレポートを作成します。

前述の操作は次の項で詳しく説明します。

カタログ化の手順

アセットの作成

この手順はカタロガの前提条件で、移行プロセス全体の概要を説明するOracle Tuxedo Applicationプロセス・ガイドで記載されているように、ソース・プラットフォームでのソース・ファイルの収集、移行プラットフォームへの転送、適切なファイル構造でのインストール、移行の準備を担当するのはTuxedo ART Workbenchのユーザーです。

アセットの作成は、ソースを取得してから、カタロガ・ツールへの有効な入力として使用できるように構成するまで、いくつかの手順からなります。

1.

z/OSから移行するソースの収集

2.

ソースのTuxedo ART Workbenchプラットフォームへの転送

3.

Cataloguerの必要に応じたタイプ別にソースをディスパッチおよび準備します。

コンポーネントをタイプ別に構成します。すべてのCICSプログラムはサブディレクトリを含む1つのディレクトリに入れ、COBOLインクルード、Batchプログラム、Jobなども同様です。

4.

z/OSからの抽出後または転送中に追加された特定の文字または行からのコンポーネントのクリーンアップなど、その他のアクションが必要な場合もあります。

作業環境の初期化と構成

Tuxedo ART Workbenchカタロガは移行プロセスで使用されるOracle Tuxedo Application Workbenchスイートの最初のツールなので、実行するプロジェクト全体に一般的な構成手順をここで説明します。

構成の目的

•

作業環境の準備に必要な時間を削減し、構成が原因で起こりうるエラーを回避します。

•

カタロガだけでなく、その他のWorkBenchツールの構成も初期化します。

•

チームワークの促進のため、標準の構成をお薦めします。

推奨するファイル構造

作業領域を構成および標準化すればするほど、移行タスクはより容易になり自動化されます。

次のサンプルで、典型的な構造を示し、同じ構造で作業することをお薦めします。

リスト1-1 サンプル・アプリケーションの階層

SampleApp

|-- Logs

|-- param

| `-- system.desc

|-- source

| `-- makefile

|-- trf

|-- tools

|-- tmp

各ディレクトリの内容

•

Source

Tuxedo ART Workbenchツールの入力として準備された、移行するすべてのソースが含まれます。

すべてのTuxedo ART Workbenchプロセスがソース・コードを見つけることのできる作業領域です。

•

param

すべての構成ファイル(Tuxedo ART Workbenchツールが使用するパラメータおよびヒント)が含まれます。

•

Logs

すべてのTuxedo ART Workbenchツールが起動され、すべてのログが生成される作業ディレクトリです。

•

tools

移行プロセス中にユーザーが作成した特定のツールを置くディレクトリです。

•

trf

変換の結果が生成されるディレクトリ。

•

tmp

変換操作中に生成された一時ファイルおよび中間ファイルが置かれるディレクトリ。

環境および作業変数の設定

Tuxedo ART Workbenchを使用してプロジェクトで作業するたびに、後で役に立つ特定の環境変数を設定することをお薦めします。必須の環境変数はREFINEDISTRIBのみで、他は単純化の目的で使用できます。

表1-12は、提案された変数の使用方法を説明しています。

表1-12 Rehosting Workbench環境変数

変数

値

使用方法

REFINEDISTRIB

Linux64またはLinux32

Tuxedo ART Workbenchバイナリ・ファイルのアーキテクチャを指定します。

PROJECT

${HOME}

ワークスペース内のプロジェクト・ルート。HOMEはトレーニング用に使用されます。ただし、値は/project/SampleAppのようにする必要があります

CVSROOT

${PROJECT}/CVS_DELIVRY

ソースおよび構成ファイルを含むのに使用するCVSリポジトリ。

LOGS

${PROJECT}/Logs

Tuxedo ART Workbenchのログが格納される構造体

PARAM

${PROJECT}/param

パラメータ・ファイルが格納されるディレクトリ

SOURCE

${PROJECT}/source

変換されるソース・ファイルが格納される構造体

REFINEDIR

/<InstallDir>/refine

Tuxedo ART Workbenchバイナリおよびユーティリティのルート

PHOENIX

${REFINEDIR}

Tuxedo ART Workbenchにより使用される変数

TMPPROJECT

${PROJECT}/tmp

Tuxedo ART WorkbenchのR4Z用の一時構造体

PATH

${PATH}:/platform/Tools

PATH補完

プロジェクト例のSimple Applicationでは、export Linuxコマンドを使用してすべての初期化を含む$PROJECT/.projectという名前の設定ファイルを使用します。このファイルはプロジェクトで作業するために新しいLinuxセッションが開かれるたびに実行されます

リスト1-2 Simple Application .projectファイルからの抽出:

echo "Welcome to SampleApp"

export GROUP=refine

export PROJECT=${HOME}/SampleApp

export LOGS=${PROJECT}/Logs

export SOURCE=${PROJECT}/source

export PARAM=${PROJECT}/param

export REFINEDIR=/product/art_wb11gR1/refine

export PHOENIX=${REFINEDIR}

export TMPPROJECT=${PROJECT}/tmp

export REFINEDISTRIB=Linux64

プロジェクトの初期化の概要

新しいプロジェクトを初期化するには、次の順序で実行します。

1.

前述のファイル構造を作成します。

2.

サンプルの構成(system.desc、version.mk、options-catalogなど)ファイルをSimple Applicationから$PROJECT/paramディレクトリにコピーし、必要な変更を行います。

3.

makefileをソース(SimpleApp)から$PROJECT/sourceにコピーします。

4.

ファイル.projectを$PROJECTの下に作成し、環境および作業変数の設定にリストした変数で初期化します。このファイルの変数はプロジェクトで作業するたびにエクスポートされます。

5.

準備したソース・ファイルを$PROJECT/sourceにコピーします

6.

オプション: ソースおよび構成ファイルをCVSで管理します。

構成

少なくとも2つの構成ファイルを設定する必要があり、追加の構成ファイルについては高度な使用の項で説明します。

次の2つの構成ファイルがカタロガでは必要です。

•

システム記述ファイル

•

一般オプション・ファイル

システム記述ファイル

システム記述ファイルはTuxedo ART Workbenchツールのメイン構成ファイルです。

Simple Applicationの例の場合

•

system-nameはSampleApp

•

移行するソースが格納されているパスは../sourceです

•

カタロガにグローバル・オプション・ファイルの場所を知らせるには、相対名または絶対名を使用できますが、複数のソース環境を移行する場合には絶対パスを使用することをお薦めします。

global-options catalog = "../param/options-catalog.desc".

•

次に、カタログ化するコンポーネントを含む各ディレクトリのエントリを追加します。

リスト1-3 Simple Applicationのシステム記述

system SampleApp root "../source"

global-options

catalog="../param/options-catalog.desc",

no-END-Xxx.

DBMS-VERSION="8"。

% Copies

directory "COPY" type COBOL-Library files "*.cpy".

% DDL

directory "DDL" type SQL-SCRIPT files "*.ddl".

% Batch

directory "BATCH" type COBOL-Batch files "*.cbl" libraries "COPY". %, "INCLUDE".

% Cics COBOL Tp

%

directory "CICS" type COBOL-TPR files "*.cbl" libraries "COPY". %, "INCLUDE".

グローバル・オプション

カタロガのオプション・ファイルの目的は、動作に影響する追加の情報をカタロガに与えることです。

Simple Applicationの例では、3つのオプションのみを使用しますが、他のオプションも使用できます。オプションの完全なリストは、『Tuxedo ART Workbenchリファレンス・ガイド』を参照してください。

リスト1-4 Simple Applicationのグローバル・オプション・ファイル

%% Options for cataloging the system

job-card-optional.

カタロガの実行

1つの操作

カタログ化を1つのコマンドで実行することができます。すべての操作は順次実行されます。

コマンド行構文の例を示します。

${REFINEDIR}/refine r4z-catalog -s $PARAM/system.desc

説明:

•

${REFINEDIR}はTuxedo ART Workbenchツールがインストールされているディレクトリです。

•

$(CATALOG)は使用されるカタロガのバージョンです

•

$(SYSTEM)はシステム記述ファイルのパスです。

このサンプルでのコマンドは次のとおりです。

ディレクトリ$LOGS/catalogからコマンドを実行します。

${REFINEDIR}/refine r4z-catalog -s $PARAM/system.desc

実行ログは画面に出力され、同時に、コマンドを開始したディレクトリの下のログ・ファイルにリダイレクトされます。

手順ごと

解析

この手順の実行は、カタログ化全体を待つことなく、特定のプログラムをチェックして結果を見たい場合に有用です。

リスト1-5 解析例

# parse only one program

${REFINEDIR}/refine r4z-preparse-files -s $PARAM/system.desc CICS/PGMM000.cbl

# parse a list of programs

# build a list that contains programs with path from source (CICS/PGMM000.cbl)

${REFINEDIR}/refine r4z-preparse-files -s $PARAM/system.desc -f list-of-file

分析

この手順の結果は、コンポーネント間情報を示すsymtab-SampleApp.pobという名前のバイナリ・ファイルです。

リスト1-6 分析例

cd $LOGDIR/catalog

${REFINEDIR}/refine r4z-analyze -s $PARAM/system.desc

レポートの出力

この手順で、バイナリ・ファイルに格納された情報が収集され、CSV形式のレポートに印刷されます。

リスト1-7 レポート出力の例

cd $LOGDIR/catalog

$REFINEDIR/refine r4z-fast-final -v M2_L3_3 -s $PARAM/system.desc

Simple Applicationでは、レポートは$PROJECT/source/Reports-SampleAppに生成されます。

•

report-SAMPLEAPP-Anomalies

•

report-SAMPLEAPP-COBOL-Copy

•

report-SAMPLEAPP-COBOL-Programs

•

report-SAMPLEAPP-JCL-Files

•

report-SAMPLEAPP-JCL-Jobs

•

report-SAMPLEAPP-JCL-Sub-Files

•

report-SAMPLEAPP-SQL-Tables

•

report-SAMPLEAPP-SQL-Views

•

report-SAMPLEAPP-Transactions

この他のレポートはOracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドに記載されています。

結果の分析と検証

カタログ化レポートを使用して、移行する正確なアセット・セットの作成のための様々なアクションを実行し、Tuxedo ART Workbenchの手順のCOBOL変換、JCL変換およびデータ変換を開始できます。

注意:

これは、カタログ化および変換アクティビティが厳密に順次であるということを意味しているわけではなく、それらは重なる可能性があります。

インベントリ

カタログ化の後、各プログラム、Copy、Job、Includeにはその使用に応じたステータスが与えられます。

表1-13 インベントリ・ステータス

ステータス

説明

CORRECT

コンポーネントはソースに存在し、使用されています。

•

少なくとも1つのプログラムにより使用されているコピーブック。

•

少なくとも1つのトランザクション、JCLまたはプログラムにより使用されているプログラム。

•

使用されているとみなされるすべてのジョブ。

•

少なくとも1つのジョブにより使用されているJCLサブファイル。

アクション: 受け入れます

UNUSED

コンポーネントは存在しますが使用されていません。

•

プログラムから呼び出されていないコピーブック

•

トランザクションまたはジョブから呼び出されていないプログラム、またはプログラムからサブプログラムとして呼び出されていないプログラム。

•

ジョブにより使用されていないJCLサブファイル

アクション: コンポーネントを保持するかアセットから削除するかを決定します。

MISSING

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

•

少なくとも1つのプログラムにより使用されているコピーブック。

•

少なくとも1つのトランザクション、JCLまたはプログラムにより使用されているプログラム。

•

少なくとも1つのジョブにより使用されているJCLサブファイル。

アクション: 欠落しているコンポーネントを追加するか、使用されていないまたは必要のない呼出しコンポーネントを削除するかを決定します。

異常分析

異常レポートに報告されたすべてのエラーは分析する必要があります。

•

FATALおよびERROR重大度レベルの異常があるコンポーネントまたはアセットは変換に適さず、分析して修正する必要があります。

•

NOTICEおよびWARNING重大度レベルの異常も分析する必要がありますが、変換に影響がない場合にはそのままにしておくこともできます。

変換に進む前に、アセットに重大なエラーが含まれないようにする必要があります。

完了条件

カタログ化はすべての必要な出力(POBファイルおよびカタログ化レポート)が生成されたら完了とみなすことができます。

プロセスとして、プロジェクトの内容によりますが、一般的にカタログ化は次の場合に完了したとみなされます。

•

すべての未使用および欠落コンポーネントが修正または許可されました。

•

すべてのエラーが修正または許可されました。

Makeユーティリティの使用

makeはターゲット(ファイルまたはアクション)の構成を自動化および最適化することを目的としたUNIXユーティリティです。

makeを使用して移行プロセスを構成する様々な操作を実行することをお薦めする理由は次のとおりです。

•

すべての(実行可能)プロセスをドキュメント化できます。

•

増分操作を効果的に管理でき、それにより時間が短縮されます。

•

プロセスの結果を管理しチェックできます。

すべての操作が実装されるソース・ディレクトリにmakefileという名前の記述子ファイルが存在する必要があります(makefileはプロジェクトの初期化中にソース・ディレクトリに準備されます)。

次の2つの項でmake構成およびmakeによるカタロガ機能の使用方法について説明します。

make構成

version.mk

$PARAMのversion.mk構成ファイルを使用して、makeユーティリティで必要な変数およびパラメータを設定します。

このファイルでは、各タイプのコンポーネントがインストールされる場所とその拡張機能、使用される様々なツールのバージョンを指定します。このファイルにはログ・ファイルの編成方法も記述されます。

リスト1-8 Simple Applicationのversion.mkからの抽出

Root = ${PROJECT}

#

# Define directory Project

#

Find_Jcl = JCL

Find_Prg = BATCH

Find_Tpr = CICS

Find_Spg =

Find_Map = MAP

SCHEMAS = AV

…

#Logs organisation

#

LOGDIR := $(LOGS)

CATALDIR := $(LOGS)/catalog

PARSEDIR := $(LOGS)/parse

TRADJCLDIR := $(LOGS)/trans-jcl

TRADDIR := $(LOGS)/trans-cbl

DATADIR := $(LOGS)/data

…

MakeFile

makefileの内容は実行するタスクの要約です。

•

version.mkを含めます

•

主な変数が設定されているかどうかを制御します。

•

変数の値を収集し、処理に必要なリストを作成します。

•

ターゲットを実装します。

Simple Applicationとともに提供されるmakefileは自動的にドキュメント化されます。

解析

すべてのプログラムの解析

$SOURCEディレクトリから次のコマンドを実行します。

> make pob

ログ・ファイルが$LOGS/parseに生成されます

解析の必要性のチェック

> make pob VERIF=TRUE

Check: Parse of BATCH/PGMMB02.cbl Need Process.. To obtain BATCH/pob/PGMMB02.cbl.pob

1つのプログラムの解析

サンプル: プログラムBATCH/PGMMB02.cblの解析

> make BATCH/pob/PGMMB02.cbl.pob

ログ・ファイルが$LOGS/parseに生成されます

カタログ化

カタログ化を起動するには次を使用します。

make catalog

ログ・ファイルが$LOGS/catalogに生成されます

Makeの高度な使用

ターゲットを追加または更新する場合

Makefileを更新して、ターゲットを追加または既存のターゲットを更新できます。

たとえば、独自のスクリプト(report.sh)を作成して、基本のカタログ化レポートを基にしてカスタマイズしたレポートを生成する場合、そのスクリプトは$TOOLSディレクトリに置きます。

次のようにMakefileを変更できます。

•

新しいターゲットを追加して新しいスクリプトを実行するには

Reporting:

@${TOOLS}/report.sh

•

既存のカタログ・ターゲットを更新するには

catalog:

@$(REAL_CMD) ${REFINEDIR}/refine r4z-catalog -v $(CATALOG) -s $(SYSTEM) $(LOG_FILE_FLAGS_CAT)

@make reporting

カスタマイズされたレポートは各カタログ化の実行後に自動的に更新されます。

Makeターゲットのデバッグ

構成の不足が原因でmakeによるコマンドが正常に動作しないことがあります。

次の手順を実行します。

1.

現在の操作を妨げないように、使用したmakefileをデバッグ・コピー(makfile.debug)にコピーします。

2.

REAL_CMDをCOMMENTに変更してmakefile.debugを変更します

catalog:

@$(COMMENT) ${REFINEDIR}/refine r4z-catalog -v $(CATALOG) -s $(SYSTEM) $(LOG_FILE_FLAGS_CAT)

オプションVERIF=TRUEを指定してコマンドを使用

> make catalog VERIF=TRUE -f makefile.debug

すべての変数の置換後、実行するコマンドが出力されます。

POBリポジトリを消去

変換

•

ファイルからファイルへの移行プロセス

•

ファイルからOracleへの移行プロセス

•

ファイルからDb2/luw (udb)への移行プロセス

•

DB2からOracleへの移行プロセス

ファイルからファイルへの移行プロセス

データ・ファイルの移行は次の項で説明しています。

•

ファイル編成

•

プロセスの初期化

•

環境の準備

•

コンポーネントの生成

ファイル編成

z/OSソース・プラットフォームからターゲット・プラットフォームに移行するとき、VSAMが関係する場合は、ファイルを保持するかデータをOracle表に移行するかをまず確認します。

Tuxedo ART Workbench File-to-Fileコンバータは、ソース・プラットフォームの形式(シーケンシャル、相対または索引付きファイル)をターゲット・プラットフォームで保持するファイルに使用されます。ターゲット・プラットフォームで、これらのファイルはソース・プラットフォームでの編成に相当するターゲットCOBOL (Micro Focus COBOL/COBOL-IT)ファイル編成を使用します。

表1-14は、z/OSにより処理されるファイル編成をリストし、ターゲット・プラットフォームで提案される編成を示します。

表1-14 z/OSからUNIXファイル編成へ

z/OSソース・ファイル

UNIX ISAMターゲット・ファイル

QSAM

ライン・シーケンシャルISAM

VSAM KSDS

索引付きISAM

VSAM RRDS

相対ISAM

VSAM ESDS

ライン・シーケンシャルISAM

注意:

z/OSファイルのISAM UNIXファイルへの変換には、COBOLアプリケーション・プログラムまたはJCLの変換への直接リンクがありません。

PDSファイル編成

PDSの一部であるファイルは、METAW00.NIV1.ESSAI(FIC)などの物理ファイル名自体で識別されます。

この場合は、PDSに合せて調整されたアンロード用JCLが生成されます。前述の表に示したソースとターゲットのファイル編成が適用されます。

GDGファイル編成

世代別データ・グループ(GDG)ファイルは、その特殊性(アンロードおよび再ロードするGDGアーカイブの数)を維持するために、アンロード・コンポーネントおよび再ロード・コンポーネントによって特別に処理されます。その後、世代ファイルとしてOracle Tuxedo Application Runtime Batchで管理されます(詳細は、『Oracle Tuxedo Application Runtime for Batchリファレンス・ガイド』を参照してください)。ターゲット・プラットフォームでは、これらのファイルはLINE SEQUENTIAL編成になります。

移行プロセス手順

この章で詳細が説明されている、ファイルからファイルへの移行プロセスの原則的な手順は次のとおりです。

1.

移行するファイルの全体的なリストを作成します。

2.

Oracle表に変換しないファイルをリストします。

3.

それらの各ファイルに対してファイル記述を作成します。

4.

必要な場合は識別ルールのリストを作成します。

5.

コンポーネントの生成に使用する環境を準備します。

6.

Tuxedo ART Workbenchを使用して、次の手順で使用するコンポーネントを生成します。

7.

ソース・プラットフォームからデータをアンロードします。

8.

データをターゲット・プラットフォームに転送します。

9.

データをトランスコードして再ロードします。

10.

結果を確認します。

プロセスの初期化

この項ではファイルの移行の開始前に実行する手順について説明します。

要件

z/OSファイルのUNIX/Linuxへの移行は、Tuxedo ART Workbenchカタロガの結果に依存します(詳細は、「分析」を参照)。これはCOBOLコンポーネントまたはJCLコンポーネントの変換に影響を与えません。

移行するファイルのリスト

最初のタスクは、移行するファイルをすべてリストすることで、これにはOracle表から取得されない処理ユニットへの永続ファイル入力などが含まれます。

ファイルの記述および同じ構造のファイルの管理

移行の候補となる各ファイルについて、その構造をCOBOL形式で記述する必要があります。この記述はTuxedo ART Workbench COBOLコンバータによってCOBOLコピーで使用され、「COBOL記述」に記載されている制限の対象になります。

移行ファイル・リストが一度作成されたら、同一構造のファイルをパージすることができます。これは、データのトランスコードと再ロードに必要なプログラム数を減らして、ファイルを移行する際の作業を減らすためです。

パージしたファイル・リストを使用し、最後のタスクとして次のファイルを作成します。

•

Datamap-<データマップ名>.re

•

mapper-<マッパー名>.re

注意:

populate.shユーティリティ(REFINEDIR/scripts/file/populate.shにある)を使用して、これら2つの構成ファイルを自動生成できます。詳細は、REFINEDIR/scripts/file/README.txtを参照してください。

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

注意:

ソース・プラットフォームのコピー・ブックにファイルの詳細が記述されている場合は、そのコピーをTuxedo ART Workbenchで直接使用および宣言できます。

COBOL記述の形式

COBOL記述形式は次のルールに従う必要があります。

•

1つのレベル01のみ。

•

語句FILLERは使用できません。

•

フィールド名は一意であることが必要です。

•

予約語がいくつかあります。リストは、『Tuxedo ART Workbenchリファレンス・ガイド』の付録を参照してください。

•

記述は列1から開始します。COBOLシーケンス番号を前に付けないでください。

•

コメントを挿入するには、列1に*を入力します。

•

フィールドのレベル番号は列2から開始できます。

例

列

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

..

*

D

E

S

C

R

I

P

T

I

O

N

O

F

F

I

L

E

X

X

X

X

0

1

F

V

1

4

.

0

5

F

V

1

4

x

1

P

I

C

X

.

COBOL記述と関連する識別ルール

COBOL記述では、同じメモリー・フィールドを記述する方法がいくつかあり、これは異なる構造と記述でオブジェクトを同じ場所に格納することを意味します。

同じメモリー・フィールドに異なる記述のオブジェクトを含めて、ファイルを読み取ることができるので、このデータ領域を適切に解釈するために、使用する記述を決定するメカニズムが必要です。

ある条件に従い、一般的にレコードの1つまたは複数のフィールドの内容により、再定義領域の読取りに使用する記述を決定(識別)できるルールが必要です。

Tuxedo ART Workbenchでは、このルールは識別ルールと呼ばれます。

識別ルールのないCOBOL記述内での再定義には、ファイルのトランスコード時に重大なリスクが存在します。そのため、等価でない再定義済フィールドは識別ルールをリクエストします。また、等価な再定義(テクニカル再定義と呼ばれる)は、COBOL記述内で消去の対象となる必要があります(次の例を参照)。

識別ルールはファイルごとに用意し、相違点と識別される領域を明確に指定する必要があります。ファイルに関しては、ファイル記述の外部のフィールドを参照することはできません。

次の記述は、Tuxedo ART Workbenchで必要なCOPYのサンプルです。

リスト1-9 COBOL 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).

識別ルールは次の形式で作成されます。

リスト1-10 COBOL COPY識別ルール

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)の順序は重要ではありません。

COBOL記述のコピー名: <COPY name>.cpy

再定義の例

等価でない再定義

リスト1-11 等価でない再定義の例

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プラットフォームに移行するのに必要です。

リスト1-12 関連する識別ルール

Field FV15-ZNPCP3

Rule if FV15-MTMGFA = 12 then FV15-ZNPCP3

elseif FV15-MTMGFA = 08 and FV15-NMASMG = "KC " then FV15-ZNB2T

テクニカル再定義と呼ばれる等価な再定義

リスト1-13 テクニカル再定義の初期状況

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

リスト1-14 テクニカル再定義の潜在的に予想される結果

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英数文字列(バイナリ、パックまたは符号付数字フィールドを除く)に相当します。この種の構造は識別ルールの実装を必要としません。

環境の準備

この項では、データ・ファイルを移行するのに使用されるコンポーネントの生成前に実行するタスクについて説明します。

環境変数の初期化

Tuxedo ART Workbenchの実行前に次の環境変数を設定します。

•

export TMPPROJECT=$HOME/tmp

- プロセスにより生成される一時オブジェクトを格納する場所。

このディレクトリは定期的にクリーンアップする必要があります。

•

export PARAM=$HOME/param

- 構成ファイルの場所。

構成ファイルの実装

次を使用して記述された3つのファイルは、Tuxedo ART Workbenchファイル構造に置く必要があります。

•

$PARAM:

•

db-param.cfg

•

$PARAM/file:

•

Datamap-<configuration name>.re

•

mapper-<configuration name>.re。

File-to-File変換ではこれらのファイルを自分で作成する必要があります。

注意:

データマップおよびマッパー構成ファイルは同じ構成名を使用する必要があります。

その他の2つの構成ファイル

•

file-templates.txt

•

file-move-assignation.pgm

これらのファイルは、Tuxedo ART Workbenchのインストール時にファイル構造に自動的に配置されます。これらのファイルの特定のバージョンが特定のz/OSファイルに必要な場合は、$PARAM/fileファイル構造に配置されます。

ファイルの構成

次の例は3つのファイル、つまり2つのQSAMファイルと1つのVSAM KSDSファイルの構成を示します。これらのファイルを実装するための識別ルールはありません。

データベース・パラメータ・ファイル(db-param.cfg)

db-param.cfgファイルで、変更が必要となる可能性のあるパラメータはtarget_osパラメータのみです。

リスト1-15 db-param.cfgの例

# 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 parameter

target_cobol:cobol_mf

hexa-map-file:tr-hexa.map

#

# 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.

必須パラメータ

target_os:unix

ターゲット・オペレーティング・システムの名前。

オプションのパラメータ

target_cobol:cobol_mf

COBOL言語の名前。許容値はcobol_mf (デフォルト値)およびcobol_itです。

この例では、言語はMicro Focus COBOLです。

hexa-map-file:tr-hexa.map

EBCDIC (z/OSのコード・セット)とASCII (Linux/UNIXのコード・セット) 16進数値間のマッピング表ファイルを指定します。hexa-map-fileを指定しない場合は、警告がロギングされます。

データマップ・パラメータ・ファイル(Datamap-<configuration name>.re)

移行する各z/OSファイルをリストする必要があります。

次のパラメータを設定する必要があります。

表1-15 データマップ・パラメータ

パラメータ

例での値

設定元

configuration name

FTFIL001

(data map FTFIL001-map)

ユーザーが自由に選択します。

system name

PROJ001

(system cat::PROJ001)

システム記述ファイルでのカタログ化中に決定されます。

file name

PJ01DDD.DO.QSAM.KBCOI001

z/OS物理ファイル名。

Organization

順次

ソースの編成

注意:

使用される様々なパラメータの説明は、『Oracle Tuxedo Application Workbenchリファレンス・ガイド』のFile To Fileコンバータに関する項を参照してください。

次の例では、最初の2つのファイルはQSAMファイルであるため編成は常にシーケンシャルです。PJ01AAA.SS.VSAM.CUSTOMERファイルはVSAM KSDSファイルであるため編成は索引付きです。パラメータkeys offset 1 bytes length 6 bytes primaryはキーを記述しています。この例では、キーは6バイトの長さでポジション1から開始します。

リスト1-16 データマップ・ファイルの例: Datamap-FTFIL001.re

%% 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

マッピング・パラメータ・ファイル(mapper-<configuration name>.re)

データマップ構成ファイルに含まれている、移行する各z/OSファイルをリストする必要があります。

次のパラメータを設定する必要があります。

表1-16 マッピング・パラメータ

パラメータ

例での値

設定元

configuration name

FTFIL001

(ufas mapper FTFIL001)

データマップ構成ファイルで使用される名前と同一です。

file name

PJ01DDD.DO.QSAM.KBCOI001

データマップ・ファイルで使用される名前です。

include

include "#VAR:RECS-SOURCE#/BCOAC01E.cpy"

生成中に、文字列#VAR:RECS-SOURCE#はコピー・ファイルが置かれたディレクトリの名前$PARAM/file/recs-sourceで置き換えられます

コピー・ファイルBCOAC01E.cpyの名前はファイルの作成時にユーザーが自由に選択します。

map record

map record REC-ENTREE defined in "#VAR:RECS-SOURCE#/BCOAC01E.cpy"

REC-ENTREEはコピー・ファイルのレベル01フィールド名に相当します。

logical name

論理名FQSAM01

ユーザーが選択します(最大8文字)。この名前は、Tuxedo ART Workbenchの様々なツールによって作成されるオブジェクト(COBOL、JCL)に名前を付けるために使用されます。

注意:

論理名にハイフン(-)は使用できません。

converter name

converter name FQSAM01

論理名と同じ名前および用途です。

注意:

使用される様々なパラメータの説明は、『Oracle Tuxedo Application Workbenchリファレンス・ガイド』のFile To Fileコンバータに関する項を参照してください。

リスト1-17 マッパー・ファイルの例: mapper-FTFIL001.re

%% 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"

論理名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-<configuration name>.reファイルに記述したコピー・ファイルを$PARAM/file/recs-sourceディレクトリに置く必要があります。

ソース・プラットフォームからのCOBOLコピーブックを使用してファイルを記述する場合(「COBOL記述」の注意を参照)、これが、前述の"COPY/ODCSF0B.cpy"の例のように、マッピング・パラメータ・ファイルで直接使用されるコピーブックの場所です。

コンポーネントの生成

z/OSファイルの移行に使用するコンポーネントを生成するには、Tuxedo ART Workbenchではfile.shコマンドを使用します。この項ではこのコマンドについて説明します。

file.sh

名前

file.sh - z/OS移行コンポーネントを生成します。

形式

file.sh [ [-g] [-m] [-i <installation directory>] <configuration name> | -s <installation directory> (<configuration name>,...) ]

説明

file.shでは、Tuxedo ART Workbenchを使用して、z/OSファイルの移行に使用するコンポーネントを生成します。

オプション

-g <configuration name>

生成オプション。アンロードおよびロード・コンポーネントは、構成ファイルにより提供された情報を使用して$TMPPROJECTに生成されます。

-m <configuration name>

変更オプション。生成されたシェル・スクリプトを実行可能にします。COBOLプログラムは、ターゲットCOBOLの固定形式に合うように調整されます。生成されたソース・ファイルを変更するシェル・スクリプトが存在する場合は実行されます。

-i <installation directory><configuration name>

インストール・オプション。コンポーネントをインストール・ディレクトリに配置します。この操作はfile-move-assignation.pgmファイルにある情報を使用します。

-s

attributes句がLOGICAL_MODULE_ONLYに設定されている場合を除き、ファイルからファイルへの移行には適用できません。

この場合、このオプションにより、COBOLコンバータで使用する構成ファイルおよびDMLユーティリティの生成が可能になります。すべての構成ファイルは$PARAM/dynamic-configに、DMLファイルは<trf>/DMLディレクトリに作成されます。

例

file.sh -gmi $HOME/trf FTFIL001

生成されたファイルの場所

-i $HOME/trfオプションで生成されるアンロード・コンポーネントおよびロード・コンポーネントは、次の場所に配置されます。

表1-17 コンポーネントの場所

場所

内容

$HOME/trf/unload/file/<configuration name>

各アンロードに使用されるJCLは各<configuration name>に対して生成されます。

$HOME/trf/reload/file/<configuration name>

各ロードに使用されるプログラムおよびKSHは各<configuration name>に対して生成されます。

$TMPPROJECT/outputs

生成ログ・ファイルMapper-log-<configuration name>は問題の解決に使用できます。

生成されたコンポーネントの変更

生成されたコンポーネントはプロジェクトの固有のスクリプトを使用して変更することができます。これらのスクリプト(sed、awk、perlなど)は次の場所に置く必要があります。

$PARAM/file/file-modif-source.sh

このファイルが存在する場合、生成プロセスの最後に自動的に実行されます。これは、引数として<configuration name>を使用して呼び出されます。

Makeユーティリティの使用

Makeはターゲット(ファイルまたはアクション)の構成を自動化および最適化することを目的としたUNIXユーティリティです。

すべての操作が実装されるソース・ディレクトリにmakefileという名前の記述子ファイルが存在する必要があります(makefileはプロジェクトの初期化中にソース・ディレクトリに準備されます)。

次の2つの項では、makefileの構成と、makefileを使用したTuxedo ART Workbench File-To-Fileコンバータ機能の使用方法について説明します。

Makeファイルの構成

version.mk

$PARAMのversion.mk構成ファイルを使用して、makeユーティリティで必要な変数およびパラメータを設定します。

version.mkには、各種コンポーネントがインストールされる場所とその拡張機能、および使用される様々なツールのバージョンを指定します。このファイルにはログ・ファイルの構成方法も記述されます。

次の一般的な変数を、version.mkファイルでの移行プロセスの最初に設定する必要があります。

•

ROOT_PROJECT

•

DIR_TRADDATA

•

TOOLS_DATA

•

LOGDIR

また、FILE_SCHEMAS変数はファイルの移行に固有で、処理する様々な構成を示します。

この構成はMakeファイルの使用の前に完了する必要があります。

makefileの内容

makefileの内容は実行するタスクの要約です。

•

version.mkを含めます

•

主な変数が設定されているかどうかを制御します。

•

変数の値を収集し、処理に必要なリストを作成します。

•

ターゲットを実装します。

makefileおよびversion.mkファイルはTuxedo ART Workbench Simple Applicationとともに提供されます。

Tuxedo ART Workbench File-To-FileコンバータでのMakefileの使用

make FileConvertコマンドを使用して、Tuxedo ART Workbench File-To-Fileコンバータを起動できます。これによりz/OSファイルのUNIX/Linuxターゲット・プラットフォームへの移行に必要なコンポーネントを生成できます。

makefileはFILE_SCHEMAS変数に含まれるすべての構成に対し、-g、-mおよび-iオプションを指定してfile.shツールを起動できます。

ファイルからOracleへの移行プロセス

•

ファイル編成

•

プロセスの初期化

•

実装のルールのリエンジニアリング

•

環境の準備

•

コンポーネントの生成

ファイル編成

VSAMファイルをソース・プラットフォームからOracle UNIXターゲット・プラットフォームに移行するとき、VSAMが関係する場合は、ファイルを保持するかデータをOracle表に移行するかをまず確認します。

z/OSで処理されるVSAM RRDS、ESDSおよびKSDSのファイル編成は、Tuxedo ART Workbenchを使用してOracleデータベースに移行できます。

Tuxedo ART Workbench File-to-Oracleコンバータは、Oracle表に変換されるこれらのファイルで使用されます。ファイル形式が維持されるファイルについては、「File-to-Fileで生成されたコンバータ・プログラムの実行」を参照してください。

移行プロセス手順

この章で詳細が説明されている、ファイルからOracleへの移行プロセスの原則的な手順は次のとおりです。

1.

移行するファイルの全体的なリストを作成します。

2.

Oracle表に変換するファイルをリストします。

3.

これらの各ファイルについて、必要な場合は識別ルールのリストを作成します。

4.

コンポーネントの生成に使用する環境を準備します。

5.

Tuxedo ART Workbenchを使用して、次の手順で使用するコンポーネントを生成します。

6.

ソース・プラットフォームからデータをアンロードします。

7.

データをターゲット・プラットフォームに転送します。

8.

データをトランスコードして再ロードします。

9.

結果を確認します。

10.

アクセス・ルーチンと生成されたユーティリティをコンパイルします。

11.

Oracleデータベースを作成します。

その他のOracle Tuxedo Application Rehosting Workbenchツールとの対話

VSAMファイルのデータのOracle表への移行は、Tuxedo ART Workbenchカタロガの結果に依存します(詳細は、「分析」を参照)。ファイルからOracleへの移行はCOBOLおよびJCLの変換に影響を与えるので、COBOLプログラムの変換作業の開始前に完了する必要があります。

プロセスの初期化

この項ではVSAMファイルのOracle表への移行の開始前に実行する手順について説明します。

移行するファイルのリスト

最初のタスクは、移行するすべてのVSAMファイルをリストし(File-to-Fileコンバータと併用して)、次にOracle表に変換する必要のあるこれらのファイルを識別することです。たとえば、レコード・レベルでロックが必要な、後でOracleまたはファイル経由で使用される永続ファイルなどです。

ファイルの記述および同じ構造のファイルの管理

移行の候補となる各ファイルについて、その構造をCOBOL形式で記述する必要があります。この記述はTuxedo ART Workbench COBOLコンバータによってCOBOLコピーで使用され、「COBOL記述」に記載されている制限の対象になります。

移行ファイル・リストが一度作成されたら、同一構造のファイルをパージすることができます。これは、データのトランスコードと再ロードに必要なプログラム数を減らして、ファイルを移行する際の作業を減らすためです。

パージされたファイルのリストから、最後のタスクは次のファイルのビルドからなります。

•

Datamap-<configuration name>.re

•

mapper-<構成名>.re

注意:

populate.shユーティリティ(REFINEDIR/scripts/file/populate.shにある)を使用して、これら2つの構成ファイルを自動生成できます。詳細は、REFINEDIR/scripts/file/README.txtを参照してください。

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

注意:

ソース・プラットフォームのコピー・ブックにファイルの詳細が記述されている場合は、そのファイルをTuxedo ART Workbenchで直接使用および宣言できます。

COBOL記述の形式

COBOL記述形式は次のルールに従う必要があります。

•

1つのレベル01のみ。

•

語句FILLERは使用できません。

•

フィールド名は一意であることが必要です。

•

予約語がいくつかあります。リストは、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』の付録を参照してください。

•

先行するシーケンス番号はなく、記述は列1から開始する必要があります。

•

コメントを挿入するには、列1に*を入力します。

•

フィールドのレベル番号は列2から開始できます。

表1-18は、COBOL記述の形式の例を示しています。

表1-18 COBOL記述の形式

列

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

.

*

D

E

S

C

R

I

P

T

I

O

N

O

F

F

I

L

E

X

X

X

X

0

1

F

V

1

4

.

0

5

F

V

1

4

x

1

P

I

C

X

.

COBOL記述と関連する識別ルール

COBOL記述では、同じメモリー・フィールドを記述する方法がいくつかあり、これは異なる構造と記述でオブジェクトを同じ場所に格納することを意味します。

同じメモリー・フィールドに異なる記述のオブジェクトを含めて、ファイルを読み取ることができるので、このデータ領域を適切に解釈するために、使用する記述を決定するメカニズムが必要です。

ある条件に従い、一般的にレコードの1つまたは複数のフィールドの内容により、再定義領域の読取りに使用する記述を決定(識別)できるルールが必要です。

Tuxedo ART Workbenchでは、このルールは識別ルールと呼ばれます。

識別ルールのないCOBOL記述内での再定義には、ファイルのトランスコード時に重大なリスクが存在します。そのため、等価でない再定義済フィールドは識別ルールをリクエストします。また、等価な再定義(テクニカル再定義と呼ばれる)は、COBOL記述内で消去の対象となる必要があります(次の例を参照)。

識別ルールはファイルごとに用意し、相違点と識別される領域を明確に指定する必要があります。ファイルに関しては、ファイル記述の外部のフィールドを参照することはできません。

次の記述は、Tuxedo ART Workbenchで必要なCOPYのサンプルです。

リスト1-18 COBOL 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).

識別ルールは次の形式で作成されます。

リスト1-19 COBOL COPY識別ルール

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)の順序は重要ではありません。

COBOL記述のコピー名: <COPY name>.cpy

再定義の例

等価でない再定義

リスト1-20 等価でない再定義の例

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プラットフォームに移行するのに必要です。

リスト1-21 関連する識別ルール

Field FV15-ZNPCP3

Rule if FV15-MTMGFA = 12 then FV15-ZNPCP3

elseif FV15-MTMGFA = 08 and FV15-NMASMG = "KC " then FV15-ZNB2T

テクニカル再定義と呼ばれる等価な再定義

リスト1-22 テクニカル再定義の初期状況

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

リスト1-23 テクニカル再定義の潜在的に予想される結果

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英数文字列(バイナリ、パックまたは符号付数字フィールドを除く)に相当します。この種の構造は識別ルールの実装を必要としません。

実装のルールのリエンジニアリング

この項では、VSAMファイルからOracleデータベースにデータを移行するときに、Tuxedo ART Workbenchにより適用されるリエンジニアリング・ルールについて説明します。

適用する移行ルール

•

CICSで使用される各VSAMファイルがOracle表になります。

•

各表の名前は、table name句を使用してmapper-<configuration name>.reファイルに規定されます。

•

ファイルのコピー記述に含まれる基本的なフィールド名はそれぞれOracle表の列名になります。ハイフン(-)はアンダースコア(_)文字に置き換えられます。

•

シーケンシャルVSAMファイル(VSAM ESDS)の場合:

Tuxedo ART Workbenchによって技術列*_SEQ_NUM NUMBER(8)が追加されます。

この列は新しい行が表に追加されるたびに増加し、表の主キーになります。

•

相対VSAMファイル(VSAM RRDS)の場合:

Tuxedo ART Workbenchによって技術列*_RELATIVE_NUMが追加されます。

列のサイズはデータマップのパラメータ・ファイルで提供される情報から推測され、この列が表の主キーになります。

この列は次のようになります。

•

表への順次書込みが行われると増加し、相対キーはゼロです。

•

相対キーがゼロではないとき相対キーを含みます。

•

索引付きVSAMファイル(VSAM KSDS)の場合:

Tuxedo ART Workbenchでは、重複キーを受け入れないかぎり、技術列が追加されず、VSAMファイルの主キーが表の主キーになります。

Picture句に適用されるルール

データをVSAMファイルからOracle表に移行するときに、次のルールがCOBOL Picture句に適用されます。

表1-19 Picture句のリエンジニアリング

COBOL Picture

Oracleの形式

PIC 9(length)

PIC S9(length)

PIC 9(length) COMP-3

PIC S9(length) COMP-3

NUMBER(length)

PIC 9(prec,scale)

PIC S9(prec,scale)

PIC 9(prec,scale) COMP-3

PIC S9(prec,scale) COMP-3

NUMBER(prec+scale, scale)

PIC S9(length) BINARY

PIC S9(length) COMP

PIC S9(length) COMP-4

NUMBER(real_binary_length)

サンプル:

PIC S9(4) BINARYはNUMBER(5)として移行されます

COMP-1またはCOMP-2

DATATYPE_DOUBLE

PIC X(…)

長さ<= 2000の場合はCHAR

長さ> 2000の場合はVARCHAR2

注意:

パラメータfile:char_limit_until_varcharがdb-param.cfgファイルに設定されている場合、前述のルールよりも優先されます。

OccursおよびRedefines句に適用されるルール

識別ルールが適用されるOCCURSおよびREDEFINES句の場合、次の3つのリエンジニアリングの可能性が提案されます。

•

サブ表の作成

•

再定義: 各記述は1つのサブ表に関連付けられます(1つの記述に対して1つのサブ表)。

•

繰返し: データが対応する要素の配列を参照するテクニカル列を含む、1つのサブ表が作成されます。

•

不透明なフィールドの作成

•

再定義: すべての記述がCHAR型またはVARCHAR2型のopaqueフィールドに格納されます。

•

繰返し: すべての要素がCHAR型またはVARCHAR2型のopaqueフィールドに格納されます。

•

拡張記述

•

再定義: コピー・ファイルで記述されたすべてのフィールドが、Oracle表の列として作成されます。

•

繰返し: 再定義領域のフィールドの各要素が、Oracle表の列として作成されます。1つの列がOCCURS句の各要素に対応します。

VSAMファイルのOracle表への移行の例

次の例では、ODCSFOBに記述された索引付きVSAMファイルは主キーとしてVS-CUSTIDENTフィールドを使用します。

リスト1-24 VSAMコピー記述の例

* ------------------------------------------------------------

* Customer record description

* -Record length : 266

* ------------------------------------------------------------

01 VS-ODCSF0-RECORD.

05 VS-CUSTIDENT PIC 9(006).

05 VS-CUSTLNAME PIC X(030).

05 VS-CUSTFNAME PIC X(020).

05 VS-CUSTADDRS PIC X(030).

05 VS-CUSTCITY PIC X(020).

05 VS-CUSTSTATE PIC X(002).

05 VS-CUSTBDATE PIC 9(008).

05 VS-CUSTBDATE-G REDEFINES VS-CUSTBDATE.

10 VS-CUSTBDATE-CC PIC 9(002).

10 VS-CUSTBDATE-YY PIC 9(002).

10 VS-CUSTBDATE-MM PIC 9(002).

10 VS-CUSTBDATE-DD PIC 9(002).

05 VS-CUSTEMAIL PIC X(040).

05 VS-CUSTPHONE PIC 9(010).

05 VS-FILLER PIC X(100).

* ------------------------------------------------------------

リスト1-25 VSAMファイルから生成されたOracle表

WHENEVER SQLERROR CONTINUE;

DROP TABLE CUSTOMER CASCADE CONSTRAINTS;

WHENEVER SQLERROR EXIT 3;

CREATE TABLE CUSTOMER (

VS_CUSTIDENT NUMBER(6) NOT NULL,

VS_SEQ_NUM NUMBER(8) NOT NULL,

VS_CUSTLNAME VARCHAR2(30),

VS_CUSTFNAME CHAR (20),

VS_CUSTADDRS VARCHAR2(30),

VS_CUSTCITY CHAR (20),

VS_CUSTSTATE CHAR (2),

VS_CUSTBDATE NUMBER(8),

VS_CUSTEMAIL VARCHAR2(40),

VS_CUSTPHONE NUMBER(10),

VS_FILLER VARCHAR2(100),

CONSTRAINT PK_CUSTOMER PRIMARY KEY (

VS_CUSTIDENT)

CONSTRAINT UK_CUSTOMER UNIQUE (

VS_SEQ_NUM)

);

注意:

コピーブックODCSFOBにはフィールドの再定義VS-CUSTBDATE-G PIC 9(008)が含まれ、これは技術フィールドのため、識別ルールは実装されません。この場合、再定義されたフィールドのみが生成された表VS_CUSTBDATE NUMBER(8)に作成されます。

環境の準備

この項では、データをVSAMファイルからOracle表に移行するのに使用するコンポーネントを生成する前に実行するタスクについて説明します。

環境変数の初期化

Tuxedo ART Workbenchの実行前に次の環境変数を設定します。

•

export TMPPROJECT=$Home/tmp

- プロセスにより生成される一時オブジェクトを格納する場所。

•

export $PARAM=$HOME/param

- 構成ファイルの場所。

構成ファイルの実装

次を使用して記述された3つのファイルは、Tuxedo ART Workbenchファイル構造に置く必要があります。

•

$PARAM:

•

db-param.cfg

•

$PARAM/file:

•

Datamap-<configuration name>.re

•

mapper-<configuration name>.re。

File-To-Oracle変換の場合、Datamap-<configuration name>.reおよびmapper-<configuration name>.reファイルを自分で作成する必要があります。

その他の2つの構成ファイル

•

file-templates.txt

•

file-move-assignation.pgm

これらのファイルは、Tuxedo ART Workbenchのインストール時にファイル構造に自動的に生成されます。これらのファイルの特定のバージョンが特定のz/OSファイルに必要な場合は、$PARAM/fileファイル構造に配置されます。

ファイルの構成

データベース・パラメータ・ファイル(db-param.cfg)

db-param.cfgファイルの場合、ターゲットおよびファイル・パラメータのみが調整される必要があります。

リスト1-26 db-param.cfgの例

# 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 parameter

target_cobol:cobol_mf

hexa-map-file:tr-hexa.map

#

# 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.

必須パラメータ

•

target_rdbms_name: oracle

ターゲットRDBMSの名前。

•

target_rdbms_version:11

ターゲットRDBMSのバージョン。

•

target_os:unix

ターゲット・オペレーティング・システムの名前。

•

file:char_limit_until_varchar:29

ORACLE VARCHARデータ型に変換される前のCOBOL英数字(PIC X)フィールドの最大長を示します。

この例では、29文字よりも長いフィールドはVARCHARフィールドになり、30文字よりも短いフィールドはCHARフィールドになります。

オプションのパラメータ

target_cobol:cobol_mf

COBOL言語の名前。許容値はcobol_mf (デフォルト値)およびcobol_itです。

この例では、言語はMicro Focus COBOLです。

hexa-map-file:tr-hexa.map

EBCDIC (z/OSのコード・セット)とASCII (Linux/UNIXのコード・セット) 16進数値間のマッピング表ファイルを指定します。hexa-map-fileを指定しない場合は、警告がロギングされます。

データマップ・パラメータ・ファイル(Datamap-<configuration name>.re)

移行するVSAMファイルをリストする必要があります。

次のパラメータを設定する必要があります。

表1-20 データマップ・パラメータ

パラメータ

例での値

設定元

configuration name

STFILEORA

(data map STFILEORA-map)

ユーザーが自由に選択します。

system name

STFILEORA

(system cat::STFILEORA)

システム記述ファイルでのカタログ化中に決定されます。

file name

PJ01AAA.SS.VSAM.CUSTOMER

z/OS物理ファイル名。

Organization

Indexed

ソースの編成

注意:

使用される様々なパラメータの説明は、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』のFile-To-Fileコンバータに関する項を参照してください。

PJ01AAA.SS.VSAM.CUSTOMERファイルはVSAM KSDSファイルのため、編成は索引付きです。パラメータkeys offset 1 bytes length 6 bytes primaryはキーを記述しています。この例では、キーは6バイトの長さでポジション1から開始します。

リスト1-27 データマップ・ファイルの例: Datamap-STFILEORA.re

%% Lines beginning with "%%" are ignored

data map STFILEORA-map system cat::STFILEORA

%%

%% Datamap File PJ01AAA.SS.VSAM.CUSTOMER

%%

file PJ01AAA.SS.VSAM.CUSTOMER

organization Indexed

keys offset 1 bytes length 6 bytes primary

マッピング・パラメータ・ファイル(mapper-<configuration name>.re)

データマップ構成ファイルに含まれている、移行する各z/OSファイルをリストする必要があります。

ファイルのパラメータおよびそのオプションは、Oracle表に変換するVSAMファイルごとに含まれる必要があります。次のパラメータを設定する必要があります。

表1-21 マッピング・パラメータ

パラメータ

例での値

設定元

configuration name

STFILEORA

(ufas mapper STFILEORA)

データマップ構成ファイルで使用される名前と一貫性があります。

file name

PJ01AAA.SS.VSAM.CUSTOMER

データマップ・ファイルで使用される名前です。

include

include "COPY/ODCSF0B.cpy"

コピー・ファイルBCOAC01E.cpyの名前およびパスはファイルの作成時にユーザーが自由に選択します。

table name

table name CUSTOMER

作成されるOracle表の名前を指定します。

map record

map record VS-ODCSF0-RECORD defined in "COPY/ODCSF0B.cpy"

VS-ODCSF0-RECORDはコピー・ファイルのレベル01フィールド名に相当します。

logical name

logical name ODCSF0B

ユーザーが選択します(最大8文字)。この名前は、Tuxedo ART Workbenchの様々なツールによって作成されるオブジェクト(COBOL、JCL)に名前を付けるために使用されます。

converter name

converter name ODCSF0B

論理名と同じ名前および用途です。

注意:

使用される様々なパラメータの説明は、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』のFile-To-Fileコンバータに関する項を参照してください。

リスト1-28 マッパー・ファイルの例: mapper-STFILEORA.re

%% Lines beginning with "%%" are ignored

ufas mapper STFILEORA

%%

%% Desc file PJ01AAA.SS.VSAM.CUSTOMER

%%

file PJ01AAA.SS.VSAM.CUSTOMER transferred converted

table name CUSTOMER

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

attributes LOGICAL_MODULE_IN_ADDITION

コピー・ファイルのインストール

COBOL記述ファイルを準備したら、mapper-<configuration name>.reファイルに記述したコピー・ファイルを$PARAM/file/recs-sourceディレクトリに置く必要があります。

ソース・プラットフォームからのCOBOLコピーブックを使用してファイルを記述する場合(「COBOL記述」の注意を参照)、これが、前述の"COPY/ODCSF0B.cpy"の例のように、マッピング・パラメータ・ファイルで直接使用されるコピーブックの場所です。

コンポーネントの生成

VSAMファイルからOracle表へのデータの移行に使用されるコンポーネントを生成するには、Tuxedo ART Workbenchではfile.shコマンドを使用します。この項ではこのコマンドについて説明します。

file.sh

名前

file.sh - z/OS移行コンポーネントを生成します。

形式

file.sh [ [-g] [-m] [-i <installation directory>] <configuration name> | -s <installation directory> (<configuration name>,...) ]

説明

file.shでは、Tuxedo ART Workbenchにより、VSAMファイルの移行に使用するコンポーネントを生成します。

オプション

-g <configuration name>

生成オプション。アンロードおよびロード・コンポーネントは、構成ファイルにより提供された情報を使用して$TMPPROJECTに生成されます。

-m <configuration name>

変更オプション。生成されたシェル・スクリプトを実行可能にします。COBOLプログラムは、ターゲットCOBOLの固定形式に合うように調整されます。生成されたソース・ファイルを変更するシェル・スクリプトが存在する場合は実行されます。

-i <installation directory> <configuration name>

インストール・オプション。コンポーネントをインストール・ディレクトリに配置します。この操作はfile-move-assignation.pgmファイルにある情報を使用します。

-s <installation directory> <schema name>,...)

COBOLコンバータで使用する構成ファイルおよびDMLユーティリティの生成を可能にします。すべての構成ファイルは$PARAM/dynamic-configに、DMLファイルは<trf>/DMLディレクトリに作成されます。

例

file.sh -gmi $HOME/trf FTFIL001

Makeユーティリティの使用

Makeはターゲット(ファイルまたはアクション)の構成を自動化および最適化することを目的としたUNIXユーティリティです。

すべての操作が実装されるソース・ディレクトリにmakefileという名前の記述子ファイルが存在する必要があります(makefileはプロジェクトの初期化中にソース・ディレクトリに準備されます)。

次の2つの項では、makefileの構成と、makefileを使用したTuxedo ART Workbench File-To-Fileコンバータ機能の使用方法について説明します。

Makeファイルの構成

version.mk

$PARAMのversion.mk構成ファイルを使用して、makeユーティリティで必要な変数およびパラメータを設定します。

version.mkには、各種コンポーネントがインストールされる場所とその拡張機能、および使用される様々なツールのバージョンを指定します。このファイルにはログ・ファイルの構成方法も記述されます。

次の一般的な変数を、version.mkファイルでの移行プロセスの最初に設定する必要があります。

•

ROOT_PROJECT

•

DIR_TRADDATA

•

TOOLS_DATA

•

LOGDIR

また、FILE_SCHEMAS変数はファイルの移行に固有で、処理する様々な構成を示します。

この構成はMakeファイルの使用の前に完了する必要があります。

makefileの内容

makefileの内容は実行するタスクの要約です。

•

version.mkを含めます

•

主な変数が設定されているかどうかを制御します。

•

変数の値を収集し、処理に必要なリストを作成します。

•

ターゲットを実装します。

makefileおよびversion.mkファイルはTuxedo ART Workbench Simple Applicationとともに提供されます。

Oracle Tuxedo Application Rehosting Workbench File-To-Fileコンバータでのmakefileの使用

make FileConvertコマンドを使用して、Tuxedo ART Workbench File-To-Fileコンバータを起動できます。これによりz/OSファイルのUNIX/Linuxターゲット・プラットフォームへの移行に必要なコンポーネントを生成できます。

makefileはFILE_SCHEMAS変数に含まれるすべての構成に対し、-g、-mおよび-iオプションを指定してfile.shツールを起動できます。

生成されたファイルの場所

-i $HOME/trfオプションで生成されるアンロード・コンポーネントおよびロード・コンポーネントは、次の場所に配置されます。

表1-22 コンポーネントの場所

場所

内容

$HOME/trf/unload/file/<configuration name>

各アンロードに使用されるプログラムおよびJCLは各<configuration name>に対して生成されます。

$HOME/trf/reload/file/<configuration name>

各ロードに使用されるプログラムおよびKSHは各<configuration name>に対して生成されます。

例: loadfile-ODCSF0.ksh RELFILE-ODCSF0.cbl

$TMPPROJECT/outputs

生成ログ・ファイルMapper-log-<configuration name>は問題の解決に使用できます。

$HOME/trf/SQL/file/<schema name>

表の作成用のSQLスクリプトおよび生成されたOracle表に対し様々な技術的操作を実行するために使用されるKornシェル・スクリプトの場所です。

$HOME/trf/DML

COBOLおよびPRO*COBOLアクセス・ルーチンの場所。これらのルーチンは、Oracle表に移行されたVSAMファイルで使用されるアクセス動詞のかわりにCOBOLプログラムによって実行されます。

生成されたコンポーネントの例

この章で使用する例では、次のスクリプトが生成されます。

CUSTOMER表を作成するのに使用されるSQLスクリプトの名前は次のとおりです。

•

ODCSF0B.sql

様々な技術的操作で使用されるスクリプトの名前は次のとおりです。

•

cleantable-ODCSF0B.ksh

•

createtable-ODCSF0B.ksh

•

droptable-ODCSF0B.ksh

•

ifemptytable-ODCSF0B.ksh

•

ifexisttable-ODCSF0B.ksh

9個のCOBOLプログラムが生成されます。これらの使用方法については、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』を参照してください。

•

ASG_ODCSF0B.cbl

•

close_all_files_STFILEORA.cbl

•

dml_locking.cbl

•

init_all_files.cbl

•

UL_ODCSF0B.cbl

•

close_all_files.cbl

•

DL_ODCSF0B.cbl

•

getfileinfo.cbl

•

init_all_files_STFILEORA.cbl

ORACLE CUSTOMER表をアクセスするための1つのPRO*COBOLプログラムが生成されます。

•

RM_ODCSF0B.pco

生成されたコンポーネントの変更

生成されたコンポーネントはプロジェクト固有のスクリプトを使用して変更できます。これらのスクリプト(sed、awk、 perlなど)は次の場所に配置する必要があります。

$PARAM/file/file-modif-source.sh

このファイルが存在する場合、生成プロセスの最後に自動的に実行されます。これは、引数として<configuration name>を使用して呼び出されます。

データ・ファイルの移行は次の項で説明しています。

ファイルからDb2/luw (udb)への移行プロセス

•

ファイル編成

•

プロセスの初期化

•

実装のルールのリエンジニアリング

•

環境の準備

•

コンポーネントの生成

ファイル編成

ソース・プラットフォームからDB2/luw (udb) UNIXターゲット・プラットフォームにVSAMファイルを移行するとき、VSAMが関係する場合は、ファイルを維持するかデータをDB2/luw (udb)表に移行するかをまず確認します。

z/OSで処理されるVSAM RRDS、ESDSおよびKSDSのファイル編成は、Tuxedo ART Workbenchを使用してOracleデータベースに移行できます。

Tuxedo ART Workbench File-To-Fileコンバータは、Oracle表に変換されるこれらのファイルで使用されます。ファイル形式が維持されるファイルについては、『Oracle Tuxedo Application Workbenchリファレンス・ガイド』のFile-to-Fileコンバータに関する項を参照してください。

移行プロセス手順

この章で詳しく説明する、ファイルからDb2/luw (udb)への移行プロセスの原則的な手順は次のとおりです。

1.

移行するファイルの全体的なリストを作成します。

2.

DB2/luw (udb)表に変換するファイルをリストします。

3.

これらの各ファイルについて、必要な場合は識別ルールのリストを作成します。

4.

コンポーネントの生成に使用する環境を準備します。

5.

Tuxedo ART Workbenchを使用して、次の手順で使用するコンポーネントを生成します。

6.

ソース・プラットフォームからデータをアンロードします。

7.

データをターゲット・プラットフォームに転送します。

8.

データをトランスコードして再ロードします。

9.

結果を確認します。

10.

アクセス・ルーチンと生成されたユーティリティをコンパイルします。

11.

Oracleデータベースを作成します。

その他のOracle Tuxedo Application Rehosting Workbenchツールとの対話

VSAMファイルのデータのDB2/Luw(udb)表への移行は、カタロガの結果に依存します。ファイルからDb2/luw (udb)への移行はCOBOLおよびJCLの変換に影響を与えるので、COBOLプログラムの変換作業の開始前に完了する必要があります。

プロセスの初期化

この項では、VSAMファイルのDB2/Luw(udb)表への移行の開始前に実行する手順について説明します。

移行するファイルのリスト

最初のタスクは移行するすべてのVSAMファイルをリストし(File-to-Fileコンバータと併用して)、次にDB2/Luw(udb)表に変換する必要のあるこれらのファイルを識別することです。たとえば、レコード・レベルでロックが必要な、後でDB2/Luwまたはファイル経由で使用される永続ファイルなどです。

ファイルの記述および同じ構造のファイルの管理

移行の候補となる各ファイルについて、その構造をCOBOL形式で記述する必要があります。この記述はTuxedo ART Workbench COBOLコンバータによってCOBOLコピーで使用され、「COBOL記述」に記載されている制限の対象になります。

移行ファイル・リストが一度作成されたら、同一構造のファイルをパージすることができます。これは、データのトランスコードと再ロードに必要なプログラム数を減らして、ファイルを移行する際の作業を減らすためです。

パージされたファイルのリストから、最後のタスクは次のファイルのビルドからなります。

•

Datamap-<configuration name>.re

•

mapper-<構成名>.re

注意:

populate.shユーティリティ(REFINEDIR/scripts/file/populate.shにある)を使用して、これら2つの構成ファイルを自動生成できます。詳細は、REFINEDIR/scripts/file/README.txtを参照してください。

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

注意:

ソース・プラットフォームのコピー・ブックにファイルの詳細が記述されている場合は、そのファイルをTuxedo ART Workbenchで直接使用および宣言できます。

COBOL記述の形式

COBOL記述形式は次のルールに従う必要があります。

•

1つのレベル01のみ。

•

語句FILLERは使用できません。

•

フィールド名は一意であることが必要です。

•

予約語がいくつかあります。リストは、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』の付録を参照してください。

•

先行するシーケンス番号はなく、記述は列1から開始する必要があります。

•

コメントを挿入するには、列1に*を入力します。

•

フィールドのレベル番号は列2から開始できます。

例

列

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

.

*

D

E

S

C

R

I

P

T

I

O

N

O

F

F

I

L

E

X

X

X

X

0

1

F

V

1

4

.

0

5

F

V

1

4

x

1

P

I

C

X

.

COBOL記述と関連する識別ルール

COBOL記述では、同じメモリー・フィールドを記述する方法がいくつかあり、これは異なる構造と記述でオブジェクトを同じ場所に格納することを意味します。

同じメモリー・フィールドに異なる記述のオブジェクトを含めて、ファイルを読み取ることができるので、このデータ領域を適切に解釈するために、使用する記述を決定するメカニズムが必要です。

ある条件に従い、一般的にレコードの1つまたは複数のフィールドの内容により、再定義領域の読取りに使用する記述を決定(識別)できるルールが必要です。Tuxedo ART Workbenchでは、このルールは識別ルールと呼ばれます。

識別ルールのないCOBOL記述内での再定義には、ファイルのトランスコード時に重大なリスクが存在します。そのため、等価でない再定義済フィールドは識別ルールをリクエストします。また、等価な再定義(テクニカル再定義と呼ばれる)は、COBOL記述内で消去の対象となる必要があります(次の例を参照)。

識別ルールはファイルごとに用意し、相違点と識別される領域を明確に指定する必要があります。ファイルに関しては、ファイル記述の外部のフィールドを参照することはできません。

次の記述は、Tuxedo ART Workbenchで必要なCOPYのサンプルです。

リスト1-29 COBOL 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).

識別ルールは次の形式で作成されます。

リスト1-30 COBOL COPY識別ルール

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)の順序は重要ではありません。

COBOL記述のコピー名: <COPY name>.cpy

再定義の例

等価でない再定義

リスト1-31 等価でない再定義の例

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プラットフォームに移行するのに必要です。

リスト1-32 関連する識別ルール

Field FV15-ZNPCP3

Rule if FV15-MTMGFA = 12 then FV15-ZNPCP3

elseif FV15-MTMGFA = 08 and FV15-NMASMG = "KC " then FV15-ZNB2T

テクニカル再定義と呼ばれる等価な再定義

リスト1-33 テクニカル再定義の初期状況

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

リスト1-34 テクニカル再定義の潜在的に予想される結果

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 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.

05 FV1-ZNPCP3.

10 FV1-MTMGFA PIC 9(6)V99.

10 FV1-NMASMG PIC X(25).

10 FV1-FILLER PIC X(12).

10 FV2-COINFA.

15 FV2-ZNALEA PIC 9(2).

15 FV2-NOSCP1 PIC 9(4).

15 FV2- FILLER PIC X(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.

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 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.

05 FV1-ZNPCP3.

10 FV1-MTMGFA PIC 9(6)V99.

10 FV1-NMASMG PIC X(25).

10 FV1-FILLER PIC X(12).

10 FV2-COINFA.

15 FV2-ZNALEA PIC 9(2).

15 FV2-NOSCP1 PIC 9(4).

15 FV2- FILLER PIC X(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).

前述の例では、2つの記述が単純なEBCDIC英数文字列(バイナリ、パックまたは符号付数字フィールドを除く)に相当します。この種の構造は識別ルールの実装を必要としません。

実装のルールのリエンジニアリング

この項では、VSAMファイルからDB2/Luw(udb)データベースにデータを移行するときに、Tuxedo ART Workbenchにより適用されるリエンジニアリング・ルールについて説明します。

適用する移行ルール

•

CICSで使用される各VSAMファイルがDB2/Luw(udb)表になります。

•

各表の名前は、table name句を使用してmapper-<configuration name>.reファイルに規定されます。

•

ファイルのコピー記述に含まれる基本的なフィールド名はそれぞれOracle表の列名になります。ハイフン(-)はアンダースコア(_)文字に置き換えられます。

•

シーケンシャルVSAMファイル(VSAM ESDS)の場合:

Tuxedo ART Workbenchによって技術列*_SEQ_NUM NUMERIC(8)が追加されます。

この列は新しい行が表に追加されるたびに増加し、表の主キーになります。

•

相対VSAMファイル(VSAM RRDS)の場合:

Tuxedo ART Workbenchによって技術列*_RELATIVE_NUMが追加されます。

列のサイズはデータマップのパラメータ・ファイルで提供される情報から推測され、この列が表の主キーになります。

この列は次のようになります。

•

表への順次書込みが行われると増加し、相対キーはゼロです。

•

相対キーがゼロではないとき相対キーを含みます。

•

索引付きVSAMファイル(VSAM KSDS)の場合:

Tuxedo ART Workbenchでは、重複キーを受け入れないかぎり、技術列が追加されず、VSAMファイルの主キーが表の主キーになります。

Picture句に適用されるルール

データをVSAMファイルからOracle表に移行するときに、次のルールがCOBOL Picture句に適用されます

表1-23 Picture句のリエンジニアリング

COBOL Picture

Oracleの形式

PIC 9(length)

PIC S9(length)

PIC 9(length) COMP-3

PIC S9(length) COMP-3

NUMERIC(length)

PIC 9(prec,scale)

PIC S9(prec,scale)

PIC 9(prec,scale) COMP-3

PIC S9(prec,scale) COMP-3

NUMERIC(prec+scale, scale)

PIC S9(length) BINARY

PIC S9(length) COMP

PIC S9(length) COMP-4

NUMERIC(real_binary_length)

例:

PIC S9(4) BINARYはNUMERIC(5)として移行されます

COMP-1

REAL

COMP-2

DOUBLE

PIC X(…)

長さ<= 255の場合はCHAR

長さ> 255の場合VARCHAR

注意:

パラメータfile:char_limit_until_varcharがdb-param.cfgファイルに設定されている場合、前述のルールよりも優先されます。

OccursおよびRedefines句に適用されるルール

識別ルールが適用されるOCCURSおよびREDEFINES句の場合、次の3つのリエンジニアリングの可能性が提案されます。

•

サブ表の作成

•

再定義: 各記述は1つのサブ表に関連付けられます(1つの記述に対して1つのサブ表)。

•

繰返し: データが対応する要素の配列を参照するテクニカル列を含む、1つのサブ表が作成されます。

•

不透明なフィールドの作成

•

再定義: すべての記述がCHAR型またはVARCHAR型のopaqueフィールドに格納されます。

•

繰返し: すべての要素がCHAR型またはVARCHAR型のopaqueフィールドに格納されます。

•

拡張記述

•

再定義: コピー・ファイルで記述されたすべてのフィールドが、Oracle表の列として作成されます。

•

繰返し: 再定義領域のフィールドの各要素が、Oracle表の列として作成されます。1つの列がOCCURS句の各要素に対応します。

VSAMファイルのDB2/luw (udb)表への移行の例

次の例では、ODCSFOBに記述された索引付きVSAMファイルは主キーとしてVS-CUSTIDENTフィールドを使用します。

リスト1-35 VSAMコピー記述の例

* ------------------------------------------------------------

* Customer record description

* -Record length : 266

* ------------------------------------------------------------

01 VS-ODCSF0-RECORD.

05 VS-CUSTIDENT PIC 9(006).

05 VS-CUSTLNAME PIC X(030).

05 VS-CUSTFNAME PIC X(020).

05 VS-CUSTADDRS PIC X(030).

05 VS-CUSTCITY PIC X(020).

05 VS-CUSTSTATE PIC X(002).

05 VS-CUSTBDATE PIC 9(008).

05 VS-CUSTBDATE-G REDEFINES VS-CUSTBDATE.

10 VS-CUSTBDATE-CC PIC 9(002).

10 VS-CUSTBDATE-YY PIC 9(002).

10 VS-CUSTBDATE-MM PIC 9(002).

10 VS-CUSTBDATE-DD PIC 9(002).

05 VS-CUSTEMAIL PIC X(040).

05 VS-CUSTPHONE PIC 9(010).

05 VS-FILLER PIC X(100).

* ------------------------------------------------------------

リスト1-36 VSAMファイルから生成されたOracle表

DROP TABLE CUSTOMER ;

COMMIT ;

CREATE TABLE CUSTOMER (

VS_CUSTIDENT NUMERIC (6) NOT NULL,

VS_CUSTLNAME VARCHAR (30),

VS_CUSTFNAME CHAR (20),

VS_CUSTADDRS VARCHAR (30),

VS_CUSTCITY CHAR (20),

VS_CUSTSTATE CHAR (2),

VS_CUSTBDATE NUMERIC (8),

VS_CUSTEMAIL VARCHAR (40),

VS_CUSTPHONE NUMERIC (10),

VS_FILLER VARCHAR (100),

CONSTRAINT PKCUSTOMER PRIMARY KEY (

VS_CUSTIDENT)) ;

COMMIT ;

注意:

コピーブックODCSFOBにはフィールドの再定義VS-CUSTBDATE-G PIC 9(008)が含まれ、これは技術フィールドのため、識別ルールは実装されません。この場合、再定義されたフィールドのみが生成された表VS_CUSTBDATE NUMBER(8)に作成されます。

環境の準備

この項では、データをVSAMファイルからDB2/luw (udb)表に移行するために使用するコンポーネントを生成する前に実行するタスクについて説明します。

環境変数の初期化

Tuxedo ART Workbenchの実行前に次の環境変数を設定します。

•

export TMPPROJECT=$Home/tmp

- プロセスにより生成される一時オブジェクトを格納する場所。

このディレクトリは定期的にクリーンアップする必要があります。

•

export $PARAM=$HOME/param

- 構成ファイルの場所。

構成ファイルの実装

次を使用して記述された3つのファイルは、Tuxedo ART Workbenchファイル構造に置く必要があります。

•

$PARAM:

•

db-param.cfg

•

$PARAM/file:

•

Datamap-<configuration name>.re

•

mapper-<configuration name>.re。

File-To-Db2/luw (UDB)変換の場合、Datamap-<configuration name>.reおよびmapper-<configuration name>.reファイルを自分で作成する必要があります。

その他の2つの構成ファイル

•

file-templates-db2luw.txt

•

file-move-assignation-db2luw.pgm

これらのファイルは、Tuxedo ART Workbenchのインストール時にファイル構造に自動的に生成されます。これらのファイルの特定のバージョンが特定のz/OSファイルに必要な場合は、$PARAM/fileファイル構造に配置されます。

ファイルの構成

データベース・パラメータ・ファイル(db-param.cfg)

db-param.cfgファイルの場合、ターゲットおよびファイル・パラメータのみが調整される必要があります。

リスト1-37 db-param.cfgの例

# 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:udb

target_rdbms_version:9

target_os:unix

# optional parameter

target_cobol:cobol_mf

hexa-map-file:tr-hexa.map

#

# 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 FF6

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.

必須パラメータ

•

target_rdbms_name: udb

ターゲットRDBMSの名前。

•

target_rdbms_version:9

ターゲットRDBMSのバージョン。

•

target_os:unix

ターゲット・オペレーティング・システムの名前。

•

file:char_limit_until_varchar:29

DB2/Luw(udb) VARCHARデータ型に変換される前のCOBOL英数字(PIC X)フィールドの最大フィールド長を示します。

この例では、29文字よりも長いフィールドはVARCHARフィールドになり、30文字よりも短いフィールドはCHARフィールドになります。

オプションのパラメータ

target_cobol:cobol_mf

COBOL言語の名前。許容値はcobol_mf (デフォルト値)およびcobol_itです。

この例では、言語はMicro Focus COBOLです。

hexa-map-file:tr-hexa.map

EBCDIC (z/OSのコード・セット)とASCII (Linux/UNIXのコード・セット) 16進数値間のマッピング表ファイルを指定します。hexa-map-fileを指定しない場合は、警告がロギングされます。

データマップ・パラメータ・ファイル(Datamap-<configuration name>.re)

移行するVSAMファイルをリストする必要があります。

次のパラメータを設定する必要があります。

表1-24 データマップ・パラメータ

パラメータ

例での値

設定元

configuration name

STFILEUDB

(data map STFILEUDB-map)

ユーザーが自由に選択します。

system name

STFILEUDB

(system cat::STFILEUDB)

カタロガのシステム記述ファイルによって決定されます。

file name

PJ01AAA.SS.VSAM.CUSTOMER

z/OS物理ファイル名。

Organization

Indexed

ソースの編成

注意:

使用される様々なパラメータの説明は、『Tuxedo ART Workbenchリファレンス・ガイド』のFile-to-Fileコンバータに関する項を参照してください。

PJ01AAA.SS.VSAM.CUSTOMERファイルはVSAM KSDSファイルのため、編成は索引付きです。パラメータkeys offset 1 bytes length 6 bytes primaryはキーを記述しています。この例では、キーは6バイトの長さでポジション1から開始します。

リスト1-38 データマップ・ファイルの例: Datamap-STFILEUDB.re

%% Lines beginning with "%%" are ignored

data map STFILEUDB-map system cat::STFILEUDB

%%

%% Datamap File PJ01AAA.SS.VSAM.CUSTOMER

%%

file PJ01AAA.SS.VSAM.CUSTOMER

organization Indexed

keys offset 1 bytes length 6 bytes primary

マッピング・パラメータ・ファイル(mapper-<configuration name>.re)

データマップ構成ファイルに含まれている、移行する各z/OSファイルをリストする必要があります。

ファイルのパラメータおよびそのオプションは、DB2/Luw(udb)表に変換するVSAMファイルごとに含まれる必要があります。次のパラメータを設定する必要があります。

表1-25 マッピング・パラメータ

パラメータ

例での値

設定元

configuration name

STFILEUDB

(ufas mapper STFILEUDB)

データマップ構成ファイルで使用される名前と一貫性があります。

file name

PJ01AAA.SS.VSAM.CUSTOMER

データマップ・ファイルで使用される名前です。

include

include "COPY/ODCSF0B.cpy"

コピー・ファイルBCOAC01E.cpyの名前およびパスはファイルの作成時にユーザーが自由に選択します。

table name

table name CUSTOMER

作成されるDB2/Luw(udb)表の名前を指定します。

map record

map record VS-ODCSF0-RECORD defined in "COPY/ODCSF0B.cpy"

VS-ODCSF0-RECORDはコピー・ファイルのレベル01フィールド名に相当します。

logical name

logical name ODCSF0B

ユーザーが選択します(最大8文字)。この名前は、Tuxedo ART Workbenchの様々なツールによって作成されるオブジェクト(COBOL、JCL)に名前を付けるために使用されます。

converter name

converter name ODCSF0B

論理名と同じ名前および用途です。

注意:

使用される様々なパラメータの説明は、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』のFile-To-Fileコンバータに関する項を参照してください。

リスト1-39 マッパー・ファイルの例: mapper-STFILEUDB.re

%% Lines beginning with "%%" are ignored

ufas mapper STFILEUDB

%%

%% Desc file PJ01AAA.SS.VSAM.CUSTOMER

%%

file PJ01AAA.SS.VSAM.CUSTOMER transferred converted

table name CUSTOMER

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

attributes LOGICAL_MODULE_IN_ADDITION

コピー・ファイルのインストール

COBOL記述ファイルを準備したら、mapper-<configuration name>.reファイルに記述したコピー・ファイルを$PARAM/file/recs-sourceディレクトリに置く必要があります。

ソース・プラットフォームからのCOBOLコピーブックを使用してファイルを記述する場合(「COBOL記述」の注意を参照)、これが、前述の"COPY/ODCSF0B.cpy"の例のように、マッピング・パラメータ・ファイルで直接使用されるコピーブックの場所です。

コンポーネントの生成

VSAMファイルからDB2/Luw(udb)表へのデータの移行に使用されるコンポーネントを生成するには、Tuxedo ART Workbenchではfile.shコマンドを使用します。この項ではこのコマンドについて説明します。

file.sh

名前

file.sh - z/OS移行コンポーネントを生成します。

形式

file.sh [ [-g] [-m] [-i <installation directory>] <configuration name> | -s <installation directory> (<configuration name>,...) ]

説明

file.shでは、Tuxedo ART Workbenchにより、VSAMファイルの移行に使用するコンポーネントを生成します。

オプション

-g <configuration name>

生成オプション。アンロードおよびロード・コンポーネントは、構成ファイルにより提供された情報を使用して$TMPPROJECTに生成されます。

-m <configuration name>

変更オプション。生成されたシェル・スクリプトを実行可能にします。COBOLプログラムは、ターゲットCOBOLの固定形式に合うように調整されます。生成されたソース・ファイルを変更するシェル・スクリプトが存在する場合は実行されます。

-i <installation directory> <configuration name>

インストール・オプション。コンポーネントをインストール・ディレクトリに配置します。この操作はfile-move-assignation-db2luw.pgmファイルにある情報を使用します。

-s <installation directory> <schema name>,...)

COBOLコンバータで使用する構成ファイルおよびDMLユーティリティの生成を可能にします。すべての構成ファイルは$PARAM/dynamic-configに、DMLファイルは<trf>/DMLディレクトリに作成されます。

例

file.sh -gmi $HOME/trf FTFIL001

Makeユーティリティの使用

Makeはターゲット(ファイルまたはアクション)の構成を自動化および最適化することを目的としたUNIXユーティリティです。

すべての操作が実装されるソース・ディレクトリにmakefileという名前の記述子ファイルが存在する必要があります(makefileはプロジェクトの初期化中にソース・ディレクトリに準備されます)。

次の2つの項では、makefileの構成と、makefileを使用したTuxedo ART Workbench File-To-Fileコンバータ機能の使用方法について説明します。

Makeファイルの構成

version.mk

$PARAMのversion.mk構成ファイルを使用して、makeユーティリティで必要な変数およびパラメータを設定します。

version.mkには、各種コンポーネントがインストールされる場所とその拡張機能、および使用される様々なツールのバージョンを指定します。このファイルにはログ・ファイルの構成方法も記述されます。

次の一般的な変数を、version.mkファイルでの移行プロセスの最初に設定する必要があります。

•

ROOT_PROJECT

•

DIR_TRADDATA

•

TOOLS_DATA

•

LOGDIR

また、FILE_SCHEMAS変数はファイルの移行に固有で、処理する様々な構成を示します。

この構成はMakeファイルの使用の前に完了する必要があります。

makefileの内容

makefileの内容は実行するタスクの要約です。

•

version.mkを含めます

•

主な変数が設定されているかどうかを制御します。

•

変数の値を収集し、処理に必要なリストを作成します。

•

ターゲットを実装します。

makefileおよびversion.mkファイルはTuxedo ART Workbench Simple Applicationとともに提供されます。

Tuxedo ART Workbench File-To-Fileコンバータでのmakefileの使用

make FileConvertコマンドを使用して、Tuxedo ART Workbench File-To-Fileコンバータを起動できます。これによりz/OSファイルのUNIX/Linuxターゲット・プラットフォームへの移行に必要なコンポーネントを生成できます。

makefileはFILE_SCHEMAS変数に含まれるすべての構成に対し、-g、-mおよび-iオプションを指定してfile.shツールを起動できます。

生成されたファイルの場所

-i $HOME/trfオプションで生成されるアンロード・コンポーネントおよびロード・コンポーネントは、次の場所に配置されます。

表1-26 コンポーネントの場所

場所

内容

$HOME/trf/unload/file/<configuration name>

各アンロードに使用されるプログラムおよびJCLは各<configuration name>に対して生成されます。

$HOME/trf/reload/file/<configuration name>

各ロードに使用されるプログラムおよびKSHは各<configuration name>に対して生成されます。

例: loadtable-ODCSF0.ksh RELTABLE-ODCSF0.sqb

$TMPPROJECT/outputs

生成ログ・ファイルMapper-log-<configuration name>は問題の解決に使用できます。

$HOME/trf/SQL/file/<schema name>

表の作成用のSQLスクリプトおよび生成されたDB2/luw (udb)表に対し様々な技術的操作を実行するために使用されるKornシェル・スクリプトの場所です。

$HOME/trf/DML

COBOLおよび埋込みSQLアクセス・ルーチンの場所。これらのルーチンは、DB2/luw (udb)表に移行されたVSAMファイルで使用されるアクセス動詞のかわりにCOBOLプログラムによって実行されます。

生成されたコンポーネントの例

この章で使用する例では、次のスクリプトが生成されます。

CUSTOMER表を作成するのに使用されるSQLスクリプトの名前は次のとおりです。

•

ODCSF0B.sql

様々な技術的操作で使用されるスクリプトの名前は次のとおりです。

•

cleantable-ODCSF0B.ksh

•

createtable-ODCSF0B.ksh

•

droptable-ODCSF0B.ksh

•

ifemptytable-ODCSF0B.ksh

•

ifexisttable-ODCSF0B.ksh

9個のCOBOLプログラムが生成されます。これらの使用方法については、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』を参照してください。

•

ASG_ODCSF0B.cbl

•

close_all_files_STFILEUDB.cbl

•

dml_locking.cbl

•

init_all_files.cbl

•

UL_ODCSF0B.cbl

•

close_all_files.cbl

•

DL_ODCSF0B.cbl

•

getfileinfo.cbl

•

init_all_files_STFILEUDB.cbl

DB2/luw (udb) CUSTOMER表にアクセスするための1つの埋込みSQLプログラムが生成されます。

•

RM_ODCSF0B.sqb

生成されたコンポーネントの変更

生成されたコンポーネントはプロジェクト固有のスクリプトを使用して変更できます。これらのスクリプト(sed、awk、 perlなど)は次の場所に配置する必要があります。

$PARAM/file/file-modif-source.sh

このファイルが存在する場合、生成プロセスの最後に自動的に実行されます。これは、引数として<configuration name>を使用して呼び出されます。

DB2からOracleへの移行プロセス

•

ファイル編成

•

実装のルールのリエンジニアリング

•

環境の準備

•

コンポーネントの生成

ファイル編成

z/OS DB2ソース・プラットフォームからOracle UNIXターゲット・プラットフォームに移行するときは、どの表を移行する必要があるかをまず確認します。移行しないDB2表がある場合、移行するオブジェクトのサブセットを示すDB2 DDLを作成する必要があります。

移行プロセス手順

この章で詳しく説明する、DB2からOracleへの移行プロセスの原則的な手順は次のとおりです。

1.

移行する表のリスト全体を作成します。すべてのDB2表を移行するわけではない場合は、移行する表のDB2 DDLを作成します。それ以外の場合は、サイトで使用するDB2 DDL全体を取得します。

2.

コンポーネントの生成に使用する環境を準備します。

3.

Tuxedo ART Workbenchを使用して、次の手順で使用するコンポーネントを生成します。

4.

ソース・プラットフォームから表をアンロードします。

5.

データをターゲット・プラットフォームに転送します。

6.

データをトランスコードして再ロードします。

7.

結果を確認します。

8.

Oracleデータベースを構築します。

その他のOracle Tuxedo Application Rehosting Workbenchツールとの対話

DB2からOracleへの移行はカタロガの結果に依存します。DB2からOracleへの移行はCOBOL変換に影響を与えるので、プログラムの変換作業の開始前に完了する必要があります。

実装のルールのリエンジニアリング

この項では、DB2データベースからOracleデータベースにデータを移行するときに、Tuxedo ART Workbenchにより適用されるリエンジニアリング・ルールについて説明します。

適用する移行ルール

Oracleへの移行に含まれるDB2オブジェクトのリストは、「生成されたOracleオブジェクトの作成」で説明します。

Tuxedo ART Workbenchの名前の変更ルールの適用を除き、Oracleへの移行時に、移行されたDB2オブジェクトの名前は保持されます(「名前の変更ルールの準備および実装」を参照)。

DB2からOracleへのデータ型移行ルール

表1-27 DB2からOracleへのデータ型

DB2 z/OSデータ型

Oracleの形式

CHAR(length)

長さ <= 2000バイトの場合はCHAR

長さ > 2000バイトの場合はVARCHAR2

VARCHAR(length)

VARCHAR2(length)

DECIMAL(…)

NUMBER(…)

NUMERIC(…)

NUMBER(…)

DEC(…)

NUMBER(…)

SMALLINT

NUMBER(5)

INTEGER

NUMBER(10)

TIMESTAMP

TIMESTAMP

TIMESTMP

TIMESTAMP

DATE

DATE

TIME

DATE

DOUBLE

BINARY_DOUBLE

FLOAT(prec)

BINARY_DOUBLE

REAL

BINARY_DOUBLE

CLOB

CLOB

BLOB

BLOB

DB2からOracleへの列プロパティの移行ルール

列プロパティによりアプリケーション・プログラムの動作を変更できます。

次の表にすべてのDB2の列プロパティと、ターゲットOracleデータベース用に変換する方法を示します。

表1-28 DB2からOracleへの列プロパティ

DB2の列プロパティ

Oracleの形式

注意

WITH DEFAULT

DEFAULT <value>

<value>はDB2/z/OSデータ型によって異なります。

WITH DEFAULT ''

CHAR: DEFAULT ‘ ‘

VARCHAR2: DEFAULT ‘ ‘

DB2でのゼロ・バイトの長さはOracleでのNULLフラグになります。

WITH DEFAULT '<value>'

DEFAULT '<value>'

NOT NULL

NOT NULL

IDENTITY

Sequenceの作成

Triggerの作成

IDENTITY属性はOracleには存在しないので、Tuxedo ART Workbenchはその属性をSequenceおよびTriggerオブジェクトで置き換えます。

FOR SBCS …

属性は無視されます

名前の変更ルールの準備および実装

Oracle Tuxedo Application Rehosting Workbenchでは、DDLソース・ファイル内の様々な名前(表名や列名)を変更できます。

名前の変更ルールは次の場合に実装できます。

•

Oracleの予約語がDB2 DDLソース・ファイルで検出される場合。

•

DDLソース・ファイルのリエンジニアリングを実行する必要がある場合。

注意:

Tuxedo ART Workbenchを実行するときにOracleの予約語がDDLソースで検出されると、エラーが報告されますが、Tuxedo ART WorkbenchはDDLの分析を続行します。

名前の変更ルールは、rename-objects-<schema name>.txtという名前のファイルに配置する必要があります。このファイルは、$PARAM/rdbmsパラメータで示されたディレクトリに配置する必要があります。

名前の変更ルールの形式は次のとおりです。

•

表:

table;<schema name>;<DB2 table name>;<Oracle table name>

•

列:

Column;<schema name>;<DB2 table name>;<DB2 column name>;<Oracle column name>

コメントは% Textのように追加できます。

例:

% Modification applied to the AUALPH0T table

column;AUANPR0U;AUALPH0T;NUM_ALPHA;MW_NUM_ALPHA

LOBSデータ型の移行の準備と実装

Tuxedo ART Workbenchでは、CLOBおよびBLOBデータ型をダウンロードできます。DB2アンロード・ユーティリティは、CLOB列またはBLOB列の各行を個別のファイルにダウンロードします(PDSまたはHFSデータセット・タイプ)。このユーティリティ(DSNUTILB)は、すべての列のデータおよびNULL技術フラグを一意のMVSメンバー・ファイルにダウンロードします。ただし、個別のCLOBまたはBLOBファイルのファイル名で置き換えられるCLOB列またはBLOB列は除きます。

MVSシステム構成によっては、PDSデータセット・タイプで一部のファイルが許可されないため、CLOBまたはBLOB列のダウンロードに別のデータセット・タイプを選択しなければならないこともあります。

これら2つの制約に基づいて、db-param.cfg構成ファイルで正しいパラメータを設定する必要があります(「構成ファイルの実装」を参照)。

MBCSデータの移行の準備と実装

Tuxedo ART Workbenchでは、シングル・バイト・データのトランスコーディングが提供されています。ただし、DB2データにMBCS文字が含まれる場合は、DSNUPROCアンロード・ユーティリティを選択してcsvデータ形式を設定する必要があります。MBCSトランスコーディングは、転送ツールによって行われます。

この制約に基づいて、db-param.cfg構成ファイルで正しいパラメータを設定する必要があります(「構成ファイルの実装」を参照)。

DB2オブジェクトの移行の例

この例では、DB2 DDLに、主キーおよびXCUSTIDENという名前の一意の索引を持つ、ODCSF0という名前の表が含まれます。

リスト1-40 移行前のDDLの例

DROP TABLE ODCSF0;

COMMIT;

CREATE TABLE ODCSF0

(CUSTIDENT DECIMAL(6, 0) NOT NULL,

CUSTLNAME CHAR(030) NOT NULL,

CUSTFNAME CHAR(020) NOT NULL,

CUSTADDRS CHAR(030) NOT NULL,

CUSTCITY CHAR(020) NOT NULL,

CUSTSTATE CHAR(002) NOT NULL,

CUSTBDATE DATE NOT NULL,

CUSTEMAIL CHAR(040) NOT NULL,

CUSTPHONE CHAR(010) NOT NULL,

PRIMARY KEY(CUSTIDENT))

IN DBPJ01A.TSPJ01A

CCSID EBCDIC;

COMMIT;

CREATE UNIQUE INDEX XCUSTIDEN

ON ODCSF0

(CUSTIDENT ASC) USING STOGROUP SGPJ01A;

COMMIT;

移行ルールの適用後、名前の変更ルールを実装せずに、次のOracleオブジェクトが取得されます。

リスト1-41 移行後のOracle表の例

WHENEVER SQLERROR CONTINUE;

DROP TABLE ODCSF0 CASCADE CONSTRAINTS;

WHENEVER SQLERROR EXIT 3;

CREATE TABLE ODCSF0 (

CUSTIDENT NUMBER(6) NOT NULL,

CUSTLNAME CHAR(30) NOT NULL,

CUSTFNAME CHAR(20) NOT NULL,

CUSTADDRS CHAR(30) NOT NULL,

CUSTCITY CHAR(20) NOT NULL,

CUSTSTATE CHAR(2) NOT NULL,

CUSTBDATE DATE NOT NULL,

CUSTEMAIL CHAR(40) NOT NULL,

CUSTPHONE CHAR(10) NOT NULL);

リスト1-42 移行後のOracle索引の例

WHENEVER SQLERROR CONTINUE;

DROP INDEX XCUSTIDEN;

WHENEVER SQLERROR EXIT 3;

CREATE UNIQUE INDEX XCUSTIDEN ON ODCSF0

(

CUSTIDENT ASC

);

リスト1-43 移行後のOracle制約の例

WHENEVER SQLERROR CONTINUE;

ALTER TABLE ODCSF0 DROP CONSTRAINT CONSTRAINT_01;

WHENEVER SQLERROR EXIT 3;

ALTER TABLE ODCSF0 ADD

CONSTRAINT CONSTRAINT_01 PRIMARY KEY (CUSTIDENT);

環境の準備

この項では、DB2データをOracleに移行するのに使用するコンポーネントを生成する前に実行するタスクについて説明します。

DB2 DDLソース・ファイルのカタログ化の実装

移行するDB2 DDLソース・ファイルは、カタログ操作を準備するときに配置されます。移行プロセス中に、SQL CREATEコマンドのみが処理されてOracleに移行されますが、すべての有効なDB2構文が受け入れられます。

system.descファイル・パラメータ

DB2からOracleへの移行では、すべてのTuxedo ART Workbenchツールで使用するカタロガ内のsystem.descシステム記述ファイルに、パラメータを設定する必要があります。

•

DBMS-VERSION="8"。

移行するRDBMSのバージョンを示します。

スキーマ

スキーマは一貫性のあるオブジェクトのセットから構成される必要があります(たとえば、スキーマに存在しない表に対してのCREATE INDEXはありません)。

デフォルトでは、DB2 DDLのSQLコマンドに接頭辞として修飾子または認可IDが付いている場合、その接頭辞はTuxedo ART Workbenchによってスキーマ名として使用されます。たとえば、CREATE TABLE <qualifier or authorization ID>.表名のように使用します。

スキーマ名は、system.descファイルのglobal-options句を使用して、Tuxedo ART Workbenchが決定することもできます。

例:

system STDB2ORA root ".."

global-options

catalog="..",

sql-schema=<schema name>.

また、各DDLディレクトリのスキーマ名は、system.descファイルのdirectory options句を使用して、Tuxedo ART Workbenchが決定することもできます。詳細は、「カタロガ」のoptions句に関する項を参照してください。

directory "DDL" type SQL-SCRIPT

files "*.sql"

options SQL-Schema = "<schema name>".

構成ファイルの実装

次の1つのファイルのみは、$PARAMで記述されたTuxedo ART Workbenchのファイル構造に置く必要があります。

•

db-param.cfg

その他の2つの構成ファイル

•

rdbms-templates.txt

•

rdbms-move-assignation.pgm

これらのファイルは、Tuxedo ART Workbenchのインストール時にファイル構造に自動的に生成されます。これらのファイルの特定のバージョンが必要な場合は、$PARAM/rdbmsファイル構造に置かれます。

環境変数の初期化

Tuxedo ART Workbenchの実行前に次の環境変数を設定します。

•

export TMPPROJECT=/$home/tmp

- プロセスにより生成される一時オブジェクトを格納する場所。

   このディレクトリは定期的にクリーンアップする必要があります。

•

export PARAM=$HOME/param

- 構成ファイルの場所。

生成パラメータ

リスト1-44 db-param.cfgファイルの例

#

# This configuration file is used by FILE & RDBMS converter

# Lines beginning by "#" 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 parameter

target_cobol:cobol_mf

hexa-map-file:tr-hexa.map

#

# 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 FF6

rdbms:time_format:HH24 MI SS

rdbms:lobs_fname_length:75

rdbms:jcl_unload_lob_file_system:pds

rdbms:jcl_unload_utility_name:dsnutilb

#rdbms:jcl_unload_format_file:csv

# rename object files

# the file param/rdbms/rename-objects-<schema>.txt is automatically loaded by # the tool if it exists.

パラメータtarget_<xxxxx>およびrdbms:<xxxxx>のみが調整される必要があります。

必須パラメータ

•

target_rdbms_name: oracle

ターゲットRDBMSの名前。

•

target_rdbms_version:11

ターゲットRDBMSのバージョン。

•

target_os:unix

ターゲット・オペレーティング・システムの名前。

オプションのパラメータ

target_cobol:cobol_mf

COBOL言語の名前。許容値はcobol_mf (デフォルト値)およびcobol_itです。

この例では、言語はMicro Focus COBOLです。

hexa-map-file:tr-hexa.map

EBCDIC (z/OSのコード・セット)とASCII (Linux/UNIXのコード・セット) 16進数値間のマッピング表ファイルを指定します。hexa-map-fileを指定しない場合は、警告がロギングされます。

DATE、TIMEおよびTIMESTAMPデータ型の場合のオプションのパラメータ

次のrdbmsパラメータは、z/OS DB2で使用され、DSNZPARMに格納される日付、タイムスタンプおよび時間形式を示します。

•

rdbms:date_format: YYYY/MM/DD

•

rdbms:timestamp_format:YYYY/MM/DD HH24 MI SS FF6

•

rdbms:time_format:HH24 MI SS

これらのパラメータは、再ロード操作、COBOLの日付および時間の操作に影響を与えます。これらはオプションで、DB2データベースにDATE、TIMEまたはTIMESTAMPフィールドが含まれる場合にのみ必要です。

警告:

これらのパラメータを正しく設定することが重要です。

CLOBまたはBLOBデータ型の場合のオプションのパラメータ

次のrdbmsパラメータはオプションで、DB2スキーマにCLOBまたはBLOBデータ型が含まれる場合にのみ必要です。

警告:

これらのパラメータを正しく設定することが重要です。

•

rdbms:jcl_unload_lob_file_system:pds / hfs

PDSで作成できるメンバー・ファイル数は制限されています。DB2アンロード・ユーティリティはCLOB/BLOB列および行ごとに新しいメンバー・ファイルを作成するため、PDSデータセット・タイプで作成できる最大LOBSファイル数を超えることがあり、その場合はHFSデータセット・タイプを選択する必要があります。詳細は、DB2 MVSの管理者に問い合せてください。デフォルトではpdsを使用します。

•

rdbms:lobs_fname_length:75

DB2アンロード用JCLによって表データ・ファイルに書き込まれるCLOBまたはBLOBファイル名の最大長を計算する必要があります。

•

pds

ターゲットMVSのデータセット名の長さがMIGR.SCH1.TAB1.COLUMN1と等しい場合(22文字)、JCLによって作成される文字列の最大長は32: 22 + 2 (カッコ文字) + 8 (メンバー名)になります。

•

HFS

ターゲットMVSのディレクトリ名の長さが/LOB/SCHEMA2/TABLE2/SECOND2と等しい場合(27文字)、JCLによって作成される文字列の最大長は36: 27 + 1 (スラッシュ文字) + 8 (ファイル名)になります。

注意:

rdbms:jcl_unload_utility_nameパラメータには、値dsnutilbを設定する必要があります。

JCLアンロード・ユーティリティのオプションのパラメータ

次のパラメータはオプションです。

•

rdbms:jcl_unload_utility_name:dsnutilb

•

rdbms:jcl_unload_format_file:binary

MVSにDB2アンロード・ユーティリティがあるかどうかによって、値を変更することもできます。

注意:

•

DB2スキーマにCLOBまたはBLOBデータ型が含まれる場合、最初のパラメータは必須です。

•

jcl_unload_utility_nameがdsnuprocに設定されている場合にのみ、2番目のパラメータをcsvに設定できます。

•

データベースにMBCS文字が含まれる場合、アンロード・ユーティリティとしてdsnuproc、アンロード形式としてcsvを選択する必要があります。

コンポーネントの生成

DB2データベースからOracleデータベースへのデータの移行に使用されるコンポーネントを生成するには、Tuxedo ART Workbenchではrdbms.shコマンドを使用します。この項ではこのコマンドについて説明します。

rdbms.sh

名前

rdbms.sh - DB2からOracleデータベースへの移行コンポーネントを生成。

形式

rdbms.sh [ [-c|-C] [-g] [-m] [-r] [-i <installation directory>] <schema name> ] -s <installation directory> (<schema name>,...) ]

説明

rdbms.shでは、z/OS DB2データベースをUNIX Oracleデータベースに移行するために使用されるTuxedo ART Workbenchのコンポーネントを生成します。

オプション

生成オプション

-C <schema name>

次のコンポーネントが$TMPPROJECTに生成されます。DDL Oracle、SQL*LOADERのCTLファイル、COBOLコンバータで使用されるXMLファイル、構成ファイル(mapper.reおよびDatamap.re)。エラーまたは警告が発生してもプロセスは中断しません。

生成操作中に作成されたSQLスクリプトについては、「トランスコードおよび再ロード・スクリプトの実行」を参照してください。

-c <schema name>

エラーまたは警告が生成されてプロセスが中断する場合を除き、このオプションでは-Cオプションと同じ結果になります。

-g <schema name>

構成ファイルで提供される情報を使用して、アンロードおよびロード・コンポーネントを$TMPPROJECTに生成します。このオプションの前に-Cまたは-cコマンドを指定してrdbms.shコマンドを実行する必要があります。

変更オプション

-m <schema name>

生成されたシェル・スクリプトを実行可能にします。COBOLプログラムは、ターゲットCOBOLの固定形式に合うように調整されます。生成されたソースを変更するシェル・スクリプトが存在する場合は実行されます。

-r <schema name>

生成されたオブジェクト(表の作成、表名、SQL*LOADER用のCTLファイル、KSH)からスキーマ名を削除します。このオプションが使用されるときに、COBOLコンポーネントの変換時に使用されるconfig-cobolファイル(COBOL変換構成ファイル)にある、オプションsql-remove-schema-qualifierを使用して、スキーマ名もCOBOLコンポーネントから削除できます。

インストール・オプション

-i <installation directory> <schema name>

コンポーネントをインストール・ディレクトリに配置します。この操作はrdbms-move-assignation.pgmファイルにある情報を使用します。

COBOL変換用の構成ファイルの生成

-s <installation directory> <schema name>,...)

COBOLコンバータの構成ファイルの生成を可能にします。このファイルは、プロジェクトのすべての単一XMLファイルを取得します。これらのファイルはすべて$PARAM/dynamic-configに作成されます。

例: rdbms-conv.txt rdbms-conv-PJ01DB2.xml

例

rdbms.sh -Cgrmi $HOME/trf PJ01DB2

Makeユーティリティの使用

Makeはターゲット(ファイルまたはアクション)の構成を自動化および最適化することを目的としたUNIXユーティリティです。

すべての操作が実装されるソース・ディレクトリにmakefileという名前の記述子ファイルが存在する必要があります(makefileはプロジェクトの初期化中にソース・ディレクトリに準備されます)。

次の2つの項では、makefileの構成と、makefileを使用したTuxedo ART Workbench File-To-Fileコンバータ機能の使用方法について説明します。

Makeファイルの構成

version.mk

$PARAMのversion.mk構成ファイルを使用して、makeユーティリティで必要な変数およびパラメータを設定します。

version.mkには、各種コンポーネントがインストールされる場所とその拡張機能、および使用される様々なツールのバージョンを指定します。このファイルにはログ・ファイルの構成方法も記述されます。

次の一般的な変数を、version.mkファイルでの移行プロセスの最初に設定する必要があります。

•

ROOT_PROJECT

•

DIR_TRADDATA

•

TOOLS_DATA

•

LOGDIR

また、RDBMS_SCHEMAS変数はDB2の移行に固有で、処理する様々なスキーマを示します。

この構成はMakeファイルの使用の前に完了する必要があります。

makefileの内容

makefileの内容は実行するタスクの要約です。

•

version.mkを含めます

•

主な変数が設定されているかどうかを制御します。

•

変数の値を収集し、処理に必要なリストを作成します。

•

ターゲットを実装します。

makefileおよびversion.mkファイルはTuxedo ART Workbench Simple Applicationとともに提供されます。

Oracle Tuxedo Application Rehosting Workbench File-To-FileコンバータでのMakefileの使用

make RdbmsConvertコマンドを使用して、Tuxedo ART Workbench File-To-Fileコンバータを起動できます。これによりDB2データベースからOracleへの移行に必要なコンポーネントを生成できます。

makefileはrdbms.shツールを、-C、-g、-r、-mおよび-iオプションを使用して、RDBMS_SCHEMAS変数に含まれるすべてのスキーマに対して起動できます。

生成されたファイルの場所

-i $HOME/trfオプションで生成されるアンロード・コンポーネントおよびロード・コンポーネントは、次の場所に配置されます。

表1-29 コンポーネントの場所

場所

内容

$HOME/trf/unload/rdbms/<schema name>

各アンロードに使用されるJCLが各<schema name>用に生成されます。

$HOME/trf/SQL/rdbms/<schema name>

Oracleオブジェクトの作成に使用されるSQLスクリプトの<schema name>による場所。この章で使用される例では、次の3つのスクリプトがあります。

•

INDEX-ODCSF0.sql

•

TABLE-ODCSF0.sql

•

CONSTRAINT-ODCSF0.sql

$HOME/trf/reload/rdbms/<schema name>/src

COBOLトランスコード・プログラムの<schema name>による場所。この章の例では、次のプログラムがあります。

•

MOD_ODCSF0.cbl

およびCLOBデータ型の場合のその他のプログラム:

•

CLOB_<table>_<column>.cbl

$HOME/trf/reload/rdbms/<schema name>/ctl

SQL*LOADERにより使用されるCTLファイルの<schema name>による場所。この章の例では、次のCTLがあります。

•

ODCSF0.ctl

$HOME/trf/reload/rdbms/<schema name>/ksh

再ロードKornシェル・スクリプトの<schema name>による場所。この章の例では、次のスクリプトがあります。

•

loadrdbms-ODCSF0.ksh

$TMPPROJECT/outputs/<schema name>

-cまたは-Cオプションを使用して生成された生成ログ・ファイル。rdbms-converter-<schema name>を使用して問題を解決できます。

trf/DSNUTILS/<schema name>

DBロード/アンロード用COBOLプログラムの<schema name>による場所。この章の例では、次の2つのプログラムがあります。

PJ01DB2-ODCSF0-L.pco

PJ01DB2-ODCSF0-U.pco

生成されたコンポーネントの変更

生成されたコンポーネントはプロジェクト固有のスクリプトを使用して変更できます。これらのスクリプト(sed、awk、 perlなど)は次の場所に配置する必要があります。

$PARAM/rdbms/rdbms-modif-source.sh

このファイルが存在している場合、生成プロセスの最後に自動的に実行されます。これは、引数として<schema name>を使用して呼び出されます。

COBOL変換

データ・ファイルの移行は次の項で説明しています。

•

要件および前提条件

•

プラットフォーム移行プロセスにおけるCOBOLコンバータの概要

•

変換手順

•

Makeファイルの使用

•

COBOLコンバータのトラブルシューティング

要件および前提条件

カタログ化の要件

COBOLコンバータを実行する前に、移行するアセットの一貫性をチェックし、構文またはアセットの一貫性(欠落または未使用コンポーネント)に関連するエラーを修正するために、カタログ化は必須です。

データ変換

データ移行プロセスは、COBOL変換が開始される前に実行しておく必要があります。この依存性は、データ移行ツールが、COBOLコンバータに読み取られる一部の構成ファイルを生成することが原因です。データ変換の構成ファイルについては、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』を参照してください。

プラットフォーム移行プロセスにおけるCOBOLコンバータの概要

Tuxedo ART Workbench COBOLコンバータ・プロセスへの入力は次のとおりです。

•

Tuxedo ART Workbenchカタロガにより生成されたPOBファイルに格納されているCOBOLプログラムの抽象構文ツリー。

•

構成ファイルのセットで、その中にはファイルからRDBMSへの変換およびリレーショナルDBMS変換(DB2からOracle)に関する情報を指定したデータ変換ツールにより生成されるものもあります。

変換手順

構成ファイルの作成と設定

変換用のメイン構成ファイルはconfig-COBOLです。これは次のものを含む他の追加の構成ファイルを参照します。

•

keywords-file

•

tr-hexa.map

•

rename-call-map-file

必要なすべての構成ファイルのサンプルはSimple Applicationにあります。必要に応じて値をチェックおよび調整する必要があります。

COBOLコンバータが使用するすべての構成ファイルは、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』の「COBOLコンバータ」に記載されています。

config-COBOLの構成

COBOL変換の前提条件の準備の後、次の例をモデルとして使用して、メイン構成ファイルを準備します。

注意:

次のファイルが使用できます。

•

post-translation-fileは一部の特定の変換を実行する必要があるときに使用されます。このファイルは手動で作成します。

•

rdbms-conversion-fileはDB2からOracleデータベースに移行するときに使用されます。このファイルはDB2-to-Oracleコンバータによって生成されます。

•

conv-ctrl-list-fileはOracle表に変換するファイルがあるときに使用されます。このファイルはFile-to-Fileコンバータによって生成される必要があります。

リスト1-45 config-cobolファイル

Config:

"Config version 1.0"

# sql-rules : none.

/* GENERAL */

target-dir: "../trf/".

keywords-file: "../param/keywords-file".

rename-call-map-file: "../param/rename-call-map-file".

accept-date : MW-DATE.

accept-day : MW-DAY.

# post-translation-file: "../param/renov.desc".

hexa-map-file: "../param/tr-hexa.map".

# rdbms-conversion-file : "dynamic-config/rdbms-conv.txt".

conv-ctrl-list-file : "dynamic-config/Conv-ctrl.txt".

on-size-error-call : "ABORT".

dcrp. /* Without reconcilation of copies files */

end

keywords-file

keywords-fileは、COBOLコンバータが、Tuxedo ART Workbench COBOLコンバータにより体系的に名前が変更されない可能性のある予約済キーワードを含む特定の変数の名前を変更するのに役立つヒント・ファイルです。

これは、変数がMicro Focus COBOLまたはCOBOL-ITの予約済キーワードでない場合でも、顧客独自の目的で名前の変更操作(一括変更)を行うための、WorkBenchにより提供されるリエンジニアリング・メカニズムです。

次のエントリをメイン構成ファイルconfig-cobolに配置します。

keywords-file: "../param/keywords-file"

リスト1-46 Keywords fileの例

( TAB . MW-TAB )

( DOUBLE . MW-DOUBLE )

( POS . MW-POS )

)

この例では、アイテムTABはすべてMW-TABで置換されます。

tr-hexa.map

tr-hexa.mapファイルはEBCDIC (z/OSのコード・セット)とASCII (Linux/UNIXのコード・セット) 16進数値間のマッピング表です。

次のエントリをメイン構成ファイルconfig-cobolに配置します。

hexa-map-file: "../param/tr-hexa.map"

このファイルは、Tr-Hexa-Mapのような変換ルールにより使用され、ソートや文字列の比較で異なる動作を引き起こす可能性のある値および文字列での、EBCDICとASCIIコード間の違いに関係する問題を、ユーザーが解決するのに役立ちます。

注意:

hexa-map-fileはオプションの項目で、指定しない場合、警告がロギングされます。

convert-hexa-copy-to-map.shスクリプトで生成されたhexa-map-file

このスクリプトは、REFINEDIR/scripts/convert-hexa-copy-to-map.shに配置されます。

構文

REFINEDIR/scripts/convert-hexa-copy-to-map.sh convertmw_copy_file

convertmw_copy_file: location of the CONVERTMW.cpy file

このスクリプトにより、現在のディレクトリ(PARAMディレクトリである必要があります)にtr-hexa.mapファイルが生成されます。

スペースの16進数コードの例

z/OSでのスペースの16進数コードは40で、UNIXでのスペースの16進数コードは20です。

ソース・プラットフォームのコードでの文は次のとおりです。

01 VarName pic X value X'40'.

これは次のように変換されます。

リスト1-47 16進数コード変換

*{ Tr-Hexa-Map 1.4.2.1

*01 VarName pic X value X'40'.

*--

01 VarName pic X value X'20'.

*}

リスト1-48 tr-hexa.mapのサンプル

00;00

01;01

02;02

03;03

37;04

2d;05

2e;06

2f;07

...

40;20

...

rename-call-map-file

rename-call-map-fileは古いコール名と新しいコール名の間のマッピング・ファイルです。

これはTr-Rename-External-Callのような一部の変換ルールにより使用され、これによりユーザーは必要に応じて特定の変更を行うことができます。

次のエントリをメイン構成ファイルconfig-cobolに配置します。

rename-call-map-file: "../param/rename-call-map-file"

リスト1-49 rename-call-map-fileの例

(

("MQGET" . "MWMQGET")

("KIX-ABEND" . "KIX_ABEND")

("KIX-ASKTIME" . "KIX_ASKTIME")

)

この例ではMQGETへのすべてのコールはMWMQGETに変更されます。

変換

変換コマンドのオプションにより可能になることがたくさんあります(詳細は、『Oracle Tuxedo Application Workbenchリファレンス・ガイド』を参照)。この項では、次の例について説明します。

•

バッチ・プログラムおよびCICSプログラムの変換。

•

プログラムのリストの変換。

•

1つのプログラムの変換。

プログラム(BatchおよびCICS)とサブプログラムの区別は必須で、オプション-cobol-typeは次の値をとります。

•

バッチ・プログラム: batch

•

CICSプログラム: tpr

•

サブプログラム: sub

次のコマンド行では、次の作業変数が設定されます。

表1-30 変換変数

変数

値

REFINEDIR

/product/art_wb11gR1/refine

PROJECT

$(HOME)/ simpleapp

PARAM

$PROJECT/param

SOURCE

$PROJECT/source

LOGS

$PROJECT/Logs

バッチ、CICSプログラムおよびサブプログラムの変換

コマンド行は次のとおりです。

•

すべてのバッチ・プログラムを変換する場合

$REFINEDIR/refine cobol-convert -v version -loop -limit=50 -s $PARAM/system.desc -c $PARAM/config-cobol -cobol-type batch

COBOLコンバータは、すべてのコンポーネントを記述するシステム記述ファイルから変換するバッチ・プログラムを認識します。ここでのversionはリリース・バージョンです(M2_L5_7など)

•

次のコマンドを呼び出すすべてのCICSプログラムを変換する場合

$REFINEDIR/refine cobol-convert -v version -loop -limit=50 -s $PARAM/system.desc -c $PARAM/config-cobol -cobol-type tpr

•

1つのプログラム(CICSプログラムPGMM002.cblなど)を変換するには、次のコマンドを呼び出します。

$REFINEDIR/refine cobol-convert -v version -loop -limit=50 -s $PARAM/system.desc -c $PARAM/config-cobol -cobol-type tpr CICS/PGMM002.cbl

•

次のコマンドを呼び出すすべてのサブプログラムを変換する場合

$REFINEDIR/refine cobol-convert -v version -loop -limit=50 -s $PARAM/system.desc -c $PARAM/config-cobol -cobol-type sub

•

次のコマンドを呼び出すすべてのCICSプログラムを変換する場合

$REFINEDIR/refine cobol-convert -v version -loop -limit=50 -s $PARAM/system.desc -c $PARAM/config-cobol -cobol-type tpr -cics

ログ・ファイルは、コマンド行が実行されるディレクトリに生成されます。特定のディレクトリまたはファイルにログを作成する場合は、-log-file-baseを使用して、その後に実行ログを格納するファイルのパスと名前を指定します。

$REFINEDIR/refine cobol-convert -v version -loop -limit=50 -s $PARAM/system.desc -log-file-base $LOGS/trans-cbl/translate-cobol-datetime -c $PARAM/config-cobol -cobol-type sub

この例では、ログ・ファイルは$LOGS/trans-cbl/translate-cobol-datetimeに生成されます。ログ・ディレクトリはあらかじめ作成しておく必要があります。

コピーブックの調整

コピーブックの調整は、COBOLコンバータにより暗黙的に実行するか、すべてのプログラムが生成された後で個別に実行できます(dcrpオプションを使用。「config-COBOLの構成」を参照)

。

調整を個別に適用するには、次のスクリプトを変換されたプログラムが置かれたディレクトリ(Simple Applicationの場合、$PROJECT/trfディレクトリ)から実行する必要があります。

リスト1-50 コピーの調整

for file in `find * -name '*-copies'`

do

$REFINEDIR/scripts/reconcil-copy-opt-imbr $PROJECT/trf $file .cbl

done

結果の確認

変換結果を確認するには、次のことを検証します。

•

必要とするプログラムがすべて生成されています。

•

空のプログラムがありません。

•

切り捨てられたプログラムがありません。

•

コピーブックに複数のバージョンがありません(調整が適切に完了)。

空のまたは切り捨てられたプログラムについては、ユーザーは$Logsに生成された実行ログを参照して、変換中に発生したエラーを分析できます。

コンパイル

コンパイルは変換の検証手順です。プログラムが正常にコンパイルされなかった場合は、完全に変換されたとみなすことはできません。

コンパイル・オプションおよび設定

次の変数によりコンパイル環境がMicro Focus COBOLまたはCOBOL-ITのコンパイル用に正しく構成されていることをチェックする必要があります。

表1-31 コンパイル変数

変数

値

使用方法

COBDIR

/Product/microfocus/cobol

COBOL製品へのアクセス

COBOLITDIR

/product/COBOL-IT

COBOL-IT製品へのアクセス

その他のCOBOL-IT環境変数

source $COBOLITDIR/bin/cobol-it-setup.sh

環境変数(PATH.LD_LIBRARY_PATH...)の初期化

PATH

$COBDIR/bin: ${PATH}

CobdirをPATH変数に追加

LD_LIBRARY_PATH

/usr/lib:$COBDIR/lib:${ORACLE_HOME}/lib:${JAVA_HOME}/lib

定義されたLD_LIBRARY_PATH

COBCPY

../DML:../Master-copy/COPY:../fixed-copy:.

プログラムがインクルードを見つけることのできる場所を示す

PCCINCLUDE

"include=../Master-copy/COPY, include=../../fixed-copies, include=.

プログラムがインクルードを見つけることのできる場所を示す

コンパイル・オプション・ファイルを準備する必要があります。Simple Applicationで使用されるコンパイル・オプションは次のとおりです。

リスト1-51 MFコンパイル・オプションの例

SOURCEFORMAT"FREE"

DEFAULTBYTE"00"

ADDRSV"COMP-6"

COMP-6"2"

ALIGN"8"

NOTRUNCCALLNAME

NOTRUNCCOPY

NOCOPYLBR

COPYEXT"cpy,cbl"

RWHARDPAGE

PERFORM-TYPE"OSVS"

NOOUTDD

INDD

NOTRUNC

HOSTARITHMETIC

NOSPZERO

INTLEVEL"4"

SIGN"EBCDIC"

ASSIGN"EXTERNAL"

NOBOUND

SETTINGS

REPORT-LINE"256"

WARNING"2"

TRACE

LIST()

詳細は、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』を参照してください。

コンパイル・コマンド

プログラムBATCH/PGMMB00.cblをコンパイルするコマンドは次のとおりです。

リスト1-52 MFコンパイルの例

# From $PROJECT/trf/BATCH

cd $PROJECT/trf/BATCH

export COBCPY=../DML:../Master-copy/COPY:../fixed-copy:.

export PCCINCLUDE="include=../Master-copy/COPY, include=../fixed-copies, include=."

cob -ug PGMMB00.cbl -C "use(../../compil_tools/opt.dir)" -C "list(PGMMB00.lst)" -C XREF -C SETTINGS 2> PGMMB00.err

説明:

•

opt.dirはコンパイル・オプションが指定されるファイルです。

•

コンパイル・エラーはPGMMB00.errに生成されます。

•

コンパイルはPGMMB00.lstにリストされます。

•

GMMB00.gntが生成されたらコンパイルは成功です。

注意:

プログラムをコンパイルする最良の方法は、コンパイルmakefileを使用する方法です。コンパイル・オプションおよび必要な構成を設定し、これらの操作に設計されたmakeツールを使用して、コンパイル手順を実行できます。

Simple Applicationの例の場合、他のプロジェクトに使用できるコンパイルmakefileがあります。「Makeファイルの使用」を参照してください。

Makeファイルの使用

構成

Simple Applicationの例とともに提供されるmakefileは、すべての変換操作を実装しており、次を適用することで他のプロジェクトでも使用できます。

•

必要な作業変数を設定します。

•

プロジェクト・プロパティおよび編成に応じてversion.mk構成ファイルを更新します。

この構成は、カタログ化の手順で開始された先行する構成に追加するものです。

makeコマンドを使用する前に、ユーザーはSimple Applicationで提供されたversion.mkの値を確認する必要があります。

リスト1-53 version.mkの例

#

# Defined extensions converted files

#

ext_trad = cbl

ext_trad_copy = cpy

ext_trad_ksh = ksh

ext_trad_map = bms

#

# Define Version variables

# Information

# with GLOBAL_VERSION=CURRENT all -v option in the makefile are ignored

#

GLOBAL_VERSION = M2_L3_5

CATALOG = $(GLOBAL_VERSION)

TRAD = $(GLOBAL_VERSION)

TRAD_JCLZ = $(GLOBAL_VERSION)

DATA_TOOLS = $(GLOBAL_VERSION)

RECONCIL_COPY = $(GLOBAL_VERSION)

TIMEOUT = 900

TIMEOUT_PARSE = 300

#

# Define Config and opt files

#

FILE_TRAD_JCL = "$(PARAM)/config-trad-JCL.desc"

FILE_TRAD_COBOL = "$(PARAM)/config-cobol"

COMM_TRADJCL = "-c $(FILE_TRAD_JCL)"

COMM_RECONCIL_COPY = "reconcil-copy-opt-imbr"

COBOL変換

COBOL変換を実行するには、次のコマンドを$SOURCEから実行します。

•

ソース・ディレクトリのすべてのプログラムを変換する場合

make trad

•

バッチ・プログラムだけを変換する場合

make trad_batch

•

CICSプログラムだけを変換する場合

make trad_cics

•

サブプログラムを変換する場合:

make trad_sub

コピーブックの調整

コピーブックを調整するには、次のコマンドを$SOURCEから呼び出します。

make reconcil_copy

COBOLコンバータのトラブルシューティング

変換中にエラー・メッセージが表示されたり、COBOLコンバータが中断されることがあります。エラー発生時に続行する方法の例として、いくつかのエラーを次に示します。

構成ファイルが存在しない

特に変換プロセスの最初で、構成ファイルが欠落している可能性があり、次のエラーを表示してCOBOLコンバータが異常終了することがあります。

メッセージ

構成/home2/wkb7/simpleapp/param/config-cobolを解析しています...

*致命的*: Hexa-map-file: このファイル'/home2/wkb7/simpleapp/param/tr-hexa.map'は存在しません

エラー: MESSAGE-ERRORのスローを捕捉できませんでした: MESSAGE-ERROR。

1 (中断)プロセスを終了します。

バックトレースの場合はb、続行する場合はc <option number>、他のオプションの場合は?を入力してください

解決策

欠落している構成ファイルを追加するか、リクエストされたファイル(この例ではtr-hexa.map)が不要な場合はメイン構成ファイルのその行を無効にします。

POBファイルの欠落

メッセージ

構成/home2/wkb7/simpleapp/param/config-cobolを解析しています...

ターゲット・ファイル/home2/wkb7/simpleapp/trf/CICS/PGMM002.cblを作成しています...

*致命的な内部エラー*: POBファイル/home2/wkb7/simpleapp/source/CICS/pob/PGMM002.cbl.pobが見つかりません; システムを再カタログ化してください。

終了

Rest in peace, Refine...

解決策

プログラムがまだカタログ化されていないか、.pobファイルが誤って削除されました。再カタログ化してリクエストされたファイルを生成します。

POBファイルが古すぎる

メッセージ

ターゲット・ファイル/home2/wkb7/simpleapp/trf/CICS/PGMM002.cblを作成しています...

*致命的な内部エラー*: POBファイル/home2/wkb7/simpleapp/source/CICS/pob/PGMM002.cbl.pobはソース・ファイル/home2/wkb7/simpleapp/source/CICS/PGMM002.cblよりも新しくありません; システムを再カタログ化してください。

解決策

このエラーは、ソース・プログラムの変更日がその対応するPOBファイルよりも新しい場合に発生します。POBファイルが生成された後でソース・プログラムが更新されることがあるため、プログラムを再カタログ化して最新の変更が含まれるようにします。

解析エラーの発生

解析エラーを含むプログラム、特にカタログ化中に致命的なエラーが発生したプログラムは変換されません。一般的にCOBOLコンバータでは重大度が致命的よりも下のエラーを含むプログラムは変換できます。

メッセージ

プログラム名はPGMM002です

警告:-- 行163で解析エラーが発生しました

*致命的*: ファイルCICS/PGMM002.cblに真の解析エラーが含まれます。中断しています!

終了

Rest in peace, Refine...

解決策

プログラムのソース・コードをチェックしてエラーを修正し、プログラムをカタログ化して再度変換します。

解析エラーの詳細は、カタログ化レポートおよびログで確認できます。原則として、カタログ化手順中に特定されたエラーを修正する前に、変換作業を開始しないでください。

JCL変換

JCLの変換は次の項で説明しています。

•

要件および前提条件

•

プラットフォーム移行プロセスにおけるCOBOLコンバータの概要

•

変換手順

•

Makeファイルの使用

要件および前提条件

カタログ化の要件

JCLトランスレータを実行する前に、移行するアセットの一貫性をチェックし、構文またはアセットの一貫性(欠落または未使用コンポーネント)に関連するエラーを修正するために、カタログ化は必須です。

データ変換

データ移行プロセスは、JCL変換が開始される前に実行しておく必要があります。この依存性は、ファイル移行ツールが、JCLトランスレータに読み取られる一部の構成ファイルを生成することが原因です。データ変換の構成ファイルについては、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』を参照してください。

プラットフォーム移行プロセスにおけるJCLトランスレータの概要

Tuxedo ART Workbench JCLトランスレータ・プロセスへの入力は次のとおりです。

•

カタロガにより生成されたPOBファイルに格納されているJCLの抽象構文ツリー。

•

File-to-Fileコンバータの変換およびDB2-to-Oracleコンバータの変換に関する情報を指定する、データ変換ツールにより生成された構成ファイルのセット。

•

次のいずれかの構成ファイルのセット。

•

他のOracle Tuxedo Application Rehosting Workbenchツール、Oracle表に変換するファイルのリストをJCLトランスレータに提供するDB2-to-Oracleコンバータにより生成されたもの

•

Tuxedo ART Workbenchとともに提供され、カスタマイズ可能なもの。

変換手順

この項では、次に関する情報と手順を説明します。

構成ファイルの作成と設定

変換手順

結果の確認

構成ファイルの作成と設定

カタロガにより生成された変換するJCLのASTに加え、Tuxedo ART Workbench JCLトランスレータは次のような様々な変換の要素を指定するメイン構成ファイルを入力として取得します。

•

カスタマイズ可能な最上位スケルトンと最下位スケルトン

•

移行するデータ・ファイル、一時ファイルおよびスプール・ファイルのルート・パス名

•

Oracle表に変換するデータ・ファイルのリスト

•

ターゲット・プラットフォームで使用するソート・ユーティリティ

•

コンポーネントおよびデータ・ファイルの名前の変更情報

•

プログラム・ランチャ構成

このファイルは、標準のテキスト・エディタを使用して記述したり、後述する他の情報ソースから生成することが簡単にできます。ここでは、Tuxedo ART Workbenchツールとともに提供される、STFILEORA Simple ApplicationでJCLファイルを変換するために作成された構成ファイルの例について説明します。

メイン構成ファイルは次のいずれかの個別のサブファイルも参照します。

•

他のTuxedo ART Workbenchツールにより生成されたもの。

•

Tuxedo ART Workbenchとともに提供され、カスタマイズ可能なもの。

•

完全にユーザーが作成したもの。

Tuxedo ART Workbenchは構成ファイルの例とともに提供されます。

JCL変換用のメイン構成ファイルは、このガイドではconfig-trad-JCL.descと呼ばれ、Simple Applicationアプリケーションとともに使用されます。

次の項では様々な構成パラメータと構成サブファイルについて説明し、この章の最後では完全なサンプルを提供します。

最上位スケルトンおよび最下位スケルトン

2つのオプションtop-skeletonおよびbottom-skeletonにより指定されたサブファイルは、それぞれ生成されたスクリプトのヘッダー・ファイルおよびフッター・ファイルを表します。これらのファイルはカスタマイズできます。

リスト1-54 メイン構成ファイルの最上位スケルトンおよび最下位スケルトン・エントリ

top-skeleton = "../param/top-ksh.txt"

bottom-skeleton = "../param/bottom-ksh.txt"

リスト1-55 top-ksh.txtのプロローグ・コードの例

#@(#)-------------------------------------------------------------------

#@(#)- SCRIPT NAME == $[JOBNAME].ksh --- VERSION OF $[DATE]

#@(#)- AUTHOR ==

#@(#)- TREATMENT ==

#@(#)- OBSERVATIONS == MAINFRAME MIGRATION

#@(#)- …..

説明:

JOBNAME

変換後に現在のJOBの名前を取得します。

DATE

KSHスクリプトの生成日です。

Oracle表に変換されるデータ・ファイルのリスト

ファイルがOracle表に変換されるとき、メイン構成ファイルは次のようなサブ構成ファイルを参照する必要があります。

file-list-in-table = "../param/dynamic-config/File-in-table.txt"

このサブファイルはFile-to-Fileコンバータにより生成されます。このファイルはJCLトランスレータにOracle表に変換されるファイルを示し、これらのファイルを含む手順を適切に変換できるようにします。例では、PJ01AAA.SS.VSAM.CUSTOMERが変換されるファイルです。

たとえば、JCLソースにOracle表に変換されるファイルが含まれている場合、対応するシェル・スクリプトはBatch Runtime関数m_ProgramExecを-bオプションを指定して使用し、COBOLプログラムを実行します。-bオプションはデータベースへの接続がプログラムの実行前に開いている必要があることを示します。例:

m_ProgramExec -b RSSABB01

ポストトランスレーション

オプションpost-translation-fileによって指定されたサブファイルには、Tuxedo ART Workbenchコンバータの後のポストトランスレーションの自動実行に使用される一連のルールが含まれています。Workbenchリファレンス・ガイドのPost-Translation構成ファイルに関する項を参照してください。

メイン構成ファイル内のポストトランスレーション・エントリは次のとおりです。

post-translation-file = "../param/renov.desc"

完全な構成例

一般オプションのroot-skeleton、target-proc、label-end、FSNの管理などは、『Oracle Tuxedo Application Workbenchリファレンス・ガイド』のJCLトランスレータに関する項で説明しています。

リスト1-56 Simple Application STFILEORA用のJCLトランスレータ構成ファイル(config-trad-JCL.desc)

% config.desc :

%

root-skeleton = "../trf-jcl/"

target-proc = "../trf-jcl/Master-Proc"

use-sort=mf-sort

%

var-dataroot = "${DATA}/"

var-tmp = "${TMP}/"

var-spool = "${SPOOL}/"

% Ksh heading

%

top-skeleton = "../param/top-ksh.txt"

% KSH footer

%

bottom-skeleton = "../param/bottom-ksh.txt"

% Files passed in tables

file-list-in-table = "../param/dynamic-config/File-in-table.txt"

% Post-Translation Configuration File

post-translation-file = "../param/renov.desc"

% Suffix of translated ksh du ksh traduit

suffix-skeleton = "ksh"

% Management of FSN to keep

set-no-delete-fsn = SORTIE ( ZIP390 ),

ENTREE ( ZIP390 ),

* ( DB2CMD,CSQUTIL ),

CFTIN ( CFTUTIL ),

SYSUT1 ( DUMMY ),

* ( ADRDSSU ).

% Management of FSN to delete

set-delete-fsn = SYSOUT ( IDCAMS ),

SYSEXEC ( CSCOLMVS ),

SYSTSIN ( * ),

SYSPUNCH ( * ),

TOOLIN ( * ),

SYSUDUMP ( * ),

SYSDBOUT ( * ),

SYSABOUT ( * ),

SYSTSPRT ( * ),

SORTLIB ( * ),

OPLIB ( * ),

STEPLIB ( * ),

JOBLIB ( * ).

ランチャの構成

このファイルは、プログラムが起動されるインスタンスを検出するためのソースJCLの解釈方法、およびこの起動操作の変換方法、つまりIKJEFT01、DLIBATCHおよびその他の標準ランチャの事前定義済の構成を記述しています。

リスト1-57 メイン構成ファイルのランチャ・エントリ

global-options jclz-launcher-spec-file = "launchers".

リスト1-58 ランチャ・コードの例

LAUNCHER DFSRRC00

IndexProg : 2,

IndexPSB : 3

END

LAUNCHER DB2BATCH

IndexProg : 2,

IndexPSB : 3

END

LAUNCHER SWCP7110

IndexProg : 2,

IndexParm : 4,

Separator : ";"

END

完全な構成例

一般オプションのroot-skeleton、target-proc、label-endなどは、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』のJCLトランスレータに関する項で説明しています。

リスト1-59 Simple Application用のJCLコンバータ構成ファイル(config-trad-JCL.desc)

%

% config.desc :

%

%

root-skeleton = "../trf-jcl/"

target-proc = "../trf-jcl/Master-Proc"

use-sort=mf-sort

%

%

var-dataroot = "${DATA}/"

var-tmp = "${TMP}/"

var-spool = "${SPOOL}/"

%

% Ksh heading

-------------------------------------------------------------------------

%

top-skeleton = "../param/top-ksh.txt"

% Ksh heading -------------------------------------------------------------------------

%

% KSH footer ------------------------------------------------------------------------

%

bottom-skeleton = "../param/bottom-ksh.txt"

%

% KSH footer --------------------------------------------------------------------------

%

% File passed in table

%

file-list-in-table = "../param/dynamic-config/File-in-table.txt"

% Suffix of translated ksh

suffix-skeleton = "ksh"

% Management of FSN to keep

set-no-delete-fsn = SYSIN ( DSNUTILB ),

OUTPUT ( ZIP390 ),

INPUT ( ZIP390 ),

* ( DB2CMD,CSQUTIL ),

CFTIN ( CFTUTIL ),

SYSUT1 ( DUMMY ),

* ( ADRDSSU ).

% Management of FSN to delete

set-delete-fsn = SYSOUT ( IDCAMS ),

SYSEXEC ( CSCOLMVS ),

SYSTSIN ( * ),

SYSIN ( IDCAMS,XMFSORT,ICEMAN,SPOOL,SORT ),

SYSPUNCH ( * ),

TOOLIN ( * ),

SYSUDUMP ( * ),

SYSDBOUT ( * ),

SYSABOUT ( * ),

SYSTSPRT ( * ),

SORTLIB ( * ),

OPLIB ( * ),

STEPLIB ( * ),

JOBLIB ( * ).

変換手順

Tuxedo ART Workbench JCLトランスレータは、移行プラットフォーム(Linux)で実行し、1つのジョブ・ファイル、一連のジョブ・ファイルまたはシステム・コンテンツ全体を自動的に変換できます。

環境変数の設定

変換の実行前に次の変数を設定する必要があります。

表1-32 トランスレータの変数

変数

値

使用方法

REFINEDIR

/product/art_wb11gR1/refine

Tuxedo ART Workbench製品のファイル構造。

PROJECT

$(HOME)/ simpleapp

プロジェクトの場所。

PARAM

$PROJECT/param

構成ファイルの場所。

SOURCE

$PROJECT/source

ソース・ファイルの場所。

LOGS

$PROJECT/Logs

ソース・ファイルの場所。

変換コマンド

次のコマンドを使用して変換を実行できます。ログ・ファイルは$LOGS/trad-jclに生成されます。

1つのJCLファイルを変換するコマンド行

入力ファイルとして同じ名前(.ksh接尾辞を除く)のKornシェル・スクリプトを作成する場合。

リスト1-60 1つのJCL変換スクリプト

cd $LOGS/trans-jcl

$REFINEDIR/refine jclz-unix -v version -s $PARAM/system.desc -c $PARAM/config-trad-JCL.desc JCL/defvcust.jcl

JCLファイルのリストを変換するコマンド行

次のコマンドを起動するJCLファイルのリストを変換する場合。

リスト1-61 JCLのリストの変換スクリプト

cd $LOGS/trans-jcl

$REFINEDIR/refine jclz-unix -v version -s $PARAM/system.desc -c $PARAM/config-trad-JCL.desc -f jcl-files-list

すべてのJCLファイルを変換するコマンド行

次のコマンドを起動するすべてのJCLファイルを変換する場合。

リスト1-62 すべてのJCLの変換スクリプト

cd $LOGS/trans-jcl

$REFINEDIR/refine jclz-unix -v version -s $PARAM/system.desc -c $PARAM/config-trad-JCL.desc

JCLポストトランスレーション手順

JCL変換の制限により、またはサイト固有の変換が必要な場合、反復的なポストトランスレーション・タスクを自動的に実行する場合があります。

ポストトランスレーションのメカニズムにより、別の内容で行の1ブロックを変更できます。

ポストトランスレーションの例

ポストトランスレーションの使用方法を示すために、次の例では、/prtvcust.ksh JCLスクリプト内のm_ProgramExec IEFBR14 ""を含む行の後にコメントを追加しています。

1.

renov-jcl.descに次のルールを書き込みます。

# by user John Doe on YY/MM/DD

regle add-comment-1

filtre [

+JCL/prtvcust.ksh

]

transform [

m_FileAssign -m R -a R -d SHR VKSDCUST ${DATA}/METAW00.VSAM.CUSTOMER

m_ProgramExec PGMMB01 ""

]

into [

m_FileAssign -m R -a R -d SHR VKSDCUST ${DATA}/METAW00.VSAM.CUSTOMER

m_ProgramExec PGMMB01 ""

# Added comment

2.

コマンド行を起動します。

$REFINEDIR/M2_L3_5/scripts/post-trans -c=\#META-RENOV\# -r=$PROJECT/param/renov-jcl.desc JCL/prtvcust.ksh < JCL/prtvcust.ksh > JCL/prtvcust.ksh.renov

grep -v "#META-RENOV#" JCL/prtvcust.ksh.renov > JCL/prtvcust.ksh

結果の確認

変換結果を確認するには、次のことを検証します。

•

必要とするファイルがすべて生成されています。

•

すべての対応するkshスクリプトが生成されています。

•

すべてのprocとインクルードが抽出されています。

•

空のスクリプトがありません。

•

切り捨てられたスクリプトがありません。

エラー・メッセージを確認します。JCLトランスレータは変換中に発生したエラー・メッセージを生成されるスクリプトに出力します。キーワードUNDEFINED、NIL、UNTRANSLATEDを検索して、メッセージが存在するかどうかを確認します。エラー・メッセージとその説明の完全なリストは、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』を参照してください。

•

プロシージャを制御します

•

Batch RunTime機能を制御します。

•

不当な警告メッセージがないことを確認します。

Makeファイルの使用

次のことができるようになるため、Tuxedo ART Workbenchを使用する場合はmakefileの使用をお薦めします。

•

すべての(実行可能)プロセスのドキュメント化

•

増分操作の効率的な管理とそれによる時間の節約。

•

プロセスの結果の制御と確認

makefileはプロジェクトの初期化時に操作が実装されたソース・ディレクトリに置かれる必要があります。

構成

「カタロガ」のMake構成に関する項を参照してください。

JCL変換

$SOURCEファイル・システムのすべてのJCLを変換する場合

$SOURCEディレクトリから次のコマンドを起動します。

make trad_jcl

JCLは1つずつ順次変換されます。

構成

データベース、コンパイラ、その他

ソースをコンパイルするには、いくつかの情報を収集する必要があります。これらの情報は構成ウィザードに入力できます。

COBOL-ITをターゲットのCOBOLコンパイラとして選択して、ISAMファイルをオープン・システムで使用する場合は、BDB DbHomeの場所を設定する必要があります。これは、データベースとログ・ファイルが格納されるディレクトリを指している必要があります。詳細は、『COBOL-IT Compiler Suite Enterprise Edition - Reference Manual』の「Oracle Berkeley DB」または『Berkeley DB Programmer's Reference Guide』の「The Berkeley DB Environment」を参照してください。

ビルドが完了すると、ルートmakefileとサブmakefileが関連するサブディレクトリの下に生成されます。また、fixed-copyディレクトリ全体がWorkbenchインストール・ディレクトリからビルド・ディレクトリにコピーされます。

Tuxedo

Tuxedoウィザードの主要機能は、Batch RuntimeとCICS Runtime用にubbconfigファイルを生成することです。

構成可能な項目には、Tuxedoの場所、IPCキー、マシン名、APPDIRなどがあります。詳細は、Oracle Tuxedo 12cリリース2 (12.2.2)を参照してください。

CICS

CICSウィザードの主要機能は、CICS Runtime用にsetenvファイルを生成することです。構成可能な項目には、CICS Runtimeの場所、共通の作業領域とモニター設定用のIPCキーがあります。

詳細は、Oracle Tuxedo Application Runtime for CICS and Batch 12cリリース2 (12.2.2)を参照してください。

Batch

Batchウィザードの主要機能は、Batch Runtime用にjesconfigとsetenvファイルを生成することです。構成可能な項目には、Batch Runtimeの場所、JESROOTなどが含まれます。

詳細は、Oracle Tuxedo Application Runtime for CICS and Batch 12cリリース2 (12.2.2)を参照してください。

IMS

IMSウィザードの主要機能は、IMS Runtime用にsetenvファイルを生成することです。構成可能な項目には、IMS Runtimeの場所などがあります。

詳細は、Oracle Tuxedo Application Runtime for IMS 12cリリース2 (12.2.2)を参照してください。

ビルド

アプリケーション・コンポーネント、データ再ロード・プログラム、データ・アクセス・プログラムおよびTUXEDO構成ファイルをビルドするように、ビルド手順によりユーザーをガイドします。

gmakeユーティリティはビルド・タスクの実行時に使用されます。関連するmakefileは前の手順で生成されます。

デプロイ

Pack Target

3つのtarファイルが生成され、これらには、デプロイ・ディレクトリの下にあるファイルがすべて格納されます。このtarファイルはデプロイの準備ができています。

アプリケーションのデプロイ

ユーザーが指定した場所にtarファイルを解凍します。

Runtimeの設定

Batch Runtime環境の設定

Batch Runtimeの環境を準備します。詳細は、Oracle Tuxedo Application Runtime for CICS and Batch 12cリリース2 (12.2.2)を参照してください。

CICS Runtime環境の設定

CICS Runtimeの環境を準備します。詳細は、Oracle Tuxedo Application Runtime for CICS and Batch 12cリリース2 (12.2.2)を参照してください。

IMS Runtime環境の設定

IMS Runtimeの環境を準備します。詳細は、Oracle Tuxedo Application Runtime for IMS 12cリリース2 (12.2.2)を参照してください。

ファイル・データのリロード

定義されているすべてのファイルが表に表示されます。表の最後の列をクリックすると、ソースの場所の下にあるファイルがリストされます。

「終了」をクリックすると、ユーザーが指定した場所にリロードの結果がすべて格納されます。

DB2データのリロード

この手順は前の手順と似ていますが、ユーザーが指定したファイル・パスではなくデータベースに結果データが格納されます。

実行

CICS Runtime

ART CICS Runtimeの起動または停止

Batch Runtime

ART Batch Runtimeを起動または停止して、ART Batch Runtimeのジョブを操作します。

IMS Runtime

ART IMS Runtimeを起動または停止します。

リセット

対応する手順からの出力をクリーンアップします。

データ移行の実行

File-to-Fileで生成されたコンバータ・プログラムの実行

この項では、Tuxedo ART Workbenchを使用して生成されたコンポーネント(「コンポーネントの生成」を参照)を使用する、アンロード、転送および再ロードのタスクについて説明します。

準備

環境の構成およびコンポーネントのインストール

z/OSでのアンロード・コンポーネントのインストール

アンロードに使用されるコンポーネント($HOME/trf/unload/fileに生成)は、ソースz/OSプラットフォームにインストールする必要があります。生成されたJCLは、JOBカード、ライブラリ・アクセス・パス、入力および出力ファイル(データ・セット名: DSN)へのアクセス・パスを含む、特定のサイトの制約への適合が必要な場合があります。

ターゲット・プラットフォームへの再ロード・コンポーネントのインストール

再ロードに使用されるコンポーネント($HOME/trf/reload/fileに生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。

次の環境変数をターゲット・プラットフォームに設定する必要があります。

表1-33 変数とそのターゲット・プラットフォーム

変数

値

DATA_SOURCE

再ロードするためにz/OSから転送されたファイルを含むディレクトリの名前。

BIN

汎用的な再ロードおよび制御スクリプトの場所($HOME/trf/reload/bin)

TMPPROJECT

一時ディレクトリ。

MT_LOG

実行ログを含むディレクトリ。

DATA

トランスコードおよび再ロード・プロセスからの出力ファイルを含むディレクトリ。これらはターゲット・プラットフォームで使用できるファイルです。

COB_EXTFH_INDEXED COB_EXTFH_LIB

ターゲットのCOBOLコンパイラとしてCOBOL-ITを選択し、オープン・システムでISAMファイルとしてBDBを使用する場合は、BatchRTがBDB形式のファイルを生成できるように、これらの2つの環境変数を設定する必要があります。そうしないと、Micro Focus COBOL互換ファイルが生成されます。

export COB_EXTFH_INDEXED=BDBEXTFH

export COB_EXTFH_LIB=/path_to_Cobol-IT/lib/libbdbextfh.so

例:

export COB_EXTFH_LIB=/opt/cobol-it-64/lib/libbdbextfh.so

アンロード用JCL

アンロード用JCLが、データマップ・パラメータ・ファイル(Datamap-<configuration name>.re)にリストされた各z/OSファイルに対して生成されます。これらのアンロード用JCLの名前は<論理ファイル名>.jclunloadです。

注意:

.jclunload拡張子は、z/OSで実行する場合には削除する必要があります。

ファイルの転送

ファイルは、サイトで使用可能なファイル転送ツール(CFT、FTPなど)を使用して、バイナリ形式で、ソースz/OSプラットフォームとターゲット・プラットフォーム間で転送される必要があります。

トランスコード・プログラムのコンパイル

トランスコードおよび再ロードに使用される生成されたCOBOLプログラムの名前は次のとおりです。

RELFILE-<論理ファイル名>

マッピング・パラメータ・ファイル(mapper-<configuration name>.re)での例で、生成されるプログラムは次のとおりです。

•

RELFILE-FQSAM01.cbl。

•

RELFILE-FQSAM02.cbl。

•

RELFILE-ODCSF0B.cbl。

シーケンシャル・ファイル(VSAM ESDS、QSAM、世代別データ・セット)

シーケンシャル・ファイルの移行時には、ターゲットのCOBOL LINE SEQUENTIAL出力ファイルが生成されます。

リスト1-63 FILE CONTROLの例 - プログラム: RELFILE-FQSAM01.cblからの抽出:

…

SELECT SORTIE

ASSIGN TO "SORTIE"

ORGANIZATION IS LINE SEQUENTIAL

FILE STATUS IS IO-STATUS.

…

VSAM KSDSファイル

VSAM KSDSファイルの移行時には、INDEXED出力ファイルが生成されます。

リスト1-64 FILE CONTROLの例 - プログラム: RELFILE-ODCSF0B.cblからの抽出:

…

SELECT MW-SORTIE

ASSIGN TO "SORTIE"

ORGANIZATION IS INDEXED

ACCESS IS DYNAMIC

RECORD KEY IS VS-CUSTIDENT

FILE STATUS IS IO-STATUS.

…

これらのCOBOLプログラムは、『Tuxedo ART Workbenchリファレンス・ガイド』のCOBOLコンバータに関する項に記載されたオプションを使用して、ターゲットのCOBOLコンパイラでコンパイルされる必要があります。

トランスコードおよび再ロード・スクリプトの実行

トランスコードおよび再ロード・スクリプトは次のパラメータを使用します。

形式

loadfile-<logical file name>.ksh [-t/-l] [-c <method>]

loadgdg-<logical file name>.ksh [-t/-l] [-c <method>]

オプション

-t

ファイルをトランスコードおよび再ロードします。

-l

ファイルをトランスコードおよび再ロードします(-tと同じ動作)。

-c ftp:<…>:<…>

転送の検証を実装します(「転送のチェック」を参照)。

例

マッピング・パラメータ・ファイル(mapper-<configuration name>.re)での例で、生成されるスクリプトは次のとおりです。

•

loadfile-FQSAM01.ksh。

•

loadfile-FQSAM02.ksh

•

loadfile-ODCSF0B.ksh。

ファイル

デフォルトでは、入力ファイルは$DATA_SOURCEで示されたディレクトリに置かれ、出力ファイルは$DATAで示されたディレクトリに置かれます。

これらのファイル名は、マッピング・パラメータ・ファイル(mapper-<configuration name>.re)で使用される論理ファイル名を使用して付けられます。

実行ログは$MT_LOGで示されたディレクトリに作成されます。

問題が発生すると、ゼロ以外のリターン・コードが生成されます。

転送のチェック

このチェックでは、次のloadfile-<logical file name>.kshのオプションを使用します

-c ftp:<name of transferred physical file>:<name of FTP log under UNIX>

注意:

このオプションは、再ロード後、z/OSから転送された物理ファイルとターゲット・プラットフォームに再ロードされたファイルに、同じレコード数が含まれていることを検証します。このチェックは、FTPログと再ロード・プログラムの実行レポートを使用して実行されます。レコード数が異なる場合は、エラー・メッセージが生成されます。

トラブル・シューティング

この項では、ファイルをソースからターゲット・プラットフォームへ移行するときに発生した使用エラーにより生じる問題について説明します。

概要

Tuxedo ART Workbenchツールを実行するときに、ユーザーは次のことを確認する必要があります。

•

画面にエラー・メッセージが表示されているか。

•

Mapper-log-<configuration name>ファイルにエラーが含まれているか(「共通の問題と解決策」を参照)。

エラー・メッセージと関連する説明はOracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドの付録にリストされています。

共通の問題と解決策

エラー: 不明なファイル編成*UNDEFINED*

file.sh -gmi $HOME/trf STFILEORAの実行時に次のメッセージが表示されます。

調整エラー...

ログ

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ファイルには存在しません。

エラー: レコード...がありません

file.sh -gmi $HOME/trf STFILEORA1の実行時に次のメッセージが表示されます。

調整エラー...

ログ

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

説明

コピー・ファイルが不明です。

エラー: レコード...がありません

file.sh -gmi $HOME/trf STFILEORA2の実行時に次のメッセージが表示されます。

調整エラー...

ログ

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

説明

RECORD名(レベル01フィールド)が不明です。

エラー: 外部変数PARAMが設定されていません

file.sh -gmi $HOME/trf STFILEORA3の実行時に次のメッセージが表示されます。

調整エラー...

ログ

Mapper-log-STFILEORA3ログ・ファイルの内容には次が含まれます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

############################################################################

Control of schema STFILEORA3

外部変数PARAMが設定されていません。

ERROR : Check directive files for schema STFILEORA3

説明

変数$PARAMが設定されていません。

File-to-Oracleで生成されたコンバータ・プログラムの実行

この項では、Tuxedo ART Workbenchを使用して生成されたコンポーネント(「コンポーネントの生成」を参照)を使用する、アンロード、転送および再ロードのタスクについて説明します。

準備

環境の構成およびコンポーネントのインストール

z/OSでのアンロード・コンポーネントのインストール

アンロードに使用されるコンポーネント($HOME/trf/unload/fileに生成)は、ソースz/OSプラットフォームにインストールする必要があります。生成されたJCLは、JOBカード、ライブラリ・アクセス・パス、入力および出力ファイル(データ・セット名: DSN)へのアクセス・パスを含む、特定のサイトの制約への適合が必要な場合があります。

UNIXでの再ロード・コンポーネントのインストール

再ロードに使用されるコンポーネント($HOME/trf/reload/fileに生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。

Oracleオブジェクト作成コンポーネントのインストール

Oracleオブジェクトの作成に使用されるコンポーネント($HOME/SQL/file/<schema name>に生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。

ターゲット・プラットフォーム環境変数の設定

表1-34は、ターゲット・プラットフォームに設定する必要がある環境変数を示しています。

表1-34 環境変数とそのプラットフォーム

変数

値

DATA_SOURCE

再ロードするためにz/OSから転送されたファイルを含むディレクトリの名前。

DATA

ASCII形式に変換され、Oracle表に再ロードする準備のできた物理ファイルを含むディレクトリの名前。

BIN

汎用的な再ロードおよび制御スクリプトの場所($HOME/trf/reload/bin)

TMPPROJECT

一時ディレクトリ。

MT_LOG

実行ログを含むディレクトリ。

NLS_LANG

Oracleドキュメントでの説明に従って設定します。

DDL

Oracleオブジェクトを作成するために使用するSQLスクリプトの場所($HOME/trf/SQL/file/<schema name>)。

次の変数はOracle Tuxedo Application Rehosting Workbenchインストレーション・ガイドの情報に従って設定する必要があります。

•

MT_DB_LOGIN。

JCLのアンロード

アンロード用JCLが、データマップ・パラメータ・ファイル(Datamap-<configuration name>.re)にリストされた各z/OSファイルに対して生成されます。これらのアンロード用JCLの名前は<論理ファイル名>.jclunload.です。これらのJCLはIDCAMSユーティリティのREPRO機能を使用してファイルをアンロードします。

注意:

.jclunload拡張子は、z/OSで実行する場合には削除する必要があります。

ファイルの転送

ファイルは、サイトで使用可能なファイル転送ツール(CFT、FTPなど)を使用して、バイナリ形式で、ソースz/OSプラットフォームとターゲットUNIXプラットフォーム間で転送される必要があります。

トランスコード・プログラムのコンパイル

トランスコードおよび再ロードに使用される生成されたCOBOLプログラムの名前は次のとおりです。

RELTABLE-<論理ファイル名>

例:

RELTABLE-ODCSF0.pco

これらのCOBOLプログラムは、『Oracle Tuxedo Application Workbenchリファレンス・ガイド』のCOBOLコンバータに関する項に記載されたオプションを使用して、ターゲットのCOBOLコンパイラでコンパイルされる必要があります。

各プログラムはSQL*LOADERユーティリティで使用できるようになる出力ファイルを生成します。

Oracleオブジェクト作成スクリプトの実行

loadtable-<…>.kshスクリプトのオプション-dにより、Oracleオブジェクトを作成できます。

トランスコードおよび再ロード・スクリプトの実行

トランスコードおよび再ロード・スクリプトには次のパラメータがあります。

形式

loadtable-<logical file name>.ksh [-d] [-t/-l] [-c <method>]

オプション

-d

Oracleオブジェクトを作成します。

-t

ファイルをトランスコードおよび再ロードします。

-l

ファイルをトランスコードおよび再ロードします(-tと同じ動作)。

-c ftp:<…>:<…>

転送の検証を実装します(「転送のチェック」を参照)。

例

マッピング・パラメータ・ファイル(mapper-<configuration name>.re)での例で、生成されるスクリプトは次のとおりです。

•

loadtable-ODCSF0B.ksh

ファイル

デフォルトでは、入力ファイルは$DATA_SOURCEで示されたディレクトリに置かれ、出力ファイルは$DATAで示されたディレクトリに置かれます。

これらのファイル名は、マッピング・パラメータ・ファイル(mapper-<configuration name>.re)構成ファイルで使用される論理ファイル名を使用して付けられます。

実行ログは$MT_LOGで示されたディレクトリに作成されます。

問題が発生すると、ゼロ以外のリターン・コードが生成されます。

転送のチェック

この確認は次のloadtable-<logical file name>.kshのオプションを使用します

-c ftp:<name of transfered physical file>:<name of FTP log under UNIX>

注意:

このオプションにより、再ロード後、z/OSから転送された物理ファイルとターゲット・プラットフォームに再ロードされたファイルに、同じレコード数が含まれていることを検証できます。このチェックは、FTPログと再ロード・プログラムの実行レポートを使用して実行されます。レコード数が異なる場合は、エラー・メッセージが生成されます。

アクセス・ルーチンとユーティリティのコンパイル

COBOLおよびPRO*COBOLアクセス・ルーチンは『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』に記載されたターゲットのCOBOLコンパイル・オプションを使用してコンパイルされる必要があります。

トラブル・シューティング

この項では、ファイルをソースからターゲット・プラットフォームへ移行するときに発生した使用エラーにより生じる問題について説明します。

概要

Tuxedo ART Workbenchツールを実行するときに、ユーザーは次のことを確認する必要があります。

•

画面にエラー・メッセージが表示されているか。

•

Mapper-log-<configuration name>ファイルにエラーが含まれているか(「共通の問題と解決策」を参照)。

エラー・メッセージとその説明は、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』の付録に記載されています。

共通の問題と解決策

エラー: 外部変数PARAMが設定されていません

file.sh -gmi $HOME/trf STFILEORAの実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-

########################################################################

構成STFILEORAの制御

外部変数PARAMが設定されていません。

エラー: 構成STFILEORAのディレクティブ・ファイルを確認してください

Abort

説明

変数$PARAMが設定されていません。

エラー: ターゲット・ディレクトリが存在しません

file.sh -gmi $HOME/trf STFILEORA1の実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-

Target output directory /home2/wkb9/trf is missing

パラメータをチェックしてください: -i <output_directory> <schema>

ERROR : usage : file.sh [ [-g] [-m] [-i <output_directory>] <schema_name> | -s <output_directory> (<schema>,...) ]

abort

エラー: 不明なファイル編成です

file.sh -gmi $HOME/trf STFILEORA2の実行時に次のメッセージが表示されます。

調整エラー...

ログ

Mapper-log-STFILEORA2ログ・ファイルの内容には次が含まれます。

file PJ01AAA.SS.VSAM.CUSTOMER Oracle

file logical name ODCSF0B

*** Unknown file organization : INDEXD

mapping record VS-ODCSF0-RECORD

record VS-ODCSF0-RECORD: logical name VS

record VS-ODCSF0-RECORD: logical name VS

record VS-ODCSF0-RECORD REDEFINES:

field VS-CUSTBDATE as opaque (default strategy)

record VS-ODCSF0-RECORD REDEFINES:

field VS-CUSTBDATE as opaque (default strategy)

説明

このファイルはINDEXEDではなくINDEXDのファイル編成で構成されています。

エラー: 不正なテキスト: "converted

file.sh -gmi $HOME/trf STFILEORAの実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-

##########################################################################

構成STFILEORAの制御

##############################

Control of templates

OK: Use Default Templates list file

File name is /REFINE/convert-data/default/file/file-templates.txt

##############################

Control of Mapper

##############################

COMPONENTS GENERATION

…

Parsing mapper file /home2/wkb9/tmp/mapper-STFILEORA.re.tmp ...

Parse error at character position 1346 in file:

/home2/wkb9/tmp/mapper-STFILEORA.re.tmp.

The illegal text is: "converrted

table name CUSTOMER

include \"COPY/ODCSF0B.cpy\"

map record VS-ODCSF0-RECORD defin"

While parsing in grammar UFAS-CONVERTER::MAPPER-INPUT-GRAMMAR,

CONVERRTED is a symbol, which is not a legal token

at this point in the input. The legal tokens at this point are:

:END "templates" "filler" "field" "file" "one-for-n" "multi-record" "table" "transferred" "mode-tp" ... [14 others]

*ERROR*: parse error is found in /home2/wkb9/tmp/mapper-STFILEORA.re.tmp.

調整エラー...

/tmp/refine-exit-status.snICMmElNYF25625

エラー: 生成が中断されました

abort

説明

マッピング・ファイルで‘CONVERTED’という語句に入力エラーが起こりました。

エラー: PJ01AAA.SS.VSAM.CUSTOMERSという名前のファイル表にファイルが見つかりません

file.sh -gmi $HOME/trf STFILEORAの実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-==-=-=-=

##########################################################################

構成STFILEORAの制御

##############################

Control of templates

Project Templates list file is missing /home2/wkb9/param/file/file-templates.txt

OK: Use Default Templates list file

File name is /Qarefine/release/M2_L4_1/convert-data/default/file/file-templates.txt

##############################

Control of Mapper

##############################

COMPONENTS GENERATION

…

Point 1 !!

Warning: Can't find file in file table named PJ01AAA.SS.VSAM.CUSTOMERS

Point 2 !!

…

調整エラー...

/tmp/refine-exit-status.IvmFDYsYDdr31956

ERROR : generation aborted

Abort

説明

Oracle表に変換するファイルの名前が、データマップ・ファイルに存在する名前と一致しません。

File-to-UDB (以前はDB2/Luw)コンバータ・プログラムの実行

この項では、Tuxedo ART Workbenchを使用して生成されたコンポーネント(「コンポーネントの生成」を参照)を使用する、アンロード、転送および再ロードのタスクについて説明します。

準備

環境の構成およびコンポーネントのインストール

z/OSでのアンロード・コンポーネントのインストール

アンロードに使用されるコンポーネント($HOME/trf/unload/fileに生成)は、ソースz/OSプラットフォームにインストールする必要があります。生成されたJCLは、JOBカード、ライブラリ・アクセス・パス、入力および出力ファイル(データ・セット名: DSN)へのアクセス・パスを含む、特定のサイトの制約への適合が必要な場合があります。

UNIXでの再ロード・コンポーネントのインストール

再ロードに使用されるコンポーネント($HOME/trf/reload/fileに生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。

DB2/luw (udb)オブジェクト作成コンポーネントのインストール

Oracleオブジェクトの作成に使用されるコンポーネント($HOME/SQL/file/<schema name>に生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。

ターゲット・プラットフォーム環境変数の設定

次の環境変数をターゲット・プラットフォームに設定する必要があります。

表1-35 ターゲット・プラットフォームの環境変数

変数

値

DATA_SOURCE

再ロードするためにz/OSから転送されたファイルを含むディレクトリの名前。

DATA

ASCII形式に変換され、Oracle表に再ロードする準備のできた物理ファイルを含むディレクトリの名前。

BIN

汎用的な再ロードおよび制御スクリプトの場所($HOME/trf/reload/bin)

TMPPROJECT

一時ディレクトリ。

MT_LOG

実行ログを含むディレクトリ。

NLS_LANG

Oracleドキュメントでの説明に従って設定します。

DDL

Oracleオブジェクトを作成するために使用するSQLスクリプトの場所($HOME/trf/SQL/file/<schema name>)。

PATH

このUNIX/Linux変数は、Oracle Tuxedo Application Runtime for Batchユーティリティのディレクトリを含む必要があります

次の変数はOracle Tuxedo Application Rehosting Workbenchインストレーション・ガイドの情報に従って設定する必要があります。

•

MT_DB_DBNAME。

•

MT_DB_USER。

•

MT_DB_PWD。

JCLのアンロード

アンロード用JCLが、データマップ・パラメータ・ファイル(Datamap-<configuration name>.re)にリストされた各z/OSファイルに対して生成されます。これらのアンロード用JCLの名前は<論理ファイル名>.jclunload.です。これらのJCLはIDCAMSユーティリティのREPRO機能を使用してファイルをアンロードします。

注意:

.jclunload拡張子は、z/OSで実行する場合には削除する必要があります。

ファイルの転送

ファイルは、サイトで使用可能なファイル転送ツール(CFT、FTPなど)を使用して、バイナリ形式で、ソースz/OSプラットフォームとターゲットUNIXプラットフォーム間で転送される必要があります。

トランスコード・プログラムのコンパイル

トランスコードおよび再ロードに使用される生成されたCOBOLプログラムの名前は次のとおりです。

RELTABLE-<論理ファイル名>

例:

RELTABLE-ODCSF0.sqb

これらのCOBOLプログラムは、Tuxedo ART Workbenchリファレンス・ガイドのCOBOLコンバータに関する項に記載されたオプションを使用して、ターゲットのCOBOLコンパイラでコンパイルされる必要があります。

各プログラムはSQL*LOADERユーティリティで使用できるようになる出力ファイルを生成します。

Oracleオブジェクト作成スクリプトの実行

loadtable-<…>.kshスクリプトのオプション-dにより、Oracleオブジェクトを作成できます。

トランスコードおよび再ロード・スクリプトの実行

トランスコードおよび再ロード・スクリプトには次のパラメータがあります。

形式

loadtable-<logical file name>.ksh [-d] [-t/-l] [-c <method>]

オプション

-d

DB2/luw (udb)オブジェクトを作成します。

-t

ファイルをトランスコードおよび再ロードします。

-l

ファイルをトランスコードおよび再ロードします(-tと同じ動作)。

-c ftp:<…>:<…>

転送の検証を実装します(「転送のチェック」を参照)。

例

マッピング・パラメータ・ファイル(mapper-<configuration name>.re)での例で、生成されるスクリプトは次のとおりです。

•

loadtable-ODCSF0B.ksh

ファイル

デフォルトでは、入力ファイルは$DATA_SOURCEで示されたディレクトリに置かれ、出力ファイルは$DATAで示されたディレクトリに置かれます。

これらのファイル名は、マッピング・パラメータ・ファイル(mapper-<configuration name>.re)構成ファイルで使用される論理ファイル名を使用して付けられます。

実行ログは$MT_LOGで示されたディレクトリに作成されます。

問題が発生すると、ゼロ以外のリターン・コードが生成されます。

転送のチェック

この確認は次のloadtable-<logical file name>.kshのオプションを使用します

-c ftp:<name of transfered physical file>:<name of FTP log under UNIX>

注意:

このオプションにより、再ロード後、z/OSから転送された物理ファイルとターゲット・プラットフォームに再ロードされたファイルに、同じレコード数が含まれていることを検証できます。このチェックは、FTPログと再ロード・プログラムの実行レポートを使用して実行されます。レコード数が異なる場合は、エラー・メッセージが生成されます。

アクセス・ルーチンとユーティリティのコンパイル

COBOLおよび埋込みSQLアクセス・ルーチンは、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』に記載されたターゲットのCOBOLコンパイル・オプションを使用してコンパイルされる必要があります。

トラブル・シューティング

この項では、ファイルをソースからターゲット・プラットフォームへ移行するときに発生した使用エラーにより生じる問題について説明します。

概要

Tuxedo ART Workbenchツールを実行するときに、ユーザーは次のことを確認する必要があります。

•

画面にエラー・メッセージが表示されているか。

•

Mapper-log-<configuration name>ファイルにエラーが含まれているか(「共通の問題と解決策」を参照)。

エラー・メッセージと関連する説明はOracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドの付録にリストされています。

共通の問題と解決策

エラー: 外部変数PARAMが設定されていません

file.sh -gmi $HOME/trf STFILEUDBの実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-

########################################################################

構成STFILEUDBの制御

外部変数PARAMが設定されていません。

エラー: 構成STFILEUDBのディレクティブ・ファイルを確認してください

Abort

説明

変数$PARAMが設定されていません。

エラー: ターゲット・ディレクトリが存在しません

file.sh -gmi $HOME/trf STFILEUDB1の実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-

Target output directory /home2/wkb9/trf is missing

パラメータをチェックしてください: -i <output_directory> <schema>

ERROR : usage : file.sh [ [-g] [-m] [-i <output_directory>] <schema_name> | -s <output_directory> (<schema>,...) ]

abort

エラー: 不明なファイル編成です

file.sh -gmi $HOME/trf STFILEUDB2の実行時に次のメッセージが表示されます。

調整エラー...

ログ

Mapper-log-STFILEUDB2ログ・ファイルの内容には次が含まれます。

file PJ01AAA.SS.VSAM.CUSTOMER Oracle

file logical name ODCSF0B

*** Unknown file organization : INDEXD

mapping record VS-ODCSF0-RECORD

record VS-ODCSF0-RECORD: logical name VS

record VS-ODCSF0-RECORD: logical name VS

record VS-ODCSF0-RECORD REDEFINES:

field VS-CUSTBDATE as opaque (default strategy)

record VS-ODCSF0-RECORD REDEFINES:

field VS-CUSTBDATE as opaque (default strategy)

説明

このファイルはINDEXEDではなくINDEXDのファイル編成で構成されています。

エラー: 不正なテキスト: "converted

file.sh -gmi $HOME/trf STFILEUDBの実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-

##########################################################################

構成STFILEUDBの制御

##############################

Control of templates

OK: Use Default Templates list file

File name is /REFINE/convert-data/default/file/file-templates-db2luw.txt

##############################

Control of Mapper

##############################

COMPONENTS GENERATION

…

Parsing mapper file /home2/wkb9/tmp/mapper-STFILEUDB.re.tmp ...

Parse error at character position 1346 in file:

/home2/wkb9/tmp/mapper-STFILEUDB.re.tmp.

The illegal text is: "converrted

table name CUSTOMER

include \"COPY/ODCSF0B.cpy\"

map record VS-ODCSF0-RECORD defin"

While parsing in grammar UFAS-CONVERTER::MAPPER-INPUT-GRAMMAR,

CONVERRTED is a symbol, which is not a legal token

at this point in the input. The legal tokens at this point are:

:END "templates" "filler" "field" "file" "one-for-n" "multi-record" "table" "transferred" "mode-tp" ... [14 others]

*ERROR*: parse error is found in /home2/wkb9/tmp/mapper-STFILEUDB.re.tmp.

調整エラー...

/tmp/refine-exit-status.snICMmElNYF25625

エラー: 生成が中断されました

abort

説明

マッピング・ファイルで‘CONVERTED’という語句に入力エラーが起こりました。

エラー: PJ01AAA.SS.VSAM.CUSTOMERSという名前のファイル表にファイルが見つかりません

file.sh -gmi $HOME/trf STFILEORAの実行時に次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-==-=-=-=

##########################################################################

構成STFILEUDBの制御

##############################

Control of templates

Project Templates list file is missing /home2/wkb9/param/file/file-templates.txt

OK: Use Default Templates list file

File name is /Qarefine/release/M2_L4_1/convert-data/default/file/file-templates.txt

##############################

Control of Mapper

##############################

COMPONENTS GENERATION

…

Point 1 !!

Warning: Can't find file in file table named PJ01AAA.SS.VSAM.CUSTOMERS

Point 2 !!

…

調整エラー...

/tmp/refine-exit-status.IvmFDYsYDdr31956

ERROR : generation aborted

Abort

説明

DB2/luw (udb)表に変換するファイルの名前が、データマップ・ファイルに存在する名前と一致しません。

DB2-to-Oracleで生成されたコンバータ・プログラムの実行

この項では、Tuxedo ART Workbenchを使用して生成されたコンポーネント(「コンポーネントの生成」を参照)を使用する、アンロード、転送および再ロードのタスクについて説明します。

準備

環境の構成およびコンポーネントのインストール

z/OSでのアンロード・コンポーネントのインストール

アンロードに使用されるコンポーネント($HOME/trf/unload/rdbmsに生成)は、ソースz/OSプラットフォームにインストールする必要があります。生成されたJCLは、JOBカード、ライブラリ・アクセス・パス、入力および出力ファイル(データ・セット名: DSN)へのアクセス・パスを含む、特定のサイトの制約への適合が必要な場合があります。

DBのロード/アンロード用COBOLプログラムのターゲット・プラットフォームへのインストール

DBのロード/アンロード用COBOLプログラム($HOME/trf/DSNUTILS/<schema name>に生成)は、コンパイルしてターゲット・プラットフォームにインストールする必要があります(実行時)。

ターゲット・プラットフォームへの再ロード・コンポーネントのインストール

再ロードに使用されるコンポーネント($HOME/trf/reload/rdbmsに生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。

表1-36は、ターゲット・プラットフォームに設定する必要がある環境変数を示しています。

表1-36 変数とそのプラットフォーム

変数

値

DATA_SOURCE

Oracle表に再ロードするためにz/OSから転送された、アンロード済DB2表を含むディレクトリの名前。

BIN

汎用的な再ロードおよび制御スクリプトの場所($HOME/trf/reload/bin)

TMPPROJECT

一時ディレクトリ。

MT_LOG

実行ログを含むディレクトリ。

CTL

SQL*LOADERで使用される<table name>.ctlファイルを含むディレクトリ($HOME/trf/reload/rdbms/<schema name>/ctl)。

DATA_TRANSCODE

DB2バイナリ・データ・トランスコード・スクリプトにより使用される一時ディレクトリ(ASCII形式の一時ファイルが含まれます)。

注意:

CLOBまたはBLOBデータ型の移行の場合、このディレクトリには<column_name>という名前のサブディレクトリが含まれることがあります。

NLS_LANG

Oracleドキュメントでの説明に従って設定します。

NLS_SORT

NLS_COMP

『Oracle Tuxedo Application Workbenchリファレンス・ガイド』およびその他のOracleドキュメントの説明に従って設定します。

NLS_DATE_FORMAT

NLS_TIMESTAMP_FORMAT

NLS_TIME_FORMAT

『Oracle Tuxedo Application Workbenchリファレンス・ガイド』およびその他のOracleドキュメントの説明に従って設定します。

次の変数は『Oracle Tuxedo Application Rehosting Workbenchインストレーション・ガイド』の情報に従って設定する必要があります。

•

MT_DB_LOGIN。

再ロード・スクリプトloadrdbms-<table name>.kshは、SQL*LDR Oracleユーティリティを使用します。このユーティリティがアクセスできるのはORACLEサーバーに限られるため、このスクリプトはORACLEサーバーで使用する必要があり、クライアント接続では使用できません。特にこの再ロード手順では、この変数に@<oracle_sid>文字列を含めることはできません。

ターゲット・プラットフォームへのMWDB2ORAパッケージ・コンポーネントのインストール

COBOLプログラムによって呼び出されるパッケージの機能(COBOLコンバータによって変換)をターゲット・プラットフォームにインストールする必要があります(実行時)。

パッケージは、REFINEDIR/convert-data/fixed-components/MWDB2ORA.plbおよびREFINEDIR/convert-data/fixed-components/MWDB2ORA_CONST.plbに配置されます。MWDB2ORA_CONST.plbパッケージを調整して、これらのパッケージをDB2-To-Oracleコンバータに関する項で説明されているように、SQLPLUSの下にインストールする必要があります。

アンロード用JCL

各DB2表をアンロードするには、IBMアンロード・ユーティリティを使用するJCLを実行します。通常、アンロード・ユーティリティによって表ごとに3つのファイルが作成されます。

•

データ・ファイル

•

ログ・ファイル

•

SYSPUNCHファイル。

表にCLOBまたはBLOBデータ型が含まれる場合、アンロード・ユーティリティで次が作成されます。

•

列および行ごとにデータ・ファイルが作成されます。

パラメータrdbms:jcl_unload_lob_file_systemがそれぞれpdsまたはhfsに設定されている場合、これらのファイルは他のデータセットまたはディレクトリに書き込まれます。

これらのアンロード用JCLの名前は<table name>.jclunloadです

表名が8文字よりも長い場合、Tuxedo ART Workbenchは可能なかぎり元の名前に近い8文字の名前をz/OS JCLに付けます。この名前変更プロセスにより、各表名の一意性が保たれます。

•

例: ODCSF0X1.jclunload

この章で使用される例では、ODCSF0という表名が、z/OS JCLの名前を付けるときにODCSF0X1に伸ばされます。

ファイルの転送

アンロードされたデータ・ファイルは、サイトで使用可能なファイル転送ツール(CFT、FTPなど)を使用して、バイナリ形式で、ソースz/OSプラットフォームとターゲットUNIXプラットフォーム間で転送される必要があります。

LOGおよびSYSPUNCHファイルはテキスト・モードで転送される必要があります。

ターゲットUNIXプラットフォームに転送されたファイルは$DATA_SOURCEディレクトリに格納される必要があります。

CLOBおよびBLOBデータ・ファイルはバイナリ・モードで転送し、$DATA_SOURCE/<schema_name>.<column_name>ディレクトリに格納する必要があります。

MBCSデータ・ファイルはテキスト・モードで転送し、転送ツールによって適切にトランスコードする必要があります。詳細は、『Oracle Tuxedo Application Workbenchリファレンス・ガイド』を参照してください。

注意:

MVSでは、Rehosting Workbenchは6文字の名前に数値を加えたもの(表の最初のCLOBまたはBLOB列には1、2番目には2など)を、データセットまたはディレクトリの<column_name>とみなします。UNIX/Linuxプラットフォームでは、loadrdbms.shスクリプトは実際のcolumn_nameを使用します。

生成されたOracleオブジェクトの作成

Oracleオブジェクト(表、索引、制約など)を作成するスクリプトは、$HOME/trf/SQL/rdbms/<schema name>ディレクトリに作成されます。これらはターゲットOracleインスタンスで実行される必要があります。

<schema name>.lstファイルには、すべての表の名前が階層順に含まれます(親表の次に子表)。

表1-37に、Tuxedo ART Workbenchで管理されるDB2オブジェクトとそれを作成するために使用するスクリプトの名前をリストします。

表1-37 DB2オブジェクト

オブジェクト・タイプ

ファイル名

注意

TABLE

TABLE- <target_table_name>.sql

表ごとに1ファイルです。このファイルには表構成が、列名、データ型および属性とともに含まれます。

NULL/NOT NULL属性を除く制約はこのファイルには書き込まれません。

INDEX

INDEX- <target_table_name>.sql

このファイルには、表<target_table_name>に関連付けられたすべてのCREATE INDEXが含まれます。このファイルは表<target_table_name>>に索引が定義されてない場合には生成されません。

索引: 一意制約または一意ではない制約

CONSTRAINT

CONSTRAINT-

<target_table_name>.sql

このファイルには、表<target_table_name>に関連付けられたすべての制約が含まれます。このファイルは、表<target_table_name>に定義された制約がない場合は生成されません

制約: 主キー、一意、チェックおよび外部キー

COMMENT

COMMENT- <target_table_name>.sql

表と列のすべてのコメントが含まれます。表ごとに1ファイルです

VIEW

VIEW-<schema_name>.sql

このファイルにはソース・データベース/スキーマで作成されたすべてのビューが含まれます。

このリリースでは、Select文はターゲット・データベース言語に自動的には変換されません。

SEQUENCE

SEQUENCE-<schema_name>.sql

このファイルにはソース・データベースですでに作成されたすべてのCREATE SEQUENCEが含まれます。

SYNONYM

SYNONYMS-<schema_name>.sql

このファイルにはソース・データベースですでに作成されたすべてのCREATE SYNONYMが含まれます。

IDENTITY

IDENTITY- <target_table_name>.sql

IDENTITYの場合、DB2からORACLEに移行すると、Tuxedo ART WorkbenchによってSequenceオブジェクトとTriggerオブジェクトが作成されます。

トランスコード・プログラムのコンパイル

トランスコードに使用される生成されたCOBOLプログラムの名前は次のとおりです。

MOD_<表名>.cbl

この章で使用される生成されたプログラムの例は次のとおりです。

•

MOD_ODCSF0.cbl

このプログラムはターゲットのCOBOLコンパイラと、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』に記載されたオプションを使用してコンパイルされる必要があります。

このプログラムは出力時にRECORD SEQUENTIALファイルを生成し、それは次にSQL*LOADERユーティリティに読み取られます。

リスト1-65 FILE CONTROLの例 - プログラム: MOD_ODCSF0.cblからの抽出

SELECT MW-SORTIE

ASSIGN TO "SORTIE"

ORGANIZATION IS RECORD SEQUENTIAL

ACCESS IS SEQUENTIAL

FILE STATUS IS IO-STATUS.

CLOB列のトランスコードに使用される、生成されたCOBOLプログラムの名前は次のとおりです。

CLOB_<table name>_<column_name>.cbl

トランスコードおよび再ロード・スクリプトの実行

データのトランスコードおよび再ロードを可能にするスクリプトが次のディレクトリに生成されます。

$HOME/trf/reload/rdbms/<schema name>/ksh

スクリプト名の形式は次のとおりです。

loadrdbms-<table name>.ksh

この章で使用する例では、スクリプトの名前は次のとおりです。

loadrdbms-ODCSF0.ksh

各スクリプトは、トランスコードを実行するCOBOLプログラムを起動し、次にSQL*LOADERユーティリティを起動します。SQL*LOADERにより使用されるCTLファイルの名前は次のとおりです。

<table name>.ctl。

この章の例で使用されるCTLファイルの名前は次のとおりです。

ODCSF0.ctl

トランスコードと再ロードのコマンド

トランスコードおよび再ロード・スクリプトには次のパラメータがあります。

形式

loadrdbms-<table name>.ksh [-t | [-O|-T]] [-l] [-c: <method>]

オプション

-t

ファイルおよびすべてのCLOBまたはBLOBファイル(ある場合)をトランスコードします。

-T

表に関連付けられているファイルのみをトランスコードします(CLOBおよびBLOBファイルは除く)。このオプションは、表にCLOBまたはBLOB列が含まれる場合に使用されます。

-O

BLOB列の場合: すべてのバイナリBLOB転送ファイルへのUNIXリンクのみを作成します。

CLOB列の場合: すべてのバイナリCLOB転送ファイルのみをトランスコードします。

-l

データをOracle表に再ロードします。

-c rows:

転送の検証を実装します(「転送のチェック」を参照)。

例

「DB2オブジェクトの移行の例」での例で、生成されるスクリプトは次のとおりです。

•

loadrdbms-ODCSF0.ksh

転送のチェック

このチェックでは、loadrdbms-<table name>.kshの次のオプションを使用します

-c rows

注意:

このオプションでは、再ロードの後でDB2アンロード・ユーティリティにより、再ロードされたOracle表にz/OSからアンロードされた対応する表と同数のレコードが含まれることを確認します。レコード数が異なる場合は、エラー・メッセージが生成されます。

トラブル・シューティング

この項では、データをDB2データベースからターゲットOracleデータベースへ移行するときに発生した使用エラーにより生じる問題について説明します。

概要

Tuxedo ART Workbenchツールを実行するときに、ユーザーは次のことを確認する必要があります。

•

画面にエラー・メッセージが表示されているか。

•

rdbms-converter-<schema name>.logファイルにエラーが含まれているか(「共通の問題と解決策」を参照)。

エラー・メッセージとその説明は、『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』の付録に記載されています。

共通の問題と解決策

エラー: RDBMS-0105

$REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/trf PJ01DB2 STFILEORAの実行時に、次のメッセージが表示されます。

Fatal RDBMS error.

Error: RDBMS-0105: Catalog for /home2/wkb9/param/system.desc is out of date

and needs to be updated externally.

調整エラー...

説明

DDLが変更されたのでカタログ化操作を再度実行します。

エラー: 変換が中断されました。読み取りできません

$REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/trf SCHEMAの実行時に、次のメッセージが表示されます。

調整エラー...

/tmp/refine-exit-status.MOaZwgTphIN14075

ERROR : conversion aborted . Can not read /home2/wkb9/tmp/outputs/SCHEMA/rdbms-converter-SCHEMA.log log file

abort

説明

スキーマ名が不明です。

エラー: 構成ファイル/db-param.cfgがありません。

$REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/trf PJ01DB2の実行時に、次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=--=-

#########################################################################

CONVERSION OF DDLs and CTL files and GENERATION of directive files

ERROR : Configuration file /db-param.cfg is missing !

ERROR : Error in reading configuration file

Abort

説明

外部変数PARAMが設定されていません。

エラー: ターゲット出力ディレクトリ...がありません

$REFINEDIR/$VERS/rdbms.sh -Cgrmi $HOME/bad-directory PJ01DB2の実行時に、次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-

Target output directory /home2/wkb9/bad-directory is missing

パラメータをチェックしてください: -i <output_directory> <schema>

ERROR : usage : rdbms.sh [ [-c|-C] [-g] [-m] [-r] [-i <output_directory>] <schema_name> ] -s <output_directory> (<schema>,...) ]

abort

説明

ターゲット・ディレクトリが存在しません。

エラー: サポートされていない機能の場合には、-cオプションの使用時に中断するします

$REFINEDIR/$VERS/rdbms.sh -c WWARNの実行時に、次のメッセージが表示されます。

*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-

WARNING: some unsupported db2 objects have been ignored by this tool.

Check file /home2/wkb9/tmp/outputs/WWARN/unsupported-WWARN.log to see a detail of those objects.

ERROR:

RDBMSWB-0199: conversion aborted due to 26 Warning message(s). Check previous error messages and try -C option instead of -c

abort

説明

DDLに、サポートされていない機能が含まれます。警告ファイルを確認してください。-cオプションを-Cオプションに置き換えることで、この中断を無視できます。

DB2-to-UDBで生成されたコンバータ・プログラムの実行

関連項目

•

Tuxedo ART Workbenchリファレンス・ガイド

•

Tuxedo ART for Batchユーザーズ・ガイド

•

Tuxedo ART for CICSユーザーズ・ガイド

•

Tuxedo ART for IMSユーザーズ・ガイド

•

付録A: Oracle Tuxedo Application Rehosting Workbench MBCSサポート

•

付録B: Simple Appアプリケーション

•

付録C: Oracle Tuxedo Application Rehosting Workbenchのログ

環境	本番	統合	テスト
ソース	本番ソース		テスト・ソース
ターゲット	本番ターゲット	統合ターゲット	テスト・ターゲット

フェーズ	移行ステップ	テスト・ステップ	環境	言語/ データ
プロジェクト管理	プロジェクトの定義
変換前	アセットの生成		ソース本番からソース・テスト	両方
	アセットのカタログ化およびアセットの合理化(必要な場合)		ソース・テスト	言語
	外部仕様アーキテクチャの開発		ターゲット環境の計画および準備
	データ変換		ソース・テストからターゲット・テスト	データ
テストの準備		テストの設計テストの準備テストのツール	ソース・テスト	両方
パイロット	パイロット・セットの変換	パイロット・セットのテスト	ターゲット・テスト	言語
残余	残余の変換	残余のテスト	ターゲット・テスト	言語
統合	システムの統合および操作の移行	システムのテストおよび操作のテスト	ターゲット・テストからターゲット統合	両方
スイッチオーバー	保守作業の変換および保守作業の変換テスト	保守作業のテストおよび予行演習	ターゲット・テスト	両方
スイッチオーバー	スイッチオーバー		ターゲット統合からターゲット本番
教育	教育およびトレーニング

タスク	説明	ソース・アセット	出力
準備手順の前におけるカスタム・スクリプトの実行	準備プロセスの前に、ユーザーによりカスタマイズされた特殊タスクを実行できます。	ユーザーが指定した範囲。	カスタム・スクリプトが準備前に実行されます。
MBCSコード・ページ変換	EBCDICエンコーディングのマルチバイト文字をASCIIベース・エンコーディングのマルチバイト文字に変換します。	すべて	すべてのファイルはASCIIベースのエンコーディングに変換されます。
dos2unix変換	ファイルをDOS形式(0x0D0Aを改行として使用)からUNIX形式(0x0Aを改行として使用)に変換します。	すべて	すべてのWindowsリターンはUNIXリターンで置換されます。
ソース・ファイル名を大文字に変更	拡張子を除いてファイル名を大文字に変更します。	すべて	すべてのファイル名は大文字で、小文字の接尾辞が付きます。
準備手順の後におけるカスタム・スクリプトの実行	準備プロセスの後に、ユーザーによりカスタマイズされた特殊タスクを実行できます。	ユーザーが指定した範囲	カスタム・スクリプトが準備後に実行されます。

タスク	説明	構成可能なオプション	出力
ビルド設定の構成	ターゲット・コンポーネント・ディレクトリごとのmakefileとルートmakefileを生成します。	データベース・オプション。COBOLコンパイラ・オプション。ART CICSプリプロセッサ・オプションなど。	ターゲット・ディレクトリ下のmakefile。
Tuxedoドメインの構成	ubbconfigテンプレートの生成	IPC KEYやマシン名などのubb構成。	ubbconfig.em ubbconfig.null ubbconfig.tsam
CICS Runtimeの構成	CICS Runtimeのubbconfigとsetenvファイルの生成	CICS Runtimeの場所やモニター設定など。	configure/CICS_RTディレクトリにあるubbconfigやsetenvなどのファイル
Batch Runtimeの構成	Batch Runtimeのubbconfigとsetenvファイルの生成	Batch Runtimeの場所、JESROOTおよびモニター設定など。	configure/BATCH _RTディレクトリにあるubbconfigやsetenvなどのファイル
IMS Runtimeの構成	IMS Runtimeのubbconfigとsetenvファイルの生成	IMS Runtimeの場所やモニター設定など	configure/IMS_RTディレクトリにあるubbconfigやsetenvなどのファイル

タスク	説明
インポートの消去	インポート・プロセスを元に戻します。$project/importedディレクトリのファイルがすべて削除されます。
準備の消去	準備プロセスを元に戻します。$project/preparedディレクトリのファイルがすべて削除されます。
ソースの消去	分析プロセスを元に戻します。$project/sourceディレクトリのファイルがすべて削除されます。
POBリポジトリを消去	$project/sourceディレクトリのpobファイルをすべて消去します。
ターゲットの消去	変換プロセスを元に戻します。変換手順の出力が削除されます。
構成の消去	構成プロセスを元に戻します。ubbconfigやsetenvなどの構成ファイルが削除されます。
ビルド・バイナリの消去	ビルド・プロセスを元に戻します。ビルド手順の出力が削除されます。
すべての消去	前述のプロセスをすべて元に戻します。$project/paramと$project/scriptsにあるファイルを除いてすべてのファイルを削除します。

接尾辞	タイプ
*.jcl	JCL
.bms、.map	BMS
.ddl、db2、*.sql	SQL-Script
*.sysin	JCL-Sysin
*.proc	CL-Lib(Proc)
*.incl	JCL-Lib(Include)
*.cpy	COBOL-Library
*.cbl	COBOL-Batch、COBOL-TPR、COBOL-Sub、COBOL-IMS
*.rdo	RDO

変数	値	使用方法
REFINEDISTRIB	Linux64またはLinux32	Tuxedo ART Workbenchバイナリ・ファイルのアーキテクチャを指定します。
PROJECT	${HOME}	ワークスペース内のプロジェクト・ルート。HOMEはトレーニング用に使用されます。ただし、値は/project/SampleAppのようにする必要があります
CVSROOT	${PROJECT}/CVS_DELIVRY	ソースおよび構成ファイルを含むのに使用するCVSリポジトリ。
LOGS	${PROJECT}/Logs	Tuxedo ART Workbenchのログが格納される構造体
PARAM	${PROJECT}/param	パラメータ・ファイルが格納されるディレクトリ
SOURCE	${PROJECT}/source	変換されるソース・ファイルが格納される構造体
REFINEDIR	/<InstallDir>/refine	Tuxedo ART Workbenchバイナリおよびユーティリティのルート
PHOENIX	${REFINEDIR}	Tuxedo ART Workbenchにより使用される変数
TMPPROJECT	${PROJECT}/tmp	Tuxedo ART WorkbenchのR4Z用の一時構造体
PATH	${PATH}:/platform/Tools	PATH補完

z/OSソース・ファイル	UNIX ISAMターゲット・ファイル
QSAM	ライン・シーケンシャルISAM
VSAM KSDS	索引付きISAM
VSAM RRDS	相対ISAM
VSAM ESDS	ライン・シーケンシャルISAM

列
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	..
*	D	E	S	C	R	I	P	T	I	O	N		O	F		F	I	L	E		X	X	X	X
	0	1		F	V	1	4	.
			0	5		F	V	1	4	x	1		P	I	C		X	.

パラメータ	例での値	設定元
configuration name	FTFIL001 (data map FTFIL001-map)	ユーザーが自由に選択します。
system name	PROJ001 (system cat::PROJ001)	システム記述ファイルでのカタログ化中に決定されます。
file name	PJ01DDD.DO.QSAM.KBCOI001	z/OS物理ファイル名。
Organization	順次	ソースの編成

列
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	..
*	D	E	S	C	R	I	P	T	I	O	N		O	F		F	I	L	E		X	X	X	X
	0	1		F	V	1	4	.
			0	5		F	V	1	4	x	1		P	I	C		X	.

場所	内容
$HOME/trf/unload/file/<configuration name>	各アンロードに使用されるJCLは各<configuration name>に対して生成されます。
$HOME/trf/reload/file/<configuration name>	各ロードに使用されるプログラムおよびKSHは各<configuration name>に対して生成されます。
$TMPPROJECT/outputs	生成ログ・ファイルMapper-log-<configuration name>は問題の解決に使用できます。

列
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	.
*	D	E	S	C	R	I	P	T	I	O	N		O	F		F	I	L	E		X	X	X	X
	0	1		F	V	1	4	.
			0	5		F	V	1	4	x	1		P	I	C		X	.

列
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	.
*	D	E	S	C	R	I	P	T	I	O	N		O	F		F	I	L	E		X	X	X	X
	0	1		F	V	1	4	.
			0	5		F	V	1	4	x	1		P	I	C		X	.

DB2 z/OSデータ型	Oracleの形式
CHAR(length)	長さ <= 2000バイトの場合はCHAR 長さ > 2000バイトの場合はVARCHAR2
VARCHAR(length)	VARCHAR2(length)
DECIMAL(…)	NUMBER(…)
NUMERIC(…)	NUMBER(…)
DEC(…)	NUMBER(…)
SMALLINT	NUMBER(5)
INTEGER	NUMBER(10)
TIMESTAMP	TIMESTAMP
TIMESTMP	TIMESTAMP
DATE	DATE
TIME	DATE
DOUBLE	BINARY_DOUBLE
FLOAT(prec)	BINARY_DOUBLE
REAL	BINARY_DOUBLE
CLOB	CLOB
BLOB	BLOB

DB2の列プロパティ	Oracleの形式	注意
WITH DEFAULT	DEFAULT <value>	<value>はDB2/z/OSデータ型によって異なります。
WITH DEFAULT ''	CHAR: DEFAULT ‘ ‘ VARCHAR2: DEFAULT ‘ ‘	DB2でのゼロ・バイトの長さはOracleでのNULLフラグになります。
WITH DEFAULT '<value>'	DEFAULT '<value>'
NOT NULL	NOT NULL
IDENTITY	Sequenceの作成 Triggerの作成	IDENTITY属性はOracleには存在しないので、Tuxedo ART Workbenchはその属性をSequenceおよびTriggerオブジェクトで置き換えます。
FOR SBCS …	属性は無視されます

変数	値
REFINEDIR	/product/art_wb11gR1/refine
PROJECT	$(HOME)/ simpleapp
PARAM	$PROJECT/param
SOURCE	$PROJECT/source
LOGS	$PROJECT/Logs

変数	値	使用方法
COBDIR	/Product/microfocus/cobol	COBOL製品へのアクセス
COBOLITDIR	/product/COBOL-IT	COBOL-IT製品へのアクセス
その他のCOBOL-IT環境変数	source $COBOLITDIR/bin/cobol-it-setup.sh	環境変数(PATH.LD_LIBRARY_PATH...)の初期化
PATH	$COBDIR/bin: ${PATH}	CobdirをPATH変数に追加
LD_LIBRARY_PATH	/usr/lib:$COBDIR/lib:${ORACLE_HOME}/lib:${JAVA_HOME}/lib	定義されたLD_LIBRARY_PATH
COBCPY	../DML:../Master-copy/COPY:../fixed-copy:.	プログラムがインクルードを見つけることのできる場所を示す
PCCINCLUDE	"include=../Master-copy/COPY, include=../../fixed-copies, include=.	プログラムがインクルードを見つけることのできる場所を示す

変数	値
DATA_SOURCE	再ロードするためにz/OSから転送されたファイルを含むディレクトリの名前。
BIN	汎用的な再ロードおよび制御スクリプトの場所($HOME/trf/reload/bin)
TMPPROJECT	一時ディレクトリ。
MT_LOG	実行ログを含むディレクトリ。
DATA	トランスコードおよび再ロード・プロセスからの出力ファイルを含むディレクトリ。これらはターゲット・プラットフォームで使用できるファイルです。
COB_EXTFH_INDEXED COB_EXTFH_LIB	ターゲットのCOBOLコンパイラとしてCOBOL-ITを選択し、オープン・システムでISAMファイルとしてBDBを使用する場合は、BatchRTがBDB形式のファイルを生成できるように、これらの2つの環境変数を設定する必要があります。そうしないと、Micro Focus COBOL互換ファイルが生成されます。 export COB_EXTFH_INDEXED=BDBEXTFH export COB_EXTFH_LIB=/path_to_Cobol-IT/lib/libbdbextfh.so 例: export COB_EXTFH_LIB=/opt/cobol-it-64/lib/libbdbextfh.so

オブジェクト・タイプ	ファイル名	注意
TABLE	TABLE- <target_table_name>.sql	表ごとに1ファイルです。このファイルには表構成が、列名、データ型および属性とともに含まれます。 NULL/NOT NULL属性を除く制約はこのファイルには書き込まれません。
INDEX	INDEX- <target_table_name>.sql	このファイルには、表<target_table_name>に関連付けられたすべてのCREATE INDEXが含まれます。このファイルは表<target_table_name>>に索引が定義されてない場合には生成されません。索引: 一意制約または一意ではない制約
CONSTRAINT	CONSTRAINT- <target_table_name>.sql	このファイルには、表<target_table_name>に関連付けられたすべての制約が含まれます。このファイルは、表<target_table_name>に定義された制約がない場合は生成されません制約: 主キー、一意、チェックおよび外部キー
COMMENT	COMMENT- <target_table_name>.sql	表と列のすべてのコメントが含まれます。表ごとに1ファイルです
VIEW	VIEW-<schema_name>.sql	このファイルにはソース・データベース/スキーマで作成されたすべてのビューが含まれます。このリリースでは、Select文はターゲット・データベース言語に自動的には変換されません。
SEQUENCE	SEQUENCE-<schema_name>.sql	このファイルにはソース・データベースですでに作成されたすべてのCREATE SEQUENCEが含まれます。
SYNONYM	SYNONYMS-<schema_name>.sql	このファイルにはソース・データベースですでに作成されたすべてのCREATE SYNONYMが含まれます。
IDENTITY	IDENTITY- <target_table_name>.sql	IDENTITYの場合、DB2からORACLEに移行すると、Tuxedo ART WorkbenchによってSequenceオブジェクトとTriggerオブジェクトが作成されます。

列
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	..
*	D	E	S	C	R	I	P	T	I	O	N		O	F		F	I	L	E		X	X	X	X
	0	1		F	V	1	4	.
			0	5		F	V	1	4	x	1		P	I	C		X	.

列
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	.
*	D	E	S	C	R	I	P	T	I	O	N		O	F		F	I	L	E		X	X	X	X
	0	1		F	V	1	4	.
			0	5		F	V	1	4	x	1		P	I	C		X	.

列
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	.
*	D	E	S	C	R	I	P	T	I	O	N		O	F		F	I	L	E		X	X	X	X
	0	1		F	V	1	4	.
			0	5		F	V	1	4	x	1		P	I	C		X	.