Re: [open-cobol-list] OC Compile Errors that work in MicroFocus and Mainframe

[Roger While]

> I have been working on compiling all of the programs that the product that 
> I work on has (over 1000), and have come up with only a couple of sytax 
> errors that are not handled in OC.  (Using the 20070518 0.33 prerelease).
>
> All can be handled with code changes, but wanted to bring them up.
>
> Running on AIX 5L, 64bit
>
> Using MicroFocus 4.0 and IBM Enterprise Cobol 3.2.1
>
> 1.  88 levels under a redefines
>
> translating /work/cob4514046_0.cob into /work/cob4514046_0.c
> /copy/AMWSUTBA:39: Error: syntax error, unexpected LITERAL, expecting WORD
>
> 10  'SUTBA'-INIT-STAT               PIC 9(3).
> 10  'SUTBA'-INIT-STAT-X           REDEFINES
>     'SUTBA'-INIT-STAT               PIC X(3).
>   88  'SUTBA'-INIT-OPEN-DEFAULT       VALUE '000'.
>   88  'SUTBA'-INIT-OPEN               VALUE '000'
>                                        THRU '099'.
>   88  'SUTBA'-INIT-OPEN-UN-DEFAULT    VALUE '100'.


Of course 88 levels are allowed within a redefine.
The problem is with your COPY REPLACING clause, see (3) below.

> 2.  Reference modification of a function
>
> AMSCATIM.cbl:25139: Error: syntax error, unexpected ':'
>
> MOVE FUNCTION CURRENT-DATE (17:5)    TO WS-DIFF-FROM-GMT.


Correct. OC does not, at the moment, support ref-modding of a function.



> 3.  Copy replacing with a reserved word (it appears so at least).
>
> 01  IN-RECORD.
>     COPY CPWWPOST REPLACING 'POST' BY IN.
>
> CPBACH.cbl:199: Error: syntax error


The error is correct.
Going by what you have in (1) above, your copy probably
looks something like -
   02  'POST'-FLD-1     PIC ....
   02  'POST'-FLD-2     PIC ....

For (1) and this (3) you should be doing psuedo-text replacement.
ie.
COPY ....   REPLACING =='POST'== BY ==IN==.




> 4.  SELECT has ORGANIZATION IS RECORD SEQUENTIAL.
>
> Looking at the doc for MicroFocus and IBM, I don't see this listed, but 
> both accept it.
>
> BPRINT.cbl:11: Error: syntax error, unexpected RECORD, expecting INDEXED 
> or LINE or RELATIVE or SEQUENTIAL
>
> FILE-CONTROL.
>     SELECT IN-FILE ASSIGN TO INFILE
>         ORGANIZATION IS RECORD SEQUENTIAL
>         ACCESS MODE IS SEQUENTIAL.

Error is correct. Nothing to say/do here.



> 5.  Compiler directive of P64  (MicroFocus)
>
>        01 SQLDA sync.
>           05 SQLDAID               PIC X(8)  VALUE "SQLDA  ".
>           05 SQLDABC               PIC S9(9) COMP-5 value 0.
>           05 SQLN                  PIC S9(4) COMP-5 value 0.
>           05 SQLD                  PIC S9(4) COMP-5 value 0.
>           05 SQLVAR OCCURS 0 TO 1489 TIMES DEPENDING ON SQLD.
>              10 SQLTYPE            PIC S9(4) COMP-5.
>              10 SQLLEN             PIC S9(4) COMP-5.
>       $IF P64 SET
>              *> For 64-bit environments, ensure that SQLDATA is
>              *> aligned on an 8-byte boundary.
>              10 FILLER             PIC S9(9) COMP-5.
>       $END
>              10 SQLDATA            USAGE POINTER.
>              10 SQLIND             USAGE POINTER.
>              10 SQLNAME.
>                 15 SQLNAMEL        PIC S9(4) COMP-5.
>                 15 SQLNAMEC        PIC X(30).


I don't think that the above code is correct.
You have changed each occurrence of SQLVAR from 4 bytes to 8 bytes.

Regardless, we do not support the $IF/END MF extension.




> 6.  Procedure Pointers and ENTRY statement
>
>
>        01  CALLED-PGMS.
>            05  300-R60100              PIC X(8)     VALUE 'R60100'.
>
>         01  800-PTR-R60100 EXTERNAL     PROCEDURE-POINTER.
>
>           SET 800-PTR-R60100             TO ENTRY 300-R60100.
>
>
>            CALL 800-PTR-R60100.
>
>
> 7.  No error or warning when PROGRAM-ID does not equal File name.
>
> MF and z/OS don't seem to care that the Program ID does not match the 
> module name.
> With how calls are done in OC, it does matter.
>
> When a module is compiled with -m, can a warning/error occur when the 
> PROGRAM-ID does not equal the file name.
> I would say change it, but after research the Procedure-pointer above, the 
> entry point goes to the name in the PROGRAM-ID.
>
> Maybe two entry points are in order.  One for the file name and one for 
> the PROGRAM-ID if they are different.

No, this was considered and rejected.
(The commented out code is in cobc/typeck.c - line 426)
Consider one source file consisting of more than one program
(nested source).

Also MF DOES care if P-ID is not equal source name.
Consider a source module named "mycob.cob" with
P-ID "MYENT".
If you compile (MF) mycob.cob to gnt/int and then
try to CALL "MYENT", it will not be found.
(Same with OC)

Note that OC does have a facility to preload modules to cater
for exactly this situation (or indeed if you have prepared
a "library" of cobol progs)
Set and export the variable COB_PRE_LOAD to the name(s)
of the module(s) (without suffix) that should be preloaded.
eg. For above
export COB_PRE_LOAD=mycob

You may specify multiple modules by using the colon seperator.

Roger