Organization

Midware Ltd.

Before you make extensive use of ILE modules and service programs, you should take some time to think through the organization of the ILE elements. If you choose not to use a binder language, you need to be a little extra careful how you organize, as adding procedures to a module will require re-binding of programs.

Organizing Procedures

The first issues you must deal with is how to organize procedures. You could choose to create a separate source member and module for each procedure. This however, would most likely create unnecessary overhead.

For example, lets say you have 10 procedures the access the same file - lets say your customer master file. If these procedures are each compiled into their own module, and you have a program that uses all 10 procedures, your job will open 10 different access paths for the same file. You could use shared open data paths and activation groups to solve this problem, but this will require even more pre-planning.

Instead, one option you may want to consider is to create a separate source member for each unique combination of files used by a procedure. One source member would be used for procedures not requiring any files.

This is kind of a no-brainer approach but, depending on the complexity of your individual environment, it may meet your requirements. The major potential problem this presents is that if you don't use a binder language when creating and updating service programs, a new procedure added to a module will change the service program's signature. All programs using that service program would then need to be re-bound.

Organizing Service Programs

Once you've decided how to organize procedures in modules, you need to then decide how to organize modules in service programs (assuming you'll be using bind-by-reference rather than bind-by-copy).

One mistake to avoid is to use one module in many service programs. This architecture compromises the ease of maintenance. If we do this, we may as well just bind the modules directly to the program without using service programs.

It's generally a good idea to use a module in only one service program. This way, when the module changes, you can simply use either CRTSRVPGM or UPDSRVPGM to update the one service program and you're in business.

Now, how many modules should we include in a service program. There are two lines of thought, and there is really no right answer.

One opinion is that all modules should be combined into one, or a limited number of service programs. The main advantage to this method is the simplicity of maintenance and creating programs. If you have multiple AS/400's, you only need to distribute one object. When creating programs, you could change the default of the CRTPGM and UPDPGM commands to automatically include the service program(s).

The main disadvantage to binding many modules to one service program is that if the signature does change, you have many more programs to recompile/rebind. This is always a problem, but it is a bigger consideration if you aren't using a binder language.

The other school of thought is that there should be a one-to-one relationship between a service program and a module. This way, if a service program signature changes, you only have to rebind the programs that use that module.

The main disadvantage to this method is that when we are creating a program that uses procedures from the service programs, we need to give thought to which service programs to bind it to and type each of those in manually. This makes the program creation process more cumbersome than it needs to be.

There is a solution to this however, which in my opinion makes the second method preferable.

Back to Service Programs

Next to Binding Directories

Last Modified: September 05, 2000