In-Depth

Big Blue Gives Mainframe Programming a Rational Retrofit

IBM’s new Rational offerings make it easier for customers to expose COBOL assets as Web services and automatically generate COBOL or Java code

• By Stephen Swoyer
• 11/13/2007

When IBM Corp. first kicked off its $100 million dollar mainframe simplification effort last October, it promised to deliver Big Iron management and development tools that were both more powerful and easier to use.

Last week, IBM delivered on the software development component of that promise.

Big Blue unveiled a raft of new mainframe-oriented Rational development tools, including retooled COBOL and PL/I compilers for z/OS; a turn-key COBOL or Java code generation tool (the obliquely-titled IBM Rational Business Developer Extension); and a new rapid component development (RCD) tool that scans existing COBOL code, identifies useful jobs or processes, and automatically "componentizes" them (the more intelligibly-branded IBM Rational Transformation Workbench.)

The upshot, IBM officials claim, is that its new Rational deliverables will make it easier for customers to expose their existing COBOL assets as Web services; generate clean, highly efficient COBOL or Java code; and more meaningfully involve System z in their ever-evolving enterprise architectures.

IBM’s Rational product push is consistent with its ongoing effort to recast the mainframe as a central player—as, in fact, an information processing and data management hub—for the enterprise. It’s a no-brainer strategy according to IBM officials. Says Dave Locke, director of offerings marketing with IBM Rational Software, "Some 200 billion lines of [COBOL] code are involved here. These are all known-good applications supporting the business. There are processes, business rules embedded in that software. Companies are under all this pressure to be more innovative. They have global acquisitions, they have consolidation of markets, [and] they have competitors all over the place.

"This is proven code. Why shouldn’t they take advantage of this proven code in innovative new ways? That’s the capability we’re delivering here."

The idea, Locke says, is to ensure that the mainframe doesn’t just remain relevant or viable, but that it continues to thrive. In this respect, IBM touts a new spin on code reuse—this time courtesy of its Transaction Workbench v3.1 product. Many of the services or business processes organizations want to deploy to distributed users are already instantiated in COBOL applications.

Instead of writing new and possibly kludgey code to deliver these services, why shouldn’t developers simply take advantage of an organization’s existing—and empirically stable—COBOL code? That’s the idea driving Transformation Workbench, says Locke. "The idea is to further empower the mainframe, so we have Transformation Workbench, which is a tool that looks at COBOL [and] actually parses through it to find and recommend components to use. It also looks for other things like good code and dead code and some efficiencies like that," he indicates.

"To give you an example, I’m a bank, I approve loans. Part of this is getting a credit report. Now if I’m a developer, I could write something from scratch to do this, or I could take advantage of this proven—this "known-good"—code on the mainframe. I can "componentize" that code and [expose it] through a Web application or some other model."

Locke explains that this doesn’t just involve service-enabling an existing application on the mainframe, but (even more intriguing) service-enabling a discrete service or process—often one that’s buried inside of (as a data structure or subroutine, for example) a larger COBOL application.

In this respect, he maintains, Transformation Workbench simultaneously promotes code reuse—in this case, of COBOL code that’s "known good" (i.e., clean, efficient, and stable)—and a bigger role for Big Iron. Call it a win-win—for both the enterprise and Big Iron.

Elsewhere, the Rational Business Developer Extension v7.0 uses code written in IBM’s Enterprise Generation Language (EGL) to generate COBOL or Java output code. EGLcan help COBOL jockeys get up to speed on object-oriented methods and practices, Locke says, without plunging heedlessly into Java coding.

"These mainframe developers, they have a lot of history with that [COBOL] code. They can’t transition to Java very well, so how do we keep them using COBOL but bring them into a more modern [development environment]? The answer is EGL. It’s a higher-level language [with construction] similar to COBOL so they can easily transition, but it also has capabilities that specifically allow you to work in an SOA environment," he explains.

"The language actually has a keyword called ‘SOA Component,’ so it actually understands and does a lot of the work of componentization. What we’ve done is basically provide a language that lets [mainframe programmers] leverage their skills in COBOL and be able to interface to a more modern architecture like SOA."

Other new Rational deliverables include improved COBOL and PL/I compilers (Enterprise COBOL for z/OS v4.1 and Enterprise PL/I for z/OS v3.7, respectively). The new compilers integrate System z applications with Web-oriented business processes and can help simplify the componentization of COBOL and PL/I applications, Locke maintains. In addition, Big Blue announced a Rational Method Composer v7.2 RUP for System z v1.0 plug-in; new Rational ClearCase v7 z/OS extensions that help developers manage asset changes across distributed and host-based platforms; Rational ClearQuest v7 z/OS support; and Rational BuildForge (the latter lets code writers automate their build and release management activities for distributed and host-based platforms).

Rational’s Big Iron development deliverables help automate many of the mundane aspects of service enablement and mainframe-based SOA application development, Locke says—but they don’t and can’t obviate the need for skilled mainframe software developers. If anything, he argues, they’ll help amplify the contributions mainframe coders make.

"It definitely requires developer interaction. You could not have a line-of-business person going in there and working these tools; nor would you want to. You need to have someone who’s development-savvy, for sure," he concludes.

"It really significantly reduces a lot of the mundane tasks. I have this monolithic COBOL application: how would I componentize it today? I’d go though it line by line and I’d look for comments in the code. This automates a lot of that drudgery, but it still takes an intellectual developer to say, ‘I’ve parsed it, I’ve looked at it, it’s made its recommendations, but now I need to make some decisions about what to do with it. Then I’ve got to go write some EGL to be able to wrap it.'"