RE: Keep alive problems with RF devices

Rick,

<snip>
------------------------------------
No way!  I've never heard of overriding anything to a dataqueue. that's
pretty cool.

so, let me get this strait.  Do you retrieve the screen input fields via
the dataqueue?  how so:  Is the maxlength of 80 the length of the display
file input buffer?  Do you then have to move the dtaq data into your screen
record format?

Could you alternatively write the dspf output buffer to a dtaq?

inquiring minds want to know.  I'm not sure what I could use this for right
now, but knowing it's available could turn the hampster wheel in the
future.
<end snip>


This is where things get "odd".

What basically happens when you attach the dataq to the dspf is it will
write
them both out at the same time; the dataq has a timer on it to send data to
the
program at a specified time out value.

The program reads the dataQ, which updates either on the time out value, or
when
I/O occurs for the displayed screen.

In your program you must check the dataq length parm, if it is equal to 0
(zero),
then the screen/dataq timed out, otherwise you must READ your screen record
into
your program, and process as normal.

As for length - I used 80 more out of habit more then anything else (though
it should be
as big as your i/o fields on your dspf.
There is no moving of data from the dataq to the "screen fields" in the way
I have
written may application - though you could.

It is possible to write the data out to the dataq  - years ago, and sadly I
have lost
the code over the years, I wrote a battle ship program that used dataq's to
transmit
the moves and hit/miss information between two players (each having a copy
of the program
running for themselves) That way each program "waited" until the other
player performed
an i/o operation to send a strike out.  It was a fun little game and taught
myself
many things; now remember, this was way back, the AS/400 had only been out
for a year or
so when I did this, and coming from a S/36 - my boss let us go
"un-restrained" for 30
days to get to know the OS and what we could do.

The "cool" thing with dataqs is that you can set programs to wait on each
other, and not
burn up cpu time cycling and waiting for some action/file/data area to be
updated.
The time to wait "parm" is liken to the dlyjob command that you "normally"
use in c/l -
except it will allow the job to continue immediately when information had
been placed
in the dataq. (other things I have seen will check a data area, do a dlyjob
for 5 minutes,
and cycle back)

HTH
Mark A. Manske