ILE: Decisions, Decisions, Part 2

August 10, 2011 Susan Gantner

In an earlier tip, I explored questions I often hear about binding directories. In this tip, I’ll explore another commonly asked ILE question and give you my perspective.

Question: How many service programs should I have and how big should they be?

Answer: It depends.

Don’t you hate that answer? But in this case, I do think it is completely application dependent. Often when I am asked this question, the emphasis seems to be related to performance. But I don’t think the decision on the “what” or “how much” to put into a service program should be made based purely on performance. These days, developer time is a far more valuable commodity than system performance. So organizing callable functions by some logic that makes them easier for developers to find and use is far more important than how they perform at run time. That said, for those of you who still have performance concerns, here are a few thoughts on the subject.

First, a service program is activated in each user’s job all at once, not one procedure at a time. So that’s why it would be best to have more than one service program–at least assuming you have more than a handful of service program procedures. It is always best not to activate more code than is necessary. In other words, avoid activating lots of code that will never actually be used in that job.

On the other hand, once the service program is activated, it typically stays around for a long time. In other words, it doesn’t need to be activated for each program or application that uses it, so you don’t pay the “cost” of activating a service program over and over in a job unless, of course, you keep reclaiming the activation group the code runs in.

It may also be important to understand what “activation” of a service program (or for that matter, a program) entails. It does not mean that the code begins to run; no files are opened, for example, as part of the activation process. However, the static storage necessary to run the code is allocated in the user’s job. The more static storage the program or service program uses, the longer the activation time. This kind of begs the question: How much static storage do my service programs need?

Assuming that–like most shops doing ILE–your service programs are made mostly of RPG subprocedure code vs. RPG code not surrounded by P specs, then the answer is that most likely your service programs use relatively little static storage. Since, by default anyway, local variables in a service program do not use static storage, shops that use mostly subprocedure code with local variables will have little static storage in their service programs. Global data in modules with subprocedures (including both globally defined files as well as global D specs) always use static storage. So if your service program procedures use a lot of global data, they will take a bit longer to activate.

But far more important than activation time is the time it takes a developer to find a service program procedure to use in their code. Or, worse yet, the time they waste re-writing the code because it was too cumbersome to locate a function that already exists. somewhere.

That’s why my answer to the original question is: It depends. It depends on what organization of the code works best for the developers who are the most likely consumers of the reusable code in the service programs. After all, the only reason to put code into service program at all is to make it easily reusable.

For another perspective on this subject, take a look at words of wisdom from IBM‘s RPG architect, Barbara Morris, including advice on how to determine how much static storage your modules use.

I’ll address other frequently asked ILE questions in future tips.

Susan Gantner is half of Partner400, a consulting company focused on education on modern programming and database techniques and tools on the IBM i platform. She is also a founding partner in System i Developer, a consortium of System i educators and hosts of the RPG & DB2 Summit conferences. Susan was a programmer for corporations in Atlanta, Georgia, before joining IBM. During her IBM career, she worked in both the Rochester and Toronto labs, providing technical support and education for application developers. Susan left IBM in 1999 to devote more time to teaching and consulting. Together with Jon Paris, she now runs Partner400, and appears regularly at many technical conferences, including System i Developer’s RPG & DB2 Summit. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page.