|
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:
midrange.com
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 / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
