Richard Troth wrote:
The key is to know ANSI X3.64 and get the applications to more fully
support it.
John Mckown wrote:
I've read a lot here about people wanting to use vi or some other
application which is "full screen" from the "Linux console". The reply
is always that the "Linux console" cannot be used in the manner. Now,
back in the deep, dark past, I remember a product that we had on VM/370
(yes, that long ago!). This was a software protocol converter which
allowed a "start-stop" or async terminal, such as a VT-100, to logon to
a service machine (via NCP/NTO). This service machine would then use
VM's LDC (?) to create a 3270 session and it would convert the 3270
control sequences to VT-100 control sequences.
Troth writes:
Arty Ecock wrote a TNVT100 program for CMS which lets one TELNET from z/VM
to, say, Linux. I seem to remember that he said it was a difficult
project and that in practice it doesn't work as well as one would hope.
Still, I love this thing! It's ... er, uh ... "elegant".
Now ... the protocol conversion you describe above is going the other way.
That's talking about plugging in a byte-at-a-time terminal into a
block-mode service. That's the easy way, ala TN3270 and ye olde 7171.
Going the other way is the tough trick. (And I know you know it's
reverse. I'm just stating that it is harder to do.) But it can be done.
In my relative youth, I wrote an application that used remote 3270s
(we're talking bi-sync here), using EXCP. Part of the application (ir
was really a basic TP monitor) provided the means to use enquiry
programs written in COBOL, hiding all the 3270 stuff from the programs.
As you might guess, I got fairly close to the protocol as it goes over
the wire, along with driving your actual 3270 screens.
As part of the project I got to advise the block writing the network
software, we didn't have real 3270s, they were async glass teletypes. In
ASCII, so I had to handle EBCDIC screens (local and remote, the ones I
had to practice with) plus remote ASCII 3270s.
The 3270 emulation took a while - basically it's equivalent to writing
slushware for the screne itself plus for the controller, but its
moderately straightforward.
To support 3270 terminals in Linux, we'd need SNA (for SNA terminals)
and/or bisync. I don't know how long the SNA would take (or even if its
already available), but I guess the bi-sync implementation would be
about what I did: not a huge task, and something I could do comfortably
in Hercules _iff_ I have a (emulated) 2701 controller. I don't know that
Herc does that.
The problem is everone's favourite Linux applications. They all expect
to see each keypress as it's made. Run lynx, type "/" and it immediately
responds. Ditto vim, emacs, links, mutt, pine.
Would you be happy using a 3270 if every second keypress is <ENTER>?
My suggestion:
If possible, use a PC running Linux. Use z3270 to talk to VM, zOS etc.
Use ssh to talk to zLinux, X if you're comfortable doing that.
If not that, then Windows on your peecee, a 3270 emulator and putty.
If you're stuck with 3270s, talk about reequipment:-)
btw rdesktop does a fine job getting a Windows desktop onto a Linux
peecee. I use it regularly.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
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
