History of IBM mainframe operating systems

The history of operating systems running on IBM mainframes is a notable chapter of history of mainframe operating systems, because of IBM's long-standing position as the world's largest hardware supplier of mainframe computers.

Arguably the operating systems which IBM supplied to customers for use on its early mainframes have seldom been very innovative, except for the virtual machine systems beginning with CP67. But the company's well-known reputation for preferring proven technology has generally given potential users the confidence to adopt new IBM systems fairly quickly. IBM's current mainframe operating systems, z/OS, z/VM, z/VSE, and z/TPF, are backwards compatible successors to operating systems introduced in the 1960s, although of course they have been improved in many ways.

Both IBM-supplied operating systems and those supplied by others are discussed here, if notably used on IBM mainframes.

Before System/360

IBM was slow to introduce operating systems: General Motors produced General Motors OS in 1955 and GM-NAA I/O in 1956 for use on its own IBM computers; and in 1962 Burroughs Corporation released MCP and General Electric introduced GECOS, in both cases for use by their customers.cite web
url=http://www.computerhistory.org/timeline/?year=1956
title=Timeline of Computer History: 1956: Software
publisher=Computer History Museum
accessdate=2007-09-04] [http://www.oshistory.net/metadot/index.pl?id=2300;isa=Category;op=show OS History - MCP] ]

In fact the first operating systems for IBM computers were written by IBM customers who did not wish to have their very expensive machines ($2M in the mid-1950s!) sitting idle while operators set up jobs manually, and so they wanted a mechanism for maintaining a queue of jobs. [http://www.bozemanlug.org/talks/linux_history.html A Brief History of Linux] ]

The operating systems described below ran only on a few processor models and were suitable only for scientific and engineering calculations. Users with other IBM computers or other applications had to manage without operating systems. But one of IBM's smaller computers, the IBM 650, introduced a feature which later became part of OS/360: if processing was interrupted by a "random processing error" (hardware glitch), the machine could automatically resume from the last checkpoint instead of requiring the operators to restart the job manually from the beginning. [http://www-03.ibm.com/ibm/history/exhibits/650/650_intro.html IBM 650 Magnetic Drum Data Processing Machine] ]

From General Motors' GM-NAA I/O to IBSYS

General Motors' Research division produced GM-NAA I/O for its IBM 701 in 1956 (from a prototype, GM Operating System, developed in 1955), and updated it for the 701's successor. In 1960 the IBM user association SHARE took it over and produced an updated version, SHARE Operating System.

Finally IBM took over the project and supplied an enhanced version called IBSYS with the IBM 7090 and IBM 7094 computers. IBSYS required 8 tape drives (fewer if the system had one or more disk drives). Its main components were: a card-based Job Control language, which was the main user interface; compilers for FORTRAN and COBOL; an assembler; and various utilities including a sort program. [http://www.frobenius.com/ibsys.htm IBM 7090/94 IBSYS Operating System] ] Cite journal
author=Gray, G.
date=1999
title=EXEC II
periodical=Unisys History Newsletter
volume=1
issue=3
url=http://www.cc.gatech.edu/~randy/folklore/v1n3.html]

In 1958 the University of Michigan Executive System adapted GM-NAA I/O to produce UMES, which was better-suited to the large number of small jobs created by students. UMES was used until 1967, when it was replaced by the MTS timesharing system. [cite journal
year = 2001
month = Jan-Mar
title =A Career Interview with Bernie Galler
journal =IEEE Annals of the History of Computing
volume = 23
issue = 1
pages = 22–33
url=http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/an/&toc=comp/mags/an/2001/01/a1toc.xml&DOI=10.1109/MAHC.2001.10001
doi =10.1109/85.910847 ]

BESYS

Bell Labs produced BESYS (sometimes referred to as BELLMON) and used it until the mid-1960s. Bell also made it available to others without charge or formal technical support.Cite journal
date=Jan 1985
title=Putting Unix in Perspective
periodical=Unix Review
volume=1
issue=3
url=http://www.bozemanlug.org/talks/linux_history.html
author=Vyssotsky, V. and Pierce, E.]

FORTRAN Monitor System

Before IBSYS, IBM produced for its IBM 709, 7090 and 7094 computers a tape-based operating system whose sole purpose was to compile FORTRAN programs - in fact FMS and the FORTRAN compiler were on the same tape. [ [http://www.idinews.com/Backus.html Reminiscences of Fortran] ] Cite journal
date=Jan-Mar, 1984
title=FORTRAN Anecdotes
periodical=IEEE Annals of the History of Computing
volume=6
issue=1
pages=59–64
url=http://millosh.wordpress.com/2007/09/07/the-worlds-first-computer-operating-system-implemented-at-general-motors-research-labs-in-warren-michigan-in-1955/]

Early timesharing and virtual machine systems

:"For explanation of timesharing, virtual memory or virtual machines, see the Technical notes near the end of this article."

MIT's Fernando Corbató produced the first experimental timesharing systems, such as CTSS, from 1957 to the early 1960s, using slightly modified IBM 704 and IBM 7090 mainframes; these systems were based on a proposal by John McCarthy.John McCarthy, " [http://www-formal.stanford.edu/jmc/history/timesharing/timesharing.html Reminiscences on the History of Time Sharing] " - describes the origins of timesharing] In the 1960s IBM's own laboratories created experimental timesharing systems, using standard mainframes with hardware and microcode modifications to support virtual memory: IBM M44/44X in the early 1960s; CP-40 from 1964 to 1967; CP-67 from 1967 to 1972. The company even released CP-67 without warranty or technical support to several large customers from 1968 to 1972. CP-40 and CP-67 used modified System/360 CPUs, but the M44/44X was based on the IBM 7044, an earlier generation of CPU which was very different internally.R. J. Creasy, [http://www.research.ibm.com/journal/rd/255/ibmrd2505M.pdf "The origin of the VM/370 time-sharing system"] , "IBM Journal of Research & Development", Vol. 25, No. 5 (September 1981), pp. 483–90, PDF] Peter J. Denning, "Performance Modeling: Experimental Computer Science at its Best", "Communications of the ACM", President's Letter (November 1981), available on-line at [http://cs.gmu.edu/cne/pjd/PUBS/ecs.pdf cs.gmu.edu] – a survey of research papers] Melinda Varian, "VM and the VM community, past present, and future," SHARE 89 Sessions 9059-9061, 1977; available online at [http://www.princeton.edu/~melinda/25paper.pdf www.princeton.edu/~melinda] - outstanding source for CP/CMS and VM history]

These experimental systems were too late to be incorporated into the System/360 series which IBM announced in 1964, but encouraged the company to add virtual memory and virtual machine capabilities to its System/370 mainframes and their operating systems in 1972:
*The M44/44X showed that a partial approach to virtual machines was not good enough, and that thrashing could severely reduce the speed of virtual memory systems. Thrashing is a condition in which the system runs very slowly because it spends a lot of its time shuffling virtual memory pages between physical memory and disk files.
*IBM learned from CP-40 and CP-67: how to make the thrashing problem negligible; that its other virtual memory and virtual machine technologies were sufficiently fast and reliable to be used in the high-volume commercial systems which were its core business. In particular IBM's David Sayre convinced the company that automated virtual memory management could consistently perform at least as well as the best programmer-designed overlay schemes. cite journal
authorlink = Peter J. Denning
last = Denning
first = Peter
title = Before Memory was Virtual
journal = In the Beginning: Recollections of Software Pioneers
year = 1997
url = http://citeseer.ist.psu.edu/denning97before.html ]

In 1968 a consulting firm called Computer Software Systems used the released version of CP-67 to set up a commercial timesharing service. The company's technical team included 2 recruits from MIT (see CTSS above), Dick Orenstein and Harold Feinleib. As it grew, the company renamed itself National CSS and modified the software to increase the number of paying users it could support until the system was sufficiently different to warrant a new name, VP/CSS. VP/CSS was the delivery mechanism for National CSS' services until the early 1980s, when it switched to IBM's VM/370 (see below).cite web | url = http://www.computerhistory.org/corphist/view.php?s=select&cid=4 | title = Company Details - National CSS | work = Computer History Museum | author = Luanne Johnson | date = December 23, 2004 | accessdate = 2007-01-30 ] cite book | author = Harold Feinleib | title = A technical history of National CSS | publisher = Computer History Museum | date = March 2005 | url = http://www.computerhistory.org/corphist/documents/doc-42ae226a5a4a1.pdf ]

Universities produced two other timesharing operating systems in the late 1960s and early 1970s:
*McGill University in Montreal started developing MUSIC/SP in 1969. MUSIC was enhanced several times and eventually supported text searches, web publishing and email as well as software development. The last official version was released in 1999. [http://webpages.mcgill.ca/staff/group3/dedwar1/web/msi/musicsp.htm McGill University - MUSIC/SP] ]
* MTS was developed in the early 1970s by a consortium of universities led by University of Michigan, and the last copy was in use until the mid-1990s. All versions ran on IBM mainframes which had virtual memory capability, starting with a 360/67. MTS was mainly oriented towards software development. [http://www.everything2.com/index.pl?node_id=1404097&lastnode_id=0 MTS History] by Dan Boulet for Everything2.com]

ystem/360 operating systems

Up to the early 1960s IBM's low-end and high-end systems were incompatible - programs could not easily be transferred from one to another, and the systems often used completely different peripherals (e.g. disk drives). [http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FT1.html Mainframe Family tree & chronology] ] IBM concluded that these factors were increasing its design and production costs for both hardware and software to a level that was unsustainable, and were reducing sales by deterring customers from upgrading. So in 1964 the company announced System/360, a new range of computers which all used the same peripherals and most of which could run the same programs.Chuck Boyer, [http://www-306.ibm.com/software/os/zseries/pdf/360Revolution_0406.pdf "The 360 Revolution"] ]

IBM originally intended that System/360 should have only one batch-oriented operating system, OS/360, and a timesharing operating system, TSS/360. There are at least two accounts of why IBM later decided it should also produce a simpler batch-oriented operating system, DOS/360: because it found that OS/360 would not fit into the limited memory available on the smaller System/360 models;cite journal
last = Johnston
date = April 1, 2005
title = VSE: A Look at the Past 40 Years
journal = z/Journal
issue = April/May 2005
publisher = Thomas Communications, Inc.
url = http://www.zjournal.com/index.cfm?section=article&aid=293 ] or because it realized that the development of OS/MFT and OS/MVT would take much longer than expected, and introduced DOS/360 as one of a series of stop-gaps to prevent System/360 hardware sales from collapsing - the others were BOS/360 (Basic Operating System, for the smallest machines) and TOS/360 (Tape Operating System, for machines with only tape drives).

System/360's operating systems were more complex than previous IBM operating systems for several reasons, including:Andrew S. Tanenbaum, [http://www.prenhall.com/divisions/esm/app/author_tanenbaum/custom/mos2e/ "History of Modern Operating Systems"] , Prentice Hall (2001)]
* They had to support multiprogramming, otherwise the faster CPUs in the range would have spent most of their time waiting for I/O operations (e.g. disk reads) to complete. This meant that the operating systems had to be the real masters of the systems, to provide whatever services the applications validly requested, and to handle crashes or misbehavior in one application without stopping others that were running at the same time.
*They had to support a much wider range of machine sizes. Memory ranged from 16KB to 1MB and processor speeds from a few thousand instructions per second to 500,000.
*System/360's operating systems had to support a wide range of application requirements, for example: some applications only needed to read through sequential files from start to finish; others needed fast, direct access to specific records in very large files; and a few applications spent nearly all their time doing calculations, with very little reading / writing of files.

This was one of the largest software projects anyone had attempted, and it soon ran into trouble, with huge time and cost over-runs and large numbers of bugs. So the company had to release a series of short-lived stop-gaps because:
*To develop and test the planned operating systems it needed to use System/360 hardware. So it first developed BPS (Basic Programming Support), which it used to develop the tools it needed for developing DOS/360 and OS/360 and the first versions of tools its would supply with these operating systems - compilers (FORTRAN and COBOL), utilities including Sort, and above all the Assembler it needed to build all the other software.
*Competitors took advantage of the delays to announce systems aimed at what they thought were the most vulnerable parts of IBM's market.

IBM released 4 stop-gap operating systems to prevent sales of System/360 from collapsing:
*BOS/360 (Basic Operating System), which loaded from a card reader and supported tape drives and a few disks. This system was supplied to beta test customers and may have been an early version of DOS/360.
*TOS/360, which was designed to provide an upgrade path for customers who had IBM 1401 computers with tape drives and no disks.
*DOS/360, which was built by the developers of BOS/360 and TOS/360 (IBM's small business computers division) and went on to become a mainstream operating system whose descendant z/VSE is still widely used.
*PCP (Primary Control Program), which was a very early version of OS/360 that didn't support multiprogramming.Citation
last=Auslander
first=M. A.
last2=Jaffe
first2=J. F.
year=1973
title=Functional structure of IBM virtual storage operating systemsPart I: Influences of dynamic address translation on operatingsystem technology
periodical=IBM Systems Journal
publisher=IBM
volume=4
url=http://www.research.ibm.com/journal/sj/124/ibmsj1204D.pdf]

TSS/360 was so late and unreliable that IBM cancelled it. By this time CP-67 was running well enough for IBM to offer it "without warranty" as a timesharing facility for a few large customers. [http://www.multicians.org/thvv/360-67.html The IBM 360/67 and CP/CMS] ]

The traumas of producing the System/360 operating systems gave a boost to the emerging discipline of software engineering, the attempt to apply scientific principles to the development of software and the management of software projects. Frederick P. Brooks, who was a senior project manager for the whole System/360 project and then was given specific responsibility for OS/360 (which was already long overdue), wrote an acclaimed book, "The Mythical Man-Month", based on the problems encountered and lessons learned during the project, two of which were:cite book
last= Brooks
first= F.P.
title= The Mythical Man-Month: Essays on Software Engineering
origyear= 1975
url= http://www.developerdotstar.com/mag/bookreviews/read_manmonth.html
year= 1995
publisher= Addison-Wesley Professional]
*Throwing additional resources (especially staff) at a struggling project quickly becomes unproductive or even counter-productive because of communication difficulties. This is the "Mythical Man-Month" syndrome which gave the book its title.
*The successor to a successful system often runs into difficulties because it gets overloaded with all the features people wished had been in the earlier system. Brooks called this the "second-system effect", and cited OS/360 as a very comprehensive example.

DOS/360

DOS/360 became the usual operating system for processors less than 256KB of memory. It had a good set of utility programs, an Assembler, and compilers for FORTRAN, COBOL and eventually PL/I. And it supported a useful range of file organizations with access methods to help in using them:
* Sequential data sets were normally read one record at a time from beginning to end.
* In indexed (ISAM) files a specified section of each record was defined as a key which could be used to look up specific records.
* In direct access (BDAM) files, the application program had to specify the physical location on the disk of the data it wanted to access. BDAM programming was not easy and most customers never used it themselves; but it was the fastest way to access data on disks and many software companies used it in their products, especially database management systems such as ADABAS, IDMS and IBM's DL/I.Sequential and ISAM files could store either fixed-length or variable-length records, and all types could occupy more than one disk volume.

DOS/360 also offered BTAM, a data communications facility which was primitive and hard to use by today's standards. But BTAM could communicate with almost any type of terminal, which was a big advantage at a time when there was hardly any standardization of communications protocols.

But DOS/360 had significant limitations compared with OS/360, which was used to control most larger System/360 machines:
*The first version could run only one program at a time. A later enhancement allowed 3 at the same time, in one of 3 "partitions" whose size was set by each customer when DOS/360 was installed.
*The JCL it used for submitting jobs was designed to be easy for the low-end machines to process, and as a result programmers did not find it easy to read or write.
*There was no spooling sub-system to improve the efficiency of punched card and printer use. In the late 1960s an independent software company started selling a spooler called GRASP.
*DOS/360 had no relocating loader, so users had to link edit a separate executable version of each program for each partition in which the program was likely to be run.
*Executable programs were stored in the Core Image Library, which did not reclaim space when programs were deleted or replaced by newer versions. When the Core Image Library became full, it had to be compressed by one of the utility programs, and this could halt development work for as much as half a day.
*Its application programming interface was different from that of OS/360. Programs written in high level languages such as COBOL needed small modifications before they could be used with OS/360 and Assembler programs needed larger changes.

IBM expected that DOS/360 users would soon upgrade to OS/360. But despite its limitations DOS/360 became the world's most widely-used operating system because: System/360 hardware sold very well; DOS/360 ran well on System/360 processors which medium-sized organizations could afford; and it was better than the "operating systems" these customers had before. As a result its descendant z/VSE is still widely-used today.Jerry Johnston, [http://www.zjournal.com/index.cfm?section=article&aid=293 "VSE: A Look at the Past 40 Years"] (2005)]

OS/360

OS/360 turned out to be not an operating system but a generic name for a group of operating systems which offered similar facilities. PCP was a stop-gap version which could run only one program at a time, but OS/MFT ("multiprogramming with fixed number of tasks") and OS/MVT ("multiprogramming with variable number of tasks") were used until at least the late 1970s, a good five years after their successors had been launched. [http://www.plex86.org/Computer_Folklore/The-midseventies-SHARE-survey.html The midseventies SHARE survey] by an IBM user group] It is unclear whether the division between OS/MFT and OS/MVT arose because MVT required too much memory to be usable on mid-range machines or because IBM needed to release a multiprogramming version of OS (MFT) as soon as possible.

OS/MFT and OS/MVT had different approaches to managing memory (see below), but provided very similar facilities:
*The same application programming interface (API), so application progams could be transferred betwwen MFT and MVT without even needing re-compilation.
*The same JCL, which was more flexible and easier to use than that of DOS/360.
*The same facilities (access methods) as DOS/360 for reading and writing files (sequential, indexed and direct) and for data communications (BTAM).
*An additional file structure, partitioned, and access method (BPAM), which was mainly used for managing program libraries. Although partitioned files needed to be compressed to reclaim free space, this seldom halted development work as it did with DOS/360's Core Image Library, because MFT and MVT allowed an indefinite number of partitioned files and each project generally had at least one.
*A file naming system which allowed files to be managed as hierarchies, e.g. "PROJECT.USER.FILENAME".
*A spooling facility (which DOS/360 lacked).
*Applications could create sub-tasks, which allowed multiprogramming within the one job.

Experience indicated that it was not advisable to install OS/MFT on systems with less than 256KB of memory, which was a lot in the 1960s.Ray Saunders, [http://www.os390-mvs.freesurf.fr/mvs360.htm "MVS... And Before OS/360 ?"] ]

OS/MFT

When installing MFT, customers would specify up to five "partitions", areas of memory with fixed boundaries, in which application programs could be run simultaneously.

OS/MVT

OS/MVT was considerably larger and more complex than MFT and therefore was used on the most powerful System/360 CPUs. It treated all memory not used by the operating system as a single pool from which contiguous "regions" could be allocated as required by an indefinite number of simultaneous application programs. This scheme was more flexible than MFT's and in principle used memory more efficiently, but was liable to fragmentation - after a while one could find that, although there was enough spare memory in total to run a program, it was divided into separate chunks none of which was large enough.

Shortly after the release of MVT, Time Sharing Option (TSO) was added. TSO became widely used for program development because it provided: an editor; the ability to submit batch jobs, be notified of their completion and view the results without waiting for printed reports; debuggers for some of the programming languages used on System/360. TSO communicated with terminals by using TCAM (Telecommunications Access Method). TCAM's name suggests that IBM hoped it would become the standard access method for data communications, but in fact TCAM was used almost entirely for TSO and was largely superseded by VTAM from the late 1970s onwards.

TP monitors

System/360's hardware and operating systems were designed for processing batch jobs which in extreme cases might run for hours. As a result they were unsuitable for transaction processing, in which there are thousands of units of work per day and each takes between 30 seconds and a very few minutes. In 1968 IBM released IMS to handle transaction processing, and in 1969 it released CICS, a simpler transaction server which a group of IBM's staff had developed for a customer. IMS was only available for OS/360 and its successors, but CICS was also available for DOS/360 and its successors. [http://www.research.ibm.com/journal/sj/374/blackman.html Technical Note - IMS celebrates thirty years as an IBM product] ] [http://www-306.ibm.com/software/htp/cics/35/60s/ CICS: 35 Years - 1960s] ] For many years this type of product was known as a "TP (teleprocessing) monitor". Strictly speaking TP monitors were not operating system components but application programs which managed other application programs. In the 1970s and 1980s several third-party TP monitors competed with CICS (notably Taskmaster, Shadow and Intercomm), but IBM gradually improved CICS to the point where most customers abandoned the alternatives. [ cite web | url=http://documentation.softwareag.com/adabas/ada744mfr/adamf/operator/linkapp.htm | title=Linking Applications to Adabas | accessdate=2008-07-08 lists the major 1970s-1980s TP monitors] [cite journal | title=Metier the model, but few followed - UK software industry | author=Hugo, I. | date=Nov 15, 1989 | periodical=Software Magazine | url=http://findarticles.com/p/articles/mi_m0SMG/is_n14_v9/ai_7951050 | accessdate=2008-07-08 ]

Special systems for airlines

In the 1950s airlines were expanding rapidly but this growth was held back by the difficulty of handling thousands of bookings manually (using card files). In 1957 IBM signed a development contract with American Airlines for the development of a computerized reservations system, which became known as SABRE. The first experimental system went live in 1960 and the system took over all booking functions in 1964 - in both cases using IBM 7090 mainframes. In the early 1960s IBM undertook similar projects for other airlines, and soon decided to produce a single standard booking system, PARS, to run on System/360 computers.

In SABRE and early versions of PARS there was no separation between the application and operating system components of the software, but in 1968 IBM divided it into PARS (application) and ACP (operating system). Later versions of ACP were named ACP / TPF and then TPF (Transaction Processing Facility) as non-airline businesses adopted this operating system for handling large volumes of online transactions. The latest version is z/TPF.

IBM developed ACP and its successors because: in the mid-1960s IBM's standard operating systems (DOS/360 and OS/360) were batch-oriented and could not handle large numbers of short transactions quickly enough; even its transaction monitors IMS and CICS, which run under the control of standard general-purpose operating systems, are not fast enough for handling reservations on hundreds of flights from thousands of travel agents.

System/360 Model 20

This machine was labelled as part of the System/360 range because it could be connected to the same peripherals, but it was not program-compatible with other members of the System/360 range. Three operating systems were developed by IBM's labs in Germany, for different 360/20 configurations; with disks (minimum memory required: 12KB); no disk but with tapes (minimum memory required: 8KB); and punched-card-based (minimum memory required: 4KB). [http://www-05.ibm.com/de/entwicklung/history/menues_en/menue_60.html History of IBM Deutschland Entwicklung GmbH - 1960s] ] These had no direct successors since IBM introduced the System/3 range of small business computers in 1969 and System/3 had a different internal design from the 360/20 and different peripherals from IBM's mainframes.

System/360 Model 44

This was another processor which used the System/360 peripherals but had a different internal design. The 360/44 was designed for scientific computation using floating point numbers, such as geological or meteorological analyses. Because of the internal differences and the specialized type of work for which it was designed, the 360/44 had its own operating system, PS/44. [http://www.beagle-ears.com/lars/engineer/comphist/model360.htm IBM 360/370/3090/390 Model Numbers] ] The 360/44 and PS/44 had no direct successors.

ystem/370 and virtual memory operating systems

When System/370 was announced in 1970 it offered essentially the same facilities as System/360 but with about 4 times the processor speeds of similarly-priced System/360 CPUs. cite web
url=http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PR370.html
title=System/370 Announcement
date=June 30, 1970
publisher=IBM] Then in 1972 IBM announced "System/370 Advanced Functions", of which the main item was that future sales of System/370 would include virtual memory capability and this could also be retro-fitted to existing System/370 CPUs. Hence IBM also committed to delivering enhanced operating systems which could support the use of virtual memory. cite web
url=http://www-03.ibm.com/ibm/history/exhibits/dpd50/dpd50_chronology4.html
title=DPD chronology (1970-1974)
publisher=IBM DPD = Data Processing Division, which was responsible for IBM's medium and large systems.] cite book
title=IBM's 360 and Early 370 Systems
authors=Pugh, E.W., Johnson, L.R. and Palmer, J.H.
publisher=MIT Press
date=1991
isbn=0262161230
url=http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=8159]

Most of the new operating systems were distinguished from their predecessors by the presence of "/VS" in their names. "VS" stands for "Virtual Storage" - IBM avoided the term "memory", allegedly because it might be interpreted to imply that their computers could forget things.

All of today's IBM mainframe operating systems except z/TPF are descendants of those included in the "System/370 Advanced Functions" announcement - z/TPF is a descendant of ACP, the system which IBM initially developed to support high-volume airline reservations applications.

DOS/VS

DOS/VS was the successor to DOS/360. In addition to virtual memory DOS/VS provided other enhancements:
*5 memory partitions instead of 3. Later releases increased this to 7.
*A relocating loader, so that it was no longer necessary to link-edit a separate copy of each program for each partition in which it was to run.
*An improved spooling component, POWER/VS.

DOS/VS was followed by significant upgrades: DOS/VSE and VSE/SP (1980s), VSE/ESA (1991), and z/VSE (2005). [http://www-03.ibm.com/servers/eserver/zseries/zvse/about/history1980s.html About VSE - 1980s] ] [http://www-03.ibm.com/servers/eserver/zseries/zvse/about/history1990s.html About VSE - 1990s] ]

OS/VS1

OS/VS1 was the successor to OS/MFT, and offered identical facilities apart from the addition of virtual memory. IBM released fairly minor enhancements of OS/VS1 until 1983, and in 1984 announced that there would be no more. OS/VS1 is the only System/370 operating system which does not have a modern descendant.

OS/VS2 and MVS

OS/VS2 was initially just OS/MVT plus virtual memory. But in 1974 IBM released what it described as OS/VS2 release 2 but which was really a new operating system which was upwards-compatible with the earlier OS/VS2. The new system was a complete rewrite and its most noticeable feature was that it supported multiple virtual address spaces - different applications thought they were using the same range of virtual addresses, but the new system's virtual memory facilities mapped these to different ranges of real memory addresses. As a result the new system rapidly became known as "MVS" (Multiple Virtual Storages), the original OS/VS2 became known as "SVS" (Single Virtual Storage). IBM itself accepted this terminology and labelled MVS's successors "MVS/...". [http://www-03.ibm.com/ibm/history/exhibits/3033/3033_TR01.html 3033 Technical press release] ]

The other distinctive features of MVS were: its main catalog "had" to be a VSAM catalog; it supported "tightly-coupled multiprocessing" (2 or more CPUs share the same memory and copy of the operating system); it included a System Resources Manager (renamed Workload Manager in later versions) which allowed users to load additional work on to the system without reducing the performance of high-priority jobs.

IBM has released several MVS upgrades: MVS/XA (1981), MVS/ESA (1985), OS/390 (1996) and currently z/OS (2001). [http://www.operating-system.org/betriebssystem/_english/bs-mvs.htm MVS, OS/390, z/OS operating system] ]

VM/370

VM/370 combined a virtual machine facility with a single-user system called Conversational Monitor System (CMS); this combination provided time-sharing by allowing each user to run a copy of CMS on his / her own virtual machine. This combination was a direct descendant of CP/CMS.Citation
last=Creasy
first=R. J.
title=The Origin of the VM/370 Time-Sharing System
journal=IBM Journal of Research and Development
volume=25
issue=5
year=1981
pages=483
url=http://domino.watson.ibm.com/tchjr/journalindex.nsf/0/d6b9939ef2f3540b85256bfa0067f4d6 ] The virtual machine facility was often used for testing new software while normal production work continued on another virtual machine, and the CMS timesharing system was widely used for program development.Citation
last=Seawright
first=L. H.
last2=MacKinnon
first2=R. A.
title=VM/370—A study of multiplicity and usefulness
journal=IBM Journal of Research and Development
volume=18
issue=1
year=1979
pages=4
url=http://domino.watson.ibm.com/tchjr/journalindex.nsf/0/d6b9939ef2f3540b85256bfa0067f4d6 ]

VM/370 was followed by a series of upgrades: VM/ESA, VM/SEPP, VM/BSEPP, VM/SP, VM/HPO, VMXA/SF, VMXA/SP and z/VM. IBM also produced optional microcode assists for VM and successors, to speed up the hypervisor's emulation of privileged instructions (those which only operating systems can use) on behalf of "guest" operating systems.cite journal
author = Osisek, D.L., Jackson, K.M., and Gum, P.H.
date =
year = 1991
month = March
title = ESA/390 interpretive-execution architecture, foundation for VM/ESA - technical
journal = IBM Systems Journal
url = http://findarticles.com/p/articles/mi_m0ISJ/is_n1_v30/ai_10540516/pg_2 ]

Technical notes

Time-sharing

Time-sharing (or timesharing) is based on the idea that computers are much faster than humans, so while one human user is reading what a computer has just displayed on a screen the computer can do some useful work for another user. Large time-sharing systems can have hundreds or even thousands of simultaneous users, and the memory required by their programs and data generally adds up to much more than the physical memory attached to the computer. Time-sharing systems solve this problem by various combinations of:
*virtual memory, described below.
*swapping, in other words while the computer is waiting for a response from one user it saves that user's programs and data on a disk, and reads it all back into its memory when the user sends a response. Swapping does not require virtual memory and was implemented before virtual memory. It transfers "all" of a user's programs and data between memory and disk, and is mainly driven by user's responses to information displayed by the system.

Virtual memory

Virtual memory is a technique by which programs are made to work as if they are using large contiguous areas of memory, but their code and data may be scattered over several areas of the computer's physical memory, and parts may even be saved on a disk until needed. In technical terms, the program is only aware of virtual addresses, not real ones. "Virtual memory" can also mean "the full range of virtual addresses".

The main components of a virtual memory system are:
*Page tables, which tell the hardware and operating system where code and data at all blocks of virtual memory (range of virtual addresses) are stored - either in various areas of real physical memory ( RAM) or on disk.
*Dynamic address translation components ("DAT box") in the CPU, which use the page tables to find out where the contents of a virtual address are really stored. If the contents of the virtual address are currently in real memory, the DAT box tells the rest of the CPU which real address to use. If the contents of the virtual address are "not" in in real memory, the DAT box generates an interrupt (internal signal) which calls the paging supervisor into action.
*The paging supervisor (part of the operating system) searches the disk for the contents of the virtual address, reads them into real physical memory, updates the page tables to reflect the new location of the virtual address and finally tells the DAT box to start the search again. When the system is working fairly hard, all of the real physical memory is already in use and the paging supervisor must first save an area of real physical memory to disk and update the page table to say that the associated virtual addresses are no longer in real physical memory but saved on disk. Paging supervisors generally save and overwrite areas of real physical memory which have not been used recently, assuming that these will be the areas which are used least often. So every time the DAT box matches a virtual address with a real physical memory address, it must put a time-stamp in the page table entry for that virtual address.

Virtual machine

Virtual machine techniques enable several operating systems ("guest" operating systems) or other software to run on the same computer so that each thinks it has a whole computer to itself, and each of these simulated whole computers is called a "virtual machine". The operating system which really controls the computer is usually called a hypervisor. Two of the major components of the hypervisor are:
*Virtual memory management. Each virtual machine appears to have a complete range of addresses from 0 to some large number, and virtual memory techniques prevent different virtual machines from confusing each other.
*Simulating "privileged" functions on behalf of the "guest" operating systems. "Privileged" functions are those which enable programs to take over all or or at least large parts of the computer, and usually operating systems immediately terminate any other program which tries to use them. But "guest" operating systems think they are entitled to use these functions, so the hypervisor detects their attempts to do so and runs the privileged functions on their behalf, using virtual memory techniques to prevent them from corrupting memory areas used by other "guest" operating systems.

ee also

* IBM mainframe
* History of operating systems
* Operating systems timeline

References