Pre-Conversion Process Overview

Introduction

When converting from a CA-IDEAL/CA-DATACOM operating environment to another programming language we have to consider the following issues as factors in the success or failure of any conversion project:

	The m2o conversion environment supports many operating systems and run time environments which differ in both operability and structure to the CA-IDEAL\CA-DATACOM environment
	Usually there are functional differences which mean that a specific method or process defined in CA-IDEAL will have to be re-engineered in order to function in the same manner in the new environment
	As the new environment uses a different database engine, there will be issues relating to how the converted system emulates the database calls made by the original CA-IDEAL
	Some of the techniques used when programming in CA-IDEAL create performance problems when converted into another language
	Most production systems evolve over their lifetime, giving rise to duplicated functionality within the code
	The structure of the data held within the CA-DATACOM database system may become de-normalized and lead to increased data redundancy
	The destination language environment may well differ in structure considerably from the CA-IDEAL environment and as such it may be necessary to restructure the original system in order to achieve the same functionality as the original system

Pre-Requisites

In order to perform the pre-conversion analyses the following are required:

	A copy of all CA-IDEAL source code including any other programs which are part of the system that be written in a different language such as Assembler or Cobol
	An electronic copy of the data dictionary in both BTG and CXX format
	The specification of the destination environment, which contains details of the destination language, database and operating system

Building the System Object Model

The first stage in building the system object model is to create a conversion repository, using the data dictionary supplied by the client. This contains definitions of all of the tables, views and indexes, which are currently held within the system to be converted.

 
During the process of loading the database definition the integrity of all of the data structures loaded is verified along with any implied relationships that may exist.

Examining Data Structures

This repository also contains detailed information such as field definitions, external references, and database calls, for each source module, which exists within the source code (which has been supplied by the client).

 
The next stage in the process of building the system object model involves examining the source code, which has been supplied using the m2o pre-conversion tool. This tool allows the user to identify common objects, normalise any tables or views, and to clean up the code (which the client has supplied).

Checking Source Using the Pre-Conversion Tool

It is possible to navigate though the hierarchy of code object dependencies within the current system model by using the right mouse button, while positioned on the map, to expand the current object. Alternatively use the module tree to navigate through all of the related code objects.

 
The users can at all times view either the code or all related tables and views again by right clicking on the appropriate code object.

This tool will identify any orphaned programs /subprograms which may not need to be included in the conversion process.

 
Identify and remove any references to dataviews and/or tables, which are no longer used within the system or a specific code module.

 
Any subroutines, which are called only from one place, may be included in the invoking program for ease of conversion and future maintenance.

 
During this process in is possible to normalise the tables/views used within the system using the field tree and dataview map windows that exist within the pre-conversion tool to identify and resolve any data redundancy.

 
It is also possible to determine which paths are used most frequently to access the various tables or views that exist, and if necessary re-structure them accordingly to enhance performance.
 

Reviewing Source Associations

This tool performs a number of functions as part of the processing: it examines the code and attempts to identify and highlight any redundant code, or code sections, as well as any code that may exist in different modules and may have the same functionality.

 
While parsing the code variable type checking is performed and any discrepancies are highlighted so that they may be corrected. Checks are also performed so that any variables, which are not referenced, are also highlighted for removal.

 
The pre-conversion software also performs validation to ensure that the integrity of data structures being used for inter-program communication are consistent in structure and form between invoking and called modules.

 
All of the processes performed during this phase are designed to optimise the code and ensure that once converted, the resultant code is both robust and reliable.