Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!UCBVAX.BERKELEY.EDU!minshall%opal.Berkeley.EDU From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet Option Negotiation to IBMish Hosts Message-ID: <8702180024.AA08089@opal.Berkeley.Edu> Date: Tue, 17-Feb-87 19:19:06 EST Article-I.D.: opal.8702180024.AA08089 Posted: Tue Feb 17 19:19:06 1987 Date-Received: Wed, 18-Feb-87 20:24:29 EST References: <8702141520.AA15042@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 65 Approved: tcp-ip@sri-nic.arpa Hi all. The question of how one gets into "3270 mode" is a one worth pondering. A follow up message by Bruce Crabill (which may not have made it to the tcp-ip list) and the original message by Mike Hojnowski are fairly worthwhile reading, but I would like to add my two-cents worth. First, there is, of course, absolutely NO standard for how "3270 over telnet" should be done. The Wisconsin picked something, based possibly on conversations with the UCLA (MVS) people. Doing this involved inventing a new Telnet option (EOR's). The initial WISCNET just negtotiated a 3270 terminal type and binary mode, and then assumed EOR. After the implementation, the EOR (end of record) RFC came out and said "thou shalt negotiate EOR prior to using it", so later versions of WISCNET have negotiated EOR in addition to the terminal type and binary mode. Berkeley TN3270 does, in fact, always respond "ibm3278-X" to "send terminal type". This is somewhat of a problem, since if we AREN'T going to get into 3270 mode, we would probably REALLY like to say "vt100", or whatever the user's terminal REALLY is. I would LIKE to see this change, but it's not really too big of a deal. Berkeley TN3270 does, in fact, check occasionally to see if "binary" and "terminal type of 3270 sent" are true. If they are, then Berkeley TN3270 magically slips into 3270 mode. If these are NOT true, then Berkeley TN3270 magically slips out of 3270 mode (which transition may not work very well - I've never had a host that wanted to leave 3270 mode on me, though I understand that the UCLA code does like to do this at times). We DON'T check EOR option being set (though the current Berkeley TN3270 is willing to have EOR set on either end). Berkeley TN3270 IS sensitive to the fact that various IBM implementations are order sensitive when doing the initial negotiations. The most recently announced version of Berkeley TN3270 had a "bug" which caused it to not work when talking with Fibronics/Spartacus/KNET. The current version (available on arpa.berkeley.edu, or from me, but never announced) has a kludge to get around the KNET operating characteristics. The problem with order sensitivity is that on start up, a client would really like to just send "do sga" and "will terminal type". Doing this sort of "parallel" option negotiating can speed up the user-perceived connect time a lot. I would like an agreement on how to do things. Perhaps an RFC. I don't think the issues are actually that easy to resolve (though maybe I'm just slow). Part of the constraints should be that if 3270 negotiation doesn't work, we should slip back into "send terminal type" so that (for example) an Amdahl-compatible machine with an onboard emulator (ala KNET) can determine the terminal type without having to ask the user. Also, the mode should be able to be switch back and forth (for the UCLA people, if no one else). The problem with doing an RFC, of course, is "who wants an RFC that only pertains to one class of terminals" (though the telnet RFC, after all, spends a lot of time making telnet work for IBM 2741's). Greg Minshall CFC 273 Evans Hall UC Berkeley, Ca. 94720 (ps - this message is partly a sly way of announcing a "fixed" version of tn3270 available on arpa.berkeley.edu in pub/tn3270tar; the message is also to announce the availability of tn3270 to the bitnet community)