RE: SrvPgms and Change Management

Greg,

Yep, you're missing something. <grin>

Even though you may recreate the service program, by watching what you change 
and by taking advantages of binder source, you don't have to recompile the 
program that use the procedures in the service program.

In Aldon, we define the binder source as the source for the service program 
object.

So we just check out the *SRVPGM object and the appropriate *MODULEs.  Make the 
changes, recompile, and promote back.  No other programs need be touched.


HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Fleming, Greg (ED)
> Sent: Friday, August 05, 2005 3:52 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: 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
> 
>  
> 
> -- 
> This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
>