From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX"  6-JAN-1991 02:54:52.40
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: Having a process detach itself (go into background)

Received:  by crdgw1.ge.com (5.57/GE 1.80)
	 id AA07686; Sun, 6 Jan 91 02:34:04 EST
Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Sat,  5 JAN 91 22:47:32 PST
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA28476; Sat, 5 Jan 91 22:39:31 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 6 Jan 91 06:38:49 GMT
From: comp.vuw.ac.nz!gp.co.nz!zl2tnm!don@uunet.uu.net  (Don Stokes)
Organization: The Time Machine Room
Subject: Re: Having a process detach itself (go into background)
Message-Id: <m22cV2w163w@zl2tnm.gp.co.nz>
References: <9101051939.AA17434@ucbvax.Berkeley.EDU>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

MLEVIN@TUFTS.BITNET writes:

> If this is possible on VMS, what would be the best way to do it?
> I want to have my program (in C) interact with the user (regular
> C RTL I/O), and then "go into background" - that is, continue to
> run, but detach itself from the terminal, giving the user back the DCL.
> The program would continue running, and at an appropriate time, print
> out a message to the screen, and then die.  Provided this is possible,
> what would be the best way to accomplish this?

Well, the "classic" approach to this would be to break the program into
a front end and a back end -- the front end asks all the qestions, kicks
off the back end in a subprocess (using LIB$SPAWN with the NOWAIT flag
set), passes data to it (either through a file or a mailbox) and returns
to DCL.  The back end would continue to crunch away; it has the terminal
open, so can print a termination message.  Alternatively, you can use
the NOTIFY flag in the LIB$SPAWN call to get the CLI to print a
termination message for you (that way the back end doesn't need to do
any terminal I/O whatsoever).

The second approach to the problem, if there is too much data to be
passed between the front and back ends, is to have the front end program
simply sleep until the back end has finished asking questions.  The
front end, on recieving a signal (mailbox message, lock grant or
something) then returns to DCL, with the back end processing happilly.

The third method, for completeness rather than as a serious suggestion,
is to use a normal spawn, then do the equalent of the ATTACH command.
Code to do this is included below.  I don't suggest that you actually
try this; it's not documented and will probably break in some future (or
een current -- I'm using 5.2 still) release.

In all these cases, you must be aware that if the user logs off with the
sub-process still active, the sub-process will be killed.  There are
various ways aound this -- one is to have the "logout" command defined to
check if any subprocesses are still active (not bulletproof).  The other
is to run the back end as a detached process -- this can only be done if
you use the first approach, and is harder than calling LIB$SPAWN, and
has a lot more traps for the unwary).  If you use this approach, you'll
need to use the $BRKTHRU system service to signal completion, as you
don't have access to the terminal, nor do you have the automatic
notification provided by LIB$SPAWN.


--cut-here--
                .title detach
;++
;
;  DETACH.MAR -- sort of ATTACH/CONTINUE for subprocesses
;
;  This procedure/module allows a subprocess to be spawned without
;  using /NOWAIT, get input (or whatever) and then return control to
;  the parent process.
;
;  As it stands, DETACH.MAR is a standalone program, but can be converted
;  to a callable procedure simply by changing the ".end detach" to just
;  ".end" (it'll work without doing this, but you'll get a warning at
;  link time).
;
;  DETACH takes no parameters, aborts on error.
;
;  Use of this code is not recommended for production systems.
;
;  Don Stokes (don@zl2tnm.gp.co.nz)                     6-Jan-1991
;
;--



		$JPIDEF
		$IODEF

		.macro status, code, ?pass
		blbs code, pass
                $EXIT_S code
pass:		.endm


		.psect detach_data, long,wrt,noexe,noshr

;
; Item lists for $GETJPIW to get parent PID and terminal name.
; Master PID is needed because terminal is not registered by subprocess (why?).
;
itmlst1:	.word 4
		.word JPI$_OWNER
		.address owner_pid
		.long 0
		.word 4
		.word JPI$_MASTER_PID
		.address master_pid
		.long 0
		.long 0,0,0
itmlst2:	.word 16
		.word JPI$_TERMINAL
		.address terminal
		.address terminal_d
		.long 0,0,0

master_pid:	.blkl
owner_pid:	.blkl
terminal:	.blkb 16
terminal_d:	.long 0
		.address terminal

;
; Mailbox stuff.  Mailbox name is DCL$ATTACH_xxxxxxxx, where xxxxxxxx is
; the process ID of the process to attach to (in this case the parent).
;
mbx_chan:	.blkw
mbx_fao:	.ascid "DCL$ATTACH_!XL:"
mbx_name_d:	.long 20
		.address 1$
1$:		.blkb 20

;
; To complete the detach, we need to read a value (completion status?) back
; from the parent process throughthe same mailbox.  This is one longword.
;
retbuf:		.blkl
iosb:		.blkl




		.psect detach_code, long,nowrt,exe,shr

		.entry detach, ^M<>
;
; Get PIDs and terminal name.  First GETJPI gets master and parent PIDs,
; second GETJPI gets terminal name from master process.
;
		$GETJPIW_S itmlst=itmlst1, iosb=iosb
		status R0
		status iosb
		$GETJPIW_S itmlst=itmlst2, iosb=iosb, pidadr=master_pid
		status R0
		status iosb

;
; Construct mailbox name from parent PID and assign channel.
;
		$FAO_S ctrstr=mbx_fao, outbuf=mbx_name_d, p1=owner_pid
		status R0
		$ASSIGN_S devnam=mbx_name_d, chan=mbx_chan
		status R0

;
; Write terminal name to mailbox to signal to parent that we want to
; detach.
;
		$QIOW_S chan=mbx_chan, func=#IO$_WRITEVBLK, iosb=iosb, -
			p1=terminal, p2=terminal_d
		status R0
		status iosb

;
; Read back acknowlegement.
;
		$QIOW_S chan=mbx_chan, func=#IO$_READVBLK, iosb=iosb, -
			p1=retbuf, p2=#4
		status R0
		status iosb

;
; And exit with return value in R0
;
		$DASSGN_S chan=mbx_chan
		status R0

		movl retbuf, R0
		ret


		.end detach
--cut-here--

Don Stokes, ZL2TNM  /  /                             don@zl2tnm.gp.co.nz (home)
Systems Programmer /GP/ GP PRINT LIMITED  Wellington,       don@gp.co.nz (work)
__________________/  / ----------------   New_Zealand__________________________

