The New COBUG Site.   Read the Full Story
GnuCOBOL (formerly OpenCOBOL) Description
GnuCOBOL (formerly OpenCOBOL) is a free COBOL compiler. cobc translates COBOL to executable using intermediate C sources, providing full access to nearly all C libraries. OpenCOBOL 1.1 continued on as GNU Cobol 1.1. Officially posted to ftp://ftp.gnu.org/gnu/gnucobol, also available here. GnuCOBOL 2.0 is on its way to a pre-release. A superb manual by Gary Cutler, along with a FAQ / How-To, and other documentation is indexed at http://opencobol.add1tocobol.com/guides OpenCOBOL 1.1 is Copyright (C) 2001-2009 Keisuke Nishida
Copyright (C) 2007-2012 Roger While
Read the Full Story
Why COBOL Will Never Die October 25, 2012 by Naomi Karten Way back when I was a programmer, COBOL was the language of choice. It wasn’t as much fun as Fortran, which made me feel like a logician, and I loved using Assembler whenever I had the chance. But COBOL did the trick, and we developed some pretty nifty systems with it. Read the Full Story
image NEW COBUG
image GnuCOBOL
image COBOL Die Never!

COBOL News

  • Other Headlines
  • COBOL Die?

Top Headline

16 Grid Layout

Why COBOL Will Never Die
Way back when I was a programmer, COBOL was the language of choice. It wasn’t as much fun as Fortran, which made me feel like a logician, and I loved using Assembler...

Read More

New COBUG News

  • Other Headlines
  • NCOBUG Site

Top Headline

The New COBUG Site.

The New COBUG Site.
This site is in memory of the late Thomas Perry the founder of the original COBUG site...

Read More

GnuCOBOL

  • Other Headlines
  • GnuCOBOL

Top Headline

RTL Support

market for Cobol skills/developers
Is there still a market for Cobol skills/developers?COBOL is dead, right? All the IT developer jobs now are in modern languages like C++, .NET and Java, right? Wrong!...

header 396x89.fw

nlogo

 

Why COBOL Will Never Die

grave 0

Way back when I was a programmer, COBOL was the language of choice. It wasn’t as much fun as Fortran, which made me feel like a logician, and I loved using Assembler whenever I had the chance. But COBOL did the trick, and we developed some pretty nifty systems with it.

And then it went away. Well, no actually, it didn’t. Despite the arrival of newer languages and the transition away from mainframes, COBOL has managed to hang around. In fact, it celebrated (if that’s the right word) its 50th anniversary in 2009. One reason it can’t die is that there remains a reported 220 billion lines of COBOL code still in use.

Computerworld described a managing director at a bank who is responsible for 112,500 COBOL programs comprising 343 million lines of code that run core banking and other operations. Whew!

In fact, according to estimates, approximately 60 to 80 percent of all business transactions performed worldwide are written in COBOL, and even a bigger percentage if you consider only financial transactions. Big banks, in fact, were one of the first sectors to implement it and may be the last to discontinue it.

Despite the constant call to prepare for COBOL’s funeral, it remains solidly able to handle huge volumes of information. Its strengths have been based in file storage, access, and manipulation of textual data. COBOL excels at taking data from a database or file, crunching it, and spewing out some sort of output. A great many of the applications written in COBOL have remained largely unchanged in the last several decades.

Yet, relative to the systems of today, COBOL has some clear weakness: It’s not the first choice for systems that require graphical interfaces. Purchased applications tend not to be written in COBOL, and some don’t link well to existing COBOL applications. Other languages came along to handle COBOL capabilities along with capabilities COBOL couldn’t handle.

But the biggest threat to COBOL’s future may be recurring predictions, warnings, blogs, and articles (such as, OK, this one) that question its survivability. This understandably makes managers nervous, and they understandably curtail use of COBOL even where its use might be appropriate and seek other languages wherever they can. I imagine that in their place, I’d do the same.

Sooner or later, and maybe sooner rather than later, COBOL’s continued existence is going to create problems as the number of people skilled in its use—and willing to use it—dwindles. Fewer and fewer colleges still teach COBOL and college graduates with COBOL training are in short supply. And those in the know—the skilled and accomplished COBOL techies—have retired, or soon will.

If I were still an IT manager, the COBOL brain drain would make me mighty nervous. But technology is infinitely adaptable and so are the people who use it. Solutions to extend its life indefinitely may yet appear. I’ll see you at COBOL’s 60th anniversary party.

 

This website uses cookies to manage authentication, navigation, and other functions. By using our website, you agree that we can place these types of cookies on your device.

View e-Privacy Directive Documents

You have declined cookies. This decision can be reversed.

You have allowed cookies to be placed on your computer. This decision can be reversed.

Login

Who's Online

blank

To get the username of the current process, from the level of DCL, you could invoke the command:

$ write sys$output f$getjpi("", "USERNAME") WISNIOS $

But it is not so obvious to implement this in the COBOL code. The function as it is called from DCL would be replaced by run-time library rutine. The prefix of function – F$ – would...

Read more...

blank

Thanks to Tim I finally managed to install the COBOL on my OpenVMS system.

Here you are a few “screen shots”.

Unzipping the archive.

$ set def dua2:[cobol] $ unzip cobol057.zip Archive: DUA2:[COBOL]COBOL057.ZIP;1 inflating: cobol057.a inflating: cobol057.b inflating: cobol057.c

Loading the license.

$ license load...
Read more...

Contact Us

2me

Contact our website news team via our Online Customer Support Service.

Member Login