Modernizing the Common Language - COBOL

Frumious Wombat writes "Over at the Register Developers section, they are quoting the head of research for Ovum Consulting on the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it. From the article: 'The first stage in the legacy modernization process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code - modern tools can automate much of this analysis for staff working at a higher level.'"

'legacy modernization'

[Fr05t]

No.. it had it's time, please let it die.

Re:But it is modern!

[jaavaaguru]

There are a few implementations of object oriented COBOL for .Net out there...

Fujitsu COBOL and NetCOBOL for .NET [fujitsu.com]
Micro Focus Net Express [microfocus.com]

Both of those are rather expensive, and I've not seen any open-source ones yet. I thought it would be fun to write a COBOL compiler for .Net as a pet project. I've started it [blogspot.com], but haven't had much time to spend on it recently. My plan was to get it to a point where it can do some useful things then put it on sourceforge.

There are companies that help with this-

[bishiraver]

One such company, Envyr Corporation [envyr.com] (makers of iCobol), builds a solid windows-based IDE for COBOL. Their compiler supports many different architectures - AIX on RS/6000, DG/UX on AViiON (though, newer versions aren't supported on this platform), HP-UX on HP Series PA-RISC 1.1, Intel RedHat (above kernel 2.2 for newer releases), SCO (yeah, yeah, I know). They also support the full line of Windows OSes, though older versions like 98, NT and ME only have basic testing performed on them.

They provide tools for transitioning from older Data General COBOL to newer OSes (Windows, RedHat).

Interesting thing also, is they provide a cgi platform for COBOL.

They also provide various APIs for C to interact with the COBOL program you have, services for code migration, etc etc.

The company is run by several ex-Data General employees, and they really know their stuff.

Disclaimer: I do not work for Envyr Corp, but I have family that does.

UTTER Nonsense! COBOL is glue language in a stack

[scottsk]

Sorry, but I have to rant: Whoever wrote this has no idea what they're talking about.

COBOL is the glue language in a stack of application components sold by IBM including CICS (or ISPF), VSAM, DB2, etc. These are quite modern and up-to-date, and run on the mainframes that make the world go around by providing reliability and uptime at load levels beyond the wildest dreams of PC and Linux users. Sure, anyone could learn COBOL basics in a day or two, but you're not going to learn and certainly not going to "modernize" a COBOL program running against a DB2 database. COBOL is a glue language that glues together high-performance relational database access, high-performance presentation-layer management (CICS makes Windows API programming look simple!), etc to process umpty transactions per second, where umpty is a number beyond the reach of most Linux boxes. You're never going to "modernize" this stuff because it's the only thing around that can do what it does at that throughput level. The COBOL part is just a driver among the different components. Even the business logic has been factored out into stored procedures now.

There is no problem bolting on web access to databases and data warehouses, or stuff like that, but whoever wrote that (imagine that, a consulting group who will come in and modernize everything for you!) has absolutely no idea what COBOL applications are or do. You are most definitely not going to port legacy applications to new platforms that use CICS or ISPF for their presentation layer! Get a clue. And what platform are you going to port your COBOL program to? The mainframe is already the highest end platform of all time - there's nothing with more throughput - I doubt a company would take the notion of porting to MySQL on an Intel box very seriously. The bottom line is people use the IBM application stack because it works, at a performance level where nothing else works.

Sure, it would be fantastic to have an open source COBOL compiler with a MySQL precompiler so people could learn the language (ever tried to parse COBOL!?). And a Mono COBOL compiler would be fantastic. But no one is going to port their mission-critical business applications from a mainframe to a virtual machine runtime environment. You might use C# or Python to create new apps to access the data in new ways, offline, but you're not going to port mission-critical stuff.

Fortran updated each decade

[peter303]

77, 95, 2003
(I skipped the 80s too.)
Like all the legacy languages it acquired all the new fad constructs. Still pretty conscise for formulas and array operations.

Re:yes COBOL and ADA

[T.E.D.]

I notice someone has already corrected you on the proper capitalization of Ada. It seems a silly thing to get sensitive about, right? But there's a good reason it gets folk's panties in a bunch. For one thing, it is nearly always done by someone who doesn't know a thing about the language, doesn't care to know a thing about it, and wants to be able to dismiss it (without getting into messy details, like its actual qualities).

That would be enough to annoy many people by itself. Additionally, by capitalizing it you are implicitly categorizing it with older acronym languages like COBOL, FORTRAN. PL/I, rather than its proper contemporaries like Modula-2, Oberon, Java, etc.

That's in terms of age. In terms of use and philosophy, probably the closest language to Ada that most folks here would be familiar with is Java. They both had the same design goals of safety, readability, and reliability. The main difference between them is that Java's designers thought that C-style syntax's marketability outweighed its readability drawbacks. Most of the other differences between the languages are in emphasis.

Anyway, I think you can probably see where Ada users would get a little ticked at someone trying to dismiss it at an ancient COBOL-like language. Try talking dismissively about "that ancient language JAVA", and see what kind of responses you get.

COBOL+VB

[dtfinch]

Some of the scariest shit I've ever seen. The old parts are written in COBOL, a pile of over 4000 scripts with 6 character filenames that work together to form an ERP system. It originally used flat files to store records, with multiple record types in each file. At some point they managed to upgrade to a real database server without significant code changes, which means multiple record types, with completely different fields, in each table. It updates database records using the ever popular "delete and reinsert without any atomicity" method, occasionally (dozens of times) deleting a major customer's records because it crashed while updating them. New parts of the ERP system are written in VB6, and store much of their data in Access databases, despite that there's a perfectly good database server they could use. At one point I wrote a script to monitor one of the Access databases and backup and repair it each time it became corrupted.