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. > I'm curious if something similar could be done for Linux. That is, have > the "Linux console" be defined as CONMODE 3270 in the guest's VM > directory. Now, have a "device driver" which could do a reverse 3270 > protocol conversion. That is, make the 3270 appear as a VT-100 (or > subset). The application would use VT-100 escape sequences. The device > driver would convert these to 3270. Right, so you want "reverse 3270 protocol conversion". Aptly named. I'm really quite fond of the idea, delighted to hear from a kindred spirit! This can be done. Arty's tool proves that it can be done, and I suggest that apps can be re-trained to get from "can do" to "can do well". > I will grant that emulating the "full duplex" ability of the VT-100 and > "control keys" would make this difficult. But z/OS DIDOCS emulates a > "full duplex" capability on a 3270, so it should be possible. Well, to > those who are smart enuf (I'm not!). Don't sell yourself short, John! You no doubt have enuf brains to get er done. Years ago I hacked some simple C code to take ANSI X3.64 escape sequences (the foundation of the VT100 you mentioned) and drew ASCII output on a physical 3270. This was with UTS, another Unix for mainframe hardware (and a slick piece of work!). The UTS guys have contributed their driver to Linux, so the same trick could be done in Linux land: reverse protocol conversion. But I only did output. The tough part is input. Arty got further (and did it with REXX) and he made it work both directions. But the remaining problem is still there, getting those byte-at-a-time applications to accept block-mode input. Hard to explain. Consider YaST: If you could sweat talk SuSE into having YaST grow an appetite for function key input in addition to its current keystroke diet, the reverse protocol conversion would boil down to the simplest of filters. Picture this: YaST uses ncurses to draw a screen full of options. Today, you hit <TAB> and use cursor keys to make your selections. But if YaST would also allow F-key input for its actions, and have better pull-down support for that, hey! It would do right nicely! ASCII apps don't need to know 3270 datastreams, they just need to tolerate block-mode operation as alluded to in ANSI X3.64. (Where did I put that VT220 doc? Boyes must have swiped it!) ;=) -- R, ---------------------------------------------------------------------- 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
