COBOL MOVEs 50 to AGE | Hacker News Reader

COBOL MOVEs 50 to AGE

guardian.co.uk

16 pointsPaddyCorry15 comments

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.

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.

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?

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.

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."

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.

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

First, it's not a very large industry.

And the technical problem is very difficult to solve - you have many different versions (from each decade) of the language to be compatible with.

But most importantly, think about the result of success - translating cobol successfully to a modern language means that your customers don't need your product once they're done. This is why MF does lame PR once a year - they want to keep businesses from modernizing away from their product.

I searched and found products to convert to C (http://www.mpsinc.com/cob2c.html) and to Java (http://www.jazillian.com/howCOBOL.html). However, it is probably easier to maintain the code in the language it was designed in. Also, as the article said, COBOL is very good at what it does.

Why? Translation would only introduce bugs, and it compiles down to assembly anyway. Better to gradually replace components one at a time (which is, from the article, what seems like is already happening).

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

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.

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.

> 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.

I meant that they see the bugs as a form of inadvertent copy-protection because their resolution requires a support call.

Apparently COBOL does have Macros: http://smuglispweeny.blogspot.com/2008/03/kenny-and-firing-s...

Reply on news.ycombinator.com