[comp.protocols.tcp-ip] TN3270 on Terminal Servers

chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) (03/05/88)

An open letter to all those involved in the design of TCP/IP terminal
servers...
Is there some logical reason why none of the currently available TCP/IP
terminal servers do not employ a TN3270 mode? I have long thought this
would be a major selling point, now that the IBM 'frame environment is
becoming an ever-present player in the scheme of interoperability. I am
fully aware of the "cpu hog" nature of the 3270 to ASCII conversion but,
let's face it, we've got some pretty capable CPU chips in these boxes.
Am I the only one who sees that the need has yet to be filled(this is
certainly the classic "rhetorical question". I make no claims to fore-
sight but I AM a well-recognized Monday morning quarterback...).
		Have I missed a point somewhere?
	Please address replies and/or comments to me personally and I will
forward appropriate text to the net.
		Thanks in advance,
				  Chris VandenBerg
				  Advanced Computer Communications(ACC)
				  chris@acc-sb-unix.arpa
Disclaimer - Comments are my own and do not reflect the viewpoints of
my employer or (frankly) ANYONE ELSE I know.

hedrick@athos.rutgers.edu (Charles Hedrick) (03/13/88)

I know at least one vendor who claims to be working on tn3270 mode.  I
think I can tell you why it hasn't been done yet.  First, it needs
more memory and CPU than a normal telnet connection.  You have to
maintain a screen image and various other state information, and you
have to do the emulation.  Most terminal servers currently use a 68000
with not much memory.  But that's not the big problem.  The big
problem is that you need to have access to somthing like termcap for
the user's terminal.  Terminal servers don't have disks, and they
don't have enough memory to store the whole thing in memory.  My
theory is that they're going to have to define a "termcap server" that
runs on a host and gives you the termcap entry for a single requested
terminal type.  Of course those machines that support tftp booting
(which I think is common) could always download /etc/termcap and just
throw away everything except the one entry that they needed.
Presumably when the vendors do it, they'll use it to help sell us
upgrades that use the SPARC chip and have 32MB of memory...  (Well,
not really, but I think you might need more than 1MB, and at least
a 68020.)

backman@interlan.UUCP (Larry Backman) (03/16/88)

In article <Mar.12.17.46.18.1988.5479@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>I know at least one vendor who claims to be working on tn3270 mode.  I
>think I can tell you why it hasn't been done yet.  First, it needs
>more memory and CPU than a normal telnet connection.  You have to
>maintain a screen image and various other state information, and you
>have to do the emulation.  Most terminal servers currently use a 68000
>with not much memory.  But that's not the big problem.  The big
>problem is that you need to have access to somthing like termcap for
>the user's terminal.  Terminal servers don't have disks, and they


	[]

	From my past, I remember implementing a 3270 emulator under
	UNIX using termcaps.  It doesn't work!  3270 terminals need
	5 or 6 modes of screen attributes to be effective (normal,
	hilight,reverse,reverse hilight,blinking,underline,etc.).
	Verry few termvcaps entries have these attributes defined
	completely.  Now the vendor has to decide... do I want to
	start mucking with termcaps for each and every terminal type I wish to
	support, or... let the user do it themselves.  As I remember,
	neither way was a viable solution.

	Yes you could define a limited subset of terrminals that would
	be supported, but that subset grows rapidly based on user feedback.

	As to memory and CPU.  The EBCDIC --> ASCII stuff eats some
	cycles, but the byte stream interpretation was no worse than
	any VT220 application.  You have to scan for order codes and
	parse some following bytes accoordingly.  Each screen image
	needs roughly 4K of memory, 2 K for the image, and 2K for the
	attributes, not a lot of memory these days.

	As with anything else, it can be done, but its a pain.  Is it
	worth it?  Count the number of PC based 3270 emulators sold;
	multiply by $500.  What do you think?


						Larry Backman
						Micom - Interrlan