.NET 中真的有 COBOL 吗？
刚才我正在查看微软的Visual Studio页面，在广告侧边栏中我突然看到了一个令人难以置信的广告：
“Net Express 是一个 COBOL 开发环境，用于将核心业务流程扩展到 .NET Framework和其他分布式平台。”
当然，我按照链接找到了一家这样做的公司，但是还有地方仍在使用COBOL吗？ 有人真正在 .NET 框架中使用 COBOL 吗？
I was checking Microsoft's Visual Studio page just now and in the advertisements sidebar I suddenly saw an incredible advertisement:
"Net Express is a COBOL development environment for extending core business processes to the .NET Framework and other distributed platforms."
Of course I followed the link and found a company that does this, but are there places still using COBOL? Does anyone actually use COBOL in .NET frameworks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Micro Focus 开发了一个 COBOL 开发套件，其主要目的是维护遗留大型机应用程序。 它可以使用来自不同平台的 20 种 COBOL 方言，并具有 CICS 仿真工具。 截至 2004 年，他们建议用它来取代高达 400 MIPS 左右的大型机工作负载。 请记住，在 20 世纪 90 年代初期，您仍然可以从 Amdahl 购买额定为 22 MIPS 的大型机系统，大型机上的 400 MIPS 是相当大的工作量。
将传统 COBOL 后端集成到现代前端是一项大生意。 终端 仿真 软件, < a href="http://en.wikipedia.org/wiki/Screen_scraping" rel="noreferrer">屏幕抓取工具、接口库和RPC 包装器 适用于各种协议，例如 CORBA 和 SOAP。
几年前，Micro Focus 推出了 COBOL .NET 编译器，它允许您可以在 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 的信用卡退款文件并每小时处理它。 这是很久以前发布的，大约在 20 世纪 90 年代，当时 35GB 比大多数 PC 的磁盘容量大得多。
让 RDMBS 在一个小时内批量加载并处理 35GB 数据（估计有 100-2 亿条记录）也不一定是一项简单的工作，即使在现代硬件上也是如此。 通常，从 SQL 中获得性能需要您采取某种间接的处理方法，这可能会模糊代码的含义； 高度调优的 SQL 可以是“只写”的。
COBOL 在此类应用程序中的使用已有大约 50 年的历史，是一项成熟、易于理解且可靠的技术，实际上做得非常好。
Micro Focus make a COBOL development suite that is substantially aimed at maintaining legacy mainframe applications. It speaks something like 20 dialects of COBOL from various platforms and has a CICS emulation facility. As of 2004 they recommend it for replacing mainframe workloads up to 400 MIPS or so. Bearing in mind that you could still buy mainframe systems rated at 22 MIPS from Amdahl in the early 1990s 400 MIPS on a mainframe is quite a substantial workload.
Integrating legacy COBOL back-ends to modern front-ends is big business. There is quite a substantial ecosystem of terminal emulation software, screen scrapers, interfacing libraries and RPC wrappers for various protocols such as CORBA and SOAP.
A few years ago Micro Focus brought out a COBOL .NET compiler that allows you to run COBOL applications on a CLR back-end. You can compile any of the supported dialects and it will run all of the legacy emulation functions. This allows you to put a GUI or web front-end (or a web services layer) on an existing COBOL application, preserving your investment in the existing code base. The front-end can be written with pretty much any development tool that supports the CLR. You want to use C#/Windows Forms, MS Workflow Foundation, SSIS, IronPython, ASP.NET or SQL Server CLR integration with your COBOL back end - knock yourself out.
As such, it's often a very attractive alternative to a complete re-write and migration of a legacy application.
This type of work accounts for quite a bit of their business, but there are still niches where COBOL actually does quite a good job in its own right. For many large batch jobs opening a record-oriented file and processing it procedurally is a good paradigm to get an application that is simple, understandable and fast. I once read a posting (on Slashdot IIRC) where someone was talking about a COBOL application that read in a 35GB file of credit card refunds and processed it every hour. That was posted quite a long time ago, sometime in the 1990s - at a time when 35GB was considerably larger than the disk capacity of most PCs.
Getting an RDMBS to bulk load and process 35GB of data (100-200 million records at a guess) in an hour is not necessarily a trivial job, even on modern hardware. Often, getting performance from SQL requires you to take a somewhat oblique approach to the processing, which can obscure the meaning of the code; highly tuned SQL can be quite 'write only.'
COBOL has been used in this type of application for something like 50 years and is a mature, well understood and reliable technology that actually does it quite well.
我确实对 COBOL 编码有所了解 - 学习了 Fortran、Pascal 和 C，但花了大部分时间我在 IBM/390s 上使用 COBOL 专业编码的前 5 年。 不过已经15年没有碰过它了。
COBOL 是卓越的批量财务处理语言。 如果结构合理，它可以比其他任何事情都做得更好，即处理大量财务数据。 它也是一种非常好的嵌入其他系统的语言——通常充当其他系统之间的粘合剂。
把它想象成一个机车:-)。 在 19 世纪，每个人都习惯乘坐火车出行，因为这是我们所拥有的一切，但大多数人都被汽车和飞机所取代。 对于运输大量重型货物来说，铁路系统仍然是最佳选择。 您在日常生活中并不经常看到机车，但它们使您的发电厂用煤炭维持运行。
值得注意的是，Lisp 在人工智能编码领域仍然拥有类似的地位。 我确实觉得有趣的是，20 世纪 60 年代/70 年代三大“大”语言中的另一个成员——Fortran——比其他语言下降得更多，这不是我当时所预料到的。 然而，我们仍然在很大程度上使用 BASIC，它实际上是 Fortran 的私生子，所以可以说所有三个人一如既往地充满活力和活力。
I really cut my teeth on COBOL coding - learned on Fortran, Pascal and C, but spent most of my first 5 years coding professionally on COBOL on IBM/390s. Haven't touched it for 15 years though.
COBOL is the batch financial processing language par excellence. Properly structured it can do what it does best - processing large amounts of financial data - better than anything else. It's also a remarkably good language to embed other systems into - quite often operating as glue between other systems.
Think of it as a locomotive :-). In the 19th Century everyone used to travel by train because it's all we had, but for the majority that was replaced by cars and planes. For moving large quantities of heavy freight around though the rail system is still the way to go. You don't often see locomotives in everyday life, but they keep your power stations running with coal.
It's noticeable that Lisp still has a similar position in AI coding. What I do find interesting is that the other member of the group of three 'big' 1960s/70's languages - Fortran - has declined more than the others, which is not what I would have expected at the time. However we still have BASIC around in a big way, which is effectively Fortran's bastard child, so arguably all three are just as much alive and kicking as they ever where.
Rob，有很多地方仍在使用 COBOL，尽管不一定是针对 .NET； 我们仍然进行大量大型机开发，并且绝大多数金融应用程序仍然是用与 CICS 接口的 COBOL 编写的。
此外，您仍然可以获得适用于 Windows 平台的 COBOL 编译器（例如 Fujitsu）。
Rob, there are a lot of places still doing COBOL although not necessarily for .NET; we still do quite a bit of mainframe development and the vast majority of financial applications are still written in COBOL interfacing with CICS.
In addition, you can still get COBOL compilers (e.g., Fujitsu) for the Windows platforms.
我认为更常见的场景是互操作性，例如，Windows 和 ASP.NET 应用程序与 COBOL/CICS 应用程序通信，反之亦然。
几年前，我曾为我国一家大型银行参与过这样一个项目，我可以想象，这对于任何拥有 40 多年 IT 经验的银行来说都是相当常见的。
I think the more common scenario is interoperability, e.g., Windows and ASP.NET applications talking to COBOL/CICS applications and vice-versa.
I've been involved in such a project a few years ago for a major bank in my country, and I can imagine that this would be fairly common for any bank that has had more than 40 years of IT under its belt.
COBOL 是一个利基市场。 一个美好、舒适、有利可图的利基市场。 这可能（迟早）会变得不存在，但现在它仍然存在。 在这里，几家主要银行组织的核心系统都是用 COBOL 开发的。 这不仅是维护，更是开发！
它已经存在了 50 年左右。 每隔十年就会有人宣布它已死，但它仍然存在。
COBOL is a niche. A nice, comfortable, profitable niche. That probably (sooner or later) will become nonexistent, but right now it is still there. Right here, several major banking organizations have their core systems developed in COBOL. This is not only maintenance, but also development!
It has been around for 50 years or so. Every 10 years someone announcing it dead, but it still hangs on.
维基百科的一篇文章令我惊讶：
http://en.wikipedia.org/wiki/COBOL
我认为 COBOL 是“木材” ”。 这不是真的。
顺便说一下，Fujitsu NetCOBOL for .NET 和 Micro Focus Net Express® with .NET 是相当全面的实现。 也许我们应该学习这门语言，然后找到一份高薪的好工作？ :)
An Article from Wikipedia astonished me:
http://en.wikipedia.org/wiki/COBOL
I thought that COBOL is "lumber". It's rather not true.
By the way, Fujitsu NetCOBOL for .NET and Micro Focus Net Express® with .NET are quite comprehensive implementations. Maybe we should study this language and find a good job with a big salary afterwards? :)
我知道 Raincode、Fujitsu 和 Microfocus。
Microfocus 尝试使用 COBOL 代码隐藏 ASP.NET。
富士通，我不确定他们是否仍在提供自己的 Web 解决方案或尝试适应 ASP.NET。
Raincode 提供了一个针对 .NET 的标准 COBOL 编译器，而不尝试利用 ASP.NET
I know of Raincode, Fujitsu, and Microfocus.
Microfocus attempts ASP.NET using COBOL Codebehind.
Fujitsu I'm not sure if they are still offering their own web solution or attempting to fit into ASP.NET.
Raincode offers a standard COBOL compiler targetting .NET without any attempt to harness ASP.NET