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




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  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.