×
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.
James:
My recommendations are:
* for use in any commercial product that is sold and supported, that
may be installed at any number of customer sites, you have no
control over what other software any customer may have installed or
might install in the future, or may have in their library list at
any given moment,
* when using open source utilities like Scott Klement's HTTPAPIR4
you should _always_ rename any *SRVPGMs that you re-distribute
(or ship with your product), and also you should rename _all_ of
the exported procedure names, for example, by prefixing them
with the name of the containing (renamed) service program.
(For examples, see Alan Campin's naming convention recommendations.)
That way, you will never have any conflicts, even if the customers are
using their own copies of (possibly a different version of) Scott's HTTPAPI.
Of course, this means you will need to go through your code to change
all instances of those procedure names, and then recompile and re-bind
with your newly renamed service program(s), and then you will need to
re-distribute all of the affected objects to all of your customers.
Hope that helps,
Mark S. Waterbury
> On 3/7/2017 3:04 PM, James H. H. Lampert wrote:
I'm finding that I'm running into conflicts between different versions
of a service program (specifically, Scott Klement's HTTPAPIR4).
Are there any "gotchas" I should know about, where renaming a service
program is concerned?
Or is it a simple matter of adjusting the binding directory used by
the programs calling the "special" version?
--
JHHL
midrange.com
