Migrating legacy COBOL to the .NET framework (part 2)

Arctic tern

The job of converting all your existing processing to access the new database is fully automated, and the Toolset can generate a modern set of objects that provide a proper Data Access Layer (DAL), separating your business logic from the data access. This generated Data Access Layer can be used by BOTH your OLD and NEW technology, and means that present and future systems share the SAME data resource. The Data Access Layer is generated in OO COBOL using embedded SQL (ESQL) OR C# using LINQ, exactly as if your own programmers had written it; you have the source and there is NO MIDDLEWARE!

Separation Layer

This separation has huge benefits in terms of minimizing the impact of tuning the data repository and "insuring" your application code against changes in the data access mechanism.

Your application code is no longer concerned with the details of manipulating data. Instead, it "sees" an interface that provides whatever it needs. (The interface contains the same COBOL record layout that the application has always used, but it is now sourced from the new RDB instead of the indexed files. This process is completely transparent to the application code.)

(For information about the use of DAL and the advantages it provides, please click here.)

Furthermore, all of the modern languages can use the same layer so your COBOL can be mixed with other languages and you now have many more options for future development than if you remain tied to COBOL alone.

The diagram depicts the PRIMA approach to moving existing COBOL onto the .NET framework.