[Info-vax] DCL "READ/TIME_OUT=n" from terminal; timer resets if message written to screen

[John Wallace]

On 24/05/2021 15:05, Dave Froble wrote:
> On 5/24/2021 8:45 AM, Simon Clubley wrote:
>> On 2021-05-22, gah4 <gah4 at u.washington.edu> wrote:
>>>
>>> Seems to make some sense to me.
>>>
>>> If you are supposed to type something, and get interrupted, you 
>>> should get
>>> extra time.  Especially if you have to read and process the message that
>>> came out.
>>>
>>
>> Why ?
>>
>> You are just typing what you have already decided to type.
>>
>> To implement it in the way VMS does just leads to the problems the
>> OP is currently experiencing.
>>
>> Simon.
>>
> 
> There is the speculation that the timer AST was queued to allow time for 
> user entry.  That might not always be the case.  Likely on a read from 
> terminal in DCL.
> 
> My "normal" usage of timer ASTs is that I want to allow some time for 
> something to happen, and if it doesn't, move on.  No speculation on 
> anything, just stop waiting and move on.
> 

My speculation suggests that the observed controversial behaviour 
results from the intentional behaviour of the read_with_prompt QIO (or 
equivalent) when used with the optional timeout. This helpfully attempts 
to treat the prompt for input and the reading of the input as a 
relatively atomic operation.

One reason for doing so might be that in a multi-tasking environment 
with more than one program using a particular terminal, it can remain 
reasonably simple to work out who is prompting and who will get any input.

Once upon a time it might even have been a "security(ish)" feature - how 
do I know which program/whose prompt is going to get my input? I hit 
control-R. Obviously security has changed since then, as have lots of 
other things.

For what it's worth, I suspect this behaviour goes back at least as far 
as RSX11.

Don't like the way it behaves? Try something different; plenty options 
to choose from :)


See also e.g. https://en.wikipedia.org/wiki/QIO#IO$_READPROMPT