.NET中实际上有COBOL吗？

Question

我刚才正在查看微软的Visual Studio页面,在广告边栏中,我突然看到了一个令人难以置信的广告:

"Net Express是一个COBOL开发环境,用于将核心业务流程扩展到.NET Framework和其他分布式平台."

当然我按照链接找到了一家这样做的公司,但还有那些地方还在使用COBOL吗？有没有人在.NET框架中实际使用COBOL？

编辑:感谢大家的以下信息,我今天肯定学到了一些东西!

Answer 1

Micro Focus构建了一个COBOL开发套件,主要用于维护传统的大型机应用程序.它讲的是来自各种平台的20种COBOL方言,并且有一个CICS仿真工具.截至2004年,他们建议将大型机工作负载替换为400 MIPS左右.请记住,在20世纪90年代早期,您仍然可以从Amdahl购买额定值为22 MIPS的大型机系统.大型机上的400 MIPS是相当大的工作量.

将传统的COBOL后端集成到现代前端是一件大事.对于各种协议(如CORBA和SOAP),终端 仿真 软件,屏幕抓取器,接口库和RPC包装器有相当大的生态系统.

几年前,Micro Focus推出了一个COBOL .NET编译器,允许您在CLR后端运行COBOL应用程序.您可以编译任何支持的方言,它将运行所有旧版仿真功能.这允许您在现有COBOL应用程序上放置GUI或Web前端(或Web服务层),从而保留您在现有代码库中的投资.前端可以用几乎任何支持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的数据(一次猜测为1亿到2亿条记录)也不一定是一项微不足道的工作.通常,从SQL获取性能需要您采用一种稍微倾斜的处理方法,这可能会模糊代码的含义; 高度优化的SQL可以完全"只写".

COBOL已经在这种类型的应用程序中使用了50年,并且是一种成熟,易于理解和可靠的技术,实际上它做得非常好.

Answer 2

Rob,有很多地方仍然在做COBOL,尽管不一定是.NET; 我们仍然进行相当多的大型机开发,绝大多数财务应用程序仍然使用COB与CICS连接编写.

此外,您仍然可以为Windows平台获得COBOL编译器(例如,Fujitsu).

Answer 3

我真的很喜欢COBOL编码 - 在Fortran,Pascal和C上学习,但是我在前5年的大部分时间里专注于IBM/390s上的COBOL编码.但是15年来没有碰过它.

COBOL是卓越的批处理财务处理语言.正确的结构,它可以做它最擅长的事情 - 处理大量的财务数据 - 比其他任何事情都要好.它也是嵌入其他系统的非常好的语言 - 经常作为其他系统之间的粘合剂运行.

把它想象成一个火车头:-).在19世纪,每个人都习惯乘火车旅行,因为这是我们所拥有的一切,但是对于大多数人而言,汽车和飞机取而代之.虽然铁路系统仍然是可行的,但为了搬运大量重型货物.你不经常在日常生活中看到机车,但它们让你的发电站用煤运行.

值得注意的是,Lisp在AI编码中仍有类似的地位.我觉得有趣的是,三十年代"大型"20世纪70年代/ 70年代语言中的另一个成员--Fortran--比其他语言下降得更多,这不是我当时的预期.然而,我们仍然在很大程度上拥有BASIC,这实际上是Fortran的私生子,所以可以说这三个人都像以往一样活跃和踢腿.

Answer 4

我认为更常见的情况是互操作性,例如,Windows和ASP.NET应用程序与COBOL/CICS应用程序通信,反之亦然.

几年前,我参与了这个项目,为我国的一家大银行做过工作,我可以想象,对于任何拥有40多年IT经验的银行而言,这都是相当普遍的.