 本番環境に載せるとき
まず、最終的に、本番環境に載せるとき、どんなことをするかイメージしましょう。
- ファイルのレイアウトは、すべて2000年対応していること。
- そのファイルに関連する全てのプログラムは、年４桁対応していること。
- ファイルのレイアウトが変わったのだから、当然そのデータの変換（年2桁から4桁）しなくてはならない。
- 移行の後、ゆとりをもって、テストしたい。できれば、1999年12月31日と仮定して、それから、2000年に入って１ヶ月くらいを、仮想テストしたい。
プログラム修正最中
さて、では溯って、プログラムの修正をしているときはどうなるかイメージしましょう。
- 現行のプログラムと修正プログラムはソースを分けるでしょう。
- すると、現行バージョンと修正中バージョンが出来ることになります。
別にバグ修正ではないので、この２つのソースは、時を隔てたシステムに対応する正しいソースです。ここで、現行の修正依頼がきたら、現行はもちろん、2000年版の方も修正する必要が出てきます。この現行ソースが数十本なら楽でしょうが、数百本ならどうしましょう。バージョン管理をしなくてはなりません。多分、データを２つに分けた日（出来れば休日）を、ファイル登録して、元データの最新修正日付と比較するのが楽かも。コメント増やしただけでも、最新の修正日付になるので要注意ですね。
優先順位
それから、修正の優先順位はどのようにするのでしょう。プログラムがたった一つのファイルを参照してるなんて、希ですよね。つまり、４つのファイルを参照するプログラムを修正するときは、それら全てのファイルを作成しているプログラムの修正や、ほかに参照しているプログラムの修正もしなくてはなりません。この無限の連鎖反応をどこで止めるのでしょうか。
優先順位をプログラムでなくファイルにしたとしても、２つのファイルの各々持つ日付同士を比較するのを修正するには、同時に２つのファイルを変更しなくては修正してもテストできません。すると片方のみ優先順位１番にしても、無意味ですよね。
もう一台のAS/400
これらは、すべて、同じコンピュータの上ですることを想定しましたが、これが、別個のコンピュータ（もう一台AS/400）があったらどうでしょう。（今の環境をそっくりもう一台のAS/400にうつすということ）。
- 少なくとも、修正中に間違えて、本番を書き換え、大騒ぎにならない。（夜安らかに眠れる。）
- ライブラリー名も本番と同じにしてもいい。
- ファイルも作り放題。
- システム日付を好きに変えてもいい。（もちろん他のプログラマーに伝えるけど、本番は関係ない）。
- 統合テストを、一日に数日分やってもいい。
- バックアップやレストアを好きに出来る。迷惑するのはプログラマーだけ。「ごめん」ですむ。
- データはそっくりすべては要らないので、ディスクは小さくてもいい（この辺は予算との関係だね）だろう。
これだ！これで予算をもらおう！
続く... | 
