INDEX

SELECT file ASSIGN xxx FILE STATUS [IS] dataName [IN dataname2]. The optional ...
SELECT file ASSIGN xxxx [RECORD DELIMITER IS xxx] . Record delimiter information parsed but ...
77 variableName USAGE IS [usage]. The usage was not being parsed correctly.
EVALUATE condition WHEN ANY ... 'any' currently treated like when other
EVALUATE condition [ALSO ...] , the optional ALSO is not currently processed and ...
FILE SECTION. FD abcd [RECORD VARYING n TO m DEPENDING var2] ...
GO TO procedureName-1 [IN procedureName-2] ... the optional part was not previously parsed
PERFORM procedureName-1 [OF procedureName-2] , the optional clause was not handled
SORT filename ON ASCENDING KEY dataname-1 '''OF filename''' ... OF filename is
COBOL Comments in mid statements are not handled - have to be manually removed...
Fail-safe Parsing Technology implemented
CICS Statements partially translated - the full architecture for support being introduced
ADDRESS OF - statement previously not handled at all - now printed with a POTENTIAL bug message.
Dealing with Arrays - memory/Performance improvements for dealing with non-redefined array variables
Data Group class does not support any color/display information - e.g.
STRING ... DELIMITED BY variable - Format is now parsed :- output is of the format
Screen formating declarations in data division - eg : 03 var a PIC X JUSTIFIED RIGHT. -
Representation of large numeric types
Embedded SQL - limited support
66 variable RENAMES variables . --- RENAME not currently handled at all.
88 type field definitions cannot have further subfields, e.g.
ACCEPT var1 ON EXCEPTION var1 PERFORM abcd - Exception part not handled/Required
CALL - On overflow, On exception.
CALL xxx USING OMITTED , BY ...
CALL xxx using yyy , zzz GIVING aaa. - Where aaa is a group item needs manual check
CD - COMMUNICATION SECTION Not supported
COBOL DECLARATIVE Section - mostly ignored
COBOL ERROR statement - Not handled properly at Code Generation stage
COBOL PICTURE Clauses contain A , B, ':' or other character
COBOL SEARCH / Varying statement not Supported
COBOL conditionals containing mathematical routines - forces a direct translation of variables within statement.
COBOL integer variables defined as PIC 999xxx999
COBOL statement 'OCCURS DEPENDING' ON statements - largetst array size selected
COMP / Packed Decimals variables occasionally are mapped incorrectly.
Cobol 'ALTER' keyword - system will ignore the ALTER keyword. A note is placed in the ...
DELPHI - No Support for function overloading
DISPLAY space SIZE n Tthe size information is discarded
Data Section : POINTER : eg 05 address1 POINTER. Not supported ...
Data-type conversions on array variables occasionally missed out.
Delphi Division Sign : 'DIV' v.s '/'
FILE SECTION. FD recordName. COPY filename. ... The 'FD recordname' MUST be defined in copyfile. ...
Hex Vairables - eg X"00" cannot be handled-
High-VALUES / LOW-VALUES -> Translated application uses contants to represent these
I-O-Control : - SAME option not currently implemented
MICROFOCUS - screen handling using CURSORS defined in SPECIAL SECTIONS - not handled
Mixed Data Types --> "999XXX999" - always converts the end variable to 'String' type
Multi 01 FD Files - START shared-key - The system has no way of knowing which SQL table ...
Multi-procedure Cobol programs. -> Cannot be supported in some target languages
Multiple redefinition of a decimal sometimes requires validation of the generated code
NULL values in database: -The generated programs uses a blank string "" or 0 for their representation.
Not all of the COBOL comments are transfered/translated in the generated code.
OPEN -- EXTENT/I-O/OUTPUT/INPUT
OPEN file-a ALLOWING ALL -> - the ALLOWING ALL information is currently not processed
Operations of type : ADD a , b, c TO d - generates non-compilable translation ...
PIC "9-" format conversion, ie negative sign at end requires manual check
Paragraph/Section IDs are mandatory ...
Parser - Use of ALL --> ABC = ALL "*" within conditional statments not handled yet
Problems in handling '77' type vars - will be picked up by compiler (java or delphi)
RD files - Unless assigned to PRINTER the system
Redefinition of 01-FD fields not supported
SELECT file ASSIGN xxx [PADDING CHARACTER IS "9"] . padding Character is parsed but ignored.
SPECIAL NAMES section ignored. Currently non of the statements in SPECIAL names are
Variable length OCCURS not supported - change OCCURS to a largest possible value...
field definitions with OCCURS n times DEPENDING on Var1 or Record - var1 of record is not ..

SELECT file ASSIGN xxx FILE STATUS [IS] dataName [IN dataname2]. The optional ...

SELECT file ASSIGN xxxx [RECORD DELIMITER IS xxx] . Record delimiter information parsed but ...

77 variableName USAGE IS [usage]. The usage was not being parsed correctly.

EVALUATE condition WHEN ANY ... 'any' currently treated like when other

EVALUATE condition [ALSO ...] , the optional ALSO is not currently processed and ...

FILE SECTION. FD abcd [RECORD VARYING n TO m DEPENDING var2] ...
The optional depending on was not previously parsed.

GO TO procedureName-1 [IN procedureName-2] ... the optional part was not previously parsed

PERFORM procedureName-1 [OF procedureName-2] , the optional clause was not handled

SORT filename ON ASCENDING KEY dataname-1 '''OF filename''' ... OF filename is

COBOL Comments in mid statements are not handled - have to be manually removed...
Eg you should remove the comment from this statement :
IF A >
* this comment should be remove
2 THEN ...
END IF.
As a rule , if the parsing has failed and there is a comment line near the failed statment, try removing it before continuing.

Fail-safe Parsing Technology implementedDuring processing of Procedure division - this system now does not stop when comming accross statements that it does not recognise.

CICS Statements partially translated - the full architecture for support being introduced in v1.2 .

ADDRESS OF - statement previously not handled at all - now printed with a POTENTIAL bug message.

Dealing with Arrays - memory/Performance improvements for dealing with non-redefined array variables

Data Group class does not support any color/display information - e.g.
e.g. 01 background blue forground white.
03 ....
the 01 entry above is not supported.

STRING ... DELIMITED BY variable - Format is now parsed :- output is of the formatSTRING var1 DELEIMITED BY var2 INTO var3
now produces:
// Software Mining - Please Check the following:
// COBOL String Command - delimited by : var2
var3 = var2;

Screen formating declarations in data division - eg : 03 var a PIC X JUSTIFIED RIGHT. -

Representation of large numeric typesJava -
the largest number represented by Java is Long (64 Bit).
COBOL variables which represent values larger than that cannot be represented.
Delphi -
the largest number represented by Delphi is LongInt (32 Bit).

Embedded SQL - limited support

66 variable RENAMES variables . --- RENAME not currently handled at all.

88 type field definitions cannot have further subfields, e.g.
03 yes-no pic x(3).88 yes "yes"
05 yes2 pic "x".
88 y "y".

ACCEPT var1 ON EXCEPTION var1 PERFORM abcd - Exception part not handled/Required

CALL - On overflow, On exception.
These are to do with memory handling in COBOL . The statements are Parsed but not translated..

CALL xxx USING OMITTED , BY ...
The parser will skip over this presently (no errors raised)

CALL xxx using yyy , zzz GIVING aaa. - Where aaa is a group item needs manual check

CD - COMMUNICATION SECTION Not supported

COBOL DECLARATIVE Section - mostly ignored

COBOL ERROR statement - Not handled properly at Code Generation stage
The system will currently generate the following line BEFORE it attempts to handle the the translation.
PLEASE CHECK THE FOLLOWING STATEMENTS (Translation of COBOL ERROR Statement)
// Following is the systems attempt to handle the error statment:

COBOL PICTURE Clauses contain A , B, ':' or other character
These are currently ignored, eg
01 ws1 pic "xx:xx" \.
....
move 1234 to ws1
is translted to :
var ws1 : String[7];
...
ws1 := '1234' ;

COBOL SEARCH / Varying statement not Supported

COBOL conditionals containing mathematical routines - forces a direct translation of variables within statement.
eg
if (a + b) = "hello; ...
If A or B are arrays, system will be unable to expand into
if (a[0] + a[1] + ...

COBOL integer variables defined as PIC 999xxx999
The target compiler should generate error which can be
handled manually. Note that if the format is of a varaible which will
be defined later in terms of PIC999, PIC XXX, PIC 999. then the
system should be able to handle it (no worries)

COBOL statement 'OCCURS DEPENDING' ON statements - largetst array size selected
Most target languages will be unable to handle this type of declarations.
Where possible replace 'depending on' clause with a fixed integer.

COMP / Packed Decimals variables occasionally are mapped incorrectly.
The following table is used to calculate the length of the COMP variables (packed decimals) in bytes.
case (length of the COMP)
0 : 0 ;
1 : 2;
2 : 2;
Even Number : 1+ ( the-length / 2)
Odd Number : (1+ the-length) / 2
This gives correct setting for most COBOL compilers - but however errors occur occasionally.
If you inform us of the particular setting of your compiler, we will be able to build that into the CORECT - and send you an upgrade to this correction very quickly.
For CORECT to work it is paramount that the mapping is done correctly - specially where the comp variables are redefined or
mapped onto other variables.
eg
07 var-1PIC 9(05) COMP.
07 var-2 REDEFINES var-1 PIC X(03) .

Cobol 'ALTER' keyword - system will ignore the ALTER keyword. A note is placed in the ...
generated program : -
// Software Mining - Poterntial problem . Alter Statement not handled
// ALTER paragraph1 PROCEED TO paragraph2

DELPHI - No Support for function overloading
Numeric Conditions: Ie translation of COBOL conditionals of type:
if variable1 is NUMERIC #.
This type of statement is currently translated to :
IF ACMNUMERIC(variable1) # .
Version 3.0 of delphi does not support function overloading, hence cannot define function ACMNUMERIC for different data-types.
Although this does not cause a big problem. Any attempt to set non-numeric values to a numeric data-type in Delphi will generate an
exception automatically. Hence the only ACMNUMERIC function provided only caters for string data types (see acmfuncs.pas file). All
tests on other number types can be commented out manually. E.g the following statement:
If ACMNumeric(integer1) then #.
should be translated to
IF TRUE then #
as the condition will never arise (the exception handler will trap it before it gets to this statement).

DISPLAY space SIZE n Tthe size information is discarded

Data Section : POINTER : eg 05 address1 POINTER. Not supported ...Used only for calling programs -
Assign the datatype as CHARACTER(1) to resolve the CONVERGE-FD programs.
Require an additional field to indicate the POINTER Operation.
Problem will rise with respect to the recieving program - also since a pointer can represent a cobol group - need a way round calling
the procedure with all individaul items in that group (eg call abcd with a , b , c ..... z) where a..z can be easily described by a
group/structure.

Data-type conversions on array variables occasionally missed out.
Array data-type conversions. Occasionally the conversion of array date types is omitted, eg the Cobol statemente
MOVE string_variable1 TO arrayed_integer_variable (n)
is currently translated to
arrayed_integer_variable (n) := string_variable1;
Instead of
arrayed_integer_variable (n) := strtoint(string_variable1);
This problem is detected by the compilers & will be corrected in future versions.

Delphi Division Sign : 'DIV' v.s '/'

FILE SECTION. FD recordName. COPY filename. ... The 'FD recordname' MUST be defined in copyfile. ...
eg.
FILE SECTION.
FD record1.
COPY copyfile1.CPY.
will not be processed correctly. But
FILE SECTION.
COPY copyfile1.CPY.
will be processed correctly if 'FD record1' is defined in the copyFile1.CPY.

Hex Vairables - eg X"00" cannot be handled-
All the information relying on the hex data must be manually corrected.

High-VALUES / LOW-VALUES -> Translated application uses contants to represent these
COBOL Hi and Low values are translated to CONSTANT variables in target language. eg in Borland DELPHI the following constants
are defined:
Const g_high_values = 999999999;
Const g_low_values = -999999999;

I-O-Control : - SAME option not currently implemented

MICROFOCUS - screen handling using CURSORS defined in SPECIAL SECTIONS - not handled
01 cursor-position.
03 cursor-row pic 99.
03 cursor-col pic 99.

Mixed Data Types --> "999XXX999" - always converts the end variable to 'String' type

Multi 01 FD Files - START shared-key - The system has no way of knowing which SQL table ...
to open. THerefore it will open all the relevant SQL tables.
A comment is generated telling the user to comment out one of the OPEN statements.The comment has the following form:
// - Software Mining WARNING - START statement containing 1 FD with multiple 01 entries -
// - One of the following OpenUsing_... statements will probably have to be commented out -

Multi-procedure Cobol programs. -> Cannot be supported in some target languages
Multi-procedure COBOL programs can only (presently ) be migrated to Borland Delphi. Java/VB lack the functionality of handling procedures with embedded procedures!
If it is at all possible -the multi-procedure modules should be broken down into separate modules.

Multiple redefinition of a decimal sometimes requires validation of the generated codeE.g
....
03 dec1 pic 9.9(9).
03 dec11 pic 99.9(8) redefines dec1.
03 dec12 pic 999.9(7) redefines dec1.
03 dec13 pic 9999.9(6) redefines dec1.
03 dec14 pic 99999.9(5) redefines dec1.
Note that in the above example the field length for all redefined items will remain the same.CORECT will translate the above to :
double dec; // (in java, or equivalant in other languages).
The above MAY cause information loss / violation / e.g.
where in COBOL we come accross :
03 str1 pic X(11);
then the statements
MOVE dec1 TO str1
and MOVE dec11 TO str1
when translated will both end up as:
str1 = dec1;

NULL values in database: -The generated programs uses a blank string "" or 0 for their representation.Java -
For purformance reasons CORECT translates COBOL variables to primary datatypes. NULL values are thus represented as "" for strings, or 0 for numericals.
Delphi -
Access to all variables are thru primary data-types in the wrappr classes. NULL values are thus represented as "" for strings, or 0 for numericals. Alteration - as of version 0.9.8.6
JAVA - The numerical values can be initialized to a static variable (e.g. ACMMath.DEFAULT_INIT_INT)
the user can hence change this value to be 0 or other values eg -999999999999.
The statements if int1 EQUALS SPACES ..
is hence translated toif (ACMMath.isNull(int1)) { ...
this method can be changed accordingly to check for 0 or the other value e.g. -999999999999 to represent NULLS.

Not all of the COBOL comments are transfered/translated in the generated code.
The following are some of the places where comments are not transfared.
>> IDENTIFICATION DIVISION COMMENTS -
Author, Security, Source-Computer, Target-computer, Remarks, ...
>>All comments prior to PROCEDURE DIVISION
>> Others, for example
Procedure division
* "comment line 1
main Section . ... ------------>> Not handled
Procedure division.
main Section .
* comment line 1 ... ------------>> handled
sect1 .
Procedure division
main Section .
sect1 .
statements.
* comment line 1 ------------>> handled
sect2 .

OPEN -- EXTENT/I-O/OUTPUT/INPUT
On a SEQUENTIAL FILE, OPEN OUTPUT will cause all the existing recordsto be deleted. Current CORECT system will treat all OPEN outputs like

OPEN file-a ALLOWING ALL -> - the ALLOWING ALL information is currently not processed

Operations of type : ADD a , b, c TO d - generates non-compilable translation ...
Some Math Operations with multiple arguments may generate an error which is picked by the compiler.
eg COBOL statement :
COMPUTE a = (B) + (C) + (D)
will generate
a = (b) + (c);
+ (d)
And Should be converted to
a = (b) + (c) + (d);
Note that this is NOT always the case and conversion of COMPUTE a = b + c + d; will be done with no errors. We will do our best to correct this problem for the futuer programs.

PIC "9-" format conversion, ie negative sign at end requires manual check
In cobol you can then say : 05 int-1 pic "9-".
05 abc
10 c-1 pic x. 10 c-2 pic x.
thenMOVE int-1 to abc.
IF c-2 = "-" then ...
This variable is translated to an SIGNED LONG INTEGER in target language (DELPHI / JAVA ...).

Paragraph/Section IDs are mandatory ...
Sometimes after the procedure division there is no section id (presumably when there will only be 1 section.) eg
PROCEDURE DIVISION .
* missing SECTION ID or Section Identifier.
move ....
Currently all sections would require names. You must modify the code to include a section name eg:
PROCEDURE DIVISION \.
* MAIN . (or SECTION MAIN .
move ....

Parser - Use of ALL --> ABC = ALL "*" within conditional statments not handled yet
Currently ALL "?" goes thru unchanged ie the above statement will become:
if abc = ALL "*" then
begin
...
end;
This will be picked up by the compiler

Problems in handling '77' type vars - will be picked up by compiler (java or delphi)
eg
01 var 1 .
03 var2 OCCURS 101 TIMES .
05 var3 PIC X(01) VALUE IS SPACES .
77 var4 PIC 9(03) VALUE 0 .
the translation of this is :
var4: array [1..101] of Longint;
var3: array [1..101] of String;

RD files - Unless assigned to PRINTER the system
will treat them just like FD files, this is incorrect, they should always be treated as printer type files.
SOLUTION
==========

Redefinition of 01-FD fields not supported
Redefinitions of 01 Field Definitions will fail during the Analysis stage.
Solution
======

SELECT file ASSIGN xxx [PADDING CHARACTER IS "9"] . padding Character is parsed but ignored.

SPECIAL NAMES section ignored. Currently non of the statements in SPECIAL names areacted upon.
Further more - the
CLASS declaration is not supported.
eg.
SPECIAL-NAMES.
currency sign is "#".

Variable length OCCURS not supported - change OCCURS to a largest possible value...eg.

field definitions with OCCURS n times DEPENDING on Var1 or Record - var1 of record is not ..currently handled yet.Note that currently the information on depending on is discarded. therefore just remove the OF Record section, e.g.03 var1 OCCURS 10 to 20 times depending on field1 of Record1. should be manually changed to 03 var1 OCCURS 10 to 20 times depending on field1.