Re: NOOPT D-Spec keyword

Hans,

I must admit that your email is way over my head and it's very possible I'm
not at all on the same page with you.  But is the situation you are
describing responsible for some bizarre behavior I recently saw?

Just before distribution, I always create my WRKDBF objects (RPG ILE and CL
ILE, no OPM's) with *FULL optimization.  And then I remove observability.
The idea being to make the objects as small and as efficient as possible.

When I tested out everything I started seeing blanks, zeros, and other
strange values in fields that I knew were not.  After scratching my head
for a long while, on a hunch, I recreated everything with optimization
*BASIC.  Magically (and mysteriously) WRKDBF started behaving properly and
showing field values accurately.

I may never use *FULL optimization again after this.  Is this soemthing
that is "known" behavior?  Or I am just not understanding optimization?

Bill




                    Hans Boldt
                    <boldt@ca.ibm.com       To:     rpg400-l@midrange.com
                    >                       cc:
                    Sent by:                Subject:     Re: NOOPT D-Spec 
keyword
                    rpg400-l-admin@mi
                    drange.com


                    06/18/2002 09:26
                    AM
                    Please respond to
                    rpg400-l






David & Eileen Keck wrote:
> I was doing a little light reading in the RPG IV reference and came
across
> the NOOPT d-spec keyword, which befuddles me.  It says we should always
> specify NOOPT when prototyping for an OPM RPG program ... that problems
with
> data currency "could" occur if it's not used.  It also says that "some"
data
> may not be "current" during exception processing unless NOOPT is
specified.
> This keyword is defined in the manual without respect to any optimization
on
> any CRT* commands.  This all seems very cloudy ... can anyone clear this
up
> for me ?  Thanks - Dave K.

The RPG IV Reference is "light" reading?

The key words regarding this particular keyword (and optimization in
general) are "may" and "might".  First, I wouldn't worry about it
much unless you're compiling your modules with optimization levels
higher that *NONE.  Second, I wouldn't worry much about using NOOPT
unless some variable used in the *PSSR or an INFSR does not have the
value you know it should have.  Thirdly, if your application does a
lot of I/O, I wouldn't worry much at all about using optimization
levels higher than *NONE.  Analyzing and optimizing your I/O logic
will always pay off better than bumping up the optimization level in
the compiler.

Why might some variable not have a "current" value?  There are a lot
of possible optimizations that an optimizing back-end can do.  One
example is that if a value intended to be assigned to some variable
is in a register, the back-end can refer to the value in the
register instead of the value in the variable.  The back-end can in
some cases defer the assignment of the value to the variable to a
point where the back-end knows the value has to be actually
contained by the variable.  But if an exception occurs in the
mean-time, the value in the register would be lost.  But considering
how pessimistic the RPG front-end is regarding optimization, I'm not
even sure if this situation would ever crop up in practice.  But in
case you do run into trouble with an unexpectedly aggressive
optimization, you do have the option to tell the optimizer to lay
off a particular variable.

Cheers!  Hans

BTW, for light reading, try a Terry Pratchett novel instead.



_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





--

NOTICE:  The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential.  If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
corrected.