| Editors: | Ted Holt | Managing Editor: | Mari Barrett | |
| Howard Arner | Technical Editor: | David Morris |
|
Volume 1, Number 10 sponsored by:Tiger Tools
|
|
|
|
|
|
How Many Modules Should Be in a Service Program? Hey, Ted: I have heard that IBM recommends limiting the number of modules in a service program to 10 to 20. The reason stated is to keep the number of static variables defined from getting too large and affecting storage in the PAG and increasing program activation time. I can see the reasoning for the activation argument but if you are creating the modules with a NOMAIN option does the static variable argument still hold? Service programs provide a way to group related procedures into a library of sorts. For instance, you might gather string manipulation routines into a service program. Still, your question is a good one. Just how many is too many? I ran your question past Barbara Morris, of the RPG compiler development team in Toronto, and this is what she told me: "Even with the NOMAIN keyword, an RPG module can have a significant amount of static storage. There are many internal control structures kept in static storage (for example the file control blocks, the exception handling information, many compiler-internal variables). Any variables defined in the main source section are in static storage. Use the Display Module (DSPMOD) command, specifying DETAIL(*SIZE) to see how much static storage a module uses. You'll see something like this:
Static storage (bytes): Breaking up a service program into two service programs serves no purpose if both service programs are always used together, so the question of "how many modules" only really applies when binding unrelated modules, and there's no particularly good reason for putting unrelated modules in the same service program. I think that the grouping of modules into service programs should be determined mainly by the function of the modules, not by some arbitrary restriction. It's an application-design problem, similar to the grouping of programs into libraries. Reducing the number of modules by putting related procedures into the same module will have a good effect on static storage, especially for RPG, since it will reduce the total number of RPG internal structures. But I wouldn't recommend a witch-hunt against static storage unless it was a problem." In addition to Barbara's recommendations, you should look at how you use activation groups. Using the Create Service Program (CRTSRVPGM) default of *CALLER is fine in pure ILE environments. If your service program might be activated in the default activation group, use a named activation group to allow the system to better manage memory usage. The ILE Concepts manual available at http://as400bks.rochester.ibm.com/ pubs/html/as400/v5r1/ic2924/books/c4156065.pdf contains a good description of activation groups. -- Ted
Subscription And Advertising Information
Subscription Information 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.
Advertising Information Please see our advertising opportunities and pricing at http://www.itjungle.com/advertising.html
Or contact Timothy Prickett Morgan at
Phone: 212 942 5818
Email: tpm@itjungle.com
|  |
|
Changing IPL Default For Applying PTFs Hey, Ted: I am reluctant to ask this question as the answer may be simple, but I have hunted high and low for a solution, to no avail. How does one change the IPL option default (Y or N) that is shown on the GO PTF, option 8 display in OS/400? Half of my eight systems are set to Y and the rest are set to N, so it must be possible to change the default. That's right. The default IPL option is Y. Use the Change Service Attributes (CHGSRVA) command, and specify *DLYALL in the PTF install type (PTFINSTYP) parameter to change the default to N. To reset the default to Y, specify *DLYIPL. The install type parameter also supports two other values, *IMMONLY, and *IMMDLY; both of these will also change the IPL option default to N, but I would recommend that you do not use either of these values. This attribute also applies to option 7 of the GO PTF menu and to the Install Program Temporary Fix (INSPTF) command. -- Ted
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 * Email Howard Arner at harner@itjungle.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.
