|
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
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
