Re: ILE Concepts

... interisting discussion, some corections and additional thoughts:

@export *all:
- all procedures ar exported (using binder language only a subset)
- sequence is aplphabetically (not source sequence)
- errors will be forced to activation time as far as the compiler could do (it's only using procedure names, not parms)

@one module - one SRVPGM:
- if the exported procedures are prefixed by modulename all external references are unique

These two guidelines together will provide a simple and foolproof strategy to avoid strange effects at runtime. But you would have to pay some price (you'll never get anything for nothing!).
- you would pay with some additional binding steps.
- you would pay with some additional deployed objects.
- you would need some check what signatures are broken (rather easy to compare imports and exports automatically)

To illustrate why and when you will need a more sophisticated approach, a short discussion about publishing a public library of functions:
- deploying a complete application in one SRVPGM (and a corresponding BNDDIR) makes it easier for other applications to use the library (=> Java would deploy one jar file)
- Binder Source is used to ensure, that only the public procedures are exported, signatures are used for versioning.
- possible libl conflicts are minimized by a one for all aproach
- additional possibilities to controll multiple activations of the same module (thinking of OA handlers)
But you would have to pay some price (you'll never get anything for nothing!).
- errors in handling your Binder Source could transfer errors from activationtime to runtime, wich is harder to detect.

(ArdGate is using an alternative aproach. Deployment unit is a library and all internal references are resolved by dynamic binding at runtime - but this is another discussion)

@one signature for all versions:
- a bad idea at all (comparable to LVLCHK *NONE for all files)
- has no influence to activation

D*B