Webifying Mainframe Apps: Lessons from the Field

Watch out for hidden costs, both in tools and people

Not everyone loves reworking Cobol applications. Angelo Serra certainly doesn't. "It was hell," says the systems supervisor at the Ohio Department of Transportation, as he describes his work adding a Java interface to a Cobol time-management system. "People can draw neat diagrams (describing the process), but it wasn't easy."

Serra isn't alone in running into problems crafting fixes and interfaces to extend the life and reach of Cobol applications. To save time and leverage existing software and labor assets, a number of companies are opening up their Cobol programs to PCs, Web browsers and other client devices, using internal networks and the Web.

"A lot of companies are running on borrowed time" in their rush to webify mainframe applications, says Charlie Burns, a vice president at research firm Giga Information Group Inc. in Cambridge, Mass. Year 2000 concerns "forced them to document their code and do an inventory on linkages. And in doing so, they realized their Cobol applications were not fixed but reusable assets."

But dusting off old Cobol applications for new levels of client access can involve unexpected difficulties and costs. Veteran developers and analysts recommend investing time up front to address the complexities of adding Web servers to mainframe environments, deciding where best to place the business logic within the application infrastructure and calculating the costs and availability of tools to do the job.

The Search for Tools

Developers say making over their old Cobol applications with a new interface costs much less than starting from scratch. However, you still need to factor in time spent finding the right tools to finish the job and the costs of the tools themselves. These costs, as well as those for labor, can quickly drive up the overall price tag.

Midway through a project to put a Windows interface on a Cobol printing application, developer Bill Kooistra at Poorman-Douglas Corp. in Beaverton, Ore., realized he needed to simulate the batch commands used in mainframes in a Windows environment.

"I started working on it but could not get all the pieces together," Kooistra says of the stalled project. "Mainframes process jobs in batches using a sequence of steps, but PCs do not use batch tools."

Kooistra wanted to create a PC network to access the Cobol application and use the same procedures in that application to extract, convert and sort data for printing bank statements and utility bills, which is the core of Poorman-Douglas' business.

He spent valuable time searching for a tool to process batch commands in a Windows environment and eventually found WinBatch from Seattle-based Wilson WindowWare Inc., but the search put the project on hold. "You need to know what tools you need for the PC environment up front," he advises.

Complicating the issue is the fact that not all Cobol applications run on mainframes. For example, Todd Thomas, director of product development at Health Data Services Inc. in Cleveland, wanted to move his 10-year-old PC-based Cobol claims-processing applications, written for pre-Windows PCs and in non-ANSI-standard Cobol, to Windows. Thomas needed a precompiler to perform syntax conversions on the Cobol code, and rewriting the applications wasn't an option.

"I've got 3,000 programs full of legacy Cobol code that would have to be rewritten in another (language), and I have about 25 Cobol programmers with 425 years of experience on staff," Thomas says. "Our goal was to move to an object-oriented, Windows-based development platform while salvaging our legacy code and leveraging our existing (personnel) in Cobol."

Thomas faced two choices during the project's design phase: spend $20,000 and wait eight weeks for a custom-built precompiler from San Jose-based Fujitsu Software Corp. or build one in-house, an undertaking that would require several hundred man-hours. Thomas decided to buy the precompiler, because "even bigger than the man-hours spent would have been the cost to pull those guys off other projects," if it had been built in-house.

Mixing Web Servers With Mainframes

Including a Web server in a mainframe computing environment presents another set of challenges. Randy Kriz, president of Orbis Systems Inc., a consulting firm and developer of health care software in Ingleside, Ill., shopped long and hard to find an Internet service provider that would provide a Web server for his Cobol applications.

"If you have your own dedicated server it's not an issue, but some (Internet service providers) will not install a mainframe runtime environment on their servers," Kriz says. "A lot of ISPs are afraid because they don't have experience with mainframes. If your application locks up their computer, it locks up 75 other people too."

"Most mainframe people are used to being able to walk into the next room and check on their computer, but with an ISP, the Web server is down the block or across the country," Kriz adds.

Bill Kwelty, a customer information services manager at Automotive Resources International Inc. in Mount Laurel, N.J., says he went through "hurdles" finding a gateway for the fleet-management firm's Groupe Bull DPS7000 mainframe, and deciding whether to install the gateway on the Web server or on the mainframe.

"Developers should first decide whether the gateway resides on the Web server or mainframe. The Web server requires less resources to configure the gateway" than a mainframe, he says.

Kwelty needed the gateway to route data in real time from the Cobol fleet-management application to client machines. He crafted an interim solution, putting part of the gateway on the mainframe and part on the Web server, until an upgrade to French vendor Groupe Bull's Open7 gateway became available. By adding the gateway, Kwelty was able to keep his data synchronized so that it reflected both updates made internally to the mainframe and those made by customers using the Web.

His goal was to make it easier to execute real-time updates without slowing down processing for people using Web browsers and Java clients.

Finding a Home for the Business Logic

Another critical issue involves the business logic. Many legacy Cobol applications contain well-defined business rules for data entry, updates, queries and reports. Developers need to decide whether to keep this logic within the source code of Cobol applications or encapsulate the logic with the data using an object-oriented design structure. Most distributed client/server environments rely on the latter approach.

"In most Cobol programs, the business logic is fragmented and not kept attached to the related data," explains Brian Reithel, a computer sciences associate professor at the University of Mississippi in Oxford. "It's better to view the database as a repository for data." For example, an order-processing Cobol application may contain a business rule that requires customers with a certain quantity of orders to pay special shipment fees. If that obscure logic is hidden within a source file, an update to the application may not also update that rule.

Instead, Reithel suggests capturing the business logic in JavaScript within an HTML file or within the database interface using Open Database Connectivity (ODBC) drivers or Common Object Request Broker Architecture objects. This allows developers to quickly update the data and the business logic at the same time, without having to search through source files on the mainframe to find that logic.

Moving the business rules closer to the data also "sets the stage for migration away from a Cobol-centric model to standard interfaces, like ODBC, which sit between the Web client and the database in a distributed client/server model," Reithel adds.

Serra's team of developers spent nine months crafting a Java interface for the Ohio Department of Transportation's Cobol time-management application. Their two-tier architecture put the calculation work on the client machines, which accessed data on the mainframes. By putting the Java rules engine on the client, it took longer to process requests than if the business logic resided on a separate database.

"The business logic was being pumped down to the client side," says Serra. "If I could do it again, I would not have built a two-tier application . . . because it made the (application) a complete pig." Serra's group is rewriting the interface but plans to migrate away from the mainframe environment.

Cobol developers were divided on whether to continue executing the procedure code within Cobol programs or implement an object-oriented approach.

Frank Boyle, former deputy CIO at the U.S.Department of Agriculture's Agricultural Marketing Service in Washington, chose to process the business logic within his Cobol application when he recently revamped the agency's decades-old financial information system.

"One of the big advantages is reusing a lot of the business logic and not having to recode," Boyle says. "It takes a lot of time to get it right and to get the knowledge of how to handle the data. It took months of interviews with internal groups and testing to work out the business logic, so a lot of aggravation is saved if you save that logic."

However, Boyle says he might consider a different setup if designing a new system. "But it would have made our project four times as expensive if we had gone the other route" and replaced the business logic.

Copyright © 2000 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon