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

[Stephen Hoffman]

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