Glossary of Multics acronyms and terms. Entries by Tom Van Vleck ([THVV]) unless noted.
Index|
A|
B|
C|
D|
E|
F|
G|
H|
I|
J|
K|
L|
M|
N|
O|
P|
Q|
R|
S|
T|
U|
V|
W|
X|
Y|
Z|
- daemon
- A beneficent spirit. A process, not associated with a human operator, that runs all the time and waits for requests to do something for a user. This term is respectable English; the application to computer processes is usually credited to M. J. Bailey, working on the design of CTSS in the early 60s.
- [JHS] "I'm working from memory here, but I think this is the story. Although the word 'process' wasn't in the vocabulary yet, we had just figured out that what one would now call 'system processes' were a solution to several problems, and we were looking for a good label for them. A British gentleman named Michael (Mick) Bailey, working on the CTSS programming staff at MIT, suggested the word 'daemon' and quoted the OED in support of both the meaning and spelling. Bailey's etymology was so impeccable that questions as to whether the spelling should be simplified to 'demon' went on for only about 30 seconds. On both CTSS and Multics, the documentation and the process names use the spelling 'daemon.' I suspect that the date on the memo that first used the term would be in 1962 or 1963."(note to Kirk McKusick, 24 Aug 1988)
- damaged switch
- Segment attribute set during crash recovery, if the volume salvager finds that a page is claimed by two segments. It takes the page away from both, and marks both damaged. User programs fault when accessing a damaged segment; the user can then check the segment and reset the switch, or initiate a reload or recovery of the segment.
- Data Management
- Large-scale project undertaken in the 1980s to add support to Multics for true transaction-oriented record databases. Melanie Weaver, André Bensoussan, Lindsey Spratt, Matt Pierret, John Bongiovanni, Lee Newcomb, Jeff Ives, and Michael Pandolf worked on it for several years. The plan was to restructure MRDS to use this new storage mechanism, FAMIS; many more Multicians worked on this aspect. Data Management was the subject of at least 40 MTBs. It was designed to run in ring 2.
- [PWB] I am pretty sure that Data Management went into production. I was the project leader for a major conversion of MRDS (team included Roger Lackey, Noah Davids, Thanh Nguyen, Ron Harvey, Al Dupuis and others). All of the code that referenced vfile_ was excised and replaced with a bunch of entry variables that could either be set to relation_manager_ (the interface to DM) or vfile_relation_manager_. The MRDS/vfile_ side of things was completed on time and actually resulted in a more performant MRDS than we had before the surgery. DM was not ready for the first release of the converted MRDS, but it did make it out, I'm fairly certain, and was used at Ford. Bert Moberg of Ford contributed heavily to that phase of the product as well.
- Datatran
- Cambridge Project feature?
- DBR
- Descriptor Base Register, sometimes Descriptor Segment Base Register, DSBR. The appending unit register that contains the absolute address of the descriptor segment for the CPU and thus the address space of a process.
- DCC
- Data Communications Corporation, Memphis, TN. Multics customer, in the business of billing advertisers for TV commercial advertising charges. Installed in 1976.
- [RR] Story: about the DCC sale.
- DCW
- Device Control Word. An instruction for an I/O controller (GIOC, IOM).
- DDDS/ORAE
- Canadian DND Multics site. Directorate of Documentation and Drafting Services, Operations Research and Analysis Establishment, Canada Systems Group, Processing Services. 1983-1993.
- debug
- [BSG] Multics source-level and process-level debugger, initially written by Steve Webber. Later partially replaced by probe, which only has source-level capabilities, but is more end-user oriented.
- deciduous
- [BSG] A neologism of Bernie Greenberg's for branches that lose their pages (Fr. "feuille", "leaf") when the "season" (running of Multics) is over. This was new to NSS, and was the method of management of that subset of paged supervisor segments that had to appear in the file hierarchy, but also had to be loaded, paged, and operative during initialization before the file system was "up" in that bootload. The technique was to withdraw the pages of these segments from the same per-bootload pool as used by the rest of the supervisor, which required special care to make sure that no attempt was ever made to return them to the file system. Unlike many colorful neologisms of the time, this one made it all the way into the official documentation.
- Decimal Unit
- [BSG] Or "DU". That portion of the 6180 CPU (no analogue on the 645) responsible for the EIS (Extended Instruction Set). Comprising an ungodly fraction of the 6180 CPU, this implementation went further than one should go in hardwired logic. The DU is a strong testimony to the power of microcode, which was not applied here. While the EIS instructions were terrific, the bugs and crashes resulting from the machinations required to save and recover the state of this complex engine at page fault time vitiated their advantage. The DU was not originally designed for Multics, and the problems arose from the retrofit.
- For "decimal" (as opposed to "long" string or bit operations), whose operand length was limited to 64 digits, the Multics version of the DU would try to touch all possible six pages ("EIS prepage") before actually beginning the computation that would modify storage (See volume maps). For "long ops", which could involve more data than would fit in pageable memory and thus had to be progressively interruptible, eight words of internal "pointer and length" info had to be stored and restored at fault (or interrupt!) time. The DU was kind enough to supply a bit in the SCU data telling you if you really had to do this, and we took advantage of it. The DU was a co-conspirator in the management of the bit and word fields of the pointer registers.
- [Ron Harvey] The EIS opcodes are listed in this file .
- definitions
- Section of an object segment that defines the offsets of the symbolic entrypoints to the segment. Used by the linker
- DELTA
- DEfinition des Langages et de Leurs Traducteurs par Attributs. SLR(k) attribute grammar translator system done at INRIA by Lorho, Blaizot, Bouchenez, and Boullier in the 1970s.
- Descartes
- Executable specification language based on data structuring methods proposed by Hoare. Initially developed by Joseph E. Urban using PL/I on a Multics system.
- descriptor
- (1) contents of an SDW.
- (2) Single word that described an operand of an EIS instruction.
- descriptor segment
- [BSG] Array of SDWs (segment descriptors) that totally define a process's address space as currently available to the hardware without segfaults. This array itself is in all respects a segment, and (by convention) is segment 0 of the process it defines: its first element is thus an image of the DBR that describes it. Supervisor segments precede all other segments; then follow stacks, then all segments initiated and terminated by supervisor calls. All of the SDWs for wired segments are in its first page; therefore, that page has to be wired before a process can run, and that page and the first page of the PDS of a process are wired when a process is made eligible. The hardware can take page faults on the rest of the descriptor segment during the address formation process, and this case is differentiated by bits in the SCU data.
- [THVV] All processes' descriptor segments have identical SDWs for the segments of the supervisor (with the exception of the PDS, the PRDS, and abs_segs). This means that the programs to handle interrupts and faults are available at the same virtual address no matter what the DBR is set to.
- development machine
- [BSG] Any of several Multics machines at or near the CISL development site in Cambridge, MA, used for testing and debugging new systems software. Until about 1974, when CISL got its own pile of iron dedicated to this purpose, the "development machine" was unique in that it only existed part of the time, being constructed by dynamic reconfiguration of processors and memory (and on the 645, the firehose drum) off the MIT service system and flipping switches to form a separate system, usually during off-hours. See development run.
- development run
- Testing of new software on the development machine at CISL. Until CISL got its own iron, development runs were done on the MIT 645, often late at night, and programmers would leave boot tapes and detailed instructions for the MIT operators and be greeted by a foot-high crash dump and some notes ("Tape hung after collection 1, manual return to BOS") scribbled on the back of a tab card.
- In 1967, a "development run" involved generating a new bootload tape, signing up for time on the 645, mounting the tape on the 645 and booting it. The system would start to initialize, read collection 1, sit for a while flashing the CPU lights, load collection 2, think some more, and crash. The programmer would dump core on the printer, find the problem, and repeat the process. See the CISL site history for more info.
- DFAST
- FAST subsystem with Dartmouth conventions.
- dial
- The answering service connects a TTY channel to an existing process if the dial command is issued instead of login. This facility is used to support transaction processing. The dial facility was designed by Tom Van Vleck, inspired by a similar facility in CP/67. Info segment for dial command
- dialup_
- Main event-driven dispatcher of the answering service.
- Source code: dialup_.pl1.
- DIM
- Device Interface Module. The Multics I/O Switch ios_ supported device-independent operations on data streams, something like the Unix Streams facility. The device-dependent operations were performed by one or more DIMs in the I/O graph. There were two kinds of DIMs: terminal DIMs actually controlled a physical device. Many of these were in the hardcore. Non-terminal DIMs performed a transformation on their input and invoked the I/O switch again, like Fenichel's famous Pig Latin transformation. ios_ was an early instance of polymorphism, supported by calling convention rather than by language. The term DIM is also used for the hardcore programs that control physical devices, even if they are not invoked via the I/O switch, for example, the disk DIM.
- DIPPER
- Code name for new hardware I/O system done in 1986, in which an Information Multiplexer Unit (IMU) replaced the IOM. IMU had up to 16 micro-programmed Integrated Peripheral Controllers (IPCs). In particular the IPC-FIPS supported FIPS standard devices such as IBM 3380 and 3390 disk and 8200 tape. IMUs also had a Maintenance Channel Adapter, connected to a micro that did firmware loading, bootload, T&D, and fault processing.
- Sites that had IMUs: DND-H, Ford, ACTC.
- Dir. Prevision
- Multics site: Ministère des Finances, Direction de la Prévision, Paris, France. Budget Forecast Center. 1980-1984.
- [Daniel Bois] It is a small part of the Ministry of Finance. Doing all forecast studies. DP is at the same level, within the Ministry of Finance, as INSEE. Both Directors report to the same Minister of Finance.
- directory
- File system container for segments, links, or other directories. Directories are organized into a tree-structured naming hierarchy. All directories are stored on the RLV. The topmost directory is called the root.
- directory control
- Supervisor subsystem that provides the directory abstraction. Directories are stored in segments with ring brackets 0,0,0 and transported to and from core by paging. Internally, a directory consists of a fixed size header, followed by a PL/I area in which directory control allocates branches, links, names, ACLs, and ACL entries. These data structures point to each other with 18-bit addresses local to the directory segment. Most structures are organized into doubly-linked lists. The salvager uses knowledge of directory control's algorithms when repairing damaged directories.
- Directories are limited to a single segment, limited by hardware to a maximum size of 1 MB, adequate to store about 900 branches (depending on the size of names and ACLs). Thus, the maximum size of a multisegment file database is about 900 MB. This seemed a generous limit in 1975, when the MIT Multics machine had a total capacity of 150 MB of disk used to store user files for about 1000 registered users, as well as the system files and the source and object tree for Multics development.
- Discourse
- [Wren McMains] Programming and simulation language based on a geographical data base that was originally designed as a tool to allow City Planners to express their thought process algorithmically. Previously much city design seemed to be black magic; Discourse provided a way to quantify and discuss the design process. Later used to simulate everything from city growth (not unlike SimCity) to military battle plans. William L. Porter postulated the original concepts which were developed into the Discourse language by Wren McMains. The initial development was done on CTSS. Discourse was one of the first application packages ported to Multics. It later became part of the Consistent System.
- Disk
- Rotating magnetic storage device with movable heads. Not "disc," those are Frisbees. (more, list models and capacities?)
- disk quota
- Multics enforces disk usage quotas at page fault time. A user cannot grow a segment even temporarily past his or her quota for the "quota directory" in which the segment resides. Some directories don't have quotas, and charge their usage to the closest parent directory that has a quota. Master directories are quota directories that have a logical volume attribute different from their parent; they draw their quota from a special segment that specifies the total quota a user can allocate on a logical volume.
- DL
- Assembler flag for "Direct lower", 18-bit immediate operand. See DU.
- DN30
- Datanet-30 communications front-end processor, used by GECOS time sharing and DTSS on the GE-635.
- DN355
- Datanet-355 communications front-end processor, added to 6180 Multics to replace the terminal channels of the GIOC. Attached to the IOM. Initial code to run the DN355 was written by Doug Wells. Later, ran MCS as well as standard Honeywell FNP code. Later marketed as the Datanet 6632.
- Article: Multics Communications and Networking.
- DN6661
- Datanet 6661 communications front-end processor. A reimplementation of the Datanet 355 using the Level 6 minicomputer technology. Two accumulators, three index registers, 32K 18-bit words of virtual address space. Supported up to 256K of physical memory: extended memory was accessed by using pager.
- DN6670
- Datanet-6670 communications front-end processor.
- DND
- Canadian Department of National Defence. Had two Multics systems, one in Ottawa, Ontario, and one in Halifax, Nova Scotia; see the DND-H site history.
- DOCKMASTER
- Unclassified Multics system operated by the US National Security Agency in Linthicum, MD. 1984-1998. Used as a communications tool among security researchers, lots of forum activity. See the DOCKMASTER site history.
- The hardware is now at The Computer Museum History Center, in Mountain View, CA.
- dollar limits
- See resource limits.
- dope
- Address-independent descriptive material for argument data. First word was the offset and succeeding words were the breakdown, consisting of an ID field and then various sizes and array maxima. Used in the EPL compiler.
- dprint
- Delayed print. Pronounced dee-print. The command that queues a file for printing on the line printer by the "I/O Daemon", IO.SysDaemon. Listings produced by the printer daemon are also called "dprints." See link. Later deprecated and replaced by enter_output_request.
- DPS
- Distributed Processing System. Honeywell added this prefix to the names of a lot of machines in the late 70s, including the DPS-68 and the DPS-8/M.
- DPS6
- Another name for a Level 6.
- DPS6plus
- Version of the Level 6 that ran a secure system.
- DPS8
- Honeywell early 80s name for its mainframe line. Multics machines were called DPS8/70M, DPS8/62M, DPS8/52M.
- DPS88
- Later name for the Honeywell ADP and Orion machines. Never ran Multics.
- DPS90
- Even later Honeywell processor line. The NEC S/1000 central system introduced by Honeywell, after GE Information Systems ordered it from NEC. It ran GCOS but never ran Multics. It was followed by DPS/9000 (aka NEC S/2000) and DPS/9000-900 (aka NEC S/3900). NEC systems were not designed to run Multics.
- Drum
- See Librafile.
- DS 10
- Early disk unit. I think these were the ones operators had to "milk" condensation from the vacuum lines with a special bottle.
- DSA
- Honeywell Distributed Systems Architecture. GCOS Communications architecture in the late 80s, ancestor of ISO networking model.
- Article: Multics Communications and Networking.
- DSEG
- Jargon for descriptor segment.
- DSS191
- Disk unit, used on Multics in the early 70s. Same as MSU0400.
- DSU170
- Disk unit, used on Multics in the early 70s.
- DSU270
- Disk unit, used on Multics in the early 70s. Capacity 10MB per unit. MIT had 15 of them in 1974.
- DTSS
- Dartmouth Time Sharing System. Created by John Kemeny & Thomas Kurtz at Dartmouth in 1963. DTSS ran on a GE-635 and supported many more users than CTSS or Multics per CPU, but with a programming model limited to 16K words per user. Multics had several DTSS simulator environments. See also BASIC, DFAST, and FAST.
- [PAK] The DTSS simulator using the Dartmouth BASIC compiler was running and installed at MIT by early 1971. I was working on the simulator (with Peter Bishop and John Strayhorn) from 9/70 to 6/71.
- There was an earlier DTSS simulator pror to 1971 that used the BASIC from the GE-605 time sharing system.
- DU
- (1) Assembler flag for "Direct upper", 18-bit immediate operand. See DL.
- (2) The Decimal Unit.
- DUMP
- BOS command that prints an octal dump of selected segments after Multics has crashed, or during system debugging. Descended from John Gintell's dump program that loaded from cards. See FDUMP.
- DVCP
- Deer Valley Computer Park. Generic name for the complex of Honeywell buildings in Phoenix at Thunderbird Road and the Black Canyon Freeway, housing LISD headquarters and manufacturing. System M and the Phoenix Multics development group were housed several miles away, at CRF.
- dynamic linking
- [BSG] Actually two related concepts: the runtime location and initiation of subroutines called by running programs, sharing one instance of the callee between all callers in a process, and the supervisor-mediated connection of instructions making external data and procedure references to their targets that occurs the first time in a process they are executed. The first of these is common in today's paradigm of "Dynamic Link Libraries"; the second is not. A Multics program can run successfully even if some of the routines or data it references do not exist, as long as the instructions that make these references are not actually executed.
- Dynamic linking in Multics occurs both through such instructions, whose operands are referenced indirectly through special indirect words called links that cause a linkage fault on first execution, and by explicit call into a linker API, hcs_$make_ptr, which is used by the shell to locate a command whose name was typed.
- When the linker is invoked in either of these ways to initiate an executable segment, in addition to making the latter known, its linkage section (containing its impure STATIC data and links) is copied into the combined linkage segment of the faulting ring. See search rules.
- dynamic reconfiguration
- Multics facility that allows the system to add and drop hardware without shutting down. Roger Schell's thesis was the basis for this feature. Reconfiguration was integrated with Online T&D so that one could run diagnostics on a CPU before adding it back into the system. I/O reconfiguration was added late in the life of the system.