Re: Best way of using Service programs.

Hi Praveen,
 
<snip>
One of the biggest practical problem I am finding with using one copy book
per service program to store the procedure declaration is: Each time I add a
new procedure to the service program, the copy book changes and as such I
have to recompile all of my programs that use this. Also I cannot use updpgm
as Turnover does not allow it.
 
I do not have a problem with Turnover compiling all the programs, but we
have 4 production environments spread across us and each change has to be
distributed to all 4 m/c. So say if 20 pgms use my srvpgm & include a copy
book, I have to compile all the 20 pgms even though they do not use all the
procedures or the new one added and distribute them.
 
So for this setup I feel the best way to go might be to not use copybooks.
Am I missing anything here.
</snip>
 
[General disclaimer: I may be wrong on some or all points made below - it is
late and I have just been accepted by DIMIA to emigrate to Australia, so my
mind is not fully-focused :-) ]
 
I would say that using a copybook for a single service program (to hold
prototypes) is perfectly fine. I am not saying it is better than other
methods, just that it is fine. What I would prefer to do is create a
separate copybook for the prototypes of each module - named the same as the
module. I would then create a copybook for the service program and simply
include the copybooks for the modules used to create the service program. I
would then reference the service program copysource in the client program.
This is a nice way to help in the reuse of modules: When you create a new
service program which uses existing modules, create a copybook for it and
slap in the module copybooks  - nice and easy. This method also helps to
document the constituent service program modules.
 
Now, copysource by definition is simply source temporarily copied into the
source prior to compile. Recompiling a service program after adding a new
prototype to a module will not necessarily affect the client program. If
your new procedure is not exported outside the module then the client
program shouldn't care. If the new procedure is not exported outside the
service program the client program shouldn't care. It is only when you
create a new procedure designed for public consumption that you may get
problems - unless you use binder language to declare the new procedure (at
the foot of the new *CURRENT block) and deprecate the current declarations
to a *PRV. You could also use custom-signatures. It is the signature and
order of exported procedures that the client program cares about - nothing
else. As long as you are careful you shouldn't need to recompile the whole
world when you have simply added a new procedure to be used by two new
client programs.
 
TurnOver will "offer" to recompile all client programs when recompiling a
service program but, if you are certain the changes will not affect some
programs you can decline the recompile for these.
 
Regarding problems with distribution to production environments - the use of
copysource and/or binding directories, or even the use of service programs
themselves, will not make a difference. Consider a service program designed
for general-purpose string manipulation. This program could be used
EVERYWHERE in a single production environment - during night and day
processes, during interactive and batch processes. Getting your changes in
can be a nightmare because you will cause some problems somewhere. But we
have always had these problems, even with OPM utility programs. We've all
had the "a program tried to refer to all or part of an object which no
longer exists" error after a code promotion - because there was some NEP
somewhere which used your program and you didn't know about it. :-)
 
I would say - use copy-per-module and group these copymembers on a
per-service program basis. I would also use binding directories - they make
life much easier. But most of all, I would strongly suggest you use binder
language. This is simply the best way I have found to allow a service
program to run with a new exported procedure added while only recompiling
the client programs which need it.
 
 
Finally, as you said:
<snip>One of the biggest practical problem I am finding with using one copy
book per service program to store the procedure declaration is: Each time I
add a new procedure to the service program, the copy book changes and as
such I have to recompile all of my programs that use this. Also I cannot use
updpgm as Turnover does not allow it.
</snip>
 
If you insist on recompiling all client programs when changing a copymember
used by a service program then consider what would happen if you DIDN'T use
a separate copymember for each service program. If several service programs
shared a copymember you would have to recompile all service programs which
use the copymember and then recompile all client programs which use all of
the service programs. Total nightmare, and all for a simple additional
procedure. The other alternative is to not use copysource and simply
cut-n-paste the prototypes into the client programs. I really wouldn't go
down that road. It is the road to maintenance hell. I would keep it simple -
you compile modules, not programs or service programs. Keep the prototype
copysource on a per-module basis and group them on a per-program or
per-service program basis. It just makes sense to me.
 
Cheers
 
Larry Ducie