********************** OPSER help file ***********************************

	The MASTER/OPSER system provides the user with a convenient way
to run and control several different programs at the same time. OPSER
is the program that handles all interaction with the various programs,
while MASTER is the means of connecting to, and exiting from, the OPSER
program; OPSER runs even if the user logs out.

	To create an OPSER process, the user issues the shell command
"master". Master responds with "[Creating OPSER]" and then passes control
to the new OPSER program. To leave OPSER, the user types the <FS> key (control
backslash).  MASTER responds "[Leaving OPSER]". The next time the master com-
mand is issued, the same OPSER program is re-entered. Note: one must always
use the master command from the same terminal and while in the same directory.
Furthermore, one should avoid using the <DEL> and <FS> keys while
talking to a created process (vs. talking to OPSER).

	OPSER prompts with a "*" and waits for a command to be typed. All
commands are one line long consisting of a command name and 0 or more
arguments, usually optional. Spaces are the only legal separators; practi-
cally everything else is included in a name. The command names may be
abbreviated to 2 or more letters, and are listed on the next page.

	The communication between OPSER and MASTER consists of a disk
file called "opser.nnnnnn" where nnnnnn is the process id number of an
OPSER process. Currently, the number is in octal. If the system crashes,
this communication link will not be accurate. There will soon be a
program called "masterchk" that will do a ps and try to straighten things
out. Note: it, like master, must be run from the same terminal in the
same directory.





		--- Command Description ---

To create a program:            CREATE name [cmnd ...]
	To start up a new process, issue the Create command; the name is
required and is the name by which the process may be referred to. Normally,
a shell is fired up, but if supplied, the cmnd and its args may be run in
place of the shell. If a command is specified, the process will terminate
when the command does; one must specifically close a shell. Note: if the
cmnd can't be run, an error message surrounded by {} will be printed;
the user should then issue the wait command (see below).

To send data to a program:      SEND [name] [file]
	One can send lines to a program via the Send command. To use it,
one types "send name" (where "name" is the name of a created process) and
types in line after line, ending with a CTRL-D. OPSER reprompts after the
CTRL-D is typed. If a file is mentioned, it is used instead of the terminal.
The name is optional (see below), but must be supplied if a file is mentioned.

To get output from a program:   DISPLAY [name]
	Typing the Display command (name is optional- see below) causes
OPSER to either type "No Output." or display any output from the program
since the last display command for it, stopping the printout as soon as it
catches up with the program's output.

To terminate a program:         KILL [name] | KILL all
	To kill a program, use the Kill command. Kill all does just that.
OPSER always responds with a "Name killed." message to confirm a death.

To get a status report:         STATUS [name] | STATUS all
	Status reports on the status of the given name, or on all currently
running programs if there is no name given (or it is "all"). The status
report consists of the process name (from the create) and one of 3 messages:
"no output" if there is none, "output waiting" if there is (may only be a
newline, etc.), and "final output" if the process has been CLOSED'd.



	The above are the basic process-controlling commands. Much more
convenient are the following package deals:

	CONNECT [name] is the eqivilent to an infinite display/send loop,
effectively connecting the terminal to a program. To disconnect, type a
CTRL-D (as in send).

	ENTER name [cmnd ...] first creates a process and then connects to it.

	CLOSE [name] closes the input to a process, presumably killing it,
and then connects to it, allowing all of the final output to be displayed
(display would say "No output." if it hadn't written any yet). Attempts to
send data to a closed process will be perpetually frustrated until the
process actually dies. Unlike kill, which murders the process, close allows
for smooth exits catching final output (close is the only way available).

	Another convenience involves the optional process names in the
above commands. OPSER always remembers the last process referred to (except
after the "all" option) and will use that process in case of default. In
general, then, one does not repeat a process name after its creation.

	To solve the zombie problem, opser does the following: (if you are not
familiar with "zombies" don't bother with this paragraph): Any kill or the
reading of an end-of-file from a process while in a display (or connect
or close) causes OPSER to wait for the death of a process. When wait(II)
confirms the death, OPSER responds "Name killed." and wipes that process
from its table. If the process that died is not the expected one, OPSER
continues waiting for it (thus catching any other deaths that might have
occured).



	There are also various utility commands:

USE file lets one prepare command files for OPSER (MASTER and OPSER must
	be run only from the terminal). All further input to OPSER is
	taken from the specified file until its end. Any error (except
	"?Bad char": the character is treated like a separator) causes
	a return to terminal input mode.

HELP    types this file using l; in fact, HELP is nothing more than a
	"enter help l /rnd/bobg/opser.help".

WAIT    causes OPSER to wait for any programs that might have died, but
	whose death has not yet been confirmed. It returns immediately
	if no programs are currently running, and hangs if any are and
	none have died. Type a <DEL> to get out.

EXIT    causes OPSER to exit, effectively doing a CLOSE all. If the master
	program created OPSER, it will respond "[OPSER exited]", but if
	it was a re-enter master, the terminal will stop after the exit.
	The user must then type an <FS> to poke master, who will
	then falsely say "[Leaving OPSER]" (never to be re-entered).

<DEL>   is the restart key. OPSER always responds with a new prompt, resets
	the input port, breaks any connects or waits, etc. It may be
	used often while in OPSER, but will probably cause weird things to
	happen to any running programs that signal for it.

<FS>    (the control backslash key) causes OPSER to go to sleep and MASTER to
	wake up. It, too, may mess up running programs that signal for it.



	In general, OPSER is human-engineered. The error messages should be
pretty much self-explanatory, and the command syntax is quickly learned
and easily typed if the 2-letter abbreviations are used. Here is a command
summary:


CREATE name [cmnd ...]          To start a new shell (or command).
ENTER  name [cmnd ...]          Create, then connect to it.


SEND [name] [file]              Send terminal or file lines to program as
				input up till end-of-file.
DISPLAY [name]                  Print the program's current output.
CONNECT [name]                  Infinite send/display loop till end-of-file.


KILL  [name]/all                Kill program, confirm death, & erase tables.
CLOSE [name]/all                Close the input to (a/every) program and then
				connect for final output.

STATUS [name] (defaults to all) List all running programs and state of output.
WAIT                            Wait for stray deaths.

HELP                            For it, type it.
EXIT                            Causes OPSER to exit, but not master!
USE file                        Take additional input from the file.
<DEL>                           Restart OPSER: breaks waits, connects, etc.
<FS>                            Return to master.
