Provide full backwards compatibility in free-form calculations

The free-form enhancements are a dramatic advancement for the language, but they are not fully backwards compatible with existing fixed-form RPG programs. If we want customers to modernize their existing code, there must be a seamless way to provide for that transition. The differences seem to be arbitrary in some cases, which make it impossible to automatically convert fixed-form to free-form without manual intervention and review.

Please provide some kind of "backwards compatibility switch", through a CRTRPGxxx parameter or GENLVL or possibly some kind of markup in the generated source or whatever you think would provide the best solution to the problems described below:

Different BIF indicator behavior (high)
Numeric overflow/truncation behavior (critical)
Language changes (medium)

%Check (or %CheckR) BIF, does not update the %Found indicator (unlike the CHECK/CHECKR opcodes)

BIF %Scan does not update the %Found indicator (unlike the SCAN opcode)

%LookUpXX (or %TLookUpXX) BIF, used to convert the operation code LOOKUP, does not update the indicators %Found and %Equal.

Maybe you could add an EVAL extender like EVAL(I) that would set those indicators in a compatible way?
EVAL(I) x=%LOOKUP(value: array);


Most critically, numeric truncation/overflow works differently in free-form code (and causes a run-time error) – in fixed-form code these overflow conditions are automatically monitored for and ignored:
Z-ADD, Z-SUB, PARM (when factor 1 or factor 2 are specified)
ADD, SUB, MULT, DIV

Maybe you could simply add a new extender for "overflow management" something like EVAL(O):
EVAL(O) val = x * .01;

...and/or add a new value on the CRTxxxRPG parameter TRUNCNBR like (*ALL) e.g. CRTBNDRPG TRUNCNBR(*ALL) would do numeric truncation just like the default *YES does for fixed-format specifications.



And then finally, some fixed-form code is simply much more clean/elegant than the corresponding free-form code, for instance
MOVEL '123' CHAR3 3
MOVE CHAR3 PKD52 5 2

Becomes this fairly unreadable code:
CHAR3 = '123';
PKD52 = %Dec(%Subst(%EditC(PKD52:'X'):1:2) + %XLate(' ':'0':CHAR3) :5:0) / 100;

Much nicer, of course, would be something like a EVALR(V) "move" or EVALR(N) "no pad" extender {i.e. the opposite of MOVE(P)} or BIF:
EVALR(V) PKD52 = CHAR3;
Or
EVALR(N) PKD52 = CHAR3;
Or
PKD52 = %MOVE(CHAR3:PKD52);


Also admittedly, GOTO is evil, but even languages like C++ support it and is required in some cases to be fully compatible. If GOTO is not supported, at least allow labeled break/continue:

START TAG
1 DOWEQ 1
X IFEQ Y
GOTO START
Y IFEQ Z
GOTO EXIT
ENDIF
ENDIF
ENDDO
EXIT TAG

Free-form:

START:
DOW 1=1;
IF X=Y;
ITER START;
IF Y=Z;
LEAVE START; // OR LEAVE EXIT, that's kind of non-standard but ok I guess...
ENDIF;
ENDIF;
ENDDO;
EXIT:


And is there any reason we need to use a ';' at the end of an IF statement?!? That is extremely confusing, surely the RPG parser could use a different token, something like this:

IF cusno=10 THEN
cusno++;

...instead of this?!? (which implies a null execution path in every single other language in the world except for RPG)
IF cusno=10;
cusno++;