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:
а затем продлил
Сначала 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 (Мультипрограммирование с фиксированным числом задач) [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, поддерживающих многопроцессорные конфигурации, хотя вариант OS / 360 M65MP, работающий на 360 моделях 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 дал пользователям возможность объединить в сеть две или более системы обработки данных через общие диски и межканальные адаптеры (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 . [3]
MVS сделала большой шаг вперед в области отказоустойчивости, основанной на более раннем средстве STAE, которое IBM называла восстановлением программного обеспечения . IBM решила сделать это после многих лет практического опыта использования MVT в мире бизнеса. Системные сбои теперь оказывали серьезное влияние на бизнес клиентов, и IBM решила сделать серьезный скачок в проектировании, полагая, что, несмотря на самые лучшие методы разработки и тестирования программного обеспечения, «проблемы БУДУТ возникать». Это глубокое предположение сыграло решающую роль в добавлении в систему большого количества отказоустойчивого кода и, вероятно, способствовало успеху системы в устойчивости к сбоям программного и аппаратного обеспечения. Трудно найти статистическую информацию, чтобы доказать ценность этих конструктивных особенностей (как можно измерить «предотвращенные» или «устраненные» проблемы?), но IBM во многих аспектах улучшила отказоустойчивое программное восстановление и быстрое решение проблем. особенности с течением времени.
В этом проекте определена иерархия программ обработки ошибок: в системном режиме (ядро/привилегированный режим), называемом процедурами функционального восстановления, и в пользовательском режиме («задача» или «проблемная программа»), называемом «ESTAE» (расширенная заданная задача). процедуры аварийного выхода), которые вызываются в случае, если система обнаружила ошибку (ошибку аппаратного процессора или хранилища, или ошибку программного обеспечения). Каждая процедура восстановления делала функцию «основной линии» повторно вызываемой, собирала диагностические данные ошибок, достаточные для отладки вызывающей проблемы, и либо «повторяла» (повторно вызывала основную линию), либо «процеживала» (передавала обработку ошибок следующей процедуре восстановления в иерархии).
Таким образом, при каждой ошибке система собирала диагностические данные и пыталась выполнить ремонт и поддерживать систему в работоспособном состоянии. Худшее, что можно было сделать, — это отключить адресное пространство пользователя («задание») в случае неисправимых ошибок. Хотя это была первоначальная точка проектирования, только в самой последней версии 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, либо виртуальная машина с гостями, либо другая) также мог занимать логический раздел (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 и более поздних версий. [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. Однако в наши дни многие приложения для мэйнфреймов имеют собственные веб-интерфейсы или графические интерфейсы. Операционная система 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 (но без графического интерфейса и обычно в режиме пакетной обработки ) — добавление, переименование или удаление новых элементов и сообщение обо всем содержимом указанного элемента. Однако, в отличие от многих других систем, эти уровни обычно [NB 4] не являются настоящими каталогами, а просто соглашением об именах (как в исходной файловой системе Macintosh , где иерархия папок была иллюзией, поддерживаемой Finder). TSO поддерживает префикс по умолчанию для файлов (аналогично концепции «текущего каталога»), а RACF поддерживает настройку контроля доступа на основе шаблонов имен файлов, аналогично управлению доступом к каталогам на других платформах.
Как и другие члены семейства ОС, наборы данных MVS ориентированы на записи . МВС унаследовал от своих предшественников три основных типа:
Последовательные наборы данных и наборы данных ISAM могут хранить записи как фиксированной, так и переменной длины, и все типы могут занимать более одного дискового тома.
Все они основаны на дисковой структуре VTOC .
Ранние системы управления базами данных IBM использовали различные комбинации наборов данных ISAM и BDAM — обычно BDAM для фактического хранения данных и ISAM для индексов.
В начале 1970-х годов в операционных системах виртуальной памяти IBM появился новый компонент управления файлами VSAM , который предоставлял аналогичные возможности:
Эти форматы 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, как если бы это был набор данных, с некоторыми ограничениями [NB 5] . Иерархическая файловая система (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. К ним относятся:
В конце семидесятых и начале восьмидесятых IBM объявила:
DF/DS добавила поддержку новых устройств, а IBM объявила, что больше не будет добавлять поддержку устройств в бесплатную базу. DF/EF добавила улучшенную структуру каталога (ICF) в качестве альтернативы каталогам VSAM и контрольным томам (CVOL), но она была пронизана проблемами надежности.
Когда IBM анонсировала [6] MVS/SP версии 2 (MVS/XA), она также объявила [7] Data Facility Product™ (DFP™) в качестве замены и обновления пяти других вышеперечисленных продуктов, которые, по ее словам, будут отозваны. от маркетинга, вступает в силу 1 декабря 1984 г. Версия 1 DFP/370 (номер программы 5665-295), анонсированная 7 июня 1983 г., предназначалась для MVS/SP версии 1, MVS/SE и OS/VS2 R3.8 и была необязательной. , но продукт MVS/Extended Architecture Data Facility (5665-284) был обязательным условием для MVS/SP версии 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 в эмуляторах мэйнфреймов. [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 выпуска 3 MVS/ESA SP, анонсированного [15] февраля 1993 г., с поддержкой POSIX и других стандартов. [16] [17] [18] Хотя первоначальная версия имела только сертификацию Национального института стандартов и технологий (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 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 . Любая связь между Amdahl и Fujitsu осуществлялась через «Спецификации только Amdahl», которые были тщательно очищены от любого IP-адреса IBM или каких-либо ссылок на IP-адрес 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 решили не лицензировать IBM z/Architecture для своих квази-MVS операционных систем и аппаратных систем, поэтому MSP и VOS3, хотя номинально поддерживаются их поставщиками, сохраняют большую часть архитектурных ограничений MVS 1980-х годов и по сей день. Поскольку z/OS по-прежнему поддерживает приложения и технологии эпохи MVS (z/OS по-прежнему содержит большую часть кода MVS, хотя и значительно усовершенствованного и улучшенного за десятилетия эволюции), приложения (и рабочие процедуры), работающие на MSP и VOS3, могут перейти на z/OS. гораздо проще, чем в других операционных системах.
Системные службы UNIX
Имя изменено с OpenEdition на OS/390 UNIX System Services.
{{cite book}}: |work=игнорируется ( помощь )