RE: ILE Question

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

Terri wrote:

>I have a section of code I have to write that
>will be used in several programs. Great chance
>to try ILE! I took a deep breath and broke out the
>books.

All right!  It's good to limber up those mental muscles and work with some
new tools.

>I don't want to use bind by copy because some
>of the compare criteria I will be using can change.

There's a bit of background you may need to cover before you can proceed.
'Bind by copy' has nothing to do with the type of code you will write.  It
deals with how you compile and bind the procedures together.  Having said
that, perhaps you can backtrack a bit and tell us what sort of routine you
intend to code?

>My question is, can I just write a sub procedure,
>then within an IF statement use a prototyped
>call to get the value I need?

Absolutely.  Something like this?
IF checkCredit(custID) = CREDIT_HOLD
  send message that customer is on credit hold
ELSE
  continue to process order
ENDIF

>Or do I need to put the sub procedure into a
>service program?

The two questions aren't really related.  That is, you would invoke your sub
procedure exactly the same whether you coded it locally within your program,
bound it in by copy or bound it in a service program (which gets bound to
THIS program.)

>Does any bound by reference procedure need
>to be in a service program?

By definition, service programs mean bind by reference.  I would ALWAYS put
a sub procedure like yours (used in more than one program) in a service
program...  Others may have a different opinion based on start-up
performance, but I think that's a bit advanced for the first touch.

Here's what I'd do:
Consider the business requirement I need to solve.
  Can I express it like the checkCredit example above?
  Is it very complex, returning many variables?
Subprocedures work best if they deal with few input
parameters and return only a few values.  If I find
myself with a sub procedure that returns a dozen values,
it's probably because I didn't decompose the problem
enough.
Draw up some pseudo-code that describes the one specific
task to perform.
Draw up the test plan that will prove my code works.
Write the code, put it in a service program.
Write the test jig, bind the service program.
Test!
When OK, implement the service program in my mainline.

I hope this was of some help.
  --buck