Re: Using a timeout with display files

[Peter Dow <petercdow@xxxxxxxxx>]

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