... so you mean, you have procedures with the same name but different
functionality in different service programs?
You simply bind with *DUPPROC and think everything is OK?
Did you ever care whether the expected procedure is called?
I run in this problem with a customer, who had modules and service programs
(and even the older renamed service programs) within the same binding
directory that was specified when binding programs or service programs.
Additionally he used the same procedure names in multiple modules and
service programs. And simply bound everything with *DUPPROC.
Sometimes the module was bound, sometimes the current service program
sometimes the old version of the service program.
May be it run but ... never ever try to do any modifications!
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im Auftrag von
Englander, Douglas
Gesendet: Monday, 04.8 2014 19:27
An: rpg400-l@xxxxxxxxxxxx
Betreff: Re: Compiler parameter
Thank you to all who replied. I was thinking along the same lines, in that,
CRTBNDRPG is basic, and only handles one module. I understand the use of
*NODUPPROC and that would be the norm for me, where one procedure was
defined in one and only one service program. But in a prior job, there were
some functions created in multiple service programs, and most (not all)
service programs were normally accessible to the compile command. But when I
compiled certain programs with *NODUPPROC, sometimes the compiles would fail
if the compiler found multiple definitions when *NODUPPROC was set by
default. The compiles had to be resubmitted with *DUPPROC and would then
compile. I did not set up the system that way, but it was something I had to
work with.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
