Re: More specifics Re: Something lighter than a database file . . . -- MIDRANGE-L

Hi James

I'm still a little bit in the dark on a few aspects of what you aretrying to do, particularly around what you are wanting the key do foryou. If the key is simply to prevent duplicate entries does this meanyou will never retrieve by key ? What method are you using togenerate the keys that could cause a duplicate, and what is theeffect of a duplicate on your processing ?


Having said that it seems to me that a possible answer is:

Use a user index to track the keyed items (and whatever else you needto know about them).

Use a plain old data queue to process the transactions in arrival sequence.

Regards
Evan Harris

 a.m. 8/03/2006, you wrote:

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