Re: Signature violations

["Rory Hewitt" <roryhewitt@xxxxxxxxx>]

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