Re: Question about service programs

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

On 01/08/2008, at 12:14 AM, David FOXWELL wrote:

> But now I am convinced that SRVPGMs are the way to go, changing all  
> those programs doesn't seem to be an easy task.

Takes a bit of thought and would have been much easier to do it  
properly from the start but it's not difficult.

First, group your existing common functions into related groups  
(e.g., all date stuff, all tax stuff, all order entry stuff, etc.).  
Those become your candidate service programs. You can put all the  
related code in a single source member or you can do separate source  
members per function, or you can split at some arbitrary number of  
functions per source member, or anything else you fancy. My  
preference is for all related functions to be in a single source  
member (although I split date, time, and time-stamp into separate  
source but single service program).

Second, create copy members for the prototypes if this hasn't already  
been done. Again, group the prototypes by function. There should be  
one copy member for each service program.

Next, create binder source for each service program. This defines the  
public interface for the service program. This is a good and  
necessary thing. Do not use EXPORT(*ALL). Anyone who suggests that  
idea should be slapped! Hard! and told to get back in whatever hole  
they crawled out of and think about it for a while and not to poke  
their head out of the hole until they've changed their mind,

Next create one binding directory for all service programs. Some  
people also use binding directories for modules but my preference is  
to name the required modules on the CRTSRVPGM command but use a  
BNDDIR on the CRTPGM or CRTBNDRPG commands. Do not mix modules and  
service programs in the same binding directory (except for modules  
that are common but never exported from a service program e.g.,  
security functions).

Finally, bind your program objects specifying MODULE() for modules  
that belong ONLY to that program and BNDDIR() for the service program  
binding directory.

Test. Although since you haven't changed any code, just altered the  
binding, if they all bind without errors then they should function  
just like the old ones. However, that's not an excuse to skip  
regression testing.

Done properly I would expect no or few errors when rebinding.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         OS/400, i5/OS Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 2 6657 8251   Mobile: +61 0411 091 400        /"\
   Fax:   +61 2 6657 8251                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------