Multiple Virtual Storage, more commonly called MVS, was the most
commonly used operating system on the
mainframe computers. It was developed by IBM, but is unrelated to
IBM's other mainframe operating systems, e.g., VSE, VM, TPF.
First released in 1974,
MVS was extended by program products with new
names multiple times:
first to MVS/SE (MVS/System Extensions),[NB 1]
MVS/SP (MVS/System Product) Version 1,
MVS/XA (MVS/eXtended Architecture),
MVS/ESA (MVS/Enterprise Systems Architecture),
finally to z/OS (when 64-bit support was added with the zSeries
IBM added UNIX support (originally called OpenEdition MVS) in
MVS/SP V4.3 and has obtained
POSIX and UNIX™ certifications at
several different levels from IEEE,
X/Open and The Open Group. The MVS
core remains fundamentally the same operating system. By design,
programs written for
MVS run on z/OS without modification.
MVS as simply a new release of OS/VS2, but it
was, in fact a major rewrite.
OS/VS2 release 1 was an upgrade of
OS/360 MVT that retained most of the original code and, like MVT, was
mainly written in assembly language. The
MVS core was almost entirely
written in Assembler XF, although a few modules were written in PL/S,
but not the performance-sensitive ones, in particular not the
Input/Output Supervisor (IOS). IBM's use of "OS/VS2" emphasized
upwards compatibility: application programs that ran under MVT did not
even need recompiling to run under MVS. The same Job Control Language
files could be used unchanged; utilities and other non-core facilities
like TSO ran unchanged.
IBM and users almost unanimously called the
MVS from the start, and
IBM continued to use the term MVS
in the naming of later major versions such as MVS/XA.
1 Evolution of MVS
3 History and modernity
9 Closely related operating systems
10 See also
13 External links
Evolution of MVS
OS/360 MFT (Multitasking with a Fixed number of Tasks) provided
multitasking: several memory partitions, each of a fixed size, were
set up when the operating system was installed and when the operator
redefined them. For example, there could be a small partition, two
medium partitions, and a large partition. If there were two large
programs ready to run, one would have to wait until the other finished
and vacated the large partition.
OS/360 MVT (Multitasking with a Variable number of Tasks) was an
enhancement that further refined memory use. Instead of using
fixed-size memory partitions, MVT allocated memory to regions for job
steps as needed, provided enough contiguous physical memory was
available. This was a significant advance over MFT's memory
management, but had some weaknesses: if a job allocated memory
dynamically (as most sort programs and database management systems
do), the programmers had to estimate the job's maximum memory
requirement and pre-define it for MVT. A job step that contained a mix
of small and large programs wasted memory while the small programs
ran. Most seriously, memory could become fragmented, i.e., the memory
not used by current jobs could be divided into uselessly small chunks
between the areas used by current jobs, and the only remedy was to
wait some current jobs finished before starting any new ones.
In the early 1970s
IBM sought to mitigate these difficulties by
introducing virtual memory (which
IBM called "virtual storage"), which
allowed programs to request address spaces larger than physical
memory. The original implementations had a single virtual address
space, shared by all jobs.
OS/VS1 was OS/360 MFT within a single
virtual address space;
OS/VS2 SVS was OS/360 MVT within a single
virtual address space. So
OS/VS1 and SVS in principle had the same
disadvantages as MFT and MVT, but the impacts were less severe because
jobs could request much larger address spaces and the requests came
out of a 16 MB pool even if physical storage was smaller.
MVS address spaces - global view
MVS (shared part of all address spaces)
Shared virtual area (controlled by MVS)
One application's view
Shared virtual area
In the mid-1970s
IBM introduced MVS, which not only supported virtual
storage that was larger than the available real storage,[NB 2] as did
SVS, but also allowed an indefinite number of applications to run in
different address spaces. Two concurrent programs might try to access
the same virtual memory address, but the virtual memory system
redirected these requests to different areas of physical memory. Each
of these address spaces consisted of three areas: an operating system
(one instance shared by all jobs), an application area unique for each
application, and a shared virtual area used for various purposes,
including inter-job communication.
IBM promised that application areas
would always be at least 8 MB. This made
MVS the perfect solution
for business problems that resulted from the need to run more
MVS maximized processing potential by providing multiprogramming and
multiprocessing capabilities. Like its MVT and
MVS supported multiprogramming; program instructions and
associated data are scheduled by a control program and given
processing cycles. Unlike a single-programming operating system, these
systems maximize the use of the processing potential by dividing
processing cycles among the instructions associated with several
different concurrently running programs. This way, the control program
does not have to wait for the I/O operation to complete before
proceeding. By executing the instructions for multiple programs, the
computer is able to switch back and forth between active and inactive
Early editions of
MVS (mid-1970s) were among the first of the
series to support multiprocessor configurations, though the M65MP
variant of OS/360 running on 360 Models 65 and 67 had provided limited
multiprocessor support. The 360 Model 67 had also hosted the
multiprocessor capable TSS/360, MTS and
CP-67 operating systems.
Because multiprocessing systems can execute instructions
simultaneously, they offer greater[clarification needed] processing
power than single-processing system. As a result,
MVS was able to
address the business problems brought on by the need to process large
amounts of data.
Multiprocessing systems are either loosely coupled, which means that
each computer has access to a common workload, or tightly coupled,
which means that the computers share the same real storage and are
controlled by a single copy of the operating system.[clarification
MVS retained both the loosely coupled multiprocessing of
Attached Support Processor (ASP)[NB 3] and the tightly coupled
multiprocessing of OS/360 Model 65 Multiprocessing. In tightly coupled
systems, two CPUs shared concurrent access to the same memory (and
copy of the operating system) and peripherals, providing greater
processing power and a degree of graceful degradation if one CPU
failed. In loosely coupled configurations each of a group of
processors (single and / or tightly coupled) had its own memory and
operating system but shared peripherals and the operating system
JES3 allowed managing the whole group from one console. This
provided greater resilience and let operators decide which processor
should run which jobs from a central job queue.
JES3 gave users
the opportunity to network together two or more data processing
systems via shared disks and Channel-to-Channel Adapters (CTCA's).
This capability eventually became available to JES2 users as
Multi-Access SPOOL (MAS).
MVS originally supported
24-bit addressing (i.e., up to 16 MB).
As the underlying hardware progressed, it supported
31-bit (XA and
ESA; up to 2048 MB) and now (as z/OS) 64-bit addressing. The most
significant motives for the rapid upgrade to
31-bit addressing were
the growth of large transaction-processing networks, mostly controlled
by CICS, which ran in a single address space—and the DB2 relational
database management system needed more than 8 MB of application
address space to run efficiently. (Early versions were configured into
two address spaces that communicated via the shared virtual area, but
this imposed a significant overhead since all such communications had
transmit via the operating system.)
The main user interfaces to
Job Control Language (JCL), which
was originally designed for batch processing but from the 1970s
onwards was also used to start and allocate resources to long-running
interactive jobs such CICS; and TSO (Time Sharing Option), the
interactive time-sharing interface, which was mainly used to run
development tools and a few end-user information systems.
ISPF is a
TSO application for users on 3270-family terminals (and later, on VM
as well), which allows the user to accomplish the same tasks as TSO's
command line but in a menu and form oriented manner, and with a full
screen editor and file browser. TSO's basic interface is command line,
although facilities were added later for form-driven interfaces).
MVS took a major step forward in fault-tolerance, built on the earlier
STAE facility, that
IBM called software recovery.
IBM decided to do
this after years of practical real-world experience with MVT in the
business world. System failures were now having major impacts on
customer businesses, and
IBM decided to take a major design jump, to
assume that despite the very best software development and testing
techniques, that 'problems WILL occur.' This profound assumption was
pivotal in adding great percentages of fault-tolerance code to the
system and likely contributed to the system's success in tolerating
software and hardware failures. Statistical information is hard to
come by to prove the value of these design features (how can you
measure 'prevented' or 'recovered' problems?), but
IBM has, in many
dimensions, enhanced these fault-tolerant software recovery and rapid
problem resolution features, over time.
This design specified a hierarchy of error-handling programs, in
system (kernel/'privileged') mode, called Functional Recovery
Routines, and in user ('task' or 'problem program') mode, called
"ESTAE" (Extended Specified Task Abnormal Exit routines) that were
invoked in case the system detected an error (actually, hardware
processor or storage error, or software error). Each recovery routine
made the 'mainline' function reinvokable, captured error diagnostic
data sufficient to debug the causing problem, and either 'retried'
(reinvoke the mainline) or 'percolated' (escalated error processing to
the next recovery routine in the hierarchy).
Thus, with each error the system captured diagnostic data, and
attempted to perform a repair and keep the system up. The worst thing
possible was to take down a user address space (a 'job') in the case
of unrepaired errors. Though it was an initial design point, it was
not until the most recent
MVS version (z/OS), that recovery program
was not only guaranteed its own recovery routine, but each recovery
routine now has its own recovery routine. This recovery structure was
embedded in the basic
MVS control program, and programming facilities
are available and used by application program developers and 3rd party
MVS software recovery made problem debugging both
easier and more difficult. Software recovery requires that programs
leave 'tracks' of where they are and what they are doing, thus
facilitating debugging—but the fact that processing progresses
despite an error can overwrite the tracks. Early date capture at the
time of the error maximizes debugging, and facilities exist for the
recovery routines (task and system mode, both) to do this.
IBM included additional criteria for a major software problem that
IBM service. If a mainline component failed to initiate
software recovery, that was considered a valid reportable failure.
Also, if a recovery routine failed to collect significant diagnostic
data such that the original problem was solvable by data collected by
that recovery routine,
IBM standards dictated that this fault was
reportable and required repair. Thus,
IBM standards, when rigorously
applied, encouraged continuous improvement.
IBM introduced an on-demand hypervisor, a major serviceability tool,
called Dynamic Support System (DSS), in the first release of MVS. This
facility could be invoked to initiate a session to create diagnostic
procedures, or invoke already-stored procedures. The procedures
'trapped' special events, such as the loading of a program, device
I/O, system procedure calls, and then triggered the activation of the
previously defined procedures. These procedures, which could be
invoked recursively, allowed for reading and writing of data, and
alteration of instruction flow. Program Event Recording hardware was
used. Due to the overhead of this tool, it was removed from
MVS systems. Program-Event Recording (PER)
exploitation was performed by the enhancement of the diagnostic "SLIP"
command with the introduction of the PER support (SLIP/Per) in SU
Multiple copies of
MVS (or other
IBM operating systems) could share
the same machine if that machine was controlled by VM/370. In this
VM/370 was the real operating system, and regarded the "guest"
operating systems as applications with unusually high privileges. As a
result of later hardware enhancements one instance of an operating
system (either MVS, or VM with guests, or other) could also occupy a
Logical Partition (LPAR) instead of an entire physical system.
MVS instances can be organized and collectively administered
in a structure called a systems complex or sysplex, introduced in
September, 1990. Instances interoperate through a software component
called a Cross-system Coupling Facility (XCF) and a hardware component
called a Hardware Coupling Facility (CF or Integrated Coupling
Facility, ICF, if co-located on the same mainframe hardware). Multiple
sysplexes can be joined via standard network protocols such as IBM's
Systems Network Architecture (SNA) or, more recently, via
TCP/IP. The z/OS operating system (MVS' most recent descendant) also
has native support to execute
POSIX and Single UNIX Specification
applications. The support began with
MVS/SP V4R3, and
IBM has obtained
UNIX 95 certification for z/OS V1R2 and later.
The system is typically used in business and banking, and applications
are often written in COBOL.
COBOL programs were traditionally used
with transaction processing systems like IMS and CICS. For a program
running in CICS, special EXEC
CICS statements are inserted in the
COBOL source code. A preprocessor (translator) replaces those EXEC
CICS statements with the appropriate
COBOL code to call
the program is compiled — not altogether unlike
SQL used to
call DB2. Applications can also be written in other languages such as
C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX.
Language support is packaged as a common component called "Language
Environment" or "LE" to allow uniform debugging, tracing, profiling,
and other language independent functions.
MVS systems are traditionally accessed by 3270 terminals or by PCs
running 3270 emulators. However, many mainframe applications these
days have custom web or
GUI interfaces. The z/OS operating system has
built-in support for TCP/IP. System management, done in the past with
a 3270 terminal, is now done through the Hardware Management Console
(HMC) and, increasingly, Web interfaces. Operator consoles are
provided through 2074 emulators, so you are unlikely to see any S/390
or zSeries processor with a real 3270 connected to it.
The native character encoding scheme of
MVS and its peripherals is
EBCDIC, but the TR instruction made it easy to translate to other 7-
and 8-bit codes. Over time
IBM added hardware-accelerated services to
perform translation to and between larger codes, hardware-specific
service for Unicode transforms and software support of, e.g., ASCII,
ISO/IEC 8859, UTF-8, UTF-16, and UTF-32. The software translation
services take source and destination code pages as inputs.
Files are properly called data sets in MVS. Names of those files are
organized in catalogs that are
VSAM files themselves.
Data set names (DSNs, mainframe term for filenames) are organized in a
hierarchy whose levels are separated with dots, e.g.
"DEPT01.SYSTEM01.FILE01". Each level in the hierarchy can be up to
eight characters long. The total filename length is a maximum of 44
characters including dots. By convention, the components separated by
the dots are used to organize files similarly to directories in other
operating systems. For example, there were utility programs that
performed similar functions to those of
Windows Explorer (but without
GUI and usually in batch processing mode) - adding, renaming or
deleting new elements and reporting all the contents of a specified
element. However, unlike in many other systems, these levels are not
usually[NB 4] actual directories but just a naming convention (like
the original Macintosh File System, where folder hierarchy was an
illusion maintained by the Finder). TSO supports a default prefix for
files (similar to a "current directory" concept), and
setting up access controls based on filename patterns, analogous to
access controls on directories on other platforms.
As with other members of the OS family, MVS' data sets were
MVS inherited three main types from its predecessors:
Sequential data sets were normally read one record at a time from
beginning to end.
In BDAM (direct access) data sets, the application program had to
specify the physical location of the data it wanted to access (usually
by specifying the offset from the start of the data set).
ISAM data sets a specified section of each record was defined as a
key that could be used as a key to look up specific records. The key
quite often consisted of multiple fields but these had to be
contiguous and in the right order; and key values had to be unique.
ISAM file could have only one key, equivalent to the
primary key of a relational database table;
ISAM could not support
ISAM datasets could store either fixed-length or
variable length records, and all types could occupy more than one disk
All of these are based on the
VTOC disk structure.
IBM database management systems used various combinations of
ISAM and BDAM datasets - usually BDAM for the actual data storage and
ISAM for indexes.
In the early 1970s IBM's virtual memory operating systems introduced a
new file management component, VSAM, which provided similar
Entry-Sequenced Datasets (ESDS) provided facilities similar to those
of both sequential and BDAM datasets, since they could be read either
from start to finish or directly by specifying an offset from the
Key-Sequenced Datasets (KSDS) were a major upgrade from ISAM: they
allowed secondary keys with non-unique values and keys formed by
concatenating non-contiguous fields in any order; they greatly reduced
the performance problems caused by overflow records in ISAM; and they
greatly reduced the risk that a software or hardware failure in the
middle of an index update might corrupt the index.
VSAM formats became the basis of IBM's database management
systems, IMS/VS and DB2 - usually ESDS for the actual data storage and
KSDS for indexes.
VSAM also included a catalog component used for MVS' master catalog.
Partitioned datasets (PDS) were sequential datasets subdivided into
"members" that could be processed as sequential files in their own
right. The most important use of PDS was for program libraries -
system administrators used the main PDS as a way to allocate disk
space to a project and the project team then created and edited the
Generation Data Groups (GDGs) were originally designed to support
grandfather-father-son backup procedures - if a file was modified, the
changed version became the new "son", the previous "son" became the
"father", the previous "father" became the "grandfather" and the
previous "grandfather" was deleted. But one could set up GDGs with a
lot more than 3 generations and some applications used GDGs to collect
data from several sources and feed the information to one program -
each collecting program created a new generation of the file and the
final program read the whole group as a single sequential file (by not
specifying a generation in the JCL).
Modern versions of
MVS (e.g., z/OS) also support POSIX-compatible
"slash" filesystems along with facilities for integrating the two
filesystems. That is, the OS can make an
MVS dataset appear as a file
POSIX program or subsystem. These newer filesystems include
Hierarchical File System (HFS) (not to be confused with Apple's
Hierarchical File System) and zFS (not to be confused with Sun's ZFS).
Programs running on network-connected computers (such as the AS/400)
can use local data management interfaces to transparently create,
manage, and access
VSAM record-oriented files by using client-server
products implemented according to Distributed Data Management
Architecture (DDM). DDM is also the base architecture for the
server that implements Distributed Relational Database Architecture
History and modernity
MVS is now a part of z/OS, older
MVS releases are no longer supported
IBM and since 2007 only 64-bit z/OS releases are supported. z/OS
supports running older
MVS applications alongside
MVS releases up to 3.8j (24-bit, released in 1981) were freely
available and it is now possible to run the
MVS 3.8j release in
mainframe emulators for free.
MVS/370 is a generic term for all versions of the
MVS operating system
prior to MVS/XA.[NB 5] The
System/370 architecture, at the time MVS
was released, supported only
24-bit virtual addresses, so the MVS/370
operating system architecture is based on a
24-bit address. Because of
24-bit address length, programs running under MVS/370 are each
given 16 megabytes of contiguous virtual storage.
MVS/XA, or Multiple Virtual Storage/Extended Architecture, was a
MVS that supported the 370-XA architecture, which expanded
addresses from 24 bits to 31 bits, providing a
2 gigabyte addressable memory area. It also supported a 24-bit
legacy addressing mode for older
24-bit applications (i.e. those that
24-bit address in the lower 24 bits of a
32-bit word and
utilized the upper 8 bits of that word for other purposes).
MVS Enterprise System Architecture. Version of MVS, first
MVS/SP Version 3 in February 1988. Replaced by/renamed
OS/390 late 1995 and subsequently as z/OS.
MVS/ESA OpenEdition: upgrade to Version 4 Release 3 of MVS/ESA
announced February 1993 with support for
POSIX and other
standards. While the initial release only had National
Institute of Standards and Technology (NIST) certification for Federal
Information Processing Standard (FIPS) 151 compliance, subsequent
releases were certified at higher levels and by other organizations,
X/Open and its successor, The Open Group. It included about 1
million new lines of code, which provide an API shell, utilities, and
an extended user interface. Works with a hierarchical file system
provided by DFSMS (Data Facility System Managed Storage). The shell
and utilities are based on Mortice Kerns' InterOpen products.
Independent specialists reckon it was over 80% open
systems-compliant—more than most
Unix systems. DCE2 support
announced February 1994, and many application development tools in
March 1995. Mid 1995
IBM started to stop referring to OpenEdition as a
separate entity, as all the open features became a standard part of
MVS/ESA SP Version 5 Release 1. Under OS/390, it became UNIX
System Services, and has kept that name under z/OS.
Main article: OS/390
In late 1995
MVS with several program products and changed
the name from
MVS/ESA to OS/390.
Main article: z/OS
The current level of
MVS is marketed as z/OS.
Closely related operating systems
Japanese mainframe manufacturers
Hitachi both repeatedly
and illegally obtained IBM's
MVS source code and internal
documentation in one of the 20th century's most famous cases of
Fujitsu relied heavily on IBM's code in its
MSP mainframe operating system, and likewise
Hitachi did the same for
its VOS3 operating system. MSP and VOS3 were heavily marketed in
Japan, where they still hold a substantial share of the mainframe
installed base, but also to some degree in other countries, notably
Australia. Even IBM's bugs and documentation misspellings were
IBM cooperated with the U.S. Federal Bureau of
Investigation in a sting operation, reluctantly supplying
Hitachi with proprietary
MVS and mainframe hardware technologies
during the course of multi-year investigations culminating in the
early 1980s—investigations which implicated senior company managers
and even some Japanese government officials. Amdahl, however, was not
involved in Fujitsu's theft of IBM's intellectual property. Any
communications from Amdahl to
Fujitsu were through "Amdahl Only
Specifications" which were scrupulously cleansed of any
IBM IP or any
references to IBM's IP.
Subsequent to the investigations,
IBM reached multimillion-dollar
settlements with both
Fujitsu and Hitachi, collecting substantial
fractions of both companies' profits for many years. Reliable reports
indicate that the settlements exceeded US$500,000,000.[citation
needed]:the Congressional testimony, near the end, only says
Hitachi has yet to admit that any of IBM's secrets were used in the
development of new products, and they have not yet compensated
the huge expenses involved in settling the case."
The three companies have long since amicably agreed to many joint
business ventures. For example, in 2000
on developing the
IBM z900 mainframe model.
Because of this historical copying, MSP and VOS3 are properly
classified as "forks" of MVS, and many third party software vendors
with MVS-compatible products were able to produce MSP- and
VOS3-compatible versions with little or no modification.
IBM introduced its 64-bit z/
Architecture mainframes in the year
IBM also introduced the 64-bit z/OS operating system, the direct
OS/390 and MVS.
Hitachi opted not to license
Architecture for their quasi-
MVS operating systems and
hardware systems, and so MSP and VOS3, while still nominally supported
by their vendors, maintain most of MVS's 1980s architectural
limitations to the present day. Since z/OS still supports MVS-era
applications and technologies—indeed, z/OS still contains most of
MVS's code, albeit greatly enhanced and improved over decades of
evolution—applications (and operational procedures) running on MSP
and VOS3 can move to z/OS much more easily than to other operating
Hercules a S/370, S/390, and zSeries emulator capable of running MVS
Utility programs supplied with
MVS (and successor) operating systems
BatchPipes is a batch job processing utility designed for the MVS/ESA
operating system, and all later incarnations—
OS/390 and z/OS.
^ some print media used the singular, MVS/System Extension:
Computerworld, Dec 15, 1980 - Page 5; June 26, 1978 - Page 8
^ Some processors could take more physical storage than the size of a
single address space, but still much smaller than the aggregate size
of a typical workload's virtual storage.
^ Via Job Entry Subsystem 3 (JES3)
^ The exceptions are mostly CVOL and user catalog alias names at the
beginning of a dataset name.
OS/VS2 Release 2 through 3.8, MVS/SE and
MVS/SP Version 1
Bob DuCharme: "The Operating Systems Handbook, Part 06: MVS"
(available online here)
MVS Overview (PDF). First Edition. IBM. June 1978. GC28-0984-0.
Archived from the original (PDF) on 16 March 2011.
IBM Corporation - UNIX 95". The Open Group. Retrieved 7 October
^ Hoskins, Jim; Frank, Bob. Exploring
IBM eServer zSeries and S/390
Servers: See Why IBM's Redesigned Mainframe Computer Family Has Become
More Popular than Ever!. Maximum Press (FL). pp. 210–290.
^ Introducing OpenEdition MVS. First Edition. IBM. December 1993.
OpenEdition MVS POSIX.1 Conformance Document. First Edition. IBM.
February 1993. GC23-3011-00.
OpenEdition MVS POSIX.2 Conformance Document. First Edition. IBM.
December 1993. GC23-3012-00.
^ a b https://fas.org/irp/congress/1989_cr/h890712-japan.htm An hour's
worth of "minutes" from a Congressional Hearing about Japanese
Industrial Espionage against IBM
^ Alexander, Charles; Buderi, Bob (5 July 1982). "Now, from the FBI:
^ Malone, Michael S. (16 May 1983). "Hitachi-F.B.I. Tapes Are
Released". The New York Times.
^ Marie Anchordoguy, "Reprogramming Japan: The High Tech Crisis Under
Communitarian Capitalism," p. 159.
IBM: z/OS V1R11.0
IBM: z/OS V1R8.0
MVS: the operating system that keeps the world going
MVS... a long history
Functional structure of
IBM virtual storage operating systems Part II:
OS/VS2-2 concepts and philosophi