Brian Johnson wrote:
The value of a generated signature comes from the fact is generated
from the ordered list of exported names. If you make a mistake
constructing the *PRV signature you *will* find out quickly when you
attempt to active a user of the *PRV signature that has not been
rebound. If you specify the the signature, you loose this safeguard
and you get to debug strange and wonderful new bugs.
What sort of mistake will you find out quickly when trying to activate
something using the *PRV signature?? What safeguard does using
*CURRENT/*PRV gain you?
Seems to me the situation is very simple. There's only four things you
can do to a service program. They are:
a) You can add new exports.
b) You can remove exports.
c) You can rename an existing export.
d) You can change the order of the exports in the signature.
With (a), it doesn't make any difference if you use *CURRENT/*PRV or
whether you use a hard-coded signature. If you don't add the new
procedures to the end, the error will go undetected in *CURRENT/*PRV,
and it will also go undetected with a hard-coded signature. There's no
difference.
With (b), same thing. For a hard-coded signature you HAVE to remember
to change the version number of the signature, it won't detect it if you
forget. For *CURRENT/*PRV, you HAVE to remove all *PRV export blocks,
you have to know to do this and understand why, and you have to remember
to do it. (Or you have to use a placeholder and never remove anything
-- in which case, this option works exactly the same in both hard-coded
and *CURRENT/*PRV).
With (c), again, the difference between hard-coded signatures and
*CURRENT/*PRV doesn't matter. In both situations, the calls are made by
export number not by name, so the renamed procedure will be called
(assuming that it's in the same place in the export block)
Option (d) is a bad idea in both cases. Neither *CURRENT/*PRV nor a
hard-coded signature will automatically detect this, and neither one
will remap old callers to call the new routines. In the case of
*CURRENT/*PRV, it's just like deleting an export, you have to remove all
old export blocks to intentionally break compatibility. In the case of
hard-coded signature, you have to remember to change the signature to
break compatibility. A better option is to never re-order your exports
-- but regardless of that -- neither solution helps more than the other.
So please enlighten us. Where's this advantage that comes from a
generated signature?!
I can tell you what the advantage of a hard-coded signature is: Your
binder source doesn't become huge, complicated and unwieldy. It's much
easier to maintain. It's much easier to add new exports (which is the
main thing that you do on a regular basis) because the code is easier to
deal with.
What does the more unwieldy *CURRENT/*PRV buy you?
I've talked to a lot of people on this subject -- and the ONLY time
people liked *CURRENT/*PRV better was when they misunderstood what it did.
midrange.com
