MVS 1

MVS
History of IBM mainframe
operating systems

On early mainframe computers:

• GM OS & GM-NAA I/O 1955
• BESYS 1957
• UMES 1958
• SOS 1959
• IBSYS 1960
• CTSS 1961
On S/360 and successors:
• BOS/360 1965
• TOS/360 1965
• TSS/360 1967
• MTS 1967
• ORVYL 1967
• MUSIC 1972
• MUSIC/SP 1985

• DOS/360 and successors 1966

• DOS/VS 1972
• DOS/VSE 1980s
• VSE/SP late 1980s
• VSE/ESA 1991
• z/VSE 2005

• OS/360 and successors 1966

• MFT 1966
• MFT II 1968
• OS/VS1 1972
• OS/VS1 BPE
• MVT 1967
• 65MP
• OS/VS2R1 (SVS) 1972
• MVS (OS/VS2R2 and later) 1974
• MVS/SE 1978
• MVS/SE 2 1979
• MVS/SP Version 1 1980
• MVS/XA 1983
• MVS/ESA 1988
• OS/390 1995
• z/OS 2000

• VM line
• CP-40/CMS 1967
• CP-67/CMS 1967
• VP/CSS 1968
• VM/370 1972
• VM/BSE (BSEPP)
• VM/SE (SEPP)
• VM/SP 1980
• VM/XA 1988
• VM/ESA 1990
• z/VM 2000
MVS 2

• TPF line
• ACP 1967
• TPF 1979
• z/TPF 2005

• UNIX and Unix-like

• UTS 1981
• AIX/370 1990
• AIX/ESA 1991
• Linux 1999
• OpenSolaris 2008
• z/OS UNIX System Services

Multiple Virtual Storage, more commonly called MVS, was the most commonly used operating system on the
System/370 and System/390 IBM mainframe computers. It was developed by IBM, but is unrelated to IBM's other
mainframe operating systems, e.g., VSE, VM.
First released in 1974, MVS had been extended by program products with new names multiple times, first to
MVS/SE (System Extension), next to MVS/SP (System Product) Version 1, next to MVS/XA (eXtended
Architecture), next to MVS/ESA (Enterprise Systems Architecture), next to OS/390 and finally to z/OS (when 64-bit
support was added with the zSeries models). IBM added Unix support (originally called OPEN EDITION) in
MVS/SP V4.3 and has obtained POSIX and Unix certifications at several different levels. MVS's core remains
fundamentally the same operating system. By design, programs written for MVS can still run on z/OS without
modification.
At first IBM described MVS as simply a new release of OS/VS2. But it was in fact a major re-write - OS/VS2
release 1 was an upgrade of OS/360 MVT that retained most of the original code and, like MVT, were mainly
written in Assembler; the core of MVS was almost entirely written in PL/S. IBM's use of "OS/VS2" emphasized
upwards compatibility: application programs which ran under MVT did not even need to be re-compiled in order to
run under MVS; the same Job Control Language files could be used unchanged; the utilities and other non-core
facilities like TSO ran unchanged. IBM and users almost unanimously called the new system MVS from the start,
and IBM continued to use the term MVS in the naming of later major versions such as MVS/XA.

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 might 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 on the other until it finished and vacated the large partition.
OS/360 MVT (Multitasking with a Variable number of Tasks) was an enhancement that further refined memory
usage. Instead of using fixed-size memory partitions, MVT allocated memory to regions for job steps as needed
provided there was enough contiguous physical memory available. This was a significant advance over MFT's
memory management. But it 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 mixture of small and large programs would waste memory
while the small programs were running; 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 (referred to by IBM as
"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
MVS 3

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 because the requests came out of a 16 MiB pool even if the physical storage was
smaller.

MVS address spaces - global view

MVS (shared part of all address spaces)

App 1 App 2 App 3

Shared virtual area (controlled by MVS)

One application's view

MVS

App 1

Shared virtual area

In the mid-1970s IBM introduced MVS, which 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 3 areas: operating system (one instance shared by all jobs); application area which was unique for each
application; shared virtual area which was used for various purposes including inter-job communication. IBM
promised that the application areas would always be at least 8MB.
MVS originally supported 24-bit addressing (i.e., up to 16MB). As the underlying hardware progressed it supported
31-bit (XA and ESA; up to 2048MB) and now (as z/OS) 64-bit addressing. Two of the most significant reasons 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; the DB2 relational database management system needed more than
8MB of application address space in order to run efficiently (early versions were configured into two address spaces
which communicated via the shared virtual area, but this imposed a significant overhead since all such
communications had to be transmitted via the operating system).
The main user interfaces to MVS are: 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 creating form-driven interfaces).
Early editions of MVS (mid-1970s) were among the first of the IBM OS series to support multiprocessor
configurations, though it had previously been supported in the 1960s on a limited basis by the M65MP variant of
OS/360 running on 360/65 and 360-67. The 360-67 had also hosted the multiprocessor capable TSS/360, MTS and
CP-67 operating systems. 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
component JES3 allowed the whole group to be managed from one console - this provided greater resilience and
enabled operators to decide which processor should run which jobs from a central job queue.
MVS 4

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, but 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). The purpose of each recovery routine was to make the 'mainline' function
reinvokable, capture error diagnostic data sufficient to debug the causing problem, and either 'retry' (reinvoke the
mainline) or 'percolate' (escalate error processing to the next recovery routine in the hierarchy).
Thus, with each and every error: diagnostic data was captured, an attempt was made 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.
Although 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 developers.
Practically, it has been observed that the MVS software recovery made problem debugging both easier and more
difficult: Software recovery required that programs leave 'tracks' of where they were and what they were doing, thus
facilitating debugging, but the fact that processing does not stop at the time of an error, but rather progresses, can
make the tracks over-written. 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 would require IBM service to repair it: If a
mainline component failed to initiate software recovery, that was considered a reportable valid 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 applied rigorously, would encourage 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
customer-available 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 64/65 (1978).
Multiple copies of MVS (or other IBM operating systems) could share the same machine if that machine was
controlled by VM/370 - in this case 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.
Multiple 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
MVS 5

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 proprietary 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 applications.
Files are properly called data sets in MVS. Names of those files are organized in catalogs which are VSAM files
themselves.
The native encoding scheme of IBM mainframes and their peripherals is Big Endian EBCDIC, but MVS provides
hardware-accelerated services to perform translation and support of ASCII, Little Endian, and Unicode.

MVS filesystem
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
which performed similar functions to those of Windows Explorer (but without the 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 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 RACF supports 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 record-oriented. 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).
• In ISAM data sets a specified section of each record was defined as a key which 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. Hence an IBM ISAM file could have only one key, equivalent to the
primary key of a relational database table; ISAM could not support foreign keys.
Sequential and ISAM datasets could store either fixed-length or variable length records, and all types could occupy
more than one disk volume.
All of these are based on the VTOC disk structure.
Early 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 facilities:
• 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 start.
• 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.
These 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.
MVS 6

VSAM also included a catalog component which was used for MVS' master catalog.
Partitioned datasets (PDS) were sequential datasets which were subdivided into "members" which 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 members.
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 to a 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).

History and modernity

MVS is now a part of z/OS, older MVS releases are no longer supported by IBM and since 2007 only 64-bit z/OS
releases are supported. Of course, z/OS continues to support running older 24-bit and 31-bit MVS applications
alongside just-written 64-bit code.
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/XA
MVS/XA, or Multiple Virtual Storage/Extended Architecture, was a version of the IBM operating system that is
now called z/OS. It was available only on the high-end 43xx, and 308x and later ranges of IBM computers, and was
replaced by MVS/ESA, then OS/390 and later z/OS.
MVS/XA maintained the same multiprogramming and multiprocessing features supported by its predecessor
MVS/370, combined with the capability of simultaneously servicing multiple programs and users. It not only
supported virtual storage that was larger than the available real storage, but that separate processes (tasks) were run
in separate address spaces. It made MVS/XA the perfect solution for business problems which resulted from the
need to run more applications.
New features:
• 31-bit addressing, thus, a 2 gigabyte addressable memory area, [1]
• legacy addressing mode for older 24-bit applications (i.e. those that utilized bits above 24 bit for other purposes)

MVS/ESA
MVS/ESA: MVS Enterprise System Architecture. Version of MVS, first introduced as MVS/SP Version 3 in
February 1988. Replaced by/renamed as 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.[2] [2] [3] 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, e.g. X/Open and its successor, The Open Group.
Included about 1 million new lines of code which provide an API shell, utilities, and an extended user interface.
MVS 7

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 vanilla MVS/ESA SP Version 5 Release 1. Under OS/390, it became
Unix System Services, and has kept that name under z/OS.

MVS/370
MVS/370 is the earliest currently supported version of the MVS operating system. The MVS/370 operating system
architecture is based on a 24-bit address. Because of this 24-bit address length, programs running under MVS/370
are each given 16 megabytes of contiguous storage. MVS/370 maximizes processing potential by proving
multiprogramming and multiprocessing capabilities.
Like its MVT predecessor, MVS/370 supported multiprogramming; program instruction and associated data are
transferred to a control program and given processing cycles. Unlike a single-programming operating system,
MVS/370 maximizes the use of the processing potential by dividing processing cycles among the instruction
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 programs.
MVS/370 also gave users the opportunity to network together two or more data processing systems. This capability
became known as multiprocessing. 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. Because multiprocessing system can execute
instructions simultaneously, they offer greater processing power than single-processing system. As a result,
MVS/370 was able to address the business problems brought on by the need to process large amounts of data.

References
• Bob DuCharme: "The Operating Systems Handbook, Part 06: MVS" (available online here [4])
• IBM (June, 1978), OS/VS2 MVS Overview [5], First Edition, GC28-0984-0.
[1] 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! (http:/ / books. google. com/ books?id=NtHhpIjIFMEC& pg=PA33& dq=computer+ virtualization+
"virtual+ machine"+ date:1960-2004& lr=& as_brr=3& sig=iJDk9Q2b6eyO2HUNIApogerBZcI#PPA216,M1). Maximum Press (FL).
pp. 210–290. ISBN 1-885068-91-3. .
[2] IBM (December 1993), Introducing OpenEdition MVS, First Edition, GC23-3010-00.
[3] IBM (December 1993), OpenEdition MVS POSIX.2 Conformance Document, First Edition, GC23-3012-00.
[4] http:/ / www. snee. com/ bob/ opsys. html
[5] http:/ / www. bitsavers. org/ pdf/ ibm/ 370/ OS_VS2/ GC28-0984-0_OSVS2_MVS_Overview. pdf
MVS 8

External links
• IBM: z/OS V1R11.0 MVS Manuals (http://www-03.ibm.com/systems/z/os/zos/bkserv/r11pdf/#mvs)
• IBM: z/OS V1R8.0 MVS manuals (http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/r8pdf/mvs.
html)-Broken link
• MVS: the operating system that keeps the world going (http://www.os390-mvs.freesurf.fr/mvs.htm)
• MVS... a long history (http://www.os390-mvs.freesurf.fr/mvshist.htm)
• Functional structure of IBM virtual storage operating systems Part II: OS/VS2-2 concepts and philosophies by A.
L. Scherr (http://www.research.ibm.com/journal/sj/124/ibmsj1204E.pdf)
• Online demo of MVS 3.8J (http://www.mvswiki.org/index.php)
Article Sources and Contributors 9

Article Sources and Contributors

MVS  Source: http://en.wikipedia.org/w/index.php?oldid=425113430  Contributors: Ahoerstemeier, Alex n, AlexPU, AlistairMcMillan, Andreas Sons, Antonrojo, Atlant, AxelBoldt,
BBCWatcher, Barefootguru, Berkut, Blaxthos, Bluemoose, Brenont, Bynzine, CanisRufus, Charles Matthews, Chatul, Conversion script, D6, David Shay, Denelson83, Dmsar, DougieLawson,
Dskwire, Dwight666, EagleOne, Ebeisher, Farimah, Frap, Funandtrvl, Gortu, Guy Harris, Hoof Hearted, Hu, Jkominek, Jnc, John Vandenberg, Jsavit, Kmorozov, KnightRider, Kubanczyk,
Looxix, Metageek, Michael Hardy, MrOllie, Mulad, Mwtoews, Mzajac, Nwbeeson, Orderud, Peter, Philcha, Polarbjorn, Poterxu, Ray12489, RedWolf, Reeve, Rfc1394, Rjwilmsi, Rwwww, Salix
alba, Samohyl Jan, Sfoskett, Simon_J_Kissane, Sperling, T-bonham, Tobias Bergemann, TreyGeek, UncleBubba, Uryah, Vegaswikian, Vinod mvs, Wernher, Wknight94, 73 anonymous edits

License
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/