问题
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?
回答1:
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.
回答2:
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.
回答3:
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.
回答4:
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.
回答5:
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.
回答6:
An Article from Wikipedia astonished me:
COBOL programs are in use globally in governmental and military agencies, in commercial enterprises, and on operating systems such as IBM's z/OS, Microsoft's Windows, and the POSIX families (Unix/Linux etc.). In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.
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? :)
回答7:
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
来源：https://stackoverflow.com/questions/325177/is-there-actually-cobol-in-net