× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Michael Q.

Regarding:
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.

There should not have been a need for the NEONOVAAPI service program to import the WRTSOMEMOS module separately, because that module was in the TFSORDERS service program. Several modules in NEONOVAAPI call functions from other service programs, and I expected modules from those other service programs to NOT appear in the DETAIL(*MODULES) list of NEONOVAAPI -- and they did not. WRTSOMEMOS was also a function called by several of the NOENOVA modules, but because WRTSOMEMOS was in another service program, I did not expect it to be in the DETAIL(*MODULES) list of NEONOVAAPI. That was the structural problem I was trying to solve.

I regret that I did not capture all the pieces that were necessary to show the "problem condition", before I went about fixing stuff, but I didn't know enough about what those pieces were when I initially posted. Going back through the changes to isolate exactly what created the problem (and what fixed it) would have been useful.

Thanks to yours and the other replies, I now have a much better understanding of how this all works.

I appreciate the help -- Best wishes for your New Year!
Michael Koester

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
MichaelQuigley@xxxxxxxxxx
Sent: Wednesday, December 30, 2015 10:39 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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.