Это статья в формате вольного пересказа более чем сорокалетнего периода работы с разными ОС, главным образом с ОС мейнфрейм, и размышлениями об их сходстве и различиях (в большей степени о различиях, конечно).
Многие популярные ОС выполняются на серверах (речь в статье пойдет исключительно про серверные ОС) х86 (Intel, AMD). Это Линукс разных мастей и названий, и Windows. В силу уклона российского образования в сторону инфраструктур на основе х86 у многих айтишников есть твердое убеждение, что то, как написаны известные ОС, это единственный вариант, как ОС и могут быть написаны. Попытки писать свою, российскую, ОС сводятся к написанию очередного Линукса.
Но есть и другие, современные ОС, выполняющиеся не на х86 платформе. Это одна из ОС IBM мейнфрейм (МФ), называемая z/OS. IBM МФ — тоже весьма современная техническая платформа. В апреле этого года IBM анонсировали новое поколение z17, т. е. семнадцатое поколение, начавшее свою историю в далеком 1964 году.
Есть и другие ОС на МФ кроме z/OS. Например z/VM — виртуальные машины — ведет свою историю из далекого 1967 года. Да‑да, виртуальные машины появились не в начале 2000-х. У z/VM была нелегкая судьба. Был момент в 70-е, когда решался вопрос: а не убить ли ее, чтобы не распылять силы разработчиков IBM, сконцентрированные на создании флагманской ОС IBM — MVS, (о которой, собственно, и будет главным образом говориться в этой статье). К разработчикам MVS был послан чиновник. Он спрашивает одного:
— Ты что делаешь?
— Отлаживаю то‑то и то‑то в MVS.
— А что ты используешь для этого?
— Виртуальную машину VM/370.
И так оказалось, что разработчики MVS отлаживали свои коды на виртуальных машинах VM/370. И чиновник сказал, что если VM хороша для разработчиков MVS, то она хороша и для IBM. Таким образом, VM не была убита и развивается до сих пор, используясь главным образом для Линукс виртуальных машин на МФ (LinuxONE). На этом с VM мы прощаемся в рамках этой статьи, добавив лишь то, что VM на МФ изначально предоставлял полную — нет, неправильно — ПОЛНУЮ виртуализацию реальной машины, в данном случае МФ.
Как я уже намекнул, говорить я буду про MVS. Причем здесь z/OS заявлена в начале статьи. Дело в том, что z/OS на самом деле состоит из двух ОС: MVS и Unix System Services (USS). Да‑да, два в одном. Причем обе системы полностью интегрированы друг с другом таким образом, что в любой программе можно обращаться и использовать фукциональность обеих систем одновременно.
Но все началось даже не с MVS, а как было принято тогда, с DOS, потом появилась OS/360 с несколькими режимами работы на выбор: OS/360 MFT (мультипрограммирование с фиксированным количеством задач), OS/360 MVT (мультипрограммирование с переменным числом задач), OS/360 VS1 (MFT в виртуальной памяти до 16 МБ) и OS/360 VS2 (MVT в виртуальной памяти до 16 МБ). Машины тогда еще даже близко не имели физической памяти в 16 МБ. Вся эта история уложилась в шесть лет, с 1966 до 1972 года. К этому времени IBM накопили богатый опыт в области их МФ и в операционных системах как таковых. Началась разработка MVS, первый релиз которой состоялся в 1974 году.
MVS расшифровывается как Multiple Virtual Storage. Множество виртуальных адресных пространств. Исторически то, что нынче называется Memory (внутренняя память компьютера), в терминологии IBM называется Storage. А то что нынче называется Storage (Disks), называлось и называется DASD (читается как дасди) — Direct Access Storage Device.
Я бы раскрыл MVS как Multiple Virtual Systems. В самом деле, каждое адресное пространство в MVS (кроме адресных пространств данных, есть такие и еще другие) содержит свою копию ОС, т. е. самого MVS. И таким образом программы как бы выполняются на виртуальной машине с собственной ОС, но это всегда MVS. Причем это ОС, сконфигурированная для конкретной программы. Ничего это никому не напоминает? Контейнеры, докеры, кубернетесы. А?
Главное отличие
Перед разработкой MVS были поставлены грандиозные требования, с которых мы и начнем разбираться, чем же различаются современные ОС и, если хотите легаси, система МФ — MVS. Вот что пишется об этом в англоговорящей Википедии — перевожу (очень глубокий по смыслу текст — не поленитесь дочитать его, даже если не все будет понятно с первого раза):
MVS сделала большой шаг вперед в отказоустойчивости, построенной на более ранней возможности STAE, которую IBM назвала восстановлением программного обеспечения. IBM решила сделать это после многих лет практического реального опыта с MVT в деловом мире. Системные сбои теперь оказывали серьезное влияние на бизнес-клиентов, и IBM решила сделать большой скачок в проектировании, предположив, что, несмотря на лучшие методы разработки и тестирования программного обеспечения, «проблемы БУДУТ возникать». Это глубокое предположение сыграло решающую роль в добавлении большого процента кода отказоустойчивости в систему и, вероятно, способствовало успеху системы в устойчивости к программным и аппаратным сбоям. Трудно получить статистическую информацию, чтобы доказать ценность этих конструктивных особенностей (как можно измерить «предотвращенные» или «исправленные» проблемы?), но IBM во многих измерениях улучшила эти функции восстановления отказоустойчивого программного обеспечения и быстрого решения проблем с течением времени. Эта конструкция определила иерархию программ обработки ошибок в системном (ядро/'привилегированный') режиме, называемых Функциональными Процедурами Восстановления, и в пользовательском ('задача' или 'проблемная программа') режиме, называемых «ESTAE» (Extended Specified Task Abnormal Exit routines / Расширенные процедуры аварийного выхода из заданной задачи), которые вызываются в случае, если система обнаруживает ошибку (ошибка аппаратного процессора или хранилища, или программная ошибка). Каждая процедура восстановления делала проблемную функцию повторно вызываемой, собирала диагностические данные об ошибках, достаточные для отладки вызывающей проблемы функции, и либо повторно вызывала эту фукцию, либо обработка ошибок эскалировалась на следующий уровень процедур восстановления в иерархии.
Таким образом, при каждой ошибке система собирала диагностические данные и пыталась выполнить исправление и поддерживать систему в рабочем состоянии. Худшим из возможных решений было отключение пользовательского адресного пространства в случае неисправленных ошибок. Хотя это была начальная точка проектирования, только в последней версии MVS (z/OS) программа восстановления не только гарантировала собственную процедуру восстановления, но и каждая процедура восстановления теперь имеет собственную процедуру восстановления. Эта процедура восстановления была встроена в базовую программу управления MVS, а средства программирования доступны и используются разработчиками прикладных программ и сторонними разработчиками.
На практике восстановление программного обеспечения MVS сделало отладку проблем как проще, так и сложнее. Восстановление программного обеспечения требует, чтобы программы оставляли «следы» того, где они находятся и что они делают, тем самым облегчая отладку, но тот факт, что обработка продолжается, несмотря на ошибку, может перезаписать следы. Ранний сбор данных во время ошибки максимизирует отладку, и для этого существуют средства для процедур восстановления (в режиме задачи и системном режиме).
IBM включила дополнительные критерии для проблемы с программным обеспечением, которое требовала обслуживания IBM. Если основной компонент не мог инициировать восстановление программного обеспечения, это считалось допустимым отказом, о котором следует сообщать. Кроме того, если процедура восстановления не могла собрать существенные диагностические данные, чтобы исходная проблема могла быть решена с помощью данных, собранных этой процедурой восстановления, стандарты IBM диктовали, что эта ошибка должна быть сообщена и требует исправления. Таким образом, стандарты IBM, при их строгом применении, были направлены на постоянное совершенствование.
В дополнении к вышеприведенному от себя добавлю, что если система не в состоянии продолжать успешное функционирование, то она переводит саму себя в режим ожидания с запрещенными прерываниями (т. н. wait status). При этом аппаратным путем предоставляется код ожидания — wait state code (большенство из них на самом деле вовсе ничего не ожидают, а по факту сообщают о причине остановки/аварии). Кодов не просто много, а очень много. Многие из этих кодов имеют уточняющие подкоды. К слову, за 25+ лет работы мне не довелось увидеть ни одного wait state code, кроме двух‑трех во время начальной загрузки системы, и они были связаны с неправильным указанием загрузочных параметров или с проблемой на загрузочном диске.
Кроме аварийных кодов ожидания есть системные коды завершения (System Completion Codes), с которыми могут завершаться прикладные программы и компоненты системы. В отличие от кодов ожидания, коды завершения не сопровождаются остановкой работы самой системы. Эти коды (их много) тоже предоставляют диагностику причины, почему система аварийно завершает прикладную программу или свою системную компоненту.
Вышеописанное различие я считаю ключевым в сравнении систем. Из своего опыта работы с Видовсами, Линуксами, OS/2 в том числе, я могу утверждать, что ничего подобного ни в одной другой системе, включая мейнфреймовские, я не видел.
Второстепенные отличия
Но перейдем к более простым и менее эффектным (может, где‑то и спорным) различиям. Замечание 1: далее многие из вас прочитают про вещи со вроде бы знакомыми названиями, но в совершенно неизвестных вам интерпретациях. Это потому, что я буду описывать классические мейнфреймовские решения. Но надо иметь в виду, что и все более привычные для открытых систем вещи на МФ тоже возможны. Например, МФ может работать с SCSI-устройствами. О них я, если все хорошо пойдет, напишу позже, в других статьях.
Начнем с...
Файловая система
Все привыкли, что файлы образуют иерархию папок (folder) и вложений в них (files), описанные в стандарте POSIX. Так оно и есть в той части z/OS, что называется Unix System Services (USS). Совсем иначе обстоят дела в MVS. Аналогом файлов являются наборы данных (data sets). Довольно отдаленным аналогом, потому что, в отличие от файлов, наборы данных имеют различную организацию. Самая простая — это последовательная организация данных в наборе данных. Аналог обычного файла.
Есть организация, называемая библиотечной. В этой организации есть оглавление и разделы, каждый из которых представляет собой последовательный набор. Обращение к разделам осуществляется в формате <имя‑библиотеки>(имя‑раздела).
Далее есть так называемая Generation Group (группа поколений данных), которая под одним названием представляет группу поколений одного и того же набора данных. Доступ к текущему (последнему) поколению осуществляется в формате <имя‑группы>(0), к предыдущему поколению <имя‑группы>(-1) и т. д., новое поколение <имя‑группы>(+1).
Есть организации наборов данных, ушедшие в прошлое, но все они (как и все остальное начиная с OS/360) до сих пор поддерживаются в текущих версиях z/OS. т. н. индексно‑последовательные и прямая организация наборов данных.
Все организации, ушедшие в прошлое, покрывают на более высоком уровне т. н. VSAM наборами данных. Эта отдельная, большая история, и я не буду останавливаться на ней, чтобы не раздувать статью до бесконечности.
Ну и последней организацией, о которой необходимо сказать, будет иерархическая организация для файловых систем Unix System Services. В двух форматах: HFS, and ZFS.
Системные и пользовательские каталоги
Каталоги в MVS содержат информацию о размещении наборов данных MVS и алиасы для путей (PATH) в иерархиях USS. Исторически и до настоящего времени диски и ленты в MVS существуют в форме т. н. томов (dasd volume). Изначально это были физически отдельные устроства (Device), объединенные в группы через т. н. управляющие устройства (Control Unit CU), которые в свою очередь подключались к каналам ввода‑вывода собственно МФ. К одному CU подключаются многие устройства, например диски. Многие — значит до 256. Все устройства, используемые МФ, по сути, всегда были и есть внешние устройства.
Вернемся к томам (volume). Каждый том имеет уникальную метку (volser — volume serial number), состоящий из числа до шести символов. Каждый том имеет таблицу содержимого тома (VTOC — Volume Table Of Content). В этой таблице находятся данные о наборах данных и их размещении на томе. Наборы данных именуются уникальными для тома составными именами длиной до 44 символов, составленными из до восьмисимвольных квалификаторов. Например SP.SMFDUMP.MVS0EA.D250 704, или проще DSN1, DSN2, и т. д.
Для однозначной адресации набора данных используется сочетание метки тома и имени набора данных. Но как правило, даже в небольшой инсталляции z/OS томов тысячи, наборов данных — сотни тысяч. На помощь приходят системные и пользовательские каталоги.
Каталог — это набор данных, используемый как базы данных о наборах данных и их местонахождении на томах системы. Имена наборов данных, хранимых в каталогах, уникальны и являются индексом для поиска остальных данных (метка тома в простейшем случае) для точной связи с набором данных, где бы он ни находился в системе и дополнительной информации о VSAM наборах данных.
В каждой инсталяции MVS есть один главный каталог (Master Catalog) и сколько угодно пользовательских каталогов (User Catalog). Главный каталог содержит информацию о системных наборах данных и алиасах, связанных с пользовательскими каталогами. Например, мы может создать алиас USER1 в главном каталоге и привязать к нему пользовательский каталог в наборе данных каталога с именем SYS1.USER1.CATALOG. Это будет означать, что данные о наборах данных с именами USER1.* будут сохраняться в и браться из SYS1.USER1.CATALOG. В главном каталоге будет только записан алиас USER1 и имя пользовательского каталога.
В ранние времена существования МФ и ранних версиях ОС было принято размещать наборы данных практически вручную с указанием метки тома и, соответственно, адресовать их двумя именами. Замечу, что на разных томах могли (и могут) существовать наборы данных с одинаковыми именами. Но в каталогах могли быть закаталогизированы только уникальные имена наборов данных.
Data Facility Storage Management Subsystem (DFSMS)
Уже в конце 70-х начале 80-х IBM разрабатывали вспомогательные компонеты MVS, автоматизирующие начальное размещение наборов данных и их миграцию на внешних носителях без каталогов того уровня автоматизации этих процессов, какой в современной Data Facility Storage Management Subsystem (DFSMS) достичь было бы невозможно. Вот поэтому в z/OS присутствуют каталоги. В общем случае пользователи z/OS, включая администраторов и ДБА, придумывают только имена наборов данных, а в большинстве случаев часть имен, следующую за т. н. квалификатором высшего уровня (HLQ). Все остальное происходит автоматически на основании политики используемых DFSMS и созданных администратором DFSMS. Эти политики включают такие понятия, как Storage Class, Management Class, Data Class, Storage Group, Extended Attributes, etc...
DFSMS была анонсирована в 1988 году. До этого, с 1981, эта тема развивалась под названием Data Facility Product (DFP), который объединил несколько продуктов, разрабатываемых с конца 70-х — начала 80-х. DFSMS остается неотъемлемой частью z/OS, автоматизируя и поддерживая все задачи, требуемые для работы с хранилищем на высочайшем уровне.
В открытых системах есть масса вариантов работы с хранилищем и масса файловых систем. Хорошо это или не очень — трудно сказать. Но что‑то говорит мне, что это обилие не гарантирует комплексности и качества этих решений. Я работал в разных Линуксах (SuSe, Red Hat). Программы для работы с хранилищем в них явно не предусматривают случай для очень больших объемов и главное — большого количества приложений в рамках одной системы. И в самом деле: зачем им это, если основным подходом является дробление на много простых установок, имеющих дело с небольшими кусочками чего-то большого. Нет, конечно, можно прицепить огромное хранилище к одному Линуксу и свалить туда все файлы в кучу по разным папкам. Можно и два, и три и т. д. хранилища подключить. Но уже ближе к десятку это превратится в большой головняк.
Однако продолжим.
Workload Manager (WLM)
WLM-функция известна практически в каждой ОС. Когда лет 20 назад я начал заниматься этой темой в zOS, то поинтересовался, как с этим обстоят дела в Юниксах, Линуксах, Виндовсах. Да, есть такие названия в этих системах. Но это совсем не то, что в zOS.
Как правило, WLM в «открытых» системах (Виндовс к ним не относится) обеспечивают аллокацию заданного/желаемого количества CPU тем или иным программам в системе. Это слишком примитивно. Ниже вы узнаете, чем оперирует WLM в zOS.
Основы управления нагрузками
Чтобы сервер мог выполнять свою роль и отвечать ожиданиям пользователей, он должен уметь распределять ресурсы: CPU(s), memory, input‑output — определенным образом, отвечающим ожиданиям тех, в чьих интересах выполняются сервисы на серверах. Обычно это закрепляется в официальных соглашениях. Например, время выполнения транзакции не должно превышать одной секунды.
Операционная система как таковая не знает об ожиданиях пользователей по интересующих их показателям. Тем не менее, в ОС есть проблема выделения процессов в смысле предпочтения перед другими, чтобы функционирование самой ОС было предсказуемым. Для этого используются приоритеты, которые имеются во всех серверных системах — и не только серверных.
Приоритеты существуют с появления ОС, как только они стали многозадачными и многопользовательскими. Но и также давно стало очевидно, что одними приоритетами многообразие показателей качества работы сервисов с точки зрения пользователей обеспечить невозможно. Тем не менее, сервера работают и пользователи в основном удовлетворяются. Как это достигается?
Достигается это на разных платформах по-разному. В этом смысле просматривается две группы подходов: применяемые на мейнфрейм (главным образом в zOS) и на платформах х86, RISC, Power в ОС Windows, Unix, Linux.
В последних как правило используется подход «один сервер‑один сервис» т. е. на физический или виртуальный сервер ставится либо СУБД, либо сервер приложений (Web), либо сервер печати, либо proxy, DNS, AD и так далее по списку. Более того, в тяжелых случаях и для надежности один и тот же сервис располагают на нескольких независимых серверах. В результате сервис обладает всеми ресурсами сервера и обеспечивает показатели, ограниченные только возможностями сервера(‑ов).
Обратной стороной медали такого подхода является перегруженность одних серверов и недогруженность других в одно и тоже время. Или общая недогруженность, если все сервера переумощены, имеют ресурсы, значительно превосходящие потребность в них.
Чем-то в этом плане помогает виртуализация, но с ней связаны другие проблемы. Как‑то с этим борются в облаках. Но сервер на х86 остается сервером х86, Windows — Windows‑ом, а Unix — Unix‑ом.
Посмотрим, как с этим обстоят дела на мейнфрейме, и в частности в zOS.
Принципы работы WLM for zOS
WLM for zOS является подсистемой, осуществляющей автоматические настройки приоритетов выполняемых процессов с целью обеспечения ожиданий пользователей в интересующих их терминах, критериях и количественных показателях. Ожидания пользователя выражаются через политики, являющиеся источником целеполагания для действий WLM. Исполнительным механизмом для WLM являются приоритеты, используемые диспетчером для обслуживания очередей готовых к выполнению процессов.
Изменения приоритетов делаются на основе измерений результатов ранее установленных приоритетов. Измеряются непосредственно те показатели, которые установил пользователь в политике для WLM. Приоритеты могут как повышаться, так и понижаться в зависимости от результатов управления. т. е., выражаясь языком систем автоматического управления WLM, работает по принципу обратной связи.
Результаты измерений разных показателей нормализуются отношением достигнутого значения параметра к заданому. Называется это отношение «индекс производительности» (ПИ). Значение ПИ = 1 означает, что цель управления в точности достигнута. ПИ < 1 означает, что цель достигнута с превышением, а ПИ > 1 означает недостаточность фактического достижения цели. Перелет или недолет в терминах артиллерии.
Для достижения целей в следущем цикле управления WLM ищет «доноров» — процессы с ПИ < 1 и понижет их приоритетность, повышая при этом приоритеты «акцепторов» — процессов с ПИ > 1. Таким образом происходит перераспределение ресурсов сервера для достижения лучшего процесса выполнения формализованных интересов пользователя.
Наличие WLM в zOS позволяет выполнять множества самых разнообразных нагрузок (БД, сервера приложений, пакетная обработка, и т. д.) без негативного влияния одних на другие при этом добиваясь более полноценного использования всех ресурсов вычислительной установки.
Основные понятия WLM for zOS
Пройдемся по основным понятиям и объектам WLM for zOS.
Политики (Policy). Хранилище всех объектов, задаваемых пользователем и используемых WLM в своей работе. Можно это называть конфигурация. В одной и той же системе может существовать несколько разных политик. В каждый момент активна одна из них, и их можно менять на ходу без перезагрузки системы. Например, по времени суток или дням недели.
Класс сервиса (Service class). Основной элемент политики, в котором пользователь прописывает свои «хотелки». Единица связанных целеполаганий и критериев пользователя, достижение которых будет требоваться от WLM. Для описания этих целеполаганий и критериев используются следующие понятия:
Важность цели (Goal Importance). Важность процесса, которому назначен класс сервиса. Задается один из шести уровней числами от 1 до 5. Высший уровень — уровень 1. Он используется для системных процессов, но может присваиваться и прикладным тоже.
Тип цели (Goal). Один из вариантов цели: «среднее время выполнения (Average response time)», «время выполнения с процентом (Response time with percentile)», «темп выполнения(Execution velocity)», «по усмотрению(Discretionary)». «По усмотрению» означает, что ресурсы предоставляются только при условии, что все другие типы цели будут удовлетворены (ПИ = 1 или ПИ < 1).
Период действия цели (Duration). Продолжительность в терминах объема производительности по истечении (по использовании) которого завершается текущий период и происходит переключение на следущий период. Последний период в классе сервиса должен быть безразмерным. Он будет длиться до окончания процесса, выполняемого в данном классе сервиса.
Квалификатор процесса (Qualifier Sets). Своего рода тип признака/атрибута и его значение, на основании которых WLM будет назначать класс сервиса процессу. Важный параметр, который определяет гранулярности различений процессов в системе. Признаки/атрибуты/квалификаторы процессов разные для разных типов процессов в zOS. Это, например, пакетные задания, процессы DB2, веб-процессы, Unix-процессы. Всего их 12 в zOS v1r13 (текущий уровень v3r2). В каждой группе признаков свой набор. Например, для DB2 этот набор состоит из 15 признаков; самый простой для понимания — имя пользователя (User ID). Также имеются признаки, связанные с учетом (accounting), типами присоединения к DB2, сетевые параметры присоединений и т. п. В итоге имеются десятки, если не сотня разных признаков для разного вида процессов, используемых WLM‑ом для связи процессов с классами сервиса.
Из однотипных квалификаторов можно строить группы квалификаторов (Classification Groups), например группа идентификаторов пользователей или имен транзакций и т. п.
Правила связи по классификаторам (Classification Rules). Это раздел политики, где описываются связи между квалификаторами и их значениями и/или группы квалификаторов с классами сервисов (goals).
Работает WLM постоянно. Остановить его нельзя. Охватывает он все процессы без изъятия. zOS из коробки поставляется с вариантом политик по умолчанию, но, как правило, ее надо доводить до нужд конкретной установки.
В Unix-подобных (HP UX, AIX) системах тоже имеются подсистемы, называемые Work Load Manager. Их инструментарий и глубина проникновения несравненно уже по сравнению с WLM for zOS. Даже в AIX продукте от того же IBM WLM попроще и поограниченнее будет. Это определяется отличиями в архитектуре платформ собственно железа и ОС.
В Unix-вариантах существенно ограничен набор квалификаторов процессов и целей. Характер целей тоже совсем иной. Это в случае Unix будет в основном количество CPU, памяти, предоставляемыми тем или иным процессам.
Из разговоров с администраторами Unix я извлек то, что популярностью WLM у них не пользуется, многие даже не знают о существовании WLM в их системах.
На zOS, как было сказано выше, WLM — неотъемлемая часть системы. И что особенно важно — это то, что работа WLM сопровождается сбором огромного объема информации о процессах и о том, как WLM удается достигать целей, заданных пользователем в политике. Это прекрасный, эффективный источник понимания того, что ж такое выполняется в конкретной системе и как следует изменять политики, чтобы лучше достигать целей при меньших затратах на сам процесс управления.
Распределенная обработка против централизованной
Операционные системы стали эффективным средством использования вычислительных мощностей (компьютеров) тогда, когда они стали многопользовательскими и многозадачными и многопроцессорными. Все современные ОС заявлены как много‑, много‑.
Но что мы имеем на практике. Мы имеем в более-менее крупных инфраструктурах под каждую нагрузку кластеры серверов, т. е. мало того, что один сервис (БД, Application, etc..) устанавливается на отдельный сервер и ни с чем не разделяет этот сервер, так и этот сервер разносится на несколько серверов в кластере. В наши дни считается нормой строить ИТ-инфраструктуры обязательно на кластерах.
К чему приводит такой подход? К недоиспользованию ресурсов. Даже когда мы ставим БД на один сервер, бизнес-приложение на другой, Active Directory и DNS на третий и четвертый, мы увидим разные уровни использования всех четырех, и нет никакой возможности поместить все четыре сервиса (а их обычно гораздо больше) на один сервер. Нет возможности, потому что нет механизма интеллектуально разделять ресурсы одного сервера между четырьмя сервисами так, чтобы никто никогда не придавливал бы. Нет таких средств в ОС для х86.
IBM МФ изначально и по наши дни исповедовал подход максимальной загрузки отдельной инсталляции ОС путем взятия на себя смеси различных нагрузок, пакетной обработки и диалоговых программ, баз данных и серверов приложений, сетевых сервисов (FTP/NFS server, etc..), секьюрити и так далее. Работая со смесями нагрузок, разработчики IBM МФ пришли к тому, что выше описано как WLM. Гибкий инструмент настройки работы ОС с множественными нагрузками, так что ни одна не монополизирует использования ресурса и в тоже время все нагрузки достигают своих целей с заданным количеством и качеством.
Ошибочно будет считать, что IBM МФ — это некий неделимый монстр, в котором выполняется одна ОС и все «программы» крутятся в ней. Как было сказано выше, уже в конце 60-х — начале 70-х на МФ появились виртуальные машины, а в 1988 виртуализация была встроена в firmware МФ, так что виртуальные машины стали доступны на уровне железа. Называется это PR/SM (читается как призм) (Processor Resource/System Manager). PR/SM позволяет создавать логические партиции в терминах ресурсов всего МФ. Все ресурсы могут использоваться совместно всеми партициями кроме памяти (memory), которая нарезается из физической памяти кусками произвольного размера сумарно не больше чем размер физической памяти. Таким образом, память в партициях не виртуализирована. Но в системах, выполняемых в партициях, конечно, память виртуализируется. Процессоры МФ могут использоваться совместно, т. е. разделяться системами в партициях, но могут и быть закреплены за ними и использоваться монопольно. В случае разделения каждая партиция получает свой вес, и PR/SM разделяет время доступа к процессорам на основе веса партиций.
Кроме разделения физических ресурсов МФ между системами IBM МФ предоставляет возможность объединять несколько МФ в группу (кластер, если хотите), так что несколько ОС (и это могут быть только zOS) будут работать как единое целое. Называется эта технология Sysplex (от Systems Complex) и/или Parallel Sysplex. До 32 образов zOS, выполняемых на разных физических МФ или в партициях одного МФ, или и то и другое вместе. В отличие от кластеров на х86, в Sysplex используются специализированные устройства и протоколы, позволяющие наращивать мощности линейно.
Многие приложения zOS могут использовать Sysplex, например БД DB2 имеет Data Sharing режим, когда несколько экземпляров DB2 в разных нодах разделяют одну и ту же БД. WLM, описанный выше, расширяет поле своей деятельности на все системы в Sysplex, используя одну и ту же политику и кроме управления ресурсами одной системы может перераспределять ресурсы между партициями с целью лучшего достижения целей сервис-классов в разных партициях.
Таким образом, по максимуму сохраняя достоинства централизованного управления ресурсами с возможностью оптимального их использования под комплексной нагрузкой, IBM МФ предоставляет гибкие возможности распределения и кластеризаций по необходимости. Инфраструктура на МФ может меняться в широких пределах без воздействия на приложения как в рамках одиночного МФ, так и их групп. WLM предоставляет лучшие показатели для понимания, что требуется в смысле ресурсов разным приложениям и сервисам с тем, чтобы подбирать правильную конфигурацию самого МФ, не превышая требуемого и в итоге экономя финансы.
В тоже время инфраструктуры на х86 не имеют иного способа строить инфраструктуры для крупных приложений, кроме как распределяя нагрузки и кластеризуя ресурсы многих серверов. При этом практически полностью теряется возможность оптимизации использования ресурсов и управления их использованием. Другими словами, инфраструктуры на х86 получаются такими, какими они получаются. Менять сложившееся по факту практически невозможно. Да и информации для целенаправленного изменения чего‑либо, как правило, нет. Можно только добавлять или убавлять сервера. Добавлять просто, а вот убавлять весьма проблематично.
Благодарю за внимание всех дочитавших до конца и обещаю ответить в комментариях на любые вопросы, как только статья моя будет принята для этого.
Комментарии (36)
JBFW
09.07.2025 15:41Все дело в деньгах, как правильно заметил предыдущий оратор - вместо ОДНОЙ ОЧЕНЬ ДОРОГОЙ установки, для которой актуально ее максимально сбалансированное использование - в мире х86 принято набрать больше мелких серверов.
И даже не х86: как выяснилось, для некоторых задач можно использовать кучку arm-серверов, каждый из которых стоит копейки, решает одну свою задачу, и поэтому вопрос о его недозагруженности не имеет практического значения.
А в случае перегруженности - добавить еще один копеечный сервер.Второй момент - физическое резервирование: кластер нужен не только для того, чтобы выполнять задачи быстрее чем отдельный сервер, но и для того, чтобы когда один из серверов вышел из строя (потоп, пожар, физическое уничтожение) - оставшиеся подхватили бы работу.
У одного большого мейнфрейма такой опции в принципе нет, если условно говоря он будет уничтожен - пострадают все, у кого на нем что-то работало.То есть, тут принципиально разные пути эволюции, и чем дальше - тем больше они расходятся...
SIISII
09.07.2025 15:41Ну, во-первых, мэйнфреймы отлично масштабируются. При нужде досыпать процессоров и памяти, как правило, проблемой не является.
Во-вторых, ничто не мешает поставить два мэйнфрейма в физически разных местах, чтобы уберечь от всяких там бедствий (точно так же, как и обычные серверы придётся ставить в разных местах).
JBFW
09.07.2025 15:41А вот это опять деньги
Разумеется для каких-то задач это подходит, а для каких-то других больше подходит "стая мелюзги"
Поэтому и говорю что разные пути эволюции.
SIISII
09.07.2025 15:41Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?
В "доисторической эре" не упомянут режим PCP -- однопрограммный. Самая первая версия OS/360 работала именно в этом режиме, поскольку IBM не успевала сделать всё, что хотела, причём для работы было достаточно 32 Кбайта памяти (примерно 14 занимало ядро системы, остальное уходило под программу пользователя или системную программу, не входящую в состав ядра). По мере развития системы требования к памяти росли; самые последние варианты PCP требовали 64 Кбайта. В конце концов, этот режим полностью выпилили, и самым младшим стал MFT, требующий к тому моменту 128 Кбайт (на момент своего появления ему было достаточно 64).
Не отмечена также изначально (или почти изначально) присутствовавшая возможность для прикладных программ создавать контрольные точки (checkpoint), чтобы в случае какого-то сбоя система могла возобновить выполнение программы с этой точки, а не с самого начала.
zVlad909 Автор
09.07.2025 15:41Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?
Это опечатка. Спасибо что заметили. Попробую испрасить.
zVlad909 Автор
09.07.2025 15:41Спасибо за критику. В одной статье охватить все ньюансы соверешенно невозможно. Такой подробности я не ставил своей целью. Статья и так получилась крупной для статьи.
Да, checkpoint, а сколько еще разного было что отличало уже в 70-е годы прешественников нынешнего zOS от нынешних Юникс, Линукс, Виндовз, и еще больше собственно zOS.
jobless
09.07.2025 15:41Спасибо. А планируете статью о z/VM? Особенно интересно во что превратилась CMS (ПДО у нас). Ведь это система со 100% паравиртуализацией. Приходилось ковыряться в макросах ввода вывода и обнаруживать вместо SIO,TIO,HIO обращения к супервизору (кажется термина гипервизор тогда не было) за услугой.
p.s. переписывал для себя stdlib Си-транслятора от НИЦЕВТ под ПДО
p.p.s. Master sheduler FOREVER!!!
SIISII
09.07.2025 15:41У нас в СВМ гипервизор именовался монитором виртуальных машин (МВМ); супервизор же был, в первом приближении, ядром DOS/360 и OS/360, но не VM/370.
ПДО -- да, однозадачная ОС, предназначенная для эксплуатации исключительно под СВМ, поэтому-то никаких команд ввода-вывода в ней нет.
Пы.Сы. А Мастер Шедулер -- это уже про ОС/360, она же ОС ЕС :)
jobless
09.07.2025 15:41ПДО -- да, однозадачная ОС
Однопользовательская, но многозадачная! У меня волею случая была фактически в качестве персоналки ЕС-1007 с терминалами ТС-7063. Поставили под проект который не взлетел и никому до неё дела не было.
SIISII
09.07.2025 15:41Ну да, хотел про однопользовательскую сказать :)
zVlad909 Автор
09.07.2025 15:41Вы не ошиблись. Строго говоря ПДО(CMS) была однопользоваетльской и однозадачной. Это можно легко проверить по документации, но я знаю это потому что в сотрудничестве с НИИЭВМ я с моими коллегами дорабатывал VM/SP Pass-Through для перекачки файлов из ПДО на ПК. Так вот в этом VM/SP Pass-Through был встроенный монитор многозадачночности. Многозадачность исходного ПДО достигалась запуском нескольких виртуальных машин и использованием протоколов связи ВМ через память.
Zhuravlev-A-E
09.07.2025 15:41Приходилось ковыряться в макросах ввода вывода и обнаруживать вместо SIO,TIO,HIO обращения к супервизору (кажется термина гипервизор тогда не было) за услугой.
видимо с помощью команды diag (на виртуальной машине это обращение к гипервизору, термин такой тогда уже был), в частности для ввода/вывода - diag 0020
SIISII
09.07.2025 15:41Угу. Вот только не diag, а просто ДИАГНОСТИКА -- у неё официально нет мнемоники. Впрочем, это уже придирки :)
zVlad909 Автор
09.07.2025 15:41Вы правы про гипервизор, согласно Вашей ссылке, но я не знал. В те года что я работал с СВМ ЕС этот термин в русскоговорящей среде не использовался и в документации на СВМ ЕС на русском языке, насколько я помню, не использовался.
zVlad909 Автор
09.07.2025 15:41Классный вопрос. Очень неожиданный и приятный.
СВМ ЕС, VM/SP это моя бурная молодость. 1985-1995 года (мои 30-40).С коллегами мы внедрили СВМ ЕС с БОС практически во все ВЦ Челябинской области (кроме ВЦ ЖД и еще может двух-трех) и еще пару-тройку ВЦ в Тюмени. Я провел до десяти курсов (40 часов) лекций по СВМ ЕС. Тесно сотрудничал с НИИЭВМ (Котов Михаил Петрович - начальник отдела, был R.I.P). Но, из Вики:
Паравиртуализация (англ. Paravirtualization) — техника виртуализации, при которой гостевые операционные системы подготавливаются для исполнения в виртуализированной среде, для чего их ядро незначительно модифицируется.
VM/370, VM/SP, и соответственно СВМ ЕС изначально были 100% виртуализацией реальной машины. Это значит что любая ОС МФ могла выполняться под VM/370 без каких либо проблем и доработок (исключения есть, но есть и решение для них в опциях конкретной виртуальной машины). Термина паравиртульность в те годы не было.
Да ПДО/CMS была изначально разработано для виртуальной машины под управлением CP (Control Program) (термина Hypervisor тогда тоже не было еще).
Ввод-Вывод в программах под ПДО осуществлялся макросами Ассемблера и операторами ввода-вывода языков высокого уровня заканчивающимися выполнением привелигированной команды DIAG (именно это Вы и должны были обнаруживать вместо SIO,...) - интерфейс к CP - используемый для выполнения ввода-вывода в CP (CP это не супервизор, супервизором тогда называли супервизор ввода-вывода для реальной МФ: DOS, OS/360, MVS, etc..) .
Кроме этого в программах на Ассемблер под ПДО можно было подготавливать программу канала и выполнять ее с SIO, TIO, HIO, но это экзотический подход используемый для экзотических нужд, требующих отличного знания архитектуры ввода-вывода МФ и как СР будет реагировать на это. Я использовал этот поход для работы с терминалом 3270 эмулированным на ПК для копирования файлов.
nv13
09.07.2025 15:41Однокурсник рассказывал, что когда все сотрудники расходились по домам и наступала ночь, их мейнфрейм начинал чем то там сам с собой заниматься, держа 30-40% нагрузки)
zVlad909 Автор
09.07.2025 15:41Был такой подход к использованию МФ когда днем пакетная обработка заданий не выполнялась в угоду диалоговой, дневной. Т.е. запустить пакетное задание было возможно, но т.н. инициаторы заданий запускались после рабочих часов. Задания эти хранились в очередях заданий и после окончания рабочего дня запускались инициаторы и шло выполнение этих пакетных заданий.
К утру все они завершались и результаты их работы либо распечатывались либо помещались в очереди к тем кто их запускал для просмотра и дальнейшей обработки. Пакетные задания и инициаторы имели т.н. классы и часть пакетов, в определенных классах, могли и днем выполняться, а те что не к спеху отправлялись в тот класс(ы) что выполнялись ночью. Вот этими очередями заданий submitted днем и выполняемыми ночью и занимался их мэйнфрэйм.
С появлением WLM (начало 21 века), и даже несколько раньше это стало не актуально и пакетные задания принимаются теперь для исполнения весь день и ночь, но в discretionary сервис классе. В правильном переводе на русский это надо понимать как "по усмотрению". Т.е. такие задания выполняются когда работы во все других сервис классах достигли своей цели и еще остались ресурсы, вот тогда ресурсы выдаются заданиям/работам в discretionary service class. Другими словами эти работы никому не мешают и используют только остатки (объетки если хотите).
Опять же если какие-то задания должны выполняться в любое время суток с выше чем discretionary importance (важностью) они запускаются в очереди классов, обслуживаемых WLM в сервис классах с более высокими важностями, и возможно разными velocity (относительнуые скорости).
Kelbon
09.07.2025 15:41Вся статья состоит из того что там что-то безопаснее и так далее, а можно конкретики? Я напомню, что другие ОС тоже не собираются падать от чего угодно, у нас есть виртуальная память в процессоре, мы можем сами перезапустить программу (а не дать ОС бездумно перезапустить и сделать всё хуже)
zVlad909 Автор
09.07.2025 15:41Спасибо за комментарий. Я ценю любые мнения.
Мне не кажется что статья только о безопасности хотя это довольно важный аспект любой ОС и zOS в этом смысле имеет механизмы просто отсутствующие в других, "современных" (в ковычках потому что текущая версия zOS - 3.2 - анносирована три с небольшим месяца назад) системах.
К моему сожалению Вы неправильно поняли про "перезапуск программы" в статье (кстати этот фрагмент есть отредактированный перевод из англоговорящего сегмента Википедии из статьи про MVS). Вот как это написано в оригиналеЖ
Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).
На практике это проявляется следущим образом. Вы выполняете программу в DB2 (или в другой среде под zOS). Ваша программа завершается с ошибкой. Это не синтаксис SQL, это глубже. Это например закончилась память на диске. У вас будет диагностика от DB2, на уровне DB2, и будет диагностика от zOS, причем от zOS возможно на разных уровнях: DFSMS, супервизор ввода-вывода, или от секьюрити если это была ошибка доступа к ресурсу без права доступа с аккаунтом под которым выполняется программа. Конечно ни DB2, ни zOS при этом не рухнет.
Иными словами это даже не столько процесс восстановления проблемного процесса с надеждой что повтор обойдет ошибку (далеко не все процессы могут восставливаться их повторением), но сбор диагностики для оперативного устранения исходной проблемы.
Я достаточно много работал и с Линукс и с Виндовз, и сейчас работаю (у меня есть сервера Линукс и Виндовз где выполняются установленные мною программы (IBM InfoSphere Data Replication) и у меня есть админ доступ к ним) и я достаточно видел ситуаций когда что-то проходит неуспешно и трудно или невозможно или сложно докапаться до исходного события из-за которого эта неуспешность происходит. В zOS все гораздо прозрачнее, а значит нужно гораздо меньше усилий и знаний/опыта персонала для траблшутинга.
Мне приходилось разбираться с проблемами приложений общего назначения и не только в zOS про которые у меня не было никакого представления что это и как оно устроено. Пользуясь описанными выше особенности zOS я довольно быстро доходил до решения проблемы и устранял ее. Это еще работает потому что в отличии от приложений в Линукс Виндовз где каждое значимое приложение создает свои службы всего что хватает куражу делать (пример Оракл) в zOS есть базовые службы (Facilties) которыми многие приложения предпочитают пользоваться не выдумывая свое, которое изначально будут хуже чем стандартные. Примеры: DFSMS (cм. выше в статье), RACF (Resource Access Control Facility), CAF (Cryptographic Facility), и т.д. Многое из этого в Линуксах и Виндовзах реализуется дополнительными пакетами и их легион, а в zOS есть свой стандартный и высококачественно реализованный набор. Что значительно упрощает работу в zOS. Наконец в zOS есть полноценный Unix и даже некоторые компоненты zOS (например TCP/IP и приложения TCP/IP) выполняются не в MVS, а в Unix System Services.
kibb
09.07.2025 15:41Вышеописанное различие я считаю ключевым в сравнении систем. Из своего опыта работы с Видовсами, Линуксами, OS/2 в том числе, я могу утверждать, что ничего подобного ни в одной другой системе, включая мейнфреймовские, я не видел.
Т.е. паники в unixе или bug-checks (синие экраны) в винде вы не увидели.
В Unix-вариантах существенно ограничен набор квалификаторов процессов и целей. Характер целей тоже совсем иной. Это в случае Unix будет в основном количество CPU, памяти, предоставляемыми тем или иным процессам.
Просто потому что одинаковый термин означает разные вещи. Процесс в MVT скорее похож на cgroup в Linux, или на job в windows.
zOS невероятно старая и дремучая. У меня есть теория, почему IBM гадит Hercules (это sw эмулятор железа, умеет запускать старые версии OS/370). Я считаю, что они таким образом прячут это безобразие от публики, пытаясь поддерживать репутацию чего-то большого и недосягаемого. А так, если иметь с ним опыт, и сравнить с любой современной системой - гуано.
SIISII
09.07.2025 15:41z/OS просто не может быть "невероятно старой" -- для перехода на 64 разряда все собственно системные вещи пришлось переписать по, надеюсь, очевидным причинам. Это OS/360 невероятно старая -- но таки да, написанные под неё программы могут выполняться в z/OS без каких-либо изменений.
И, кстати, в MVT процессов не было. Были задания, задачи, подзадачи, были разделы памяти -- но не процессы.
А ещё кстати -- OS/370 в природе не существует. А Геркулес умеет запускать хоть древние системы, хоть современные.
zVlad909 Автор
09.07.2025 15:41Синии экраны конечно видел. Поэтому и назвал то как обрабатываются такие ситуации в zOS одним из главных отличий. Паники в zOS не бывает.
Просто потому что одинаковый термин означает разные вещи. Процесс в MVT скорее похож на cgroup в Linux, или на job в windows.
MVT это не MVS. Может вы опечатались имея в видутаки MVS, но тем не менее просто процесс это далеко не все что различается в zOS для работы WLM и других конечно целей. Например, в DB2 есть "threads" и "enclaves" (последние есть также в WebSphere). WLM различает их и может назначать им квалифицированные сервис классы.
Дело не терминалогии как таковой а в ее развитости и поддержке. В zOS поддерживается много больше признаков приложений и даже их внутренних компонет для целей менеджмента чем в любой другой известной системе.
Текущая версия zOS 3.2 анносирована 8 апреля 2025 года. Это современнейшааяся система для бэкэнда со всеми возможностями, протоколами, языками и технологиями известными и значимыми.
Геркулес (не мифический герой) без МФ это всего лишь иммитация связки zOS и МФ. Без собственно МФ это всего лишь эммуляция. Hercules приемлен лишь для начального обучения работе с zOS без возможности иметь доступ к настоящему МФ, что в наше время не представляет никаких трудностей. Достаточно выразить желание и назваться студентом и вы можете получить доступ к настоящему МФ. Конечно даже имея такой доступ и будучи студентом вы не осознаете всего что такое есть zOS на МФ. Для это надо поработать администратором, или как раньше говорили ситемным программистом zOS.
mikleh
09.07.2025 15:41z/OS и IBMовские мейнфреймы - великолепный пример того, что талантливый некромант может ехать на дохлой лошади очень долго и даже обгонять многих живых скакунов.
В то время как появление доступных микропроцессоров совершило революцию в мире электроники и позволило перейти к распределенным системам, которые по совокупности характеристик оказались лучше старых мейнфреймов, IBM приложила титанические усилия к тому, чтобы убедить мир, что их система надежна. Имел я опыт общения с z/OS. В далеком 2006, но мне кажется, там ничего принципиально не изменилось за последние 20 лет, как не менялось за предшествующие 30. Система надежная в своем роде, просто она надежно делает то, для чего ее создали. Но это точно не какие-то там ваши прикладные задачи.
SIISII
09.07.2025 15:41Ну так и мэйнфреймы давным-давно уже микропроцессорные. Да и не сказать, что доступные микропроцессоры произвели какую-то революцию. Ну, вышел 8080 (первый более-менее полноценный микропроцессор), и что? Он лишь слегка подвинул мини-ЭВМ из их ниши, поскольку тягаться даже с самыми слабыми из них ему было, скажем так, проблематично. А к тому времени, как производительность микропроцессоров в достаточной степени увеличилась, мини-ЭВМ тоже превратились в микропроцессорные машины, а несколько позже то же самое сделали и мэйнфреймы.
zVlad909 Автор
09.07.2025 15:41Спасибо за мнение. Я уважаю все мнения.
Позвольте спросить чем Вы занимались в zOS в 2006 году? Не подумайте что это наезд, мне действительно хочется как люди имевшие контакт с этой тематикой приходят к такими выводам и заключениям как представили Вы.
Тех кто серьезно работает с ИБМ МФ и zOS, а их везде по миру достаточно много для таких, я бы даже не постеснялся сказать глобальных, проектов, убеждать ни в чем не надо. Они все прекрасно знают, это не секрет. Они работают и никуда уходить не собираются. Да, много ушло. Вот где я сейчас работаю уходят. Уходят с 1995 года и наконец то похоже уйдут и дадут мне уйти наконец на пенсию (мне 70).
Лучше старых мэйнфрэйм это каких? В апреле ИБМ выкатил z17. Вы легко найдете информацию на z17 в сети.
Да, система zOS в связке с МФ супер надежна. И это дотигается не многократным дублированием, а гораздо более интелектуально и централизованно. Распределенные система это не понацея всего, у них есть очень много издержек и недостатков. С увеличением масштаба эти издержки и недостатки многократно увеличиваются и ... увы дорожают. Инфраструктуры на МФ из года в год дешевеют и мощнеют.
Tzimie
Ну WLM очень хорошо управляется ресурсами, но в х86 мире за те же деньги можно купить в 10-100 раз больше железа по мощности и просто не заморачиваться
SIISII
Есть нюансы. Во-первых, выполнение некоего тяжёлого приложения на единой машине с 100500 процессоров и гигантским объёмом ОЗУ, в общем и целом, эффективнее, чем работа на 100500 хилых машинах со связью по локальной сети. Во-вторых, вопросы надёжности и восстановления после сбоев: с IBM тут тягаться тяжело, всё ж они на этой теме были зациклены ещё с 1960-х годов. Ну а в-третьих, в эксплуатации один мэйнфрейм может оказаться дешевле, чем куча обычных серверов.
Но, понятно, все эти вопросы дискуссионные, и в разных ситуациях можно получить разные результаты.
Alex-Freeman
Ну такое, как выше сказали на эти же деньги можно купить во много раз больше железа, сделать FT для критических процессов и соединить чем ни будь типа 400G InfiniBand
zVlad909 Автор
Спасибо за комментарий. Но достоверности для надо сказать что не с 60-х годов ИБМ "зациклился" на надежности, а с началом и в процессе разработки MVS. Это 70-е годы. Желаемый уровень был достигнуть существенно позже. Это очень трудоемкая работа и много кода.
SIISII
Тут Вы ошибаетесь. И средства обработки аппаратных ошибок были с самого начала заложены в аппаратуру, и программная обработка и, по мере возможности, восстановление были предусмотрены ещё в MFT/MVT -- естественно, на тех моделях, которые позволяли это сделать. В частности, сбой (не полный отказ, а именно сбой) процессора или блока памяти при наличии MCH (он мог присутствовать для некоторых моделей Системы 360 и был обязателен для любых моделей Системы 370) во время выполнения прикладной задачи приводил к аварийному завершению этой задачи, а не системы в целом; всё остальное продолжало работать -- ну а сбойнувшая задача при определённых условиях могла быть перезапущена с контрольной точки. Макрокоманда STAE тоже была предусмотрена с самого начала. В MVS очень сильно расширяли расширили и дополнили уже имевшиеся механизмы и, в конце концов, довели их до ума, но сказать, что только в ней начали, будет некорректно.
zVlad909 Автор
Все верно Вы говорите. Полностью с Вами согласен. Сам начинал с OS/360 и именно как системный программист генерирующий системы. Все что Вы перечислили было и в OS/360 (ОС ЕС), но то что я дал в цитате из Википедии про требования к MVS начали внедрятся именно в MVS и это взяло немало лет.
MVS в СССР очень не сильно был распространен. ВЦ ЖД с ним работало И больше я не знаю кто. Да, еще в НИЭВМ был студент которому дали разобраться с MVS и он достиг больших успехов в чтении дампов. Ну и конечно НИЦЭВТ.
zVlad909 Автор
Спасибо за комментарий.
Стандартный, ожидаемый ответ. Много раз слышал такой на мои выступления на эту тему в других местах. Могу согласиться что "..за те же деньги купить в 10-100 раз больше железа по мощности" (хотя вряд ли даже в 10, и точно не в 100), но посмею утверждать что загрузить эти мощности на 100% не получится. А в случае с МФ, zOS и WLM нормальным является потоянная загрузка на 100%.
Кроме того имейте в виду что сравнение по мощности МФ с х86 далеко не тривиальное дело и это не сранение количеств CPU, тактовых частот и размера оперативной памяти (RAM).
C интересом ознакомлюсь с Вашими источниками по этому вопросу.