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.