МВС

Множественное виртуальное хранилище (MVS)

Разработчик	ИБМ
Написано в	Ассемблер (XF) , PL/S
Семейство ОС	ОС/360
Первоначальный выпуск	1974 ; 51 год назад ( 1974 )
Маркетинговая цель	Мейнфреймовые компьютеры IBM
Доступно в	Английский
Платформы	Система/370 , Система/390
Под влиянием	ТСС
Лицензия	Запатентованная Изначально бесплатная
Предшествовал	ОС/ВС2 (СВС)
Преемник	МВС/СЕ, МВС/СП , МВС/ХА , МВС/ЕСА , ОС/390 , z/OS

Multiple Virtual Storage , чаще называемая MVS , является наиболее часто используемой операционной системой на мэйнфреймах IBM System/370 , System/390 и IBM Z. IBM разработала MVS, наряду с OS/VS1 и SVS , как преемника OS/360 . Она не связана с другими линейками операционных систем для мэйнфреймов IBM, например, VSE , VM , TPF .

Впервые выпущенный в 1974 году, MVS был расширен программными продуктами с новыми названиями несколько раз, сохраняя термин MVS в номенклатуре:

• сначала MVS/SE (MVS/System Extensions), ^{[NB 1]}
• рядом с MVS/SP (MVS/System Product) Версия 1,
• рядом с MVS/XA (MVS/eXtended Architecture),
• рядом с MVS/ESA (MVS/Enterprise Systems Architecture),

а затем продлили

• к OS/390 для систем System/390 и
• наконец, к z/OS (когда поддержка 64-бит была добавлена ​​в моделях zSeries ). IBM добавила поддержку UNIX (первоначально называвшуюся OpenEdition MVS ) в MVS/SP V4.3 и получила сертификации POSIX и UNIX™ на нескольких различных уровнях от IEEE , X/Open и The Open Group . Ядро MVS остается в основе той же операционной системы. По замыслу программы, написанные для MVS, работают на z/OS без изменений.

Сначала IBM описала MVS просто как новый выпуск OS/VS2 , но на самом деле это серьезная переработка. Выпуск OS/VS2 1 — это обновление OS/360 MVT , которое сохранило большую часть исходного кода и, как и MVT, в основном написано на языке ассемблера . Ядро MVS почти полностью написано на Assembler XF , хотя несколько модулей были написаны на PL/S , но не те, которые чувствительны к производительности, в частности, не Input/Output Supervisor (IOS). Использование IBM «OS/VS2» подчеркивало восходящую совместимость: прикладные программы, работавшие под MVT, даже не нуждались в перекомпиляции для запуска под MVS. Те же файлы Job Control Language можно было использовать без изменений; утилиты и другие неосновные средства, такие как TSO, работали без изменений. IBM и пользователи почти единогласно назвали новую систему MVS с самого начала, и IBM продолжала использовать термин MVS в наименовании более поздних основных версий, таких как MVS/XA.

OS/360 MFT (мультипрограммирование с фиксированным числом задач) ^[1] обеспечивает многопрограммирование : несколько разделов памяти , каждый фиксированного размера, настраиваются при установке операционной системы и когда оператор переопределяет их. Например, может быть небольшой раздел, два средних раздела и большой раздел. Если бы были две большие программы, готовые к запуску, одной пришлось бы ждать, пока другая завершит работу и освободит большой раздел. OS/360 R19 добавила подзадачность MFT ( многозадачность ), способность задания динамически создавать новые задачи с помощью макроса ATTACH.

OS/360 MVT (мультипрограммирование с переменным числом задач) ^[1] было усовершенствованием, которое еще больше улучшило использование памяти. Вместо использования разделов памяти фиксированного размера, MVT выделяет память регионам для шагов задания по мере необходимости, при условии наличия достаточной непрерывной физической памяти . Это значительный шаг вперед по сравнению с управлением памятью MFT, но у него есть некоторые недостатки: если задание выделяет память динамически (как это делают большинство программ сортировки и систем управления базами данных ), программистам приходится оценивать максимальное требование к памяти задания и заранее определять его для MVT. Шаг задания, содержащий смесь малых и больших программ, тратит память впустую, пока выполняются маленькие программы. Самое серьезное, что память может стать фрагментированной , т. е. память, не используемая текущими заданиями, может быть разделена на бесполезно маленькие фрагменты между областями, используемыми текущими заданиями, и единственным средством было дождаться завершения некоторых текущих заданий, прежде чем начинать какие-либо новые.

В начале 1970-х годов IBM попыталась смягчить эти трудности, введя виртуальную память (которую IBM называла «виртуальным хранилищем»), которая позволяла программам запрашивать адресные пространства, превышающие физическую память. Первоначальные реализации имели единое виртуальное адресное пространство , общее для всех заданий. OS/VS1 — это OS/360 MFT в едином виртуальном адресном пространстве; OS/VS2 SVS — это OS/360 MVT в едином виртуальном адресном пространстве. Таким образом, OS/VS1 и SVS в принципе имели те же недостатки, что и MFT и MVT, но последствия были менее серьезными, поскольку задания и операторы могли запрашивать гораздо большие разделы с гранулярностью 2 КиБ (для OS/VS1) или регионы с гранулярностью 4 КиБ (для SVS), а запросы исходили из адресного пространства 16 МиБ, даже если физическое хранилище было меньше. Как и в OS/360 MVT, пользователи TSO в SVS назначаются региону TSO во время обработки входа в систему и конкурируют с другими пользователями, назначенными в тот же регион, по сути, с той же логикой замены, что и TSO в MVT.

В середине 1970-х годов IBM представила MVS, которая не только поддерживала виртуальное хранилище, превышающее доступное реальное хранилище ^{[NB 2]} , как и SVS, но и позволяла неограниченному количеству приложений работать в разных адресных пространствах. Две параллельные программы могли попытаться получить доступ к одному и тому же адресу виртуальной памяти, но система виртуальной памяти перенаправляла эти запросы в разные области физической памяти. Каждое из этих адресных пространств состояло из трех областей: операционной системы (один экземпляр, общий для всех заданий), области приложения, уникальной для каждого приложения, и общей виртуальной области, используемой для различных целей, включая межзадачное взаимодействие. IBM обещала, что области приложений всегда будут иметь размер не менее 8 МБ. Это сделало MVS идеальным решением для бизнес-задач, возникавших из-за необходимости запускать больше приложений.

MVS максимизировал потенциал обработки, предоставляя возможности многопрограммирования и многопроцессорности . ^[2] Как и его предшественники MVT и OS/VS2 SVS , MVS поддерживал многопрограммирование ; инструкции программы и связанные с ней данные планируются управляющей программой и задаются циклами обработки. В отличие от операционной системы с одним программированием, эти системы максимизируют использование потенциала обработки, разделяя циклы обработки между инструкциями, связанными с несколькими различными одновременно работающими программами. Таким образом, управляющей программе не приходится ждать завершения операции ввода-вывода, прежде чем продолжить работу. Выполняя инструкции для нескольких программ, компьютер может переключаться между активными и неактивными программами.

Ранние выпуски MVS (середина 1970-х годов) являются одними из первых в серии IBM OS, поддерживающих многопроцессорные конфигурации, хотя вариант M65MP OS/360, работающий на 360 Models 65 и 67, обеспечивал ограниченную поддержку многопроцессорности. 360 Model 67 также размещал многопроцессорные операционные системы TSS/360 , MTS и CP-67 . Поскольку многопроцессорные системы могут выполнять инструкции одновременно, они предлагают большую ^{[ требуется разъяснение ]} вычислительную мощность, чем однопроцессорные системы. В результате MVS смогла решить бизнес-проблемы, вызванные необходимостью обработки больших объемов данных.

Многопроцессорные системы бывают либо слабосвязанными, что означает, что каждый компьютер имеет доступ к общей рабочей нагрузке, либо тесносвязанными , что означает, что компьютеры совместно используют одно и то же реальное хранилище и управляются одной копией операционной системы . ^{[ необходимо разъяснение ]} MVS сохранила как слабосвязанную многопроцессорность Attached Support Processor ( ASP) ^{[NB 3]} , так и тесносвязанную многопроцессорность OS/360 Model 65 Multiprocessing . В тесносвязанных системах два ЦП совместно использовали параллельный доступ к одной и той же памяти (и копии операционной системы) и периферийным устройствам, обеспечивая большую вычислительную мощность и определенную степень постепенной деградации в случае отказа одного ЦП. В слабосвязанных конфигурациях каждый из группы процессоров (отдельных и/или тесносвязанных) имел свою собственную память и операционную систему, но общие периферийные устройства и компонент операционной системы JES3 позволяли управлять всей группой с одной консоли. Это обеспечивало большую устойчивость и позволяло операторам решать, какой процессор должен выполнять какие задания из центральной очереди заданий. MVS JES3 предоставил пользователям возможность объединить в сеть две или более систем обработки данных через общие диски и адаптеры Channel-to-Channel (CTCA). Эта возможность в конечном итоге стала доступна пользователям JES2 как Multi-Access SPOOL (MAS). ^{[ необходима цитата ]}

Первоначально MVS поддерживал 24-битную адресацию (т. е. до 16 МБ). По мере развития базового оборудования он поддерживал 31-битную (XA и ESA; до 2048 МБ) и теперь (как z/OS) 64-битную адресацию. Наиболее существенными мотивами для быстрого обновления до 31-битной адресации были рост крупных сетей обработки транзакций, в основном контролируемых CICS , которые работали в едином адресном пространстве, а реляционной системе управления базами данных DB2 требовалось более 8 МБ адресного пространства приложений для эффективной работы. (Ранние версии были сконфигурированы в два адресных пространства, которые взаимодействовали через общую виртуальную область, но это приводило к значительным накладным расходам, поскольку все такие коммуникации передавались через операционную систему.)

Основные пользовательские интерфейсы MVS: Job Control Language (JCL), который изначально был разработан для пакетной обработки , но с 1970-х годов также использовался для запуска и распределения ресурсов для длительных интерактивных заданий, таких как CICS ; и TSO (Time Sharing Option), интерактивный интерфейс с разделением времени , который в основном использовался для запуска инструментов разработки и нескольких информационных систем конечного пользователя. ISPF — это приложение TSO для пользователей на терминалах семейства 3270 (а позже и на VM), которое позволяет пользователю выполнять те же задачи, что и командная строка TSO, но в меню и ориентированной на формы манере, а также с полноэкранным редактором и файловым браузером. Базовым интерфейсом TSO является командная строка , хотя позже были добавлены такие возможности, как ISPF , для интерфейсов, управляемых формами. ^[3]

MVS сделала большой шаг вперед в отказоустойчивости, построенной на более ранней возможности STAE, которую IBM назвала восстановлением программного обеспечения . IBM решила сделать это после многих лет практического реального опыта с MVT в деловом мире. Системные сбои теперь оказывали серьезное влияние на бизнес клиентов, и IBM решила сделать большой скачок в проектировании, предположив, что, несмотря на самые лучшие методы разработки и тестирования программного обеспечения, «проблемы БУДУТ возникать». Это глубокое предположение сыграло решающую роль в добавлении большого процента кода отказоустойчивости в систему и, вероятно, способствовало успеху системы в устойчивости к программным и аппаратным сбоям. Трудно получить статистическую информацию, чтобы доказать ценность этих конструктивных особенностей (как можно измерить «предотвращенные» или «восстановленные» проблемы?), но IBM во многих измерениях улучшила эти функции восстановления отказоустойчивого программного обеспечения и быстрого решения проблем с течением времени.

Эта конструкция определила иерархию программ обработки ошибок в системном (ядро/'привилегированный') режиме, называемых Функциональными Процедурами Восстановления, и в пользовательском ('задача' или 'проблемная программа') режиме, называемых "ESTAE" (Расширенные процедуры аварийного выхода из заданной задачи), которые вызываются в случае, если система обнаруживает ошибку (ошибка аппаратного процессора или хранилища, или программная ошибка). Каждая процедура восстановления делала функцию 'mainline' повторно вызываемой, захватывала диагностические данные об ошибках, достаточные для отладки вызывающей проблемы, и либо 'повторяла' (повторно вызывала основную линию), либо 'просачивалась' (обработка ошибок распространялась на следующую процедуру восстановления в иерархии).

Таким образом, при каждой ошибке система собирала диагностические данные и пыталась выполнить ремонт и поддерживать систему в рабочем состоянии. Худшим из возможных вариантов было отключение пользовательского адресного пространства («задания») в случае неисправленных ошибок. Хотя это была первоначальная точка проектирования, только в последней версии MVS (z/OS) программа восстановления не только получила собственную процедуру восстановления, но и каждая процедура восстановления теперь имеет собственную процедуру восстановления. Эта структура восстановления была встроена в базовую программу управления MVS, а программные средства доступны и используются разработчиками прикладных программ и сторонними разработчиками.

На практике восстановление программного обеспечения MVS сделало отладку проблем и проще, и сложнее. Восстановление программного обеспечения требует, чтобы программы оставляли «следы» того, где они находятся и что они делают, тем самым облегчая отладку, но тот факт, что обработка продолжается, несмотря на ошибку, может перезаписать следы. Ранний сбор данных во время ошибки максимизирует отладку, и существуют возможности для процедур восстановления (режим задачи и системный режим, оба) сделать это.

IBM включила дополнительные критерии для серьезной проблемы с программным обеспечением, которая требовала обслуживания IBM. Если основной компонент не мог инициировать восстановление программного обеспечения, это считалось допустимым отказом, о котором следует сообщать. Кроме того, если процедура восстановления не могла собрать существенные диагностические данные, чтобы исходная проблема могла быть решена с помощью данных, собранных этой процедурой восстановления, стандарты IBM диктовали, что эта ошибка должна быть сообщена и требует ремонта. Таким образом, стандарты IBM, при их строгом применении, поощряли постоянное совершенствование.

IBM продолжала поддерживать основной инструмент обслуживания Dynamic Support System ^[4] (DSS), который она представила в OS/VS1 и OS/VS2 Release 1. Этот интерактивный инструмент можно было вызвать для инициирования сеанса для создания диагностических процедур или вызова уже сохраненных процедур. Процедуры перехватывали специальные события, такие как загрузка программы, ввод-вывод устройства, вызовы системных процедур, а затем запускали активацию ранее определенных процедур. Эти процедуры, которые можно было вызывать рекурсивно, позволяли считывать и записывать данные, а также изменять поток инструкций. Использовалось оборудование для записи событий программы.

IBM прекратила поддержку DSS с Selectable Unit 7 (SU7), обновлением OS/VS2 Release 3.7, требуемым программным продуктом OS/VS2 MVS/System Extensions (MVS/SE), номер программы 5740-XEl. Группа пользователей SHARE приняла требование, чтобы IBM восстановила DSS, и IBM предоставила PTF , чтобы разрешить использование DSS после установки MVS/SE.

IBM снова прекратила поддержку DSS в SU64, обновлении OS/VS2 Release 3.8, необходимом для Release 2 MVS/SE.

Эксплуатация записи событий программы (PER) осуществлялась путем усовершенствования диагностической команды SLIP с введением поддержки PER (SLIP/Per) в SU 64/65 (1978).

Несколько копий MVS (или других операционных систем IBM) могли совместно использовать одну и ту же машину, если эта машина управлялась VM/370 . В этом случае VM/370 была реальной операционной системой и рассматривала «гостевые» операционные системы как приложения с необычно высокими привилегиями. В результате более поздних усовершенствований оборудования один экземпляр операционной системы (MVS, или VM с гостями, или другой) также мог занимать логический раздел (LPAR) вместо всей физической системы.

Несколько экземпляров MVS могут быть организованы и совместно администрироваться в структуре, называемой системным комплексом или сисплексом , представленной в сентябре 1990 года. Экземпляры взаимодействуют через программный компонент, называемый Cross-system Coupling Facility (XCF), и аппаратный компонент, называемый Hardware Coupling Facility (CF или Integrated Coupling Facility, ICF, если они размещены на одном и том же оборудовании мэйнфрейма). Несколько сисплексов могут быть объединены через стандартные сетевые протоколы, такие как фирменная архитектура IBM Systems Network Architecture (SNA) или, в последнее время, через TCP/IP . Операционная система z/OS (последний потомок MVS) также имеет встроенную поддержку для выполнения приложений POSIX и Single UNIX Specification . Поддержка началась с MVS/SP V4R3, и IBM получила сертификацию UNIX 95 для z/OS V1R2 и более поздних версий. ^[5]

Система обычно используется в бизнесе и банковском деле, а приложения часто пишутся на языке COBOL . Программы на языке COBOL традиционно использовались с системами обработки транзакций, такими как IMS и CICS . Для программы, работающей в CICS, в исходный код COBOL вставляются специальные операторы EXEC CICS. Препроцессор (транслятор) заменяет эти операторы EXEC CICS соответствующим кодом COBOL для вызова CICS до компиляции программы — не совсем так, как SQL, используемый для вызова DB2 . Приложения также могут быть написаны на других языках, таких как C , C++ , Java , язык ассемблера , FORTRAN , BASIC , RPG и REXX . Поддержка языка упакована как общий компонент, называемый «Языковая среда» или «LE», чтобы обеспечить единообразную отладку, трассировку, профилирование и другие независимые от языка функции.

Системы MVS традиционно доступны через терминалы 3270 или ПК с эмуляторами 3270. Однако многие приложения для мэйнфреймов в наши дни имеют собственные веб- интерфейсы или GUI -интерфейсы. Операционная система z/OS имеет встроенную поддержку TCP/IP . Управление системой, которое в прошлом выполнялось с помощью терминала 3270, теперь осуществляется через консоль управления оборудованием (HMC) и, все чаще, через веб-интерфейсы. Консоли оператора предоставляются через эмуляторы 2074, поэтому вы вряд ли увидите какой-либо процессор S/390 или zSeries с реальным подключенным к нему 3270.

Собственная схема кодировки символов MVS и его периферийных устройств — EBCDIC , но инструкция TR упрощает перевод в другие 7- и 8-битные коды. Со временем IBM добавила аппаратно-ускоренные службы для выполнения перевода в более крупные коды и между ними, аппаратно-специфическую службу для преобразований Unicode и программную поддержку, например, ASCII , ISO/IEC 8859 , UTF-8 , UTF-16 и UTF-32 . Службы программного перевода принимают исходные и целевые кодовые страницы в качестве входных данных.

Файлы, отличные от файлов Unix, правильно называются наборами данных в MVS. Имена этих файлов организованы в каталоги, которые сами являются файлами VSAM .

Имена наборов данных (DSN, термин мэйнфреймов для имен файлов) организованы в иерархию, уровни которой разделены точками, например, "DEPT01.SYSTEM01.FILE01". Каждый уровень в иерархии может быть длиной до восьми символов. Общая длина имени файла составляет максимум 44 символа, включая точки. По соглашению, компоненты, разделенные точками, используются для организации файлов аналогично каталогам в других операционных системах. Например, существуют служебные программы, которые выполняют функции, аналогичные функциям Windows Explorer (но без графического интерфейса и обычно в режиме пакетной обработки ) - добавление, переименование или удаление новых элементов и отчет обо всем содержимом указанного элемента. Однако, в отличие от многих других систем, эти уровни обычно не являются ^{[NB 4]} фактическими каталогами, а просто соглашением об именовании (как в оригинальной файловой системе Macintosh , где иерархия папок была иллюзией, поддерживаемой Finder). TSO поддерживает префикс по умолчанию для файлов (аналогично концепции «текущего каталога»), а RACF поддерживает настройку контроля доступа на основе шаблонов имен файлов, аналогично контролю доступа к каталогам на других платформах.

Как и в случае с другими членами семейства ОС, наборы данных MVS ориентированы на записи . MVS унаследовал от своих предшественников три основных типа:

• Последовательные наборы данных обычно считывались по одной записи за раз от начала до конца.
• В наборах данных BDAM (прямой доступ) прикладная программа должна была указать физическое местоположение данных, к которым она хотела получить доступ (обычно путем указания смещения от начала набора данных).
• В наборах данных ISAM указанный раздел каждой записи определялся как ключ, который можно было использовать в качестве ключа для поиска определенных записей. Ключ довольно часто состоял из нескольких полей , но они должны были быть смежными и располагаться в правильном порядке; а значения ключей должны были быть уникальными. Следовательно, файл IBM ISAM мог иметь только один ключ, эквивалентный первичному ключу таблицы реляционной базы данных ; ISAM не мог поддерживать внешние ключи .

Последовательные и ISAM-наборы данных могут хранить записи как фиксированной, так и переменной длины, и все типы могут занимать более одного тома на диске.

Все они основаны на структуре диска VTOC .

Ранние системы управления базами данных IBM использовали различные комбинации наборов данных ISAM и BDAM — обычно BDAM для фактического хранения данных и ISAM для индексов.

В начале 1970-х годов операционные системы виртуальной памяти IBM представили новый компонент управления файлами VSAM , который предоставлял схожие возможности:

• Наборы данных с последовательностью записей (ESDS) предоставляют возможности, аналогичные возможностям последовательных наборов данных и наборов данных BDAM, поскольку их можно читать либо от начала до конца, либо напрямую, указав смещение от начала.
• Наборы данных с последовательностью ключей (KSDS) представляют собой существенное усовершенствование ISAM: они допускают вторичные ключи с неуникальными значениями и ключи, сформированные путем объединения несмежных полей в любом порядке; они значительно уменьшили проблемы с производительностью, вызванные переполнением записей в ISAM; и они значительно снизили риск того, что программный или аппаратный сбой во время обновления индекса может повредить индекс.

Эти форматы VSAM стали основой систем управления базами данных IBM , IMS/VS и DB2 — обычно ESDS для фактического хранения данных и KSDS для индексов.

VSAM также включал компонент каталога, используемый для пользовательских каталогов и главного каталога MVS.

Разделенные наборы данных (PDS) — это последовательные наборы данных, подразделенные на «члены», каждый из которых может обрабатываться как последовательный файл по своему собственному праву (как папка в файловой системе). Наиболее важным применением PDS было для библиотек программ — системные администраторы использовали основной PDS как способ выделения дискового пространства для проекта, а затем команда проекта создавала и редактировала членов. Другие применения PDS — это библиотеки часто используемых процедур управления заданиями (PROC) и «копировальные книги» операторов языка программирования, таких как определения записей, используемые несколькими программами.

Группы данных поколений (GDG) — это группы наборов данных с одинаковыми именами, на которые можно ссылаться по абсолютному номеру поколения или по смещению от самого последнего поколения. Изначально они были разработаны для поддержки процедур резервного копирования «дед-отец-сын» — если файл был изменен, измененная версия становилась новым «сыном», предыдущий «сын» становился «отцом», предыдущий «отец» становился «дедушкой», а предыдущий «дедушка» удалялся. Но можно было настроить GDG с более чем 3 поколениями, и некоторые приложения использовали GDG для сбора данных из нескольких источников и передачи информации в одну программу — каждая программа сбора создавала новое поколение файла, а конечная программа считывала всю группу как один последовательный файл (не указывая поколение в JCL ).

Современные версии MVS (например, z/OS) используют наборы данных в качестве контейнеров для файловых систем Unix вместе с возможностями для их частичной интеграции. То есть программы Unix, использующие fopen(), могут получить доступ к набору данных MVS, а пользователь может выделить файл Unix, как если бы это был набор данных, с некоторыми ^{[NB 5]} ограничениями. Иерархическая файловая система (HFS) (не путать с иерархической файловой системой Apple ) использует уникальный тип набора данных, в то время как более новая файловая система z/OS (zFS) (не путать с ZFS от Sun ) использует линейный набор данных VSAM (LDS).

Программы, работающие на компьютерах, подключенных к сети (например, IBM AS/400 ), могут использовать локальные интерфейсы управления данными для прозрачного создания, управления и доступа к файлам VSAM, ориентированным на записи, с помощью клиент-серверных продуктов, реализованных в соответствии с архитектурой распределенного управления данными (DDM). DDM также является базовой архитектурой для сервера MVS DB2 , который реализует архитектуру распределенной реляционной базы данных (DRDA).

MVS включает в себя функцию виртуального ввода-вывода (VIO), с помощью которой временные наборы данных могут храниться в моделируемых дорожках в страничных наборах данных, что устраняет накладные расходы на выделение памяти, но добавляет некоторые накладные расходы на обработку.

В дополнение к новым функциям, которые IBM добавила с выпусками и суб-выпусками OS/VS2, IBM предоставила ряд бесплатных выпусков Incremental Change Releases (ICR) и Selectable Units (SU), а также платные программные продукты и разработанные на местах программы, которые IBM в конечном итоге включила в состав z/OS. К ним относятся:

• ACF/TCAM (5735-RCl)
• ACF/VTAM (5746-RC3, 5735-RC2)
• Поддержка устройств/устройств обработки данных (DF/DS), 5740-AM7
• Расширенная функция Data Facility (DF/EF), 5740-XYQ
• Службы обработки данных/наборов данных (DF/DSS), 5740-UT3.
• Сортировка объектов данных, 5740-SM1
• OS/VS2 MVS Метод последовательного доступа-расширенный (SAM-E), 5740-AM3
• Продукт MVS/370 Data Facility (DFP), 5665-295, заменяющий
  • 5740-AM7 Поддержка устройств обработки данных (DFDS)
  • Расширенная функция устройства обработки данных 5740-XYQ (DFEF)
  • 5740-AM3 Метод последовательного доступа расширенный (SAM-E)
  • 5740-AM8 Метод доступа Услуги Криптографическая опция
  • 5748-UT2 Оффлайн 3800 Утилита
• Продукт MVS/XA Data Facility, версия 1, выпуск 1, 5665-284
• Продукт MVS/XA Data Facility версии 2, выпуск 1, 5665-XA2
• Продукт MVS/ESA Data Facility версии 3, 5665-XA3
• Подсистема управления хранилищем данных (DFSMS), 5695-DF1
  Заменяет DFP, DF/DSS и DF/HSM
• Пакет команд OS/VS2 MVS TSO (5740-XT6)
• Процессор команд TSO - FDP 5798-AYF (команда PRINT)
• Программное средство управления TSO/VS2 - FDP 5798-BBJ
• TSO Программирование Управляющего Устройства - II (PCF II), FDP 5798-CLW,
• Расширения TSO
  заменяют пакет команд TSO, процессор команд TSO и PCF
  • 5665-285 для МВС/370
  • 5665-293 для МВС/ХА
  • 5685-025 для MVS/XA
    Первая версия с REXX
• OS/VS2 MVS/Системные расширения, 5740-XEl
• MVS/Системный продукт
  • JES3 Версия 1 5740-XYN
  • JES2 Версия 1 5740-XYS
  • MVS/System Product-JES2 Версия 2, 5740-XC6
  • MVS/System Product-JES3 Версия 2, 5665-291
  • MVS/System Product-JES2 Версия 3, 5685-001
  • MVS/System Product-JES3 Версия 3, 5685-002
  • Продукт системы MVS/ESA: JES2 Версия 4, 5695-047
  • Продукт системы MVS/ESA: JES3 Версия 4, 5695-048
  • Продукт системы MVS/ESA: JES2 Версия 5, 5655-068
  • Продукт системы MVS/ESA: JES3 Версия 5, 5655-069

В конце семидесятых и начале восьмидесятых годов IBM объявила:

• 5740-AM7 Поддержка устройств передачи данных (DF/DS)
• Расширенная функция устройства обработки данных 5740-XYQ (DF/EF)
• 5740-AM3 Метод последовательного доступа расширенный (SAM-E)
• 5740-AM8 Метод доступа Услуги Криптографическая опция
• 5748-UT2 Оффлайн 3800 Утилита

DF/DS добавила поддержку новых устройств, и IBM объявила, что больше не будет добавлять поддержку устройств в бесплатную базу. DF/EF добавила улучшенную структуру каталога (ICF) в качестве альтернативы каталогам VSAM и контрольным томам (CVOL), но она была пронизана проблемами надежности.

Когда IBM анонсировала ^[6] MVS/SP Version 2 (MVS/XA), она также анонсировала ^[7] Data Facility Product™ (DFP™) в качестве замены и обновления для других пяти продуктов, указанных выше, которые, как она заявила, будут сняты с продажи с 1 декабря 1984 года. DFP/370 Release 1 (номер программы 5665-295), анонсированная 7 июня 1983 года, была предназначена для MVS/SP Version 1, MVS/SE и OS/VS2 R3.8 и была необязательной, но MVS/Extended Architecture Data Facility Product (5665-284) была сопутствующим условием для MVS/SP Version 2 (MVS/XA). В дополнение к улучшению возможностей управления данными, DFP заменила бесплатные версии редактора связей и утилит.

DFP больше не доступен как отдельный продукт, но стал частью подсистемы управления хранилищем данных под названием DFSMSdfp .

MVS теперь эволюционировал в z/OS; старые версии MVS больше не поддерживаются IBM, и с 2007 года поддерживаются только 64-разрядные версии z/OS. z/OS поддерживает запуск старых 24- и 31-разрядных приложений MVS наряду с новыми 64-разрядными приложениями.

Выпуски MVS до версии 3.8j (24-бит, выпущен в 1981 году) были доступны бесплатно, и теперь можно бесплатно запустить выпуск MVS 3.8j в эмуляторах мэйнфреймов, таких как Hercules Emulator . ^[8]

MVS/370 — это общее название для всех версий операционной системы MVS до MVS/XA. ^{[NB 6]} Архитектура System/370 на момент выпуска MVS поддерживала только 24-битные виртуальные адреса, поэтому архитектура операционной системы MVS/370 основана на 24-битном адресе. Из-за этой 24-битной длины адреса программам, работающим под MVS/370, выделяется 16 МБ непрерывной виртуальной памяти.

MVS/XA , или Multiple Virtual Storage/Extended Architecture , была версией MVS, которая поддерживала архитектуру 370-XA , которая имела новую архитектуру ввода-вывода, а также расширяла адреса с 24 бит до 31 бита, предоставляя  адресуемую область памяти размером 2 гигабайта . ^[9] MVS/XA поддерживала 24-битный устаревший режим адресации для старых 24-битных приложений (т. е. тех, которые хранили 24-битный адрес в нижних 24 битах 32-битного слова и использовали верхние 8 бит этого слова для других целей).

Архитектура корпоративных систем MVS ( MVS/ESA ) — это любая версия MVS до OS/390 , которая поддерживает архитектуру корпоративных систем S/370 (S/370-ESA). MVS/ESA расширяет 24-битные и 31-битные режимы адресации MVS/XA, добавляя режим регистра доступа (AR) для ссылок между адресными пространствами.

IBM представила ^[10] MVS/ESA как MVS/SP версии 3 в феврале 1988 года, затем MVS/ESA SP версии 4 ^[11] и MVS/ESA SP версии 5. ^[12] IBM заменила его на OS/390 ^{[13] [14]} в конце 1995 года, а затем на z/OS .

MVS/ESA OpenEdition: обновление до версии 4 Release 3 MVS/ESA SP, анонсированное ^[15] февраля 1993 г. с поддержкой POSIX и других стандартов. ^{[16] [17] [18]} Хотя первоначальный выпуск имел только сертификацию Национального института стандартов и технологий (NIST) на соответствие Федеральному стандарту обработки информации (FIPS) 151, последующие выпуски были сертифицированы на более высоких уровнях и другими организациями, например, X/Open и его преемником The Open Group. Он включал около 1 миллиона новых строк кода, которые предоставляют оболочку API, утилиты и расширенный пользовательский интерфейс. Работает с иерархической файловой системой, предоставленной DFSMS (Data Facility System Managed Storage). Оболочка и утилиты основаны на продуктах InterOpen Мортиса Кернса . Независимые специалисты оценивают, что он более чем на 80% соответствует открытым системам — больше, чем большинство систем Unix. Поддержка DCE2 была объявлена ​​в феврале 1994 года, а многие инструменты разработки приложений — в марте 1995 года. С середины 1995 года, когда все открытые функции стали стандартной частью vanilla MVS/ESA SP Version 5 Release 1, IBM перестала отличать OpenEdition от операционной системы. В OS/390 V2R6 она стала UNIX System Services , ^{[19] [20]} и сохранила это название в z/OS .

В конце 1995 года IBM объединила MVS с несколькими программными продуктами и изменила название с MVS/ESA на OS/390.

Текущий уровень MVS позиционируется как z/OS.

Японские производители мэйнфреймов Fujitsu и Hitachi неоднократно и незаконно получали исходный код MVS и внутреннюю документацию IBM в одном из самых известных случаев промышленного шпионажа 20-го века . ^[21] Fujitsu в значительной степени полагалась на код IBM в своей операционной системе для мэйнфреймов MSP , и Hitachi сделала то же самое для своей операционной системы VOS3. MSP и VOS3 активно продавались в Японии, где они по-прежнему занимают существенную долю установленной базы мэйнфреймов, но также в некоторой степени и в других странах, в частности в Австралии. Даже ошибки и опечатки в документации IBM были добросовестно скопированы. IBM сотрудничала с Федеральным бюро расследований США в спецоперации , неохотно поставляя Fujitsu и Hitachi фирменные технологии MVS и оборудования для мэйнфреймов в ходе многолетних расследований, кульминацией которых стало начало 1980-х годов, — расследований, в которых были замешаны старшие менеджеры компании и даже некоторые японские правительственные чиновники. Однако Амдал не был замешан в краже Fujitsu интеллектуальной собственности IBM . Любые сообщения от Амдала к Fujitsu осуществлялись через «Amdahl Only Specifications», которые были тщательно очищены от любой интеллектуальной собственности IBM или любых ссылок на интеллектуальной собственности IBM.

После расследований IBM достигла многомиллионных соглашений с Fujitsu и Hitachi, собирая существенные доли прибыли обеих компаний в течение многих лет. Надежные отчеты указывают, что соглашения превысили 500 000 000 долларов США. ^{[ необходима цитата ] [21] [NB 7]}

Три компании давно уже полюбовно договорились о многих совместных предприятиях. Например, в 2000 году IBM и Hitachi сотрудничали в разработке модели мэйнфрейма IBM z900.

Из-за этого исторического копирования MSP и VOS3 по праву классифицируются как «ответвления» MVS, и многие сторонние поставщики программного обеспечения с продуктами, совместимыми с MVS, смогли создать версии, совместимые с MSP и VOS3, с небольшими изменениями или без них. ^{[22] [23] [24]}

Когда IBM представила свои 64-битные мэйнфреймы z/Architecture в 2000 году, IBM также представила 64-битную операционную систему z/OS, прямую преемницу OS/390 и MVS. Fujitsu и Hitachi решили не лицензировать z/Architecture от IBM для своих квази-MVS операционных систем и аппаратных систем, и поэтому MSP и VOS3, хотя и по-прежнему номинально поддерживаются их поставщиками, сохраняют большинство архитектурных ограничений MVS 1980-х годов по сей день. Поскольку z/OS по-прежнему поддерживает приложения и технологии эпохи MVS — z/OS по-прежнему содержит большую часть кода MVS, хотя и значительно улучшенного и усовершенствованного за десятилетия эволюции — приложения (и операционные процедуры), работающие на MSP и VOS3, могут перейти на z/OS гораздо проще, чем на другие операционные системы.

• Hercules — эмулятор S/370, S/390 и zSeries, способный запускать MVS
• Служебные программы, поставляемые с операционными системами MVS (и последующими версиями)
• BatchPipes — это утилита пакетной обработки заданий , разработанная для операционной системы MVS/ESA и всех более поздних версий — OS/390 и z/OS .

• IBM: z/OS V1R11.0 MVS Руководства на Wayback Machine (архив 2009-09-05)
• IBM: руководства z/OS V1R8.0 MVS на Wayback Machine (архив 2006-11-04)
• MVS: операционная система, которая поддерживает работу мира на Wayback Machine (архив 2001-06-30)
• MVS... долгая история в Wayback Machine (архив 2001-07-16)
• AL Scherr (декабрь 1973 г.). «Функциональная структура операционных систем виртуального хранения IBM. Часть II: концепции и философия OS/VS2-2». IBM Systems Journal . 12 (4). IBM: 382– 400. doi :10.1147/sj.124.0382.