Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!mailrus!umix!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.os.vms
Subject: Re:  Odd subprocess behaviour
Message-ID: <2746@enea.se>
Date: 20 Feb 88 00:38:15 GMT
References: <8802151119.AA27861@ucbvax.Berkeley.EDU>
Reply-To: sommar@enea.UUCP(Erland Sommarskog)
Followup-To: comp.os.vms
Organization: ENEA DATA AB, Sweden
Lines: 31

Jerry Leichter writes:
>	...[I]f you create a subprocess and attach to it, then re-attach to
>	the parent process, then spawn a second subprocess and attach to it,
>	THEN kill the first subprocess with a STOP command from t'other (still
>	with me?), VMS can't decide which of the remaining two processes
>	(parent and 2nd child) is attached to the terminal!  You get a mixture
>	of prompts, and it isn't clear where the things you type go.
>	...
>
>Same thing happens on VMS V4.5.  It's actually not hard to see why this is
>happening, given the mechanisms DCL uses to implement SPAWN and ATTACH (which
>are too involved to go into here); but it certainly isn't what you'd WANT to
>have happening.  Submit an SPR!  In the meantime, the easiest work-around I

To add some more on this. I have been exposed to something similar:
Main process: Communication with target computer.
Sub-proc 1: TPU
Sub-proc of Sub-proc 2: DCL
Mostly I switched between TPU looking up line numbers in compilation 
listsings and the main process sending commands to my target machine. 
Sometimes I needed some other utility and created the DCL process, but since
it was rarely used, the watch dog killed it. And now: chaos. One key-
stroke in TPU, next in the comm.program. Total confusion. This happened
to me more than one time. I never studied it closely enough to tell
whether it mattered if I went from DCL to TPU to the main process, or
went there directly.
-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP              Io, chi parlo di niente, 
                              lo faccio soltanto in paura di silenzio