Re: Procedures, Modules, Service Programs

Birgitta Hauser wrote:

Currently Iâm using several procedures within a single module (grouped
according functionality).

To make it easy I normally create a service program for each module
(exceptionally I also bind several modules with generic names for example
Date* into a service program).

Into a program only a single module gets bound and I never export procedures
from a program module.



An colleague argues having a lot of service programs is not good, he insists
in having a single service program with all modules for the whole
application, because there will be only a single activation.

I donât like this idea, because: If I only want to use a string function for
my batch program all display and printer file and what else functions must
be activated.



I just like to know how you handle it and why.

We've tried all three. The single service program with generally
applicable methods (like AR or GL) didn't work out very well because
someone always wants to work on something that's in there. Even with
multiple modules that's been a problem because of conflicts with
copybooks, binding directories and binder language.

Multiple modules in a single service program seems to work ok if the
service program is part of a single application function, and multiple
people need to develop concurrently. I have one billing program that was
built that way. It was written by 3 different people, but that's my
area, so now nobody else wants to mess with it very much.

I find the single module, multiple related function method much easier
to control. We have several like that, and since a project usually
involves several related methods, that's worked well. Since it's easy to
have related methods call each other inside the service program, you can
expose some of the functionality, like status values by day, or value
ranges that are mainly used within the service module, but might also be
useful to external code, especially if you use an incremental approach
to removing redundant methods from multiple programs. I also find it
very helpful to construct the methods so they cache their results
internally and return cached data deterministically based on the request
arguments. That permits related methods to call each other without
concern for data retrieval and calculation overhead, really does allow a
method to be the sole source for whatever data it produces, and greatly
cuts down on the need for global data.

We use a single binding directory for application program compiles, so
that related service programs can be linked without too much regard to
exactly where the method is. Service programs that don't end up with
referenced methods are dropped by the compiler, so there's no real down
side.