Editing MVS (section)

==MVS filesystem==
Files, other than Unix files, are properly called [[data set (IBM mainframe)|data set]]s 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 [[Directory (computing)|directories]] in other operating systems. For example, there are utility programs that 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 usually<ref group=NB>The exceptions are mostly CVOL and user catalog alias names at the beginning of a dataset name.</ref> actual directories but just a naming convention (like the original [[Macintosh File System]], where folder hierarchy was an illusion maintained by the Finder). [[Time Sharing Option|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 are [[record-oriented filesystem|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 [[basic direct access method|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 that could be used as a key to look up specific records. The key quite often consisted of multiple [[field (computer science)|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 key]]s.
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 system]]s 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) are a major upgrade from ISAM: they allow 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]], [[IBM Information Management System|IMS/VS]] and [[IBM DB2|DB2]] - usually ESDS for the actual data storage and KSDS for indexes.

VSAM also included a catalog component used for user catalogs and MVS' master catalog.

Partitioned data sets (PDS) are sequential data sets subdivided into "members" that could each be processed as sequential files in their own right (like a [[directory (computing)|folder]] in a file system). The most important use of PDSes 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. Other uses of PDSs are libraries of frequently used job control procedures (PROCs), and "copy books" of programming language statements such as record definitions used by several programs.

Generation Data Groups (GDGs) are groups of like named data sets, which can be referenced by absolute generation number, or by an offset from the most recent generation. They were originally designed to support [[Grandfather-Father-Son Backup|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 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 [[Job Control Language|JCL]]).

Modern versions of MVS (e.g., z/OS) use datasets as containers for Unix filesystems along with facilities for partially integrating them. That is, Unix programs using fopen() can access an MVS dataset and a user can allocate a Unix file as though it were a dataset, with some<ref group=NB>E.g., IBM does not support using a concatenation of PDSs and Unix directories.</ref> restrictions. The [[Hierarchical File System (IBM MVS)|Hierarchical File System]] (HFS) (not to be confused with Apple's [[Hierarchical File System (Apple)|Hierarchical File System]]) uses a unique type of dataset, while the newer z/OS File System (zFS) (not to be confused with Sun's [[ZFS]]) uses a VSAM Linear Data Set (LDS).

Programs running on network-connected computers (such as the [[IBM AS/400]]) 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 Architecture]] (DDM). DDM is also the base architecture for the MVS [[IBM DB2|DB2]] server that implements [[DRDA|Distributed Relational Database Architecture]] (DRDA).

=== Virtual I/O (VIO) ===
MVS includes a facility called Virtual I/O (VIO), with which temporary datasets can be stored in simulated tracks on the paging datasets, eliminating the overhead of allocation but adding some processing overhead.