I'd like to talk to you about ducts. Wait a minute. Strike that. I meant COBOL. The Common Business Oriented Language is celebrating its fiftieth anniversary as the language that is everywhere and nowhere at once:
As a result, today COBOL is everywhere, yet is largely unheard of among the millions of people who interact with it on a daily basis. Its reach is so pervasive that it is almost unthinkable that the average person could go a day without it. Whether using an ATM, stopping at traffic lights or purchasing a product online, the vast majority of us will use COBOL in one form or another as part of our daily existence.The statistics that surround COBOL attest to its huge influence upon the business world. There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world's actively used code. There are estimated to be over a million COBOL programmers in the world today. Most impressive perhaps, is that 200 times as many COBOL transactions take place each day than Google searches - a figure which puts the influence of Web 2.0 into stark perspective.
Every year, COBOL systems are responsible for transporting up to 72,000 shipping containers, caring for 60 million patients, processing 80% of point-of-sales transactions and connecting 500 million mobile phone users. COBOL manages our train timetables, air traffic control systems, holiday bookings and supermarket stock controls. And the list could go on.
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. That probably says more about my isolation as a programmer than anything else, but still. I find the whole situation a bit perplexing. If these 220 billion lines of COBOL code are truly running out there somewhere, where are all the COBOL programmers? 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?
If so, that's a mighty impressive feat.
And if COBOL is so pervasive, why is it number one in this list of dead (or dying) computer skills compiled in 2007?
Y2k was like a second gold rush for Cobol programmers who were seeing dwindling need for their skills. But six-and-a-half years later, there's no savior in sight for this fading language. At the same time, while there's little curriculum coverage anymore at universities teaching computer science, "when you talk to practitioners, they'll say there are applications in thousands of organizations that have to be maintained," says Heikki Topi, chair of computer information services at Bentley College in Waltham, Mass., and a member of the education board for the Association for Computing Machinery.
When you dig in and read about some of these real world COBOL systems, you can get a glimpse of the sort of difficulties they're facing.
Read says Columbia Insurance's policy management and claims processing software is 20 years old and has 1 million lines of COBOL code with some 3,000 modifications layered on over the years. "Despite everyone pronouncing Cobol dead for a couple of decades, it's still around," he says. "We continue to enhance the base system. It's still green-screen, if you can believe that."Read says getting younger workers to take on Cobol chores is a "real challenge, because that's not where technology is today." He simply tells them they must do some Cobol work, promising a switch to other things at the earliest opportunity.
Remember how the common language runtime of .NET promised rich support for a plethora of different languages -- but none of that ever mattered because everyone pretty much just uses C# anyway? Well, that CLR didn't go to waste, because it is possible to write code in COBOL.NET.
private void button1_Click(object sender, System.EventArgs e)
{
button1.Text = "Call COBOL";
}
That was C#, of course. Here's the COBOL.NET version of same:
METHOD-ID. button1_Click PRIVATE.
DATA DIVISION.
LINKAGE SECTION.
01 sender OBJECT REFERENCE CLASS-OBJECT.
01 e OBJECT REFERENCE CLASS-EVENTARGS.
PROCEDURE DIVISION USING BY VALUE sender e.
SET PROP-TEXT OF button1 TO "Call COBOL".
END METHOD button1_Click.
Is there anything I could write here that the above code doesn't make abundantly clear?
COBOL: so vibrantly alive, yet … so very, very dead.
COBOL is the one that making sure your money is safe at the bank. I know it's an ugly language, but no other language does better job. And that's a fact, Mam.
I Know on August 10, 2009 2:05 AMI learned ANSI C and COBOL in college. I went to work after graduation in 1995 for a telecom company. I was hired as a C programmer, but when I arrived at my new job they said "We see you have COBOL skills, we want you to work in COBOL instead of C." The billing system was on IBM mainframes and the Usage system (reading the switches) was on Tandems, both in COBOL, using DB2. I worked with hundreds of other COBOL programmers until 2002 when I was laid off when most of our work was outsourced to India. Many of us went to other types of work, a few are still working in COBOL. I trained to make the switch to C#.Net with SQL Server over a year ago, but getting a job without experience in it has been impossible (and my bachelor's degree is in Computer Information Systems.) WILL PROGRAM COBOL FOR FOOD!
Meg on August 10, 2009 2:48 AMIt is one of the great great ironies of our modern software industry that so many of the younger generation of programmers are so unaware of what technologies are actually really out there and working. Sure a lot of this modern "stuff" sounds great, but hell, it just doesn't work!
What good is a fancy, flashy interface if it just keeps eating the data? What good are dynamic languages if they are built on flaky foundations. If you can't trust the stability of the system, it would be madness to actually use it for something critical, won't it.
Over twenty years ago, when I got out of school, the big revolution was to get out there and re-write all of those legacy COBOL systems. That was the cool-aid that we all drank back then. But as is clear with the above facts, decades later and most of those systems are still humming along just fine, while their supposed "modern" replacements died inglorious deaths. And in many cases those "legacy" jobs supporting those systems have paid better than hacking at the modern stuff.
It's just another one of those cruel jokes in the software industry. We get all of these people running around, talking up the next wave of technology, telling us how great it is, how it will change everything. But ultimately, except for a few sample systems here and there, it ends as each new generation has bit the dust faster and more painfully than the last. We only seem to be getting better at building worst (but flashier) stuff. Sad, but true.
Paul.
Ha ha entertaining to read about COBOL and these ancient techniques. Myself has not working with something else besides webdevelopment. Besides in school I did some Windows Forms then it has been all Webdev.. Actually I would maybe do some other things besides web, maybe C++?? (Like Qt - that looks cool!).
YESS on August 10, 2009 3:12 AMCOBOL is absurd language
Sudeep on August 10, 2009 3:45 AMI had been in the first two years of my post-University career a COBOL programmer. To put that in context, I graduated 2001.
The software in question had been originally started in 1983 to fill a gap in the market. By the time I joined the company, there was about 10 modules and millions of lines of code. Of course given COBOL's verbosity, that would equate to about 5 lines of C#.
In general, the reason given for not moving to a more modern language was just the sheer scale of how long it would take to rewrite!
I also had the somewhat dubious pleasure of meeting several old COBOL programmers and the amount of brainrot that had set in from writing such a hideous language had reduced them to barely able to take any form of independant thought!
Fortunately I jumped into the small part of the company that was doing C# then after gaining enough skills that the COBOL was a little buried on my CV, I jumped ship!
Rach on August 10, 2009 3:45 AMThe problem IMHO is that in your "professional programming career," you have been working with high-tech companies. You want to see COBOL? Go look at a company that processes payroll, or handles trucking, food delivery, or shipping. Look at companies that handle book purchase orders or government disbursements or checking account reconciliation. There's a huge ecosystem of code out there that's truly invisible to those of us who work in and around the Internet; I have the (dis)advantage of having started in enterprise software; I wrote C code that generated COBOL! I was responsible for generating millions and millions of lines of COBOL for companies to move data from one place to another.
Here's another interesting fact: most of the data in the world that isn't text is in EBCDIC, and not ASCII or UTF-8. You and I today work almost exclusively with text or text-based (XML, JSON) data. But I'd be willing to bet that the code running on the computers that handle the shipment of our computers was written in COBOL.
Glen Campbell on August 10, 2009 4:04 AMStrength and robustness!
I a bank or assurence company, why change a back office program that work for 20 years?
Paul Pacheco on August 10, 2009 4:06 AMCue obligatory Dilbert reference: http://www.funnyphotos.net.au/images/dilbert-cobol-programmer-dinosaur1.gif
Miff on August 10, 2009 4:11 AMI'm working with COBOL right now. Actually, I'm reading this blog post while on a break from thousand of lines of COBOL code.
I'm not a COBOL programmer, I am just migrating some old COBOL programs to Oracle PL/SQL. And one of the reasons I accepted to work on this project is because I believe I'm somehow helping COBOL to die.
The reason COBOL is still alive, in my opinion, is because most developers are not brave enough to face this awful piece of crap in order to rewrite it in a better language. Having COBOL programmers purposely keeping it alive because it's the only language they know (and they don't want to learn another) also helps.
Anyway, I'm doing my part.
Rodrigo Sieiro on August 10, 2009 4:13 AMThis explains!
We are living (in the Internet) in some what an ideal world. We use latest technologies and cutting edge solution.
When I discovered the outside world, I found that they still use Microsoft Access, C++ (Ms-Dos) and very old technologies. Yet as you said they wrote hundred of thousands of lines of code that made tweaking the old better than moving to the new.
In my opinion, it's microsoft (or any other producer fault). If Microsoft support dot net for 20 years and developers build amazingly giant applications and then MS comes and says it wants to make the switch to a cutting edge solution and platform: This is really not a so smart solution.
As they do (by tweaking their old code) MS and other companies should do by tweaking their old platform rather than creating new ones.
Omar Abid on August 10, 2009 4:14 AMCobol writers are quite old and are not part of our world.
I had to work as a Cobol developer (I'm a Java specialist) for one year in my former company. I was something like 25 yo but most of my coworkers where over 40 and on the customer side, they were over 50.
All of them doing COBOL for 20 years, some of them don't know how to use a mouse and worked on VT-100 terminal (orange and black screen , one keyboard and that's all).
Cobol is still alive but it's death is closer than ever because people that knows it are going to be retired soon...
Humble.JoK on August 10, 2009 4:21 AM"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?"
No, absolutely not, but since COBOL programmers are so hard to find, companies instead hire teams of "new" developers to write screen scrapers and wrapper APIs for the old systems, hoping to fix bugs and circumvent quirks in the process.
If you can't maintain it, hide it...
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.
For the rest of us, those who (as sad as it is) know at least some COBOL, this number is not so impressive at all. As your own sample above shows, considering the fact that you may need 100 lines of COBOL to do the same thing that a modern language can do in 20, if you are lucky, maybe in 3(!!!) lines of code, somewhat puts the number into perspective.
Rewrite those 220 billion lines in a language that is not older than 20 years and the number will shrink so dramatically; it will shrink even without considering things like powerful standard APIs that would further reduce the number even more. And all of a sudden 80% of all code lines in the word are not even getting close to 5% any longer.
@Rach: Yes, rewriting all this code is a damn lot of work. It is so incredible much work, that I would question the concept of a rewrite and instead considering writing a translator. A translator that can take any piece of COBOL and translates it to ... I don't know, translating it to a high level language like Java or C# seems to make no sense to me. I would translate it to plain C. Basically you write a COBOL compiler, but not one that outputs machine code for the CPU but that outputs C source code. Such a translator can be written in a couple of months - definitely less time than rewriting all those COBOL lines! And once you have it done, it can translate billion lines of COBOL and it won't even take long for that (even if you are no compiler guru and your implementation of the compiler sucks, it can easily translate 1000 lines of COBOL to C within a second).
Of course this won't fix the main problem. The structure of COBOL code sucks and so will the structure of the C code. However, unlike COBOL there are million of C programmers out there that have no problem to slowly re-factor the C code more and more as they go over it to fix bugs, add features, etc.
Alternatively write a compiler that translates COBOL into Java Bytecode. Not only do you have immediately executable code that way that any JVM in the world can execute, there exists great Java Decompilers that can translate .class files back to .java files and the code is surprisingly good and readable. The only problem here is that the OO concept of Java is not compatible to COBOL IMHO and the output of decompilation will produce real Java code, however Java code that no Java programmer in the world had ever written that way.
Mecki on August 10, 2009 4:26 AMThe company I worked for had a mainframe as database vehicle. They'd quit working on documentation and more than the essential maintenance years before because the system was going to be replaced. Turned out that C++ on a bunch of PCs didn't gave the required performance.
Fast forward a few years, years in which the documentation was updated somewhat and the system had grown only bigger. The new silver bullet was .Net, with all the shininess of C# and SQL Server.
This was years ago, when .Net was in its beta stages. Migrating to a platform in its infancy is slightly braindead, doing so without essential trust in the capabilities is even worse.
You won't believe the trouble we ran into. But that wasn't the worst. The existing workforce had been chased away or was under training to work with the new architecture ("What's object orientation?"). Documentation was again no priority. Fairly dumb terminals (bottom grade PCs) had to be upgraded to something that carried at least XP, with all the organisational trouble that came with that. And when we finally produced a basic transactional system, it didn't perform, no matter which expert looked at it. Although we could write the code faster.
I went away, don't know the end of the story. It's very well possible that there was no return back to the mainframe anymore but maybe they threw enough fast hardware against it to make it work. I'm still wondering why anyone would bother to replace one vendor lock-in for the other (one of the main reasons for the transition) but that's not up to me.
Sure, COBOL's dead, just like the mainframe it ran on. More in the minds of the management than in reality though.
Caesar Tjalbo on August 10, 2009 4:30 AMto TJ : Please let me know where I can get one of those $150/hr jobs.
I've been a software developer for over 30 years. When I first got in the business, people made fun of COBOL and predicted its demise. Maybe it's finally happening, I don't know. The language I used during my career has been primarily COBOL. Over the years I've used many other languages, but most of them fell out of fashion and never replaced COBOL.
I was laid off from my last job in December, 2008. Prior to that I worked there for 16 years developing commercial software in COBOL.
The main reason COBOL was used was due to its portability. The software ran on mainframe environments like MVS, VSE, Z/OS, CICS, and IMS. It ran on Open VMS for VAX and Alpha. It ran on many flavors of UNIX. It ran on AS/400. It ran on Windows. Most of the code was shared between all the platforms; the same development teams supported all the plaftorms and there were usually less than 5 people per product.
Granted, the user interface looked like mainframe green screens, but people bought it for its batch processing capabilities, not for its looks.
The last 10 years I was there, several efforts were made to replace the use of COBOL with other languages. Now COBOL, Java, C#, C++, and mainly C are used there. My guess is that the C code will eventually kill off the COBOL.
I still have a few years left in me. If anyone needs a COBOL programmer, please let me know.
Herb J in Kemp on August 10, 2009 4:30 AMWe have as many COBOL programmers at our company as Java developers maintaining the legacy systems. The programmers are typically non-Computer Science graduates who are taught COBOL in house, and are actually often quite youthful. I guess the advantages to employing non CS grads is that they have no frame for comparison...
Ant on August 10, 2009 4:36 AMThere's a simple rule of thumb you can use to know where COBOL is used or not. If the organization in question existed 30 years ago and, at that time, had money enough to use computers, then it most likely used, and still uses, COBOL. If not, then it most likely doesn't use and has never used COBOL.
Actually more like:
method-id. "button1_Click" final private.
procedure division using by value sender as object
e as type "System.EventArgs".
set button1::"Text" to "Call COBOL"
end method "button1_Click".
including a bit of white space to look pretty. It's a good idea to make your comments based on knowledge rather than outdated hearsay.
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. That's not to say we don't know c#, VB or any other number of languages. That's also not to say there aren't dinasaurs in the COBOL world ... I've met quitea few ... I've also met quite a few in the VB and Java world as well.
Burgun on August 10, 2009 4:49 AMWhat a bunch of crap. Not what you write Jeff, but the COBOL "article" you reference.
First of all, the author of the article is one Stephen Kelly, who seems to be the owner or is otherwise affiliated with Micro Focus World, a dis-functional website (http://www.microfocusworld.com/) with a business focus. Micro Focus is a sponsor (the only one?) of http://www.cobolportal.com/ which as you can get by it's name is all about COBOL. Gasp, cue conspiracy theory...
So of course such a person would spout all kinds of "facts" about how prevalent COBOL is and how it is still important.
As for the facts themselves...
"There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world's actively used code." - bunch of crap figures regurgitated from a 2003 (!!) PDF linked to from the Wikipedia article on COBOL (citation #5). That PDF was published by LegacyJ, a -- you guessed it -- software firm specializing in COBOL solutions. Gasp again!
Not only that, the LegacyJ PDF lists a 1997(!!!) Gartner study as the source of these figures - but fails to provide a reference. Was there really a Gartner study back in 1997 which gave those numbers? How did Gartner collect them? what does "actively used code" even mean?! Are these numbers as relevant now, 12 years later?!
"There are estimated to be over a million COBOL programmers in the world today." - yes, estimated by COBOL software houses eager to sell you their solutions and to calm your likely fears of being stuck with a language but without any programmers...
Pop question - how many questions in StackOverflow are currently tagged COBOL? It's 61 of this writing. Compare to 17k questions tagged Java, just for example...
I could go on but you get the idea. COBOL is out there, it is used. But I seriously doubt any claims making it to be the "dark matter of programming languages". It it were so prevalent we would know.
Now if you really want to talk about a prevalent but no longer sexy language, there's... C. Simple old C, no longer sexy enough for most people... yet so much code is still written in C, including the little OS that could, Linux...
Solidstate on August 10, 2009 4:50 AMCobol code lines == Zombies
Steve Schnepp on August 10, 2009 4:55 AMHonestly, those numbers are made up on the spot. How on earth can anyone make any guess about how many lines of code any programming language has?
Herman on August 10, 2009 4:56 AMCOBOL is still in use this is a fact! As mentionned COBOL programs still doing business! Companies maintain COBOL applications because it will be too expensive to rewrite them. Moreover lot of companies have based their core system on COBOL applications. So rewriting COBOL applications would be a business risk too high .
BUT, we have to pay attention that this does not mean COBOL programs are still under control. Several generations of developpers have coded those applications. COBOL applications knowledge has often gone away following the developpers. Consequences are: code duplication, fear to modify working, regressions... To ensure the ability of our COBOL programs to evolve we have to control them again. That is to say to instantly measure impacts of a code modification.
Newer language (Java, .NET, PHP, C) used XUnit framework to write unit tests (JUnit, NUnit, PHPUnit, CUnit). RPG has its unit test framework too: RPGUnit. The first need is to have a simple tool to write and automate unit tests on new code or on legacy code (to ensure no regression when delivering a code change or ensure capability of COBOL prgrams to interact with recent programs written in new generation language).
COBOLUnit (http://cobolunit.org) is a simple open source Unit testing framework to write and run repeatable tests in COBOL. It is an instance of the XUnit architecture for unit testing frameworks.
This framework is a way to modernize our existing application and made them more agile!
COBOLUnit is young and needs you to evolve. Have a look on COBOLUnit (http://cobolunit.org) and send your feedback to the COBOLUnit community (or join it) to make this initiative fit your needs.
At the moment i'm involved in a project to replace old Cobol software with a brand new Java-based one. The old software is absolutely critical and rather big so it was a tough decision to rewrite it. They probably wouldn't have done it at all, but they wanted certain features which Cobol simply couldn't implement.
The numbers are probably exaggerated, but a lot of Cobol is still out there up and running. The smaller and less critical software has already been replaced, but some big and important ones remain because they are so expensive and important.
cobolotym on August 10, 2009 5:05 AMWow... that is new COBOL with functions it looks like. I was taught old COBOL86. No functions for me.
"It it were so prevalent we would know."
@Solidstate: That is the point, you would if you were told about it, but most people are not, so you don't. As a programmer these days, the smart money is in COBOL because it is a niche, you could charge pretty much whatever you want as a consultant and they would pay because they would have very few other choices ;).
SeanJA on August 10, 2009 5:08 AMHonestly.
Why do you FEAR COBOL?
...please, no "cute" answers.
I have never programmed in Cobol, but I learned some concepts and, although I did not like it, its simplicity and effectiveness is certainly something that keeps it alive. Since the language and the tools are fairly crude, your brain has to work for a living. You have to *know* how to compile programs out of object files. And, you have to understand your business problem inside out or you will not get anywhere otherwise.
Compare that crude simplicity with modern languages which pamper us with development tools, complexity, GUI... software development has *worsened* as the tools have improved. When I say "worsened", I am saying that there are more failed project (on a big scale) than ever before - despite the "body of knowledge" and "improved" tools.
Aside from its simplicity, Cobol offers a standard for everything in the pipeline, from user interface (green screen) to database (VSAM).
All our methodologies are designed to deal not only with complexity but also with ineffective development tools, ineffective build tools, shitty environment (service pack on top of another service pack), memory hogging, garbage collections which don't work as they should half of the time...
The school of simplicity was burried under OOP school of complexity. Niklaus Wirth developed an Oberon system (which was OOP all the way) which also provided end-to-end software environment (development and runtime) and worked beautifully. I am not saying that Oberon was perfect but it solve some of the burning issues that arise from complexity.
Unfortunately, the industry embraced piece of garbage called VB, dll hell, Windowses and the rest is history.
securityhorror on August 10, 2009 5:20 AMWow, Cobol86! when I went to UNB in 97 they were still using Cobol72. It was hard to take a course seriously when the compiler was older then 99% of the class. I didn't mind COBOL all that much except for all the typing, I sucked (and still do) suck at typing.
Steven Howes on August 10, 2009 5:26 AMMy first job as a programmer was doing COBOL development. This was a little over a year ago. The company I worked for not only did maintanence of old COBOL programs, which, granted, was the bulk of the work, but they were also doing new applications in COBOL. Right before I left, the company was gearing up to create a new web app in COBOL. Before then, I didn't even know you could do that sort of work in COBOL, but lo and behold, you can.
The reasoning behind using COBOL was that COBOL was more readable than any other language. I would tend to agree that COBOL is easier to comprehend in smaller programs to non-programmers (it was, in fact, created to be understandable to managers), but when any sort of complexity is introduced, the sheer verbosity of COBOL causes programs to become convoluted messes that take a large amount of time to figure out what's going on.
The major problem with using COBOL as a starting point (most new-hires cut their teeth with COBOL before being allowed to go on to anything else, if they ever were) was the carry over of COBOL techniques to more modern languages. The PHP and ASP apps tended to be utter messes. There were a few notable exceptions to this, but, for the most part, The COBOL mentality dominated.
Besides just using COBOL, we were also using an antiquated version of COBOL (COBOL86, I believe) on an antiquated system (MPE/iX). There were many times where the copyright date on the software I was using was before my year of birth. One was even around 10 years before I was born.
Is this the norm? I highly doubt it, but don't be so quick to believe that COBOL is gone. It may be dying, but it's going to die a very, very slow death. There are (shockingly) some people in the world who actually find COBOL to be a very good language, and will continue to use it, regardless of developments in language design.
Andrew on August 10, 2009 5:26 AMI think you should take the site you quoted with a grain of salt though.
It lists C as the #6 dying technology. Clearly, that's not true if you walk into anywhere that does embedded, systems, or a number of other different kinds of work.
Sam Kerr on August 10, 2009 5:32 AMI keep hearing about how COBOL programmers are in demand still, yet I never see jobs advertised for it. You'd think if it was so in demand that they'd be looking for people! COBOL is not my preferred language, but I have no problem with it. Problem is that so much "COBOL" is actually CICS... They DO still teach COBOL in school, but nobody knows CICS, so there's a significant amount of learning that needs to happen for new COBOL programmers before they can actually get any work done.
Also, you're right, there's a huge disconnect between the "Internet world" and the rest of the programming world. There's a huge portion of programmers that don't do web, don't use the web other than e-mail, etc. The things that they're working on just don't intersect with the Internet world. A few of us try to live in both worlds. :-)
Brian Knoblauch on August 10, 2009 5:33 AMYou need to ask Joel to emit COBOL from Wasabi, and he could make billions :)
Dave Markle on August 10, 2009 5:39 AMOne of those big investment banks which just failed had a core trading platform written in Cobol on an AS/400 with a back end DB/2. They had scores of Cobol programmers maintaining it.
They had a C# front end I worked on which could only access the database by sending socket messages to Cobol jobs. Of course these jobs were actively being developed as well, in many cases by people in different offices, which made debugging and development something of a challenge to say the least. You could go for hours unable to even start the C# app up, because some crucial job was shut down ("in message wait").
They had also contrived to bring the lack of productivity you expect from green screen Cobol development to the .NET world.
Most of the screens were so complex they were incapable of being loaded into the screen designer, so adding a control meant spelunking through the .designer.cs file and adding it (and figuring out location co-ordinates) by hand.
And by underpinning the whole with a very large and creaky market data engine written in C++ they removed the ability to use the Visual Studio debugger. If you stopped in the debugger at any point the market data engine killed your process!
There were enough WTFs there to write a book.
Ex Bear on August 10, 2009 5:39 AMPutting aside the "my computer language is bigger than yours" statistics, it's interesting that computer language communities are so isolated from each other. Is it just because of historical happenstance, or is there some not-well-understood advantage in staying out of the "mainstream"?
MattF on August 10, 2009 5:40 AMTHIS: http://media-tech.blogspot.com/2009/06/naca-presented-jazoon-2009.html
... is great. That company migrated all their Cobol codebase to Java by writing their own conversion tool. You have to read all the papers, because it's a very cool way of doing it.
Basically, unlike what you'd expect from existing language converters, the converted code is maintainable, and there is no need for any manual intervention after it's done.
They fine-tuned the system until it was perfect, continuing in the mean time on working on the Cobol code (because you always need some amount of change to keep your business going!) and when it was, they converted and migrated over to the java version, working on that from then on.
They released their tool as F/OSS so that others could benefit from it.
Very, very cool.
"`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."
The other day there was a presentation in school by a former student and also friend of mine. She is working for New York Life, an insurance company, and guess what tool she is using everyday to write programs? You said it: Cobol (and also Assembly!).
Cezar on August 10, 2009 5:47 AMCOBOL is trivial enough to be generated/converted to be abstracted. Could this be a solution ?
Laurent on August 10, 2009 5:52 AMCOBOL is trivial enough to be generated, converted.. Well, to be "abstracted" somehow. Could it be a part of a solution ?
Laurent on August 10, 2009 5:53 AMWhy is COBOL around? There are a lot of reasons but I can certainly give you one glaring example. IBM mainframes and DEC VAXes and Alphas don't have "Blue Screens of Death". They measure their uptimes in *YEARS*. In my previous incarnations as a Cobol programmer on DEC (VMS) hardware, I can count the layers between source code and the CPU on one hand. You can't do that on Windows or with Apple. You could be running an ASP.NET application with Java going through a browser built on several layers of OS andp-code translators before you actually make it to the CPU. All those opportunities for failure.
Don't get me wrong, I'm in the .NET world now becuase there weren't enough "legacy" jobs as of 5 years ago. If you learned top-down modularization and object-orientation, your programming skills still translate in the "brave new world".
David on August 10, 2009 5:55 AM"I have never, in my entire so-called "professional" programming career, met anyone who was actively writing COBOL code."
You would if you've ever worked for a bank, an insurance company, or anywhere in India.
Brian on August 10, 2009 5:58 AMThe 3 COBOL programmers I know are half dead, but COBOL itself remains unendingly alive.
There's something delightfully perverse about installing a build environment for a 50 year old language on a brand-spanking-shiny-new Sun T5220. I recommend it.
ilikejam on August 10, 2009 6:01 AMMy first job after graduation(2000) was also on COBOL - for giant US based insurance company and they are still using COBOL. I did write tons of code to produce very little output.
Rashmi on August 10, 2009 6:08 AMAs an ex-COBOL programmer,
Anonymous on August 10, 2009 6:23 AMIf you've only really programmed on *nix and Windows, there's a good chance you haven't come across COBOL.
But if you cross into the mainframe world, it's everywhere.
Billing systems, printing systems, accounting systems. My brushing up against it has been in the telecom and printing world-- so there are a lot others on this list but I haven't had as much direct experience with them.
Most of the credit card billing, landline telephones (and, where they've integrated, cell phones), and I suspect bank software is still on COBOL.
So every time you make a call from the phone on your wall, many of the cell phones, purchase something with a credit card-- chances are high that there are one or more COBOL queries going on behind the scene.
It is a verbose language; it largely reads like English. I don't know whether that made code written in COBOL less buggy when originally written but I do know that most of what is out there was debugged in the 70s and so while it may not be perfect, it's at a place where it pretty much just runs.
I think that most of the jobs in COBOL are internal; and they tend not always to be viewed as "programmers" but rather "MIS" staff.
The people maintaining the code probably weren't hired as programmers or even as something called IT but rather as people to handle the tape drives on the mainframes and then they progressed from there. At least that's what I saw at the customers I dealt with.
davesnyd on August 10, 2009 6:23 AMI programmed in Cobol for years then moved to .net, then got a job in Peoplesoft which had an overnight job that ran forever and guess what it was in cobol and I was back there again. What is funny about cobol is that it had convention over configuration to an extent. You had a Data division that you had to declare a certain way, even making sure that the correct data was in the correct column in the source file. The thing about it that people forget is that the B is for Business and for Business apps, nothing could be simplier. It only has a hand full of data types. Where the modern cobol has gone wrong is where I feel c# is going wrong. It tried to be all things to all people, object oriented cobol never worked. C# is now going to be dynamic I hear, why. There are dynamic languages already. Do I write cobol today ? no way ? Would I if cobol was as easy as it was with green screens and people did not try add every feature that java, c# and c++ have, in a heart beat it was so easy back then.
steve on August 10, 2009 6:28 AMYou don't hear about COBOL because COBOL programmers don't hear about you. Seriously, I used to program COBOL and at 30 years old, I was the by far the youngest programmer. Everyone had PCs, but they were basically dumb terminals. Right now the industry is desperate for a good migration strategy away from COBOL (this is a huge cash cow waiting to be milked), but the solutions I've investigated in the past have been awful.
It's also worth noting that I would sometimes fix software which was written in the 60s. Very little spaghetti code you see today will compare with the horror of much of that code, but the thing is, that code *works*. The only thing which will fix this problem is when the availability of COBOL programmers is so short that their salaries skyrocket to unmaintainable levels. Even then, companies will wrap the software rather than rewrite. Also, many of those old COBOL programs have been compiled and the source code is not available, making a rewrite significantly harder.
Ovid on August 10, 2009 6:29 AMI am one of the not so rare bread of COBOL programmers, or at least have been until last year. A large pension insurance in Switzerland has a 30 year old COBOL program, both heavily batch oriented as well as CICS (some sort of transaction processing environment for online programs).
The company started 5! attempts within the last 10 years, usually staffed with 80-120 programmers, to replace the system in ORACLE Forms, Java, JEE, C#. All failed, each costing many millions.
The programmers that keep the system alive, implementing law changes on a yearly basis, has an average age of maybe 55, with many being retired and working on part time.
The hardware the systems run on have been discontinued for the last 5 years, the hardware company went bankrupt, but there still are some other machines retired and then bought up as spare parts. Next a port to UNIX midrange is planned, with a virtual OS and CICS emulating the host environment.
Huge problems. But then, many are facing the same problems and go out of their way to solve these,as it is less expensive short term then starting the 6th attempt of a rewrite.
Ralph Rickenbach on August 10, 2009 6:31 AMReferencing a Computerworld article on programming is a lot like referencing the National Enquirer in your term paper.
Sure- you can do it, just don't expect people to take your point seriously.
Matt Osbun on August 10, 2009 6:32 AM"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (Edsgar Dijkstra)
I forgot where the quote comes from, but I have come across it several times.
AF on August 10, 2009 6:32 AMI'm under the impression you haven't been involved in the enterprise development biz that much? That is, ERPs and whatnot?
I started my career developing systems for the logistics business, and in my "first real job", my team of around 10 people had one full-time COBOL programmer and two part-time. And this was in 2005.
More recently: last year, I was consulting a press/publishing company and they had a full-time COBOL coder working for them.
So they're still out there.
On the other hand, COBOL systems have been kicking about for so long that they've pretty much got the boiler-plate stuff fixed so the maintenance focuses on keeping the business logic side up-to-date.
Timo Saikkonen on August 10, 2009 6:33 AM"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (Edsgar Dijkstra)
I forgot where the quote comes from, but I have come across it several times.
AF on August 10, 2009 6:33 AM@Brian:
> I keep hearing about how COBOL programmers are in demand still, yet
> I never see jobs advertised for it. You'd think if it was so in
> demand that they'd be looking for people!
Job-offers are done by obituary notices
Regards, Lothar
220,000,000,000 LOC / 1,000,000 programmers = 220,000 LOC/programmer. Hmmm.
David A. Lessnau on August 10, 2009 6:39 AMCome on Jeff, If you are going to play shenanigans and include a event handler in COBOL at least include a routine to store data in hierarchical DB.
Sure, COBOL is older than dirt, but it is *STILL* up. It's like a pathological cockroach that just wont die. The uptime on our mainframe is currently over 8 years. Since the day we moved to a new data center. It was 15 years before that.
And just because I have never met a *REAL* VB or assembler programmer doesn't mean they dont exist.
Tristan on August 10, 2009 6:47 AMI once applied for a job as senior programmer for the Ministry of Public Service in charge of teacher payrolls, i found they programmed in COBOL so i ripped a site and made a cobol manual using which i learned COBOL. when the senior (in the true sense of the word) programmers heard i had learned COBOl in a week, i was sent to work in records. I quit after a month. I love COBOL. It was the easiest language i have ever learned in the shortest time too. i never saw COBOL.Net or the promised object oriented cobol or even relational db in cobol. i feel short changed!!
oh and the microfocus IDE costs an BOMB!!
jake on August 10, 2009 6:47 AMCOBOL was my first commercial project. Like, first ever. Including these "you're good at computers, can you fix this little problem I have with my work PC?" type of jobs which barely count as commercial.
I was 14, knew a good deal of BASIC, and... well... nothing else, actually. A new law required my father's inventory software to be changed slightly, but no one knew how to. With the confidence of a pubescent kid, I stepped in -- and made it.
The concept of "GOTO 1200-1299" (right, not a single line number, a range of lines) grossed me out, however. I promised to never touch COBOL again, and the promise still holds :)
Regarding the article, it was the only COBOL software I ever saw. But I am willing to believe many of these facts. If some software has been working for 20+ years, where's the incentive to switch? Whole companies went out of business because of ignoring the old wisdom of "don't fix what ain't broken".
I have been rewriting (less critial) systems from scratch, and it takes years to flesh out all the little details that are invisibly buried below the obvious functionality.
Moe on August 10, 2009 6:52 AMI still have a large number of COBOL listings, i haven't thrown them out because there's something gratifying about looking at the reams of alternating color print paper.
Michael on August 10, 2009 6:57 AM@Sudeep: I've got COBOL code thats probably older than you, still running, still earning a very large financial institution LOTS OF MONEY and its relatively maintenance free. Whats absurd is all of this new stuff that comes and goes while COBOL's "death" keeps coming up and going away just as fast. Take for instance, agile. Another FAIL.
To the rest of you knocking COBOL, you're just jealous that you dont earn $150/hr writing and maintaining mainframe systems and are considering retiring before 50.
TJ on August 10, 2009 7:00 AMI'm a Java programmer and I had to work with a team that had COBOL programmers interfacing with our software. We were working on a system that had to interface with an insurance company's existing systems. They didn't have an XML parser because IBM hadn't released a non-beta COBOL XML parser for that platform, so they parsed XML by hand (improperly, I might add). It was... interesting.
But certainly there are lots of COBOL systems out there. I suspect many of these systems are being extended through non-COBOL means where possible. But then again, I have a friend who worked for a bank where they weren't allowed to use C; they had to write code in assembler. You read that right. And this was in 2003.
Mr. Shiny New on August 10, 2009 7:06 AM"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.
Reed Hedges on August 10, 2009 7:11 AMI 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.
Joe M on August 10, 2009 7:17 AMThe 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.)
Not a bad post, but remember that total cost and total revenues are not the same as marginal cost and marginal revenues.
Sam Schutte on August 10, 2009 7:22 AMI 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.
PS: regarding the COBOL to automatic translation, it's not so easy. Not because of lack of local variables in functions (which a modern compiler will figure out), but because it has a very particular "call" semantics (aka "perform" statement) that can cross "procedure" boundaries (ex: "perform a thru d" where each from a to d are different named chunks of code).
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 :-).
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.
Jeremy on August 10, 2009 7:27 AMWhat'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.
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.
Matthew S on August 10, 2009 7:41 AMWhen 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.
this mat on August 10, 2009 7:41 AMWe 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. ;-)
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.
Dave C. on August 10, 2009 7:51 AMI 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.
Gunther on August 10, 2009 7:54 AMWe 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.
Robert S. Robbins on August 10, 2009 7:55 AMAs 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!
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.
Chess on August 10, 2009 8:09 AM"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?
Jess Sightler on August 10, 2009 8:12 AMI 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.
Mike Woodhouse on August 10, 2009 8:17 AMAt my company we upgraded to a popular Accounting/ERP system last year. Its written in COBOL.
John on August 10, 2009 8:25 AMI 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.
tim on August 10, 2009 8:30 AM@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.
TJ on August 10, 2009 8:30 AMI 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.
Cordell Bowers on August 10, 2009 8:37 AMi 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
Michael on August 10, 2009 8:40 AMThere 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.
Lee Dumond on August 10, 2009 8:41 AMIn 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.
Karthik on August 10, 2009 8:44 AMLast 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.
Chicago Man on August 10, 2009 8:46 AMJeff: 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.
DevMan on August 10, 2009 8:53 AM> 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.
Mario on August 10, 2009 8:56 AMI'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.
Schnapple on August 10, 2009 9:01 AMWhat 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.
Lennaert on August 10, 2009 9:05 AMThe 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.
Jim Blizard on August 10, 2009 9:06 AMI 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.
pete on August 10, 2009 9:06 AMsorry there not their
pete on August 10, 2009 9:07 AMThe 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.
Jim Blizard on August 10, 2009 9:08 AM>>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.
Neil (SM) on August 10, 2009 9:24 AMWhere would you like to meet, Jeff?
Cory A. on August 10, 2009 9:25 AMPart 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.
will on August 10, 2009 9:46 AMI 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.
Josh Volchko on August 10, 2009 9:50 AMHave 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.
Skyler Jermyn on August 10, 2009 9:50 AMI 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.
Kris on August 10, 2009 9:54 AMI bought a book on COBOL 2002 and I couldn't understand shit of it.
Tiago on August 10, 2009 9:57 AMThe comments to this entry are closed.
| Content (c) 2012 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |