Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.unix.cray
Subject: Re: Whats Missing?
Message-ID: <2172@munnari.oz.au>
Date: 23 Sep 89 10:11:04 GMT
References: <3199@amelia.nas.nasa.gov> <4438@ncar.ucar.edu>
Sender: news@cs.mu.oz.au
Distribution: comp.unix.cray
Lines: 26

In article <4438@ncar.ucar.edu>, morreale@bierstadt.ucar.edu (Peter Morreale) writes:
>     Users at this site (COS) are heavily dependent on Fortran-callable 
>     JCL for re-start capability.  Rolling out a 5+MW job to do an
>     " IERR=ISHELL('assign  ')" is an unacceptable solution.
>     (Fortran-callable JCL also allowed access to our Mass Storage
>     System through local extensions)

I don't know if this works for UNICOS, but I had occasion to use a '*NIX'
where large (128kb!) processes couldn't fork at all.  On that machine,
the fix was to write a wrapper program and a new "shell" function.

The wrapper program is a _small_ program which creates a temporary file,
and then forks a child to do the real job.  The name of the temp file
is passed to the child in the environment array.  The wrapper then goes
to sleep waiting for a signal or the death of the child.  When the child
dies the wrapper deletes the temporary file and exits with the child's
status.

The new "shell" function writes the command to the temporary file, and
signals the wrapper.  It then goes to sleep waiting for a signal.

The wrapper receives the signal, and forks again to execute the command.
(Remember, it's a small program.)  It waits for the command to finish,
then it signals the child and goes back to sleep.

The child receives the wrapper's signal and returns from "shell".