Service Program Signatures and Change Management

Is anyone out there using change management software and controlling
service program signatures by using binder source ?

As far as I can tell from previous discussions I've had on this list
(whose moderator happens to work for MKS, who sells the Implementer
product we use for change management), Implementer will automatically
recompile all objects related to my service program when I promote it.

 

Granted, it does this behind the scenes, so I don't have to worry about
it, but my point is that this seems to remove the value of using binder
source to control service program signatures.  

 

I asked the nice people at the MKS help desk, and they sent me a
knowledgebase article with the following relevant snippet:

 

<Begin Quote>

CHECKING OUT

 

Modules, ILE programs, service programs, and binding directories can be
checked out just like any other objects, but there are some things to
keep in mind. 

* When checking out modules, all ILE programs are considered to be
related objects, just like the relationship between a file and a
program. 

* A big difference is that you can not compile the ILE programs in your
development environment unless Implementer can find all the modules that
are linked to that ILE program. If you retain all programs in each
environment, you are OK, but that is not usually the case. Therefore, we
recommend that you put your production libraries at the end of your test
and QAC environments' library lists in order for Implementer to find the
ILE program and pick up all of its existing attributes and modules. If
Implementer can find the ILE program using the environment's library
list, it will pick up the list of modules and any attributes used to
build the ILE program automatically for you. There is no need for you to
rekey the module list. 

* All of the modules that were previously bound into a program will be
brought along and placed on the creation command for the compile. This
can be viewed by doing an option 14 with an F4. If you wish to add or
remove modules, you should do so at this time. 

* Implementer does not support the UPDPGM or UPDSRVPGM commands. We have
decided that we will not support it in the future, due to complications
brought about by using those commands. 

<End Quote>

 

Also, a snippet from David Gibbs when I broached a similar topic last
august:

 

>When you promote the service program in Implementer, any related
objects
>will automatically be added to the request and recompiled.  This, of
>course, happens largely under the covers... so you don't have to worry
>about it.

 

I guess my question for David would be whether that is still true even
if I override the CRTSRVPGM command and point it to binder source.

 

To recap and (hopefully) clarify, a syllogism:

 

Premise1: The value of using binder source is that it allows me to NOT
compile calling programs which don't use the latest procedure.

Premise2: Implementer (and presumably other change management products)
recompile all related objects behind the scenes anyway.

Conclusion: Therefore, if using change management, there is no value in
using binder source. 

 

Is there anything wrong with my logic ? 

 

Greg Fleming

Programmer/Analyst

Everglades Direct, Inc.

720 International Parkway

Sunrise, FL 33325

954.514.2258

954.851.1201 Fax

gfleming@xxxxxxxxxxxxxxxxxxxx