Software Development

Celebrating COBOL's 50th birthday

Justin James honors COBOL's 50th birthday with a brief overview of the language's history and an endorsement of why it's still a valuable skill.

 

COBOL celebrated its 50th birthday on September 18, 2009. Many developers see COBOL as a relic, a dying dinosaur, or a stodgy language that has been superseded by more powerful systems. I believe that viewpoint as being uninformed. In honor of COBOL's 50th birthday, here's an overview of COBOL's history and place in the current development landscape.

COBOL's origins

COBOL was designed by the late, great Grace Hopper. Ms. Hopper had an extraordinary influence on the computing industry, including writing the first compiler, the "A compiler." In addition, she served in the U.S. Navy, eventually attaining the impressive rank of rear admiral; there is even a U.S. Navy destroyer named after her in honor of her service.

COBOL was designed by committee, including representatives from the three government agencies and six major companies. The initial seed was planted in April 1959. On September 18, 1959, the committee picked "COBOL" for the name, and by the end of 1960, COBOL compilers had been completed and working programs had been made. (Thanks to Wikipedia for information about COBOL's history.)

COBOL is an interesting language. Originally, it did not have many of the features that we have come to rely upon. For instance, you would not expect to find object oriented capabilities in 1959, but there were not even local variables then. The structure of a COBOL program is also different from what you would expect, being divided into different "divisions," each of which serving a particular purpose. COBOL is best known for batch processing, in which large amounts of data are fed in and acted upon on a regular basis. In recent years, COBOL has undergone many changes and adapted to the needs of modern programmers, including adding object-oriented programming capabilities.

COBOL applications run the world

The average person deals with a COBOL-powered system 13 times a day. ATMs, inventory systems, airline ticketing, and health insurance all run on COBOL.

COBOL has been ported to numerous platforms, and currently runs on everything from traditional mainframes to Windows PCs on the .NET Framework. Forrester Research analyst Mike Gilpin says, "32% of enterprises say they still use COBOL for development or maintenance." That is remarkable penetration for a language that has been around so long and that has been supposedly "superseded."

In fact, I recommend COBOL as a job skill for developers looking for a long-term, stable career. The simple truth is the COBOL applications out there cannot be replaced. It is an impossible task in reality. In and of itself, this would not necessarily mean a strong job market. But for a variety of reasons, fewer and fewer colleges are giving their students exposure to COBOL, and new programmers have a negative perception of it and avoid it, meaning that the pool of new programmers is quite small. To make matters worse, the COBOL workforce is aging rapidly, and these developers are transitioning to management, retiring, and dying faster than they can be replaced. Meanwhile, new developers on these projects can take years to become fully acquainted with what it takes to maintain a million line application. This all adds up to a great environment for someone looking for a steady job over the years to come.

Micro Focus has put together an amusing video about COBOL's start (well, it's amusing if you're a geek -- I'm sure my wife wouldn't enjoy it). Visit the COBOL @ 50 site to celebrate this milestone.

Related TechRepublic resources

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides. He is also under contract to OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and other articles.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

70 comments
e-list
e-list

ex-COBOL programmer. I don't see any reason for young people to study COBOL when there are so many out-of-work ex-COBOL programmers who can't find work. It doesn't sound like a very promising career. I haven't seen a whole lot of job postings for COBOL programmers on job websites.

jwlindsey
jwlindsey

I took several computer programming classes in college in 1960 which launched my computer career. This was before there was such a thing as a "computer science" curriculum. In one class the professor wanted to show us the differences between and limitations of various languages. He assigned a project where we wrote a simple "scientific" application in COBOL (COmmon Business Oriented Language) and a business application in Fortran (FORmula TRANslator). What an eye opener!

dpresley_50201
dpresley_50201

Des Moines, being one of the centers of the insurance industry, will always have a market for COBOL development skills. The local community college stills teaches COBOL classes. Even so, my wife, a programmer/analyst for a local hospital, regards COBOL as her least favorite programming language. Its rules and restrictions are too limiting for her.

pfbenapfl
pfbenapfl

I have never seen a computer 'language' describe its data as beautifully as COBOL can. And that includes XML.

john3347
john3347

Did I miss it, or was there nowhere in this article the words "COmmon Business Oriented Language"? Many who have less than 50 years experience in the computer field may not know what COBOL means.

jslarochelle
jslarochelle

When I went back to school to study CS I had high grades in all topics except COBOL. I just did not like the language. In fact I suspect that the teacher tripped my note for this one so that I did not affect my graduation schedule. A question of taste I guess since some very respected people think that COBOL is a good language (Glass among others).

ogregator
ogregator

You know, if Monash had started out teaching everyone COBOL as opposed to kicking us off on C++, there would've been lot lesss drop out. As a language, it was a beautiful thing. Simplistic yet powerful. It was something you learn at home with a cut down version and didn't require you to do a course that may cost you $10k. Tempted to dig out my old build of COBOL now. K

Teufelhund
Teufelhund

I cut my teeth on COBOL back in the 80s. I actually had the opportunity to speak with Rear Admiral Hopper. She spoke at a symposium in my home town and I briefly spoke with her afterward. As I recall, I expressed my belief that COBOL was a language that was easily learned and used. She said that if she had it to do over again, she would do it a lot differently. Learn, evolve, grow.

herlizness
herlizness

SO? Is there an open-source COBOL compiler to be found? It might be fun to write a few hundred lines with all the free time I have ...

Stan.Williams
Stan.Williams

In all fairness, if you are my age (50 something) and you've been in this career path for any length of time it's almost a guarantee you've programmed in COBOL and BASIC. I was told over 20 yrs ago COBOL would be obsolete and forgotten in 10 yrs or less. Yeah, right. Now I can't even fathom a world where a couple of languages is considered a "broad depth of knowledge". As much as COBOL had it's good/bad moments I think it's absurd to replace frameworks every couple of years.

chris
chris

I worked at Southwest Missouri State University several years back. One of the professors verbally stated that women shouldn't be programming. And he taught COBOL.

Justin James
Justin James

How has COBOL affected your life? Spent time working on COBOL applications, supporting them, or adminstrating mainframes? Learned it in school? Any fond (or not so fond) memories? J.Ja

mattohare
mattohare

They don't want to look dead end. Maybe things are different there in Seattle, Afganistan?

ogregator
ogregator

I agree, from a career perspective it's a dead fish. There are COBOL jobs out there but it's like trying to find work as a system analyst. Job title's changed and there's more than COBOL involved. It's still required though in the sense that COBOL is a perfect platform for beginners programming (I feel at least). Why I feel it's a great beginner's tool: 1) It's free and you don't need a particularly powerful box for it. 2) It's highly structured, which is important when your starting out at anything. 3) You're not reliant on the mouse, it's mainly keyboard based and so you're not breaking out of your mindset when your doing your thing 4) It's relatively easy to troubleshoot a problem 5) Unlike C++ or other platforms, it's relatively close to English Of course the brains out there could poke holes in all my arguments (I'm doing it right not) but I hope I get the main idea out there as to why COBOL should hang around.

Justin James
Justin James

A friend of mine just got lured out of retirement AND relocated 400 miles to work on a 10 year contract. From everything I can tell, the COBOL job market does NOT operate like the Java/.NET job market, and you WON'T see those jobs advertised. That's my belief, based on a small handful of anecdotes, so take it as you will. In fact, even in the .NET world, the jobs you see advertised... well, by the time they get advertised, it means that most of the people "in the network" have already passed on it. My suggestion to you is to try as hard as you can to get "in the network". Find out where the COBOL folks in your area spend time... professional associations, a bar next to a major bank in town, anything, whatever it takes. Get "in the network". Find some sites that a lot of those folks post on, start showing off your expertise (in an appropriate way, of course), like answering questions. I also beleive that the companies who hire COBOL programmers tend to post jobs to their own job board first, and may even still post ads in the paper. I learned a while ago, that if you want to work for a company like IBM, Microsoft, or another big company, they don't post to Mosnter, Dice, etc., they maintain their own job ads and you need to go to their site to apply. I know this holds doubly true for the more traditional Fortune 500 companies that are the big COBOL shops. Hope this helps! J.Ja

fgalan
fgalan

COBOL was the second programming language I learned, just after FROTRAN IV, in 1982 I wrote "Computer languages: A comparative study" to obtain my engineer degree, in those years COBOL was the jewel of the crown, Pascal and C were just some brute jewels, not even thinking about c++. After 27 year I still think COBOL is the clearer and simpliest tool to describe data (and even proceess), today I use C##, java, .Net, Ajax, XML, SQL..., but I keep writing a kind of DATA DIVISION to describe data layouts to make my team of developers to understand what it's nedeed. Just for the good old days, some midnigths, I still write a few COBOL lines to make me feel alive...

Justin James
Justin James

You are right, I forgot that small but important item. Whoops! J.Ja

Ole88
Ole88

There are a few open source initiatives out there. You can check out cobol-it.com and opencobol.org. I started looking around for one myself and MicroFocus even has NET Express Personal Edition that you can use for just that purpose. You can get that one at http://www.microfocus.com/Resources/Communities/Academic/. Just scroll down and you will see a link labeled "individual/professional."

philr
philr

I came to COBOL late having done real-time assembler stuff on minis. COBOL and KDF9 Usercode were the easiest languages I have ever used. Some COBOL programs almost worked first time using Jackson Structured Programming. However, one COBOL program I had to modify was so complicated I get nightmares about it, and I have kept an annotated listing of it just-in-case! That was 20 years ago. As always "write as you would be written unto" applies even in COBOL.

njoy_d_ride
njoy_d_ride

OK, this prof had an opinion. I disagree with it. I bet Grace Hopper would too.

LadyReader
LadyReader

I am a woman and I have been programming since 1979, first as a student and then as a professional software developer. I have been pretty successful, especially since my time was divided between programming and running a household as a divorced mother. I spent 15 years coding COBOL. Those years, especially the first few, had their high points, but when I found a position outside the mainframe world, I was happy to leave COBOL behind for a 4GL and then .Net.

Sterling chip Camden
Sterling chip Camden

I was a COBOL programmer for a few years, and then went to DIBOL. DIBOL was partially based on COBOL (similar data structuring syntax), and went on to become the basis for Synergy/DE. So COBOL is in my roots -- though I try to keep it from showing.

norbyf1
norbyf1

I had the great pleasure of working with Dr. Hopper in the '60s when she was at Univac. I was working for another division of the then Sperry Rand Corporation (now Unisys) and was modifying the COBOL syntax and code generators for a military application - yes, kiddies, COBOL was used for military apps - there wasn't always a C++. She was a wonderful person and a delight to work with. Not only did we share martinis together, we also shared a cigar!!

johnh
johnh

I was working as a corporate accountant in the late 1980's when I took what seemed to be a good opportunity to work for a software company. The software, written in ICOBOL (I=Interactive), was an accounting package designed for advertising agencies. My job was installation, support and training. I stayed with this company 13 years and although I never programmed a line of code in COBOL, it greatly increased my interest in programming. Several years later after programming in several languages, I find myself loving the opportunity to write and modify programs more and more each day.

silvergrrl
silvergrrl

I started working as a COBOL programmer in 1979 - coding sheets, keypunch, card decks, & all. ISPF revolutionized our lives! The IBM mainframe world has been very, very good to me. And continues to be, even though I hardly ever code anymore. I still review the code others write, and do research to figure out how things work. There is lots of business intelligence in those old systems. I agree with what others have said - COBOL isn't going anywhere. We use a COBOL generator at the shop where I work, but even with that if you want to see the full compiled module with copybooks, etc, you will be looking at COBOL. So you still have to be able to read it. We train our own programmers since (as others have mentioned) young people don't get it in school. So happy birthday, COBOL, and thanks for a rewarding career.

rich_old_comcast@yahoo.
rich_old_comcast@yahoo.

I have either coded or looked at a Cobol program every month for almost 30 years. It has been fun and kept me employed :)

jamurray
jamurray

I wrote my first lines of COBOL code in April of 1969 as a team of 15 newly trained programmers who had been given the task of coverting massive insurance applications from the IBM 360 to the Control Data 3300. Over the next 27 years COBOL provided for me and my family as I churned out code on CDC, IBM, Honeywell, Burroughs and RCA mainframe and mid-range systems as both an employee and a consultant. You haven't lived until you've watched the punched card tray holding your 2,000 line program fall to the ground as you kick yourself for not putting sequence numbers in the 1st 6 columns of each card. Of course I had the opportunity to use punched cards, mag tape, mag cards, disk drives and CRT's as I/O devices. I have done amazing things with data in an ISAM structured datastore. I have also used COBOL with relational database structures. I started a consulting/integrations/development company in 1979 and by 1982 we were writing COBOL code on pc's running CP/M and DOS. We also developed and supported applications on x86 boxes running Xenix and Unix. Oh, where have all the Altos systems gone!? We developed applications for almost every industry using COBOl during those days. I sold my share of the company in 1996 and took a position with a firm that had been a client. The company continues to support and develop COBOL applications to this day. RM/COBOL was the first pc COBOL that I used. Later, MicroFocus COBOL became the compiler of choice because of the runtime environment feature that allowed the same compiled applications to execute in both the DOS/Windows environment as well as in Unix environments. I could go on and on because COBOL has been such a huge part of my life. I have also developed applications in Basic, SQL, RPG, 4GL scripting, Fortran and manufacturing process control equipment languages. I have maintained apps written in C and assembly language. COBOL remains my favorite language. I wrote my last lines of COBOL code in 1999 in the shadow of Y2K as I put an end to an integrated accounting system I had developed in 1976 and replaced it with an ERP system written in a 4GL language. I had a great run with COBOL. And though it appears that my COBOL coding days are over, I share the belief that COBOL will be around for a long, long time to come.

rdorwart
rdorwart

In 1978, I took a 1st yr university COBOL class, my Prof said it was the best thing since sliced bread, my advisor told me it's a dead end path.... Luckily I listened to my prof. Five months before I graduated I had two job offers (both COBOL). Started with an insurance company and for the past 24 years working as a consultant at a Utility company. Have had many double digit pay contract renewals to keep me working with VSAM/COBOL with some Powerbuilder and VB work mixed in. Our current TRES system is to be replaced in the next 3 years... (But I have heard that before). Enjoy the work and people and they must like me as they keep renewing my contract. If only my kids can find a job like this when they graduate... No regets

cliveamcgregor
cliveamcgregor

I taught myself the language while working as a computer operator on an IBM system 3 (fore runner to the IBM AS400) and used it extensively as a developer on IBM System 370, 4300 series and DEC/VAX environments. Some of my likes: Easy to learn (English language construct), easy to debug (using trace/debug features), easy to enhance for new data types on fixed and variable length records(just plunk in the new data desription), Could redefine a particular field as nemeric or alpha-numeric) at the same time, facilitaed the sorage of data into packed fields (you could store 12 characters in a 6 bytes), relatively easy to add new procedures when data or business requirements change. The only issue i had with it was that it required a lot of coding just to set up the the data files description, the working storage, and the procedures to be executed even for a simple report.

knowlengr
knowlengr

In the 70's it became clear that most complex business applications were written in COBOL (the alternative was usually BASIC!), and the visionary was going to have to bide his time. The COBOL MOVE statement and LEVEL 88 created readable code and the language supported hierarchical data structures and an indexed file system. On some machines, especially Burroughs hardware, it was even efficient. But interop was terrible, and seemed to lag further behind as the years wore on. It was practical code reuse on Unix and VMS platforms that spawned the progenitor of Acuity and its underlying platform, which became Acucobol. Acucobol was spun off, became successful, and was ultimately purchased by MicroFocus. COBOL provided both a confining software model and ultimately a sound business model with a substantial and enduring international following. Who would have thought COBOL would have survived those 30 years? Eons in software-years. But it was never designed to support abstraction, and early on I figured out that COBOL should be generated, not authored. And the visionary? He's nosing around Domain Specific Languages and wondering how that could have been implemented in the early 80's and how things might have been different . . .

stuart
stuart

COBOL was my first programming which I learned in a Vocational Technical School with punch cards and everything. In college I took a course in COBOL and received departmental honors because I knew more about it than the students and to a point, the professor. After college, my first programming gig was with COBOL on an IBM 4300 mainframe. I really enjoyed it, except of course, if you were missing a period, then all heck broke loose;)

bfpower
bfpower

I'm a full-time desktop tech, so I don't touch anything beyond batch files. But I'm also a full-time student, majoring in IT with a Software Dev focus. After I get this finished, I plan to my remedial CS courses and do a Masters in CS. I'm not wild about the rapidly fluctuating 'developer' market, so I'm of course interested in long-term situations like the one you're describing. Justin, I know I don't have a lot of background on this, but how can you be sure COBOL apps are irreplaceable? Eventually, won't someone come up with new hardware/software paradigms that will allow for the phasing out of COBOL? Help me understand this, if you don't mind.

RookieTech
RookieTech

pop the cork of that champagne and lets PARTY!!! weeeooooooo KEGGER!! lol

joe11701
joe11701

I remember it weill. I've spent most of my career designing and maintaining accounting systems written in several dialects of COBOL, both with and without database enhancements. My longest stint at a company was as an applications programmer, maintaining an all COBOL accounting system. it started with Burroughs / Unisys, migrated to VAX/VMS COBOL..... then the system migrated to MS Solomon.... i almost cried the day we turned off the VAX 4000/500 A for the last time.... Sigh.

Ole88
Ole88

I learned COBOL for the PC and the mainframe in college in the late 90's. I always had fun with the PC based work, but I despised the mainframe. I always wondered what rocket scientist decided that a good program should give you 3 sheets of greenbar and one missing a simple period needed to spit out 1/2 case of paper (or more)? Needless to say, after college I ended up on the admin track due to most development firms taking months to offer a job after you took their test and had an interview. At this point, I have been seriously considering reviewing old code, old books, the new COBOL standards and getting sharp on the language as well as others just to do something different and get back to the challenges I still enjoy to this day.

mbrown
mbrown

COBOL programming was my first paying gig back in the early 80's and kept me fed and housed for many years. I haven't touched COBOL code in over 15 years, but I would not be where I am today without it. Happy Birthday COBOL!

john.a.wills
john.a.wills

I moved from a Cobol environment to a series of non-Cobol systems with the occasional piece of Cobol thrown in without cross-references or fixed line numbers. I miss the Cobol environment dreadfully (even the IBM version), but I do not find many ads on Dice for Cobol positions.

RookieTech
RookieTech

I call the corner piece of the cake lol

santeewelding
santeewelding

Entirely so here in your case. Entirely actionable and commendable, should you deign to accept my plaudit. In other affairs, not. I do hope Tammy shared word-by-word.

herlizness
herlizness

> cool ... maybe I'll build a web service in COBOL ... that might get more attention than a tight sweater ;)

rhomp2002
rhomp2002

I had mini programs for most of the various file formats that all I had to do was write a couple of instructions and voila, new program or new report or whatever you wanted it to be. Really speeded things up. When I finished my contract I always turned them over to programmers with notes on how to use them and got all kinds of thanks for them. Got lots of free meals where the programmers took me out to dinner for making their job so easy.

Lee.P.Scott
Lee.P.Scott

Started using in 1997 and ended in 2008. The newer languages are harder to debug. Actually think a company is better off using COBOL than most other languages that are only understandable by the author. I wrote many on-line programs after the 70's using COBOL. COBOL will always be KING.

Justin James
Justin James

It's a good question. The fact is, most of those COBOL application are enormous. We're talking hundreds of thousands of lines of code, millions of lines of code. They are the size of an operating system. There is simply no automated tool that can morph that cleanly into another language. Even for something "simple" like translating VB 6 to VB.NET (which are very similar at many levels) requires a good deal of post-conversion processing. Converting COBOL to something else would require a TON of inspection and fixing. In and of itself, that would not be so bad, but remember, we are talking about a moving target. Let's say it takes 5 a team of 10 (developers, project managers, QA, etc.) 5 years to rewrite the application. First of all, this team needs to be extremely fluent in both COBOL and the new language/system. That's a rare combination of skills. Now, a team of 10 people is going to run you at *least* $1,000,000/year. In reality, the $1,000,000/year is just the direct costs of the team... we're ignoring the fact that every department touched by the migration will need to dedicate countless hours to providing information about "why does the system do things like this?", and "can't we improve this thing here?" and so on... not to mention the testing, QA, retraining, and so on. So let's suppose for a moment that the project really is going to cost $3,000,000/year. And of course, we know how IT projects almost never get completely on time, especially massive ones like this. Let's take the "5 years to do it" and make it a more realistic "7 years". Now, we're looking at a $21,000,000 project. After 7 years and $21,000,000, what have we got? A direct translation of the application... as it was 7 years ago! But that is a moving target, since it was constantly being changed. Let's add another year of development just to bring it up to speed... $24,000,000. So, we're now looking at $24,000,000 and 8 years, to replace an application that has been working fine for 30 years. And we haven't even actually improved the software yet! Just recreated it in a system which was cutting edge when the project began, and is now just as "obsolete" as COBOL is considered! Pretend you started this is 2001, re-writing the application in C#/.NET Framework. Well, C# 3 is a zillion times better than C# 1 was, ditto for the .NET Framework 1.0 compared to the current 3.5 or 4 that is being released soon. Ditto for Java, Ruby, or any other language you might consider. Imagine if, in 2001, you decided to move from COBOL to the ColdFusion platform. Whoops! Here's the kicker: IT projects have a MASSIVE failure rate. 70% is the widely accepted estimate of that. SEVENTY PERCENT! Now, what CEO (or CIO) is going to sign off on a project with direct and indirect costs of roughly $24,000,000 (really unknown until its done) that will take 8 years, only to acheive feature parity with an existing system on a platform which is already going to be outdated when the project is done, *and* has a 70% chance of failure? Not many. And that is why these systems are irreplacable. It's not a technology hurdle, it's a management and "getting it done" hurdle. It's cheaper, better, and more realistic to maintain the existing code for eternity, training programmers in house if need be, that it is to try to replace it. J.Ja

Will Dilbert
Will Dilbert

It's the cost rather than the technology that discourages replacing COBOL. When you have 20 Million lines of code containing thousands of rules that support complex business processes, it's difficult to cost justify rewriting in another language. While there are significant benefits to more modern development platforms, those benefits need to exceed the cost to justify the conversion. In 1985 a CS dept head of a major state university told me that COBOL was dead and that within 10 years all business applications would be written in Pascal. Now I chuckle when all the developers under age 40 ask, "What's Pascal?"

joethejet
joethejet

Yeah, there are all of six posts today on Dice for Cobol in the SF area. Compare that to pages and pages for something like PL/SQL.

c.walters
c.walters

It has been a while, but Cobol sure provided a steady income for me at the start of my career. I wanted to get out, because I presumed that CObol wouldn't be there for ever + I wanted to move up the ladder. But with the knowledge I have today, I could have made also a very good career in Cobol. Happy birthday Cobol!

Ole88
Ole88

It will only install if you have Visual Studio Pro installed... I just found that out when I tried to install it on a plain system... guess I'll have to load it on the dev system :D

Lee.P.Scott
Lee.P.Scott

Started using in 1967 and ended in 2008

BlueKnight
BlueKnight

Most COBOL application systems are large to enormous, and costs will vary widely depending upon the approach and target language if one wishes to attempt to "replace" the system. Labor costs would be huge in any case and you also need to factor in the costs of replacement hardware and software for the new code to run on... remember COBOL primarily runs on mainframes. AND... don't forget conversion of the database while you're at it. The reasons why most projects of this magnitude fail are lack of planning, poor project management and little to no user involvement. We just completed migrating an extremely complex, 20 year old, mainframe based application system - online and batch - with several million lines of IBM COBOL source with a mix of Assembler routines, IDEAL and Easytrieve thrown in. We began the entire process by researching what alternatives were available. After that, we researched similar installations to find out what they had done, or had planned or in progress, and what the results were. This gave us a very good base to decide what approaches were feasible in our case. After two years of research and planning we decided to keep COBOL and port it to an alternate platform which ended up being AIX. The project planning begain early in 2007 and we went into production mode in July 2009. A good deal of that time was occupied with conversion of source, files and various interfaces to external systems. The second greatest amount of time was spent testing... and this comes to one of my points -- in a legacy COBOL system, you have many, many years of business rules built into the system for checks and balances and processing regulations etc., etc. A business enterprise cannot afford to break these rules when translating them into a different language. Compound that by the fact that current employees may not even be aware of many of these business rules, thus they get overlooked when a "replacement" system is developed in a new language. This also can lead to the failure of a project. We spent a number of months testing, using plain old hands-on testing with a room full of users who really know the system. They developed and scripted hundreds of business scenarios and recorded them with software specifically designed for this. The "scripts" were then replayed on the converted system and results (screens and reports etc.) were compared to be certain they were identical. We also fully stress tested the system and did complete failover/failback. On the weekend of the cutover, everything went almost flawlessly and we were in production mode on the new platform 35 hours ahead of schedule... and we were under budget!... and this all included a database conversion as well. To contrast that, another very similar installation took the approach of converting COBOL to java and converting the database to Oracle as we did. They did very little, if any, research and did not involve the users at all. After two years and more then $800K in software costs alone, they were nowhere near completion. After another year, they gave up on that approach and their CIO was replaced. Plan, plan, plan... then follow the plans and make sure you have excellent project oversight, which should include the best of your most experienced users. This was the most complex single application system I've worked on in more than 42 years in the field and it was the most successful project... due to research, planning, project management and the people selected to work on the team.

jamurray
jamurray

But, COBOL apps work and are relatively easy to maintain. COBOL does what it was designed to do, allow the development, deployment and maintenance of business applications. You want games, maybe you don't want COBOL. You want mobile device apps, maybe you don't want COBOL. You want a sound business application, especially in a mainframe environment, COBOL is still the best choice. What is so wrong with being able to actually 'read' the code and understand the application?

silvergrrl
silvergrrl

it's proprietary information. All I can say is we did a detailed cost/benefit analysis (over the projected next 5 years) of continuing to use web servers vs. Websphere running on zLinux and Websphere won.

Justin James
Justin James

To be honest with you, the LegacyJ website left it to me to fill in the blanks of how their software works. No where does it claim to directly translate COBOL to Java. Everything points to a compilation to bytecode followed by a dissassembly of bytecode to Java source. Here's the statement (from their whitepaper at: http://www.legacyj.com/marketing/LegacyJChoice.pdf) that makes me think that this is what is happening: "Once we?ve moved your procedural COBOL source over into Object-Oriented Java executables, we present you with the Java source code for each new object ? but with the corresponding COBOL code embedded along with each section as comments to allow you to maintain and move forward in the new programming model ? not just the ?Old Standard?." Now, I could very much be reading this wrong. But I don't think so, because of this other statement (the paragraph above my previous quote from the same document): "It?s our LegacyJ compiler technology which lets us do the ?heavy lifting? to create Java executables from your COBOL source code in a very short period of time ? letting you focus your resources on the validation testing for your new platforms. But it?s not only the speed of our compilers, but their accuracy: rather than a source-code converter that?ll accomplish 35% of the process require thousands of man-hours to finish, our Java executables are better than 99% accurate, first time, every time." I think you can see why I have the impression of their functionality that I do. But, in the spirit of keeping an open mind, I've reached out to LegacyJ to do a follow up article on this topic. I've already gotten in touch with my contacts at Micro Focus, and they have sent me some information. I plan to do an article in a few weeks discussing the realistic feasability of this kind of project, what it entails, etc. I'd love to give the LegacyJ product a spin. Unfortunately, the last time I used COBOL hands on was 10th grade, and the last time I touched Java (I never knew it well to begin with) was 2002, so I am in no position to give it an honest, hands-on evaluation. Regarding the mid-grade Sun servers... you are right, those servers had those features, and were definitely not mainframes. But that was 10 years ago, and that market has shrunk dramatically. I'm talking commodity servers here (think, Dell, HP, IBM, etc. stuff in 1U - 3U boxes). They've basically dropped the idea of hotswapping at the component level within the box for the idea of swapping the box itself within a cluster, blade system, etc. Personally, as someone who has not worked hands-on with *any* of those technologies, I beleive that I'd rather have 1 big box that supports hardware hot swapping, then deal with a million little boxes and then get my software to work in a distributed fashion. This is just from the standpoint of comparing the complexity of a modern N-tiered application designed to deal with the scaling/reliability issues of those clustered environments to the architecture that you see in, say, a big COBOL application. I'd rather let the OS and hardware deal with this stuff than put in on the application developers' shoulders! J.Ja

swidup
swidup

I'm replying to your "World of difference between compiling and translating" post here as there is apparently a thread message limit blocking me from replying to the other directly. First, your assessment of how LegacyJ's product works in your most recent response post is incorrect. You ask me if I know how it works. Without going in to details I have, in the past, been *intimately* familiar with the product in question, both what it does and how it does it. PerCOBOL, the actual product name, reads in COBOL source and outputs JAVA source. The product includes with JAVA runtime libraries that perform equivalently for the COBOL language statements / concepts they represent. The product does not, at any time, reverse engineer byte code back in to source. As to difference between compiler and translator. They aren't effectively any different from a technical (computer science) perspective. The tool which performs the "compilation" or "translation" from COBOL source to JAVA source is, by its very definition, a compiler. In fact, it performs no different from any other compiler. It takes a statement (i.e. a line of code like your previously inferred "print" statement), tokenizes it, and produces a set of statements in the target language based upon a specific set of rules (grammar). Compilers are, after all, analyzing parsers that output a result based upon the input provided (simplified, but effectively correct). The format of the output isn't relevant. It is, by definition, a compiler. The compilers you (assuming, since this is the case for many developers) are historically familiar with, such as C, generally target an intermediate code which is used to generate platform specific assembly and ultimately executable object code (take a look at GCC if you want a prime example of this). In this case, it happens that the target language of the PerCOBOL compiler is JAVA source. It stops at the JAVA source stage and enables the JAVA SDK of the developers choice to perform the remaining tasks (effectively using the JDK as a compiler back-end). You asked in your earlier post how to test such "a beast". The developer (or QA team) can test the application at this point in precisely the same manner they previously did, just using the JAVA runtime system rather than the proprietary runtime of their previous COBOL vendor. Functional tests will yield the same functional results. The developer can then choose to either continue to support the application in COBOL, or muck about the generated JAVA source to make changes (all though with more difficulty as the generated code would be harder to support directly). The choice of in what language to support the application is theirs (or their organizations' to be more appropriate). In fact, the thought process behind the product was that COBOL existed for a reason and that there was a significant amount of life left in it, especially if it could be freed from certain constraints (such as where it would run or how expensive it was to run it) and enabled to take advantage of other technologies (such as the wealth of APIs provided by or through JAVA). In essence, it was designed to be "a better COBOL", not necessarily a COBOL replacement. How one uses it (translation vs development tool) is, of course, up to them. If you want to find out more for yourself, I suggest you try downloading the product sometime. They still provide a fully functional time limited evaluation copy last I checked (http://www.legacyj.com/evaluation/getting-started.html). As to the E10K, yes, it was effectively a mainframe. However, the 3000/3500 through 6000/6500 series were not mainframes and they did support the suspension of a CPU board for the purposes of swapping out hardware. So you do see these features reaching down in to the mid-range servers and that was in the late 90's early 2000's. So, since they fit the definition of mid-range and have the hardware hot swap capability you mention, I am forced to disagree with you. Cheers

Justin James
Justin James

The difference between compiling and translating is like the difference between building a cookie and a cake from the same pile of sugar, flour, eggs, and vanilla, and trying to transform a cake into a cookie. OK, maybe not the best analogy... My point is, the compilation process takes something simple (say, a "print" statement) and breaks it down into a complex combination of basic operations. While the details are complex, the "thought process" is not. Translating from one language to another is an entirely different beast, particularly when the languages are so dissimilar as COBOL and... well... anything else. Take a careful look at LegacyJ. You know how it works? It compiles COBOL to Java bytecode (a process which I trust) and then does a disassembly of the bytecode to Java source. Not exactly pretty, and I certainly wouldn't call it "translation" by any means. That's like having an English speaker give instructions to someone, and having a Japanese speaker narrate what actions they see being performed, and claim that you have created a great "English to Japanese translation system". Regarding you E10K statements. Well aware. I would also have to say that the E10K is a "mainframe". Some might not call it as such, but it is. Just because it runs *Nix does not mean it isn't a "mainframe". What I am getting at, is that you won't find that functionality in a commodity server on the market. Mainframes, regardless of vendor or OS, have advantages that non-mainframes simply do not, and hot hardware swap is one of those differentiating factors! J.Ja

swidup
swidup

I disagree. I believe your focusing too much on the fact that the tool compiles to source rather than byte code. If you go to byte code (which you can do by compiling the resulting java source), then you have the same testing problems you would with a new version of your product using an updated compiler. One would generally be safe in assuming you have a test procedure for the application. All you would need to do is test the new version of your application as it runs on the JVM. You have swapped out the compiler and runtimes, so a full system test would be in order before deployment. Assuming you keep your tests (which you should), this shouldn't be difficult or long (at least not significantly longer than your application tests ran previously). If you cannot trust your system tests, then I think you have another problem altogether.

swidup
swidup

There are places where the mainframe is needed. I wouldn't argue that it should be removed from scene. Just that not all operations or that all business need it. The mainframe costs are large and in many shops, more than what the company needs for all their applications. I'd be curious to see how moving everything to the mainframe would be cost effecient. If you have numbers you can share, I'd love to see them.

swidup
swidup

Hi Justin, It's interesting that you have an issue with code translators. Do you only develop in assembly? If not, then your using a translator for your high level language (C, C++, Java, COBOL, etc). All compilers translate one language in to another. The difference is whether or not you happen to work directly with the output as source or not. LegacyJ's product is a compiler, the compiler targets the Java platform. It just happens to target it as source rather than byte code. It's interesting that you'd trust byte code over source (I'm inferring this based on the fact that you stated you would believe in a COBOL to java platform compiler). Honestly, what's the difference in the end? You compile the Java source output and the result is the same; a program you can run on the JVM. You have the same problem set either way, how to trust the execution. For COBOL, the vendor does this through the NIST test suites which indicate compliance with the COBOL standard. Frankly, writing such a tool to byte code rather than source would yield a much less useful product, not to mention a maintenance nightmare for the author. It's easier to modify the compiler to use new java structures via their intended interface (source). Understanding those changes at the byte code level at each java version iteration is *much* more work and would take longer to output an update. Going to source is a better product deciscion and it gives their customers more options. I don't know about you, but I prefer options when I can have them. As to swapping out CPU/ram on unix systems while running, well, it's been a while for me since I was hands on as a UNIX admin, but if memory serves, Sun had this on their E10k back in 2000. I think I remember that same functionality in the rest of their enterprise line shortly their after. In short, I don't think this is an issue. I look forward to hearing your responses. Cheers Properly written translators function in the same manner as compilers.

eclypse
eclypse

Justin said: "Good luck hot swapping RAM or a CPU on a non-mainframe platform, even one running *Nix, for example." You could use the live partition mobility feature of AIX on Power 6 to migrate (an) LPAR(s) from one physical server to another. Expensive, but my guess is even on the more expensive Power Systems this is still cheaper than operating a mainframe. And our experience with IBM UNIX hardware has been good (although, I am extremely disappointed in the performance of Power 6 compared to previous generations of Power CPUs - their floating point rocks, though).

rhomp2002
rhomp2002

My last company decided to rewrite a major system to work on PC's rather than mainframe COBOL. They hired in 20 people to write the PC version. This was a time-dependent system where all the daily transactions had to be distributed world-wide by no later than midnight. With COBOL they made the deadline 99.99999% of the time, the odd miss being because of power problems. I spent 6 months totally documenting and explaining the current system and the rules for everything it did and why. The major accountant problem solver was assigned to the system to help them out. After 3 years and a multitude of attempts they were able to get the transactions out by 6 AM and there were alot of problems with reliability. The more transactions you threw at it, the slower the transactions processed which made it even later. I have been retired for 5 years now and they are still developing that PC version, it is now down to 2 AM but it is still prone to being very slow on days with more transactions and there are still major errors. Meanwhile my old team of 3 people still keeps the old COBOL system humming along just fine. That is 1 system with 135 programs. Multiply this by the number of systems involved in major corporations processing and then cost it all out. BTW my team of 3 for that system did Y2K updaing for the whole 135 programs for that and also 3 other systems the same size in 6 months with no errors at the end when it was all tested. Don't think the PC guys could have matched that time frame either.

scg8r
scg8r

Right on target! The company for which I currently work, like many from the early days of business computing, have extensive "homegrown" systems, written in COBOL, that have been tailored over the past twenty-five years to meet their exacting needs. Due to the demise of their hardware platform vendor during the 90's, the company decided to re-write all of their applications in VB on SQL Server just after the "Year 2000" modifications. After three years they were about 50% complete and the project was scrapped due to operational problems and the projected time to completion. A third party conversion company was then contracted to "convert" all of the existing COBOL programs to a PC based COBOL. Two years and 20 million dollars later, that project was scrapped in favor of a "canned" package that could supposedly provide all of the functionality of their "homegrown" systems. Ah, but alas, after two more years and another 20 million dollars, this project was also scrapped due to the fact that the "package" could not meet all of the company's requirements and would be a giant step backward from what they were accustomed. At the beginning of this year, an OS emulator that runs on Linux was purchased, and all of the original COBOL programs and data were copied intact from the old hardware platform to the new Linux based PC server. Therefore we are still maintaining and developing applications in COBOL and probably will be for the forseeable future. As previously posted, it's all about the money, the time, and the business knowledge and expertise that has been invested in these systems that probably cannot be duplicated that will keep COBOL alive and well for many years to come. Just like "Murphy". scg8r

silvergrrl
silvergrrl

Mainframes may be expensive, but they are fast, stable, and can process enormous quantities of data very quickly. My company is in the process of converting all of our web-based applications OFF of web servers and ONTO zLinux on our IBM mainframe. Faster, better, cheaper, and WAY less floor space. Also, all of our core applications are in generated COBOL, and we train our own programmers.

mattohare
mattohare

Where no two languages are identical, there is no automatic translation between any two. It is possible to get a translator to get things 100% identical most of the time. Translators make assumptions. These can go very wrong in huge, old applications. What we are talking about here are application that will crunch through millions of transactions in seconds. These transactions have to work right the first time. Would you want to find your airline booking to Hawaii changed to one in Anchorage? In the winter? What if your paycheck went into someone else's account? Now imagine the headache for a firm where this happens not once or twice, but thousands or millions of times? The only way to do it would be to spec and write a whole new application from the ground up. Run it through all the usual testing and validation. With a lot of luck, this may finish in half the time of Justin's converstion estimate.

Justin James
Justin James

Sure, I've heard of LegacyJ. But my experience with code translators has never been good. If someone said, "I've got a COBOL compiler for the Java platform", I'd beleive it. Targeting the Java platform for COBOL code is no different from targeted the .NET CLR like Micro Focus and/or Fujitsu are already doing (for the same purpose of getting away from mainframe environments), and no different from targeting a different OS. But when someone makes a tool that claims to "output Java" that is going to run "exactly the same" as the original COBOL (or any other language), I'm going to be suspicious. My experience with code translators/converters has been poor in the past. Even still, doing a shake 'n bake conversion of any massive system like that is fraught with risk. Do the people currently familiar with the system know enough of the new system to properly validate it? How do you test/QA such a beast? In a nutshell, a direct code conversion can definitely make the process faster (assuming it works 100%), but many of the other issues around the conversion still stand. Doing a migration of a million line application is a massive risk with little upside. Besides, "if it ain't broke, don't fix it!" Sure, the mainframes are expensive. But they are extremely reliable and stable. Good luck hot swapping RAM or a CPU on a non-mainframe platform, even one running *Nix, for example. J.Ja

swidup
swidup

Statement: There is simply no automated tool that can morph that cleanly into another language. Not quite correct. There is a COBOL->Java tool on the market today (see LegacyJ PerCOBOL at http://www.legacyj.com) that will take COBOL src code and output Java. Resulting output runs in *exactly* the exact same manner as the original COBOL, only on a JVM. The tool also supports multiple vendor specific extensions including EXEC-CICS support. What it required was someone willing to write the java equivalent of the COBOL runtimes for the JVM and ensure that they performed correctly (not a small feat at all). Now, maintenance of the resulting code in java might be a little tricky (considering things like the fact that GOTO doesn't exist), but it is possible (and you can always maintain in COBOL and re-run the tool, it's just another compiler after all ;->). And before I get flamed by people complaining about the fact that Java is interpreted let me point out that COBOL is as well (that's what costs you a large chunk of the money for COBOL; the interpreter licenses). Why might you use something like this? To get your systems off expensive mainframes and where the annual cost per year is astronomical and down in to midrange+ UN*X environments (much less expensive to manage/maintain).

D Walker
D Walker

If a company is able to throw out many of the old business logic and start over with more general rules or, in the case of a merger, using the other companies rules/logic the COBOL applications can be elimininated. May take several tries over several years. I was a development COBOL programmer for a company that supplied applications run on a shared system. Some clients attempted to go to other "more modern" systems and ended up back after never completely getting up on the other system. As the product I worked with was eventually discontinued, the remaining client companies had to change how they worked to match the systems they ended up using. They were able to replace the COBOL applications with various packages that had most of the capabilites of the "old" mature mainframe system applications. Modern systems seem to expect that the business change to new platforms and interfaces every few years. (Even changes on existing systems may require some retraining - like Word 2003 to 2007.) Mainframe systems allow changes but traditionally presented a stable, seemingly unchanging, environment - possibly for decades. It would have been interesting to rewrite the applications. Hundreds of programs with shared subroutines and application configuration file. Some programs written in 1970 were still in use 25 years later but had been updated hundreds of times.

sundar.krishnaswamy
sundar.krishnaswamy

Great points Justin. I have observed similar logic expressed by multiple companies I have worked for. Most legacy systems do not have up-to-date specs/documentation for all the business rules/logic. These would have to be reconstructed most likely from code which adds significant cost to the project. Also all the rules/logic have to be tested to make sure they work correctly. In many complex systems, it is not uncommon to see a need for tens of thousands of test cases. When all these costs are added up, it quickly becomes prohibitive

mattohare
mattohare

That would be a class way to take COBOL on board. I self-taught it, poorly, when I was just out of uni and had to crunch a lot of postal data on an HP-3000. It never stuck.

Justin James
Justin James

... is that COBOL jobs are not advertised like other jobs. Part of it is cultural. Part of it is camoflage. I have seen ads that I knew for a fact were COBOL positions, and they did *not* contain the word "COBOL" at all. I know of at least one major COBOL shop that has more or less given up on hiring experienced developers, and instead they lure folks fresh out of college in, and train them in COBOL in house. Sleazy? In a way, their ads are definitely deceptive, and they tend to hire people who can't read between the lines. As a result, they have a massive turnover rate. At the same time, it seems like the only way to get folks in, when those graduates seem to prefer unemployment to mainframe development. J.Ja

Editor's Picks