History of IBM mainframe operating systems

IBM Mainframe Operating Systems
Industry	Computer software
Founded	1950s
Founder	IBM
Products	z/OS, z/VM, z/VSE, z/TPF, OS/360, DOS/360, TSS/360, CP-67, IBSYS, BESYS, UMES, MTS, MUSIC
Owner	IBM

The evolution of IBM mainframe operating systems holds a significant place in the development of mainframe OS owing to IBM's leading position as the foremost supplier of mainframe computer hardware worldwide. Operating systems running on IBM mainframes are produced both by IBM itself and by external developers.

In the early days, IBM mainframe operating systems seldom introduced groundbreaking features, with exceptions such as TSS/360 and the virtual machine environments beginning with CP-67. Nevertheless, IBM's approach of prioritizing established technologies facilitated swift user adoption. The current lineup of IBM mainframe operating systems—z/OS, z/VM, z/VSE, and z/TPF—are direct descendants of platforms that originated in the 1960s and maintain backward compatibility.

Prior to System/360

IBM initially lagged in operating system development. During this period, other organizations like General Motors created their own solutions, including General Motors OS (1955) and GM-NAA I/O (1956), designed to operate on IBM hardware. In 1962, Burroughs Corporation introduced MCP, while General Electric launched the GECOS, both tailored for their respective clientele.

The first IBM operating systems appeared in the mid-1950s, crafted by IBM customers who operated expensive machines (costing roughly US$2 million in 1955) that remained idle during manual job setups. These early OSs automated job scheduling to enhance machine utilization.

Such initial systems were limited to specific processor models and primarily supported scientific and engineering applications. Some IBM computers even functioned without any operating system. A notable innovation from the smaller IBM 650 was an automatic hardware interrupt recovery mechanism that resumed processing from the last checkpoint instead of requiring manual job restarts—a feature later integrated into OS/360.

Transition from General Motors GM-NAA I/O to IBSYS

In 1956, General Motors Research developed GM-NAA I/O for the IBM 701, building upon a 1955 prototype named GM Operating System, and later updated it for its successor model. By 1960, the IBM user community group SHARE assumed responsibility and issued an updated version called the SHARE Operating System.

Subsequently, IBM advanced this initiative by creating IBSYS for the IBM 7090 and IBM 7094. IBSYS required eight tape drive units unless disk drives were available, which reduced this number. Its main components comprised a card-based Job Control Language serving as the user interface; compilers for languages such as FORTRAN and COBOL; an assembler; along with utility programs including a sorter.

In 1958, the University of Michigan adapted GM-NAA I/O into the UMES, designed specifically to handle numerous small student jobs efficiently. UMES remained operational until 1967 when it was superseded by the timesharing system known as the MTS.

BESYS

Developed by Bell Labs, BESYS (also referred to as BELLMON) was utilized until the mid-1960s. Bell Labs freely distributed BESYS without formal technical assistance, promoting wider usage.

FORTRAN Monitor System

Before IBSYS's introduction, IBM offered a tape-based operating system dedicated solely to compiling FORTRAN programs on its IBM 709, 7090, and 7094 models. Both the FORTRAN compiler and this operating system were supplied together on a single tape.

Early developments in time-sharing and virtual machine technologies

During the late 1950s and early 1960s, MIT's Fernando Corbató pioneered the initial experimental time-sharing systems, including the CTSS, implemented on modified IBM 709, IBM 7090, and IBM 7094 mainframes. These innovations were inspired by a concept proposed by John McCarthy. In the 1960s, IBM experimented with time-sharing systems enhanced by hardware and microcode adaptations to support virtual memory. These included the IBM M44/44X (early 1960s), IBM CP-40 (1964–1967), and CP-67 (1967–1972). IBM distributed CP-67 to select clients without formal support or warranty. The CP-40 and CP-67 systems utilized customized System/360 processors, whereas the M44/44X was based on the earlier IBM 7044 architecture.

Although these projects followed IBM's 1964 announcement of System/360, they significantly influenced later integration of virtual memory and virtual machine capabilities into System/370 mainframes by 1972. Important insights gained were:

The M44/44X demonstrated that partial virtualization strategies could cause severe performance degradation due to thrashing, impacting virtual memory efficiency.
IBM's experience with CP-40 and CP-67 led to effective thrashing management techniques and validated the reliability and efficiency of their virtual memory and machine technologies for commercial-scale operations. Notably, David Sayre from IBM showcased that automated virtual memory management could outperform manual overlay programming techniques.

In 1968, Computer Software Systems, a consulting firm, leveraged CP-67 to initiate a commercial time-sharing service. The technical team included former MIT personnel Dick Orenstein and Harold Feinleib. This company was later rebranded as National CSS, which enhanced the software to accommodate a larger user base until it evolved into VP/CSS. VP/CSS remained the backbone of National CSS services until the early 1980s when it transitioned to IBM's VM/370 platform.

In the late 1960s, several universities created additional S/360 time-sharing operating systems:

The Michigan Terminal System (MTS), developed in 1967 by a consortium led by the University of Michigan, operated on IBM mainframes equipped with virtual memory starting with the S/360-67. MTS remained in use until 1999.
Beginning in 1969, McGill University developed MUSIC, which expanded to include features such as text search, web publishing, email, and software development tools. Marketed primarily to educational institutions as an economical operating system by IBM, MUSIC became an official IBM Systems Product in 1985; its final release occurred in 1999.
At Stanford University, between 1967 and 1968, ORVYL and WYLBUR were created for the IBM S/360-67, providing some of the earliest time-sharing functionalities on IBM S/360 machines.

Operating systems for System/360

Prior to the mid-1960s, IBM’s lower-end and high-end computer lines were incompatible due to differing peripherals and software environments, complicating program portability. This fragmentation increased development costs and discouraged customers from upgrading. To address this, IBM introduced the unified System/360 family in 1964, featuring shared peripherals and broad software compatibility across models.

Initially, IBM intended System/360 to run a single batch-oriented operating system named OS/360. However, due to OS/360’s large size exceeding memory constraints on smaller models or its protracted development schedule, a simpler batch OS called DOS/360 was created. Additional interim systems included BOS/360 (targeting smallest machines) and TOS/360 (designed for tape-only configurations).

The operating systems designed for System/360 were considerably more sophisticated than earlier IBM offerings because they had to support:

Multiprogramming, enabling multiple applications to run concurrently to improve CPU utilization during slow input/output operations.
A broad spectrum of hardware configurations ranging from as little as 16 KB up to 1 MB of memory with varying processor speeds.
Diverse application demands including sequential file processing, rapid direct record access, and computation-intensive workloads.

These factors made OS/360 one of the most ambitious software projects ever undertaken at that time, leading to significant delays, budget overruns, and numerous defects. Its development necessitated creating the BPS/360, which provided fundamental tools such as compilers for languages like FORTRAN and COBOL, utilities including sorting programs, as well as an assembler.

Competitors capitalized on delays in OS/360’s release by targeting vulnerable market segments. To sustain System/360 sales momentum, IBM introduced four temporary operating systems:

BOS/360, supporting tape drives and limited disk storage.
TOS/360, offering an upgrade path for customers using IBM 1401 tape-only systems.
DOS/360, developed within IBM’s small business division; it achieved widespread adoption with its descendant system z/VSE still operational today.
A restricted version of OS/360 containing only the Primary Control Program (PCP) without multiprogramming capabilities.

With the launch of the S/360-67, IBM unveiled a timesharing operating system called TSS/360, which utilized virtual memory technology. However, TSS/360 suffered from delays and instability issues. In contrast, CP-67 from IBM’s Cambridge Scientific Center proved more dependable and was distributed “as is” without warranty for selected users. CP-67 eventually evolved into VM/370 and subsequently into today's z/VM. Before discontinuing TSS variants completely, IBM released three versions of TSS/370 as migration options.

The difficulties encountered during System/360 OS development significantly advanced software engineering practices. Project manager Frederick P. Brooks chronicled these experiences in his book The Mythical Man-Month, emphasizing that adding personnel to struggling projects often impedes progress—a phenomenon known as "Mythical Man-Month" syndrome—and that successors to successful products tend to accumulate excessive features—a tendency referred to as the "second-system effect." OS/360 serves as a classic case study illustrating these principles.

DOS/360

While OS/360 was designed for the more advanced System/360 models, DOS/360 served as the primary operating system for the less capable machines in the lineup. It came equipped with utility tools, a macro assembler, and compilers for both FORTRAN and COBOL. Subsequent enhancements introduced support for IBM RPG and a subset of PL/I. DOS/360 accommodated multiple file organizations through various access methods:

Sequential data sets processed records one by one.
Indexed files (ISAM) utilized keys to locate specific records efficiently.
Direct access files (BDAM) required specifying exact physical disk addresses; although more complex to handle, BDAM provided the fastest disk retrieval speeds and was preferred by software developers, particularly for database systems such as ADABAS, IDMS, and IBM’s DL/I.

Files could contain either fixed or variable-length records and could extend across several disk volumes.

Additionally, DOS/360 included BTAM, a fundamental yet adaptable data communications interface compatible with numerous terminal types—a significant benefit given the limited standardization of communication protocols at the time.

However, compared to OS/360, DOS/360 exhibited several constraints:

Initially supported only single-tasking; later releases allowed running up to three concurrent programs within fixed-size partitions.
Its Job Control Language (JCL) was designed with simplicity in mind for lower-end hardware but proved challenging for programmers to use effectively.
Lacked a built-in spooling system; third-party products like GRASP were developed to enhance input/output efficiency.
Did not provide a relocating loader; separate executable versions had to be maintained for each partition.
Executables were stored in the Core Image Library, which did not reclaim space after deletions—requiring occasional compression that could interrupt development workflows.
The application programming interface (API) differed from that of OS/360, necessitating code adjustments to ensure compatibility between systems.

IBM expected users of DOS/360 to eventually transition to OS/360. Nonetheless, DOS/360 became the most widely adopted operating system globally due to:

Strong sales of System/360 hardware.
More than 90% of System/360 units sold were Models 20, 30, and 40—entry-level machines with insufficient memory capacity to support OS/360.
DOS/360 operated efficiently on these cost-effective processors and outperformed earlier operating systems used by medium-sized enterprises.

Consequently, its lineage continues today through z/VSE, which remained in widespread use as of 2005.

OS/360

OS/360 offered several support tiers along with a unified API and shared codebase. PCP was a basic configuration allowing only one program execution at a time, whereas MFT ("Multiprogramming with a Fixed number of Tasks") and MVT ("Multiprogramming with a Variable number of Tasks") persisted into the late 1970s despite newer versions being released. The separation among PCP, MFT, and MVT likely resulted from MVT’s greater memory requirements or the need to expedite delivery of a multiprogramming system (MFT).

Though employing different memory management techniques, PCP, MFT, and MVT shared similar features valuable for business applications:

A consistent application programming interface (API), facilitating application portability without recompilation.
The same flexible JCL, representing an improvement over that used in DOS/360.
File access methods inherited from DOS/360 covering sequential, indexed, direct files, and data communications (BTAM).
Added support for partitioned file structures with an access method (BPAM) tailored for managing program libraries; unlike DOS/360’s Core Image Library, partitioned files allowed multiple instances per project without interrupting development.
Hierarchical file naming conventions (e.g., PROJECT.USER.FILENAME).
Included spooling capabilities absent in DOS/360.
Support for sub-tasks enabling multiprogramming within individual jobs.

A practical installation of OS/360 demanded at least 256 KB of memory—a common limitation during the 1960s.

MFT

During the installation of MFT, users specified up to four fixed memory partitions to enable concurrent program execution. With the release of MFT Version II, this capacity expanded to allow as many as 52 partitions.

MVT

Compared to MFT, MVT was more extensive and intricate, tailored for the highest-performance System/360 processors. It managed all memory not reserved for the operating system as a unified pool, assigning contiguous "regions" to multiple programs running simultaneously. This method offered greater flexibility and efficiency than MFT's fixed partitions but was susceptible to fragmentation, where free memory became divided into unusable segments despite an adequate total amount.

The Time Sharing Option (TSO) was introduced for MVT in 1971, gaining popularity among developers by providing tools such as an editor, debuggers for System/360 programming languages, and batch job submission with progress updates. TSO utilized TCAM (Telecommunications Access Method) for terminal communication, which replaced the earlier QTAM. Although IBM designed TCAM as a universal data communication method, its primary use was for TSO before being mostly supplanted by VTAM starting in the late 1970s.

TP monitors

System/360 hardware and its operating systems were optimized for executing lengthy batch processing workloads but were not well-suited for handling high volumes of transaction processing, which involves processing thousands of brief transactions daily. To meet this demand, IBM introduced IMS in 1968 as a transaction processing solution for OS/360 and related systems. The following year, IBM released CICS, a more straightforward transaction processing system also compatible with DOS/360 and its successors.

These solutions, commonly referred to as "TP (teleprocessing) monitors," functioned as application-level programs that managed other applications rather than being part of the OS itself. Throughout the 1970s and 1980s, various third-party TP monitors—such as COM-PLETE, DATACOM/DC, ENVIRON/1, INTERCOMM, SHADOW II, TASK/MASTER, and WESTI—competed with CICS. Nevertheless, IBM consistently improved CICS, leading most clients to prefer it over competing products.

Special systems for airlines

In the 1950s, airline expansion faced limitations due to manual reservation systems. In 1957, IBM collaborated with American Airlines to create SABRE, an automated reservations platform. The pilot system debuted in 1960 and achieved full booking automation by 1964 using IBM 7090 mainframes. Subsequently, IBM developed a standardized reservation solution named PARS designed for System/360 computers.

Initially, SABRE and early PARS versions integrated both application logic and operating system components. By 1968, IBM separated these into PARS (the application layer) and ACP (the OS). ACP evolved into ACP/TPF and later became known as TPF, which extended beyond airline use cases to support high-volume online transaction processing. The current version is called z/TPF.

IBM created ACP because mid-1960s standard operating systems (DOS/360, OS/360) were oriented toward batch jobs and lacked the responsiveness needed for rapid transaction handling. Even transaction monitors like IMS and CICS could not meet the performance requirements imposed by thousands of agents making airline reservations simultaneously.

The final freely distributed ACP release was version 9.2, provided on a single mini-reel accompanied by comprehensive documentation; it supported IBM 3340 disk drives to enable full functionality. Although originally intended for financial applications such as MasterCard processing, ACP had matured into a versatile OS suitable for airline reservation systems.

ACP included a hypervisor component known as CHYR that allowed virtualized guest operating systems (commonly VS1 or VS2) to run concurrently. This capability facilitated simultaneous program development or file maintenance alongside live online operations. Certain production workloads—including potentially IMS databases—operated under VS2 through this hypervisor feature.

System/360 Model 20

Although the Model 20 belonged to the System/360 series because of its peripheral compatibility, it was a 16-bit system and lacked full program compatibility with other System/360 models. IBM Germany created three distinct operating systems tailored to various Model 20 setups: DPS for disk-based systems requiring at least 12 KB of memory, TPS for tape-based configurations needing a minimum of 8 KB, and CPS designed for punched-card environments with at least 4 KB memory. These operating systems did not have successors since IBM launched the System/3 range in 1969, which featured architecture and peripherals different from mainframes.

System/360 Model 44

The 360/44 processor utilized System/360 peripherals but incorporated a modified instruction set optimized for scientific calculations involving floating point operations, such as those used in geology or meteorology. Due to this specialized purpose, the 360/44 ran its own operating system, PS/44. An optional System/360 emulator could operate within hidden storage to provide missing instructions necessary for OS/360 compatibility. Neither the 360/44 nor PS/44 had direct successors.

System/370 and virtual memory operating systems

Introduced in 1970, the System/370 delivered approximately four times the processing speed of similarly priced System/360 processors. In 1972, IBM unveiled "System/370 Advanced Functions," which introduced virtual memory capabilities to both new and existing System/370 models. This advancement was accompanied by commitments to develop enhanced operating systems supporting virtual memory.

Most newly developed operating systems appended "/VS" ("Virtual Storage") to their names, deliberately avoiding the term "virtual memory" due to sensitivities around the word "memory." Except for z/TPF, all contemporary IBM mainframe operating systems trace their lineage back to those introduced with the "System/370 Advanced Functions." Notably, z/TPF originated from the ACP, initially created for high-volume airline reservation processing.

DOS/VS

DOS/VS followed DOS/360, incorporating virtual memory alongside improvements such as:

Support for five memory partitions (later expanded to seven).
A relocating loader that removed the need to maintain separate link-edited program copies for each partition.
An enhanced spooling system known as POWER/VS.

During the 1980s, DOS/VS evolved into DOS/VSE and VSE/SP, later progressing to VSE/ESA in 1991 and ultimately z/VSE in 2005.

OS/VS1

Replacing MFT, OS/VS1 introduced virtual memory support. IBM made minor updates until halting development in 1984. OS/VS1 and TSS/370 remain unique among IBM System/370 operating systems as they lack modern descendants.

The Special Real Time Operating System (SRTOS), available via Programming RPQ Z06751, is a variant of OS/VS1 designed for real-time applications, particularly in sectors such as electric utilities and oil refining.

OS/VS2 and MVS

OS/VS2 Release 1 (SVS) replaced MVT, adding virtual memory while preserving much of its original structure.

In 1974, IBM introduced OS/VS2 Release 2—a comprehensive redesign supporting multiple virtual address spaces—allowing applications to utilize overlapping virtual addresses mapped to separate real memory locations. This version became known as "MVS" (Multiple Virtual Storages), whereas the initial OS/VS2 was termed "SVS" (Single Virtual Storage). IBM continued using these designations in later releases.

Significant features of MVS include mandatory use of a VSAM catalog as the primary catalog, support for "tightly-coupled multiprocessing", and a System Resources Manager (later called Workload Manager) that optimizes workload distribution without compromising high-priority job performance.

IBM issued several MVS enhancements: MVS/SE, MVS/SP Version 1, MVS/XA (1981), MVS/ESA (1985), OS/390 (1996), culminating with the current z/OS (2001).

VM/370

VM/370 combines a virtual machine environment with the single-user Conversational Monitor System (CMS), supporting time-sharing by allowing each individual to operate CMS within their own virtual machine. It is a direct successor to CP/CMS. The virtual machine capability enabled simultaneous software testing alongside active production tasks, while CMS served extensively as a development platform.

The evolution of VM/370 included several enhancements such as VM/SEPP ("Systems Extensions Program Product"), VM/BSEPP ("Basic Systems Extensions Program Product"), VM/SP (System Product), VM/SP HPO ("High Performance Option"), VM/XA MA ("Extended Architecture Migration Aid"), VM/XA SF ("Extended Architecture System Facility"), VM/XA SP ("Extended Architecture System Product"), VM/ESA ("Enterprise Systems Architecture"), and eventually z/VM. IBM provided optional microcode assists designed to speed up the hypervisor emulation of privileged instructions used by guest operating systems. With the introduction of the 370/Extended Architecture, IBM added the Start Interpretive Execution (SIE) instruction, further improving the efficiency of the CP hypervisor.

External links