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.
INTRODUCTION
The value proposition of DataKom can be summarized as:
DATA MIGRATION
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.
CODE MIGRATION
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
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’.
To the non-specialist, translating a piece of software from IDEAL to COBOL (or to any other language for that matter) is similar to compilation. It is an atomic process that converts a system written in IDEAL into a (hopefully) equivalent system in COBOL:
While possible in theory, such a monolithic approach (where the translation is performed by a single, probably complex process as opposed to a sequence of smaller, more manageable components) is vastly sub-optimal, because it requires the translation process to deal with all the facilities provided by CA-IDEAL, in all possible combinations.
The translation is divided in 3 steps but totally transparent to the end-user, who only sees the final result of this scaffolding of intermediate transformations.
When dealing with a non-trivial translation, where the source language does not map trivially to the target language, it is preferable to start by applying a number of simplifications to the source system to transform it to a canonical form, thereby reducing the number of constructs and cases to be taken care of by the translation process.
The process which ultimately translates a system from IDEAL to COBOL. It must be complete, in the sense of addressing all (or at the very least, a canonical subset thereof) the supported features of IDEAL and providing an equivalent implementation in the target language. It must be monolithic. If it isn’t, if it is to be divided in processes which each address some of the aspects of the translation from IDEAL to COBOL, its intermediate results would be inconsistent. They would be made of a mix of IDEAL and COBOL, which is a less than desirable property.
Similarly, to the case for the division of the preliminary transformation in a sequence of independent passes, allowing for additional transformation after the migration process is an equally appealing proposition. It allows for division of concern and reusability. Equally importantly, it allows the IDEAL to COBOL phase to remain as simple as possible, since a number of quality improvement processes can now be performed post hoc.
What makes this even more appealing is the fact that the COBOL restructuring facility used at the end of this translation chain is a standard component provided by RaincodeLabs in a number of situations, including PACBASE, COOL:Gen or MetaCOBOL migrations.
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.
IN THE NEWS TODAY
Case Study: Bespoke, Platform-specific Compilers
Case Study: Bespoke, Platform-specific Compilers Since 2011, LzLabs has been developing innovative solutions for enterprise computing customers. Their flagship product, [...]
How Early Bad Smell Detection Can Save Your Project
In most modernization projects, issues with code quality are addressed at the end to simplify the migration process. However, our experience shows that sniffing [...]
Demystifying DSLs Part II : A Working Definition
Demystifying DSLs Part II : A Working Definition Domain-specific Languages (DSLs) are everywhere, but there is precious little consensus on a working definition to describe [...]
