a companion discussion area for blog.codinghorror.com

COBOL: Everywhere and Nowhere


#221

WHY IS IT ALL CAPITALS? MY HEAD HURTS NOW.


#222

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


#223

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.


#224

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.


#225

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!

Cheers,

Bruce


#226

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.


#227

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)


#228

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


#229

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:
SUBTRACT CUSTOMER-WITHDTRAW-AMOUNT
FROM CUSTOMER-CURRENT-BALANCE
GIVING CUSTOMER-NEW-BALANCE.
or this…
COMPUTE NB = CB - W.

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

At COBOL Gold Mine, we think differently.


#230

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


#231

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.


#232

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.


#233

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.


#234

I don’t think so! They (bank’s bosses) just can’t afford to change the whole system to another technology (Java maybe). It costs billions.


#235

You can try a trip to Japan, they 're still thirsty on COBOL blood :slight_smile:


#236

O am a cobol programmer 23 years and going strong. Our UIs are all java based but many use cobol stored procedures. If you wanted to convert all the Cobol to java you would still need a cobol analyst to figure out how the Cobol currently works sp you can build the same functionality in java.plus Cobol hasnt changed much over the years. With java thete is always refactoring to do to use the latest gramework or the latest version of WebSphere. We still do a lot of cobol batch new development because for the most part the environment is all ready to go.It seems to mr that with java thete is some environmemt setup and authid setup needed.Also from whar I have seen Cobol batch seems to I would love to learn java or some of the high level languages but I dont have the time to take night classes. With all the cobol code out there running today it would cost a fortune


#237

In COBOL, it is pretty much impossible to construct an SQL query without SQL-injection vulnerability. Nobody in their right mind would let you communicate with their COBOL program directly. If anything, you can create the SQL queries via some option-menus, but you sure as hell won’t get to input text. If you do, then you can bet that there is some PHP script between you and the COBOL program, which sanitizes your input - i.e. you’re not communicating with COBOL directly again


#238

I’ve read in several places, that these companies spend 75-90% of their IT budgets JUST for keeping that COBOL crap running. 100 million $ per year just for maintenance of mainframes… developers taking 800-2000$ PER DAY and then do such excruciatingly hard work like “searching where a variable is being set” FOR MONTHS! That’s around 100,000$ for something you could do with 2 mouse-clicks in modern languages!

I think a large part of the problem is that COBOL developers keep telling their supervisors how great and reliable COBOL was - but that’s just because said developers are to INCOMPETENT to even UNDERSTAND the added value in modern languages. (I’ve seen enough laughable pseudo-classes written by COBOL-botchers to know that). And they probably also don’t understand SQL-injections (which are near un-avoidable in COBOL)

And I haven’t even started ranting about variable-visibility, the CANCEL statement, out-of-line PERFORM statements, the language not being LR(k) or LL(k) for any constant k, etc. etc. etc.


#239

I’m pretty much doing that - You can’t imagine, how hard it actually is.

The most basic problem is that modern languages like Java and Python don’t have a goto statement anymore, so how do you translate the GO TOs from cobol? There are “normalization” techniques, but they make the code quite ugly IMHO.

Another example: the out-of-line PERFORM statements redirect the program-flow in absolutely crazy ways (something like “temporarily jumping into the middle of a different function”). This is really hard to translate, You can translate it to the Kleene-Normal-Form, but that requires a lot of ugly, hard-to-read boilerplate-code. You need extremely strong program-flow analysis techniques (fixed point iteration is the key here) to find out when you can translate it to more readable code.

Another example: in an IF-THEN-ELSE statement, you can combine multiple boolean expressions like so: IF X > Y AND A > B THEN .... BUT cobol also allows you to use “AND” to compare something to multiple other values like this: IF X > Y AND A which is equivalent to IF X > Y AND X > A. That doesn’t seem to be such a problem, but try explaining that to a compiler generator like bison! All “normal” compiler generators read single-pass left-to-right, so when they see that “AND” after the Y, they can’t decide what to do. You need to use GLR-Parsing for this. That makes your parser’s code relatively ugly and slow.
Also you easily produce hard-to-detect problems when you continue your development - every time you get a new shift-reduce or reduce-reduce conflict, you need to analyze it carefully to decide if you can safely ignore it (because it’s handled by your custom merge rules) or if it’s an actual problem in your grammar.

I could go on, but that should be sufficient.