Re: ILE Service Program best practices

[Mike Eovino <meovino@xxxxxxxxx>]

On Tue, 16 Nov 2004 08:38:36 +1100, Simon Coulter <shc@xxxxxxxxxxxxxxxxx> wrote:
> 
> On 16/11/2004, at 7:56 AM, Mike Eovino wrote:
> 
> > Service Program A was made from Module A and contains subprocedures 1
> > and 2
> > Service Program B was made from Module B and contains subprocedures 3
> > and 4
> > Subprocedure 2 calls subprocedure 3
> > Subprocedure 4 calls subprocedure 1
> 
> stuff deleted
> 
> > Each service program is dependent upon the other.
> >
> > We can fake this out by moving the existing objects over as well, but
> > this raised an interesting question:  How do we keep this from
> > happening in the future?
> 
> Better design? That's meant seriously. What is the purpose of service
> program A and B. Should the functions they export really be in the same
> service program (e.g., all string stuff, or all Accounts Receivable
> stuff)?

I won't call our design either good or bad, but we do put related
subprocedures together into  service programs.  So (as far as we know)
all the subprocedures in each service program should be grouped
together.

> > The only thing we can think of is to limit service programs to a
> > single subprocedure, but is this really something we want to do?

Just wondering, is there a strong reason NOT to go this route?  I just
want to know so when people ask, I can tell them why.
 
> You can create one service program and specify OPTION(*UNRSLVREF) then
> create the other. Once the second one is created recreate the first one
> without specifying unresolved references.

Didn't know about that.  That's pretty cool.

> This is the method I use to handle the following example in my own code:
> My MATH service program uses my MSG service program which uses my STG
> service program which uses my MATH service program. The only way to
> avoid this cyclic dependency is to either:
>         a) Duplicate function (either by /COPY, cloning, or writing
> differently)
>         b) Artificially separate the MATH function need by STG into a separate
> service program
> 
> Neither of which I find palatable. The code is separated by functional
> group and that i show it should stay because it makes using the service
> programs easier. To get the ease of use I pay a price of slightly messy
> creation.