I probably explained it badly. I know I have seen documentation on this but can't find it right now. I have tested it and found it to be true. Our shop is in the midst of cleaning up after several years of working around this problem, as well as a few others.
If on the create service program command you specify to bind a second service program the list of exports will be a combination of both service programs if *ALL is used for the export keyword.
Simply referring to a procedure in a second service program and having the compiler locate it using a binding directory does not add the second service programs exports to the export list.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Simon Coulter
Sent: Monday, September 28, 2009 8:49 AM
To: Midrange Systems Technical Discussion
Subject: Re: Binder Source
On 28/09/2009, at 10:21 PM, <Rick.Chevalier@xxxxxxxxxxxxxxx> wrote:
You don't even need to use the export keyword to have a procedure
available within a service program. If a procedure is only used
within a service program I wouldn't even put the export keyword on it.
That's only true for single module programs and service programs. If you have multiple modules you must use EXPORT to make procedures in one module visible to the other modules in the same bind object.
Another reason for binder source is that if service program SP1 binds
to service program SP2 service program SP1 will by default export not
only any procedures it contains that are defined with the export
keyword but also every procedure exported from SP2. If both of these
service programs are in the same binding directory you will get
duplicate definition errors when binding to one of the duplicated
exports. Using binder source limits this kind of duplication and keeps
procedures exported only from the service program you want them
exported from.
Either you are very confused or you explained this badly. SP1 will not export procedures from SP2.
If you experience bind errors due to duplicates from modules in SP1 and modules in SP2 then it's due to you either specifying the same module in both SP1 and SP2, specifying the same export name in different modules, or specifying both modules and service programs in the same binding directory. None of these approaches are sensible.
Binder source will not protect you from this situation except in one limited and contrived scenario.
I guess you could mean that SP1 contains Ma and Mb and SP2 contains Mb and Mc. In this case you could get duplicate exports due to Mb being in both SP1 and SP2. You could use binder source to hide the Mb exports from either SP1 or SP2 but if that's really what you meant then I'd question your whole design. Why have Mb in both SP1 and SP2?
Just have it in one SP and bind to it from the other.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.
midrange.com
