Re: ILE Concepts

["D*B" <dieter.bender@xxxxxxxxxxxx>]

<Jon
Nah - Dieter would still disagree with me.
</Jon>
There are many points we agree and some we disagree.

<Jon>
There is clearly no "best" solution. Only the one that works best for your 
shop.
</Jon>
+1

Just some additional arguments:

@one module one SRVPGM: SRVPGMs enable to bind module(s) by reference. The 
alternative to this is binding by copy. The goal of ILE versus OPM is to 
modularize your applications by putting code wich is needed more than once 
in modules. Binding by copy would tend to having the same module nound to 
multiple PGMs/SRVPGMs. One point of error are diffrent versions of a module 
in diffrent PGMs/SRVPGMs. Binding all modules per reference is a simple way 
to avoid this.

@hiding exported procedures to the outside (package scope): In the one to 
one world a SRVPGM has one module that exports its public procedures and n 
SRVPGMs binding all other needed modules per reference (the public 
procedures of these modules could'nt be exported - the binder wouldn't allow 
this). All needed exports are done by exported delegates. The assisting 
SRVPGMs have ACTGRP *CALLER. For critical functions the top level SRVPGM 
gets a named ACTGRP (= SRVPGM-name), this prevents the outer world of direct 
access to the running instances of the assisting SRVPGMs.

@java RPG analogies and the limits of OO design in RPG: In java you have 
full controll of creating objects from a given class, in RPG activating a 
SRVPGM is controlled by the ACTGRP its running in. Its impossible to decide 
at runtime in wich ACTGRP a SRVPGM is activated. There are some workarounds, 
on of these is demonstrated in one of my Snippets 
(http://bender-dv.de/Sourcen/QRPGLESRC.APILIST).

@Binder Source: In the one to one world *all exports the same procedures, 
you would export by Binder Source. The one and only diffrence is the number 
of needed rebinds if an export is added. If no export is added, there is no 
diffrence (this would be the normal case. In a world of a shop with its own 
application (that are my customers) all PGMs/SRVPGMs using a changed SRVPGM 
are well known and rebind all PGMs/SRVPGMs using the changed SRVPGM is the 
simplest and most stable possibility. For a softwarehouse, using SRVPGMs in 
diffrent applications, running in diffrent combinations at diffrent sites, 
where maintenance is done by patches and releases, using Bindersource and 
the technic Scott, Jon or others recommend is mostly used and needed. 
(Another way would be binding per APIs at runtime).

D*B