|
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.
Top | Index | Glossary
|
