4

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

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

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

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

4

12 回答 12

11

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

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

于 2009-09-23T02:24:02.527 回答
6

是和否。在 COBOL 中，您必须声明变量，以便您实际上必须说出一个数字中有多少位，即YEAR PIC 99声明变量YEAR，使其只能保存两位十进制数字。所以，是的，犯这个错误比在Cint中更容易犯错您的输出中存在问题，或者基于认为年份小于或等于 99 进行其他内部计算。shortcharprintf19%d

于 2009-09-23T01:18:03.067 回答
1

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

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

于 2009-09-23T00:59:44.783 回答
1

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

程序员1 . 以及运行 COBOL 程序的系统2 .

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

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

于 2009-09-23T01:29:08.967 回答
1

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

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

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

较新的语言具有内置数据类型（和设施），用于日期等许多内容，以及可使用的巨大内存，有助于避免许多潜在的 Y2Kish 问题。

于 2009-09-23T01:42:47.253 回答
1

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

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

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

于 2009-09-23T01:47:57.617 回答
0

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

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

于 2009-09-23T01:01:58.380 回答
0

有一些事情COBOL加剧了这种情况。

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

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

于 2009-09-23T02:13:06.227 回答
0

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

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

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

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

然而，如果 COBOL 有一个标准的日期类型......

03 ORDER-DATE     PIC DATE.

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

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

于 2009-09-24T18:54:40.773 回答
0

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

** 为此目的，特定实现可能具有非标准扩展。

于 2009-09-28T12:57:07.607 回答
0

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

ACCEPT todays-date FROM DATE

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

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

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

ACCEPT todays-date FROM CENTURY-DATE

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

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

于 2018-08-09T03:45:31.763 回答
0

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

当您的 10 万美元计算机有 128K 和 4 个磁盘，总计约 6 兆字节时，您可以要求您的管理人员再购买一个 256K 的机器以获取 12 兆磁盘存储空间，或者在空间方面非常有效。

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

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

于 2018-08-14T18:25:19.870 回答