File Extensions
The differentiation between different file types enables COBOL Translation Toolkit to organize the processing of the files in a better order. If all your programs use the same extension, you will need to modify them to use different extension. Note that ALL PROGRAM FILES REQUIRE AN EXTENTION.

Migrated programs
Programs translated by COBOL Translation Toolkit from COBOL to DELPHI or JAVA.

Operational Stages
There are 4 stages to migration of each COBOL program module: Pre-Processor: Minimal Syntax changes and preparation of COBOL programs.
Parsing: Semantic parsing of programs - generates a logical model of program structure and data-definitions of each program.
Analysis: Further Analysis of program modules and data-definitions will produce an intermediate model of both data and operation logic programs and data-files.
Code Generation: The process of translation of the intermediate data/logical models into a selected target program.
There are many steps within each of the above stages.
The user interface is organized in such a way to help you going through these processes.


Parsing
There are two options on parsing.
Parse of data-definitions is useful if you may need to examine and modify the data structures of you programs - prior to the main processing. It effectively cuts out the processing of the PROCEDURE divisions, hence saving time in parsing time required. Note that the date-time conversions will NOT be picked up by the system - however, you may manually change the data type of a variable using the functions provided. The main benefit of parsing the data-definitions first is that you can see the effect of REDEFINITIONS of variables, and how redefined map on to each other, and where necessary remove/change the redefinitions if they are not absolutely essential. Such changes must be saved, and the subsequent re-parsing of the programs will pick these changes up.
DO NOT ATTEMPT TO FURTHER PROCESS (ANALYSE) the partly parsed programs. You will need to start complete parse before any analysis can be done by the system.

Redefines, Ignored Redefines, Delayed Redefines
You can modify the REDEFINEs on a field/group to Ignore Redefines or Delayed Redefines. By changing the Redefines to Ignored Redefines the system essentially creates different variable/memory spaces for each of the involved variables, as opposed to the REDEFINES statement, which essentially creates a SINGLE memory space/variable for the involved fields.
The system will make no attempt to consolidate the variables whose definition has been changed to Ignored Redefines.
Delayed Redefined is similar to above, but the system will attempt to consolidate the variables after each operation on the variables.

For example, the variables in following COBOL code

03 var-1 pic x(3) .
03 var-2 REDEFINES var-1 pic x(2) comp
....
move 'abc' to var-1
move 'xyz' to var-2

will be translated into only the 1 variable in the target language:

String var_1;
...
var_1 = 'abc';
var_1 = 'xyz';

By changing the redefinition to Ignored Redefines, the target code will become:

String var_1;
String var_2;
...
var_1 = 'abc';
var_2 = 'xyz';

By changing the redefinition to Delayed Redefines, the target code will become:

String var_1;
String var_2;
...
var_1 = 'abc';
var_2 = var_1;
var_2 = 'xyz';
var_1 = var_2;

Note that the system does not guarantee that the variables will always be equated on Delayed Redefines. Particularly, the equating processmay be skipped on operations involving sub-groups of the Redefined item, for example in translation of the following COBOL statements:

02 group-1 .
   03 group-2 .
     05 var-1 pic x(3).
02 var-2 redefines var-1 pic x(3)
....
MOVE 'abc' TO VAR-1 .

If the Redefinition on Var-2 is modified to Delayed Redefines, then the system may just generate var_1 = abc';and var_2 = var1; may not be generated.
Saving Generated Model of Record Structures
This is useful when an FD is used in more than 1 COBOL module/program.
The first time you parse and analyze a COBOL program, which utilizes this particular FD, the COBOL Translation Toolkit will generate its own internal representation of the FD. Saving your work at this stage will improve the system performance in dealing with other COBOL modules also utilizing this FD.
Saving your work will also allows COBOL Translation Toolkit to remember any modifications you may have made to the COBOL Translation Toolkit’s representation of the FD using Expanded FD Screen.
WS/FD Object Wrappers
None of the migrated programs access the data migrated from COBOL WS/FD directly. All access is achieved through a set of objects automatically created by COBOL Translation Toolkit. This structure eases optimization of the memory access routines (for WS wrappers) or the database access routines (for FD wrappers) by allowing changes to be made to the objects representing the WS section or the FD, and none of the migrated programs will require modifications.