答案 0 :(得分：6)
答案 1 :(得分：2)
我永远不会在Gartner捍卫那些小丑，但仍然：
您对IBM / 370s的看法是错误的。 370是一种架构，而不是一台特定的机器 - 它适用于从水冷怪物到小型，小型计算机大小的机器（与VAX大小相同）的所有设备。因此，售出的数量可能远远超过您怀疑的数量级。
此外，COBOL在DEC的VAX阵容中大量使用，之前在DEC-10和DEC-20线上使用。在英国，它被用于所有ICL大型机。许多其他平台也支持它。
答案 2 :(得分：2)
[通常免责声明 - 我为COBOL供应商工作]
这是一个有趣的问题，并且总是很难获得可证明的数字。关于COBOL程序员估计的数量 - 这300万个数字可能不是错误的数量级。我认为过去估计有一两百万。其中每一个都可以在20年的职业生涯中产生大量代码。在印度，每年都有成千上万的新COBOL程序员加入游泳池（也许每个月！）。
我认为自动生成的代码可能比想象的要大。例如，PACBASE是银行业中非常受欢迎的应用程序。我所知道的一个非常大的全球银行广泛使用它，它们将所有代码生成到COBOL中，并估计这个生成的代码是其总代码库的95％，其他5％是手工编码/维护。我不认为这种情况并不常见。这些系统的维护和开发通常在模型级别完成，而不是如您所说的生成代码。
原始问题中缺少一组应用程序 - COBOL不仅是大型机语言。 Micro Focus的早期几乎完全花费在OEM市场上 - 我们曾经拥有200个不同的OEM（很多像DEC，Stratus，Bull等......）。每个OEM都必须在C和Assembler旁边的盒子上安装COBOL编译器。当时构建了许多大型应用程序并且仍然很强大 - 考虑最大的HR ERP系统，最大的移动电话计费系统等。我的观点是，IBM大型机上从未有过大量的COBOL代码。并经常被忽视。
最后，COBOL商店中代码库的大小可能比“平均”大。这不仅仅是因为COBOL是冗长的（或者是 - 很长一段时间都不是这样）但系统只是更大 - 它们在大型组织中，执行大量不同的任务。站点拥有数百万的LoC是非常常见的。
答案 3 :(得分：2)
我没有数据，但我的第一份“真正的”工作是在IBM 370s上。
第一：销售数量。 1974年，一条大型铁路运行了三个370。然而，这些都是370，但你可以得到一个小的，少了很多。 （对于透视，当时是否获得另一兆字节是VP级别的决定。）
第二：COBOL代码就是你所谓的“蓬松”，因为一个典型的句子（COBOLese for line）可能是“添加1到客户的主要帐户”。每行的机器指令相对较少。 （在IBM 360及更高版本中尤其如此，它具有围绕执行COBOL设计的机器指令。）顺便说一下，地址是16位，四个用于指定寄存器（使用底部24位作为基址），12作为偏移。这意味着可以一次寻址64K以下的东西，因为由于各种原因，并非所有16个寄存器都可以用作基址寄存器。不要低估人们将程序安装到小内存中的能力。
另外，不要低估程序的数量。程序库将位于磁盘和磁带上，并且基本上仅受成本和容量的限制。 （早些时候，他们会使用打卡，因为数据和程序存储存在严重问题。）
第三：是的，当时大多数软件都是为业务编写的。那时的机器要便宜得多，人们便宜一些。编写程序是为了使现有业务流程自动化，并且您可以获得外部软件并改变业务实践的想法几乎是异端邪说。当然，这随着时间的推移而改变。
第四：程序员可以比现在更快，每人每年的代码行数，因为这些都是针对大笨问题的大笨计。根据我的经验，DATA DIVISION是每个COBOL程序的很大一部分，并且经常会对文件布局进行大量描述，并在系列的每个程序中重复它们。
我对程序生成器的经验有限，但当时使用它来生成应用程序然后修改输出是很常见的。这部分只是不好的做法，部分原因是程序生成器无法完成所需的一切。
第五：尽管IBM付出了努力，PL / I并没有被大量使用。虽然据我所知，唯一真正无法解决的主要问题是找出精密系统。国防部使用Ada和COBOL完全不同的东西。您将汇编语言省略为竞争对手，许多小商店使用BAL（也称为ASM）而不是COBOL。毕竟，程序员很便宜，编译器价格昂贵，而且COBOL无法做很多事情。它实际上是一种非常好的汇编语言，我非常喜欢它。
答案 4 :(得分：1)
嗯，你在这里问错了地方。这个论坛由.net程序员主导，具有重要的java少数群体和如此年龄的积累，只有极少数人拥有任何cobol经验。
CASE工具市场包含很多cobol代码生成器。大多数工具都是只写的，而不是双向的。这确保了很多代码行。这个市场比70年代更新，因此cobol代码的数量在80年代和90年代迅速增长。
很多cobol开发都是由没有重要互联网访问权限且因此可见性的人完成的。没有必要。 Cobol prorammers习惯于拥有内部编程课程和纸质文档（很多）。
[编辑]生成cobol源很有意义。 Cobol非常冗长且水平低。各种cobol实现都略有不同，因此配置代码生成器可以消除许多潜在的错误。
答案 5 :(得分：0)
关于＃4：有多少可能是机器生成的代码？我不知道基于模板的代码是否与Cobol一起使用了很多，但我现在看到很多东西用于各种各样的事情。如果我的应用程序有数千台由机器生成的LOC，那并不意味着什么。我写的最后一个代码生成脚本需要20分钟写入，10分钟格式化输入，2分钟运行，然后一小时执行一套自动测试以验证它实际工作，但它生成的代码将采取用手做几天（或早上会和午餐之间的时间，按照我的方式做;））。好的我承认它并不总是那么容易，并且经常涉及手动调整，但是如果代码生成器被大量使用，我仍然认为LOC度量没有多大意义。
也许这就是他们在如此短的时间内生成如此多代码的方式。