jbvb@BORAX.LCS.MIT.EDU.UUCP (03/26/87)
Could someone familiar with the UCLA ACP tell me at what point in the connection/login sequence it first negotiates 3270 mode (Term Type, EOR and Binary)? I have tried connecting to an UCLA MVS Arpanet machine, but negotiation didn't seem to take place on connection open (unlike WISCNET), and I didn't have an account, so I haven't been able to proceed further. Is my code broken, or do I have to log in to really test it? jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software Inc. (617) 868-4878
braden@ISI.EDU.UUCP (03/27/87)
Could someone familiar with the UCLA ACP tell me at what point in the connection/login sequence it first negotiates 3270 mode (Term Type, EOR and Binary)? I have tried connecting to an UCLA MVS Arpanet machine, but negotiation didn't seem to take place on connection open (unlike WISCNET), and I didn't have an account, so I haven't been able to proceed further. Is my code broken, or do I have to log in to really test it? James, Well, yes, I can tell you. Too bad you did not go to the TCP/IP Interoperability Workshop in Monterey last week; Greg Minshall gave a whole session on IBM 3270 support, and I described the rules for negotiation into fullscreen mode. Basically, VM uses a less-than-general approach to fullscreen negotiation because of restrictions in that operating system's virtual terminal machinery. If you simply connect to a UCLA MVS system with a normal Telnet NVT, you will understand the problem. It does not negotiate fullscreen mode until it is able to determine that the particular service subsystem of the host to which you actually want to talk handles fullscreen mode. EG, if you "logon" to TSO, it will then try to negotiate full screen; when you logoff TSO, it will return you to NVT mode, etc. Since this topic is probably not of general interest, and has been somewhat beaten to death in the past, I suggest we take any further discussion on this off the mailing list. Bob Braden