MULTIPLE VIRTUAL STORAGE, more commonly called MVS, was the most
commonly used operating system on the
First released in 1974, MVS was extended by program products with new names multiple times:
* first to MVS/SE (MVS/System Extensions),
* next to
MVS/SP (MVS/System Product) Version 1,
* next to
MVS/XA (MVS/eXtended Architecture),
* next to
MVS/ESA (MVS/Enterprise Systems Architecture),
* then to
* finally to z/OS (when 64-bit support was added with the zSeries
* 1 Evolution of MVS * 2 MVS filesystem * 3 History and modernity * 4 MVS/370 * 5 MVS/XA * 6 MVS/ESA * 7 OS/390 * 8 z/OS * 9 Closely related operating systems * 10 See also * 11 Notes * 12 References * 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
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
Shared virtual area
In the mid-1970s
MVS maximized processing potential by providing multiprogramming and multiprocessing capabilities. Like its MVT and OS/VS2 SVS predecessors, 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 programs.
Early editions of
MVS (mid-1970s) were among the first of the
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 . MVS retained both the loosely coupled multiprocessing of Attached Support Processor (ASP) 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 component 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. MVS 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 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 form-driven interfaces).
MVS took a major step forward in fault-tolerance, built on the
earlier STAE facility, that
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 developers.
Practically, the 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.
Multiple copies of
MVS (or other
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
The system is typically used in business and banking, and
applications are often written in
MVS systems are traditionally accessed by 3270 terminals or by PCs
running 3270 emulators. However, many mainframe applications these
days have custom web or
The native character encoding scheme of
MVS and its peripherals is
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
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).
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.
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.
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.
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 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 ).
Programs running on network-connected computers (such as the
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
HISTORY AND MODERNITY
MVS is now a part of z/OS, older
MVS releases are no longer supported
MVS/370 is a generic term for all versions of the
system prior to MVS/XA. The
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
24-bit applications (i.e. those that stored a
24-bit address in
the lower 24 bits of a
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, e.g.
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
Main article: OS/390
Main article: z/OS
The current level of MVS is marketed as z/OS.
CLOSELY RELATED OPERATING SYSTEMS
Japanese mainframe manufacturers
Subsequent to the investigations,
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.