MVS
From Wikipedia, the free encyclopedia
 |
It has been suggested that this article or section be merged into OS/360 and successors. (Discuss) |
| History of IBM mainframe operating systems |
|
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 system, VM.
First released in 1974, MVS had been renamed multiple times, first to MVS/XA (eXtended Architecture), next to MVS/ESA (Enterprise Systems Architecture), then to OS/390 (when UNIX System Services (USS) were added), and finally to z/OS (when 64-bit support was added with the zSeries models). Its 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 complete re-write - previous OS/VS2 releases were upgrades of OS/MVT 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. But users almost unanimously called the new system MVS from the start, and IBM followed their lead in the naming of later major versions such as MVS/XA. After the release of MVS, users described earlier OS/VS2 releases as SVS (Single Virtual Storage).
Contents |
[edit] Evolution of MVS
OS/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. 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/MVT (Multitasking with a Variable number of Tasks) was an enhancement which further refined memory usage. Instead of using fixed-size memory partitions, MVT allocated memory to programs as needed provided there was enough contiguous physical memory available. This was a significant advance over MFT's memory management: there was no predefined limit on the number of jobs that could run at the same time; and two or more large jobs could run at the same time if enough memory was available. 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 which 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 until all 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/MFT within a single virtual address space; OS/VS2 SVS was OS/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.
MVS address spaces - global view
|
|||||||||
One application's view
|
|||||||||
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 an interface which allows the user to accomplish the same tasks as TSO but in a menu and form oriented manner (TSO's basic interface is command line, although facilities were added later for creating form-driven interfaces).
Early editions of MVS (mid-1970s) were the first of the OS series to support multiprocessor configurations. In tightly-coupled systems 2 (later up to 8) 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.
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 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.
[edit] 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[disambiguation needed] 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 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 (i.e. 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).
[edit] History and modernity
MVS is no longer supported by IBM. In fact, IBM phased out support for the 31-bit compatible versions of z/OS in 2007, so only the 64-bit z/OS versions still enjoy support. z/OS continues to receive cutting edge improvements to extend its leadership as the flagship enterprise operating system. In addition to those enhancements mentioned above, others include:
- XML (Xerces-based toolkits for C/C++ and Java)
- network file systems
- TLS/SSL support throughout (including the TCP/IP stack level)
- removal of previous architectural limits (such as the number of I/O channels)
- encrypting file systems
- Workload Manager (WLM)
- special Java acceleration (zAAP support)
- HiperSocket
While z/OS continues to run older 24-bit MVS applications, it does so alongside just written 64-bit hardware-accelerated Java running with state-of-the-art security and Unicode XML data formats on protected filesystems with flexible mounting and long filenames, communicating across IPv6 Hipersocket virtual networks and/or high speed CFs to 64-bit geographically clustered relational databases that use the latest performance-enhancing SQL features including materialized query tables and cube views — for example.
[edit] See also
- Hercules a S/370, S/390, and zSeries emulator capable of running MVS
- Utility programs supplied with MVS (and successor) operating systems
[edit] References
- Bob DuCharme: "The Operating Systems Handbook, Part 06: MVS" (available online here)
