RE: OPTIMIZE(*FULL)

Attached is the QuickGuide to IBM Tech Support.

albartell@xxxxxxxxx 1/8/2007 5:38:31 PM >>>

Then tried it with OPTIMZE(*FULL):

        DSPLY  0001
        DSPLY  0001

Oops! 

[wiping sweat from forehead] Well, I guess I can thank the Big Guy upstairs
for the error that is occurring, because who knows what else would break
once on another system! Yikes!  I am so glad this code didn't make it into
production [another brow wiping]

Time to write in the good ol' blog about this one :-)

Anybody know what I need to open an PMR for this?  I think I just need to
know the phone number, serial number, and my customer number, correct?
Seems like I only do this once, maybe twice, a year and I always forget.

Thanks,
Aaron Bartell

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] 
On Behalf Of Simon Coulter
Sent: Monday, January 08, 2007 4:13 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: OPTIMIZE(*FULL)


On 09/01/2007, at 6:53 AM, albartell wrote:

Calling xyzProc when it is compiled with OPTIMIZE(*NONE) or
OPTIMIZE(*BASIC)
works just fine and all variables have values as expected.  When I 
recompile to OPTIMIZE(*FULL) I get the value of pParm3 in pParm2 (even 
though
pParm2
is passed literally!!!!)

Looks like I am not the only one having the problem :-( 
http://archive.midrange.com/rpg400-l/200112/msg00617.html 
http://archive.midrange.com/rpg400-l/199711/msg00004.html 

These appear to refer to debug differences. Your problem seems to be more
fundamental.

Anybody have a fix to this problem other than "don't use *FULL"?

I played about with this for 10 minutes. I modified your example to DSPLY
the contents of pParm2 and pParm3 inside xyzProc.

Ran it with OPTIMIZE(*NONE) and worked as expected:
        DSPLY  yyyy
        DSPLY  0001

Then tried it with OPTIMZE(*FULL):
        DSPLY  0001
        DSPLY  0001

Oops!

I initially thought your problem might be due to not referencing pParm2 so
it gets "optimized away". Might look weird in debug but not really a problem
if it's never properly used. Nope.

Then I changed VALUE to CONST and ran with OPTIMIZE(*FULL)
        DSPLY  yyyy
        DSPLY  0001

Hmm, working as expected. I would never experience this problem because I
only use VALUE when prototyping C functions. I don't use it in my own code
because I dislike that it allows the value of a variable to be changed even
though that change will not be reflected in the caller. 
CONST is more obvious.

However, even though you have a work-around by specifying CONST this still
seems broken so an APAR is in order. Report it and either get it fixed or at
least get an explanation why it's working as designed.

NOTE: There is a difference between running with OPTIMIZE(*FULL) and
debugging with OPTIMIZE(*FULL). Debug can show erroneous values in this case
and that is expected and documented. However, running should produce the
same results even if the executed code path is somewhat different.

Regards,
Simon Coulter.
--------------------------------------------------------------------
    FlyByNight Software         AS/400 Technical Specialists

    http://www.flybynight.com.au/ 
    Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
    Fax:   +61 3 9419 0175                                   \ /
                                                              X
                  ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------


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