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

[Jan-Erik Söderholm]

Den 2023-06-22 kl. 14:18, skrev Johnny Billquist:
> On 2023-06-22 14:05, Jan-Erik Söderholm wrote:
>> Den 2023-06-22 kl. 13:25, skrev Phil Howell:
>>> On Thursday, 22 June 2023 at 7:36:54 am UTC+10, Jan-Erik Söderholm wrote:
>>>> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>>>>> On 2023-06-21 20:45:12 +0000, Jan-Erik S derholm said:
>>>>>
>>>>>> Now, here is a technical one...
>>>>>>
>>>>>> 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...
>>>>>
>>>>> I've never had great success...
>>>>
>>>>
>>>> I'm sorry about that. As I wrote, it works perfectly. In the
>>>> case of reads, of course, where it is supported.
>>>>
>>>> My question was about writes, and it has been confirmed that
>>>> timeout paramaters are not supported there. Thanks Arne.
>>>>
>>>> Now we need to weight the coding work against getting
>>>> network cables installed to the printers. Wired printers
>>>> will also "solve" the issue with the current code. We have
>>>> 15-20 older similar Zebra label printers, all wired, and
>>>> we do not see these error scenarios with those.
>>>> All using the same C routine for the QIOW calls.
>>>>
>>>>
>>>> Jan-Erik.
>>> While you cannot request a timeout on a WRITEVBLK
>>> you may be able to workaround this by using READPROMPT
>>> With this you get two i/o's in one call,
>>> the first is a write of your "prompt" followed by a read on the same 
>>> channel.
>>> If you set up your "prompt" as the content of your label then do the qio 
>>> call
>>> it should write this to the device, then do the read, which you can 
>>> check or ignore.
>>> If you get a tt_timeout, then wait a bit and retry.
>>> The most concise explanation of this is in wikipedia on the qio page.
>>> The I/O user manual just goes on and on
>>> You may have to increase the size of the typeahead buffer to cater for 
>>> the size of your label
>>> as well as managing all the usual qio stuff like buffer lengths, IOSBs, 
>>> terminator masks, ASTs, etc.
>>>
>>> If I was retiring in a couple of weeks I would recommend cabling up all 
>>> the printers,
>>> but it could be an interesting way of getting your successor to hate you?
>>>
>>> Phil
>>>
>>
>> Hi. That was a nice way of "using" (or "mis-using" ? ) QIOW!
>> I'm actually leaving this place Friday next week, 30 June.
>>
>> Right now, it seems as we'll simply get the printers hard-wired.
>> It is 6 printers that are on Wifi now, and our other 15-20 label
>> printers (all hard-wired) do not show the same error scenario.
> 
> Unless you are expecting some input, won't this mean you *always* get a 
> timeout. So even something that prints, and completes in no time, will only 
> return when the timeout happens.
> 
> Seems the wrong way to go about it. Not to mention you better be sure the 
> read timeout applies even if the write part haven't completed.
> 
> (I much prefer using the same EF for both mark time and read. :) )
> 
>    Johnny
> 

Yes, right. That is a problem.
On the other hard wired printers we simply do a WRITEVBLK.
We have very few issues, since the network is always "up".