Is there actually COBOL in .NET?

Question

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?

Gamic

I'm voting to close this question as off-topic because it's a very old question which does not fit on the site today, and which could be answered by search-engining, contacting Micro Focus, noticing that they have new releases of the product and other trivial methods. – Zeidman

Answer 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.

Benelux

Answer 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.

Pithos

I think Fortran is still used quite a lot in the scientific community. My physics degree course (at a very well regarded UK university) included a module on Fortran and that was only about 5 years ago. – Racecourse

BASIC-that-was-like-Fortran died two decades ago along with ZX-Spectrum and similar equipment. Modern Visual Basic is much closer to C# rather than to Fortran – Quick

Oh come off it. Even now VB.net is horribly structured as compared to a real language. Sure it may have improved quite considerably, but underneath it's still BASIC, you can't change it's nature. – Pithos

@Cruachan: You must also have a very low opinion of C#, as VB.NET and and C# and almost identical twins with minor syntax differences. – Dobbins

@ChadD I see what you mean, but I'm not sure that's true, superficially because the predominant aspect of developing on .Net is the API itself then they appear to be similar, but if you separate out that from the language itself then basic is still, well BASIC. – Pithos

Wish I could upvote more than once. I LOVE the locomotive/rail analogy. Brilliant! I started my development career with COBOL in 1994. I used VB5/6 late 90s early 00s. Started JavaScript and C# in 2002. Used COBOL as recently as 2010. I still love it. It really is the Big Iron Workhorse as you so deftly described with your analogy. – Belgae

Answer 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.

Durbar

I had no idea, I'd always heard Cobol was a dinosaur, so I thought Cobol was actually extinct with a very few exceptions. Its enlightening to here its still somewhat alive and kicking – Gamic

The mainframe is also a dinosaur but I'm pretty certain the return on investment for IBM's STG (the division that makes z/OS) is still 20-to-1 or better. – Durbar

re being a dinosaur: The IBM z800 series was developed with the code name Raptor, which I thought was pretty funny. You can still buy them used... according to this reseller, they go in the range from US$300,000 to US$1,200,000. [reliablecomputer.com/pricez8.html] – Kindred

Answer 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.

Irresolution

I imagined these sort of things had been replaced already, but that just goes to show how wrong I was, thanks for the "news" ! – Gamic

Answer 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.

Kaiserslautern

One of my all time favorite jokes is the "Y10K Problem". toofaani.com/jokes/computers/year-10000-and-cobol – Belgae

It is still here 11 years later. – Radicle

Answer 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? :)

Patnode

Answer 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

Cinematography