• Login
• Become a member
• RSS
• Part of the TechTarget network

Ron Turull

Way, way back, when the news was filled with the upcoming release of OS/400 V2R1, a program manager at IBM told me that IBM already knew how to optimize programs "up the wazoo," they just didn't have the right environment on the AS/400 yet to implement it. That right environment that the IBMer was referring to was ILE, which we got a few years later. Since then we have been able to reap the rewards of program optimization. If you're not using it, now is the time for administrators to consider it, especially if your system is getting sluggish.

How to optimize your programs

Programs are optimized using the ILE optimizing translator. Access to the optimizing translator is provided by the OPTIMIZE parameter of the CHGPGM, CHGMOD, CHGSRVPGM, and the various ILE create module and create bound program commands (e.g., CRTRPGMOD and CRTBNDRPG).

Optimization is done at the module level. (That is why there is an OPTIMIZE parameter on the CHGMOD and CRTxxxMOD commands.) Each module is optimized as a separate entity with no cross-module optimization taking place. (There is a way to do inter-module optimization, but that is the subject of another article.) When an entire program is optimize (e.g., using the CHGPGM or CHGSRVPGM commands), every module in the program is optimized, but they are still optimized at the module level. That flexibility gives you the ability to optimize some modules in a program while keeping others intact, or optimizing different modules at different levels.

More Information Getting up to speed on ILE commands Best practices for tuning DB2 UDB v8.1 Let the system tune itself based on your business rules

Three basic levels of optimization

There are three basic levels of optimization from which to choose:

1. *NONE. No optimization is done, except for what is necessary in order to translate the module.
2. *BASIC. Some basic optimization is done, but more dramatic optimization -- optimization that can (in very rare instances) cause program errors -- is not performed.
3. *FULL. All optimization techniques are applied. While this optimization level produces the fastest running code, it can also, in rare circumstances, cause programs to fail (see The price of optimization below). There is a fourth level of optimization, but in addition to doing everything that *FULL optimization does, it simply disables trace data.

The chart below shows an example program optimized at these three different levels and the affect it has on the program run-time performance and object size. It should be noted that while this example shows object size decreasing with increased levels of optimization, sometimes that is not the case; object size often increases as higher levels of optimization are applied.

The price of optimization

Program optimization comes at a price. The price of optimization is made up of three factors: increased object size (sometimes), debugging difficulties and program errors. The following describes each and gives you some tips to lessen their effect.

Increased object size. Frequently the optimizing translator has to add some code to your program in order to optimize. While the optimizer will delete frivolous code, the code it adds often outweighs this and the net effect is a larger object. However, the increase is generally very small, and on most systems this cost is negligible.

Debugging difficulties. Even at the *BASIC level of optimization, the ILE optimizing translator often has to rearrange code. This can cause problems when debugging an optimized program. For example, a variable may not yet have the expected value when displayed at a certain breakpoint if the code that changes that variable has been rearranged (i.e., placed in a more strategic spot). Additionally, changing the value of a variable under debug may cause unexpected results, such as cause the job to end abnormally. There are two ways to overcome that obstacle:

1. Thoroughly test your code in a production environment before optimizing it, minimizing the probability of having to debug it after it has been optimized.
2. Un-optimize the program by either using the CHGPGM specifying OPTIMIZE(*NONE) or by recreating the program/modules. A variation of this is to debug an un-optimized copy of the program.

Program errors. In rare instances, programs optimized with *FULL can fail during run-time with message MCH3601. That is caused by the optimizer rearranging how arrays are processed in a loop. Worst of all, though, is that this error is not consistent; it may occur one time the program is executed and not the next. Take heart, though, because this error is very rare to non-existent (i.e., we haven't heard of any problems yet) in RPG and COBOL because of the way these compilers handle arrays and because array processing is not as common in these languages as it is in languages such as C (where this problem most frequently occurs). One way to avoid the problem is to increment array indexes at the end of the loop. Besides, this is better programming practice anyway.

-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.