robin@csuchico.edu (Robin Goldstone) (07/03/90)
NCSA Telnet 2.3 added a menu option called "Setup Keys..." under the Session menu. One of the fields under this option is called "Interrupt Process" and it is set to ^C. I have found that this is the cause of a problem I have been having when telnetted to our VAX. The problem is that issuing a control-C "hangs" my telnet session. If I blank out the Interrupt Process field, it eliminates the problem. The 2.3 documentation indicates that the values in the Setup Keys option can be configured via config.tel but I cannot find a parameter in Ch. 8 that corresponds to this option. I need to find the config.tel option of I have to manually blank out this field every time I open a new session. On a related note, once I disable Interrupt Process and fix the hanging problem, I go back to the behavior of Telnet 2.2, which is a very delayed response to my control-C. If I am listing a file to the screen and do a control-C, it takes several (5+) seconds for the host to actually respond and cancel the command. On a serial connection to the VAX, control-c is interpreted instantaneously. The Telnet documentation indicates that control commands are only interpreted between transmitted blocks and that I can improve response to my control-C by setting block=low number in config.tel. I have set it to the minimum (100) but control-c responses still take a long time. Does anyone have any suggestions for me as to: 1) disabling Setup Keys option "Interrupt Process" via config.tel 2) improving response to control-C Thanks. Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services robin@csuchico.edu
resnick@lees.cogsci.uiuc.edu (Pete Resnick) (07/05/90)
robin@csuchico.edu (Robin Goldstone) writes: >NCSA Telnet 2.3 added a menu option called "Setup Keys..." under the >Session menu. One of the fields under this option is called "Interrupt >Process" and it is set to ^C. I have found that this is the cause of >a problem I have been having when telnetted to our VAX. The problem is >that issuing a control-C "hangs" my telnet session. If I blank out the >Interrupt Process field, it eliminates the problem. The 2.3 documentation >indicates that the values in the Setup Keys option can be configured via >config.tel but I cannot find a parameter in Ch. 8 that corresponds to this >option. I need to find the config.tel option of I have to manually blank >out this field every time I open a new session. This was left out of the docs. Jennie File, the person at NCSA sent me this to put in config.tel: localkeys={3,19,17} This entry sets the interrupt, suspend and resume keys respectively. To set off any or all the keys, set the value of that key to '0'. localkeys=off This entry can be also used to unset all keys. That should do it for you. Remember that hitting ctrl-c when it is set in the Setup Keys option is exactly the same as hitting command-y or choosing Interrupt Process from the Network menu. It sends the Telnet Interrupt Process message to the foreign host. So as to the next question..... >On a related note, once I disable Interrupt Process and fix the hanging >problem, I go back to the behavior of Telnet 2.2, which is a very delayed >response to my control-C. If I am listing a file to the screen and do a >control-C, it takes several (5+) seconds for the host to actually respond >and cancel the command. On a serial connection to the VAX, control-c >is interpreted instantaneously. The Telnet documentation indicates that >control commands are only interpreted between transmitted blocks and that >I can improve response to my control-C by setting block=low number in >config.tel. I have set it to the minimum (100) but control-c responses >still take a long time. When you do an Interrupt Process (either using crtl-c from Setup Keys or the menu choice or command-y), NCSA Telnet sends it through in urgent mode and sends a timing mark to stop displaying until the host says that it got the interrupt. As far as I know, the ctrl-c when it is not set up as the Interrupt Process key will be sent through as standard data. That means that the Vax decides when to take care of it, which is obviously longer than you would like it. I don't know why Telnet is hanging on the Vax. It may be that the Vax implementation of Telnet isn't dealing properly with the Interrupt Process. Maybe try Abort Output from the Network menu instead (hit command-a). pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@kant.cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD