InformationWeek
Defining The Business Value Of Technology
| August 18, 1997 |
A Logical Migration Path
Corporate developers turn to Visual Basic to extend the life of Cobol applications
By
Rich Levin
Sound familiar? These are the same promises vendors make about modern Internet architectures. Conventional wisdom dictates thin Web clients as the logical migration path for legacy Cobol applications and character-mode terminal interfaces.
Three
similarities between terminal and Web-based systems reinforce this view. Both platforms are stateless, meaning users complete data-entry screens, then submit the information to a back-end system for processing. Both use thin clients wired to centrally administered systems. And like Cobol, Web technologies are largely portable across platforms.
But that's where the similarities end and reality sets in. Though the tools, infrastructures, and usage of the two systems appear similar on the surface, simply fronting, surrounding, or augmenting legacy systems with pure Web technology may sacrifice distinct competitive advantages available through more conventional, fat-client technologies.
In addition, while Web development tools, middleware, and security technologies are in their infancy, desktop and middle-tier server development environments are mature, robust, and able to deliver distributed computing capabilities.
"If I'm going to put interactive interfaces in front of my customers and employees,
I'm going to do that on a platform, and with development tools, that most developers are familiar with, and the industry supports," says Lance Williams, executive VP with Merkle Computer Systems Inc., a database marketing service bureau in Lanham, Md. "I'm not going to fall back on mainframe stuff, and run CICS transactions across a T1 line through a Web browser."
And with good reason. Simply providing customers and employees with thin-client access to legacy systems often doesn't provide competitive advantages. Merkle, which rents mailing lists to national direct marketers, had to reduce the time needed to process queries and final orders, as well as provide customers and employees with universal remote access.
A browser front end would have given users the direct access they desired, but wouldn't have improved the performance of the batch-mode, Cobol CICS applications chugging away on the company's IBM mainframes. "Our systems were taking two to three days to turn orders around," Williams says. "It
was causing problems because customers wanted orders processed in a day, and there was at least one competitor who was promising that."
If not a browser-based front end, then what? Surprisingly, for a growing number of seasoned Cobol shops, Microsoft's Visual Basic has become the migration tool of choice. The Basic language shares many of the syntactical and structural features of Cobol, making it easy for Cobol programmers to get up to speed. "Basic is more English-like," says Yisroel Bongart, assistant VP with Prudential Securities Inc., in New York. "It's not as English-like as Cobol, but it's close, and it's a lot more practical to teach than C++ or Java." Prudential has replaced all of its 18,000 mainframe terminals in 250 locations worldwide with PCs, and is migrating application solutions to Visual Basic.
Prudential provides an intensive five-day course to its Cobol programmers, many of whom had never developed a PC application. To insure an effective education, Bongart suggests focusing on the
similarities between the two languages, and mapping differences in syntax as closely as possible.
"The calling of a DLL (dynamic link library) was mapped to the calling of a `load module,' and we equate parameters to setting things up in the `linkage' section of Cobol," Bongart says. "We draw the two languages together as closely as possible."
Next Step, Middleware
"We have a boatload of legacy telco billing systems written in Cobol," says Dave Mendlen, director of development for Ameritech Inc. a regional Bell operating company in Chicago. "We considered and then rejected a migration strategy that called for the entire billing system to be ported to VB. We ha
ve code that works, and is running our business. We can't risk changing those things."
But some of Ameritech's Cobol applications were written in the early '70s and can't be considered modern. Migrating pieces of the legacy applications to a more modern platform is the only option.
To leverage the code, Mendlen's team is experimenting with a beta Cobol-to-VB middleware translation layer from Microsoft, code-named Cedar. The software sits on top of Microsoft Transaction Service under Windows NT and provides VB developers with unobstructed access to Cobol APIs. No changes are required to underlying Cobol code, provided the original source was designed with a decoupled user interface.
"You point it at a Cobol function call," Mendlen says. "It peruses the function, identifies the input and output parameters-names and data types-and does the conversion for you." For example, Cobol "packed decimal" data types are automatically converted to VB-friendly formats.
If all goes well with the pilot, Amer
itech's VB developers will be able to treat the legacy Cobol functions as one huge Visual Basic function library, without having to learn or understand the Cobol language. Cobol functions are returned to VB as standard COM (ActiveX) objects.
Other Visual Basic add-ons can also enhance the migration process, and provide business dividends. Crystal Linen Inc., a large industrial uniform supplier in Yakima, Wash., is using the PB/DLL compiler, from PowerBasic in Carmel, Calif., to improve the run-time performance of migrated applications, and increase end-user productivity.
The company migrated most of its legacy systems to graphical front ends, using Visual Basic to design the forms and data-entry screens. But large portions of the application logic, along with legacy systems communications, are being handled by native-code DLLs developed in PB/DLL.
"PB is wonderful as middleware," says Jim Barber, data processing director for Crystal Linen. "It makes it easier to communicate with legacy systems. VB
has some problems in that area, such as converting strings to OLE, which imposes a performance load, and 4-byte alignment structures that you can't use with parts of the Win32 API, and certain legacy interfaces."
Unlike Visual Basic, PB/DLL components are multithreaded and reentrant (they can call themselves). This allows migrated applications to spawn multiple processes while letting users continue working.
"We have gigabytes of data to thrash," Barber says. "We used PB/DLL to propagate processes that run on the server. Communication with those processes are maintained by individual threads. So our users aren't held up for hours by reports' being generated."
Scalability Concerns
"We found Windows tools, such as th
e Source Safe version control system, could not be used in enterprise systems," says Prudential's Bongart. "They couldn't be used as a central repository of all source code and load modules because they didn't scale. They were geared toward the small-workgroup development, running on proprietary databases, and couldn't provide the universal access we require."
Fortunately, VB's crown jewel-the Basic language itself-can help in this area. When migration is a requirement and failure is not an option, the simplicity of the Basic language, with its Cobol similarities and VB's rapid application development framework, can be a winning combination in the hands of the right development team.
"We built our own tools using VB," Bongart says. "Then we went further and built common developer's tools, to make porting and new development even faster." Home-grown tools, such as application wizards, class builders, mainframe connectivity and security components, and templates for component references, declarations,
and constants now are standard fare in Prudential's VB shop.
No matter how it's sliced, migrating legacy programs to modern distributed systems is rarely, if ever, easy. For those IT shops with an aging workhorse in the back room, and little time to invest in training, playing with beta middleware, or creating their own change management tools, the best course may be to outsource.
Such was the case at database marketing firm Merkle, which turned to a local reseller to migrate application functionality, rather than create its own solutions. "Merkle was in panic mode when we first met," says John Repko, director of development at Micro Endeavors Inc., an Upper Darby, Pa., value-added reseller that offers legacy-to-Windows migration services.
"Merkle had a three-month deadline to get a file-server version of this in place," Repko says. "We figured the best tool for rapid systems database development would be Visual FoxPro. No other tools were used-no ActiveX, no DCOM. Just a plain client-server archi
tecture. We turned that around in three months, and that became the functional spec for the second version," he says.
The second version, also completed in three months, added a componentized VB front end, a middle tier running the FoxPro database, and a back-end SQL Server hosted by Windows NT. VB was chosen as the front end because a future spec calls for Internet access, and the VB client can be recompiled to a downloadable browser plug-in.
IT developers say their investment in Cobol-to-VB migration is paying off. "The difference is night and day," says Merkle's Williams. "Productivity doubled, and costs fell by 50%. This doesn't happen many times in your management career. The thing just works 100 times better than what we used to have, took six months to build, and in the end, it's cheaper."
Tips For Migrating Legacy Code To Visual Basic
|
or mainframe shops in the age of the Internet, there's conventional wisdom and there's reality. Consider migration strategies. Not long ago, leading industry pundits encouraged mainframe shops to migrate systems to client-server architectures, which promised to reduce costs, increase flexibility, and provide users and developers with powerful, cost-effective productivity solutions.
Featured Microsite
