Burroughs MCP

MCP (Master Control Program)

Company type	Operating system
Industry	Computer software
Founded	1961
Products	Operating system for Burroughs B5000 series and Unisys Clearpath/MCP platforms

The MCP (Master Control Program) serves as the operating system for Burroughs B5000/B5500/B5700 and B6500 and later models, including the Unisys Clearpath/MCP platforms.

Initially created in 1961 with ESPOL, MCP underwent a complete rewrite in the 1970s using NEWP, a language designed to be more structured, secure, and reliable. MCP introduced several groundbreaking features: it was the first operating system to support multiprocessing, the first commercial OS to incorporate virtual memory, and the first to be entirely developed in a high-level language.

History

In 1961, MCP distinguished itself as the first OS developed exclusively in a high-level language (HLL). The Burroughs Large System (B5000 and its successors) was architected with the expectation that all software, including system-level programs, would be written in HLL rather than assembly—a pioneering concept at that time.

Unlike IBM, Burroughs software was tightly coupled with its own hardware since there were no compatible third-party platforms. This exclusivity enabled Burroughs to provide customers with source code access, allowing them to recompile and tailor system software according to their requirements—a practice common among major clients such as the Federal Reserve. This transparency led to the creation of a Burroughs Users Group, which facilitated collaboration on OS enhancements; many of these improvements were eventually integrated into the core OS. In this way, MCP can be regarded as an early example of open-source software.

Although Burroughs entered the electronic computing market later than competitors like NCR, IBM, and Univac, MCP has retained its unique position. As MCP now runs on standard hardware platforms, Unisys no longer distributes all components in source code form.

MCP was also a pioneer in implementing virtual memory within a commercial OS, supported by Burroughs hardware from its inception. Its architecture manages compiler-defined objects instead of fixed-size pages, reflecting its non-von Neumann stack-based design principles.

Noteworthy is Donald Knuth’s involvement as a consultant for Burroughs between 1960 and 1968; during this period, he contributed ideas such as the "boundary-tag" technique for dynamic memory allocation that influenced MCP's development.

Following Unisys’ discontinuation of hardware manufacturing in the early 2010s, MCP currently operates through emulation.

File system

MCP provides a file system featuring hierarchical directory structures. Early implementations used distinct files to represent directory nodes; however, since around 1970, MCP utilizes a 'FLAT' directory model listing all file paths on a volume. This design enhances performance by eliminating multiple directory lookups while preserving hierarchical naming conventions. It is possible for files and directories to share identical names within a path (for instance, "A/B" and "A/B/C").

Files are stored on named volumes (e.g., 'this/is/a/filename on myvol'), which are independent of physical disk drives. Volumes may span several disks or be configured with mirroring for redundancy. Programs can remap volume names using the process’ FAMILY assignment feature, allowing logical volume identifiers to correspond to primary and fallback physical volumes. For example, “FAMILY DISK = USERPACK OTHERWISE SYSPACK” directs file operations initially to USERPACK and then to SYSPACK if necessary; if no volume is specified explicitly, DISK acts as the default.

Each file carries attributes including its name, type (which determines processing methods), record size, block size (defining input/output units), and area size (allocation units on disk). File types specify whether content is character data, source code for various languages, binary data, or executable programs.

Security mechanisms incorporate standard access controls such as public or private settings alongside guard files for more sophisticated policies. Furthermore, only compilers authorized by trusted operators can generate code files—operators with adequate privileges must approve new compilers via the 'mc' command to prevent unauthorized program creation.

MCP’s Journaling file system provides resilience against disk failures or power interruptions by preventing file system corruption except when caused by trusted system components.

By default, the file system is case-insensitive, but it also supports case-sensitive and case-preserving filenames when enclosed within quotation marks.

Process management

In MCP, processes are referred to as "Jobs" and "Tasks." A single Job may encompass multiple tasks, which can execute either sequentially or concurrently. The job flow is governed by job-level logic, generally implemented through MCP's job control language, WFL. A job is considered complete once all its associated tasks have finished execution.

The lifecycle of an MCP Process begins with the Job entering a "Queued" state within user-defined Job Queues. It then transitions to "Scheduled" when loaded into memory. Tasks, upon initiation, move directly into the 'Scheduled' state. Throughout their execution, both jobs and tasks cycle through "Active," "Waiting," and "Scheduled" states before reaching the 'Completed' status at termination.

Processes that are actively running consume processor time; those ready but awaiting processor availability enter the ready queue. Each process is assigned a “Declared” or “Visible” priority ranging from 0 to 99, with a default of 50. System processes are typically given higher priority values. The overall priority hierarchy depends on task classification: Independent Runners (core OS processes) hold the highest priority, followed by MCP lock users, Message Control Systems such as CANDE, Discontinued processes, Workflow Language jobs, and lastly user-initiated processes. Additionally, a Fine priority mechanism elevates IO-bound tasks above CPU-bound ones when they share the same declared priority.

When processes wait for resources like file reads, they do so by waiting on an EVENT data structure. Once the resource becomes available, the event triggers and awakens all waiting processes. Processes may simultaneously wait on multiple events or timeouts. These events are fully programmable by users, allowing for highly customizable system behavior.

Processes that have terminated are flagged as completed. Operators can monitor all task statuses: running and ready tasks appear under 'Active,' thanks to MCP's preemptive multitasking capabilities accessible via the 'A' command. Terminated tasks display termination reasons such as EOT (normal completion), DSed (failure), or operator-initiated O-DS entries. Fault-related terminations include codes like F-DS or P-DS for errors such as invalid index or numeric overflow. Completed tasks can be listed using the 'C' command.

Tasks in waiting states are shown with their respective reasons using the 'W' command; further details can be accessed via 'Y'. Tasks may pause awaiting operator input (through accept 'AX'), file availability, or other resources. Unlike many systems that automatically terminate tasks lacking necessary resources, MCP permits operators to provide missing files or redirect tasks. This approach enhances system recoverability and reduces programming complexity by minimizing error-checking requirements.

MCP facilitates dynamic remapping of file and database requests both prior to and during task execution and incorporates mechanisms for error detection and recovery. The longstanding 'ON' statement manages specific faults or broad 'anyfault' conditions by transferring control to designated fault-handling routines.

To better handle abnormal terminations and support secure third-party plug-ins, MCP introduced a 'try' statement in the mid-1990s with syntax similar to 'if...else'. Recoverable terminations activate the first 'else' block, which receives attributes detailing the error condition. This feature bolsters fault tolerance beyond conventional program fault management.

Most task terminations are recoverable except those caused by operator/user DS commands unless privileged tasks employ an UNSAFE try variant. Consequently, MCP delivers a robust fault-tolerant environment in contrast to typical crash-and-dump systems.

Tasks possess attributes such as priority (which can be set at compile-time, runtime, or dynamically adjusted), processor usage time, wait duration, and status—all accessible programmatically alongside file attributes. The parent task is also obtainable through programming interfaces (e.g., 'myself.initiator.name').

Memory management relies on GETSPACE and FORGETSPACE procedures for allocating and freeing memory and disk overlays. Memory types include SAVE (resident), OVERLAYABLE (virtual), and STICKY (resident but movable). These procedures are triggered by events like HARDWAREINTERRUPT, which handles hardware interrupts and may invoke GETSPACE or IO_FINISH. The BLOCKEXIT event oversees cleanup upon exiting code blocks by calling functions such as FILECLOSE and FORGETSPACE.

J_EDGAR_HOOVER serves as the primary security overseer during process initiation, file access, user logon, and other critical system events.

The scheduling process GEORGE decides which process receives CPU allocation next and utilizes specialized instructions like MoveStack.

Task states evolve from NASCENT to ALIVE upon receiving the DELIVERY event BIRTH; PROCESSKILL changes a task’s state to DISEASED; DEATH moves tasks into the MORGUE queue where PROCESSKILL handles resource deallocation.

While in the ALIVE state, MCP routines execute within each process's stack context with CPU usage accounted accordingly; security permissions apply per stack instance. Before BIRTH and after DEATH states, MCP operates on separate stacks or maintains an idle stack if none is available.

Software components and libraries

MCP libraries facilitate the sharing of both code and data across different processes, marking a notable advancement from earlier Burroughs systems where interdependent processes operated asynchronously but had to be combined into a single program. The introduction of libraries delivered several important benefits:

• Separation of programming units for libraries and processes
• Encapsulated data access to ensure controlled resource sharing
• Compatibility across different programming languages between libraries and their clients
• Elimination of process context switching for secure data handling

These libraries, introduced in the early 1980s by Roy Guck and colleagues at Burroughs, are conceptually similar to C. A. R. Hoare's monitors, offering regulated mutual exclusion and synchronization through MCP EVENT mechanisms and the Dahm locking approach. Libraries provide procedural entry points that undergo interface compatibility verification prior to linking, enabling dependable synchronized interactions without requiring synchronization logic on the client side.

Compared to conventional dynamic libraries (DLLs), MCP libraries offer three distinct sharing configurations: 'shared by all', ‘shared by rununit’, and 'private'. Private libraries create unique instances for each client without sharing data. The 'shared by all' mode connects multiple clients to a single library instance, optimizing resource utilization. The 'shared by rununit' mode, tailored for COBOL environments, allocates one library instance per initiating client program along with its linked libraries, supporting dynamic COBOL rununits.

When a library is accessed for the first time, it sets up its global environment and enters a freeze state, which exposes entry points while suspending further stack activity until unfrozen for cleanup or shutdown. Client invocations execute on their individual stacks, allowing concurrent, synchronized operations that access the library’s global data safely.

Freeze states include temporary (where the library terminates when no clients remain), permanent (the library stays loaded until manually unfrozen by an operator), and controlled (the library remains active for tasks such as monitoring or initialization).

Libraries can be accessed either 'by title' (using file names) or 'by function' (through logical names mapped via operator commands). MCP manages unavailable libraries gracefully by queuing client requests until the library becomes accessible or is redirected.

Updates to libraries occur dynamically: operators can load new versions while existing clients continue using previous versions until they terminate.

Security is maintained through linkage classes: standard libraries operate at class zero; privileged system libraries reside at class one, restricting access from ordinary programs unless marked as ‘trusted’ with selective entry points exposed.

Fundamental MCP subsystems—including the database engine, networking modules, and system intrinsics—are implemented as libraries to provide efficient multi-client access.

In the mid-1990s, Connection Libraries were introduced as standalone executable programs that exchange data and functions via structured arrays. For instance, the networking subsystem functions as a connection library, permitting direct function calls between clients and network services without buffering or context switches. Each linkage maintains dedicated state blocks, allowing precise control over link authorizations and terminations, thereby improving modularity and overall performance.

Port files

Port files represent another form of inter-process communication (IPC), enhancing traditional Unix pipes by enabling multi-directional and multi-party data exchange. While they operate at a slower pace compared to IPC methods confined to a single machine, such as library calls, port files are particularly effective for distributed IPC scenarios.

Initially developed within the Burroughs Network Architecture (BNA), port files have since been adapted to function over common network protocols like OSI and TCP/IP. Servers establish a port file identified by the KIND attribute set to PORT to accept incoming client connections. Each client connection generates a uniquely indexed subfile, facilitating numerous concurrent network interactions.

Server applications retrieve client requests through the port file—subfile 0 allows reading from any active connection—and reply by writing back to the client’s designated subfile. This mechanism supports streamlined and scalable networked IPC communication.

Operating environment

The MCP provides a refined yet user-friendly operator interface designed to accommodate installations of varying scale. In large configurations, dedicated Operator Display Terminals (ODTs) are positioned in secure locations, whereas smaller systems permit operator control from any authorized terminal via the MARC utility (Menu Assisted Resource Control). Operator inputs are brief—mostly one or two letters—and case-insensitive, tailored for proficient operators overseeing mainframe activities with maximum efficiency.

Task and library management is handled through the 'mix' utility, with tasks identified by mix numbers. Operators launch programs using commands like 'EX' or 'RUN' followed by the program’s filename. ODTs commonly run ADM (Automatic Display Mode), a configurable interface displaying active, waiting, and completed tasks alongside system messages requiring operator attention.

Operators track task statuses using commands such as 'A' for active, 'W' for waiting, 'C' for completed, and 'MSG' for messages. For tasks pending operator input, entering the mix number followed by 'Y' (e.g., '3456Y') reveals the necessary input fields. Tasks can be suspended with commands like '3456ST' and resumed with '3456OK'; often, the system autonomously detects resource availability and triggers relevant events without manual intervention.

Text-based interactions between operators and programs are facilitated through the accept command (e.g., ‘3456AX MORE INFO’) and DISPLAY messages routed to the MSG screen.

File operations are managed using commands such as FILE (to list files), COPY, REMOVE, and RENAME, granting operators comprehensive control over system files.

In summary, MCP’s operating environment balances robustness with simplicity and generally demands fewer operators than similar platforms. Central to this efficiency is its advanced Work Flow Language, which significantly streamlines operational processes.

Logging

The MCP environment maintains detailed logs encompassing all system activities, including operator commands and messages. Crucial program events—like workflow job initiation and completion—are documented within both system and application logs. File and database transactions may also be recorded. The extensive logging strategy contributes to MCP’s comparatively slower performance relative to systems such as Unix because MCP enforces physical disk writes immediately after each record, whereas Unix employs buffered logging.

These comprehensive logs play vital roles in business contexts by enabling forensic investigations of system failures and uncovering security incidents. System logs rotate automatically based on configurable time intervals and generate substantial amounts of data that can be filtered and examined using tools like LOGANALYZER.

Memory dumps are analyzed through DUMPANALYZER, which leverages embedded LINEINFO within source code files to identify precise source statements at the moment of failure. Standard program dumps include source sequence numbers along with variable names, making these diagnostic utilities indispensable for effective troubleshooting and system tuning.

Innovations

In addition to technological breakthroughs, Burroughs Large Systems introduced management practices that have become standard within the technology sector. The MCP software was distributed along with complete source code and development utilities, allowing users to tailor and improve the operating system. Customers frequently submitted patches—small segments of source code identified by sequence numbers—as either feature additions or bug fixes (FTRs). A significant number of these contributions were incorporated into later MCP versions.

This model of collaborative development, where a knowledgeable user community actively participates in the product’s advancement, foreshadowed the open innovation frameworks that have been widely embraced across various industries since the 1970s.

Compilers

Unisys MCP accommodates several generations of compilers supporting a variety of programming languages essential for enterprise-level applications, including:

• ALGOL (DCALGOL, BDMSALGOL, DMALGOL)
• C
• COBOL (COBOL74, COBOL85)
• Fortran77
• NEWP
• Pascal
• RPG

Other important development utilities consist of:

• Binder
• Network Definition Language
• Work Flow Language (WFL)

Earlier compiler versions supported languages such as ESPOL, COBOL(68), Fortran(66), APL, and PL/I. These compilers contribute to MCP’s adaptability in running both legacy and contemporary business software across multiple sectors.

Assembler

The Unisys MCP operating system does not provide an assembler component.

Summary

MCP holds the distinction of being the first operating system entirely written in a high-level language. Throughout its more than five decades of existence, it has introduced pioneering commercial features including virtual memory, symmetric multiprocessing, and a sophisticated high-level job control language (WFL). Many capabilities offered by MCP have only been adopted by other major operating systems in recent years. Coupled with Burroughs’ large systems architecture, MCP delivers a secure, efficient multitasking and transaction processing platform.

External links

• MCP 21.0 Documentation – Free access; may require copyright acknowledgement