github.com/PDP-10.its
1
0
Fork 0
mirror of https://github.com/PDP-10/its.git synced 2026-01-11 23:53:12 +00:00
Code Issues Releases Wiki Activity
PDP-10.its/doc/sysdoc/uuos.114
Björn Victor 96e382460d Document .RYEAR for timezone fix.
2021-06-23 17:07:11 +02:00

2358 lines
89 KiB
Plaintext
Executable File
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Copyright (c) 1999 Massachusetts Institute of Technology
See the COPYING file at the top-level directory of this project.
------------------------------
ITS UUOS:
This file attempts to maintain up-to-date documentation on
all non-symbolic ("old") system calls. Those wonderful
souls who update the information in any way (additions,
deletions, corrections) should describe their
modifications in a brief note to INFO-ITS@AI so
that interested parties can correct their copies or
conceptions without needing to print or read the
entire file again. For example:
:QMAIL INFO-ITS@AI I added more details to the .FOO uuo ^C
If you want to be put on the INFO-ITS mailing list,
just say so in a message to it.
-------------------------------------------------
On the PDP-10, opcodes 0 through 77 are deliberately "not
defined", and are called uuos ("unimplemented user operations").
Also, certain other opcodes are either illegal in user mode
or undefined (for example, I/O instructions, JRST 4,).
When an undefined instruction is executed, it "traps to 40":
it is stored in location 40
with the index and indirect fields zeroed and the address field
replaced by the effective address, and then the instruction
in 41 is executed (it is usually a subroutine call).
(Some instructions actually trap to 60 on KA's, but ITS contrives
to make them appear to have trapped to 40 just like all
the others).
uuos 1 through 37 are reserved for user programs. They
go through the entire trap sequence remaining in user mode,
so it is the user's locations 40 and 41 that are used.
The operating system is not involved at all.
These uuos are called "user uuos".
The other undefined opcodes enter exec mode during the trap,
so that the system's 40 and 41 are used; the PC saved by the
subroutine call will say "user mode" if the uuo was executed
in user mode, however. These instructions are the normal way
of calling any PDP-10 operating system.
ITS interprets uuos 40 through 47 as monitor calls; those
uuos are called "system uuos". The bulk of this file is devoted
to describing how to use them. In addition, ITS will simulate
some I/O instructions for the user (for example, any CONI, and
DATAI 0,). All other instructions that trap to the system
will be signaled to the user (they are "returnable uuos").
For simple programs, they will cause an ILOPR interrupt
(%PIILO, bit 1.6 of .PIRQC). For programs that appear able to
handle them, they are "returned" to the user, pretending to
be user uuos - that is, the system makes it appear that they had
trapped to the user's 40. However, they do not act precisely
like user uuos:
1) The system can't simulate any trap instruction but
unindexed, direct JSR. If the user's trap instruction is
not a JSR, or is indexed or indirect, the system assumes that
the user can't handle the returnable uuos, and causes an ILOPR
interrupt instead. Also, if the AC field of the JSR is nonzero,
the system will interrupt instead of returning the uuo; this
is a way for a program to say explicitly that it doesn't want
to have uuos returned, but still handle user uuos.
2) If the opcode in 41 is 0, the system treats it as if it
were a JSR.
3) 0 is not considered a reasonable place to JSR to. If the
address field of 41 is 0, the system will interrupt instead of
returning the uuo.
4) While the addresses 40 and 41 are fixed by hardware for
user uuos, for system returned uuos they are not. They must
always be consecutive, but the address of the first one is
kept in the RH of the .USET variable .40ADDR (whose initial value is,
of course, 40). Thus, the user may have one handler for user uuos
and another for returned uuos.
Note that the system uses "42" for interrupts and "43" and "44"
for the "locks" feature; those locations are also shifted
by setting .40ADDR.
5) Returnable UUOs have complicated interactions with DDT.
When proceeding from a breakpoint, DDT must simulate certain
instructions, including all those that can transfer control.
User uuos can be simulated properly, but not returnable ones
since DDT does not know how to decide whether they are to cause
ILOPRs. So DDT treats those uuos like the typical instructions;
it puts the uuo in 31, a jump to 1 + the actual address of the
uuo in 32, and a jump to 2 + that address in 33. It then starts
the job at 31. If the returnable uuo handler does nothing with
the PC except possibly return to it, and does not try to examine
the uuo except by looking at 40, this causes no problem. However,
if the uuo is followed by arguments, or if it can skip more than
once, or if it tries to remember the PC somewhere, the handler
must understand that if the PC is 31 (+1) special treatment is required.
In addition, the real location of the uuo will contain not the
uuo but a .BREAK, which will be there to implement the breakpoint.
If the .UTRAP variable of a job is nonzero, ALL instructions
that trap to the system will cause ILOPR interrupts - even those
that are usually treated as system calls. In addition, the
job will not handle any of its own interrupts - they all interrupt
its superior. Thus, the superior can make the job believe it is
running under a non-ITS environment. User uuos are not affected.
The .UTRAP variable is the same as the %OPTRP bit in the LH of .OPTION.
If the %OPDEC bit in the LH of .OPTION is set, uuos 40, 41 and 47
(as well as those I/O instructions which ITS usually simulates)
become returnable uuos instead of system calls. By a lucky
coincidence, those uuos, which are the only ones used by both
ITS and TOPS-10, are not really necessary in ITS (they are
.OPEN, .IOT and .ACCESS, and all have alternative forms using .CALL).
In this mode, all uuos used as system calls by TOPS-10 are
returnable. One of the TOPS-10 simulators works by setting
this bit, and making .40ADDR point into the simulator where
it lives at the top of core (to avoid conflicting with the user
uuo handlers of the simulated programs).
CALLS: Overview of ITS System Calls
ITS system calls come in two kinds: the older, numerically
decoded, non-standardized kind, and the newer "symbolic
system calls" with a standard calling sequence.
Each of the numerically decoded system calls is distinguished
from all of the others by the values of specific fields
in the instruction (the opcode, and maybe the AC and address
fields). Each specific system call is known as "a uuo", and
its name is a predefined symbol in the assembler, whose value
is the appropriate instruction. For example, one uuo is
.ACCESS; it is distinguished by the opcode field alone, which means
that the AC field and address are available as arguments.
The symbol .ACCESS is defined as the appropriate opcode.
.RCHST, however, is distinguished by its opcode and its address,
so that only the AC field can be used as an argument. The uuos
distinguished by opcode and address all have the same opcode,
which is called .OPER; thus, all such uuos are called ".OPER's".
.FDELE is distinguished by opcode and ac field, leaving the address
as an argument; such uuos are called ".CALL's" since they all have
.CALL as their opcode. Each uuo is described individually in this file.
The symbolic system calls all use the uuo .CALL. They are
distinguished by the contents of the block addressed by the .CALL,
which also points to the arguments. Ths symbolic system calls
are described in more detail in the file .INFO.;ITS .CALLS.
.ACCESS chnum,[access pointer] set file access pointer
Sets the access pointer for the I/O channel <chnum>
for the next input/output operation. This is used to
effect random access. On the DSK device (and DSK-like
JOB devices) the access pointer is the number of "bytes"
from the beginning of the file. Bytes are normally the
same as words, but in unit ascii mode there are five
seven-bit bytes per word. In the future there may be
the ability to have bytes of any size from 1 to 36 bits.
On the USR device the access pointer is the address
within the job's memory.
Random access on the USR device can also be effected
via page mapping (see the .CBLK uuo and the CORBLK
symbolic system call). If the channel number <chnum>
is variable, the symbolic system call ACCESS may
be used in place of the .ACCESS uuo.
The symbolic call RFPNTR may be used to read the current
access pointer for a file.
.ARMOFF turn AMF arm off
Turn the ARM arm off. The arm no longer exists.

.ARMOVE ac, move AMF arm
;normal return
;test successful return
This system call allows one job at at time to exercise
special control over several D/A multiplexor channels.
It provides acceleration and velicoty limiting, software
limit stops, and conversion from joint number to multiplexor
channel. The accumulator <ac> should contain -<length>,,<addr>
pointing to a block of words, each specifying a command.
If any test command is true, the .ARMOVE will skip.

.ARMRS reset AMF arm lock flags
Reset the AMF arm lock flags. The arm no longer exists.
.ASSIGN ac, assign a microtape
;skip if successful
The accumulator <ac> should contain the number of a
microtape drive. If it succeeds, it assigns the drive
to the user who executed the .ASSIGN. When a job
attempts to use a microtape drive,
it will succeed only if it has the same
sname as the uname of the job which did the .ASSIGN.
A .ASSIGN will fail only if the drive is already
assigned to a different user (i.e. a different uname),
or if an invalid drive number is given.
See also the .DESIGN and .RCHST uuo's.
.ATTY chnum, assign tty to inferior
;skip if successful
Puts the job in the state of wishing to pass control of
the tty to the direct inferior open on the specified
channel. It skips if successful; it fails if the
channel does not have a direct inferior open, if the
executing job had never had the tty, or if it had not
been in the state of wishing to retain the tty. If the
job had the tty, after the .ATTY the tty will belong
to the specified inferior, or one of its inferiors.
A job need not have the tty to do an .ATTY.
See the .DTTY uuo, and the .TTY user variable.
Also see ITS TTY.
.BREAK ac,address breakpoint instruction, etc.
The <ac> and <address> fields of this uuo are totally
ignored by ITS. The procedure executing it receives
a class 1 interrupt (bit 2.2 of the .PICLR user
variable, called %PIBRK), stopping it and interrupting
its superior.
The standard superior procedure, DDT, assigns
the following semantics to .BREAK, dependent on
the <ac> field (for full information see DDT ORDER):
<ac> meaning
1-10 Breakpoint number <n> in the program, for <n>
between 1 and 10.
12 Request for information transfer.
15 Temporary breakpoint number 1.
16 Request for program suspension or termination.
17 Temporary breakpoint number 2.
The "normal termination" instruction is .BREAK 16,160000
(but also see .LOGOUT).
When DDT sets a breakpoint in a program on a given
instruction, it replaces the opcode with .BREAK
and the ac field with the breakpoint number. Thus
the instruction will still calculate its usual effective
address before breaking. The two temporary breakpoints
are used for ^N (multiple instruction proceed), etc.
.BREAK 12, is used to transfer information between
DDT and the executing program at the latter's request.
.BREAK 12, is like .SUSET in that it points
either to a specification word or to an AOBJN
pointer of such words. Bit 4.9=0 means read, =1 means
write (from the program's point of view). Writing can
be illegal if the ..PERMIT variable in DDT for
the job is set appropriately. Bits 4.7-3.1
determine the type of information transferred:
..RSTA 1 Starting address of program.
..RLFI 2 Loaded file name.
Four words: device, sname, file name 1, file name 2.
..RSTP 3 (read only) AOBJN pointer to program's symbol table
in DDT. The left half is the negative of
the symbol table size. See type 7 (..RSTB).
..RSYM 4 Symbol definition. Uses two words.
Read: first word contains squoze for symbol.
Second word receives value.
If undefined, first word is zeroed.
Write: first word contains squoze, second value.
..RJCL 5 Read: fetches command string for program.
Set by : command or via :JCL.
Always transfers at least one word of
packed ascii, then more until either a
zero word is transferred or until a
non-zero is about to be transferred into.
String is terminated by ^M if non-null.
Write: clear command string.
..RPFI 6 File name defaults used for :PRINT.
Four words: device, sname, file name 1, file name 2.
..RSTB 7 Symbol table. Allows transfers of many
symbols in either direction.
..RCON 10 (read only) Number to symbol conversion.
Uses two words. The first should initially
contain a value. It receives squoze for
a symbol, and the next word receives a delta.
The value of the symbol plus the delta equals
the original argument. The lookup used by DDT
for symbolic typeout is employed here.
If the lookup fails, the first word receives
zero and the second receives what the first held.
..RXUN 11 (read only) The XUNAME (a uname to be used for
getting mail, etc.). This is like the UNAME, but
has trailing digits stripped off, etc. This is
OBSOLETE; use the .XUNAME user variable.
..RXJN 12 (read only) The XJNAME (what this job should think
of as its "real" name). This is like the JNAME,
but has trailing digits stripped off, etc. This is
OBSOLETE; use the .XJNAME user variable.
..RLJB 13 (read only) Read index of previously current job.
..RRND 14 Reads or writes the ..URANDM variable in DDT for
this job.
..RPUR 15 Unpurify page.
..RHSN 16 (read only) Ask to lookup an HSNAME from an XUNAME.
..RMAI 17 (read only) Ask to lookup user's mail file name.
(Symbols with names starting with "..S" exist for all those not
marked as read only. For example ..RSTA==1 and ..SSTA==400001.)
Illegal .BREAK 12,'s cause DDT to give the program an
illegal operation interrupt (bit 1.6 in the .PIRQC
user variable).
.BREAK 16, is used to return to DDT in various
nice ways. The effective address is decoded as follows:
2.9 Return from X. (Do not use unless you understand it!)
2.8 Type extra carriage return in DDT.
2.7 Do not reset TTY input (effective only if
executing job has the TTY).
"Normal" returns to DDT should always have
this bit set.
2.6 Kill executing job:
Immediately, if it has the TTY.
When it gets the TTY, if current job.
Otherwise when J'd to in DDT.
Will print ":KILL" when killed.
2.5 Kill executing job:
Like 2.6 if job current.
Otherwise is killed silently.
2.6&2.5 Together mean kill executing job:
Like 2.6 if job current.
Otherwise kill immediately, and print
JOB <jname> FINISHED on TTY.
2.4 Conditional breakpoint return.
2.8=1 => condition true.
2.8=0 => condition false.
Used by DDT. Dangerous for users to play with.
2.3 Don't type even a carriage return. Don't close
the currently open location. If killing self
don't type :KILL.
2.2-1.1 Illegal. (Reserved for expansion.)
DDT sets the %OPCMD and %OPBRK bits for
its inferiors appropriately. See the .OPTION
user variable.
.CALL [ SETZ ? SIXBIT \name\ ? -- args -- ] symbolic system call
;skip if successful
The .CALL uuo is used to invoke a large class of
operations which are distinguished by a sixbit name.
See the file ITS .CALLS for more information.
.CALL is sometimes used in a generic sense to denote
the set of uuo's with the same opcode as .CALL; they
are distinguished by their accumulator fields:
.CALL 0, .CALL
.CALL 1, .DISMISS
.CALL 2, .LOSE
.CALL 3, .TRANAD
.CALL 4, .VALUE
.CALL 5, .UTRAN
.CALL 6, .CORE
.CALL 7, .TRANDL
.CALL 10, .DSTART
.CALL 11, .FDELE
.CALL 12, .DSTRT
.CALL 13, .SUSET
.CALL 14, .LTPEN
.CALL 15, .VSCAN
.CALL 16, .POTSET
.CALL 17, unused
.CBLK ac, hack a core block
;skip if successful
This uuo is ARCHAIC. Its use should be avoided
in new programs, since the CORBLK symbolic system call
is much more flexible and easy to understand.
The contents of accumulator <ac> specify an operation
on the executing job's core. It modifies the job's
page map entry for one page. The contents of <ac>
should be as follows:
4.9 Must be zero.
4.3-4.1 Desired operation:
0 Get page from self.
1 Get absolute page.
2 Get a page from the user open on
the channel specified by bits 3.8-3.1.
3 Get a page from the user whose user
index is in bits 3.8-3.1.
4 Get fresh page.
5 Get public page.
6 Make my page public.
7 Make my page private.
3.9 If 1, request write permission for the page.
Assumed 1 for operation 4 (fresh page).
Otherwise valid only for self, public page,
or direct inferior open on channel.
3.8-3.1 User index or USR device channel.
If the executing job is a job device, then
377 will refer to the job which invoked it.
2.9 1 = insert page in core map.
0 = delete page. If the operation is 6 or 7,
this bit is ignored. Otherwise, the operation
is ignored for deletion.
2.8-2.1 Virtual page to be affected within the core map
of the executing job.
1.9-1.1 Block number within source specified by
bits 4.3-4.1.
Sample contents of <ac> for various operations:
Delete my page 43: 0,,43000
Create a fresh page 217: 4400,,517000
Make my page 45 be read-only: 0,,445045
Make my read-only page 45 writable: 400,,445045
Make page 16 of job 34 read-only
as my page 377: 3034,,777016
This uuo is all right for hacking single pages within
your own core map. To alter another job's core map,
or to hack many pages at once, use the CORBLK
symbolic system call.
For more information on core blocks, see ITS CORBLK.
.CLOSE chnum, close a file
The input/output channel <chnum> is closed. All
operations associated with that channel are completed.
For file structured devices, if another file with
the same name exists (if <chnum> was being used for
output), that file is deleted at this time and the new
file replaces it.
Any further attempts to use the channel without re-opening
it will cause errors.
.CLOSE does nothing if the channel is not open.
If the USR device is open on the specified channel,
the job is not killed by .CLOSE; it is merely made
to be no longer open on the channel. To kill a USR
device job, the .UCLOSE uuo must be used.
If the channel number is a variable, the CLOSE
symbolic system call may be used.
.CORE <number of blocks> set core limit
;skip if successful
This uuo is a relic of the old pre-paging version of ITS.
For applications which want to be relatively clever
about paging and core allocation, see the .CBLK uuo
and the CORBLK symbolic system call.
The effective address of .CORE should be a number between
0 and 400 octal. The core of the procedure executing it
is modified as follows:
(DEFUN *CORE (N)
(DO ((K (// (*SUSET *RMEMT) 2000)
(// (*SUSET *RMEMT) 2000)))
((= K N))
(COND ((< K N) (CREATE-PAGE K))
(T (DELETE-PAGE (- K 1))))))
That is, at each step a page is either added or deleted
at the top of the job's memory until page <n-1> is the
highest one in the job's memory. Only a .CORE to
acquire more core can fail. If a .CORE fails to skip,
some of the requested core may have been obtained,
though not all.
.DCLOSE display close
This system call releases the 340 display or the
E&S display, if possessed by the executing job, and
closes all channels on which the display is open.
If the display is being hacked via .DSTART, this
won't be any channels. In the case of the 340, the
display is made available to the pdp-6.
If the executing job does not possess the
display, .DCLOSE does nothing but return.

.DCONTIN display continue
This system call will restart the E&S display after stopping
or single stepping (.DSTOP, .DSTEP). If the display is
stopped because of a Display MPV, a Hit Stop, WCR stop or
PROG Stop, the condition will NOT be cleared and the display
NOT restarted. If the display is not stopped or does not
belong to the executing job, no action is taken.
This system call is ignored by the 340 display.
.DEMON acknowledge one demon request
.DEMON ac, acknowledge <n> demon requests
;skip if successful and more requests pending
As of September 1, 1976, only the DM machine has this.
If the executing job is not a demon, the uuo merely returns
without skipping. If it is a demon, then either 1 or
the contents of the specified non-zero <ac> are subtracted
from the demon's request count, and the uuo skips iff the
resulting count is still positive.
See the DEMSIG, RDDMST, and STDMST symbolic system calls.
.DESIGN ac, de-assign a microtape
;skip if successful
The accumulator <ac> should contain the number of a
microtape drive. It reverses the effect of a .ASSIGN
uuo by making the drive unassigned again. A .DESIGN
will fail only if an invalid drive number is given,
or if the drive is assigned to some other user than
the one owning the job trying to do the .DESIGN.
It will succeed if the drive is already unassigned.
.DIAL ac, ANCIENT HISTORY dial a dataphone line
;skip if successful
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .NETAC.
The accumulator <ac> should contain a byte pointer
of the following form:
440600,,[data](n)
where <n> is not an index field, but the number of
a dialer (0 or 1), and <data> is a series of dialing
bytes. The byte string may not be longer than 5 words.
Each byte specifies a dialing step as follows:
0 End of data.
1-10. Send 1-10. dialing pulses. Pauses are supplied
between digits automatically.
> 10. Pause <<byte>-10.> seconds in dialing.
If the accumulator is zero except for the dialer number,
then the "break" signal is sent after any previous
dialing has been completed.
A .DIAL will fail if the dialer number is invalid,
if the TTY associated with the dialer (0=T07, 1=T06)
is in use by another job, or if the dialer is being used
by some other job (the other job has not done .HANGUP yet).
See the .DIALW and .HANGUP uuos.
.DIALW dialnum, ANCIENT HISTORY wait for dialing to finish
;skip if successful
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .NETS.
If dialer number <dialnum> is assigned to the job
executing the .DIALW (i.e. the job has done a .DIAL
but not a .HANGUP), then .DIALW skips after waiting
for dialing to be completed. Otherwise it fails.
See the .DIAL and .HANGUP uuos.
.DIETIME ac, OBSOLETE time until system dies
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by the SSTATU
symbolic system call.
The accumulator <ac> is set to the maximum time
(in thirtieths of a second) before ITS will go
down. If the system is not planning to go down
(the normal case, we hope!) <ac> is set to -1.
See also the .REVIVE and .SHUTDN uuos.
.DISMISS [new PC] dismiss an interrupt
Dismiss an interrupt. The user variable .PICLR
is set to -1, thereby enabling interrupts, and the PC
receives the quantity <new PC>.
This is for the so-called "old-style" interrupt scheme.
See also the DISMIS symbolic system call, which
is ordinarily used with the "new-style" vectored
interrupt scheme, but may be used in either case.
Typically .DISMISS is used in this manner:
LOC 42
JSR TSINT ;pointer to interrupt handler
LOC 100 ;or wherever
TSINT: 0 ;interrupt flags
0 ;PC as of interrupt
EXCH A,TSINT
TSINT1: TLZE A,<bit1> ;check for various interrupts
JRST <handler1> ;handlers return to TSINT1
TLZE A,<bit2>
JRST <handler2>
. . . .
MOVE A,TSINT ;restore accumulator
.DISMISS TSINT+1 ;dismiss interrupt
See ITS INTRUP for more information on interrupts.
.DISOWN chnum, disown an inferior
An inferior job should be open on channel <chnum>.
The job is caused to be no longer an inferior of
the executing job, and is made to be the top level
job of a disowned job tree. The usual reason for
disowning a job is so that it can continue to exist
after its former superior has been killed (for instance,
after the user who disowned it has logged out).
Another reason for disowning a subtree is to reown it
under a different superior, thus altering the shape
of the system's job-tree structure.
All channels on which the executing job has open the
job being disowned will be closed in the process of
disowning (see the .CLOSE uuo). Disowning is illegal if
<chnum> does not have an inferior open, or if the
subtree being disowned controls the console (see the
.ATTY uuo). If the jobs of the subtree have opened
the console, then the channels are not closed, but
are marked as "disowned tty"; certain operations
on such a channel will succeed, and others will hang
until the tree is re-owned and a console tty given
to the job. Such channels appear to be open on
tty number %TINON=77 octal.
A disowned job is distinguished by the fact that
bit 4.9 of its .APRC user variable is set.
A disowned job never succeeds in executing the RELOAD symbolic
system call, even if it is the top level job in its tree.
When a job tree is logged out, any micro-tapes assigned
to the uname of that job tree are de-assigned (see the
.ASSIGN and .DESIGN uuo's), but only if the job tree is
not disowned.
All disowned jobs share a resource word for purposes of
scheduling, in the same way that all jobs in a single
non-disowned tree share a resource word. Thus all disowned
jobs tend collectively to use no more runtime than any
single non-disowned job tree.
Furthermore, individual disowned jobs are given only 1/4
the priority to run as a non-disowned job. This does
not apply, however, if the disowned job in question has
.MASTER mode, or controls the 340 display, the E&S display,
the vidisector, the arm, the LPT (line printer), or the
PLT (plotter).
When operating under heavy loads, the swapper prefers to
swap out disowned jobs rather than non-disowned jobs.
The DETACH symbolic system call makes a non-disowned tree
disowned.
When a non-disowned top-level job encounters
a fatal interrupt, the system will make it disowned and
print a suitable message on the system console and on
the job's console (if it has one). The disowned tree
can then be reowned with DDT and debugged.
.DMPCH ac, OBSOLETE mung dump check bit
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by the RDMPBT
and SDMPBT symbolic system calls.
The accumulator should contain a channel number
in the right half, which should have a disk channel
open on it. The left half describes any alterations
to be made to the dump check bit for the open file:
4.9 Set dump check bit.
4.8 Clear dump check bit.
The state of the dump check bit (possibly after setting)
is returned in accumulator <ac> in bit 1.1.
The dump check bit is used by the magtape file backup
system to keep track of which files have been backed
up on magtape. This bit therefore should not be
twiddled light-heartedly. The "!" you sometimes see
in front of a date in a disk file directory is present
iff the dump check bit for the file is zero.
.DSTART [start-addr] start the display
; skip if successful
This system call is used to start the E&S or 340 display processor,
whichever one the system has. If it has neither, the uuo is
an illegal operation and gives a %PIILO interrupt.
.DSTART assigns the display to the executing job if it is available,
and skips if successful. If the display is not available
.DSTART does not skip.
In the case of the 340 display, the effective address of the
.DSTART is the address of the user's display list. This can
be either a single BLKO pointer (if the word is negative), or
the first word in a linked list (if the word is positive).
The right half of each word in the linked list is zero
to end the list, or the address of the next word in the list.
The left half of each word in the linked list is the address
(which must be less than 400000!) of a BLKO pointer. If this
address is zero, or the BLKO pointer is zero, it is ignored
(this allows "jump-type" entries in the list.)
The display will continually execute the commands pointed
to by this list. It is OK to change the list, or the single
BLKO pointer, while the display is running, provided everything
always points to valid data.
The .DSTRTL uuo is the same as .DSTART except that it uses
regular AOBJN pointers instead of BLKO pointers.
In the case of the E&S display, the argument to .DSTART contains
in the right half, the address at which the display program will
start, and in the left half, a code to determine modes of
operation: There are four 3-bit fields in this code:
3.1-3.3 Start mode. Only the 3.1 bit is significant. If set,
the display is started in single step mode.
3.4-3.6 Action to take on Program stop.
3.7-3.9 Action to take on Hit stop.
4.1-4.3 Action to take on Memory stop.
Each of the three Action fields is decoded as follows:
0 Restart from address of the last .DSTART.
1 Continue after the stop condition has been reset.
2 Stop.
3 (Reserved).
4 Interrupt and restart.
5 Interrupt and continue.
6 Interrupt and stop.
.DSTEP step the E&S display
The .DSTEP call will step the display processor one instruction
cycle if it has been stopped (.DSTOP) or started (.DSTART) in
step mode. If the display is not stopped, .DSTEP will first
simulate a .DSTOP. If the display is not the executing job's,
no action is taken.
The .DSTEP call is ignored by the 340 display.

.DSTOP stop the display
The .DSTOP call will stop the E&S or 340 display processor,
if the display belongs to the executing job.

.DSTRTL start the display
In the case of the 340 display, this is the same as
.DSTART (q.v.) except that the display will use AOBJN
pointers instead of BLKO pointers.
In the case of the E&S display, this
crashes the system. Maybe someday this will be fixed.
.DTTY devour the tty
.DTTY is used when a job decides that it wishes to
retain the tty. It skips if it succeeds; it fails if
the job was already in the state of wishing to retain
the tty, or if it had never had the tty. If the tty had
actually belonged to some (possibly indirect) inferior, it
will belong after the .DTTY to the job that executed it.
A job need not have the tty to do a .DTTY.
See ITS TTY for a full explanation of .DTTY.
See also the .ATTY uuo, and the .TTY user variable.

.DWORD [word] send word to E&S display
The specified word is sent to the E&S display via
the DATAO instruction. The display is stopped first
via .DSTOP if necessary.
This system call is ignored if there is no E&S display
or the executing job does not own it.

.EOFC ac, OBSOLETE end of file character
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been obsoleted and not replaced.
Accumulator <ac> receives the eof character used to
pad the end of the file open on the channel specified
by the contents of <ac> before the uuo is executed.
Apparently early microtape files used 141 as the pad
character.

.EVAL ac, evaluate squoze symbol
;skip if successful
Before the uuo is executed, accumulator <ac> should
contain the squoze code for a symbol. This symbol
is looked up in the symbol table used by exec DDT
(the one used to debug ITS); this table contains
symbols defined within ITS. The uuo fails to
skip if the symbol is not found; otherwise the value
is placed in <ac> and the uuo skips.
This uuo offers a useful method of obtaining
information from ITS, when combined with the .GETLOC
uuo or with absolute memory pages; for example,
to find out how many irrecoverable disk errors there
have been, PEEK .EVAL's the symbol QIRRCV and examines
that location in the system. Naturally, this is more
risky than using a system call, since the system's
symbols may be changed. One protection against that
is to make an entry in the file AI:SYSTEM;EVSYMS >
mentioning which symbol is being .EVAL'ed by which
program. Then, there will probably be warning from
ITS hackers of any change.
.FDELE fblock OBSOLETE delete or rename file
;skip if successful
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by the DELETE,
RENAME, and RENMWO symbolic system calls.
This uuo may be used to delete and rename files.
It points to a five-word block describing the
operation to be performed. There are three cases.
[1] Delete a file.
fblock: SIXBIT \ dev\ ;right-justified device name
SIXBIT \fname1\ ;file name 1
SIXBIT \fname2\ ;file name 2
0 ;zero
--- ;not examined
[2] Rename a file open for writing on channel <chnum>.
fblock: --- ;not examined
0 ;zero
<chnum> ;channel number
SIXBIT \fname1\ ;new file name 1
SIXBIT \fname2\ ;new file name 2
[3] Rename an arbitrary file.
fblock: SIXBIT \ dev\ ;right-justified device name
SIXBIT \fname1\ ;old file name 1
SIXBIT \fname2\ ;old file name 2
SIXBIT \fname1\ ;new file name 1
SIXBIT \fname2\ ;new file name 2
In cases [1] and [3], if the device specified has
true directory structure, the .SNAME user variable
for the executing job is used as the directory name.
Also, the file names (for case [1]) or the old file
names (for case [3]) are subject to input translation
(see the TRANAD symbolic system call).
If the device is not file structured, .FDELE
succeeds and skips. If .FDELE fails, it returns
an error code on channel 0 which can be retrieved via
the .STATUS uuo or the ERR device.
.FEED chnum, feed paper tape
;skip if successful
If device PTP (the paper tape punch) is open on
channel <chnum>, the uuo punches one line of blank
tape and skips. Otherwise it fails and does not skip.

.GENNUM ac, generate number
Accumulator <ac> receives a unique generated number
which will not be generated again for a very long
time (unless the system crashes, in which case the
counter is reset, of course).
[ In ITS 1554 and later. ]

.GENSYM ac, generate symbol
Accumulator <ac> receives the sixbit name of a
unique generated symbol which will not be generated
again for a very long time (unless the system
crashes, in which case the counter is reset, of
course).

.GETLOC ac, get absolute location
The accumulator <ac> should contain
an absolute address in the left half and an address
within the executing job in the right half.
The contents of the absolute location specified is
deposited in the location specified within the job.
This is useful for examining locations within the
system. However, if many locations are to be
examined, or if a location is to be examined many
times, it is far more efficient to map the absolute
page(s) containing the location(s) of interest into
the job's core map as read-only memory; the job
can then examine the locations at top speed without
having to go through the system uuo handler.
Such page mappings can be established via the .CBLK
uuo or the CORBLK symbolic system call.
.GETSYS ac, get system data
;skip if successful
Accumulator <ac> should contain an AOBJN pointer to a data area in
the user's core. (A zero left half means the data area extends to
the end of core.) Accumulator <ac+1> should contain the sixbit
name of a system data area. The specified system data area is
transferred into the user's core in such a way that the data is
consistent (i.e. interrupts are inhibited in appropriate ways,
etc.). If the .GETSYS is successful, <ac> is updated to point to
the unused part of the user's data area.
If the named data area does not exits, <ac+1> is cleared. If the
area in the user's core is too small, the left half of <ac> is
replaced with the negative of the correct size. In both of these
cases .GETSYS fails to skip.
Valid data areas are:
MEMORY Memory tables.
UTAPE Micro-tape variables.
NCPSM Network control program socket map.
NCPPQ Network control program pending RFC queue.
NCPHT Network control program host table.
USERS User variables for all jobs.
USER User variables for job whose user index is in <ac+2>.
Formerly a uname-jname pair was accepted in <ac+2>
and <ac+3>, but this is no longer true (ANCIENT HISTORY).
GETS Valid sixbit .GETSYS area names.
DEVS Valid sixbit built-in device names. (Doesn't include those on
DEVICE directory.)
CALLS Official system symbol table. Squoze symbols and values for
UUO's, .USET variables, and bits DEFSYM'ed in SYSTEM;BITS.
IMPX Input multiplexor data area.
CLINK Core link device variables.
DSYMS Exec DDT symbol table. Squoze symbols and values.
USYMS Squoze symbols and values for .USET variables only.
(Does -not- contain .RMEMT or .SMEMT, but rather .MEMT.
Used by DDT when you type ".MEMT/".)
CHDEVS Device names, from .RCHST table.
NCALLS Valid sixbit names for symbolic system calls.
USRVAR Valid sixbit user variable names for USRVAR system call.
TTYVAR Valid sixbit tty variable names for TTYVAR system call.
ITSNMS Valid sixbit names of all local ITS machines.
Names which used to be valid but are no longer (ANCIENT HISTORY):
TRANS Translation tables.
OMPX Output multiplexor data area.
PEEK used to use this uuo to get system information.
Nowadays it merely maps systems pages into its core
image, thereby gaining efficiency at some small cost
in accuracy.

.GSNAME ac, ANCIENT HISTORY get system name
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function has been superseded by .SUSET of .RSNAM.
Its opcode has been recycled as .REALT.
Put the executing job's .SNAM user variable
into accumulator <ac>; this is the default directory
name ("system name") for the job.
.GUN ac, gun down a job tree
;skip if successful
Accumulator <ac> should contain the user index of the
top level job of a job tree. That job tree is expunged
from the system. All the jobs are closed and killed.
This is to be used as a last resort to flush hung
and worthless jobs. The system program LOCK
contains a command which performs this operation.
The system job will print a message on the system console
describing what job was gunned and who gunned it.
.HANG hang until condition satisfied
The .HANG uuo is to make it easy for programs to wait for various
conditions. It should be used the way a JRST .-1 would be used in
a stand-alone program. Explicitly, it should be preceded by an
instruction that will skip or jump if the awaited condition is
true. Because the system must understand that instruction, only
certain instructions are allowed to be used (any others cause
illegal operation interrupts (%PIILO, bit 1.6 of the .PIRQC user
variable)). They are: SKIP, JUMP, AOS, SOS, AOJ, SOJ, CAI, and CAM
class instructions, -all- test instructions, CONSO and CONSZ (which
work only if the job is in .IOTLSR mode, and the processor is not a
KS10), SKIP and JFCL, which are used to hang forever (really, until
some interrupt routine jumps away instead of returning), SKIPA and
CAIA, which are used to cause rescheduling but don't actually hang,
and JFFO. XCT is also allowed, but the ultimate end of the chain
of XCT's must be one of the instructions listed above.
In the case of hanging forever, the job is specified to be
desirable to swap out, since it may hang for a long time.
.HANG conditional instructions which reference only ACs are treated
as hang-forever, except that they don't set the desire-to-swap-out
flag, since the contents of the AC can't change without the job
being interrupted out of the .HANG.
When a job executes a .HANG, the system effectively executes the
preceding instruction at each schedule to decide whether the job
may be run (cf. the .FLS user variable). If the job is
interrupted, the interrupt routine will find that the saved PC
points to the instruction before the .HANG instruction. It may
dismiss normally, in which case the .HANG will be executed again
unless the condition has become true (of course, the interrupt
routine may do something to make the condition true).
.HANG takes care to be certain that any side effects of the
instruction will be performed when the condition finally becomes
true. .HANG does this by always exiting by jumping to .-1. Thus
an AOSE instruction followed by a .HANG really will increment the
referenced location after it becomes -1, JFFO AC, followed by .HANG
really will store a bit number into AC+1, and TLZN followed by
.HANG really will clear out the bit after it comes on.
While a job is waiting in a .HANG, the system does not re-examine
the AC used by the conditional instruction each time it executes
that instruction; it uses what was in the AC when the .HANG was
entered. However, there is no way for this AC to change without
the job being interrupted out of the .HANG so it can change it, or
PCLSRed out when it's superior changes it. Also, the effective
address calculation is not repeated, and if the actual instruction
supplied is an XCT, the XCT'd instruction is not re-fetched.
Therefore, it does not work to expect the condition to become true
because the contents of a memory location indirected through or
XCTed will change. Because an interrupt always causes the .HANG to
be redone, it does work to expect the interrupt routine to change
the AC or the indirect pointer in order to make the instruction
skip.
In the special case of waiting for a specific interval of time to
pass, the .SLEEP uuo (q.v.) may be useful. In the special case of
waiting for a network socket to change state, the NETBLK symbolic
system call may be useful.
.HANG ac, .HANG with timeout
[In ITS version 1622 and later]
.HANG with a non-zero AC field acts as the disjuction of .HANG and
.SLEEP, allowing a program to wait either for a condition to become
true or for some time to pass. The contents of accumulator <ac>
specify when the .HANG should stop waiting for the condition to
become true by returning to the instruction following the .HANG.
If non-negative, it is a length of time to wait in thirtieths of a
second. If negative, it means to wait until the system TIME
variable exceeds its absolute value.
As with .SLEEP, if the job is interrupted while .HANGing, the
accumulator will be found to contain the appropriate negative
number to allow the .HANG to be resumed properly when the interrupt
is dismissed.
If .HANG times out before the awaited condition becomes true, the
accumulator will contain 0. This is the only case in which .HANG
will exit to the following instruction.
If the awaited condition becomes true, so that the previous
instruction skips or jumps away, the accumulator will contain the
negative of the time at which the .HANG would have timed out.
.HANGUP dialnum, ANCIENT HISTORY hang up a dialed line
;skip if successful
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .REVIVE.
This uuo was used to hang up on a line which had
been dialed by the .DIAL uuo.
.IFSET ac, if location contains what I think, set it
;skip if successful
The accumulator <ac> should contain an absolute 18.-bit
address in the right half and a pointer to a two-word block
in the left half. The first word of the two-word block
contains a test word, and the second a new value.
If the absolute core location specified contains exactly
the quantity specified by the test word, then the contents
of that location are replaced by the new value specified,
and the .IFSET skips. If the contents of the location
are not the same as the test word, the .IFSET fails.
This is similar to the .SETLOC uuo, but provides a
measure of safety if the contents of the location
may be volatile. Like the .SETLOC uuo, if the .IFSET
succeeds the system job prints out a message on the
system console detailing the old and new contents
of the location and who modified it.
.IOPDL reset I/O pdl
The I/O channel pdl of the executing job is reset.
Entries on the I/O pdl contain the channel number
from which they were pushed; .IOPDL is equivalent
to just enough .IOPOP's (possibly none) to clear
the I/O pdl, popping each entry into the channel
it was pushed from.
See the .IOPUSH and .IOPOP uuos, and the .IOC, .IOS,
.IOP user variables.

.IOPOP chnum, pop I/O channel
This uuo is the inverse of the .IOPUSH uuo.
The top entry of the I/O pdl is popped into
channel <chnum>, which may be a different channel
from the one the entry was pushed from.
A .CLOSE is first performed on the channel popped into.
If the channel originally pushed was a closed channel,
then after popping channel <chnum> will be closed.
If the I/O pdl has no entries on it, IOC error
number 5 is signaled on channel <chnum>, giving the
job a class 2 interrupt (%PIIOC, bit 1.9 of the .PIRQC
user variable).
If the channel number is variable, the IOPOP symbolic
call may be used.
See the .IOPUSH and .IOPDL uuos, and the .IOC, .IOS,
and .IOP user variables.
See also the .UCLOSE uuo for a discussion of what
occurs when a job open on a pushed channel is killed.

.IOPUSH chnum, push I/O channel
The channel <chnum> is pushed onto the I/O pdl
for the executing job. A channel may be pushed
whether or not it is actually open; if it is open,
transactions on the channel are suspended when
it is pushed, and any transfer on that channel is
inaccessible until the pushed entry is popped
again. The error status and access pointer are
correctly saved as well. The channel number <chnum>
is also saved in the pdl entry for use by the .IOPDL uuo.
After the channel has been pushed it is returned to
a non-open state (this is not the same as being closed
since closing implies terminating the I/O transaction).
The I/O pdl for each job has room for eight entries;
if all are in use .IOPUSH will signal IOC error
number 6 on channel <chnum>, giving the job a
class 2 interrupt (%PIIOC, bit 1.9 of the .PIRQC user variable).
If the channel number is variable, the IOPUSH
symbolic call may be used.
See the .IOPOP and .IOPDL uuos, and the .IOC, .IOS,
and .IOP user variables.
See also the .UCLOSE uuo for a discussion of what
occurs when a job open on a pushed channel is killed.
.IOT chan,[foo] input/output transfer
Input or output is performed, according to the device
open on the specified channel and the mode in which it
was opened. If an error occurs, any of several IOC
errors may occur, giving the job a class 2 interrupt
(%PIIOC, bit 1.9 of the .PIRQC user variable.)
In "unit mode", foo is the datum to be transferred
in or out. (In the case of input, the word pointed
to by the effective address of the .IOT is modified.)
In "block mode", foo is an AOBJN pointer to the data
to be transferred in or out. The left half is the
negative of the number of words, the right half is
the address of the first word. The pointer is updated
as the transfer proceeds. When the .IOT returns the
pointer will have been fully counted out, that is
the left half will be zero, except in the case of input
that stops because the end of the file was reached.
In the case of block mode on an intrinsically character
device, such as TTY, bits 4.9-4.7 of the pointer are
fiddled to indicate which byte in the word is being
processed.
The VID, NVD, and IMX devices handle .IOT in a non-standard
way because they do both input and output at the same time.
The symbolic system calls IOT and SIOT are versions of
.IOT which have additional features.
.IOTLSR ac, iot loser mode
This uuo is used to request permission from
the system to run in user I/O mode (bit 4.3 of the PC).
In this mode a program is in user mode (and thus is
subject to user mode page mapping), but may perform
I/O instructions without trapping to the system.
This facility must naturally be used with discretion.
It should be noted that ITS will interpretively
simulate most I/O instructions anyway, if it thinks
that the operation will not harm the time-sharing
system. For example, one may use DATAI to read the
console switches even when not in .IOTLSR mode.
This simulation is slower than direct execution
of I/O instructions, but much safer.
If bit 4.9 (the sign bit) of accumulator <ac> is zero,
.IOTLSR mode is relinquished, even if it was not formerly
possessed by the job.
If bit 4.9 is one, then the executing job is granted .IOTLSR
mode, and the system job prints a message on the system
console to document the fact.
.IPDP chnum, interrupt PDP-6
Channel <chnum> should have the PDP-6 open as an
inferior procedure; if it does not, .IPDP does nothing.
Otherwise the PDP-6 receives an interrupt.
The PDP-6 can also interrupt the PDP-10; when this occurs
a job with the PDP-6 open as an inferior will receive
an interrupt if enabled for it. See the .IFPIR
user variable for PDP-6 channel interrupts.
The interface between the PDP-6 and the PDP-10
is device 20 octal.
The interrupts are given via a CONO:
1.5 Interrupt other processor.
1.4 Clear interrupt flag.
1.3-1.1 Priority interrupt assignment.
The bits read by CONI are as follows:
1.4 Interrupt flag.
1.3-1.1 Priority interrupt assignment.
.ITYI ac, OBSOLETE input tty interrupt
;skip if successful
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by the .ITYIC uuo.
This uuo is exactly like .ITYIC except that it applies
only to the job's console, if any. This uuo is to be
flushed eventually.

.ITYIC ac, input tty interrupt on channel
;skip if successful
The specified accumulator <ac> should contain the
number of a channel which is open for tty input.
If an interrupt character is pending in that tty's
input buffer, that character replaces the channel number
in <ac> and the .ITYIC skips. It will fail if the
channel is bad, if it does not have a tty open, if the
tty is the job's console but the job does not possess it,
or if there is no interrupt character pending.
If the job does not possess its console and the job's
%TBINT bit is set in the .TTY user variable, the job
receives a class 2 word 1 interrupt (bit 4.2 in the
.PIRQC user variable).
This uuo is typically used in an interrupt routine
invoked by bit 1.1 (%PITYI) in the .PIRQC user variable or by
a word 2 I/O interrupt on a tty input channel.
If the .ITYIC does not skip the program should ignore
the interrupt entirely; this can happen due to certain
timing screws related to passing the console around
among several jobs.
See the TTYGET and TTYSET symbolic system calls, which
manipulate bits relevant to interrupt characters.
See the WHYINT system call, which (in the case of
TTY channels) is another way to do the same function
as .ITYIC.
See the .PIRQC and .TTY user variables.
See ITS TTY for a complete explanation of .ITYIC.

.LISTEN ac, listen to tty
If the job possesses its console, .LISTEN waits
for any output to be completed, and then returns the
number of input characters pending in the input
buffer. If the job does not possess a console, zero is
returned.
See also the LISTEN symbolic system call.
.LOGIN ac, ANCIENT HISTORY log in
;skip if successful
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function has been superseded by the LOGIN symbolic system call.
Its opcode has been recycled as .DEMON.
Accumulator <ac> contains the sixbit name to log in as.
Attempting to log in with a uname equal to 0 or -1 fails,
as does attempting to log in when already logged in.

.LOGOUT log out
The executing job and all direct inferiors are killed,
providing that it is the top-level job of its job tree.
All resources used by such jobs are freed. If the job
tree was console-controlled, the system job will print
a "console free" message on the freed console.
If the executing job is not top-level, .LOGOUT with zero
in the AC field merely returns without skipping.
(An inferior job may not commit suicide without the consent
of its superior.) .LOGOUT with a nonzero AC field will
cause a fatal %PIBRK interrupt which will inform the superior
that the job wants to be killed. If the superior is DDT,
it will kill the job. Here is how a program should exit:
SKIPE DEBUG ;optional debugging aid:
.VALUE ; job hangs if being debugged
.LOGOUT 1, ;log out or be killed.
.LOSE lossage-code report lossage
The job's Program Counter is set to the address of the
.LOSE minus one, the job's .VAL user variable is set
to the new PC,,the magic bits, and the
job is given a %PILOS interrupt. If the job does not
enable this interrupt, and it's superior is DDT, a
helpful error message will be printed.
The magic bits are documented in DDT ORDER.
The most useful ones are 0 for a random error,
1000 to ask DDT to type the error message corresponding
to the most recent system call error return, and
1400 if DDT should attempt to print the names of
the file that the call was opening/referring to.
The lossage codes are defined by DDT's interpretation of them.
The defined values are:
%LSSYS==1000 The last error code returned by a failing
system call describes the problem.
%LSFIL==1400 The last error code returned by a failing
system call, together with the name of the file
it was operating on, describe the problem.
That system call should be right before the .LOSE.
DDT will decode it to determine the filenames
(if it is an OPEN) or the channel number and then
the filenames via an RFNAME.
%LSSYS+errcode Means that the system call error code
<errcode> describes the problem.
%LSFIL+errcode Means that the error code <errcode>
together with the filenames being used
describe the problem.
1+.LZ <interrupt bit>
Means that the error should be handled as if it
were a fatal interrupt on the specified interrupt
bit. For example, the lossage code 1+.LZ %PIMPV
will to cause DDT to print out an MPV error message.
These lossage codes are more useful with the
LOSE and DISMIS symbolic system calls.
0 Signifies some other nondescript error condition.
The usual way of using this uuo is to put it
after a system call which is expected always to
skip. If it fails to skip, DDT will print an error
message based on what the system call is and what
it was failing to do (if you said 1000 or 1400).
Proceeding the job will retry the call.
See also the LOSE symbolic system call.
This call never gets an error, and never returns.
.LTPEN block hack light pen
This uuo hacks the light pen on the 340 display.
The address <block> should be the start of a six-word
block. The first word controls the mode:
4.9 0 => ignore other bits, 1 => examine them.
3.1 1 => hang until light pen seen at least once.
1.1 Used to set the multiple sighting mode (1 = on).
The six words of data returned are as follows:
wd 0 The word read by DATAI from the 340 display at
the last light pen interrupt.
wd 1 Number of times the light pen interrupted
since the last .LTPEN uuo.
wd 2 Sum of all Y coordinates since the last .LTPEN uuo.
wd 3 Sum of all X coordinates since the last .LTPEN uuo.
wd 4 The current linked display list pointer.
wd 5 The current BLKO display pointer.
If the job does not currently possess the 340 display,
words 0 and 1 are set to zero.
If the system has no 340, .LTPEN is ignored.

.MASTER ac, request/release master mode
;skip if successful
Accumulator <ac> should have bit 4.9=1 to request
master mode, or =0 to release it. Releasing master
mode always succeeds, even if the job did not have it.
Requesting master mode succeeds if the job already has
master mode, or if it has control of its tty (as determined
by bit 4.9 (%TBNOT) of the .TTY user variable).
Only one job at a time may have master mode; thus requesting
master mode may imply taking it from some other job.
A job in master mode gets double priority for run time;
that is, it tends to get twice as much run time as any other
job competing for run time. Furthermore, it has priority
in grabbing the 340 display from another user. (The precise
algorithm for grabbing the 340 is actually a function of
who has master mode and of the %TT340 and %TT3HP bits of
the TTYTYP variables of the jobs involved.)
Master mode should be used only when absolutely necessary.
Needless use of it is considered to be antisocial, and may
be grounds for harassment.
.MSPACE ac, ANCIENT HISTORY hack magtape unit 0
;skip if successful
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function has been superseded by .MTAPE.
Its opcode has been recycled as .DWORD.
Accumulator <ac> should have a function code.
The job should have device MT0 open.
Valid function codes are:
0 Rewind tape.
1 Space to end-of-tape.
2 Write end-of-file.
17 Hang until interrupt routine dies.
.MTAPE ac, hack magtape
;skip if successful
Accumulator <ac> should have a channel number in the
left half and an address in the right half.
(An illegal channel number causes an illegal operation
interrupt (%PIILO, bit 1.6 of the .PIRQC user variable).)
The channel should have device MTn open on it.
The address should point to a word with a signed count <n>
in the left half and a function code in the right half.
Valid function codes are:
0 Hang until tape motion done.
1 Rewind tape.
2 Rewind and dismount.
3 Write end-of-record (i.e. force current output buffer).
4 Write three inches of blank tape.
5 Write end-of-file.
6 Space over <n> records (negative => backwards).
Illegal for output channel.
7 Space over <n> files (negative => backwards).
Illegal for output channel.
10 Space to end-of-tape.
11 Stop all commands on this channel.
12 Set block size for writing to <n> words.
13 Return block size in <ac>. For reading, this is the size
of the record most recently swallowed by an IOT.
This operation may trigger one of the following IOC errors,
causing an interrupt (%PIIOC, bit 1.9 of the .PIRQC user variable):
1 ILLEGAL HARDWARE OPERATION ATTEMPTED
3 NON-RECOVERABLE DATA ERROR
9 DEVICE FULL
.NDIS ac, display <n> times
;skip if successful
This uuo is intended for use in taking pictures of
the 340 display screen. It sets a display control
variable from the contents of accumulator <ac>.
This variable has no effect if negative, but if
zero it inhibits display completely, and if positive
is decremented by 1 each time the current display
block or list of blocks is displayed. This call
fails to skip if the job does not possess the 340 display.
On systems which don't have a 340, .NDIS is ignored.
.NETAC chnum, OBSOLETE accept network connection
;skip if successful
This UUO is obsolete.
It is documented here for historical purposes only.
It now ALWAYS fails to skip.
Channel <chnum> should be be a network channel in
the "RFC received while listening" (%NSRFC) state (see
the ITS NCP file.)
This is used to accept a connection on a socket opened
with mode bit 1.5=1 (see the OPEN symbolic system call).
An RFC is sent back and the channel put into the
"connection open" state.
To reject a connection, the channel should be closed with
either the .CLOSE uuo or the CLOSE symbolic system call.

.NETINT chnum, OBSOLETE network interrupt
This UUO is obsolete.
It is documented here for historical purposes only.
It is now always a no-op.
Sends an interrupt out on the network socket associated
with channel number <chnum>, which should be open on
the NET device. If the local socket number is even
(receiving), an INR message is sent; otherwise, INS
is sent.

.NETS chnum, network send
Channel number <chnum> should be open for network
output. The .NETS uuo forces the current output buffer
to be sent. If the channel is open in the wrong direction,
IOC error 1 (ILLEGAL HARDWARE OPERATION ATTEMPTED) will occur,
possibly giving the user an IOC interrupt (%PIIOC, bit 1.9 of
the .PIRQC user variable).
.OPEN chnum,block open a file
;skip if successful
This uuo is semi-obsolete. The OPEN symbolic system
call is somewhat more flexible and consistent.
However, it is still reasonable to use .OPEN for
devices which do not use directory names.
A file is opened on the channel specified by <chnum>.
That channel number is then used to specify the file
on all further I/O transactions on that file.
The address <block> should be the first of several
locations:
wd 0 <mode bits>,,<device name>
wd 1 File name 1, if applicable.
wd 2 File name 2, if applicable.
wd 3 For the NET device, the foreign host number.
The directory name, if applicable, is taken from the
.SNAME user variable. Note that the device name may
be only three characters. The mode bits are as for
the OPEN symbolic system call.
If bits 4.9-4.7 of word 0 contain 2, then a link is
created. Words 1-5 are then as follows:
wd 1 From file name 1.
wd 2 From file name 2.
wd 3 To file name 1.
wd 4 To file name 2.
wd 5 To sname.
.OPEN should never be used in this way in new programs;
use the MLINK symbolic system call instead.
If the .OPEN fails to skip, an error code as for
.CALL OPEN will be returned on channel <chnum>.
.OPER random operation
The term .OPER is used to refer to a class of uuo's
which all have the same op-code and are decoded by
the value of their effective address. Those .OPER's
which take arguments generally specify either an
accumulator or an I/O channel number in the accumulator
field of the .OPER.
If the effective address is not a valid .OPER number,
then the job executing the .OPER receives an illegal
operation interrupt (%PIILO, bit 1.6 of the .PIRQC user
variable).
A list of currently valid .OPER's is given below in
numerical order.
.OPER 0 illegal
.OPER 1 .ITYI
.OPER 2 .LISTEN
.OPER 3 .SLEEP
.OPER 4 .SETMSK
.OPER 5 .SETM2
.OPER 6 .DEMON
.OPER 7 .CLOSE
.OPER 10 .UCLOSE
.OPER 11 .ATTY
.OPER 12 .DTTY
.OPER 13 .IOPUSH
.OPER 14 .IOPOP
.OPER 15 .DCLOSE
.OPER 16 .DSTOP
.OPER 17 .RDTIME
.OPER 20 .RDSW
.OPER 21 .GUN
.OPER 22 .UDISMT
.OPER 23 .GETSYS
.OPER 24 .IPDP
.OPER 25 .GETLOC
.OPER 26 .SETLOC
.OPER 27 .DISOWN
.OPER 30 .DWORD
.OPER 31 .DSTEP
.OPER 32 .GENSYM
.OPER 33 .LOGOUT
.OPER 34 .REALT
.OPER 35 .WSNAME
.OPER 36 .UPISET
.OPER 37 .RESET
.OPER 40 .ARMOVE
.OPER 41 .DCONT
.OPER 42 .CBLK
.OPER 43 .ASSIGN
.OPER 44 .DESIGN
.OPER 45 .RTIME
.OPER 46 .RDATE
.OPER 47 .HANG
.OPER 50 .EOFC
.OPER 51 .IOTLSR
.OPER 52 .RSYSI
.OPER 53 .SUPSET
.OPER 54 .PDTIME
.OPER 55 .ARMRS
.OPER 56 .UBLAT
.OPER 57 .IOPDL
.OPER 60 .ITYIC
.OPER 61 .MASTER
.OPER 62 .VSTST
.OPER 63 .NETAC
.OPER 64 .NETS
.OPER 65 .REVIVE
.OPER 66 .DIETIME
.OPER 67 .SHUTDN
.OPER 70 .ARMOFF
.OPER 71 .NDIS
.OPER 72 .FEED
.OPER 73 .EVAL
.OPER 74 .REDEF
.OPER 75 .IFSET
.OPER 76 .UTNAM
.OPER 77 .UINIT
.OPER 100 .RYEAR
.OPER 101 .RLPDTM
.OPER 102 .RDATIM
.OPER 103 .RCHST
.OPER 104 .RBTC
.OPER 105 .DMPCH
.OPER 106 .SWAP
.OPER 107 .MTAPE
.OPER 110 .GENNUM
.OPER 111 .NETINT
.ORGI ac, ANCIENT HISTORY read organ keboard
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .PDTIME.
Read input from an electric organ keyboard and store in <ac>
through <ac+2>.
.ORGO ac, ANCIENT HISTORY write tone generator
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .ARMRS.
Write output to a tone generator from <ac> through <ac+2>.
.PDTIME ac, PD time
Returns in accumulator <ac> the time since the beginning of the
year, measured in sixtieths of a second. If the time is not known,
-1 is returned. PD = Paul DeCoriolis, who hacked the original
clock on which this was based. Said clock ceased to work many
years ago.

.POTSET [block] read pots
This call gives the user a flexible means of controlling
program parameters via the input multiplexer.

.RBTC ac, robot console switches
The contents of accumulator <ac> are sent to the
robot console (device 514) with a DATAO. After a short
delay the result of a DATAI are returned in <ac>.
What the heck is device 514???
.RCHST ac, OBSOLETE read channel status
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by the RCHST
and RFNAME symbolic system calls.
Accumulator <ac> should contain a channel number
in the left half and an address in the right half
pointing to a block of several words.
The executing job receives an illegal operation
interrupt (%PIILO, bit 1.6 of the .PIRQC user variable)
if the channel number is illegal.
The block of words is filled with information
about the status of the channel. The general
pattern of this information is as follows, though
not all devices adhere to it strictly:
wd 0 Device name in the right half.
wd 1 First file name, if applicable.
wd 2 Second file name, if applicable.
wd 3 Sname (directory name), if applicable.
wd 4 Access pointer. Measured in words.
A byte pointer if in character mode, for some devices.
-1 if not randomly accessible.
wds 5-n Other data. May be garbage, or not stored,
depending on the device as specified by word 0.
See the RCHST symbolic system call for details
of what information is returned for specific devices.
Wd 0 from .RCHST has in its RH the LH of symbolic
RCHST's 1st value. Wds 1-4 from .RCHST are the same as
the 2nd-5th values returned by symbolic RCHST.
Wds 5 and up from .RCHST are the same as values 7 and up
of symbolic RCHST, except that they are not stored for
devices which do not return significant information in
them. Note that value 6 of the RCHST symbolic system
call is not available from .RCHST.
.RD500 ac, ANCIENT HISTORY read device 500
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .IPDP.
Device 500 formerly purported to be some kind of clock.

.RD710 ac, ANCIENT HISTORY read device 710
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .HANG.
Device 710 used to be a kind of clock on the PDP-6.
This uuo read a 24.-bit quantity from this clock,
measured in 4-microsecond ticks.

.RD760 ANCIENT HISTORY
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .DWORD.
Device 760 of the PDP-6 used to be used for temporary
direct sense hookups. (For example, the low six
bits controlled lights on the hand of the AMF arm.)
This uuo returned the result of a DATAI on this device.
.RDATE ac, read date
The current date is returned in accumulator <ac> as a
word of sixbit characters "YYMMDD", where YY is the
year (modulo 100.), MM is the month, and DD is the day,
all as two-digit decimal numbers.
If the system does not know what the current date is,
-1 is returned.

.RDATIM ac, read date and time
This is exactly like the sequence
.RTIME ac,
.RDATE ac+1,
except that the timing error involved with crossing
midnight between execution of the two uuo's is avoided.
Thus accumulator <ac> receives the time of day as a word
of sixbit "HHMMSS", where HH is the hour (in 24.-hour
notation), MM is the minute, and SS is the second,
all as two-digit decimal numbers.
Accumulator <ac+1> receives the date as a word of sixbit
characters "YYMMDD" where YY is the year (modulo
100.), MM is the month, and DD is the day,
all as two-digit decimal numbers.
If one of the quantities is not known by the system,
-1 is returned for that quantity.

.RDSW ac, OBSOLETE read switches
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by DATAI.
The contents of the data switches on the PDP-10 console
are returned in accumulator <ac>.
The same effect can be achieved by using DATAI 0,<ac>
(or any arbitrary location instead of <ac>), which, if
the job is not in .IOTLSR mode, ITS will interpret
specially and simulate.
Neither .RDSW nor DATAI works correctly on KL10s.
Hopefully this will not inconvenience anyone.
On KS10s .RDSW no longer exists.

.RDTIME ac, read system time
The time since the system started running, measured in
thirtieths of a second, is returned in accumulator <ac>.
Thus the difference between two successive values gives
the amount of real time which passed between the two
executions of .RDTIME. This time does not include time
during which the system was temporarily down, for instance
stopped at a bug halt from which it was later continued
by a system hacker.
.REALT ac, real time hackery
;maybe skip on success (see below)
This uuo controls a fairly complex facility allowing
a job to get good service in real time. The contents
of the specified accumulator are decoded as follows:
%RLFLS 4.9 Turn off old clock rate, zero the tick count,
and release the real time facility.
%RLSET 4.8 Turn on new clock rate.
%RLUSR 4.7 Attempt to seize the real time facility.
%RLNPS 4.6 Do not settle for pseudo-real time status.
%RLPSD 4.5 Insist on pseudo-real time status.
%RLBLK 4.4 Block me except during high priority period.
%RLGET 4.3 Read into words 2-3 (see below) before
interpreting the other bits.
4.2-3.1 Reserved. Should be zero.
2.9-1.1 Pointer to four word block:
wd0 Frame time in sixtieths of a second.
Must fit in the right half.
wd1 Priority time in sixtieths of a second.
Must be less than 15 octal, and less
than or equal to half the contents
of word 0.
wd2 If bit 4.3 on, set the right half to
the frame time, and the left half to
the tick count since last examined.
wd3 If bit 4.3 on, set the right half to
the high priority time, and the left
half to 0 if currently at low priority
or -1 if currently at high priority.
The real time facility is interpreted as follows:
real time is broken up into cycles, each the number
of sixtieths of a second in length specified by the frame
time. At the beginning of each frame, the %PIRLT
bit (4.8) in the job's .PIRQC user variable is turned
on. This causes an interrupt if the corresponding
bit is on in the .MASK user variable.
Within each frame, the first <n> sixtieths are
high priority time for the job with the real time
facility, where <n> is the specified high priority time.
If a job has the facility, presently has high priority,
and otherwise wants to run, then it is scheduled above
all other jobs. This guarantees that a job will
get a certain amount of run time at specified intervals;
this is useful for responding to real-time conditions.
The system will not schedule the job during its low-priority
phase if it has requested that it be blocked (bit 4.4),
unless it gets an interrupt and is not using the new-style
interrupt system.
The .REALT uuo will skip only if the facility
was requested and successfully seized. In all other
cases it does not skip, even if the requested operation
succeeded. If an invalid quantity is supplied for
a frame time, or for the high priority time, an
illegal operation interrupt occurs
(%PIILO, bit 1.6 of the .PIRQC user variable).
.REDEF ac, redefine symbol to exec DDT
;skip if successful
The specified accumulator should contain the address of
a two word block:
wd0 SQUOZE bits,symbol
wd1 value
If the <bits> are all ones, then the symbol is deleted.
Otherwise it is defined with the specified value,
replacing any old value. This occurs in the symbol
table used by exec DDT, which is used to debug the
system, and which is used by the .EVAL uuo.
A .REDEF fails to skip only if it tries to add
a new symbol and fails for lack of room in the system.

.RESET chnum, reset I/O channel
I/O channel <chnum> is reset. This is exactly
like the symbolic system call RESET. What happens
is device-dependent; see the description of that call.

.REVIVE revive system
This uuo reverses the effect of the .SHUTDN uuo.
It is used by the REVIVE command of LOCK.
Jobs which have enabled it will receive an
interrupt (bit 1.7 of the .PIRQC user variable).
See the .DIETIME and .SHUTDN uuo's, and the SSTATU
symbolic system call.
.RLPDTM ac, read localized PD time and .RYEAR
This returns the time and date in <ac> and <ac+1>, in a binary
form. <ac+1> contains the result of .RYEAR; see the description
of that uuo for details. <ac> contains the "localized" number
of seconds since the beginning of the year. If this is divided
by the number of seconds in a day (86400.), the remainder will
be the number of seconds since midnight local time, and the
quotient will be the number of days since the beginning of the
year, with the (mis)feature that all years are considered to
include February 29. This is done so that date-printing
routines do not have to check for leap-year, but it does mean
that during the last 10 months of non-leap years the day number
is 1 greater than the correct Julian day. Bit 4.9 of <ac+1> is
set in this case.
Note also that when daylight savings time is in effect <ac> will
be advanced by one hour. Again this is done to simplify date
and time printing routines. Bit 4.7 of <ac+1> is set in this
case.
Note that .RLPDTM should be used instead of .PDTIME followed by
.RYEAR, since it guarantees consistency of the two values
returned.

.RRTIM ac, ANCIENT HISTORY read run time
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function has been superseded by the .RUNT user variable.
Its opcode has been recycled as .CBLK.
The job's run time is returned in accumulator <ac>.
See the .RUNT user variable.

.RSYSI ac, read system incarnation
Returns in <ac> the .FNAM2 of the system when it
was assembled. Thus, it is a version number in sixbit.
This is the same as the seventh value of the
SSTATU symbolic system call.

.RTIME ac, read time
The time of day is returned in accumulator <ac> as a word
of sixbit characters "HHMMSS", where HH is the hour
(in 24.-hour notation), MM is the minute, and SS is
the second, all as two-digit decimal numbers.
If the system does not know the time, -1 is returned.
See also .RDATIM.

.RYEAR ac, read year
Returns in accumulator <ac> a word as follows:
4.9 This year has 365. days, and it is after February 28.
4.8 This year is a leap year (366. days).
4.7 Daylight savings time is in effect.
4.6 The time of year is known.
4.4 The timezone is known, and is found in bits
4.3 and 3.5-3.1 (if not set, assume EST/EDT=5).
4.3 Sign bit of the timezone offset (bits 3.5-3.1).
4.2-3.9 If bit 4.6 set, the current day of the week.
Sunday=0, Monday=1, etc.
3.8-3.6 The day of the week of January 1 of this year.
3.5-3.1 Absolute value of timezone offset.
2.9-1.1 The year, not modulo 100., but as a full quantity,
e.g. 1969. or 1975.
If the system does not know the time, zero is returned.
.SETLOC ac, deposit in system
Expects the rh of <ac> to contain the address of a
location in physical core, and the lh of <ac> to point
to a word of data in the executing job's memory.
The job's argument word is copied into the addressed
location in physical core, and a message is printed
on the system console.

.SETM2 OBSOLETE set two interrupt masks
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by block-mode
.SUSET of .MASK and .MSK2.
The job's .MASK and .MSK2 user variables are set to
the respective contents of accumulators <ac> and <ac+1>.

.SETMSK ac, OBSOLETE set interrupt mask
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by .SUSET of .MASK.
The job's .MASK user variable is set to the contents of
accumulator <ac>.
.SHUTDN ac, shut down system
;skip on success
This uuo causes the system to prepare to go down.
(It is used by the KILL command in LOCK.)
Accumulator <ac> should contain a time interval,
in thirtieths of a second. The system will go down
exactly that much time after the present moment.
When the system prepares to go down, all jobs enabled
for it receive a system going down interrupt (%PIDWN, bit 1.7
of the .PIRQC user variable). (DDT prints a message when it
receives such an interrupt; part of this message is the
contents of the file SYS:DOWN MAIL.) This interrupt will
occur repeatedly every time 3/4 of the time from the previous
interrupt to the time of shutdown has elapsed, except that
interrupts will not occur less than ten seconds before shutdown.
(Thus, if the system were scheduled to go down in ten minutes,
interrupts would happen at the following times before shutdown:
10:00, 2:30, 0:37. If in five minutes: 5:00, 1:15, 0:17.)
When the magic moment arrives, all users are forceably logged
out, all jobs killed (except job trees whose top-level jobs
have the %OPLIV bit set in their respective .OPTION user variables
-- a feature used primarily by system daemons. Such trees are
expected to log out on their own after finishing their work),
all micro-tapes are flapped, the file SYS:DOWN MAIL is deleted,
"ITS NOT IN OPERATION" messages are printed on all consoles,
all Terminet motors are stopped, all files, directories, and TUTs
are written out, and everything generally put into a good state;
the system then calls DDT. It may be brought back up again
with XREVIV$X, which reloads demons and allows ^Z'ing once more.
The effects of a .SHUTDN may be reversed by a .REVIVE uuo.
See the .DIETIME and .REVIVE uuo's, and the SSTATU symbolic
system call.
.SLEEP ac, sleep
The .SLEEP uuo temporarily puts the executing job into
a dormant but interruptable state. The job consumes no
run time until the specified time interval has elapsed,
unless an interrupt occurs.
The contents of accumulator <ac> specify how long the
job is to sleep. If non-negative, it is the length
of time to sleep in thirtieths of a second. If negative,
it means to sleep until the system TIME variable (which
is read by the .RDTIME uuo (q.v.)) exceeds the absolute
value of the specified quantity; thus one can sleep
until a specific time.
If the job is interrupted in the middle of a .SLEEP,
the accumulator will be seen to contain the appropriate
negative number, either the one originally there or one
calculated from the original positive argument. Thus
re-executing the .SLEEP after dismissing the interrupt
will cause the .SLEEP to be resumed correctly.
Often it is desirable to "sleep" until some condition
other than the passing of time occurs. For this see
the .HANG uuo. For the special case of sleeping until
a network socket changes state, see the NETBLK symbolic
system call.

.STATUS chnum,loc I/O channel status
The status of I/O channel <chnum> is placed in
location <loc>. This is exactly like the STATUS
symbolic system call.

.SUPSET ac, SUPCOR set
The system job is partially controlled by a variable
called SUPCOR; .SUPSET XOR's the contents of accumulator
<ac> with that variable, returning the result of
the XOR in <ac>. Not all bits specified by <ac> take
effect; some are AND'ed out first. A message is printed on
the system console as for the .IFSET and .SETLOC uuo's.
The only really useful bits to set are as follows:
1.6 Update TV who lines.
1.2 Kill current file being spooled from TPL to LPT
(this is what the TPL command in LOCK uses).

.SUSET [suset spec] self USET
This uuo is used to examine and set user variables
associated with the executing job. See ITS USETS
for more information on .SUSET and .USET.
.SWAP ac, hack swapping
This uuo is illegal unless the system is being
debugged (the SYSDBG variable in the system is
non-zero; see the SSTATU symbolic system call).
The bits in the specified accumulator indicate
a test of the page swapping software in the
system:
4.9-4.7 Operation to perform.
0 Swap out the number of pages
specified in 2.9-1.1.
1,3,5,7 Go into a loop, waiting for
a few seconds and then referencing
location 2000 octal.
2 Hack the PCLSR test feature on
this job. Bits 2.9-1.1 specify
the test mode:
-1 Enter in hold mode.
0 Leave PCLSR test mode.
1 Enter in advance mode.
2 Enter in advance but don't ^Z.
4 Swap out the virtual page specified
by bits 2.9-1.1 for the user specified
by bits 3.9-3.1.
6 Swap out all pages for the user
specified by bits 3.9-3.1.
3.9-3.1 User index, for operations 4 and 6. A user
index of zero means the job executing the .SWAP.
(After all, it's hard to swap out the system!)
2.9-1.1 Number of pages for operation 0.
Test mode for operation 2.
Virtual page number for operation 4.

.TRANAD OBSOLETE translation-list add

.TRANDL OBSOLETE translation-list delete

.TRANS ANCIENT HISTORY translate file name

.UBLAT ac, micro-tape blat (?)
;skip if successful
The specified accumulator should contain a micro-tape
drive number. If the uuo succeeds, the drive is marked
as being in .UBLAT mode. In this mode, there are
only two permissible operations on the drive: to dismount
(flap) it, and to open it as one giant file. This uuo
is intended for use in reading micro-tapes written in
non-standard (e.g. DEC) format. Any .OPEN
on a micro-tape in .UBLAT mode will ignore the
file names, and all the blocks of the tape except block 0
will be read or written consecutively. No deletes, renames,
etc. are permitted. A .UBLAT will fail if the drive does
not exist, if the micro-tape directory has been read in
already by the system, or if the drive is not assigned
to the user whose job is trying to do a .UBLAT.
.UCLOSE chnum, USR close
This uuo is used to explicitly kill an inferior
open on channel <chnum>. Merely performing a
.CLOSE on the channel is not enough - that
dissociates the inferior from the I/O channel,
but does not destroy the inferior procedure.
When the procedure is destroyed, all of its
inferiors, direct or indirect, are destroyed also.
As each job is destroyed, its I/O channels
are automatically .CLOSE'd, and any facilities
such as .MASTER mode are released. The translation
lists are cleared for all destroyed jobs.
If any procedure whatever has a destroyed job
open on an I/O channel, that channel is automatically
closed; in particular, the channel <chnum> is
closed. All jobs with channels which have the job open
as a foreign user (as opposed to an inferior or a
job device) also receive a word 2 I/O interrupt on each
such channel (see the .IFPIR user variable).
If a procedure has pushed a channel with a job to be
destroyed onto its I/O pdl (see the .IOPUSH, .IOPOP, and
.IOPDL uuos, and the .IOC, .IOS, and .IOP user variables),
then that I/O pdl entry is replaced on the pdl with a special
entry for a pseudo-device called the "interrupt on .IOPOP
device", which delivers a word 2 interrupt when popped from
the I/O pdl and then closes its channel (thus it should be
impossible to perform any operation on this "device" except
.IOPOP). In this way a job can detect the fact that a
foreign job disappeared while it was pushed.
A procedure which executes a .UCLOSE receives
an I/O channel error interrupt (%PIIOC, bit 1.9 of the
.PIRQC user variable) if the specified channel
does not have an immediately inferior procedure
open on it.
.UDISMT ac, micro-tape dismount
;skip if successful
The specified accumulator should contain a micro-tape
drive number. If the uuo succeeds, the directory
is written back onto the micro-tape and excised from
the system's memory. The micro-tape is then physically
dismounted (this is known as "flapping" the tape, since
when it runs off the reel it goes flap, flap).
Micro-tapes should not be manually dismounted, for this
will cause the directories to get out of phase, messing
up that micro-tape and the next one to use that drive.
The .UDISMT will fail if any files are still
open on the micro-tape, or if someone else has the
drive assigned to him.
DDT makes this available via its command :FLAP.
See also the FLAP symbolic system call.

.UINIT ac, initialize micro-tape
;skip if successful
The specified accumulator should contain a micro-tape
drive number. If the uuo succeeds, the directory
of the micro-tape is initialized (containing no files).
The uuo fails if the drive does not exist, or if the
drive is not assigned to the user whose job is trying
to do the .UINIT.
See the .ASSIGN and .DESIGN uuos.

.UPISET ac, OBSOLETE user priority interrupt set
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by .SUSET of .PICLR
and/or the .DISMISS uuo and the DISMIS symbolic system
call.
The value of the ac is converted to -1 or 0 on the basis
of bit 4.9; this value is then exchanged with the .PICLR
user variable for the executing job. Thus the accumulator
gets the old value of .PICLR even as it specifies a
new value. This allows enabling and disabling of
interrupts.
.USET chnum,[uset spec] set (or get) user variable
This uuo is used to inspect or alter the user variables
of a job open on channel <chnum>, which may be a channel
open on the USR or BOJ device.
See ITS USETS for further information on .USET and .SUSET.

.UTNAM ac, set micro-tape name
;skip if successful
The specified accumulator should contain a micro-tape
drive number in the right half and a three character
sixbit name in the left half. If the uuo succeeds,
the name of the micro tape will be changed to the one
specified. The uuo fails if there is no such drive,
if it is in .UBLAT mode, or if it is assigned
to another user.
The name of a micro-tape can be examined with the .RCHST uuo.

.UTRAN loc user interrupt bit translate
;skip if successful
The effective address of .UTRAN must be a three-word
block:
loc: bit,, ;interrupt bit of inferior
0 ;uname returned here
0 ;jname returned here
The first word should be all zero, except for one
of bits 3.1-3.8; these correspond to inferior
interrupt bits in the .IFPIR user variable.
If the job executing job has an inferior for that
interrupt bit, .UTRAN stores the uname and jname
of the inferior in the second and third words and skips;
otherwise it fails to skip.
DDT uses this to find jobs which have been :FORGET'ed, or
accidentally created by open's of the USR: device via :PRINT
etc. Normally, superiors should keep track of the interrupt bit
and job names when the job is created, and this UUO should be
used only for exceptional cases.
See the .IFPIR, .UNAME, .JNAME, and .UIND user variables.
.VALUE [item] return value to superior
The job which executes a .VALUE receives a class 1
interrupt, which stops the job, turns on %PIVAL (bit 1.8)
in its .PIRQC variable, and interrupts its superior.
The word <item> is placed in the .VAL variable of
the executing job (this fact is a historical artifact,
relatively useless now).
The standard superior procedure (DDT) imposes the
following additional semantics on .VALUE:
If the effective address is zero, then DDT prints
out a message to that effect, and the job is left stopped.
This used to be the standard way to crap out from a grossly
irrecoverable situation (e.g. can't get core, or can't
open the TTY when started). Now .LOSE (q.v.) is preferred.
A typical sequence is:
GO: .OPEN TTYC,[SIXBIT \ !TTY\]
.VALUE ;unhappy if never got TTY
.CALL [ SETZ ? 'TTYGET ? 1000,,TTYC ? 2000,,A ? 402000,,B ]
.VALUE ;shouldn't lose if .OPEN succeeded
If the effective address is not zero, it is assumed to
point to an ASCIZ string in the memory of the job
which executed the .VALUE. DDT proceeds to
interpret these characters as if they were typed to
DDT on the console. Thus a job might execute
.VALUE [ASCIZ \:PROCED :DISOWN V\]
or something similar, to get itself running again and
disowned from its superior. See the DDT documentation
for specific details on .VALUE.
.VSCAN <block> read vidissector data
The effective address should point at an eleven word
block of parameters defining the points to be scanned,
the locations to be read into, the mode they are to be
read in, and whether the call should hang until the
scan is through.

.VSTST ac, test vidissector
This system call allows later control of and sensing by
a job that has overlapped computation with a .VSCAN. If
the contents of <ac> is positive, the .VSTST hangs till
the scan is over. If the contents of <ac> is negative,
any scan in progress is aborted. If the contents is zero,
the user's location then being stored into by the scan,
if any, replaces it.

.WMAR ac, ANCIENT HISTORY write mar address
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function has been superseded by .SUSET of .MARA.
Its opcode has been recycled as .DCONT.
The user's mar address variable is set from the
contents of the specified accumulator.

.WR760 ac, ANCIENT HISTORY write device 760
This uuo NO LONGER EXISTS.
It is documented here for historical purposes only.
Its function is obsolete.
Its opcode has been recycled as .DSTEP.
Device 760 of the PDP-6 used to be used for temporary
direct sense hookups. (For example, the low six
bits controlled lights on the hand of the AMF arm.)
This uuo used the contents of accumulator <ac> for a
DATAO to device 760.

.WSNAME ac, OBSOLETE write system name
This uuo is ARCHAIC and OBSOLETE.
It is documented here for historical purposes only.
Its use in new programs is to be avoided.
Its function has been superseded by .SUSET of .SNAME.
The system name for the job (used as a file directory name)
is set to the sixbit contents of accumulator <ac>.
Reference in New Issue View Git Blame Copy Permalink