Cobol 中是不是存在本质上使其易受千年虫问题影响的东西？

Posted 2023-03-31

【中文标题】Cobol 中是不是存在本质上使其易受千年虫问题影响的东西？

【英文标题】：Was there something in Cobol intrinsically making it susceptible to Y2K issues?Cobol 中是否存在本质上使其易受千年虫问题影响的东西？

【发布时间】：2009-09-23 00:57:35

【问题描述】：

我知道很多 Y2K 的努力/恐慌都以某种方式集中在 COBOL 上，无论是否应得。 （见鬼，我在 Perl 脚本中看到了一个小的 Y2K 错误，该错误在 2000 年 1 月 1 日被破坏）

我感兴趣的是，作为一种语言，COBOL 是否有一些特定的东西使它容易受到 Y2K 问题的影响？

也就是说，与大多数程序在其中编写的时代以及随后需要节省由旧硬件驱动的内存/磁盘使用以及没有人预计这些程序能够存活 30 年这一事实相反？

如果答案是“除了年龄之外没有任何特定于 COBOL 的内容”，我非常高兴 - 只是好奇，对 COBOL 一无所知。

【问题讨论】：

如果我们从 Y2K 漏洞中学到了什么，那就是我们需要向前看并牢记 2038 年的漏洞 :) en.wikipedia.org/wiki/Year_2038_problem

或者 Y1C 问题 (en.wikipedia.org/wiki/Y1C_Problem) :D

【参考方案1】：

80% 是关于存储容量，纯粹而简单。

人们没有意识到他们今天的笔记本电脑硬盘容量在 1980 年会花费 数百万。你认为节省两个字节是愚蠢的吗？当您拥有 100,000 条客户记录和一个冰箱大小的 20 兆字节硬盘并且需要一个特殊的房间来保持凉爽时，情况就不是这样了。

【讨论】：

已在 (1) Sinclair Z80 上编程，使用盒式磁带作为唯一的存储设备； (2) 8088 Zenith 笔记本电脑，带有 2 个 750K 软盘作为唯一存储设备； (3) 早期的 IBM 大型机仿冒品，带有 4K 内存芯片和用于存储的穿孔卡/磁带 - 完成所有这些之后，老实说，我完全理解每年存储 2 位数字的心情:)

100% 正确。此外，当决定使用 2 位数年份时，他们知道 2000 年会出现问题，但是当其中大部分被编码时，1980 年代、70 年代甚至 60 年代，他们的想法是正在编写的应用程序会20、30 或 40 年不得使用。

【参考方案2】：

是和否。在 COBOL 中，您必须声明变量，以便您实际上必须说出一个数字中有多少位，即 YEAR PIC 99 声明了变量 YEAR，以便它只能保存两位小数。所以是的，如果你将int 或short 或char 作为年份并且仍然有足够的空间来存储大于99 的年份，那么犯这个错误比在C 中更容易。当然，这并不能保护您来自 printfing 19%d 在 C 中仍然存在输出问题，或者基于认为年份小于或等于 99 进行其他内部计算。

【参考方案3】：

这似乎更像是人们不知道他们的代码会使用多长时间的问题，所以他们选择使用 2 位数的年份。

因此，COBOL 并没有什么特别的，只是 COBOL 程序往往是关键且陈旧的，因此它们更有可能受到影响。

【参考方案4】：

Cobol 中是否存在本质上使其容易受到 Y2K 问题影响的东西？

程序员¹。以及运行 COBOL 程序的系统².

---

1：他们没有设计前瞻性的 30 年。我真的不能怪他们。如果我有内存限制，在每个日期压缩 2 个字节和让它在 30 年后工作之间，我很可能会做出同样的决定。

2：如果硬件以两位数存储年份，系统可能会遇到同样的问题。

【讨论】：

您是在暗示非 cobol 程序员本质上具有更长的世界观吗？ :)

没有。我的意思是程序员本质上是狭隘的世界观。 你会预言 COBOL 的生存能力吗？

【参考方案5】：

有趣的问题。 Y2K 问题本质上是什么？这是没有充分定义您的宇宙的问题。没有认真尝试对所有日期进行建模，因为空间更重要（届时应用程序将被替换）。因此，在 Cobol 的各个级别中，这很重要：在存储级别和程序级别都高效且不会过度声明所需的内存。

在效率很重要的情况下，我们会犯 Y2Kish 错误......每次我们在没有时区的数据库中存储日期时都会这样做。因此，现代存储肯定会出现 Y2Kish 错误，因为我们试图提高使用空间的效率（尽管我敢打赌，它在许多情况下都过度优化了，尤其是在企业过度优化的层面上）。

另一方面，我们避免了应用程序级别的 Y2Kish 错误，因为每次使用 Date（比如说 Java 中的）时，它总是会带来大量的包袱（比如时区）。为什么？因为日期（和许多其他概念）现在是操作系统的一部分，所以制作操作系统的聪明人试图模拟一个成熟的日期概念。由于我们依赖于他们的日期概念，我们不能搞砸它......而且它是模块化和可替换的！

较新的语言具有内置数据类型（和工具），用于许多事情，例如日期，以及可供使用的大量内存，有助于避免许多潜在的 Y2Kish 问题。

【讨论】：

我喜欢你的回答，虽然我不确定“缺乏复杂的数据类型/库”是否可以算作 COBOL 的特定功能。

DVK，绝对不是。我不认为同一时期的汇编程序比当时的 Cobol 程序更能避免 Y2K 错误。

【参考方案6】：

这是两部分。 1- Cobol 软件的年龄/寿命，以及 2- 数据记录的 80 个字符限制。

首先 - 那个时代的大多数软件只使用 2 位数字来存储年份，因为没有人认为他们的软件会持续这么长时间！ COBOL 已被银行业采用，银行业因从不丢弃代码而臭名昭著。大多数其他软件都被扔掉了，而银行却没有！

其次，COBOL 被限制为每条数据记录 80 个字符（由于穿孔卡片的大小！），开发人员在限制字段大小方面面临更大的压力。因为他们认为“直到我退休后，2000 年才会到来！”保存数据的2个字符很大！

【讨论】：

问题是，是否有任何特定于 COBOL 的推理？例如。一旦停止使用打孔卡，COBOL 是否仍受数据记录限制 80 个字符？

为了向后兼容，80 个字符的 COBOL 限制在穿孔卡片之后一直存在很长时间，而且屏幕也被制成 80 个字符宽！出于某种原因，COBOL 刚刚被银行采用，主要是由于其当时易于使用的语法和强大的功能。当时的替代品不是很丰富（FORTRAN、C 等），非常令人困惑，并且不适合所需的交易类型。 80 个字符的限制是在有意义的时候做出的设计决定，并且坚持了足够长的时间导致了这个问题。

它是否以某种方式在语言中进行了硬编码？或者仅仅是每个人都使用的非强制标准？我假设是前者。

80 列与它无关。那只是编码格式，代码可以在下一行继续。数据记录的大小可能会更大。

【参考方案7】：

这与将年份存储在只能保存 0 到 99 之间的值（两个字符，或两个十进制数字，或一个字节）的数据项中更相关。这和对年份值做出类似假设的计算。

这几乎不是 Cobol 特有的东西。许多项目受到影响。

【参考方案8】：

COBOL 的某些事情使情况更加恶化。

它很老了，所以更少使用库代码，更多的是本土化的东西 它已经过时了，所以前互联网、前社交网络、更多 NIH、更少框架、更多自定义内容 它很旧，所以不太抽象，更有可能有开放编码的解决方案 它已经过时了，所以，回到足够远的地方，节省 2 个字节可能有点重要 它很旧，所以它早于 SQL。旧版操作软件甚至对面向记录的磁盘文件进行了索引，从而使在每个程序中滚动您自己的数据库变得更加容易。 “printf”格式字符串和数据类型声明是一回事，都是n个数字

我见过没有实际子例程的巨型 Fortran 程序。真的，一个 3,000 行的主程序，而不是一个非库子程序，就是这样。我想这可能发生在 COBOL 世界中，所以现在您必须阅读每一行才能找到日期处理。

【参考方案9】：

COBOL 从未附带任何标准日期处理库。

所以每个人都编写了自己的解决方案。

与千年相比，有些解决方案非常糟糕。这些糟糕的解决方案中的大多数都无关紧要，因为这些应用程序没有存活 40 多年。少数糟糕的解决方案会导致商业世界中众所周知的千年虫问题。

（一些解决方案更好。我知道在 1950 年代编码的 COBOL 系统，其日期格式在 2027 年之前都可以使用——当时一定是永远存在的；我在 1970 年代设计的系统可以在 2079 年之前使用）。

但是，如果 COBOL 有一个标准的日期类型......

03 ORDER-DATE     PIC DATE.

....整个行业的解决方案都可以在编译器级别使用，从而降低所需修复的复杂性。

道德：使用标准库的语言。

【参考方案10】：

COBOL 85（1985 年标准）和更早的版本没有任何方法获得当前世纪**，这是 COBOL 固有的一个因素，即使在 2 个字节的额外存储空间之后也不鼓励使用 4 位数年份不再是问题。

** 特定的实现可能为此目的进行了非标准扩展。

【参考方案11】：

Cobol 的唯一内在问题是它用于检索当前系统日期的原始（1960 年代后期）标准语句，即：

ACCEPT todays-date FROM DATE

这会返回一个 6 位数字，日期为 YYMMDD 格式。

但是，即使这也不一定是问题，因为我们在 90 年代使用此语句编写代码，该语句仅检查年份部分是否小于 70 并假设日期为 20YY，这将使其成为 Y2K070 问题。 :-)

该标准后来被扩展（我认为是 COBOL-85），因此您可以要求不同格式的日期，例如：

ACCEPT todays-date FROM CENTURY-DATE

这给了你一个 8 位数字，日期为 CCYYMMDD。

正如您和其他人所指出的，许多其他计算机编程语言允许“有损”日期/年份的表示。

【参考方案12】：

问题实际上与 70 年代末 80 年代初的内存和存储限制有关。

当您价值 25 万美元的计算机有 128K 和 4 个磁盘，总计约 6 MB 时，您可以要求您的管理人员再购买一个 256K 的机器以获取 12 兆磁盘存储空间，或者非常非常有效地使用空间。

因此使用了各种节省空间的技巧。我最喜欢的是将 YYMMDD 日期作为 991231 存储在压缩十进制字段 x'9912310C' 中，然后敲掉最后一个字节并将其存储为 '991231'。所以你只占用了 3 个字节，而不是 6 个字节。

其他技巧包括一些用于价格的 hokey Hooky 类型编码 - 代码 12 -> 19.99 美元。