Re: ILE Concepts

<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