Pathfinder Development » I have seen the future, and its name is COBOL

I have seen the future, and its name is COBOL

Brian Dillard, Wednesday, October 3, 2007 @ 1:10 pm

Nothing puts day-to-day developments in the Ajax world into perspective quite like a sit-down with someone from an earlier generation of software developers. I got the chance for just such a conversation recently when my dad came down to Chicago for a White Sox game. My father worked in Battle Creek, MI, for Post/General Foods/Kraft/Philip Morris/Altria for close to 35 years, first as a computer operator and later as a programmer. For most of that time, he wrote in COBOL, followed by a few years of C development in the '80s and early '90s, then retirement. Chatting with my dad about the ups and downs of his department and his career, I couldn't help but think about how little things have changed. Now, as then, a successful career in technology is as much about maintaining expertise in foundational technologies as jumping on the latest bandwagon.

COBOL doesn't come up, well, ever on blogs like this one, but it's still one of the most-used programming languages on the planet. As this article on the future of COBOL attests, COBOL still provides the business logic and transaction processing for most financial institutions and other big companies. Sure, Java and .Net provide a bridge between COBOL back-ends and shiny new web interfaces. But the fact is, millions of new lines of COBOL are still written every year. ANSI's latest standardization of the language, COBOL 2002, is only five years old.

A friend of mine who works as a government bank examiner joined my father and me for lunch. He told us how difficult it is for regulatory agencies to find people who are qualified to look at the guts of COBOL systems to assess their compliance with laws and regulations. COBOL still gets taught in the computer-science curriculum, but most practicing COBOL developers get snapped up by the organizations that need them most: banks, manufacturing companies and other large businesses. A lot of large banks are even looking to partner with computer-science departments to produce a new generation of COBOL developers. According to my friend - and all of the causal reading I've done - mainframe-based COBOL code can still process millions of transactions a day in a fraction of the time it would take to do it in Java. Think about that the next time your online banking system is on hold because their "system is being updated."

None of this really has much to do with the development of rich internet applications, but it's interesting to think that someday the technologies we're all iterating over so rapidly will seem, to the next generation of technologists, like total anachronisms. Let's hope that, like today's COBOL developers, our skills will still be in high demand even when the technologies we're using become old hat. I know I'll think twice next time I start griping about legacy systems.

Technorati Tags

COBOL

Topics: COBOL, Legacy Systems

agile ajax

Comments: 14 so far

Thank you for this commentary. This perspective should be shared as often as possible.

I work with IT and software development but I also function in the environmental engineering domain. In both domains people (including myself) get enamored with the “latest.”

Today, soil removal (literally digging up and transporting contaminated soil off site) is, in many cases, more effective and cheaper than the latest vaporizing, bio “solution.”

I’ve been dazzled by PHP only to learn later that a C plus approach would have saved money and would have crunched the data probably 50 times faster, with out breaking.

Comment by Tony, Wednesday, October 3, 2007 @ 5:04 pm
COBOL faster than java (or c# or c++ or any other modern languages) ???
How can it be ? does cobol supports massive threading, parallel programming, transactional cache and so on ?
Batch (sequential) processing is far from be as efficient as parallel processing. I guess old timers are always blind to new truths.
Changing one’s programming habit is hard and old myths are still strong. Cobol is not good for the needs of today.

Comment by jos, Wednesday, October 3, 2007 @ 6:01 pm
@tony

i think you misunderstand the term batch processing regarding cobol on mainframes …

it just describes a batch program which runs without any user involvement. you can have hundreds+ of those programs running at the same time and everyone can handle millions of database operations in just a fraction of the time a c# or c++ could be able to do.

[quote]I guess old timers are always blind to new truths.[/quote] … i would say most of the programmers today don’t want to realize that there are still some specific areas where “old technology” can do a better job than “new technology” …

Comment by kajdo, Thursday, October 4, 2007 @ 12:10 am
i quite agree, see this one.somtimes going backwards is really fast forwarding. I would like to draw your attention to another alternative which is a paradigm shift for AJAX front ends. One should be aware that I am not, and do not pretend to be objective, never the less I believe that one can judge for himself. Visual WebGui is an open source rapid application development framework for graphic user interfaces of IT web applications. VWG replaces the obsolete paradigms of ASP.NET in both design-time and run-time which were designed for developing sites, with WinForms methodologies, which were designed for developing applications. Thus enabling designer that was designed for application interfaces (WinForms designer) instead of a word documents (ASP.NET designer). This provides the developer with an extremely efficient way to design interfaces using drag and drop instead of hand coding HTML Worth a look at http://www.visualwebgui.com

Comment by navot, Thursday, October 4, 2007 @ 12:25 pm
is COBOL really in demand? If so, I’ll go learn it.

Comment by Henry, Thursday, October 4, 2007 @ 1:50 pm
“COBOL code can still process millions of transactions a day in a fraction of the time it would take to do it in Java”

That’s completely untrue. Care to backup your argument with statistics? I work for a vendor that supplies systems to financial institutions (COBOL backend/Java frontend), and your comments do not coincide with my experience.

Comment by John, Thursday, October 4, 2007 @ 3:03 pm
I’m one of the few people I know under 30 who actually writes Cobol for a living. I’m an ERP programmer, the whole thing is written in Cobol, there is no question that this language is here to stay. However, I’m spending a significant amount of time learning Java. Why? Simple, Cobol isn’t fun to code in. Java is “the new Cobol”, it will be around forever too, but at least it’s a more powerful language.

Comment by Adam U., Thursday, October 4, 2007 @ 4:45 pm
@Adam: I’d love to hear how you got involved in writing COBOL, whether you studied it at university or learned on the job, etc.

Comment by Brian Dillard, Thursday, October 4, 2007 @ 5:07 pm
@Henry

i don’t have statistics at hand but if you work in/for such a company just compare the response time of a user command …

just try to update a table using the java-frontend with a cmp/bmp in the db-layer and compare it with the same command using a cics-transaction - you’ll be surprised how much time it takes just to dig through all of the j2ee layers to do the update and once again to present the result - i think you don’t need scientific statistics to prove the efficiency of the cics-version

never tried to code a java-batch but i think if there is something like a vm on the host - it’s also clear that this would take longer to interpret than a cobol written batch job (at least cobol was designed for exactly that reason - making as much db operations as possible in a minimum of time) … btw. a usage of a vm on the host would also need lots of resources i think

Comment by kajdo, Thursday, October 4, 2007 @ 6:37 pm
sorry the previous post was regarding john’s comment not henry’s …

Comment by kajdo, Thursday, October 4, 2007 @ 6:40 pm
Hi all,

No, I’m sorry to say I don’t believe COBOL is faster than big distributed environments. I was a COBOL/CICS programmer for the first 6 years of my career (11 years ago) and currently work for a company that does really massive batch processing. We used to do it on the mainframe– in ASSEMBLER, no less, but have since switched to a big grid of Linux machines. It’s much faster, believe me.

BTW, the grid mostly runs C++ and CORBA stuff…. For parallelism, look over tools like Abinitio and Data Stage. These offer pipeline and partition parallelism, with a reasonable development environment.

My .02 worth…

Best Regards,

Rick

Comment by Rick, Thursday, October 4, 2007 @ 9:20 pm
I work on C/C++ apps running on HP-UX PA-RISC boxes that interface with “legacy” mainframe/COBOL systems. I cannot accept that mainframe systems are faster than modern systems. The reasons why the mainframes are around at my place are:
1>The business logic implemented in these systems are either not or poorly documented. It would take ages to get back documented business logic from the existing codebase
2>The company doesnt want to throw away the investments it made in these systems and go with new-fad C++/Java/Ruby replacements because the existing systems are “good enough” and there wouldnt be sufficient ROI

Modern Midrange(Sun,HPUX,AIX_)/PC environments can run in circles around these mainframe systems.

All said, I do believe that the mainframes are much more reliable environments (No crashing/Restarting etc) than the Midrange/PC environments

Comment by Gryph0n, Friday, October 5, 2007 @ 5:11 pm
@Gryph0n & Rick

very interesting comments … could you give me some more information abt. your environment … right now i started to write my master-thesis with the “workingtitle” Cobol meets J2EE and i would really be interested in your point of view you can contact me via http://www.contactify.com/eb813

Comment by kajdo, Wednesday, October 10, 2007 @ 10:26 pm
At my first job at CN&W, I had 5 job duties. I was Programmer, Analyst (a separate job now called Business Analyst), Tester (a separate job now called QA Tester), Documentation, Production Support (a separate job now called Support Engineer).
The best way to hold down IT costs would be to have the programmer do ALL these tasks, under the direction of a manager WHO ACTUALLY HAS DONE PROGRAMMING. You can’t believe how many managers are NON-TECHNICAL. Your manager should be a go-to person, who has more knowledge than the developer, not just a chart maker. Nowadays the analysis is done in the US, the programming done in India, the QA done in the US, the support done in India, the documentation not done anywhere. Information technology is a bloated, inefficient PIG nowadays - blame MANAGEMENT. You have 5 separate parts pulling a program in 5 different directions.
A truly competent programmer/analyst, which is what my title used to be, can save the company a LOT of money.

Comment by yakijy, Tuesday, January 1, 2008 @ 10:50 am