Is the Demise of COBOL Greatly Exaggerated?

Some people say COBOL is kind of like a Wall Street bank: It’s too big to fail.

CobolNot long ago, our blogger David Strom argued that as a stand-alone skill, COBOL wasn’t all that valuable anymore despite its prevalence in legacy systems. Along with Fortran and to some extent Visual Basic, he said COBOL was pretty much “dead and forgotten.”

A number of users disagreed, pointing out that the federal government and corporations from banks to manufacturers rely on COBOL and are always on the lookout for people who can maintain their legacy systems.

Last week, IT World’s Eric Bloom wrote that prospects are good for COBOL talent. Big COBOL applications are “too big and work too well to consider replacement.”

A fair point, but he goes on to say that there are complementary skills it would be smart to develop:

Regarding expanding your knowledge and skill set, there are versions of Micro Focus COBOL running on Windows, UNIX, and Linux. I’m not suggesting that entirely new applications on these platforms are being written in COBOL, but instead COBOL shops are using it to create off-host interfaces for existing applications. They are trying to move these applications as-written to other platforms. The advantage is that this provides the opportunity to work on and learn these other operating systems as a way to expand your marketability.

Indeed, the demand for talent is there, it just doesn’t get much buzz. Experienced mainframe programmers are beginning to retire — one observer estimated that half of the Social Security Administration’s 1,000 COBOL-skilled programmers will be eligible to depart by 2015. Meanwhile, the number of those trained to replace them is inadequate. That dynamic, Bloom suggests, means COBOL-centric skills will be marketable for a good while to come.

Should new graduates think about getting into legacy work? That’s not clear. If they do, they should be prepared to undertake a lot of training in order to keep up with large-system developments as platforms continue to evolve. But for experienced techs, it seems a whole lot of people still believe mainframes remain a viable specialty.

Should mainframe specialists stick to what they know, or is it time to move into another area? Let us know what you think by posting a comment below.

51 Responses to “Is the Demise of COBOL Greatly Exaggerated?”

  1. Johnny Hopkins


    I have read about the COBOL shortage over the last few years and it may be a good path for IT professionals to take. The COBOL vendors need to find a way to let students train on the technology if it is so important for federal and banking-driven system. We have to find the job listings looking for COBOL developers for us to take advantage of these retirements that are supposedly happening with mainframe programmers.

  2. Scott M

    I would not recommend new graduates learn COBOL as their primary skillset. However, it does not hurt to have it in your toolkit. I have done a fair amount of work for several large companies where I have converted some of their old COBOL direct I/O applications to SQL procedures. Obviously, you have to have a working knowledge of COBOL to do this.

    However, for some of those people out there who are within a few years of retirement and lack updated skillsets, I think COBOL is a good route. I find it interesting that I get far more calls from recruiters looking for COBOL developers than JAVA developers, even though I have done it in more than a decade now.

  3. Joel C

    The same can be said of RPG programming skills. Try doing a search for RPG programmer resumes and find one that appears to be under 55 years of age. I can’t.

    There’s a lot of RPG legacy code out there, too.

      • Mel Stricker

        Your problem is age not skill. We who are older than the people interviewing us have little chance to be called once our age becomes clear. I keep getting, “You have too much experience for this job.” or words to that effect. One guy even said, ” We contact people by email, do you know how to use email?” I said, “Of course.” to which he replied, “Oh, people your age normally have trouble with technology.” to which I finally said, “Hold on, I am an experienced programmer so why are you asking about my ability to use technology?” He changed the subject and needless to say I never received a call back.

        Same thing (with variations) with other job prospects.

        • Jim McKee

          Mel, you have put into words what I have been feeling for a while; it’s extremely frustrating. I don’t want to be a whiner, though, so I try not to dwell on it. I feel that my eventual route will be starting my own business.

          • John J

            I received a call from a recruiter a short while back looking for a mainframe candidate. He had a client that ‘insisted’ that all my skills be right up to the minute. This included JCL and COBOL. When I told him that my Cobol skills were 6 months old, he rejected me immediately. That’s the trouble with this business; too many turkeys and parrots who can’t think and evaluate for themselves. Its very frustrating being an older IT person and you wind up getting age-rejected. One plus to this. You hear about how African Americans put up with racism. Well, talk to an older unemployee about his/her experience in job searching. Some of the luckier ones who get called in for an interview see the smile just slowly fade into obscurity as the recruiter quickly searches his/her bag of excuses and hustles you out the door. I’ve seen this several times and it shows what an emotional penalty an older person or African American has to suffer. It makes no difference whether or not you are the absolute best in your field, you’re on the wrong side of the conveyor belt of life.

        • Mel, this is a clear violation of the “Age Discrimination in Employment Act of 1967”. You should contact the Equal Employment Opportunity Commission. From the U.S.EEOC site,

          “It is unlawful to harass a person because of his or her age.

          Harassment can include, for example, offensive remarks about a person’s age”

          • Mel Stricker

            Yes, this is the problem, proof. Most people never come out and say it is age. Depending on the state recording are covered by strict rules.. In Florida, in order to legally record a conversation both sides are required to know that a recording is occurring (this would end any ability to get proof). In some states (I think in New York) only one side need know but, you have to have that conversation and this is quite difficult.

            So, in the end, those of us being discriminated against because of age have little or no recourse.

            Thanks for you concern.

        • 52 as well. Experience with maintaining and converting so-called “legacy systems”. Been told flat out by more than one person (not recruiters) my 3 most significant challenges are age, experience (more than 20 years) and education (MBA). None of which I can do anything to eliminate or reduce. Meanwhile there are allegedly many jobs going unfilled because there is an insufficient pool of folks who know how to use technology OTHER than Java, and PCs or Macs.

          • Walter

            Yep – they don’t want to pay us what we are worth, they want to pay someone half our rates. Problem is, since schools do not teach COBOL anymore, where are you going to get someone with 3-5 years experience? You can’t. Thus jobs go unfilled and get offshored.

        • I’ve run into that, quite often. Particularly over the past 15 years. You would think, that as a contractor, none of these things would be relevant. But, “recruiters” (a.k.a. “buzzword matchers”), and personnel pukes, operate on the same page. So, I run into the same thing. Unfortunately, the responsible manager/executive is also clueless, at times. That’s where it becomes really difficult.

          I usually meet the “over experienced” objection with simply stating “That just means there’a a good chance that I know how to avoid the mistakes, or resource misallocation, of my lesser experienced competitors.”. Then I follow it up with “Do you want the project/job done, or are you screening for a popularity contest?”. Then I point out how I can not only bring the end deliverable on time and within budget, assuming their estimates and expectations reflect reality to begin with, but also minimize their maintenance costs thereafter by applying all those 40+ years of experience to the entire effort. I also point out that I will review their estimates, deliverables, and expectations, up front, and either agree, or disagree. If I disagree, I’ll tell them explicitly why. Depending on the scope of the effort, about 50% of the time, I’ll do the up front assessment, for free. The othr 50% of the time, I charge for that assessment, if the scope of the effort/project is large, or the risk extremely high. Some of the contracts that I do, are for exactly that, independent review of project plans, scope, costs, timeline, etc..

          Works (or used to) about half of the time. I haven’t been doing low level contracts (straight programming) contracts for quite awhile now, though. Primarily because of exactly this phenomenon. For those of us old, dinosaurs, I think we have to now, make our own market.

          Perhaps this can be done by looking at what is being advertised as a need by companies, and then coming up with a short (1-2 pg.) proposal to include, scope, cost, and duration estimates, submitted independently, if possible. For example, if someone is advertising for development, requiring expertise in, Java, HTML, XML, SQL, C, C++, and SOA, we can derive that what is to be developed is going to be on a network, a front end probably for a client/server based architecture, w/a GUI front end. Usually there will be a brief description of what the developed software is to do. From this, we can extrapolate an estimate of the overall effort it’s going to entail, and come up with a proposal (high level) that describes what we will do, how long it is estimated to take, and how much it will cost. Has anybody tried this, for low level contracts? If so, what’s been your experience? Anyone else have any other, or better, ideas?

          As for COBOL, it’s never going away. I’ve seen languages come, go, change, and resurrect themselves, over the years. Two things are never going away. Assembler, doesn’t matter what platform(s)/processors, and COBOL. Assembler, by definition, can never go away. COBOL has been around for 60 years now, and there are trillions of dollars invested in the core systems of any large application. To make it go away would require trillions of dollars of investment, again! Nobody is going to make that kind of investment. Why fix what doesn’t need fixing?

          All the other languages I’ve seen over the years, come and go. In my younger years in the filed, just like everybody else, I wanted to reinvent the wheel, because it would be so much better, and cheaper. That’s the key pitch that has been used over the years. Even with COBOL. The idea was, and is, that “code generators” will decrease development time, be cheaper thereby, more flexible, and reduced maintenance cost. How many time have you heard this? I can think of at least a dozen variations for COBOL alone, such as Meta-COBOL, PsuedoCOBOL, TELON, eGen, GenTran, Gen-Code, Flexus, and countless others. None of them really do the job, and usually increase the development costs. And runtime performance – what a joke!

          All the other high level languages I’ve seen, with a few exceptions, have come and gone. Examples are: APL, ACP/TPF, PL/1, Fortran, Prolog, Dbase, ALGOL, ADA, AutoCoder, Basic (not VB), Cecil, Clarion, Clipper, LISP, Compass, Rexx, DataTreive, Delphi, Easytrieve, DIBOL, FoxPro, Forth, Forte, Jovial, MARK IV Mumps, Adabas/NATURAL, Pascal, PDL (although arguably PDL is not a language, IMHO), SNOBOL, J, J++, and the list goes on and on. These are just a few off the top of my head. The exceptions (not going away) are: C, C++, C#, Java (and related), PL/C, UNIX scripting (bash, perl, etc.), HTML. These have become entrenched, standardized, and heavily invested in, as well. For good reason. Higher level languages that work, on multiple platforms, and are flexible enough to adapt to any environment. Same as COBOL.

          For the above entrenched, heavily invested development in the languages, above, there is no financial incentive, and doubtfully, will ever be, to “reinvent the wheel”. The world will not stand for another upheavel in IT the likes of when IBM completely changed from the 360 architecture to the 370 baseline architecture! Not gonna happen again.

          Any comments to the above will be appreciated.

          • Unca Alby

            Fortran and Delphi have not gone away, and by virtue of being an intricate part of Delphi, neither has Pascal. Indeed, I still get the occasional email for said languages.

            What pains me is that I have a smattering familiarity with almost everything on your list, which probably means I’m too old.

          • aceet1951

            Well said. I don’t worry anymore about rejection when I interview. If I don’t get that one, I will the next one. To be a mainframe programmer you have to know many, many different things. Do you remember when you could just be a batch programmer or just online? Not anymore. The market has so degraded our talent now we should know everything. i blame the ‘microsoft effect’ because now clients want pretty. Pretty screens and pretty reports. Usually if it is a large complex, transactions driven system, the work horse in the back is the mainframe. i hate that there does not seem to be entry level opportunity for the young folks. I’ve been outsourced and now I compete with forgein workers who may have 5 to 6 years experience. But I’m up for it. I hope I can keep working until I save for my 2nd retirement fund.

        • Bernie Starzewski

          That is entirely consistent with my experiences.
          I have an additional disadvantage of living in a rural area and most of this work is done exclusively by large corporations in major cities.
          In the past I used to work with smaller scale applications written for smaller businesses in COBOL and DIBOL that worked great but Windows mania not their functionality made the obsolete.

  4. Mel Stricker

    I remember after Y2K an editorial in PC World (or was it PC Magazine, not sure). The person writing the editorial stated, with full confidence, that, “no one will be writing programs for the mainframe any more. Mainframe programming is dead.”

    Here we are some 13 years later and mainframe programming is alive and well and, because of mobile technology, it appears the PC may be the thing that is dead.

      • If the PC is running Micro$auce software its use is limited. PCs have their place; so do BRSs (BIg Reliable Servers) running a robust OS that is not changed dramatically with each major release.

    • Bernie Starzewski

      Ive worked 100% on Unix/Linux based COBOL apps.
      IBM mainframes still have uses in the shipping industry as I understand they do an excellent job of holding large ships in place during storms.

      Companies that still use them for IT work are spending all that cash not to support COBOL apps but because of the JCL.
      Its just not easy to get IBM people to convert. Ive seem some real hash jobs where the IBMers didnt know shell scripting and did some horrific and stupid things in shell scripts and then used the results as evidence that Unix doesnt measure up.

  5. Mark Foster

    I am an old dinosaur, 30 billion years of skills and experience that no one can take away from me. But are they now evolved enough to know how to use it? They think they are inventing the wheel, they are wrong. My last contract I included in my technical docs some pseudo code for a Java developer. She asked what is this, COBOL code? I said, no, it’s IF, THAN, ELSE pseudo code to explain the program logic. Her eyes rolled to the back of her head! I don’t need that, take it out! Then she asked, what is this CCYY/MM/DD in my report layout description? I said, have you ever heard of century, year, month and day before? I looked around for a wall to bang my head against. I said I can write the code in one day and start testing the next. She said, yeah right, whatever. Thirty-four days later she came back excited exclaiming she done! I looked at her test report and she didn’t get one thing right. She didn’t even know about fixed pitch vs. variable pitch fonts. She mixed fonts at will thinking it was pretty. I secretly wrote it in COBOL in one day, thirty days ago and she didn’t believe me.

    So what’s good with this Java code anyway? You can’t read it like COBOL. I look into Java for Dummies and Java for the COBOL Programmers and I can’t believe who came up with this crap! Just because Bill Gates didn’t put NT on the Mainframe, way back when, we are stuck with all these servers and distributed systems, languages and utilities. Has anyone asked why COBOL legacy has lasted so many years? And why are we so fast in trying to replace it? Is it just the fancy GUI screens, cheaper platforms? Yes, Mainframes are expensive that’s because of IBM not having much competition. Distributed platforms will get expensive too, one day. What if the internet changes back to ‘charge per minute’ business model? What will become of everything then?

    • Mel Stricker

      I am sorry Mark but I am a COBOL programmer (more than 40 years) and just because you cannot read Java like COBOL does not make it, as you say, a crap language. I am also an IBM Assembler programmer (also more than 40 years) and Assembler is less readable than Java. Java is quite a valuable language. It is highly readable but, like most languages, you have to know how to read it.

      In fact without the comments on the right side of Assembler, even an experienced Assembler programmer would have a difficult time determining exactly what is going on. I have cursed many times when I have had to modify an Assembler program that had little or no comments. While comments are important to Java, it is much easier to read this language.

      Just going through a book to understand a language and then to declare that language crap because one does not understand what they are reading is quite ingenuous.

      • Mel,

        Regardless of the language there are too many programs lacking useful comments. Typically there are no comments (obfuscated code or not) or the comment states the obvious (increment A by 1) with no information regarding the use of A.


      • Bernie Starzewski

        Ive worked in Java too and once you get used to it it is OK.
        However Java’s use is not in accounting operations like back room settlements and report writing as with COBOL.
        Its main use is in creating web enables data input and query screens.

        The main problem with Java is not its own code but the ever changing bevy of 3rd party development tools that seek to shield the programmer from programming.
        We used to call these – source code generators.
        Sun has Java Studio but almost nobody uses it.
        Then you had Borland’s J Builder (now defunct)
        Then Symantec’s Java Cafe (also defunct)
        Ive lost track of all the new ones and the beans and all that.
        Knowing Java is almost irrelevant today . You need to be an expert in the packages that write it for you. And they change daily it seems.

    • Bernie Starzewski

      Ive had many similar experiences. Perhaps we should share war stories?
      In one case a programmer didnt know how to implement a stack – a rather language independent skill.
      So, he did it in the program code by adding a new redundant paragraph for each level of the tree complete with all the code replicated imply because he had to jump to the next leaf. (It was an inventor BOM report).
      The program didnt work and nobody could figure it out.

      When I finally figured out what the guy had done (and after I stopped laughing) I set up a pointer table and did it with the array they way you learned way back in Data Structures.
      I too fixed it in a single day.
      But the programmer who created it got pissy and complained to the boss who couldnt argue that the output wasnt correct but told me NEVER to use that method again because he couldnt read the code!
      I quit a couple days later.

      • Bernie Starzewski

        In another case of a botched Unix conversion the chief coder had been working under false notions of how Unix worked.
        She had added maybe 50 lines of overhead to every single shell script first setting up environment variables and then deconstructing them so as “not to corrupt them for other users and processes…”
        I had to explain and then demonstrate how shells actually work and why all that hard coded overhead was creating problems due to replication errors.

        Needless to say I didnt last too long at that job either.
        It seems the contractor I was looking for had been making the case to the client that they should move back to AS-400s because all that Unix junk didnt work.

  6. Bob Gaydos

    Well said Mel,

    COBOL, especially the later versions are very flexible and extensible. When you combine the minute bit twiddling of an Assembler subroutine you can do virtually anything in a mainframe environments. I worked with it for about a decade and though it has its shortcomings it requires a lot of demanding set-up…but if you do it right it can be very maintainable precisely because it is so readable and English-friendly.

    Obviously OO languages have the upper hand on modeling real-world applications from scratch and working with the Web, but you can program a lot of basic business applications in COBOL with little effort and maximum maintainability. There’s still a call for that in “closed” environments.

    • I have to disagree with the “upper hand” of “OO languages”. Object Oriented ‘x’ (analysis, design, development, etc.), on a bottom line, is no different than proper, structured design, approach, technique, developmental controls and configuration management that have been in place, and practiced, since the 1960’s. Meaning, there is no difference between the identification of a common object for services and interfaces, than identification of system services, macros, or subroutines, when designing a system.

      When it came out in the late 80’s/early 90’s, I looked at the ” new, revolutionary” approaches of OOA and OOD, Unix scripts, system objects, etc., and I remember thinking then “What a scam!”. The “new” OOA/OOD methodologies, and associated approaches, techniques, libraries, etc., was no different than what we (I) had been doing since the 70’s (for me), and simply “renamed” what we had been doing for years in the first place. The “renaming” or, in essence, using the same stuff, and just changing the name, and promoting “it” (whatever “it’ was) as the “latest and greatest” thing, is what IBM had been doing since the 60’s. The only difference in the “OO” world is that “it” was coming from a Unix perspective, which evolved from the DEC (Digital Equipment Corp.) weenies, who were constantly writing their own I/O routines, and formats, for each and every application they wrote, all the way into the 80’s. Finally, somebody woke up and said “Hey, why can’t we standardize some things, so we don’t have to duplicate our efforts all the time?”. Revelations! So began the “era” of “OO”. Not that outside the DEC realm, we hadn’t already been doing the same thing, just with different names for over 20 years at that point.

      There’s a whole history behind it, that goes clear back to AT&T, Tom Richley (architect of AT&T Unix back in the 70’s), that I’m not going to bore you with here, but that’s really all that happened, when you discard all the BS, and look at the fundamentals of both.

      So, no, “OO” languages don’t have an upper anything. Sort of a “been there, done that” kind of thing.

  7. Sadly age discrimination is alive and well. Many of the recruiters are young MEllenials, in their first job ever, and are allegedly “technically savvy” (but I don’t view ability to walk and listen to an iPED as technically savvy) so don’t be surprised if they assume you (and I) know nothing useful. I too have spoken to recruiters but when they realize I am “old” there is no further contact.

  8. Michele

    Mel, Mark was simply voicing his feelings just as you did. There was no need to attacked him as you did. You sould like an old dinosaur who never developed social skills. A lot of COBOL professionals feel the same way he does. We wrote programs, now they click.

  9. My last COBOL project (2008) involved the parsing of free-form real estate text data into SQL Load-Ready files. The resulting code looked more like ‘C’ that COBOL. It was a well-documented thing of beauty and ran like a scalded dog.

  10. Hi Mark, It seems to me you are missing out an important idea in your article about COBOL. At this point in history, COBOL is something like the Latin of computer languages. It still, clearly, has a practical use in IT (as Latin has in Classics) but it’s also still good for doing what it was originally intended to do…model business processes and thereby facilitate communication between business-types and programmers…when it was specified in the 1950s by a DoD special committee (Grace Hopper, Chair). (Look it up.) I think this is the underlying message in Mark Foster’s story above. As such, COBOL would still be a great foundation course in a programming curriculum and might better prepare student programmers to really understand what their future clients are trying to accomplish.
    The question “Will COBOL survive?” has been asked over and over again since the 1970s that I know of. The founders of COBOL legend Micro Focus asked the question in 1976. They decided to take a risk and continue work on their COBOL compiler for microcomputers because they felt COBOL would be around for another 10 years in all likelihood. How right they were.

  11. I have been teaching college level C, C++ and C# for a while. I mentioned COBOL as a potential language to know to a group of my students. To my surprise they asked the school administration if I could teach a COBOL class as well. I did. The reaction was absolutely amazing. The usual comment was “We should have done this first so we could understand what is happening in the computer before we got fancy with C++, etc”.

    I’m beginning to believe that many of the new programmers (especially the OO variety) are performing what I call Lego Programming. You need a program, go to your Lego program box, get a bunch of blocks and put them together. If you chose the right blocks, it should work, but I’m thinking that the result is not optimal just like the jagged edges on some of the Lego sculptures.

    Anyway, COBOL will probably persist for a long time to come because the applications that were written in it are not going away any time soon (like payroll). Most of the folks who are running those applications cannot change them in any way since there is too much money or liability involved. Replacing the application with a new version written in a new language is risky at best and these folks are definitely risk averse.

    By the by, there are other implementations of COBOL on the PC. The one I have been using on a 2 million line application is from Fujitsu. They have versions for Win32, Win64 and .NET.

    • Tom,

      I’ve read/heard the same thing about “Lego Programming”. The NKOTB (new kids on the block) program by using already created objects; they do not write code.


  12. Ryan Chow

    To be or not to be…

    We did not think about ‘to be’ before jumping in. That is the question.


    54 years old, 30+ experience, ASSEMBLER/COBOL, BANKING/Government, and not in a project for 3 years.

  13. Richard Hart

    I have been working with RPG for many years now. COBOL is similar in many ways (procedure-oriented). I would switch the the mainFrame world in a hart-beat (pun intended) if I could find a stable environment to work with for the next ten years.

  14. Dane Jordan

    COBOL IS JUST A COMPILER AND COULD VERY EASILY BE CONVERTED TO A COMMAND INTERPRETER. It all boils down to assembler or machine language. In other words the Cobol compiler can be upgraded to include objects, calculus functions, anything you can imagine. We have been able to embed SQL into cobol when DB2 was about the only RDMS. It is just a language that gets compiled into eventually zeros and ones just like everything else. It will evolve, slowly but surely.

  15. Darrell Bright

    I wish I could agree with Mark Feffer as I am an experienced 370 – Assembler, RPG, and COBOL programmer. I actually taught these languages for 16 years. My wife is a COBOL programer too. I have written COBOL on IBM and Stratus mainframes, AS/400 mid-size computers, and have written micro-focus COBOL on Pc’s. I can read a core dump and also Hollerith code on a keypunched card. Unfortunately, I have heard this argument about the retiring government programmers for at least 10 years but it had thus far not resulted in COBOL jobs becoming available in government jobs or elsewhere. The truth is, you can go for months without seeing an RPG job in the mid-south as most of the AS/400 market is using JD Edwards software. I also haven’t seem a 370- Assembler job in years. There are few companies in this area that continue to use COBOL, and most of them plan to phase this out in favor of Java. I wish it were true as I only want a few more years of work anyway. Unfortunately, other languages outnumber COBOL jobs by perhaps a factor of 50 to 1.

  16. I moved off the mainframe several years ago after 30 years because job postings are almost nonexistent and all marketing hype from Gartner and others have declared it dead. The future of the applications built on the mainframe should be interesting. It is not just COBOL skills going away. JCL, CICS, DB2, VSAM, TSO, ISPF, REXX, CLIST, IBM Utilities, RACF, plus many other skills will be part of the mainframe exodus as well.

    Good luck industry! Gartner, an apology is waiting!

  17. Dick Daswick

    Age is one primary factor for hiring us to program. Also, I would suggest that it is simply cheaper to hire any programmers overseas, whether they are that good or not. However, the demand for us as COBOL programmers can also be impacted by the time we have been forced to spend away from the language. I last coded in Cobol in 1998-9, using primarily SQL and SQR with a smattering of COBOL, thereafter. I was forced to become a BA in 2004 after the shop I was in was offshored. Now, what I hear is comments on “how long it has been since I coded COBOL”. Even though I coded for over 20 years in the same 1974 COBOL most mainframe shops use, and learned Micro-focus COBOL, too!

  18. Mark Deters

    My experiences align with many of the comments to this point. Seemingly, a bleak outlook for the professionals who automated manufacturing, banking, insurance, distribution, transportation, and other industries for the past 40 years. The lessons we mainframers learned (mistakes we made), have been repeated over and over again as the new language technologies mature. This experience should have translated into leadership positions, trusting the judgement that only decades of learning could bring, but it does not seem so.

  19. Larry

    I wrote my first COBOL in 1970. My company closed its office in my location. I’ve been told I’m not experienced enough for some COBOL positions I have applied for. I’m sure there are plenty of onshore and offshore resources though.

  20. I get calls all the time for COBOL, RPG, etc.
    The problem is these are 6 contract to hire gigs, and they want you to move cross-country for it.
    I have removed my phone number from my resume so I don’t have to waste my time fielding calls for contract gigs. Now I get the all the e-mails, and I can only return calls for perm gigs.

    • Most folks desire to remain where they currently live. I meet quite a few folks who work in VB or c# that telecommute. If these companies really want mainframe talent they could get some very qualified programmers by following suit.

  21. David Parker

    In the 1980’s (I’m giving away my age here), I predicted that COBOL skills would continue to be needed until I retire (much closer now). This has been the case and I currently predict that COBOL will persist until at least 2050. I object to people who say we lack updated skillsets as I made a deliberate decision to stay with the is skillset. Incidentally, the latest IBM COBOL allows one to write objects in COBOL (though I never would) and it can parse and generate XML and JSON.

    I worry about companies that have so much invested in COBOL. However there is a school in Chennai, India that is teaching new students COBOL. Why don’t American schools have the same foresight.

    By the way, do others consider JAVA to be the new COBOL, since it is now over 25 years old? People have been predicting the death of COBOL since the time it was less than 25 years old.