Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!uwvax!umn-d-ub!umn-cs!ems!pwcs!ncs-med!swg
From: swg@ncs-med.UUCP (Stephen Glennon)
Newsgroups: comp.os.vms
Subject: Problem with TPU affecting VT-220 terminal behavior
Keywords: TPU, VT-220, Weird, Annoying
Message-ID: <532@ncs-med.UUCP>
Date: 3 Feb 88 01:43:43 GMT
Organization: Dimensional Medicine, Inc.  Minnetonka, MN.
Lines: 60
Posted: Tue Feb  2 19:43:43 1988


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!