6月
30
2006

いまさら2000年問題

コンピューターの世界に2000年問題というのがあった。
6年以上前の問題だから、知らない人もいるかもしれない。
いまになって、その問題の復習をしてみる。

2000年問題というのは、コンピューター特にホスト(大型コンピューター)
でカレンダーの年数を2桁で扱っていたことに発する問題だ。

昔はメモリーやハードディスクなどの記憶装置は高く、また計算を少しでも
早くする必要があった。そのため西暦を4桁の2006年と扱わずに06年と扱っ
ていた。というとややこしいが1998年を98年としていた。

それが2000年になると、99→00となってしまう。
例えば、年齢を計算するときに1970年生まれが1999年では、
99 – 70 = 29 歳と計算すればいいが、
00 – 70 = -30 歳となってしまう。
このようにカレンダーの計算が間違うので、銀行の利息計算や生命保険の計
算など、いろいろな計算が狂ってしまう。

対応策は、以下の3つだと思う
1. カレンダーのデータがあるところを2桁→4桁にする。データベースのデー
タが入っているところを4桁にして頭2桁に’19’を埋める
2. カレンダーの計算しているところを、4桁に直す。
3. すべてうまく修正できたかを、テストする

カレンダーを使っているプログラムの多くは、金融関係の仕事で使っている
プログラム言語のほとんどはCOBOLであった。そのため、そのCOBOLのソース
プログラムをチェックしてカレンダーのデータを扱うところを自動修正した
りするようなプログラムも出てきた。しかし中には20年以上前のプログラム
を今でも使っていて、ソースがなかったりするものもあったし、まったく異
なる言語やアセンブリ言語でかかれたものもあった。そういうプログラムは
新しく作り直されたものもあった。

直すところはわずかなんだけれど、その影響は全てのシステムに及んだ。そ
のため2000年1月1日になって、たくさんのシステムが止まり、銀行から残高
がなくなり、ライフラインも止まってしまうのではないかということが週刊
誌に書かれた。

しかし、実際に2000年1月1日を迎えて、そのようなことはほとんど起きな
かった。3年ぐらい前から多大な費用をかけて、対応してきたからである。

しかし、今も2000年問題に相当するような問題がある。

お客さんに「ちょっとそこを直してよ。たいしたことないでしょ。」といっ
たんプログラムを開発終了してからいわれる。

それはカレンダー2桁から4桁になったようなささいな問題だ。

しかし、プログラムの半分以上に影響が及び、プログラム完成後にテストを
しなければならない。三乗ぐらいの負荷がかかるかな。全体の10%を直すと
いう場合でも、

(1 + 0.1) ^ 3 = 1.331

33% およそ1/3の変更となる。

この計算でいけば、全体の30%を直すとすれば、
(1 + 0.3)^3 = 2.19700
2倍を超える。こうなったら0から作り直したほうが早い。
(三乗というのは大きすぎるので間違っているかもしれない)

プログラマーは経験上、修正が入るのは予期しているのでその対策をもちな
がら作っている。しかし、想定外のことを言われたり、完成寸前で修正や追
加を命令されると、とたんに対策の域を出てしまい最初からやり直しになっ
てしまう。

いまやっている仕事とは関係ないけれど、修正につぐ修正を積もり重ねてい
くと、だんだんとたいへんなことになっていくと思った。すでにプログラム
は複雑になり、人間の頭脳では追いきれなくなってきている。

2000年問題
出典: フリー百科事典『ウィキペディア(Wikipedia)』
http://ja.wikipedia.org/wiki/2000%E5%B9%B4%E5%95%8F%E9%A1%8C

Written by in: 楽天日記 |

コメントはまだありません »


コメント&トラックバック




トラックバック URL

コメントのRSS feed