SrvPgms and Change Management

I was having a good read in the archives all about service programs, as
I was trying to work out the advantage of 

 

a.      a service program created over an rpg module which contains
several date conversion routines and including said srvpgm on a binding
directory versus:
b.      just putting the module on the binding directory.

 

Apparently, the answer has somewhat to do with the fact that the service
program is bound by reference, whereas the module is bound by copy.

 

I figured the practical upshot of all this was that if I went with the
service program, I should theoretically be able to check out the module
from our production environment to my user library and modify it, then
promote it back through Q/A and into production again, all without
having to recompile all of the programs which refer to procedures within
said module.

 

Our change management software (MKS Implementer v5.4) won't cooperate.
I contacted them, and they sent me a nice knowledgebase article which
seems to confirm that all related objects must be checked out along with
the module being changed and promoted right along with it.  (It
explicitly states that they do not nor will they ever support UPDSRVPGM
or UPDPGM). Not only this, but I must also check out and recreate the
service program itself with the module and all the programs.

 

So where my intention was to keep the number of objects I need to change
to a minimum, by going with the service program option, I just have one
more than I otherwise would have. 

 

Is there some other advantage to using the service program in this
scenario that I am missing ? 

 

Is the inability to take advantage of the "bound by reference" nature of
the srvpgm purely a matter of bad design on the part of my change
management software, or have I simply misunderstood the practical
implications of this feature ?   Isn't the idea behind reusable code
supposed to be the ability to make changes in one little piece of the
application without touching all the others ?  

 

 

Greg Fleming

Programmer/Analyst

Everglades Direct, Inc.

gfleming@xxxxxxxxxxxxxxxxxxxx