Re: RSE LPEX CL editor problems

Hi Vern,

Let me see what I can do for you.....

First of all, prior to V5.0 the prompter used by the RSE was that shipped
in the iSeries toolbox, and as you mention the WDSC team had no control
over it.
As of 5.1, the prompter was ported over to eclipse and is now owned by the
WDSC team, and at this point me :-)

1) This is true - for now. (see  response to #3)

2) An easily reproducible bug - which I will fix - hopefully for our next
service.

3) This is true.  The original prompter was not designed to prompt in
source, which is why those fields are missing.  Once ported the design flaw
remained.
his is definitely a to-do on our list.  I will add your vote to help us
prioritize.
Once Label and Comment are added, then it will make sense to prompt
commands with no parameters, and that "check" will be removed.

4) Agreed - sometimes things are too optimized. I will fix this - hopefully
for our next service.

5)  An easily reproducible bug - which I will fix - hopefully for our next
service.

5) (but really 6)  This one is not a prompter - but rather a parser
problem. An easily reproducible bug - which I will fix - hopefully for our
next service.

I hope this helps.

Violaine Batthish
WebSphere Development Studio Client, IBM Toronto Lab




wdsci-l-bounces@xxxxxxxxxxxx wrote on 25/08/2004 09:44:58:

> I have an open PMR about problems with the WDSC RSE CL editor. I like the

> new formatting controls, but there are some irritations and a couple real

> gotchas. Here's what I've found, for all your consideration. See whether
> you get the same results, and, if so, submit a defect report with your
> examples. Somehow the function of the parser of SEU is not getting
> duplicated properly. Someone, please look at THAT code again and see how
> things are done correctly. I mean, this is 20+ year-old code - it works!
>
> I believe I was told when I'd submitted a similar report, that the
prompter
> is from some source other than the WDSC team and is not under their
control
> - or something, unlike the CODE prompter. All I have to say is, this
> dependency on, I believe, open source is not sufficient here.
>
> I've not tried these things in CODE - I leave that as an exercise for
those
> who have no life.
>
> ================================================
> 1. Commands that have no parameters (ENDPGM, e.g.) cannot be prompted.
>
> 2. The prompter says that the following needs a variable name in the VAR
> parameter:
>
> CHGVAR VAR(%BIN(&RCVRLEN)) VALUE(60)
>
> This command is completely valid - the prompter needs to handle valid
> expressions in cases such as this.
>
> 3. Comments and labels are not displayed in the prompt, as they are in
SEU.
> The promise of WDSC is to do better than SEU - this is lost
functionality.
>
> 4. In a prompt in SEU, if I type any character of a default value, it
> becomes part of the command. This does not work in jLPEX - if I prompt
the
> SBMJOB command, which has *NO as default for LOGCLPGM, I may want to
> specify this value, even though it is the default on my system, because
it
> might not be the default on another system where our software is
installed.
> However, typing in the value in the prompt does not add it to the command

> string at the bottom. It DOES work if I type it into the source text, but
I
> believe I should be able to do this while prompting.
>
> 5. The statement below is a valid CL statement. Prompting in SEU handles
it
> properly. The jLPEX syntax checker passes it. But the prompter reports an

> error, that COND is an invalid keyword.
>
> ELSE IF COND(%BIN(&PERIOD 1 2) = 2) THEN(DO)
>
> BTW, I am using WDSC for iSeries 5.1.2
>
> 5. Another error showed up, but with automatic formatting, not the
prompter
> per se:
>
> This source, which is valid
>
> dspobjd qsys/*all *lib +
>          output(*outfile) +
>          outfile(qtemp/qadspobj)
>
> got changed to
>
> dspobjd    qsys /* all *lib output(*outfile) outfile (qtemp/qadspobj)
> */
>
> Note that the "/*" was interpreted as the start of a comment, and the end

> comment "*/" was added. However, this is incorrect.
>
> Turns out it is related to prompting - if I prompt the first item, it has

> already changed the statement as indicated above.
> ================================================
>