Re: Signature violations

Steve,

That's why you put the following highlighted comment at the top of the
binder source:

/* DO NOT REMOVE ANY EXPORTS FROM THIS SOURCE MEMBER */
/* ANY NEW EXPORTS MUST BE ADDED AT THE BOTTOM */

Typically we have a comment against each export, which by default says the
module from which it is exported, but this would be changed to OBSOLETE
(again, highlighted), e.g.:

EXPORT SYMBOL('DumpProcedureError') /* YERRPRC */
EXPORT SYMBOL('GetDebugMode') /* OBSOLETE */
EXPORT SYMBOL('GetDebugModeExt') /* YDBGPRC */

But as Buck says, if you (or I) trust someone enough to write RPG code
(especially ILE procedures which will be exported from service programs),
then I trust them enough to follow instructions and do the binder source
right.

We have tried using an authority-based system to control who can update
source (both program source and also binder source), but eventually we just
let all developers copy production source into a separate test environment,
make changes and then it's the responsibility of the product builder
(typically me) to 'roll' that change into production. Part of that rolling
process is checking old/new source, including binder source.

FWIW, we use hard-coded signatures. We've never used the (massively
overly-complicated) *PRV and *CURRENT signature system. Our hard-coded
signatures typically include a product release or build number. Since we
sell our software, we're especially concerned about backwards
compatibility...

Rory


On 6/26/07, Steve Richter <stephenrichter@xxxxxxxxx> wrote:

Buck,

maybe I am wrong on this. If I am correct, I think it is important for
people to understand the problems you are exposed to if you
incorrectly use service programs.

*prv signatures dont protect from the problem of reordering of the
exports of the srvpgm. As I understand it, the *PRV and *current
signatures of a srvpgm are the ones that will not signal a signature
violation. But if you insert or remove entries from the binding
source, which causes the export numbers of your exports to change,
your applications are going to fail - despite the fact you dont get a
signature violation.

a recent job. we were coding a lot of applications, had a lot of
production jobs running on the system, and I was pushing the use of
CALLPRC from CL. Everytime I added a new procedure I was very
concerned I would break something and we would have to spend time we
did not have to fix the files and rerun the jobs. That was mostly
superstition because I had learned by trial and error to update the
srvpgm correctly. But I was there as a contractor, and there is no
guarantee that the people who follow me and work on that code will
know to maintain the order of the binding source. The point is the
system provides no protection from the inadvertent reordering of the
binding source.

-Steve