Thursday, March 28, 2024

Forever COBOL

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.


In the beginning, there was COBOL. These stalwart, usually mainframe-based, applications ran businesses for over 40 years. Today–surprise!–COBOL applications are with us still, whether they run on the same big iron or have migrated to more open environments. But these tried-and-true applications no longer have to present a green-screen face to the world. Indeed, many COBOL applications now have fancy graphical front ends, even Web capability. This is not your father’s COBOL.

IT managers today are likely to be grappling with how to put a fresh face on the aging applications that have been running their business for decades. “Modernizing legacy applications is the key issue facing IT managers today because there’s enormous pressure on organizations to change the way they run their business to meet the new paradigm for commerce. Modernizing legacy apps is at the heart of that,” says Robert Mack, vice president and research area director in the IT business management group at GartnerGroup Inc., in Stamford, Conn.

Systems manager Joe Horlander and project leader Al Halligan, both on the manufacturing systems team at distiller Seagram Americas, wanted to avoid rewriting 1.8 million lines of code.
Photo: Jim Callaway/SABA

In companies around the globe, IT managers are taking varied approaches to modernizing their legacy applications (see chart, “Making the move”) Some companies have unplugged the mainframe (or aging minicomputers such as Wang), rewritten their core applications, and moved to platforms such as UNIX or Microsoft Corp. Windows NT. Rewriting COBOL applications from the ground up is the costliest and most time-consuming option, says Pam Coker, president and CEO of Acucorp Inc., a maker of application transformation tools, in San Diego.

AT A GLANCE: Seagram Americas

The company: Maintaining legacy COBOL code on a UNIX platform

The problem: Maintaining legacy COBOL code on a UNIX platform

The solution: Unicon’s conversion of the legacy COBOL to pure ACUCOBOL-GT

The IT infrastructure: Seagram’s legacy computing environment consisted of an IBM ES9000 model R32 mainframe running VM/VSE with 150 attached terminals. The database was IBM’s DL/1. AS/400 machines host the company’s homegrown COBOL-based financial systems. The post-migration computing environment includes two Hewlett-Packard servers running HP/UX and Cincom’s Supra Server database.

Another option is to convert the legacy COBOL applications to an open systems COBOL, such as Acucorp’s ACUCOBOL-GT or Merant’s Micro Focus to “rehost” COBOL applications on another platform. Many IT managers believe this gives them the advantage of a lower-cost hardware platform while maintaining their familiar COBOL applications (see “The best of both worlds,” below). And they can make their users happy by putting in an easy-to-use graphical user interface (GUI) on top of the COBOL code. Many companies are rejuvenating their legacy applications, using the power and functionality of the new COBOL languages like ACUCOBOL, says Jim Garden, director of technical services for Technology Business Research Inc., a market research company in Hampton, N.H. “It’s a highly cost-effective approach to the problem of what to do with legacy applications.”

Some companies (especially those in the financial services sector) would never dream of bidding their mainframes adieu–for them, the mainframe is simply the most reliable and robust computing platform around for processing financial transactions. Since the Internet is becoming an inescapable aspect of doing business, these companies are finding ways to Web-enable their mainframe-based COBOL applications (see chart “New lease on life,” below). A whole raft of tools have blossomed in this space, from Ottawa-based Simware Inc.’s Salvo to London-based Intelligent Environments Group PLC’s Amazon Integrator.

The message is there are lots of ways–some less expensive than others–to let a little fresh air and sunlight into the fusty, but reliable legacy code that has run businesses for these many decades. Read on for ideas and inspiration.

The best of both worlds

Joe Horlander gets to have his cake and eat it, too.

Horlander, manager of North American manufacturing systems for distilled spirit giant Seagram Americas (a subsidiary of $9.7 billion The Seagram Co. Ltd., New York City), knew he wanted to move his applications off an ES9000 R32 mainframe from IBM Corp., in Armonk, N.Y. But with over 1.8 million lines of code in the core manufacturing, shipping, and back-office applications, Horlander also knew it would be prohibitively expensive to rewrite the applications for the UNIX platform, from Hewlett-Packard Co., in Palo Alto, Calif., which had been chosen as the corporate standard. So, he opted to “rehost” his COBOL applications to run on HP/UX. Horlander contracted with Unicon Conversion Technologies Inc., of Mission Viejo, Calif., which used its own automated tools to convert legacy COBOL to pure ACUCOBOL-GT from Acucorp.

The bonus: Horlander gets to keep the COBOL applications that his programmers know so well, but run them in a UNIX environment that is much more cost effective.

“The hardware and software costs are much higher on the mainframe,” says Horlander, at the Seagram plant in Lawrenceburg, Ind.

Horlander certainly isn’t the only one looking to maintain his legacy applications even while moving off the mainframe. Many companies are finding this to be a logical route, says Acucorp’s Coker.

“CIOs now realize their COBOL applications are very valuable. They’ve reinvested in them with Y2K [remediation projects] and now they want to find a low-cost way to modernize them,” says Coker.

Enhancing COBOL applications after conversion using a tool like ACUCOBOL is “one of the easiest ways to put a new face on an old application,” says Garden of Technology Business Research. Adding a GUI to an application for the first time has the added benefit of reducing the skill level required of the computer operator, he says. “The users don’t need any special training, unlike the old green-screen applications,” says Garden.

No-brainer ROI

Seagram and its diversified business units had been gradually moving away from the mainframe to HP/UX for a number of years. Where divisions all over the United States and in Canada once had their own individual mainframes, the corporate division decided in 1995 to consolidate mainframe operations onto a single machine. Horlander’s group began running all of its applications on a mainframe located at the company’s Universal Studios unit in Hollywood, Calif. Due to the high transaction volume running on that server, application performance sometimes suffered. And users in the Lawrenceburg, Ind.-based warehouse shipping operation are notoriously unforgiving of unavailable systems.

Why move from mainframes to distributed computing?

Faster reaction to changing market conditions and competition

Faster, easier access to information and data

Lower cost of business processes and IT development

“Speed to market” of business products and services

Year 2000 compliance

Inflexible, unstable existing systems and processes

To accommodate corporate acquisitions and restructuring

To accommodate business growth and expansion

Other

How many companies are in which phase of the transition?
Stage 0: Centralized computing running on legacy mainframes

Stage 1: The addition of PCs and stand-alone LANs running workgroup applications

Stage 2: Business apps on PCs or C/S, but dependent on business logic and/or data from legacy mainframes

Stage 3: Apps for one business unit or mission-critical process reengineered for distributed computing–no dependence on legacy app code

Stage 4: Apps for multiple business unit or mission-critical processes reengineered for distributed computing–no dependence on legacy app code

Stage 5: Complete reengineering of all key apps and processes to the distributed model

Source: GartnerGroup Inc., August 1998 survey of 30 small, medium, and large organizations

“If the system is slow or down, the user goes away. He may not come back again later,” says Horlander. If the user went away, the shipping data simply wouldn’t be entered into the system. Not a good way to track product. So, Horlander needed to improve user service levels, as well as reduce costs.

The first step in the mainframe migration was to port the IBM DL/1 data into a relational database management system. Horlander and his team chose Cincinnati-based Cincom Systems Inc.’s Supra Server database since it was able to run on IBM MVS and HP/UX (in addition to a variety of other OSs).

In 1997, Horlander presented to upper management a cost justification statement for the mainframe migration project. He used his budget of $530,000 for annual mainframe costs (including his unit’s share of mainframe hardware and software lease costs as well as personnel costs) as the baseline. The cost of the entire migration–including two additional copies of the Supra database, the HP/UX servers, Acucorp software, and conversion services from Unicon cost less than one year’s expenses on the mainframe.

“I used my last mainframe budget as a target against which to measure savings. We had a small payback in year 0,” says Horlander. Seagram turned off the mainframe in February of this year and has not looked back.

Seagram Americas spent many years customizing its applications to do very specific things for its business. It couldn’t find a shelf package that fit the needs catered for by these applications, says James Harding, marketing manager for Unicon. “We preserved Seagram Americas’ investment in these customized applications by converting them so they can run on open systems,” he says.

Payback beyond costs

Gerry Cullen also found contracting Unicon to convert his legacy COBOL applications to ACUCOBOL to be cost-effective. Director of special projects for Detroit Diesel-Allison B.C. Ltd., Cullen was worried about being able to make a business case for spending millions of dollars to put in a new enterprise computing platform like R/3 from SAP AG, in Walldorf, Germany. Detroit Diesel was running its mission-critical applications on a Wang VS10,000 minicomputer, which was not Y2K compliant, among other problems. But he just didn’t think he could sell upper management on the need to spend millions moving to an open platform.

Happily, he found out he only needed to spend about $400,000, at today’s exchange rates, to convert the company’s applications from Wang COBOL to ACUCOBOL running on two Data General AV3-650 UNIX machines. This number also included the cost of installing a high-speed Frame Relay network and the purchase of 90 thin client Wyse Winterms.

“We needed to make sure there was a good business reason for what we were doing,” says Cullen, in Surrey, British Columbia, Canada. Although the migration is only scheduled to be finished this month (June), Cullen has already been able to show payback surpassing costs. For example, it used to take four hours to run the month-end financial statements on the Wang minicomputer. On the UNIX box, that job runs in about eight minutes.

By far one of the biggest paybacks of keeping applications in COBOL even after the migration off legacy hardware is that you get to leverage your developers’ familiarity and comfort level.

“The screen [in ACUCOBOL] is identical to the old COBOL screen,” says Al Halligan, project leader of manufacturing systems support for Seagram. “There was zero retraining.”

For now, although both Seagram and Detroit Diesel have moved off their old hardware platforms, they are secure in knowing they can use, maintain, and even add to COBOL applications they’ve depended on for years. “We’re maintaining our [COBOL] applications, tweaking them, making enhancements,” says Cullen. “This has brought us from 1980’s technology to more current technology–and we didn’t have to break the bank doing it.”

New lease on life

Like most financial services companies, Central Insurance Co. runs its business on a mainframe. As far as anyone in IT can tell, the auto, home, and commercial insurer will never turn off the mainframe. The expense of migrating, combined with lower manageability, make moving to an environment like UNIX or NT undesirable.


Larry Streets, a senior systems analyst for the Internet group at Central Insurance Co., says there’s no real reason to get off the mainframe.

“There’s never been any question of moving off the mainframe. Everything we have is invested there,” says Larry Streets, a senior systems analyst for the Internet group at Central, a 120-year-old privately held company in Van Wert, Ohio. But that doesn’t mean the move to open computing and the Internet are totally lost on the company. In order to give its 650 independent agents speedier service, Central recently Web-ified a number of its applications and made them available to the agents on an extranet.

“Now, there’s no real reason to get off the mainframe,” says Streets. Web-enabling its legacy applications is a “big plus” for Central, he says.

With hundreds of vendors selling in this space, the Web-to-host market is hot, says Garden of Technology Business Research. Companies that stay on the mainframe and Web-enable components for business partners or select user groups have the advantage of lower cost of ownership than some client/server environments, he says. “The pendulum is swinging back toward strong centralized servers like the mainframe. Companies are using the mainframe for the jobs that it’s suited for and Web-enabling some of the customer-facing applications,” says Garden.

Companies that serve a constituency of independent agents and franchisees are jumping at the chance to connect with these external partners using an extranet. Diehard mainframe shops like Central and car rental giant Avis Europe in Bracknell, England, are enticed by the productivity gains and improved customer service of giving their independent agents and franchisees access to their applications via Web browser.

In many cases, these new Web applications represent the agent companies’ first foray into using computers of any kind. Many small insurance agencies and reservations booking offices must rely on manual methods such as telephone and fax to get the job done. The benefits of migrating to an easy-to-use Web application are clear.

Quicker turnaround

Lessons learned…

…about maintaining legacy COBOL code on a UNIX platform and Web-enabling mainframe COBOL applications

COBOL is COBOL. The programmer learning curve with an open systems COBOL language like ACUCOBOL is short, since the code is still COBOL and programmers need only learn some syntax to create a GUI.

UNIX has what it takes. UNIX has many of the same security and manageability characteristics of the mainframe, but with the benefit of openness and lower cost of computing, says Seagram’s Joe Horlander.

Steep learning curve. The Central Insurance team had to educate themselves on IIS, IE, Web security issues, and JavaScript–none of which they had ever touched before.

Start small. Central’s Larry Streets recommends picking a very simple application of no more than five to six screens as your first Web-enabled application.

Get the users involved. Go directly to the people who will be using the application or you’ll miss critical components of the business process, says Streets.

Don’t forget the help desk. When a company moves from a wholly mainframe-based environment to a mainframe plus extranet environment, its help desk will likely be flooded with calls post-deployment. Help desk personnel will need a lot of Web training.

Two years ago, when it came time to Web-enable the legacy applications, Streets’ first priority was to extend Central’s COBOL-based commercial quoting system to an extranet. Previously, an agent wanting to get an insurance quote for a commercial customer would have to fill out a long, paper-based application and send it through the U.S. mail to Central’s headquarters office, where clerks would re-key the information into the mainframe. It would take an average of five to seven business days before the agent would receive the quote back. Not exactly what you’d call crackerjack customer service.

So, Streets embarked on a project to Web-enable the quoting application using the Amazon product from Intelligent Environments. He chose Amazon over tools from Attachmate Corp., of Bellevue, Wash., because at the time it could connect to a variety of different types of legacy data, from VSAM files, to DB/2 data, to 3270 files. “Their product was superior in terms of the types of connections it could make to different data types,” says Streets. Although the commercial quoting application data was in 3270 files, he knew later he would wish to extend other legacy data sources to the Web.

Using a dynamic form on the extranet, the agent now gets the quote back in about five minutes, and there’s no need to re-key the data. Central has not cut head count as a result of Web-enabling its applications, but has absorbed data-entry people into other roles, says Streets.

The one difficulty was selling the application to the agents, most of whom either did not have a PC or did not have an Internet connection. It took a few months of marketing the Web application through brochures and other product literature for the agents to come around. Today, about 200 nationwide use the system and Streets expects that number to grow.

Bringing partners closer via the Web

Just as Central Insurance used the Web to link its agents, so too did Avis Europe. The company used the Salvo tool from Simware to Web-enable its car reservation system for the smaller independent companies all over the world that book its car rentals. These firms often could not afford the cost of a dial-up connection to Avis’ famous Wizard reservations and fleet management system.

“In many cases, the communications infrastructure for leased lines is not developed sufficiently. It’s still quite expensive for a company in a country like Kenya that may be doing a low volume of rentals,” says John Saunders, director of business systems for sales and marketing for Avis Europe. On the other hand, with a few exceptions, such as Saudi Arabia, even the underdeveloped countries generally have telephone lines that are adequate to connect to the Internet.

So, the company elected to make its Wizard system available on an extranet for its agents to use. Web-enabling the system was lower in cost and hassles than Saunders had expected. The company spent roughly $16,000 U.S., at today’s exchange rates, to develop the link.

Like Central, Avis Europe is sticking with its mainframe. “We had a legacy system that we had to keep. We’ve used this system for 24 years–we weren’t going to throw it out. Everything else had to fit in with that,” he says. Bringing its business partners closer to the mainframe system in a convenient, low-cost Web-access method was gravy. //

Contributing editor Lauren Gibbons Paul writes frequently about legacy systems. She can be reached at laurenpaul@mediaone.net.

Subscribe to Data Insider

Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

Similar articles

Get the Free Newsletter!

Subscribe to Data Insider for top news, trends & analysis

Latest Articles