COBOL Application Migration Options

COBOL applications have been successfully deployed for many years. These "legacy" applications provide stable business processing capabilities. In spite of this successful history, many COBOL users are looking to move all or part of their application from COBOL to some other technology.

Migration Reasons

As COBOL applications have worked successfully for many years, the applications will outlive the original designed platform. In some cases, the application still works very well, but the hardware is difficult to find, or is obsolete. In other cases, the application COBOL compiler will no longer be upgraded to new platforms, or is not well supported, etc. Continued use of the COBOL application becomes dependant on migration to a newer environment.

New technology drives many requests for improvements to existing, stable applications. Interoperability is critical as businesses depend on multiple applications (accounting, shipping, sales processing, etc.) for a complete solution. End-users demand the latest UI (User Interface) look and feel, as well as support for web access and transactions across a wide variety of platforms. As COBOL is not a leading edge provider of these technologies, companies are pressing for applications to be provided in languages that do completely support the new technologies without a large wait in time.

Application Migration Continuum

Each application has different migration requirements. This includes the type of migration needed, the steps to be taken, the time requirements for implementation, demands for a partial or phased approach (some critical elements immediately, followed by other features in a later release). This becomes a continuum, as shown below.

Concept of Continuum

A continuum is not an orderly sequence of releases that all applications must follow. This continuum shows various levels of migration based on business needs. All applications need to go to some point within the continuum, yet not all applications need to go to the same point. Some applications need a phased approach, where they will go to one point on the continuum for immediate release, followed by moving to another point at a future target date. While certain applications need to move very quickly away from COBOL, other applications may have a goal of converting the dynamic portions of the application, while leaving some of the logic in COBOL for the foreseeable future.

This particular continuum assumes that the current application is written in COBOL, using COBOL syntax for screens (with or without screen sections), provides printed output on line printers, and uses COBOL file structures (flat files and keyed files). Choices within the continuum vary from simply providing an improved User Interface all the way to a complete rewrite of the application. The following areas explain the various concepts, including advantages and disadvantages of this movement, as well as why this change is included in a particular point on the continuum.

Language

COBOL
COBOL is the building block of the core application logic. It has been used successfully for many years. The primary disadvantage of continuing to use COBOL for the core logic is the inability to find people with the skills or willingness to maintain COBOL code.

COBOL/Other
At this point, the application is starting to move from COBOL. Certain stable functions remain in COBOL, while new and upgraded functions are written in another language. This blend of languages utilizes the power of other syntax, while not forcing the rewrite of those portions that do not change over time. In order to use the advantages of other languages, there must be support for graphical interfaces and for database access. For these reasons, it does not make sense to move from COBOL to a split language development until the Screen Interface and File System are being (or have been) migrated away from COBOL dependant code.

Other
This signifies that all of the application is written without the use of any COBOL syntax. It may be critical to do this very quickly for some applications (especially where there are concerns about high production costs for some COBOLs). For others, the need for functional enhancements will limit the time available to rewrite stable code that has no outstanding enhancement requests.

Screen Interface

COBOL Text GUI
COBOL Text GUI is a step beyond traditional 24*80 screens, where the mouse can be used to depress buttons, view pull down menus, etc. (This does not include graphical objects). The advantage of this interface is that it is cross platform, as many UNIX platforms have difficulty with more advanced user interfaces. A second advantage is that conversion from text screens to this point is very easy to accomplish. In some cases, the compiler helps you accomplish this without any code changes. The disadvantage is that this style of user interface has been viewed as "old" since the early 1990s; users will not be happy if they are promised a "COMPLETE GUI", and see this format.

The reason for including this is that in some cases, applications have previously been upgraded to GUI, and are currently in a Text GUI mode. This is listed first, because it is a first step. As the work for this step is rarely leveraged (reducing work for some other migration point on the continuum), it is not a viable interim choice for most applications.

Windows Emulation GUI/Visual Basic
This implies a GUI that matches well with any Visual Basic application. Typically this user interface will include various OCX or Activex controls that go beyond capabilities found within COBOL syntax. (Note that in some cases, the COBOL vendor provides these capabilities to the developer.) The advantage is that this GUI looks exactly like anything from Microsoft, and it allows inclusion of many pre-built interfaces for entering dates, addresses, etc. The disadvantage is that Visual Basic is very platform specific and not the current standard. The web (HTML, Java, etc.) has a different look and feel. The web provides interfaces to all kinds of platforms, including Microsoft and various flavors of Unix.

This environment is placed here because it is a major improvement over Text GUI, yet is not well designed to handle web server processing, especially where there are requirements for multiple platform support. In addition, complete support for many Visual Basic Controls (OCX, VBX, etc.) need support not provided by COBOL syntax (such as access to an ANSI SQL database through ODBC). Without that support in the application, there will be limits on the Visual Basic Controls that can be used.

Lastly, as this interface is typically very different than web processing, much of the work done to implement this GUI will have to be completely redone when moving to a web centric application.

Web Emulation/HTML
Simple HTML screens are setup in a manner similar to traditional COBOL screen sections (enter a screen of data, allowing the user to move between fields using either mouse or tab, etc.). When COBOL vendors support some kind of emulation of HTML format, this can quickly transform the user interface to match current and future expectation, without making many changes to underlying COBOL processes. This can quickly upgrade an application, without retooling.

The environment is placed here because it is closer to the final goal (an application that works on the web, supports current standards, and is free from COBOL limitations). It is not placed earlier for two reasons: First, initial conversion of COBOL programs had a very narrow focus towards Microsoft Windows, and second, implementation of HTML in addition to simple emulation of the COBOL expect support for database access, as well as a more advanced system model.

New Technology (HTML, Java, etc.)
Many websites have evolved far beyond simple HTML format. They include graphical information, diagrams, pictures, etc., as needed to increase the understanding of the running application. As an application evolves into this medium, the user interface is controlled by HTML, and enhanced with technology like Java. This is the current standard for web applications; moving to this standard will integrate existing code with the latest applications that are developed. However, much of this interface will be developed and simply converted or emulated by a COBOL vendor. This cost is fairly high, but the value is very high, if this application will continue to provide value for the next several years.

The environment is placed at this point in the continuum as it is much more complicated than a simple Web emulation. Also, Java and HTML interfaces typically require the ability to converse directly to a database through ANSI interfaces (SQL, or XML), and the technology is so advanced that printed reports will also need to reflect a complete graphical capability, whether produced in house, or available directly through the web.

Reports

Plain Text
Textual reports have existed since the first COBOL programs. They have evolved from fanfold "green bar" paper to having information printed on pre-formatted forms. While graphical pictures may exist on the form (company logo, etc.,) the output of the COBOL process is plain text. This is used where environments have not evolved to the point that a lack of graphical textual output is noted.

Graphical Text
COBOL deals with textual data. As user interfaces evolve to be more graphical, there is a need to match that through the use of graphical text (differing font types, styles, etc.). This simple advancement in style can be an effective solution, until the time where applications store graphical information that is needed within the reports. The limitation of this interface is that graphical images that can be seen within the application cannot be added at printing time to the generated report.

This environment is placed here because the focus of development is on the user interface, and this enhancement to printed output will satisfy users who are focusing their efforts in a review of the graphical user interface. COBOL application developers who are looking for a graphical textual reports should look at tools like Totem, which provide COBOL syntax reports that span textual, graphical text, and graphical needs, so that development done for a conversion in one step will not have to be replicated on another platform for the next step.

Graphical Report
This implies the ability to create complete forms using laser writers, and not dedicated printers. It also implies the ability to include graphical images that match the screens from which the report was generated. The advantage of this interface is a seamless flow from user screens to the generated report. The problem with this solution is that it requires extra design and development work over text reports, unless a Report generation tool like Totem is used.

File System

COBOL API to Database
This implies that COBOL syntax is still used to access data, but that data is stored within a robust database. As the migration continuum included technologies other than COBOL, the ability to store and access data in a database becomes critical. In addition, the database must support the standard access that is required by the new technologies (such as SQL, ODBC, JDBC, XML, etc.). The potential disadvantage of database is when a quick solution, such as DBMaker DCI, is not available that both supports COBOL syntax AND supports current COBOL access speed.

This environment is placed here because it is a requirement for migration to any new non-COBOL technology. Also, when the correct strategy is chosen, migration from COBOL files to a COBOL API can be done very quickly.

COBOL API and ANSI Database
This implies that current COBOL applications can access the data through the COBOL API. In addition, other applications (or COBOL programs) can access the data directly from the database. This means that new technologies are not limited by COBOL file constructs. The disadvantage is that some data may need to be re-arranged in a format that is better accessed by the new technology.

This environment is placed here so that new technologies employed for user interfaces have flexibility in accessing data. Each time that data access is accomplished through the ANSI interface, and not through the COBOL API, that function can be freed from COBOL syntax. The requirement for this particular environment will depend on the kinds of extensions (controls, interfaces, etc) that are needed within the user interface. In some cases, if the user interface is not greatly enhanced, this environment may be replaced with the COBOL API to database.

ANSI Database
This implies a database that no longer is accessed by the COBOL application through COBOL file syntax. All database interactions are performed through SQL, ODBC, etc. The advantage of this choice is that the database design can more closely follow normalization rules. When a database has been chosen that does not access the database kernel directly, this can restore lost transaction speeds. (Note that this is not an issue for DBMaker, which has a direct access from COBOL to the database kernel.)

This environment is placed here to reflect the time when COBOL will no longer be used.

Conclusions

There are many aspects to consider when moving from COBOL to a different environment. Development managers need to carefully look at the overall goals for the application, and come up with a model for migration that makes the most sense.

They need to look at what should be done first, that will give the greatest flexibility and development enhancements during subsequent development. Some conversion activities (like going to Text GUI) only work within a small segment of the continuum, and the work will be replicated at a future point. Other conversion activities, (like moving to a COBOL database API) will reduce the effort of subsequent development AND involve work that will not need to be repeated.

Managers and developers also need to review the long term plans, and identify which of the interim parts of the continuum can make sense as a partial release, so that the application can continue to be enhanced, even as it is converted into the new environment.