It would seem that you have a need for a service program. I would think
maybe a different module for each routine bound into one service program.
Is there nothing in the logic of these 99 routines that is common?

You definitely need a copy block for the prototypes.

It is also possible that you have a need to dynamically load a service
program based on your description. You said you only need to run one of the
routines and you don't seem to know which one you need to run until run
time based on something in a database table. This would seem to be a
perfect place for a dynamically loaded service program. See my dynamic load
service program at www.think400.dk/downloads.htm for further information.
If you go that route you would have a service program for each routine or
function.

Based on what you indicated I would bet you have common logic that could be
factored out but only a guess.


On Thu, Jan 24, 2013 at 1:24 PM, Michael Naughton <
michael_naughton@xxxxxxxxxxxx> wrote:

I'm posting to both midrange and RPG because I'm not sure just where this
falls. I'm starting to build an application in which PgmA will call PgmB,
passing it a key value and expecting back a character field. PgmB will use
the key value to look in
File0000 to determine which of dozens of routines (RtnC01 through RtnC99)
it should call. It will then call the right routine, passing it the key
value and getting back a string, which it will then pass back to PgmA. The
routines will each use values in
a unque data file (Fil01 through Fil99) to build the string. The data
files will all have the same key structure, but other than that they could
be completely different.

I'm trying to decide what the best architecture for this is -- is there a
clear answer, or does it just come down to weighing the trade-offs between
the existing choices? I figure I could make Rtn01 through Rtn99 procedures
in PgmB, but it seems that
might make PgmB kind of big and unwieldy. For one thing, I'd have to
define Fil01 through Fil09 in the F-specs, and isn't there a limit on the
number of files you can define in a program? Also, in the real world, each
routine will have several different
parts, some of which might get kind of complicated (they're actually doing
more than just passing back a string).

All that makes me think that maybe Rtn01 through Rtn99 should each be in a
separate source member. But then what should I do? Compile them all into a
service program? Bind them all to PgmB using binder source? Either way,
I'd have to put put prototype
definitions for all of them in PgmB, right? (We don't use /COPY members
here -- maybe now is the time to start?)

Another consideration is that every time PgmB is invoked, it will only
call one routine, so not having to load all of them every time might give
me some performance benefits.

I'd appreciate your thoughts on the pluses and minuses of these or any
other approaches .....

Thanks very much,

Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA 01376
413-676-3144
Internal: x 444
mnaughton@xxxxxxxxxxxx
****************************************
NOTICE: This e-mail and any files transmitted with it are confidential and
solely for the use of the intended recipient. If you are not the intended
recipient or the person responsible for delivering to the intended
recipient, be advised that any use is
strictly prohibited. If you have received this e-mail in error, please
notify us immediately by replying to it and then delete it from your
computer.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.