RE: More specifics Re: Something lighter than a database file . . .

Maybe the database file is being used for too many functions.  What if
you utilize two data structures?  One to track duplicates and one to
process from.  For example, an array or user index keeps track of
duplicate keys and a FIFO data queue that simulated requests are
processed from.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H H Lampert
Sent: Tuesday, March 07, 2006 10:05 AM
To: Midrange Systems Technical Discussion
Subject: More specifics Re: Something lighter than a database file . . .


The most useful things I've heard seem to have been the 
keyed *DTAQ and the *USRIDX. But in looking through the 
manuals on these, neither one seems to quite be the 
answer.

First of all, the process of generating the simulated 
client requests continues even as they are being read 
back, as they themselves can generate additional simulated 
requests.

This leads to the second thorny issue: the key is used 
strictly for duplicate prevention, as the requests are 
read and processed in arrival sequence (as indeed they 
would have to be, given that each one that's processed can 
add more onto the end.

Given that the index is used strictly for duplicate 
prevention, the keyed *DTAQ doesn't seem like it would do 
the job, since if one simulated request generates another 
that duplicates one that had already been processed, we 
end up in an endless loop.

Likewise, a *USRIDX (and maybe also a keyed *DTAQ as well; 
I haven't read through all the docs on them yet) doesn't 
appear to have any way to retrieve in arrival sequence, so 
it would, by itself, leave us with no way of knowing which 
requests we'd processed and which ones we hadn't.

This whole operation is being done by an RPG module in a 
mixed-language ILE program. Is there some way to have an 
open-ended, self-extending structure that looks like a 
multi-occurrence data structure to RPG?

Could I maybe have a *USRIDX that gets written to strictly 
for duplicate prevention, with (if the USRIDX write is 
successful) a parallel write to a self-extending *USRSPC? 
(let's, see, there is such a thing as a self-extending 
*USRSPC, right? Didn't I just use one for something else?)

--
JHHL