OS/360 R19 added MFT sub-tasking (multitasking), the ability for a job to dynamically create new tasks with the ATTACH macro.

So OS/VS1 and SVS in principle had the same disadvantages as MFT and MVT, but the impacts are less severe because jobs and operators could request much larger partitions with a 2 KiB granularity (for OS/VS1) or regions with a 4 KiB granularity (for SVS), and the requests came out of a 16MiB address space even if physical storage was smaller.

This made MVS the perfect solution for business problems that resulted from the need to run more applications.

As a result, MVS was able to address the business problems brought on by the need to process large amounts of data.

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).

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 as 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.

[3] MVS took a major step forward in fault-tolerance, built on the earlier STAE facility, that IBM called software recovery.

), but IBM has, in many dimensions, enhanced these fault-tolerant software recovery and rapid problem resolution features, over time.

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 data capture at the time of the error maximizes debugging, and facilities exist for the recovery routines (task and system mode, both) to do this.

If a mainline component failed to initiate software recovery, that was considered a valid reportable failure.

These procedures, which could be invoked recursively, allowed for reading and writing of data, and alteration of instruction flow.

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 MVS instances can be organized and collectively administered in a structure called a systems complex or sysplex, introduced in September, 1990.

The z/OS operating system (MVS' most recent descendant) also has native support to execute POSIX and Single UNIX Specification applications.

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.

Data set names (DSNs, mainframe term for filenames) are organized in a hierarchy whose levels are separated with dots, e.g. "DEPT01.SYSTEM01.FILE01".

By convention, the components separated by the dots are used to organize files similarly to directories in other operating systems.

In the early 1970s IBM's virtual memory operating systems introduced a new file management component, VSAM, which provided similar facilities: 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.

Modern versions of MVS (e.g., z/OS) use datasets as containers for Unix filesystems along with facilities for partially integrating them.

In addition to enhancing data management facilities, DFP replaced free versions of the linkage editor and utilities.

DFP is no longer available as a separate product, but has become part of Data Facility Storage Management Subsystem, under the name DFSMSdfp.

MVS/ESA OpenEdition: upgrade to Version 4 Release 3 of MVS/ESA SP announced[15] February 1993 with support for POSIX and other standards.

It included about 1 million new lines of code, which provide an API shell, utilities, and an extended user interface.

From mid 1995, as all of the open features became a standard part of vanilla MVS/ESA SP Version 5 Release 1, IBM stopped distinguishing OpenEdition from the operating system.

Japanese mainframe manufacturers Fujitsu and 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 industrial espionage.

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.

IBM cooperated with the U.S. Federal Bureau of Investigation in a sting operation, reluctantly supplying Fujitsu and 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.

Subsequent to the investigations, IBM reached multimillion-dollar settlements with both Fujitsu and Hitachi, collecting substantial fractions of both companies' profits for many years.

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.