МВС

Чтобы узнать о других значениях, см. MVS (значения) .

Несколько виртуальных хранилищ (MVS)

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

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

Обзор

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

• сначала MVS/SE (MVS/System Extensions),
• рядом с MVS/SP (MVS/System Product) версии 1,
• рядом с MVS/XA (MVS/расширенная архитектура),
• рядом с MVS/ESA (архитектура MVS/корпоративных систем),

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

• на 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 Release 1 представляет собой обновление OS/360 MVT , которое сохранило большую часть исходного кода и, как и MVT, в основном написано на языке ассемблера . Ядро MVS почти полностью написано на Assembler XF , хотя несколько модулей были написаны на PL/S , но не тех, которые чувствительны к производительности, в частности, супервизора ввода/вывода (IOS). Использование IBM «OS/VS2» подчеркивало совместимость снизу вверх: прикладные программы, работавшие под управлением MVT, даже не нуждались в перекомпиляции для работы под управлением MVS. Те же файлы языка управления заданиями можно использовать без изменений; коммунальные услуги и другие непрофильные объекты, такие как TSO, работали без изменений. IBM и пользователи с самого начала почти единогласно назвали новую систему MVS, и IBM продолжала использовать термин MVS в названии более поздних основных версий, таких как MVS/XA.

Эволюция МВС

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

OS/360 MVT (Мультипрограммирование с переменным количеством задач) было усовершенствованием, которое еще больше усовершенствовало использование памяти. Вместо использования разделов памяти фиксированного размера 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.

Адресные пространства MVS — глобальный вид MVS (общая часть всех адресных пространств) Приложение 1 Приложение 2 Приложение 3 Общая виртуальная область (контролируется MVS)

Вид одного приложения МВС Приложение 1 Общая виртуальная область

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

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

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

Многопроцессорные системы либо слабо связаны, что означает, что каждый компьютер имеет доступ к общей рабочей нагрузке, либо тесно связаны , что означает, что компьютеры используют одно и то же реальное хранилище и управляются одной копией операционной системы . MVS сохранил как слабосвязанную многопроцессорную обработку ( Attached Support Processor ASP), так и и тесно связанная многопроцессорность OS/360 Model 65 Multiprocessing . В тесно связанных системах два ЦП имеют одновременный доступ к одной и той же памяти (и копии операционной системы) и периферийным устройствам, обеспечивая большую вычислительную мощность и определенную степень постепенного снижения производительности в случае сбоя одного ЦП. В слабосвязанных конфигурациях каждый из группы процессоров (одиночных и/или сильно связанных) имел собственную память и операционную систему, но общую периферию и компонент операционной системы JES3 позволял управлять всей группой с одной консоли. Это обеспечило большую отказоустойчивость и позволило операторам решать, какой процессор должен выполнять какие задания из центральной очереди заданий. MVS JES3 дал пользователям возможность объединить в сеть две или более системы обработки данных через общие диски и межканальные адаптеры (CTCA). Эта возможность в конечном итоге стала доступна пользователям JES2 как 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 является командная строка такие средства, как ISPF . , хотя для интерфейсов, управляемых формами, позже были добавлены

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

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

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

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

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

IBM продолжает поддерживать основной инструмент обеспечения удобства обслуживания Dynamic Support System. (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, либо виртуальная машина с гостями, либо другая) также мог занимать логический раздел (LPAR) вместо всей физической системы.

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

Система обычно используется в бизнесе и банковском деле, а приложения часто пишутся на 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. Однако в наши дни многие приложения для мэйнфреймов имеют собственные веб-интерфейсы или графические интерфейсы. Операционная система 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, в MVS . Имена этих файлов организованы в каталоги , которые сами являются файлами VSAM .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виртуальный ввод-вывод (ВИО)

MVS включает в себя средство под названием Virtual I/O (VIO), с помощью которого временные наборы данных могут храниться на смоделированных дорожках в наборах данных подкачки, устраняя накладные расходы на распределение, но добавляя некоторые накладные расходы на обработку.

Обновления до МВС

В дополнение к новым функциональным возможностям, которые IBM добавила в выпуски и подвыпуски OS/VS2, IBM предоставила ряд бесплатных выпусков с добавочными изменениями (ICR) и выбираемых модулей (SU), а также платных программных продуктов и программ, разработанных на месте, которые IBM в конечном итоге объединила как часть z/OS. К ним относятся:

Номера МВС СУ показывать

SU	SUID	SU name
1	5752-801	VTAM2
2	5752-802	TCAM 10
3	5752-803	JES2 Release 4
4	5752-804	Scheduler Improvements
5	5752-805	Supervisor Performance 1
6	5752-806	168AP
7	5752-807	Supervisor Performance 2
8	5752-808	Data Management Enhancements
9	5752-809
10	5752-810	3800 Support
12	5752-812	JES3 Release 2
13	5752-813	TSO/VTAM
15	5752-815	SMP
16	5752-816	Scheduler/IOS Support
17	5752-817	Service Data Improvements
18	5752-818	JES3 Release 3.1 MSS
21	5752-821	SSS Release 4
24	5752-824	3850 MSS Programming Enhancements
25	5752-825	JES2 Release 4.1 RJE 3790 Support
26	5752-826	JES3 RJP
27	5752-827	EREP Modifications
29	5752-829	3838 VPSS
30	5752-830	3895 Deposit System
32	5752-832	System Security Support
33	5752-833	MVS Dumping Improvements
36	5752-836	TCAM Direct (TCAM 10)
37	5752-837	SSS Release 5 TCAM Direct
47	5752-847	158/168 AP
48	5752-848	3800 12 Lines Per Inch
51	5752-851	Processor Support
55	5752-855	Hardware Recovery Enhancements
57	5752-857	IPCS
58	5752-858	TSO/VTAM Level 2
60	5752-860	Data Management Support
63	5752-863	SMP Release 3
64	5752-864	Processor Support 2
68	5752-868	DEMF (Display Exceprion Monitoring Program)

• ACF/TCAM (5735-RCl)
• АКФ/ВТАМ (5746-RC3, 5735-RC2)
• Поддержка средств обработки данных/устройств (DF/DS), 5740-AM7
• Расширенная функция средства обработки данных (DF/EF), 5740-XYQ
• Службы обработки данных/наборов данных (DF/DSS), 5740-UT3.
• Сортировка данных, 5740-SM1
• OS/VS2 MVS — расширенный метод последовательного доступа (SAM-E), 5740-AM3
• Продукт средства передачи данных MVS/370 (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, версия 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 для МВС/ХА
    Первая версия с 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.

Продукт для обработки данных (DFP)

Основная статья: Подсистема управления хранилищем данных (MVS)

В конце семидесятых и начале восьмидесятых 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 объявила MVS/SP версии 2 (MVS/XA), также анонсировано Data Facility Product™ (DFP™) в качестве замены и обновления пяти других вышеперечисленных продуктов, которые, по словам компании, будут сняты с продажи с 1 декабря 1984 года. Анонсирован выпуск DFP/370 Release 1 (номер программы 5665-295). 7 июня 1983 г. предназначалось для MVS/SP версии 1, MVS/SE и OS/VS2 R3.8 и было необязательным, но продукт MVS/Extended Architecture Data Facility (5665-284) был обязательным условием для MVS/SP версии 2. (МВС/ХА). Помимо улучшения возможностей управления данными, DFP заменил бесплатные версии редактора связей и утилит.

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

Современный МВС

MVS работает на Hercules эмуляторе

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 .

МВС/370

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

МВС/ХА

MVS/XA , или Multiple Virtual Storage/Extended Architecture , представляла собой версию MVS, которая поддерживала архитектуру 370-XA , которая имела новую архитектуру ввода-вывода, а также расширяла адреса с 24 бит до 31 бита, обеспечивая объемом 2 гигабайта. адресуемую память область. 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 представила MVS/ESA как MVS/SP версии 3 в феврале 1988 г., затем MVS/ESA SP версии 4 и MVS/ESA SP версии 5. IBM заменила его OS/390. в конце 1995 года, а затем и в z/OS .

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

ОС/390

Основная статья: OS/390

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

з/ОС

Основная статья: z/OS

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

Тесно связанные операционные системы

Дополнительная информация: jp:VOS3.

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

После расследования IBM заключила многомиллионные соглашения с Fujitsu и Hitachi, получив значительную часть прибыли обеих компаний в течение многих лет. Надежные отчеты показывают, что суммы выплат превысили 500 000 000 долларов США.

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

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

IBM представила свои 64-битные мэйнфреймы z/Architecture Когда в 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. гораздо проще, чем в других операционных системах.

См. также

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

Внешние ссылки

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