Industry


Ads by TechWords

See your link here


Sound Off's picture
Sound Off

From Computerworld Readers

Cobol versus Java and C#

According to the Computerworld article Cobol: Not Dead Yet, Cobol may be the Rodney Dangerfield of programming languages but it also can't be beat for such uses as batch processing. Its defenders claim that Cobol is easier to learn, write, read, and manage that OO languages. Is Cobol as rock-solid as its proponents make it out to be? Are Cobol programmers dinosaurs, or are they vital to maintain all of the Cobol apps still operational in mainframe environments?

Given that Cobol can be compiled to run on Windows, Unix and Linux servers, so why isn't more of that occurring? Why are so many perfectly good Cobol applications being ported to Java or C#? What's the business case for this?  What's the programming case?

________________________________
Related Articles and Opinion:

What People Are Saying

COBOL is still alive. It

COBOL is still alive. It cant die. As far as I know, its being used in a wide number of places even now. Not only the classical apps but even new ones are still being built.

See my site at http://www.dotnetuncle.com

COBOL is the one language

COBOL is the one language that utilizes business terminogy and did true decimal arithmetic ("comp-3" on a mainframe). It didn't require college courses and management could read through the code. The justification for replacing it was that it was verbose and difficult, neither of which iss true.

COBOL, Not cobol. COmmon

COBOL, Not cobol.
COmmon Business Oriented language. The most Mature and most stable programming language ever devised for business Applications to date. Be it Financial, Manufacturing, Reservation, Banking, or any industries.

It is also the most consistently updated programming language: COBOL born in 1959. Continually updated and enhanced to support new technologies and computer power in 1968, 1974, 1985, 1997 and 2002 (COBOL-68, COBOL-74 COBOL-85, COBOL-97, COBOL-2002).

It is also the only programming language that runs on practically all computing platforms ever built (American, British, French, Japanese Mainframes, Minis, PCs and it run on just about every UNIX platform), and the Internet!

Read about some of what has been said or taught wrong about COBOL and the truth about COBOL and where it stands today at ( http://tech.groups.yahoo.com/group/cobolgoldmine/message/327 ). Those who think that COBOL is dead have not done their homework. All credit card transactions around the world are handled by COBOL. Just about every ATM machine on the planet provide cash to account holder using COBOL application. Nowadays, more business applications are being developed using COBOL that any other language. Many project managers hide this fact by fear of looking “outdated” or use some language “du Jour” to develop Internet applications because they do not know that COBOL power and performance are much higher even on the Internet.

COBOL ON THE INTERNET: visit www.COBOLonWeb.com. “Seeing is Believing”.

If any of you want to see what can be accomplished on the Internet with COBOL, visit http://www.COBOLonWeb.com , and experience the power and lightning speed of COBOL on the internet like you have never seen it before. There is no - repeat - no other language used to power the business application per se. At the moment you select an option COBOL takes over. The user interface is in HTML. And some JavaScript to handle animated graphics, the menu and to make COBOL "swing". FYI, the Web server in located in central Florida and is the slowest machine we could find to prove a point; a mere 1.29 Ghz Intel CPU.
Furthermore the same COBOL module runs in a multi-lingual environment, from English to French to Spanish to Arabic, Hebrew, Hindu, and more...
And try the “2007 look” of the application by clicking on the United Nations flag. Again still the absolute same COBOL modules but different UI. Enjoy!

Questions and Inquiries welcome at cgm@ils-international.com

I'm an intern at a large

I'm an intern at a large insurance company. I still have a year left in my CS degree and my new employer is helping me to learn COBOL. I could not even imagine replacing the massive mainframe dinosaur. I think eventually it will have to go, just because the system and the language is so cryptic. Today I watched a senior programmer write a COBOL batch program. He took probably 3 hours from start to finish. If I were to have written the same program in C++ or Java it would have taken me several days, if not a week, mainly because there are already so many written programs out there in COBOL that he was able to copy and paste most every line of code he used. He took pre-built parts of the car and put them together. For me, I would have to make new functions for everything.
Now, if the code base for the company had been in Java or C++ I bet I could have assembled the program in under an hour.
Even though I say COBOL seems cryptic, I have seen it solve every business problem thrown at it, but I have no doubt with C++ or Java's flexibility that they could also do the same but with better efficiency.
I do not wish that I would be programming in Java or C++, etc, because with so much COBOL still out there, and a quickly declining COBOL programmer base, someone will need to re-write these systems.

I program now in csharp, but

I program now in csharp, but I did it in cobol 17 years ago for a while... and if cobol is alive is for something... it really works, Tandem computers with screen cobol and cobol85 does what several years later was called client/server computing... why most banking applications runs on mainframe and cobol?... I guess it will be here for another decade

happy coding

I'll defer to the master on

I'll defer to the master on the question of COBOL... To wit:

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense"

-- Edgar Djikstra

All of the reasons for

All of the reasons for killing COBOL have as much relevance as those for keeping it.

Languages that build applications that are insulated from the technology they run on are more durable and less costly to sustain. COBOL was born on the mainframe where churn from technology has been reduced significantly. Otherwise you wouldn't / couldn't have sustained the applications without committing to costly yearly investments merely to remain current with the latest infrastructure.

Businesses do not value from investments made to chase technology merely to stay current. Converting an application from one language to another doesn't add value unless some event has made staying where they are too risky.

However, the hype over the need to convert languages does open up the door for outsourcing options. After all - who best to complete that costly conversion. Once converted, who now knows those applications better?

IT professionals need to focus on solving business problems with technology - not chasing the technology as if there were inherent value in it.

ps - you can hard-code in any language. Most of the faults attributed to COBOL dealt with design choices made when memory and on-line storage were scarce commodities.

COBOL on Unix never took

COBOL on Unix never took off, because COBOL is a glue language on the mainframe that controls CICS, ISPF, DB2, etc and most of these technologies were never ported to Unix (except DB2). Without the stuff it glues together, COBOL isn't very useful.

Why is programming language

Why is programming language selection is always portrayed as a form of class warfare?
If a designer cannot decide whether a particular application needs to be implemented in Java or in Cobol, he needs to be fired on the spot for sheer incompetence. Cobol and OO languages should not replace each other - they occupy different niches and in fact work quite well together. Java is geared for many exciting things but transaction processing is not one of them. Attempting to implement a back end of good reliable transaction processing (e.g. financial) system in Java is no better than attempting to implement a real time operating system in cobol or fortran. Just make sure your IT folk knows Cobol and OOP languages equally well.

Presently developing an XML

Presently developing an XML document (Tax Filing and Payment required by the Florida Department of Revenue) using AcuCobol-GT 7.3

Get the PICture?