ユーザーズ・ガイド

Oracle Tuxedo Application Rehosting Workbenchカタロガ

概要

目的

この章の目的

Rehosting Workbenchカタロガの使用方法に関する情報と手順を説明します。
Rehosting Workbenchカタロガ・ツールの構成と実行を支援します。
メッセージとステータス情報の解釈結果を検証する方法を示します。

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

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

注意:

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

スキル

移行プロセスおよび概念

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

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

UNIX/Linuxスキル

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

構成ファイルおよび出力ファイルの作成、変更、表示および削除を行う、標準のUnix/Linuxコマンド。
カタログ化の前後で、元のz/OSアセットを格納および管理を行う、標準のUnix/Linuxコマンドおよび特化したスクリプト(シェル、makefile、cvs)。
Rehosting Workbenchカタロガの実行を開始、監視および終了するコマンドのセット(シェル、makefile)。

z/OSスキル

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

編成

Oracle Tuxedo Application Rehosting Workbenchカタロガは次の項に記載されています。

要件および前提条件

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

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

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

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

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

サンプルのSimple Application

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

カタログ化移行手順

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

構成ファイルと、カタログ化のために準備されたソース・ファイルの説明を読みます。
ソース・アセットの各コンポーネントを解析し、パック・オブジェクト・ベースと呼ばれる内部表現(拡張子.pob)を作成します。これらのコンポーネントの内部的な不整合(構文エラーまたは未定義の変数への参照など)を特定します。
COBOLプログラムからCOBOLサブプログラムへのCALL文などの、これらのコンポーネント間の相互参照を計算します。
アセットから欠落しているサブプログラムへのCALL文の参照、またはアセットのどのCOBOLプログラムからも参照されないSQL表(未使用のコンポーネント)などの、これらの関係における相互の不整合を特定します。
アセット内のすべてのコンポーネントをそのステータス(欠落、未使用または正常)と上記で検出されたすべての異常(不整合)とともにリストするCSV形式のレポートを作成します。

上記の操作は次の項で詳しく説明します。

カタログ化手順

アセットの作成

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

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

z/OSから移行するソースの収集
ソースのRehosting Workbenchプラットフォームへの転送

ソース・ファイルは移行プラットフォームで理解できるようにASCIIコードセットに変換される必要があります。この変換はファイル転送ユーティリティを使用するか、または個別のEBCDIC/ASCII変換手順を適用するかのどちらかで行うことができます。
転送手順によってソースの内容が破損していないことを確認する必要があります。

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

すべてのコンポーネントをUNIX形式に変換します(dos2unixコマンドなどを使用)。
COBOLコンポーネントをCOBOLコンバータによるリクエストに応じた自由形式に変換します。カタロガ自体はどちらの形式も受け入れますが、cobol-left-marginおよびcobol-right-marginオプションだけは設定する必要があります。
コンポーネントをタイプ別に構成します。すべてのCICSプログラムはサブディレクトリを含む1つのディレクトリに入れ、COBOLインクルード、Batchプログラム、Jobなども同様です。
各タイプにファイルの拡張子を追加します。COBOLプログラムには.cbl、COBOLインクルードには.cpy、Jobには.jclです。

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

作業環境の初期化と構成

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

構成の目的

作業環境の準備に必要な時間を削減し、構成が原因で起こりうるエラーを回避します。
カタロガだけでなく、その他のWorkBenchツールの構成も初期化します。
チームワークの促進のため、標準の構成をお薦めします。

推奨するファイル構造

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

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

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

SampleApp

|-- CVS_DELIVRY

|-- Logs

|-- param

|   `-- system.desc

|-- source

|   `-- makefile

|-- tools

各ディレクトリの内容

Source

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

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

param

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

Logs

すべてのRehosting Workbenchツールが開始し、すべてのログが生成される作業ディレクトリです。

tools

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

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

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

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

表2-1 Rehosting Workbench環境変数
変数	値	使用方法
`REFINEDISTRIB`	`Linux64またはLinux32`	Rehosting Workbenchバイナリ・ファイルのアーキテクチャを指定します。
`PROJECT`	`${HOME}`	作業領域内のプロジェクトのルート。HOMEは研修用に使用されます。しかし値は/project/SampleAppのようになります
`CVSROOT`	`${PROJECT}/CVS_DELIVRY`	ソースおよび構成ファイルを含むのに使用するCVSリポジトリ。
`LOGS`	`${PROJECT}/Logs`	Rehosting Workbenchのログが格納される構造体
`PARAM`	`${PROJECT}/param`	パラメータ・ファイルが格納されるディレクトリ
`SOURCE`	`${PROJECT}/source`	変換されるソース・ファイルが格納される構造体
`REFINEDIR`	`/<InstallDir>/refine`	Rehosting Workbenchバイナリおよびユーティリティのルート
`PHOENIX`	`${REFINEDIR}`	Rehosting Workbenchにより使用される変数
`TMPPROJECT`	`${PROJECT}/tmp`	Rehosting WorkbenchのR4Z用の一時構造体
`PATH`	`${PATH}:/platform/Tools`	PATH補完

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

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

echo "Welcome to SampleApp"

export GROUP=refine

export PROJECT=${HOME}/SampleApp

export CVS_LIV=${PROJECT}/CVS_DELIVRY

export CVSROOT=${PROJECT}/CVS_DELIVRY

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

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

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

前述のファイル構造を作成します。
サンプルの構成(system.desc、version.mk、options-catalogなど)をSimple Applicationから$PROJECT/paramディレクトリにコピーし、必要な変更を行います。
makefileをソース(SimpleApp)から$PROJECT/sourceへコピーします。
ファイル.projectを$PROJECTの下に作成し、環境および作業変数の設定にリストした変数で初期化します。このファイルの変数はプロジェクトで作業するたびにエクスポートされます。
準備したソース・ファイルを$PROJECT/sourceにコピーします。
オプション: ソースおよび構成ファイルをCVSで管理します。

構成

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

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

システム記述ファイル
一般オプション・ファイル

システム記述ファイル

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

Simple Applicationの例の場合

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

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

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

リスト2-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つのオプションのみを使用しますが、もちろん他のオプションも使用できます。全部のオプションのリストについては、Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドを参照してください。

リスト2-4 Simple Applicationのグローバル・オプション

%% Options for cataloging the system

job-card-optional.

カタロガの実行

1つの操作

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

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

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

説明:

${REFINEDIR}はRehosting Workbenchツールがインストールされているディレクトリです。
$(CATALOG)は使用されるカタロガのバージョンです。
$(SYSTEM)はシステム記述ファイルのパスです。

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

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

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

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

手順ごと

解析

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

リスト2-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という名前のバイナリ・ファイルです。

リスト2-6 分析例

cd $LOGDIR/catalog

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

レポートの印刷

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

リスト2-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リファレンス・ガイドに記載されています。

結果の分析と検証

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

注意:

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

インベントリ

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

表2-2 インベントリ・ステータス
ステータス	説明
`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ユーティリティが必要とする変数およびパラメータを設定するのに使用されます。

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

リスト2-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の内容は実行するタスクの要約です。

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