|Editors:||Ted Holt||Managing Editor:||Mari Barrett|
|Howard Arner||Technical Editor:||David Morris|
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.
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.
To unsubscribe, change your email address, or sign up for any of Guild Companies, Inc's free email newsletters, visit http://www.itjungle.com. Hit the SUBSCRIBE button on the homepage and it will lead you to our online subscription system.
When you sign up for one of our e-newsletters, you can be assured that your e-mail address will NEVER be sold to an outside company.
Please see our advertising opportunities and pricing at
Or contact Timothy Prickett Morgan at
Phone: 212 942 5818
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.
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 firstname.lastname@example.org
* Email Howard Arner at email@example.com
This document may be redistributed freely and enthusiastically by email, but only in its unedited form. Thanks for your cooperation.
Midrange Guru is a registered trademark of Guild Companies, Inc. IBM, AS/400, iSeries, OS/400, and eServer registered trademarks of International Business Machines Corp. All other product names are trademarked or copyrighted by their respective holders.