Sign up for our newsletter.

I agree to this site's Privacy Policy.

Staying Power!

The Big Idea

Not Fade Away

  • COBOL is not about to go away. According to the Gartner research firm, the aggregate base of COBOL code—which exceeds 200 billion lines—continues to grow each year.
  • COBOL codejockeys who come to the mainframe from OO programming backgrounds prefer to stick with vanilla COBOL 85.
  • In mainframe model-driven architecture, business requirements are expressed in the context of a model, and not specified explicitly in COBOL code, so they can be easily modified.

Common Business Oriented Language and Assembler rule today's mainframe shops, but enterprise codejockeys have more application development options than ever. Even programmers who have little or no mainframe experience can write C, C++ or Java code on Windows and Linux systems and recompile it to run on heavy-metal systems. COBOLis not about to go away. Many COBOLapps have been running nonstop for decades, and according to the Gartner research firm, the aggregate base of COBOL code—which exceeds 200 billion lines—continues to grow each year.

Staying  Power

What's more, service enablement and service-oriented architectures have given legacy apps a new lease on life. Key application features can be exposed as services, which lets the mainframe behave as a good citizen in the heterogeneous enterprise landscapes of today. Given the preponderance of mission-critical data sitting in CICS, IMS, VSAM and other mainframe data sources, that's a good thing.

There's another wrinkle, says Tyler Allman, a product manager with app dev testing tools vendor Compuware: The richly declarative and copiously documented COBOLlanguage is ideally suited for the requirements of business. COBOL often strikes executive decision-makers as a safer, more reliable bet than 3GL languages such as C or Java—even as IBM is impelling customers toward mainframe-based Linux and WebSphere solutions.


Turing Award winner Edsger Dijkstra, a fierce critic of COBOL, assailed that language’s highly declarative syntax. In an infamous formulation (which he later repudiated) Dijkstra argued, &The use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal offense.&

In terms of runtime performance alone, [COBOL] is several times faster than Java,& Allman argues. &And COBOLis a very well understood, self-documenting language. It is often the case that people are able to get some initial code written in Java fairly quickly, but there are many challenges as you try to ramp that application up, in terms of debugging—especially when you've got these very, very granular methods—tracing through where the problem is.&

Evolution through intelligent design
COBOLhas evolved and bears only a passing resemblance to the first incarnation, which debuted in 1959. Now COBOL is UNICODE—compliant, object oriented and XMLfriendly. It can be a full-fledged participant in MDAdevelopment. Web services can be called natively from COBOL apps, and COBOL apps or services can be wrapped in Java. And although IBM has pushed zLinux as a strategy to help break the mainframe's dependency on COBOL, some big-iron shops are deploying COBOLapps on mainframe Linux. Talk about staying power.

The changes introduced as part of the revised COBOL 2002 standard were the first since COBOL 1985 introduced support for local variables, dynamic memory allocation and other conceptual fixtures of modern 3GLs. The result is that COBOL 2002 is object oriented, though it's doubtful that most COBOL codejockeys are taking advantage of its OO capabilities.

&In production environments, over three-quarters of [our customers] are generating straight COBOLcode,& says Mike Smith, VP of development with Computer Associates. Smith heads up CA's All-Fusion Gen, a model-driven development tool that's used by organizations to generate COBOLcode for their mainframes.

Help Wanted: Sooner or Later

Many codejockeys cross over to the mainframe world when opportunity knocks. That's the path followed by Chris Little, a 35-year-old mainframe technologist with the Department of Human Services who parlayed his skill with Linux into a career working with mainframes. "I came up through operations," Little says. "That was my first mainframe experience." He started managing and programming his employer's HP-UX resources, followed by some "light" z/OS coding responsibilities. "I wrote some CLISTS and REXX scripts to load DB2 stuff," Little says. "A few years ago, management decided to put Linux on our zSeries. To make it useful, I needed to learn z/VM. Most of my day-to-day work is in the zSeries space, supporting our Linux activities."

Little does more zLinux management than programming, but he's picking up other mainframe skills along the way. For example, although he isn't a COBOL programmer by trade, he is learning the ropes from his colleague, systems programming veteran Ken Sharpe. "Chris is the baby around here, but...we can't [help but] notice he is good at what he does...[he's] just more gung ho than us gray hairs, so [he] could use some aging," Sharpe deadpans.

Like many mainframe programmers, Sharpe enjoys the life. He says there's always work, and he isn't worried about being forced to retire. He thinks it's a good opportunity for other codejockeys who cross over from other skill areas. In most cases, Sharpe says, such mainframe transplants typically move on to bigger and better things. "It's hard working for state government to get someone who is young and to train them. That's because if they are good quality, they end up going somewhere else."

All isn't sweetness and light. Mainframe skills are among those most likely to be outsourced, in some cases to offshore locales. There are several reasons for this: the two most important are the comparative maturity of mainframe apps and the relative high cost of big-iron programming expertise. As it stands now, much of the work proper of mainframe systems programming consists of maintenance activities such as break-fix coding or implementing new feature requests. Such activities are viewed as easy to outsource. "When it makes sense economically to put an application into standard maintenance mode, you're going to look for your best cost performance to do that, and in a lot of cases, you get your best cost performance by outsourcing it," confirms Mike Smith, VP of development with Computer Associates.

Nevertheless, Smith and other mainframe boosters say codejockeys who are mulling career changes should think about crossing over. For every mature mainframe app that's outsourced as standard maintenance, there's an existing application--written in Assembler, COBOL and, increasingly, Java or J2EE--that's being refitted for new life, either as part of a service-enablement initiative or simply because of changing business requirements.

"It goes beyond SOAs," Smith says. "Customers are also looking at their mainframe [application] portfolios and seeing an opportunity to create new offerings and add some business logic and new code to existing applications. When you think about how much money companies have invested [in their mainframes], these kinds of [mainframe app dev] skills will always be in demand."

Stephen Swoyer

Same old COBOL
Even COBOLcodejockeys who come to the mainframe from OO programming backgrounds prefer to stick with vanilla COBOL 85. "I've heard about [OO COBOL], but I've never really talked to anybody who's used it," confirms Josh Smith, a mainframe system programmer with The Timken Comany, a manufacturing giant. "Most everybody I work with has been here for 10 years or more, and we've been using mainframes for more than 30 years now. But we're still going by the most recent ANSI standard."

In comparison to mainframe's elders, Smith is a bright-eyed youngster. His first exposure to mainframe coding was in college, when he had a chance to program Assembler on mainframe hardware that IBM donated to his school as part of its zSeries Academic Initiative.

He was hired straight out of college by Timken, which—like most other longtime mainframe shops—is desperate to recruit new mainframe expertise. Like most of his classmates, Smith cut his teeth on 3GL languages and visual development tools. Slightly more than a year after graduating, however, he’s at home writing COBOLcode on a 3270 terminal.

“Generally I enjoy it,” he says. “There are a few things that seem backward from the way they’re done in other languages. Of course, because I picked up COBOL after these other languages, that’s why they seem backward to me,” he comments. “It’s a little easier to read than some of the other languages, especially compared to C++. It reads almost like English.”

If the COBOL 2002 OO extensionsare of dubious value to the vast majority of mainframe programmers, another of today’s most salient app dev paradigms—MDA—has been far more successful.

New world of heavy-metal app dev
Larry Schmidt wears a couple of hats for services giant Electronic Data Systems. He’s an enterprise architect, for starters,
and he’s also chief architect of application delivery for EDS’ booming healthcare practice. In this capacity, he oversees
an enormous mainframe development project—the company’s MetaVance, a claims-processing solution that EDS markets to U.S. healthcare insurers. It’s available for AIX, HP-UXand Solaris, in addition to the venerable mainframe. In its big-iron form, it consists almost entirely of COBOL code. It’s based on an older IMS-based application (IMS is a non-relational mainframe data store), but—almost 10 years on—bears only a facile resemblance to its predecessor.

MetaVance is a textbook example of the brave new world of mainframe app dev. Although it’s written in COBOL, its development owes very little to the coding efforts of COBOL programmers. That’s because MetaVance is a product of CA’s AllFusion Gen model-driven development tool. This means programmers and business analysts collaborate to build models that AllFusion Gen uses to generate COBOL code for mainframe systems and C code for UNIXplatforms.

The $64,000 Question

Mainframe boosters say programmers don’t need to know a thing about COBOL, Assembler or another legacy language to develop software for the mainframe apps of today. Now that there’s a mainframe-ready flavor of Linux and a mainframe engine specifically optimized for Java, codejockeys can easily develop software for mainframe systems from the comfort of Microsoft Windows, Linux or UNIX workstations. So what are they waiting for?

There's a method to IBM's madness, says Mike Bliss, System z9 and zSeries director with IBM. "From an application development perspective, recruiting is probably the biggest concern [customers] have," he comments. "It's the systems programmers; it's the application developers they're most worried about. It's replacing the folks that are getting closer to retirement that have a good view of the system, and that includes software architects, too."

Stephen Swoyer

This approach has a number of advantages, Schmidt says. “Since [the mainframe] has been around now for 40 or 50 years, some of our COBOL programmers have been around for a long time, too, [and] the only knowledge we have of these programs is in their heads. So what happens when they retire?”

MDA helps to inoculate EDS and its customers against the effects of these and other disruptions, Schmidt says. “I think MDA gives us requirements that are expressed at a higher level than COBOL or Assembler programming, which I think allows a larger population to understand what the system is doing.”

From a technology perspective, healthcare is a reliably dynamic field: there are HIPAA requirements, for starters, along with a host of state and even local requirements, some that change yearly.

Mainframe DNA
In mainframe MDA, business requirements are expressed in the context of a model, and not specified in COBOL code, so they can be easily modified. Mainframe shops are notoriously risk averse. Many continue to develop software just as they have for decades. And some performance-conscious customers will balk at the idea of running generated code on their expensive mainframe hardware.

Model-driven development as a pervasive design methodology isn’t without its critics, either. As for the first objection, EDS’ programmers typically do very little to tweak the COBOL code generated by AllFusion Gen, Schmidt says. And even granting the legitimate objections of MDA’s discontents, there are cases in which even the most conservative of mainframe development shops might want to consider a model-driven approach.

“It really depends on what their business drivers are,” Schmidt explains. “If it turns out that the enterprise is pretty stable, and change for that specific enterprise is something that is very small, it might not be worth the effort to move into a model-driven architecture. If it turns out that you’re in a volatile industry where the rate of change is very fast, having the ability to express requirements as models improves the overall productivity of the developers and allows you a faster speed to market with whatever changes need to occur.”

IBM Takes the Initiative

Earlier this year, IBM announced an ambitious new program called the Academic Initiative for zSeries to expose college students to mainframe concepts and methods. The program involves more than 150 colleges and technical institutions and provides students and instructors handson access to zSeries mainframes, a mainframe-oriented curriculum, expert assistance and training. IBM hopes the Academic Initiative will recruit as many as 20,000 mainframe pros over the next 5 years.

There's a method to IBM's madness, says Mike Bliss, System z9 and zSeries director with IBM. "From an application development perspective, recruiting is probably the biggest concern [customers] have," he comments. "It's the systems programmers; it's the application developers they're most worried about. It's replacing the folks that are getting closer to retirement that have a good view of the system, and that includes software architects, too."

--Stephen Swoyer

It’s irresistible
IBM is betting customers who deploy Linux on heavy metal will exploit the GNU development stack or the Eclipse IDE to build 3GLapps. There’s some hope for this strategy: zLinux and WebSphere-onzSeries workloads account for the bulk of
new mainframe capacity. However, there hasn’t been an explosion in zLinux-based app dev. And mainframe WebSphere is
only just starting to pick up steam.

If nothing else, the promise of moving expensive COBOL apps running under z/OS to IBM’s deep-discounted zLinux
engines is irresistible. That’s the approach taken by COBOLprogrammer Joe Poole’s employer, a prominent retailer. His costconscious CIO is determined to wean his company off expensive z/OS mainframe capacity—even if it means porting its entire application stack to zLinux. “COBOL is still the primary language, so much so that the CIO has been looking at Acu-
COBOLas another way of developing applications on Linux rather than z/OS,” Poole explains. “He’s looking to reduce the
software budget any way possible, and still use the existing programming staff.”


  • COBOL-to-Java translation tool
    By Linda L. Briggs
  • Legacy integration tools driven by SOA
    By Linda L. Briggs
  • Enterprise modernization: New life for old apps
    By Jason Halla
comments powered by Disqus