データセットの移行
本章では、データセットを移行する方法について説明します。
1. 概要
データセットは、データ・レコードの論理的な集合体です。またレコードは、アプリケーションで使用される情報の基本単位です。データセットは大きく非VSAMデータセットとVSAMデータセットに分けられます。
|
データセットについての詳細は、OpenFrame Base『データセットガイド』を参照してください。 |
-
非VSAMデータセット
以下は、非VSAMデータセットのPDS、GDG、SAMデータセット、ISAMデータセットの移行方法です。
区分 説明 PDS
PDSは、ディレクトリとメンバーから構成されるデータセットです。PDSは、pdsgenまたはdscreateツール使用して作成し、PDSの各メンバー・ファイルは、dsmiginツールを使用して文字セットを変換します。
GDG
GDGは、世代で構成されるデータセットのグループです。GDGは、gdgcreateツールを使用してカタログに登録し、SAMデータセットの移行方法に従って移行します。
SAMデータセット
一般的な非VSAMデータセットであるSAMデータセットは、COBOLコピーブックなどを参照してデータセット変換スキーマを作成した後、dsmiginツールを使用してOpenFrameデータセットにインポートします。
ISAMデータセット
ISAMデータセットはOpenFrameでサポートしており、VSAM KSDSに代替して使用することもできます。
-
VSAMデータセット
以下は、VSAMデータセットのKSDS、ESDS、RRDS、LDSの移行方法です。
区分 説明 KSDS
KSDSは、idcamsツールのDEFINE CLUSTERコマンドでOpenFrame VSAMデータセットを定義します。また、dsmiginツールのRECATALOGオプションを使用してデータをVSAMデータセットにインポートします。
ESDS
KSDSの移行方法と同じです。
RRDS
RRDSは、各レコードごとに番号が付与されます。データセットの中に番号が欠けているレコードがなければ、VSAM KSDSと同じ方法で移行できます。ただし、番号が欠けているレコードがある場合は、別のRRDSインポート・プログラムを作成して移行する必要があります。
LDS
現在VSAM LDSは、OpenFrameでサポートしていません。VSAM LDSのサポートが必要な場合は、弊社の技術サポート・チームにお問い合わせください。
メインフレームのデータセットをOpenFrameに移行する方法は、次のようにデータセットの種類によって異なります。
2. 非VSAMデータセットの移行
OpenFrameで一般的な非VSAMデータセットの移行プロセスは以下のとおりです。
-
移行対象の確認およびソース・ファイルのダウンロード
-
データセット・レイアウトの分析
-
データセット変換スキーマの作成
-
ターゲット・データセットの移行
-
PDSデータセットの移行
-
GDGベースの定義
-
可変長データセットの移行
-
データセット移行の検証
2.1. 移行対象の確認およびソース・ファイルのダウンロード
移行対象となるデータセットの一覧を作成することは、移行プロジェクトを成功させるための重要な作業です。JCLまたはプロシージャを分析して一覧を作成することもできますが、大規模なプロジェクトでは、OpenFrameへの移行によって不要となったり、SMSポリシーやセキュリティ・ポリシーによってデータセット名が変更される場合もあるため、お客さまから正確な一覧を取得する必要があります。
移行するデータセットが決まったら、ホスト(運用中のメインフレーム)で使用しているデータセットのソース・ファイルをダウンロードします。ただし、データセットをASCII形式でダウンロードすると、特殊文字、SOSI、2バイト文字が正常に変換されず問題が発生するため、ホストで使用しているEBCDIC形式のデータセットをそのままダウンロードしてください。
2.2. データセット・レイアウトの分析
データセットのレイアウト分析は、データセットの移行を正常に実行するために最も重要なステップです。現在使用中のデータセットは、COBOLコピーブックやデータベース・スキーマからデータセットのレイアウト情報を抽出できますが、長期間使用していないデータセットは、直接確認しないと、レイアウトを正確に分析することは難しいです。したがって、顧客会社からレイアウト情報を取得し、データセットの移行を行うのが一般的です。
通常は、1つのデータセットのすべてのレコードは、1つのレイアウトが適用されますが、一部のデータセットは、各レコードに異なるレイアウトが適用される場合もあります。これは、COBOLのREDEFINES文によって複数のレイアウトが生成された場合や、データセットのレコードが可変長である場合に発生します。
2.3. データセット変換スキーマの作成
データセットのレイアウト情報は、運用の利便性を考慮してさまざまな形式で提供されます。これらをすべてサポートすることは難しいため、以下のような標準のCOBOLコピーブックまたはPL/Iインクルードを変換して使用します。
<XTBC106.cpy>
01 I1.
05 KYAKUMEI-KN PIC X(0018).
05 BTN-CD PIC X(0004).
05 KYAKU-NO PIC X(0007).
05 ATUKAI-CD PIC X(0003).
05 MDY-CD PIC X(0003).
05 YAKU-YMD PIC S9(0009) COMP-3.
05 UKEW-YMD PIC S9(0009) COMP-3.
05 KOYU-MEI-CD PIC S9(0005) COMP-3.
05 KAISU PIC S9(0005) COMP-3.
05 GO .
10 GO-1 PIC X(0001).
10 GO-2 PIC X(0001).
10 GO-3 PIC X(0001).
データセットのレイアウト情報を示すCOBOLコピーブック・ファイル<XTBC106.cpy>がある場合は、cobgenschツールを使用してデータセット変換スキーマ・ファイルを作成することができます。
以下のコマンドでは、-rオプションを使用してレコード長を54に指定しています。このようにレコード長を指定する場合は、COBOLコピーブック・ファイルの各フィールドの長さを足した実際のレコード長と一致するかを確認する必要があります。
$ cobgensch XTBC106.cpy –r 54以下は、上記のサンプル・ファイル<XTBC106.cpy>をcobgenschツールを実行して作成されたデータセット変換スキーマ・ファイルの内容です。
<XTBC106.conv>
* Schema Version 7.1 L1, 01, I1, NULL, NULL, 0, 1:1, L2, 05, KYAKUMEI-KN, EBC_ASC, NULL, 18, 1:1, L3, 05, BTN-CD, EBC_ASC, NULL, 4, 1:1, L4, 05, KYAKU-NO, EBC_ASC, NULL, 7, 1:1, L5, 05, ATUKAI-CD, EBC_ASC, NULL, 3, 1:1, L6, 05, MDY-CD, EBC_ASC, NULL, 3, 1:1, L7, 05, YAKU-YMD, PACKED, NULL, 5, 1:1, L8, 05, UKEW-YMD, PACKED, NULL, 5, 1:1, L9, 05, KOYU-MEI-CD, PACKED, NULL, 3, 1:1, L10, 05, KAISU, PACKED, NULL, 3, 1:1, L11, 05, GO, NULL, NULL, 0, 1:1, L12, 10, GO-1, EBC_ASC, NULL, 1, 1:1, L13, 10, GO-2, EBC_ASC, NULL, 1, 1:1, L14, 10, GO-3, EBC_ASC, NULL, 1, 1:1, * Condition L0, "\0", ( L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 L11 L12 L13 L14 )
COBOLコピーブックのPIC句で構成された各構文がデータセット変換スキーマ形式に変換されていることが確認できます。PIC X句はEBCDIC文字をASCII文字に変換するためのEBC_ASCタイプに指定され、PIC S9のCOMP-3句はPACKEDタイプに指定されていることが分かります。ここで使用されたタイプの他に、ゾーン10進数値を表現するZONEDタイプと2バイト文字を表現するGRAPHICタイプがあります。
上記で説明したCOBOLコピーブック・ファイル以外に、以下のようなPL/Iインクルード形式のデータセット・レイアウト情報を変換して使用することもできます。
<XTBC107.inc>
3 ID CHAR(02),
3 NAME CHAR(05),
3 CODE,
5 CODE_NUM PIC'(03)9',
5 CODE_DAT PIC'(03)X',
3 ETC FIXED DEC (3, 0) ;
データセットのレイアウト情報を表すPL/Iインクルード・ファイル<XTBC107.inc>がある場合は、以下のようにpligenschツールを使用してデータセット変換スキーマ・ファイルを作成することができます。
以下のように、-sオプションを指定する場合は、PL/Iインクルード・ファイルの一部だけを変換します。
$ pligensch -s XTBC107.inc以下は、サンプル・ファイル<XTBC107.inc>をpligenschツールで実行して作成したデータセット変換スキーマ・ファイルの内容です。PL/Iインクルード・ファイルで各フィールド・タイプを示すCHAR句、PIC 9句、FIXED DEC句が、以下のようにEBC_ASC、ZONED、PACKEDタイプにそれぞれ変換されていることを確認できます。
<XTBC107.conv>
* Schema Version 7.1 L1, 01, ID_STRUCTURE, NULL, NULL, 0, 1:1, L2, 03, ID, EBC_ASC, NULL, 2, 1:1, L3, 03, NAME, EBC_ASC, NULL, 5, 1:1, L4, 03, CODE, NULL, NULL, 0, 1:1, L5, 05, CODE_NUM, ZONED, NULL, 3, 1:1, L6, 05, CODE_DAT, EBC_ASC, NULL, 3, 1:1, L7, 03, ETC, PACKED, NULL, 2, 1:1, * Condition L0, "\0", ( L1 L2 L3 L4 L5 L6 L7 )
|
スキーマ・ファイルの構造についての詳細は、スキーマ・ファイルの構造を参照してください。 |
2.4. ターゲット・データセットの移行
移行対象のソース・データセットと変換スキーマ・ファイルが準備されたら、dsmiginツールを使用してデータセットを移行します。
以下は、ソース・ファイル<XTB.T66.raw>と変換スキーマ・ファイル<XTB.T66.conv>を基に、dsmiginツールを使用してデータセット<XTB.T66>を作成する例です。
$ dsmigin XTB.T66.raw XTB.T66 –s XTB.T66.conv –e JP –l 800dsmiginツールは、各レコード・データのコード変換およびデータセットのカタログ登録を行います。
|
dsmiginツールの詳細については、OpenFrame Base『ツールリファレンスガイド』を参照してください。 |
2.5. PDSの移行
PDSは、ディレクトリとメンバー・ファイルから構成されるデータセットで、JCLまたはPROCのDSNパラメータにPDS名と括弧で囲まれたメンバー名を一緒に表記します。
//SYSIN DD DSN=PLNI.EDVR.SYSIN(LNIYY01), // DISP=(SHR,PASS,KEEP)
PDSは通常、実行モジュールを管理するライブラリ・データセットとして使用されるか、あるいはJCL、PROC、SYSINなどのファイルを管理するライブラリ・データセットとして使用されます。
PDSはOpenFrameでUNIXファイル・システムのディレクトリとして管理され、pdsgenツールまたはdscreateツールで作成することができます。
以下は、dscreateツールを使用してTEST.PDSという名前のPDSを作成する例です。
$ dscreate -o PO TEST.PDSPDSを作成する際に注意すべきことは、SYSINタイプのデータセットは、レコード・フォーマットを「L」タイプに指定する必要があることです。「L」タイプは、メインフレームには存在しないレコード・フォーマットで、UNIXプラットフォームに合わせて改行(linefeed)を1つのレコード単位として認識するために、OpenFrameでサポートする新しいレコード・フォーマットです。
実行モジュールを管理するPDSには、コンパイルされた実行モジュールをPDSのディレクトリ・メンバーとして保存します。その他に、JCL、PROC、SYSINなどのファイル管理のために使用されるPDSには、メインフレームからダウンロードしたEBCDIC形式のソース・ファイルをdsmiginツールで文字セットを変換した変換ファイルをPDSのメンバーとして保存します。
2.6. GDGベースの定義
GDGベースはカタログ項目であり、gdgcreateツールで作成することができます。GDGベースを作成する際にGDG LIMIT値は、お客さまから正確な情報の提供を受けて作成してください。
以下は、gdgcreateツールを使用してGDGベースを定義するJCLの例です。
$ gdgcreate -l 255 TEST.GDG01GDGベースが特定のユーザー・カタログに登録されると、関連するすべてのGDS（GDGグループ内のデータセット）データセットも同ユーザー・カタログに登録されます。GDGベースを作成せずにGDSデータセットのカタロギングを行うと、AMS_ERR_GDG_NOT_REGISTERED (-4025)エラーが発生します。
2.7. 可変長データセットの移行
可変長データセットの移行は、一般的なデータセットの移行プロセスと同じです。ただし、データセットのレイアウトを分析して変換スキーマを作成する作業が複雑なので注意が必要です。
メインフレームからダウンロードした可変長データセットのソース・データセットは、下図のように順次ファイルと同一形式です。ただし、各レコードは4バイトのRDW(Record Descriptor Word)と引き続くデータで構成されます。RDWの最初の2バイトは、4バイトのRDWを含むレコード長情報を持ち、残りの2バイトは0で構成されます。このRDWのレコード情報で、レコードの先頭と末尾を区分することができます。
固定長データセットと同様に可変長データセットも、データセットのレイアウトをCOBOLコピーブック形式にまとめたものをcobgenschツールを実行して変換スキーマを作成します。しかし、プロジェクトの状況に応じて、COBOLコピーブック形式にまとめる段階を省略し、下記のような変換スキーマ・ファイルを早速作成して使用する場合もあります。
* Schema Version 7.1 L1, 01, V-REC, NULL, NULL, 0, 1:1, L2, 05, REC-KEY, EBC_ASC, NULL, 8, 1:1, L3, 05, ODO-LEN, COPY, NULL, 2, 1:1, L4, 05, ODO-FLD, NULL, NULL, 0, 0:4000, ODO-LEN L5, 07, ODO-DAT, EBC_ASC, NULL, 1, 1:1, * Condition L0, "\0", ( L1 L2 L3 L4 L5 )
上記例のスキーマ・ファイルは、ODO-LENフィールドの値によってODO-FLDの長さが変わる可変長データセットの例です。各レコードの変換を行う際に、レコードのODO-LENフィールド値を読み込んで、ODO-FLDの繰り返し回数とデータセットの長さを決定します。ソース・データセットと変換スキーマ・ファイルの準備ができたら、固定長データセットと同様に、dsmiginツールを使用してデータセットを移行します。
以下は、ソース・ファイル<TEST.VAR.raw>と変換スキーマ・ファイル<TEST.VAR.conv>を基に、dsmiginツールを使用してデータセット<TEST.VAR>を作成する例です。
$ dsmigin TEST.VAR.raw TEST.VAR –s TEST.VAR.conv –e JP -f VB
3. VSAMデータセットの移行
OpenFrameの一般的なVSAMデータセットの移行プロセスは以下のとおりです。
-
idcamsツールのDEFINE CLUSTERコマンドで空のVSAMデータセットを定義します。
-
dsmiginツールのRECATALOGオプションでデータをVSAMデータセットにインポートします。
上記の方法で移行されないデータセット(データセットの中に番号が欠けているレコードがある場合)は、別のRRDSインポート・プログラムを作成して移行する必要があります。
3.1. VSAMデータセットの定義
VSAMデータセットは、idcamsツールのDEFINE CLUSTERコマンドで定義します。
以下は、idcamsツールを使用してVSAMデータセットを定義する例です。
$ idcams DEFINE CLUSTER -n TEST.KSDS -o KS -k 6,0 -l 250,250
|
3.2. VSAMデータセットのインポート
VSAMデータセットを定義した後、dsmiginツールの-R(Recatalog)オプションでデータをVSAMデータセットにインポートします。
以下は、dsmiginツールを使用して、<XTB.XY1315>という非VSAMデータセットの全レコード・データをVSAMデータセット<TEST.VSAM.KSDS>にインポートする例です。
$ dsmigin XTB.XY1315 TEST.KSDS –s XTB.XY1315.conv –e JP -ROpenFrameの以前バージョンでは、移行ツールを使用してVSAMデータセットをインポートする方法をサポートしていなかったため、IDCAMSユーティリティのREPROコマンドを使って、SAM形式の非VSAMデータセットをVSAMデータセットにコピーする方法を使用しました。しかし、現バージョンでは、dsmiginツールを使用してVSAMデータセットをインポートする方法をサポートするようになったので、IDCAMSユーティリティよりはdsmiginツールを使用することをお勧めします。
3.3. データセット・インポート・プログラムの作成
データセットの中に番号が欠けているレコードが存在するVSAM RRDSのように、dsmiginツールを使用してインポートできないデータセットは、別のインポート・プログラムを作成してインポートします。
インポート・プログラムを使用したデータセットの移行プロセスは以下のとおりです。
-
メインフレームからダウンロードしたソース・データセットの文字セットを、dsmiginツールを使用して変換します。
-
idcamsツールのDEFINE CLUSTERコマンドを使用して、空のVSAMデータセットを定義します。
-
データセット・インポート・プログラムを実行してデータセットをインポートします。
データセット・インポート・プログラムは、なるべくUNIXプラットフォームで広く使われているC言語で作成してください。
|
WRITE関数を呼び出して個々のレコードを正しいキーの位置にインポートするプログラムを作成する方法については、OpenFrame Base『データセットガイド』の「データセットI/O API」を参照してください。 |
4. 静的変換と動的変換
OpenFrameのデータセットの移行方法には、静的変換と動的変換の2つの処理方法があります。データセットを移行する際に、データセットのスキーマ情報を確認して、データセットを静的変換で移行するか動的変換で移行するかを決定します。
4.1. 静的変換と動的変換の比較
-
静的変換
静的変換は、データセットの移行を実行する際、ユーザーが最初に$$COND条件に指定した移行パスから1つを決定し、すべてのレコードをこのパス情報を使用して移行する方法です。
-
動的変換
動的変換は、データセットの移行時に「動的変換テーブル」を管理しながら、ユーザーが指定したCOND条件をすべてのグループ・アイテムに対してチェックし、その情報を動的変換テーブルに適用して、COND条件の分析が完了した後にその情報を使用して移行する方法です。
動的変換はすべてのグループ・アイテムごとに$$COND条件を判断するため、静的変換よりパフォーマンスが低下します。ただし、動的変換のみ使用できる場合のように静的変換を使用できない場合や、動的変換の使用を推奨する場合のように静的変換は使用できるが、動的変換のほうがスキーマ情報を簡単に作成できる場合もあります。その他の場合は、必要に応じて動的変換を使用することができます。
4.2. 動的変換のみ使用できる場合
以下の場合は、動的変換を指定する必要があります。
-
スキーマ・ファイルを作成するコピーブックの$$COND条件を判断するフィールドがOCCURS内にある場合
$$COND条件を判断するフィールドがOCCURS内にある場合に静的変換を使用すると、最初のOCCURSの値によって変換する移行パスを決定しますが、最初のOCCURS以降の条件を判断するフィールドの値が最初のOCCURS値と異なる場合も最初に指定した移行パスで変換処理を行うため、正常に変換処理が行われないことがあります。
01 A OCCURS 10 TIMES. 05 KBN PIC X. 05 B1 PIC N(3) 05 B2 PIC X(6) REDEFINES B1. $$COND : KBN : "1" : B1 $$COND : KBN : !"1" : B2
4.3. 動的変換の使用を推奨する場合
以下の場合には、静的変換を使用することもできますが、動的変換を使用すると、より効率的にスキーマ・ファイルを作成することができます。
-
条件を判断する項目による変換対象項目がLIST形式で存在する場合
$$COND条件を満たし、変換対象項目がLIST形式で存在する場合、静的変換を使用すると、すべての項目を記述しなければなりません。理論的には最低2^n個を作成する必要があります。ただし、動的変換を使用すると、この数を2*nまでに減らすことができます。
03 A OCCURS 10 TIMES. 05 KBN1 PIC X. 05 B1 PIC N(3). 05 B2 PIC X(6) REDEFINES B1. 05 C1 PIC X(5). 05 C2 PIC 9(5) REDEFINES C1. 05 D1 PIC X(5). 05 D2 PIC 9(5) REDEFINES D1<静的変換を使用した$$COND条件の記述>
$COND : KBN1 : X"01" : B1, C1, D1 $COND : KBN1 : X"02" : B1, C1, D2 $COND : KBN1 : X"03" : B1, C2, D1 $COND : KBN1 : X"04" : B1, C2, D2 $COND : KBN1 : X"05" : B2, C1, D1 $COND : KBN1 : X"06" : B2, C1, D2 $COND : KBN1 : X"07" : B2, C2, D1 $COND : KBN1 : X"08" : B2, C2, D2<動的変換を使用した$$COND条件の記述>
$COND : KBN1 : X"01", X”02”, X”03”, X”04” : B1 $COND : KBN1 : X"04", X”05”, X”06”, X”07” : B2 $COND : KBN1 : X"01", X”02”, X”05”, X”06” : C1 $COND : KBN1 : X"03", X”04”, X”07”, X”08” : C2 $COND : KBN1 : X"01", X”03”, X”05”, X”07” : D1 $COND : KBN1 : X"02”, X”04”, X”06”, X”08” : D2
5. データセットの移行
本節では、固定長データセット、可変長データセット、REDEFINES文が使用されるデータセットの移行について説明します。
5.1. 固定長データセット
以下は、レコード長が16で、3つのレコードを持つメインフレームEBCDICデータセット<FL.SAMPLE.raw>です。
以下のCOBOLコピーブック<FL.SAMPLE.cpy>の例から、データセットのレイアウト情報を確認できます。
<FL.SAMPLE.cpy>
01 FIXEDLENGTH.
05 KEY PIC X(4).
05 TYPE PIC X(6).
05 DATA.
10 EBCDATA PIC X(3).
10 ZONEDDATA PIC S9(3).
データセットのレイアウト情報を確認したら、cobgenschツールを使用して以下のように変換スキーマ・ファイルを作成します。
$ cobgensch FL.SAMPLE.cpy以下は、cobgenschツールの実行によって作成された変換スキーマ・ファイルです。
<FL.SAMPLE.conv>
* Schema Version 7.1 L1, 01, FIXEDLENGTH, NULL, NULL, 0, 1:1, L2, 05, KEY, EBC_ASC, NULL, 4, 1:1, L3, 05, TYPE, EBC_ASC, NULL, 6, 1:1, L4, 05, DATA, NULL, NULL, 0, 1:1, L5, 10, EBCDATA, EBC_ASC, NULL, 3, 1:1, L6, 10, ZONEDDATA, ZONED, TRAILING, 3, 1:1, * Condition L0, "\0", ( L1 L2 L3 L4 L5 L6 )
ソース・データセットと変換スキーマ・ファイルを準備できたら、dsmiginツールを使用してデータセットを移行します。
$ dsmigin FL.SAMPLE.raw FL.SAMPLE.TEST –s FL.SAMPLE.conv –l 16データセットの移行が完了したら、dsviewツールを使用して結果を確認します。
5.2. 可変長データセット
以下は、可変長レコードを持つメインフレームのデータセットの例です。
00000001..AAAAAAAAAAAA 00000002..BBBB 00000003..CCCCCCCCCCCCCCCCCCCCC
メインフレームからダウンロードした可変長データセット<VB.SAMPLE.raw>は、以下のように各レコードの先頭に4バイトのRDW(Record Description Word)が含まれています。
このデータセットのレイアウト情報は、コピーブックに以下のように表示されます。
<VB.SAMPLE.cpy>
01 V-REC.
05 REC-KEY PIC X(8).
05 ODO-LEN PIC S9(4) COMP.
05 ODO-FLD OCCURS 4000 TIMES
DEPENDING ON ODO-LEN.
07 ODO-DAT PIC X(1).
指定されたコピーブックを入力としてcobgenschツールを実行すると、以下のような移行スキーマ・ファイルが作成されます。
* Schema Version 7.1 L1, 01, V-REC, NULL, NULL, 0, 1:1, L2, 05, REC-KEY, EBC_ASC, NULL, 8, 1:1, L3, 05, ODO-LEN, COPY, NULL, 2, 1:1, L4, 05, ODO-FLD, NULL, NULL, 0, 1:4000, ODO-LEN L5, 07, ODO-DAT, EBC_ASC, NULL, 1, 1:1, * Condition L0, "\0", ( L1 L2 L3 L4 L5 )
ソース・データセットと移行スキーマ・ファイルが準備されたら、dsmiginツールを使用してデータセットを移行します。
$ dsmigin VB.SAMPLE.raw VB.SAMPLE.TEST –s VB.SAMPLE.conv –e JP -f VB<VB.SAMPLE.raw>はダウンロードしたソース・ファイルであり、<VB.SAMPLE.TEST>は移行後に保存されるデータセットです。また、<VB.SAMPLE.conv>は移行スキーマ・ファイルです。
5.3. REDEFINES文が使用されたデータセット
以下のように、REDEFINES文が含まれているレイアウトを持つデータセットは、分岐条件に関する情報が必要です。
01 A.
05 B PIC X(01).
05 C PIC X(05).
05 D REDEFINES C.
10 E PIC X(02).
10 F PIC X(03).
フィールドBの値がAの場合にのみ再定義されたDの情報を参照し、その他の場合は、Cの情報を参照するには、コピーブックに$$COND条件文を追加する必要があります。
以下は、$$COND文の使用方法です。
$$COND : NAME_01 : VALUE_01 [: NAME_02 : VALUE_02 … ] : REDEFINE_NAME [...]-
$$COND
-
条件文の開始を示します。
-
-
NAME_01 : VALUE_01
-
フィールド名とそのフィールドに該当する条件値を順次に入力します。各項目を区切るときは、コロン(:)を使用します。dsmiginツールを使用して移行する場合、VALUE_#の条件値はすでに定義されているNAME_#フィールド項目の形式に自動的に変換されます。したがって、EBCDIC、ZONED、PACKEDなどのフィールド形式を考慮することなく、ASCII値を引用符(' ')で囲んで入力します。
-
複数の「NAME_# : VALUE_#」条件が使用される場合は、各条件をコロン(:)で区切ります。
-
-
REDEFINE_NAME
-
条件が成立した場合に実行する1つまたは複数のREDEFINEフィールド名を指定すると、条件文の作成が完了します。
-
条件文に値を入力するときに値のタイプを指定することで、フィールド・タイプを使用せずに必要なタイプに変換することができます。
-
ユーザー指定のフィールド・タイプは以下のとおりです。
タイプ 説明 !
NOT EQUALITYをチェックします。
'(empty)'
フィールドのデフォルト・タイプに変換します。
'A'
入力値をASCII文字のまま使用します。
'E'
EBCDIC文字に変換します。
'P' または 'UP'
パック10進数または符号なしパック10進数形式に変換します。
'Z' または 'UZ'
ゾーン10進数または符号なしゾーン10進数形式に変換します。
'G'
GRAPHIC(2バイト)文字に変換します。
'H'
入力値を16進数に変換します。(例: H"123" → 0x7B)
'X'
入力した2バイト値を1バイトの16進数に変換します。（例: X"12AB" → 0x12 0xAB）
'T' (Zoned、Packed、Nationalのみサポート)
フィールド・タイプを確認します。（例: T"ZONED"/T"PACKED"/T"NATIONAL" → フィールドがゾーン/パック10進数または国別文字であるかを確認）
-
パック10進数またはゾーン10進数の条件値を指定する場合は、そのフィールドが符号付き10進数と符号なし10進数のどちらの形式を使用するかを考慮して条件値のタイプを指定する必要があります。
たとえば、パック10進数フィールドの最終桁のHex値が'0x0C'(正数)または'0x0D'(負数)に指定されている場合は、'P’タイプを指定して符号付きパック10進数形式に条件値を変換します。最後のHex値が'0x0F’である場合は、'UP’タイプを指定して符号なしパック10進数形式に変換します。
ゾーン10進数の条件値を指定する場合は、ゾーン10進数フィールドの最終桁のHex値が'0xC0'(正数)または'0xD0'(負数)に指定されている場合、'Z’タイプを指定して符号付きゾーン10進数形式に条件値を変換する必要があります。最後のHex値が'0xF0’である場合は、'UZ’タイプを指定して符号なしゾーン10進数形式に変換します。
-
以下は、REDEFINES文が含まれているコピーブックに$$COND条件文を使用した例です。
01 A.
05 B PIC X(01).
05 C PIC X(05).
05 D REDEFINES C.
10 E PIC X(02).
10 F PIC X(03).
$$COND : B : "A" : D
cobgenschツールは、$$COND文の情報を参照して、dsmiginツールが使用できる移行スキーマを作成します。
以下は、作成された移行スキーマの例です。
* Schema Version 7.1 L1, 01, A, NULL, NULL, 0, 1:1, L2, 05, B, EBC_ASC, NULL, 1, 1:1, L3, 05, C, EBC_ASC, NULL, 5, 1:1, L4, 05, D, NULL, NULL, 0, 1:1, # REDEFINES C L5, 10, E, EBC_ASC, NULL, 2, 1:1, L6, 10, F, EBC_ASC, NULL, 3, 1:1, * Condition L2, "A", ( L1 L2 L4 L5 L6 ) L0, "\0", ( L1 L2 L3 )
このように作成されたスキーマ・ファイルを使用してデータセットのレコードを移行すると、データセットの各レコードのフィールドBの位置にある値に従って適切な移行ルールが適用され、データセットが移行されます。
上記例では、コピーブックで作成した条件以外に、もう1つの条件が作成されています。最終行に作成された「L0」というラベルを持つ条件は、デフォルトで実行される条件文です。
5.4. 複数のレイアウトを使用するデータセット
複数のレイアウトを使用するデータセットは、REDEFINES文を処理する方法と同様に条件文を作成します。
01 AAA-A.
03 BBB-A.
05 DATA-1 PIC X(01).
05 DATA-2 PIC X(04).
05 DATA-A REDEFINES DATA-2.
07 DATA-A1 PIC 9(02).
07 DATA-A2 PIC X(02).
01 AAA-B.
03 BBB-B.
05 DATA-3 PIC 9(01).
05 DATA-4 PIC 9(04).
05 DATA-D REDEFINES DATA-4.
07 DATA-D1 PIC 9(01).
07 DATA-D2 PIC X(03).
上記のように01レベルの項目が複数存在する場合、2番目からのレイアウトを使用するには、REDEFINES文の処理と同様に$$COND文を使用する必要があります。
以下は、特定のレイアウトを使用するための$$COND文を作成する方法です。
$$COND : DATA-3 : "B" : AAA-B以下は、2番目のレイアウトにあるREDEFINES文を一緒に指定するために作成した$$COND文です。
$$COND : DATA-3 : "D" : AAA-B DATA-D以下は、cobgenschツールを使用して作成したスキーマ・ファイルです。
* Schema Version 7.1 L1, 01, AAA-A, NULL, NULL, 0, 1:1, L2, 03, BBB-A, NULL, NULL, 0, 1:1, L3, 05, DATA-1, EBC_ASC, NULL, 1, 1:1, L4, 05, DATA-2, EBC_ASC, NULL, 4, 1:1, L5, 05, DATA-A, NULL, NULL, 0, 1:1, # REDEFINES DATA-2 L6, 07, DATA-A1, U_ZONED, NULL, 2, 1:1, L7, 07, DATA-A2, EBC_ASC, NULL, 2, 1:1, L8, 01, AAA-B, NULL, NULL, 0, 1:1, L9, 03, BBB-B, NULL, NULL, 0, 1:1, L10, 05, DATA-3, U_ZONED, NULL, 1, 1:1, L11, 05, DATA-4, U_ZONED, NULL, 4, 1:1, L12, 05, DATA-D, NULL, NULL, 0, 1:1, # REDEFINES DATA-4 L13, 07, DATA-D1, U_ZONED, NULL, 1, 1:1, L14, 07, DATA-D2, EBC_ASC, NULL, 3, 1:1, * Condition L10, "B", ( L8 L9 L10 L11 ) L10, "D", ( L8 L9 L10 L12 L13 L14 ) L0, "\0", ( L1 L2 L3 L4 )
作成されたスキーマ・ファイルでは、01レベルを含む2つのレイアウトが含まれており、デフォルト条件を除く、$$COND文で作成した条件がすべて2番目の01レベル項目であるフィールドAAA-Bから始まることを確認できます。
このように生成されたスキーマ・ファイルを利用すると、REDEFINES文を使用したのと同様にフィールドDATA-3の位置にある値に応じて移行規則が適用され、複数のレイアウトを使用するデータセットを移行することができます。