• Subject: Re: Binding Directories
  • From: "Phil Hall" <hallp@xxxxxxxx>
  • Date: Tue, 16 Jan 2001 12:20:20 -0600

Martin,

> > If I have a *MODULE and a *SRVPGM that both export
> > PROC_A [but the *MODULE one takes a  pointer as the
> > parm, the *SRVPGM one takes a PKD as the parm] in my *LIBL
>
> ... then you have a design problem, IMHO :-)

Yes, to compound things, this imaginary project does have design issues, and
it's already past due and well over budget ;-)

> > As for the explicit lib/module parameter of the CRTPGM cmd,
> > sadly, CRTPGM
> > binds all the modules listed in the list, even if they are
> > never referenced,
> > leading to bloated objects containing orphaned *MODULEs.
>
> Erm, no it doesn't.  It does put a lock on them all at compile time,
> which can cause a few problems, and I don't think is necessary, but it
> only binds the objects it actually needs.

I wish you were correct Martin, but for the case Mark suggested, that I
outlined, were you use the MODULE parm of the CRTPGM,  **all** the modules
listed on that parm are bound into the resultant program object, even if as
I said before, they are never used (go try it for proof).

You are correct however, if you list your modules in a BNDDIR, then only the
ones needed are bound in to the program object. But that doesn't solve the
issue of determining which duplicate export to use...

--phil

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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].