Jump to content

OS/360 and successors

From Alfawiki
OS/360
Company typeOperating system
IndustryComputer software
Founded1964
FounderIBM
ProductsBatch processing operating system for IBM System/360
OwnerIBM

OS/360, formally known as the IBM System/360 Operating System, is a batch processing operating system developed by IBM for the 1964 System/360 mainframe computer, now discontinued. Its design drew upon earlier IBM software such as IBSYS/IBJOB and the PR155 Operating System used on the IBM 1410/IBM 7010. Notably, OS/360 was among the earliest operating systems to mandate hardware equipped with at least one direct access storage device.

While OS/360 itself is no longer supported, its lineage continues through successors like the virtual storage MVS and the 64-bit z/OS, which still provide compatibility at the application level.

Overview

IBM released three distinct levels of OS/360, all derived from identical tape sources and sharing the majority of their codebase. These levels were later renamed following design revisions:

  • Single Sequential Scheduler (SSS)
    • Option 1 / Primary Control Program (PCP)
  • Multiple Sequential Schedulers (MSS)
    • Option 2 / Multiprogramming with a Fixed number of Tasks (MFT) / MFT II
  • Multiple Priority Schedulers (MPS)
    • Option 4 / VMS[NB 1] / Multiprogramming with a Variable number of Tasks (MVT) / Model 65 Multiprocessing (M65MP)

End users frequently referred to these systems informally as "Big OS" or "OS/MFT," though such terminology was never officially adopted by IBM.

Distribution of OS/360 was conducted via tape libraries intended for installation restoration onto DASD during system generation. Optional source code tapes were made available to permit site-specific modifications of modules typically delivered only as object code. Additionally, microfiche containing assembly listings and service updates were provided.[NB 2] Over time, IBM transitioned to an Object Code Only (OCO) policy for its licensed software products.

Another prominent System/360 operating system was DOS/360.

OS/360 has entered the public domain and can be freely downloaded. Beyond operation on original System/360 hardware, it can be run using the free Hercules emulator, which supports most UNIX-based platforms such as Linux, Solaris, and macOS, along with Windows. Preconfigured turnkey OS/360 21.8 installations are also distributed on CDs for straightforward deployment on Hercules.

Origin

IBM's original intention for System/360 was to support a single batch-oriented operating system, OS/360, capable of running on machines with memory as limited as 32 KiB. However, OS/360 actually required a minimum of 44 KiB, and IBM planned a separate timesharing system, TSS/360, specifically for the System/360 Model 67. Due to the extensive size of OS/360’s code—approximately 1.5 million instructions—and slower than expected development progress, IBM created additional simpler batch-oriented operating systems to accommodate smaller models.

To promote System/360 hardware sales during this period, IBM introduced interim software solutions: Basic Programming Support (BPS), Basic Operating System (BOS/360) designed for machines with 8K memory, Tape Operating System (TOS/360) targeting systems equipped with tape drives and at least 16K memory, and Disk Operating System (DOS/360), which gained widespread adoption and evolved into what is now known as VSEn.

IBM launched three versions of OS/360: PCP (Primary Control Program), a single-job interim release in 1966; MFT (Multiprogramming with Fixed Tasks) aimed at mid-range systems; and MVT (Multiprogramming with Variable Tasks) tailored for high-end machines. Even after newer operating systems appeared, MFT and MVT continued in use into the early 1980s. The distinction between MFT and MVT stemmed from limitations in storage management and task scheduling. Initially described as configurations within OS/360, IBM later classified them as separate versions.

Although originally implemented entirely in assembly language, OS/360 later incorporated Basic Systems Language (BSL), a subset derived from PL/I, notably utilized in TSO Release 20.

The timesharing system TSS/360 experienced delays and reliability issues that led IBM to discontinue it. Instead, three releases of TSS/370 were offered as a Program Request for Price Quotation (PRPQ). By that time, CP-67 had matured sufficiently for IBM to offer it without warranty as a timesharing option to select large customers.

OS/360 Versions

The trio of OS/360 configurations—PCP, MFT, and MVT—provided comparable capabilities, allowing applications to be transferred among them with minimal adjustments. The majority of IBM Program Products, application software, and utilities operated across all three variants. In this context, PCP, MFT, and MVT are treated as updated designations for the original SSS, MSS, and MPS, incorporating certain architectural modifications. The M65MP variant is not separately distinguished from MVT here.

Formally, PCP, MFT, and MVT represent install-time configuration choices for OS/360's Nucleus and Scheduler components rather than entirely distinct operating systems. Nevertheless, due to their differing operational characteristics and memory requirements, they are frequently regarded as separate systems: "early OS/360," "OS/MFT," and "OS/MVT." The key distinction between MFT and MVT lies in memory management: MFT utilizes a predetermined number of fixed memory partitions defined during system generation (SysGen), with each partition dedicated to a single running application.

PCP

The Primary Control Program (PCP) was designed for machines with limited memory capacity, functioning similarly to MFT but employing only one partition. Although IBM advised against deploying OS/360 on systems with less than 128 KiB of memory, some limited production usage occurred on machines with as little as 48 KiB. IBM eventually phased out PCP in later OS/360 versions, concentrating development on MFT II and MVT configurations that demanded larger memory sizes.

In system-dependent macro expansions, PCP was also referred to as SYS=MIN.

MFT

Multiprogramming with a Fixed number of Tasks (MFT) acted as a transitional solution until the introduction of Multiprogramming with a Variable number of Tasks (MVT) in 1967. Due to initial reliability concerns with MVT, many users continued to rely on the more straightforward MFT. With the arrival of System/370 hardware supporting virtual memory in 1972, IBM advanced MFT II into OS/VS1, marking the final iteration in this series.

The first release of MFT shared significant codebase and design elements with PCP and offered support for up to four fixed partitions. Managing multiple partitions was complex; therefore, many installations employed Houston Automatic Spooling Priority (HASP) to simplify operations.

MFT Version II (MFT-II) integrated greater shared code from the Control Program and Scheduler components of MVT, enhancing flexibility and increasing the maximum number of partitions to 52. Subsequent improvements introduced sub-tasking capabilities that permitted dynamic task handling within fixed partitions.

Installing MFT on systems equipped with less than 256 KiB of memory was discouraged due to its substantial resource demands during that era.

Within system-dependent macro expansions, MFT was also identified as SYS=INT.

MVT

Multiprogramming with a Variable number of Tasks (MVT) represented the most sophisticated control program configuration among the three OS/360 options and was one of two maintained in the final releases. Intended for the largest System/360 models, it was initially designed in 1964 but only became generally available by 1967. Early implementations encountered difficulties; consequently, many users continued utilizing the simpler MFT for several years. IBM recommended against running MVT on systems with under 512 KiB of memory.

MVT managed all non-operating system memory as a unified pool, assigning contiguous regions to an unrestricted number of concurrent applications and system processes. This adaptable strategy aimed to optimize memory utilization beyond what MFT could achieve but introduced the risk of fragmentation—where free memory became divided into segments too small for program execution. Since System/360 lacked hardware support for memory relocation, compaction was not feasible. The Rollout/Rollin mechanism allowed jobs to be swapped out to secondary storage to release memory; however, swapped-out jobs had to be restored at their original memory addresses.

In release 20.1 from 1971, the Time Sharing Option (TSO) was incorporated into MVT. TSO gained significant traction among developers by providing features such as an editor, batch job submission with completion notification, and debugging tools tailored for System/360 programming languages. TSO utilized Telecommunications Access Method (TCAM) for communication—a protocol initially designed as a general data communications standard but primarily employed for TSO purposes. TCAM was later superseded by Virtual Telecommunications Access Method (VTAM) during the mid-to-late 1970s.

Within certain system-dependent macro invocations, MVT was also designated as SYS=VMS.

M65MP

The Model 65 Multiprocessing (M65MP) is a version of MVT designed to operate on the 360/65 in Multisystem mode. It employs traps triggered by the Set System Mask (SSM) instruction to coordinate disabled code execution between two processors. In terms of functionality, M65MP operates similarly to other MVT implementations.

The SYS=VMS keyword parameter encompassed both the M65MP and the single-processor MVT variants.

Common Characteristics

From an application standpoint, PCP, MFT, and MVT provide comparable features:

  • They share an identical application programming interface (API) and application binary interface (ABI), enabling seamless program migration between MFT and MVT without requiring changes or recompilation.
  • Batch job submission uses the same JCL, which offers greater flexibility than DOS/360 but is more intricate.
  • Uniform access methods are employed for file handling and data communication:
    • Sequential datasets are processed one record at a time using BSAM or QSAM, essential for devices like tape drives, card readers/punches, and printers.
    • Indexed files (ISAM) utilize keys to directly access specific records.
    • Direct access (BDAM) demands specifying either relative block numbers or physical locations on Direct-access storage device (DASD). Although complex, BDAM provided the fastest disk access available and was widely adopted by software vendors, particularly within database management systems such as ADABAS, IDMS, and IBM's DL/I. BDAM datasets are unblocked, with each logical record corresponding to a single physical record.
    • Partitioned datasets (BPAM) efficiently organize program libraries; having multiple partitioned datasets per project lessened space reclamation issues compared to the Core Image Library approach in DOS/360.
    • Generation Data Groups (GDGs) facilitated backup operations and flexible data management by treating multiple file versions as a unified sequential dataset.
    • Despite its rudimentary design, BTAM supported extensive terminal communication compatibility.
  • File naming conventions allowed hierarchical structures with up to eight characters per segment (e.g., PROJECT.USER.FILENAME), integrated with the system catalog (SYSCTLG) and Control Volumes (CVOLs) using 8-byte key entries.

Features Specific to MFT and MVT

Certain capabilities were exclusive to MFT and MVT but not present in PCP:

System/370 and Virtual Memory Operating Systems

Introduced in 1970, the System/370 matched the capabilities of System/360 but delivered roughly quadruple the processor performance at comparable cost. In 1972, IBM launched System/370 Advanced Functions, which incorporated virtual memory support—available both on new hardware models and as upgrades for existing CPUs. IBM also pledged to enhance its operating systems to fully leverage virtual memory technology.

OS/360

IBM offered a System/370-compatible option within the OS/360 SYSGEN process, which did not include DAT but incorporated:

  • Support for control registers
  • Advanced input/output functions
  • A dedicated System/370 Machine Check Handler
  • Basic timer facility capabilities

OS/VS1

OS/VS1, the successor to MFT, provided comparable functionality along with enhancements such as RES and virtual memory support. Initially, VSAM was released as a separate component before its integration into OS/VS1. IBM continued to release minor updates for OS/VS1 until 1983 and discontinued its development in 1984. Importantly, OS/VS1, together with AIX/370, AIX/ESA, DPPX, and TSS/370, does not have any modern operating system descendants within the System/370 family.

OS/VS2 SVS and MVS

The first release of OS/VS2 was essentially MVT enhanced by virtual memory and VSAM features. This version was later renamed OS/VS2 SVS (Single Virtual Storage) following the introduction of OS/VS2 Release 2, known as MVS (Multiple Virtual Storage). SVS functioned as an intermediary stage between MVT and MVS and is now primarily of historical significance.

In 1974, IBM launched OS/VS2 Release 2, a substantially new operating system backward-compatible with OS/VS2 Release 1. The Supervisor component underwent extensive rewriting in PL/S, a PL/I-based language tailored for implementing privileged instructions essential for system control. Performance-critical parts such as the OS Dispatcher and IOS remained programmed in an enhanced assembler language (IFOX00 Assembler).

MVS address spaces - global view
MVS (shared portion across all address spaces)
App 1 App 2 App 3
Shared virtual area (managed by MVS)
Individual application perspective
MVS
App 1
Shared virtual area

A major advancement was the introduction of multiple virtual address spaces, enabling applications to utilize identical virtual addresses that mapped to distinct physical memory locations. Each application's address space consisted of a shared operating system segment, a dedicated application segment (minimum size of 8MB), and a shared virtual segment for inter-process communication. This design resolved memory fragmentation challenges found in earlier systems and improved internal security measures. The system became widely recognized as "MVS," while the original OS/VS2 version was designated "SVS," terminology that IBM maintained for later releases.

MVS also introduced workload management capabilities that allowed users to define performance objectives for high-priority batch workloads, facilitating enhanced system throughput without compromising critical operations.

As IBM’s first mainstream System/370 operating system to support tightly coupled multiprocessing, MVS initially operated with two CPUs sharing memory and resources. This capability later expanded to support up to 12 CPUs on IBM mainframes and as many as 16 on Amdahl platforms. This multiprocessing architecture not only increased processing capacity but also enabled graceful degradation in the event of CPU failures, significantly improving overall system availability from mere hours to multiple years.

Originally, MVS included the job management subsystem JES2 (Job Entry Subsystem 2), which evolved from HASP (Houston Automatic Spooling Priority) and supported Remote Job Entry from offsite terminals. JES2 managed workload queues on single-CPU or tightly coupled multiprocessor configurations. In 1976, IBM released JES3, derived from ASP (Attached Support Processor), which centralized job queue management by allowing one CPU to oversee job distribution across several distinct processors. Prior to these, JES1 served as the job queue manager for OS/VS1.

VSAM

IBM created the Virtual Storage Access Method (VSAM) to succeed previous sequential, indexed, and direct access techniques with enhanced versions:

  • Entry-Sequenced Datasets (ESDS) merge characteristics of both sequential and direct access files, permitting data reading either sequentially or by specifying a particular offset.
  • Key-Sequenced Datasets (KSDS) represent a major advancement over IBM's ISAM by supporting secondary keys that may have duplicate values, enabling concatenated keys from non-adjacent fields, and minimizing performance degradation caused by overflow records. KSDS also decreases the likelihood of index corruption during update operations. An ISAM/VSAM Interface allows applications based on ISAM to utilize VSAM KSDS without requiring code modifications.
  • Relative Record Datasets (RRDS) serve as replacements for direct access (BDAM) datasets, providing access via relative record numbers but lacking support for variable-length records.

These VSAM dataset types form the foundation for IBM’s database management systems like IMS/VS and DB2, which commonly use ESDS for storing data and KSDS for indexing purposes.

Additionally, VSAM introduced an improved catalog mechanism that lets applications reference files by name without needing to know their physical disk locations. Prior to usage, VSAM datasets must be registered in a VSAM catalog; catalogs can also include non-VSAM datasets. The MVS Master Catalog is required to be a VSAM catalog. Initially, OS/360 employed CVOLs as catalogs; MVS later introduced a dedicated VSAM catalog structure, followed by Integrated Catalog Facility (ICF) catalogs. Due to Y2K concerns, IBM phased out CVOL and VSAM catalogs by the year 2000, leaving only ICF catalogs supported on z/OS.

SNA

IBM launched Systems Network Architecture (SNA) in 1974 to lower expenses related to managing extensive terminal networks by optimizing communication line utilization. SNA is exclusive to IBM’s virtual memory operating systems because its core mainframe networking component, VTAM, is available solely on these platforms.

Later MVS versions and enhancements

In 1977, IBM introduced MVS/System Extensions, a commercial program product designed to improve MVS's performance and expand its capabilities.

MVS derivatives continue running on successors of System/360 such as System/390 and zSeries, renamed respectively as OS/390 for System/390 and the 64-bit z/OS for zSeries.

Structure, interface and logic

This section addresses the MVT variant of OS/360; PCP and MFT are broadly similar with only minor distinctions. OS/VS1 and SVS share structural elements with MFT II and MVT. Although MVS preserves much of MVT’s architecture, it incorporates significant enhancements discussed separately. IBM refers to storage rather than memory terminology.

CPU allocation

Within OS/360, processors are allocated to tasks that resemble lightweight processes or threads. Each task maintains a Task Control Block (TCB) along with a stack of Request Blocks (RBs). Tasks are categorized as dispatchable or nondispatchable; the Dispatcher selects the highest priority dispatchable task whose current RB is not in a waiting state.

In MVS, processor assignment extends to Virtual Address Spaces (analogous to processes), Service Request Blocks (SRBs), and tasks within those address spaces. Every address space contains an Address Space Control Block (ASCB), together with queues managing SRBs and TCBs.

Storage arrangement

MVT storage organization following IPL and NIP
Content Area
Optional Resident BLDL section Common area Uppermost
Link Pack Area (LPA)
Master Scheduler zone
Job regions, MOUNT, started tasks, and TSO areas Dynamic area
System Queue Area (SQA) Fixed area
Nucleus Lowest

Within OS/360, all storage is accessible system-wide, although fetch protection restricts access to control blocks and inter-job boundaries.

The main storage structure for MVT is segmented into:

  • Fixed area located at the bottom:
    • Nucleus—loaded from , it contains interrupt handlers, control blocks, supervisor call routines, and both privileged and non-privileged callable code.
    • System Queue Area (SQA)—a shared memory region accessible to multiple jobs.
  • Private area in the center:
    • Dedicated to job regions (batch jobs initiated by the Initiator), interactive TSO sessions, Mount regions (triggered by operator MOUNT commands), and started tasks (invoked via operator START commands).
  • Common area positioned at the top:
    • Resident BLDL section—stores cached directory entries for faster access.
    • Master Scheduler region—includes the Master Scheduler and Communication task allocated through NIP.
    • Link Pack Area (LPA)—loads reentrant access method routines and other shared programs during IPL to be utilized by all executing jobs.

SVS storage arrangement

In SVS, the system area occupies both the upper and lower ends of virtual storage, with the Nucleus residing in Virtual=Real (V=R) memory. The private area features a Local System Queue Area (LSQA) dedicated to each region. The LPA is subdivided into:

Pageable Link Pack Area (PLPA)
Comprises all modules from SYS1.LPALIB; its backing page dataset remains persistent across IPLs unless the create LPA (CLPA) option is enabled.
Modified Link Pack Area (MLPA)
Holds modules specified in an IEALPAxx member of SYS1.PARMLIB, which replace PLPA modules during IPL.
Fixed Link Pack Area (FLPA)
Contains page-fixed modules defined in an IEAFIXxx member of SYS1.PARMLIB, substituting PLPA modules for the duration of the IPL.

MVS/370 Storage arrangement

Under MVS, all address spaces share the system area while maintaining their own distinct private areas. New components introduced include:

Common Storage Area (CSA)
A dynamic memory region allocated for sharing among all address spaces.
System Work Area (SWA)
Houses control blocks formerly located in SYS1.SYSJOBQE under OS/360 and SVS systems.

MVS/XA, MVS/ESA and OS/390 storage organization

Starting with MVS/XA, the system, private, and common storage areas are located below the 16 MiB threshold, while extended storage regions occupy the space between 16 MiB and 2 GiB.

z/OS storage organization

In z/OS, the storage structure closely mirrors that of MVS/XA, MVS/ESA, and OS/390; however, memory above the 2 GiB limit is handled by distinct services compared to those managing storage beneath this boundary.

IPL procedure

When operators initiate , the system issues a command to read 24 bytes from cylinder 0, track 0, record 1 into address 0. The bytes from positions 8 through 23 are then copied to the bootstrap record located at cylinder 0, track 0, record 2, which subsequently loads the IPL Loader. The IPL Loader carries out initial setup tasks, locates and relocates the Nucleus—placing the interrupt handler at address zero and positioning the Nucleus Initialization csect at the end for eventual removal.

The Nucleus Initialization Program (NIP) is responsible for initializing system components and starts by providing essential services itself before handing over control to standard OS services. For instance, it employs the macro to access Data Set Control Blocks (DSCBs) from the Volume Table of Contents (VTOC).

NIP reads configuration members from , which can be defaults, operator-defined, or parameter-driven entries. It then establishes a Master Schedule region within private storage and transfers execution to IEEVIPL to set up the Master Scheduler and Communication Task, thus finalizing system startup.

Job-like work units

Apart from batch jobs, OS/360 processes various types of work in a similar manner by interpreting JCL, allocating necessary regions and devices, and launching job-step programs. For batch jobs, the Reader/Interpreter handles JCL input from external sources; for , commands, and TSO sessions, the system produces JCL that invokes cataloged procedures.

API

OS/360 includes a Communications Vector Table (CVT) control block containing pointers to other control blocks and routines. Several OS/360 macro-instructions reference fields within the CVT and associated control blocks.

While some macros provide dsect mappings for certain control blocks, many rely on fixed offsets rather than mapping macros.

Service parameters are generally passed in register 1; some services use registers 0 and 1 or registers 0, 1, and 15.

Service macros are available in three variants:

Execute form
Executes functions using supplied parameter lists
List form
Creates predefined parameter lists for use with execute macros
Standard form
Generates necessary parameter lists and executes functions

Core services are implemented through SVC routines that preserve registers 2 through 14. Other services are accessible as direct subroutines with entry points stored in system control blocks; these require Register 13 to reference a save area and maintain registers 2–13. Typically, Register 15 holds return codes while registers 0 and 1 may carry additional output data.

Synchronization

OS/360 achieves serialization using Event Control Blocks (ECBs), which monitor events or hold waiting Request Blocks (RBs). The WAIT macro suspends tasks until designated events occur; conversely, the POST macro signals ECB completion by storing completion codes and updating waiting RBs to potentially dispatch tasks.

MVS introduces further synchronization mechanisms.

Serialization

In OS/360, resource access serialization is managed through the use of the ENQ and DEQ macros, which operate based on queue (qname) and resource (rname) identifiers. The ENQ macro causes tasks to wait until the requested resources become available, while the DEQ macro frees resources previously acquired via ENQ. It is not mandatory for DEQ invocations to release all resources at once, but they must eventually relinquish them.

The MVS operating system broadens the range of serialization capabilities beyond those in OS/360.

Operator consoles

OS/360 mandates at least one operator console, with two distinct support configurations:

Primary
This basic level supports a single primary console along with an optional secondary console serving as a backup.
Multiple Console Support (MCS)
MCS allows for one master console plus up to 31 subordinate consoles, each optionally paired with an alternate console for redundancy. It facilitates message logging either on secondary consoles or onto DASD-based system logs (SYSLOG). Additionally, MCS incorporates Device Independent Display Operator Console Support (DIDOCS), providing a standardized environment for CRT-based console displays.

Messages sent using Write To Operator (WTO) or Write To Operator with Reply (WTOR) include routing codes that enable selective message display on designated consoles. This feature is particularly useful for directing communications to specialized operators, such as tape librarians. For example, routing code 7 ensures that message content is recorded in the job's message log.

Messages also contain descriptors that govern their handling procedures.

One important command is , which responds solely to messages directed to the receiving console.

For graphical display terminals like 2250, 2260, and 3270, the CONTROL (K) command configures settings such as scrolling behavior.

Timeline

Presented below is a summary table of key OS/360 and its successor releases, outlining announcement dates, shipment periods, and end-of-support milestones pertinent to managing product lifecycles:

MFT/MVT/MVS releases
Order No. Announced Shipped Support
dropped 		Rel # Name
360S 1964-04 Operating System/360
1964-04 1965-11 1 Operating System/360 prerelease
Single Sequential Scheduler
1964-04 1966-11 OS/360 Multiple Sequential Scheduler
360S 1965-12 1966-03-31 1 Operating System/360
360S 1966-06 2 Operating System/360
360S 1966-08-18 1966-08 4/5 Operating System/360
360S 1966-04-29 1966-10 6 Operating System/360
MFT
360S 1966-12-07 8 Operating System/360
360S 1967-02 9.5 Operating System/360
360S 1967-05 11 Operating System/360
360S 1967-08-08 12 Operating System/360
MVT?
360S 1967-08 13 Operating System/360
MVT
360S 1968-01 14 Operating System/360
360S 1968-08-30 15/16 Operating System/360
MFT-II, VTOC positioning
360S 1969-03 17 Operating System/360
360S 1969-07 1969-09 18 Operating System/360
SMF for MVT
360S 1969-10 18.6 Operating System/360
1970-08-05 |19.1 |Operating System/360
SMF for MFT, MFT Attach, support for IBM models |
Operating System/360 |
Operating System/360<TSO> |
Operating System/360 |
Operating System/360 |
Operating System/360 |
Operating System/360 |
Operating System/360 |
Operating System/360 |

1972-08 |1973-|1 |Operating System/Virtual Storage 1 (OS/VS1) |

1972-08 |1972-|1 |Operating System/Virtual Storage 2 (OS/VS2) Single Virtual Storage (SVS) |

1972-08 |1974-|2 |Operating System/Virtual Storage 2 (OS/VS2) Multiple Virtual address Spaces (MVS) with JES2 |

1972-|1975-10 ||2 .1 OS/VS2 MVS with JES3 ||-

5752-VS2 3 OS/VS2 MVS with JES2 and JES3 -
5752-VS2 3.6 OS/VS2 MVS with JES2 and JES3 -

1976-11 ||||3.7 OS/VS2 MVS with JES2 and JES3 ||-

1979-| ||||3.8 OS/VS2 MVS with JES2 and JES3 ||-

5740-XE1 1 MVS/System Extensions (MVS/SE) -

1979-03 – 1979–08 ||||MVS/System Extensions (MVS/SE2) ||-

5740-XYS

1980–06 –1980–12 ||||MVS/System Product Version 1 JES2 (MVS/SP 1.1) ||-

5740-XYN

1980–06 –1980–12 ||||MVS/System Product Version 1 JES3 (MVS/SP 1.1) ||-

5740-XYS

1980–06 –1981–06 ||||MVS/System Product Version 1 JES2 (MVS/SP 1.2) ||-

5740-XYN

1980–06 –1981–06 ||||MVS/System Product Version 1 JES3 (MVS/SP 1.2) ||-

5740-XYS

1980–11 –1981–10 ||||MVS/System Product Version 1 JES2 (MVS/SP 1.3) ||-

5740-XYN

1980–11 –1981–10 ||||MVS/System Product Version 1 JES3 (MVS/SP 1.3) ||-

5740-XC6

1981–10 –1983–03 ||||MVS/System Product - JES2 Version 2 (MVS/XA) ||-

5740-XC6

1981–10 –1983–03 ||||MVS/System Product - JES3 Version 2 (MVS/XA) ||-

5685-001

1988–02 –1988–07 ||||MVS/System Product - JES2 Version 3 (MVS/ESA) ||-

5685-002

1988–02 –1988–07 ||||MVS/System Product - JES3 Version 3 (MVS/ESA) ||-

5685-047

1990–09–05 –1990–10–26 –1994–03–31 ||||MVS/ESA SP - JES2 Version 4 ||-

5685-047

1990–09–05 –1992–12–31 –1999–06–30 ||||MVS/ESA SP - JES2 Version 4 ||-

5685-047

1992–06–18 –1993–03–26 –1999–06–30 ||||MVS/ESA SP - JES2 Version 4 ||-

5685-048

1990–09 –1990–10 –1999–06–30 ||||MVS/ESA SP - JES3 Version 4 ||-

5655-068

1994–04–05 –1994–06–24 –2001–01–31 ||||MVS/ESA SP - JES2 Version 5 ||-

5655-068

1994–09–13 –1995–06–30 –2001–03–31 ||||MVS/ESA SP - JES2 Version 5 ||-

5655-069

1994–09–13 –1995--09--13 –2001--03--31 ||||MVS/ESA SP - JES3 Version 5 (versions corrected)||-

=5655--069= =1995--02--28= =1995--09--29= =2001--03--31= === === ===


See also

OS/360 manuals

DMMAC
DMSVC
DMSYS
INTRO
JCLREF
JCLUSER
LKED
MFT
MVT

| url ={http://bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC28-6720-5_MVT_Guide_Rel_21.7_Aug74.pdf} | series ={IBM Systems Reference Library} | publisher ={IBM} | access-date ={June 7, 2022} }}

SMF

| url ={http://bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC28-6712-7_OS_SMF_Rel_21.7_Apr73.pdf} | series ={IBM Systems Reference Library} | publisher ={IBM} | access-date ={June 7, 2022} }}

SUP

| url ={http://bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC28-6646-7_Supervisor_Services_and_Macro_Instructions_Rel_21.7_Sep74.pdf} | series ={IBM Systems Reference Library} | publisher ={IBM} | access-date ={June 7, 2022} }}

SYSCB

| url ={http://bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC28-6628-9_OS_System_Ctl_Blks_R21.7_Apr73.pdf} | series ={IBM Systems Reference Library} | publisher ={IBM} | access-date ={June 7, 2022} }}

SYSGEN

| url ={http://bitsavers.org/pdf/ibm/360/os/R21.8_Aug74/GC28-6554-13_OS_System_Generation_Release_21.8_Aug74.pdf} | series ={IBM Systems Reference Library} | publisher ={IBM} | access-date ={June 7, 2022} }}

SYSPG

| url ={http://bitsavers.org/pdf/ibm/360/os/R20.1_Mar71/GC28-6550-9_OS_System_Programmers_Guide_Rel_20.1_Jun71.pdf} | series ={IBM Systems Reference Library} | publisher ={IBM} | access-date ={June 7, 2022} }}

TSO

| url ={http://bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC28-5360-20_IBM_System_360_Operating_System_-_Time_Sharing_Option_Guide_OS_Rel_21.7_7th_ed_197304.pdf} | series ={IBM Systems Reference Library} | publisher ={IBM} | access-date ={June 7, 2022} }}

TSOCMD

OS/360 logic manuals

IOS 2nd ed
IOS
IPL
PCPJOB
MVTJOB
MVTSUP

Manuals

Books

  • Brooks, Jr., Frederick P. (1975). The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley. (Corrected reprint issued January 1982)
  • Binder, Robert V. (1985). Application Debugging: An MVS Abend Handbook for Cobol, Assembly, PL/I, and Fortran Programmers, Prentice-Hall.
  • Pugh, Emerson W.; Johnson, Lyle R.; Palmer, John H. (1991). IBM's 360 and Early 370 Systems, Cambridge: MIT Press. (pp. 291–345)

Articles

  • "The Development of the System/360 Mainframe Almost Bankrupted IBM", IEEE Spectrum, 2019-04-05

References in popular culture

External links


Cite error: <ref> tags exist for a group named "NB", but no corresponding <references group="NB"/> tag was found

Retrieved from "https://www.alfawiki.org/index.php?title=OS/360_and_successors&oldid=28170"