Re: Signature violations

Hi Steve,

> the problem with assigning a signature is if you ever remove a
> procedure from the binding source, or insert a new one ( in
> alphabetical order ) you will have all sorts of problems.

Right, but what is the business case for rearranging the exports in the
binder language? You can sort them in any order you wish in the RPG
source...

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.

> ILE was implemented back in the day when the CPU was a lot slower and
> more expensive than what you get on the p5 today. Whatever methods
> java and .net use to find the method being called is no doubt more cpu
> intensive, but it is a lot easier on the programmer.

Well, I can tell you that overloading in Java had me pulling out my hair
when I was inadvertently calling the wrong method because I had the
parameter types wrong. A new paradigm always calls for some adaptation.

in java and .net you dont have to code a seperate procedure prototype
header file.

Yes I understand that, but that wasn't the point. The point was that the flexibility mechanism that allows Java to choose the appropriate method based on the parameters (an implicit signature, not explicit) has pitfalls too. Every new thing is, by definition, different and requires adaptation.

> RPG programmers are faulted all the time for not adopting ILE. which
> I think is unfair because there are a few extra steps you have to
> learn, steps which the OS could easily be handling automatically.

In the context of signature violations, there is only the step of
copying existing exports to the top of the binder language and changing
the (now previous) signature to *PRV. Yes, it's an extra step. No,
it's not remotely difficult to understand or perform in my opinion.

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...
--buck