× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I decided to try the LPEX editor again in 5.1.2.4 instead of CODE for CL
after a past of problems.  I was starting an "IF" statement and prompted.
Then started typing the condition so it would look like "IF COND(&WRITEFILE
= 'Y') THEN(DO)".  Well, I was able to type the variable but then I could
not type anything past the space.  So, I experimented with 8 characters for
the variable name instead of 9 and that worked.  Any variable over 8
characters did not work.  Once the condition was entered I could go back
and increase the size of my variable length.  I was just about to post
about this problem wondering why it was not discovered and I quickly came
to this recent post.  It was not surprising to me and it makes me wonder
how many people actually use the LPEX editor for CL.  I will try using the
LPEX editor for CL more often so I can be a guinea pig but how do we know
the problems already discovered?  I hate to bother IBM with a problem if
they already know about the problem.  Given the statement that there are
many problems with the CL prompter, how do we decide which ones to complain
about?

Craig Strong

Vern wrote:
There are a lot of problems with the CL prompter. Some were caused by
5.1.2.4. Others, like this one, just don't work. Better than SEU? NOT!

Yet, the developers are aware of some of these things. The prompter
originated as a command-line prompter, not a programming prompter with
variable names and expressions - I dare you to put something in with *CAT
-
and something as simple as

dcl &varname *dec (9 0)

does not get through the prompter correctly. These are things that are
second-nature in SEU, and the fact they don't work here makes this a tough

sell.

BTW, if there are no parameters on a command (such as ENDDO), you cannot
prompt it. Sheesh! And there are several cases where prompting does not
capitalize things that are not in quotes - not even *CAT operators, e.g.
Again, please give us something as good as SEU - this ain't it yet! Either

do it everywhere (as SEU does) or not at all.

I rant - all you developers have heard me before - I bet you won't get the

time you need to really make this work. More's the pity. But maybe you can

point out to the money folks that IBM has all this hype and promise, and
that this, at least, does not live up to the promise - IMO, anyway.   ;-)

Vern

At 12:25 PM 5/9/2005, you wrote:

>Reading along with the new wdsc redbook, I'm trying out the cl formatter.
>I prompted a cmd and realized that the variable name can't be longer than
>the length of the PARM on the command!  And, that the variable name can
be
>as long as the PARM - i.e. over 10.
>
>Guess I'll skip to the next chapter.
>
>Version: 5.1.2.4
>Build id: 20050104_2139
>
>Phil


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.