Re: Signature violations

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

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

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

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