Re: WDSc LPEX structure-nesting bug - has this been fixed?

I've never seen this one, but that's because I don't usually separate the exec sql from the first SQL statement. If you combine lines 3 and 4 below to "exec sql select col1" then c-m and c-s-o both work fine. Unfortunately, the code you show below still confuses the parser. I guess the "select" being the first word on the line is the issue.

Joe

Buck mentioned this "issue" on this list in March 2009, but I found no
follow-up. If an SQLRPGLE source member has an imbedded SQL select
within an "if" structure, attempts to identify the structure nesting
yield unsatisfactory results.


My workstation has WDSc at V 7.0.0.8 (7.0.0.20090225_1508) with Interim
Fix V 001 (7.0.0.8_20090312_1000)

Our i is running v5r4, but will be on 6.1 in a couple weeks.


Specifically, if in my silly source member shown below, with my cursor
on the outer "endif" on line 13, I press Ctrl+M, I expect to see lines
2-13 selected. The block gets confused by the sql "Select" (no, there
will be no "endsl" so don't look for one) and shows only lines 4-13 in
the structure. Likewise, if I put the cursor on the if on line 2,
Ctrl+M won't play at all.

The other block nesting aide (shift-Ctrl-O) misbehaves the same way.

1 /free

2 if this = that;

3 exec sql

4 select col1

5 into :hostFld1

6 from TableX

7 where col2 = :that;

8 if %subst(SQLSTATE : 1 : 2) = '00';

9 this = hostFld1;

10 else;

11 that = hostFld1;
12 endif;

13 endif;

14 /end-free


Has this been fixed in a newer build of WDSc? Or perhaps I need a PTF?
Or do I need to convince the "higher powers" to spend the big bucks for
RDP to get this functionality to perform adequately?


I'd really like this to be reliable, as I maintain some butt-ugly
programs with some pretty wild nesting. Is there any hope?

Hey, while I'm dreaming, does RDP also mark the ELSE lines somehow?


Many thanks.

- Michael Koester