Is there actually COBOL in .NET?
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?
Answer
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.