MVS - MVS

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

Разработчик	IBM
Семейство ОС	MVS
изначальный выпуск	1974; 46 лет назад (1974)
Маркетинговая цель	Мэйнфреймы IBM
Доступно в	английский
Платформы	Система / 370, Система / 390
Лицензия	Проприетарный

Множественное виртуальное хранилище, чаще называемый MVS, был наиболее часто используемым Операционная система на Система / 370 и Система / 390 Мэйнфреймы IBM. IBM разработала MVS вместе с OS / VS1 и SVS, как преемник OS / 360. Это не связано с другими линиями операционных систем для мэйнфреймов IBM, например, ВСЕ, ВМ, TPF.

Обзор

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

• сначала в MVS / SE (MVS / системные расширения),^{[NB 1]}
• рядом с MVS / SP (MVS / Системный продукт) версии 1,
• рядом с MVS / XA (MVS / eXtended Architecture),
• рядом с MVS / ESA (MVS / Архитектура корпоративных систем),
• затем к OS / 390 и
• наконец, чтобы z / OS (когда 64-битный поддержка была добавлена ​​с zСерия модели). IBM добавила поддержку UNIX (первоначально называлась OpenEdition MVS ) в MVS / SP V4.3 и получил POSIX и UNIX ™ сертификаты на нескольких разных уровнях от IEEE, X / Открыть и Открытая группа. Ядро MVS по сути остается той же операционной системой. По задумке программы, написанные для MVS, работают в z / OS без изменений.

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

Эволюция MVS

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

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

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

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

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

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

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

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

Основные пользовательские интерфейсы к MVS: Язык управления заданиями (JCL), который изначально был разработан для пакетная обработка но с 1970-х годов также использовался для запуска и распределения ресурсов для долгосрочных интерактивный рабочие места, такие как CICS; и TSO (Вариант разделения времени), интерактивный совместное времяпровождение интерфейс, который в основном использовался для запуска инструментов разработки и нескольких информационных систем для конечных пользователей. ISPF это приложение TSO для пользователей 3270-семья терминалы (а позже и на виртуальной машине), что позволяет пользователю выполнять те же задачи, что и TSO. командная строка но с ориентацией на меню и формы, с полноэкранным редактором и файловым браузером. Базовый интерфейс TSO командная строка, хотя средства были добавлены позже для интерфейсов, управляемых формами).

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

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

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

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

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

IBM продолжала поддерживать основной инструмент повышения удобства обслуживания Dynamic Support System^[1] (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. Группа пользователей ПОДЕЛИТЬСЯ приняла требование, чтобы IBM восстановила DSS, и IBM предоставила ПТФ чтобы разрешить использование 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, либо виртуальная машина с гостями, либо другой) также может занимать Логический раздел (LPAR) вместо всей физической системы.

Несколько экземпляров MVS могут быть организованы и совместно администрированы в структуре, называемой комплекс систем или же сисплекс, представленный в сентябре 1990 года. Экземпляры взаимодействуют через программный компонент, называемый Межсистемное соединение (XCF) и аппаратный компонент, называемый Аппаратное соединение (CF или Integrated Coupling Facility, ICF, если они расположены на одном оборудовании мэйнфрейма). Несколько систем можно объединить с помощью стандартных сетевых протоколов, таких как собственный протокол IBM. Системная сетевая архитектура (СНС) или, в последнее время, через TCP / IP. Операционная система z / OS (последний потомок MVS) также имеет встроенную поддержку для выполнения POSIX и Единая спецификация UNIX Приложения. Поддержка началась с MVS / SP V4R3, а IBM получила сертификат UNIX 95 для z / OS V1R2 и более поздних версий.^[2]

Система обычно используется в бизнесе и банковском деле, а приложения часто пишутся на КОБОЛ. Программы COBOL традиционно использовались с системами обработки транзакций, такими как IMS и CICS. Для программы, работающей на CICS, специальные операторы EXEC CICS вставляются в исходный код COBOL. Препроцессор (транслятор) заменяет эти операторы EXEC CICS на соответствующий код COBOL для вызова CICS перед компиляцией программы - в общем, в отличие от SQL раньше звонил DB2. Приложения также могут быть написаны на других языках, например C, C ++, Ява, язык ассемблера, FORTRAN, БАЗОВЫЙ, РПГ, и REXX. Языковая поддержка представлена ​​в виде общего компонента, называемого «Language Environment» или «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. Службы перевода программного обеспечения принимают исходную и целевую кодовые страницы в качестве входных данных.

Файловая система MVS

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

Имена наборов данных (DSN, термин мэйнфрейма для имен файлов) организованы в иерархию, уровни которой разделены точками, например "DEPT01.SYSTEM01.FILE01". Каждый уровень иерархии может содержать до восьми символов. Общая длина имени файла не должна превышать 44 символа, включая точки. По соглашению компоненты, разделенные точками, используются для организации файлов аналогично каталоги в других операционных системах. Например, были служебные программы, которые выполняли функции, аналогичные функциям проводник Виндоус (но без GUI и обычно в пакетная обработка mode) - добавление, переименование или удаление новых элементов и отчет обо всем содержимом указанного элемента. Однако, в отличие от многих других систем, эти уровни обычно не^{[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) (не путать с Sun ZFS ) использует набор линейных данных VSAM (LDS).

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

Обновления до MVS

В дополнение к новой функциональности, которую IBM добавила с выпусками и дополнительными выпусками OS / VS2, IBM предоставила ряд бесплатных выпусков с постепенными изменениями (ICR) и выбираемых модулей (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.
• Data Facility Sort, 5740-SM1
• OS / VS2 Расширенный метод последовательного доступа MVS (SAM-E), 5740-AM3
• MVS / 370 Data Facility Product (DFP), 5665-295
• Версия продукта 1 средства обработки данных MVS / XA, выпуск 1, 5665-284
• Продукт MVS / XA Data Facility, версия 2, выпуск 1, (https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/897/ENUS285-030/index.html&request_locale=en 5665-XA2]
• Продукт средства обработки данных MVS / ESA, версия 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 для MVS / 370
  • 5665-293 для MVS / XA
  • 5685-025 для MVS / XA
    Первая версия с REXX
• OS / VS2 MVS / Системные расширения, 5740-XEl
• MVS / Системный продукт
  • JES3 Версия 1 5740-XYN
  • JES2 Версия 1 5740-XYS
  • MVS / Системный продукт-JES2 Версия 2, 5740-XC6
  • MVS / Системный продукт-JES3 Версия 2, 5665-291
  • MVS / Системный продукт-JES2 Версия 3, 5685-001
  • MVS / Системный продукт-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

Современный MVS

MVS работает на Геркулес эмулятор

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

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

MVS / 370

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

MVS / XA

MVS / XA, или же Множественное виртуальное хранилище / Расширенная архитектура, была версией MVS, которая поддерживала 370-XA архитектура, которая расширила адреса с 24 бит до 31 бит, обеспечивая 2гигабайт адресуемая область памяти.^[4] Он также поддерживал 24-битный унаследованный режим адресации для старых 24-битных приложений (т.е. тех, которые сохраняли 24-битный адрес в младших 24 битах 32-битного слова и использовали старшие 8 бит этого слова для других целей) .

МВС / ЕКА

МВС / ЕКА: Архитектура корпоративной системы MVS. Версия MVS, впервые представленная как MVS / SP Version 3 в феврале 1988 г. Заменена на / переименована в OS / 390 в конце 1995 г., а затем в z / OS.

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

OS / 390

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

z / OS

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

Близко связанные операционные системы

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

После расследований IBM достигла многомиллионных расчетов с Fujitsu и Hitachi, получая значительную долю прибыли обеих компаний в течение многих лет. По достоверным отчетам сумма расчетов превысила 500 000 000 долларов США.^{[нужна цитата ][10]:в показаниях Конгресса в самом конце говорится только: «Hitachi еще не признала, что какие-либо секреты IBM использовались при разработке новых продуктов, и они еще не компенсировали IBM огромные расходы, связанные с урегулированием дела».}

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

Из-за этого исторического копирования MSP и VOS3 правильно классифицируются как "вилки" MVS, и многие сторонние поставщики программного обеспечения с MVS-совместимыми продуктами смогли создать MSP- и VOS3-совместимые версии с небольшими изменениями или без них.^[11][12][13]

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

Смотрите также

• Геркулес эмулятор S / 370, S / 390 и zSeries, способный запускать MVS
• Служебные программы поставляется с операционными системами MVS (и последующих)
• BatchPipes это пакетная обработка заданий утилита, предназначенная для МВС / ЕКА операционная система, и все более поздние версии -OS / 390 и z / OS.

Примечания

Рекомендации

• Боб Дюшарм: "Руководство по операционным системам, часть 06: MVS" (доступно в Интернете Вот )
• Обзор OS / VS2 MVS (PDF). Первое издание. IBM. Июнь 1978 года. GC28-0984-0. Архивировано из оригинал (PDF) 16 марта 2011 г.

внешняя ссылка

• IBM: z / OS V1R11.0 MVS Руководства
• IBM: z / OS V1R8.0 MVS руководства
• MVS: операционная система, которая поддерживает мир
• МВС ... долгая история
• Функциональная структура операционных систем виртуального хранения IBM. Часть II: концепции и философия OS / VS2-2. Автор: А. Л. Шерр