Re: Using a timeout with display files

Javier,

Just fyi, I tested DSM APIs with a DDS file and sleep() to have it timeout, and posted the code at

https://code.midrange.com/426e55b724.html

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /

On 8/15/2021 3:04 PM, Javier Sanchez wrote:

Francois:

Thanks for your comments. I am actually trying to achieve this using ONLY
the DSM API set, no DDS at all. This is because you can always create the
actual display screen by hand (although tedious of course) and then I'll
try to combine the different input operations. All of what I've been
reading on this subject doesn't tell me anything about how to connect DDS
with DSM API's but I bet it's possible.

Since there is no DDS, you have to construct a low-level environment where
all the parameters like the INVITE keyword equivalent and also the time-out
value are set with the QsnCrtEnv (Create Low-level Environment) API.

I've been dealing with the DSM documentation, but this is barely the API
prototypes and the several data structures and constant values that these
use. There are no significant examples and what I've found on the Web is
also poor material. I'll have to wrap up my sleeves and try.

What I've read until now is that the QsnReadInvited API has to be issued in
combination with another AID-generating input Read. So that when the
latter Read fails and times-out, it's the former which informs the
timeout. Since the input buffer is still there, that's the right moment to
invoke the *QsnReadImm* API which is a non-AID-generating read input from
the screen, and that should probably bring me the data that I'm expecting:
the one the user may have typed in.

I'm still writing a test program to do that. I will share with you guys my
results.

Thank you Jon Paris also for your recent comments about the subject.
Regards.

message: 1
date: Wed, 11 Aug 2021 17:26:23 +0000
from: Francois Lavoie <Francois.Lavoie@xxxxxxxxxxxxxxxxxxxx>
subject: RE: Using a timeout with display files

DDS manual says:
" On a read operation from invited devices operation to a display file,
only data from devices with an
outstanding invite operation are considered. The input operation waits for
data from any of the invited
devices. (See the WAITRCD parameter on the Create Display File (CRTDSPF)
and Change Display File
(CHGDSPF) commands.) If none of the invited devices responds before the
wait time ends, a notify
message is sent and no data is returned."

So, no data is returned when the notify message (Status=1331) is sent

------------------------------

message: 3
date: Wed, 11 Aug 2021 17:46:20 +0000
from: Francois Lavoie <Francois.Lavoie@xxxxxxxxxxxxxxxxxxxx>
subject: RE: Using a timeout with display files

Maybe if you put an indicator on the INVITE keyword
You 1st set it ON, then READ dspf
If timing out (Status-1331) then you set INVITE indicator OFF and re-READ
dspf
*Maybe* (didn?t test it) that would return any data typed by the user