wrong order leads to "syntax error, unexpected INTO" (processed by citpgsql)

[GitMensch]

       IDENTIFICATION DIVISION.
       PROGRAM-ID.    TE899.
      *-----------------------------------------------------------*
       DATA DIVISION.
       WORKING-STORAGE SECTION.
      *
           EXEC SQL BEGIN DECLARE SECTION END-EXEC.
      *
       01 TABID                    PIC  9(09) COMP-5 VALUE 42.
       01 LEN                      PIC S9(09) COMP.
      *
           EXEC SQL END DECLARE SECTION END-EXEC.
           EXEC SQL INCLUDE SQLCA END-EXEC.
      *-----------------------------------------------------------*
       PROCEDURE DIVISION.
       TMAIN SECTION.
       P05R-00.
      *
           EXEC SQL
              SELECT LENGTHV FROM TAB INTO :LEN WHERE TID = :TABID
           END-EXEC.
      *
           IF SQLCODE NOT = 0
              DISPLAY "ERROR" SQLCODE
              GOBACK.
           DISPLAY  LEN.
      *
       P05R-99.
           EXIT.
      /

preprocessing results in

TE899.pco:20: error: syntax error, unexpected INTO

[mridoni]

Having a better lok at it: isn't this a SQL syntax error?

It should normally be something like:

       EXEC SQL
          SELECT LENGTHV INTO :LEN  FROM TAB WHERE TID = :TABID
       END-EXEC.

The IBM docs are quite specific on the order of the clauses and ProCOB also indicates that a INTO clause should always precede a FROM (page 490 of the ProCOB docs)

[GitMensch]

Thanks for having a look into it, retested with procob:

Error at line 20, column 44 in file TEST.pco
              SELECT LENGTHV FROM TAB INTO :LEN WHERE TID = :TABID
...........................................1
PCB-S-00400, Encountered the symbol ":" when expecting one of the following:

   , START END-EXEC CONNECT GROUP HAVING INTERSECT MINUS ORDER
   WHERE WITH FOR UNION

Which is better than the ocesql one, but actually quite similar.

The code seems to only precompile with the C*IT preparser. Rechecking that shows that it also compile with the correct order.

That leaves the questions: Do we (you) care about preprocessing it? If the answer is yes: should it be explicit be part of the parser and return a nice error message about wrong order, raise a warning and process it or process it silently?

I'm leaning towards the warning, but am also fine to say "close this as not planned".

[mridoni]

Unless it's necessary to make some pre-existing program work without too many changes, I wouldn't include it, even as a warning: it actually goes against the established syntax of two of the major precompilers/environment out there. Do we have any documentation on C*IT to check this (might also be a bug there: something is parsed while it shouldn't be)?

[GitMensch]

Agreed.