× 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.



According to Hans, this code isn't correct anyway:


> > For instance:
> >
> > If a = b
> >   dow *in90
> >      if java = 'slow'
> >        select
> >        when slow = 'reallyslow'
> >            eval Variable = %trim(%char(Custno)
>                                   + ':'
>                                   + %trim(CustFName)
>                                   + %trim(CustLName)
> >        endsl
> >      endif
> >   enddo
> > EndIf


Hans has indicated that there needs to be a semicolon at the end of
EVERY statement, including DOW *IN90 and the IF A=B

If a = b;
  dow *in90;
     if java = 'slow';
       select;
       when slow = 'reallyslow';
           eval Variable = %trim(%char(Custno)
                                + ':'
                                + %trim(CustFName)
                                + %trim(CustLName);
       endsl;
     endif;
  enddo;
EndIf;


Horse sh*t syntax if you has me, but I'm holding back. :)

And why isn't the semicolon allowed on the older "fixed" form EVAL
opcode in the Extended Factor 2? In other words, why does this fail?

C             EVAL       A = B * C;

But this doesn't:

   eval a= b*c;


Habitually, the semicolon is entered at the end of an expression. Why
require it in /FREE after an expression and PROHIBIT it at the end of an
expression in the regular syntax? It should be an optional symbol in the
regular syntax extended Factor 2 for the EVAL and CALLP opcodes.

It should be optional after conditional statements and after the ENDxx
statements.

But this is just part of a bigger issue. There is very little
consistency in new features implemented in the RPG IV language.

We have: EXTBININT(*YES | *NO)
And yet we have: OPENOPT(*INZOFL)

.....H EXTBININT  OPENOPT(*INZOFL)
.....H EXTBININT(*YES)  OPENOPT(*INZOFL)
.....H EXTBININT(*NO)   OPENOPT(*INZOFL)

Its not like there are other open options for print files on the header
specification.  This probably should have been a file-level keyword, but
that debate was not something I participated in, so I'm sure they
decided that a program/module-level setting was more useful. I can
accept that. But then it should have just been an on/off switch, so
using their current syntax, the keyword might have been: INZOFLIND(*YES
| *NO)

Another one is the ON-ERROR opcode. Why is there an embedded dash? To
make it stand out? Or was it a COBOL compiler developer that built that
opcode? <vbg>

And this is just the beginning.

Bob




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.