cobc does not handle the SET <procedure-pointer>
TO ENTRY <ws pgm name>.
Roger While <address@hidden> wrote on 05/25/2007
02:00:43 AM:
>
>
>
> >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
>
>