翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
データ移行の課題
ほとんどのメインフレーム環境には、リレーショナルデータベースに加えて、シーケンシャルファイルや Virtual Storage Access Method (VSAM) ファイルなどの物理データセットが組み合わされています。データベースの移行では、多くの場合、データを抽出、変換、およびターゲットデータベースに挿入するツールが必要です。このセクションでは、物理データセットの課題について概説します。
文字セット変換
データファイルを EBCDIC から ASCII に変換するには、変換テーブルを使用する必要があります。変換テーブル
次の表は、EBCDIC から ASCII への変換テーブルを使用する場合に、どのデータ型が変換の問題による影響を受けるかを示しています。
文字セット変換の問題がないデータ型 |
文字セット変換の問題があるデータ型 |
|---|---|
PIC X (n) |
PIC S9 (n) |
PIC A (n) |
PIC S9 または 9 バイナリ/COMP |
PIC 9 (n) (符号なし) |
PIC S9 または 9 COMP-3 |
PIC S9 (n) 符号は別 |
ゾーン 10 進数形式
ゾーン 10 進数形式
次のテーブルは、EBCDIC 値と ASCII 値の両方で「+/-」 1～9 を表すようにデータに格納されている値を示しています。
数字 |
EBCDIC 16 進数バイナリ |
EBCDIC ディスプレイ |
ASCII 16 進数バイナリ |
ASCII ディスプレイ |
|---|---|---|---|---|
+0 |
X"C0"–1100 0000 |
{ |
X"30"–0011 0000 |
0 |
+1 |
X"C1"–1100 0001 |
A |
X"31"–0011 0001 |
1 |
2+ |
X"C2"–1100 0010 |
B |
X"32"–0011 0010 |
2 |
+3 |
X"C3"–1100 0011 |
C |
X"33"–0011 0011 |
3 |
+4 |
X"C4"–1100 0100 |
D |
X"34"–0011 0100 |
4 |
5+ |
X"C5"–1100 0101 |
E |
X"35"–0011 0101 |
5 |
+6 |
X"C6"–1100 0110 |
F |
X"36"–0011 0110 |
6 |
+7 |
X"C7"–1100 0111 |
G |
X"37"–0011 0111 |
7 |
+8 |
X"C8"–1100 1000 |
H |
X"38"–0011 1000 |
8 |
+9 |
X"C9"–1100 1001 |
I |
X"39"–0011 1001 |
9 |
-0 |
X"D0"–1101 0000 |
} |
X"70"–0111 0000 |
p |
-1 |
X"D1"–1101 0001 |
J |
X"71"–0111 0001 |
q |
-2 |
X"D2"–1101 0010 |
K |
X"72"–0111 0010 |
r |
-3 |
X"D3"–1101 0011 |
L |
X"73"–0111 0011 |
s |
-4 |
X"D4"–1101 0100 |
M |
X"74"–0111 0100 |
t |
-5 |
X"D5"–1101 0101 |
N |
X"75"–0111 0101 |
u |
-6 |
X"D6"–1101 0110 |
O |
X"76"–0111 0110 |
v |
-7 |
X"D7"–1101 0111 |
P |
X"77"–0111 0111 |
w |
-8 |
X"D8"–1101 0100 |
Q |
X"78"–0111 1000 |
x |
-9 |
X"D9"–1101 1001 |
R |
X"79"–0111 1001 |
y |
例えば、PIC S9 (4) に "-1234"という値が含まれている場合、その値は EBCDIC に X"F1F2F3D4" として格納されます。各バイトは EBCDIC から ASCII への変換テーブルで検索され、対応する ASCII 値に翻訳されます。この例では、最初の 3 文字が EBCDIC 数値から ASCII 数値 X"313233" に正しく変換されます。ただし、オーバーパンチ符号ニブル X"D4" "M" を含む最後の文字は、ASCII の "M" に相当する X"4D" に変換されます。
このゾーン 10 進文字の正しい ASCII 値は X"74" "t" です。EBCDIC から ASCII への変換テーブルを使用してこのフィールドを変換すると、結果は X"3132334Dv" "123M" になり、正しい X"31323374" "123t" ではなくなります。このデータを正しく処理しないと、アプリケーションでデータ破損や無効な数値データエラーが発生する可能性があります。
バイナリ (COMP または COMP-4)
バイナリ (COMP または COMP-4)
PIC 9 (4) COMP は 2 バイトのバイナリフィールド (C の短整数と同じ) で、"0"～"65535" の値を含むことができます。表示数値フィールドに最大値を格納するには PIC 9 (6) が必要で、これによってさらに 2 バイトが消費されます。次の例は、2 進数で表される値 "1234" を示しています。
バイト 1 |
バイト 2 |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
1 |
0 |
1 |
0 |
0 |
1 |
0 |
16 進数データとして表される前述の例には、値 X"04D2"が含まれています。EBCDIC から ASCII への変換テーブルを使用してこのデータを変換すると、データは X"1A4B" となります。数値として解釈すると、値は "6731" で、予想される "1234" ではありません。
COMP データは EBCDIC と ASCII の両方で同じように格納されるため、変換の必要はありません。COMP データを正しく処理しないと、データが破損する可能性があります。COMP データ項目の値はすべて有効な数値なので、アプリケーションから数値処理エラーが報告されることはありません。値が単純に正しくないのです。前述の例が示すように、"1234" の値は "6731" になります。
パック 10 進数形式 (COMP-3)
COMP-3 フィールド
COMP-3 フィールドには、最後のバイトの下位ニブルに符号なし値と正の符号付き値を表す「C」の文字と、負の符号付き値を表す「D」が含まれます。COMP-3 データは EBCDIC と ASCII で同じように格納されるため、変換の必要はありません。EBCDIC から ASCII への変換テーブルを使用して COMP-3 データを変換すると、データが破損し、アプリケーションで無効な数値データエラーが発生します。
複雑なレコードレイアウト
データファイルを EBCDIC から ASCII に変換する際に考慮すべき問題は、ゾーン 10 進数、COMP、または COMP-3 フィールドを含むファイルだけではありません。ファイル自体にさまざまなレコードレイアウトが含まれている場合や、REDEFINES 句を使用して特別な処理が必要なデータ領域の組み合わせを導入する領域が含まれている場合があります。そのような場合は、Micro Focus データファイルエディタ
-
非テキストデータを含む単一レコード構造
-
REDEFINES 領域内の非テキストデータを含む単一レコード構造
-
非テキストデータを含む複数の 01 レコード構造
非テキストデータを含む単一レコード構造
非テキストデータを含む単一レコード構造とは、データ領域に ZD、COMP、または COMP-3 データ型が含まれる REDEFINES のない 01 レコード領域が 1 つ含まれているファイルのことです。テキスト以外のデータを含む単一のレコード構造には、Micro Focus データファイルエディタを使用して構築されたシンプルな「デフォルトレコードレイアウト」が必要です。次の例は、非テキストデータを含む単一のレコード構造を示しています。
01 S-PARTS-RECORD. 05 S-PART-ID PIC 9(9) COMP. 05 S-PART-TYPE PIC X(2). 05 S-PART-NAME PIC X(40). 05 S-SUB-PART-DATA. 10 S-SUB-DESC PIC X(40). 10 S-SUB-COST PIC S9(4)V99 COMP. 10 S-SUB-WEIGHT PIC 9(4)V99 COMP-3. 10 FILLER PIC X(34).
REDEFINES 領域内の非テキストデータを含む単一レコード構造
REDEFINES 領域内に非テキストデータを含む単一レコード構造とは、データ領域に ZD、COMP、または COMP-3 データ型が含まれる REDEFINES のある 1 つの 01 レコード領域を含む任意のファイルです。次の例は、テキストデータと非テキストデータの組み合わせを含む共通の PIC X (80) 領域を定義する 2 つの REDEFINES を示しています。
01 PARTS-RECORD. 05 PART-ID PIC 9(9) COMP. 05 PART-TYPE PIC X(2). 05 PART-NAME PIC X(40). 05 PART-DATA PIC X(80). 05 MAIN-PART REDEFINES PART-DATA. 10 MAIN-DESC PIC X(40). 10 MAIN-SUB-COUNT PIC 9(2) COMP. 10 MAIN-ASSEMBLIES OCCURS 10. 15 MAIN-SUB-ID PIC 9(9) COMP. 05 SUB-PART REDEFINES PART-DATA. 10 SUB-DESC PIC X(40). 10 SUB-COST PIC S9(4)V99 COMP. 10 SUB-WEIGHT PIC 9(4)V99 COMP-3. 10 FILLER PIC X(34).
このタイプのレコード構造を最初に分解して、レコード構造の複数のビューを作成する REDEFINES ステートメントを削除する必要があります。レコード構造を分解しないと、作成された構造ファイルは REDEFINES の下の領域を無視し、領域全体をテキストデータとして扱います。前述の例では、REDEFINES 句の下にある 2 つの異なる非テキスト構造について説明しています。作成した構造ファイルには、これらの領域をデータコンバーターが対象とする一意の構造の一部として記述する必要があります。次の例は、REDEFINES が削除された後の 2 つの一意のレイアウトを示しています。
01 M-PARTS-RECORD. 05 M-PART-ID PIC 9(9) COMP. 05 M-PART-TYPE PIC X(2). 05 M-PART-NAME PIC X(40). 05 M-PART-DATA. 10 M-MAIN-DESC PIC X(40). 10 M-MAIN-SUB-COUNT PIC 9(2) COMP. 10 M-MAIN-ASSEMBLIES OCCURS 10. 15 M-MAIN-SUB-ID PIC 9(9) COMP. 01 S-PARTS-RECORD. 05 S-PART-ID PIC 9(9) COMP. 05 S-PART-TYPE PIC X(2). 05 S-PART-NAME PIC X(40). 05 S-SUB-PART-DATA. 10 S-SUB-DESC PIC X(40). 10 S-SUB-COST PIC S9(4)V99 COMP. 10 S-SUB-WEIGHT PIC 9(4)V99 COMP-3. 10 FILLER PIC X(34).
次のステップは、あるレコードレイアウトを他方のレコードレイアウトから分離するために使用できる条件ステートメントを決定することです。条件ステートメントを決定するには、対象分野の専門家に相談するか、ソースコードを調べることを推奨します。次の例はソースコードを示しています。
MOVE "M" TO PART-TYPE MOVE "MAIN ASSEMBLY" TO PART-NAME MOVE "S" TO PART-TYPE MOVE "SUB ASSEMBLY 1" TO PART-NAME
ソースコードでは、「PART-TYPE」フィールドがレコードタイプの決定に使用されていることがわかります。値「M」は「M-PART-RECORD」に使用され、値「S」は「S-PART-RECORD」に使用されます。これで、「M-PART-ID」フィールドと「S-PART-ID」フィールドで特定したそれぞれの条件を使用して、2 つの条件レコードのいずれかを含む構造ファイルを作成できます。または、1 つのデフォルトレイアウトと 1 つの条件付きレイアウトを作成することもできます。
非テキストデータを含む複数の 01 レコード構造
非テキストデータを含む複数の 01 レコード構造とは、次の例に示すように、ZD、COMP、または COMP-3 データ型を含む複数の 01 レコード領域を含むファイルのことです。
01 M-PARTS-RECORD. 05 M-PART-ID PIC 9(9) COMP. 05 M-PART-TYPE PIC X(2). 05 M-PART-NAME PIC X(40). 05 M-PART-DATA. 10 M-MAIN-DESC PIC X(40). 10 M-MAIN-SUB-COUNT PIC 9(2) COMP. 10 M-MAIN-ASSEMBLIES OCCURS 10. 15 M-MAIN-SUB-ID PIC 9(9) COMP. 01 S-PARTS-RECORD. 05 S-PART-ID PIC 9(9) COMP. 05 S-PART-TYPE PIC X(2). 05 S-PART-NAME PIC X(40). 05 S-SUB-PART-DATA. 10 S-SUB-DESC PIC X(40). 10 S-SUB-COST PIC S9(4)V99 COMP. 10 S-SUB-WEIGHT PIC 9(4)V99 COMP-3. 10 FILLER PIC X(34).
最初のステップは、1 つのレコードレイアウトを別のレイアウトから分離するために使用できる条件ステートメントを決定することです。条件ステートメントを決定するには、対象分野の専門家に相談するか、ソースコードを調べることを推奨します。次の例はソースコードを示しています。
MOVE "M" TO PART-TYPE MOVE "MAIN ASSEMBLY" TO PART-NAME MOVE "S" TO PART-TYPE MOVE "SUB ASSEMBLY 1" TO PART-NAME
ソースコードでは、「PART-TYPE」フィールドがレコードタイプの決定に使用されていることがわかります。値「M」は「M-PART-RECORD」に使用され、値「S」は「S-PART-RECORD」に使用されます。これで、「M-PART-ID」フィールドと「S-PART-ID」フィールドで特定したそれぞれの条件を使用して、2 つの条件レコードのいずれかを含む構造ファイルを作成できます。または、1 つのデフォルトレイアウトと 1 つの条件付きレイアウトを作成することもできます。
部分的なレコード記述を使用するプログラム
コピーファイルを使用してファイルの形式全体を記述するのが良いプログラミングスタイルですが、特定のレコードやデータ構造を対象とする場合、プログラムに必要な構造のみをプログラマーが手作業でコーディングすることがあります。これには、大きな FILLER 項目で隠されているファイルのセクションや、それぞれがファイルの一部を記述する複数のプログラムが含まれる場合があります。このような場合、次の PROGRAM1 と PROGRAM2 の例に示すように、ファイルの完全な説明を含む 1 つのプログラムを作成する必要があります。
PROGRAM1 の例:
01 M-PARTS-RECORD. 05 M-PART-ID PIC 9(9) COMP. 05 M-PART-TYPE PIC X(2). 05 M-PART-NAME PIC X(40). 05 M-PART-DATA. 10 M-MAIN-DESC PIC X(40). 10 M-MAIN-SUB-COUNT PIC 9(2) COMP. 10 M-MAIN-ASSEMBLIES OCCURS 10. 15 M-MAIN-SUB-ID PIC 9(9) COMP.
PROGRAM2 の例:
01 S-PARTS-RECORD. 05 S-PART-ID PIC 9(9) COMP. 05 S-PART-TYPE PIC X(2). 05 S-PART-NAME PIC X(40). 05 S-SUB-PART-DATA. 10 S-SUB-DESC PIC X(40). 10 S-SUB-COST PIC S9(4)V99 COMP. 10 S-SUB-WEIGHT PIC 9(4)V99 COMP-3. 10 FILLER PIC X(34).
前述の例では、各プログラムのデータディクショナリを 1 つずつ読み込んだ後に、さまざまな構造をレコードレイアウトに追加できます。ただし、次の PROGRAM1 と PROGRAM2 の例が示すように、より複雑な状況が発生する可能性があります。
PROGRAM1 の例:
01 M-PARTS-RECORD. 05 M-PART-ID PIC 9(9) COMP. 05 M-PART-TYPE PIC X(2). 05 M-PART-NAME PIC X(40). 05 FILLER PIC X(82).
PROGRAM2 の例:
01 S-PARTS-RECORD. 05 S-PART-ID PIC 9(9) COMP. 05 S-PART-TYPE PIC X(2). 05 S-PART-NAME PIC X(40). 05 S-SUB-PART-DATA. 10 S-SUB-DESC PIC X(40). 10 S-SUB-COST PIC S9(4)V99 COMP. 10 S-SUB-WEIGHT PIC 9(4)V99 COMP-3. 10 FILLER PIC X(34).
この場合、PROGRAM1 のレコードレイアウトの一部は FILLER ステートメントを使用してマスクされます。この情報を使用してレコードレイアウトを作成すると、「M-PARTS-RECORD」の FILLER ブロック内のデータはテキストとして扱われ、正しく変換されません。開発者は、レコードレイアウトをコンストラクトする前に、デューデリジェンスを実施してファイルの絶対構造を確認する必要があります。
リレーショナルデータベース
メインフレームのリレーショナルデータベースを分散型リレーショナルデータベースに変換する際には、いくつかの考慮事項があります。例えば、ASCII 文字セットや ANSI 文字セットに移行すると、データとの照合順序の問題が生じる可能性があります。これらの問題の詳細については、このガイドの「アプリケーション移行の課題」にある「照合順序」のセクションを参照してください。
例えば、キー列は、メインフレームで返される順序とは異なる順序でデータを返す場合があります。CURSORS 句と WHERE 句は、データベースの照合順序を尊重します。データが EBCDIC 照合順序に依存している場合は、可能であれば、データベースで EBCDIC 照合順序を使用します。または、必要に応じて EBCDIC 照合順序を使用するようにアプリケーションロジックを変更してください。SQL ステートメントで代替の照合順序を指定すると、ステートメントの実行時に待ち時間が長くなることを考慮します。
データボリューム
すべての移行と同様に、メインフレームから分散環境にデータを移行する必要があります。どの移行ツールを使用するかを検討する前に、まず移行するデータの量を検討することが重要です。データの移行は次の 4 つに分けることができます。
-
統合テストデータ
-
システムテストデータ
-
カットオーバーデータまたは稼働開始データ
-
履歴データとアーカイブデータ
統合データとシステムテストデータの移行は、使用前に長期間にわたってデータを移動できるため、通常は大きな問題にはなりません。代わりに、カットオーバーデータや稼働開始データ、履歴データやアーカイブデータに時間と労力を費やすほうがよいでしょう。
物理ファイルとデータベーステーブルの両方を含め、移行の早い段階で稼働開始イベント用のデータ量を決定するのがベストプラクティスです。ファイルのエクスポートで収集したデータを使用して、このデータを EBCDIC から ASCII に変換し、そのデータをターゲットシステムにインポートすることで、メインフレームからのデータのカットオーバーにかかる時間を見積もることができます。ビジネスがダウンする可能性のある時間や、稼働開始のデプロイ後に取り戻す時間を要するような状況によっては、データ移行ウィンドウが許容できない場合があります。次に、データカットオーバーを最大 50% 削減できる EBCDIC にとどまるか、それとも長期にわたる業務停止や復旧の計画など、他の対策を講じるかを決定する必要があります。
履歴データは並行プロジェクトとして実施されることが多く、通常は稼働開始のデプロイ前に完成しません。履歴データの変換は、特にレコードやテーブルのレイアウトが時間の経過とともに変化していると、難しい場合があります。組織がコンプライアンスや規制の要件を満たすことができるように、必要なデータを移行する計画を立てることを推奨します。
