The steps in the PRIMA Migration process are as follows:

This is partly so that COBOL reporting requirements can be met by tools like Crystal Reports and Stimulsoft. These tools can reduce dependency on COBOL by a significant percentage. BUT, most importantly, doing this allows Old and New Technology to share the data resource, and this takes much of the pressure out of Migration.

The Toolset can generate Classes that separate the business logic in the legacy code from the access to data. These components carry out required maintenance and manipulation of the RDB tables, on behalf of the application programs, ensuring that the applications "see" exactly the same data structures they saw when they were accessing the indexed datasets. In this way, the applications no longer contain hard coded data access. Instead, they invoke the DAL objects to provide what they need. This is not a required action, but the Toolset makes it so easy and the benefits are so large, it is normally done by most clients.

The alternative to this separation is to use hard-coded embedded SQL in your migrated code and that can be a nightmare; the Toolset automatically generates the DAL Layer and it automatically Transforms the legacy code to become "object aware" so it can use these objects. What would manually take months or years is done in minutes with a few mouse clicks.

(For an explanation of the pros and cons of using DAL, as opposed to ESQL, click here.)

The Toolset's TRANSFORMATION tool can automatically refactor all existing COBOL indexed file access into invokes of DAL objects against the new database.

But there may be routines and sub-programs in your legacy which might be useful to have available as an encapsulated service or Class, for use by the new development. This refactoring is not always necessary and it can certainly be done as part of future development, rather than at conversion time, but the Toolset provides templates and models that can greatly assist and expedite the process.

In the same way that separation was created between the applications and the Data Access Layer, separation should be injected between the applications and the User Interface. Visual Studio has a very rich User Interface Design Tool which can be used to build modern graphic interfaces to your legacy.

If your site uses PowerCOBOL to provide a Graphic Interface to COBOL, we have tools that can move your PowerCOBOL sheets and scriptlets into .Net and, once there, they can use the new DAL objects just like everything else. Click here for more information.

The applications see an interface that provides properties and methods of objects to interact with the User, in very much the same way that they see properties and methods of DAL objects to interact with the Database. Note that this new Graphic User Interface is available for both the desktop and the Net.

The end point of the above steps is a layered, component based system that runs in the .NET or Mono frameworks.

COBOL code that was previously monolithic is now "object aware" and can use objects just like modern code. As such, the COBOL application objects can interact with, and provide services to, other application objects, written in other languages. The "options" are immediately wide open and development is no longer tied to only using COBOL.

If you are PLANNING TO MOVE ON FROM COBOL, you DO NOT NEED TO BUY A .NET COBOL COMPILER, if you use the PRIMA MIGRATION TOOLSET, and your current compiler supports OO COBOL!

(Fujitsu and Micro Focus both have native code compilers (Fujitsu NetCOBOL for Windows and Micro Focus NetExpress) that DO support OO COBOL and there are others also. Check the COBOL compiler you currently use and see if it supports OO constructs. (REPOSITORY, METHOD, etc.))

PRIMA Computing has been involved in numerous successful migrations with clients around the World and is continuing this work. We have moved this experience into our tools and can be considered a "Centre of Competence" for Migrating COBOL. Projects which were assessed as man/years of effort have been done in a month or less using the Migration Toolset.

...more