On Mon, Jun 4, 2018 at 12:06 AM, Richard Schoen
<Richard.Schoen@xxxxxxxxxxxxxxx> wrote:
I guess I was able to say it in one short post 😊
I said the same thing in three posts because people seem not to read
all the posts, or they don't understand it the first two (or three or
more) times.
Also less layers. No data queue or iToolkit plumbing or polling which is what it sounded like you were advocating. Synchronous real-time.
I was not advocating data queue. Go back and read my very first post.
The first thing I mentioned was IFS stream file, because that requires
no additional infrastructure on the Python side, and most midrangers
seem to be reasonably comfortable and familiar with dealing with them.
The second thing I mentioned was a database table, and I can't imagine
a single midranger who can't deal with that.
STDOUT sends feedback directly to an IFS or OUTFILE which the RPG app can simply read immediately once the Python call completes.
What you seem to be missing from all of my previous posts is: How does
the RPG app know when the Python call completes?
Buck didn't seem to be embracing either the stream file or database
table idea wholeheartedly, and the reason is that he was thinking in
terms of a call with output parameters or a return value, where the
caller simply hangs until the callee returns. If the data is coming
back in a stream file or database table, or indeed ANYTHING other than
output parameters or a return value, the caller has to do SOMETHING to
fetch that data, because it's not an intrinsic part of the call
mechanism.
I only brought up data queues because that is one way in which I
figured RPG programmers would be able to retrieve the data *in
principle* as soon as the data was available. I am not completely sure
I was right about that, since I don't use data queues myself. I was
under the impression that you could basically put yourself in a
data-queue-wait status. In other words, hang until the data queue
isn't empty, and the instant that it's not empty, fetch the data. That
way, you simultaneously find out when the callee has completed and
pick up the data produced by the callee. If data queues cannot be used
in this way, then I don't recommend them.
John Y.
midrange.com
