PHOENIX

A path in migration!

Legacy COBOL migration to Microsoft Visual Basic .Net (VB.Net)

I was browsing the Internet years ago and came across a paper "The Realities of Language Conversions" by A.A. Terekhov^* and C. Verhoef explaining the intricacies of migrating applications from high level languages such as COBOL and PL/1 to Java or other open languages. For the most part this document points to straight conversion concepts. In most applications there is not a need to convert all of the code from one language to another.

Primarily, there are 4 areas of conversion to be concerned with. Each area has its own specific problems with conversion or "migration". These are Screens, Data, Screen-Data binding, and finally direct conversion from legacy to windows. Complete conversion of structured code from a legacy system to a windows systems was not a requirement of ours so this will not be discussed and for the most part is unnecessary for most business requirements. The amount of time to parse code from one language to another would be similar to de-compiling and then reformatting to the new language. This concept would take years to develop and would not be necessary for the final product. As a simple example, consider the following:

Cobol has a function that is used to "START" reading a file based on either key fields or to start reading from the beginning. The START function returns an event to signify whether a valid record was read or not. It does not actually retrieve the record if one was found, but signifies, based on the event, whether a  valid record exists. If a valid record was found, the READ NEXT function is used to retrieve the record and is repeated until the EOF (End Of File) event is set which has to be checked for each read. In addition the number of records found is not available unless you read each record with a counter and then you have to close the record and restart your START statement. The amount of code to migrate this code from COBOL to C or VB is unnecessary and useless. For example, Microsoft's ADO (Active Data Objects) allows a programmer to use the power of a database with the structure of ADO. In Visual Basic, we simply open the database with a SELECT statement and then check the record count.

adors.Open "select * from table where sp_name='" & SP_name & "'", db, adOpenDynamic, adLockOptimistic, adCmdText
If adors.RecordCount > 0 Then
    Do Until adors.EOF
        debug.print adors.fields("fieldname")
        adors.MoveNext
    Loop
Else
    msgbox "No data found"
End If
 

If the record count is > 0, we have data, and if not, then there was no data retrieved. Converting all the code from COBOL to a language such as Visual Basic or even Java would be pointless, so building a converter to migrate all COBOL code to Visual Basic, C or Java would have to be highly specific. You would not want all the code converted "As Is".

Another consideration is whether to migrate with screens and data "as-is" or enhance the application as you migrate. Our feeling on this subject is that if the environment is relatively simple with respect to the number of applications, screens and tables, go ahead and enhance as you migrate. If your environment has hundreds of applications, screens and many transactions which require updating records in several tables for each transaction, then migrate first, test, then enhance. Otherwise you will be complicating the migration process and your testing phase will become enormous. Convert the code that is working to duplicate what is on your legacy system, get it operational then enhance it.

Moving On..
 

Screen Conversion

First, what you see on the screen when you run the legacy application needs to be migrated  to a new display format or screen. For example,. the Cobol Accept-Display statements with screen formatting, or the FMS/DECforms screens of the VAX/ALPHA era were specific to the environments they were developed in. it was not possible to move these various and sometimes cumbersome screens to Java or HTML, or even .NET ASPX forms. Many software systems have numerous screens such as  PRAXA, ASK MAN-MAN, MCBA, MAPICS, and BPICS. The first task is to seamlessly migrate them "as-is" to the new format and platform. One of the utilities we developed at ABCOMM was to actually parse the COBOL screen formats and migrate them initially to Microsoft Visual Basic .FRM files. When .NET began to evolve, we identified a more suitable platform which was the dynamic ASPX format. .NET gave us the ability to have screens with similar structure as that of the 80X24 line text screen of the legacy systems with the addition of controls, events and everything else a developer or user could possible need.  After extensive testing we were able to convert 1000+ screens from the Cobol environment to the ASPX.NET platform in less then 4 minutes. Much to our surprise, this reduced conversion time for the screens from 2 man years to 8 days for the coding and testing and 4 minutes to actually convert them all.  The following images are of our convert. This application parses the program to determine which screen files and tables are opened by the application. The user simply select the required screen and then select "Buildform".  This create a new window with all the labels and textboxes with the same geometry as the Cobol screen. The user now has the ability to select table field names and drag-drop them to the required textboxes know as databinding. The code will automatically generate a link for the table, fieldname and textbox for each drag-drop sequence. This procedure requires 1-2 minutes/screen. Upon completion, the user simply select FormDev to ASPX.NET and the new ASPX form is created.

Initial Selection Screen

Viewing the Cobol Screen Layout


Viewing the Converted VB Screen


The Converted ASPX screen

The final conversion  and the one which is vital to us was the binding of data fields within our SQL tables to our program and converted screens. We designed an application which allow us to bind the ASPX fields to the SQL table field name by simply dragging and dropping the field name to the textbox. The environment parses the COBOL program to determine which data files were used. Using these names, we used the Schema of the SQL database to present the tables which were used in each specific program and allow a technician to manually bind fields to controls on the form. Upon completion, we simply generate the ASPX form with the appropriate controls bound to SQL tables and fields. A final highlight was to embed the stored procedure name in a routine in the ASPX program and then link the required stored procedure fields directly to the form and validate them before executing the stored procedures.

Binding table names to textbox objects.

Final Task

The only task left is building the functionality for each application, which is the most time consuming. The requires reading each COBOL program and duplicating the functions or calculation in each routine to the ASPX program. Most legacy systems have a large number of queries and reports which do not update data or perform extensive calculations. These ones can usually be converted in less than 30 minutes and many in less than 10 minutes. The transaction applications are the most difficult to convert since they my update multiple files (tables) and perform extensive calculations. Testing and debugging these applications can take days and at times weeks to validate all the functionality. In order to reduce the amount of coding required to convert large numbers of programs which may require the same data to be accessed or updated, use stored procedures as much as possible. This also enables routines to be maintained at a single source instead of in each module or application. In the event of migration to other databases, this practice will reduce further code changes.

Conversion of legacy applications to open windows applications can be accomplished easily. The first step is the plan for migration and then the team to execute the plan. Use the best tools available and the migration will be effective and fairly painless. The overwhelming benefit is that you own the applications, the data and your environment.

For more information on tools and concepts for Legacy code migration, please contact us at Applied Business Communications, Inc..

Richard Ladendecker II
President
Applied Business Communications, Inc.

Sales@AppBusCom.com