[COFF] I think we can get even closer to full duplex on the UTS 3270 device driver

[Adam Thornton via COFF]

So, I've been vibe-coding Yet Another 3270 Emulator, and in so doing, I
watched Moshix's latest video:

https://youtu.be/-NAT_K7ng6A

I then went digging through the tube.h and tube.c code for the UTS (v7)
device driver under VM/370.

I note that NOACTION is defined in tube.h, and is never referenced in
tube.c.

It strikes me that the following might be possible.  Obviously this would
be a terrible, terrible idea on a real System/370 that had dozens or
hundreds of connected users and cost a whole lot of money to acquire and
operate.

But on VM/370 running under Hercules...I mean, who cares?  For me, VM/370
is one of about ten emulated machines running on a single Raspberry Pi 4,
which didn't set me back very much money at all, and running flat out it's
burning five watts, which is also not setting me back very much money at
all, and at most Hercules is going to consume one CPU core emulating a
370/168, and I have four of them.  On top of that, the odds that more than
one person is ever going to be connecting to UTS simultaneously are pretty
low indeed.

So what I'm proposing is a minor variant of the tube driver that sets the
modified bit on input fields, polls the device at some specified frequency
(I don't think I have any way of sleeping for less than a second, although
maybe I can somehow hook SIGCLK and get up to 60Hz, which seems to be the
v7 timer tick)...so that's another question: how best to implement
subsecond waits in v7?)  (hence, my proposed name is "hottube"), and (as
Moshix's code does), if the AID comes back 0x60 (NOACTION) but the current
contents of the read field are different than the stored contents of the
field, repaints that field and updates the current contents.

I think that would give you *very* nearly true full-duplex on a 3270
terminal under UTS.

Mostly I want to know from Tom Lyon why, above and beyond burning an
enormous number of processor cycles to continually scan the input fields
for each attached hottube device, this is a stupid idea, but I also want to
know, am I missing something else architectural here, or would this
probably work if I don't mind burning those cycles?

Adam