MVS - MVS Filesystem

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