Re: This is a software design question - ILE related

Nathan


> With ILE you're encouraged to encapsulate code according to subject into
> reusable components.

I was brought up long ago when all program binding was static - on the System
/360 being called linkage-editing if my memory is correct. When the System/38 
was
announced in 1979, it allowed dynamic binding and I thought that this was a 
great
step forward.  I worked on the /38 from late 1980 onwards and found dynamic
program calling very efficient, providing you remembered to free a program once
you had finished with it.

This became the OPM of the AS/400 and when ILE was announced, I wondered if it
was a step backward ( of course you can still use dynamic calling if you 
prefer).
I have used ILE for about 7 months and learnt all the tricks (and have now
forgotten those relating to binding, signatures, etc.).  You listed the
advantages.  The disadvantages are larger objects ( and  I presume a larger PAG
which will affect performance if you are short of memory), an additional 
learning
curve (but not too difficult) and more opportunities to make simple  mistakes
which, until you are up to speed, take a little while to diagnose and fix.  I
don't find the ILE model compelling but it is a matter of personal choice.

> With that preface, here's the hypothetical:
>
> An ERP application has separate "service programs" for encapsulating code
> related to "employees", "vendors", "customers", "sales leads", etc.  One
> thing common to each module is "person" related data (i.e.. name and
> address).  Each separate module needs to use a "zip code" file to look-up
> the "city" associated with a zip code.
>
> For modularity, one idea is to create a single service program that opens
> the zip code file, and exports a function that returns the city for any
> given zip.  All other modules in the application can simply "bind" to, and
> use that function.  It saves little code by not including the record
> retrieval code in each module.
>
> To summarize, the application might have the following structure:
>
> ERP
>  |-----"EMPLOYEE MODULE" ------"CITY LOOKUP MODULE"
>  |-----"VENDOR MODULE" --------"CITY LOOKUP MODULE"
>  |-----"CUSTOMER MODULE" ------"CITY LOOKUP MODULE"
>  |-----"SALES LEADS MODULE" ---"CITY LOOKUP MODULE"
>  |-----"OTHER MODULES" --------"CITY LOOKUP MODULE"
>
> Another idea is to turn the "CITY LOOKUP" module into a server rather than a
> service program/sub-procedure.  A set of data queues could be used to send a
> zip code - receive a city (in the context of a single request).  The
> application might have the following structure:
>
> ERP
>  |-----"EMPLOYEE MODULE" ------
>  |-----"VENDOR MODULE" --------
>  |-----"CUSTOMER MODULE" ------
>  |-----"SALES LEADS MODULE" ---
>  |-----"OTHER MODULES" --------
>
>        ---Data Queue Set---
>
>         CITY LOOKUP SERVER
>
> The ERP application may have thousands of concurrent users.  Which design
> approach would you take, and why?  Or, would you do something else?

Yes something else - I define as much as possible in my database rather than in
code.
This dramatically reduces the development effort and improves response times.  I
use my own product ERROS to do this.  If you want to know more click on the URL
below



Rob Dixon

________________________________________________________

Erros plc

44 (0) 1844 239 339

http://www.erros.co.uk - The AS/400 Neural Database for the Internet

_________________________________________________________


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---