Re: RPG400-L Digest, Vol 2, Issue 772

For what it's worth...

My last four gigs (either as an employee or as a consultant) have involved
training a lot of OPM programmers to use ILE.  

There are a lot of issues in the learning curve, but the main thing I've found
is that these shops that haven't got experience with this kind of modular
programming.  So, the first steps are definitely small.  

To help my clients or fellow employees see and think in terms of ILE design,
I've usually worked under the following rules for service program/module
creation and design:

1.  One function per module.  Modules that are functionally related are lumped
into a service program, even if only one module will make up the service
program.  The only exception to this rule is when "classic" (non SQL) I/O is
being used.  Then, multiple functions that deal with a file or group of files
may be grouped into one module.

Reason:  This has helped people see the relationship between modules and a
service program.  The idea of aggregating physically separate runtime objects
into a single object has been a tough one to communicate.  Demonstrating how
the modules become service programs is much easier when you can show a working
example in the context of the current codebase.

2.  Service programs always have binder source, even if the binder source
export list is identical to the service program function list.

Reason: Making service source mandatory leaves the door open for multiple
signature support, if extra modules or functions are added to the service
program.

3.  Application programs do not bind directly to service programs.  The
application programs bind to binding directories.  Period.

Reason:  Although there are some trade-offs for this particular point, I've
found overall that this enforces consistency in implementation.

Also, according to the ILE Concepts Manual, there's a bit of overhead going
through the Binding Directory -> Service Program chain when loadint the Service
Program into memory.  The fewer entries, the better, according to the book.  

So, to keep the binding directories lightweight, we have created different
binding directories for different applications.  For example, customer lookup
is used in various parts of the system by different applications.  Rather than
forcing the system to scan through the entire customer-related binding
directory, we have separate "hybrid" binding directories containing the most
commonly-used functions for the system.  This binding directory may only
contain one or two of the customer related service programs.  Despite the
apparent maintenance implications, we've found this system works reasonably
well.

As I say, these are just the things I've come up with in my own experience. 
Your mileage may vary.

-Doc