David Boyes wrote:
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.
Which takes us back to my original argument that if you use the console
only to get the network back up -- which does not require any
byte-oriented stuff -- then you don't need the console any more, and the
whole thing is irrelevant.
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.
My point, better put. Generating a new channel program per byte request
is painfully slow and resource intensive.
and unnecessary, especially if you use a local device. See my followup.
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's only one manufacturer, and only for ESCON, not FICON. Channel
adapters are about US $6000, by the time you get drivers, etc for them.
_I_ don't know whether Fortune 500 finds that expensive. When we bought
out 168s, we might not have (back then the $US was only worth about 70c).
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.
Via coax, yes. You still needed a 3x74, which puts us back in the
host-doesn't-see-the-keystroke model.
Is that a controller device? I'm suggesting the PC connect as a
controller. Unfortunately, we're on my wrong reply:-(
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.
Thus my suggestion for using PVM. If we really need to solve this
PVM??
This?
Name : pvm Relocations: (not relocatable)
Version : 3.4.4 Vendor: Red Hat, Inc.
Release : 21 Build Date: Fri 25 Jun 2004
04:03:13 WST
Install Date: (not installed) Build Host:
tweety.build.redhat.com
Group : Development/Libraries Source RPM: pvm-3.4.4-21.src.rpm
Size : 6478892 License: freely distributable
Signature : DSA/SHA1, Thu 21 Oct 2004 01:39:06 WST, Key ID
b44269d04f2a6fd2
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://www.epm.ornl.gov/pvm/pvm_home.html
Summary : Libraries for distributed computing.
Description :
PVM3 (Parallel Virtual Machine) is a library and daemon that allows
distributed processing environments to be constructed on heterogeneous
machines and architectures.
[EMAIL PROTECTED] squid]#
How does this help when your network's down?
problem, there has to be some packetization going on somewhere to
circumvent the byte-banging-kills-us problem. The PVM line protocol is
relatively efficient, and while it might be a bit jerky, we can pick the
individual characters out of the incoming stream and respond fairly
elegantly w/o constant polling, eg. it would allow presenting a
byte-oriented function w/o making the machine do byte-oriented I/O.
----------------------------------------------------------------------
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
--
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
