Jump to content

MVS

From Alfawiki
Multiple Virtual Storage (MVS)
Company typeOperating system
IndustryComputer software
Founded1974
FounderIBM
ProductsOperating system for IBM mainframes (System/370, System/390, IBM Z)
ParentIBM

Multiple Virtual Storage (MVS) serves as the chief operating system for IBM's mainframe lines including System/370, System/390, and IBM Z. Created by IBM to succeed OS/360, MVS was developed in parallel with OS/VS1 and SVS. It stands apart from other IBM mainframe operating systems such as VSE, VM, and TPF.

Overview

Initially launched in 1974, MVS progressed through multiple iterations while maintaining the MVS designation:

  • MVS/SE (System Extensions),
  • MVS/SP (System Product) Version 1,
  • MVS/XA (eXtended Architecture),
  • MVS/ESA (Enterprise Systems Architecture),

which later evolved into OS/390 for the System/390 platform and eventually into z/OS featuring enhanced 64-bit capabilities on zSeries hardware. IBM incorporated UNIX compatibility (starting with OpenEdition MVS) in MVS/SP V4.3, achieving various POSIX and UNIX™ standard certifications. The fundamental MVS architecture remains intact, ensuring that applications designed for MVS execute seamlessly on z/OS without modification.

Though initially positioned as a new version of OS/VS2, MVS represented a substantial overhaul. OS/VS2 Release 1 upgraded the multiprogramming capabilities of OS/360 MVT, largely preserving assembly language code, whereas MVS’s core was extensively rewritten using Assembler XF, supplemented by components written in PL/S. IBM prioritized backward compatibility—allowing existing applications and Job Control Language scripts to operate unchanged—resulting in widespread adoption of the term MVS.

Evolution of MVS

OS/360 MFT (Multiprogramming with a Fixed number of Tasks) facilitated multiprogramming by dividing memory into fixed partitions configured during installation or via operator commands. This approach limited flexibility when large applications competed for memory partitions. The OS/360 R19 release introduced multitasking within tasks through the ATTACH macro.

OS/360 MVT enhanced memory management by dynamically allocating variable-sized regions, improving utilization but requiring programmers to specify maximum memory requirements beforehand. Despite this, fragmentation issues persisted, occasionally causing jobs to wait for available memory.

In the early 1970s, IBM introduced virtual memory ("virtual storage"), enabling programs to access address spaces larger than physical memory. OS/VS1 and OS/VS2 SVS implemented a single virtual address space shared among all jobs, alleviating some constraints but retaining limitations similar to those in MFT and MVT.

The mid-1970s marked the debut of MVS, which supported multiple simultaneous applications running in isolated address spaces. Each application had its dedicated area along with shared and operating system regions. These application areas were guaranteed at least 8MB of storage, catering well to business workloads involving numerous concurrent programs.

MVS optimized CPU utilization through multiprogramming and multiprocessing, interleaving instructions from several programs to prevent idle CPU cycles during I/O waits. Early versions supported multiprocessor configurations, building upon limited multiprocessing capabilities present in OS/360 variants and other IBM systems. This multiprocessing capability significantly enhanced processing power essential for extensive business data processing tasks.

MVS accommodated both loosely coupled multiprocessing—using Attached Support Processor (ASP) and JES3—and tightly coupled multiprocessing involving shared memory and an OS copy, providing fault tolerance and centralized workload control. JES3 enabled networking multiple systems via shared disk storage and Channel-to-Channel Adapters; similarly, Multi-Access SPOOL extended comparable functionality to JES2 environments.

Originally designed with 24-bit addressing (16MB), MVS advanced to 31-bit addressing architectures under XA and ESA standards, supporting up to 2GB of addressable space. This evolution was driven by demands from transaction processing systems like CICS and database platforms such as IBM DB2. The modern z/OS platform further extends this capability with 64-bit addressing support.

Primary user interaction methods include Job Control Language (JCL) for batch processing and interactive job management, along with the TSO, an interactive time-sharing environment primarily used for development and end-user tasks. ISPF is a TSO-based application offering menu-driven navigation combined with full-screen text editing capabilities.

MVS introduced sophisticated fault-tolerance based on "software recovery," operating under the assumption that errors will occur despite thorough testing. A structured hierarchy of error-handling routines collects diagnostic information, attempts recovery actions, or escalates issues as needed—thereby enhancing system availability critical for business operations. This framework has been refined continuously through subsequent releases including z/OS.

IBM provided diagnostic utilities such as the Dynamic Support System (DSS) for event-driven automation; although DSS support was eventually discontinued in later versions, user community feedback led to its temporary reinstatement.

Multiple instances of MVS can run concurrently on a single physical machine under the control of VM/370, or within Logical Partitions (LPARs), facilitating flexible resource distribution. These instances can be managed collectively within an IBM Parallel Sysplex environment introduced in 1990, which employs software components like the Cross-system Coupling Facility alongside hardware coupling facilities to deliver high availability and scalability. Sysplexes interconnect through protocols such as SNA or TCP/IP.

z/OS natively executes applications conforming to POSIX and the Single UNIX Specification, maintaining UNIX certification since version z/OS V1R2.

MVS remains prevalent across industries including banking; many applications are developed in COBOL, integrated tightly with transaction processing systems like IMS and CICS via EXEC CICS statements processed by preprocessors. Other supported programming languages encompass C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX—all managed under a unified "Language Environment" that standardizes development tools.

User access traditionally occurs through 3270 terminals or PC-based emulators; contemporary mainframe applications often employ custom web or graphical user interfaces. z/OS incorporates built-in TCP/IP networking support; system administration has transitioned from 3270 terminals to Hardware Management Consoles (HMC) and web-based interfaces.

While MVS utilizes EBCDIC character encoding internally, it supports hardware-accelerated translation among various code pages including ASCII, ISO standards, UTF-8, UTF-16, UTF-32, and Unicode transformations—an essential feature for global enterprise environments.

MVS filesystem

Non-Unix files within MVS are referred to as data sets. These data sets are cataloged in catalogs, which themselves are VSAM files.

Data set names (DSNs) utilize a hierarchical structure separated by periods, for example, "DEPT01.SYSTEM01.FILE01." Each segment can be up to eight characters long, with an overall length limit of 44 characters. Although these segments resemble directory paths in other operating systems, they do not represent actual directories. Management of these data sets is typically handled through batch utilities. The TSO environment supports default prefixes functioning similarly to a "current directory," and RACF provides access control mechanisms based on filename patterns, analogous to directory permissions found in other systems.

MVS data sets are record-oriented and can be classified into three primary types:

  • Sequential data sets process records in a linear sequence.
  • BDAM data sets require explicit specification of the physical location for data retrieval.
  • ISAM data sets employ a unique key for record access, comparable to primary keys in relational databases, though they lack foreign key capabilities.

Both sequential and ISAM data sets may contain fixed or variable-length records and can span several disk volumes, all structured according to the VTOC disk layout.

Earlier IBM database management system implementations combined ISAM and BDAM data sets by using BDAM for storing data and ISAM for indexing purposes.

During the 1970s, IBM introduced VSAM, which enhanced file management by offering:

  • Entry-Sequenced Datasets (ESDS), supporting both sequential and direct access methods.
  • Key-Sequenced Datasets (KSDS), which improved upon ISAM by allowing secondary keys, concatenated key fields, and enhanced index consistency.

These VSAM formats form the basis of IBM's IMS/VS and DB2, where ESDS typically stores data while KSDS manages indexes.

Partitioned data sets (PDS) divide sequential data sets into multiple "members," functioning similarly to folders. PDSes are primarily used as repositories for program libraries, job control procedures, and collections of reusable code modules.

Generation Data Groups (GDGs) organize related datasets by generation numbers, supporting backup strategies such as grandfather-father-son and enabling applications to process data spanning multiple generations.

Contemporary MVS releases (such as z/OS) integrate datasets with Unix file systems. This allows Unix applications to open MVS datasets via fopen(), while Unix files can be allocated as datasets under certain constraints. The HFS employs a specialized dataset type, whereas the newer z/OS File System (zFS) utilizes VSAM Linear Data Sets (LDS).

Networked platforms like the IBM AS/400 use local data management interfaces that transparently create and access VSAM files through client-server solutions based on Distributed Data Management Architecture (DDM). DDM also underpins the MVS DB2 server's implementation of Distributed Relational Database Architecture (DRDA).

Virtual I/O (VIO)

MVS includes Virtual I/O (VIO), a feature that permits temporary datasets to reside within simulated tracks on paging datasets. This approach removes allocation delays but introduces some additional processing overhead.

Upgrades to MVS

IBM progressively expanded OS/VS2's capabilities through a series of releases, sub-releases, free Incremental Change Releases (ICRs), Selectable Units (SUs), commercial program products, and field-developed enhancements, many of which were later incorporated into z/OS. Among the notable Selectable Units were:

Complementary IBM offerings that facilitated MVS enhancements included:

  • ACF/TCAM and ACF/VTAM for managing communications.
  • Data Facility components such as Device Support, Extended Function, Data Set Services, and Sort utilities.
  • Evolving versions of MVS/370 and MVS/XA Data Facility Products designed to improve data handling and storage management.
  • The Data Facility Storage Management Subsystem (DFSMS), which unified previous data facility components to streamline storage administration.
  • TSO programming utilities featuring command processors and extensions that introduced REXX scripting for advanced programmability.
  • Various MVS/System Products, including successive JES releases, which enhanced job entry subsystem capabilities over time.

These improvements illustrate IBM’s commitment to advancing mainframe system efficiency, security, data handling, and user productivity.

Data Facility Product (DFP)

During the late seventies and early eighties, IBM released multiple products such as:

  • 5740-AM7 Data Facility Device Support (DF/DS)
  • 5740-XYQ Data Facility Extended Function (DF/EF)
  • 5740-AM3 Sequential Access Method Extended (SAM-E)
  • 5740-AM8 Access Method Services Cryptographic Option
  • 5748-UT2 Offline 3800 Utility

DF/DS introduced support for additional devices, marking IBM’s transition away from including device support in the base no-charge product. DF/EF brought forward the Improved Catalog Structure (ICF), an alternative to VSAM catalogs and Control Volumes; however, it encountered stability challenges.

With the release of MVS/SP Version 2 (MVS/XA), IBM unveiled the Data Facility Product™ (DFP™) as a consolidated upgrade that replaced these earlier offerings, which were discontinued from marketing by December 1, 1984. DFP/370 Release 1 (program number 5665-295), announced on June 7, 1983, was compatible with MVS/SP Version 1, MVS/SE, and OS/VS2 R3.8 as an optional add-on; for MVS/SP Version 2 (MVS/XA), DFP became a mandatory co-requisite under program number 5665-284. In addition to advancing data management functions, DFP superseded previously free linkage editors and utility versions.

Currently, DFP is embedded within the Data Facility Storage Management Subsystem as DFSMSdfp.

Modern MVS

MVS has transformed into what is now known as z/OS; IBM discontinued support for earlier MVS versions and, since 2007, has exclusively supported 64-bit z/OS releases. z/OS preserves backward compatibility by allowing legacy 24-bit and 31-bit MVS applications to execute alongside contemporary 64-bit programs.

Earlier MVS versions up to 3.8j (a 24-bit release from 1981) remain accessible without charge and can be operated on mainframe emulators such as the Hercules Emulator.

MVS/370

The term MVS/370 encompasses all MVS editions preceding MVS/XA. At that time, the System/370 architecture only supported 24-bit virtual addressing, meaning MVS/370 provided a 24-bit address space that allowed each application access to a maximum of 16 MB of continuous virtual memory.

MVS/XA

MVS/XA (Multiple Virtual Storage/Extended Architecture) represented an iteration of MVS compatible with the 370-XA architecture. It introduced a revamped I/O system and expanded the addressable memory from 24 bits to 31 bits, facilitating access to up to 2 gigabytes of memory. For older software relying on 24-bit addressing, MVS/XA retained a legacy mode supporting that addressing scheme.

MVS/ESA

MVS Enterprise System Architecture (MVS/ESA) designates MVS versions preceding OS/390 that implemented the S/370 Enterprise Systems Architecture (S/370-ESA). This version enhanced MVS/XA’s addressing capabilities by incorporating an access register (AR) mode, enabling referencing across different address spaces.

IBM introduced MVS/ESA as MVS/SP Version 3 in February 1988, followed by subsequent releases in Versions 4 and 5. It was eventually succeeded by OS/390 in late 1995 and later by z/OS.

MVS/ESA OpenEdition: Announced in February 1993 as an upgrade to Version 4 Release 3, OpenEdition incorporated support for POSIX and additional standards, significantly improving system interoperability. This enhancement added approximately one million lines of code, including an API shell, utilities, and an extended user interface integrated with DFSMS’s hierarchical file system. The shell and utilities were derived from Mortice Kern Systems' InterOpen products. Independent evaluations estimated compliance with open systems standards exceeded 80%, outperforming many Unix systems at the time. DCE2 support was introduced in February 1994, followed by further application development tools in March 1995. By mid-1995, these open system features were fully integrated into MVS/ESA SP Version 5 Release 1, after which IBM discontinued treating OpenEdition as a separate entity. Under OS/390 V2R6, OpenEdition was rebranded UNIX System Services—a designation retained within z/OS.

OS/390

In late 1995, IBM consolidated MVS with several additional program products and renamed MVS/ESA as OS/390.

z/OS

The present-day evolution of MVS is marketed under the name z/OS.

Closely related operating systems

Japanese mainframe producers Fujitsu and Hitachi were involved in a significant industrial espionage scandal after unlawfully acquiring IBM's MVS source code along with confidential internal documents. Fujitsu incorporated IBM's code into its MSP mainframe operating system, while Hitachi embedded it within its VOS3 OS. Both MSP and VOS3 have sustained notable market presence in Japan and, to a lesser degree, in Australia. Remarkably, even IBM's software bugs and documentation inaccuracies were duplicated. Collaborating with the U.S. Federal Bureau of Investigation, IBM conducted a covert operation by providing Fujitsu and Hitachi with proprietary MVS and hardware technology over several years during early 1980s investigations, which implicated high-ranking executives and certain Japanese government officials. It is important to note that Amdahl Corporation was not implicated; its communications with Fujitsu deliberately excluded any IBM intellectual property.

As a result of these inquiries, IBM obtained settlements from Fujitsu and Hitachi totaling reportedly over US$500 million, reclaiming a significant share of profits accrued over many years. Although initial relations were contentious, the companies eventually collaborated on joint ventures, including the 2000 partnership between IBM and Hitachi focused on the IBM z900 mainframe.

Given this background, MSP and VOS3 are regarded as forks of MVS. Numerous third-party developers adapted MVS-compatible software to function on MSP and VOS3 with only minor modifications.

When IBM introduced 64-bit z/Architecture mainframes in 2000, it also launched the 64-bit z/OS operating system as the successor to OS/390 and MVS. Fujitsu and Hitachi opted not to license z/Architecture for their platforms; consequently, MSP and VOS3 preserve much of the original MVS architecture from the 1980s. Since z/OS maintains support for legacy MVS applications and technologies—retaining extensive portions of MVS’s foundational code refined over decades—the migration from MSP or VOS3 to z/OS remains relatively uncomplicated for enterprises.

See also

External links

Retrieved from "https://www.alfawiki.org/index.php?title=MVS&oldid=28104"