Multics 826 entries
16 Aug 2014

Glossary - B

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|
B2
Orange Book (US government TCSEC) rating achieved by Multics. (See NCSC.) Multics got the first B2 rating, in August, 1985, and had the only B2 for many years. A rating at the B level indicates support for mandatory access control as well as a relatively high level of security assurance. See AIM. Story: B2 Security Evaluation.

backup
Dumping files from disk to tape so they can be restored in case of a system crash. While Multics is running, this operation is done by a daemon process: the Backup.SysDaemon ran incremental and complete dumps. While Multics is not running, the BOS SAVE command copies disk contents to tape. See also volume backup.

BASED
PL/I storage class, meaning "found by following a pointer." The way this language construct dovetails with the 645 hardware's pointer registers is elegant and compelling. User and system code use pointers to refer to whole segments or to small data structures, and the hardware makes this efficient.

BASIC
Beginner's All-purpose Symbolic Instruction Code, a language invented by Professors John Kemeny and Thomas Kurtz at Dartmouth in 1963. Multics had several BASIC implementations; the final one was a compiler by Barry Wolman at Honeywell CISL that produced native Multics object segments.

Bath
University of Bath, England. See Avon.

BCD
[BSG] Binary-coded decimal. Really not that at all, but a six bit character code native to the GE 600 family (see 645) and by extension the 6000's (see 6180), the native character set and encoding of GECOS. There is hardware support for six-bit characters in exotic indirect words, maskable memory (see SCU) instructions, and EIS. Obviously, BCD had no lower-case characters, and Multics did not use BCD at all, except to output log and crash and tape mount messages from ring 0 to the primitive Selectric operator's console. BOS, however, operated largely in BCD: C printf's granddaddy BOS ERPT worked in BCD. See also printer. The IBM 7094 had a slightly different BCD character set; see also EBCDIC.

BCE
Bootload Command Environment. The successor to BOS.

BCO
Billerica Computer Operations. The division of Honeywell that built the Level 6 minicomputer and the VIP7801. Used a Multics as its software factory. There was also a compiler group housed here that wrote the Multics COBOL compiler. After CISL was closed, some Honeywell Multicians moved to Billerica to work on a proposed next generation system, Opus.

BCPL
Bootstrap Combined Programming Language. A language defined by Martin Richards of Cambridge, for bootstrapping CPL. Richards visited MIT in 1967 and brought the language design with him; BCPL was first implemented on CTSS in 1967. Dennis Ritchie and Rudd Canaday ported CTSS BCPL to Multics. Ken Thompson wrote a version of his QED editor in BCPL, and Doug McIlroy and Bob Morris wrote Multics runoff in BCPL. BCPL is an ancestor of the C language.

Bell Canada
Multics customer, Bell Canada. Had two sites, Toronto (Don Mills, Ontario, Canada) and Montreal (Dorval, Quebec, Canada). Bell Canada site history.

benchmark
One part of most RFPs was a performance benchmark. Vendors were required to demonstrate an actual system running a specified workload, and complex scoring procedures in the RFP would eliminate a system if it didn't meet certain criteria, and award points for other measures.

In some cases, the system being demonstrated would be driven by another computer system simulating interactive users issuing requests. We used the CUESTA system in Phoenix to do this.

Multics participated in a lot of benchmarks, and won some. The configuration of System M in Phoenix had extra equipment so that benchmarks could be developed and run.

There were cases where Honeywell received an RFP, bid GCOS, tried to run the benchmark and failed, and called in the Multics team at the last minute, and we put together a benchmark response, and not only passed the benchmark but surpassed other competitors.

binder
[BSG] Utility that combines program binaries, the output of compilers, into a larger program binary, an alternative to dynamic linking. There are several reasons for doing this: reduction of page fragmentation, coordination and synchronization of the components of a software package, the deliberate making unavailable of internal interfaces, reduction of the number of segment numbers used by a process (see KST) and page tables used by the system (see AST), and reduction of the number of linkage faults (see dynamic linking) needed to run a program are among the foremost. Typically, all of the pieces of, say, the Version 2 APL interpreter are "bound" into a single segment called bound_v2apl_ (see underscore). The input to the binder is an archive of binaries to be bound, with a control file thrown in, too. Melanie Weaver was Lord of the Binder for many years.

Birmingham
Multics site: University of Birmingham. See UBCC.

bisync
Binary Synchronous Communication. MCS supported this kind of channel for Remote Job Entry and other high-speed communications.

bit count
The file system stores a bit count for each segment and directory, but attaches no hardcore meaning to this quantity. User-ring programs, by convention, interpret the bit count as the length of a segment in bits; on a directory, a non-zero bit count indicates that the directory should be treated as a multisegment file. Directory control does maintain the bit count author, a field that remembers the last user ID that modified the bit count of a segment; since editors set the bit count when writing out a segment, this value is an (insecure) "who last modified" flag.

[WOS] It's worth pointing out that "bit count" is a clumsy mechanism because it is entirely discretionary: it can be inconsistent with the real segment length, confusing applications (and users) no end. The NSS star-listing interfaces exacerbated this, by requiring users to make a choice between getting correct (but expensive) length information and the unreliable (but fast) bit count.

block
[BSG] "Block and wakeup" is one of two interprocess synchronization mechanisms in Multics. A process "goes blocked" (i.e., into a suspended state) awaiting any "wakeup" sent to it. A "wakeup" identifies not only the process, but a "channel" on which it is said to be woken up, and contains a 72-bit arbitrary datum. Received wakeups for a given channel are "queued" for that channel. A process can either go blocked "on" ("event wait", i.e., waiting for a wakeup on) a given channel, or declare a callback procedure ("event call") for a channel, a common way of implementing server-type software. The other synchronization mechanism is "wait and notify." .

boot tape
[BSG] Multics Standard Tape (MST) from which the three "collections" of segments of the supervisor (and a handful of other segments needed to start up a Multics from scratch) are loaded into core, virtual memory, and the file system, respectively. Since each of these stages depends upon successive states of increased operability of the supervisor, the technique of merely loading an "image" is not available. The "bootload", or "bootstrap load" process really is a classic "up by the bootstraps" endeavor: successive mechanisms of the supervisor (e.g., segmentation, PL/I runtime, paging, dynamic linking) are made operative one by one in and by restricted environments devoid of those features. Some of the steps, such as the copying of unpaged segments into paged ones when paging had become operative (done by make_segs_paged, which Mike Grady Alexandrically renamed from update_sst_pl1), are mind-bogglingly profound. The bootstrap process is known as initialization.

The first record of the boot tape is read into core by BOS, which then transfers control to it -- BOS was an afterthought, and Multics was at first designed to have been booted on a bare machine. But in fact, BOS passes an array of hardware configuration information and software parameters (e.g., table sizes) read in from cards (the config deck) necessary for Multics operation. See development run

bootload
To load software into a system and start it up. On the 645, pushing the BOOT button on the GIOC booted from cards or tape, and Multics System Tapes had a special self-loading first record. When BOS was first written, it booted from cards and then the BOS BOOT command booted MSTs. A warm boot of BOS, if it was already loaded on the disk, required only a single card.

Article: Multics Bootstrap Loading

bootstrap1
First program on a Multics boot tape. bootstrap1 is entered in absolute mode. (On the 645, it paired the ABRs.) It then reads the rest of collection 1, remembering where it loaded bootstrap2 and the prelinker, establishes a primitive appending environment and stack, and calls bootstrap2, which prelinks collection 1 and proceeds with initialization. Initially written by Nguyen Van Binh, made to work by Noel Morris and Tom Van Vleck, and further maintained and improved by many.

BOS
[BSG] Bootload Operating System. A minimal, single-user, single-processor, non-paged, entirely assembly language 645/6180 "operating system" that was run before Multics came up and after it was shut down or crashed. Part of the Multics software, and not used anywhere else, BOS played no role at all while Multics was running, comprising only a several-hundred word "toehold" to swap core with Multics when the latter finally stopped running. BOS included commands to make and restore disk snapshots, patch and dump virtual memory to the printer, load device controller microcode and the like, and initiate the bootload and/or ESD of Multics. Initially created on the 645 by Stan Dunten, BOS was continued on the 6180 largely by Noel Morris, although others contributed. BOS was later replaced by BCE.

branch
Structure in a directory allocated for each segment or directory. Sometimes extended in meaning to the object described by it, e.g., "there are three types of branches: ordinary segments, directories, and MSF directories." (The other kind of directory entry is a link.)

Bristol
University of Bristol. See Avon.

Brunel
Multics site: Brunel University (Uxbridge, Middlesex, England). Installed 1983, removed 1988.

BSA
Bootstrap Assembler.

BTL
Bell Telephone Laboratories. Research arm of the Bell System in the 1960s. A team from Bell Labs, led by E. E. David, Jr., joined MIT and General Electric in the initial design of Multics.

Bell Labs Multicians worked at BTL locations in Murray Hill, NJ, Whippany, NJ, and Holmdel NJ. A GE-645 system was installed at Murray Hill from 1967 until Bell withdrew from Multics development in 1969.

Some BTL Multicians went on to built another operating system with Multics-like features. Story: UNIX and Multics.

Bulk Store
Replacement for the firehose drum, this was a large bank of slow core memory, accessed as if it were a drum. See page multilevel.

[WOS] Bulk store was eliminated in MR8.0 (I think) as part of the attempt to support Orion. I was personally responsible for this, and I was mighty upset to discover that, despite assurances that they wouldn't mind, all three USGS sites still used it and were, in fact, none too pleased.

Bull
[Jean Bellec] Compagnie des Machines Bull (CMB), a French computer company partially owned by GE as Bull-General Electric in 1964, became Compagnie Honeywell-Bull in 1970. Absorbed the French company Cii and was nationalized by the French Government in 1982. It marketed Multics successfully between 1975 and 1985. Eventually, Compagnie des Machines Bull bought back the computer division of Honeywell in 1985 and ran it as Honeywell-Bull Inc.

[JWG] Known as Cii Honeywell Bull in the 70s. In the 80s, after Bull had been nationalized and was not owned by Honeywell, it actively marketed Multics and was responsible for almost 50% of the sites. In 1989 it bought the computer division of Honeywell and folded it into what is called Bull Worldwide Information Systems.

[Jean Bellec] Compagnie Honeywell-Bull adopted the segmented ring hardware (with process exchange support in the HW) for its IBM 360 clone in ~69, and operated a 645 located in Avenue Gambetta in Paris from 1972 to 1975 as a software factory for Honeywell's Series 60 Level 64 GCOS64 operating system. (history) This system was used in sync with a similar system operated in Billerica by Honeywell BCO that initially shared the work on GCOS64. The Billerica system was accessed in 1971 from Paris thru a multiplexer allowing six TTY37s to share a leased-phone line.

[Daniel Bois] Most of the internal (GCOS 7) code of the DPS 7, produced on the 645 is still there. And in fact NEC has derived an ACOS machine, called Acos 4 and some of THEIR code (still) have comments in French !!!

bump
Involuntary logout. A logged in user could be bumped by the answering service for several reasons: inactivity, exceeding a resource limit, or explicit administrator action.