× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.