I searched but didn't find this mentioned anywhere...

If I do this:

$ READ/TIME_OUT=10 SYS$COMMAND FOOBAR

And while the READ is waiting for me to respond to it, if someone sends a REPLY message to my screen, or if I have a subprocess running that sends some output to my screen, the ten second timer restarts at zero again.

I tested this with a subprocess that just shoots out a message every 9 seconds, and the ten-second READ *never* timed-out.

Tried this on OpenVMS Alpha V7.3-2 and V8.4-2L2, same result.

Anyone else encounter this before? Documented somewhere? Bug? Feature? Etc...

The motivation behind this: During startup, a command procedure asks the operator a few questions; if an operator isn't there, the questions time-out and default answers are assumed. BUT - the timeout is currently set to 60 seconds, and there's a fairly constant stream of OPCOM messages coming to OPA0:, and those messages usually come more frequently than once a minute. End result, the questions never time out and the system never finishes startup.

Yes, I know that other solutions are possible. Shortening the timeout, suppressing the OPCOM messages, etc. But at this point I just want to know if this is "the way it's supposed to work" or not!

Scott

On 2021-05-21, Scott Snadow <scott@snadow.com> wrote:
> I searched but didn't find this mentioned anywhere...
>
> If I do this:
>
> $ READ/TIME_OUT=10 SYS$COMMAND FOOBAR
>
> And while the READ is waiting for me to respond to it, if someone sends a REPLY message to my screen, or if I have a subprocess running that sends some output to my screen, the ten second timer restarts at zero again.
>

Now that is a new one on me. :-)

I wonder if this is just a DCL problem or if it's a general terminal
driver problem.

To solve your immediate problem, can you spawn/nowait a subprocess, stall
the main process for about 3-5 minutes, ask the questions in the subprocess,
and then kill the subprocess if the subprocess is still running when the
main process resumes execution ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Scott,

this is expected and documented behaviour. It has nothing to do with DCL.

https://vmssoftware.com/docs/VSI_IO_REF.pdf

Table 5.6. Read QIO Function Modifiers for the Terminal Driver

IO$M_TIMED ...
If a read operation is interrupted by either a broadcast write or a synchronous write request, the timer operation is restarted.

Volker.

On Saturday, May 22, 2021 at 2:13:33 AM UTC-5, Volker Halle wrote:

> this is expected and documented behaviour. It has nothing to do with DCL.
>
> https://vmssoftware.com/docs/VSI_IO_REF.pdf
>
> Table 5.6. Read QIO Function Modifiers for the Terminal Driver
>
> IO$M_TIMED ...
> If a read operation is interrupted by either a broadcast write or a synchronous write request, the timer operation is restarted.

Look at that. It *IS* documented! Thanks Volker for pointing me to that. It also makes sense that it's buried inside of the terminal driver and not in DCL, since I couldn't imagine that DCL would actually be coded to be aware of incoming writes to the terminal from other processes.

VSI, if you're reading this, a documentation enhancement request: Please mention this in the DCL Manual and also in "HELP READ /TIME_OUT" since a casual DCL programmer probably wouldn't be perusing the I/O User's Reference Manual very often!

Scott

On 5/22/2021 11:11 AM, Scott Snadow wrote:

> VSI, if you're reading this, a documentation enhancement request: Please
> mention this in the DCL Manual and also in "HELP READ /TIME_OUT" since a
> casual DCL programmer probably wouldn't be perusing the I/O User's Reference
> Manual very often!

Noted.

I'll pass it along to the doc team.

--
-- Rob

On 5/22/2021 11:18 AM, Robert A. Brooks wrote:
> On 5/22/2021 11:11 AM, Scott Snadow wrote:
>
>> VSI, if you're reading this, a documentation enhancement request: Please
>> mention this in the DCL Manual and also in "HELP READ /TIME_OUT" since a
>> casual DCL programmer probably wouldn't be perusing the I/O User's
>> Reference
>> Manual very often!
>
> Noted.
>
> I'll pass it along to the doc team.
>

Ok, the pest is about to possibly show his ignorance.

:-)

All my uses of a timer AST has been with a delta time. All I've ever
needed. But consider:

SUBMIT/AFTER=????

Where ???? is an absolute time. I'm not aware of a timer AST being able
to use an absolute time. Can it? If not, what can?

Curious, not in need.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/22/2021 4:14 PM, Dave Froble wrote:
> All my uses of a timer AST has been with a delta time.  All I've ever
> needed.  But consider:
>
> SUBMIT/AFTER=????
>
> Where ???? is an absolute time.  I'm not aware of a timer AST being able
> to use an absolute time.  Can it?  If not, what can?
>
> Curious, not in need.

Docs says:

<quote>
$SETIMR
Set Timer — Sets the timer to expire at a specified time. On Alpha and
Integrity server systems, this service accepts 64-bit addresses.

Format
SYS$SETIMR [efn] ,daytim ,[astadr] ,[reqidt] ,[flags]
....
daytim
OpenVMS usage: date_time
type: quadword
access: read only
mechanism: by 64-bit reference (Alpha and Integrity servers)
Time at which the timer expires. The daytim argument is the 64-bit
address (on Alpha and Integrity
server systems) of a quadword time value. A positive time value
specifies an absolute time at which
the timer expires; a negative time value specifies an offset (delta
time) from the current time.
</quote>

Arne

On 2021-05-22 15:18:02 +0000, Robert A. Brooks said:

> On 5/22/2021 11:11 AM, Scott Snadow wrote:
>
>> VSI, if you're reading this, a documentation enhancement request:
>> Please mention this in the DCL Manual and also in "HELP READ /TIME_OUT"
>> since a casual DCL programmer probably wouldn't be perusing the I/O
>> User's Reference Manual very often!
>
> Noted.
>
> I'll pass it along to the doc team.

Referring to the current behavior as "documented" as per a previous
posting here is, well, generous, and calling this behavior appropriate
yet more generous.

Who here thinks that a broadcast should reset an input timeout timer?
Principle of least surprise and all.

At least with a $qio or $io_perform and a timeout, I can (mostly) avoid
that get-interrupted-and-the-timer-resets mess.

BTW, one of the safer approaches for dealing with this within an app is
to first set an "ignore" flag (interlocked bitlock) somewhere and
either let the $qio or $io_perform AST fire, or set the flag and issue
a $cancel.

OpenVMS lacks means to fire off a thread save via an AST, and the
queuing is necessarily home-grown within the app. But I digress. For
those that haven't looked into it and are working with asynchronous
processing (on other platforms), FRP can get interesting here, too.

--
Pure Personal Opinion | HoffmanLabs LLC

On Friday, May 21, 2021 at 10:14:53 AM UTC-7, sc...@snadow.com wrote:
> I searched but didn't find this mentioned anywhere...

> If I do this:

> $ READ/TIME_OUT=10 SYS$COMMAND FOOBAR

> And while the READ is waiting for me to respond to it, if someone sends a REPLY
> message to my screen, or if I have a subprocess running that sends some output
> to my screen, the ten second timer restarts at zero again.

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.

Is there a way to turn off such messages? All except the most important?

On 2021-05-23 00:05:03 +0000, gah4 said:

> 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.
>
> Is there a way to turn off such messages? All except the most important?

Page 8-4ff in the old OpenVMS FAQ: http://hoffmanlabs.com/vmsfaq/vmsfaq.pdf

Page 27ff in the doc:
https://vmssoftware.com/docs/VSI_SYS_MGMT_MANUAL_VOL_I.PDF

The few console messages that can't be blocked, well, can't be blocked.
Search for details of the PAGEFRAG and PAGECRIT messages, there.

The OPCOM messages, send that chatter somewhere else other than the
console, if you need to have that chatter logged somewhere other than
OPERATOR.LOG.

--
Pure Personal Opinion | HoffmanLabs LLC

On Saturday, May 22, 2021 at 5:24:40 PM UTC-7, Stephen Hoffman wrote:

(snip)

> The few console messages that can't be blocked, well, can't be blocked.
> Search for details of the PAGEFRAG and PAGECRIT messages, there.

Are we talking about the console or ordinary user terminals.

I remember some systems, maybe TOPS-10, VMS, and Unix, that allow one to
write to any terminal. Maybe also supply a special command for doing it.
I haven't actually thought about it recently, though.

But I think also have the ability to block them, at least ones from
ordinary users.

On 23/05/2021 10:56, gah4 wrote:
> On Saturday, May 22, 2021 at 5:24:40 PM UTC-7, Stephen Hoffman wrote:
>
> (snip)
>
>> The few console messages that can't be blocked, well, can't be blocked.
>> Search for details of the PAGEFRAG and PAGECRIT messages, there.
>
> Are we talking about the console or ordinary user terminals.
>
> I remember some systems, maybe TOPS-10, VMS, and Unix, that allow one to
> write to any terminal. Maybe also supply a special command for doing it.
> I haven't actually thought about it recently, though.
>
> But I think also have the ability to block them, at least ones from
> ordinary users.
>
>
SET BROADCAST

--
Chris Townley

On 2021-05-23 09:56:51 +0000, gah4 said:

> On Saturday, May 22, 2021 at 5:24:40 PM UTC-7, Stephen Hoffman wrote:
>
> (snip)
>
>> The few console messages that can't be blocked, well, can't be blocked.
>> Search for details of the PAGEFRAG and PAGECRIT messages, there.
>
> Are we talking about the console or ordinary user terminals.

There are terminal broadcasts which can arise from system services or
via REPLY /TO, there are kernel broadcasts from device drivers and the
kernel, and there are OPCOM-related broadcasts.

The kernel broadcasts are high-IPL last-ditch calls, of which PAGEFRAG
and PAGECRIT are two currently-ill-documented messages, and these two
messages are sent only to the console.

There are a few others. In one project decades ago, I had the device
driver detect and send a message to the console when the device
hardware interrupt vector setting was wrong. There are a few other
examples around.

OPCOM generates an endless buffet of chatter and—outside of those few
sites unfortunately still using actual tape or disk operators still on
the console—are messages rather less than useful for ordinarily
enabling to the console.

And yes, automating some of the OPCOM processing is possible, as is
central collection, but, well, kinda ugly at best. OPCOM itself was
seemingly overdue for an overhaul for Y2K (easier automation, easier
syslogng-style central collection, etc), yet here we are.

The SET BROADCAST command controls the broadcast path, and is a
less-than-preferred but functional means for controlling arriving OPCOM
messages.

OPCOM messages are more commonly controlled using the OPC$* logical
names previously linked, or the older and less-preferred
logical-name-redirection-REPLY command.

The kernel/driver broadcasts for PAGEFRAG and PAGECRIT are
approximately undocumented at VSI at present, not sure what's up with
that. Whether those are now gone from OpenVMS, or "just" gone from the
doc?

> I remember some systems, maybe TOPS-10, VMS, and Unix, that allow one
> to write to any terminal. Maybe also supply a special command for doing
> it. I haven't actually thought about it recently, though.

On OpenVMS, PHONE and REPLY (REPLY /TO, REPLY / ALL, etc) were the
usual commands for that.

On some other systems, messages to the local network were also feasible
at different times with (for instance) the /net send/ command of
Windows.

> But I think also have the ability to block them, at least ones from
> ordinary users.

Most messaging mechanisms do have that, as unrestricted messaging
mechanisms tend to become fodder for harassment.

OPCOM was always less than useful to the console, as it drowns out
other and vastly more important traffic sent to the console device. The
whole of the OpenVMS startup is just hilariously bad, if you look at it
from the perspective of what info you need to the console, and what you
don't. The self-tests and the rest are utter rubbish—absent errors—and
the same holds for the OpenVMS and site-specific startups. Linux has a
vastly better and cleaner design for what is a detailed and
still-chatty startup, and other systems have other less-chatty designs.
What do we care about in a startup as system managers, other than
continued progress to app readiness, and any actual hardware or
software or network errors? More experienced system managers tend to
reduce the startup chatter, too. But by default, the OpenVMS startup is
just hilariously bad. But I've grumped about the startup before, and I
digress. OPCOM is a big contributor to console chatter.

And I don't think that resetting a terminal timeout timer is a
reasonable behavior. That read should time out based on (lack of) user
input (read), not on commonly-unrelated terminal output (write).

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-05-22, Volker Halle <volker_halle@hotmail.com> wrote:
> Scott,
>
> this is expected and documented behaviour. It has nothing to do with DCL.
>
> https://vmssoftware.com/docs/VSI_IO_REF.pdf
>
> Table 5.6. Read QIO Function Modifiers for the Terminal Driver
>
> IO$M_TIMED ...
> If a read operation is interrupted by either a broadcast write or a synchronous write request, the timer operation is restarted.
>
> Volker.

What could the point of that behaviour possibly be ???

This sounds to me like someone added timeout support to the terminal driver,
found a bug where the timer gets reset on terminal writes, could not find
a way to easily fix it, so they ended up documenting the bug as expected
behaviour. :-)

If that wasn't the case, and this was actually intended behaviour, then
what could the reasoning for this behaviour possibly be ?

And before everyone jumps on me, just remember that we talking about
a driver that is apparently so convoluted internally that adding code
to allow editing of lines longer than the terminal width is apparently
not viable to do (even though you can do this just fine on other operating
systems).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-22, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> Who here thinks that a broadcast should reset an input timeout timer?

Never. It's utter nonsense to think it should. That timeout was given by
the programmer for a reason.

> Principle of least surprise and all.
>

Well, it's certainly something I didn't know about.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-22, gah4 <gah4@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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/24/2021 8:39 AM, Simon Clubley wrote:
> On 2021-05-22, Volker Halle <volker_halle@hotmail.com> wrote:
>> Scott,
>>
>> this is expected and documented behaviour. It has nothing to do with DCL.
>>
>> https://vmssoftware.com/docs/VSI_IO_REF.pdf
>>
>> Table 5.6. Read QIO Function Modifiers for the Terminal Driver
>>
>> IO$M_TIMED ...
>> If a read operation is interrupted by either a broadcast write or a synchronous write request, the timer operation is restarted.
>>
>> Volker.
>
> What could the point of that behaviour possibly be ???
>
> This sounds to me like someone added timeout support to the terminal driver,
> found a bug where the timer gets reset on terminal writes, could not find
> a way to easily fix it, so they ended up documenting the bug as expected
> behaviour. :-)
>
> If that wasn't the case, and this was actually intended behaviour, then
> what could the reasoning for this behaviour possibly be ?
>
> And before everyone jumps on me, just remember that we talking about
> a driver that is apparently so convoluted internally that adding code
> to allow editing of lines longer than the terminal width is apparently
> not viable to do (even though you can do this just fine on other operating
> systems).
>
> Simon.
>

Well, Ok, perhaps time for some "devil's advocate" ...

There might be circumstances where if an AST on "something" is
triggered, timer ASTs also get triggered/deleted.

Having written that, it's not something I'd want ...

Which might lead to the question of "how does a timer AST get triggered?"

No source code, so some speculation. A timer AST using a delta time
probably checks the current time, add the delta time, and sets an AST
for the calculated actual time. If so, then the absolute time for the
timer AST to trigger is known (to something), and so I'd ask, why isn't
the timer AST reset using the actual time to trigger?

Just wondering why it's implemented as it currently exists ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/24/2021 8:45 AM, Simon Clubley wrote:
> On 2021-05-22, gah4 <gah4@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.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Monday, May 24, 2021 at 10:04:49 AM UTC-4, Dave Froble wrote:
> 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.
> --

I imagine read/time_out=... is using the timeout feature of the terminal driver
and not timer ASTs. The timeout is a feature of the wait for interrupt function
in the kernel, which is why it resets for every character entered (as well as
breakthru writes).

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@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

On 2021-05-24, David Jones <osuvman50@gmail.com> wrote:
>
> I imagine read/time_out=... is using the timeout feature of the terminal driver
> and not timer ASTs. The timeout is a feature of the wait for interrupt function
> in the kernel, which is why it resets for every character entered (as well as
> breakthru writes).

_If_ that is the case, then the read timeout functionality is broken
IMHO because that is _very_ unexpected behaviour.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Monday, 24 May 2021 at 14:12:55 UTC-4, Simon Clubley wrote:
> On 2021-05-24, David Jones <osuv...@gmail.com> wrote:
> >
> > I imagine read/time_out=... is using the timeout feature of the terminal driver
> > and not timer ASTs. The timeout is a feature of the wait for interrupt function
> > in the kernel, which is why it resets for every character entered (as well as
> > breakthru writes).
> _If_ that is the case, then the read timeout functionality is broken
> IMHO because that is _very_ unexpected behaviour.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

I would put forth the following possibility:

What happens if the number of "messages" is sufficient to prevent the input of a response to the initial question posed to the user? In this case, the input will fail due to lack of input which may revert the system to an unwanted state. While this is not likely to happen, perhaps this is what was in mind when the timer was reset.

We can't know what prompted this behavior (pun intended). However, after 40 years of working this way, we can't know if there are programs or procedures that depend on this behavior.

On 5/24/2021 11:31 AM, David Jones wrote:
> On Monday, May 24, 2021 at 10:04:49 AM UTC-4, Dave Froble wrote:
>> 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.
>> --
>
> I imagine read/time_out=... is using the timeout feature of the terminal driver
> and not timer ASTs. The timeout is a feature of the wait for interrupt function
> in the kernel, which is why it resets for every character entered (as well as
> breakthru writes).
>

Thank you David, I was not aware the terminal driver had that timeout
feature. That does explain much.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/24/2021 2:12 PM, Simon Clubley wrote:
> On 2021-05-24, David Jones <osuvman50@gmail.com> wrote:
>>
>> I imagine read/time_out=... is using the timeout feature of the terminal driver
>> and not timer ASTs. The timeout is a feature of the wait for interrupt function
>> in the kernel, which is why it resets for every character entered (as well as
>> breakthru writes).
>
> _If_ that is the case, then the read timeout functionality is broken
> IMHO because that is _very_ unexpected behaviour.

I don't agree with what you wrote. Yes, I'd prefer a bit different
operation, but, I can understand and accept what's there. Maybe could
be better, but, not broken.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/24/2021 7:53 PM, Dave Froble wrote:
> On 5/24/2021 2:12 PM, Simon Clubley wrote:
>> On 2021-05-24, David Jones <osuvman50@gmail.com> wrote:
>>> I imagine read/time_out=... is using the timeout feature of the
>>> terminal driver
>>> and not timer ASTs. The timeout is a feature of the wait for
>>> interrupt function
>>> in the kernel, which is why it resets for every character entered (as
>>> well as
>>> breakthru writes).
>>
>> _If_ that is the case, then the read timeout functionality is broken
>> IMHO because that is _very_ unexpected behaviour.
>
> I don't agree with what you wrote.  Yes, I'd prefer a bit different
> operation, but, I can understand and accept what's there.  Maybe could
> be better, but, not broken.

I agree.

Not only is it what's there.

As it turned out then it is actually documented behavior.

Actual behavior is expected to follow documented behavior.

It is almost guaranteed that there will be some functionality
where ones expectation without reading the documentation is
different from actual behavior.

Arne