私は、2000 年問題の取り組みや恐怖の多くが、当然かどうかにかかわらず、どういうわけか COBOL に集中していたことを知っています。(ちなみに、2000 年 1 月 1 日壊れた Perl スクリプトでマイナーな Y2K バグを見ました)
私が興味を持っているのは、Y2K 問題の影響を受けやすい言語としての COBOL に固有の何かがあったことですか?
つまり、ほとんどのプログラムが古いハードウェアに起因するメモリ/ディスクの使用量を節約する必要があり、これらのプログラムが 30 年間生き残るとは誰も予想していなかったという事実とは対照的ですか?
答えが「年齢以外に COBOL に固有のものは何もない」である場合、私は完全に満足しています。単に興味があり、COBOL について何も知りません。
純粋でシンプルなストレージ容量については 80% でした。
今日のラップトップのハード ドライブの容量が、1980 年には何百万ドルもかかっていたことに人々は気づいていません。2 バイトを節約するのは馬鹿げていると思いますか? 100,000 件の顧客レコードと、20 メガバイトを保持する冷蔵庫サイズのハード ドライブがあり、冷却するための特別な部屋が必要な場合ではありません。
はい、いいえ。COBOL では、数値の桁数を実際に指定する必要があるように変数を宣言する必要がありましYEAR PIC 99たYEAR。そうです、C よりも間違いを犯しやすかったのは、年としてintorshortまたはcharがあり、99 年よりも大きい年を表示する余地がまだ十分にある場合です。出力に問題があるか、年が 99 以下になるという考えに基づいて他の内部計算を行っています。printf19%d
魅力的な質問。本質的に、Y2K問題とは何ですか？それはあなたの宇宙を十分に定義していないという問題です。スペースがより重要だったため、すべての日付をモデル化する真剣な試みはありませんでした（そしてアプリはそれによって置き換えられました）。したがって、すべてのレベルのCOBOLでは、それが重要です。効率的であり、ストアレベルとプログラムレベルの両方で必要なメモリを過剰に宣言しないようにすることです。
効率が重要な場合、Y2Kishエラーをコミットします...タイムゾーンなしでDBに日付を保存するたびにこれを行います。そのため、最新のストレージは間違いなくY2Kishエラーの影響を受けます。これは、使用するスペースを効率化しようとしているためです（ただし、多くの場合、特に企業のやり過ぎレベルでは、過度に最適化されていると思います）。
一方、アプリケーションレベルでのY2Kishエラーは回避します。これは、たとえば、Date（Javaでは、たとえば）を操作するたびに、常に大量の手荷物（タイムゾーンなど）を運ぶためです。なんで？日付（および他の多くの概念）がOSの一部になっているため、OSを作成する賢い人物は、日付の本格的な概念をモデル化しようとします。私たちは彼らの日付の概念に依存しているので、それを台無しにすることはできません...そしてそれはモジュール式で交換可能です！
日付などの多くのデータ型（および機能）が組み込まれている新しい言語と、操作するための巨大なメモリは、Y2Kishの潜在的な問題の多くを回避するのに役立ちます。
それは2つの部分でした。1-Cobolソフトウェアの年齢/寿命、および2-データレコードの80文字の制限。
まず、その時代のほとんどのソフトウェアは、ソフトウェアがそれほど長く続くとは誰も考えていなかったため、年の保管に2桁の数字しか使用していませんでした。COBOLは、コードを決して捨てないことで悪名高い銀行業界に採用されていました。他のほとんどのソフトウェアは捨てられましたが、銀行は捨てられませんでした！
第2に、COBOLはデータのレコードあたり80文字に制限されていたため（パンチカードのサイズが原因で！）、開発者はフィールドのサイズを制限するというさらに大きなプレッシャーにさらされていました。彼らは「私が長く引退するまで2000年はここにいないだろう」と考えたからです。保存されたデータの2文字は巨大でした！
本質的に 2000 年問題の影響を受けやすくする何かが Cobol にあったのでしょうか?
プログラマー1．そして、COBOL プログラムが実行されるシステム2 .
1: 30 年先を見越した設計をしていない。彼らを本当に責めることはできません。日付ごとに 2 バイトを圧縮してから 30 年後に機能させるまでの間にメモリの制約がある場合、おそらく同じ決定を下すでしょう。
2: ハードウェアが年を 2 桁で格納していた場合、システムで同じ問題が発生した可能性があります。
コードがどのくらいの期間使用されるかがわからないという問題の方が多いように思われたため、2 桁の年を使用することにしました。
したがって、COBOL に固有のものではなく、単に COBOL プログラムが重要で古い傾向があるため、影響を受ける可能性が高かったということです。
COBOL 85 (1985 標準) 以前のバージョンでは、現在の世紀を取得する方法がありませんでした**。これは、2 バイトの余分な記憶域がなくなった後でも、4 桁の年の使用を思いとどまらせる COBOL 固有の要因の 1 つでした。問題。
** 特定の実装には、この目的のために非標準の拡張機能が含まれている場合があります。
COBOL状況を悪化させるいくつかのことがありました。
実際のサブルーチンのない巨大な Fortran プログラムを見てきました。本当に、単一の非ライブラリ サブルーチンではなく、1 つの 3,000 行のメイン プログラムでした。これは COBOL の世界で発生した可能性があるため、すべての行を読み取って日付処理を見つける必要があると思います。
これは、0 から 99 までの値 (2 文字、または 2 桁の 10 進数、または 1 バイト) しか保持できないデータ項目に年を格納することにはるかに関連していました。それと、年の値について同様の仮定を行った計算。
それはCobol固有のものではありませんでした。多くのプログラムが影響を受けました。
COBOL には、標準の日付処理ライブラリが付属していません。
そのため、誰もが独自のソリューションをコーディングしました。
いくつかの解決策は、ミレニアムに対して非常に悪いものでした。アプリケーションが 40 年以上生きていなかったため、これらの悪いソリューションのほとんどは問題ではありませんでした。ビジネスの世界でよく知られている 2000 年問題は、それほど少数ではない悪い解決策によって引き起こされます。
(いくつかの解決策の方が優れていました。1950 年代に 2027 年まで有効な日付形式でコーディングされた COBOL システムを知っています。当時は永遠に思われたに違いありません。1970 年代に設計したシステムは 2079 年まで有効です)。
しかし、COBOLに標準の日付型があったとしたら....
03 ORDER-DATE PIC DATE.
....業界全体のソリューションがコンパイラ レベルで利用可能であり、必要な修復の複雑さが軽減されていたはずです。
道徳: 標準ライブラリで言語を使用します。