* INITIALIZE
  ** Assign input, output, termination, and status mbx's.
  ** Issue read on termination mbx.
  ** Create process with input mbx name as input, output mbx name as output
     and error, termination mbx unit as termination.
  ** Write "SET NOON!'F$VERIFY(0)" and
     "OPEN/WRITE <status_logical_name> <status_mbx_name>".  This prevents
     errors from killing the process, supresses the echoing of commands, and
     opens the file which the process will use to write status codes back to
     its parent.

* EXECUTE COMMAND
  ** Write command string to input mbx.
  ** Write "WRITE <status_logical_name> $STATUS" to input mbx.
  ** Issue an asynchronous read (with AST routine) on output mbx.
  ** Issue synchronous read on status mbx.

* PROCESSING
  ** When output AST routine is called, pass data back to caller and reissue
     output mbx read.
  ** When status mbx read is satisfied, command is complete.  String read will
     be an 8 character hex number preceded by "%X" which is the exit status of
     the command.  $CANCEL any pending read on output mbx.

* MISC
  ** If the termination mbx read is ever satisfied, the process has died.
     $CANCEL any pending reads on the status mbx (note that this will in turn
     $CANCEL any reads on the output mbx).
  ** The commands string will not be echoed by the subprocess.  If echoing is
     needed, it must be done manually.
  ** The caller should supply an exit handler to kill all subprocesses (as
     well as do application specific cleanup such as deleting an incomplete
     object file for MAKE).

* TODO
  ** If we REALLY want to support multiple, concurrent processes, need to not
     have the process_execute_command call wait for it's read on the status
     mbx.
  ** To properly support output suppression for FANCY_OUTPUT, need to not
     write the new command (and change output routine) until the previous
     command completes.  We can check this by means of a READATTN ast on the
     output channel or when the status read is satisfied (if there IS a status
     read).  Perhaps the process structure should contain a queue of pending
     commands?
  ** Need a way for the caller to wait on all pending commands.
  ** Need to genericise the status read/interpretation stuff.  Need to be able
     to specify what string (if any) should be sent and what routine should be
     called to convert the string read into an integer.  Need some way for the
     caller to find the status mbx name (just look into structure?).
  ** If the status genericising is done, allow caller to specify image to run
     if USE_CREPRC (and supress writing of default setup strings).
  ** Need a way for the caller to wait for some set of processes to complete
     their commands.  EF's in the process structure?