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

The problem is less the expense than that IBM is pushing very hard to
get people to FICON (with good reason). Most big shops have done the
forklift upgrade to FICON and don't HAVE any ESCON left (or are trying
to get rid of it ASAP). The smaller shops would find that fairly pricy. 

> >>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 wasn't aware there were controller devices that would connect to a PC
other than a 7171. In that case, wouldn't you need both channel and coax
adapter? Or were you thinking of something like MS SNA Server that just
front-ended a single DFT connection?

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

No, sorry... old VM term. VM/PASSTHRU, aka PVM (for Passthru Virtual
Machine). 

> How does this help when your network's down?

PASSTHRU provided a multisession terminal connection between systems
that handled session multiplexing over single links without requiring a
functioning network protocol (either IP or SNA). It could be used over
CTC, SNA, IP -- pretty much anything you could lash into a way to
transmit bits from system A to system B. Someone even did a PVM line
driver that worked over RSCS links. 

In the old days, you connected to PVM via DIAL, then you got a nice menu
to select which system you wanted to connect to. You hit a key or typed
a system name, and PVM connected you to that system. 

Key point is that other than the line discipline and setup sequence for
the PVM link, PVM doesn't care what the contents of the sessions it
carries are. It could be ASCII bytestreams -- they'll get segmented up
into PVM packets for transmission, but that's no worse than IP
networking (example: someone wrote a RSCS NJE driver to work over a PVM
session). Also, if one used the PVM TCP link setup, a participating PVM
implementation could be written on Linux, which would give you all the
SSH and Kerberos and telnet goodies that you'd want in your front end.
The Linux console driver would need to be modified to bring up a PVM
link and session (and PVM would need to be installed), but that would be
relatively minor surgery, and we don't need any hardware at that point. 

PVM was also relatively cheap -- a few hundred dollars even at the worst
of times. Since it's necessary for other things (like CSE) to work,
there is a case to be made that IBM should incorporate it into the z/VM
base similar to how TCPIP was added. If that were to happen, and we did
the work needed to provide the console driver and link management mods,
and the proxy server out in Linux land, then there's the console problem
solved. 

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

Reply via email to