#213 cannot call entry in same program.

[wim niemans]

The following code is found on codeproject, and I was curious.

identification division.
program-id. myEntry.
 data division.
 working-storage section.
 01 my-group.
    03 thing1 pic s9(5)v9(5).
    03 thing2 pic x(10).
 linkage section.
 01 x pic x any length.
 procedure division.
     move 12345.12345          to thing1
     move "dog day afternoons" to thing2
     call "dangerous" using my-group
     goback.

     entry "dangerous" using  x

     display x(1:20)
     goback.

After compile as an executable, on execute :

myEntry.cbl: 17: libcob: Cannot find module 'dangerous'
Process finished with exit code 1

After compile as a module, on execute :

Attempt to reference unallocated memory (Signal SIGSEGV)
Abnormal termination - File contents may be incorrect

In this case, openIDE fails with

libcob: Cannot find module 'myEntry'
Process finished with exit code 1

Have fun!

[wim niemans]

line 17 in above post must be read as being line 13 in posted cobol source.

[Edward Hart]

The code runs as expected if it is marked RECURSIVE.

[Simon Sobisch]

Thank you for checking this. Therefore it is no bug in the runtime or code generation.
Do you think you can add a check for compile time (included with the same-program-id problem you tackle)?

[Edward Hart]

I'll see what I can do. It'll be a while before I get round to it, though. This is my list of outstanding tasks:

1. [bugs:#205],
2. [bugs:#217],
3. [bugs:#124],
4. this bug,
5. [bugs:#212], and
6. Screen section stuff.

[Brian Tiffin]

Turns out the ANY LENGTH fill in code occurs before CALL parameter setup when ENTRY is involved. Two work arounds, leave the ENTRY and CALL STATIC "thing", but LINKAGE will need to be fixed length, not ANY. Or move the ENTRY to a full PROCEDURE.

::cobolfree
       identification division.
       program-id. myEntry.
        data division.
        working-storage section.
        01 my-group.
           03 thing1 pic s9(5)v9(5).
           03 thing2 pic x(10).
        procedure division.
            move 12345.12345          to thing1
            move "dog day afternoons" to thing2
            call "dangerous" using my-group
            goback.

       end program myEntry.

       identification division.
       program-id. dangerous.
        data division.
        working-storage section.
        linkage section.
        01 x pic x any length.
        procedure division using x.

            display x(1:20)
            goback.

procedure with ANY LENGTH

or

::cobolfree
       identification division.                                         
       program-id. myEntry.                                             
        data division.
        working-storage section.
        01 my-group.
           03 thing1 pic s9(5)v9(5).
           03 thing2 pic x(10).
        linkage section.
        01 x pic x(20).
        procedure division.
            move 12345.12345          to thing1
            move "dog day afternoons" to thing2
            call static "dangerous" using my-group
            goback.

            entry "dangerous" using  x.

            display x(1:20)
            goback.

CALL STATIC to get proper ld link, and use a fixed length in the LINKAGE SECTION.

Both of these workarounds avoid a codegen code flow issue with current 2.0.

In the C, original case, this line

::c
  cob_procedure_params[0] = &f_6;

occurs too late; after the module attempts to determine the ANY LENGTH (and has no data to pull size from), which occurs just before the CALL to "dangerous". output_call occurs after output_internal_function. Either fix avoids that scenario for now.