Re: Processes after CRTSRVPGM

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Again...  Using *CURRENT/*PRV signatures does not solve this problem. 
Whether they use a hard-coded signature, or whether they use 
*CURRENT/*PRV doesn't matter  -- both will have the same problem.

If you deleted all of the *PRV signatures, you could force a re-bind. 
Or if you changed the hard-coded signature you could force a re-bind. 
But, hard-coded signature and using *CURRENT/*PRV behave the same way.

Though, hopefully our friends who are software vendors do regression 
testing!!  Hopefully they have a system in place to make certain they 
don't break backward-compatibility if they expect to sell their tools to 
vendors!

Yikes, imagine if we had to re-bind all of our programs on each release 
upgrade of i5/OS, because the RPG runtime or the system APIs changed the 
order of exports in their service programs.   As it is, it's hard to get 
 i5/OS upgraded, but imagine if we had to re-bind all of our programs 
with each release upgrade!!

Software houses need to provide backward-compatible software -- at 
least, MOST of the time they need to.  On the rare occasion that 
breaking compatibility is necessary, changing the version number in a 
signature is a lot easier than deleting all of the *PRV blocks.   In any 
of these cases, folks need to learn what they're doing -- which isn't a 
big deal, since it juuuuuust isn't that difficult that all of your 
customers should suffer.


M. Lazarus wrote:
> Scott,
>
>   A software vendor installs a *SRVPGM to be utilized by clients' software.
>
> Scenario:
>   Signature is hardcoded.
>
>   Version 1 has two exports.
>
>   Version 2 with 3 exports gets shipped and installed.
>
>
>   If the manual signature has not changed, the new version will not 
> throw an error if the calling programs have not been rebound.  This 
> may be a desired behavior, if the new version handles it 
> properly.  But the oversight may allow undesirable results if an 
> export was dropped.
>
>   -mark