From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 22-APR-1992 12:51:55.64
To:	info-vax@kl.sri.com
CC:	
Subj:	re: LIB$SPAWN misbehaves, SYS$INPUT not really inherited?

In article <9204192300.AA20901@uu.psi.com>, leichter@lrw.com (Jerry Leichter) writes:
|> 
|> 	I've run into an apparant conflict between apparant and documented
|> 	behavior of LIB$SPAWN.  I have a couple of workarounds in mind, but
|> 	would appreciate learning any accumulated wisom on this issue.
|> 
|> 	The docs say a spawned subprocess inherits its parent's SYS$INPUT,
|> 	unless an alternative is supplied.  When the parent has been reading
|> 	input from a .COM file, I would expect the subprocess to see that same
|> 	stream.
[details on the problem...]
|> 	In fact, PARENT gets input from the .COM file correctly, but CHILD
|> 	sits and waits for input from the terminal.  I can understand making a
|> 	new subprocess take the default SYS$INPUT -- except that DEC claims it
|> 	will get whatever SYS$INPUT the parent already had.
|> 
|> Well, no, the documentation is fairly ambiguous.
|> 
|> First off, the documentation of LIB$SPAWN contains less detail than that for
|> the DCL SPAWN command.  It shouldn't, but it does.  The LIB$SPAWN documenta-
|> tion really says very little about what will happen in a situation like this.
|> 
[further explanations...]

The VAX C manual, Sections 5.1 and 5.2 (Implementing Child Processes in VAX C)
also give some (pretty amazing) details on the way vfork, exec, etc are made
to work under VMS.  It gives some details on how the RTL authors dealt with
file sharing.  (See especially the use of VAXC$EXECMBX and an lseek() on the
input file).

jim mullens
mullens@jamsun.ic.ornl.gov (128.219.64.31)
voice: 615-574-5564