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