翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
データ移行の課題
リレーショナルデータベースに加えて、ほとんどのメインフレーム環境には、シーケンシャルファイルや仮想ストレージアクセス方法 (VSAM) ファイルなどの物理データセットの組み合わせがあります。データベースの移行では、多くの場合、データを抽出、変換、およびターゲットデータベースに挿入するツールが必要です。このセクションでは、物理データセットの課題について概説します。
文字セット変換
データファイルを から EBCDIC に変換するには、変換テーブルを使用する必要がありますASCII。変換テーブル
次の表は、 EBCDICから へのASCII変換テーブルを使用する場合、変換の問題によって影響を受けるデータ型を示しています。
文字セット変換の問題がないデータ型 |
文字セット変換の問題があるデータ型 |
|---|---|
PIC X (n) |
PIC S9 (n) |
PIC A (n) |
PIC S9 または 9 BINARY/COMP |
PIC 9 (n) (署名なし） |
PIC S9 または 9 COMP-3 |
PIC S9 (n) SIGN SEPARATE |
ゾーン 10 進数形式
ゾーン 10 進数形式
次の表は、 EBCDICと の値の両方で「+/-」1～9 を表すためにデータに保存されているASCII値を示しています。
数字 |
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 |
例えば、PICS9 (4) に「-1234」という値が含まれている場合、その値は X「F1F2F3D4EBCDIC」として に保存されます。各バイトは EBCDICから へのASCII変換テーブルで検索され、対応するASCII値に変換されます。この例では、最初の 3 EBCDIC 文字が数値から数値 X"313233" ASCII に正しく変換されます。ただし、オーバーパンチされた符号ニブル X"D4" "M" を含む最後の文字は、ASCII「M" に相当する X"4D" に変換されます。
このゾーン 10 進数の文字の正しいASCII値は X"74" "t" です。このフィールドを変換するために EBCDICから ASCIIへの変換テーブルを使用する場合、結果は X"3132334Dv" "123M" であり、正しい X"31323374" "123t" ではありません。このデータを正しく処理しないと、アプリケーションでデータ破損や無効な数値データエラーが発生する可能性があります。
BINARY (COMP または COMP-4)
BINARY (COMP または COMP-4)
PIC 9 (4) COMPは 2 バイトのバイナリフィールド (C の短い整数と同じ) で、「0」～「65535」の値を含めることができます。最大値を表示数値フィールドに保存するには、9 (6) PIC が必要で、さらに 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-to-ASCII conversion テーブルを使用して COMP-3 データを変換すると、データが破損し、アプリケーションで無効な数値データエラーが発生します。
複雑なレコードレイアウト
データファイルを から に変換するときに考慮する問題はCOMP、ゾーン 10 進数、、または COMP-3 EBCDIC フィールドを含むファイルだけではありませんASCII。ファイル自体には、さまざまなレコードレイアウトや、 REDEFINES句を使用して特別な処理が必要なデータ領域の組み合わせを導入する領域を含めることができます。このような場合は、Micro Focus データファイルエディタ
-
非テキストデータを含む単一レコード構造
-
の領域内の非テキストデータを含む単一レコード構造 REDEFINES
-
非テキストデータを含む複数の 01 レコード構造
非テキストデータを含む単一レコード構造
テキスト以外のデータを含む 1 つのレコード構造は、 を含まない単一の 01 レコード領域を含む任意のファイルでREDEFINES、データ領域には ZD、COMP、または COMP-3 データ型が含まれます。非テキストデータを含む単一レコード構造には、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は、 を含む単一の 01 レコード領域を含む任意のファイルでREDEFINES、データ領域には ZD、COMP、または COMP-3 データ型が含まれます。次の例はREDEFINES、テキストデータと非テキストデータを組み合わせた共通の PIC X(80) エリアを定義する 2 つの を示しています。
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。これで、2 つの条件レコードのいずれかを含む構造ファイルを作成できます。1 つは、「M-PART-ID」フィールドと「S-PART-ID」フィールドで識別された条件を使用してそれぞれに作成します。または、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。これで、2 つの条件レコードのいずれかを含む構造ファイルを作成できます。1 つは、「M-PART-ID」フィールドと「S-PART-ID」フィールドで識別された条件を使用してそれぞれに作成します。または、1 つのデフォルトレイアウトと 1 つの条件付きレイアウトを作成することもできます。
部分的なレコード記述を使用するプログラム
コピーファイルを使用してファイルの形式全体を記述するのが良いプログラミングスタイルですが、特定のレコードやデータ構造を対象とする場合、プログラムに必要な構造のみをプログラマーが手作業でコーディングすることがあります。これには、大きなFILLER項目によってマスクされたファイルのセクションや、それぞれがファイルの一部を記述する複数のプログラムが含まれる場合があります。このような場合は、次の 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 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できる にとどまるか、あるいは事業停止や復旧の延長計画など、他の手段を取るかを決定する必要があります。
履歴データは並行プロジェクトとして実施されることが多く、通常は稼働開始のデプロイ前に完成しません。履歴データの変換は、特にレコードやテーブルのレイアウトが時間の経過とともに変化していると、難しい場合があります。組織がコンプライアンスや規制の要件を満たすことができるように、必要なデータを移行する計画を立てることを推奨します。
