.net - .NET 中真的有 COBOL 吗？

Question

刚才在查看微软的 Visual Studio 页面，突然在广告侧边栏看到了一个不可思议的广告:

"Net Express is a COBOL development environment for extending core business processes to the .NET Framework and other distributed platforms."

当然我关注了 link并找到了一家这样做的公司，但是还有地方仍在使用COBOL吗？有人真的在 .NET 框架中使用 COBOL 吗？

Answer 1

Micro Focus制作一个主要用于维护遗留大型机应用程序的 COBOL 开发套件。它会说来自各种平台的 20 种 COBOL 方言，并具有 CICS仿真设施。自 2004 年起，他们推荐使用它来替换高达 400 MIPS 的大型机工作负载。或者。请记住，您仍然可以在 1990 年代初期从 Amdahl 购买额定为 22 MIPS 的大型机系统，在大型机上 400 MIPS 是相当大的工作量。

将传统的 COBOL 后端集成到现代前端是一项大生意。 terminal 的生态系统相当丰富emulation software , screen scrapers , interfacing libraries和 RPC wrappers用于各种协议(protocol)，例如 CORBA 和 SOAP。

几年前，Micro Focus 推出了 COBOL .NET compiler它允许您在 CLR 后端运行 COBOL 应用程序。您可以编译任何受支持的方言，它将运行所有旧版仿真功能。这允许您将 GUI 或 Web 前端(或 Web 服务层)放在现有的 COBOL 应用程序上，从而保留对现有代码库的投资。几乎可以使用任何支持 CLR 的开发工具来编写前端。您想使用 C#/Windows Forms、MS Workflow Foundation、SSIS、IronPython、ASP.NET 或 SQL Server CLR 与您的 COBOL 后端集成 - 让自己失望。

因此，对于遗留应用程序的完全重写和迁移，它通常是一个非常有吸引力的替代方案。

这种类型的工作占了他们业务的很大一部分，但仍然有一些利基市场，COBOL 实际上本身就做得很好。对于许多大批量作业，打开面向记录的文件并按程序处理它是获得简单、可理解和快速的应用程序的良好范例。我曾经读过一篇帖子(在 Slashdot IIRC 上)，有人在谈论一个 COBOL 应用程序，该应用程序读取 35GB 的信用卡退款文件并每小时处理一次。这是很久以前发布的，在 1990 年代的某个时候——当时 35GB 比大多数 PC 的磁盘容量大得多。

让 RDMBS 在一个小时内批量加载和处理 35GB 的数据(估计 100-2 亿条记录)不一定是一件微不足道的工作，即使在现代硬件上也是如此。通常，从 SQL 中获得性能需要您对处理采取一种有些不恰当的方法，这可能会混淆代码的含义；高度调整的 SQL 可以是相当“只写”的。

COBOL 已在此类应用程序中使用了大约 50 年，是一种成熟、易于理解且可靠的技术，实际上做得很好。