Cobol programming in a Java world What are your options for making the Cobol conversion? By Robert E. Lee

April  1998

We all know that the mainframe isn't going to disappear. In the progressing client/server world, terminal emulation has gained popularity as a way to connect mainframe applications to client systems. But terminal emulation still isn't the ideal solution. Lately, the industry has turned to Cobol conversion tools. Robert E. Lee investigates various methods and products for converting Cobol programs to Java, C++, or Visual Basic applications. (1,800 words)

Mail this article to a friend

or the past 10 years, "legacy" in the networked computing revolution has included the idea that Cobol programming was a thing of the past and something to be discarded, just as mainframes were to be discarded. But that misperception has gone by the wayside -- mainframes are here to stay and Cobol programming has kept its niche in the lair of the mainframe. But what do you do with the mass of Cobol programmers who know little if anything about the client systems you are implementing, whether these clients be Unix workstations, Macintoshes, or Windows PCs? How do you transform those programming talents to meet this very different paradigm of programming?

The beginning of the transformation and perhaps its strongest mainstay are the terminal emulation technologies that emerged at the start of the PC era. Especially in the PC world, adding a terminal emulator to the box allowed billions of lines of mainframe code to be preserved as the PC was relegated to the lowly task of emulating a dumb terminal. That move pushed out the issues of transforming programmers for a number of years. Even now, in the late 1990s, state of the art terminal emulation programs are emerging to continue this very basic trend of linking the mainframe to the workstation. Instead of a dedicated terminal emulation program, the latest rage is a Java component that adds sophisticated screen scraping to the world of browser-based applications. OpenConnect Systems at Internet World Spring 98 last month showed off this technology to connect to mainframe solutions, including a robust 3270 terminal emulation, and extensive security support that features a patent-pending SNA session control over the Internet technology.

Why terminal emulation isn't the long-term answer
Over the last decade another spate of technologies arrived on the scene in the form of middleware solutions that began the successful linking of mainframe-based legacy applications to the new client world of workstations. These middleware solutions required massive new programming efforts to implement, presenting the first true challenge to existing programming staffs to begin developing new skills. Not only did new languages appear, notably C++, but applications needed to be migrated to new database technologies on Unix and PC platforms. The anticipated savings and benefits in early client/server migrations failed to appear as expected, and legions of traditional programmers appeared to be left in the dust.

So terminal emulation returned to favor, as it became very apparent that mainframes were here to stay due to cost and functionality issues. But again, terminal emulation didn't make the best use of the extensive client-side computing power that distributes processing to where it's needed.

Enter a new breed of technology, in the form of Cobol-to-current-generation-programming-language conversion tools. At the core, this technology promises to transform Cobol programmers into creators of Java, C++, and Visual Basic. Best of all, this doesn't mean training Cobol programmers in these new languages. Instead, it involves the transformation of the code they create into viable modules in the target language.

Cobol conversion is an enticing thought for any MIS manager who has a staff fully proficient in the Cobol language and the applications that were built on it. Through this approach, the people most familiar with the application can begin to break their programs down into client and server components. Then the client components can be transformed into GUI-based modules. And, assuming you're satisfied with converted code (which won't be as efficient as originally-written code), you'll have successfully turned your programmers and applications into a state of the art solution.

Solution possibilities
There are several ways to approach the problem of converting legacy applications from Cobol to a more current programming language. Your first choice is to rewrite applications from scratch, designed with all of the latest technologies and innovations, converting all of the data structures, and subsequently the data, with all of the business logic and other variables involved. Now, if your application is small, and you have sufficient staff and resources, this option is very workable. In some situations, even in large-scale projects, where the original application code has gotten out of hand over decades of maintenance, this might be the preferred option. But for many applications, this will be the most expensive and least successful route.

The second choice is the conversion of the existing applications from Cobol to Java, C++, or Visual Basic. In doing so, you begin to migrate the application to current-generation programming technologies. In this category, there are several choices: do the conversion yourself, participate in the conversion, or have the conversion done for you (with or without code optimization). As might be expected, a number of new companies have jumped into the game to help you with the process.

For example, Metamorphic provides a service that will allow you to convert Cobol code to Visual Basic, Java, or C++. Services are divided into the three options outlined above. Should you choose to do all the work yourself, it will cost a cool $250,000 for the converter software for use inside your company, but no resale of service is possible. If you wish a simple conversion, with no code optimization, 5 cents per line of code is the price, while the full-blown conversion service will be 25 cents per line of code.

A different and perhaps more effective approach was announced by Relativity Technologies in January: its RescueWare product line. The approach this time is to analyze the complete application environment and to begin an intelligent migration to a non-Cobol-centric solution. The overall application is dissected (see Figure 1) for screen maps, screen and process flow logic, business logic, and data definitions, all of which are used to generate code in Java, HTML, Visual Basic, and C++, plus database definitions for many SQL platforms and JDBC and ODBC interfaces, and CORBA and ActiveX/DCOM architectures. At $15,000 plus a per-line-of-code conversion charge, this is also an expensive solution.

Figure 1: Application dissection

At the lower end of the cost structure Synkronix Inc. has produced a specific Cobol-to-Java conversion engine that is being marketed through licensing agreements, not directly to end users. Fujitsu has incorporated the engine into its Cobol offering as NetCobol. This product takes Cobol source and generates Java bytecode to run as Java applets or applications. Synkronix is working to extend its core technology to include embedded SQL for Java JDBC driver access, Cobol file system support for indexed, relative, and sequential files, additional Cobol functionality to support event driven, multithreading, and TCP/IP extensions, and pointers. There is even support for dynamic HTML pages from Cobol programs. Fujitsu supplies this technology as an add-on to its Cobol product for an additional $750. While pricing is not yet available, another company, ACM Ltd. in the United Kingdom, is producing the CORECT solution for Cobol conversion. This product is a Cobol-to-Java or Delphi conversion tool that performs many of the same functions that the Synkronix solution does.

Where do you go from here?
How many countless billions of lines of Cobol code are out there today? Recent research by the Aberdeen Group found that "transformation tools" that can convert Cobol to languages like Java could help preserve 25 to 75 percent of existing legacy data today.

A stronger argument is not the preservation of data, but the actual preservation of the following: business rules, data rules, process flow, computing resources, and application integrity. Data can always be migrated to better forms, but it is often the preservation of those elements that defines the collection, and use and retirement of data is crucial.

With more mainframe-class computers being upgraded to include a Java virtual machine, very interesting application possibilities emerge. Since Java is a platform-independent technology, the successful migration of any code into Java signals the ability to run that application everywhere. If that migration includes support for the legacy file systems, the data itself can be left intact on a processor that is capable of handling it. Perhaps more importantly, the tried and true batch processing that Cobol and mainframes do so well can be left untouched while the legacy client interfaces are transformed to Java solutions.

The Synkronix approach opens the door to one more level of preservation, that of the Cobol programmer. By including extensions to Cobol to support legacy file systems, Java, and HTML technologies, a traditional Cobol programmer can continue to build core application logic in his or her native language while the transformation tool moves that code to the platform-independent Java bytecode files. Applications can be built in one language, yet deployed in multiple languages.

In order to decide what approach is best for you, it's necessary to understand the strengths of your programming organization, the pressures for converting applications (ie., year 2000 deadlines), and the platforms that must be utilized to deliver the applications. Because all of the conversions of code require that you understand your application and have a solid plan for its migration, the cost will be significant. Perhaps the most baseline questions will be:

• Do you have your application logic clearly defined and documented?
• Do you need coexistence or preservation of existing legacy systems?
• Do the existing applications perform as required?
• Do you only need a client interface change?
• Are there compelling new application capabilities that derive from the newer programming technologies?
• Can your staff handle the transformation process?

The questions are actually much more numerous, but starting with these you can begin to define the scope of your needs and the direction you must take. The good news is that these new tools look promising, as does the foundation from which they were built. It is very likely that by the early part of the next century, tools like these will be in every programming shop, assisting in the development of new applications in addition to the transformation of legacy applications.

Resources

• Metamorphic COBOL Converter http://www.metamorphic.com/html/cobol.html
• ACM Ltd. http://www.acm.co.uk/
• RescueWare http://www.relativity.com/products/rescueware
• Synkronix http://www.synkronix.com/
• Fujitsu http://www.adtools.com/
• OpenConnect http://www.openconnect.com/

About the author
Robert E. Lee is a technology consultant, speaker, columnist, and author who has been in the computer industry for 20 years. He specializes in networking, Internet strategies, systems analysis, and design activities, and has participated in the Windows NT and Internet Information Server betas since their respective beginnings. His most recent feature for SunWorld was "Untangling network wiring."

You can learn more about Lee's The ISDN Consultant: A Stress-Free Guide to High-Speed Communications and Serving the Net: Using the Power of Microsoft Internet Information Server at Amazon.com Books. Reach Robert at rob.lee@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-04-1998/swol-04-cobolconversion.html
Last modified: