2019年04月17日

【回想録】2000年問題の思い出

 新元号も「令和」になるとわかり、改元までの残りわずか数週間、キーボードを懸命にたたいて過去のソースを手直ししているプログラマは少なくないのかもしれない。なんとも、お疲れさまでございます m(_ _)m

 うちの会社が使っているアプリケーションは、一部がメーカーの対応待ち中だが、会社の決算月が三月なので、今年の確定申告と税納付(5月末)では大きな間違いはないだろうと思われる。
 弊社で製作する書類で元号変更が必要なのは税務関係の書類だけ。社内文書を作成するプログラムはたいていわたしが書いているが、そのたぐいは創立時から西暦で計算するよう統一してあるので、今回の改元で問題は起こらない、はず、はず、ハズ……。

 と、ちょっと弱気なのは、2000年問題のとき、思いもかけないプログラムで、自分の作ったアプリケーションが誤動作したことがあったからだ。
 今年が2019年だから、あれはもう19年も昔の話になる――というわけで、もう十分「回想録」カテゴリなのだな。

 若い人はご存じないかもしれないが、西暦が1999年から2000年に変わるとき、コンピュータ関係で「2000年問題」というものがあったのだ。
 想像すればすぐおわかりいただけると思うが、当時はまだ、西暦を納める変数に2bytes(0x0000〜0xFFFF)を使わず、1byteでごまかしている(0x00〜0xFF)システムが稼働していたのである。
 こういうプログラムは、表示のところだけ、19≠先にプリントし、残りの二桁だけで年数を表示したり、計算したりしていた。
 2bytesで表現できる数字は、十進数だと0〜65535だが、1byteだと0〜255までとなる。

 そんな設計のシステムが2000年を迎えるとどうなるかと言うと、単純に言えば、見た目、「1900」年に戻ってしまうのである。内部的にはちゃんと計算できていたりするが、表示はあくまで1900年代のままだったり、内部計算もおかしくなったりするシステムがあったりと、それはまちまちであった。

 変数を1byteで取っていたプログラマを責めることはできない。なにしろ、古いシステムではメモリ環境もプアで、1byteも無駄にできないプログラムというのがあったのである。かの祝一平氏も「1バイト入魂」という名言を残している。

 さらには、自分の書いたプログラムが、2000年まで使われているはずがあるまいよ。と思っていたプログラマも珍しくはなかったはず(笑)。
 しかし、そういうプログラムも、誰もメンテをせず、ひっそりと何十年も使われ続けていたりしたのである。

 1999年の時点で、世の中のいろいろなものを動かすシステムの多くはコンピュータに依存するようになっており、実際、2000年になってみないと、そんな過去のプログラムがどう動くかわからないという怖さがあった。これが「2000年問題」なのであった。

 例えば、2000年になったとたん、ガスが止まるかも、電気が止まるかも、と、不安をあおる報道などもあり、1999年年の年末には、ポータブルガスコンロなどが飛ぶように売れたのであった。

 市井のいちプログラマであったわたし自身は、人命に関わるようなコードを書いていたわけでもなく、気楽なものであった。実際、それほど混乱は起こらないだろうな、という楽観的な感触も持っていた。
 配布していたフリーソフトに関しても、振り返ってみて、カレンダーを計算するソフトはなく、少なくとも自分が書いたプログラムは2000年問題とは無縁だと思っていたのである。

 ところが、年が明けて2000年になって、誤動作するフリーソフトがひとつあったのだ。
 それは、ニフティサーブの会議室ログを整合化し、削除発言のダミー挿入や、親発言の根を自動生成して、ログビュアーで見るときに不整合が起きないようにする、という、かなりマニアックなソフト、「ログロジカライザ」であった。
 生ログを整合して、今で言うなら、Androidのchmateのように美しくログを読めるようにするソフトなのである。
 ログのアペンドミスで逆行している発言を自動的になおしたり、ファイルのタイムスタンプも操作し、その会議室の最初の発言のそれにあわせたりもできる。かなり凝ったものであったと自負している。
 Cソースコードのコンパチビリティにも挑戦し、X68kのGCCでも、MicrosoftのQuickCでも同じソースでコンパイルでき、MS-DOS環境下では同じエグゼバイナリで使えた。
 ちゃんとしたログをきちんとライブラリに残したいというsysopさんは重宝したはず。残念ながら、インターネットが一般化しつつある頃に公開したので、あまり人気はなかったが……。

 その「ログロジカライザ」が、ばっちり2000年問題に引っかかっていたのである orz

 もうよく覚えていないのだが、引っかかったのは、先にも書いた、ログの最初の発言日時をファイルのタイムスタンプに反映させる機能だったと思う。
 しかもX68k版は大丈夫で、QuickCでコンパイルしたDOS汎用版の年が異常になってしまったように記憶している。つまり、QuickCの、ファイルのタイムスタンプを変更するライブラリに問題があったのだ。

 つまるところ、純粋にわたしの責任ではないが、少なくとも、わたしが書いたプログラムは2000年問題にばっちり引っかかっていたのである。

 こういうふうに「プログラマ自身は責任がないと思っていても、また、ソースを見ても問題はないのに、他の要因依存で2000年問題に引っかかることがあるのだなぁ」というのは、いい経験になった。

 今現在、税務署のOCR提出書類では、生年月日の年号を数字で書くことが少なくない。明治を1=A大正を2=A昭和を3=A平成を4≠ニ書くわけだ。当然、令和は5≠ノなるだろう。そしてこの欄は1桁しか用意されていない。
 あと元号が5つ変わったら二桁にするのか、それとも、そんな頃は明治大正昭和の人間は生きていないだろうからまた1≠割り振るのか、興味あるところだが、その頃、わたしはこの世にいないだろう。残念である。

 今、そのOCR処理を書いているプログラマも「どうせその頃、俺、生きてないし」と思っているのだろうな(笑)。
posted by 結城恭介 at 08:00| 回想録