DataKom is an integrated end-to-end solution to migrate from CA-DATACOM workloads to Unix or Windows platform, including 3GL code , 4GL code and data. The migration process is 100% automated, which eliminates the risks induced by manual interventions.


The value proposition of DataKom can be summarized as:


Data migration, and more generally, the entire migration project revolves around a comprehensive data dictionary. It can be initialized with the content of the original CA-DATACOM data dictionary, or can be populated by other means if needed. In any case, it is crucial for this data dictionary to be accurate and detailed enough as it controls the entire migration process.

It includes:

  • The structure of the tables, structured in fields and sub-structures

  • Indexing

  • CA-DATACOM areas and elements

  • Data cleansing information

  • Mapping information, controlling how CA-DATACOM data map to relational columns

The DataKom toolset includes a comprehensive GUI tool to manage the data dictionary, add and modify tables, fields, indexes, etc.


Experience seems to indicate that code migration is the riskiest component of a non-trivial migration project. This is where the original behavior must be maintained while the source code is transformed. This is where the true promise of the migration project must be fulfilled, namely to have a system that behaves exactly the same at the end of the process


CA-IDEAL is the 4GL most commonly associated with CA-DATACOM, and data access statements as supported by CA-IDEAL are of rather high level of abstraction, and can be converted to semantically equivalent embedded SQL statements.
In the context of Datakom’s CA-IDEAL migrations, the source code is converted to strictly equivalent COBOL code. Why COBOL? It simply comes from the fact that IDEAL is at heart a mainframe language, with mainframe data types and mainframe behaviors attached to these data types; and the only commonly available language that provides support for these data types today is COBOL. Aiming at COBOL also allows for a more homogeneous environment to maintain at the end of the migration project, if the system to migrate is not made of IDEAL code only, but also contains some COBOL code to start with.
On the other hand, CA-DATACOM can also be called from within common third generation languages, PL/I and mostly COBOL, with a far more primitive mechanism. Programs then call CA-DATACOM by populating a data structure describing the operation to perform, and passing this data structure to a program named ‘DBNTRY’.

DBNTRY replacement

DataKom includes a tool that can generate a ‘DBNTRY’ replacement module that will behave exactly like the original except for the fact that ultimately, DB2, SQLServer or Oracle will be used for persistence.This allows application programs written in COBOL and PL/I to be ported as is. They don’t have to be modified; they don’t even have to know that what they are calling is not the true original
CA-DATACOM but something that just behaves exactly like it.
This generated component is database-specific, in the sense that it is made of a number of predefined statically compiled SQL statements, in order to get the best performance possible, significantly better than if they were generated dynamically. When this option is used, the data dictionary must be maintained using the GUI tool that comes with DataKom. Evolutions to the data model can be brought to production by regenerating the ‘DBNTRY’ replacement program.


Go to Top