Re: Program vs Service Program Procedures

Greg, my experience suggests that you will, when you least expect it, need
to touch those files with some other (non-5250) interface. The service
program is the way to do it.

But I've found *many* more uses of service programs for non-database code
and it may be prudent to focus on non-database areas where you have known
code duplication--such refactoring could make a short-term difference.
Designing a service program for database I/O, where you have no known need
for such an approach, might be a harder sell: up-front effort for a
non-requirement. Examples of non-database code include common financial
calculations, or determining an expected delivery/completion date, or a
routine to validate common data items (states, telephone number formats,
city/state-province/postal code combinations, etc.). That boring stuff is
what will save you person-months over the life of an application.

Depending upon the size of your order files, parameter lists could be
unwieldy, so you might end up using multiple service programs/subprocedures
for one file, and this means you'll have to pay attention to commitment
control. The design of "data layer" service programs is not a trivial task.

I have moved almost all of my parameter list code into source members, with
one member containing a parameter list, another with a prototype skeleton,
another with the prototype field definitions, and the last with the
parameter list field definitions. Doing this makes it easy to call a
program from many other programs and maintaining the code is a snap. Need
to add a field? Update your four copybooks, recompile all referencing
programs, and you're done.

Last thoughts on the database service program: I'd start with the insert
procedure first because this is where many default values are set. I'd
whiteboard a couple of designs and try the design on a few small master
(slowly-changing) files just to see how it works and to see if there are
any design issues. Last but not least, if you can design a standard
approach, you can write a code generator that reads the data dictionary for
a table and creates service programs with SQL scaffolding in place.


On Thu, Nov 9, 2023 at 1:51 PM Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

I have the need to write several different programs or procedures to
update/create database files in our Order Entry system.
I'm debating whether to write separate RPG programs versus creating a
Service Program to contain the same calls to Procedures.

Right now, I see little reason to "reuse" this logic elsewhere. I guess
that could change in future as these will operate on our ERP Order Header
and Order Detail files.

Is there any significant performance reason to use bound procedures
instead of call to separate RPG programs?

I found some older posts on forums that indicate the difference is
negligible.

Thanks,
Greg
[Logo]<https://www.totalbizfulfillment.com/> Greg Wilburn
Director of IT
301.895.3792 ext. 1231
301.895.3895 direct
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx<mailto:gwilburn@xxxxxxxxxxxxxxxxxxxxxxx>
1 Corporate Dr
Grantsville, MD 21536
www.totalbizfulfillment.com<http://www.totalbizfulfillment.com>
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.