I went to a “1 year wonder” school in 1986 and we were taught BASIC (Not VB), COBOL and RPG III. Got hired in a RPG shop in 1988 and we are still using RPG to this day. We even have some old FORTRAN apps running on old VAX workstations. I have done a little COBOL moonlighting. We are so backwards we still have over 75 Twin-ax tubes in our shop hooked up to our IBM iSeries. I now write some .net front ends,but I have to admit, I don’t like it when I have to put files on anything but the IBM because it never ever “Eats” the data.
i have 5 years of hands on cobol experience in a germam insurance company
“
Did they write software systems so perfect, so bug-free, that all these billions of lines of code are somehow maintaining themselves without the need for legions and armies of COBOL programmers, decades later?
”
in some ways that it is the truth
in our company we have code that runs bugfree since 1992, furthermore the vast amount of the transactions are done with cobol
in contrast the company is slowly changing the running applications from cobol to java, guess what … 100 bugs everyday in production 
in the end it’s not the language, but in the COBOL times and in ‘those’ companies (insurance, bank, etc.) the it-departments tended to produce high quality code with special quality service groups… today there are deadlines and the trinity where time and budget always wins over quality
There is an office with 100+ COBOL guys cranking it out, less than 4 miles from where I’m sitting right now. I’ve actually met several of them.
These guys are recruited from all over the globe and believe me, they make about 3 times more than the .NET guys they sit right next to.
This company has been attempting to port their systems over to .NET since .NET came out, and they’ve barely made a dent in 10 years.
In 10-15 years we’ll be talking about ABAP/SAP the same way we’re talking about COBOL. And the funny thing is, there’s still companies paying TONS of money to SAP and its consultants to build systems that will dig them in the same way COBOL did 20 years ago.
Last year I was talking with a contractor in Chicago who recently developed a replacement for a COBOL based insurance package. It was running on Texas Instruments TI990 hardware under DX10 - an OS which has not had an update since 1984 and a hardware platform which dates from 1973. It was maintained by an 85 (yes eighty five) year old guy who came in a couple of times a week.
Jeff: So what?
Commenters: It is possible and typical to write good code in COBOL.
I can also attest to repeated attempts to replace existing large scale application systems consisting largely of Cobol. These have been a recurring nightmare to be involved in, though most have never made it into production before being called off at terrible expense.
Cobol is still alive but it’s death is closer than ever because people that knows it are going to be retired soon…
Not really (about retiring soon).
I’m 39 and I did COBOL for Alcatel back in 91. I’m maybe 20 to 25 years to retirement.
COBOL is just and only a programming language. As long as there are legacy programs running COBOL or more modern systems running on COBOL’s more recent incarnations (OO COBOL and COBOL 2002), the language is pretty much alive since it’s being actively used.
If we don’t know any COBOL programmers it is because of the same reason we may not know any car factory workers, or scientific investigator. We tend to stay around what we do. But you do go to USENET or to COBOL specialized websites and suddenly you’ll see where they hang out and your perception changes.
I agree the self-promoting text is perhaps a little too over the top. Couldn’t say for sure. But the world is more than just business applications oriented towards the desktop. There’s an whole world out there that powers nuclear stations, does weather prediction, maintains giant warehouse inventories, help management of commercial ports, dams, etc.
Certainly not a popular programming language these days. And definitely not the language of choice if one is given the option (which used to be a lot more limited back then).
But it’s just and only a programming language. And if there is the need to support a legacy system, even if that means upgrading it, or creating something new, any of us can learn the program language, or on some cases revisit it.
I’m 32 but my first job out of college used COBOL a lot.
I was never trained in COBOL. It was instead one of those languages where you just sort of infer by staring at it long enough.
But your snippets above underscore why so much of the world’s code is written in COBOL - it takes way more lines to pull even simple things off. Back when COBOL was the norm, programmers were rated by the KLOC - thousand lines of code.
When you see mentions of COBOL statistics, the #1 reason cited for the declining population of COBOL programmers is “retirement and death”. Young people (myself included) don’t want to use COBOL and would rather code in Java or C# or even C++ or something. So the number of COBOL programmers is in decline though there are offshoring companies willing to take up the slack. Problem comes when the companies employing those older programmers decide to cut them loose early to avoid paying pension and retirement benefits since now they have low cost replacements.
And as nicely as I can put this, a lot of the COBOL programming population is old and from a generation where computer programming was akin to candle making - you learned how to do your one thing (your trade) and you spent the rest of your life doing that. And there’s fields where this is a perfectly legitimate career course but not modern programming. So the reason a number of COBOL programmers are still COBOL programmers is because they just don’t want to learn anything else or change.
We once had people come in to train us on VB.NET (back in the .NET 1.0 era), and some of the programmers were furious when they thought they would be expected to learn OOP. One of my coworkers in that job was a 76-year-old grandmother who was only working to get away from her husband. When something came up she didn’t want to do, she’d just refuse to do it, or threaten to quit. And this was seen as acceptable somehow (context: it was a state government gig).
So I was never so happy as when I was finally out of that job.
What I don’t understand is that so many people are saying stuff like “This here newfangled Java code has a lot more bugs than our COBOL-software”.
Of course the COBOL-version has less bugs: It’s been debugged for 30 years! Even if someone says he’s been working with some specific piece of code for the last 25 years, he still hasn’t seen 95% of all the bugs that were in there in the first 5.
This is not to say that COBOL is without merits: It’s probably really fast, lightweight and probably runs on any platform you throw at it, which, in the really long run, is more important than code structurability (who cares if your code is well-structured if it doesn’t run on any hardware?).
But let’s not pretend that if you write some COBOL-software today, it will still be used in 40 years: Those software lifespans are either long gone or at least not limited to COBOL: Given the right company policies, you’ll probably find old Java-code still being used in 40 years time as well.
The fact that you’ve never met someone who programs COBOL for a living says way more about you and the systems you are accustomed to building than it does about COBOL.
If the programs that are compiled from COBOL simply ceased to exist modern life would follow quickly. Used an ATM recently, I’ll bet you whatever you like that it talked to some COBOL code before it spit out your $100.
COBOL code lives on because the systems that were built with it are functional AND critical.
I also have never had to deal with COBOL but looking at your example you can see why there are so many LINES of COBOL. Perhaps their is a better measure than sheer line count.
sorry there not their
The fact that you’ve never met someone who programs COBOL for a living says way more about you and the systems you are accustomed to building than it does about COBOL.
If the programs that are compiled from COBOL simply ceased to exist modern life would follow quickly. Used an ATM recently, I’ll bet you whatever you like that it talked to some COBOL code before it spit out your $100.
COBOL code lives on because the systems that were built with it are functional AND critical.
Burgun Wrote: “Yep, I know there aren’t many of us left and some of the work isn’t as exciting but I’d rather earn what I’m earning rather than competing with some kid just out of high school who’ll charge fifty bucks to set up a web site that will be probably full of security holes and be unmaintainable in a month.”
What are you on about? I can’t make any sense out of that.
Where would you like to meet, Jeff?
Part of my first job was to move around the various parts of the organization so I got 1 month of COBOL training and 3 months doing programming.
This was 15 years ago and it had one of the best business aka forms user interface designers.
The forms portion was totally separated from the rest of the COBOL, so your COBOL code could take for granted that the code was in the correct format.
You setup how you wanted the form to look and then for each field you could specify what type of data it was(phone, SSN, date, etc) or you could create your own using regexp. Error and informative messages were done in the user interface program and you could have a simple message and there was a link the user could show more detailed info; this was auto generated or could be customized. You could differ the display format from the what the user had to enter so when the user entered a box for a number it would change to remove commas but when they exited the box it was back to having them. Best thing was that dates and other formats that could entered in multiple ways were handled and converted to a specificed format and it recognized those different format.
Still looking for a current tool that would do all that old tool could do without the need for extra coding.
I write COBOL code – only been on the job for one year, thought it would be a change of pace to do… never took it in college, they got rid of it by the start of my junior year – and to point out, I wouldn’t say the code is “perfect”, but for the most part, unless we’re cleaning out some old code, or code that still carries out some sort of transaction (but is no longer needed and we want to remove it to reduce line count), there can be programs that haven’t been touched since 2004 (our project started in 2002, still in HS at this point!)
Since it is most transaction oriented - one program for one type of transaction (say, DB2 into some flat file or vice-versa), once that transaction works, the code stays that way indefinitely until there’s some new code needed to add. This only happens if some business groups says they need something new added. And most of the time it could be done elsewhere than in the mainframe processing.
This will also say why it isn’t likely to be replaced. The obscene amount of datasets, databases, transaction processing code, etc, would take forever, and then some, and besides, it’s so incredibly well suited for its purpose, there’s almost no reason to change it. That, and it’s cake to pick up. But really, no one uses it for anything else, and obviously for good reason.
Have a friend who’s parents make a living being the only people in the state who know COBOL as well as they do. They maintain and update systems decades old for organizations too cheap to completely overhaul them.
I took Cobol as part of my Computer Science degree in college but have avoided applying for any jobs that required it (it wasn’t a good experience). Very much happier working in .Net.
Most of the places I saw jobs for Cobol (I applied/searched alot when I first graduated) were banks and insurrance agencies. I pitty anyone that took those jobs.
The State of Michigan was looking to hire a Cobol programmer a year or so back… they wanted an entry level person though. Good luck finding that I say, no one straight out of college is going to have enough Cobol experience to realistically work on large scale Cobol systems.