RE: Application Architecture/Design Question

I encountered the same need, so I wrote a "registry" api. At minimum, I required to "keys" to identify entries, with optional use of another key.

The physical implementation was one DB2 table, a service program, a display file & maintenance program. Oh yeah, a couple of command objects to allow the maintenance program to perform simple GET and SET actions from CL and command line...

I wound up adding support for DB2 field encryption, so that I can optionally encrypt certain values, like passwords or keys used to access web-services, whatever...

The two key requirement:
key one defines scope, typically program name
key two defines the attribute name
optional key allows for subsets, (as in, ("PayPalApplication", "MerchantAccountName", "MySite1"), where you need a different Merchant Account User for each website...

All in all, it was fun to write, and allows us to concentrate much of the miscellaneous control-value settings into a common repository, eliminating the need for dozens of DTAARA objects. Encryption allows for secure storage of credentials and other "protected" contents...

Hth,
-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Naughton
Sent: Thursday, January 24, 2013 1:24 PM
To: Midrange Systems Technical Discussion; RPG400-L@xxxxxxxxxxxx
Subject: Application Architecture/Design Question

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.