In-Depth

Staying Power!

• By Stephen Swoyer
• December 1, 2005

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.

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.

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.

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.

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.”

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.”

ILLUSTRATION BY CHRISTOPHER ZACHAROW