David Boyes wrote:
That generates an interrupt in the host, and then the host issues a
read.
This kind of approach, where the terminal generates an interrupt for
each key-press, wouldn't be so expensive.
I beg to differ. I/O interrupts on a 390 are *unbelievably* expensive if
the amount of data transferred is one byte. A LOT of stuff happens --
but, if you limit it to recovery/ermergency work, then there won't be a
lot of such I/O.
everything in the architecture is designed to minimize that happening.
You'd have to have a continuously running channel program to make this
only painful rather than impossibly so. Cf the history of the original
BusTech network adapter and the Lippke driver for it -- the same
physical hardware was literally almost 5 times faster if you didn't use
the 8232 I/O model but a continuous channel program.
Many years ago, I wrote a program to drive some remote 3270 terminals: a
small TP monitor, I used a general poll, and the work was offloaded to
the 3704 running Emulation Program.
At the same time, we had TCAM on our 168s driving a few remote bisync
3270s - the same kind of scenario and so directly comparable, TCAM did
indeed consume great gobs of CPU; I can only imagine it was polling each
defined terminal in turn, and generating small channel programs for the
purpose.
The TCAM approach might give each terminal user predicatable, consistent
responses (as far as line congestion allowed), but there is no way I was
going to do that on a 145.
Running my channel programs (I used EXCP), the CPU was completely idle
until someone pressed their enter key, and the controller responded to
the general poll.
Possibly, the remote controller might have given preference to the
lower-addressed terminals over higher-addressed terminals, but if so,
that didn't matter to us: typical user action would be to type a few
characters, then spend second or minutes dealing with the reponse.
In my experience, a continuously-running channel program isn't a problem
(if the device detaches). The problem I saw arose with TCAM _not_ using
a continuously-running channel program, but rather continuously
regenerating one.
This would require a local controller; perhaps a channel-attached
netvista would do,
We'd need a inexpensive channel adapter first. Not simple or easy. We
also can do it in software, which would be much more attractive.
I haven't any idea of what is available here; I surmise there might be a
PCI card available, but I'm only guessing. There have in the past been
cards one could install in a PC to give it the ability to emulate a
local 3270-style console. One of those, with new programming, might do
the job.
I don't see how it _can_ be done cleanly in software; if I'm sitting at
my (approved) PC at home typing the sorts of stuff Linux expects, what I
want is for my keypresses (as interpreted) to get to the mainframe, byte
by byte.
So far as I have noticed, so far as software implementations go, we've
only discussed crude hacks that occasional sysadmins forget.
What I'm proposing is a proper peripheral that would work as *x expects.
I don't expect it would be used much differently from console devices
that come with mainframes: that is, infrequently and little.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Please do not reply off-list
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
