RE: Best way of using Service programs.

We handle it with a change management package.  The good news about
prototype definitions is that the actual procedures don't have to exist when
a program is compiled.  That means the source member can be checked out and
promoted for checkout by others very easily.  That may be more difficult in
a larger shop and were I in that position I'd probably have to rethink the
single source member concept.  Then again, a big shop could afford to have
someone keep a document of all the procedures and where the prototypes
reside. 

With a change management package, an emergency bug-fix, which I would think
would only very rarely entail changing a prototype definition, is handled
easily.  The production source is checked out, changed, and promoted back to
production.  Anyone else that has the source member checked out gets a
condition code that indicates the production source has been changed since
it was checked out. 

Donald R. Fisher, III
Project Manager
Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@xxxxxxxxxxxxx

<clip>
I agree that name clashes are more difficult to manage when using multiple
source members, but in large MIS departments the thought of runnning
multiple concurrent projects, is bad enough. But with the added complication

of putting all prototype changes/additions into the same source member makes
me want to take a lie down. :-) I can't even image how we would handle that.
<clip>
I just don't like the idea of having to change a prototype in a module for a
production bug-fix, only to find three other programmers are working on the
source member for three completely different projects. They'd have to back
their changes out so I could get the "clean" code + bug-fix back into
production asap. The more modules you include in this source member the
higher the chances this will happen.
<clip>