A new day for Big Iron

Pressure mounts to reassess role of mainframes

As technology marches on, it's certainly not striding toward the mainframe. On the other hand, it isn't abandoning it either. Although federal information technology departments may be considering defecting from Big Iron eventually, the outcome of that deliberation — and the time frame for such a move — is far from clear. "We're seeing very little new mainframe programming. But we're also seeing almost no interest in moving [mainframe] Cobol applications to other platforms," said Diego Alfarache, technology manager at ICOM Informatics, an Austin, Texas-based developer of PC- and Web-to-mainframe communications software.

Instead, most agencies are seeking ways to extend the life of applications on their current platforms, while tentatively moving to newer programming environments, such as Java or C++ and Unix platforms, for future development.

In a way, the mainframe is like an old but trusty car. It may be a bit banged up or out of style, but it runs too well to be replaced. Besides, you probably just spent a bundle for a complete overhaul, preparing for the Year 2000 bug.

"The bottom line is it doesn't make sense to expend limited resources on a project which when completed, you end up with exactly what you started with," said Andre den Haan, vice president of product strategy at Seagull, an Atlanta, Ga.-based e-business solutions provider.

Dean Mesterharm, deputy commissioner for systems at the Social Security Administration, agrees with den Haan. "We have 35 million lines of code, mostly [mainframe] Cobol and mostly written 10 to 15 years ago," he said. "We have no intention of touching any of that."

But Mesterharm is questioning what to do about new projects. He said he is well aware that Cobol may eventually become a dead language because few colleges teach it these days. And he believes that Unix servers are at least approaching mainframe levels of capability. He has also read reports that servers are cheaper in terms of operating costs and licensing fees. But at this point, he says that issue requires further study.

"Over the next six to 12 months, we'll be looking at all the options" for new development, he said. "We may come up with a transition strategy for moving to other programming languages. But there is still a lot to consider." Currently, Mesterharm is using a number of products, primarily IBM Corp.'s WebSphere, to allow people not connected to the mainframe to access some mainframe data via the Web.

DeWayne Kalberg, chief of the Processed Commodities Systems Division (PCSD) at the Agriculture Department, said his agency is on an odyssey, almost 3 years old now, to extend the mainframe by allowing outside users to access it via PC or Web-based applications. He has been using products from Information Builders Inc. to Web-enable some mainframe applications. But now he believes that journey may lead him further afield with new Java or C++ programming.

The PCSD's odyssey began in 1999 with the Electronic Bid Entry System (EBES), a client/server-based computer system used to facilitate food procurement for worldwide distribution.

Vendors in the program are given client software, which they load on their own computers and use to enter their bids. Once the bids are entered in the onscreen forms, the information is uploaded to a USDA Web site, whose only purpose is to hold the data until the bids are opened. At that point, an operator uploads all the bid data to the IBM mainframe DB2 database, from which procurement officers can access them.

Next, in April 2000, the PCSD released the Domestic Electronic Bid Entry System (DEBES), which is similar to EBES but is aimed at food procurement for domestic distribution. The technology of this system varied from EBES. Instead of requiring client software, vendors use a standard Web browser to access the online bid form directly from the Web site. "This was a step forward in that it got us out of the business of supporting and distributing client software," Kalberg said.

Because EBES and DEBES allow vendors to enter bids closer to their opening times, reducing the risk of price fluctuations for them, the bids were on average 1 percent lower than before the systems were in place. As a result, the agency saved $12 million.

A further step in the PCSD's journey gives vendors two-way communications with the mainframe back end via the Web. The ED3 (Electronic Distribution of Disbursement Data) Web site allows vendors to get information about the status of their invoices.

New projects at PCSD will involve a more dramatic shift away from the mainframe than any of the previous ones. Kalberg said the PCSD and many other USDA divisions have agreed to standardize on IBM's VisualAge for Java as a programming environment. That means Web-based Java, not Cobol, will be the programming language increasingly used for new development projects.

But Kalberg and others at the USDA are not yet convinced that this move to Java will be a boon for the agency. For one thing, hiring Java programmers will dilute the PCSD programming pool, which is now entirely composed of Cobol programmers.

All the older systems — EBES, DEBES and ED3 — will remain where they are. And whether further development moves off the mainframe or not will depend on more evaluation. "Like a lot of people, we're still trying to figure out what is best," Kalberg said.

Stevens is a freelance journalist who has written about information technology since 1982.

p

NEXT STORY: Anti-terror law expands powers