Hey, Ted:

Are there any guidelines or rules of thumb regarding optimization of programs? I know you lose some debug functionality when you optimize, but other than that, why not optimize all programs?

That's a good question. During development, you need accurate debug information. Optimization makes debug almost worthless because you can't depend on the values of variables. At some levels of optimization, you can't change a variable's value. Other levels of optimization allow you to change the values of variables, but doing so is risky.

When a program goes into production, debugging should be behind you. Can you tell you're talking to an optimist here? At that point, you should optimize the program so that you may get better performance.

I asked a couple of IBMers about this point, and they were both adamant that there is no good reason not to optimize programs. You have nothing to lose and better performance to gain. Make it a standard in your shop to optimize a program when placing it into production.

The easiest way to optimize a program, or at least my favorite way, is to use the Change Program (CHGPGM) command, specifying OPTIMIZE(*YES). The system performs the maximum possible optimization on the program, regardless of whether it is an OPM or ILE object.

Other commands also have optimization parameters.

CRTRPGPGM GENOPT(*OPTIMIZE)
CRTBNDRPG OPTIMIZE(*FULL)
CRTRPGMOD OPTIMIZE(*FULL)
CRTCBLPGM GENOPT(*OPTIMIZE)
CRTBNDCBL OPTIMIZE(*FULL)
CRTCBLMOD OPTIMIZE(*FULL)

Create CL Module (CRTCLMOD) and Create Bound CL Program (CRTBNDCL) also have an OPTIMIZE parameter, but it is of no value. The compiler ignores the OPTIMIZE parameter because CL modules and programs cannot be optimized. I assume it was included for some sort of compatibility with the syntax of other program-creation commands.

-- Ted

Hey, Ted:

We have an RPG program that includes a control break on company number. My boss asked me to change it so that it would build a separate spool file for each company. That lets us send each company's data to the appropriate person.

I modified the program to open the printer file before processing a new company and to close it when finished with that company. So far so good. Our problem is that now the program produces a bunch of indistinguishable spool files. A human being has to look at each one to see which company's data it contains before changing it to the output queue of the intended recipient. Is there a better way?

You've done well, and you're almost there. There's one thing you lack, though. You must add an override to the RPG program.

You didn't tell me some things, such as whether you're using RPG III or IV, whether the program uses the cycle to handle the control breaks or includes its own break-handling logic, and whether the printer file is externally described or program described. None of that matters, because the principle is the same. It's just that I can't make my example match your program. So adapt accordingly.

You have two good ways to distinguish the spool files--by spool file name or by user data. Of course, there's no law that says you can't use both, but that would be unnecessary.

Use an Override with Printer File (OVRPRTF) command and fill in either the SPLFNAME or USRDTA parameter with some value of up to ten characters that defines the data. Here are program fragments from an example in RPG IV.

 * Working variables
D ovr             s            128                     
D SplfName        s             10                     

 * prototype for QCMDEXC
D qcmdexc         pr                  extpgm('QCMDEXC')
D   cmd                        128    const            
D   cmdlen                      15p 5 const            

 * do this before processing a company
C                   exsr      override    
C                   open      custreport  
 * calcs to produce the report go here
 * 
 * do this after processing a company
C                   close     custreport  
C*** build and execute the override command
C     override      begsr                                                 
C                   eval      SplFName = 'COMPANY' + %char(company)       
C                   eval      ovr = 'OVRPRTF FILE(CUSTREPORT) SPLFNAME(' +
C                             SplfName + ')'                              
C                   callp     qcmdexc (ovr: %len(ovr))                    
C                   endsr                                                 

In this example, the control break is on the field named COMPANY. When the program finds the first record for a company, it loads the desired spooled file name into variable SPLFNAME. This variable assumes values such as COMPANY1, COMPANY2, etc. Then it opens the printer file, CUSTREPORT, and processes the company's data. After it has processed all records for the company, it closes the printer file.

When you look at your spool files, either with a green-screen command or with Operations Navigator, you will see immediately that each company has its own report.

One reason that I prefer to override the spooled file name rather than the user data is that commands like Copy from Spooled File (CPYFRMSPLF) access reports by spooled file name. If I were to place the identifying information in the user data, it would be more difficult to programmatically manipulate the spooled files.

-- Ted  

SPONSORED BY ASNA ARE YOU AN RPG PROGRAMMER? Do you want to use your existing RPG skills to build powerful Windows, Web, and Wireless apps that easily access your AS/400-iSeries and Windows NT/2000 data? Download your FREE trial of ASNA Visual RPG (AVR), including a helpful "Smarties" tutorial to get you started. Visit the ASNA Web site for seminar info and to download your free trial today: http://www.asna.com/downloads.asp.

One of the great things about the OS/400 community is that it is indeed a community. We may be all working from our cubicles, but we are all connected and trying to figure out how to best employ the computer technology at our disposal. There are more than a few ways to skin any cat, and if you have a clever and unique answer to a problem that one of our Midrange Gurus has solved, we'd love to hear from you. This newsletter is an open dialog, and we value your input as well as your readership.

It goes without saying--but we'll say it anyway--that your hard technical questions pertaining to real world problems are equally valuable as a foundation for this newsletter as are your programming insights. We hope you find all the editions of Midrange Guru valuable, and we are going to work hard to make sure that they are.

If you have a tough problem, our gurus can probably help. Their mailboxes are always open.

* Email Ted Holt at tholt@itjungle.com