

COBOL MOVEs 50 to AGE - PaddyCorry
http://www.guardian.co.uk/technology/2009/apr/09/cobol-internet-programming

======
greggraham
When I used to ride the train to work, I sat next to a young man who was
looking over a printout of what I recognized as COBOL code. I talked to him,
and he was debugging a problem that came up the night before in the back-end
of a gas pump point-of-sale system. He was very cheerful and seemed to love
his work. After that I thought about that one nice thing about being a COBOL
programmer was that you didn't have to keep up with all of the latest
frameworks and standards.

------
jballanc
Reading this article made me think of Jared Diamond's assertion that invention
is the mother of necessity, not the other way around.

Before anyone gripes about outdated technology you need to ask yourself a
question: what's so great about the new stuff? I'm not saying there isn't an
answer to that question (I'm also not saying that there _is_ ), what I'm
saying is that the answer needs to be better communicated before anything is
going to change.

------
ShabbyDoo
It seems that there a few broad problems with owning/using legacy COBOL:

1\. It's usually run on a big, expensive mainframe.

2\. Good developers run from it, so you're stuck with the coders left over
from adverse selection

3\. It has questionable modularity/maintainability and integration with more
modern stuff is hard.

What opportunities are created by these problems?

My limited experience is that Mainframe COBOL systems (I know nothing of
Microfocus) use either a database (DB2 usually) or large, random access flat
files for persistence. COBOL programs are much like scripts run from within a
transaction monitor. [Please correct me if I'm wrong here!]. Why has no one
done a WINE-style implementation of the important APIs along with an
interpreter so that existing code can be run on a horizontally-scalable
platform? Mainframes are really expensive. Not only does IBM charge a lot, but
you end up buying 3rd party software (ABEND-AID, I'm not kidding...) just to
keep the lights on. Perhaps a distributed flat file implementation could be
built to mimic 60's era data storage models. Does anyone do this? It seems
like a great Open Source business as COBOL users are accustomed to paying for
support and services. What do I not understand about this?

~~~
maxharris
Micro Focus is a major player in bringing cobol onto Unix/Linux/Windows
systems.

They've been around for 30 years, and they have a market cap of less than a
billion dollars (converting from pounds to USD - they're based in the UK).

Their business is really old (but new by mainframe standards), and doesn't
have nearly as much room to grow. Even if they double in size by cannibalizing
mainframe sales, they'll be worth 0.01 Googles, or 0.05 Amazons. So there's
just not enough potential in supporting this kind of junk (which is not a
trivial thing technically - it's ALL messy backward compatibility stuff, and
the jobs are really not intellectually appealing: just imagine telling
yourself or your friends that you maintain a small part of a cobol compiler
for a living).

And startups have virtually no chance at cannibalizing Micro Focus - it took
MF a very long time to take any appreciable amount of business away from IBM's
mainframes.

~~~
ShabbyDoo
An intersting lack of success relative to the amount of legacy COBOL out
there. Thanks for the info. I am reminded of the quote (recently popularized
by Spolsky), "where there's muck, there's brass."

------
maxharris
If cobol is so great, why do Amazon and google run exactly 0 lines of it?

There is a cost (vastly increased development time, inflexibility) to sticking
with cobol, and it may be so great someday that it'll drive the companies that
use it out of business. Just give newer companies 15 years after the current
economic crisis is over and free competition and you'll see the difference.

------
andr
If it's such a big industry how come no one has written something that
translates COBOL to a modern language?

~~~
gaius
Why would they? The only "problem" with COBOL is that it's unfashionable.

~~~
maxharris
Not true - cobol code is often very unstructured. It's very difficult to limit
variable scope in cobol, and functions that would normally be a few lines long
have so much cobol boilerplate around them that each "function" is usually put
into its own source file.

Try dealing with "just" 14k lines of cobol that you haven't written; try to
make minor changes to it (and wait a minute for your $3000 piece of shit Micro
Focus compiler to run) without breaking things. Try getting fed up and
spending a year of your life rewriting the code in Pascal. You won't like it,
but when you're done, you'll say "thank god i'm free of cobol!"

Come to think of it, Micro Focus is usually behind these lame annual PR
campaigns to try to drum up talk about cobol. Their business isn't growing.
Some reasons:

* Installing their product is a big pain. (At least on Solaris/SPARC and Linux.) Bugs in the installer script mean that you have to spend an hour or more on the phone just to install their junk. Support is included with the $3000 fee, but only for a year. So if and when you have to reinstall, prepare to pay a few hundred for the incident.

* Their product uses flexlm, and it sucks just like most consumer DRM, only worse, because it's buggy. I imagine that MF sees it as another form of copy-protection.

* The compiler doesn't play nicely with make, so when you rebuild your project, object files that are up-to-date are recompiled anyway.

* Interoperability with other languages and database systems is so cumbersome that you'll just end up writing output into some cumbersome flat text file, and have the rest of your system _poll_ it to display progress from to your cobol program.

* The free/OSS cobol compilers won't compile non-trivial systems.

If you still think that the only problem is that it's "unfashionable", there
are two possibilities: either you don't really know much about cobol (haven't
used it in a real production environment), or you don't know much about
anything _but_ cobol.

~~~
gaius
You can make a list like that about any language - there are plenty of things
wrong with Java too, such as the amount of boilerplate code required for EJBs,
or the fact that the fragile superclass problem still hasn't been solved, or
there are application servers with stupid licensing. I can't see COBOL being
much worse than Java for any real-world project.

