Re: SrvPgms and Change Management

This question really doesn't apply directly to RPG programming, so I'm
replying in MIDRANGE-L (http://lists.midrange.com/listinfo/midrange-l).

david
(who works for MKS in addition to running the lists)

Fleming, Greg (ED) wrote:
> 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 ?