Reason why COBOL is ALIVE 2

I've read some books about software engineering, like Pressman, R.S.: Software Engineering, A Practitioner's Approach. And now it's clear why the big enterprice projects are still using COBOL. It's ECONOMY!

When a project is big and complicated, tasks like planing, developing and testing got bigger and bigger share. It's not rare to see a COBOL-project where coding is less than 20% of total hours allocated.

So even if programmer productivity is eventually boosted up by a NEW LANQUAGE something like 10 - 20 percent, total savings are quite minor: only 2 to 4 percent gained. That doesn't justify conversion to an another lanqueage - which is by the way a major moneysucking event.

Cheers, Humu

 

[mikrom]

I thing, it's not only the economy but the risk too.
It's very risky to rewrite the core business apps working in production over decades into something completely new.
The risk for the business may be very high.

 

[TysonLPrice]

Also many of those systems are running on mainframes and need that kind of horsepower.

 

[webrabbit]

Well, I replaced a VB application with a COBOL application on a PC. The COBOL application was over 10,000 times faster than the VB application.

 

[tom62]

To be honest, there isn't any feature in the COBOL language that cannot be done with less coding in another programming language. COBOL is still there because companies have invested heavily in it. Major applications were written in it and it would take an enormous effort (and money) to replace all those thousands or even millions lines of code.

Apart from that, it is difficult to train people, who have years of COBOL experience and have done nothing else, to lean another, more modern programing language. I've seen for example many object-oriented projects go down the drain, because they were done by programmers, who didn't got a clue about what object-oriented programming is all about. Learning a new language and becoming fluent in it, takes time and money. Whether some shops wants to invest all that money in their IT-staff, remains to be seen.

The trend that I'm seeing, is that companies will keep COBOL alive as the "workhorse" on the mainframe. Things that need to be done in batch-mode or that requires huge amounts of data being shuffled from one place to another are some good examples for keeping COBOL alive.

On the end-user part however, I see that the role of COBOL will diminish. In our company for example, we've replaced all application front-ends with Java, because the mainframe "look and feel" was too cumbersome and heavily out-dated for our users. Not to mention of course, that it would have taken us ages to create decent looking, user-friendly screens in COBOL on the mainframe. Ever tried to create a screen, where the user can scroll up, down, left and right in COBOL? That is truly a pain in the you know where.

 

[papadba]

Apart from that, it is difficult to train people, who have years of COBOL experience and have done nothing else. .

There is as much (or more) difficulty for people who only know point-n-click programming to learn cobol.

Ever tried to create a screen, where the user can scroll up, down, left and right in COBOL? That is truly a pain in the you know where.

Sure - it is not that uncommon. . . A "phone-book" scroll (or other similar style) is nothing more than defining the appropriate arrays and populating them before sending the screen to the user. . . It doesn't have to be that difficult, but some people make it nearly impossible.

we've replaced all application front-ends with Java, because the mainframe "look and feel" was too cumbersome and heavily out-dated for our users

Yup, lots of people like the Windows presentation environment. At the same time lots of users who spend lots of their time entering columnar data prefer the 3270-style screens.


Personally, i believe they should be able to have both/either.

. . .to replace all those thousands or even millions lines of code.

Maybe needs an upward adjustment - read on<g>. . .

Gartner has estimated that there are 180 billion lines of Cobol code in use around the world. Imagine that you printed out all of that Cobol code. Let’s say you get 50 lines per page in landscape mode. Copy paper comes in 2-in. reams with 500 sheets per ream. That figures out to a 227-mile-tall printout. OK, so you print on both sides of the paper; then it’s 113.6 miles tall.

Gartner estimated in 2003 that there were 90,000 Cobol programmers in the U.S. These guys are all looking for something to do, so let’s have them handle the conversion for the whole world.

Let’s see, 180 billion lines of code and 90,000 programmers works out to 2 million lines per programmer. Surely a decent Cobol programmer can translate 20 lines per hour. At that rate, each programmer will require 100,000 hours to complete the conversion of 2 million lines. That works out to 12,500 eight-hour workdays. If we figure 250 workdays per year (though it’s unlikely any Cobol programmers are settling for just two weeks of vacation per year), these guys should be done in 50 years.

 

[tom62]

There is as much (or more) difficulty for people who only know point-n-click programming to learn cobol.

I believe that any serious programmer will be able to learn COBOL in a short period of time, if he or she is willing to do that. Problem is that COBOL isn't a fashionable language any more. In our company we therefore have to teach our younger programmers ourselves. Luckily for us, they are able to pick-up the ropes very fast, because (like I said before), COBOL is not a difficult language to learn

Programming is a serious profession and occasionally an "art", independent in which language your programming. Anyway, you won't find many programmers in companies, who just point-n-click programs together. Working in the IT for more than 25 years, I have only seen end-users, who click something together and then expect the IT-staff to support their crappy MS-Access or MS-Excel "application".

. . .to replace all those thousands or even millions lines of code.

Maybe needs an upward adjustment - read on

I was referring to the lines of COBOL code written in a single company.

 

[mikrom]

...any serious programmer will be able to learn COBOL ... if he or she is willing to do that.

Yes, but the problem is that the most of them is not willing to do that. Some Java/C# programmers think that Java/C# is allmighty and they don't need to learn something other. They are very dependent from the IDEs, which they were trained to use, so they feel very uncorfotable when they should do something on the green screen or the command line.
For example, I can write a simple Java program which uses SQL to work a database table, but my only-Java colleagues cannot (are not willing) write such simple COBOL program.

Most COBOL programmers I know, also have deep understanding of business processes, so they don't need to get detailed analysis to program an application - they could do the analysis, implementation and most part of testing standalone.

So: the former "legacy" application was done by one COBOL programmer/analyst, who programmed self the backend with business logic and the frontend with the green screen.

Now for developing the new application, you need the same COBOL programmer/analyst who analyzes the requirements and programs the business logic and eventually the green screen frontend and then you need one or two Java developers (and maybe a web designer) for programming the Java application which calls the COBOL backend and brings it to the web.
And that's not all, you need new hardware for runnning application/web servers and you need an admin for these servers. And because it seems to be a big project you need to have a project manager.

Some years ago we started so to modernize our business apps. Now some people want to have the frontends ambiguos - (green screen and web), because they say that the working with the green screens is much faster than working with the new click-frontends.

 

[tom62]

Yes, but the problem is that the most of them is not willing to do that. Some Java/C# programmers think that Java/C# is allmighty and they don't need to learn something other.

I agree with you in general. What some of these programmer perhaps don't realize is that COBOL isn't dead [yet] and has been longer around than any of their fancy programming languages. However, I do know several young programmers, who think that learning COBOL gives them better chances on the job market than Java/C#/Ruby (etc.) alone. The demand for COBOL programmers is getting higher and higher, because the older generation of COBOL programmers are retiring and it gets very hard to replace them.

I think that it is always good idea to lean more than one computer language. Reason for this is that there isn't a "Golden Hammer" programming language. All languages have their strengths and weaknesses. For one project COBOL might be better suited, for an other project perhaps JAVA or something else could be the better choice.

They are very dependent from the IDEs, which they were trained to use, so they feel very uncorfotable when they should do something on the green screen or the command line.

Even the COBOL world made some wonderful progress regarding IDE's (f.e. Eclipse), so there is no need to stare at a green screen anymore. This makes debugging and coding much more comfortable in COBOL than ever before. I'm sorry to say, but if IDE's make our lives more easy then why should we not use them? The IDE itself doesn't make a good programmer out of a bad one, because a fool with a tool is still a fool.

Most COBOL programmers I know, also have deep understanding of business processes, so they don't need to get detailed analysis to program an application - they could do the analysis, implementation and most part of testing standalone.

Understanding the business processes is something that someone learns over the years. That has nothing to do with whether he or she programs in COBOL or in any another language. Reason why many COBOL programmers know the business processes better than anyone else is because (at least in my firm) they are longer with the company than the younger "hot shots". It is the experience that counts. That is what makes the COBOL programmer so valuable, not only for the company, but also for the junior programmers.

Some years ago we started so to modernize our business apps. Now some people want to have the frontends ambiguos - (green screen and web), because they say that the working with the green screens is much faster than working with the new click-frontends.

That depends on the program- and GUI design. I've seen some very good examples of "green screen" mainframe applications as well as very bad ones. The same is the case for applications that have GUI front-ends. Some of them "stink", others are wonderful to work with.

 

[webrabbit]

The COBOL language was designed to implement business rules. Other languages are designed to implement flashy user inerfaces, machine efficient code, or other functions such as engineering functions. I doubt that a fourier transformation would work well in Java. I know of no other language that could work with the national debt to the penny without rounding errors. Furthermore, no one in this discussiion has mentioned Object COBOL or Visual COBOL, both of which support cutting edge user and database interfaces.

Proper progam design involves a psuedocode step. COBOL is psuedocode. Have you ever had to write a truth table? COBOL has a truth table implemented as native code. Have you ever had to explain to a user that your program has implemented his business rules. If it were COBOL, he could read it for himself.

 

[mikrom]

With the truth table, you probably mean Decision table. I'm happy that COBOL has implemented EVALUATE statement and I'm using it frequently.
And yes COBOL is self-documenting.
But as pseudocode for fast prototyping of algorithms, I'm rather using Python or Ruby

 

[webrabbit]

Yes, the EVALUATE statement has not always been part of COBOL, but it has been in COBOL nearly twice as long as COBOL existed without it. The same is true for most other "modern" aspects of COBOL.

 

[TysonLPrice]

Apart from that, it is difficult to train people, who have years of COBOL experience and have done nothing else, to lean another, more modern programming language. I've seen for example many object-oriented projects go down the drain, because they were done by programmers, who didn't got a clue about what object-oriented programming is all about. Learning a new language and becoming fluent in it, takes time and money. Whether some shops wants to invest all that money in their IT-staff, remains to be seen.

I have to disagree with that from my own personal experience. I was a COBOL programmer on IBM mainframes for eighteen years and found the transition easy (almost fun). I had already made the transition from sequential files to relational databases and had quite a bit of experience on-line (CICS). I’ve also found COBOL programmers generally have a better concept of manipulating memory, i.e. what’s going on under the covers.

There hasn’t been much discussion of another aspect of COBOL programming, at least on IBM mainframes, and that’s JCL. Having to handle memory allocations, file structures, etc. for batch processing. Especially when your mixing databases, VSAM files, and flat files.

 

[jmanj]

Whats the fuss? Cobol will be here to stay for a long time. I was trained by IBM (early 65) in many computer languages such as Fortran,basic,RPG, Assembler, Cobol, Pascal, Socket programming, etc. Cobol has been recycled so many times(flavors). Nowadays cobol can deal with forms and portal environment and can call different APIs written in different languages. Many ERPs like SAP, Lawson and Peoplesoft has written many of it's program in Cobol with combination of other languages.

It is true that computer languages evolves into many forms mainly because of business requirements and also because computers has evolved into a more powerful and savvy devices.

Nowadays I have to learn Java, Javascript, VB, C++, Perl and other object oriented languages just to keep up with the changing environment. Yet, in the midst of it all, Cobol is still there much much more powerful than a generation ago.

At present, in my free time, I'm doing some game and graphic programming and my inspiration of methodology is always the Cobol standard.

 

[burnie75]

And then there's me ... I started programming in COBOL in 1967 ... using coding sheets and cards/keypunches, then moving on through online/mainframe coding, CICS, up through Microfocus COBOL, etc.

Sprinkled throughout the years were programs written in C, Fortran, DataBus, Assemblers (many types), QuickBasic, QuickC for Windows, all versions of Visual Basic and C#.

And when you look at my code, it all looks like COBOL!! %-)

Burnie

 

[dneufarth]

current programming languages like Jave, C#, et al are merely the legacy languages 10-15 yrs in the future.

Dave

 

[gmt360]

I personally believe, If a person has a little understanding of programming (logic basically) then COBOL is self driven, just follow it and it is clear. What else I can say in Honor of this language.

Garry