Cobol有什么东西可以让它容易受到Y2K问题的影响吗？

Question

我知道很多Y2K的努力/恐慌都以某种方式集中在COBOL，当之无愧。 （哎呀，我在2000年1月1日的Perl脚本中看到了轻微的Y2K错误）

我感兴趣的是，COBOL是否有某种特定的语言使其容易受到Y2K问题的影响？

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

如果答案是“除了年龄之外没有COBOL特有的东西”，我感到非常高兴 - 只是好奇，对COBOL一无所知。

Answer 1

存储容量的80％，纯粹而简单。

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

Answer 2

是和否。在COBOL中，您必须声明变量，以便您实际上必须说出一个数字中有多少位数，即YEAR PIC 99声明变量YEAR以便它只能保留两位小数。所以，是的，犯下这个错误比在C中更容易，如果你有int或short或char作为年份，并且仍然有足够的空间可以存在超过99年的年份。当然，这不能保护您免于printf {C} 19%d并且仍然在您的输出中出现问题，或者基于对年份的思考进行其他内部计算将小于或等于99. < / p>

Answer 3

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

所以，没有什么特别的COBOL，只是COBOL程序往往是关键和旧的，所以他们更有可能受到影响。

Answer 4

  

Cobol有什么东西可以让它容易受到Y2K问题的影响吗？

编程 ¹ 。 COBOL程序运行的系统 ² 。

---

<子> 1：他们没有设计前瞻性的30年。我不能真的责备他们。如果我有内存限制，在每个日期压缩2个字节并使其在30年后工作之间，我很可能做出同样的决定。

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

Answer 5

引人入胜的问题。什么是Y2K问题，实质上是什么？这是没有充分定义你的宇宙的问题。没有认真尝试对所有日期进行建模，因为空间更重要（并且应用程序将被当时替换）。因此，在各个级别的Cobol中，重要的是：在商店和程序级别提高效率，而不是过度使用所需的内存。

在效率很重要的情况下，我们会提交Y2Kish错误...我们每次在没有时区的情况下在DB中存储日期时都这样做。因此，现代存储肯定会受到Y2Kish错误的影响，因为我们试图在使用空间时保持高效（尽管我敢打赌它在许多情况下过度优化，特别是在企业过度使用的所有级别）。

另一方面，我们避免在应用程序级别上出现Y2Kish错误，因为每次使用日期时（比如Java），它总是带有大量的行李（如时区）。为什么？因为Date（和许多其他概念）现在是操作系统的一部分，所以制作操作系统的智能家伙试图模拟一个完整的日期概念。由于我们依赖于他们的约会概念，我们无法搞砸......而且它是模块化和可更换的！

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

Answer 6

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

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

其次，COBOL被限制为每个数据记录80个字符（由于打卡的大小！），开发人员在限制字段大小的压力更大。因为他们认为“2000年不会在这里，直到我长久退休！”保存数据的2个字符很大！

Answer 7

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

这不是特定于Cobol的事情。许多计划受到影响。

Answer 8

COBOL有些事情使情况恶化。

• 它很旧，所以少用图书馆代码，更多本土的一切
• 它已经老了，所以互联网之前，社交前网络，更多NIH，更少的框架，更多的自定义内容
• 它已经陈旧，因此，不那么抽象，更有可能拥有开放式编码解决方案
• 它已经过时了，所以，回到足够远的地方，保存2个字节可能有点重要
• 它已经老了，所以它早于SQL。传统的操作软件甚至已经将面向记录的磁盘文件编入索引，使每个程序中的滚动数据库变得更容易一些。
• “printf”格式字符串和数据类型声明是一回事，一切都有 n 数字

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

Answer 9

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

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

有些解决方案相对于千禧年而言非常糟糕。大多数这些糟糕的解决方案并不重要，因为应用程序没有超过40年。不那么极少数的不良解决方案会导致商业界众所周知的Y2K问题。

（有些解决方案更好。我知道20世纪50年代编码的COBOL系统的日期格式在2027年之前是好的 - 当时似乎永远都是如此;而且我在20世纪70年代设计的系统在2079年之前一直很好。）< / p>

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

03 ORDER-DATE     PIC DATE.

....行业广泛的解决方案可以在编译器级别上获得，从而降低了所需补救的复杂性。

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

Answer 10

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

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

Answer 11

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

ACCEPT todays-date FROM DATE

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

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

该标准后来进行了扩展（我认为是COBOL-85），因此您可以要求使用其他格式的日期，例如：

ACCEPT todays-date FROM CENTURY-DATE

哪个给了您一个8位数字，日期为CCYYMMDD。

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

Answer 12

问题确实出在70年代末80年代初。

当一百万美元的四分之一计算机中有128K和4个磁盘，总计约6兆字节时，您可以向管理层要求另一四分之一的工厂来购买256K的计算机，该计算机具有12兆的磁盘存储空间，或者空间效率非常高。 >

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

其他技巧还包括一些价格昂贵的Hooky Hooky类型编码-代码12-> $ 19.99。