最初のページに戻ります。

総合の目次があるページに戻ります。

よく使うマニュアルです

Wiki

updated on 2004.06.23

a.2. 2000年問題 其の弐

[ Previous ] [ HOME ] [ Upper ] [ Next ]


本番環境に載せるとき

まず、最終的に、本番環境に載せるとき、どんなことをするかイメージしましょう。

  1. ファイルのレイアウトは、すべて2000年対応していること。
  2. そのファイルに関連する全てのプログラムは、年4桁対応していること。
  3. ファイルのレイアウトが変わったのだから、当然そのデータの変換(年2桁から4桁)しなくてはならない。
  4. 移行の後、ゆとりをもって、テストしたい。できれば、1999年12月31日と仮定して、それから、2000年に入って1ヶ月くらいを、仮想テストしたい。

プログラム修正最中

さて、では溯って、プログラムの修正をしているときはどうなるかイメージしましょう。

  1. 現行のプログラムと修正プログラムはソースを分けるでしょう。
  2. すると、現行バージョンと修正中バージョンが出来ることになります。

別にバグ修正ではないので、この2つのソースは、時を隔てたシステムに対応する正しいソースです。ここで、現行の修正依頼がきたら、現行はもちろん、2000年版の方も修正する必要が出てきます。この現行ソースが数十本なら楽でしょうが、数百本ならどうしましょう。バージョン管理をしなくてはなりません。多分、データを2つに分けた日(出来れば休日)を、ファイル登録して、元データの最新修正日付と比較するのが楽かも。コメント増やしただけでも、最新の修正日付になるので要注意ですね。

優先順位

それから、修正の優先順位はどのようにするのでしょう。プログラムがたった一つのファイルを参照してるなんて、希ですよね。つまり、4つのファイルを参照するプログラムを修正するときは、それら全てのファイルを作成しているプログラムの修正や、ほかに参照しているプログラムの修正もしなくてはなりません。この無限の連鎖反応をどこで止めるのでしょうか。
優先順位をプログラムでなくファイルにしたとしても、2つのファイルの各々持つ日付同士を比較するのを修正するには、同時に2つのファイルを変更しなくては修正してもテストできません。すると片方のみ優先順位1番にしても、無意味ですよね。

もう一台のAS/400

これらは、すべて、同じコンピュータの上ですることを想定しましたが、これが、別個のコンピュータ(もう一台AS/400)があったらどうでしょう。(今の環境をそっくりもう一台のAS/400にうつすということ)。

  1. 少なくとも、修正中に間違えて、本番を書き換え、大騒ぎにならない。(夜安らかに眠れる。)
  2. ライブラリー名も本番と同じにしてもいい。
  3. ファイルも作り放題。
  4. システム日付を好きに変えてもいい。(もちろん他のプログラマーに伝えるけど、本番は関係ない)。
  5. 統合テストを、一日に数日分やってもいい。
  6. バックアップやレストアを好きに出来る。迷惑するのはプログラマーだけ。「ごめん」ですむ。
  7. データはそっくりすべては要らないので、ディスクは小さくてもいい(この辺は予算との関係だね)だろう。

これだ!これで予算をもらおう!

続く...


[ Previous ] [ HOME ] [ Upper ] [ Next ]

You are at K's tips-n-kicks of AS/400

 

Ads by TOK2