RE: Service Programs and Naming Conventions -- RPG400-L

1st version: MyProc   pr  extproc('MyProc.01.00')
2nd version: MyProc   pr  extproc('MyProc.01.01')
3rd version: MyProc   pr  extproc('MyProc.02.00')

Frankly, the need to do something like this only comes up VERY VERYrarely. The ability to add optional parameters to the end of theprototype without affecting anything makes it easy to update serviceprograms without having to maintain a dozen versions of a givensubprocedure. That eliminates headaches, nightmares, blurred vision,stomach cramps...


... ANYWAY...

When you DO have an occasion where you must add a new procedure interfacein order to preserve backward compatibility, it's easy to do with bindersource.


Let's say that this is your original service program layout:

STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('MySrvPgm Signature')
    EXPORT SYMBOL('MyProc')
ENDPGMEXP

Remember, when programs are bound, they do so by "export number". In thiscase, there's only one export, and it's export #1. So that's what anycalling program remembers about it -- it remembers it being called "Export#1" It doesn't even really know that the name was MyProc.

Now, horror of horrors, you're forced to introduce a new procedureinterface that would break backward compatibility. Here's what you do:


a) Go into the source code for the service program, and change the
   name of MyProc to be MyProc_v1.  Change the code for MyProc_v1
   so that it manipulates the parameters and calls the new version
   which will now be called MyProc.

b) Update the binder source to read as follows:

STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('MySrvPgm Signature')
    EXPORT SYMBOL('MyProc_v1')
    EXPORT SYMBOL('MyProc')
ENDPGMEXP

Now programs that are still using the old signature are calling Export #1,which has changed to now be called MyProc_v1. New programs, since they'llbe looking for MyProc() will get signature #1 which is the current versionof the procedure.

The main thing that I want to stress is that it's EXTREMELY unusual thatyou have to do something like this. It's much better to have a simpler,easier to use naming convention, and deal with the exceptions when theycome up than to great a hugely complicated naming convention to protectyou against something that will only come up, maybe once a year.