なぜ、データ移行が難しいのか？
データ移行設計に必要な考慮点
【メインフレームテープ編】

仮想テープ装置導入時に避けては通れない作業としてテープ・データセットの移行作業がある。基本はDITTO等を使用したコピー作業なのであるが、蓋を開けてみれば考慮点の多さから、移行環境はかなり複雑なものになる。設計段階では考慮点が漠然としており、最善の方法を見つけ出す為に苦戦するはずである。 私の経験から以下に一般的な考慮点を列記する。もちろんテープ運用環境により全てが該当する訳ではない。それ以上にお客様毎にテープ運用の細部は千差万別で、それに対するケアはここにあげる一般的考慮点以上に厄介なものになるケースも少なくない。

 

 

■"強制移行"か"強制移行＋自然移行か"の決定

出力を新規装置側に向ける（自然移行）が一般的であろう。コピーツールで強制的にコピーし移行する（強制移行）は移行進捗を加速化する為には効果的であるが、強制であるが故に、考慮点も多い。

■移行対象本数の調査

移行計画時に必要となる基本情報である。意外とアバウトな数字しか出てこないケースが多いのであらゆる情報を組み合わせて精度を高める必要がある。

■各ボリュームのカテゴリー分け（1:1? n:1? 1:n? n:n? cataloged? GDG? SL/NL?)

既に述べた部分もあるが、テープ属性の仕分け。意外と苦戦するがこれも基本情報なので高精度を要求される。

■移行スケジュールの作成

移行速度の見積り、日別移行対象ボリュームの選定が必要。移行速度より一日に必ず移行できる本数を計画する事が必要。移行に伴い、JCLの変更、仮想テープ装置への登録、カタログの張り替えなどが発生し、これらが済みの状態で移行が間に合わないという状況は避けなくてはならない。移行対象ボリュームの選定は基本”当時使用しないもの”を対象にする。自然移行では”当日出力から使用するもの”を対象とする。

■本番に影響を及ぼさない移行設計

基本中の基本。これを考慮するが故に、移行は厄介なのである。

■移行用装置確保の考慮

移行作業で使用するドライブ台数の確保。移行作業に割り振った為に本番処理の遅延が発生しない様に、時間単位で使用できる台数を見積る事。つまりテープ運用における使用ドライブ台数状況の調査といった、細かい分析系作業も必要となる。

■ターゲット・ボルシルの変更の有無検討

データ移行はターゲット・ボルシルを変更するか否かを選択できる。その選択によりコピー方法も大きく変わってくる。知らない間にボリューム管理が煩雑化してしまっている状況ではボルシルを変更しデータ移行する事により再整理する事も可能。ボルシル範囲に断片化が多いと仮想テープへのボルシル登録の関係上、問題が出る場合もあるので要注意。

■コピーツールの決定

データ移行用アプリケーションの検討も一案だが、コスト面やお客様の環境に適合させる事を考えると、DITTOを使用し、移行環境を構築した方が柔軟性がある。また、DITTOがない環境ではIEBGENERを使用したコピーになるが、ボリューム名の他に、それぞれのファイル名も必要になるので、この洗い出しに手が掛かる。システム的にテープラベルから抽出するのが最適であるが、コピー前の準備作業と考えると時間がかかり、移行進捗に影響する。

■移行手順書の作成

移行環境構築後、コピー作業員用に手順書をわかりやすく作成し用意しておく。

■進捗/課題/問題管理

コピー作業は毎日時間に追われながら大量のテープを扱う為、担当者には作業に集中させる必要がある。その為、コピー作業員の他に監督者を用意した方がよい。

■ソースボリュームの保管

コピー済のソースボリュームの管理も疎かにできない。考慮点は、いかなる場合にもすぐに見つけ出す事ができ、緊急時に備える。データの機密保護は言う迄もない。

■緊急時対処方法の策定

事前にコピー作業が本番に与えるあらゆるケースを想定し、回避策を講じておく。

■移行環境構築（設計/開発）

移行設計書を元に必要なツールを設計／開発し、それらを使用した移行環境を構築する必要がある。もちろん、環境のテストや移行リハーサルも不可欠である。

■移行作業に関する各種報告書の作成と報告ラインの決定

移行スケジュールの部署間通達、移行完了報告、課題／問題報告書、作業日次レポート等の作成が必要

■マルチ・ボリュームの考慮

マルチ・ボリュームについてはマルチ・ファイルの様な考慮点はないが、一つ注意点としてはDITTOでのコピーを採用する場合。マルチ・ボリュームについてのDITTO機能はかなり危ないので正常終了を鵜呑みにしては痛い目にあう。マルチ・ボリュームのセットが完全で完全な順序であれば問題ないが、抜けがあったり、乱れがあると知らない間に正常にコピーできていないケースが生まれる。もちろん、これをチェックする術はあるので研究が必要。

■マルチ・ファイルボリュームの考慮

マルチファイル・マルチボリューム・テープの場合に注意が必要。移行元／移行先のファイルの位置が崩れる場合、運用に影響を与える可能性があるのでしっかりと事前確認が必要。移行元／移行先ともに同一サイズの媒体であっても安心できないので要注意。

■マルチ・ボリュームの判別

マルチボリューム群をどの様に判別するかの問題だが、テープ管理システム（TMS）からの情報があればいいのだが、TMS管理されていない場合は、カタログやJCL解析という方法で判別しなくてはならない。基本的にお客様から戴くマルチボリューム情報を元にし、精度を高める為にこの様なダブル・チェックも怠ってはならない。

■マルチ・ボリューム・マルチ・ファイルの考慮

前出の「マルチ・ボリューム」「マルチ・ファイル」を参考にして欲しい。

■アプリケーションに依存したデータセットの考慮

DITTOでコピーできないデータセットがある。DFDSSのDUMPデータセットなどがそう。IBM社SEの話もまちまちなのだが、ＮＧであるという情報がある限りはCOPYDUMPで複製するのが無難。因にIEBGENERでのコピーは間違いなくNG。

■カタログデータセットのリカタログ考慮

移行時のカタログとして思いあたるのは２点。一つ目は3480から3490へのカタログ・データセットのリカタログである。メインフレーム技術者にとってはリカタログは難しい作業ではないが、問題はそのタイミングと、さらにカタログされているデータセットを見分ける事にある。テープ・データセットの属性が全てしっかり管理されていれば苦労はないのだが、これまで10社様以上で作業させて戴いたが、完全な情報は皆無。したがって、移行作業の中に「カタログ・データセットを見つける」ステップを追加しなくてはならない。二つ目はGDG管理されたテープ・データセットの移行である。3490へのリカタログと同様、タイミングと見分け作業が必要になるが、さらに厄介である。2002年にテープ・データセット全てがGDG管理されているお客様の移行をした事がある。膨大なテープの中にはマルチに記録された予想を遥かに上回るデータセットの数。これが全てGDG管理されており、さらに、移行はボルシルを変更しながらという難題であった。もちろん移行前との世代は継承するのが大前提。この様にGDG管理されているお持ちのお客様は要注意である。

■仮想テープ定義自動登録

ターゲット・ボリュームへのコピー前に仮想テープ側へボルシルの登録を行う必要がある。事前に全ボルシルを登録できるケースもあるが、移行期間中に、コピー未済ボルシルの誤使用等を考慮すると移行直前の登録が安全である。

■コピーJCL自動作成

移行JCL作成ツールを作成し、移行環境に組み入れる必要がある。これにより、移行作業の効率化とともに、人為的ミスも回避できる。

■コピー結果チェック

コピー開始直後の数日間はコピー元、コピー先のデータを全件コンペアーをすべきである。しかし、かなりの時間がかかるので移行進捗に影響する。移行環境について問題なしと判断が下された後は、ヘッダー情報やコピーブロック数の比較によるチェックで良いと思われる。

■ソースボリューム排他制御方法

コピー中もしくは、コピー直後にソース・ボリュームへの書き込みを回避する為にソース・ボリュームに対してはコピー直前よりロックをかけなくてはならない。

■ターゲットボリュームの未使用チェック

コピー処理の先頭ステップにおいてターゲットボリュームへ排他をかけながら、そのボリュームにデータが何も書き込まれていない事を確認する必要がある。データが記録されているケースにおいては、そのデータの必要性を確認した上でコピー作業を実施しなくてはならず、その為コピー直前のステップでチェックを施す必要がある。

■移行作業マニフェストファイルの出力

移行作業の履歴は全て残すのがいいだろう。特にコピー結果やそのチェックステップのアウトプットは必須である。

■移行進捗管理ファイルの出力

進捗管理用のファイルを都度書き出しておくべきである。

■JCL変更箇所の考慮

ボルシルの変更の有無、ソース装置とターゲット装置のユニット名の違いにより、コピー作業に合わせたJCL変更が必要になってくる。コピー作業とのタイミングが難しいので注意。

 

この他にも細かい考慮点は存在するが、環境により様々な条件が課せられるものである。
柔軟に対応可能な移行環境の構築が求められる。