The development group produced many different series of documents describing Multics and our plans and progress in building it.

Multics Design Notebook

The very early plans for Multics were described in a set of Project MAC memos called the Multics Design Notebook. These memos were written in 1964 and circulated to the system builders and to other OS researchers to explain what MIT wanted from its next machine. In Section I: Introduction Prof. Corbató mentions that the choice of GE as the system vendor had already been made as of November 64.

The MSPM

The Multics System Programmers' Manual (MSPM) was intended to be the primary design document for Multics. Most of the MSPM was written between 1965 and 1969. The Table of Contents is online, and a few of the 839 sections have been placed on the web:

BA.1 MSPM- General Information

General statement of what the MSPM was for. (5K, 07/26/68)

BA.2 Summary of Multics Technical Policy

Key technical directions, e.g. segments don't overlap, need permission to write master mode. (5K, 07/26/65)

BA.3.00 Documentation Conventions

Labeling and content of MSPM sections. (8K, 05/19/66)

BB.2 System Module Interfaces (PL/I Subset for System Programming)

Data formats and programming conventions. Note that many of the formats described in this section are specific to EPL and were changed radically when later versions of the PL/I compiler were introduced. (19K, 9 figures, 6/24/66)

BB.2.01 EPL Subset for System Programming

Definition of the REPL subset of EPL. (6K, 01/31/69)

BB.3.01 Multics Standard Tape Format

The format of Multics "native" tapes. (9K, 06/02/67)

BX.1.00 Multics Command Language

The definition of the Multics command language. Interpretation of commands, Shell, Listener, special characters. (18K, 10/29/68)

Multics Programmer's Manual

The Multics Programmers' Manual (MPM) was begun at Project MAC in 1965 as the follow-on manual to the CTSS User's Guide. As described below, these manuals were taken over by Honeywell.

Repository Documents

During the early development phase of the project, 1965 to 1968, there were a number of other documents that didn't fit into the MSPM. Technical white papers, tool documentation, and so forth were assigned a "repository number" and published to the project. There were three series: M for Project MAC, B for Bell Labs, and G for General Electric. There were about 100 documents in each series, but the online table does not list those that were later obsoleted.

Multics Planning Notebook

The Multics Planning Notebook (MPN) was a multi-section management document which described Multics production milestones in the 1967-68 time frame.

Checkout Bulletins and Related Documents

Multics Checkout Bulletins (MCBs), and their successors Multics Technical Bulletins (MTBs), were design documents created by the development staff proposing, explaining, and expanding ideas for changes to Multics. As described in "The Multics System Programming Process," one or more MCBs would be written as the first step in introducing a significant change to the system. MCB numbers started at 1 and went up to over 1000, before the series was replaced by MTBs (because Multics was "checked out"). The MTB series began in 1973 and continued on into the 1980s. (An index of 719 MTBs from 1973 to 1987 (100K, 08/17/96) is available online.) At first, MCBs also covered task assignments and schedules, but later these kinds of documents were put into a different series, Multics Task Reports (MTRs).

There were also Multics Staff Bulletins (MSBs), which were memos describing staff rules and organization; these were later replaced by Multics Administrative Bulletins (MABs), same idea. Multics Operating Staff Notes (MOSNs) informed the system operators at MIT of procedural changes. A later series of documents called Multics Alternative Documentation (MAD) was produced by and for site analysts.

A series of memos were written about 1970 describing the proposed system design of the "follow-on" machine to the 645. This machine eventually became the Honeywell 6180. The series was called Multics Hardware Design Memos (MHDM). MHDM-12 by Corby was the one cited in the MIT/GE agreements.

In order to obtain the B2 Orange Book rating, a set of documents describing the Multics design and security implementation, a series of Multics Design Documents (MDD) was produced.

Multics Change Documents

In order to make any change to Multics, even a one-line fix, a programmer had to fill out a Multics Change Request (MCR) and have it approved by the MCR Board. This practice was instituted about 1975, and is documented in "The Multics System Programming Process."

Once the change was approved, the programmer filled out a "yellow form," which told the program librarians which source modules to pick up, how to recompile them, and how to integrate them into the operating system. The yellow form required the signatures of the programmer, programmer's manager, auditor, and documentation representative.

The MCR and yellow form were replaced by electronic versions in the 1980s, near the end of the system's development. MAB-048 describes the rules for the MCR board as of 1985 and contains a sample MCR form.

Project MAC TRs and TMs

MIT Project MAC produced many Technical Reports and Technical Memos. MIT theses that were done using MAC facilities were often published as TRs or TMs. The MIT Library 2000 project scanned a large number of these documents and the images and abstracts are available online on a server provided by the MIT Libraries. See the Multics Bibliography for pointers to these documents.

Manuals

When Honeywell turned Multics into a commercial product, one of its steps was to take over the MPM and produce it as a four-volume set of manuals, numbered AG90, AG91, AG92, and AG93. These manuals have been  scanned and put online by Al Kossow. Honeywell eventually produced almost 100 manuals describing Multics. Manual AW17 was a brief summary of commands.

Papers, Books, and Articles

Over 232 conference papers, books, and articles about Multics were written during the system's lifetime, many by members of the development team.