a companion discussion area for blog.codinghorror.com

COBOL: Everywhere and Nowhere




COBOL is not going away any time soon.

Mission impossible:

  • Cost of converting the 10.5 million lines of production COBOL code.
  • Finding a system to replace COBOL running on IBM Mainframe(s)that has the ability to process 800,000 stock market transactions at market open in less than 1 minute.

An ex-COBOL Developer with 10years of experience,I had to develop in Delphi and then .NET on the side to keep my sanity.

Very young compared to most COBOL Developers 40


Where there is death, there is life.

If indeed all that code needs maintaining and no one is here to maintain it, those who LEARN it become invaluable.

Could actually be a good career move.


Large new reengineering projects don’t failing multiple times because of what language is or isn’t used, smug comments to the contrary. Projects like that fail because the problems they are trying to solve are extremely complex.

The key reason why an older system can keep chugging along in a complex environment, while boil-the-ocean reengineering projects fail, is that the legacy system has evolved into its niche. It embodies more detailed knowledge about the enterprise than any one person has.

The specific reasons for any new, large project’s failure can usually be tracked down: inadequate business analysis, software development management blunders, interference from the pointy-haired ones, engineers with technology fetishes. But those are details. The main reason is simply that the legacy system knows more about the enterprise than you do.


Well, it’s obvious that COBOL syntax isn’t that friendly.

However, it is far and away the best language for batch processing, i.e. importing a file, sorting it and updating some table.

I worked on a job a few years ago, C++, 6 month contract.

Could have done the whole thing in COBOL is 2 weeks!

Trust me, it may be out of fashion these days, but it is damn good at what it does!




First of all, let me put this clear: I’m not a Cobol programmer. I’m an .Net/J2EE architect with both Java and C# certifications (among others). I don’t need to believe that there are many Cobol programmers outhere, I know that. I work in a company that cannot hire all Cobol programmers that it needs.

Regarding the low number of positions on US for Cobol programmers, that’s pretty easy to understand: all those Cobol jobs went to India, Brazil or China (I live in Brazil, so I know what I’m talking about).

I agree that Cobol is a pain in the ass, but don’t you go that fast to discredit OO Cobol. It is verbose for sure, but the logic part of the code is pretty amazing the same as for C# or Java. Don’t you believe me? Take a look in this excerpt below to digital sign an XML file:

set emptyString to StringEmpty of SystemString

invoke ClassCspParameters “NEW” returning cspParams

set KeyContainer OF cspParams to “XML_DSIG_RSA_KEY”

invoke ClassRSACryptoServiceProvider “NEW” using cspParams returning rsaKey

invoke ClassXmlDocument “NEW” returning xmlDoc

set PreserveWhitespace of xmlDoc to b"1"

invoke xmlDoc “Load” using “c:\test.xml”

invoke ClassSignedXml “NEW” using xmlDoc returning signedXml

set SigningKey of signedXml to rsaKey

invoke ClassXmlReference “NEW” returning xmlReference

set uri of xmlReference to emptyString

invoke ClassXmlDsigEnvSignatureTrans “NEW” returning env

invoke xmlReference “AddTransform” using env

invoke signedXml “AddReference” using xmlReference

invoke signedXml “ComputeSignature”

invoke signedXml “GetXml” returning xmlDigitalSignature

invoke xmlDoc “ImportNode” using xmlDigitalSignature, b"1"
returning xmlDocChild

set xmlElement to DocumentElement of xmlDoc

invoke xmlElement “AppendChild” using xmlDocChild

invoke xmlDoc “Save” using “c:\SignedTest.xml”

The number of lines to perform the logic is almost the same as for C# (if you don’t believe in me take a look in the Microsoft sample to do the same task in C#: http://msdn.microsoft.com/en-us/library/ms229745.aspx).

My point is that Cobol is evolving, and to believe that it would fade away in a near future is not only a mistake, but a recurrent mistake done in the last decades by IBM (PL/1), Nantucket(Clipper), Powersoft(Powerbuilder) and Microsoft(VB/Foxbase) just to name a few…

I do believe that the part of an existing Cobol code that should exposed data to the world should be done by OO Cobol, so you would not ended up with aliens languages trying to communicate with legacy (Java JNI for instance…what a mess) or relying on text files import/export (ugh), EAI (2x ugh) or something like that.

To code a web services in OO Cobol is not only convenient, but also easy to do. There are many compiler options of OO Cobol out there, being Fujitsu one of most impressive.

One of my projects it to create a website with examples of how to do GoF patterns (all 23), RIA with Flex, webservices etc all with OO Cobol. Why? Not only because it is possible, but because this is the way it should be done from a business perspective, and also to make younger programmers get involved without feeling that he/she is wasting their time on this planet. An Abstract Factory is the same, no matter the language…

Again, I do not work with Cobol, I just realized that it still has a long path ahead, and I want to use the best tool in each part of my projects, and not replace one with another compromising scope, responsibilities and, in the end, schedule and budget.

Regards, Emerson
Architects golden rule - keep the stakeholder happy, stupid.


No one’s posted to this thread for some time so I’m probably speaking to an empty room, but its a Friday so why not waste some time.

I’m a COBOL programmer. I learned the language back in 1971, and I’ve been making a living with it off and on ever since. Mixed in during that time I’ve worked in 17 other languages.

COBOL is my language of choice, but I’m a native english speaker, and COBOL was designed first for the english speaking world, and ‘secondarily’ for the oxcidental thinkers of the world.

If you want to understand structure the various computer languages you need to examine the environment/society from which it sprung.

English verb , adverb, object
COBOL verb, qualifier, field/record name

One other thing… one of the old posts bragged about the brevity of the ‘modern’ languages compared to COBOL. You sir/madam are forgetting the library of object, methods, utilities, interpreters, functions, etc. that has to be drug along with your three lines of C# or .NET code.

Without that ‘standard’ library your modern language is useless.

COBOL code is still around not because guys like me are resisting change, it’s still here because nothing better has come along.

COBOL is verbose, because it needs to be. If your modern language doen’t describe the data in the same detail, you left something out.

Burgess (COBOL-o-Sauras)


i gottta take one cobol course in school. anyone know a website or person that will accept payment to do assignments?


COBOL is Dead, Long Live COBOL!

If you do not wish or do not have time to read the following then visit COBOLonWeb.com; See COBOL in Action on the INTERNET like you have never seen it before! Also visit COBOLGoldMine.com to learn more.

COBOL is dead? Right. So is the Explosion Engine that powers individual, commercial, industrial and military vehicles…and the electric car is here to rules the world’s roads and highways…

Why waste all your mission-critical business COBOL applications in which you have invested so much during decades to stay ahead of the competition?

Why rewrite them using one or a combination of those fragile, slow and inefficient languages that pop up almost every six months? Your worst nightmare is to find out after all the time and money spent, that these immature languages are not meant for business mission-critical applications.

Why keep that prohibitive Mainframe just to run your COBOL Batch and Online applications when you could use more cost effective Windows or UNIX Servers to reduce a significant part of your IT overhead and still have your business-critical COBOL systems perform in state-of-the-art GUI and Internet environment and RDMBS such as SQL Server?

Still in doubt? Experience COBOL in Action at COBOLonWeb.com and believe…The rest is easy.

Legacy, eBusiness, eCommerce et alia.

COBOL has been running on more computing platforms than any computer programming language worthy of this name; from Mainframes, to mid-sizes to minis to PCs to Intelligent Cash registers, even handheld computers and scanners much used in the retail and manufacturing industries.

COBOL has also been performing on more Operating Systems than all other past and present computer programming languages combined.

So what is so special about the latest Information Technology “platform” baptized the INTERNET? …Nothing! The Internet is simply a wide and open highway where COBOL feels right at Home.

One last remark: COBOL is too verbose? Too wordy? Here is the fact: COBOL was created to be self-documented programming language. It is the one and only of its kind. Any genuine COBOL programmer knows that one could write either:
or this…

Any Maintenance COBOL Programmer can appreciate the first style not the latter.

At COBOL Gold Mine, we think differently.


Half of our workforce is working in COBOL. Ours is a software service company with strength over 10000.


The COBOL language can be learned easily. When compiled, a COBOL program can become memory efficient and can execute very fast. The feat is understanding the applications. Oftentimes, there are thousands of lines of code wherein all that can be seen is the passing of values. COBOL programmers are extraordinary because they can make sense out of these hundres of thousands of lines! I am an ERP programmer of a system that has COBOL applications for its engines - the most critical parts. Very robust and efficient, did not experience a major fix. On the other hand, the use of the friendlier programs for the more visible functions such as the pages, reports or processing, were the ones that needed most of the fixes and performance tuning.


I know is many years later, but I didn’t read this before and cant help myself now, because I am very young and COBOL expert since I started when 19 yrs old before graduate BScs. My only point is, I couldn’t believe how much of what I was reading… not commenting about it, only to the fact that as everything learning on past techniques, in our career for instance programming languages is critical to the understanding of newer generation languages and without it. Ever since I began programming in COBOL, (not by choice) just an opportunity that changed my life, even though I was very young handling these mainframes and middle range computers seemed to me the main difference to PC’s and client servers types was stability and power, only these could handle millions of transactions without hiccups or choking, it seems stills are. COBOL not ugly, but long depending how expert you are at it, very helpful when I was able to help my programmers troubleshoot their code, in nice English.Created by a wonderful woman Grace Hopper was and still was up until you wrote the article best for business transactions as before others handle scientific, or assembly for machine language, but the data needed in business transactions, COBOL was the best. Also my career took me uninterrupted in ERP systems around 17 yrs working in COBOL, so yes I have very high opinions of it and besides the fact that inspired other languages that still very much alive.


I just checked in to confirm that COBOL is indeed dead, but lo and behold a Monster.com search now yields 1,000 hits compared to @owein’s 174 hits in his August 2009 comment above. Apparently COBOL’s death has been greatly exaggerated…again.