Multics 831 entries
30 Mar 2016

Glossary - C

Glossary of Multics acronyms and terms. Entries by Tom Van Vleck ([THVV]) unless noted.

Index| A| B| C| P| C| D| E| F| G| H| I| J| K| L| M| N| O| P| Q| R| S| T| U| V| W| X|
The original 645 shipped with a separate box that was a microsecond realtime clock with the ability to interrupt any CPU. On the 6180, the clock moved into the SCU and didn't take up a port. See SCAS. The calendar clock value read by the rccl instruction is 52 bits (right-justified in the 72-bit AQ register). Story: "Multics Calendar Clock Calculations".

clock algorithm
[BSG] Page-replacement algorithm (PRA) due to Corbató, whose variants and tweaks remained the Multics PRA for the life of the product. The idea is to approximate "least-recently-used" (LRU) (i.e., when a new core frame is needed, the "least recently used" page should be evicted.) True LRU is computationally expensive to implement, if not impossible, as it potentially requires reshuffling a queue or stack at every page access. The "Clock algorithm" places all the core frames in a doubly-linked circular list (like a clock face), with a rotating "hand", in whose wake the "most recently used" pages are, and in advance of whom are the "least-recently-used." When a free frame is required and some page has to be evicted, the hand simply sweeps until a page not PHU (recently used) is found. Pages that are PHU have PHU turned off (i.e., are given a "grace lap"), PHU1 turned on (for pre-paging control), and be passed over, thus, as "most recently used". A page not PHU has a write started if one is needed, or is simply evicted to satisfy the demand. Artificial, "premature" eviction of pages (e.g., for deactivation of segments) moves free core frames to the "LRU" region of the list immediately.

Multics site: Centre National d'Etudes sur les Télécommunications [CNET] (Issy, France), near Paris. 1982-1988.

Corporate Network Operations. Honeywell site in Minneapolis, MN. 1979-1987.

[Cec Erickson] The decision to get Multics in Minneapolis was made in January 1978 and the CNO system was up and running in February 1979 with over 400 registered users and 70 projects. (CNO customers were using the Phoenix system first and then we transferred their work to CNO system. As an interesting aside, when we shut down the CNO system in December 1986 there were over 3000 registered users that we had to migrate to other systems and, oh by the way, to the best of my knowledge NONE of them migrated to a GCOS system....)

COBOL compiler done at Honeywell Billerica in early 1970s. Shared internal data structures and code generator with the Multics PL/I compiler.

A Multics boot tape contains three logical groups of segments called collections. Each collection is read in and then run, to bootstrap a more complex environment for loading and executing the next collection.

[BSG] Collection One consists of all segments necessary for the implementation of paging including all hardware I/O (GIOC and IOM control) and the PL/I environment. All of its segments are wired except the config deck and some other segments that cannot not be there (and the deciduous ones paged and wired).

Collection Two consists of all additional segments that are necessary to implement the file system, e.g., segment control, directory control, and the like, and all remaining parts of the ring 0 supervisor. All of these segments are paged, and none are wired. Some are deciduous.

Collection Three consists of segments, none of which are part of the supervisor and all of which are loaded into the file system, being precisely the amount of non-supervisor software necessary to get a reload going from backup tapes.

The term "Collection 0" is sometimes used to refer to a set of segments created in core by bootstrap1 dynamically, the DSEG, config deck, Segment Loading Table, and the like, which are not in any sense loaded from tape.

combined linkage segment
Per-ring segment that contains the LOT, the ring's STATIC data, outbound links (snapped and unsnapped), and entrypoint names.

[BSG] Program designed to be invoked by typing its name at a terminal. Multics commands are ordinary user programs, and what is more, ordinary PL/I procedures. Commands and "subroutines" are indistinguishable at the PL/I and dynamic linking levels. Although this reduces the number of search mechanisms, it rarely turned out to be useful, as calling a command as a subroutine or vice-versa, although fully possible and often done in kludges, presents all kinds of UI problems. The proper handling and diagnosis of missing, malformed, or non-string arguments makes the passing of command arguments as actual parameters a poor idea, and the current C "argc/argv" scheme, an outcome of Multics's experience, is one correct solution.

Correct handling of the star convention and equal convention are not so easy, though, and the seemingly-obvious solution of relegating that task to the shell (or "command processor") is fraught with well-known dangers whose horror stories adorn the landscape of Unix critiques.

[THVV] See Multics Commands and Active Functions for a list of commands.See also additional names.

command language
The Multics command language derives from the CTSS language, with ideas added from BESYS and TRAC. The listener reads lines from the input stream and passes them to the shell for execution.

[PG] The Multics command language permits quoting, iteration and command functions ("active functions") with string return values. The string return values can themselves contain quoting, iteration, or more command functions. By default the command processor evaluates the return value, but you can suppress that and use the unevaluated return value. There is no particular limit to the length of a command line, command argument or return value; the [files] active function returns the names of all files matching a star name, for example, which can easily return hundreds of file names. Everything in Multics is case sensitive; Multics permits use of the full upper and lower case ASCII character set.

Multics command names and programming languages use lowercase by convention, but users are free to use uppercase letters in path names, identifiers, user names, etc.

Simple command line example:

rename a.pl1 b.pl1 /* renames branch a.pl1 to b.pl1 */
/* works on files, dirs, or links */

Quoted command line example:

rename "x y z" "x_y_z" /* change spaces to underscores */
/* yes, filenames could have spaces */

Iteration example:

rename (a b c).pl1 (d e f).pl1

expands to:

rename a.pl1 d.pl1
rename b.pl1 e.pl1
rename c.pl1 f.pl1

Active Function example:

copy [home_dir]>Green.abbrev

All of these features can be combined, nested, etc., to produce very complex (and very useful) command lines. To run two commands on the same file, you can say:

(edm pl1) t.pl1

which runs the edm line editor, then the pl1 compiler, on the file t.pl1.

Since Multics was meant to be extensible, you can write your own commands, your own active functions, your own command processor, or even your own "listener" (the top-level program in the process that reads command lines and dispatches them to the command processor). We had environments that simulated Dartmouth BASIC (by Bob Frankston) and GCOS timesharing, to name two.

[THVV] An early implementation of the Multics command language is described in MSPM section BX.1.00. Several features described in that section were changed later, such as the support for two different quoting mechanisms.

command level
[AG91] Process state in which lines input from the user's terminal are interpreted by the system as a command (i.e. the line is sent to the command processor). A user is at command level when he logs in, when a command completes or encounters an error, or is stopped by issuing the QUIT signal. Command level is normally indicated by a ready message.

command processor
See shell. Users may call their command processor via cu_$cp.

Multics command: compares two ASCII files and prints differences.

Multics text formatting command, successor to runoff. Written by Ed Wallman of Honeywell Phoenix. Unbundled product.

computer utility
[BSG] A computer, its software, and staff set up to provide 24-hour service for all of a community's information needs, the ancestor of the "Information Highway". Multics was envisioned as quite this, a "Multiplexed Information and Computing Service", to be present, reliable, powerful, and all that is needed as an information resource for a large number of people, all the time. This was radical at the time, when computers were viewed mainly as tools and toys for "scientists". See "Introduction and Overview of the Multics System".

[THVV] See Martin Greenberger's 1964 article "The Computers of Tomorrow".

config deck
[BSG] An array of card images read by BOS and passed to Multics initialization, describing the number and sizes of memories, number of processors, peripherals and their channels, etc., as well as the sizes of critical tables (such as the SST) to be created by initialization. Ultimately, BOS acquired the capability of keeping these images on tape or in its own disk partition, not needing actual cards.

The cards, or card images, were parsed by an interesting BOS routine ("SCAN") first written by Stan Dunten, that determined into what to parse a datum (e.g., 4-character string, octal number, decimal number, letter) by looking at the datum itself, storing one-word "parsed" data in one array and "data types" in a parallel array, very much like a LISP reader.

[BSG] Communication signal sent from one active device to another. When received by a processor, as polled for the control unit after each instruction pair like an interrupt, a special fault (connect fault), very much like an interrupt, is taken. As with interrupts, processors send "connects" to each other through the SCU, the only possible channel. While an interrupt is set in an SCU register and fielded by the first "taker" of all appropriately masked CPUs, a connect fault is routed by the SCU to one, specified processor (or I/O controller), and cannot be masked against (although the recipient's inhibit bit can postpone it for a short while). Sending a connect to the GIOC or IOM was the way of instructing it to begin executing I/O commands. See SCAS.

Multics uses connects for forcing all CPUs to take note of SDW and PTW invalidation (and clear their associative memories and execute a partial cache clear when appropriate), holding CPUs in the air during critical phases of dynamic reconfiguration, and the like. If my memory serves me well, functions such as system crashing, scheduler preemption, and processor startup switched back and forth between software-generated interrupts and connects throughout the '70s.

connect time
The accounting system metered and charged for "time logged in" because data communication equipment and FNP ports were a scarce resource.

connection failure
At segment activation time, segment control checks that the unique ID of the segment from the branch matches the unique ID in the VTOCE and returns an error otherwise.

Consistent System
Social science data manipulation subsystem built by MIT's Cambridge Project, architected by John Klensin.

[Wren McMains] The concept was to provide Social Scientists with a tool box of building blocks that they could put together in ways not envisioned when the individual tools were originally developed. (Much like the Multics/Unix concept of building block commands, but using higher level building blocks designed to meet the statistical and analytical needs of the Social Sciences.)

The Consistent System also tried to solve another problem that still exists 30 years later: An application or command script worked just fine when you used it a couple of years ago, but when you go back and try to do the same thing again with new data it no longer works because someone has "improved" the underlying programs. You're not a computer scientist, you just want do your research. You want the computer to work the way you knew and "loved". You want to get your new answer and get away from the damned computer as soon as possible. The theory was that the Consistent System could seamlessly revert to older versions of software upon command. (I'm not convinced it ever worked seamlessly, but the idea is still worth exploring. Things haven't really gotten better, and instead of 100's of frustrated users there are now 100's of millions around the world.)

Terminal device hard wired to the IOM and used for system control. The 645 and 6180 used a Selectric mechanism. Besides the keyboard and printer, the console had a panel with the BOOT button and a "speedometer" measured in MIPS. BOS commands such as MULT, DUMP and BOOT were input on the console by the system operator.

The operator console was a lot more than just a terminal mechanism. Its pedestal contained a large amount of circuitry that translated the Selectric codes into GEBCD and enabled the console to work in a primitive environment. The support for the BOOT button was also partly in the console. Proposals for later generations of Honeywell hardware wanted to support complex diagnostics built into a programmable console, and one issue was how to initialize and boot the console, so it could boot the system.

Bulletin board program that ran on Multics in the late 70s. Supported threaded discussions on multiple topics, like "a one-node version of netnews." Written by USGS employee Pat Doherty. Picked up by Site SA Mike Auerbach and installed on System M to coordinate MRDS changes in response to the EOP procurement. Ancestor of forum.

control argument
An argument that controls how a command works. For example, ls -long. There are several types of control arguments:
  • simple switches, e.g. -long
  • control arguments that take modifier values, e.g. cis -pn fred
  • control arguments that can appear multiple times
Like command options in Unix, Multics control arguments are individually coded into the program that is affected by them. By convention, Multics control arguments usually have long and abbreviated forms. Also by convention, Multics control arguments need not appear before operand arguments such as filenames: commands customarily took two passes over the argument list, one to determine all control argument settings, and another to process operands.

print test.pl1 -no_header


pr -nhe test.pl1

were equivalent. A few commands were exceptions to this convention.

Control Unit
[BSG] That portion of the 6180 processor (the parallel component was the Control Frame on the 645) responsible for "instruction preparation", i.e., sequencing, fetching, and decoding instructions, including address computation (as expressed by indirection (see eppbp)), index registers, and the non-segment portions of pointer registers.

Fetching instructions in double-word pairs, the CU maintains an internal image of its "current instruction," whose address and tag fields it modifies from those of the successive indirect words it fetches. By buffering two instructions, it supports operations that repeat (RPD, 'repeat double') or execute a pair of instructions out of line (XED ('execute double'), or a fault vector). The CU generates memory requests and dispatches them to the port logic (which queues them), giving the latter a "return address" of whichever processor unit (see Appending Unit, Decimal Unit, Operations Unit) is supposed to deal with that instruction, to which it also passes off the opcode. (Stores are more or less the same, "but different.":)

Although modified for Multics, the basic CU is not Multics-specific, and does not know about segmentation, let alone paging. It operates more or less identically in Multics as in a GCOS processor: the illusions of segmentation and paging are created by the Appending Unit.

copy switch
Argument to hcs_$initiate that caused a copy of the segment to be initiated instead of the original.

Computer memory technology invented by Jay Forrester of MIT in the 1950s and used on the WHIRLWIND computer, and on 1960s computers including the GE-645. Later models of the 6180 used solid-state MOS or other RAM technology, but main memory was often called "core" in casual conversation.

Several different manufacturers produced 645 core memory: Lockheed, Fabritek, who else.. I remember running memory diagnostics that printed out FABRITEK WCCP PATTERN TEST, WCCP meant "worst case core pattern." There was a problem in 1966 with non-plated sense wires on core planes from some manufacturer, forget who, that for a while caused the 645 to burn out a core assembly a week. They worked fine in Arizona's dry air, but Boston's salty & polluted atmosphere was too much for them.

core metering
Memory usage metering was described by Bob Frankston in his undergraduate thesis. The units of memory occupancy, page-milliseconds, are familiarly called "Frankstons." The official name was "memory units," and the accounting software accumulated and charged for them.

cow's stomach
[BSG] The "Coreadd queue" of Release 6.1 and afterward. This creation of Bernie Greenberg's was a solution to the problem of multi-CPU contention on the "page table lock" (PTL), a "spin lock" on the entire paging database, which had become a severe performance bottleneck. By the nature of the beast (see wired), disk interrupts, as they arrived at page control's interrupt side from the disk DIMs, had to spin on this lock, too. The "Cow's stomach" was a queue where the interrupt side saved the results of completed disk operations for later digestion by page control, viz., when the PTL was unlocked.

The algorithm defining the interaction of manipulating this queue with the locking and unlocking of the PTL was quite complex, and took Greenberg some time and effort to devise; when he had done so, he posted outside his door a hand-drawn flowchart replete with starfish and keyhole shapes and other innovations to symbolize non-traditional flowchart steps. The overall shape of a delimited loop representing area protected by a new lock resembled a stomach, and the complexity made many people ask if it was "a cow's stomach." As is evident, the functionality of the thing very much resembled that of a ruminant's stomach-complex, and the name stuck, and was even used for a similar mechanism in later operating systems of other vendors.

Honeywell bought rights to the CP-V operating system from Xerox, who had acquired its ancestors from Scientific Data Systems. The port of CP-V to the Honeywell 6000 line GCOS machines was called CP-6. It was an elegant and capable time-sharing system, programmed in the PL-6 language. Like Multics, CP-6 eventually lost the battle for resources and respect within LISD. See "The Palyn Report"

IBM operating system for the 360/67, begun at the IBM Cambridge Scientific Center in Tech Square in the mid-60s. Ancestor of VM. Story: "CP/CMS and the 360/67".

Central Processing Unit, or processor. The active device that fetched machine instructions from memory and executed them. There were two CPU architectures for Multics: 645 and 6180.

[AG91] An unplanned termination of system availability caused by problems in hardware and/or software.

When a signal is raised in an inner ring routine called from an outer ring, the signal is reflected back to the caller via a crawlout. To the user process, it appears that the signal originated from a stack frame in the outer ring. Ring 0 takes a special action on crawlouts: if any directories are locked, they are unlocked and salvaged before leaving ring 0.

Cray Station
[BWS] Usually titled Multics Cray Station (although the acronym MCS was already taken). Written by Warren Johnson for CCVR, it made Multics look like an RJE station for a Cray with job, file transfer, and print queues. Used by Ford (it was the reason for obtaining the third Multics system), CCVR, and RAE in the UK.

[VS] Ford's original Cray XMP ran COS (Cray Operating System) and required a front-end computer to submit, control, and retrieve jobs. The Cray station software on Multics allowed us to use Multics as a front-end computer for the Cray.

[PWB] Story: The User Ring (see page 2).

Credit Lyonnais
Multics site: Credit Lyonnais (Paris, France). Multics was an InfoCenter, alone, in middle of "IBM only" shop.

Camelback Road Facility. Honeywell building in Phoenix at the corner of Camelback Road and the Black Canyon Freeway that housed PMDC, home of the Phoenicians and System M. This building was a former discount store; in 1978 it was painted bright blue.

see Consistent System.

Computer Sciences Corporation, Moorestown NJ. This contractor installed 4 Multics systems for the US Naval War Games System.

[BWS] Cygnus Sort, a more performant reimplementation of the standard Multics sort/merge product by Cygnus Cybernetics Corp (Jim Homan).

[EAR] Copious Spare Time (CST). Personal time spent developing great ideas. e.g. "I developed it in my Copious Spare Time which seemed to be when a lot of stuff got done at CISL."

Compatible Time Sharing System. This IBM 7094 timesharing operating system was created at MIT Project MAC and first demonstrated in 1961. It was used as the programming and debugging tool during initial Multics programming and bringup by Project MAC, GE CISL, and BTL personnel. In some sense the intellectual offspring of CTSS, Multics was conceived as the next step into the future of multiple-access computing. Many of the MIT Multics principals had worked on the earlier system. Story: "The IBM 7094 and CTSS"

See Control Unit.

Simulated user driver for benchmarks. CUESTA could simulate multiple users issuing commands specified by scripts, with varying "think times."

Implementation of Unix CURSES package. Added to Multics in the mid 80s.

[BSG] For "command utility". A set of user-ring APIs for accessing command argument lists, supplying user substitutes for and calling the listener and command processor and other functions often needed by commands.