Re: RE: binder language, binding directories, bind by copy/reference

[jrc@xxxxxxxxxx]

This has been an enlightening, albeit shocking, thread.  I went to Binder 
Source and the *CURRENT/*PRV method based on how great everyone on this list 
and others like it claimed it was.  I later followed a similar approach and 
began adding my own signatures based on the dates when the Binder source 
changed.

I haven't had any problems so far and it has seemed to work as advertised, so 
before I change my methodology again I want to be sure I understand what is 
being said, so if someone could simply verify these statements:

1.  Hardcoding signatures buys you nothing beyond documentation and may 
actually hide potential problems.  There *should* be no problem with this 
approach, however, if the order of the exports does not change (which seems to 
be sound advice under all the scenarios) and you retain the hardcoded 
signatures in the *PRV blocks.

2.  Procedures are actually called by their export order number and not their 
name, so as long as I don't reorder the exports (there we go again), I don't 
actually need *PRV blocks IF I hardcode a *permanent* signature.

3.  I can use *CURRENT/*PRV and allow the signatures to be *GEN as long as I 
...DON'T CHANGE THE EXPORT ORDER... without any problems.


Assuming that I have no problems changing the order of the exports (lol), are 
there any potential binding hassles with any of these approaches?  I'm getting 
ready to release a toolkit based entirely on *SRVPGMs and I don't want the 
potential users to run into any binding issues down the road.


<COMMENTARY>
I'll keep my comments short and cut right to the chase: we need procedure 
overloading.  If a procedure had real signatures based on the name, parm list 
(including sizes and types), and return value, then we could hash those 
signatures to create the service programs.  RPG has bifs with overloading (like 
%date) so why can't we have it in the language?  

It would also be great if some of this was a little more automated.  How about 
an APDSRVPGM (append service program) command?  It is a pain to add a new 
procedure to an existing service program.  And how about a BSTOSRVPGM - Convert 
binder source to Service Program.  If I use Binder source (which I *think* is 
still the preferred method), then I still have to type all the module names and 
the binder source name on the CRTSRVPGM command.  I know I could probably write 
these commands myself but it just seems they should be built in.

Sorry, seems like a good day to unload a little.
</COMMENTARY>


Thanks,

Joel
http://www.rpgnext.com