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:
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 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!
It 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!).
COBOL is absurd language
I 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!
The 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.
Strength and robustness!
I a bank or assurence company, why change a back office program that work for 20 years?
Cue obligatory Dilbert reference: http://www.funnyphotos.net.au/images/dilbert-cobol-programmer-dinosaur1.gif
I’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.
This 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.
Cobol 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…
“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.
The 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.
to 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.
We 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…
There’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.