Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Government

COBOL Turns 60. Why It Will Outlive Us All (zdnet.com) 163

Posted by EditorDavid from the (CO)mmon-(B)usiness-(O)riented-(L)anguage dept.
ZDNet remembers when the only programming languages "were machine and assembler," until Burroughs Corporation programmer Mary Hawes proposed a vendor-neutral language with an English-like vocabulary. (Grace Hopper suggested they approach the Department of Defense, leading to a summit of 41 computer users and manufacturers at the Pentagon in 1959.)

But ZDNet argues that 60 years later, COBOL isn't done yet. In 2016, the Government Accountability Office reported the Department of Homeland Security, Department of Veterans Affairs, and the Social Security Administration, to name just three, were still using COBOL. According to a COBOL consulting company, which goes by the delightful name, COBOL Cowboys, 200 billion lines of COBOL code are still in use today and 90% of Fortune 500 companies still having COBOL code keeping the lights on. And, if you've received cash out of an ATM recently, it's almost certain COBOL was running behind the scenes.
ZDNet explains that's the largest number of businesses using COBOL are financial institutions, which, according to Micro Focus includes "banking, insurance and wealth management/equities trading. Second is government services (federal, provincial, local)." Micro Focus is the company that now maintains COBOL, and their global director of marketing and "application modernization" tells ZDNet that "the number of organizations running COBOL systems today is in the tens of thousands. It is impossible to estimate the tens of millions of end users who interface with COBOL-based applications on a daily basis, but the language's reliance is clearly seen with its use in 70 percent of global transaction processing systems. Any time you phone a call center, any time you transfer money, or check your account, or pay a mortgage, or renew or get an insurance quote, or when contacting a government department, or shipping a parcel, or ordering some flowers, or buying something online at a whole range of retailers, or booking a vacation, or a flight, or trading stocks, or even checking your favorite baseball team's seasonal statistics, you are interacting with COBOL.
ZDNet notes that some people are even moving their COBOL applications into the cloud, concluding "At this rate, COBOL programs will outlive us all."
This discussion has been archived. No new comments can be posted.

COBOL Turns 60. Why It Will Outlive Us All More

COBOL Turns 60. Why It Will Outlive Us All

Comments Filter:

  • laughed at the "tens of millions of users" (Score:4, Informative)

    by iggymanz ( 596061 ) on Saturday September 07, 2019 @01:39PM (#59169180)

    No, there are over a billion users of COBOL daily. If you're moving money in the western world with western banking or credit cards, that happens with COBOL. I hear rumors there are a lot of COBOL in Japan, South Korea and India too.

    • Re:laughed at the "tens of millions of users" (Score:4, Informative)

      by phantomfive ( 622387 ) on Saturday September 07, 2019 @01:48PM (#59169214) Journal
      I tried to look for some COBOL jobs a few years back, when I bought into the COBOL hype. There aren't very many (which is ok, as long as there is one for me), and more importantly they are relatively low paying. $60k per year and a lousy boss, no thanks.

      Surely they don't all come with a lousy boss, but they are being phased out. Here is one example [slashdot.org], and they saved $3 million euros a year after the migration. Other people I know who are working with COBOL have similar plans.

      On the other hand, IBM mainframe sales keep rising, so they must be doing something

      • On the other hand, IBM mainframe sales keep rising, so they must be doing something

        Z-series sales have been on a decline for over a decade. There have been a couple small peaks in there but in general it's been on a steady downhill trend.

        • Re: (Score:2)

          by guruevi ( 827432 )

          IBM "mainframes" are rarely Z-series these days. IBM sells a product that will convert their own Z-series systems into the IBM cloud, which is just running on standard x86 iron, I know a couple of smallish vendors that do the same thing or run disaster recovery 'mainframes' simply by creating a VPN between your mainframe and Amazon and then running some software.

          • IBM "mainframes" are rarely Z-series these days. IBM sells a product that will convert their own Z-series systems into the IBM cloud, which is just running on standard x86 iron,

            A cluster is a fine thing, but it isn't a mainframe. I'd argue that it's generally superior to a mainframe, and the market seems to agree.

      • Re:laughed at the "tens of millions of users" (Score:4, Interesting)

        by Aighearach ( 97333 ) on Saturday September 07, 2019 @03:02PM (#59169394)

        I learned COBOL for Y2K, and I agree. There is not actually any demand.

        Mainframes are mostly running code written in C.

        COBOL programs are mostly maintained by switching to modern compilers, and writing new libraries in C. The old code is not touched other than to hook in the new libraries.

        • I learned COBOL for Y2K, and I agree. There is not actually any demand.

          Wrong, you just need to find the right employment agency. They don't really advertise because it generally produces zero results. If you find the right employment agency you will find plenty jobs. Most job hunting is done by word of mouth now because no one teaches COBOL anymore.

          • Re:laughed at the "tens of millions of users" (Score:4, Informative)

            by phantomfive ( 622387 ) on Saturday September 07, 2019 @05:37PM (#59169554) Journal
            I just checked again, to make sure. There's this job, that pays like dirt [indeed.com], and look what the reviews are saying [indeed.com]: "OPERS could be a great employer but unfortunately, there are many issues that are deeply rooted." That's exactly what I expected.

            OK, lest you say that's only in Ohio, let's look in California, another job posting that pays dirt [indeed.com].

            The only ones making money off COBOL are the consulting firms quoted in the summary and article.

            • 5 figures and it is a "senior" position, so to qualify you have to have a long history of being a specialist receiving below industry average pay.

            • Comment removed based on user account deletion

              • asking people to come out of retirement for a gig

                Yep. I still get feelers despite telling everyone I wasn't interested for over twenty years now.

              • So there is even less demand than there is legacy supply. And supply must be shrinking, so demand must be shrinking faster.

          • If you need someone to teach you a language you are, by definition, not qualified to write software.

          • If you're going through an "employment agency," you already failed at consulting and will get low pay once you calculate the hours.

        • Mainframes are mostly running code written in C.

          Hmm . . . I would have guessed, PL/I.

          In a project that I worked on in the late 80's, we had to port stuff written in PL/S for an IBM Series 1 to IBM "Industrial PCs" running OS/2.

          That was a hoot and a half.

          And it would explain to anyone why my posts here are completely batshit crazy.

          • Disgusting, but at least it works. And I doubt you have to swim in third-party libraries with conflicting version requirements, so better than the average modern enterprise framework.

            But the places that buy that have shitty HR and can barely hire anybody. They have to merge with another company just to pillage engineers.

          • Mainframes are mostly running code written in C.

            Hmm . . . I would have guessed, PL/I.

            You'd be out of touch. Most mainframes these days run Linux/C/other.

        • COBOL programs are mostly maintained by switching to modern compilers, and writing new libraries in C. The old code is not touched other than to hook in the new libraries.
          That does not make any sense. Cobol is excellent in data processing. What the compiler gives you for free you would need to write manually in C (input/output/formatting) ... no one is so stupid doing that.

      • I tried to look for some COBOL jobs a few years back, when I bought into the COBOL hype. There aren't very many (which is ok, as long as there is one for me), and more importantly they are relatively low paying. $60k per year and a lousy boss, no thanks.

        That's because most of them are in the financial sector, where it is a fundamental principle that 99 percent of the money is reserved for the big cheeses and the shareholders. (Two groups who increasingly tend to be the same people).

    • No, there are over a billion users of COBOL daily.

      And there are more than 7 billion people producing trash each day. What of it? The trash still stinks.

  • The job control and IBM COBOL dialects and IBM compiler preprocessor commands, CICS and SQL baked in the IBM way, EBCDIC mode, mainframe arithmetic precision modes and BCD that aren't the IEEE types.... all mean the big corporations are not going to bother porting code built up over decades to Unix iron, or Linux based Intel/amd x86 servers.

    • The middle managers in those companies who are running Unix iron will only see the cost of migration and say “not gonna happen” - without considering how much overall they're paying annually to keep those beasts going.

    • The job control

      When someone says to me "JCL", it flips me out and causes post traumatic syndrome symptoms about Job Control Language, which I used in the early 80's.

      What really frightened me was that I did a gig in a development system of IBM Z back in the late 90's . . . and they were still using that stuff, as opposed to bash, or what similar.

      I need to like my job. Sure, I can do a bunch of stuff in ornery and arcane languages, but at the end of the day, I need to say, "That was fun!"

    • OTOH, in writing firmware for microcontrollers I have to deal with BCD all the time. Sometimes I just buy a BCD chip for a few cents if it is only needed on IO and I have extra GPIO pins.

      I'll bet a lot of them would port it if their HR departments were willing to let them hire contractors based on deliverables instead of resumes.

      Companies don't migrate because they have broken hiring practices, not because old BCD is hard, and not because IBM SQL is hard.

      I personally would actually prefer to work on some CO

      • I don't think it has to do with HR. They don't migrate because it's thousands of apps with tens of millions of lines of code that is still being changed. No one is going to take years to migrate that to a platform that is more expensive (at the large end), less reliable, less secure, and with lower performance.

        • "Millions of lines of code" usually ends up including a few hundred thousand lines just of math routines that you don't rewrite when you port, you just make minor modifications to hook in the new stuff.

          Nobody has millions of lines of business logic or IO, which is the stuff that has to be ported.

          And depending on the comment polices, every 5 lines of C is 50 lines of COBOL, because you know they didn't get to the millions if they stripped comments and boilerplate.

          • And depending on the comment polices, every 5 lines of C is 50 lines of COBOL,
            In *logic* prhaps.
            In data processing/formatting: most certainly the opposite around.

      • OTOH, in writing firmware for microcontrollers I have to deal with BCD all the time

        What the hell are you doing that you need BCD ? I've been working with microcontrollers for decades, and I've never used BCD for anything.

        Sometimes I just buy a BCD chip for a few cents if it is only needed on IO and I have extra GPIO pins.

        Why not just copy/paste some working code ?

  • Extending Cobol (?) (Score:4, Interesting)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Saturday September 07, 2019 @01:52PM (#59169218)

    Shouldn't it be possible to extend Cobol without breaking backwards compatibility? I know Cobol looks like someone combined a beta version of SQL and a design draft on an early Basic while on a mix of bad LSD and crack, but that shouldn't prevent anyone from adding features that make sense, in a modern way.
    What I'm trying to say is that I see know reason Cobol couldn't be around for another 200 years and why that musn't be a bad thing - especially if Cobol is maintained and extended in a sensible manner that doesn't break existing workflows. I mean, people still code in other obscure languages like Lisp and Haskell and whatnot and AFAICT that stuff works if done right.

    Anybody with current insight into the Cobol world that can tell us what's happening with Cobol in the non-breaking extensions department?
    I'm curious.

    • Re: (Score:2)

      by Mal-2 ( 675116 )

      Case in point: QB64 [qb64.net].

      Any language can be modernized, if there are enough (and/or sufficiently influential) people who want it.

    • Crack and LSD weren't invented when COBOL was born.

    • Yes, COBOL gets extended same as any other language by standard committee. Object oriented extensions, recursion, unicode and pointers were formalized in COBOL 2002

      COBOL 2014 added collection classes, XML processing, dynamic sized and allocated tables.

    • Re:Extending Cobol (?) (Score:5, Funny)

      by Waffle Iron ( 339739 ) on Saturday September 07, 2019 @02:59PM (#59169386)

      Shouldn't it be possible to extend Cobol without breaking backwards compatibility?

      Sure. Here's my suggestion:

      IDENTIFICATION DIVISION.
      PROGRAM-ID. hello-world.
      PROCEDURE DIVISION.
      SWITCH TO ALTERNATE INTERPRETER "Python" STARTING AT BEGIN AND THEN CONTINUE RUNNING THRU END
      BEGIN.
      def main():
          print("Hello World!")
      main()
      END.
      .

    • I know Cobol looks like someone combined a beta version of SQL and a design draft on an early Basic while on a mix of bad LSD and crack

      That's mostly the direct consequence of having been written in terms a business user can readily understand. In other words, it was the very first domain-specific language.

      Languages like C, C++, Java, Python, etc. are written much more in terms familiar to programmers. That's good, but it leaves an aching chasm between the actual problem statement and the programmers who have to try to create solutions.

    • Re: (Score:2)

      by Toshito ( 452851 )

      The latest version of COBOL had been released last year.

      Each time they add a lot of new functions and features.

      You can now parse and generate JSON messages with a single instruction.

      You can do the same with XML.

      We develop new APIs in COBOL that allow web services to communicate with the legacy applications, using MQ messages.

      We have batch jobs that processes millions of transactions using less than a second of cpu, and under 16 MB of RAM, you can't do that in java (I know because I do both COBOL and java de

  • Of course (Score:5, Insightful)

    by Brett Buck ( 811747 ) on Saturday September 07, 2019 @01:53PM (#59169222)

    It's billions, effectively, every financial transaction will probably use a COBOL program at some point.

      It will outlive us all because it just works, it doesn't need to be improved, or supplanted, etc. It's funny, computer weenies mock it (" I could write that in 4 lines of C, ha ha!") but it's perfectly good solution to the problem they had/have.

        FORTRAN is the same way with scientific and engineering work, it's never going away, because there's no need for it to go away. It was designed more-or-less for these applications, by true professionals And with the F77+DEC extensions (or the same things from other versions), you don't need to do anything thing else or hypothetically "better". We still use FORTRAN subroutines written in the early 60s and only slightly modified since *every single day*.

    • Re: (Score:3)

      by Tablizer ( 95088 )

      [some] mock it (" I could write that in 4 lines of C, ha ha!"

      Not really. You'd need multiple libraries that handle business-oriented and data-centric idioms built into COBOL's language.

      COBOL has some handy features built in, such as hierarchical defining and naming of data blocks. You can reference the blocks by name rather than have to list each column by name.

      • Yeah, in general you don't choose the language for the features, you choose it for the libraries.
      • I've coded in lots of different languages, and NOTHING can chop up blocks of data like COBOL can.
        Personally I don't like working in COBOL, but it's not the language I don't like, it's the tedious work that goes with it.

    • FORTRAN is the same way with scientific and engineering work, it's never going away, because there's no need for it to go away. ... We still use FORTRAN subroutines written in the early 60s and only slightly modified since *every single day*.

      I don't think a lot of new scientific code is being developed in Fortran, but I could be wrong. The widely used Fortan libraries such as LAPACK (which have wrappers for C and Python and which Matlab relies on) are getting replaced by API-compatible versions such as the free (beer) Intel MKL that I don't think are written in Fortran and that are faster as long as you run on Intel CPUs.

      • Re: (Score:3)

        by stevel ( 64802 )

        I don't think a lot of new scientific code is being developed in Fortran, but I could be wrong.

        Yes, you are wrong. Fortran may not be what the "cool kids" are using, but there is a LOT of new Fortran code being written for scientific and engineering applications. Fortran also continues to evolve - Fortran 2018 was published last year. What's being written is not utility routines like LAPACK, but full-on applications in domains such as weather forecasting and optical analysis.

        COBOL is indeed still widely used, and well-paying consulting gigs are still available, but the COBOL standards committee disba

    • Even if you write it in 4 lines of C, you only need a couple lines of COBOL to use it there. :)

      Many of the Ruby and Perl libraries are implemented in C, too.

    • It's not that it just works. In many cases it could be improved. The problem is that it's just too much of a risk to replace it with new software. The current software written in COBOL is so old that there's probably nobody that knows the various parts system with all of the edge cases that have been put in over the years. While it's possible to run past transactions through a test system to verify that the new system works how would one know how far back to test to ensure that the majority of exceptional c

    • effectively, every financial transaction will probably use a COBOL program at some point.

      Yah, no. The financial system migrated to Java long ago, and much of it is now on C++.

    • It's billions, effectively, every financial transaction will probably use a COBOL program at some point. It will outlive us all because it just works, it doesn't need to be improved, or supplanted, etc

      There's plenty of stuff in the financial world that has been improved or changed. My own personal banking is totally different than it was a few decades ago. We have a lot more financial products, and nightly batch processing and mail-in checks have been replaced by real-time internet banking, phone apps, pin & chip, ATMs, and contactless payments. There are new government/tax regulations, financial mergers, and more security features to combat all the new ways to commit fraud.

  • Shit, we still have people becoming fluent in Latin as part of their jobs. What's a programming language compared to that?

    • Shit, we still have people becoming fluent in Latin as part of their jobs. What's a programming language compared to that?

      Approximately the same. One is a language used in science, the other is a language used in engineering.

      • Re: (Score:2)

        by Mal-2 ( 675116 )

        I think the cost of maintaining knowledge of a programming language is considerably less than knowing a full spoken language, but let's just say they are the same for simplicity. Even if that is the cost -- there will always be code from the past that needs to be read. Like Latin, there will always be at least a few people who know and use COBOL, because the cost of doing so is simply not that high. (This presumes civilization as a whole survives, of course.)

  • I did COBOL when I was very young, handpunching real words and comprehensible datanames into 80-column cards. It 'just worked', even if it took overnight to compile on multiple tapes. By the time I retired, there was no plain-language way of organising things. In my multi country/lingual fully ardent committees we played forever with object orientation etc., but nothing would ever actually compile usefully. Come on, youngsters, do whatever it takes...

  • It's like Latin: it's used for scientific naming because it stays the same because it's a mostly "dead" language, not shaped by trends and fads; some of them wasteful, redundant, and useless in IT.

  • Cobol consulting pays since it takes 3 times the time to write a given program.

    • Three times the typing, but that only translates to an increase of maybe 5% in time.

      And OTOH the decimal math will reduce some of the programmer time.

      • Also, not sure Cobol is the easiest language when it comes to maintenance.

        • It doesn't have anything weird like dependencies that load over git repos, so maintenance is as easy as any old code. Which could be good or bad, depending.

          It at least gives you a chance.

      • And OTOH the decimal math will reduce some of the programmer time.

        Not really. Binary math just works. The only place you need decimal is in the conversion from user input/output. That is trivial, and only needs to be done once.

  • ZDNet was around 60 years ago ???

  • It's like Latin in theology (Score:3)

    by JeffTL ( 667728 ) on Saturday September 07, 2019 @03:29PM (#59169436)
    Like Ecclesiastical Latin, the slowness or outright lack of change in the language is a feature, not a bug. Old code is still understood as originally intended.
  • Even Arduinos do COBOL.

  • A Story from my COBOL-Y2K days (Score:3, Funny)

    by Duh-People-Really ( 6172216 ) on Saturday September 07, 2019 @06:05PM (#59169588)

    There was a COBOL programmer who was tired of dealing with the Y2K (faux issue) hype so they arranged to be put into hibernation in 1998. The programmer was supposed come out of hibernation in 2002 - getting rid of all the pointy haired managers. Buried in his secret cave his timer had the Y2K leap year bug and would reset itself back to 1998 every two years. The legend of this programmer was written into Comp Sci classes all time.

    However, at some point, the secret cave was discovered and the so-called super brains figured out that the system timer had a ---- malfunction. So the super brains figured out how to stop the reset and to the hibernation system thought it was now 2002, not 2000 and it slowly woke up the COBOL programmer.

    He opened his eyes and say grey skinned pointy haired skinny things giving each other high what evers and patting each other on the back of their silvery coats. As the programmer came out of hibernation they asked - WTF? and the "things" had to slowly explain to the programmer the God Awful Truth --- The programmer had a unique job position, the year was 9997 and they were the only person on the planet who knew COBOL with the year 1,000 "Right Around the Corner".

    It's never too early to start planning for the crap to hit the fan.

    • ...with the year 1,000 "Right Around the Corner".

      I must've put a decimal point in the wrong place or something. Shit. I always do that. I always mess up some mundane detail.

  • The article is mostly bullcrap. COBOL is a compiler that translates source code written in COBOL into machine code that can be executed by a computer. No one interacts with COBOL -- they interact with the code executing on a computer. COBOL does not have to be "supported" by any given computer system or CPU, you merely have to have a compiler that can convert the COBOL source code into the machine code that executes on that computer/CPU.

    So nothing you do ever interacts with COBOL (unless you are using a

  • COBOL is tedious but it's not really complex in terms of language features. I don't believe it would be unreasonably hard to create a somewhat higher level language with a much cleaner and simpler design that could have an automated and exact translation back and forth between it and genuine COBOL code. Data representation in COBOL really is clever and could be a very interesting feature to implement in a new language and that's the only part that existing systems truly need to work with.

    Not saying it wou

  • Once I worked for an outfit pf respectable size that considered migrating to GNU/Linux using the Micro Focus library. Huge savings could have been made. Yada yada...

    The rumor was that IBM convinced both the shop and Micro Focus to consider "the implications". The project never even passed the brainstorming phase.

    Personally I don't care much for COBOL but I highly respect it for its business. The fact that it doesn't show in statistics is perhaps due to the fact that IBM and customers really don't care

Slashdot Top Deals

You know you've landed gear-up when it takes full power to taxi.

Close