Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!apollo!gaz
From: gaz@apollo.COM (Gary Zaidenweber)
Newsgroups: comp.sys.apollo
Subject: Re: vt100 under sr10
Message-ID: <43d38fb1.ce45@apollo.COM>
Date: 14 Jun 89 14:09:00 GMT
References: <8906122022.AA18993@umix.cc.umich.edu>
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 41

From article <8906122022.AA18993@umix.cc.umich.edu>, by FERGUSON@TMASL.EXXON.COM:
> 
> Forgive me for not having paid attention months ago when everyone
> else solved this one:
> 
> Using vt100 under sr10, CNTRL-Z terminates the graphics mode in the
> window, and it acts like it's about to return the prompt. However,
> the process goes into oblivion, and I have to blast it to get rid of
> it.
> 
> Is there a patch, or maybe I've got something configured wrong? I'm
> mainly still at sr9.7, so I haven't practiced much with sr10.
> Thanks,
> Scott Ferguson
> ferguson@erevax.bitnet
> Exxon Research & Engineering

I believe that ^d is now the "terminator" for vt100. ^z will suspend
it if you ran it in a shell with job-control (like csh). I also believe
that this is the case regardless of what your DM keydefs are. This
would be consistent with the behavior you describe, i.e. a suspended
process cannot be stopped (easily :-) ).

Ok, I just tried it. If run in a sys5 Bourne shell or a bsd4.3 c-shell
^z does nothing and ^d terminates the vt100 process. In a com-shell
it behaves exactly like you say. Given that habits are sometimes hard
to break :-), if you accidentally do it again here's a more graceful
recovery, 
	1) do a pst and then 
	2) 'sigp -u <uid-of-vt100> -c 12002b'
(12002b is the code for fault_$continue_proc from fault.ins.*)
In general, don't blast process unless you have to (I would have felt
that I had to in this case too) and I always reboot the machine asap
just in case.


-- 
Gary Zaidenweber
Apollo Computer Division of Hewlett Packard Company
UUCP:   {umix|decvax|mit-eddie}!apollo!gaz
ARPA:   gaz@apollo.COM