#901 PERFORM ... THRU falls thru the procedure end into a following ENTRY statement
This issue was first recognized in [0cb519d87b].
Given the code
IDENTIFICATION DIVISION.
PROGRAM-ID. "prgmain".
*
PROCEDURE DIVISION.
START-PG.
CALL "prgent".
CALL "ENT001".
CALL "ENT002".
STOP RUN.
END PROGRAM 'prgmain'.
IDENTIFICATION DIVISION.
PROGRAM-ID. "prgent".
*
PROCEDURE DIVISION.
START-PG.
GO TO END-PG.
*
ENTRY "INIT".
GO TO END-PG.
*
ENTRY "ENT001".
ENT001-START.
PERFORM PER01 THRU END-PER01.
GO TO END-PG.
*
PER01.
CONTINUE.
END-PER01.
EXIT.
*
ENTRY "ENT002".
ENT002-START.
GO TO END-PG.
*
END-PG.
EXIT PROGRAM.
*
END PROGRAM 'prgent'.
and a run with COB_SET_TRACE=1 cobc -xjg -ftrace prge.cob shows
Source: 'prge.cob'
Program-Id: prgmain
Program-Id: prgmain Entry: prgmain Line: 5
Program-Id: prgmain Paragraph: START-PG Line: 5
Program-Id: prgent
Program-Id: prgent Entry: prgent Line: 18
Program-Id: prgent Paragraph: START-PG Line: 18
Program-Id: prgent Paragraph: END-PG Line: 38
Program-Id: prgent Exit: prgent Line: 38
Program-Id: prgent Entry: ENT001 Line: 5
Program-Id: prgent Paragraph: ENT001-START Line: 25
Program-Id: prgent Paragraph: PER01 Line: 29
Program-Id: prgent Paragraph: END-PER01 Line: 31
Program-Id: prgent Entry: ENT002 Line: 31
Program-Id: prgent Paragraph: END-PG Line: 38
Program-Id: prgent Exit: prgent Line: 38
Program-Id: prgent Entry: ENT002 Line: 5
Program-Id: prgent Paragraph: ENT002-START Line: 35
Program-Id: prgent Paragraph: END-PG Line: 38
Program-Id: prgent Exit: prgent Line: 38
There are too much entry points "executed", because the implicit return call used for PERFORM and PERFORM THRU is only generated at the start of a new procedure (section/paragraph) [which is also needed for "EXIT SECTION"/"EXIT PARAGRAPH" to work correctly], while it should be generated at the explicit end of the procedure.
The temping solution of creating it additional at the end of the "EXIT" statement can break the lax handling of the rules "must be the only statement in the sentence/procedure". [This also shows that we may need to test how MF and ACU handle it if there are statements after this in the same sentence.] ... and it also breaks SQ21A and ST133A for reasons to be analyzed.
Insights/patches welcome.
Note: outside of bad tracing results and minimal overhead this should have no effect on the program execution.
Related
Bugs: #901
Discussion: 0cb519d87b
Discussion: Help for migration MF/Adabas -> GC/Adabas
This may be easier to fix if GNU COBOL handled PERFORM .. THRU similar to how IBM and MF handle it. In particular, GNU COBOL appears to build a stack of return values, so that for sequential paragraphs A, B, C, if you 1. PERFORM A thru C, and through conditional branching inside of, say B you also 2. PERFORM A thru C, it will stack those up and at the end of C first return to the statement after 2, then to the statement after 1 the next time you reach the end of C. IBM doesn't do that; it overwrites whatever was there. So, if you 1. PERFORM A thru C, and inside B you 2. PERFORM D thru F, and inside E you GO TO C, at the end of C it will return control to the line after 1, but if later you GO TO F, it will return control to the line after 2 at the end of F. In other words it's a list, not a stack, and that list is live until you either get to the end of the set of paragraphs, or you exit the program or subprogram. The only way you can re-enter a paragraph while a perform is still active is if the list of paragraphs you are performing is different (and overlaps can't be A thru C and B thru D for example; they have to end on the same paragraph or sooner).
Thank you for the note, but that won't help here, this is a different issue.
Still, you may be interested in the following from
cobc --help:-fperform-osvsexit point of any currently executing perform is recognized if reachedLast edit: Simon Sobisch 2023-09-11
Thanks, that works as expected.
On Mon, Sep 11, 2023 at 12:29 PM Simon Sobisch sf-mensch@users.sourceforge.net wrote:
Related
Bugs: #901
Discussion: 0cb519d87b