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

Carel,

Good point.  I hadn't thought far enough ahead yet to consider the application 
group.  I think you are correct that it should be considered as part of the 
implementation.

Rick

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Carel Teijgeler
Sent: Friday, February 18, 2005 4:50 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Modules in a service program - How many is too many?


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.


Privileged and Confidential.  This e-mail, and any attachments there to, is 
intended only for use by the addressee(s) named herein and may contain legally 
privileged or confidential information.  If you have received this e-mail in 
error, please notify me immediately by a return e-mail and delete this e-mail.  
You are hereby notified that any dissemination, distribution or copying of this 
e-mail and/or any attachments thereto, is strictly prohibited.