From:	HENRY::IN%"carl%cithex.caltech.edu%sri-kl.ARPA%relay.cs.net@rca.com"  4-MAR-1987 08:26
To:	McGuire_Ed%GRINNELL.Mailnet@mit-multics.arpa, 
Subj:	Re: Multiple VMS processes

  >>  H. Steinberg (?) writes of a nifty feature wherein one can gain a new
  >>  prompt and do things under Unix on receipt of a ^Z type-in.
  >>            I've seen this done under VMS by typing ^Y and then
  >>  various SPAWN/NOWAIT commands and continue commands. [. . .]
  >>            Glenn Everhart
  >>  Everhart%Arisia@RCA.com
  >  
  >  It sounded if the UNIX feature the person was asking for wasn't an
  >  interrupt. Suppose I'm running something that will take awhile to
  >  complete.  I want to create a subprocess, but I want the parent process to
  >  continue working.  I don't know how to do that, but I'd love to find out
  >  if it's possible! 

It's done as follows:
	1)  If you've got NOCONTROL_Y set, you're out of luck; it can't
	    be done.
	2)  Hit a control-Y (not a control-C, since the image may be trapping
	    for control-C's, in which case, you won't get what you want.
	3)  Type the command "SPAWN/NOWAIT" with any other appropriate
	    qualifiers you might want:  e.g., it's easier to keep track
	    of what's going on if you use a distinct prompt for the subprocess,
	    if you have SYS$COMMAND or SYS$OUTPUT directed away from the
	    terminal, you'll want to explicitly direct them back for the
	    subprocess, and so on.
	4)  Once the subprocess is spawned, issue the CONTINUE command to
	    the original process.  You've now accomplished what was described
	    above.

In some ways, this is superior to the UNIX version; in others, it's decidedly
worse.  If you log out of the subprocess, you automatically find yourself
talking to the previously "background" process again.  On the other hand,
if the original process decides it wants terminal input, the only warning
you'll have is that it will issue its own prompt (which is why I suggest
a different prompt for the subprocess.  There is one big gotcha here though.
It's illustrated by the following procedure:
	$	IF P1 .NES. "" THEN GOTO NEXT
	$	SET CONTROL=(T,Y)
	$	SPAWN/NOWAIT/INPUT='F$TRN("SYS$COMMAND") -
	$		@'F$ENV("PROCEDURE")' X
	$ LOOP:	WRITE SYS$OUTPUT F$TIME, " F$ENVIRONMENT(""CONTROL"") = ",-
	$	F$ENVIRONMENT("CONTROL")
	$	WAIT 00:01:00.00
	$	GOTO LOOP
	$ NEXT:	SPAWN/INPUT='F$TRN("SYS$COMMAND")' -
	$		ATTACH/ID='F$GETJPI("","PID")'
	$	WRITE SYS$OUTPUT "STOPPING JOB"
	$	STOP /ID=0
What this does is as follows: You invoke the procedure without any arguments;
The procedure spawns an ASYNCHRONOUS subprocess which reinvokes the procedure
with an argument.   Meanwhile, the original process starts, at one-minute
intervals, whether control-t and control-y are enabled or disabled. The
subprocess now spawns a SYNCHRONOUS subprocess which immediately reattaches to
the first subprocess, which then commits suicide, killing the second subprocess
at the same time, of course.  Now here's the fun part: Though the procedure
explicitly enabled both control-t and control-y, and though it's still
reporting them as being enabled, you'll have to go elsewhere to stop execution
of this procedure:  You see, the second subprocess was given access to the
interrupts when it was created as a synchronous subprocess; when it attached
to the first subprocess, it passed access to the signals to it.  The first
one, however, being asynchronous, felt no onbligation to inform its parent
process when it killed itself, and the second subprocess didn't even know
about the original process.  Thus, the process you're left with is ignoring
the interrupts, assuming they will be serviced by one of its (no longer
extant) subprocesses, and will continue to do so until it receives an
appropriate termination message in a temporary mailbox.  Of course, there's
no subprocess to send it a termination message anyjore, so you either have
to make a good guess and manually copy the appropriate messaage to the mailbox,
or else log in elsewhere and delete the stalled process.  Have fun.