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: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.