Re: Stray module in service program

There's been quite a bit of discussion about how the WRTSOMEMOS module got
into the service program--including thinking that simply having it listed
in a referenced binding directory caused the problem. This is *NOT*
correct. A binding directory simply lists modules for *possible
inclusion*. Here's the text from the 7.1 ILE Concepts manual, page 32.
The text is point three under 'Binding Directory Processing':

-----------------------------
All of the binding directories on the BNDDIR parameter are processed in
the order listed. All the
objects listed in these binding directories are examined in the order
listed, but they are bound only if
needed to resolve imports. Duplicate entries in binding directories are
silently ignored.
-----------------------------

The significant point to the discussion in this thread is 'they are bound
*only if needed* to resolve imports'. If the module ended up being
included, it was needed to resolve an import in the NEONOVAAPI service
program.

You can list every module on your system in a binding directory, but only
those you need would be bound to the program or service program being
created. That said, it wouldn't be wise to do this because each object in
the directory is examined to see if it satisfies a needed import.
Including too much in a binding directory could make for slow compiles.

I have binding directories which list service programs with seldom used
modules and those modules never show up in a program or service program
unless I specifically need them.

If the binding directory lists a *MODULE object and it satisfies a needed
import, it is bound by copy. If the needed import is a module is in a
service program, the module is bound by reference. I think Chris covered
that in an earlier reply.

There's really not a lot of mystery to binding directories. To avoid
having someone change them and get odd results, we control their
move/promotion to production just like any other production artifact.