Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT

Many Businesses Still Love COBOL (techradar.com) 195

Posted by EditorDavid from the 60-year-old-languages dept.
TechRadar shares some surprising results from a new survey of enterprises using COBOL and mainframe technologies: According to a survey by Micro Focus, which follows data gathered in previous 2017 survey, 70 percent favor modernization as an approach for implementing strategic change. This is opposed to replacing or retiring their key COBOL applications as they continue to provide a low-risk and effective means of transforming IT to support digital business initiatives...

This is further supported by the results of the survey with an increase in the size of the average application code base which grew from 8.4m in 2017 to 9.9m this year, showing continued investment, re-use and expansion in core business systems.
"92 percent of respondents felt as though their organization's COBOL applications are strategic in comparison to 84 percent of respondents in 2017," according to the official survey results. The survey spanned 40 different countries, and involved COBOL-connected architects, developers, development managers and IT executives.

"COBOL's credentials as a strong digital technology appear to be set for another decade," according to Micro Focus' senior vice president of application modernization and connectivity. "With 60 years of experience supporting mission-critical applications and business systems, COBOL continues to evolve as a flexible and resilient computer language that will remain relevant and important for businesses around the world."
This discussion has been archived. No new comments can be posted.

Many Businesses Still Love COBOL More

Many Businesses Still Love COBOL

Comments Filter:

  • Compare code back then and today (Score:5, Insightful)

    by Opportunist ( 166417 ) on Monday February 17, 2020 @07:50AM (#59735180)

    Back then, code was written by people who not only had the training but also the background to know what they're doing, and they got plenty of time to get it done right. The code got audited and reviewed before being tossed onto the production system was out of the question, considering how much the system costed and how much even running a faulty code once costed.

    Now compare that to today, where code monkey with little to no experience and training slap together snippets they copy from Stack Exchange while having equally little to no idea what exactly that code does, or what side-effects may lurk in those lines, let alone how it performs in edge cases, coupled with an "it compiles, ship it" mentality from management.

    And you wonder why companies cling to ancient code that they KNOW works?

    • Re: (Score:3)

      by Megane ( 129182 )
      So COBOL is relevant and strategic because it's a filter that keeps out millennial code monkeys? That sounds cromulent to me.

    • I guess it's the same as in every industry.

      Profit maximization means effort minimization too.
      Somtimes, that can be a good thing. [youtu.be]
      But usually, all you get is wasting more time with replacing broken things to save a little in the short run, while paying more in the long run (aka generating more profit).

      I think the key problem is, that people simply can't afford making wise long-term investments. It might be wise for your family, to build a brick house without metal, that lasts a literal thousand years. But if

    • Considering the reason why modern code like that exists is because management doesn't want to pay the additional costs for highly educated and/or skilled workers or implement time consuming review processes you can be damn sure those ancient COBOL system are going to be maintained the exact same way. In other words; When management cuts corners like that, you can be damn sure that it's how they maintain everything, including the well thought out and developed COBOL-based systems they've inherited from previ

      • Re: (Score:2)

        by hjf ( 703092 )

        well thought out and developed COBOL-based systems

        LOL. Why do people idealize COBOL as "so good"?
        Is it because people back in COBOL days used to wear ties at the office?

        COBOL just looks like "good" because no one ever dares touch it because "it works". Truth is, a lot of that COBOL code would shit itself if you try to make even insignificant changes to it.

        We've always had incompetent developers. COBOL doesn't save you from those.

    • Re: (Score:3)

      by jythie ( 914043 )
      There is a certain irony in this given that COBOL was essentially designed by non-programmers for non-programmers.

      But other than that.. yeah,.. the economics and expectations of programming have changed radically. I really can not blame the code monkies.. often they have the brainings and the training, but not the time or resources to do things in a more structured way.

    • Re: (Score:2)

      by hjf ( 703092 )

      BULLSHIT.
      The lead developer for a small bank here used to be a construction worker (he still has rough hands from handling bricks back in the day). He picked up a COBOL book in his spare time and learned on his own. This was 40 years ago. A construction worker with no formal training other than a COBOL book. There was no code review, audit, or "testing environment".

      Stop romanticizing the good ol times. Shops that still run COBOL are usually run by greybeards with Big Blue hearts. Why would you want to chang

      • Shops that still run COBOL are usually run by greybeards with Big Blue hearts.

        Pulled that out of your butt, so bullshit right back at'cha. Banks don't just use IBM or major iron, you know. Ever hear of Tandem? Lots of COBOL code running on Tandem.

        • Re: (Score:2)

          by hjf ( 703092 )

          I said SHOPS, not specifically BANKS.

          I know for a fact that the bank I mentioned earlier does use AS/400. And the province's IT department also uses it. They did support for the province's lottery and they had AS/400 as well. I saw their old "decomissioned" stuff too: I never saw a mountain of over 100 Token Ring MAUs before that.

    • ...Now compare that to today, where code monkey with little to no experience and training slap together snippets they copy from Stack Exchange while having equally little to no idea what exactly that code does...

      I guess you have no idea what today's DevOps is???

  • Gee whizz, Sir, I don't think it will last when everybody who learned it died.

    -- Lil Timmy, who never learned Cobol, and never will.

    • There will be many, many other languages that will disappear long before all the younger programmers who currently work with COBOL die out.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Monday February 17, 2020 @08:24AM (#59735234)
    Comment removed based on user account deletion

  • Comment removed (Score:4, Informative)

    by account_deleted ( 4530225 ) on Monday February 17, 2020 @08:32AM (#59735248)
    Comment removed based on user account deletion
    • I wonder how much of the COBOL still running is owned by government at various levels? Based on experience over the decades, getting money to replace a million lines of legacy COBOL from private sector management is a piece of cake compared to prying it from the hands of, say, a state legislature.

    • It works, but nobody knows why.

      Yep. COBOL is one of those languages where it's not just possible, but relatively common to find out that whoever originally wrote the code you're working on is now dead. We have a ~40 year old COBOL program on site. No clue who the original programmer was, but we typically have 1 "main" COBOL programmer who babysits that stuff and we're on our 5th programmer that's maintained that code as the previous ones retire. Each one has put on their own brand of quick band-aid fixes to make stuff work - and work

      • it's almost impossible to understand certain parts of the code.

        It's fucking **English**. That statement says scores more about your programmers than the language.

  • So COBOL developers think that it's a good idea not to port their projects away from COBOL, and this is a "surprising result"?

  • Windows XP and Internet Explorer are th next cobol (Score:3)

    by xack ( 5304745 ) on Monday February 17, 2020 @08:37AM (#59735266)
    Still in widespread use six years after end of offcial support. Despite Microsoft begging companies not to use them they are kept going. It's Microsoft's fault too for not providing a telemetryless build of Windows 10 without hacks plus trying to force online accounts.

    • I have one work tool that doesn't work correctly except in IE.

      I have another work tool that doesn't work correctly except in Chrome, no, not in Firefox either.

      And there is another whole suite of tools that work in Chrome but not Edge or IE.

      Some of these are modern tools. Some not. It's not so simple, browser issues are still with us.

  • Many people also LOVE their wife, because it's too expensive to get a new one.

    • Have you looked at the wife market lately? Not much out there that is long-term reliable. Most of the used ones haven't been maintained or upgraded, and the new ones are a real roll of the dice. It's like whoever is designing them doesn't know how marriage works at all.

      And no, the Uber/Lyft models are too expensive for regular use, and have real demand issues. Never available when you want them, or price gouging when they think you're dependent on the service.

      Think before you leap.It's probably you...

  • Ok, so what should they port it to? (Score:5, Insightful)

    by lurcher ( 88082 ) on Monday February 17, 2020 @08:56AM (#59735318) Homepage

    So you have a COBOL system that's been working fine for 40 years, and you are told you need to rewrite it in a current language. So what current language will be around for the next 40 years? Not sure which one? Maybe lets wait another 5 years and see if that new long term language comes along. Otherwise you know that if you rewrite it today, after those 5 years, you will be told it needs rewriting again in the newest shiny language. Sometimes doing nothing is the optimum strategy.

    • Re:Ok, so what should they port it to? (Score:4, Insightful)

      by jythie ( 914043 ) on Monday February 17, 2020 @09:05AM (#59735342)
      This.

      Something I always find a bit unnerving about the post Y2K programming culture is the short time horizon. Modern languages constantly breaking compatibility in order to 'stay relevant', developers thinking in terms of months or maybe a few years rather than decades.

      On my current project, we have had to update our version of Python a total of 5 times. We have probably lost about 6 months of dev time to that over the years, and keep having to rewrite things to work around the language changes. If our stuff was doing anything mission critical, I would have pushed for just staying on 2.3....

    • Re:Ok, so what should they port it to? (Score:4, Insightful)

      by TheDarkMaster ( 1292526 ) on Monday February 17, 2020 @09:10AM (#59735354)
      This. The "new guys" can't seem to understand that some systems are going to live longer than the developers themselves (literally!), and for that reason these systems can't be made or work well in languages that break compatibility every year.

    • Re: (Score:3, Informative)

      by ArchieBunker ( 132337 )

      Today it would be ported to Python without question. Then of course Python 2 code is not compatible with Python 3. A quick search shows 8 years between versions 2 and 3. I bet some of these machines running COBOL have uptimes longer than that, especially the AS/400.

    • Re: (Score:3)

      by clovis ( 4684 )

      So you have a COBOL system that's been working fine for 40 years, and you are told you need to rewrite it in a current language. So what current language will be around for the next 40 years? Not sure which one?

      ALGOL, of course.

    • Re: (Score:2)

      by necro81 ( 917438 )

      So you have a COBOL system that's been working fine for 40 years, and you are told you need to rewrite it in a current language. So what current language will be around for the next 40 years? Not sure which one? Maybe lets wait another 5 years and see if that new long term language comes along. Otherwise you know that if you rewrite it today, after those 5 years, you will be told it needs rewriting again in the newest shiny language. Sometimes doing nothing is the optimum strategy.

      I do not entirely disagr

      • Re: (Score:2)

        by lurcher ( 88082 )

        "I do not entirely disagree. However, one thing that a total rewrite would force is to actually understand the ins and outs of the existing COBOL code"

        If that happens, then I agree, though what normally happens is what gets rewritten is what they think the code is doing, and often those little subtitles are lost until they encounter the reason they were there the first time.

        Over time the process of discovering the exceptions continue until the new code is as much an incomprehensible mess as the COBOL origin

  • Bias (Score:2, Funny)

    by StormReaver ( 59959 )

    So the company that makes the language says that people love the language. Sounds unbiased and reliable to me.

    • Re: (Score:2)

      by DRJlaw ( 946416 )

      So the company that makes the language says that people love the language. Sounds unbiased and reliable to me.

      Micro Focus "makes" COBOL? Are you sure? [wikipedia.org]

      Sounds like someone with no knowledge is taking pot shots to feed their ego.

  • So what? (Score:3)

    by mschaffer ( 97223 ) on Monday February 17, 2020 @09:12AM (#59735368)

    In this age of virtual machines and simulations I do not understand why this is such a big deal? Also, with CEOs funneling more and more cash away from business infrastructure, they can just say "well, the Cobol experts said this is the right thing to do". These decisions are made by the company executives and, ultimately, they are the responsible parties here, and they are the ones that have the most potential exposure if something fails.

  • The obsession with constantly devising new languages is silly. If it ain't broken, why fix it?

  • COBOL: A very inefficient language (Score:5, Interesting)

    by hAckz0r ( 989977 ) on Monday February 17, 2020 @09:17AM (#59735382)

    Line for line COBOL is a very inefficient language to write in

    In the early 80's I worked for an electronics manufacturing company whos data processing department was using mainframes running COBOL. For years our production staff had been asking for a fairly simple application, one that would give us a fully nested bill of materials needed to build any particular product so that we could get an early start on the procurement process. They said it was not possible.

    One day I sat down at my IBM PC XT which I had adapted a terminal interface card to connect to the mainframe so that I could read a virtual representation of the terminal console for the mainframe. In less than 6 hours I coded up a Pascal application that could extract all the individual bill of materials and calculate how many of each assembly would be required, and then did a fully exploded list of every nut, bolt, diode, filter, and resistor that would be required to ship a particular order. It took about an hour to run and handed me what would normally take two weeks of manual processing. A production analyst could simply fill in the model number and a quantity, and my little program could then tell you in less than an hour what long-lead items were likely to hold up the production line. With management's signature, we could then get those long lead items on order that very same day and potentially save as much as a month on the delivery time of an order.

    After seeing my printed report my manager grabbed my report from my hands and marched straight down to the data processing managers' corner office to confront them about why they couldn't do the same thing. They finally relented and assigned their most experienced COBOL programmer to code up the exact same report. I had to run my program again because the DP management kept my only copy.

    My little Pascal program took me about 6 hours to write, and their same COBOL project took over 6 man-months to write and test. They even had direct access to the data on the mainframe while I had to dance through fiery hoops to extract that same information and build my own temporary database.

    The DP manager offered me a job writing COBOL, and needless to say, I refused the offer. About six months later I left the company to become a professional programmer and never looked back. I stopped counting at 24 different computer languages more than 30 years ago when I realized it is not in your best interest for management to find out you know how to write in particular languages, like COBOL or PL1, because one day they will very likely ask you to "fix" something that would be better rewritten in another language better suited for the assignment. Some languages should just be retired, and its safe to say COBOL is one of them.

    • DP Manager

      Hell there is a term I have not heard in ages!

    • Re:COBOL: A very inefficient language (Score:4, Informative)

      by Eravnrekaree ( 467752 ) on Monday February 17, 2020 @10:37AM (#59735680)

      This can be misleading because it is anecdotal and based on what COBOL was like on mainframes. These days, with a modern compiler, using free form COBOL (no line numbers or strict formatting), COBOL is comparable to other languages. So it does not apply or accurately describe these more modern implementations such as GNU COBOL which support free form COBOL and are easier to use.

    • In less than 6 hours I coded up a Pascal application that could extract all the individual bill of materials and calculate how many of each assembly would be required, and then did a fully exploded list of every nut, bolt, diode, filter, and resistor that would be required to ship a particular order.

      Bullshit. I know both COBOL and Pascal. Bullshit.

      Line for line COBOL is a very inefficient language to write in

      Yeah, that's the metric, how few lines you use. You know, those things that no machine actually

    • Re:COBOL: A very inefficient language (Score:5, Insightful)

      by mvdwege ( 243851 ) <mvdwege@mail.com> on Monday February 17, 2020 @11:40AM (#59735976) Homepage Journal

      My little Pascal program took me about 6 hours to write, and their same COBOL project took over 6 man-months to write and test.

      That's probably because your little program stumbled over all the corner cases that the COBOL programmers spent years working into their code.

      The kind of programmer that thinks a 6-hour job is production ready is precisely the sort of cowboy that tests on a limited data set and proclaims himself God. The one you keep away from working production code without mentoring by an experienced maintenance programmer.

  • ...until a language is developed that can match COBOL's ability to rapidly process huge amounts of data, and do so at least as efficiently with regard to memory and processor usage.

    Remember COBOL's heritage. Then begin to understand why it has seen such longevity.

    That's as far as I go.

  • The machine is not running COBOL, it is running whatever was compiled from it. COBOL is there for the convenience of the people, If you don't like COBOL, concentrate on getting the machine to translate the COBOL to something the people understand and have the people modify that. Then, for all I care, the machine can translate the differences back into COBOL as a lingua franca.

    ie. concentrate on making tools that can represent the old code base in the way you want to see it (which will likely change over ti

  • Best thing for COBOL is GNUCOBOL (Score:3)

    by Eravnrekaree ( 467752 ) on Monday February 17, 2020 @10:33AM (#59735642)

    GNU COBOL is now mature, so COBOL could see even more use, since previously a major barrier towards use of the language was lack of open source, accessible compilers for it. Now anyone can write a program in COBOL so it can see even more use.

  • Back in the dark ages, I was tasked with finding out why a COBOL application meant to update a random access file was taking hours to update a dozen or so records. This was not any COBOL, it was NCR Century 151 COBOL, a variant that allowed the programmer to mix Neat/3 (NCR's answer to IBM's Basic Assembler Language) freely with COBOL code. The original programmer had decided it would be more efficient to drop into Neat/3 to do a binary search, but due to a bad register assignment was always starting the se

  • Again? (Score:3)

    by AlanObject ( 3603453 ) on Monday February 17, 2020 @12:03PM (#59736058)

    It seems like this article gets posted about 2-3 times per year for the last 5 years or so.

    It is almost as if someone around here is astounded that all the COBOL code hasn't been already re-written in Javascript.

    Do grow up, people. The corporate management of trillions of dollars of assets doesn't really give a damn about your sense of computer language aesthetics. And never will.

  • 77 year old cobol programmer (Score:3)

    by atomicalgebra ( 4566883 ) on Monday February 17, 2020 @01:41PM (#59736530)
    I have friend whom is 77 years old and is a cobol programmer. He is still in demand at his age working on legacy systems for multiple fortune 500 companies.

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close