The
system will generally refer to int1 as str(1) ;
However,
there are situations where the variables and their redefinitions do not map to
the same thing, eg.
03 integers.
05 int4 Pic 99.
05 int5 Pic 99.
03 strings REDEFINES integers.
05 str4 PIC X.
05 str5 PIC XXX.
In
such situations, there are two options available:
(A)
Remove the REDEFINITION from the code - this is a viable option where the
variables are independent of each other, and a redefinition is used as a course
to reduce memory requirement of the COBOL programs. We may be able to pick some
of such variables out, but it is up to the proprietor of the code to approve of
such changes, and for the best migration result, the proprietor and authors, or
people in charge of maintenance of the code are in a better position to point
such areas out.
Where
different redefined variables map differently, but represent the same
conceptual vairable, the migration process may still benefit in removal of the
redefinition, - ie the finished code could become substatially easier to debug.
In such situations a programmer is required to go through the generated code in
order to manually insert the appropriate assigments into the code. This process
would become automated in due course.
(B)
To let the system do its best to cater for such situations. Sometimes the
result will be correct and compilable, other times the generated code will
contain errors and would need manual touch up. For example, in the above
scenario, the references to int5 like:
COMPUTE int1 = int4 + 2
may be converted to
int1 := COPY( str4 + str5 , 1, 2) + 2;
But
MOVE ZERO TO array1(int1);
may
be converted incorrectly to
array1[str1, str2] = 0;
System
Running Out Of Memory - large arrays
Large
arrays can cause memory problems with CORECT. Consider the following COBOL
example :
01 example-group.
02 group1 occurs 2 times.
03 x pic XX.
03 y pic XX.
02 group2 redefines group1.
03 a pic XX occurs 2 Times.
03 b pic XX occurs 2 Times.
Here
CORECT should be able to do the following matching / mapping:
X Y X Y
A A B B
In
order to achieve the above match, CORECT will actually create the full set of
the above elements ie will create 4 objects for group1 and 4 objects for
group2, and then tries to map them onto each other. Hence, for large arrays -
numerous objects will be created and the process of mapping these objects will
take a long time. Futher versions of CORECT will use a different algorithm for
finding the common denominator of the above.
Presently
- where possible you are best advised to reduce the array size of variables.
Note that nested arrays will cause the most amount of objects to be created -
eg:
01 group1 occurs 3 times
02 group1 occurs 4 times.
04 group3 occurs 5 times
05 x pic XX occurs 6 times.
In
the above example the system will attempt to generate 6 x 5 x 4 x 3 = 360
objects.
You
can also adjust the amount of HEAP size allocated to the executable by
modifying the
C:\CORECTxx\BIN\ALLEGRO.INI,
and
increasing the variable HEAPSIZE. This variable refers to amount of Heap memory
in MegaBytes allocated to CORECT via the LISP interpreter.
Note
do not reduce this value to below 16.0.
Fails to start with 'COMCTL32.dll version 4.7 or
later' error. This only applies to earlier versions
of
Windows 95 or Windows NT 3.51.
This
error is due to the new GUI componenets introduced in MS Windows eg ToolBars,
CoolBars, flat buttons, etc.
To
corrected your system you will need to either
- install a newer version of operating system
or
- installing Internet Explorer version 3.0 or later.
REDEFINES
statements in COBOL variable definitions
COBOL Redefinitions are by far
the cause of most problems in the conversion of COBOL code into almost any
other computer language. This is due to the fact that almost no other language
provides for such redefinitions. As it is, the system can handle converson of a variety of redefinitions, but not all can be
handled properly. n cases the sizes of the redefined
variables map directly onto other variable, the produced code will handle the
conversion successfully, eg
03 integers.
05 int1 Pic 99.
05 int2 Pic 99.
03 strings
REDEFINES integers.
05 str1 PIC XX.
05 str2 PIC XX.
The variables will be
converted to int1 and int2, and all the subsequent references to str1 and str2
will be handled as
inttostr(int1), or
int1 :=
strtoint(another_integer);
Also where a set of variables
are the redefined as arrays with same variable sizes, the conversion is also
successful - eg
03 integers.
05 int1 Pic
XX.
05 int2 Pic
XX.
03 str REDEFINES integers PIC XX OCCURS 2 TIMES.
The system will generally
refer to int1 as str(1) ;
However, there are situations
where the variables and their redefinitions do not map to the same thing, eg.
03 integers.
05 int4 Pic 99.
05 int5 Pic 99.
03 strings
REDEFINES integers.
05 str4 PIC X.
05 str5 PIC XXX.
In such situations, there are
two options available:
(A) Remove the REDEFINITION
from the code - this is a viable option where the variables are independent of
each other, and a redefinition is used as a course to reduce memory requirement
of the COBOL programs. We may be able to pick some of such variables out, but
it is up to the proprietor of the code to approve of such changes, and for the
best migration result, the proprietor and authors, or people in charge of
maintenance of the code are in a better position to point such areas out.
Where different redefined
variables map differently, but represent the same conceptual vairable, the migration process may still benefit in
removal of the redefinition, - ie the finished code
could become substatially easier to debug. In such
situations a programmer is required to go through the generated code in order
to manually insert the appropriate assigments into
the code. This process would become automated in due course.
(B) To let the system do its best to cater for such situations. Sometimes the result
will be correct and compilable, other times the
generated code will contain errors and would need manual touch up. For example,
in the above scenario, the references to int5 like:
COMPUTE int1 = int4 + 2
may
be converted to
int1 :=
COPY( str4 + str5 , 1, 2) + 2;
But
MOVE ZERO TO array1(int1);
may
be converted incorrectly to
array1[str1,
str2] = 0;
CORECT refers to 'ignore-redefines'
to d-redefines and delete-redefiens to c-redefines
Failures during Parsing.
Some non COBOL-85 , and some standard COBOL statements are not catered for.
When the COBOL statement is part of the Ansi 85
standard, there is usually a good reason for not including it in the system.
You will need to manually
adjust the prepared files (or the original Cobol
program module, and then prepare it again) to remove the statments
not recognised by the system. For modificatons
of the prepared files see help topics : Properties
& Specification Section ' Prepared File Formats'
The system will print the line
where parsing failed. You can use this information to correct the prepared
files. Look for the following in the prepared files:
- Remove comments
from failed area,
- Modify or remove
non-standard COBOL 85 statements
- if the above fail
then see the Limitation and bugs pages to see if you can find information
related to your specific problem.
- if there are any HEX statements , remove them eg MOVE x"e4" to VAR-1 will cause a problem - change it to "xe4" and then modify the target generated program
manually.
Dongle
Installation Failure under Windows NT
You will require Administrator
access to the system before running of HINST.EXE software.
Java
- Symantec Cafe - the created / added form is not listed in the 'Objects'
screen and cannot be accessed via GUI Bui
1- Make sure the ACMFrame.java is added to the project.
2- In Projects window, select
the Files tab.
3- Open the Program form (eg for program1 - open CFrmProgram1.java) by double
clicking on it.
4- In order to force the IDE
to reparse the form, make a small - trivial change to file (eg
insert a space within in a comment)
5-
Save the file.
