[Info-vax] Timeout in a write using QUIW.

Jan-Erik Söderholm jan-erik.soderholm at telia.com
Wed Jun 21 17:39:19 EDT 2023


Den 2023-06-21 kl. 23:17, skrev Arne Vajhøj:
> On 6/21/2023 4:45 PM, Jan-Erik Söderholm wrote:
>> When doing a *read* from a terminal device using QIOW, one
>> can use IO$M_TIMED and supply a timeout value in P3. That
>> works perfectly and we use that a lot.
>>
>> Now, we are having issues with an application when *writing*
>> to a terminal (TNA) device using QUIW that points to a small
>> label printer. If the printer is offline or not accessable on
>> the network, the application just hangs.
>>
>> As far as I can see, QIO/QIOW does not support a timeout value
>> when used for writing, is that correct?
> 
> Yes.
> 
> https://vmssoftware.com/docs/VSI_IO_REF.pdf
> 
> Table 5.6 lists IO$M_TIMED for IO$_READ* while table 5.8
> does not list it for IO$_WRITE*.
> 
>> I was hoping that one could add a timeout value just as in the
>> read case, but it doesn't look so. So I do not see how to get
>> out of the hanging call to QIOW. Maybe using QIO, and doing
>> some extra coding to check the I/O, I guess.
>>
>> So, is there a way to get out of this state, still using QIOW?
> 
> Totally untested idea:
> 
> SYS$SETIMR with an AST routine that calls SYS$CANCEL
> 
> Arne
> 
> 

My thought was to just queue the I/O, wait a sec or two
using $WAIT and then check the IOSB. If not completed OK,
CANCEL and return an error to the application...

We'll see. Hopefully we can convince them to install
wired connections instead of using Wifi...

Jan-Erik.



More information about the Info-vax mailing list