Would you like to receive similar articles straight to your inbox?

The Inevitable Return of COBOL

It’s only a matter of time until the Common Business Oriented Language (COBOL) will regain its spotlight as one of the most in-demand skills of future generations of software engineers. We can just see it now: Programmers of the future will hop out of their driverless cars, walk into their offices and sit down to start coding in 1959’s COBOL.

It sounds crazy, considering COBOL is the furthest thing from most engineers’ minds today. It ranks fairly low in the Tiobe Index, a measurement of today’s most popular programming languages. Many newer, speedier languages give today’s coders little reason not to scoff at the antiquated COBOL.

The most telling evidence of COBOL’s irrelevancy is that about 70% of universities said they don’t even include COBOL in their computer science curriculum anymore, according to a recent survey. It’s logical.

Why waste curriculum space for a skill that employers don’t even look for these days? A quick search for “COBOL programmer” on any job site, for instance, yields a few hundred job postings while the more popular “Java programmer” yields thousands.

Based on these facts alone, COBOL appears to be nearly extinct. You might even wonder why we’re writing about COBOL at all?

But looks can be deceiving.

COBOL is a mysterious paradox. Born in another era, COBOL lives on as the quiet but important pillar on which the majority of businesses stand today. In a field that evolves at an unprecedented speed, younger generations may be overlooking a critical skill of the future.

Out of Sight, Out of Mind

Those of you who are familiar with legacy systems know the widely cited stat: *70-80% of all business transactions worldwide are written in COBOL today. But what’s not emphasized often enough is there’s a slowly increasing gap between the number of massive institutions relying on COBOL and its relevancy among programmers today.

COBOL knowledge skill gap (3)

While newer programmers aren’t as interested in learning COBOL, its role in millions upon millions of mission-critical transactions from healthcare to travel can’t be denied. COBOL is written for mainframes created 10 years before man walked on the moon.

Those same mainframes still operate some of the biggest institutionalized computing today. If someone pulled the plug on COBOL, millions of businesses worldwide would suffer from malfunctioning machines. This old programming language is a bit of a taboo today, but it’s important to recognize just how big of an impact COBOL still has on our day-to-day.

Here’s a quick breakdown of the biggest systems that run on COBOL:

COBOL impact

Why Haven’t We Replaced COBOL?

If COBOL’s been such a foundational root of business apps for decades, why hasn’t something better come along? The short answer: If it ain’t broke, don’t fix it. The long answer requires us to take a step back in time. COBOL was created in 1959, the computing era when programming languages were tailored for specific purposes. For instance:

  • Fortran → Scientific problems
  • Lisp → Artificial intelligence
  • Cobol → Business applications

As banks, insurance companies and government institutions started joining the computer age, they’d create programming languages specific to their machines.

You can imagine how costly and time-consuming this was. There needed to be a universal business language to carry out business operations faster.


Grace Hopper, the mother of COBOL, helped champion the creation of this brand new programming language that aimed to function across all business systems, saving an immense amount of time and money. Hopper was also the first to believe that programming languages should read just like English instead of computer jargon.

Hence why COBOL’s syntax is so wordy. But it helped humanize the computing process for businesses during an era when computing was intensive and prevalent only in research facilities.

And so a new committee, consisting of industry, universities, and US government folks, formed to develop the much-needed language to help standardize business programming. The Department of Defense even decreed that all businesses must run on COBOL in the 1960s. One article by notable software engineer Robert L. Glass explains that COBOL does the 4 essential business tasks better than most modern languages today:

  • The capability for heterogenous “record-structure” data
  • The capability for decimal arithmetic
  • The capability for convenient report generation
  • The capability for accessing and manipulating masses of data (typically made up of heterogeneous data structure).

“COBOL is either good or adequate in all 4 (except for database access and GUI construction, they were designed into the language from the outset), whereas the COBOL replacement languages, like Visual Basic and Java are good at few if any of them,” Glass says. And as language designers started to take more of a universal, flexible approach:

“The unique capabilities of COBOL and the business reasons for them were lost in passage of time.”

This was true as of 1997. So, at least until the late nineties, there really hasn’t been a successor that could carry out the massive batch processes as sturdily as COBOL.

But the even bigger reason not to rock the boat is the sheer size and cost of replacing billions of lines of COBOL that exist today. Many of these programs contain sensitive information about people, like social security numbers, banking info, credit card info and healthcare records.

Creators of COBOL invested 2 trillion dollars for the universal language. Businesses worldwide run on over 220 billion lines of code today. It would be a herculean feat to replace every single business program with a brand new language without introducing detrimental bugs. Hence, the cost just hasn’t outweighed the benefits of replacing COBOL.

The Case for the COBOL Comeback

Although COBOL is currently out of sight and out of mind, businesses have to focus on restitching the antiquated fabric of their infrastructure…eventually. Consider the average age of the COBOL programmer today.

One survey of IT managers from 352 companies finds:

Age of COBOL programmers

That survey was taken 9 years ago. In 2014, Micro Focus says that the average age of COBOL programmer is still about 55-years-old.

“Without a doubt, it is a challenge to find a developer in Cobol who is not nearing retirement age,” says Dale Vecchio, research vice president of application development at Gartner Inc. “In 2004, the last time Gartner tried to count Cobol programmers, the consultancy estimated that there were about 2 million of them worldwide and that the number was declining at 5% annually.”

COBOL programmers are starting to retire; meanwhile, there’s no interest from young programmers to take on COBOL challenges. So, what will businesses do to keep maintaining their mission-critical programs?

COBOL skills will be in demand to reverse-engineer pivotal mainframes. And as time goes on, the market will need to correct this skill gap by boosting the value of COBOL programming skills, drawing more engineers to learning the language.

Some COBOL-heavy organizations, like IBM and Micro Focus, have already developed programs to promote COBOL in younger generations. So far, IBM has developed curricula in association with more than 80 colleges and universities. Companies in Dallas are also doing something about it as well.

Dr.Leon Kappelman, professor of Information Technology at the University of North Texas told the Wall Street Journal:

“Four years ago, local Fortune 500 employers encouraged the university to offer Cobol courses. Now, graduates who take Cobol electives earn starting salaries of $75,000 compared to starting salaries of $62,500 for those who did not.”

Plus, many forums and online discussions about the language illustrate that…guys…it’s really not that bad. It’s important to note that, unlike modern languages, COBOL is not designed to be versatile.

Once you adjust your expectation, COBOL isn’t as ugly. Some programmers enjoy the puzzle aspect of maintaining COBOL-based mainframes, like figuring out the exact line of code to fix an existing script. Others find the stable environment allows them to focus on the business aspects of the program. It’s why the few universities that offer COBOL courses mask it under “Intro to Business Systems Programming.”

As taboo as COBOL might be in the ping pong rooms of modern startup-driven culture today, its influence and irreplaceability will result in a spotlight on the dinosaur language again. Businesses must figure out who will maintain their mainframes when COBOL programmers retire in the near future.

If you ran a COBOL-oriented business today, what would you do to address the looming skill shortage? Tell us in the comment section below!


NEXT: Read the 2018 Developer Skills Report

* The 70-80% stat on total COBOL business transactions is an estimate based on Gartner and Micro Focus sources. 

Comments (220)

  • I’d rather take $12,500 less per year to NOT have to program in COBOL. I’m a Perl programmer and I took the COBOL class at my college twice but I just couldn’t finish it because COBOL is such a pain. 10 lines of Perl equals roughly 100 lines of COBOL.

    • mfrager
    • July 6, 2015 at 6:21 pm
    • Reply
    • If it’s $12 500 for a newbie today… what it’s going to be for an experienced guy in ten years? I need to invest in a good COBOL book, I think.

      • chx
      • July 7, 2015 at 3:00 am
      • Reply
      • One of The Godfather’s of the language, Don Nelson’s book on COBOL is the best, you can purchase on Amazon

        • Anna Pearl35
        • April 3, 2018 at 3:21 pm
        • Reply
    • I’m a Perl programmer, but I can’t get a job in that area. Therefore I do COBOL.

      • Patterner
      • July 7, 2015 at 6:18 am
      • Reply
      • Would be my attitude. I am not worried about the future of COBOL and when the jobs end, I worry about my future and if I die before my retirement money runs out.
        Work is not necessarily fun, that is why they pay you. They currently pay more for some trailing-edge programming knowledge because somebody with 30 years ahead of them in programming does need to look at how viable the knowledge is. COBOL pretty much stays COBOL. However how long will Perl last and how long will your current employer stay up with the times.
        Any language, new or old, can go stale, and you can rot on the vine. I work in C# today, did my last, and best COBOL project in 2012. But you need to keep up constantly with SQL and C# versions or you will be even more lost than being a COBOL expert.

        • carlo151
        • October 14, 2015 at 3:30 pm
        • Reply
      • Well perl does suck…. so there is that

        • Stud
        • February 22, 2017 at 11:49 pm
        • Reply
      • Patterner, if interested in Cobol job in NC, give me a call at 919-644-1690 Jim Hall

        • Hi, Jim I had learned COBOL in 1994, but since no opportunities existed in my country (INDIA), I had to shift to FoxPro which was gaining ground. I am amazed to know that still you have openings in COBOL. I am totally out of track and 20 years is more than enough to leave behind what you have learned. Can you please guide me, where should I start to come back on the COBOL track. And last but not least what kind of pay to expect.

          • M S Rahate
          • November 30, 2017 at 1:41 pm
          • Reply
        • Hi Jim, interested.

          • Miguel Diaz
          • February 20, 2018 at 8:56 pm
          • Reply
      • Are you still looking for a job involving Cobol and other languages?

        • LOL

          • Melvin Fink
          • July 15, 2017 at 4:11 pm
          • Reply
        • Yes. Looking in PA/DE area.

          • Joe Malone
          • July 29, 2017 at 11:26 am
          • Reply
    • More fast run program Cobol than a program of 10 lines. Performance or not?

      • ¿Qué?

        • Melvin Fink
        • July 15, 2017 at 4:12 pm
        • Reply
    • @mfrager
      ‘I’d rather take $12,500 less per year to NOT have to program in COBOL’
      And I’d say there would be plenty who’d pay you $12,500 per year to NOT program in COBOL.

      • Kevin O'Brien
      • March 25, 2017 at 8:02 am
      • Reply
    • Yet another “shortage of” article.
      If such articles are to be believed I would have not been unemployed for any length of time. I have a city & guilds certificate in COBOL programming and no one had ever offered me a COBOL job. These days I work as a Delphi programmer and apparently there’s a shortage of those too.
      Programming is a mindset, a good programmer can learn a programming language in a couple of weeks. Don’t waste your time learning COBOL until someone actually offers you a job that needs it!
      Also most mainframes are in the middle of a city so any extra money you get will be spent on living in a more expensive location.

      • I was gonna be mr smarty pants & say ‘but you just said you have a job’ but actually I think we’re on the same page here.
        1)it’s a pita finding good jobs
        2)and F–K COBOL 🐸 !

        • Jonny Cache
        • February 10, 2018 at 11:23 am
        • Reply
    • Perl is even more disgusting than COBOL…

      • Pepe
      • November 24, 2017 at 4:09 pm
      • Reply
    • Yes, but those 100 lines of cobol completly explain what the computer is doingl The cobol programmer has complete control of what is happening, and there is no other language that is as good as manipulating and storing data.

  • COBOL is well optimized for reading a (possibly large) record, fiddling with small parts of it, and putting it back out (all without changing the representation into an “internal” format). This makes it very efficient for certain kinds of data processing tasks.

    • Rich Morin
    • July 6, 2015 at 6:56 pm
    • Reply
    • Because of my COBOL background, I have surprised younger programmers by manipulation of strings of data. I have written systems that start off reading a SQL table, then writing to flat files on the local CTemp areas to filter and parse data for exporting to vendors that do printing. Doing that is sometimes easier, and usually much faster that running complex SQL statements to select out the data you need. And it takes the load off the database server.
      Something learned from a background in COBOL. Also, there is no better language to work with money as your data.

      • carlo151
      • July 7, 2015 at 1:06 pm
      • Reply
      • COBOL was said to be dying in 1970 and in 2015 – 45 years later it’s still here. UNIX and other operating systems can’t handle the capacity of mainframes in data heavy applications. The one thing that COBOL & mainframes do well is volume processing. Processing trillions of transactions a day requires throughput and UNIX/LINUX just doesn’t cut it.

        • jerry153
        • October 14, 2015 at 2:46 am
        • Reply
        • This: “The one thing that COBOL & mainframes do well is volume processing. Processing trillions of transactions a day requires throughput and UNIX/LINUX just doesn’t cut it.”

          • Ghost Writer
          • December 16, 2015 at 10:34 pm
          • Reply
        • Nah, that’s just a straightforward lie. COBOL is there because the costs of migrating to something different. The 100% of the TOP 500 supercomputers of the world uses Linux, get a clue.

          • Pepe
          • November 24, 2017 at 4:10 pm
          • Reply
  • I became a programmer through a COBOL training program at a company in Michigan, work as a python programmer in Silicon Valley now, and trust me, the language is horrible. Once you adjust your expectations, the language still has no data structures other than tables, no scoping, no libraries, and it doesn’t lend itself to OO design. Sure it can be fun tracking down weird bugs that we don’t get with modern languages because we know how to manage memory and scoping and can write OO code, but that doesn’t mean it’s a good language to write things anymore. Systems use COBOL because the business requirements for the program are not understood well enough for any one person to be able to write new specs; rewrites are too massive of an undertaking especially in such high stakes areas. The existing code isn’t going away, but writing new systems in it is ill-advised.
    Another problem is that the language itself can be learned in probably a week, that’s not where the skills vacuum exists. All the tools that go along with it take a bit longer, but the biggest challenge is that because the language is so rudimentary, many ‘helper’ programs have to be built in house. This is a pre-unix, pre-open source paradigm. You need to be trained in the specific system’s idiosyncracies and ‘libraries’, and there are a ton of them. This is secondary to the language itself. Getting a developer up to speed is always a challenge, but with COBOL it’s much bigger because the code bases are so much more sprawling and complex, and you can do nearly nothing without specific knowledge. You can’t teach that in college because there isn’t a 1 size fits all approach.

    • Justin Lippi
    • July 6, 2015 at 7:18 pm
    • Reply
    • Wow, absolutely nailed it on the head in my opinion. I started my programming career working on COBOL programs for a couple years. I eventually knew I had to get out of that and back into others if my career was going to stand a chance.
      Yes, the mainframe is very fast, but I have seen Java applications be just as fast or faster especially with all of the third party software out there. Those COBOL programs are huge and have easily 25+ years of business logic baked in. Not many people are willing to regather all of the requirements necessary out of fear for missing the smallest detail.

      • Lee
      • November 29, 2016 at 11:53 am
      • Reply
      • Hmmm. Sounds like Spring to me.

        • William Lightner
        • September 7, 2017 at 7:05 pm
        • Reply
  • I’ve programmed tens of thousands of lines of Cobol and perhaps a hundred thousands of lines of C. My Cobol use is some decades ago, but some things don’t go away.
    The design of Cobol is broken, for those who know modern programming concepts. No, it cannot be ported to Java. We can fix the worst features of Cobol with a few simple adjustments to control structures, call and perform, enhanced class conditions, and a very modest addition to the notion of data types. The new language compiler must hardly be different from the existing Cobol compilers.
    And translation to the modified language could be programmed reliably, if the new language were conservatively and carefully designed. We have the time and the talent. No, a new Cobol should not have pointers, garbage collection, inheritance, pattern matching, multi-threading, or other hyper-modern stuff.
    The main advantages would be to reduce new bugs and to attract more programmers with a more modern orientation.
    The addition of totally new features, such as a hash-map (Isam anyone?), would be simpler to implement as there would be no conflict with existing code, and these new features could be totally ignored. The language translator could fix most identifier name conflicts.

    • AreaMan
    • July 6, 2015 at 8:11 pm
    • Reply
    • “garbage collection … or other hyper-modern stuff”
      Garbage collection originated with LISP, which predated COBOL.

      • truth_machine
      • July 8, 2015 at 3:18 am
      • Reply
      • Very true. However, GC is still too modern for Cobol. Let me say it another way:
        Adding GC to Cobol would make it a different language. This would make it harder to migrate to.
        As a side note: I learned at University in the 1960’s that Lisp was obsolete and would never be used again. Boy was that wrong.

        • AreaMan
        • July 15, 2015 at 6:29 am
        • Reply
    • I guess Multi-threading is managed by cics, that by the way is an awesome transaction processor…I guess is cuestion of using the right tool

      • Juan Manuel
      • November 30, 2016 at 3:44 pm
      • Reply
  • It would be interesting to see this point developed:
    4. The capability for accessing and manipulating masses of data (typically made up of heterogenous data structure).

    • solidsnack
    • July 6, 2015 at 11:43 pm
    • Reply
  • I taught myself C64 basic, trained on COBOL, got a job in PICK another legacy OS/database/language slightly younger than COBOL but better. And now I’m a Microsoft Stack DevOps – C#, SQL, Azure. COBOL is ugly, horrible and aweful and PICK less so. You’d have to pay me double my Microsoft Stack salary to work on PICK and tripple to work on COBOL – WHY? Because the longer you stick at a legacy IT software platform the more you become unemployable so you need to pay me that risk. I’m already at risk with my current role through a cheaper work force overseas or via immigration.
    I would actively discourage graduates from learning COBOL – it is soo far removed from current technology – it’s obsolete for a reason. These monoliths need to get with the program and change with the times like everyone else and they could have started 9 years ago.

    • Dean Goddard
    • July 7, 2015 at 6:44 am
    • Reply
    • Agreed. A good example of replacing the legacy applications is the Alabama CARES project. It’s a 3 to 5 year project that is being converted from COBOL to ASP.NET. Eventually, all organizations will need to do a similar project to get off the mainframe.

      • JY
      • July 7, 2015 at 12:57 pm
      • Reply
      • Instead of a 3 to 5 year project… maybe they should have considered providing access to the “legacy” applications as services using a ReST API served up through zosconnect. Just a thought! See also http://www.redbooks.ibm.com/abstracts/sg248324.html

        • CEL
        • December 9, 2016 at 9:18 pm
        • Reply
  • If you adjust your expectations, then C is user-friendly. Adjusting your expectations can change everything bad to something good. So this doesn’t count.

    • ReBoot
    • July 7, 2015 at 7:58 am
    • Reply
  • Really interesting piece about the continued viability of the language. And it raises a good question about skills – and whether the future generation of app developers will have the skill or appetite to maintain these must-not-fail COBOL systems. This is an enterprise resource planning question as much as it is a question of taste for any developer. The laws of supply and demand will dictate that any gaps will be filled, especially if the roles become well paid. The smart CIO is going to have to build a resource plan for COBOL as well as any other technology in play to get in front of this. In the middle of this is newer COBOL technology and arrangements with academia to put COBOL back on the syllabus. Interestingly this is already being done successfully in a number of institutions in support of a number of household name organizations. The so called ‘skills gap’ is just an IT management planning task, just as skills for any other important technical function must be planned for.

    • Derek Britton
    • July 7, 2015 at 8:48 am
    • Reply
  • I was stuck trying to fix a COBOL program when I was a junior programmer back in the mid ’80’s it was horrible then and everyone made the same excuses this article makes. “It’s To Expensive To Replace All That Code”…The only damn reason there is so much code is that the language demands you write a hundred lines of code for something that should take 5 lines of SQL or even PERL. The problem is that even trying to maintain this mountain of bad code is a loosing proposition, the tools are antiquated, the compilers are horrid, even the OS’s they are running on are starting to end of life. What is going to happen then? Who is maintaining the environments and tools, let alone the programs themselves? Heck the programs I was trying to fix were running on a UNIVAC – does UNIVAC even still exist?

    • Thomas Chizek
    • July 7, 2015 at 12:34 pm
    • Reply
    • Problem is not the code, but it is the business rules. Companies laid off the old coders also lost the knowledge of everything the program was doing within the company. Maybe you change something to create an easier to read report so you did not need to run the job anymore, only to find that another program read in the same data that accumulates all year and sends the 1099’s out. So you spend all January trying to recreate the lost data!
      But seriously, some code was real scary stuff. I always liked to tackle it because I was more a maintenance programmer than a new developer. I specialized in reading code written by others. But the worst was the early COBOL code that was migrated from assembler by an assembler programmer. It was COBOL that looked like assembler language.

      • carlo151
      • October 14, 2015 at 12:07 pm
      • Reply
  • Things are going to be interesting. In one hand, code that is not maintained rot, in the other hand you will always have people willing to learn a ancient language if you pay enough. In one scenario mantaining COBOL will be feasible, but it will just be unpractical, not because COBOL programmers will be expensive, but because you will have to always mantain a army of them ready and have them “patrol” the code. Is just like mantaining my old car, at some point is just cheaper to buy a new car.

    • Tei
    • July 7, 2015 at 2:20 pm
    • Reply
  • You make a compelling case, Ritika; but in terms of jobs, the numbers don’t seem to support your conclusions. I just counted the number of job openings near Seattle posted on Indeed for several languages. C#: 2877. C++: 3029. Java: 4096. Cobol? 25.

    • It is the jobs to employees ratio. 25 COBOL with 11 people in the area with the skills.
      I work in C#, but in that area your skill set also narrows. I work with non-web programs that do long running database and sometimes print output. Those C# skills do not translate to the web app skill set since you need to know JQuery, or they want you to know cloud development, etc, you can really split the skills out to a very fine level.
      The next split comes with the business model. If you worked in government they do not think you can work in the business world. If you are in insurance, they do not think you can cut it in banking. And medical is in its own world, it splits between billing/insurance, and medical imaging/patient records.
      In some respects the COBOL might be an easier fit because of the fewer flavors. And you might need to search old school cities with high frequency back end programming like federal government or large state agencies in large states, or banking in NYC or Dallas, or energy in Houston or Oklahoma. Or even the old Hartford area in insurance, years ago they had lay-offs in all these sectors as front ends went web or off-shore. Today those same people they kept on are looking for a lake house and no alarm clock.

      • carlo151
      • October 14, 2015 at 11:58 am
      • Reply
  • There’s a scary thought: the resurgence of COBOL. One wonders if, once it becomes a skill that’s truly in demand, a whole bunch of young programmers will become specialized in it, and then start writing their own things in it, and then develop an object-oriented version of it (perhaps this has already happened) and an entire new generation of nastiness will be born… “add desperation to ignorance giving COBOL,” as it were…
    “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.” — E.W. Dijkstra (from this paper: http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html in which he also states “…with respect to COBOL you can really do only one of two things: fight the disease or pretend that it does not exist”).
    Right – back to work: I have some COBOL programs to write…

    • Meh, E. W. Dijkstra is overrated.
      How many customers has he served?
      OK, now how about COBOL? How many has COBOL served?
      More than Dijkstra methinks.
      Nice try, Dijkstra you old… guy

      • E. W. Dijkstra
      • December 17, 2016 at 3:03 am
      • Reply
  • You can tell it is actually NOT THAT VALUED by the C-Suite because the CIO would just say: “Open source license it, put it up on Sourceforge or github, etc. and let everyone cooperate on a port project.” They keep saying there are tons of banks, etc. which would benefit. It can’t be a security concern because the code is too idiosyncratic to hack.

    • Who keeps saying that?
      The government?

      • The government
      • December 17, 2016 at 3:06 am
      • Reply
  • the best COBOL version I ever saw was on a Wang VS
    its not a bad language, its just wordy and its not ‘hip’

    • TheDjoker
    • July 7, 2015 at 8:51 pm
    • Reply
  • This article is good, but could be better. Please run spellcheck and proof read … “business programing” and “most all modern languages” aren’t proper English. Also, even if Glass’s claims were true, which is dubious, they ignore the numerous ways in which modern languages are far superior to COBOL. As you say, it’s those 220 billion lines of code that are the reason COBOL is here to stay. You say that “it’s really not that bad”, but your link really doesn’t support that. Also it is false that the DoD mandated COBOL for all businesses — something that it could not have done. The DoD did mandate *ADA* for *contracted software*, but that’s a far cry from “all businesses”. Also, Grace Hopper’s influence on COBOL was mostly through FLOW-MATIC, her own business language for the UNIVAC. An important fact about COBOL: there were short- mid, and long-range committees. COBOL is the product of the short-term committee and the other two committees were disbanded. “its influence and irreplaceability will result in a spotlight on the dinosaur language again” — no broader a spotlight than this and a couple of other similar articles.

    • truth_machine
    • July 7, 2015 at 11:15 pm
    • Reply
    • Whoa, I’d ask for my money back

      • Grace "Ada" Hopper
      • December 17, 2016 at 3:13 am
      • Reply
  • When I started in the 1970s, large companies would pull people from the business units and train them in-house on Cobol. Or business people would be sent to offsite consultants who did the training. Very few business programmers were developed by the universities. University graduates generally could not tolerate the Cobol work environment.

    • mcon
    • July 8, 2015 at 11:49 am
    • Reply
    • Of course these pampered collegians could not tolerate it, it meant doing actual work. COBOL is a man’s language.

      • Shilly
      • July 6, 2016 at 2:03 am
      • Reply
      • That’s funny.
        Back in the day, a friend in the biz always said assembler was the masculine language and COBOL was the feminine language
        To this day, I can’t say he was wrong..

        • BALR R14,R15
        • December 17, 2016 at 3:17 am
        • Reply
        • I’ve always liked talking to females. 😉
          I’ve been gainfully employed for 31 years as a COBOL CICS DB2 developer and never lacking for work, mostly in the Transportation sector. Making a big business hum operationally and securely is being down in the trenches. When you are the CORE systems, the Business depends upon you. Sometimes you feel like Mr Scott controlling the Warp Engines. The Captain will seek you for what you can do for the Enterprise. Saved many implementations because some vendor project could handle something, but some quick COBOL coding would compensate and save the day.
          I’ve witnessed a lot of languages come and go, but COBOL has remained King throughout my career. I’ve come to appreciate the consistency and beauty of COBOL. The naysayers can continue predicting the demise for another 20 years and will be equally wrong again. They overlooked that COBOL has matured and grown itself over the years. There’s a lot to be said for stability and reliability.

          • padimm
          • December 20, 2016 at 3:54 am
          • Reply
      • @Shilly
        I very much agree with the sentiment of your comments.
        And the ‘ work ‘ aspect of COBOL means you’ve really got to master the logical thinking aspect of your brain.
        Thinking is not such an encouraged thing now and therfore COBOL has red hot enemies.
        The big rewards are for people who are expert at parroting and not questioning.

        • Kevin O'Brien
        • March 25, 2017 at 6:04 am
        • Reply
        • What a ludicrous hypothesis.

          • Pepe
          • November 24, 2017 at 4:15 pm
          • Reply
  • Hard to believe that soon all of the Cobol programmers will be retired or dead. If you thought that Y2K was bad, wait until Y2.1K!

    • Jim L
    • July 8, 2015 at 10:18 pm
    • Reply
    • Noooooo!!!!
      I don’t want to be retired or dead.

      • Retired R. Dead
      • December 17, 2016 at 3:18 am
      • Reply
  • I’m 26 and I’ve been a Cobol programmer for little more than a year. Here in Brazil, Cobol programmers are the highest paid programmers in the market. Banks, and particularly Insurance, which is the area I work at, make billions of dollars of profit every year and, at least to this date, this trend continues despite the general Brazilian crisis.
    There is no shortage of people who know Cobol: a person with a little programming background would get the language in a day. Tools that are usually necessary for the work, such as JCL and some IBM utilities, can also be learned in a short period of the time. The real shortage is of people experienced with the codebases and the business rules they implement. Cobol codebases are usually gigantic messes of spaghetti code, magic numbers and ad hoc additions. You would get scared at what programs and systems that process millions of dollars of your money daily look like when you open the hood.
    Equally as important, there’s an absolute shortage of tools: things that other people take for granted, such as automated testing tools, are either non existant or not used. As a result, people get (rightly) afraid of making small changes in the code and, when those changes are made, we often have to learn an entire set of other poorly designed processes to test it.
    People who can quickly navigate this mess, who know what the magic numbers stand for and such, are very highly paid. I’ve seen those usually older gentlemen solve problems that involved huge amounts of money over phone calls. Despite efforts on the bank’s part to train a new generation, some systems are almost effectively orphaned due to no one being able to understand them.
    Just as a final observation: Cobol sucks. It’s not bad at what it does (processing sequential files) but, in general, it sucks. It’s a powerless, unexpressive language. It’s definitely not a language to be taught at Universitites. Students need to learn and solidify Computer Science fundamentals and have an appreciation for ideas and design clearly expressed in code. If and when they want a job, then they apply to a Cobol position.

    • Marcus Souza
    • July 9, 2015 at 1:55 pm
    • Reply
    • Oh now, Marcus.
      COBOL doesn’t suck.
      It’s not great but it doesn’t suck.
      You know what sucks? Octal bit flag programming in 256 bytes of ROM on an old NCR cash register to set up sales tax tables.
      Compared to that, COBOL rocks!

      • Keepum Cummins
      • December 17, 2016 at 3:24 am
      • Reply
      • COBOL is to programming languages is what The Beatles are to music. Every musician at Coachella would love to have what the Beatles had. If you want to program for the rest of your life learn C orJava and tomorrow there will be a new language. But if you want to be the CIO of a fortune 100 company, learn COBOL because that is where the business is hidden.

        • AQ
        • April 17, 2017 at 7:21 am
        • Reply
    • @Marcus Souza
      ‘ a person with a little programming background would get the language in a day ’
      ‘ It’s not bad at what it does (processing sequential files) ’
      Please think about what you are saying.

      • Kevin O'Brien
      • March 25, 2017 at 6:28 am
      • Reply
      • The reason COBOL is still around is that it is *very* good at what it does, and what it does *needs* to be done. Usually they are critical to the business. And usually replacements done in other languages are not as fast, clean, efficient or reliable. For example: research shows (no, I don’t have a reference. Look it up!) that for the same program implemented in Java and COBOL, the COBOL implementation will have half as many bugs as the Java version.
        Think about that. I know I had trouble with that thought for some time.
        Then consider that the hardware most non-COBOL programs run on (Intel & Copiers) was designed to run COBOL.
        Then consider that for the most part the replacement of COBOL by any modern (and thus “superior”) language has not gone well. At all.
        The problem is, most attempts to migrate from mainframe/COBOL to “modern” languages & platforms *fail*. There are research reports that verify this (and have been doing so for more than a decade. The numbers I saw, now woefully out of date, were a failure rate of 90%. I haven’t seen any more current numbers, though).
        At the company where I am working the migration off of the mainframe has been going on for roughly 10 years, and cost tens of millions of dollars. The server farm & support now costs more than the mainframe (and is still expanding) and the core, critical business processes are *still* running on the mainframe.
        The support costs, however, are almost all dedicated to the new, “improved”, and non-COBOL code.
        Personally, I have been following with interest the development of the GNU Cobol compiler suite. And I noticed that last year COBOL twice (at least) *rose* into the top 20 languages on the TIOBE index. In fact, its percentage of market seems to be steadily rising overall (I can’t afford the 5K$ required to buy the raw data from TIOBE to verify this, but I’d love to). It now hovers at #26, and other languages rise (and fall) around it.
        I’ve experimented with the GNU Cobol compiler. I’ve done two small projects, both of which required dealing with a lot of data. One was 3+ billion lines (to avoid the cost of re-running a length Java process, I had to do a transform on the {gasp!} sequential data output. Processing time: less than 30 seconds. That, plus the time to write the code, was accomplished in less time than would have been required to regenerate the data via the Java program.
        The second was approximately 35 billion lines of data. Again, a transform on sequential data (we don’t do that anymore, do we?). Execution time (on an Intel, Windows box): approximately 3.5 minutes. It took me longer to write this program, but the process was all from scratch and the parsing required was fairly complex.
        Do that in Java on 1 Windows box. I could have done it in C/C++ or Pascal, and with some effort achieved similar performance. But in this case it was easier to do (for the most part) in COBOL.
        I don’t think COBOL is dead, yet. And when, for the first time in history, we have a *free* production-quality COBOL compiler (sometime later this year, most likely…although it is already good enough for all but some esoteric things done in mainframe IBM COBOL), I expect we’ll see something of an upsurge in interest.
        Spoken as someone who began investing in Java programming at version 1.12, and delivered his first Production Java program (the first in the company at the time) in Java version 1.14 (which program is still in use, although no longer on the mainframe…)
        Learn to use many tools, and many languages. Use the right tool. Sometimes that is (still) COBOL.

        • William Lightner
        • September 7, 2017 at 7:47 pm
        • Reply
  • Perhaps the conclusion should be the opposite. Instead of training young people to program in this dinosaur language these old, crusty, ultra conservative corporations should finally upgrade their systems to something that’s less than half a century old. Maybe the lack of qualified programmers able to maintain them will finally force them to do so.
    There’s nothing good about COBOL. The only reason it’s still around is because it’s used by industries that are entrenched & completely impervious to change. Once COBOL based systems become impossible or prohibitively expensive to maintain there will be no choice, but to rewrite them in something that doesn’t suck to program in.

    • ranndino
    • July 15, 2015 at 11:37 pm
    • Reply
    • spot on

      • Swapneel Prasanth Mishra
      • July 21, 2015 at 5:58 pm
      • Reply
    • COBOL is a problem at my university. There is a system written in COBOL that handles critical information, including the list of courses offered each semester, students’ schedules, and grades. The developers who maintain that system have many other responsibilities, so they can’t spare the effort to rewrite the code. That’s resulted in a looming threat: that one day, the system will break down. There have already been several close calls and it’s costing more and more to keep it alive.

      • Humberto Diaz
      • September 8, 2015 at 5:23 am
      • Reply
    • Couldn’t agree more.

      • Pepe
      • November 24, 2017 at 4:14 pm
      • Reply
  • cross compilers!!! they are already in the market for churning code out from pre-built programes .. since COBOL is a structured language , it will be easy to built a compiler to convert it into a modern language like C++ or Java. You don’t need all the programmers in the world to do that.

    • Denny Jose
    • July 25, 2015 at 3:35 am
    • Reply
    • Aside from the possibility that cross compilers may not always be 100% accurate, consideration ought to be given to the fact that Mainframe systems (Z/OS) are, collectively, the biggest hosts of the programs written in COBOL language!
      The datatypes (such as packed decimal, zoned decimal) and encodings (such as EBCIDIC) used are unknown and unheard of to the most modern languages, including C, C++ and JAVA; whereas the resident data sets and databases (like DB2) on mainframes use those structures heavily. There is also barely any provision in the modern day programming languages to processes “indexed” files.
      Mainframe systems also significantly rely on data stored on “magnetic tapes”. In order to give the programming language a capability to read those “tape files”, you’d also need to write a new device driver, as the hardware used to mount / unmount tape files is totally different from what we see for CD Drives, HDDs or Flash Drives.

      • Dhruv Saxena
      • August 14, 2015 at 11:03 am
      • Reply
    • Cross compiled programs are really really hard to maintain. I have worked with some. the code is almost unreadable.

      • pete schenk
      • January 19, 2017 at 11:54 pm
      • Reply
    • @Denny Jose
      ‘ You don’t need all the programmers in the world to do that ‘.
      So how many programmers do you need?

      • Kevin O'Brien
      • March 25, 2017 at 6:31 am
      • Reply
    • @Denny Jose MicroFocus does that with Enterprise Developer — you can compile your Cobol program into Java or C# byte code

      • ed08857
      • April 18, 2017 at 2:06 pm
      • Reply
  • There are also a few independent educators that teach COBOL and also bring COBOL programmers up to date with XML capabilities that the compilers now offer.

    • ps2os2
    • July 29, 2015 at 4:29 am
    • Reply
  • I would post a comment, but this screen is white-background with black letting. My age prevents me from interacting with such a color-laden screen.

    • Ann Onymous
    • July 30, 2015 at 1:23 pm
    • Reply
    • I Use 5 Browsers – All Of Them Have Color Tweaks Or Extensions That Allow That Tweaking.
      My Favorite Tweaking Is Black Font On Soft Grey Background ( Links Use Other Colors ).
      Ask For Help – No Need For You To Avoid Commenting, Whatsoever.

      • A41202813GMAIL
      • February 16, 2016 at 10:15 am
      • Reply
  • Back in 2000 I did raise the suggestion that if we could get Cobo to run in a real time interpretive mode, like REXX, then Cobol everywhere was a real possibility. Unfortunately the powers that be at that time were a bunch of recently out of college fastpaths who poo pooed the idea. What a shame , that would have been a real money spinner and kept Cobol on College curricula. OO languages may be faster to code but the runtime pathlength is horrendous and maintenance a nightmare.

    • Ian Griffiths
    • October 12, 2015 at 9:16 pm
    • Reply
    • I think that would not have made Cobol en vogue. Cobol is a very simple procedural language and allows simple flow of statements. Many of the sophisticated programming techniques are not possible in it with addition to being extremely descriptive in nature. Lack of any common libraries and 1000s of home grown solutions have turned it into a learning nightmare.

      • Some1
      • February 1, 2016 at 7:29 am
      • Reply
  • COBOL isn’t taught much in the US because companies don’t want to hire Americans when they can outsource the work to third world countries for a much lower cost.

  • COBOL must die. But slowly and painfully.
    Maybe, just maybe, we could have a runtime or a VM that manages COBOL code, and communicates with the underlying hardware (a copycat from Java/Erlang);
    Heck, this VM could be a BEAM or just Java.
    It could be a small runtime for COBOL code.
    That is step one.
    Step two is replace all of the world’s COBOL hardware from machine-compiled COBOL to VM compiled-bytecode COBOL.
    Performance? Nah. Not a problem. The VM can make JIT and smart optimizations on compiled bytecode. It would get smarter with time. This is a long time project.
    Step three is develop a new language. A modern language. A high level language. For generations to come. Or bindings from different languages to this VM.
    That spins up a whole new world. Suddenly, everyone wants to write some finnancial app.
    It’s a problem, but we must pave the way to modern programming languages and environments.

    • Bruno Luis Panuto Silva
    • October 22, 2015 at 6:37 pm
    • Reply
    • bruno do u know any cobol programmers with modern language expertices like C++, C#, etc. I have 30 yr old software running on Cobol/Linux and would like to modernize as 4 programmers are ready to retire

  • Feels like the “teacher shortage” problem that has never shown up. The biggest problem I have is not with COBOL but generally the platforms is run on. For example,. if it is on a mainframe running Z/OS then you are stuck with an inferior database as well as a platform that is difficult to interface with(limited web service support, etc.). The biggest reason is correct that there is so much that runs on it and it is expensive to rewrite, but other than that I see no advantages. Code is not self documenting, test driven development doesn’t really exist, and much of the code is not reusable. I get that COBOL can be coded in a “smarter” way but often not as many COBOL programmers are not programmers but people who moved from analyst to programmer as it was path up. Now there isn’t even good design at the COBOL level as solid application design skills are not developed. It is no wonder legacy systems are so expensive to maintain.

    • Glen Jones
    • October 30, 2015 at 7:09 pm
    • Reply
    • Define “…if…mainframe running Z/OS then you are stuck with an inferior database…”. What database? Much of what you have written makes no sense; COBOL is self documenting (provided the coder took advantage of a descriptive variable name), test driven development does exist (provided that the environments are set up – not a COBOL issue), and code can be reusable (provided the coder understands “how” to write reusable paragraphs and/or linked CALL subprograms).
      This all sounds like you a repeating what someone else told you. But I will agree with one statement – “COBOL can be coded in a “smarter” way but often not as many COBOL programmers are not programmers but people who moved from analyst to programmer as it was path up.”; but the statement was started with “I get that”. Starting a statement with “I get that” implies you have knowledge of or book knowledge of a concept but no practical experience.
      Your comment added nothing to this discussion.

      • Jeff Sullivan
      • December 1, 2016 at 5:05 pm
      • Reply
      • I always get irritated when I hear the “COBOL is self-documenting!” type of arguments. It’s almost as bad as “COBOL programs don’t have bugs!” or “COBOL programs are super resilient!” It’s repeated ad nauseam, with no supporting evidence. I can tell you that as someone who has had to, unfortunately, deal with COBOL code, I can say that I have never found the code to be self documenting.
        The variable names are vague, short, and usually contain encodings that vary from organization to organization. The code is poorly designed with large swaths of convoluted spaghetti code and Gotos that make it nearly impossible to keep track of the flow of a program. The reason for this is less to do with the language itself and more for whom the language was designed for and who did/does most of the coding: non-coders who don’t know their CS fundamentals. Yes, any language can and does have poorly written code, but COBOL makes it easier because of it’s lower barrier to entry and the resistance to add breaking changes from version to version. Features that we learned the hard way are bad and shouldn’t be relied upon are used and abused by COBOL developers everyday.
        True, it’s not all COBOL developer and it’s probably not even close to most COBOL developers (at least in modern times), but it’s far too many. COBOL relies heavily, probably more than any other language, on the skill of the developer who wrote it in order to make it understandable and maintainable. Unfortunately, too many of those developers were either unaware or didn’t care of the effort needed to write solid code.

        • Ryan M
        • November 1, 2017 at 5:44 pm
        • Reply
  • I just to be a COBOL developer on unix clone in 87-90 then in Digital Vax in ~91-92.
    Then moved to other platforms and from time get some extra bucks doing consultancy on COBOL until ~2000.
    Since then I read a lot of blog positings and magazine articles saying that COBOL will return and will bring 1000s of jobs.
    Guess what?
    I’m still waiting for those 1000s of COBOL jobs.

    • Sergio Samayoa
    • December 28, 2015 at 9:04 pm
    • Reply
  • The problem is government compliance. It is no coincidence that the most heavily regulated industries of Finance and Health Care are also the two industries entrenched in old technology. There are plenty of smart IT and Business leaders at these behemoth companies who understand the benefit of a massive migration to a world of SAP and Oracle. However, the compliance risk stemming from any migration bugs would absolutely kill any one of these companies. Back to the matter of compliance, the reason that you don’t see smaller companies disrupting the entire scene is that they can’t afford all the legal/finance/admin/regulatory overhead to deliver all the mandatory government reports. This is what big government looks like. We used to laugh at those old ugly Soviet Union cars? Well now you can start laughing at those old ugly COBOL mainframes.

    • Robert Casper
    • January 12, 2016 at 3:36 pm
    • Reply
    • There are no old ugly COBOL mainframes left. We now have beautiful shiny new COBOL mainframes that are cheaper to run and easier to maintain than the massive estate of mid range servers that would be required to process the same volumes of data………

      • rockyIII
      • January 31, 2016 at 9:23 pm
      • Reply
    • @Robert Casper
      … and once an organization corners the market with their own proprietary software, then what?
      Do they perhaps raise their prices?

      • Kevin O'Brien
      • March 25, 2017 at 6:41 am
      • Reply
  • We are in 2049 and scientists wake up a man who had been frozen many years ago and had a terminal illness.
    – Oh, did you find a cure for my disease? asks the man.
    – No – they answer – we desperately need a Cobol programmer…

    • Lu A
    • January 12, 2016 at 11:40 pm
    • Reply
  • They’ve been telling me that COBOL was dying since I took my first job and it was in COBOL… over 20 years ago. Well I’m still working in COBOL, it’s not dead yet and I’ve found enough work to keep me going. Seems like when the country is in a recession the old tired ‘dead’ languages come out to play (and jobs are plenty). When the country is doing well… the new ‘toys’ come out and tell us old language people that COBOL is dying. I’ll believe it when I see it in front of me.

    • Nicol Smith
    • January 30, 2016 at 5:00 pm
    • Reply
    • I am 23yr old, just started in cobol, is it good to continue or I should move on to some other tech like informatica or big data?
      I am little bit concerned about my future. plz help!!!!!!!!!

      • vjais
      • August 8, 2016 at 6:01 am
      • Reply
      • Do You Know Anything Related To The IBM AS400 Hardware Family ? – The Most Used Language Is RPG, But There Are Companies Still Using COBOL.
        The Site ALL400S Has A List Of Companies That Use The Platform All Over The World.
        Good Luck.

        • A41202813GMAIL
        • August 8, 2016 at 6:41 am
        • Reply
      • @vjais
        I think you should walk away from a computing career.
        No …. RUN!
        The pace of change is too much for most.
        You might have ‘ flavor of the month ’ skills now, but you will have to be relentlessly keeping up with new skills.
        Try any other profession except computing.
        Other professions are evolving at a rate which most people can cope with.
        As you get older, you will have other priorities which are of much higher importance than acquiring skills on the latest combobulator.
        Think – people.

        • Kevin O'Brien
        • March 25, 2017 at 7:01 am
        • Reply
  • What you have to do is kill the business that is using COBOL by disrupting it. For example, say you find a better way of networking ATM’s and you come in and disrupt the entire industry. And of course, you also happen to be writing in more modern frameworks, like Java/Spring or dot Net, so the COBOL is destroyed. In other words, the old line business runs its COBOL until a disrupter puts it out of business.

    • George Campbell
    • February 2, 2016 at 12:06 am
    • Reply
    • @George Campbell I don’t think you understand what you are talking about.
      “For example, say you find a better way of networking ATM’s and you come in and disrupt the entire industry. ”
      What does Cobol have to do with networking those machines?

      • ed08857
      • April 18, 2017 at 2:19 pm
      • Reply
  • bank question papers

    • sudheeratiketi
    • February 9, 2016 at 7:58 am
    • Reply
  • This is a good article. As I read through the comments, though, there are several misconceptions still. First, COBOL does not equal mainframe Second, those commenting on Z/OS don’t really understand the capabilities of the platform. Inferior database? DB2? You can choose to run Oracle and others on the platform. Web server? It has one. Web interface to a COBOL based system – you interact with them every day and you don’t even know it. COBOL has not been static. It has grown and evolved over the years of it’s life and is as capable as any other general purpose language. It has OO features. It runs in virtually any platform. Many commented on a JVM COBOL. There are several variants of this available. I work on COBOL based systems that run on Unix, (Linux and others) as well as Windows and Mainframes of all different flavors. COBOL is just one of many different choices in programming languages and is not less capable because of the age of it’s specification or the platforms on which it can run. COBOL’s biggest handicap is the fact that the systems have worked and worked well. Many just run with NO maintenance. And then years down the road when something is needed it can be difficult to find someone to work on it. Staffing is going to become important in the coming years, but like any other shortage, the gap will be filled by willing and able devellpers of all stripes.

    • ImaPangolin
    • February 15, 2016 at 4:50 pm
    • Reply
  • COBOL is obsolete because the procedural paradigm simply doesn’t work well in a networked environment, where objects and layers make much more sense. It has nothing to do with the language itself, which served us very well when there was ONE central processor and no event-driven programming required. COBOL is still an excellent language for batch processing (where the procedural, rather than object-oriented, paradigm is perfectly adequate) and that is why mainframe sites cling to it.
    Object orientation WAS added to COBOL in the 1990s, but it was largely rejected by the COBOL community. By the time it became apparent that the World had voted with its feet and OO was replacing procedural code as being ideal for networked systems, the OO COBOL boat had sailed. The FACT is that modern languages which were designed for OO, do it “better” (read…”More quickly and easily”) than COBOL, which had OO added as an afterthought. Despite millions being spent annually by COBOL vendors to hype it up, any modern CIO who bet the farm on COBOL would not be employed for very long.
    It is interesting to see the same old figures for COBOL code being trotted out again. These figures came originally from a Gartner report which has since been disclaimed by Gartner, who admit that it is impossible to verify with any reasonable degree of accuracy. There IS a large codebase of COBOL still extant, but it is diminishing every year as more and more companies embrace more modern technology.
    This is a typical article designed to persuade us there is still a case for COBOL, when there actually isn’t. COBOL is to modern programming what Latin and Sanskrit are to literature: useful to have some knowledge of, but pretty irrelevant when it comes to making a living as a writer.
    (Try doing a search on “Cretaceous COBOL Jurassic Java” for more of my thoughts on this.)

    • PeteDashwood
    • February 22, 2016 at 7:54 pm
    • Reply
    • So you are saying that object-oriented code is not procedural? Have you taken apart a Java program? Guess what, sparky, it is procedural. Do you think polymorphism is new and unique? Again, in my day, we called these called procedures where the values could be changed. Yet another non-contributing opinion.

      • Jeff Sullivan
      • December 1, 2016 at 5:13 pm
      • Reply
    • @PeteDashwood
      If you didn’t learn about invalid arguments in business school, then there is a book called ‘ Thinking Straight ’ by a bloke called Beardsley – you should try reading it some time.
      Here are a few examples of the invalid arguments that you have used – assertion, analogy, appeal to authority, ad hominem, non sequitur & slippery slope.
      Take all of them out of your comments – and there’s nothing left.

      • Kevin O'Brien
      • March 25, 2017 at 7:50 am
      • Reply
    • The most thoughtful comment on this page so far. Thank you.

      • brad m
      • April 10, 2017 at 3:28 pm
      • Reply
  • bank question papers

    • sudheeratiketi
    • March 5, 2016 at 4:24 pm
    • Reply
  • “There’s a shortage of COBOL programmers! Learn COBOL, you’ll make big bucks! Supply and demand!” If this idea catches on, there will be a glut of COBOL programmers and they’ll be working for peanuts just to get a job. Remember the ‘shortage’ of people who knew Medical Coding? And the following glut?

    • RoyF
    • June 27, 2016 at 6:22 am
    • Reply
    • Hi Eric,
      I haven’t looked at this thread for a few years and it is unlikely that your “question” is still pertinent, but if you post it publicly or mail me privately, I’ll be happy to respond.

      • PeteDashwood
      • August 24, 2018 at 10:25 pm
      • Reply
  • Is this discussion still going I have a question for /imapangolin AND/OR PeteDashwoodmplease.
    If not I would love to speak to anyone!!! I requested them because they seemed to be on opposite sides; polar opposites, and that I liked. Especially with their experience.
    Thanks so much for your time everyone!

    • Eric
    • October 23, 2016 at 2:41 am
    • Reply
  • Everything you have said is true, I am a thirty year COBOL veteran and I have not been able to land even an interview in a year’s time.
    COBOL is still in high demand, and in use all over the land, and the same can be said for Indian programmers who have displaced Americans in these jobs.

    • That has happened to me several times in several places. This has been building since the 1990’s. “Off-shore” talent taking away jobs from us over 30 year COBOL veterans because they will work longer hours for less money. OH – did I mention that they are willing to learn COBOL? Maybe that is the crux of the problem. Learn it here to keep it here. Bring back COBOL in our “S.T.E.M” learning institutes.

      • Al
      • November 24, 2016 at 10:43 pm
      • Reply
      • Hold on. Americans think Indian programmers are taking their jobs but alas that’s half the truth. These same American companies who fired Americans and hired Indians in an offshore office are firing old Indian IT professionals. And “old” means age 35. So imagine a 23 year old Indian being hired and made to work long hours for “not so great” amount of money and then fired at age 35 because he is “old”. With no governmental social security in India and a family to support and rising cost of living, this so called “cheap” Indian has been taken for a ride of his life by the IT industry. So Mr. American programmer, it is not the Indian programmer that is your enemy. It is these greedy corporations who only want to milk us out for their profit

        • Pat
        • July 6, 2017 at 6:32 am
        • Reply
    • do u have any expertise with modern languages like c++ or c#. I need a cobol programmer in hillsboro, nc

  • I was a COBOL programmer for many years, before becoming a system admin in windows, and a security admin.
    I was always a ‘techie’, and when I learned COBOL I did take the books home and read them on my own. I also made sure that I understood CISC, DB, and BAL. This gave a great insight into what you can accomplish with COBOL.
    For me, understanding the technology and what you can do with the technology allowed me to excel in the programming part of my career. COBOL is as complex or as simple as you choose to make it. If you code just to ‘get by’, your code is not going to be very flexable.
    COBOL is tool to some, to me it’s akin to learning an instrument, i.e. a guitar. You just strum and get by, or you can go much more in depth.
    Sadly the only issues I ever saw in my programming days, was management not caring about the ‘quality’ of work, but rather ‘just get it done’. If you build something cheep, your quality is going to be ‘cheep’.

    • Donald Swartz
    • November 19, 2016 at 6:45 pm
    • Reply
    • I think you’ve got an undefined variable name towards the end of your code.
      01 ww-cheap PIC X(05).
      88 cheap value ‘cheep’.

      • Kevin O'Brien
      • March 25, 2017 at 4:37 am
      • Reply
  • COBOL, in the MVS environment, was used extensively, when I worked in the insurance industry in the 1980’s. Although, one person, on this blog, indicated that COBOL didn’t shine with event driven processing, the programmers where I worked were able to adapt it to do so, as part of large system implementations. COBOL, was used extensively in both the online (TP), environments and the batch environments, so a common core, among programmers, using COBOL, was important. Systems programmers, and application programmers alike, coded in COBOL, or 370 assembly language for that matter. As a side note, the editors back in the day (TSO/ISPF), still blow away any editor, or graphics based IDE today, and coding COBOL was a joy, for both handling transnational and event driven programming tasks, to batch systems, or resource management, including networking applications. Those who think COBOL, was purely an application programming language, forget that resource management, (for example) is just another systems level application, and many of the advanced concepts used widely today, were implemented at least once, in a COBOL, MVS environment. The old nothing new under the sun adage.

  • COBOL, in the MVS environment, was used extensively, when I worked in the insurance industry in the 1980’s. Although, one person, on this blog, indicated that COBOL didn’t shine with event driven processing, the programmers where I worked were able to adapt it to do so, as part of large system implementations. COBOL, was used extensively in both the online (TP), environments and the batch environments, so a common core, among programmers, using COBOL, was important. Systems programmers, and application programmers alike, coded in COBOL, or 370 assembly language for that matter. As a side note, the editors back in the day (TSO/ISPF), still blow away any editor, or graphics based IDE today, and coding COBOL was a joy, for both handling transactional and event driven programming tasks, to batch systems, or resource management, including networking applications. Those who think COBOL, was purely an application programming language, forget that resource management, (for example) is just another systems level application, and many of the advanced concepts used widely today, were implemented at least once, in a COBOL, MVS environment. The old nothing new under the sun adage.

  • I love cobol programming so much! And i also thank cobol…

    • Marky Briones
    • November 30, 2016 at 3:04 am
    • Reply
  • Today’s mainframes and today’s COBOL are faster then just about any other language even hand crafted Assembler. When the author talks about a language developed 10 years before man walked on the moon etc it is really just a display of ignorance.

    • John J. Leonard
    • November 30, 2016 at 1:23 pm
    • Reply
  • I work as a Systems analyst on mainframe systems, and have developed on them for 15 years. I also design on JAVA, .NET, Terasata, and Cloud. In reading the comments there has been some good discussion generated and, in my opinion some pure tripe. YES there is OO COBOL. There is also a newer version of COBOL, 6.1 just recently released. I agree with the statements that the language is an art form or thought process of combining code with JCL or other script. COBOL is also highly effective in DB2 stored procedures and CICS web services. In fact the capabilities that many othe languages are renaming or discovering today were discovered and used in mainframe development years ago. I notice many languages try to repackage the same concepts and pretend they are the latest thing (SOA amyone), I also note that IBM also has begun showing these “dinasour” mainframes not as mainframe but now as large scale web server through their service capacity.
    As for the off-shore discussions. I work with many companies around the world and do find many programmers in India and Mexico. However, it is rare, that you find a good one that is beyond a 1st or 2nd year skill level. Every language has its strengths and weaknesses. The real key is to combine this strengths into a well designed product useful to the end user. I see way too often developers creating nasty WMD code because that was the only skill set they knew and, god forbid, they look outside of their realm or consider that antique language. As for COBOL developers, admittedly, many of us were taught, and still code as if it were still 1975 and refuse to use the more robust capabilities of Enterprise COBOL (GO TO and EXIT anyone?). Abilitity to focus on the business problem rather than worrying which version of Spring, Maven, Cucumber, or other tools is an advantage. Are you developing to solve real problems or for the sake of the technology? We develop to make life and processes easier. As developers we have to get past our platform ‘bigotry’ and see the bigger picture. If COBOL is not your thing and JAVA is then so be it. By the way, UNIX/LINUX is only 1 year younger than Mainframe. Didn’t see anyone mark that as a dinosaur. Just sayin’.

    • Bill Wester
    • November 30, 2016 at 5:08 pm
    • Reply
    • Pretty good stuff there Bill, but let me throw in a few more random thoughts.
      What do people mean when they talk about Cobol or any other language being fast or slow?
      Execution speed depends on the executable code generated by the compiler and is not readily apparent to the programmer. Well written Cobol with an optimising compiler is pretty slick.
      Speed of writing a program depends in part on the ability of the programmer to use facilities to include pre-written code, such as record layouts, or even Procedure Division code.
      Then there is the ability to reuse separately compiled modules.
      It is over 20 years since I have written Cobol and I taught myself from the previously mentioned books, published by Mike Murach and Associates, in a few days and was highly proficient. Cobol was easy. I could start writing Cobol again tomorrow.
      One of the arguments I have heard for its longevity in the commercial world is that it is so ‘English like’ that non-programmer auditors can easily read it, something not possible in other languages.
      That said, I also have some experience with OO languages and acknowledge the benefits of OO.

      • Graeme
      • December 1, 2016 at 6:42 am
      • Reply
    • Right on, Bill. I will submit that the presentation layer of data should keep up with the various display technologies (pads, smart phones, and so on). My only complaint is that these devices mask a deeper issue – performance. Many people blame the network but I’ve also found that the backend DBMS can also be an issue. Can the DBMS be tunable or is it a Microsoft WINTEL thing? (like SQL-Server). Can the DBMS scale to over 100K users with 10K concurrently? (hitting enter or the whatever button at the same time).
      This is why I would not count out COBOL and mainframes just yet. They work well with what they are designed to do – deliver data VERY FAST. (oh, gawd, I hear the Oracle people now…)
      Even the worst COBOL program on a mainframe given x amount of data from a RDBMS than a JAVA routine running on windows against SQL-Server. That is why you will not see any banks or financial systems get off the mainframe. Go ask Schwab what they run, or JPMC, or Delta airlines (DB2 backended to mainframe running dynamic SQL), TSYS (largest card card clearinghouse in the East US).
      Note to people getting into this industry – Don’t get fooled by the pretty packaging of things that are easy, follow the opportunities.

      • Jeff Sullivan
      • December 1, 2016 at 6:52 pm
      • Reply
  • Excelente artículo lleno de razón. Después de programar en COBOL durante años, nos dijeron que iba a desaparecer. No me lo creí y perseveré. Ahora soy formadora en el entorno ZOS (también en PLI) para distintas consultoras y como máximo, en grupos de 15 alumnos cada vez. Poco, para la demanda que sigue existiendo aquí en España, donde somos unos pocos profesores que viajamos por el país allá donde nos necesitan. Siempre me ha gustado programar en COBOL aunque implique mucho código y le estoy muy agradecida, pues es y ha sido mi medio de vida. Comprendo que tarde o temprano volverán a incluir esta materia en la universidad porque hay un problema crítico en no muchos años vista pero nadie parece darse cuenta.

    • Perdón! copié mal el link del website. Ahora ya está correcto.

  • i think here you not talking something about cobol and mainframes, that the asembler its diferent, and that its an extra security issue, no easy do overflows etc.

  • I think it is very smart. It is in plain english. Easy to reed, and I suppose it is fast. I also thought it was dead. I wrote some programs 40 years ago on a course. Well there is a lot of hate of Assembler, Fortran, Lisp,Cobol, Pascal and even C. They are still used. So what should you use for business and administration? Pyton?Perl?C#? Mathlab i stead of Fortran? The old languages are there for speed and efficiency. What is the point of creating new resource hungry, slow and complicated languages when we use more and more small gadgets. I write this on an Android and not a gaming machine that costs 4000 dollars. It has limitations.

    • Oscar Lind
    • December 24, 2016 at 1:25 am
    • Reply
  • I have been a cobol programmer for 43 years. Nothing beats a Db2 data base and cobol to fix some bad sql that broke the data base, screwing up all the data. PC programmers are lost when this happens. With Cobol 4 you can have JAVA and XML mixed in. Do you know what broke the health care web site? Version’s Cloud. It was replaced with a DB2 data base. Now it zooms along. Nothing is more hack proof than a DB2 main frame data base. All you Tech Service guys have to do is remember to remove the “GUEST” user id. Remember that!!!!!!!! I have had a great career and have made lots of money knowing COBOL. After I retire, I still want to code in Cobol. By the way, get your self a good Cobol batch debugger! Nothing teaches you Cobol faster or finds a bug faster. A debugger also shows you what the program is doing and you can watch every line execute and see what is in the fields. RSA and other PC tools have great debuggers, but, you should demand a batch debugging tool if you are maintaining Cobol code. Even through I have worked in the JAVA world, I like COBOL best.

    • Dr Cobol
    • December 28, 2016 at 3:08 pm
    • Reply
    • Hi Dr COBOL, I am also a COBOL programmer of 34 years. It is harder and harder to find COBOL contracts now because of offshoring of work. Do you have any suggestions of how to get COBOL work now, also work that pays. Since offshoring of the work there are fewer onshore COBOL DB2 contracts and if there are they pay junior rates.

      • Bob Boylen
      • January 18, 2017 at 7:08 pm
      • Reply
  • As others have mentioned already – COBOL is not necessarily an “old” language, it got a lot of non-standard extensions from many vendors and updated standards (2002 added OO, dynamic+automatic data allocation/free, standardized some common extensions, … and the last standard is from end of 2014). Anyone that likes to know more may read https://en.wikipedia.org/wiki/COBOL
    COBOL is *not* a GUI language. Although many compilers added a lock-in highly non-portable GUI – if you want to use a GUI it is likely a good idea to either separate the parts depending on the language (frontend in Java/Python/Whatever, calling the COBOL routines for business logic) or do a direct CALL of the underlying C API (people CALL windows API’s, GTK, …).
    If you want to combine it – go ahead and use COBOL from node.js (all done already).
    So… yes: obviously you can run COBOL on normal PCs.
    If you actually want to do some COBOL coding you may pick a free implementation of COBOL https://www.gnu.org/software/gnucobol/ (yes, there is an official GNU COBOL compiler… and yes it works on operating systems from Apple and Microsoft…)

    • Simon Sobisch
    • January 6, 2017 at 10:15 pm
    • Reply
  • This article as many others talk about needing COBOL programmers to replace the programmers that are retiring. But it is not mentioned that a lot of the COBOL programming jobs have been sent offshore to India. So north America has another country supporting its financial systems and also these people have access to the clients personal and financial information.

    • Bob Boylen
    • January 18, 2017 at 7:01 pm
    • Reply
    • Not true….Indian IT shops do not have access to live customer data. They have access to development and test environments only

      • Pratod Dixit
      • July 5, 2017 at 11:51 am
      • Reply
  • I’ve tried various other languages but I keep coming back to COBOL. Why:
    1) It’s self documenting and self-documentation never goes out of date.
    2) It’s a lot faster/efficient than any other language I’ve used.
    3) It could be programmed using voice recognition.
    So, I think COBOL will make a come-back, once the current management have retired (the ones who never could code, so blamed the language) but driverless cars? No chance!

    • Hey, try C#, and not a “Hello World” example, you have to dig a bit deeper to start seeing the benefits.
      You can quickly write a HTTP Restful service with open standards security, permissions, data storage, validation, caching, logging, monitoring and notifications, that will scale across servers and can be recommissioned dynamically at runtime depending on the quantity of requests. Impressive? Well maybe not until you realise you can do that all with about 20 lines of code in about 10 minutes (per exposed method – if you know what you are doing). That’s without using any third party tools or taking into account gains made from DRY principles across endpoints.
      Progress doesn’t always bring benefits, but sometimes it does, and if you don’t think a couple of generations worth of technology advancement has brought anything to the development arena then it is time to retire because there is no hope lol.
      On the speed note, C# is not significantly slower than native after JIT compilation for a lot of things. It has been carefully optimised over the years and has come a long way. Not as quick as assembly, but that is more due to being able to trim out unnecessary operations than a differential in speed between operations.

      • Technical
      • March 19, 2017 at 9:15 pm
      • Reply
  • This article was enjoyable but at various points misleading. Without having an axe to grind, let me add some points of clarity for consideration. The present benchmarks for performance have the COBOL language (executing on the IBM mainframe) 400 times faster than the JAVA language (executing on any server platform). For more perspective, the non-objectified C++ language has been benchmarked at 600 times faster than JAVA.
    I routinely code in both languages although in appropriately different settings–not on the same job site. I lead a double life in IT. I will tell you that COBOL can be utilized to develop about 70% of what can be developed in C++. It even has a long-standing GUI brand known as “CICS COBOL”(historically referred to as “command-level COBOL). This CICS brand was multi-threaded years ago well prior to the advent of modern languages and platforms with which we now accomplish such. And, “objects”? We knew those in the mainframe environment as simply sub-routine programs, statically or dynamically linked.
    Though I favor C++ the most, I have found COBOL to be highly amenable to modern demands and constructs. Without any gnashing of teeth I have been able to code COBOL with modern techniques which favorably impact the applications that live on the mainframe platform. The pieces like a medium sized Lego set have been there since the ANSI version 2 begining in the nineties.
    And the IBM mainframes of newer vintage–the Z12 and Z13–now compete with Cray Supercomputers. It is true. To this day the IBM core processors are 5.4 GHz rated for continuous duty. Intel (who I like a lot) is still a piker when it comes to this caliber of CPU performance. The Z13 box just realeased last year is designed to virtualize 8000 servers simultaneously running any mix of server OS that a site fancies. Folks laughed two or so years ago when IBM exited the physical server market. Sillies asked, “Servers are booming, what the heck is IBM is thinking?!”

    • Craig
    • January 29, 2017 at 6:12 pm
    • Reply
    • Craig, I need a cobol programmer with other expertise. If interested call Jim at 919-644-1690

  • Hi,
    I am a COBOL programmer with more than 25 years experience and looking for COBOL dev. service/work from home. Does anybody know where to look for to offer my services (platform, freelance etc.)? Thanks a lot for any hint…!

  • I’m a 55+ programmer “weaned” on COBOL, and I’d be more than happy to supplement my retirement with a bit of contract programming work – bring it on!

    • Don Arnison
    • February 2, 2017 at 6:11 am
    • Reply
  • I’m not old but ancient. Have programmed/designed/managed software since 1963 at all levels up to CIO. Always hated COBOL, never sure why PL/1 didn’t replace it in the 1970s but programmer resistance to learning something new was definitely part of it. The point about the heavy reliance of mission critical large OLTP systems on CICS or IMS-DC is valid. One reason is that so many of the projects to replace these systems failed disastrously and expensively. The 1990s saw many such projects as an alternative to remediating Y2K problems but many failed and were abandoned. Stories of abandoned projects continue in the media, although I expect that others are not publicised. Now out of the industry, I would be interested to hear of more recent statistics for such complete replacements, not just surrounding old code with web interfaces. Now as a hobbyist I find programming in C# or Swift more interesting but probably less productive than my old professional environment but it should be recognised that there is a large difference between what works for a small team writing code for a mobile phone and for teams of hundreds collaborating on a high transaction volume TP system with many thousands of simultaneous users. Good luck guys, I’m still a dependent user of many of them!

    • les cook
    • February 18, 2017 at 5:01 am
    • Reply
    • ‘ Always hated COBOL ‘. That’s a bit emotional for a programmer.
      If you had been taught by trainers who genuinely understood COBOL particularly in relation to the human aspect of it, such as structured programming, egoless programming, table processing, minimum coupling, maximum cohesion, working-storage prefix’s, section & paragraph prefixes, global modules, subprograms, the KISS concept, hierarchy structure, peer walk-thru’s, & use of genuinely meaningful procedure & data names that people who have to maintain your code can understand, then maybe things would have been different for you.

      • Kevin O'Brien
      • March 25, 2017 at 4:59 am
      • Reply
      • COBOL engendered hyperbole. Almost nobody was ‘taught’ programming in the early 1960s, there were no tertiary courses and it was hardly recognised as a profession. The lack of structuring capability in COBOL at the time was a major reason for disliking it, which is why many switched to PL/1, a block structured language (from ALGOL 60) which contained all the mechanisms required by Dikstra. I doubt that Gerry Weinberg had dreamed up egoless programming at that stage and Barry Boehm had not performed the analysis of mainframe applications programming which led to the coupling/cohesion principles. All this is peripheral to the more interesting point that I was trying to make in this thread, that the persistence of the old software systems is largely because of the poor success rate of redevelopment projects. If Technical can do this for 100th the cost (presumably of the original development) then he is truly worth many millions and should not be wasting his time with polemics on blog sites.

        • les cook
        • April 2, 2017 at 4:38 am
        • Reply
  • If the number of codelines is relevant to “being a terrific language” then why didn’t we keep using RPG? Takes a bit of a learning, but I can code in 2 lines where in Java you need 10!

    • Wilfred
    • March 1, 2017 at 1:44 pm
    • Reply
  • I think it would be good for the owners of the businesses to get their children and grandchildren to learn the language.

    • Emma
    • March 12, 2017 at 6:37 pm
    • Reply
  • The continuation of COBOL is just reflective of the deep conservative views of some people working in technology. Modern programming languages have adapted to provide productivity for modern applications, COBOLs biggest problem is that it takes forever to program anything complex in it. Which leaves you often struggling with antiquated middleware licensed at horrendous cost by IBM.
    Besides COBOL implies mainframe, and that is both costly, inflexible, difficult to apply concepts like geo-resilience and it tends to be commissioned in massive steps rather than being flexed dynamically, it also always needs a lot of looking after. It is all a ridiculous setup that has no justification in the modern world.
    IBM live in a delusion and their marketing spin despite being laughable is suckering ignorant managers. Yes you can buy a Z13 that can do 2.5 billion transactions a day, but I can do that on two middle range dell servers these days (if I program for performance and small transactions) at 100th of the cost. Not only that I can get the software delivered on them at 100th of the cost and time due to the productivity and availability of resources for the modern languages it supports.
    IT is full of know nothing idiots who refuse to learn anything new. It presents an existential problem to businesses as it can’t be maintained (due to it never being designed for applications of modern complexities). It will be the story of the 2020s, multi-nationals failing as they either can’t compete or can’t even function because they are hobbled to 70 year old technology. Does that sounds an unreasonable prediction if you think about it?

    • Technical
    • March 19, 2017 at 8:24 pm
    • Reply
    • Could not agree with you mate.
      ‘ The continuation of COBOL is just reflective of the deep conservative views of some people …’.
      I think the reason is ‘ economics ’.
      ‘ Besides COBOL implies mainframe ….’.
      Microsoft brought out a COBOL compiler for PC’s in 1984. Similarly, Microfocus. And COBOL has got better & better via evolution.
      ‘IT is full of know nothing idiots …’
      Yet, IT has produced productivity gains measured in orders of magnitude.
      ‘ It will be the story of the 2020s, multi-nationals failing as they either can’t compete or can’t even function because they are hobbled to 70 year old technology ’.
      Yes I know – those Babbage machines must be wearing out already if they haven’t been keeping them oiled.

      • Kevin O'Brien
      • March 25, 2017 at 5:27 am
      • Reply
  • it is a very hopeful article for me. Too bad I have to wait to become so much in demand. I am looking for a job now.

    • Marina
    • March 22, 2017 at 6:58 pm
    • Reply
  • ‘ … walk into their offices and sit down to start coding in 1959’s COBOL ‘
    You forgot to say that COBOL has evolved since the 1959 version.

    • Kevin O'Brien
    • March 25, 2017 at 4:27 am
    • Reply
  • I totally agree with Kevin O’brien when he says
    “…. structured programming, egoless programming, table processing, minimum coupling, maximum cohesion, working-storage prefix’s, section & paragraph prefixes, global modules, subprograms, the KISS concept, hierarchy structure, peer walk-thru’s, & use of genuinely meaningful procedure & data names…”
    I would add “extreme refactoring”.
    I think the main Cobol problem are the Cobol programmers not applying those rules.
    About transaction performance, i have to say that some time ago i make an attempt to convert my Cobol software based on indexed files to Postgres database.
    There was no game: Cobol software was 10 times faster , so i dropped the project and now i am bounded with Cobol waiting for somenting having the same efficiency.
    “You forgot to say that COBOL has evolved since the 1959 version”.
    And (maybe) also forget that the writing of Cobol software TODAY has nothing to do with 1959 coding or at least should have not.
    ‘ Besides COBOL implies mainframe ….’
    Absolutely i don’t agree, there are many and many graphical Windows software packages written in Cobol that are indistinguishable from something written with VB, because…yes, it is possible to write event-driven programs in Cobol.
    “You can quickly write a HTTP Restful service with open standards security, permissions, data storage, validation, caching, logging, monitoring and notifications, that will scale across servers and can be recommissioned dynamically at runtime depending on the quantity of requests. Impressive? Well maybe not until you realise you can do that all with about 20 lines of code in about 10 minutes (per exposed method – if you know what you are doing). That’s without using any third party tools or taking into account gains made from DRY principles across endpoints”.
    Yes, but if i have to do something like this, i don’t use Cobol.
    If i have to go to mall to buy cigarettes i don’t take an airplane, but the bicycle even if is a 150 year old transport, so if i have to manage something Cobol does better than other tool, i use Cobol.

    • salvatore
    • March 26, 2017 at 11:30 pm
    • Reply
  • Hi,
    First time I am seeing Mother of COBOL Language Compiler with Debugger (Grace Hopper, the mother of COBOL) with Coding Sheet Emulator Or Computer Engine.
    Best Language for Evergreen of
    Language”. But another way now it is useful for Micro Electronics Processors and latest trend Robotics based works like from Legacy Mainframe to Nano based Objects, Partical’s Processing, Performing with Internetworking, Programmable Integrated Circuited, Data Reader and Files Writer by Virtual Robots in Wireless, Digital Signal Computer.
    “Computing of Open Business Objects Language”
    Yours Faithfully,
    COBOL Lover.

  • PROFITEZ EN UN TEMPS DE L’HEURE POUR TOUS LES TYPES DE COURRIEL HACK.Change Grades école? Hack Banks? Effacer le casier judiciaire? Hack sites Web? Hack Base de données? Hack Permis de conduire? Hack Call Log? Chambres Hack Visichat et FlashChat? Hack utilisateur FTP et Pass? Hack Facebook, Whatssap, Twitter, Instagram, Webcam etc.Hack VB Forum? Blog Hack WordPress? Hack CC tout pays? Hack argent Booker compte? Hack Liberté inversée compte? Hack compte Paypal? Serveur racine? By Pass Google Phone vérification? Installer Red sur Linux Server? Hash Crack? DDOS Server? Récupération de fichiers et documents perdus CONTACT: empiricalhackers@gmail.com

    • empirical
    • May 8, 2017 at 12:39 pm
    • Reply
  • 联系方式:savvyhackers@gmail.com。我们是专业,值得信赖和可靠的黑客,以下服务。
    – 攻入学校数据的基础上,改变你的等级
    – 攻入信用局数据库,提高你的信用评分
    – 进攻任何电子邮件或社交网络,并知道如果对方欺骗你
    – 攻入对方的电话PICS,短信和收听通话要知道他是骗
    – 劈到任何银行网站
    – 哈克到任何一家公司网站
    – 侵入任何政府机构网站
    – 侵入安全局网站和清除犯罪记录
    – 哈克到Craigslist网站并删除标记
    – 劈到任何数据库系统
    – HACK PayPal帐户
    – 服务器崩溃黑客
    – 下落不明INTERNET协议等;
    – 你或你的孩子在网上之前欺负想要回于人GET,我们可以帮助您跟踪人的实际位置,做你的要求的人员计算机
    – 有没有人敲诈你在网上,并且希望我们能够进入他们的

    • savvy
    • May 25, 2017 at 1:22 pm
    • Reply
  • From New York Times, June 4, 2017 – Jean Sammet’s Obituary – setting the record straight(https://mobile.nytimes.com/2017/06/04/technology/obituary-jean-sammet-software-designer-cobol.html ):
    “Grace Hopper, a computer pioneer at Sperry Rand in the late 1950s, led the effort to bring computer makers together to collaborate on the new programming language. Ms. Hopper is often called the “mother of COBOL,” but she was not one of the six people, including Ms. Sammet, who designed the language — a fact Ms. Sammet rarely failed to point out. (Ms. Sammet worked for Sylvania Electric at the time.) “I yield to no one in my admiration for Grace,” she said. “But she was not the mother, creator or developer of COBOL.””

    • Urban Wemmerlov
    • June 6, 2017 at 9:25 pm
    • Reply
    • When I mentioned to Grace (I was on the CODASYL Executive Committee being the chairman of the CODASY COBOL Committee) that she really was not the mother of COBOL, she replied that she was really the grandmother of COBOL. The amount of ignorance about COBOL in all of these postings is amazing. They apparently are not aware that COBOL has changed since 1959.

      • Don Nelson
      • April 4, 2018 at 12:22 am
      • Reply
  • Your information so good and useful visit naukri batao

  • I have programmed in COBOL for over 35 years. Some of the COBOL programs I wrote generated JavaScript, and JSON to build web pages for use by desktops seeking data feeds from a mainframe’s intranet server. Some of the COBOL programs I wrote linked operating system libraries so as to gain access to expanded utilities. Never had I ever looked at retirement age as way to stop doing what I loved. But at the same time I had never looked at coding as just a way to make a living. What sent be out the door of my last company (after 28 years), with retirement being the quickest exit, was the increase of young, empty-suit programming managers who were clueless about the real value of good, experienced, COBOL programmers and belittled their work. They thought they could simply hire just-in-time commodity programmers like they were doing with the little Java and C# they had.
    I am 75 and I still code: COBOL, Java, JavaScript, C# and do HTML and CSS.

    • Gary Mason
    • June 17, 2017 at 2:07 am
    • Reply
  • I am a very experienced Cobol and CICS programmer. Unfortunately over here where I live, there is hardly any companies are still using their old Cobol programs anymore. If there are openings for Cobol programmer, pls contact me to further discuss. I am willing to relocate to another country.

    • Gracia K.
    • July 1, 2017 at 5:18 pm
    • Reply
  • If I ran a COBOL based business in Europe or America, I would
    1. Open up an IT shop in India where you get low cost COBOL trained youngsters who are willing to spend their entire lives working on COBOL-Mainframe applications that were written 50 years ago.
    2. Not just programming but even COBOL testing is critical too so I would grow COBOL testing team too.
    3. COBOL applications are complex and the key to success of the India model is “transfer of application knowledge”. For a programmer/tester, its easy to master COBOL and other mainframe skills. The difficult part is mastering the application which typically runs into millions of lines of code. This “application knowledge” is hardly documented anywhere so all of it lies in the heads of the “about to retire” COBOL programmers. Once these old guys retire, it will become almost impossible to maintain COBOL code. Looking at this threat, I would start growing an IT shop in India as soon as possible.
    4. Not just programmers and testers, I would build “subject matter experts” in the COBOL applications in the India shop. These SMEs would then have the much desired “application knowledge”. The real threat to COBOL applications is not “lack of finding COBOL programmers” but “not having COBOL programmers who have strong application knowledge”.
    I have seen how banks like HSBC and financial institutions like Household International have grown low cost COBOL-Mainframe shops (with team sizes 200+) in Pune City, India and have been highly successful at it.
    COBOL-Mainframe shops in Europe/America wake up. Before its too late.

    • Pratod Dixit
    • July 5, 2017 at 11:03 am
    • Reply
  • You are explaining very well of COBOL, thanks for such a nice explanation.

  • Why if COBOL is still so much in demand I am unemployed for the last 3 years. Being a COBOL experienced resource with over 40 years of exposure to COBOL I am considered to be too old.
    A younger resource may learn how to use COBOL in fairly short period of time but experience comes with time and learning the hard way as the baby boomers did.
    There may be millions of lines of code still active in mainframe environment but they are mostly well tested and proven code which has become dormant, there is no alteration required as it has been well tested and is in stable and working state.

    • William Knox
    • August 14, 2017 at 11:38 am
    • Reply
  • I don’t think COBOL is still in demand. The employment rate is very less if you are looking for jobs in COBOL.

  • I worked in Cobol and Natural from 1999 until now, but work in other languages some years in parallel. I believe that the big difference between the old technology and new technology is that in these days all work is done in the database and some critical issue are for that reason.
    Before with Natural and Cobol we used several facility from JCL or VSAM elements more near to the Operating System level. Batch process used more tools from there. The database work less in this way.
    Pairing of files. Sort of files for several fields do not need any change and new table or indexes definitions in database. Many weighted work it was done with plain files SORT Icetools and easy programs that compare and match in parallel 2 or more files to get a result, without any use of database and is fast very fast and use little resource. Is more fast than to wait for a change in the database, you can be free of the DATABASE this is one of the more important point of Cobol and Nateral and mainframe to work with plain text compressed or not. To avoid the bottle neck of databases.
    I believe the new language should learn to work without database, perhaps the new NOSQL database will be more similar to batch process with flat files. Other special files are VSAM they are strong and very fast. DB2 is builded on VSAM, but you can use VSAM without DB2 as a database and are great!
    I processed millions of Cell phone register from VSAM fast !! without any database and I could have a big reduction in time of processing. (sorry my english I am spanish). ADABAS and DB2 are very fast databases and with high power. In 1999 my company when I was working , a telecommunication company, ask to Oracle if they can process a quantity of several millions of registers and the answer was NO . Today perhaps YES. But several time we do not use databases, we used VSAM and flat files to process million of register fast and ok with any problem. that i the ponit the new languages forgott to process in pure batch without any database. You can do it with any language with flat files no compressed. I sometime used basic of pc, yes pure basic to process millions of registers in my PC with very little resource, only a good hard disk an interpeter of Qbasic o Quick basic compiled and the sort of DOS and in this way I do some jobs replacing mainframe and with ftp send and get the files to PC. And with little resource and time do the job. Lear to work in batch without databases !

    • Jose
    • August 31, 2017 at 3:54 pm
    • Reply
  • Do not Forget that COBOL had OO from long time ago. People do not use it but COBOL has OO before many language…

    • Jose
    • August 31, 2017 at 7:50 pm
    • Reply
  • And what do you think of the French company COBOL-IT; COBOL-IT is the first company to offer a COBOL compiler based on an open source professional-grade platform; Founded in 2008, COBOL-IT quickly established itself as a global leader, successfully migrating hundreds of customers, representing several million users and hundreds of millions of lines of COBOL code.
    By leveraging its software suite and a robust migration process, the company enables its customers to preserve their strategic COBOL applications while improving performance and agility with significant cost savings. After several years of consolidation, these performances have been confirmed and validated by renowned technology partners such as IBM, HP and Oracle, within the framework of concrete projects carried out for major companies and governmental organizations in France (Directorate General of Public Finance, Mutuelles Sociales Agricoles, Social Security, Yellow Pages, HSBC, etc.) and in the world (Pepsico Spain, Carrefour, Verifone USA, ING Chile, Pelephone Israel, etc.). But I see that companies in New york always use with the traditional Cobol, Cobol and DB2. Do you really think that all companies will migrate with this system one day? COBOL-IT.fr

    • caroline
    • September 22, 2017 at 11:16 am
    • Reply
  • I create a powerpoint on the history of cobol from 1959 to the present day and I need to know whether or not he is really led to die with these new platforms. In addition, it is said that with the cloud, this language cobol is the one that will resist the most jobs, because these are big companies that maintain it, and that all the other languages ​​will cause unemployment, because the companies will go through the cloud. Your opinion ? thank you

    • caroline
    • September 22, 2017 at 11:19 am
    • Reply
  • By choosing open source and distributed architectures, Amadeus has taken a step ahead of its competitors – who basically continue to drive their engine’s heart on TPF – and has also gained an edge competitive. The migration to the cloud and containers should make the firm one of the major users of these technologies in the world.
    The mainframe release was motivated by technological reasons – TPF is rigid and it becomes difficult to find qualified experts on technology – and economical: in a few years, the ratio look to book – ratio of the requests made to obtain a reservation firm – which was 10 for 1 to cross the 1000 for 1 bar.
    so we see that the mainframes are transformed (in 7 years certainly) to the open source

    • caroline
    • September 22, 2017 at 11:39 am
    • Reply
  • It is true, however, that Amadeus had no cobol, but mainframe

    • caroline
    • September 22, 2017 at 11:40 am
    • Reply
  • COBOL is wordy/tedious but it is also much easier to learn and support than many of the newer languages like Java. The COBOL commands were designed back in the 1960’s before the days of databases and interactive communications with users. My recommendation … Upgrade the COBOL instruction set to include commands to improve interactive graphical communications with users, more flexible/relevant database access capabilities, and the ability to process ASCII or EBCDIC data. Finally, add the capability for COBOL to call Java Objects. These upgrades would allow existing applications to keep running and avid massive migration costs and would allow COBOL to be used for new systems development. Many of these capabilities were added to Microfocus COBOL but not to the mainframe compilers.

    • Nicholas Spanos
    • September 26, 2017 at 1:54 pm
    • Reply
  • I have over 30 years experience in the IT industry, having lived and worked in South Africa, the USA and Australia.
    With many millions of financial business transactions to process globally and also a huge amount in many countries, COBOL has proved to be the right tool for the job. Any environment needs a probable mix of tools and COBOL is a central one of these. Calling sub-programs works well because of being the better or “right” tool for that part of the job. Systems can benefit from having a mix of computer programming languages used: Use the best tool available for that part of the overall job.
    Translating billions of lines of COBOL code into a newer more hip language(s) would require a careful ‘step at a time’ plan and execution that would be horrendous to manage and implement.
    The alternative is to ‘leave what ain’t bust alone’ but that will lead to ongoing COBOL usage, training ad infinitum, particularly with the ageing COBOL expertise that exists.
    Sometimes a donkey is more useful than a Mercedes Benz, just as sometimes COBOL is better suited than Java etc.
    COBOL can lead to structured programs more easily and universally understood: and more so in systems where each task is accomplished with the best tool for it. I am surprised that in all the many things said in this article, EASYTREIVE PLUS was not mentioned. This language is tantamount to a COBOL shorthand that is not with unlimited use compared to COBOL. However, it can certainly be used fairly widely in similar environments and it is easy to learn and is fast and efficient.
    Structured COBOL, CICS COBOL, EASYTREIVE PLUS, NaturalAdabas/DB2, other tools/languages used efficiently & effectively as beneficial (Assembler, Java, C, C+, Delphi …..)
    with a focus on customer service & needs and a good grasp of the business.
    This is an environment where things can be stable and provide for natural growth, expansion and changes as necessary. With JCL and utilities of course. Employ coding nutters and those who can think and manage.
    Nothing lasts forever is the cliche – in time this “temporary panacea forever” will also change.
    But it seems to me to be a working solution for now and towards the future. Where change will be the only constant.

  • Read it in reverse: Lobo-C .
    When you write a compiler, the Cobol approach is the exact way you shouldn’t do it.
    Maybe you missed the humour in computer science. They probably found it funny to develop hilarious trash and then came up with the Univac.

    • Chuck
    • October 17, 2017 at 3:35 am
    • Reply
  • I am retired now but I did like COBOL 74 with RPG II over FORTRAN any day. The reason why is that you wrote out the program in logical sentence easy for anyone to understand what you are doing. With proper remark statement made the program easy understand and to update because the remark section would tell you what was happening in the program and then you could follow the previous programmer’s logic and make changes to the program. I remember right, when you first look at FORTRAN it look like letters and formulas that is hard to understand what is going on, so BASIC was developed as a first step to learning FORTRAN when you understood basic you then it was easier to learn FORTRAN. It took about the same amount of time to learn COBOL as it did to learn BASIC and then FORTRAN.
    I think that the large amount of typing and the Environment section of the Program may look like too much work and put people off. But once you start working with it and stepping through with a debugger you just might like it.
    Unless they are still using mainframes and middy computers which were 4 and 8 bit machines which had ROM of 4 to 32 K of memory, most running around 0.5 megahertz in my time I think with today’s computers and the power they have it would be easier to program in Cobol. Where there were teletype, Video Terminals, card punchers and reader, paper and magnetic tape along with the winchester 5 meg hard drives and the 8 inch floppy disk, you now have the keyboard, cpu and printer and with cloud technology and hard drives, cd readers and writers, other devices that are already programed to print. No queuing the printer or CRT screen through command language and using RPG to set up print commands to format the report in today’s programming.
    I am not sure but with menu driven computers nowaday I don’t think you need to learn the computer’s command language to compile the program and then execute the program. I could be wrong on this assumption.

    • Michael Callahan
    • November 15, 2017 at 2:28 pm
    • Reply
  • I find this information helpful for me. Thanks for sharing this info.

  • Yeah! this is quite helpful. Thanks for sharing the information like this.

  • This is useful for everybody.

  • How to improve!!

  • thanks a lot . very nice information

  • Great Info. Thanks for help us.

  • Such a important info.. Thanks for sharing.

  • nice article

  • Awesome
    Haryana Police Admit Card

    • Haryana Police Admit Card
    • January 22, 2018 at 3:33 pm
    • Reply
  • I like this post.
    SSC CHSL Admit Card

    • SSC CHSL Admit Card
    • January 22, 2018 at 3:47 pm
    • Reply
  • Nice one
    Rajasthan Police Admit Card

    • Rajasthan Police Admit Card
    • January 22, 2018 at 3:50 pm
    • Reply
  • Supeb
    UP Police PET Admit Card

    • UP Police PET Admit Card
    • January 22, 2018 at 3:51 pm
    • Reply
  • Nice article
    SSC CHSL Admit Card 2018

    • SSC CHSL Admit Card 2018
    • January 22, 2018 at 3:55 pm
    • Reply
  • Great team provides as appropriate information.

  • Great to hear you. Thanks for the post.

  • Thanks for the important update.

  • Very great!! Nice news actually.

  • The board of intermediate education of Telangana is mainly focusing it on improving the education system for the students. Every year there are many students give their examinations across the state.

  • What a great content!!!

  • I have been programming professionally since the 1980’s and to this day, the best online programs I have written were done back then on an HP3000 mainframe using View and the Cobol language. Many of these programs are still in use and they are so much better than the online stuff you see today. I am baffled that there have been no improvements in online systems since the 1980s. One thing that is particularly baffling is error handling. When I fill out an online form, probably written in Java, it can be very difficult to find out what you did wrong. With my old Cobol programs, when an error is typed, the cursor goes right to the offending field, and the field starts blinking, with an explanation of the error at the bottom of the screen. You can’t miss it. I do not see this in today’s programs.
    People complain about how Cobol needs too many lines of code to do the same thing as other languages do in a fraction of the code. But this gives the programmer complete control of the computer that SQL or Perl programmers do not have. And when starting a new project, a good Cobol programmer knows how to find an existing program that does something similar and start with that, so there is really not that much typing. And in Cobol, things are done in a logical, step by step method that makes sense to the programmer and anyone else who comes back into the program several years later. In languages such as SQL, it always seems like you have to trick the language into doing what you want it do, and it often makes no logical sense.

  • Great info! thanks for sharing.

  • Thanks for the amazing info.

  • Excellent article. I’m facing many of these
    issues as well..

  • Thank for sharing a great article.

  • What a great content!!!

  • I must say that post is great for new user like me who want to learn something about education portal.

  • COBOL is a great language and the opportunity on COBOL is still going on.

  • Although there still are some COBOL jobs out there, they are hard to find unless you are willing to move. There is no stability in this field, because even if you get a job in COBOL it will most likely be Temporary, or a Contract. I would much rather be in a Java, or C# programmer’s seat. There use to be tons of COBOL jobs just about 15 years ago, but the Internet and a much better Telecommunications infrastructure, has allowed those jobs to be outsourced, not to mention H1B’s and Indian/Americans who are viciously competing for the remaining scraps….

    • Ziggy 2018
    • April 12, 2018 at 7:03 pm
    • Reply
  • This is a Beast Thank You Verry Much For Sharing Amazing article

  • Best article, I Love it. Thanks for sharing.

  • Hello everybody.
    I’m a 60 years old Cobol programmer from Barcelona. My first program in Cobol was written in 1984, quite a lot of time ago.
    During the last years of the last century I most everyday used to hear that Cobol absolutely obsolete. Nevertheless, now it’s completely reborn. There’re many reasons but, after being some years without a job, I was very happy since I found a brand new job. It’s right: there aren’t enough cobol programmers and for people of my age it’s good luck, otherwise it would ve next to impossible founding a new job for the enterprises do prefer younger people. However I must say that in Spain the salaries have been going down during this century which means that I earn less than in the last century…
    Good luck for all the colleagues in the world.

    • Manel Fernàndez.
    • April 19, 2018 at 5:39 am
    • Reply
    • Best article, I Love it. Thanks for sharing.

  • There’re many reasons but, after being some years without a job, I was very happy since I found a brand new job.

  • Nice Post

  • Awesome

  • I read this article. I think you put a lot of effort to create this article. I appreciate your work

  • Good Article ! Sarkari Naukri

  • Thanks, Best article, I Love it. Thanks for sharing.

  • Fantastic Post

  • Thanks. Nice Article. I like it. thanks for sharing

  • Helpful article. I’m facing many of these issues as well.. and now i can solve them

  • Thanks. Nice Article. I like it. thanks for sharing

  • Helpful article. I’m facing many of these issues as well.. and now i can solve them

Leave a Reply

Your email address will not be published. Required fields are marked *