Re: Modules in a service program - How many is too many?

["Carel Teijgeler" <coteijgeler@xxxxxxxxx>]

Rick,

You should divide the SRVPGMs into two groups: one for application modules and 
one for common routines.

Common routines are string manuplition (upper/lower, parsing), date 
calculations and conversions, prize calculations (can be used for Payments and 
Fundings).

If you use APIs, like use spaces or user indexes, I would put those 
(sub)procedures (if you use procedures to the API-calls) in a seperate SRVPGM.

(Then the next question will be: in what activation group (AG) should those 
SRVPGMs run: in the same AG as the *CALLER, in a special AG for SRVPGMs, a *NEW 
AG? It may not seem related, but I think it is an element of the 
implemantation.)

Regards,
Carel Teijgeler. 

*********** REPLY SEPARATOR  ***********

On 18-2-05 at 15:08 Rick.Chevalier@xxxxxxxxxxxxxxx wrote:

>Based on the last two posts to the procedure name vs. production support
>thread and seeing this theme run through the prior posts I'm going to go
>for the gusto and try to get the approval to combine multiple procedure
>into a module and, if I understand correctly, multiple modules into a service 
>program.
>
>The question I have now is where to draw the line on how to do the general
>design.  First some background.  Our applications can be separated into
>different areas; payments, collections, funding, etc.  Should I have a
>single service program for each application area or would there be more
>than one per area?  I presume one for everything is not a good idea.
>
>Even though most of the suggestions from the other thread advocated
>multiple procedures in a single module I wasn't picking up much on
>multiple modules in a service program (probably my thick skull) but that seems 
>to make sense.