Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!edison.ge.COM!uucp
From: uucp@edison.ge.COM (UNIX-to-UNIX Copy)
Newsgroups: comp.os.vms
Subject: Submission for mod-computers-vax
Message-ID: <8704280651.AA20014@edison.GE.COM>
Date: Tue, 28-Apr-87 02:51:56 EDT
Article-I.D.: edison.8704280651.AA20014
Posted: Tue Apr 28 02:51:56 1987
Date-Received: Sat, 2-May-87 03:12:30 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 55

Path: edison!uvacs!virginia!umd5!brl-adm!seismo!mnetor!utzoo!dciem!nrcaer!cognos!jimp
From: jimp@cognos.uucp (Jim Patterson)
Newsgroups: comp.lang.lisp,comp.org.decus,mod.computers.vax,comp.sources.wanted
Subject: Re: Need faster VMS spawn
Message-ID: <596@cognos.UUCP>
Date: 24 Apr 87 14:01:23 GMT
References: <602@rdin.UUCP>
Reply-To: jimp@cognos.UUCP (Jim Patterson)
Organization: Cognos Incorporated, Ottawa, Canada
Lines: 44

We've been using a technique similar to what you've described for
the same reasons (speed).  While I can't post any source, we did
use C and I can describe the general technique.

I should first point out the difference between LIB$SPAWN and
SYS$CREPRC.  LIB$SPAWN creates effectively a copy of your DCL
session, including all current symbols and process logical names.
(It does NOT execute your LOGIN.COM file to do this, however,
and so is not quite as slow as an actual logon).  SYS$CREPRC
just runs a process; it does not have any symbols or process
logicals defined when it starts up.  Since for our application
it was quite important that the user's "context" of symbols
and logicals was maintained, we used LIB$SPAWN.

The actual process of getting LIB$SPAWN to stay around is quite
simple.  We simply set up a mailbox for the input device of
LIB$SPAWN and sent mail commands down to it.  We also set up a
"status" mailbox, whose purpose is to return status information and
also to synchronise the parent and child processes.  These mailboxes
were manipulated using $QIO calls, because they often must be asynchronous.

To execute a command in the child session, the command is written to
the input mailbox, followed by a command to write the $STATUS symbol
to the status mailbox, and then the parent reads from the status
mailbox (which blocks the parent until the child finishes).  In case
the child gets into trouble and aborts, we also use the termination
AST of LIB$SPAWN which will cancel the status mailbox in order to
unblock the parent.  Note that this whole technique assumes that
what is being run are DCL commands.

Here are some other points of interest:
- If not interactive, you also need to set up a mailbox for
standard output and echo it onto the parent's standard output.
This can be useful anyways if you want to control where the output
goes (e.g. if in a window environment).
- Prior to sending down commands, we found it useful to send down
a few other commands to redirect the TT and SYS$INPUT files back
to the parent's input (otherwise they point to the input mailbox).
- Terminal ASTs (control-Y, control-T) are a problem. There's been
some discussion of these problems recently in the net; I just know
that our code still has a few glitches due to errant control-Y's
in particular.

I hope this is of some help in your application.