Announcement

**Helder** · 10-12-2013, 02:40:11 PM

Cobol sucks!! I took a course in it in school many years ago and it's just old and lacks features of C++ and way too much declarations needed. Oh and the whole Y2K scare years ago was because of Cobol's shortcomings and inability to go past 99 in the years field. Tons of programmers were hired to fix the fault and we avoided the Y2K scare.

**dlevere** · 10-12-2013, 02:52:50 PM

Tons of programmers were hired to fix the fault

Heheheh...I remember that...tons of old Cobol and Fortran programmers, they were the only ones who knew the language well.

**Pyriel** · 10-12-2013, 07:34:19 PM

COBOL is all right if all you're doing is "read a file, write a record" type tasks. I imagine they've added some extensions to it, so it's not just batch-only without CICS layered over it. Although, it sounds like they haven't added enough that you could do anything graphical with it. And it does have a pretty extensive set of required declarations for even simple tasks.

The Y2K thing wasn't a limitation of COBOL, strictly speaking. COBOL doesn't have an inherent datetime type, or at least COBOL 74/85 and right up to the modern era didn't. The problem was short-sighted developers believed their code and standards would fall into disuse because of rapid improvements in technology. They didn't count on the incredible inertia of business, and since they were working with more limited storage—RAM and persistent—they saved space by allocating 5-6 positions for date fields, instead of the 7-8 that would have been preferable. Then they wrote their programs and library code around that standard. Most of the Y2K effort was just expanding fields and correcting all references to them to include an additional two digits in the date. Which led to jokes about a programmer who put himself into cryogenic sleep, hoping to bypass all the Y2K hassles. Naturally, he was forgotten about until about the year 9998, when he was thawed to work on the Y10K issue.

**dlevere** · 08-05-2014, 01:50:34 AM

Looking for a Job? How's Your COBOL?

Looking for a great technical skill to develop to make you all the more marketable in today’s increasingly fast-paced industry? Have you considered COBOL?

No, we’re not kidding, and no we aren’t confused because we’ve been binge watching Mad Men and Halt and Catch Fire with their throwbacks to ancient systems and software. The industry—particularly the U.S. federal government—is facing a shortage of experts in the venerable language, and they’re willing to pay handsomely for expertise.

For all you Millennials out there who probably aren’t familiar with this particular acronym, COBOL is a computer language designed in 1959 (based on work by Grace Hopper). Unlike its primary competitor at the time, FORTRAN, COBOL was intended for business use, rather than scientific use. Hence its name: Common Business Oriented Language. And in the heyday of computer commerce and administration in the 1960s, billions of lines of it were written. (One could argue this is because it took so many lines of COBOL to do anything.)

As we all know, hardware may come and hardware may go, but software is forever. Despite all the talk about reengineering business processes, it takes a long time and a lot of money to rewrite a program, especially one that works. Major federal agencies such as the Internal Revenue Service and the Social Security Administration are based on COBOL. The SSA has 60 million lines of COBOL in production as of 2013, and found that the benefits of replacing COBOL would not outweigh the risks. Remember the issues with software in the Veterans Administration? What do you think would happen if the tax system or Social Security went down?

COBOL vendor Micro Focus claims:

COBOL supports 90 percent of Fortune 500 business systems every day
70 percent of all critical business logic and data is written in COBOL
COBOL powers 85 percent of all daily business transactions processed
$2 trillion worth of mainframe applications in corporations are written in COBOL
1.5 million new lines of COBOL code are written every day
5 billion lines of new COBOL code are developed every year
The total investment in COBOL technologies, staff and hardware is estimated at $5 trillion
An estimated 2 million people are currently working in COBOL

Some COBOL programs did get rewritten in other languages to deal with the hype surrounding the Y2K problem. (This is when people believed programs might fail upon reaching the year 2000, because they’d all been written to expect years to start with 19.) But some COBOL programs were just patched to deal with it. Others actually had four-digit year fields to begin with, and those COBOL programs just kept chugging along.

So what’s the problem? As the Department of the Navy said when it explained why it still used 200 billion lines of COBOL code, “If it ain’t broke, don’t fix it,” right?

The problem is that the program is in operation, but the world isn’t cranking out many COBOL programmers anymore. The COBOL programmers we do have are nearing retirement, with as many as half of them aged 50 or more, according to Bloomberg Business Week. This goes beyond the government, as it affects private industry as well. “In some cases, only one or two people understand the core banking software the bank runs on and the older programming language in which it is written,” writes American Banker, which it calls the “key person” problem.

Consequently, active COBOL programmers are in short supply. So, thanks to the law of supply and demand, salaries for COBOL programmers are going up. “The salary for top talent can reach six figures, and agencies and companies are still awarding contracts today for COBOL software maintenance,” writes FedTech. The U.S. Office of Personnel Management estimated that the maintenance costs for the retirement system could go up 10 to 15 percent due to the lack of programmers.

The most difficult aspect of learning COBOL might be finding classes. A number of schools dropped COBOL courses because nobody was enrolling in them anymore. A 2013 survey by Micro Focus found that 73 percent of academics running IT courses at universities around the globe do not have COBOL programming as part of their curriculum, although 71 percent still believed that business organizations will continue to rely on applications built using the COBOL language for more than the next 10 years.

The survey also found that the universities believed students weren’t all that interested in learning COBOL, either. When asked about student attitudes toward learning COBOL, 65 percent of universities gave a negative response, with 39 percent saying their students viewed COBOL as un-cool and outdated, 13 percent saying they believed COBOL was dead and 15 percent saying their students wouldn’t know what COBOL was.

Perhaps they just hadn’t heard this joke:

A COBOL programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.

When he asked why he was unfrozen, he was told:

"It's the year 9999—and you know COBOL."

**Pyriel** · 08-05-2014, 12:32:50 PM

Frankly, I don't know why you'd offer a full-blown course in COBOL anyway. You can probably learn 70% of it in an afternoon. Come back the next day for a lesson on the EVALUATE statement and more advanced JCL. Next week, we'll spend both sessions learning CICS and other interactive add-ons, which you won't be fully exposed to until you're on the job.

If it wasn't for all the declarations and other ancient conventions, I think the language would comprise about 50 keywords and operators, none of which are particularly novel. The lone exception is the EVALUATE statement which is strange and powerful and frequently misused. At it's core it's like a switch...case in C or a CASE...WHEN in T-SQL (more like the latter than the former). You can do "EVALUATE MY-FIELD WHEN 'A'...WHEN 'B'...", but it also allows you to do "EVALUATE TRUE WHEN MY-FIELD = 'A'...WHEN MY-FIELD NOT = 'A'", and so on. You can specify multiple conditions with "ALSO". Where it gets problematic is when people come along and do things like:

Code:

EVALUATE TRUE ALSO TRUE ALSO TRUE ALSO TRUE ALSO TRUE
  WHEN MY-FIELD = "A" ALSO TRUE ALSO TRUE ALSO TRUE ALSO TRUE ...
  WHEN MY-FIELD = "B" ALSO MY-FIELD2 = "1" ALSO TRUE ALSO TRUE ALSO TRUE...
  WHEN MY-FIELD = "C" ALSO TRUE ALSO TRUE ALSO TRUE ALSO TRUE...
END-EVALUATE

I saw crap like that more than once while I was working on Y2K stuff. People would come up with bizarre standards that were supposed to make maintenance easier, or somebody would do a "performance analysis" comparing IF statements to EVALUATE statements while the machine was under wildly different loads or by running different files and conclude that EVALUATE performed better, so all IF statements should be replaced. So basically, I reckon you can pass as a COBOL programmer even if you're a complete doofus.

Announcement

COBOL Code Contest Challenge

COBOL Code Contest Challenge

Comment

Comment

Comment

Comment

Comment