$A PAGENO=1; JUST=1; TOP=3; BOTTOM=4; MARK=2
$A NLS=2
$A TAB=5,10,15,20,25,30
$B1
$N
$L1CM
PDP 11/40 SYSTEM
$P1 @THE NEW SYSTEM IS BASED ON A MESSAGE PASING SCHEME. @A
MESSAGE CONSISTS OF FOUR WORDS, THE FIRST OF WHICH HOLDS THE
ROUTING INFORMATION, BOTH FOR THE MESSAGE AND ANY REPLY. @THE
REMAINING THREE WORDS ARE USED FOR PASSING PARAMETERS.  @IN .IMP IT IS
EXPRESSED AS FOLLOWS:-
$A INDENT=1
.$%RECORD .$%FORMAT .PF($%BYTEINTEGER .SERVICE, .REPLY, .$%C
$I0
$I+1 .$%INTEGER .A1, .A2, .A3)
$A INDENT=0
$P1 
@THREE ROUTINES ARE PROVIDED IN .'PERM' TO SEND AND RECEIVE MESSAGES,
THEY ARE ACCESSED AS FOLLOWS:-
$A INDENT=1
.$%PERMROUTINESPEC .PON($%RECORD .(PF) .$%NAME .P);  ! SEND A MESSAGE
$B0
.$%PERMROUTINESPEC .POFF($%RECORD .(PF) .$%NAME .P); ! WAIT FOR A REPLY
$B0
.$%PERMROUTINESPEC .SVC($%RECORD .(PF) .$%NAME .P); ! SEND AND WAIT
$B0
.NOTE: .IMP AS IMPLEMENTED BY 
 @PETER @ROBERTSON IS DIFFERENT FROM .EMAS .IMP
 IN ITS SYNTAX IN .RECORD SPECIFICATION.
$A INDENT=0
$P1 @THESE ROUTINES COPY THE RECORD. @THE .KERNAL MAINTAINS
LISTS OF MESSAGES WAITING TO BE PROCESSED.
@THE .KERNAL ALSO HOLDS A LIST, MAPPING SERVICE NUMBERS TO TASK
IDENTIFIERS.  @A .TASK IS NORMALLY ALLOCATED THE SAME SERVICE NUMBER
AS ITS OWN IDENTIFIER AND IT IS POSSIBLE TO OBTAIN OTHERS.
$B0
 @THE REST OF THE .KERNAL
CONSISTS OF 1) .CPU SCHEDULER, 2) .CORE ALLOCATE/RETURN ROUTINES
AND 3) A .CLOCK HANDLER.
@ALL OTHER FUNCTIONS IN THE SYSTEM ARE PROVIDED BY 'SYSTEM' TASKS, 
RUNNING IN .USER MODE.
$P1 @INTERRUPTS ARE TAKEN IN .KERNAL MODE, AND ARE PASSED UP TO THE
OWNING TASK VIA THE MESSAGE PASSING MECHANISM. @THE TASK
WOULD THEN DEAL WITH THE INTERRUPT IN .USER MODE. @THIS STRATEGY
WILL WORK FOR MOST DEVICES, BUT FOR SOME EXTREMELY TIME CRITICAL
ONES IT WILL MAKE SENSE TO HANDLE THEM PARTIALLY IN THE .KERNAL,
OR IN OTHER WORDS A 'SOFTWARE' INTERRUPT INTERFACE IS USED.
$P2 @ALL .TASKS ON THE SYSTEM RUN IN A VIRTUAL
MEMORY ENVIRONMENT, ENSURING THAT TASKS CANNOT OVERWRITE
EITHER OTHER TASKS OR THE SYSTEM ITSELF.  @IN GENERAL A FULL
32K WORD VIRTUAL MEMORY IS AVAILABLE FOR EACH
TASK, BUT CERTAIN SEGMENTS (A 4K AREA) IS
NORMALLY USED TO CONTAIN SHARED MATERIAL 
IE .PERM
(WITH READ ONLY ACCESS).
$P1 @A SWOPPING STRATEGY (TO AND FROM THE DISC) WILL BE EMPLOYED IF
THE REAL CORE BECOMES OVERALLOCATED.
$P1 @A TASK COMMUNICATES WITH OTHER TASKS %ONLY VIA THE .PON/POFF
MECHANISM (SYSTEM TASKS ARE ALLOWED TO ACCESS THE DEVICE REGISTERS
DIRECTLY), CONSEQUENTLY ALL INTERFACES WILL BE EXPRESSED IN MESSAGE
TERMS.
$B2
$L1C
DEVICES
$A INDENT=1
$I-1 .RK05: $T+1 @THE .DISCS ARE HANDLED BY TWO TASKS, THE FIRST ONE
ORGANISES THE TRANSFER OF DATA TOAND FROM CORE 
(IN BLOCKS OF 256 WORDS),
SEE .APPENDIX .ONE FOR THE DEFINITION OF THE INTERFACE. @THE SECOND 
TASK HANDLES THE FILE STRUCTURE ON THE DISCS, ALLOWING FILES TO
BE CREATED, DESTROYED, EXTENDED ETC (SEE .APPENDIX .TWO).
$B1 $I-1
.TERMINALS: $T+1 @EACH CONSOLE DEVICE IS HANDLED BY A TASK (WHICK
WILL SHARE COMMON CODE), CALLS ARE PROVIDED TO READ, WRITE AND PROMPT
ON THE DEVICE. @SEE .APPENDIX .THREE FOR DETAILS.
$B1
@THERE IS ALSO A .COMMAND .LANGUAGE .INTERPRETER TASK ASSOCIATED 
WITH EACH CONSOLE, TO RUN AND OTHERWISE CONTROL PROGRAMS, THOUGH IT
MAY BE OMITTED IF THE TERMINAL IS ONLY GOING TO BE USED
FOR 'SIMPLE' .I/O.
$B2
$I-1 .TU16 .(MAGTAPE): $T+1 @A TASK
WILL INTERFACE THIS DEVICE TO THE SYSTEM, A PRELIMINARY
SPECIFICATION OF THE INTERFACE IS GIVEN IN .APPENDIX .FOUR, BUT THE
FULL DETAILS OF ERROR REPLIES MAY HAVE TO CHANGE
IN THE LIGHT OF EXPERIENCE.
$B2 $I-1 .DQS11E .(SDLC .HARDWARE): $T+1 @ONE TASK WILL BE USED TO
HANDLE DATA TRANSFERS ON THE LINE,
A SECOND TASK WILL INTERFACE TO IT AND CONTROL THE .SDLC PROTOCOL
(IE RETRIES AFTER ERRORS ETC).
$B2 $I-1 .CARD .READER, .LINE .PRINTER ETC: $B0
@ONE TASK WILL LOOK AFTER EACH DEVICE, USING A SUBSET OF THE
TERMINAL INTERFACE TO DRIVE IT.  @NORMALLY THERE WILL
ALSO BE A SPOOLING PROGRAM TO ORGANISE THE QUEUING OF FILES.
$B3
$A INDENT=0
$L1CM
NODE COMMUNICATION
$P1 @ALL COMMUNICATION WITH THE .NODE WILL BE SPOOLED. @A TASK
WILL BE WRITTEN THAT 1) @SEARCHES THE .DISC .DIRECTORY FOR FILES
OF A PARTICULAR TYPE OF NAME, ON FINDING ONE, IT WILL EITHER SEND IT TO
THE .NODE, OR USE IT AS THE BASIS FOR INSTRUCTIONS TO SEND
OTHER FILES TO THE .NODE (THIS SECOND FORM
MAY NOT BE NECESSARY).  2) @ON RECEIPT OF A FILE FROM THE .NODE,
IT WILL TRANSFER IT TO THE .DISC GIVING IT A NAME OF A PARTICULAR
TYPE.
$P1 @THESE FILES ON DISC WILL THEN BE INTERROGATED BY A SERIES
OF PROGRAMS, ON TO EACH DEVICE (IE LINE PRINTER, GRAPH PLOTTER, OR
OPERATOR TELETYPE). @THESE PROGRAMS WILL
ASK TO BE KICKED BY THE CLOCK ON A REGULAR BASIS (SAY ONE MINUTE)
AND WILL INTERROGATE THE .DISC .DIRECTORY TO SEE IF ANYTHING
HAS ARRIVED. @WHEN A FILE ARRIVES, IT WILL THEN BE .RENAMED AND
DEALT WITH. @WHEN ALL THE FILES HAVE BEEN
READ, THE PROGRAM WILL GO BACK TO SLEEP.
$B2
$L1CM
OPERATOR COMMUNICATION WITH THE NODE
$P1 @A TELETYPE WILL BE RESERVED FOR USE BY THE OPERATORS. @A PROGRAM
WILL READ A LINE FROM IT, PUT IT IN A FILE AND .RENAME IT FOR
AUTOMATIC TRANSMISSION.  @THE REPLY IS PUT IN A FILE AND THEN COULD
BE EITHER TYPED ON THE CONSOLE OR PRINTED ON THE LINE PRINTER.
$B2
$L1CM
SENDING MAGNETIC TAPES TO THE NODE
$P1 @AFTER DISCUSSION WITH @BILL @GORDAN, IT WOULD SEEM THAT 99.9$% OF
ALL TAPES WOULD EASILY FIT ON THE DISC (29,000 FULL CARD IMAGES),
THE SENSIBLE SCHEME 
WOULD THEN SEEM TO BE TO TREAT IT LIKE THE CARD READER, IE SPOOL IT ONTO
THE DISC FOR AUTOMATIC TRANSMISSION.  @A SEPERATE PROGRAM COULD
BE HELD (AND RUN OVERNIGHT SAY) TO HANDLE THE EXCEPTIONS, BUT
IT SHOULD BE POINTED OUT THAT FILES OF THAT LENGTH ( >29,000 CARD IMAGES)
COULD WELL HAVE TROUBLE REACHING THEIR DESTINATION DUE TO THE LONG
TIME REQUIRED TO TRANSMIT THEM.

$N
$A INDENT=2
$L1C
APPENDIX ONE
$L1CM
RK05 (DISC) HANDLER INTERFACE
$B2
$I-1 .SERVICE = 3
$B0 .A1 = 0 - .READ A BLOCK
$B0 .A1 = 1 - .WRITE A BLOCK.
$B1 .A2 = (VIRTUAL) .TRANSFER .ADDRESS.
$B1 .A3 = .BLOCK .NUMBER
$B2 $I-1 .ON .REPLY:-
$B0 .A1 = 0  @TRANSFER SUCCESSFUL.
$B0 $C+3      = 1  @VIRTUAL SEGMENT TOO SHORT/NON EXISTENT
$B0 $C+3     = 2  @COMMAND WRONG.
$B0 $C+3     = 3  .DISC FAULT - ADDITIONAL INFORMATION:-
$B0 $C+8 .A2 = .ERROR .REGISTER, .A3 = .STATUS .REGISTER.
$N
$L1C
APPENDIX TWO
$L1CM
DIRECTORY HANDLER INTERFACE
$I-1 .SERVICE = 4
$B1 .A1 = 0  .EXAMINE .FILE
$B0 $C+3 = 1  .GET .NEXT .BLOCK .NUMBER.
$B0 $C+3 = 2  .DESTROY .FILE.
$B0 $C+3 = 3  .CREATE .FILE.
$B0 $C+3 = 4  .APPEND .BLOCK .TO .FILE.
$B0 $C+3 = 5  .RENAME .FILE.
$B0 $C+3 = 6  .RENAME .IMP .TEMP .OUTPUT .FILE.
$B1 .A2 =  (VIRTUAL) ADDRESS OF NAME DESCRIPTOR
$B1 .A3 =  OTHER INFORMATION:-
$B0 $C+8 .A) .GET .NEXT - PREVIOUS BLOCK.
$B0 $C+8 .B) .APPEND - PREVIOUS BLOCK.
$B0 $C+8 .C) .RENAME - (VIRTUAL) POINTER TO 'NEW' FILE NAME.
$N
$L1C
APPENDIX THREE
$L1CM
TERMINAL HANDLER INTERFACE
$I-1 .SERVICE = 1 (MAIN TERMINAL)
$B0 .A1 = 0  .READ REQUEST.
$B0 $C+3 = 1  .WRITE REQUEST.
$B0 $C+3 = 2  .CLI READ REQUEST
$B0 $C+3 = 3  .PROMPT.
$B1 .A2 = (VIRTUAL) ADDRESS OF BUFFER.
$B1 .A3 = LENGTH OF DATA (FOR CALLS 1 AND 3).
$B2 $I-1 .ON .REPLY:-
$B1 .READ .REPLY - .A1 = NO OF CHARS READ (0 IS END-OF-FILE)
$B0 .WRITE .REPLY - .A1 = 0 IMPLIES AN ERROR
$B0 @THERE IS NO .PROMPT REPLY.
$N
$L1C
APPENDIX FOUR
$L1CM
TU16 (MAGTAPE) HANDLER
$B1 $I-1 .SERVICE = 6
$B1 .A1 = .COMMAND (SEE BELOW).
$B0 .A2 = (VIRTUAL) ADDRESS OF BUFFER (ON .READ AND .WRITE).
$B0 .A3 = LENGTH OF DATA/SUPPLEMENTARY INFO.
$B1 $I-1 .ON .REPLY:-
$B1 .A1 = 0 INDICATES SUCCESS, OTHERWISE A FAULT
$B1 @OTHER PARAMETER VALUES WILL DEPEND ON EACH COMMAND
$B2 $I-1 .COMMANDS
$B1 0 $C+2  NO OPERATION.
$B0 1 $C+2  REWIND OFF LINE.
$B0 2 $C+2  REWIND.
$B0 3 $C+2  DRIVE CLEAR (RESET DEVICE).
$B0 4 $C+2  ERASE.
$B0 5 $C+2  WRITE TAPE MARK.
$B0 6 $C+2  SPACE FORWARD  .(A3 = NO OF BLOCKS).
$B0 7 $C+2  SPACE REVERSE .(A3 = NO OF BLOCKS).
$B0 8 $C+2  WRITE CHECK FORWARD.
$B0 9 $C+2  WRITE CHECK REVERSE.
$B0 10 $C+2  WRITE FORWARD .(A3 = NO OF WORDS).
$B0 11 $C+2 READ FORWARD (ON REPLY .A1=NUMBER OF BYTES ACTUALLY READ).
$N
$E