This document aims at providing you with enough information to start migration of your COBOL applications into your target language. You may like to print this page and study it in detail.

General

COBOL migration is achieved in 4 phases.

• Preparing the COBOL program modules
• Parse of the Prepared program modules
• Analysis of the data & logic in the parsed programs
• Generation of Code for the analyzed program modules.

COBOL Toolkit has been organized in a set of pages (screens). Three of these pages control the above phases. Other pages are provided for confirmation and modification the produced data and logical models of the Program Modules.

Before the migration process starts you must provide the system with some general information regarding your COBOL programs (see Setup Screen). This includes information on your COBOL platform, as well as your Working and Repository directories. Once the setup information is completed you can start the migration process.

The following main screens are provided

• Project Page - This page allows you to prepare a set of COBOL programs. The programs will be placed into a repository directory so they can be shared with other users of COBOL Toolkit.
• Processing Page - This page is the main control center for the Parsing, Analysis and Code Generation of the prepared files. There is a push button provided for each of theses processing stages. For example, you can analyze a set of COBOL programs and then try to immediately process it and generate an output code in your desired language. But for large programs you may want to firstly generate flowchart documentation, revise it, possibly perform some modifications and only then to process your code. The following pages provide some support, which can be used in between these operations.
• Documentation Page - This screen displays all the data definition found at '01' level of FD entries, Working Storage Sections, etc. Double clicking on any of the items in this box will initiate another screen where you can view / modify the individual items for the selected entries. This is most useful when you have many REDEFINITIONS (e.g. var1 REDEFINES var2), which do not match exactly onto each other and hence requires alterations for successful migrations - see Redefines , Ignored Redefines, Delayed Redefines. This screen also allows you to break down large programs into smaller ones.
  Use this screen to make alterations to the system only after successful parsing of a set of COBOL program modules and prior to the code generation stage.
• Data / Printer Files Pages - Sometimes different paths, or different input variable names are used within a SELECT … ASSIGN TO … (File-Control Section) of different COBOL modules. COBOL Toolkit assumes that the different paths or input variable names will refer to different File-structures. You change such assumptions from this page by dragging one of the listed files onto another. Also occasionally COBOL Toolkit may assume that an FD definition refers to a PRINTER instead of a data-files, or vice-versa. This page allows you to correct this assumption.
  This page can be used to make alterations to the system only after successful parsing of a set of COBOL program modules and prior to the code generation stage.
• Target Data-Schemas page. Once the Parsing and Analysis stages are successfully completed - all the FD definitions can be saved (removes the requirement for further parsing & analysis on the subsequent use of the FD in other COBOL modules), and exported in SQL Data Definition language. This page allows you to view the new record structures before saving or exporting them .

• In every run - process as few files as possible - the ideal processing is 1 COBOL program module, plus all its auxiliary copied WS structures and FD structures.
• In applications where the FD definition is placed inside the COBOL program modules (instead of separate include files), COBOL Toolkit needs all the programs, which TOGETHER contain the full definition for the FD, to be processed together. For example, if you have

IDENTIFICATION. PROGRAM1.CBL
...
FD record1.
01 rec1.
03 name pic x(20).
03 Filler .
...

and in next program you have

IDENTIFICATION. PROGRAM2.CBL
...
FD record1.
01 rec1.
03 filler pic x(20).
03 address-line x(60).
...

and in next program you have

IDENTIFICATION. PROGRAM3.CBL
...
FD record1.
01 rec1.
03 filler pic x(20).
03 address-line x(60).
...

then you should process programs 1 & 2 together and 1 & 3 together. This is because the FD entry for record1 is only complete when the above combinations are processed together.

• For applications where the FD / Working Storage variables are placed into separate files and COPIED into the various COBOL program modules - First create a set of COBOL programs - each containing 10 to 15 COPY ***.FD statements. This may be done with a help of DataGen utility, which can be run from the Projects page. For each of the new COBOL modules, insert relevant ACCEPT var1 FROM DATE or ACCEPT var2 FROM TIME to reflect the date settings of the FD or WS date/time variables. The following is an example of one such COBOL program:

IDENTIFICATION DIVISION.
PROGRAM-ID. dataMig1 .
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
INPUT-OUTPUT SECTION.
File-control.

COPY "FD1.SL".
COPY "FD2.SL".
COPY "FD3.SL".


DATA DIVISION.
FILE SECTION.
COPY "FD1.FD".
COPY "FD2.FD".
COPY "FD3.FD".

PROCEDURE DIVISION .
START-section .
* Assume the date-of-birth variable is defined in "FD1.FD"
ACCEPT date-of-birth FROM DATE.

* Assume the logon-time variable is defined in "FD2.FD"
ACCEPT logon-time FROM TIME.

* Assume the logoff-time variable is defined in "FD2.FD"
ACCEPT logoff-time FROM TIME.

stop run .

If you create and process this file first, and then save the data-structures in the Target Data Schemas Page you can relax during the rest of the migration phase with the knowledge that all the date/time variables will actually be treated as 'Date data-type'.

Otherwise, when you process a file which does not contain ACCEPT variable FROM DATE/TIME, then in that file the variable will NOT be treated as 'date data-type' within the generated programs.

Before you start migration of your applications also see the following pages -

Current Limitations - Capabilities not supported by COBOL Toolkit.

General Properties - Additional information on treatment of some COBOL statements.

Known Bugs - Bugs known in current version.

See http://www.softwaremining.com for more up to date version of these files.