Re: Benefits of Sub-procedures

> Thanks for laying that out, Buck!  For the little I know about
> procedures, this would seem to be a good way to get the feet
> wet, but nothing more

Yes, absolutely right.

> I have not yet seen any responses (if there are any) to my post
> yesterday, but wouldn't one want to move quickly to
> service programs as opposed to coding inline sub-procs?

That's my view.  Some prefer the intermediate step of bind by copy.

> I have a thing or two against using /COPY.  No version control.
> Library / File names get changed, will all the programs that use
> /COPYs get modified to reflect this?

Don't specify a library name in the /copy; use the library list! :-)

> Given the choice of using /COPY or including the procedure
> source in the main program's source member, I'd
> always take the latter.

/COPY reduces the maintenance burden by keeping the source physically in one
place.  When you make a change to that /COPY member you do need to go
re-compile all the programs using it.  And that is not fun, but Pathfinder
or Abstract/Probe or other cross reference tool will help automate that.
FNDSTRPDM can help too.  With the source physically located in several dozen
programs, not only do I get to re-compile, but I need to physically edit
each program first, and automating THAT is darned nigh impossible.

>But given the choice between that and service programs, I
> think I'd always (usually?) take service programs.

Agreed again.  With service programs, the source code is in one physical
place and so is the object code!  Making a change is as easy as editing the
source, re-creating the *SRVPGM and deploying the *SRVPGM.  Unless you
needed to change the interface (say, add a new parameter to a procedure
call) you don't even have to know what programs use that *SRVPGM!  It
doesn't get much simpler than that for me.

No holy war.  Good thread!
  --buck