RE: Something lighter than a database file . . .

So far none of the suggestion will provide you with duplicate record
checking.  You will need the Unique Key of the full DBMS to get that
with out writing a lot of code to check for duplicates.  Keyed Data
queue will not work, no duplicate checking and hard to read and leave on
queue.  Any duplicate checking code you write will have to search
through all records to find that possible duplicate.  I do not think
that you problem is the data base file.  If these records are few and
written to qtemp, they probably never make it to disk but stay in
memory.  A suggestion is to put your keys in a sorted array for
duplicate checking and possibly writing to a subfile.  Tricky to get a
sub file into a server job with no workstation attached but it is
possible.   I just don't remember how.  Your array would hold your
subfile rrn. 


Christopher Bipes
Information Services Director
CrossCheck, Inc.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gary Monnier
Sent: Tuesday, March 07, 2006 9:28 AM
To: Midrange Systems Technical Discussion
Subject: RE: Something lighter than a database file . . .

After yesterday I'm not sure I want to respond.  My neck is still a bit
sore.  But here goes anyway.  I have the feeling you were just having a
blue Monday.

Could you make the "simulation" process asynchronous to your server's
process?  For example write entries to a data queue(s) instead of a
database.  Data queue would then be read by your asynchronous server.
Asynchronous server does the simulation work one request at a time, or
spawns jobs to perform individual simulations.  Results are then be fed
back to the client via some signal, and data retrieval if needed,
mechanism.

If not, then as others have suggested internal arrays, user spaces, user
indexes, keyed data queues or keyed user queues are the avenues open to
you.  If your server is written in Java the Derby database may be an
option.