我刚才正在查看Microsoft的Visual Studio页面，在广告侧栏中，我突然看到了一个不可思议的广告:
当然，我遵循link并找到了一家做到这一点的公司，但是还有地方仍在使用COBOL吗？有人在.NET框架中实际使用COBOL吗？
最佳答案
Micro Focus创建了一个COBOL开发套件，该套件实质上旨在维护旧的大型机应用程序。它可以说来自各种平台的20种COBOL方言，并具有CICS仿真功能。从2004年开始，他们推荐它替代400 MIPS左右的大型机工作负载。请记住，您仍然可以在1990年代初从Amdahl购买额定值为22 MIPS的主机系统，在主机上使用400 MIPS的工作量是相当大的。
将传统的COBOL后端集成到现代前端是一项艰巨的任务。对于各种协议(protocol)(例如CORBA和SOAP)，存在一个相当大的terminal emulation software，screen scrapers，interfacing libraries和RPC wrappers生态系统。
几年前，Micro Focus推出了COBOL .NET compiler，它允许您在CLR后端上运行COBOL应用程序。您可以编译任何受支持的方言，它将运行所有旧版仿真功能。这使您可以在现有的COBOL应用程序上放置GUI或Web前端(或Web服务层)，从而保留对现有代码库的投资。几乎可以使用支持CLR的任何开发工具来编写前端。您想将C#/ Windows窗体，MS Workflow Foundation，SSIS，IronPython，ASP.NET或SQL Server CLR与COBOL后端一起使用-淘汰自己。
这样，它通常是对旧版应用程序进行完全重写和迁移的一种非常有吸引力的选择。
这种类型的工作占了他们很大一部分业务，但在某些细分市场中，COBOL实际上本身就做得很好。对于许多大型批处理作业而言，打开面向记录的文件并按程序进行处理是获得简单，可理解且快速的应用程序的良好范例。我曾经读过一个帖子(在Slashdot IIRC上)，有人在谈论一个COBOL应用程序，该应用程序读取35GB的信用卡退款文件，并每小时进行处理。该信息发布于很久以前，即1990年代，当时35GB的容量比大多数PC的磁盘容量大得多。
即使在现代硬件上，在一小时内让RDMBS批量加载和处理35GB数据(猜测为100-200亿条记录)也不一定是一件容易的事。通常，要想从SQL中获得性能，就需要对处理采取某种倾斜的方法，这会使代码的含义难以理解。高度优化的SQL可能完全是“只写”的。
COBOL已在此类应用程序中使用了50多年，它是一种成熟，易于理解且可靠的技术，实际上效果很好。
关于.net - .NET中实际上有COBOL吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/325177/