RPGIV @ Work

A unique site for RPG and System i Lovers

Welcome!

Hi, this site will provide all what you need in System i and RPG developments.

My Name is Chamara Withanachchi, System i Expert and RPG Developer. And in the field for last 11 years.

I hope you will find lot of valuable information from this site

Optimization and Debugging Problems Print E-mail
User Rating: / 1
PoorBest 
Written by Chamara Withanachchi   
Optimization and Debugging Problems

This tip originally appeared on: Bryan Meyers's Web site


When you optimize a module, the system streamlines the module to make the runtime performance as fast as possible. But optimization can have adverse side effects when you are debugging the program or service program.


Optimization may rearrange or eliminate some statements altogether. Consequently, field values presented by the debugger, as well as breakpoints and step locations, may be inaccurate. Optimization will also affect the accuracy of the DUMP operation and error handling routines (e.g., Monitor groups, *PSSR and INFSR subroutines).


There are three levels of optimization, set by the OPTIMIZE keyword in H-specs (or in the CRTRPGMOD and CRTBNDRPG commands):


OPTIMIZE(*NONE) is the default value. The compiler performs no optimization on the code. This option allows you to debug the program accurately, with the debugger presenting correct current field values.


OPTIMIZE(*BASIC) performs some optimization on the compiled code. The debugger will let you display variables, but the displayed value may not be the current value. The debugger will also allow variable changes, but you may encounter unexpected results if you try to use the changed variables.


OPTIMIZE(*FULL) generates the most efficient code -- and the compile process also takes longer. The program should run faster than with either of the other two options. The debugger will let you see (but not change) field values; but the debugger may not show you the correct current field values.


Optimization works best with call-intensive programs; it does not improve the performance of file I/O. In rare cases, optimization may actually make the program slower. I usually just leave the default OPTIMIZE(*NONE).


If you do choose to optimize, some data items can "opt out" of the optimization process; use the NOOPT D-spec keyword to prevent optimization of those data items that you do not want to optimize. Using this option will cure the innacuracy problem (for those data items only).


The DSPMOD, DSPPGM, and DSPSRVPGM commands will show you the current level of optimization for an object. You can change optimization levels with the CHGMOD, CHGPGM, or CHGSRVPGM commands; these commands support the levels already discussed, but also add other options:


OPTIMIZE(*NONE|*NO|10) -- These options are equivalent, and are discussed above. OPTIMIZE(*NO) is used only by the CHGPGM command.


OPTIMIZE(*BASIC|20) -- These options are equivalent, and are discussed above.


OPTIMIZE(*FULL|30) -- These options are equivalent, and are discussed above.


OPTIMIZE(*YES|40) -- This is the highest possible optimization level. In addition to all level 30 optimization, level 40 optimization prevents call and instruction tracing. OPTIMIZE(*YES) is used only by the CHGPGM command.


<Previous   Next>