Re: Stray module in service program

On 12/29/2015 12:44 PM, Koester, Michael wrote:

I have a service program with a couple dozen modules that I intended it to have, and one extra one that the CRTSRVPGM thought I should have "just because".
I really want that other one to be in another service program instead, and I don't want it to be in both.
This is a project I've been working on for awhile. Over the months, I've changed my strategy of what-belongs-where. The "WRTSOMEMOS" module should be in the TFSORDERS service program - it may have been in the NEONOVAAPI service program at one time.

I myself only put one module in a service program. I have been known to
move sub-procedures from one service program to another as I refactor
things, which is only sort of similar.

I delete the NEONOVAAPI service program.
I create the TFSORDERS service program with MODULE(WRTSOMEMOS + a couple others that belong there).

What is the exact compile command? Specifically, I want to understand
the MODULE() and BNDDIR() parameters.

I verify TFSORDERS now has WRTSOMEMOS, and that the TFSORDERS *BNDDIR has the current copy WRTSOMEMOS module. (OK so far).

Please do a DSPBNDDIR TFSORDERS and post the results. Also, do all 3
source members have H-specs for BNDDIR(TFSORDERS)? If so, why?
Dieter's advice comes into play here: a common binding directory (of
*MODULEs) indicates that those modules will be used in multiple places.
Which is exactly what you don't want. Thus, Dieter's advice to simply
specify the modules on the CRTSRVPGM MODULE() parameter, since each
service program will have a unique list of modules.

I recompile the module source members that have an H-spec BNDDIR(TFSORDERS) just in case that matters, and I delete the four programs in my development library that have that H-spec, just in case that matters.
I create the NEONOVAAPI service program, specifying the modules that should be there, and specify EXPORT(*SRCFILE). [the export list in the QSRVSRC member does NOT include WRTSOMEMOS].

First, EXPORT() has nothing to do with the modules that are bound into
the service program. Second, the binder language does not refer to a
module; not directly. The binder language would have a list of
procedures being exported.

I run DSPSRVPGM NEONOVAAPI DETAIL(*MODULE) and see that WRTSOMEMOS is there (?).

If the H-spec has a BNDDIR(TFSORDERS), and that *BNDDIR has *MODULE
WRTSOMEMOS in it, this will happen.

Okay, I try this again. I delete and recreate the NEONOVAAPI *srvpgm, this time with EXPORT(*ALL). Still has the WRTSOMEMOS module.
And again, after deleting the WRTSOMEMOS module. CRTSRVPGM fails, because it can't find the module I didn't want it to find.

I suspect there might be an object (in my library or elsewhere?) that has some connection to that module, but I don't know what or where.

Hopefully when you look at all the H-specs and binding directories the
cause and effect will be revealed.