COBOL: Everywhere and Nowhere

blog
61

“I have a hard time reconciling this data point with the fact that I have never, in my entire so-called “professional” programming career, met anyone who was actively writing COBOL code.”

This is because you are less than 50 years old, as are most of your friends probably. I know several COBOL programmers who work for things like insurance firms, etc. But I only know them because they’re relatives.

Look in the classifieds of major newspapers under software jobs, until recently a big chunk of them were AS/400, Crystal Reports, and COBOL. This stuff was the nuts and bolts of business software for the past 20 years or so, slowly being replaced by a more modern spectrum encompassing VB, Access, Oracle, SAP, whatever. But they’re still around.

62

I still write COBOL in my job… It’s currently my primary language, though I’m shifting towards primarily .Net development.

And as far as usefulness goes, I can make COBOL do most things I need it to. Including servicing web calls. We’ve got .Net code that makes a web service call that is served by a combination of COBOL and Fortran.

Is it my first choice for doing that? Hell no. But when you have to live within certain shop constraints, you learn to adapt and get the job done.

63

The world could probably benefit from a Cobol variant that adds a more familiar C-like syntax in the source code but is binary compatible to previous versions. (There apparently already are recent versions with modern language features like object-oriented concepts, etc.)

64

Not a bad post, but remember that total cost and total revenues are not the same as marginal cost and marginal revenues.

65

I think everybody here is confusing syntax, power and tool scope.

Every successful language has a syntax tuned for it’s task (sql has a good syntax for data manipulation, c for memory/register manipulation, awk for lines of text manipulation, etc).

COBOL is not an exception. Yes, you can see that fragment of code and think what a verbose thing. You are wrong! COBOL syntax if pretty compact for what it is designed to do. You are just looking at the wrong example. Try writing a Java (or other modern language) program that receives an input file (say XML, reads every entry, does some calculation and writes it back to the same format and you would get exactly the same verbose bunch of lines. On the other hand, write an online processing server and the same language is very succinct.

COBOL was successful in it’s days because it’s very close to assembler (the syntax is easier to maintain but it can be easily translated). It has no dynamic memory allocation (so you can guarantee performance for every transaction, which is not as easy in modern languages).

And it’s oriented towards data processing, NOT object or functional processing.

This should not be a problem for anyone trying to use the right tool for the right problem (unless of course you plan to use awk to write your next mission critical accounting application).

I don’t write COBOL (and i prefer C++ or Javascript/Python), but there is a healthy community of COBOL programmers (mostly in any large companies having a system that has must handle more thank 100K customers/invoices).

I think it’s unlikely that it will go away as it is still very efficient doing what it does (that’s why it’s wrapped with new technology’s applications).

If nature and evolution enhance what is already there to create better organisms, i don’t see why our industry should work different.

In this scenario you would be tempted to make a secuence of calls, but the problem is that you can jump from inside one of these blocks to another. This, i believe, was the right semantics when COBOL was created, because memory and disk was scarce, but most important, because at the time, modern CPUs didn’t have stacks and call/return instructions (if you can imagine such a world :-).

66

I work in an office where there are about 40 COBOL developers. We also have an Indian office (10+) and UK office (a couple). They are around and I can assure you, COBOL isn’t going away for the product created here for a long, long time - if ever.

The nature of the application means that it gets updated yearly and we’d do about 4 releases a year.

Thankfully, I work on on of the frontend products, using Delphi. We also use C++ and C# here.

67

What’s the point of the video?

COBOL isn’t and was never meant to do WinForms. Reminds me of the Monty Python skit where they go after mosquitoes with shot guns.

If you want to process a batch, i. e., take 1 or more dataset, apply procedural logic to them, and create a new dataset, COBOL can reliably get the job done.

68

I had to take an editor class and COBOL class in college about 10 years ago. Man there was a lot of paper printing on those computer lab printers. I kind of miss those 3 inch tall stacks of paper that made up each program.

69

When I moved to the corporate office to program, one of the stipulations was that I had to learn COBOL so I wasn’t just using .NET and could help with the other technologies.

I’m by far the youngest person here, but there are plenty of people under 40 who use COBOL daily.

After 2+ years with it, I have to say, it’s like writing a novel for ever program, to top it off, we don’t even use a relational database, still on VSAM.

As painful as it is, COBOL has made me a better programmer. It tends to make mistakes in logic painfully obvious.

“The line number figure sounds pretty impressive, doesn’t it? 220 billion lines of code, 80% of all code lines in the world. Wow, that’s really, really impressive… for those people that don’t know COBOL at all.”

Hilarious, and oh so true.

70

We love to sit back and watch you young wipper-snappers reinvent everything we’ve done before!

I’m a lead application engineer at a Fortune 500 company. The application I support has around 3,400 COBOL and around a thousand assembler programs (yes assembler!). We continue to add features to our system every day. We bring in the young ones that have been brained-washed into thinking they can program in a vacuum, and teach them COBOL. The fact that it is in English and is fairly easy to use it a big bonus!

And yes it runs on big iron, which is getting smaller and faster every day. Think of the mainframe as a large server. :wink:

71

My lovely wife (a COBOL youngster at age 45) works with COBOL software running on VMS on HP Integrity servers. Her company has twice tried to re-create their software (computer-assisted dispatching for 911 call centers) under Windows. They ended up with big messes of unreliable software that have led to their being sued by various large US cities and counties.

As you can imagine, she’s now pretty smug about both COBOL and VMS and wonders why my code has all those silly lower-case characters in it. On the other hand, she despairs of ever getting a programming job with anything other than a huge corporate or government bureaucracy.

72

I work with .NET / Java. But, the large insurance company I work for has lots of COBOL systems. I’ve dabbled a bit in the code. The worst part is not the language, it’s the development tools – they’re the same vintage as COBOL.

73

We still use RPG II were I work, an IBM mainframe language that was designed for punchcards with a fixed program logic loop. You have not experienced coding horror until you’ve struggled with RPG II.

I recently created an ASP.NET web service using Fujitsu NetCOBOL for .NET and wrote a blog post about it. After hours of experimentation I created the only non-trivial example of using NetCOBOL to actually do something.

74

As a college intern with a power utility company based in Staten Island, NY - in 1990 - I was given the job of extending the functionality of their HR application managing overtime approvals/accounting.
I spent a couple of weeks collecting requirements - until it was realized that this thing was required to be written in COBOL - of which I had no experience.
I spent the next three months in a COBOL crash course.
I had 3 weeks left to write the app - I managed to convince my manager that it was a futile gesture. I wrote them a Lotus 1-2-3 macro based solution, network aware, distributed, which not only met all their requirements, but at the end gave them a data dump that they could load into the mainframe.
I was never as relieved to get out that place - COBOL is not for me!

75

Last job at a electric/gas company for a large city was using .Net and Sql server, but ultimately at the very core, was a mainframe running cobol. Current job at a print manufacturer, using .Net, but all pricing (and lots of other stuff) comes from a custom Cobol application.

The Cobol crisis will become apparent when old cobol programmers retire and younger developers don’t apply for empty positions because they don’t want to work on such an old language. Thats when all cobol work will move offshore.

76

“IBM mainframes and DEC VAXes and Alphas don’t have “Blue Screens of Death”. They measure their uptimes in YEARS.”

The AS/400s (admittedly not mainframes) that I’ve seen get IPL’ed (essentially rebooted) about once per week. Isn’t that fairly common?

77

I am almost exactly the same age as COBOL, which was the source of (most of) my income up to around 1989. I know that code I wrote in the early 80s is still in operation: I still meet - occasionally - the people who run it.

But I got better. 15 years or so of mostly VB (living on in my world as Excel VBA) has now given way to the majority of my time being spent with Ruby (and the obligatory, but not exclusive Rails). Very little that I have written since my COBOL days beyond maybe the last five years survives. That’s probably not a bad thing.

78

At my company we upgraded to a popular Accounting/ERP system last year. Its written in COBOL.

79

I have a hard time believing that cobol has anything to do with mobile phones. I also have never met a cobol programmer. Then again, I have managed to stay away form the horrors of insurance companies, car rental places, retail banks and the like.

80

@Chess: Why does it have to move offshore? There are plenty of developers here in the USA and if we paid them properly then they’d work as COBOL developers. Havent we yet learned that code coming from $12/hr offshore developers is so sub-par that 1/2 of it has to be rewritten again, over here in the States? I guess not. You get what you pay for.