Re: Signature violations

On 6/26/07, Buck <kc2hiz@xxxxxxxxx> wrote:

Hi Steve,

> would you ever user lvlchk(*no) on your database files? You can if
> all you ever do is add new fields to the end of the record format.
> Using lvlchk(*no) is the same as hardcoding the signature. The
> alternative is to have the system assign a new signature and recreate
> all the programs that use the srvpgm. Same as recompiling all the
> programs that use the database file.

My original suggestion for you to use hard coded signatures was based on
my mistaken assumption that you simply didn't like the signature
violation concept. Hard code the sig, no violation :-) Having said
that, lvlchk(*no) is not the same as a hard coded signature because we
have the ability to make an intelligent signature, viz:

strpgmexp pgmlvl(*current) signature('01.00 20070404')

With this mechanism I can clearly define which version of the exports
are bound to a program.

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.

>
> and you trust all your programmers, consultants, managers - whomever
> is able to add a new procedure to a srvpgm - to always add new exports
> to the end of the binding source? There is no system support for
> enforcing this rule. Yet if it is not followed all your applications
> could crash when the revised srvpgm is promoted to production.

Yes. If I did not trust that a programmer was capable of adding an
export to the end of binder language source, why on earth would I trust
him to be able to do anything at all? I understand your point about
dynamic procedure loading, and that's actually possible:
http://archive.midrange.com/rpg400-l/200306/msg00462.html

May I inquire if this is an actual problem you have encountered in your
travels? I personally have not run into an RPG programmer who couldn't
get this right, but not everyone is exposed to the same circumstances...

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