× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


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.