|
I would not have encountered this Brian because I would never put a module
in a binding directory.
If I remember correctly, the ability to list modules in binding
directories was intended as an easy method for building programs from
multiple modules. But few people do that - I certainly don't.
If I need a module in more than one place I put it in a service program
and that is what goes in the binding directory.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Feb 6, 2018, at 7:27 PM, Brian Parkins <goodprophet.bp@xxxxxxxxx>wrote:
list from the Binder Language also determines which components to be
That's not quite my experience, Jon. IF a *BNDDIR is used, the Export
included, i.e. only those *MODULEs whose exports satisfy the Export list.
no use at all
EXAMPLE
Three *MODULEs, M1, M2 and M3.
M1 - has no imports or exports defined (daft as it may sound) and is of
M2 - has export E2only.
M3 - has export E3
The *BNDDIR BD has two entries for M2 and M3
The Binder Language (source member) SRV specifies EXPORT SYMBOL('E2')
(Name, generic*, *SRVPGM, *ALL)
To create the *SRVPGM SRV I can specify:
CRTSRVPGM SRVPGM(SRV)
MODULE(M1) <<<< specify something because the only values allowed are
EXPORT(*SRCFILE) SRCMBR(SRV)is not required to satisfy the Export list, nor any imports required by M1
BNDDIR(BD)
I end up with *SRVPGM SRV containing M1 and M2 - not M3. The *MODULE M3
and M2.
issued the command,
But I don't really want M1 in the *SRVPGM. So, perhaps I should have
*SRVPGM, *ALL)
CRTSRVPGM SRVPGM(SRV)
MODULE(M2) <<<< because the only values allowed are (Name, generic*,
EXPORT(*SRCFILE) SRCMBR(SRV)issue the command,
BNDDIR(BD)
but now M2 is mentioned twice, (on the command _and_ in the *BNDDIR).
This is a somewhat silly example, but I suggest we should be able to
some folk have a separate *BNDDIR for each *SRVPGM. So, the list of module
CRTSRVPGM SRVPGM(SRV)
MODULE(*NONE) <<<<
EXPORT(*SRCFILE) SRCMBR(SRV)
BNDDIR(BD)
if a Binding Directory is specified.
<Phew>. I hope I have explained the situation. It comes about because
names in the *BNDDIR reflects the "make-up" of the *SRVPGM. Under these
circumstances, why do we need to specify the MODULE() parameter at all?
I've never quite got it and I hate saying, "that's just the way it is" to
people.
function is a much neater way of dealing with things. Perhaps *BNDDIR
Apologies for steering things off in a wild direction. I agree a "make"
should be avoided altogether?
included/referenced surely.
Brian.
On 06/02/2018 23:01, Jon Paris wrote:
That base module is going to determine which other components are
the service program - not the overall components to be included. It could
The Export list is only identifying those labels to be exported from
easily get to be a nasty circular mess without some "guidance".
wrote:
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
On Feb 6, 2018, at 4:24 PM, Brian Parkins <goodprophet.bp@xxxxxxxxx>
quite understood about the CRTSRVPGM command, perhaps someone can enlighten
Forgive me for hijacking this thread a little. One thing I have never
me?
the procedure exports. Suppose also I wish to use a *BNDDIR to specify the
Suppose I wish to create a *SRVPGM using the Binder Language to define
list of *MODULES to search for these exports.
parameter explicitly defined? In other words, why does (at least) one
QUESTION: Why then must the CRTSRVPGM command still have the MODULE
*MODULE have to be specified explicitly on the command. (The default is
MODULE(*SRVPGM).) The Binder Language will specify the export symbol table
and thus determine other *MODULES that are required from the *BNDDIR (and
hence any other *SRVPGMs/*MODULEs) to complete the bind.
MODULE parameter required at all? (The BNDSRVPGM parameter is optional, so
CRTSRVPGM SRVPGM(SRVPGMNAME)
MODULE(???????) <<< Why is this needed??
EXPORT(*SRCFILE) SRCFILE(QSRVSRC)
BNDDIR(DIRNAME)
Put another way, since a *SRVPGM has no Entry Module, why is the
why not the MODULE parameter under these circumstances?)
implication NOEXPORTS does nothing at all. It is of no use within the
Silly Example: Suppose I specified MODULE(NOEXPORTS) above. By
*SRVPGM yet the parameter must be specified.
(RPG400-L) mailing list
I must be missing something obvious.
Brian.
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
questions.To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
affiliate link: http://amzn.to/2dEadiD
Help support midrange.com by shopping at amazon.com with our
mailing list
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
To post a message email: RPG400-L@xxxxxxxxxxxxquestions.
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
link: http://amzn.to/2dEadiD
Help support midrange.com by shopping at amazon.com with our affiliate
--
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: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
