swg@ncs-med.UUCP (Stephen Glennon) (02/03/88)
Summary: VT-220 Terminal characteristics are modified when attaching between a process running EVE (TPU) and a DCL process. Background: We have established a working environment on our VAX 8200 (under VMS 4.6) that maintains three active processes for each user. One is retained as an interactive DCL process, one is dedicated to the EVE editor (which is customized), and one is dedicated to testing. Problem: Intermittently, but with annoying frequency, when one attaches from the EVE process back to the DCL process, the terminal characteristics are mysteriously changed. The change is most obvious when text is entered on the command line and then deleted with the backspace key. As far as the keyboard input buffer is concerned the input text has been deleted but the text is still displayed on the screen as in the following example: NOTE: the cursor position is shown with an underscore "_" (at DCL prompt after attach) $_ (type in "dir" at the prompt) $dir_ (enter one backspace) $di_r (enter second backspace) $d_i r (enter third backspace) $_d i r Doing anything that updates the screen in DCL (such as monitor) produces a uselessly jumbled display. A ^w will refresh the screen but the problem will remain. We have discovered two ways to restore normal terminal behavior when this occurs: execute a terminal reset from the setup menu, or start and immediately exit from EDT. This behavior occurs on both DEC VT-220 terminals and the ZENTEC 1055 (VT-220 emulation) terminals that we have. A call to DEC Support in Colorado revealed that this problem was news to them and that they were unable to duplicate the problem on either their 4.6 system or their test 5.0 system. Here at our site the problem is maddeningly erratic. Every time anyone thinks that they have found a repeatable sequence that causes the problem to occur, on further testing it will only cause the problem every third or fourth try. Or the terminal will go into the odd state before you even complete the test sequence. Request: If anyone has encountered (and especially resolved) this problem, or has any suggestions as to methods of attack or further analysis, or has any further questions, << or merely wishes to express sympathy :-) >> I would be delighted to hear from you. I will post any resolution (he said optimistically) to the net. Address: (I am a Unix neophyte and am unsure exactly what mail address (to provide so I will give the path I use to get to one of the (net backbone sites and hope that provides sufficient data. seismo!rutgers!umn-cs!ncs-med!swg (Steve Glennon) Thank you!
cfchiesa@bsu-cs.UUCP (Sir Xetwnk) (02/07/88)
I've seen the precise problem you describe, under similar circumstances - i.e.
attaching back and forth from one process to another.
What's happening is this: the user is working in EVE, in Insert mode (or the
equivalent; in EDT this would be the Keypad Mode default). He then attaches
to the DCL process. DCL doesn't know that the user has been anyplace (other
process) else since issuing the previous DCL-process command, so doesn't
realize that the terminal's PHYSICAL characteristics have been altered by
EVE - to be specific, EVE has switched the TERMINAL SETUP from the DCL default
of "overstrike" mode, to EVE-compatible "insert" mode. So DCL thinks the
terminal is in "overstrike" mode, while it is actually, physically in "insert"
mode.
You should be able to fix this problem by one of several methods:
1) If EVE allows the user to toggle Insert/Overstrike modes, exit to DCL should
be flawless if done from the midst of Overstrike mode.
2) Hitting control-A in DCL toggles command-line input mode between insert and
overstrike mode, including the corresponding adjustment of terminal physi-
cal characteristics. Hitting control-A TWICE when you return to DCL should
fix your problem, by sending first the "enter insert mode" sequence (no
effect; terminal is ALREADY in insert mode), then the "enter overstrike
mode" sequence (which will fix the terminal).
NOTE: Once the terminal is placed into OVERSTRIKE mode, it is now out-of-
sync with EVE; I don't know what EVE can do about toggling this; if it
can do it, a double-toggle in EVE on reattaching that process should fix
it in that direction, also.
(By the way, the weird visual effect you describe is due to the way "delete
character left of cursor" is actually performed by VMS so that "what you see
is what you get": You hit DEL, sending ASCII 127 to VMS. VMS returns an
ASCII 8 (backspace to sit on the character being deleted), ASCII 32 (space;
BLANK OUT the character from the display, "deleting" it visually), and another
ASCII 8 (move cursor back to recover from the space character moving the cur-
sor). In Overstrike mode, this has the effect you are used to. However, in
insert mode, the space character INSERTS BETWEEN characters, rather than
WIPING AWAY a character, hence you see everything that was originally there,
which you have "deleted", with spaces between them. Your command line is
being edited properly nonetheless; but the discrepancy between what DCL EX-
PECTS the terminal to do, and what the terminal ACTUALLY does, causes a
breakdown of the visual effect. "What you see is NOT what you get," in this
case.)
Hope this helps!
Chris Chiesa
<><><><><><><><><><><><><><><><><><><><><><><><><><><><> Chris Chiesa <><><><><>
<> {ihpn4|seismo}!{iuvax|pur-ee}!bsu-cs!cfchiesa <>
<> cfchiesa@bsu-cs.UUCP <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>RALPH@UHHEPG.BITNET (02/11/88)
Date: 10-FEB-1988 11:24:18.07 From: Ralph Becker-Szendy RALPH AT UHHEPG To: B_INFOVAX,RALPH Subj: Re: Re: Problem with TPU affecting VT-220 terminal behavior I didn't get the original message (is the moderator listening out there ?), but i have two cents worth on the problem: >From: Sir Xetwnk <bsu-cs!cfchiesa@iuvax.cs.indiana.edu> >Subject: Re: Problem with TPU affecting VT-220 terminal behavior > >I've seen the precise problem you describe, under similar circumstances - i.e. >attaching back and forth from one process to another. > >What's happening is this: the user is working in EVE, in Insert mode (or the >equivalent; in EDT this would be the Keypad Mode default). He then attaches to >the DCL process. DCL doesn't know that the user has been anyplace (other >process) else since issuing the previous DCL-process command, so doesn't >realize that the terminal's PHYSICAL characteristics have been altered by EVE >to be specific, EVE has switched the TERMINAL SETUP from the DCL default of >"overstrike" mode, to EVE-compatible "insert" mode. So DCL thinks the terminal >is in "overstrike" mode, while it is actually, physically in "insert" mode. First of all, to really find out what the terminal is doing, you need a terminal which can display the insert mode setting in the status line (time to praise my Falco 5220). Then the following observations are real easy: (they were all done with the default terminal mode settings for a VT200) Strangely enough, DCL >> does not << use insert mode when you are in the "SET TERM/INSERT" mode. It rather rewrites the command line when you insert characters. Using the terminal monitor mode, i saw it do the following: - Delete character (the DEL key) uses "BS blank BS" - Cursor left uses "BS" (and no cursor control sequence) - character overwriting is obvious - character insert writes the new character, writes the rest of the line, does a "ESC [ K" (erase to end of line) and moves back with "BS"s. To me it seems to be very stupid that DCL doesn't use the insert mode, but as usual i can't search the soul of the VMS developers. The version of EDT we have here (but i never use it) does all its inserting the same way DCL does it (a little test reveals that), which again seems to be very stupid, in particular if you are trying to edit over a modem line. Now EVE (i should rather say TPU, because that's where these functions are handled) is more intelligent: when you are in "overstrike" mode it >>never<< switches insert on. When you are in insert mode and you are at the end of the line, it leaves the terminal in overstrike, too. The reason seems to be that some terminals (in particular the VT241) are really slow in insert mode, even if you just have to shift out blanks. It only uses insert mode when you are actually "inserting" new characters in the middle of a line. By the way, EVE (ar again, rather TPU) is quite a bit more efficient in screen handling (that is one of the reasons why i use it exclusively, speed becomes important with 44 lines on the terminal at 9600 baud). What "vanilla" SMG does ? i didn't bother to write a test program to figure it out. I guess it will behave like TPU (after all TPU uses SMG for all its terminal IO). Now, Chris explanation of going into insert mode at the wrong time ... >(By the way, the weird visual effect you describe is due to the way "delete >character left of cursor" is actually performed by VMS so that "what you see >is what you get": You hit DEL, sending ASCII 127 to VMS. VMS returns an ASCII >8 (backspace to sit on the character being deleted), ASCII 32 (space; BLANK >OUT the character from the display, "deleting" it visually), and another ASCII >8 (move cursor back to recover from the space character moving the cursor). >In Overstrike mode, this has the effect you are used to. However, in insert >mode, the space character INSERTS BETWEEN characters, rather than WIPING AWAY >a character, hence you see everything that was originally there, which you >have "deleted", with spaces between them. Your command line is being edited >properly nonetheless; but the discrepancy between what DCL EXPECTS the >terminal to do, and what the terminal ACTUALLY does, causes a breakdown of the >visual effect. "What you see is NOT what you get," in this case.) .. is right. His cure is unfortunately wrong ... >Hitting control-A in DCL toggles command-line input mode between insert and >overstrike mode, including the corresponding adjustment of terminal physical >characteristics. Hitting control-A TWICE when you return to DCL should fix >your problem, by sending first the "enter insert mode" sequence (no effect; >terminal is ALREADY in insert mode), then the "enter overstrike mode" sequence >(which will fix the terminal). .. because DCL will never switch the terminal to insert mode (or out of it). I actually don't know any nive way to cure the problem (short of going into EVE again and exiting the right way): >If EVE allows the user to toggle Insert/Overstrike modes, exit to DCL should >be flawless if done from the midst of Overstrike mode. That's what science is all about ... explaining a trivial detail in great depth ! Ralph Becker-Szendy RALPH@UHHEPG.BITNET University of Hawaii / High Energy Physics Group (808)948-7391 Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822 "Hawaii - it's not just for tourists. People actually live and work there."
jbs@eddie.MIT.EDU (Jeff Siegal) (02/21/88)
In article <8802151613.AA01263@ucbvax.Berkeley.EDU> RALPH@UHHEPG.BITNET writes: >The version of EDT we have here (but i never use it) does all its inserting the >same way DCL does it [without using the terminal's insert mode] If you execute the EDT command SET TERMINAL EDIT, it will use the insert/delete character sequences. >(after all TPU uses SMG for all its >terminal IO). I do not believe this is true. Jeff Siegal