When transforming legacy programs into fully equivalent programs in modern technology that use a relational database, special attention is required to implement the mapping of the data access statements to read, update, delete and insert data in the various legacy data stores.
These data stores - such as IDMS, UDS, IMS, ADABAS, and VSAM, are not accessed through SQL syntax like you would use for an RDBMS. Instead, each data store provides the developer with dedicated syntax (typically called DML statements where DML stands for Data Manipulation Language) to access the data in all necessary ways.
When we started working on the first generation of the CodeTurn transformation tools, targeting various flavors of COBOL (both on and off mainframe), our initial idea was to replace each DML statement directly with its SQL equivalent. The target of the transformation is a relational database after all. While the reasoning behind this idea is valid, the actual practicality of it did not hold. Let’s look at three specific issues:
All the above imply that a lot of additional support code needs to be generated to ensure functional correctness, hence decreasing the maintainability of the transformed application. Maintainability of the transformed application is one of the key evaluation factors of an automated transformation however and this meant that this design was not implemented. Instead, it was replaced by an alternative which we internally refer to as “IO Modules” but which is more widely known as the “Table Access Gateway” pattern.
With the “IO Modules design”, each relational table is accessed via a API (i.e. calling interface) that is implemented in a separately generated piece of code: the “IO Module”. When targeting COBOL, each IO module:
Since its inception, the IO Module design has been successfully implemented in many different projects.
When the time came to work on a new CodeTurn generation that supports C# and Java as output languages, the original design was revised by the Anubex architects, leading to a significant update to better match the characteristics and advantages of these languages – while still adhering to goals of functional correctness, good performance and maintainability of the transformed business programs.
When CodeTurn generates Java and C#, each generated IO Module only contains the structural information of the target relational database (which columns, column types, relations, …). The bulk of the actual data access (i.e. the SQL statements executed at runtime) is provided by a single code library. This design further decreases the amount of code to be maintained by the development team, while still retaining the benefits mentioned above. Additionally, more advanced and more dynamic performance optimizations are now possible as well, mainly thanks to the virtues of the Java and .NET platforms.
Some examples of these new performance tuning options include:
This revised IO Module design has been successfully implemented in various projects.
Get an instant copy of this Fact Sheet.