OMOUNT.HLP--OMOUNT VERSION 22--OCTOBER 1971

GENERAL
-------

	OMOUNT IS RUN BY THE OPERATOR AT A LOCAL TTY IN ORDER
	TO SERVICE REQUESTS GENERATED BY UMOUNT (PLEASE,FILE, MOUNT,
	AND DISMOUNT USER COMMANDS) AND/OR PERFORM SERVICES
	EXPLICITLY COMMANDED BY THE OPERATOR.  MORE THAN ONE OMOUNT
	MAY BE RUN IN PARALLEL AND EACH OMOUNT MAY BE COMMANDED
	(START & STOP OPR. COMMANDS) TO SERVICE ALL REQUESTS, SOME
	REQUESTS (FILE OR MOUNT-DISMOUNT), OR NO REQUESTS (OPR. COMMANDS
	ONLY).  OPERATOR COMMANDS MAY BE TYPED ANY TIME OMOUNT
	IS NOT ACTIVELY SERVICING A UMOUNT REQUEST.  OMOUNT
	SIGNALS ITS ABILITY TO ACCEPT AN OPERATOR COMMAND BY
	TYPING '*' OR '!'.  THE '!' IS TYPED WHENEVER OMOUNT IS 
	ENABLED FOR UMOUNT REQUESTS (I.E. SCANNING THE REQUEST QUEUE).

	THE 'KILL' COMMAND IS USED TO PURGE THE QUEUE OF ALL PENDING
	REQUESTS OF A PARTICULAR TYPE.  THIS IS NEEDED, FOR
	EXAMPLE, AFTER CRASHES.

STARTING FRESH (E.G. AT BEGINNING OF DAY)

	.R OMOUNT
	*KILL		;PURGE ALL REQUESTS
	*START		;OR 'START:FILE' IF ONLY
	!		;  WISH TO SERVICE FILE REQUESTS ETC.

STARTING AFTER A CRASH

	.R OMOUNT
	*KILL:MOUNT	;FILE REQUESTS ARE STILL VALID
	*START
	!

TO CHANGE THE TYPE OF REQUESTS BEING SERVICED

	!STOP		;STOP ALL SERVICING
	*START:FILE	;TO SELECT FILE REQUESTS OR
	!		;  'START:MOUNT' FOR MOUNT-DISMOUNT REQUESTS
THE 'PROCEED?' QUESTION

	AT VARIOUS POINTS IN THE PROCESSING OF REQUESTS OR COMMANDS
	WHEN OMOUNT DISCOVERS ERRONEOUS OR UNUSUAL CONDITIONS, IT
	WILL TYPE 'PROCEED?' IN ORDER TO GIVE THE OPERATOR A
	CHANCE TO CANCEL OR DEFER THE REQUEST.  IN ADDITION
	THE 'PROCEED?' QUESTION MAY BE INVOKED AT ANY POINT
	BY REENTERING OMOUNT (I.E. ^C ^C .REENTER).
	IN BOTH CASES THE POSSIBLE REPLIES ARE:
		NO	CANCEL THE REQUEST AND DELETE FROM QUEUE
		YES	PROCEED IF POSSIBLE
		CANCEL	SAME AS 'NO'
		DEFER	CANCEL REQUEST BUT DONT DELETE FROM QUEUE
		START:X START PROCESSING X REQUESTS AFTER THIS ONE
		STOP:X	STOP PROCESSING X REQUESTS AFTER THIS ONE
			X=PLEASE,FILE,MOUNT,NONE,ALL
			/START & /STOP MAY ACCOMPANY OTHER REPLIES

'MOUNT' REQUEST SERVICE
-----------------------

	WHEN OMOUNT RECEIVES A 'MOUNT' REQUEST, IT CHECKS FOR DEVICE
	TYPE AND PROCEEDS AS FOLLOWS:

NON-FILE STRUCTURE DEVICES:

	(1) IF ANY OF THE SPECIAL SWITCHES /WLOCK, /WENABLE, OR
	    /VID (VISUAL I.D.) ARE PRESENT, THEY ARE TYPED TO THE
	    OPERATOR.
	(2) A CHECK OF THE DEVICE IS MADE FOR ANY SPECIAL CONDITIONS
	    (NOT AVAILABLE, ALREADY ASSIGNED, ETC.) AND THESE
	    ARE TYPED TO THE OPERATOR.
	(3) IF THE DEVICE IS ALREADY ASSIGNED TO THE USER, OMOUNT 
	    WAITS FOR ANY OPERATOR ACTIONS TO BE PERFORMED BY TYPING
	    'PROCEED?'.
	    WHEN ANSWERED (YES OR NO) THE REQUEST IS DELETED FROM THE
	    QUEUE AND THE USER'S JOB IF WAITING, WILL CONTINUE.
	(4) IF NOT ALREADY ASSIGNED, OMOUNT WILL REQUEST THE
	    OPERATOR'S SELECTION BY TYPING:
		ASSIGN DEV:
	    OR
		ASSIGN DEV(N):
	    (THE LATTER IS TYPED IF THE REQUEST WAS FOR A GENERIC DEVICE
	    AND OMOUNT HAS FOUND DRIVE N TO BE FREE)
	    THE OPERATOR MAKES HIS SELECTION BY TYPING:
		CARRAGE RETURN  SELECTS THE ONE CHOSED BY OMOUNT
		M	SELECT DRIVE-M
		/CANCEL	CANCEL REQUEST AND DELETE FROM QUEUE
		/DEFER	CANCEL REQUEST BUT DONT DELETE FROM QUEUE
		/START:X START PROCESSING X REQUESTS AFTER THIS ONE
		/STOP:X	STOP PROCESSING X REQUESTS AFTER THIS ONE
			X=PLEASE,FILE,MOUNT,NONE,ALL
			/START & /STOP MAY ACCOMPANY OTHER REPLIES

	(5) WHEN AN ACCEPTABLE DRIVE IS SELECTED, OMOUNT
	    REASSIGNES IT TO THE USER AND DELETES THE REQUEST FROM THE
	    QUEUE TO ALLOW THE USERS JOB TO CONTINUE IF WAITING.
FILE STRUCTURES

	(1) IF THE F.S. ALREADY EXISTS, OMOUNT PROCEEDS AS IN
	    (4) BELOW.
	(2) IF NOT, OMOUNT TRIES TO FIND ENOUGH FREE DRIVES OF THE
	    PROPER TYPE TO MOUNT THE F.S.  ANY SPECIFIC DRIVE
	    REQUESTS BY THE USER ARE HONORED IF POSSIBLE.
	    IF NOT ENOUGH DRIVES THE 'PROCEED?' QUESTION IS TYPED.
	    A LIST OF FREE DRIVES (OF THE PROPER TYPE) IS TYPED.
	(3) NEXT EACH UNIT I.D. IS TYPED FOLLOWED BY A SUGGESTED
	    DRIVE (IF ANY) IN PARENS:
		2RP003 (DPA3):
	    THE OPERATOR NOW MOUNTS THE F.S. UNITS ON THE DRIVES.
	    AFTER EACH UNIT-DRIVE PAIR IS TYPED (AND WHEN THE
	    DRIVE BECOMES READY)
	    THE OPERATOR MAY RESPOND AS FOLLOWS:
		CARRAGE RETURN  SELECTS THE ONE CHOSEN BY OMOUNT
		M	SELECT DRIVE-M
		/CANCEL	CANCEL REQUEST AND DELETE FROM QUEUE
		/DEFER	CANCEL REQUEST BUT DONT DELETE FROM QUEUE
		/START:X START PROCESSING X REQUESTS AFTER THIS ONE
		/STOP:X	STOP PROCESSING X REQUESTS AFTER THIS ONE
			X=PLEASE,FILE,MOUNT,NONE,ALL
			/START & /STOP MAY ACCOMPANY OTHER REPLIES
	(4) WHEN THE F.S. IS SUCCESSFULLY DEFINED
	    IT IS ADDED TO THE USERS SEARCH LIST.  A UFD
	    IS CREATED IF NONE EXISTS AND THERE IS AN ENTRY FOR
	    HIM IN THE QUOTA.SYS ON THE F.S.
'DISMOUNT' REQUEST SERVICE
--------------------------

NON FILE STRUCTURE DEVICES

	(1) ANY SPECIAL SWITCHES SUCH AS /REMOVE ARE TYPED
 	(2) OMOUNT WAITS FOR OPERATOR'S ACTIONS BY TYPING 'PROCEED?'
	    AND WHEN ANSWERED (YES OR NO) DELETES THE REQUEST FROM
	    THE QUEUE ALLOWING THE USERS JOB TO CONTINUE.

FILE STRUCTURES

	DISMOUNT REQUESTS ARE QUEUED TO THE OPERATOR ONLY WHEN
	THE /REMOVE SWITCH IS SPECIFIED.

	(1) THE FOLLOWING CHECKS ARE MADE OF THE F.S. AND IF ONE
	     OR MORE ARE TRUE THE 'PROCEED?' QUESTION IS TYPED.
		IS MOUNT-COUNT GREATER THAN ZERO?
		IS F.S. IN SYSTEM SEARCH LIST?
		DOES F.S. CONTAIN STRLST.SYS?
		DOES F.S. CONTAIN QUEUE (3,3.UFD)?
		DOES F.S. CONTAIN SWAPPING UNITS?
	(2) IF NONE OF THE ABOVE CONDITIONS EXIST (OR THE OPERATOR
	    CHOOSES TO PROCEED ANYWAY) THE F.S. IS REMOVED FROM
	    ALL USERS SEARCH LISTS AND THEN DELETED FROM THE SYSTEM.
'FILE' REQUEST SERVICE
----------------------

BACKGROUND
----------
PDP-10 USERS REQUEST DECTAPE OPERATIONS VIA TWO CUSPS, UMOUNT AND
OMOUNT. THE COMMAND, FILE..., RUNS UMOUNT, WHICH CONVERTS THE USER'S
TYPED COMMAND TO A COMMAND FILE ON A SYSTEM SPECIFIED DISK AREA CMDPPN.
THE OMOUNT CUSP IS USUALLY RUN UNDER A SUBJOB OF OPSER, THE OPERATOR
SERVICE PROGRAM. THE QUEUE CONSISTS OF THE SET OF COMMAND FILES ON DISK
AREA CMDPPN THAT HAVE FILE NAMES FXXXX.CMD. THE NAME OF THE COMMAND FILE
CONSISTS OF THE INCLUSIVE OR OF SIXBIT/F/ AND 12 BITS OF "TIMER" IN THE
LEFT HALF AND THE INCLUSIVE OR OF THE USER'S PPN IN THE RIGHT HALF.

     SIXBIT/F/!<TIMER 12 BITS>,,IORPPN.CMD

THE FILE'S CONTENTS IS:

     ASCIZ/F JOBNNN TTYXXX P,PN ID COMMANDS/

DECTAPE ALGORITHM IN OMOUNT
------- --------- -- ------
THE OBJECTIVE OF THE DECTAPE HANDLER IN OMOUNT IS TO MINIMIZE OPERATOR
INTERVENTION BY:
     1.  ALWAYS REQUESTING A TAPE MOUNTED WITH WRITE ENABLED ASSUMED.
     2.  ONLY OUTPUT TO THE OPERATOR WHEN NECESSARY TO MOUNT A NEW TAPE.
     3.  IF A TAPE BECOMES A SCRATCH, IT STAYS MOUNTED LIKE ANY OTHER
         TAPE AND IS USED AGAIN IF A REQUEST FOR A SCRATCH IS ISSUED.

IN ADDITION, IMPROVED QUEUE COMMAND PROCESSING IS OBTAINED BY SERVICING
UP TO FIVE (5) REQUESTS FOR THE SAME TAPE BY THE SAME USER IN ONE
OPERATION. ALSO, OFF-HOUR CAPABILITY IS INCLUDED.

TO REMEMBER THE STATUS OF DECTAPES MOUNTED, THE FOLLOWING TABLES AND
PARAMETERS ARE USED BY OMOUNT:
     DTANUM (DRIVE) - THIS IS THE TABLE INDEXED BY DRIVE NUMBER WHERE
EACH ENTRY CONTAINS THE SIXBIT /ID/ OF THE TAPE MOUNTED. THE DIRECTORY
OF THE TAPE MOUNTED IS READ BEFORE EACH OPERATION TO BE SURE THE TABLE
IS CORRECT. IF THE TABLE AND TAPE DISAGREE, OMOUNT SEARCHES ALL THE
MOUNTED TAPES AND UPDATES THE DTANUM TABLE (ALSO DTASTS AND DTATIM).
IF THE TAPE IS FOUND MOUNTED, OMOUNT DOES THE REQUESTED OPERATION.
OTHERWISE, THE OPERATOR IS NOTIFIED TO MOUNT THE REQUESTED TAPE. IF THE
CONTENTS OF THE TABLE ENTRY IS ZERO, THE CORRESPONDING DRIVE IS NOT
BEING USED BY OMOUNT.

     DTASTS (DRIVE) - THIS TABLE DETERMINES THE TYPE OF DECTAPE AND ITS
STATUS.
         BIT 35 = 1, THEN TAPE IS A SCRATCH
         BIT 34 = 1, THEN TAPE IS OLD FORMAT
         BIT 33 = 1, THEN TAPE HAS FILE PROTECTION

     DTATIM (DRIVE) - THIS TABLE REPRESENTS THE "MSTIME" OF THE LAST DTA
OPERATION ON A PARTICULAR DRIVE. THIS INFORMATION IS USED TO DETERMINE
WHICH IS THE "OLDEST" DRIVE WHEN A TAPE IS TO BE UNWOUND FOR A NEW TAPE
MOUNTING.
     CMWCNT - THIS PARAMETER CONTAINS THE NUMBER OF TAPES REQUESTED THAT
MUST BE MOUNTED. IT DOES NOT INCLUDE TAPES ALREADY MOUNTED.

     DTALLY - THIS REPRESENTS THE TOTAL NUMBER OF FILE COMMAND REQUESTS
PENDING.

     THISPN - THIS CONTAINS THE PROJECT-PROGRAMMER NUMBER OF THE LAST
USER WHO OBTAINED FILE COMMAND SERVICE.

     DTDRIV - IS THE SIXBIT DECTAPE DRIVE NUMBER CURRENTLY BEING
REFERENCED.

     DTUNIT - REPRESENTS THE TABLE INDEX OF THE DRIVE BEING REFERENCED.

     WAITIN (INDEX) - THIS TABLE CONTAINS THE SIXBIT TAPE NUMBERS
WAITING TO BE SERVICED. THIS IS USED TO NOTIFY THE OPERATOR OF PENDING
REQUEST.

     CMXNAM (INDEX) - THIS TABLE MAY CONTAIN UP TO FIVE (5) COMMAND FILE
NAMES REPRESENTING CONSECUTIVE DTA OPERATIONS TO BE DONE ON THE SAME
DECTAPE AND FOR THE SAME USER.

THE DECTAPE REQUEST QUEUE IS SERVICED ON A FIRST COME, FIRST SERVED
(FCFS) BASIS. HOWEVER, IF IN ADDITION TO THE PRESENT FILE REQUEST, OTHER
REQUESTS FOR THE SAME DECTAPE NUMBER AND FROM THE SAME USER ARE PENDING,
THEY ALSO WILL BE PROCESSED UP TO A CERTAIN MAXIMUM (PRESENTLY EQUAL TO
5). THE NEXT REQUEST SERVICED IS THE NEXT FILE IF IT IS NOT FROM THE
SAME USER AS THE LAST OPERATION AND THE QUEUE IS NOT BEING SEARCHED
AGAIN (I.E., PERHAPS ONLY ONE USER HAS FILE REQUESTS PENDING).

THE DECTAPE HANDLER CONTINUES TO ASSIGN NEW DRIVES FOR EACH ADDITIONAL
NEED TO MOUNT A TAPE UNTIL UNSUCCESSFUL. IT THEN SEARCHES FOR THE
"OLDEST" USED DRIVE BY LOOKING INTO THE DTATIM TABLE. THE TAPE TO BE
DISMOUNTED IS THE OLDEST TAPE AND THERE ARE NO PENDING REQUESTS FOR IT.
IF THERE ARE PENDING REQUESTS FOR ALL MOUNTED TAPES, THE OLDEST TAPE IS
UNWOUND AND DISMOUNTED.

THE OPERATOR IS NOTIFIED OF PENDING REQUEST FOR DECTAPES NOT ALREADY
MOUNTED. IMMEDIATELY BEFORE EACH REQUEST TO MOUNT A DECTAPE WILL APPEAR
UP TO FIVE DECTAPE NUMBERS PENDING. IN THE LEFT MARGIN JUST BEFORE THE
MOUNT REQUEST APPEARS THE NUMBER (DTALLY) OF FILE COMMANDS PENDING. THIS
NUMBER MAY NOT BE THE SAME AS THE NUMBER OF TAPES WAITING TO BE MOUNTED.
A TYPICAL MOUNT MESSAGE TO THE OPERATOR IS (WRITE ENABLED IS ALWAYS
IMPLIED):

     563  123  167
     05 JOB 11 TTY3 [1,7] MOUNT 198 ON DTA4:

THE OPERATOR SHOULD RESPOND BY MOUNTING THE TAPE AND TYPING CARRIAGE
RETURN OR SPECIFYING SOME OTHER DRIVE (EITHER N OR DTAN) FOLLOWED BY
CARRIAGE RETURN. IF THE CORRECT TAPE WAS MOUNTED, THE DECTAPE OPERATION
IS PERFORMED. IF THE REQUIRED TAPE WAS NOT FOUND ON THE SPECIFIED DRIVE,
OMOUNT WILL SEARCH FOR THE CORRECT TAPE AND ALSO UPDATE THE DTANUM
TABLE.

IF THE PPN FOR THE CORRECT TAPE DIFFERS FROM THAT GIVEN IN THE SYSTEM
DECTAPE FILE, DTAPPN.SYS, THE OPERATOR SHOULD SEE:
     "XXX[PJX,PGX] ON DTAN DISAGREES WITH [PJY,PGY] IN DTAPPNSYS.
     TO UPDATE DTAPPN.SYS DO YOU WISH TO PROCEED?"

THIS CONDITION MAY OCCUR IF THE DECTAPE HAS BEEN USED DIRECTLY WITHOUT
USING THE U/OMOUNT SYSTEM. THE OPERATOR SHOULD NORMALLY RESPOND WITH
YES. IF THE RESPONSE IS NO, HE MUST THEN ANSWER WHY. WITH A NO, THE
CURRENT OPERATION IS ABORTED, AND THE OPERATOR'S ANSWER IS RETURNED TO
THE USER VIA THE DIRECTORY FILE.

	THE OPERATOR MAY ALSO REPLY:
		/CANCEL	CANCEL REQUEST AND DELETE FROM QUEUE
		/DEFER	CANCEL REQUEST BUT DONT DELETE FROM QUEUE
		/START:X START PROCESSING X REQUESTS AFTER THIS ONE
		/STOP:X	STOP PROCESSING X REQUESTS AFTER THIS ONE
			X=PLEASE,FILE,MOUNT,NONE,ALL
			/START & /STOP MAY ACCOMPANY OTHER REPLIES

A REQUEST TO DIRECTLY ACCESS A DECTAPE SHOULD BE DONE BY THE MOUNT
COMMAND RATHER THAN THE PLEASE COMMAND. OMOUNT WILL THEN REASSIGN A
DRIVE TO THE JOB REQUESTING THE MOUNT AND UPDATE DTANUM ACCORDINGLY IF
THE OPERATOR ALLOWS IT. OMOUNT FIRST CHECKS TO SEE IF THE USER ALREADY
HAS A DRIVE ASSIGNED.

THE DECTAPE SERVICE IN OMOUNT CAN CONTROL OFF-HOUR DECTAPE OPERATIONS.
OFF-HOUR IS DEFINED WHEN THE OPERATOR IS NOT PRESENT (I.E. SET SCHED
400). DURING THIS TIME, NO TAPES WILL BE UNWOUND. DECTAPES MOUNTED WILL
BE SERVICED WITHOUT OPERATOR INTERVENTION. IF A REQUESTED TAPE IS NOT
MOUNTED, THE FOLLOWING USER MESSAGE WILL BE STORED IN THE USER DIRECTORY
FILES:

     "?SORRY, NO OPERATOR IS PRESENT"

BEFORE THE OPERATOR LEAVES, HE CAN MOUNT PREVIOUSLY SELECTED TAPES
(INCLUDING SCRATCH TAPES) TO BE USED DURING OFF HOURS. AFTER THE
OPERATOR TYPES THE OPERATOR PRIVILEGED COMMAND, SET SCHED 400, OMOUNT
WILL REFERENCE ALL DECTAPE DRIVES TO UPDATE ITS CORRESPONDENCE TABLES
AND PROCEED WITH OFF-HOUR OPERATIONS.

MESSAGES TO OPERATOR
-------- -- --------
1.  IF OMOUNT IS UNABLE TO ASSIGN ANY DECTAPE DRIVES, THE OPERATOR SEES:

     "?NO DECTAPE DRIVES AVAILABLE"

    THE OPERATOR SHOULD DEASSIGN DRIVES TO THE SYSTEM POOL OR REASSIGN
    DRIVES TO THE OMOUNT JOB.
2.  IF A USER'S REQUEST FOR A SCRATCH TAPE WAS UNSUCCESSFUL BECAUSE NO
    SCRATCH TAPES WERE AVAILABLE, THE OPERATOR IS NOTIFIED.

      "?NO SCRATCH TAPES"

3.  IF FOR SOME REASON OMOUNT CANNOT REASSIGN A DEVICE TO A USER
     ON A MOUNT COMMAND.  THE OPERATOR WILL BE NOTIFIED:

	"?CANNOT REASSIGN DEVICE TO USER"

     AND THE PARTICULAR DEVICE WILL BE DEASSIGNED FROM THE OMOUNT JOB.
OPERATOR COMMANDS
-----------------

MOUNT NAME

	THE 'MOUNT' OPERATOR COMMAND IS SIMILAR TO THE 'MOUNT'
	USER COMMAND EXCEPT THAT THE F.S. IS NOT ADDED
	TO OMOUNT'S SEARCH LIST.
	IN ADDITION THE REQUIREMENT THAT THE F.S. NAME BE
	IN STRLST.SYS IS NOT MANDATORY.  THIS ALLOWS
	THE OPERATOR TO MOUNT FILE STRUCTURES UNDER A DIFFERENT NAME
	THAN THE ONE RECORDED IN THEIR HOME BLOCKS AND ALLOWS THE
	STRLST.SYS SEARCH TO BE BYPASSED.
	THE SWITCH /NOSEARCH WILL SUPPRESS ANY SEARCHING
	OF STRLST.SYS.
	IF THE F.S. NAME TYPED IN DIFFERS FROM THE ONE IN
	THE HOME BLOCKS, A WARNING IS TYPED. IF THE OPERATOR
	PROCEEDS AND IF THE MOUNT IS SUCCESSFUL,
	THE F.S. WILL BE GIVEN THE OPERATOR'S NAME (RATHER THAN
	THE HOME BLOCK NAME).

	FOR EXAMPLE TO MOUNT A 2-PACK F.S. TO HAVE THE NAME 'FOO'
	REGARDLESS OF WHETHER IT IS IN STRLST.SYS
	OR WHAT ITS HOME-BLOCK NAME IS:
		!MOUNT FOO (DP,DP) /NOSEARCH
REMOVE NAME

	REMOVE IS SIMILAR TO THE USER 'DISMOUNT/REMOVE'
	COMMAND.

LOCK NAME

	TO 'LOCK' A F.S. MEANS TO PREVENT ANY FURTHER NEW
	ACCESSES TO IT -- FILES CURRENTLY OPENED ON THE F.S.
	ARE ALLOWED TO PROCEED NORMALLY TO A CLOSE.

	THE F.S. IS CHECKED AS IN THE REMOVE COMMAND FOR
	ANY SPECIAL CONDITIONS (E.G. MOUNT COUNT .GT. 0 ETC).

USERS NAME
USERS

	A LIST OF THE SPECIFIED F.S.'S UNITS, SPECIAL CONDITIONS
	(E.G. WHETHER LOCKED OR NOT), AND USERS (JOBS IN WHOSE
	SEARCH LIST IT APPEARS) IS TYPED.

	IF NO F.S. NAME IS TYPED, ALL MOUNTED F.S.'S ARE LISTED.

	IF THE F.S. IS IN THE SYSTEM SEARCH LIST, THE WORD 'SYS'
	IS INCLUDED IN THE JOB-NUMBER LIST.
START:X		(X=FILE,MOUNT,ALL,ALL)
START		(EQUALS START:ALL)

	THE SPECIFIED TYPE OF REQUESTS WILL BE SERVICED. I.E.
	ONLY THE SPECIFIED TYPE OF COMMAND FILES ARE SCANNED FOR
	IN THE REQUEST QUEUE.
	OMOUNT IS STARTED (R OMOUNT) IN A 'START:NONE' CONDITION
	THEREFOR AN INITIAL START (OR START:FILE OR START:MOUNT)
	COMMAND MUST BE GIVEN BEFORE REQUEST SERVICE WILL BEGIN.

STOP:X		(X=FILE,MOUNT,ALL,ALL)
STOP		(EQUALS STOP:ALL)

	STOP SERVICING (SCANNING THE REQUEST QUEUE FOR) THE SPECIFIED
	TYPE OF REQUESTS.

KILL:X		(X=FILE,MOUNT,ALL,ALL)
KILL		(EQUALS KILL:ALL)

	PURGE THE REQUEST QUEUE OF ALL PENDING REQUESTS OF THE
	SPECIFIED TYPE.  AFTER A MONITOR RELOAD THE
	'KILL:MOUNT' COMMAND SHOULD BE GIVEN SINCE
	ANY UNPROCESSED MOUNT-DISMOUNT REQUESTS LEFT OVER
	FROM BEFORE THE RELOAD ARE IRRELEVENT IF NOT DANGEROUS.
