Re: Renaming service programs: any gotchas?

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