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 / \
--------------------------------------------------------------------
midrange.com
