|
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.
As an Amazon Associate we earn from qualifying purchases.
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.