Re: service program signatures

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

On 14/07/2005, at 10:04 PM, Scott Klement wrote:

> I agree with you completely. Using *CURRENT/*PRV provides absolutely 
> no benefits that I can find.

There is at least one case where *CURRENT/*PRV does provide a benefit. 
If I provide a service program for external consumption and I need to 
completely rewrite the behaviour but I don't want existing consumer to 
get the new behaviour I can use *CURRENT to rename the old function and 
allow *PRV to reference it using the old name. If I have to change the 
interface to a function I can do the same thing. For example:

Presume I have a getTaxAmount function in a common service program. The 
exports for this service program are:
        
        STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('VRM110')
        EXPORT SYMBOL('getFidTaxRate')
        EXPORT SYMBOL('getGstTaxRate')
        EXPORT SYMBOL('getFidTaxAmount')
        EXPORT SYMBOL('getGstTaxAmount')
        ENDPGMEXP

Now suppose the rules for the getFidTaxAmount calculation change such 
that either an extra parameter has to be added to the interface and it 
can't be optional or a complete rewrite of the implementation is 
required. I don't want to force consumers to change just because the 
service program has changed. I want to let them modify their code 
gradually so existing compiled objects continue to work in the way they 
used to and recompiled objects pick up the new interface and the new 
prototype requires them to make the code change. I can do this by:
	o In my service program I rename the current getFidTaxAmount function 
as getFidTaxAmountOLD
        o In my service program I write a new getFidTaxAmount function
        o In my binding source I change the exports as follows:
                STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('VRM120')
                EXPORT SYMBOL('getFidTaxRate')
                EXPORT SYMBOL('getGstTaxRate')
                EXPORT SYMBOL('getFidTaxAmountOLD')
                EXPORT SYMBOL('getGstTaxAmount')
                EXPORT SYMBOL('getFidTaxAmount')
                ENDPGMEXP
                STRPGMEXP PGMLVL(*PRV) SIGNATURE('VRM110')
                EXPORT SYMBOL('getFidTaxRate')
                EXPORT SYMBOL('getGstTaxRate')
                EXPORT SYMBOL('getFidTaxAmount')
                EXPORT SYMBOL('getGstTaxAmount')
                ENDPGMEXP

Eh, voila! Existing compiled programs find the new service program has 
a matching signature and the fourth export will be invoked even though 
it has a different name from the name used in the consumer.

Admittedly, you could achieve the same effect by having a single export 
block with a hard-coded signature such as:
                STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('TAX_STUFF')
                EXPORT SYMBOL('getFidTaxRate')
                EXPORT SYMBOL('getGstTaxRate')
                EXPORT SYMBOL('getFidTaxAmountOLD')
                EXPORT SYMBOL('getGstTaxAmount')
                EXPORT SYMBOL('getFidTaxAmount')
                ENDPGMEXP

but you lose the ability to view the consuming object and know which 
public interface it is using. If the consuming program shows a 
signature of TAX_STUFF I don't know whether it will call 
getFidTaxAmountOLD or getFidAmount without guessing based on creation 
dates. If the signature shows VRM110 then I know it is calling 
getFidTaxAmountOLD. If the signature is VRM120 then I know it is 
calling getFidTaxAmount. I think this reduces support costs 
sufficiently to warrant the extra work. For internal stuff (i.e., stuff 
only ever consumed by your own code) it may not be worthwhile.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------