Sounds like a case for dynamic SQL to me. No file definition at all. Each routine (Rtn37) builds the sql it needs to get to the file. All keyfield sizes, etc are abstracted away into the dynamic select or insert.
Still, I'd make it modular. Compile each Rtn as it's own NOMAIN module. Then maintenance on one routine requires only re-compiling that module and rebinding the service program. Yes, I'd make PgmB a service program. Export all the routine names.
All those routines will need protypes in PgmA. Great use for /COPY. Use the same prototype within the module file in each routine that will be in PgmB in the source for PgmA.
I think I'd look for a way to gather some of those files into a smaller set of files where records have similar characteristics. You can sparsely load columns in the file if needed (null when a particular type of record doesn't have a 5.3 keyfield for example). Let the database do a lot of the work for you. Include a "type" column. So your selects look like:
SELECT templateField from FileA where type='Rtn37' and decimalColumn = 5.7 and stringColumn='Some Value'
And
SELECT templateField from FileA where type='Rtn38' and integerColumn = 22 and stringColumn='Hello'
Receive the SQL results into a data area you can differentiate for the result sets from the query. Each module has its own data area. Keep the size of the PASA down by ALLOC'ing the memory for the data area before the call and deleting it after.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Naughton
Sent: Friday, January 25, 2013 9:38 AM
To: Midrange Systems Technical Discussion
Subject: Re: Application Architecture/Design Question
Thanks to everyone for your help!
The basic idea is that the user will be working with tables (in a web browser) having various (user selected) columns. Each column heading indicates a certain type of data: one might be "name of country", one might be "population per square mile", one might be "main export product: name, category, annual $$", etc. So some might be character data of various lengths, some might be numbers of various sizes and precisions, and some might be combinations of two or more types.
For each cell in the table, PgmB will use the column heading as the key to figure out which routine to call, and it will pass that routine (let's say Rtn37) a second key to indicate exactly which cell is being referenced. Rtn37 will also be passed a string as an input parameter and an "action" code, and it will pass back a string as an output parameter.
To keep it simple, Rtn37 will do two things. If the action code is "display", the string passed in will be blank, and Rtn37 will read a record from the data file and build a string to be passed back and displayed in the table cell. If the action is "save", the string passed in will be the data wrapped in XML, and Rtn37 will parse it and store it in the data file, passing back a blank string.
So, all the data files may be different: one might be a key and a ten-character field, another a key and a 5-digit number, another a key and a twenty-character field, a five-character field, and a 7,3 number, so lumping them all into one big file won't work. Each data file probably won't have a lot of records -- maybe a few dozen up to a few hundred. Similarly, all the RtnXXs will basically do the same things: either read a record and build a string, or parse some XML and save a record. But the "build the string" process will range from putting a single data value into the string all the way to adding words, possibly adding html tags, formatting numbers, etc., and the XML parse will be filling very different record formats (with possibly some massaging of the data coming in before actually storing it).
I don't know if that makes it clearer or not. Does this help?
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> writes:
Hi, Mike:
OS/400 or IBM i provides many viable alternatives to using database
tables (files) -- for example, perhaps you could use a never-ending
server job, and your applications would make requests and receive
results via data queues... Also, you might want to consider using a
combination of user spaces and user indexes to store the data in a way
that might be far better than database files, from a searching speed
perspective. (You could use one or more database files or members to
house the data, to make it easier to initially load and maintain the
data, then read it into the user space and/or user index when the
"server job" starts.)
Perhaps you could give us some kind of "example" of the type(s) of
key(s) to be used and the kind(s) of data to be returned, even if it is
entirely fictional, contrived or hypothetical, just to give us all a
better idea of what you may be trying to do?
Also, can you give us some idea of the record layout of these files?
Are they all the same, but only the data content is different? Also,
how many records do you anticipate would be contained in each of those
individual files? (If they all have the same record format and layout,
perhaps you could use multiple members instead of many files?)
The more detail you can provide, the better the answers or suggestions
we may be able to supply.
All the best,
Mark S. Waterbury
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 Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
