Break free from CA-DATACOM®, rehost your CA-DATACOM® on Azure

Don’t let CA-DATACOM® stop you from getting off the mainframe

Data Migration

Data migration, and more generally, the entire CA-DATACOM® 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 necessary. In any case, it is crucial for this data dictionary to be accurate and detailed enough as it controls the entire migration process.

Data migration is a deliverable artefact in the form of a fully automated process. Data migration is not about merely moving the data, it is about providing a process that can be run to move the most up to date version of the data at any time.

This process is run repeatedly during the migration project and improved continuously until one is fully satisfied with the results, in terms of data modeling and performance. One can then plan the switch over. Data migration is run once a week, once a day, or potentially even more depending on the project at hand.

The data migration process is improved continuously together with the customer. It allows for ad hoc corrections, for instance to check for a given field, and convert chosen values to another value, replacing LOW-VALUE by spaces and vice versa. This is of course an application-level decision, which is taken by the stakeholder and not by Raincode, as we do not have the required expertise nor authority to judge the relevance of such transformations from the application’s perspective.

The DataKom toolset allows for such corrections to be integrated in the data dictionary, so that they are defined once, and are run automatically as part of the data migration process from there on.

CA-IDEAL®

CA-IDEAL® is the 4GL most commonly associated with CA-DATACOM®. 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; 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.

DBNTRY replacement

CA-DATACOM® can also be called from within common third generation languages, PL/I and predominantly 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’.

DataKom includes a tool that can generate a ‘DBNTRY’ replacement module that will behave exactly like the original, except for the fact that ultimately SQLServer will be used for persistence. This allows application programs written in COBOL and PL/I to be ported as is. They don’t need to be modified; they don’t even need to be aware 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.