COBOL gets a web-friendly facelift on IBM mainframes

COBOL gets a web-friendly facelift on IBM mainframes

Summary: COBOL apps for IBM System z mainframes should see improved performance following the latest release of IBM Enterprise COBOL for z/OS.


IBM has overhauled how the 50-year-old programming language COBOL runs on its System z mainframes to give COBOL apps a web-friendly facelift.

Despite COBOL's age IBM estimates that more than 200 billion lines of COBOL code are still being used across industries such as banking, insurance and retail.

IBM is attempting to streamline development of COBOL apps for its System z mainframes with the latest release of IBM Enterprise COBOL for z/OS, its COBOL compiler for z/OS.

COBOL apps using the compiler should see improved performance, with IBM claiming that in testing some applications' performance increased by 10 to 20 percent.

The compiler should also allow COBOL software to more easily swap information with websites and apps thanks to changes in the parsing of XML, the mark-up language commonly used to share information over the web. The new compiler allows parsing workloads to be offloaded to speciality engines. Interoperability with Java 7 should also make it easier to integrate COBOL software with new web apps.

Improvements to UTF-8 Unicode handling will make language support easier and increased compiler limts will allow larger data items and groups of data to be handled, as well as improving application exploitation of system resources. Support for unbounded tables and groups has also been added to improve usability in defining variable length tables and groups.

A new level of z/OS System Management Facilities tracking should also reduce the administrative burden for users who implement sub-capacity tracking.

IBM Enterprise COBOL for z/OS v5.1 compiler works with the latest versions of IBM Customer Information Control System (CICS), Information Management System (IMS) and DB2 software. It is expected to be released in June. More information about v5.1 is available here.

In spite of COBOL's continued use by the enterprise, a recent survey of academics found the majority of universities do not teach the programming language on their curriculum.

Topics: Enterprise Software, Hardware, IBM, Software Development


Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Do COBOL Programmers Even Know What "XML" Stands For?

    And are there really any performance-intensive COBOL apps?

    (Just to prove I'm qualified to make that comment--yes, I know what "USAGE IS COMPUTATIONAL" means!)
    • No performance intensive COBOL apps.

      The reason there are no performance intensive COBOL apps, is because the IBM Mainframe cpus are really slow. The newest z12 at 5.26GHz and close to 200MB cpu cache, is actually far slower than a high end x86 cpu. You can emulate a IBM Mainframe on a laptop with open sourced "TurboHercules". That is the reason IBM attacked TurboHercules, because if the emulation was not successful IBM would not have cared. But emulation is successful, so IBM has attacked Hercules derivatives.
      An 8-socket x86 server gives 3.200 MIPS under software emulation, which is 5-10x slower than running native code. This means, if you could run native code, then the x86 server would give 5-10x more MIPS, which translates to 16.000-32.000 MIPS. This is almost inline with the biggest IBM Mainframe with 24 cpus, which gives ca 50.000 MIPS.

      Here is another Mainframe specialist that concludes that 1 MIPS equals 4MHz on x86. This means that 50.000 MIPS equals 200.000 MHz. But a 10-core x86 cpu running at 3GHz, gives 30.000MHz. Thus, we need only a few x86 cpus to match the biggest IBM Mainframe.

      Ergo, IBM Mainframe cpus are really slow, and that is the reason IBM never releases Mainframe benchmarks such as SPECint2006, etc. That is also the reason IBM Mainframes are never used for number crunching. Instead, use a cheap x86 cluster that gives much more performance than a Mainframe.

      To be fair, Mainframes have superior I/O. That is the reason you use Mainframes: to get superior I/O.
      • MHz?

        It's the Operating System running circles around anything else.
        MHz has no meaning, unless you're looking at an Android tablet.
        As far as COBOL goes, take a look at the biggest banks around.
        Running on Linux Servers, using Java, perchance?
        'nuf said.
        • Re: It's the Operating System running circles around anything else.

          Really?? Where you can't even make a file bigger without having to manually allocate another storage area for it?

          Yes, there are mainframe installations running Linux. On those mainframes.
      • not exactly.

        "few x86 cpus to match the biggest IBM Mainframe."

        Not even in a single Z mainframe.

        One of those can handle over 1500 instances of a guest OS.

        Try that with an x86-64.

        Not happening.
        • Re: One of those can handle over 1500 instances of a guest OS.

          As opposed to Linux, which regularly runs multiple roles side by side on the same OS instance, because that's what's meant by a "multi-user" OS.

          A single Linux instance was successfully tested running 100,000 processes years ago.
      • Re: To be fair, Mainframes have superior I/O

        That's the point: "performance-intensive" doesn't mean "CPU-intensive", but "I/O-intensive". Hence "RESERVE n ALTERNATE AREAS" and all that jazz.
    • ldo17

      Usage computational is a start. How about comp-3 and comp-5 and when to use them. Also a bit of level 88. I once entered a language performance competition on behalf of MicroFocus COBOL and won it easily against C and others.
  • Um ...

    I guess, since I have been doing COBOL since 1978 and I do , lets see:

    Perl, Python, C, C++, Java, Ruby, administer Apache and Tom Cat Servers.

    Oh, yeah, Have done WEB PAGE output via HTML tags in a Acu Cobol program.

    Now, any more questions ?
  • Really?

    How is this news? I'm pretty sure both COBOL programmers have already been informed by IBM.
  • XML - Yes, plus many others

    I started with COBOL in 1980, since then, Assembler, Java, C, C#.NET, BAT & CMD, Prolog, Basic (yuck), Javascript, Python, VBScript, HTML, CSS, XSD, XSLT, VMWare (20 OS images and counting on my home network), Blaze Advisor SRL, Corticon, PL/SQL, IMS DB/DC, CICS and so on and so on to just name a few. Wow, what arrogance! "If you know COBOL you must be stupid." Hey idiot, a tool is a tool. Just because you ran into one person who knew COBOL and didn't want to do anything else doesn't mean everyone is so limited. Please open your mind, shut your mouth, and get some experience out in the real world before passing around insults.
  • And the beat goes on ...

    COBOL is not dead. It's well into middle age, but not dead.
    A friend of mine works for one of the Big financial companies. They still have many systems running COBOL. If it ain't broke ... Besides the cost to replace them would be massive.
    The fun part is that they are paying a bounty for COBOL programmers.
  • I used COBOL for about eight months

    Back around 1982, I maintained an hourly personnel system in COBOL. The application was in the process of being replaced, though I wonder if it actually ever was, and if so, by what? It wasn't the COBOL programs that were the problem, it was the interaction with the transaction processing monitor. The programs were so old that many of the TP components were written using BTAM, and IBM 360 Assembly Language was now most of that stuff was accessed, and it never got changed.

    To me, that would have been more of a maintenance issue than the COBOL code; we routinely changed a half dozen to a dozen applications per week in our group in order to meet changing personnel requirements. That doesn't strike me as something particularly difficult to document or maintain. No wonder COBOL lives on.

    As far as interacting with XML or any Web-based stuff, all you'd need in COBOL would be a way to make procedural calls; that stuff should have been available years ago; I suspect it has been. This is just either about some new tool or rehashing old news; COBOL has kept up. Record structures can be easily defined in either COBOL, C, C++, C#, PL/1, or Pascal; more important are the tools to interact with data and application libraries, and the necessary support skills. To me, anyone who knows five or more programming languages could probably read the code as is, and by grabbing a book on COBOL, could probably maintain most well-written COBOL apps - if they are a decent development support engineer.
  • Say goodnight, COBOL. Goodnight COBOL.

    That 200 billion line quote dates back to 1997, and it's credited to Gartner. A whole lot has happened during the past 16 years, and little of it is good for the future prospects of COBOL. Y2K drove lots of universities to dump their homegrown ERP solutions written in COBOL, and replace them with PeopleSoft, SAP, SunGard, etc. which are NOT written in COBOL. The biggest banks, insurance companies, and credit bureaus have their own in-house COBOL operations, but smaller players in these markets use a service bureau or build something NOT written in COBOL. GE Healthcare (formerly IDX, formerly PHAMIS) and McKesson are the last two hospital clinical software products written in COBOL, and GE is fading and dying in this market.

    I've been a Cobologist for 23 years, but the lights are going out on COBOL. Stop with the "COBOL is dead! COBOL is alive!" talk and focus on the future potential of COBOL development opportunities. I knows LOTS of unemployed Cobolasaurs who are actively looking. The need just ain't there.