COBOL Will Outlive Us All

jfruh writes "Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works. The truth behind that is the reason that so much decades-old COBOL code is out there still driving crucial applications at banks and other huge companies. Many attempts to replace COBOL applications flopped in the 1980s and '90s, and we're stuck with them for the foreseeable future — but the Baby Boomers who wrote all that code are now retiring en masse."

Comments

Batch

[mwvdlee]

Well... that and the fact that COBOL is actually very good at what it was made to do; batch file processing.

Re:Batch

[mwvdlee]

Yes, I'm sure it's much easier to code in RPG. In Java/C++/PHP/C# you could probably do it in less than a dozen lines of code as well. But none of those come close to the performance of COBOL for these specific tasks.

As far as right-aligning a string; it's supported in the data division: http://mainframewizard.com/content/cobol-just-right-clause. I'm sure if I had to program RPG without any training or a manual, I wouldn't produce very good code either.

COBOL is bad at a lot of things and in a lot of ways, but it does have a few redeeming qualities. It just turns out those particular qualities are highly sought after in many large companies.

Re:Batch

[grh_angelone]

ok, this doesn't bring us any further, but do you really think, that moving something in a right justified variable is the solution?

this doesn't only need another variable, but if your source value has trailing spaces you will need a ridiculously long INSPECT line and an index variable for a substring.
since cobol is dumb, you will further need an INITIALIZE for both variables.

cobol:
01 var1 PIC X(50)
01 var2 PIC X(50) justified right
01 sub PIC 9(2)
initialize var1 var2 sub
move "test " to var1
initialize var1 tallying sub for trailing space
if sub = 0
move var1 to var2
else
move var1(1:sub) to var2
end-if

rpg:
d var1 s 50a
d var2 s 50a
c eval var1='test '
c evalr var2=%trim(var1)

seems way more convinient :)
even tough RPG is ill-reputed as an old static programming language this looks somehow like any other high level language and anyone should understand what's going on here without trying to figure out what that strange INSPECT does

Re:Batch

[Anonymous Coward]

No. COBOL was designed for taking simple decimal (BCD) representations of quantities and financial amounts, conducting basic arithmetic operations on those and transferring the result back to storage or line-printer-style reports.

It is still the basis of a great many online, interactive applications as a result of the development of OLTP systems that were intended to provide "real time" transactions on top of old legacy batch procedures. CICS in particular is alive and well and nothing to do with batch processing - though its interactivity is largely achieved by having the display terminal emulate the fixed fields of punched cards and line printer columns - and although it has support for several languages, COBOL is where it found its natural home.

There's nothing magical or mysterious about COBOL (apart, perhaps, from the MOVE CORRESPONDING statement) - it's a procedural programming language that works with simple representations of data. The idea that a modern generation of programmers can't understand it is ludicrous and anyone that suggests rewriting swathes of code simply to change the syntax of its representation doesn't understand the first principles of software engineering.

COBOL is here to stay in both batch and interactive applications.

Re:Batch

[Anonymous Coward]

No, COBOL is magical, in that it supports handling of decimal arithmetic as integer, keeping track of the decimal place as a separate operation until the end. That is one of the main reasons that so many financial institutions used it -- no rounding. As far as I know, only PL/I is the only other language with this built in feature, even to this day. Certain compilers also used occult features of machines that did arithmetic in decimal (like a calculator) instead of binary --again, great (and in the 70's, a requirement for international banking) for financial applications.

Re:Batch

[bws111]

Um, no. I don't know where you got that crap, but it is entirely false. IBM itself currently sells COBOL, FORTRAN, C/C++, PL/1, and REXX compilers for z/OS. In addition, you can use gcc, etc.

And your line about IBM mainframes not having protected memory is complete bullshit. They have had protected memory since 1964. It is not an option.

And NO user space programs affect system integrity, no matter how they are written or what language they are written in. That is one of the major selling points of z/OS.

Re:Batch

[Sique]

When COBOL was being used for new development, I don't think the P1 was even out, we're on Xeons now.

When COBOL was being used for new development, the microprocessor wasn't even invented yet, and Intel founder Robert Noyce was working at Fairchild Semiconductor and had his first integreted circuit ready.

Re:Batch

[grh_angelone]

i ditched the columns for my example :)
but i don't mind the column-specific syntax.
in fact, i really like it

but IBM introduced free format RPG some time ago
you can start a free block wich /free and end it with /end-free
http://www.ilerpgprogramming.com/2009/01/code-examples-of-free-format-rpg-iv.html
but they did a sloppy job on the implementation
the definitions in the program header and some operations still have to be done in fixed format

OpenCOBOL.org

[emil]

If you have any contact with COBOL in your profession, check out OpenCOBOL.org.

With a free COBOL compiler, you have an option of moving this ancient code onto a modern platform with fast CPUs. If you find it lacking, start coding!

I've tested it for Linux and Cygwin, and it works.